Trojans for industrial espionage

A reader (thanks, Tal!) has alerted us to a developing story in Israel. It seems as if a number of renowned companies fell victim to an industrial espionage attack through custom-written trojan horses and viruses. Jerusalem Post has more: http://www.jpost.com/servlet/Satellite?pagename=JPost/JPArticle/ShowFull&cid=1117333096614
ISC reader Axel, doing a great job with using Google on the little solid information that has been made available on the incident so far, strongly suspects that the Trojan in question was what Symantec calls <A HREF="http://securityresponse.symantec.com/avcenter/venc/data/trojan.hotword.html">Trojan.Hotword</A>.

openrbl.org offline?

It seems as if the spam sink openrbl.org has dropped off the net. The various orbl.net DNS servers are apparently up and reachable, but the "A" record for openrbl.org itself is gone.

Analyzing evidence of DNS attacks in PIX firewall logs

With the increase of traffic to DNS (port 53) that
<A HREF="http://www.dshield.org/port_report.php?port=53"> DShield</A> is seeing recently, I wanted to find out what the log of a Cisco PIX firewall protecting a DNS server could tell about incoming attacks. The answer, unfortunately, is: very little. But what little there is, is explained below.



The built-in IDS of a PIX firewall can generate four different DNS related log entries. The four alerts are

%PIX-4-400034 IDS:6050 DNS HINFO Request Attack

This alert will go off if somebody requests a HINFO record from your DNS server. The request will still go through, unless you have configured the PIX to drop (#ip audit attack action drop) the offending packet. HINFO requests are very rare, and serve no real purpose other than to set off all sorts of perimeter IDS.

%PIX-4-400035 IDS:6051 DNS Zone Transfer Attack

This alert will trigger whenever someone tries a DNS zone transfer (aka download of all your DNS information) through the PIX. If you are hosting the primary DNS for a zone, and legitimate secondary DNS servers outside of your network are configured to host a copy of your zones, then this signature will fire every time the secondaries update. Yes, not very useful.

%PIX-4-400036 IDS:6052 DNS Zone Transfer from High Port Attack

This likely means that somebody just tried a "dig -t AXFR @yourdnsserver yourdomain.com" against your DNS server. Usually an indication of reconnaissance.

%PIX-4-400037 IDS:6053 DNS Request for All Records Attack

This log entry is the result of a "dig -t ANY" or "set type=ANY" in nslookup. These requests don't happen "by accident" in the wild, but still happen hundreds of times per day on a busy DNS server. My recommendation is to turn this signature off, or to simply and silently collect these log lines without any alerting configured on them. Below are two samples of how the above alerts look like in a real-world PIX log:

May 26 14:45:11 %PIX-4-400034: IDS:6050 DNS host info request 

from ATTACKER.231 to COMPANY.9 on interface outside

May 26 14:42:01 %PIX-4-400036: IDS:6052 DNS high zone transfer request

from ATTACKER.231 to COMPANY.9 on interface outside

Besides the built-in IDS, DNS packets can also get caught by other sanity checks built into the PIX firewall. Some examples are shown below.

May 26 16:00:42 %PIX-4-410001: Dropped UDP DNS request from

outside:ATTACKER.231/37467 to inside:COMPANY.9/53; packet

length 5200 bytes exceeds configured limit of 512 bytes

The above log entry suggests that somebody just ran afoul of the DNS packet length restrictions. 512 bytes is the default length restriction set by the "fixup protocol dns" command. In PIX versions >6.3.3, this length restriction can be changed through the "maximum-length" parameter. For PIX 7.0, the command has mutated from "fixup" to "inspect", but is otherwise unchanged. Seeing the above message in your logs does NOT necessarily mean that some nefarious bad guy is playing with your server, packet lengths above 512 bytes DO exist, espeically if EDNS (RFC 2671) is being used -- but a DNS request of 5200 bytes is a bit too much for natural occurrence.

May 26 14:02:23 %PIX-4-410001: Dropped UDP DNS reply from 

outside:SOMEDNS.17/53 to inside:COMPANY.240/65233; packet

length 523 bytes exceeds configured limit of 512 bytes

This event can and does happen quite frequently. It means that a DNS request that originated inside your company (eg. on a client, or DNS forwarder) has been replied to with a DNS packet longer than 512 bytes. Especially if the far end (SOMEDNS) is running Windows 2003, chances are that the server will insist on using EDNS, and usually return too long an answer to still squeeze through the PIX. Usually not hostile.

May 26 16:01:33 %PIX-4-410001: Dropped UDP DNS reply from

outside:ATTACKER.231/14431 to inside:COMPANY.9/53; packet

length 560 bytes exceeds configured limit of 512 bytes

Similar to the above, but now our PIX is really confused. Note how the packet went from high port to port 53, and therefore very likely is a DNS request rather than a reply as indicated in the message. This is usually a strong indication that the DNS packet has been tampered with.

%PIX-4-410001:UDP DNS packet dropped due to compression length check

of <n> bytes: actual length:<n1> bytes

This is a PIX log message that I haven't seen in the wild so far. Allegedly, it is being written if a very crafty DNS packet containing a looping pointer is detected by the PIX. If you have sample packets and sample log entries, please submit.
To finish, two samples of the odd ducks among PIX DNS log lines. Note the novel approach Cisco seems to take at math (9 exceeds 63). I haven't gotten to the bottom of this, but as far as I can tell, what they mean is "label length exceeds 63 by 9 characters"

May 26 13:24:33 %PIX-4-410001: Dropped UDP DNS reply from outside:SOMEDNS.17/53

to inside:COMPANY.240/61858; label length 9 bytes exceeds protocol limit of 63 bytes

May 26 16:02:42 %PIX-4-410001:Dropped UDP DNS reply from inside:COMPANY.9/37709

to outside:ATTACKER.231/53; label length 16 bytes exceeds protocol limit of 63 bytes

The first log line above only signifies that an external DNS server has responded to a query originating from your site with a reply containing a host name of which a "label" is longer than 63 characters. A "label" according to the DNS RFC (1035) is any component between dots in a host name. In DNS parlance, isc.sans.org consists of three labels, with length 3-4-3. Getting a response longer than 63 usually happens on "fancy" host names that are especially common when return resolving IP addresses used in IRC networks. Seeing this log entry is quite rare, but not too much cause for concern. Not so for the second sample above. Note how the PIX is dropping a DNS reply sent outbound from our DNS server. The firewall is also sufficently confused to actually cause a swap of the port numbers; packet traces confirm that 53 is inside and 37709 at the attacker's site, as we would expect. So far I've only seen these log entries during a real attack against a DNS server, and they are usually caused by the attacker sending a non-standard packet and the DNS server (rather than swallowing it without reply) sending the packet back flagged as an error. Why the PIX apparently does not catch the inbound attack and only triggers on the outbound reply is still a mystery to me.
One strong caveat: DNS UDP requests can be easily spoofed and can show up in your logs with a different source address than the actual originator. Also, the "ANY" records and "HINFO" requests can be relayed through an arbitrary DNS server that supports query recursion. So, before you take any action against an alleged offender, make sure you got a solid case (packet traces, and a good answer to "Probability that the source address was spoofed
", as you were taught in Mike Poor's class :-)).
If you have other explanations or have seen additional DNS related log entries in your PIX firewall log, please <A HREF="http://isc.sans.org/contact.php"> let me know</A>.
-----------------

Daniel Wesemann

Email: echo "ebojfm/jtdAhnbjm/dpn" | perl -pe 's/(.)/chr(ord($1)-1)/ge'