A DNS hijacking wave is targeting companies at an almost unprecedented scale
arstechnica.com
arstechnica.com
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...
If I have control of a dns or register control panel I can use any of the other free ssl certs out there for an attack.
Comodo Will give you a valid cert for 90 days as a trial, others will give you 30 days. AWS cert manager (ok iirc I can only use those within AWS but the point still stands. And if I’m being naughty it’s not gonna be hard to acquire a few stolen CC to bill my AWS usage too) will give you a year. All for free. WooSign / StarCom used to issue free 1 year certs (I think wooSign might still do but they are issued by another CA).
I am having a hard time understanding how more websites using https could possibly be a worse thing.
What we're shifting towards (and maybe already are there) is https is default, and an http-only site is an amateur setup, on the same level as hosting your site via IP (no domain name at all) or with a url like http://myisp.net/~mycompany/default.htm.
Like it or not, browsers are treating sites like this now, and you don't see many "Secured by TrustworthyCo SSL" golden padlock badge images anymore.
So many on HN has this mindset. Criminals just whip up credit cards like it's nothing. They don't. It's noisy to use some grandma's credit card to buy a cert for buttsnstuff.ca when she donates to her local church five times a month. Almost all criminals are fucking dumb or even if they're smart they fuck up before they're good and land themselves in jail. Like at least 98% of them.
HTTPS is a tire fire. Root certs by hostiles. Near-trivial PDAs. Termination at network edge. OS installed certs. Even when it "works" 95% of the packets are on shitty, broken ciphers with no forward secrecy. And that last 5% is built on PKI which we know quantum is breaking pretty fucking soon. Almost nobody rotates access tokens. Almost nobody layers encryption. Almost nobody safeguards certs by locking down permissions. Almost nobody pins them. Almost nobody uses HSTS.
Everything is shabby and shitty and breakable. Let's Encrypt is the wrong solution. It helps irrelevant hobby websites and increases risk for medium sized companies that tried to do the right thing.
I've worked on multiple projects with credit card fraud. I've helped the Canadian government with both cybercrime and machine learning. When I say 98% of criminals are dumb, I really fucking mean it. Not everyone is USG. Most governments are worse-resourced than your run-of-the-mill startup. But people don't want to hear that scriptable HTTPS has downsides and people that are in positions that come with social cache rarely listen. They end up becoming the next generation of people with blinders on. I helped with projects that threw over a dozen people in jail. We got them on two things: IP addresses and financial transactions. Let's Encrypt takes away one possible way we could have gotten them. But people on HN are so deluded about what actual crime looks like.
You know how the vast majority of programmers are these dumb PHP coders that cobble together a Wordpress site? Crime is the same thing only worse. They have no fucking clue what they're doing. They bruteforce passwords and use exploits that target long-out-of-day vulns.
The idea that credit card forms are a form of defense in depth is lunacy.
Scammers are fully aware that banks will also use the data to find other stolen cards.
You get reports that 100 people what their details breached. You look though their transactions. The one thing they all used was momandpopsidebusiness.com for small transactions.
These were prob test transactions so now you start looking for other customers whose cards fall under the same pattern and let the other banks know of your findings.
So scammers will use many “test sites” so if one get found it doesn’t it doesn’t knock out their whole batch.
And word would also quickly spread that cctesterrorscammers.com is a honeypot used by the banks and card processors.
You could look at it like they don’t need the honeypots at all as they just need a few customers to report activity on their accounts and then they can start looking at the data they already have on file.
Most criminals are dumb opportunists.
If your credentials are compromised, even a paying certificate is easy to get.
On a small company, the payment might be noticed. On big companies the odds are low.
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.
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.
But it's worth keeping in mind that most organizations can't use offline signing, because the duct-tape-and-baling-wire solutions DNSSEC applies to people dumping zones with NSEC records all require online signers.
Offline signing is a very useful feature precisely because it makes it easier to differentiate security domains. For example, I could use offline signing for foo.com (along with a registrar lock) but delegate the subdomain dyn.foo.com to a separate SOA that uses real-time signing (or none at all) for use by internal services.
The problem with the modern web PKI is that, as a practical matter, everybody is forced to put their private keys not only online, but unprotected (because HSM and PKCS#11 support isn't that great, yet).[1] Key rotation and certificate expiration doesn't really solve the problem; in fact, rotation exacerbates the problem by 1) forcing you to keep the CA keys online, and 2) incentivizing increasingly loose authorization policies.
Offline signing makes it easier to manage risk in a more robust manner. It's a tool, not a panacea; a tool conspicuously missing from TLS infrastructure. Some newer projects like Wireguard have effectively turned asymmetric key authentication systems into something that walks and quacks exactly like shared passwords. They do it because key management is a hard problem. But I'm not ready to throw in the towel, and the option (both officially and as a practical choice) of offline key signing in DNSSEC is under appreciated. From a security perspective, allowing people to enumerate my subdomains is a small price to pay for permitting me to keep my private keys offline. I don't expect everybody to make that calculation, but it bothers me that people fail to see the value at all.
[1] People faithfully recite the mantra "encrypt at rest" as if that means something. Data at rest is useless. If your data is worth anything then you're going to actually be, you know, using it, and if it's not protected in use then it's all just security theater. This is most clear with the private keys (e.g. stored "encrypted at rest" in KMS) used by cloud services for acquiring access tokens. It's 2019 and industry is still basically using shared passwords--tons of them, a complex web of passwords dutifully pushed around the network by layers of complex software. As if any of it matters to someone who has figured out how to penetrate your network; as if 5 minute or even 5 second password rotation matters to the guy who already figured out how to automate penetration onto your systems.
(You addressed the first half of my comment and not the second).
[0] https://sockpuppet.org/blog/2016/10/27/14-dns-nerds-dont-con...
But instead of 14 nerds, it's the US government (for .com).
I need to read up on DNSSEC.
So it's much worse than it being 14 random nerds then!
/not-sure-if-joking
In DNSSEC/DANE, world only has to watch one entity rather than 10s of entities.
Still you have 3 choices in DNSSEC/DANE,
- get a .xxx, trust dnsroot.
- get a .xxx (when .xxx is as easy to register as xxx.com), trust dnsroot.
- pick one tld out 1000s and get xxx.ttt, and trust ttt and dnsroot.DNSSEC: Google need to watch .com and dnsroot.
Which one is better ?
----
(I am ratelimited so posting here rather than reply to the child post by tptacek https://news.ycombinator.com/item?id=18889809)
Of course they can. There is literally no legal or otherwise difference between Verisign and .com. Chrome can do whatever it want, cause its Google's browser not .com's.
In case when .xxx becomes dishonest, you can just move to your own gtld or .more-trustable tld. In current system, there is no concept of ditching a CA. If a CA decided to missmap a name and you are too small, you are fked.
> it’s actually 1, or 1 AND 2
No you can have DNSSEC without CAs. I have explained that already without changing much of the tls. Basically example.com DNSSEC key become CA for example.com. example.com then would create a tls cert in the usual way. No pain.
But feel free to ask the relevant team at Google, who will give you the same answer.
The operator of .com can use their control over it to get a valid TLS cert issued by any number of CAs.
So the situation is no different currently, trust in the DNS is essential.
So you’re already trusting the DNS, whether protected with DNSSEC or not, in the existing system.
And how is any of this, any of it all, relevant in a world where registrars can simply speak RDAP to CAs? If you believe the problem is that the Internet will (to use your turn of phrase upthread) crumble away unless we secure the DNS for domain validation, why should we forklift out the entire DNS to do so, when we can just get a small group of organizations to deploy RDAP, something they're planning on deploying anyways, and then add that to the 10 Blessed Methods?
No part of DNSSEC makes any sense.
It makes no sense not to try to secure the DNS.
Deploying RDAP and adding it to the CA/B Forum Blessed Methods gives CA's themselves an end-to-end ability to validate domains, decisively solving the DV problem, and doesn't require any of that expense.
Explain to me again why we should choose the former over the latter?
The DNS is already acting as the root of trust for X.509. X.509 does not make the scenario of a rogue TLD operator any different.
Not in DNSSEC. .xxx need only trust dnsroot. yyy.xxx need only trust .yyy and dnsroot.
firefox/chrome/etc with support from important orgs with high value names (google.com/bankofamerica.com/etc) would then make sure that dnsroot/.com/etc do not abuse the trust. They have incentive and methods of punishment. There is no legal authority that clients need to map DNS . to existing root keys. A client can map a.b.c to any key it wants.
The risk of gov overreach is same for both tls and DNSSEC. DNSSEC just trusts fewer entities. The only people who benefit from current system, are CAs who are getting $$$ for nothing.
> https://www.imperialviolet.org/2015/01/17/notdane.html
This is orthogonal. Weak Keys are not required or implied characterstic of DNSSEC.
However who gets to have dnsroot is just a value of a config in DNSSEC. The value itself should not be used to criticize DNSSEC cause its changeable.
Again this is unavoidable in any system that need trust. Thats why I like PoW DNS.
Lets say .com gets mismanaged. Community is infurious. firefox/chrome/etc demands that . remap .com to new more trustable entity. If . does not. firefox/chrome/etc then remap . to new more trustable entity, because .com must be as trustable as ., because .com is that important. New . give back ownership of all tlds to their previous owners. Except for .com. .com goes to the more trustable entity as intended. New .com then does again similar import of all good xxx.com.
In this whole incident, no one loses the ownership of their names except for .com and possibly . .
Now no gov can touch *.com. Though its different for cctld. Those are owned by their respective govs. Same goes for gtld. But no one gets to mess with . .com .org .net.
Ultimately its about deciding who gets to own "x.y.z" string brand globally/contextlessly. World obviously need a single naming system. Either that or expect to have multiple owners to "google.com".
My suggestions are required otherwise why would someone build a global brand if ownership is not safe or guarnteed enough. Future is way more chaotic. Without crypto, a global naming system is not going to survive.
All you need to obtain valid TLS certs for any domain is to make a CA think you control the domain. So the CA’s trust in the DNS root is already functioning as the basis of X.509.
Tell me more about how the whole thing crumbles away? Because I'm pretty sure I'm typing into a TEXTAREA on the real HN, and not some facsimile a DNS hacker created to fool me. The Internet seems to be working fine without the government-run PKI you're saying we have to have.
In pure DANE you need only trust the DNS root.
Yes, DNSSEC is not adopted. But what the intention with it is to stop people hijacking DNS requests (re-routing then to rogue servers for instance,) and then returning spurious answers.
That’s a relatively simple attack, and it can have fairly serious reprocussions. Just return an A record for the domain and host straight HTTP for example. Or re-divert emails with MX records. Publish fake CAA records to bypass that safety lock if you want to supply a cert obtained elsewhere.
The stuff about the US Govt controlling sites is the most facetious of all. As the original (non) story above shows, controlling the DNS is all you need to control a site in the X.509 world. Extended validation is a joke, controlling the domain is the only barrier to getting TLS certs issued for any domain.
We implicitly need to trust the root DNS. That’s a given. So why couldn’t it be the root of trust for secure browsing? Browsers trust something like 1500 CAs out of the box these days, is it really better to create a system where that many orgs need to be honest, and not get hacked, to be effective?
To claim that the current system, with no way to for people know the DNS answers they receive are valid, poses no security risk, is extremely foolish.
If you believe control of the DNS is straightforward without DNSSEC, and that control of the DNS is all you need to get an X.509 certificate issued, go get a GOOGLE.COM certificate misissued. Or FACEBOOK.COM. If you actually manage to do it (you won't), turn the timer on your iPhone on so we can measure how long it takes for Google to kill the CA you got it from, with no notification or further intervention from you.
We do not implicitly trust the DNS roots. In fact, it's a core feature of modern Internet security (modern since the late 1990s) that we do not trust DNS at all. It is a small faction of standards zealots, whose pet standard failed for almost 30 years to either gel or get traction in the market, who have decided that their spurned work turns out to be critical to all Internet security, and they're the ones revisiting that long-decided question.
You made this argument in, I think, 3 other places in this thread, and I'd just like to say that I put some effort into making sure my rebuttals relied on different arguments each time. Collect them all! I wrote them I think a little snarkily, but I tried to exceed the bar you set by claiming I'm "peddling bullshit".
I didn’t for one minute suggest DNSSEC would help in relation to the attack detailed in the article.
I am just saying that to claim securing the DNS is pointless is, in my opinion, a fallacy.
> 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.
[1] https://www.us-cert.gov/ncas/current-activity/2019/01/10/DNS...
[2] https://www.fireeye.com/blog/threat-research/2019/01/global-...
* 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"
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.
There's validity in the approach and I hope it comes back sometime, maybe with additional mechanism around managing pins.
I never set it up for any of my sites for the same reason, just too many ways for it to go wrong.
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...)
Not trivial, but far from impossible for as long as the world maintains that securing the DNS is pointless.
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.
It seems most of the time that a web site is "hacked" (defaced) somebody changed the DNS instead of attacking the actual web server.
SSL signing can potentially be a second line of defense, but only if having control of the DNS (thus web and email) is insufficient to get a cert.
About 20 years ago, I remember having to go through tons of hoops to get a certificate. Faxing corporate docs and other bureaucracy. That can all be forged.
- CNAME record: pointless if your DNS is hacked
- Put a file or add a meta-tag to HTML at a specific path: pointless if your DNS is hacked, they can just add/change A/AAAA record and host their own webserver
- Email to webmaster@.. etc: pointless if your DNS is hacked, add MX record
And this is where a lot of the world is heavily behind say Estonia, Latvia (or other countries) that provide cryptographically secure signed documents tied to people, you practically can't forge those documents.
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.