It's some kind of alarmism over letsencrypt ... "letsencrypt will give tricky attackers a valid certificate for a domain!!!" (if they get control over the domain) (... certs have almost always been granted based on control of the domain, though historically it mostly MX records ... so attackers could do pretty much the same thing 15 years ago)
Something I'm always interested in is how vulnerabilities/attacks are leveraged once a system is compromised.
Obviously if an attacker controls DNS they could do all sorts of bad things: setup a phishing site that looks official, put up a fake press release announcing a merger or sale to manipulate the stock price, hold the domain hostage, etc.
Most of those actions (while bad) would be detected pretty readily. What's clever here is that the attackers _maintain_ a working proxy back to the real system for an extended period of time. Time during which they can then inspect the traffic and peel out sensitive data, presumably to re-use those credentials to break into other systems and escalate further.
This is not a clever trick. This is just a count compromise. Don’t use a shitty domain registrar or a shitty DNS hosting service and for gods sake use multi factor authentication on what is the most crucial element of your online presence.
I pitched that idea at startup school, and got accepted. However, after a while I pivoted to something else, as I decided that the name registry and DNS market is just too crowded. I was afraid that we'd be spending 99% of the time and budget on convincing people they need secure domain/DNS management, instead of building the technology.
Security could be an advantage for a variety of online services. When selecting an online service, I'm starting to use U2F 2FA support as a way to narrow the list of services to consider, so making a decision is easier. Few domain name registrars offer U2F from what I can tell.
Note that these attacks involve compromised accounts with authority servers, so despite being the most visible and impactful DNS attacks of the last few years, DNSSEC would have done little to defend against them; in fact, even in the DNSSEC fantasy-world where DANE replaces X.509 CAs, these attackers would still have accomplished their goals.
DNSSEC has the unique advantage of permitting offline signing. If you go this route, even somebody controlling your authoritative servers wouldn't be able to modify your records.
Obviously the signing of example.com by .com must be secure itself. Otherwise no crypto delegation is secure, including tls signing.
> where DANE replaces X.509 CAs
Much easier migration actually. Just patch all firefox/etc to accept example.com's DNSSEC key as root ca. Then example.com can create its own tls cert. A very simple and minor patch to tls codebase.
"almost unprecedented" implies that there was an earlier wave of DNS hijacking that was even larger (thus setting some kind of precedent). Was there such a precedent? And if so, I didn't see mention of it in the article.
> The National Cybersecurity and Communications Integration Center issued a statement [1] that encouraged administrators to read the FireEye report. [2]
"One DNS hijacking technique involves changing what’s known as the DNS A record."
Could be any record, depends on the intentions of the hijacker. Typically we see web traffic being hijacked to another ipv4 host which indeed, is an A record. Another abuse option could be to alter SPF/DKIM to do a more sophisticated phishing campaign.
What ever happened to HPKP? It seems like that would somewhat mitigate these attacks since they rely on using their control over the domain to get a new DV cert. A pinned certificate would at least protect those who have accessed the sites before.
HPKP could have potentiated these attacks by allowing an attacker to pin their certificate while they were in control of the domain, making it difficult for the domain owner to ever fully regain control.
Being widely phased-out due to being too risky and error-prone. Attacks like this get a lot of media attention, but are pretty rare overall. It's much more common for someone to handle certificates and servers badly somehow, ending up in locking all of your visitors out of your own site, or you never bother with it, but the attacker who takes over your domain does, once again basically hijacking your domain name indefinitely.
I never set it up for any of my sites for the same reason, just too many ways for it to go wrong.
If an attacker can spoof your DNS records (or if they can simply man in the middle the connection between your server and the internet), then they can generate valid Let’s Encrypt certificates.
If I had the time or inclination, I’d write a transparent https gateway that used let’s encrypt to man-in-the-middle http and https connections to servers behind it.
You could imagine deploying something like that on the edge of AWS for mass surveillance purposes, or maybe a misguided white-hat could use it to “secure” http-only services (it’s an improvement in a defeatist sort of way...)
For the MTM scenario, how would you convince letsencrypt’s CA to issue you a cert for any domain? Don’t you need to complete the challenge in order for the CA to issue you a cert?
This is the problem with quickie SSL cert issuance from "Let's Encrypt". If it took 10 days of consistent domain resolution to get an SSL cert, this wouldn't be happening.
The attack is based on compromising control of the victim’s domain.
What’s to stop someone in control of a domain putting records up for 10 days? It’d still happen, just be a delay between compromising the domain and getting the cert is all.
This is clever in that they evaded detection. But I've seen and been the victim of much more sophisticated DNS hijacks that didn't require any credentials.
All domain-validated certificates use factors you can control if you control the domain, whether email or web or DNS. This has nothing to do with Let's Encrypt.
So, the validation done by all publicly trusted Certificate Authorities has to require one of the "Ten Blessed Methods". That's what they're called, though today there are exactly nine of them.
3.2.2.4.1 and 3.2.2.4.5 are now obsolete and no longer used, method 3.2.2.4.11 is basically what happened before the "Ten Blessed Methods" and so now irrelevant.
Methods 3.2.2.4.2 through 3.2.2.4.4 are about contacting somebody based on details from WHOIS by various methods, like sending them a Fax, or giving them a phone call. This is even more laughably insecure than your average DNS setup.
Method 3.2.2.4.6 is the way most people get their first Let's Encrypt cert, and is also a popular option for lots of other bulk CAs, it's about making a change to your web site that the CA can confirm. Obviously they need DNS to reach the site so that's affected.
3.2.2.4.7 puts the change into DNS directly. A better option for Let's Encrypt in most cases, and the only one of these methods that's cryptographically secure end to end (if you deploy DNSSEC).
3.2.2.4.8 turns things upside down and validates based on you having previously proved you control an IP address, then they do a DNS lookup to find that the DNS name you're asking for has an A or AAAA record with that address. This might, maybe, be a good way to get the cert for 1.1.1.1 or things like that, but I will not be astonished if this goes away.
3.2.2.4.9 instead of changing a web page you put a dummy certificate up, created by the CA (not a real cert, it's just to prove you can change the certificate).
3.2.2.4.10 is how the tls-sni-01 (now abandoned) and tls-alpn-01 (new hotness) features in Let's Encrypt work. You do TLS setup, but then you (ab)use that to prove your identity instead of actually delivering a good cert, since if you already had a good cert you wouldn't be trying to get one.
3.2.2.4.12 says basically if you're the DNS registrar AND a Certificate Authority then you can issue everybody who has names under your domain with certificates, since you know who they are.
As you can see, most of these methods depend on DNS, a few don't but are relying on something that makes DNS look like Fort Knox. 3.2.2.4.12 only sidesteps this by making your DNS registrar also your CA, so if they broke into your DNS registrar account they would still get a cert.
[+] [-] ams6110|7 years ago|reply
previously compromised the login credentials for the administration panel of the target’s DNS provider
or
previously compromised domain registrar or ccTLD
Unless I'm missing something, given either of those things, doesn't take much cleverness...
[+] [-] ploxiln|7 years ago|reply
[+] [-] michaelbuckbee|7 years ago|reply
Obviously if an attacker controls DNS they could do all sorts of bad things: setup a phishing site that looks official, put up a fake press release announcing a merger or sale to manipulate the stock price, hold the domain hostage, etc.
Most of those actions (while bad) would be detected pretty readily. What's clever here is that the attackers _maintain_ a working proxy back to the real system for an extended period of time. Time during which they can then inspect the traffic and peel out sensitive data, presumably to re-use those credentials to break into other systems and escalate further.
[+] [-] ttul|7 years ago|reply
[+] [-] LeonM|7 years ago|reply
https://news.ycombinator.com/item?id=17704828
I pitched that idea at startup school, and got accepted. However, after a while I pivoted to something else, as I decided that the name registry and DNS market is just too crowded. I was afraid that we'd be spending 99% of the time and budget on convincing people they need secure domain/DNS management, instead of building the technology.
[+] [-] btrettel|7 years ago|reply
[+] [-] tptacek|7 years ago|reply
[+] [-] fosco|7 years ago|reply
[0] https://sockpuppet.org/blog/2016/10/27/14-dns-nerds-dont-con...
[+] [-] wahern|7 years ago|reply
[+] [-] wav-part|7 years ago|reply
> where DANE replaces X.509 CAs
Much easier migration actually. Just patch all firefox/etc to accept example.com's DNSSEC key as root ca. Then example.com can create its own tls cert. A very simple and minor patch to tls codebase.
[+] [-] cobbzilla|7 years ago|reply
[+] [-] throwaway5752|7 years ago|reply
[+] [-] westurner|7 years ago|reply
[1] https://www.us-cert.gov/ncas/current-activity/2019/01/10/DNS...
[2] https://www.fireeye.com/blog/threat-research/2019/01/global-...
[+] [-] ccnafr|7 years ago|reply
[+] [-] abbadadda|7 years ago|reply
* ensure they’re using multifactor authentication to protect the domain’s administration panel
* check that their A and NS records are valid
* search transparency logs for unauthorized TLS certificates covering their domains and
*conduct internal investigations to assess if networks have been compromised"
[+] [-] mobilemidget|7 years ago|reply
Could be any record, depends on the intentions of the hijacker. Typically we see web traffic being hijacked to another ipv4 host which indeed, is an A record. Another abuse option could be to alter SPF/DKIM to do a more sophisticated phishing campaign.
[+] [-] aidos|7 years ago|reply
[+] [-] bonyt|7 years ago|reply
[+] [-] duskwuff|7 years ago|reply
[+] [-] mh-|7 years ago|reply
https://www.chromestatus.com/feature/5903385005916160
[+] [-] ufmace|7 years ago|reply
I never set it up for any of my sites for the same reason, just too many ways for it to go wrong.
[+] [-] hedora|7 years ago|reply
If I had the time or inclination, I’d write a transparent https gateway that used let’s encrypt to man-in-the-middle http and https connections to servers behind it.
You could imagine deploying something like that on the edge of AWS for mass surveillance purposes, or maybe a misguided white-hat could use it to “secure” http-only services (it’s an improvement in a defeatist sort of way...)
[+] [-] wcdolphin|7 years ago|reply
[+] [-] Animats|7 years ago|reply
[+] [-] topranks|7 years ago|reply
What’s to stop someone in control of a domain putting records up for 10 days? It’d still happen, just be a delay between compromising the domain and getting the cert is all.
[+] [-] josefresco|7 years ago|reply
[+] [-] PaulHoule|7 years ago|reply
[+] [-] JoshTriplett|7 years ago|reply
[+] [-] tialaramex|7 years ago|reply
3.2.2.4.1 and 3.2.2.4.5 are now obsolete and no longer used, method 3.2.2.4.11 is basically what happened before the "Ten Blessed Methods" and so now irrelevant.
Methods 3.2.2.4.2 through 3.2.2.4.4 are about contacting somebody based on details from WHOIS by various methods, like sending them a Fax, or giving them a phone call. This is even more laughably insecure than your average DNS setup.
Method 3.2.2.4.6 is the way most people get their first Let's Encrypt cert, and is also a popular option for lots of other bulk CAs, it's about making a change to your web site that the CA can confirm. Obviously they need DNS to reach the site so that's affected.
3.2.2.4.7 puts the change into DNS directly. A better option for Let's Encrypt in most cases, and the only one of these methods that's cryptographically secure end to end (if you deploy DNSSEC).
3.2.2.4.8 turns things upside down and validates based on you having previously proved you control an IP address, then they do a DNS lookup to find that the DNS name you're asking for has an A or AAAA record with that address. This might, maybe, be a good way to get the cert for 1.1.1.1 or things like that, but I will not be astonished if this goes away.
3.2.2.4.9 instead of changing a web page you put a dummy certificate up, created by the CA (not a real cert, it's just to prove you can change the certificate).
3.2.2.4.10 is how the tls-sni-01 (now abandoned) and tls-alpn-01 (new hotness) features in Let's Encrypt work. You do TLS setup, but then you (ab)use that to prove your identity instead of actually delivering a good cert, since if you already had a good cert you wouldn't be trying to get one.
3.2.2.4.12 says basically if you're the DNS registrar AND a Certificate Authority then you can issue everybody who has names under your domain with certificates, since you know who they are.
As you can see, most of these methods depend on DNS, a few don't but are relying on something that makes DNS look like Fort Knox. 3.2.2.4.12 only sidesteps this by making your DNS registrar also your CA, so if they broke into your DNS registrar account they would still get a cert.