AWS DNS network hijack turns MyEtherWallet into ThievesEtherWallet Crooks today hijacked internet connections to Amazon Web Services systems to ultimately steal a chunk of alt-coins from online cryptocurrency website MyEtherWallet.com. The Ethereum wallet developer confirmed on Tuesday morning that thieves redirected DNS lookups for its dot-com to a malicious website masquerading as the real …
Yeah, looks as though Google couldn't get through to AWS Route53 during the hijack, so stopped resolving things.
C.
"Mounting an attack of this scale requires access to BGP routers at major ISPs and real computing resource to deal with so much DNS traffic," Beaumont said. "It seems unlikely Myetherwallet.com was the only target, when they had such levels of access."
This looks like a huge attack, and yet once again the MSM isn't reporting on this...WTF???
Nothing shall be reported about anything as long as there is even a sliver of a hope that Trump has Russian Ties, a sliver of a hope that Russians have Managed the Election and a sliver of a hope that Hillary is Actually Rightfully President. Oh and Assad Must Be Gone because something something Gas.
Nothing shall be reported
Come on, liven up. Nobody said it was Russians. Using a Russian server means very little at a point where you can hack ISP routers and hijack successfully a range with Amazon's name servers from under Amazon's feet.
It goes to prove a perennial point - something those of us involved in various aspects of Internet architecture and peerings have been saying since the late 90-es. The current private peering system in the USA is criminal in its insecurity. There are no ACLs on the route announcements and if you are big enough to peer in the first place, you can announce any shit you like. That is very difficult to pull in Europe where everyone has 30k+ of ACLs generated from routing registry information to guard against that. In order to pull it in Europe you have to hack the RIPE routing registry first, pass all of its safeguards and leave a trail of evidence mile long and half a mile wide doing so.
The issue was further exasperated by the route53 architecture. It does not use traditional large scale Service Provider DNS resilience methods such as anycast so hacking the routing for one region is generally enough to take out any DNS services out of that region.
By the way, I am surprised that a hack at that level did not involve a stolen certificate to sign the web server. Lame.
Last but not least - to all those trying to pretend cyberattack and cyberdefence in the NATO exercise running at the moment. http://www.theregister.co.uk/2018/04/24/nato_locked_shields_2018_cyberwar_excercise/
Here is an example of what a proficient gang can do. Now extrapolate that to a nation state instead of running your joke scenarios about "intermittent messing with the grid".
"This looks like a huge attack, and yet once again the MSM isn't reporting on this...WTF???"
Yeah, let's get the word out to the man on the clapham omnibus that border gateway protocol insecurity caused domain name system resolution to be rerouted that allowed a spoof of an online web wallet using a self-signed https certificate to drain a few peoples cryptocurrency. That'll surely be meaningful to them.
I'd just transferred a couple of secondary domains to AWS and Route 53, thankfully I hadn't spun anything up on them yet, so they aren't likely targets.
I'm glad to know that the global computing network still depends on systems where 1 idiot or bad actor can override the stable infrastructure of high profile 3rd parties like Amazon. DNS, SSL, BGP, and IPV6 have remained stalwart bastions of incompetence that seem impervious to change or reason.
Amazon, Azure, Google all have well known infrastructure. Blindly trusting information that conflicts with the route information advertised by the actual provider on their known BGP and DNS servers is insane.
NOPE. This wasn't the computer's blind trust, it was the user's. People had to click through a https UNTRUSTED certificate error dialog.
Looks like an idiot fee situation. You're an idiot, you get to pay a fee.
To clarify the point of my point a bit more. It is a huge problem that for each supposedly secure request, one bad actor in a chain of third parties can hijack, disrupt, or impersonate connections. The basic internet protocols have trust issues and architectural scope-of -authority issues. So even though the crypto may be secure, and the client and server are fully patched, and not compromised at either end, the session can still get pwned.
BGP relies on every single operator to do their own sanity checking, and can't really handle scope of authority. DNS has no built in security, no one seems to be in a rush to implement DNSSEC, and it has weak scope of authority. SSL certificates have a broken model where any authority can produce a "Valid" cert for any sight or service.
In this attack the SSL warning on the client was just a lose end on the part of the attackers. One which could have been closed by several means. Claiming that this was user error due to the bad cert is ignoring the whole chain of failures that allowed those users to EVER see that bad cert.
If robbers broke into by bank by driving a bulldozer through a wall, dynamiting a security gate, and cracking the vaults combination lock, I'm not going to give the bank a free pass because they tricked my Gran into giving them her safe deposit key at the last step.
The broad strokes of how I'd start to tackle this:
During domain registration, require the registrant to designate their CAs is a similar fashion to SPF records and designate an Authoritative DNS and RIPE/NIC assignment. Plenty of space for it with all of the other cruft, especially if the WHOIS loses weight thanks to the EU.
In DNS, set DNSSEC, establish SPF records, Authoritative IP scopes, etc. Sign your records with the designated cert.
Change the logic of SSL Certificate validation to ensure that the Cert came from withing the scope of authority of a designated CA, and maintain a list of critical and well known hosts/certs for pinning.
Which gets us into striking distance of better BGP sanity checking, since we have a place to check for authoritative information about where our traffic is supposed to go. So if Myanmar or Venezuela start advertising routes for the middle of a block of addresses for the NHS, your ISPs have a reasonable basis for suspicion. As a bonus, implementing it wouldn't require new firmware for every router on the planet, as the changes could be rolled out in a BGP optimizer which may also reduce the load on the core routing infrastructure.
Not huge changes, and mostly could be pushed though by about 4 big companies if wasn't for ICANN.
I have limited sympathy for people who clicked through an SSL warning.
This is something that HTTP public key pinning could have helped with, but that seems to be essentially deprecated due to its potential for foot-shooting. Reg story about that: https://www.theregister.co.uk/2017/10/30/google_hpkp/ . I wonder how popular the Expect-CT thing mentioned there is now? I guess also DNSSEC would have avoided this.
The problem here is that users can be fooled, easily. Years ago I demonstrated to a fellow with multiple doctorates that I could hijack eBay on the LAN and intercept all SSL traffic. I pointed out to him that the certificate wasn't signed, which of course showed all of the warnings, etc. He said that if I hadn't walked him through the whole process, he would have never realised something was wrong.
A lot of sites still sport self-signed certificates. Some ecommerce, some government, and of course personal sites. That's what trains people to just click through regardless of the warnings.
Letsencrypt is free and not self-signed. No need for self-signed personal site certificates any more.
It does seem that the problem here is insufficient enforcement of SSL/HTTPS, unless the attackers were able to get fake SSL certificates by using a non-standard CA? The whole point of SSL certificates is that you do not trust DNS because the certificate says "website.com is 111.222.33.44, public key XYZ, signed CA_name". At which point if you trust the CA you should not be using a different IP address from fake DNS.
DNSSEC would be a good idea though, probably.
...And therein is the flaw in Let's Encrypt and s good example of how it breaks Internet security.
These baddies had control of DNS. So they could easily have set up a Let's Encrypt cert and everyone would have got the nice green banner and padlock, no warnings.
This hack could, fairly easily, have been much much worse.
CAA is a record that all public CAs (incl Letsencrypt) must validate before issuing a certificate for a particular domain. It's new and not widely used bu spread the word brothers and sisters!
https://en.wikipedia.org/wiki/DNS_Certification_Authority_Authorization
All a CAA record does is prevent non-listed Certificate Authorities from issuing a certificate for that domain. And as long as ID-10-T's want to save a few dollars and use Let's Encrypt, a CAA record authorizing Lets Encrypt effectively authorizes the world.
"And as long as ID-10-T's want to save a few dollars and use Let's Encrypt, a CAA record authorizing Lets Encrypt effectively authorizes the world"
Chalk that up as a risk when using Let's Encrypt and its speedy, automated issuing system. I have no issue with certificate issuance being a delayed experience due to the diligence that ought to be in place at least when dealing with signing requests for/from untrusted sources. For those organisations who contract the right CA based on their business requirements, it's handy to know that it got a whole lot harder for people to get certs for your domains.
> These baddies had control of DNS. So they could easily have set up a Let's Encrypt cert
That’s got 5 downvotes; could someone who thinks it’s false explain?
It seems to me that if this attack had caused Let’s Encrypt to resolve the fake DNS they could indeed have got themselves a cert.
Crypto monkeys pride themselves on their tech savvy; they're excellent fodder for this sort of scam. The ordinary fellow on the bus still carries cash, just in case. It is ironical that those who should be most aware and have the most to lose are so easily conned. Polyphemus springs to mind...
The sad truth is that we are trained at an early age to ignore certificate errors. I have called the helpdesk at work (a large corporation with a history of being hacked in places) with certificate errors that prevent some random tool (usually Cisco Jabber) from working to be told to just click through. I am sure my experience is not unusual.
Again the issue is that IT departments and providers routinely can't get their finger out and do certificate change correctly, with the result that they cock it up often enough that your alternatives are: 1. stare at an essentially dead device 2. click through.
> Letsencrypt is free and not self-signed. No need for self-signed personal site certificates any more.
Why would I trust Letsencrypt?
It isn't turtles all the way down, at some point in the chain you have to trust someone.
I've never even heard of Letsencrypt, why should I trust them, and if they're free how can they perform any kind of check.
They're basically producing self-signed certs, nothing more.
Why care if you trust them? The browsers trust them - that's what matters.
They are not self-signed.
You admit your own ignorance in never having heard of letsencrypt (really? in a topic about CAs and certificates?) - you could have at leasf done 30 seconds research before posting.
"They are not self-signed."
No. And Edward never said they were. But from an identification perspective they might as well be, as he did say.
All you need to get a Let's Encrypt cert is to control the domain, either by adding a resource served by the server or by modifying the DNS response. The criminals here *did* control the domain and could have done either of those. So they could, if they wanted to, put a Let's Encrypt cert on the site and browsers would have accepted it as valid.
The people who did this were clever, but they could have been much cleverer.
SSL, with proper CAs provides a guarantee that your session is encrypted and is talking to who you think it is. SSL with Let's Encrypt only provides the former.
Users can be fooled yes, but these are people who were logging onto a website *specifically* to do financial stuff. Move money around, buy or sell something, or gamble on price movements.
You'd think this would make them think twice, and take things seriously.
The issue is however there's a large subset of crypto people who consider themselves a genius on the way to early retirement/being a millionaire.
They "know crypto" and they are in facebook groups talking about which devs at which of the hundreds of new crypto currencies are good, and which are bad. Which offering make sense and are solid etc etc. They openly mock those who aren't funneling every spare penny into crypto. It's arrogance, and this is the result.
A twat tax.
DNSSEC wouldn't have avoided anything because that system is massively flawed in itself.
See, what many people seem to ignore is that the only reason dnssec aware software is doing a look up is because of the dnssec records. Since you're spoofing anyway then what could be easier than simply not including those in the first place? Now your lookup simply tells you that no dnssec is present, just like it does for a majority of the domains.
DNSSEC sounds very nice in theory but it doesn't do too much when needed. Unlike that SSL certificate I might add...
> Do you also have limited sympathy for people who drive over
> any of the 55,000 bridges in the USA that are currently classified
> as "Structurally Deficient"?
If those bridges had signs saying “Warnimg, structurally deficient bridge” and those drivers had to actively “click OK” to continue, then yes my sympathy woild be somewhat less in the event of a failure than otherwise. Note no no sympathy, just less sympathy.
The article mentions "eNet peers with Level 3, Hurricane Electric, Cogent, NTT and others, and is therefore plugged into the internet's backbone." - but it should be noted that out of those four, only Hurricane Electric accepted and propagated the rogue routing announcements.
source: "AS10297's three transit providers (2914, 3356, 174) did not carry these routes." https://twitter.com/InternetIntel/status/988844501207830528
So if it didn't go via AS2914 (NTT), Level 3 or Cogent, does that just leave Hurricane Electric and their customers as potential victims? eNet don't appear to be big by Internet standards (https://www.peeringdb.com/asn/10297) and are only listed as having 4 peers (https://bgpview.io/asn/10297) with 20 prefixes.
So I guess the questions are:
- why didn't HE have route filters for such a small customer
- why doesn't MEW have HSTS given they've been the target of domain hijacking attacks in the past?
- how many potential victims are there given the subset of ISP's using HE peering (although it looks like Google DNS was affected), users of MyEtherWallet and users who would accept an untrusted certificate. Losses are reportedly US$150k so not many?
Why on earth is an online wallet site not using HSTS??
HSTS was designed to prevent this attack. If enabled, it stops you clicking through the security warning. You just get a certificate error page, you don't get an option to click through. Because we have trained users to click through the error messages.
HSTS also prevents you from accidentally visiting the http: version of the site, your web browser will silently redirect you to the https: version.
HSTS is a flag that the website enables. Once enabled, browsers remember it (and it can't be unset), so you're protected for subsequent visits to the site. A website owner can also ask for their site to be added to the HSTS preload list, which is built into the browser, to provide protection to people visiting the site for the first time.
I had a serious fight to get HSTS and DNSSSEC implemented because Marketing was whining too loudly about the "What if..." nonsense. I won but I got scarred. Now we don't even bother to let them know unless they ask and being Marketing types they are totally inept technically so they never ask.
What was Hurricane Electric thinking not to have proper filters in place. For a small ISP like eNet it could easy have been added, even more shocking that HE does not seem to use automatic IRR filtering tools then? This issue as was well documented in a 2006 paper already so why 12 years later are these mistakes still going on. https://www.cc.gatech.edu/classes/AY2007/cs7260_spring/papers/p396-ramachandran.pdf
1. Why favor Cloudflare over Google public DNS? There's no evidence provided that Cloudflare's "immunity" was anything but a fluke.
2. Why the assumption that state actors would be more effective than organized crime? "Private enterprise" engaged in the illegal drug trade seems to have gotten the better of its government adversaries for decades, and the childish naivite of bureaucrats and business leaders about computer security is only a little less pronounced than that of the public at large.
3. Most of us are idiots. That's why the human race is doomed.
Private enterprise" engaged in the illegal drug trade seems to have gotten the better of has been paying for the assistance of its government adversaries for decades
The industry(ies) that *benefit* from war on (communism/drugs/terror/alcohol/red man/black man/furriners/aliens/USSR/Kraken/etc) benefit by selling to *both* sides, and additionally go out of their way to coordinate cooperation between the teams. Your paranoia is *far* too shallow.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
