Cатсн²² (in)sесuяitу / ChrisJohnRiley

Because we're damned if we do, and we're damned if we don't!

Tag Archives: dns

What, more Python ctypes! – DNS TXT records

Yeah I know, this is turning into a Python blog, and not a very good one at that. Still, hang in there, because all these handy little scripts will make sense soon. Yes, there’s method in the madness!

For those who missed the earlier posts, you can view info on IcmpSendEchoInternetConnectedState and WinInet (SSPI).

So we’ve covered some interesting stuff, but one thing was still bugging me… Thanks to a pointer by Didier Stevens (literally, it was a pointer issue), I managed to get a simple DnsQuery script running to gather and display DNS Text records.

Again, the script is a little large to post on the blog in its entirity, but I’ve included the dnsapi.DnsQuery_A function below for those searching for that specific function. There’s a lot more to getting this running than just the below code, but for the full info you can download the example source (dnstxt.py) below.

....
dnsquery = dnsapi.DnsQuery_A(
           dns,
           DNS_TYPE_TEXT,
           Options,
           False,
           precord,
           False,
           )
....

As with the other examples I’ve created a small (and narrowly focused) tool to retrieve DNS Text records and display them on the screen. It’s a simple script, that takes a dns name, and has options to restrict the request to UDP or TCP only if desired. It’s interesting to use UDP only to test of Text records are too large, and need TCP. Feel free to check it out on c22.cc (which is too large for UDP).

Those who’ve done any work with Python will know that there’s a few modules that you can download and install to handle DNS requests of various types. Modules like PyDNS and dnspython are going to give you more flexibility for most things. Unless you really need (or want) to go the ctypes route of course)… yes, I’m a sucker for punishment!

Example use:

The above example runs with the default UDP and TCP requests and merges the responses into a unique list to return to the user. By selecting –udponly you can restrict the request to only UDP traffic (see below)

Specifying –tcponly works the same way, but restricts to TCP only. Specifying both is just stupid ;)

dnstxt :

  • Python sourcecode –> HERE
  • dnstxt.exe –> HERE
Feel free to leave any comments if you have ideas, uses, or generally want to laugh at by bad coding ;)

Links:

  • DnsQuery Reference – MSDN

26C3: cat /proc/sys/net/ipv4/fuckups

“Built around a fictional average company network, we will tell the story of an attack making use of subtle bugs across the layers all of which are as of yet undisclosed. This will include a bug in an Ethernet-driver, which allows an attacker to bypass MAC- and IP-based filters, bugs in TCP-implementations that are assumed to be fixed but aren’t, a web-cache which confuses itself and an instant-messenger, which was fooled by the protocol specification.

All of these bugs share a common property: They are a consequence of insecure coding-practices.”

Alone these bugs don’t achieve much, but when chaining them together and creating a jigsaw puzzle of attacks, it’s possible to construct an effective attack.

Stage 1: Attacking the clients

The client offers a huge variety of attack possibilities. However you need to target the attack to the specific system. What application do you want to exploit, how, what host system, what shellcode to use…. The first phase is information disclosure.

The application of choice for this demo is Pidgin emoticons. Using the MSN-SLP protocol, a client receiving an emoticon is able to request the graphic from the client by specifying the file to download. By replacing the name of the emoticon to fetch with a more interesting file (/etc/passwd springs to mind), an attacker can remotely retrieve the file. Adium suffers from the same issues as Pidgin as the issue replies on the underlying protocol and not the application itself.

This issue is less of an implementation issue, and more of a protocol issue due to the complexity of the protocol (for no reason).

Stage 2: Bypassing the internal packet filter

When trying to attack layer n, it’s always best to look at the lower layers to see if you can control or exploit them. Looking at  the link layer protocol for example, you see the typical MTU value of 1500 Bytes. Now that gigabit ethernet is coming to the enterprise, jumbo frames are supported (alongside the older 1500 MTU values). So what happens if somebody sends 2000 Bytes to a system that only supports 1500 ? Typically a controller will take the data and make it spam more than one receive buffer. However in some instances this might be the case. For example the e1000 Linux driver from earlier this year. It was fixed, but not really fixed !

When sending a frame that would normally be checked (i.e. a firewall) only the first part is checked, the second isn’t. This means that you can bypass the firewall rules, and send packets (and attacks) to systems behind it. 0-day !!!

Stage3: Poisoning the cache

Squid webcache, is also a DNS cache. This means that it’s vulnerable to the typical issues that standard DNS suffers from. Squid implements it’s DNS features independently of other DNS servers. Even though it randomizes the source port, the port is then statically assigned for the lifetime of the cache. Many layers of security are handed off to other systems (i.e. layer II protections).

By using NAT’s build in source-port protections it’s possible to fingerprint the port used by Squid.

