This group should mostly be dealing with how web applications enable networking security issues that are otherwise not there. Everything is being tunneled over port 80 now so what does that enable and how do we fix it?

I have a theory about a possible method of DNS spoofing from a network when using a PIX firewall (up to and including version 7.x of the PIX OS)

I plan to test it over this coming weekend but thought I would mention it here to see if anyone has anything to say about it.

By default a PIX will allow the first DNS response back into a network providing that the stateful element meets what it has in its state-table (Source IP, Port, Destination IP etc) As DNS obviously works over UDP the PIX is limited to what is can use from a stateful inspection of the frame.(I.e no TCP sequence numbers etc)

However, if a link was followed from a web site under a would be attackers control, then the resulting DNS lookup that the client will make could be pre-empted - if the link was to an obscure web site then chances are it would not be cached locally and a valid DNS lookup would emminate from the client, ergo the PIX would be willing to allow a single DNS response back in to the network providing some criteria was met.

If we could send a DNS response back to the client before the legitimate one arrived then the PIX would allow the spoofed response back in and would drop the 'real' one. The problem with this would be anticipating the source port of the host, as obviously the DNS response would have to have this as the destination port. (I have a few theories on ways to circumvent this or at least fool a PIX into allowing the packet in and as a last resort to force the PIX to allow the packet through).

In addition to this we would need to know the clients DNS server that is in use, so the DNS response frame can appear to come from the correct IP address (Spoofing the IP address does not pose a problem as we do not need a reply).

I have two vague ideas in mind with what could work for this - either via maybe javascript to determine from the client IP settings what the DNS servers are set to to obtain the correct IP. (would only work if they were set to an external IP of maybe an ISP's DNS server), if they are we can generate a packet the is guaranteed to traverse a PIX providing that it gets there before the real DNS response. The second way would be to use a web based DNS service over port 80 which would in turn update the clients DNS - however the real DNS response would still arrive on UDP:53 and make its way to the client.

There are a lot of pro's and con's to this and it is still mostly in my head and needs testing. Please comment/flame/take the piss out of, as you see fit.

I know there is a strict criteria that would need to be met, and albeit this is an unlikely set of circumstance to come across but I _think_ it could be the building blocks for a valid vector of attack due to the well known and mostly ignored method the PIX uses to handle DNS.

(There is no reason for this to be limited to a PIX, however this is the only firewall I have a very in-depth knowledge of. Home router/firewall type devices may also be considered)

I am very sure that I can't be the first person to have brought this topic up, however I have searched and have not really found any material on this subject that specifically targets a PIX or at least they process a stateful firewall goes through when processing DNS replies. Apologies if anyone does find a link to something useful :-)

If anyone's interested; I managed to test it and it 'mostly' worked - I could anticipate the DNS request emanating from the source IP and a short script was able to send the DNS reply back to the host before the legitimate one arrived (it arrived a considerable amount of time before the legitimate one as it gets a pretty good head start... but I had to cheat to get it through the PIX).

As mentioned I did have to cheat a little as my theory to circumvent the source port 'limitation' on the PIX's statetable worked but took too long - in which time the real DNS frame arrived and was allowed in thereby ensuring my spoofed one was not.

I have a few other theories to test for this.

Method:
To aim-off for any possible DNS-Pinning I chose an obscure site (http://www.gardensheds.com) but sent an IP address for another web site under my control in the spoofed DNS packet.

The remote user sure enough followed a link to gardensheds.com but came to the web site of the IP address I supplied, (DNS-Pinning is actually used to my advantage here as I don't have to worry about DNS timing-out or the real response ever arriving).

Obviously if the link said hotmail.com and my site was a replica then the ramifications would be more serious....and if the host was on a cooperate network with it's own internal DNS servers, then these would cache the "IP address = Hotmail.com" and supply this IP to subsequent DNS lookup's for all internal clients that use this DNS server (for a limited time)........allowing the pre-empting on one single DNS lookup due to a user following a hyperlink to poison multiple hosts behind a firewall.

I need to tidy up the script that creates the DNS packet and test the source port issue out.