7 ms·
An attack against BGP where the attacker takes over traffic for an IP address isn't at all prevented by DNSSEC. The sequence there is: 1. I hijack traffic des
by akerl_ 1y ago
An attack against BGP where the attacker takes over traffic for an IP address isn't at all prevented by DNSSEC.
The sequence there is:
1. I hijack traffic destined for an IP address
2. Anything whose DNS resolves to that IP, regardless of whether or not they use DNSSEC, starts coming to me
In this model, I don't bother trying to hijack the IP of a DNS server: that's a pain because with multi-perspective validation, I plausibly have to hijack a bunch of different IPs in a bunch of different spots. So instead I just hijack the IP of the service I want to get a malicious cert for, and serve up responses to let me pass the ALPN ACME challenge.
- cyberax 1y agoSure. But you won't have a TLS certificate for that address, if the host uses a DNS-based ACME challenge and prohibits the plain HTTP challenge: https://letsencrypt.org/docs/caa/ https://letsencrypt.org/docs/caa/ So DNSSEC still offers protection here.
- akerl_ 1y agoOk, so deploying DNSSEC would specifically solve the threat model of an attacker who can perform a BGP hijack of IP addresses, but doesn’t want to hijack multiple DNS server IPs because that’s more work, for a domain that has CAA records and disallows validation by ALPN. That feels like a pretty narrow gain to justify strapping all this to all my zones and eating the operational cost and risk that if I mess it up, my site stops existing for a while
- cyberax 1y ago> but doesn’t want to hijack multiple DNS server IPs because that’s more work No. I'm saying that you can _not_ hijack a DNSSEC-enabled DNS name, even if you have a full control over the network. The DNSSEC public keys for the domain are stored in the top-level domain zone. Which in turn is protected by a signature with the key from the root zone.
- akerl_ 1y agoI don’t think you’re grokking what a BGP hijack looks like. The attacker steals traffic destined to an IP address at the routing layer. They aren’t hijacking a name, they’re hijacking traffic to the IP that name resolves to. In the case of attacking the ALPN ACME validation, they hijack the IP address of the site they want a TLS certificate for: example.org resolves to 1.2.3.4, I hijack traffic to 1.2.3.4, the DNS flow is unchanged, the verification traffic comes to me, and I get a certificate for example.org The DNS server hijack works the same way: I don’t try to change what ns1.example.org resolves to. I hijack traffic to the real IP that it resolves to and serve up responses for the site I want to hijack saying “yea, these are the records you want and don’t worry, the DS bit is set to true”. Though it’s worth remembering that both DNS and BGP attacks are basically a rounding error compared to the instances of ATO-based attacks
- cyberax 1y agoI know exactly how BGP works, I actually implemented a BGP reflector long time ago. My home has two DIA circuits and my home network is announced via BGP. > In the case of attacking the ALPN ACME validation, they hijack the IP address of the site they want a TLS certificate for: example.org resolves to 1.2.3.4, I hijack traffic to 1.2.3.4, the DNS flow is unchanged, the verification traffic comes to me, and I get a certificate for example.org As I said, a CAA record in DNS will prohibit this, instructing the ACME CA to use the DNS challenge. > I hijack traffic to the real IP that it resolves to and serve up responses for the site I want to hijack saying “yea, these are the records you want and don’t worry, the DS bit is set to true”. And then your faked DNS replies will have a wrong signature because you don't have the private key for the DNS zone. And DNSSEC-validating clients will detect this because the top-level domain will have a DNSKEY entry for the hijacked domain. You can't fake the replies from the top-level domain DNS because it in turn will have a DNSKEY entry in the root zone.