Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

doublepulsar.com

Post reply on HN
Print view View original

181–190 of 291 posts

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

#181

Post by pfg »

LinuxBender wrote: post #130
bklyn11201 wrote: post #38

Getting a basic certificate issued is incredibly easy these days. If you own the DNS resolution, you can get a cert. Here a few ways I can think of to make this harder for an attacker: * Add a Strict-Transport-Security to all HTTPS requests. This means the attacker will need to get a valid cert (still easy if you can hijack BGP). * Pick a preferred SSL issuer and stick with them. Add a CAA DNS record only allowing th…

If I control the network, I can strip off any security that might be in DNS. I can change or remove CAA records, DNSSEC, etc. Those things currently fail open, which exception to DNS replication which will take "refresh" time to fail. I can then get new certs for the DNS I now control. HSTS just means use HTTPS. It doesn't validate the previous cert. That is HPKP which almost nobody uses unless they control the clien…

One could argue that in a perfect world the combination of DNSSEC and CAA should stop attacks of this nature. However, this only holds up under a rather limited set of circumstances:

1. The targeted domain would need to make use of both DNSSEC and CAA in the first place. I doubt that's true for more than a tenth of one percent of all domains out there.

2. The attackers would have to only target DNS resolution, and not the IP ranges hosting the targeted domain itself.*

3. Every single CA out there would have to follow the Baseline Requirements to the letter and fail closed for DNSSEC-enabled domains.†

I'm not sure if that makes for a good argument in favour of wading into the cesspit of DNSSEC.

* By targeting the IP ranges the site is hosted at, rather than the authoritative DNS, an attacker would be able to complete a "Agreed-Upon Change to Website" challenge as defined in the Baseline Requirements (http-01 in ACME). There's work being done to somewhat mitigate this by extending CAA to support whitelisting domain validation methods.

† From what I recall, when researchers looked into this this shortly after CAA became mandatory for CAs, a number of CAs were found to have issues with DNSSEC enforcement. Additionally, some argued the language in the Baseline Requirements regarding CAA and DNSSEC was quite ambiguous.

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

#182

Post by Kalium »

web007 wrote: post #121
Kalium wrote: post #64

Earlier quoted context omitted.

> * Pick a preferred SSL issuer and stick with them. Add a CAA DNS record only allowing that one issuer. It may be worth also suggesting HPKP here. That would be effective for many customers. > * DNSSEC? Make sure to choose an SSL issuer that will correctly test DNSSEC? This basically means you can't use Route53, which is a deal-breaker for a lot of people running services.

I thought HPKP was essentially deprecated - too many footgun scenarios and not enough specificity on "what to pin" since CAs can use / issue with multiple intermediates.

There are definitely a series of foot-gun-y scenarios with HPKP, just as with full DNSSEC. It's just one of the few things I can think of that gives you the ability to detect when a cert has changed unexpectedly.

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

#183

Post by cft »

rocqua wrote: post #179
cft wrote: post #175

Earlier quoted context omitted.

Is it possible to get a TLD registrar to set a very short TTL like 5min on your NS record? Then you can switch to a backup DNS hosted on another network fast.

Yes, you can set a short TTL on your NS record, but that would not keep this attack from hijacking your site. This attack intercepts the clients DNS lookup, so the DNS a browser is talking to is ill-behaved. No amount of correct setup here will work because the ill-behaved DNS server will just replace your setup with whatever that server wants. There is no strong defense against this as a website. With an app the sol…

Wait: in example.com say .com registrar sets a 5min TTL on NS record for example.com that resolves to 1.2.3.4. That means that your DNS server is at 1.2.3.4, serving your A and MX records. An attacker BGP hijacks 1.2.3.4. You change NS record in your .com registrar settings to 5.6.7.8 that is not compromised. Notice I am not talking about your A or MX records that you controlled on a compromised IP, but of NS record that a .com registrar controls. So after 5 min the browsers contact a non-compromised nameserver at 5.6.7.8 to get your A records.

I think unless a TLD registrar gets hijacked that mitigates the attack on your own DNS after the NS TTL

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

#184

Post by rocqua »

plange wrote: post #180
rocqua wrote: post #170

Earlier quoted context omitted.

Not an expert either, but I think it was slightly different. Firstly, I believe BGP hijacking works by announcing a more specific prefix rather than path-length. That is to get to 3.3.3.3 A 3.3.0.0/16 route takes precedence over a 3.0.0.0/8 route. Secondly, this attack did not obtain a valid cert. They probably could have using spoofing (either of MX or just of A records and using lets-encrypt), but they did not. Thi…

Confusion prevention squad: > That is to get to 3.3.3.3 A 3.3.0.0/16 route takes precedence over a 3.0.0.0/32 route. I think you mean: > That is to get to 3.3.3.3 A 3.3.0.0/16 route takes precedence over a 3.0.0.0/8 route. a /32 is _more_ specific.

Thanks, you are totally right. Not sure what caused that brain fart. Luckily, I could still edit.

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

#185

Post by [deleted] »

cft wrote: post #183
rocqua wrote: post #179

Earlier quoted context omitted.

Yes, you can set a short TTL on your NS record, but that would not keep this attack from hijacking your site. This attack intercepts the clients DNS lookup, so the DNS a browser is talking to is ill-behaved. No amount of correct setup here will work because the ill-behaved DNS server will just replace your setup with whatever that server wants. There is no strong defense against this as a website. With an app the sol…

