jamesv
Premium
join:2003-03-08
Austin, TX
|  [z70] DoxPara port de-randomization / DNS cache poisoning?
I have a z70 running "V3.65(WM.2) | 09/26/2005", rather ancient but workable until now. It appears that the NAT is de-randomizing the port numbers that a named/bind server on a FreeBSD box on the LAN is using, making me vulnerable to DNS cache poisoning via whatever technique underlies the current DNS uproar as described on the doxpara website and elsewhere.
I have two WAN ports. The one shown as 70.1.2.3 below is on a 1-1 NAT (no port renumbering) as has random source port numbers (the method the new version of bind uses to try to defeat the attack).
But the WAN port at 24.1.2.3 below is an SUA NAT and port number remapping is done. It appears the ZyWall 70 is using a clock-hand to allocate remapped port numbers, and is sequentializing the randomness bind uses, undoing to effort to defend against doxpara's DNS cache poisoning technique.
output from the test script on the doxpara page:
Has anyone tested a version of the ZyWall firmware and found that is does *not* de-randomize source port numbers? |
|
dslpartner
join:2005-02-18
| 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
| 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
| 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... |
|
CampMaster
Rather Be Camp'n
Premium
join:2001-05-16
Trabuco Canyon, CA
 ·ViaTalk
 ·DSL EXTREME
| reply to jamesv
I am seeing this with my ZW5 4.04 XD1, very surprised.
Failing Doxpara.com, port are not random at all.
I am running a SBS2003 Server, forwarding port 53 to the server. the SBS2003 is a backup DNS for various internet domains as well as the local domain. I have all the MS patches, and that is working fine. ZyXEL is messing it up.
Any ideas?
~CMT
--
There's no place like 127.0.0.1
|
|
jamesv
Premium
join:2003-03-08
Austin, TX | If you point upstream DNS queries to opendns, or to your ISP if their cache is OK, you're reasonably safe. Just wait until new Firmware comes out. |
|
CampMaster
Rather Be Camp'n
Premium
join:2001-05-16
Trabuco Canyon, CA
·ViaTalk
·DSL EXTREME
| I can do DNS forwarding, but that is only if the local DNS can't complete the lookup. That also will not stop the fact that outside DNS queries to my DNS will still go out almost sequential port, because of the failure of the ZyXEL to randomize the outgoing ports.
The solution is for ZyXEL to randomize outgoing ports. I just don't know if we need to wait for a firmware fix (4.04 XD1 is from 7/15/08) or if there is a CLI command that would resolve this
~CMT
--
There's no place like 127.0.0.1
|
|
CampMaster
Rather Be Camp'n
Premium
join:2001-05-16
Trabuco Canyon, CA
·ViaTalk
·DSL EXTREME
| Called ZyXEL on my ZW5 and they do have a patched firmware, still 4.04 XD1, but a different date.
They emailed it to me and I installed it, I am still trying to test, but having issues with doxpara.com site.
They will be releasing an "official" firmware update "VERY" soon according to support.
Will update on the patched 4.04 XD1 071508 when I have a chance to test.
~CMT
--
There's no place like 127.0.0.1
|
|
dslpartner
join:2005-02-18
| reply to jamesv
»www.unixwiz.net/techtips/iguide-···uln.html
some more info on the dns flaw
--
"Perl is executable line noise, Python is executable pseudo-code." |
|