When waiting for a DNS response, Squid constantly queries the next received packet. When it’s not expecting a response it caches responses until it makes a request. You can then put responses into the cache before even asking Squid to resolve. The first response wins, and you’ve given answers before the DNS server has even asked the question.

Squid is automatically setup to wait 2 minutes for a response. By performing a DoS on the firewall, you have enough time to poison the cache.

Stage 4:
Denial of Service the Firewall

In 2009, a fix was implemented to the RTL Linux driver to re-enable the previously disabled hardware filtering on the NIC. By scanning possible MTU lengths, you can find the exact value that triggers the NIC to throw an error saying that multiple fragmented packets have been received, both of 8000 Bytes (this isn’t really possible). This will also cause garbage to be sent up the stack, instead of the packet contents. Lucky for us, the attacker can specify this garbage and control where the crash takes place.

More than just a Denial of Service, control over the remote machine.

Conclusion

  • The security of a network component relies on the environment
  • Security issues do not live in isolation – You never know the impact of a vulnerability until you see how it can be put to work

More information can be found on the CCC wiki

DNS Cache Poisoning against djbdns

I’ve been reading up on the newest DNS cache vulnerability. Hot on the heals of the most over-hyped bug of the year (Sorry Dan), comes an attack that actually works against djbdns.

djbA little history. Djbdns (Daniel J. Bernstein’s DNS) was immune to the 2008 Cache Poisoning attacks from Dan Kaminsky as it already implemented the UDP Port randomisation that was marketed as the (temporary) solution to the issue. Although port randomisation doesn’t solve the problem 100%, it makes the attack considerably harder (read longer) to complete. The theory is, that you’ll see an attacker hammering your DNS serer with UDP packets for hours or days before they manage to poison the cache. That is if you’re paying attention to your DNS server. Anyway, a discussion of the 2008 attack vectors isn’t the point here. There are many sources of this already on the interwebs.

The djbdns attack was released on 09.02.2009 by Kevin Day. Full details of the research and examples can be found on his website. The Basics : By using a number of flaws in the dnscache program provided with djbdns, Kevin was able to prove that djbdns is vulnerable to cache poisoning. The attack centers around SOA records and the fact that these are not cached by djbdns. By filling the buffer (defaulted to 200 open requests) with SOA queries, he was able to attempt a collision (matching ID and UDP Port). By having 200 active SOA requests he is in effect increasing the chances of a collision by 20,000%. This reduces the 40 billion packets required for a 50% collision to around 16.8 million packets (not much in computer terms). If the server has been configured to accept more than 200 simultaneous queries, then the attack could be executed even faster.  By constantly rotating the queries (djbdns drops older queries if the buffer is full and a new request comes in) he was able to force djbdns to ignore the official responses from the nameserver, and keep the dns server from accepting a valid response. This attack requires that communication between the attacker and dns cache being poisoned is quicker than the nameserver of the domain being poisoned.

My explanation is a little hard to follow (it’s hard to cram into 10 lines on a blog). So I suggest you hop over to Kevin’s site, read the excellent paper and apply the 3rd party patch to your djbdns server before a Metasploit module appears. Going by previous vulnerabilities, that won’t be long ;)

DJBDNS –> http://cr.yp.to/djbdns.html

There is no bag…. only a cat

Well looks like late last night (at least European time) details about Dan Kaminsky’s recently disclosed DNS attack were made public. So the cat is out of the bag…. if there ever was a bag to begin with.

The confusion seems to be a post on the ADD / XOR / ROL blog. In response the Matasano blog posted more information that seemingly was not meant to be public just yet. All parties seem to be taking it well, which of course makes some conspiracy nuts think that maybe this was the plan all along, or that just maybe some key elements of the attack were left out to move things along a little faster for the slow adopters. Personally I can see the validity of the attack vector and logically I can see no flaw in the thinking. It’s not new, but it is a good way to avoid the restrictions put in place from previous such attacks (i.e. the DNS Transaction ID and the filter to ignore unrequested DNS answers). More information can be seem on the blogs linked above, and on Wesley McGrew’s blog.

Some comments have also been made about the use of OpenDNS as an alternative fix. I’m no expert on this, as I’ve never used the service. However from all accounts it appears that OpenDNS doesn’t return NXDOMAIN answers for non-existant domains. If this is the case I can see problems with users just changing over to avoid the new DNS vulnerability. I can also see some issues with this from a security standpoint. After all there is no race condition if OpenDNS isn’t replying that a domain is invalid. A crafty attacker could use this to force browsers to a malware site for all instances where the user mis-types a domain. This is just speculation, but is however an interesting theory.

Now get patching….

Follow

Get every new post delivered to your Inbox.

Join 123 other followers