7 ms·

Spoofing DNS with fragments

31 points by ahubert 8y ago

teddyh 8y ago
Well, yes, DNS is spoofable. The solution is, and has always been, DNSSEC. This just makes it slightly more urgent to start using it.
- eximius 8y ago
  > Fragmented DNS responses happen occasionally with DNSSEC It is not clear that DNSSEC helps in this case. Given just the text (and my unfamiliarity with DNS protocols on the wire) it seems to imply this occurs because of DNSSEC. EDIT: > In the meantime, DNSSEC does actually protect against this vulnerability, but it does require that your domain is signed and that your CA validates. This may not yet be the case. Nevermind.
- tptacek 8y ago
  DNS is virtually never spoofed in practice because of a combination of (1) sensitive systems being built to assume the DNS was already insecure and (2) the settings where DNS spoofing is useful are already so insecure than DNS security doesn't do much to help you (for instance, coffee shop wireless). In practice, there are two significant targets for DNS spoofing: 1. SMTP email, where TLS isn't universally required among MTAs. 2. CA domain validation. For problem (1), we has SMTP STS, which simply establishes a long-term requirement for TLS between a pair of MTAs, sidestepping the spoofing problem. For problem (2), there is a whole panoply of countermeasures to DNS spoofing, erratically deployed across a variety of CAs. CAs do not as a rule do strict DNSSEC validation (it's too broken), but many of them do multi-perspective lookups which make packet-level spoofing tricky to accomplish in practice. The real solution to this problem isn't a government-run PKI that forklifts in a whole new DNS protocol, but rather a culling of CAs that can't deploy adequate countermeasures against these attacks. Note that the Usenix paper illustrates scenarios in which DNSSEC makes this attack easier, not harder.
  - tialaramex 8y ago
    > CAs do not as a rule do strict DNSSEC validation (it's too broken), but many of them do multi-perspective lookups which make packet-level spoofing tricky to accomplish in practice. Can you give specific examples of "many of them" doing multi-perspective DNS today ?
    - tptacek 8y ago
      Can't. But if I've given the impression that the majority of CAs are sophisticated, that wasn't intentional.
      - tialaramex 8y ago
        So to be clear: You say DNSSEC validation is "too broken" for any public CA to be doing that, but actually the largest (by issuance volume) does exactly that Whereas you say multi-perspective is so prevalent "many of them" do it, but you aren't able to produce any examples at all. Maybe time for a re-think?
        tptacek 8y ago
        I do not understand your argument at all, sorry.
        JdeBP 8y ago
        tialaramex is mis-reading "do not as a rule" as "never" and then constructing a straw man based upon that, and is also asking you to specifically name any CA that does what you say many of them do. (-:
  - dane-pgp 8y ago
    Just to clarify, it is a "government-run" PKI in the sense that some governments control some TLDs, as opposed to the CA ecosystem where a single rogue (government-run) CA can issue a certificate for any domain (happily ignoring any CAA record). It would be nice to have something like Certificate Transparency for DNSSEC (at least for the TLDs), but for now CT has the problem that it is only a requirement for new certs, and a rogue CA could backdate a cert they maliciously created for your domain.
- notafraudster 8y ago
  Naive question: Is there any reason, given that my registrar allows me to turn on DNSSEC, that I shouldn't? Any negative consequences or things I need to account for? Or is this a no duh move?
  - tptacek 8y ago
    Yes: if you DNSSEC-sign your domain but don't keep up maintenance of it, your domain will vanish off the Internet for users behind strict-validating DNS caches. That happened to HBO NOW for all Comcast users the week they rolled out. (You'd also be participating in a government-run PKI but I'm not assuming your politics preclude you from doing so).
    - regecks 8y ago
      > but don't keep up maintenance of it Not sure about this phrasing. It's not on the domain owner to maintain anything, you just need to not forget you have DNSSEC enabled if you move your zone to different NS. It's up to your DNS host to handle things like key rollovers and most people aren't writing and running their own authoritative DNS servers. Regardless, the risk vs reward is still heavily in favor of not signing. It is so sparsely deployed that it can't be relied upon for anything (like DANE) and it seems like DoH (both for clients and between resolvers) may end up being the better way forward.
      - tptacek 8y ago
        In addition to DoH, there's already a direct-to-domain-registrar protocol in the works for the CA problem. DNSSEC is, I think, pretty much dead.
        cpach 8y ago
        ”there's already a direct-to-domain-registrar protocol in the works for the CA problem” Sounds interesting. Are there any drafts/discussions available?
- gerdesj 8y ago
  DNSSEC is probably the way forward. However it is bloody awful to implement, OK it isn't really but it is hard (not the same thing). I suggest that DNSSEC evangelists look at how Let's Encrypt are doing things for TLS certs and learn a few lessons. Just in case I've put a nose out of joint: on a brand new Ubuntu Bionic minimal install with a NAT port forward to 80/tcp from WAN, I can get a LE cert with: # apt install certbot # certbot -d systemname.example.co.uk Fill in a few questions as required and off we go. There is a systemd timer unit that automatically renews certs or you can use cron. Naively using both by accident does not matter. In general the LE system just works because clients have been designed to work like that (my general experience here is only Linux - Windows and Apples may have a different experience) Now, DNSSEC has not been handled like LE. Window's DNS daemon seems to have DNSSEC built into the GUI (mmc) from at least 2012R2. The options on Linux and others are not quite so easy.
peterwwillis 8y ago
Don't rely on DNS for security. DNS is a reverse phone book. It doesn't matter if the phone book is über-secure. Even if the number you get is really your friend Gary's number, the person who picks up on the other end might not be Gary. Maybe Fred knocked Gary out with a lead pipe and answered the phone. You can't be sure it's Gary talking to you just because the phone number was right.
- jedisct1 8y ago
  It's not a phone book. It's a distributed key/value store.
  - ASalazarMX 8y ago
    A distributed IP book then?
  - Dylan16807 8y ago
    Phone books also have non-phone information on some entries, but their primary purpose is to get phone numbers. The analogy is fine.
  - gerdesj 8y ago
    I can go to nearly any house and pick up a phone book and get the equivalent of A records (name to address).
  - ianleeclark 8y ago
    A phone book is a great analogy? If you want someone in Berlin, you'd look in a Berlin phonebook; if you want someone in Austin, you'd look in an Austin phonebook. Maybe the underlying storage mechanism doesn't rely on consistent hashing or buckets, but phone books are inherently distributed key/value stores.
- deytempo 8y ago
  Right! Same thing with trusting a site just because it has SSL. All it ensures is that you are having a private conversation. You could be having a private conversation with SATAN.
Dylan16807 8y ago
Do any DNS resolvers monitor for huge spikes of spoofed results? Is falling back to TCP for those queries likely to break much?
- gerdesj 8y ago
  What are you trying to fix?
  - Dylan16807 8y ago
    Poisoning attacks. Also reporting them.
- baolongtrann 8y ago
  My question as someone who doesn't know much about DNS beyond the most basic stuff, how would a DNS resolver know a when query is spoofed? You can maintain a query cache to filter out unsolicited (spoof) responses but what would make a query valid or invalid? I'm talking about DNS/UDP btw. Maybe some sort of challenges? Authentication? Like DNS cookies or something.
  - Dylan16807 8y ago
    At a level that needs OS cooperation to detect, there are packets with invalid ports or invalid sequence numbers for TCP. On top of that, the requests themselves have a 16-bit ID that acts as a random cookie. If we could extend DNS to make the ID bigger that would solve the problem by itself. There have been attempts to use rAnDOm CAsE to make spoofing harder, but it only works on some DNS servers. For attacks like this, there are thousands to billions of spoofed responses coming in. It's not subtle at all, or very hard to keep track of the domains under fire. Edit: Oh wait, the queries themselves? That's a very different problem and there's no good solution. Harass more ISPs into implementing filters that drop spoofed IPs from their users.
    - JdeBP 8y ago
      Daniel J. Bernstein discussed the collision likelihoods with message ID and port numbers years ago, which he later repeated on his WWW site; distinguishing between various forms of attackers according to how much network access they have (for snooping the query traffic). From the design of his TAICLOCK protocol one could tell that such thinking had been a contributory factor. 236 bytes are available for (say) a client-generated random number. * http://cr.yp.to/proto/taiclock.txt http://cr.yp.to/proto/taiclock.txt * http://cr.yp.to/djbdns/forgery.html http://cr.yp.to/djbdns/forgery.html

31 points by ahubert 8y ago

Well, yes, DNS is spoofable. The solution is, and has always been, DNSSEC. This just makes it slightly more urgent to start using it.

eximius 8y ago
> Fragmented DNS responses happen occasionally with DNSSEC It is not clear that DNSSEC helps in this case. Given just the text (and my unfamiliarity with DNS protocols on the wire) it seems to imply this occurs because of DNSSEC. EDIT: > In the meantime, DNSSEC does actually protect against this vulnerability, but it does require that your domain is signed and that your CA validates. This may not yet be the case. Nevermind.
tptacek 8y ago
DNS is virtually never spoofed in practice because of a combination of (1) sensitive systems being built to assume the DNS was already insecure and (2) the settings where DNS spoofing is useful are already so insecure than DNS security doesn't do much to help you (for instance, coffee shop wireless). In practice, there are two significant targets for DNS spoofing: 1. SMTP email, where TLS isn't universally required among MTAs. 2. CA domain validation. For problem (1), we has SMTP STS, which simply establishes a long-term requirement for TLS between a pair of MTAs, sidestepping the spoofing problem. For problem (2), there is a whole panoply of countermeasures to DNS spoofing, erratically deployed across a variety of CAs. CAs do not as a rule do strict DNSSEC validation (it's too broken), but many of them do multi-perspective lookups which make packet-level spoofing tricky to accomplish in practice. The real solution to this problem isn't a government-run PKI that forklifts in a whole new DNS protocol, but rather a culling of CAs that can't deploy adequate countermeasures against these attacks. Note that the Usenix paper illustrates scenarios in which DNSSEC makes this attack easier, not harder.
- tialaramex 8y ago
  > CAs do not as a rule do strict DNSSEC validation (it's too broken), but many of them do multi-perspective lookups which make packet-level spoofing tricky to accomplish in practice. Can you give specific examples of "many of them" doing multi-perspective DNS today ?
  - tptacek 8y ago
    Can't. But if I've given the impression that the majority of CAs are sophisticated, that wasn't intentional.
    - tialaramex 8y ago
      So to be clear: You say DNSSEC validation is "too broken" for any public CA to be doing that, but actually the largest (by issuance volume) does exactly that Whereas you say multi-perspective is so prevalent "many of them" do it, but you aren't able to produce any examples at all. Maybe time for a re-think?
      - tptacek 8y ago
        I do not understand your argument at all, sorry.
        JdeBP 8y ago
        tialaramex is mis-reading "do not as a rule" as "never" and then constructing a straw man based upon that, and is also asking you to specifically name any CA that does what you say many of them do. (-:
- dane-pgp 8y ago
  Just to clarify, it is a "government-run" PKI in the sense that some governments control some TLDs, as opposed to the CA ecosystem where a single rogue (government-run) CA can issue a certificate for any domain (happily ignoring any CAA record). It would be nice to have something like Certificate Transparency for DNSSEC (at least for the TLDs), but for now CT has the problem that it is only a requirement for new certs, and a rogue CA could backdate a cert they maliciously created for your domain.
notafraudster 8y ago
Naive question: Is there any reason, given that my registrar allows me to turn on DNSSEC, that I shouldn't? Any negative consequences or things I need to account for? Or is this a no duh move?
- tptacek 8y ago
  Yes: if you DNSSEC-sign your domain but don't keep up maintenance of it, your domain will vanish off the Internet for users behind strict-validating DNS caches. That happened to HBO NOW for all Comcast users the week they rolled out. (You'd also be participating in a government-run PKI but I'm not assuming your politics preclude you from doing so).
  - regecks 8y ago
    > but don't keep up maintenance of it Not sure about this phrasing. It's not on the domain owner to maintain anything, you just need to not forget you have DNSSEC enabled if you move your zone to different NS. It's up to your DNS host to handle things like key rollovers and most people aren't writing and running their own authoritative DNS servers. Regardless, the risk vs reward is still heavily in favor of not signing. It is so sparsely deployed that it can't be relied upon for anything (like DANE) and it seems like DoH (both for clients and between resolvers) may end up being the better way forward.
    - tptacek 8y ago
      In addition to DoH, there's already a direct-to-domain-registrar protocol in the works for the CA problem. DNSSEC is, I think, pretty much dead.
      - cpach 8y ago
        ”there's already a direct-to-domain-registrar protocol in the works for the CA problem” Sounds interesting. Are there any drafts/discussions available?
gerdesj 8y ago
DNSSEC is probably the way forward. However it is bloody awful to implement, OK it isn't really but it is hard (not the same thing). I suggest that DNSSEC evangelists look at how Let's Encrypt are doing things for TLS certs and learn a few lessons. Just in case I've put a nose out of joint: on a brand new Ubuntu Bionic minimal install with a NAT port forward to 80/tcp from WAN, I can get a LE cert with: # apt install certbot # certbot -d systemname.example.co.uk Fill in a few questions as required and off we go. There is a systemd timer unit that automatically renews certs or you can use cron. Naively using both by accident does not matter. In general the LE system just works because clients have been designed to work like that (my general experience here is only Linux - Windows and Apples may have a different experience) Now, DNSSEC has not been handled like LE. Window's DNS daemon seems to have DNSSEC built into the GUI (mmc) from at least 2012R2. The options on Linux and others are not quite so easy.

peterwwillis 8y ago

Don't rely on DNS for security. DNS is a reverse phone book. It doesn't matter if the phone book is über-secure. Even if the number you get is really your friend Gary's number, the person who picks up on the other end might not be Gary. Maybe Fred knocked Gary out with a lead pipe and answered the phone. You can't be sure it's Gary talking to you just because the phone number was right.

jedisct1 8y ago
It's not a phone book. It's a distributed key/value store.
- ASalazarMX 8y ago
  A distributed IP book then?
- Dylan16807 8y ago
  Phone books also have non-phone information on some entries, but their primary purpose is to get phone numbers. The analogy is fine.
- gerdesj 8y ago
  I can go to nearly any house and pick up a phone book and get the equivalent of A records (name to address).
- ianleeclark 8y ago
  A phone book is a great analogy? If you want someone in Berlin, you'd look in a Berlin phonebook; if you want someone in Austin, you'd look in an Austin phonebook. Maybe the underlying storage mechanism doesn't rely on consistent hashing or buckets, but phone books are inherently distributed key/value stores.
deytempo 8y ago
Right! Same thing with trusting a site just because it has SSL. All it ensures is that you are having a private conversation. You could be having a private conversation with SATAN.

Dylan16807 8y ago

Do any DNS resolvers monitor for huge spikes of spoofed results? Is falling back to TCP for those queries likely to break much?

gerdesj 8y ago
What are you trying to fix?
- Dylan16807 8y ago
  Poisoning attacks. Also reporting them.
baolongtrann 8y ago
My question as someone who doesn't know much about DNS beyond the most basic stuff, how would a DNS resolver know a when query is spoofed? You can maintain a query cache to filter out unsolicited (spoof) responses but what would make a query valid or invalid? I'm talking about DNS/UDP btw. Maybe some sort of challenges? Authentication? Like DNS cookies or something.
- Dylan16807 8y ago
  At a level that needs OS cooperation to detect, there are packets with invalid ports or invalid sequence numbers for TCP. On top of that, the requests themselves have a 16-bit ID that acts as a random cookie. If we could extend DNS to make the ID bigger that would solve the problem by itself. There have been attempts to use rAnDOm CAsE to make spoofing harder, but it only works on some DNS servers. For attacks like this, there are thousands to billions of spoofed responses coming in. It's not subtle at all, or very hard to keep track of the domains under fire. Edit: Oh wait, the queries themselves? That's a very different problem and there's no good solution. Harass more ISPs into implementing filters that drop spoofed IPs from their users.
  - JdeBP 8y ago
    Daniel J. Bernstein discussed the collision likelihoods with message ID and port numbers years ago, which he later repeated on his WWW site; distinguishing between various forms of attackers according to how much network access they have (for snooping the query traffic). From the design of his TAICLOCK protocol one could tell that such thinking had been a contributory factor. 236 bytes are available for (say) a client-generated random number. * http://cr.yp.to/proto/taiclock.txt http://cr.yp.to/proto/taiclock.txt * http://cr.yp.to/djbdns/forgery.html http://cr.yp.to/djbdns/forgery.html