When probing a client's Internet-facing network I saw some strange replies to DNS queries. Their setup was pretty simple, a classic three-legged firewall with som public services on the DMZ. I managed to find the RFC 1918 addresses used on the DMZ segment through a misconfigured IIS and shot off a PTR query to their public DNS server:
$ dig -x 10.10.10.10 @212.212.212.21 ; <<>> DiG 9.3.4 <<>> -x 10.10.10.10 @212.212.212.21 ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 2283 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;21.212.212.212.in-addr.arpa. IN PTR ;; Query time: 6 msec ;; SERVER: 212.212.212.21#53(212.212.212.21) ;; WHEN: Wed Nov 4 15:55:06 2009 ;; MSG SIZE rcvd: 45 $
Wait a minute, what's that in the "query section" of the dig output? Let's try that again using a different IP address:
$ dig -x 10.10.10.1 @212.212.212.21 ; <<>> DiG 9.3.4 <<>> -x 10.10.10.1 @212.212.212.21 ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 7347 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;1.10.10.10.in-addr.arpa. IN PTR ;; Query time: 15 msec ;; SERVER: 212.212.212.21#53(212.212.212.21) ;; WHEN: Wed Nov 4 15:59:56 2009 ;; MSG SIZE rcvd: 41 $
That's more what I expected to see, the query I sent repeated back in the reply. So what happened to the earlier DNS query? Time to bust out some ad-hoc shellscripting:
$ for i in `seq 255` ; do dig in ptr ${i}.10.10.10.in-addr.arpa. @212.212.212.21 | grep PTR; done
;1.10.10.10.in-addr.arpa. IN PTR
;2.10.10.10.in-addr.arpa. IN PTR
;3.10.10.10.in-addr.arpa. IN PTR
;4.10.10.10.in-addr.arpa. IN PTR
;5.10.10.10.in-addr.arpa. IN PTR
;6.10.10.10.in-addr.arpa. IN PTR
;7.10.10.10.in-addr.arpa. IN PTR
;8.10.10.10.in-addr.arpa. IN PTR
;9.10.10.10.in-addr.arpa. IN PTR
;21.212.212.212.in-addr.arpa. IN PTR
;11.10.10.10.in-addr.arpa. IN PTR
;12.10.10.10.in-addr.arpa. IN PTR
;56.171.171.82.in-addr.arpa. IN PTR
;14.10.10.10.in-addr.arpa. IN PTR
;15.10.10.10.in-addr.arpa. IN PTR
;35.212.212.212.in-addr.arpa. IN PTR
;17.10.10.10.in-addr.arpa. IN PTR
...
But why do we see these strange replies? It's almost as if someone were rewriting DNS replies for certain addresses. Turns out, that's exactly what's happening. The Cisco PIX/ASA static NAT rules have an optional keyword 'dns' that, when appended to the rule rewrites DNS packets according to the address translation scheme. There isn't too much documentation available (from a cursory google search) about this feature and so people might be using it even when not strictly necessary. The primary motivation for using it seems to be when you want internal users to access the public servers on the DMZ-segment using the RFC 1918 addresses of the DMZ segment and not the actuall publicly routable addresses. Check out this Cisco article explaining when to use DNS rewriting.
In my humble opinion this is probably just a bug in the PIX/ASA DNS rewriting module, it's being a bit too frivolous and rewriting something it really shouldn't touch. I could be wrong, of course, there might be some weird use case where you would want to change even the query portion of DNS reply packets... Comments?
So, what did we learn today? Well, I learned that both this client's public IP address ranges were being mapped to services on the DMZ of a Cisco PIX firewall and I could enumerate all the static NAT rules of that firewall == all publicly available servers.
More general lessons:
- Defenders; know what features you are configuring/enabling when writing rulesets, don't just fiddle with it until "it works". Adding a feature that you don't need can get you in trouble sometimes!
- Attackers; pay close attention to the reply packets when scanning DNS servers, they SHOULD contain a copy of your query. If they don't you might have something interesting there!
/olle
All client IP-addresses have been doctored, obviously...