5 ms·

>A few things can be done on the upper levels of the network stack. On DNS, you can use DNSSEC to sign your records. The IPs returned by the fake DNS would not

>A few things can be done on the upper levels of the network stack. On DNS, you can use DNSSEC to sign your records. The IPs returned by the fake DNS would not have been signed as they do not have the private keys. Would this have helped though? The attacker's DNS resolver could just return records without DNSSEC.

boudin 8y ago
With DNSSEC, the public key is not hosted on the zone iself, where your zone delegation is hosted. It's the DS records : https://uk.godaddy.com/help/what-is-a-ds-record-6148 https://uk.godaddy.com/help/what-is-a-ds-record-6148
- cthalupa 8y ago
  I don't see how this really solve this attack. Like, it solves the specific way they did it - standing up their own DNS server on the IPs they've started advertising - but really, all they have to do is announce the IP(s) that are in the DNSSEC signed records. Then you're still getting the traffic, and nothing has thrown any red flags on the DNSSEC side because nothing has changed as far as DNS goes. The problem is that when you can hijack the routing for an IP there's nothing that can realistically be done with how the internet works today to protect again it. Basically every system of validation requires you have access to some outside authority that can verify authenticity, and if you can announce the route to those IPs to your own infrastructure, you can fool the validation.
  - boudin 8y ago
    If i'm not mistaken, in this scenario they only hijacked the dns traffic and were using it to resolve a domain to another IP, so they were changing the DNS zone. DNSSEC would have prevented this as the change they did in the zone needs to be signed, so it would require them to also get the private key used to sign the zone. It fails to solve the issue if the dns resolver doesn't check DNSSEC signatures though. If they managed to hijack the route to the server itself, there's no need to hijack DNS at all, so it's a different issue that can't be solved at DNS level itself as DNS is not involved in the attack
    - cthalupa 8y ago
      Well, that's specifically my point - fundamentally the two attacks are the same. The key part here is the BGP leak itself. This specific attack would potentially be solved by DNSSEC, but if you can poison the internet routing table, you can just advertise a route for the IP you want to steal traffic from just as easily. The potential downside there is the specificity - last I checked, the internet routing table won't take anything more specific than a /24 - so if you can't provide a more specific route, as-path-length becomes the next determining factor, so you might be in a situation where you can announce the DNS cidr with more specificity and not whatever IP is in the A record... But that's pretty far outside of your control and could just as easily flip the other way. All of this is to say: I think the important part of this whole thing was the BGP hijack, and not necessarily the lower level specifics, because the hijack isn't dependent on a lot of those specifics.
tptacek 8y ago
No, it clearly would not have. In a BGP attack, attackers control IP addresses. Whatever your signed DNS record points to, attackers can simply inject prefixes for.
- richardwhiuk 8y ago
  Interesting that wasn't the approach they took, and instead injected for the DNS server - any idea why?
  - tptacek 8y ago
    They did the simplest thing that could possibly work. Their target didn't even set HSTS. It wasn't exactly the vault at the Bellagio.
    - jgrahamc 8y ago
      I think there's also a tradeoff. If they had redirected a large chunk of AWS traffic to their machines it would have been hard to handle, by redirecting Route53 and poisoning DNS they get a big bang for their buck because the public resolvers (like 8.8.8.8, 9.9.9.9 and 1.1.1.1) will take the poisoned records and do the real work of serving the DNS records. So, I think it was a rational choice.
- AndyMcConachie 8y ago
  The invalid BGP route advertisements redirected folks to the attacker's DNS servers, which served invalid responses to queries. In this instance, had myetherwallet.com been signed, and had a user been using a DNSSEC validating resolver, they would not have visited the invalid site. The attacker's DNS responses would not have validated. Had myetherwallet.com been DNSSEC signed anyone using Google's public DNS resolver at 8.8.8.8 would not have visited the invalid site.
  - tptacek 8y ago
    Again: the attackers control IP addresses. All of them (or, enough to randomly claim AWS addresses from places in the topology nowhere close to AWS). It doesn't matter what the DNS says.

boudin 8y ago

With DNSSEC, the public key is not hosted on the zone iself, where your zone delegation is hosted. It's the DS records : https://uk.godaddy.com/help/what-is-a-ds-record-6148 https://uk.godaddy.com/help/what-is-a-ds-record-6148

cthalupa 8y ago
I don't see how this really solve this attack. Like, it solves the specific way they did it - standing up their own DNS server on the IPs they've started advertising - but really, all they have to do is announce the IP(s) that are in the DNSSEC signed records. Then you're still getting the traffic, and nothing has thrown any red flags on the DNSSEC side because nothing has changed as far as DNS goes. The problem is that when you can hijack the routing for an IP there's nothing that can realistically be done with how the internet works today to protect again it. Basically every system of validation requires you have access to some outside authority that can verify authenticity, and if you can announce the route to those IPs to your own infrastructure, you can fool the validation.
- boudin 8y ago
  If i'm not mistaken, in this scenario they only hijacked the dns traffic and were using it to resolve a domain to another IP, so they were changing the DNS zone. DNSSEC would have prevented this as the change they did in the zone needs to be signed, so it would require them to also get the private key used to sign the zone. It fails to solve the issue if the dns resolver doesn't check DNSSEC signatures though. If they managed to hijack the route to the server itself, there's no need to hijack DNS at all, so it's a different issue that can't be solved at DNS level itself as DNS is not involved in the attack
  - cthalupa 8y ago
    Well, that's specifically my point - fundamentally the two attacks are the same. The key part here is the BGP leak itself. This specific attack would potentially be solved by DNSSEC, but if you can poison the internet routing table, you can just advertise a route for the IP you want to steal traffic from just as easily. The potential downside there is the specificity - last I checked, the internet routing table won't take anything more specific than a /24 - so if you can't provide a more specific route, as-path-length becomes the next determining factor, so you might be in a situation where you can announce the DNS cidr with more specificity and not whatever IP is in the A record... But that's pretty far outside of your control and could just as easily flip the other way. All of this is to say: I think the important part of this whole thing was the BGP hijack, and not necessarily the lower level specifics, because the hijack isn't dependent on a lot of those specifics.

tptacek 8y ago

No, it clearly would not have. In a BGP attack, attackers control IP addresses. Whatever your signed DNS record points to, attackers can simply inject prefixes for.

richardwhiuk 8y ago
Interesting that wasn't the approach they took, and instead injected for the DNS server - any idea why?
- tptacek 8y ago
  They did the simplest thing that could possibly work. Their target didn't even set HSTS. It wasn't exactly the vault at the Bellagio.
  - jgrahamc 8y ago
    I think there's also a tradeoff. If they had redirected a large chunk of AWS traffic to their machines it would have been hard to handle, by redirecting Route53 and poisoning DNS they get a big bang for their buck because the public resolvers (like 8.8.8.8, 9.9.9.9 and 1.1.1.1) will take the poisoned records and do the real work of serving the DNS records. So, I think it was a rational choice.
AndyMcConachie 8y ago
The invalid BGP route advertisements redirected folks to the attacker's DNS servers, which served invalid responses to queries. In this instance, had myetherwallet.com been signed, and had a user been using a DNSSEC validating resolver, they would not have visited the invalid site. The attacker's DNS responses would not have validated. Had myetherwallet.com been DNSSEC signed anyone using Google's public DNS resolver at 8.8.8.8 would not have visited the invalid site.
- tptacek 8y ago
  Again: the attackers control IP addresses. All of them (or, enough to randomly claim AWS addresses from places in the topology nowhere close to AWS). It doesn't matter what the DNS says.