Wait: in example.com say .com registrar sets a 5min TTL on NS record for example.com that resolves to 1.2.3.4. That means that your DNS server is at 1.2.3.4, serving your A and MX records. An attacker BGP hijacks 1.2.3.4. You change NS record in your .com registrar settings to 5.6.7.8 that is not compromised. Notice I am not talking about your A or MX records that you controlled on a compromised IP, but of NS record…

[deleted]

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

#186

Post by textmode »

viraptor wrote: post #173
textmode wrote: post #140

"Between 11am until 1pm UTC today, DNS traffic-the phone book of the internet, routing you to your favourite websites-was hijacked by an unknown actor." Is it worth keeping a record of the IP addresses for "your favorite websites"? For example, with IP addresses saved, would this enable reaching the websites ven if DNS is not working? How often do these "favorite websites" change IP addresses? Are they all the same i…

Depends on how the website is hosted. If it's a tiny website on a single server/VPS, then it's going to be fairly stable with the IP. For anything else, you're out of luck. Shared hosting or PaaS will change ips when needed internally, or to rebalance the traffic, or when new hosts come up. Anyone with large enough traffic will use some edge network like CloudFlare which would also get a different address depending o…

"Anyone with large enough traffic will use some edge network like Cloudflare which would also get a different address depending on your location."

What if the request is always sent from the same location?

What if when the user moves location, e.g., from one country to another, she updates her stored IP addresses?

"And you can't tell easily which one want."

Personal experience as a user is that when it is an "intended" change, the previous IP address no longer hosts the content.

Personal experience is that this is surprisingly rare.

In the case of the more common load balancing, the user who may store several IP addresses for the website, all of which continue to serve the content. She can choose which of those she prefers.

Personal experience is that this works very well.

Further questions:

If this was a BGP hijack, why did the hijackers target the IP addresses of DNS servers, rather than the target IP addresses of the websites?

If they had targeted the IP addresses of the websites, then what would be the possible mitigations, if any?

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

#187

Post by maltalex »

bklyn11201 wrote: post #38

Getting a basic certificate issued is incredibly easy these days. If you own the DNS resolution, you can get a cert. Here a few ways I can think of to make this harder for an attacker: * Add a Strict-Transport-Security to all HTTPS requests. This means the attacker will need to get a valid cert (still easy if you can hijack BGP). * Pick a preferred SSL issuer and stick with them. Add a CAA DNS record only allowing th…

None of these steps would help against a BGP hijack since the IP address space itself is being stolen, not just the domain name. Heck, with a good hijack, the attacker could even get himself a valid automated certificate from let's encrypt.

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

#188

Post by rocqua »

cft wrote: post #183
rocqua wrote: post #179

Earlier quoted context omitted.

Yes, you can set a short TTL on your NS record, but that would not keep this attack from hijacking your site. This attack intercepts the clients DNS lookup, so the DNS a browser is talking to is ill-behaved. No amount of correct setup here will work because the ill-behaved DNS server will just replace your setup with whatever that server wants. There is no strong defense against this as a website. With an app the sol…

Wait: in example.com say .com registrar sets a 5min TTL on NS record for example.com that resolves to 1.2.3.4. That means that your DNS server is at 1.2.3.4, serving your A and MX records. An attacker BGP hijacks 1.2.3.4. You change NS record in your .com registrar settings to 5.6.7.8 that is not compromised. Notice I am not talking about your A or MX records that you controlled on a compromised IP, but of NS record…

You are right, I was thinking of a different attack. Something like a BGP-hijack of 8.8.8.8 , 1.1.1.1 or similar often used DNS resolvers.

Here though, people using area53 for DNS probably can't move away from it as they are stuck on amazon.

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

#189

Post by pfg »

C4K3 wrote: post #178
bklyn11201 wrote: post #51

Earlier quoted context omitted.

HSTS wouldn't help users clicking through warnings, but it's a good thing to have (myetherwallet doesn't use HSTS). CAA record would only help in remaining TTL. Once expired, then it doesn't matter. So yeah, these seem like decent steps to help protect but certainly not going to 100% prevent an attack like this one.

I'm seeing HSTS on https://www.myetherwallet.com/ curl -I https://www.myetherwallet.com/ strict-transport-security: max-age=63072000; includeSubdomains; preload

Presumably that's fairly new. The domain hasn't made it on the HSTS preload list shipped by browsers yet, so my guess would be they started using HSTS in response to this attack.

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

#190

Post by omarforgotpwd »

viraptor wrote: post #164
omarforgotpwd wrote: post #43

Wow. Just wow. These BGP vulnerabilities are ridculous. Imagine, someone taking over DNS for even a small subset of people and being able to basically just rewrite the internet as they see fit, completely taking control of anything. Even without being able to get a valid SSL certificate you could do a lot of damage. For example, let's say I rewrote requests for SomeNationalBank.com to my proxy server. I make a reques…

SomeNationalBank.com in my experience uses 1 or 2 ciphers which are not the most modern, but are secure enough. For a few reasons there are almost no banks which would allow you to drop lower than aes-128-cbc.

Certain configurations of aes-128-cbc using certain software stacks have been found to have vulnerabilities. But if you really couldn't decrypt it, you could at least save anything you think might have the password in it, and then wait until you can decrypt it at some point in the future.
Post reply on HN