Live data from Hacker News

Hijack of Amazon’s domain service used to reroute web traffic for two hours

doublepulsar.com

251–260 of 291 posts

Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours

#251

Earlier quoted context omitted.

Making sure the cert is valid.

Also do a dry run before each usage, generating a throwaway wallet, and inspect the network tab / use fiddler to check if there is any suspicious sending of data. Even this isn't 100% as they could seed keys if bad person gets control of the website. This has been done many times in the IOTA community for example, albeit those sites were dodgy from the get-go. So I'd probably get a snapshot of their client code when…

Also, you can save the MEW webpage locally and use it.

Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours

#252
post #22

Earlier quoted context omitted.

What's also interesting is in the comments someone stated they'd used a Godaddy certificate issued on april 7. Maybe they had access to their account, or Godaddy's internal systems?

Hi I'm the GM for Security Products at GoDaddy, responsible for the GoDaddy CA. I have checked with the team and do not see any certificates issued to: http://myetherwallet.com/ (including DV). If someone has an image of what was seen, please send it to me at tperez@godaddy.com so that we can investigate further. Thanks Tony

I guess the comment was unfounded. Can't seem to find anything about it with the information available now, they appear to only have used a self signed cert which users ignored.

Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours

#253
A lot of people in here are talking about securing their DNS setups but not their BGP setups.

For any BGP operators out there, you could automate your inbound/outbound BGP prefix filters using IRR/LIR databases, peeringdb.com, RADB etc. Tools like https://github.com/snar/bgpq3 can help with auto-generation. Even manual prefix lists will do, anything is better than nothing!

It would be good if operators could also use AS-SETs so that other operators can see what downstream ASNs should be seen via their peers (and which ones should not).

Also BGP RPKI (Resource Public Key Infrastructure) based ROA (Route Origin Authorisations) can also help to ensure that prefixes are announced by their true originator.

Most networks follow the Pareto rule - 20% of prefixes learnt via BGP (in some cases even less!) are the source/destination for 80% of their traffic flows. Some operators use an approach of writing explicit filters for those 20% of prefixes explicitly blocking them from all their BGP peers except the origin peer sessions.

None of these techniques are fool proof and we all need to play along to improve their impact. They cost nothing, only man hours, and we can all benefit. In metaphor - no encryption is unbreakable but we can try and make it unappealingly difficult.

Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours

#254
Isn’t dns hijacking a major problem? I could go to a Starbucks and setup my own dhcp server on my laptop. A certain fraction of the WiFi devices would probably pick up my dhcp given dns which would reroute requests to my own dns server. Nobody would ever know... or am I misunderstanding something about https?

Or if I was a malware writer I would discretely target hosts files or the local dns configuration - exploits in certain routers to try to reconfigure the complete local network and such.

Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours

#255

Isn’t dns hijacking a major problem? I could go to a Starbucks and setup my own dhcp server on my laptop. A certain fraction of the WiFi devices would probably pick up my dhcp given dns which would reroute requests to my own dns server. Nobody would ever know... or am I misunderstanding something about https? Or if I was a malware writer I would discretely target hosts files or the local dns configuration - exploits…

You are missing something about HTTPS: you can't produce a valid certificate for the site you're trying to impersonate, and therefore users would notice.

HTTPS operates on the assumption that DNS is insecure.

Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours

#256

Isn’t dns hijacking a major problem? I could go to a Starbucks and setup my own dhcp server on my laptop. A certain fraction of the WiFi devices would probably pick up my dhcp given dns which would reroute requests to my own dns server. Nobody would ever know... or am I misunderstanding something about https? Or if I was a malware writer I would discretely target hosts files or the local dns configuration - exploits…

That would only work for websites that do not use HSTS.

Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours

#257

Isn’t dns hijacking a major problem? I could go to a Starbucks and setup my own dhcp server on my laptop. A certain fraction of the WiFi devices would probably pick up my dhcp given dns which would reroute requests to my own dns server. Nobody would ever know... or am I misunderstanding something about https? Or if I was a malware writer I would discretely target hosts files or the local dns configuration - exploits…

Let's hope your local Starbucks has device isolation enabled so that isn't possible.

Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours

#258
> which served the website using a fake certificate

This would cause an untrusted certificate error in browsers.

> failed to obtain an SSL certificate while man-in-the-middle attacking

The sentence doesn't make sense. MITM is by definition an attack where an actor was able to impersonate the target. In this case, they presented an certificate that was not signed by a CA in the root CA file on the clients. So this can be qualified as a failed MITM attempt.

Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours

#259

Isn’t dns hijacking a major problem? I could go to a Starbucks and setup my own dhcp server on my laptop. A certain fraction of the WiFi devices would probably pick up my dhcp given dns which would reroute requests to my own dns server. Nobody would ever know... or am I misunderstanding something about https? Or if I was a malware writer I would discretely target hosts files or the local dns configuration - exploits…

Let's hope your local Starbucks has device isolation enabled so that isn't possible.

I will find out and report back.

Re: Hijack of Amazon’s domain service used to reroute web traffic for two hours

#260
If you use Route53, I encourage to you to check crt.sh if any SSL certificates were issued for your subdomain over the last few days.

Example: https://crt.sh/?Identity=%.MyEtherWallet.com

Keep in mind that crt.sh has a certain time lag between the time a certificate is issued and a certificate entry is inserted into the crt.sh database.

Post reply on HN