Re: The story about MyEtherWallet.com hijack or how to become a millionare in 2 hours.
Well there is quite abit of data around that particular server. So it definitely happened. https://twitter.com/GossiTheDog/status/988873775285460992 This tweet is a good start. The server answer to me right now and google safe browsing has flagged it as well for being insecure (no the regular cert-fail warning but deceptivness warning) The SSL-cert is a self-signed one impersonating MyEtherWallet.com. Id take it that 15169 accepted the prefix for some reason over a bilateral peering-sesssion (to the best of my knowledge the equinix routeservers does indeed do filter, but please correct me on this one) with 10297 and hence poisoned the 8.8.8.8 resolver for some time with the wrong ip-addr.
On Tue, Apr 24, 2018 at 08:35:17PM +0200, Fredrik Korsbäck <hugge@nordu.net> wrote a message of 28 lines which said:
Surprised this hasnt "made the news" over at this list yet.
It was discussed several hours before on the Outages mailing list.
Also, there are not a lot of hard facts. The BGP hijacking is clear and easy to find in the usual places.
The supposed rogue DNS server is much more elusive. Nobody apparently thought of querying it with dig during the hijack. There are reports of people being directed to a rogue www.myetherwallet.com but, again, no detail, no IP address, not the certificate of the rogue server, nothing.
seems to be some kind of transparent proxy out of russia with a bogus SSL-cert (but still pretty good) (https://46.161.42.42/)
DNSDB does not confirm this:
% isc-dnsdb-query rdata ip 46.161.42.42 pigroot.sciencesupply.eu. IN A 46.161.42.42 value.rollliquid.com. IN A 46.161.42.42 campsprings.collaspepaw.com. IN A 46.161.42.42 bronchopneumonic.collaspepaw.com. IN A 46.161.42.42 server42.woodorganism.com. IN A 46.161.42.42 ;;; Returned 5 RRs in 0.03 seconds. ;;; DNSDB
Currently, this machine does not accept connections.
-- hugge
On Tue, Apr 24, 2018 at 10:22:19PM +0200, Fredrik Korsbäck wrote:
Id take it that 15169 accepted the prefix for some reason over a bilateral peering-sesssion (to the best of my knowledge the equinix routeservers does indeed do filter, but please correct me on this one) with 10297 and hence poisoned the 8.8.8.8 resolver for some time with the wrong ip-addr.
I have no reason to believe the Equinix route servers propagated or contributed to this hijack, I checked with them. It is a good thing their route server has filters, otherwise the damage could've been even worse! Kind regards, Job
participants (2)
-
Fredrik Korsbäck -
Job Snijders