Re: Attacking networks using DHCP, DNS - probably kills DNSSEC
William Allen Simpson [EMAIL PROTECTED] writes: Would this be the DHCP working group that on at least 2 occasions when I was there, insisted that secure DHCP wouldn't require a secret, since DHCP isn't supposed to require configuration? Given that their goal is zero-configuration networking, I can see that being required to provide a shared secret would mess things up a bit for them. It'd be a bit like PKIX being asked to make ease-of-use a consideration in their work, or OpenPGP to take X.509 compatibility into account. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Attacking networks using DHCP, DNS - probably kills DNSSEC
On Tue, 1 Jul 2003, Peter Gutmann wrote: Given that their goal is zero-configuration networking, I can see that being required to provide a shared secret would mess things up a bit for them. It'd be a bit like PKIX being asked to make ease-of-use a consideration in their work, or OpenPGP to take X.509 compatibility into account. I tend to agree... I don't think zero-configuration networking has a real possibility to create any safety zones beyond the immediate physical machine. After all, if you can plug it into any network and it just works, you can plug it into an insecure or subverted network and it'll just work. At the very least you've got to have a file of keys. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Attacking networks using DHCP, DNS - probably kills DNSSEC
In message [EMAIL PROTECTED], Simon Josefsson writes: Of course, everything fails if you ALSO get your DNSSEC root key from the DHCP server, but in this case you shouldn't expect to be secure. I wouldn't be surprised if some people suggest pushing the DNSSEC root key via DHCP though, because alas, getting the right key into the laptop in the first place is a difficult problem. I can pretty much guarantee that the IETF will never standardize that, except possibly in conjunction with authenticated dhcp. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of Firewalls book) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Attacking networks using DHCP, DNS - probably kills DNSSEC
At 11:49 PM 06/29/2003 +0200, Simon Josefsson wrote: No, I believe only one of the following situations can occur: * Your laptop see and uses the name yahoo.com, and the DNS server translate them into yahoo.com.attackersdomain.com. If your laptop knows the DNSSEC root key, the attacker cannot spoof yahoo.com since it doesn't know the yahoo.com key. This attack is essentially a man-in-the-middle attack between you and your recursive DNS server. That doesn't happen. (Well, it could, but as you point out, it's not a successful attack methodology, because DNSSEC was designed to correctly take care of this.) * Your laptop see and uses the name yahoo.com.attackersdomain.com. You may be able to verify this using your DNSSEC root key, if the attackersdomain.com people have set up DNSSEC for their spoofed entries, but unless you are using bad software or judgment, you will not confuse this for the real yahoo.com. The DNS suffix business is designed so that your laptop tries to use yahoo.com.attackersdomain.com, either before yahoo.com or after unsuccessfully trying yahoo.com, depending on implementation. It may be bad judgement, but it's designed to support intranet sites for domains that want their web browsers and email to let you refer to marketing as opposed to marketing.webservers.example.com, and Netscape-derived browsers support it as well as IE. Of course, everything fails if you ALSO get your DNSSEC root key from the DHCP server, but in this case you shouldn't expect to be secure. I wouldn't be surprised if some people suggest pushing the DNSSEC root key via DHCP though, because alas, getting the right key into the laptop in the first place is a difficult problem. I agree with you and Steve that this would be a Really Bad Idea. The only way to make it secure is to use an authenticated DHCP, which means you have to put authentication keys in somehow, plus you need a reasonable response for handling authentication failures, which means you need a user interface as well. It's also the wrong scope, since the DNSSEC is global information, not connection-oriented information, so it's not really DHCP's job. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Attacking networks using DHCP, DNS - probably kills DNSSEC NOT
Bill Stewart [EMAIL PROTECTED] writes: * Your laptop see and uses the name yahoo.com.attackersdomain.com. You may be able to verify this using your DNSSEC root key, if the attackersdomain.com people have set up DNSSEC for their spoofed entries, but unless you are using bad software or judgment, you will not confuse this for the real yahoo.com. The DNS suffix business is designed so that your laptop tries to use yahoo.com.attackersdomain.com, either before yahoo.com or after unsuccessfully trying yahoo.com, depending on implementation. It may be bad judgement, but it's designed to support intranet sites for domains that want their web browsers and email to let you refer to marketing as opposed to marketing.webservers.example.com, and Netscape-derived browsers support it as well as IE. It can be a useful feature, but it does not circumvent DNSSEC in any way, that I can see. DNSSEC see yahoo.com.attackersdomain.com and can verify that the IP addresses for that host are the one that the owner of the y.c.a.c domain publishes, and that is what DNSSEC delivers. The bad judgement I referred to was if your software, after DNSSEC verification, confuses yahoo.com with yahoo.com.attackersdomain.com. Of course, everything fails if you ALSO get your DNSSEC root key from the DHCP server, but in this case you shouldn't expect to be secure. I wouldn't be surprised if some people suggest pushing the DNSSEC root key via DHCP though, because alas, getting the right key into the laptop in the first place is a difficult problem. I agree with you and Steve that this would be a Really Bad Idea. The only way to make it secure is to use an authenticated DHCP, which means you have to put authentication keys in somehow, plus you need a reasonable response for handling authentication failures, which means you need a user interface as well. It's also the wrong scope, since the DNSSEC is global information, not connection-oriented information, so it's not really DHCP's job. I think it is simpler to have the DNSSEC root key installed with the DNSSEC software. If someone can replace the root key in that distribution channel, they could also modify your DNSSEC software, so you are no worse off. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Attacking networks using DHCP, DNS - probably kills DNSSEC NOT
On Mon, 30 Jun 2003, Simon Josefsson wrote: Bill Stewart [EMAIL PROTECTED] writes: * Your laptop see and uses the name yahoo.com.attackersdomain.com. You may be able to verify this using your DNSSEC root key, if the attackersdomain.com people have set up DNSSEC for their spoofed entries, but unless you are using bad software or judgment, you will not confuse this for the real yahoo.com. The DNS suffix business is designed so that your laptop tries to use yahoo.com.attackersdomain.com, either before yahoo.com or after unsuccessfully trying yahoo.com, depending on implementation. It may be bad judgement, but it's designed to support intranet sites for domains that want their web browsers and email to let you refer to marketing as opposed to marketing.webservers.example.com, and Netscape-derived browsers support it as well as IE. It can be a useful feature, but it does not circumvent DNSSEC in any way, that I can see. DNSSEC see yahoo.com.attackersdomain.com and can verify that the IP addresses for that host are the one that the owner of the y.c.a.c domain publishes, and that is what DNSSEC delivers. The bad judgement I referred to was if your software, after DNSSEC verification, confuses yahoo.com with yahoo.com.attackersdomain.com. I think that the problem would be somewhat ameliorated if there were a DNS cache on the laptop itself. It would still use DNS servers, but if it got a different IP number for the same address, it should notify someone. This can happen without an attack going on, if the legitimate addressee's DNS record changes because the IP address of that service actually changes - but with sites like Yahoo, Paypal, etc, they've got a lot of infrastructure and momentum there. Those IP addresses don't change on a whim. And those are the major targets for a DNS spoof. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Attacking networks using DHCP, DNS - probably kills DNSSEC NOT
In message [EMAIL PROTECTED], Simon Josefsson writes: Bill Stewart [EMAIL PROTECTED] writes: * Your laptop see and uses the name yahoo.com.attackersdomain.com. You may be able to verify this using your DNSSEC root key, if the attackersdomain.com people have set up DNSSEC for their spoofed entries, but unless you are using bad software or judgment, you will not confuse this for the real yahoo.com. The DNS suffix business is designed so that your laptop tries to use yahoo.com.attackersdomain.com, either before yahoo.com or after unsuccessfully trying yahoo.com, depending on implementation. It may be bad judgement, but it's designed to support intranet sites for domains that want their web browsers and email to let you refer to marketing as opposed to marketing.webservers.example.com, and Netscape-derived browsers support it as well as IE. It can be a useful feature, but it does not circumvent DNSSEC in any way, that I can see. DNSSEC see yahoo.com.attackersdomain.com and can verify that the IP addresses for that host are the one that the owner of the y.c.a.c domain publishes, and that is what DNSSEC delivers. The bad judgement I referred to was if your software, after DNSSEC verification, confuses yahoo.com with yahoo.com.attackersdomain.com. It's also not a new problem -- see RFC 1535. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of Firewalls book) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Attacking networks using DHCP, DNS - probably kills DNSSEC
Steven M. Bellovin wrote: In message [EMAIL PROTECTED], Simon Josefsson writes: Of course, everything fails if you ALSO get your DNSSEC root key from the DHCP server, but in this case you shouldn't expect to be secure. I wouldn't be surprised if some people suggest pushing the DNSSEC root key via DHCP though, because alas, getting the right key into the laptop in the first place is a difficult problem. I can pretty much guarantee that the IETF will never standardize that, except possibly in conjunction with authenticated dhcp. Would this be the DHCP working group that on at least 2 occasions when I was there, insisted that secure DHCP wouldn't require a secret, since DHCP isn't supposed to require configuration? And all I was proposing at the time was username, challenge, MD5-hash response (very CHAP-like). They can configure ARP addresses for security, but having both the user and administrator configure a per host secret was apparently out of the question. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Attacking networks using DHCP, DNS - probably kills DNSSEC NOT
Once upon a time, bear sent Kevin a note that said... I think that the problem would be somewhat ameliorated if there were a DNS cache on the laptop itself. It would still use DNS servers, but if it got a different IP number for the same address, it should notify someone. Win2k and WinXP have a cache for the resolver. To show it, type 'ipconfig /displaydns' in a command prompt. To clear it (which is a good troubleshooting tactic) us 'ipconfig /flushdns' K -- In Vino Veritas http://userguide.mozdev.org http://astroturfgarden.com/~ktneely - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Attacking networks using DHCP, DNS - probably kills DNSSEC
In message [EMAIL PROTECTED], Bill Stewart writes: Somebody did an interesting attack on a cable network's customers. They cracked the cable company's DHCP server, got it to provide a Connection-specific DNS suffic pointing to a machine they owned, and also told it to use their DNS server. This meant that when your machine wanted to look up yahoo.com, it would look up yahoo.com.attackersdomain.com instead. This looks like it has the ability to work around DNSSEC. Somebody trying to verify that they'd correctly reached yahoo.com would instead verify that they'd correctly reached yahoo.com.attackersdomain.com, which can provide all the signatures it needs to make this convincing. So if you're depending on DNSSEC to secure your IPSEC connection, do make sure your DNS server doesn't have a suffix of echelon.nsa.gov... No, that's just not true of DNSsec. DNSsec doesn't depend on the integrity of the connection to your DNS server; rather, the RRsets are digitally signed. In other words, it works a lot like certificates, with a trust chain going back to a magic root key. I'm not saying that there can't be problems with that model, but compromised DNS servers (and poisoned DNS caches) are among the major threat models it was designed to deal with. If nothing else, the existence of caching DNS servers, which are not authoritative for the information they hand out, makes a transmission-based solution pretty useless. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of Firewalls book) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Attacking networks using DHCP, DNS - probably kills DNSSEC
At 11:15 PM 06/28/2003 -0400, Steven M. Bellovin wrote: In message [EMAIL PROTECTED], Bill Stewart writes: This looks like it has the ability to work around DNSSEC. Somebody trying to verify that they'd correctly reached yahoo.com would instead verify that they'd correctly reached yahoo.com.attackersdomain.com, which can provide all the signatures it needs to make this convincing. So if you're depending on DNSSEC to secure your IPSEC connection, do make sure your DNS server doesn't have a suffix of echelon.nsa.gov... No, that's just not true of DNSsec. DNSsec doesn't depend on the integrity of the connection to your DNS server; rather, the RRsets are digitally signed. In other words, it works a lot like certificates, with a trust chain going back to a magic root key. I thought about that, and I think this is an exception, because this attack tricks your machine into using the trust chain yahoo.com.attackersdomain.com., which it controls, instead of the trust chain yahoo.com., which DNSSEC protects adequately. So you're getting a trustable answer to the wrong query. I'm less sure of the implementation issues of the Connection-specific DNS suffix, and I've seen conflicting documentation. If the resolver looks up domain.suffix before domain, then the attacker's DNS doesn't need to control the DNS access, and only needs to provide the attacker's certificates, but if the resolver looks up domain before domain.suffix, then the attacker also needs to make sure that the lookup of domain fails, which is most easily done by telling the DHCP client to use the attacker's DNS server along with telling it the suffix. (That doesn't add any extra work to the attack, but does make it a bit easier to trace the attacker after the fact; if you're not replacing the attacker's DNS server entry, then all you need is a legitimate-looking server for *.attackersdomain.com. In either case, somebody who can pull off this kind of an attack probably uses a compromised machine to run the DNS server on anyway.) I'm not saying that there can't be problems with that model, but compromised DNS servers (and poisoned DNS caches) are among the major threat models it was designed to deal with. If nothing else, the existence of caching DNS servers, which are not authoritative for the information they hand out, makes a transmission-based solution pretty useless. DNSSEC seems to do a pretty thorough job of making sure that if you look up the correct domain name, you'll get the correct answer, in spite of attackers trying to prevent it. But this attack tricks you into looking up the wrong domain name, and DNSSEC makes sure that you get the correct answer for the wrong name, which isn't the result you want. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Attacking networks using DHCP, DNS - probably kills DNSSEC
Bill Stewart [EMAIL PROTECTED] writes: At 11:15 PM 06/28/2003 -0400, Steven M. Bellovin wrote: In message [EMAIL PROTECTED], Bill Stewart writes: This looks like it has the ability to work around DNSSEC. Somebody trying to verify that they'd correctly reached yahoo.com would instead verify that they'd correctly reached yahoo.com.attackersdomain.com, which can provide all the signatures it needs to make this convincing. So if you're depending on DNSSEC to secure your IPSEC connection, do make sure your DNS server doesn't have a suffix of echelon.nsa.gov... No, that's just not true of DNSsec. DNSsec doesn't depend on the integrity of the connection to your DNS server; rather, the RRsets are digitally signed. In other words, it works a lot like certificates, with a trust chain going back to a magic root key. I thought about that, and I think this is an exception, because this attack tricks your machine into using the trust chain yahoo.com.attackersdomain.com., which it controls, instead of the trust chain yahoo.com., which DNSSEC protects adequately. So you're getting a trustable answer to the wrong query. No, I believe only one of the following situations can occur: * Your laptop see and uses the name yahoo.com, and the DNS server translate them into yahoo.com.attackersdomain.com. If your laptop knows the DNSSEC root key, the attacker cannot spoof yahoo.com since it doesn't know the yahoo.com key. This attack is essentially a man-in-the-middle attack between you and your recursive DNS server. * Your laptop see and uses the name yahoo.com.attackersdomain.com. You may be able to verify this using your DNSSEC root key, if the attackersdomain.com people have set up DNSSEC for their spoofed entries, but unless you are using bad software or judgment, you will not confuse this for the real yahoo.com. Of course, everything fails if you ALSO get your DNSSEC root key from the DHCP server, but in this case you shouldn't expect to be secure. I wouldn't be surprised if some people suggest pushing the DNSSEC root key via DHCP though, because alas, getting the right key into the laptop in the first place is a difficult problem. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Attacking networks using DHCP, DNS - probably kills DNSSEC
Somebody did an interesting attack on a cable network's customers. They cracked the cable company's DHCP server, got it to provide a Connection-specific DNS suffic pointing to a machine they owned, and also told it to use their DNS server. This meant that when your machine wanted to look up yahoo.com, it would look up yahoo.com.attackersdomain.com instead. This looks like it has the ability to work around DNSSEC. Somebody trying to verify that they'd correctly reached yahoo.com would instead verify that they'd correctly reached yahoo.com.attackersdomain.com, which can provide all the signatures it needs to make this convincing. So if you're depending on DNSSEC to secure your IPSEC connection, do make sure your DNS server doesn't have a suffix of echelon.nsa.gov... -- RISKS-LIST: Risks-Forum Digest Saturday 17 June 2003 Volume 22 : Issue 78 http://catless.ncl.ac.uk/Risks/22.78.html -- Date: Fri, 20 Jun 2003 15:33:15 -0400 From: Tom Van Vleck [EMAIL PROTECTED] Subject: ISP's DHCP servers infiltrated http://ask.slashdot.org/article.pl?sid=03/06/19/2325235mode=threadtid=126tid=172tid=95 ... It turns out, Charter Communications' DHCP servers were infiltrated and were providing p5115.tdko.com as the 'Connection-specific DNS suffix', causing all non-hardened Windows (whatever that means in a Windows context) machines to get lookups from a hijacked subdomain DNS server which simply responded to every query with a set of 3 addresses (66.220.17.45, 66.220.17.46, 66.220.17.47). On these IPs were some phantom services. There were proxying Web servers (presumably collecting cookies and username/password combos), as well as an ssh server where the perpetrators were most likely hoping people would simply say 'yes' to the key differences and enter in their username/password... Hmm, my cable ISP was down this morning. Maybe coincidence. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Attacking networks using DHCP, DNS - probably kills DNSSEC
On Sat, Jun 28, 2003 at 01:06:03PM -0700, Bill Stewart wrote: Somebody did an interesting attack on a cable network's customers. They cracked the cable company's DHCP server, got it to provide a Connection-specific DNS suffic pointing to a machine they owned, and also told it to use their DNS server. This meant that when your machine wanted to look up yahoo.com, it would look up yahoo.com.attackersdomain.com instead. This problem is old and well-understood. It is why there is work in the IETF to combine the acquisition of a DHCP lease with the acquisition of an initial IPsec SA to integrity-protect that lease. It's not easy for me to see why anyone would expect anything *but* that MITM attacks against client systems that are entirely configured by DHCP would be practical. If the DHCP client and server share no cryptographic guarantee of trust... ..oh, I'm sorry, I forgot that the anacephalic have fallen for you can magic up trust out of nowhere about ten times in succession in my immediately previous area of work, 802.11. :-) Where I used to work, at ReefEdge, we disposed of the 802.11 security garbage and used a TLS-based solution that was not entirely unlike PIC, dispensing temporary credentials for use with IKE to users based on their legacy authentication. As the designer and maintainer of this system, I became *very* cognizant of DHCP-based and DNS-based attacks, and very skeptical of the sort of proposal someone brought be every few days suggesting that some later establishment of a trust relationship could overcome a successful MITM attack on one of the early stages of the client's boot up and get SA negotiation. (of course, I also became very skeptical of many other folks' use legacy credentials to bootstrap IKE techniques; there are implementations out there in widespread use which default to only authentication methods that are trivially MITMed, and at least one I can think of that _can not be configured_ to do standard IKE in a secure way. Ouch! But the simultaneous IKE and DHCP proposal I read a few years ago at the London IETF seemed pretty sound.) Thor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
