dslpartner
join:2005-02-18
| reply to jamesv
Re: [z70] DoxPara port de-randomization / DNS cache poisoning?
That is the standard way ZyNOS based devices have being doing it as long as I know.
It has a reserved pool of ports that it uses for port translation. I am not sure about the new nat implementation, the one that introduced the "ip nat hash" command instead of the older "ip nat iface" command. But the older one atleast used ports starting from port 10000 and then it just used the next available in the reserved pool.
So I think you have to wait until ZyXEL updates its NAT to randomize the port it uses for PAT source ports.
I have not followed this dns issue, is it public why port randomization works? How does it get past SPI, port restricted cone nat or symmetric port.
Or is it "valid" traffic that is actually poisoning the servers?
--
"Perl is executable line noise, Python is executable pseudo-code." |
|
jamesv
Premium
join:2003-03-08
Austin, TX
| The full report on this particular problem isn't public yet as we're still in the window to get it fixed. But enough credible people believe it's real (ISC, etc) I'm buying it until the full disclosure in a couple of weeks.
In the SPI case getting past it with UDP just means you need to correctly predict the port number a DNS query will come from next and blindly send a packet there. DNS queries have a 16-bit tag so that the query source can reject bogus replies but apparently that's not enough. And since the NAT makes the source port extremely predictable there's a problem...
The traffic is "valid" or it would be easy for the DNS query source to reject bogus replies. The traffic is forged and until DNSSEC is deployed all that can be done is to make this attack much harder by increasing the number of bits of randomness from 16-bits (the DNS packet tag) to, say, 31 bits (16 bits from the tag and 15 from the source port number).
ZyXel probably need not randomize the port: just add a short-circuit to the existing WAN port allocation code that says "if the LAN source port number is not allocated as a WAN source port, allocate it instead of using the clock-hand to find a new WAN port number" (in other words, don't remap port numbers unless there is actually a need to do so).
This approach is also unlikely to introduce new problems since one assumes the source ports numbers used by LAN hosts are reasonable to use on the WAN.
ZyXel needs to roll out firmware updates anyway to fix the internal DNS server since many people use that. Might as well fix port remapping at the same time. |
|
stefaanE
Premium
join:2002-07-10
Luxembourg
 ·Redwood Virtual
| reply to dslpartner
said by dslpartner  :Or is it "valid" traffic that is actually poisoning the servers? You cannot poison a DNS server, you poison a DNS cache.
Unfortunately, the fact that the majority of DNS implementations use a single program to be both the authoritative DNS server for a domain, and the cache for the rest of the Internet, has lead to the use of the word "server" for what is in effect merely a cache.
When a cache tries to resolve an address, it will send a (large) number of UDP datagrams to a cascade of servers, starting with the root servers. The replies are cached based on the TTL (Time To Live) field in the reply, so that the number of queries can be kept to a minimum (resulting in less load on the top-level servers and faster name resolution).
UDP reply packets can be spoofed if you can predict the port number. The combination of a large number of UDP requests from the same host, with a predictable sequence of port numbers makes it (relatively) easy to send back a forged reply. It gets past the router's protection measures because it looks and feels like the genuine article.
All subsequent queries to that cache will then use the forged entry, and all the traffic for the domain in question will surreptitiously redirected to the malicious server.
This means that you're vulnerable if you run your own DNS cache (but unless you're a sizable organisation it's unlikely you'll be a target), or if your ISP's DNS cache has been compromised (in which case you can't do much).
The attack is not simple, and only the big fish are worth the effort. Flooding random IP addresses with DNS replies will get you noticed quickly and is unlikely to poison any cache. The attacker has to be able to monitor the traffic coming from a DNS cache, or going to a particular DNS server, predict the port, and get the malicious reply off to the requesting cache before the authentic reply.
I'm not a hat (black or white), but I don't see how this could be done from your average ADSL connection. In the age of switched networks one would need access to a monitor port on the segments on which the targets reside, or on one of the Internet routers to be able to sniff the traffic - not something the typical spammer would have.
If it's far easier than I suspect I'd love to be enlightened  .
Take care,
Stefaan
--
"Technically, Windows is an 'operating system,' which means that it supplies your computer with the basic commands that it needs to suddenly, with no warning whatsoever, stop operating." -Dave Barry |
|
jamesv
Premium
join:2003-03-08
Austin, TX
| said by stefaanE :The attacker has to be able to monitor the traffic coming from a DNS cache, This part is easy. Set up a compromised or honeypot web site that people will visit.
Set up monitoring software on the DNS server for that web site (if your merely compromise disney.com and not its DNS server then add a reference on the web page to a site that you do have DNS server access to).
When DNS queries start coming in for the website you've pwned you've got an IP address and port number to start attacking.
The attacker does need to monitor some traffic coming from the cache, but the monitoring need not be done at the source, and it need not be a stream of traffic if the port numbers used by the source are sequential - a single request suffices (of course, more than one enables you to decide if the source DNS cache is cluelessly sequential). |
|
stefaanE
Premium
join:2002-07-10
Luxembourg
·Redwood Virtual
| said by jamesv :said by stefaanE :The attacker has to be able to monitor the traffic coming from a DNS cache, This part is easy. Set up a compromised or honeypot web site that people will visit. This would indeed allow you to determine if a particular cache is vulnerable. I don't see how it would allow you to poison that DNS cache with much more than fake information on a domain that you already control (which arguably isn't much of an exploit ). Or do most DNS caches still accept out-of-bailiwick responses?
Take care,
Stefaan
--
"Technically, Windows is an 'operating system,' which means that it supplies your computer with the basic commands that it needs to suddenly, with no warning whatsoever, stop operating." -Dave Barry |
|
jamesv
Premium
join:2003-03-08
Austin, TX
| said by stefaanE :I don't see how it would allow you to poison that DNS cache with much more than fake information on a domain that you already control (which arguably isn't much of an exploit ). The hacked web page can not only include referenced to monitoreddns.com to detect DNS lookups, but a link to bigbank.com or paypal.com. The idea is that a hit on the DNS server for monitoreddns.com means is about to be a query from the DNS query source for paypal.com, so (I assume) you quickly flood that IP address you know with fake answers at port+1.
Or something like that. I don't see how to make it work in the real world but others apparently do. The success rate is likely low but even 0.01% would be a big number... |
|
