More DNS "fun"...

[Lv4]

A couple of weeks ago I posted about some BIND/DNS based attacks we were seeing here at work. They were the BIND Infoleak buffer overflow and DNS UDP oversized packet attacks. Both of these have no false positives known and are definate attacks, but no one seems to know why we are seeing so many of these attacks. I have chatted with some folks on different mailing lists, and even my IDS provider and no one knows of any 0-days that are floating around involving BIND or DNS in general... so it seems they are an ineffectual attack against our servers but they are still happening a LOT.

Now, this morning something new started popping up. Once again a DNS attack, no false positives known and no reason behind it. The alerts I'm seeing this morning started around 6am PST and are on going... and there are a LOT of them again.

Time
05:43:26 16-Feb-2004
Host
one of my IDS boxes
Alert ID
dns_labels:binary_alert
Source ID
dns_labels:labels_source
Alert Message
attackers IP address... owned by Stanford University -> one of my BIND boxes id 2396 DNS label contains binary data
severity
Attack



OVERVIEW
A DNS label contains binary data.

WHY THIS IS IMPORTANT
A DNS label contains binary data. This can be indicative of an attempted buffer overflow or 
format string attack.

TECHNICAL INFORMATION
According to RFC 1035, encoded DNS labelnames should only contain ASCII characters. Buffer 
overflows and format string attacks often use the labelnames to hold shellcode when 
exploiting a bug in a DNS server. This alert will trigger when a labelname contains non-ASCII 
data, often indicative of an attack.

This individual alert can be disabled by going to Administration, Variables Configuration, and 
setting ALERT_ON_BINARY to 0.

FALSE POSITIVES
None known.

REFERENCES
RFC 1035: Domain Names - Implementation and Specification
http://www.faqs.org/rfcs/rfc1035.html

So, once again I'll put this out here. If anyone has any clue as to why we are seeing so many of these DNS attacks drop me a line. I'm at wits end at trying to figure this out. Our boxes are patched up to date, both OS and application versions. They are fairly hardened too with no unneeded applications installed. I'm getting tired of seeing these attacks on my DNS boxes and they are starting to fill my logs up :-/

[DjM]

attackers IP address... owned by Stanford University

So, are you saying all attacks are coming from Stanford University, or just this one? If it's all, have you thought about contacting the admin at the University?

Cheers:

[Lv4]

Not all of them are coming from Stanford, but a vast majority of them seem to be. I have sent an email (or three) to their contact but so far I have had no response

[JuJuBeans]

How are you DNS?

[Maverick811]

I know that you'd like to figure out what exactly is going on, and to be honest, I don't really have any more ideas for you, but wanted to say this: even though you see these attacks trying to get through, you should rest assured that they are being detected and stopped - at least they aren't successful attacks, right? I know it's a pain to keep seeing those logs filling up with this information, but it could be worse...

It also seems that you are taking all the right steps as far as prevention, just continue to keep up with those patches and such...

Not all of them are coming from Stanford, but a vast majority of them seem to be. I have sent an email (or three) to their contact but so far I have had no response

Perhaps you should contact the ISP for Stanford, maybe you can get a response from them?

[Lv4]

Maverick811 - yah, I just got finished talking with my CIO about this. My suggestion that she has approved is to start blackholing these IP addresses. Most of them are university owned IP addresses and the rest of them seem to resolve to home broadband IPs (sounding more like a zombie set up all the time to me) and don't have any legitimate reason to even attempt to connect to our network. Hell, we just dropped all APNIC owned IP addresses for this same reason, way WAY too many attacks coming from mainland China to our network. I also suggested that we escalate this to the upstream provider if we don't get a response from the admin/tech of the IP addresses in question.

One thing I have noticed on all of the IP addresses that have been "attacking" our DNS boxes has been that they have the 31337 (elite) port open and listening so perhaps this is some BO2k trick or some other 'leet' tool is involved.

[nebulus200]

I looked into this a while ago, there was a worm that came out a month or two ago that caused these corrupted DNS packets to be formed. I will go back and look and try to remember which one it was...

nebulus

Can't remeber if this was it or not:

http://isc.sans.org/diary.html?date=2003-12-16

In controlled infections, the Calypso trojan has been seen to connect to seemingly random IP addresses using a UDP datagram sent to port 53. This activity is believed to be an attempt to connect in a peer-to-peer fashion with other Calypso trojans. The packet itself simply appears to contain a malformed DNS query. When the trojan randomly hits a real DNS server, the server may reply with an error message. When it contacts another infected host, however, an information exchange takes place, including a sharing of IP addresses of other infected hosts. This appears to be a network map synchronization to maintain complete awareness of the network amongst

If this isn't it, it was very much something like this...

[Lv4]

thanks nebulus200, that would be a great boon to me if you could locate that information for me.

[Lv4]

Thanks nebulus200, that could explain the malformed DNS packets I have been getting... but it doesn't explain the infoleak exploit I'm seeing.

Oh and this weekend a new DNS attack was seen hitting two of my DNS servers. It's the DNS_solinger DoS attacks. Once again these are malformed packets, and for BIND 8.2.2 it will cause a 120 second denial of service before DNS resets itself. I'm going to start some recording and check these packets out to see if they match the info you passed me. Thanks once again