Handler on Duty: Jesse La Grew
Threat Level: green
March 2005 DNS Poisoning Summary
compiled by Kyle Haugsness
########################################################################
##
## DNS CACHE POISONING DETAILED ANALYSIS REPORT Version 2
##
## (by Kyle Haugsness and the ISC Incident Handlers)
##
########################################################################
########################################################################
## Summary
########################################################################
Around 22:30 GMT on March 3, 2005 the SANS Internet Storm Center began
receiving reports from multiple sites about DNS cache poisoning attacks
that were redirecting users to websites hosting malware. As the
"Handler on Duty" for March 4, I began investigating the incident over
the course of the following hours and days. This report is intended to
provide useful details about this incident to the community.
The initial reports showed solid evidence of DNS cache poisoning, but
there also seemed to be a spyware/adware/malware component at work.
After complete analysis, the attack involved several different
technologies: dynamic DNS, DNS cache poisoning, a bug in Symantec
firewall/gateway products, default settings on Windows NT4/2000,
spwyare/adware, and a compromise of at least 5 UNIX webservers. We
received information the attack may have started as early as Feb. 22,
2005 but probably only affected a small number of people.
On March 24, we received reports of a different DNS cache poisoning
attack. This attack did not appear to affect as many people. This will
be referred to as the "second attack" in the remainder of this report.
After monitoring the situation for several weeks now, it has become
apparent that the attacker(s) are changing their methods and toolset to
point at different compromised servers in an effort to keep the attacks
alive. This attack morphed into a similar attack with different IP
addresses that users were re-directed toward. This will be referred to
as the third attack and is still ongoing as of April 1, 2005.
Before proceeding, a note of thanks is in order for all the people that
have submitted reports to us, helped us investigate further, and
provided us logs or data. The Internet Storm Center is a volunteer
effort and the better information that we receive from the community,
the better analysis we can perform and contribute back to the community.
Contents:
1. How can others help?
2. How do I recover from a DNS cache poisoning attack?
3. What software is vulnerable?
4. I am a dial-up/DSL/cable modem user -- am I vulnerable?
5. Where can I test my site to see if I am vulnerable?
6. What exactly is DNS cache poisoning?
7. What was the motivation for this type of attack?
8. Weren't DNS cache poisoning attacks squashed around 8 years ago?
9. What was the trigger for the attack?
10. How exactly did this DNS cache poisoning attack work?
11. What domain names were being hijacked?
12. What were the victim sites?
13. What malware was placed on my machine if I visited the evil servers?
14. Got packets?
15. Got snort?
########################################################################
## How can others help?
########################################################################
We are still seeking assistance from the community. You can help out by
providing the following data:
1. We still would like reports of active cache poisoning. When
reporting, please include the DNS server software in use and whether
you have forwarders in place. A good description would be "Windows
2000 server (with registry key to secure cache against polution)
forwarding to a BIND 8.4.6 server in a DMZ that is not forwarding to
any other upstream server". Try to include packet captures of all
UDP port 53 traffic after you have been poisoned. Also, try to send
us a copy of your current DNS cache (see next two paragraphs).
There doesn't seem to be a method to export the running DNS cache on
any of the Windows platforms. The only possibile option would be to
put the DNS server in debug mode and then dig through the log files,
which is not really a viable option. Some people have sent us
screenshots of the DNS Manager/Console, which is probably the best
option (unless somebody sends us a better method).
On BIND you can export the current DNS cache that by running the
"ndc" command (for BIND 8) or "rndc" (for BIND 9) on the server
itself as root and then executing "dumpdb". This command will save
the current memory cache to the directory specified in your
named.conf file under the "directory" option; it is typically
"/var/cache/bind".
2. Run the snort signatures at the end of this document and send us
some of the alerts with the full packet trace.
3. If your sniffer is big enough, you can start logging all UDP port 53
traffic into/out of your site. Later, as we identify more malicious
DNS servers, we may be asking for all DNS traffic to/from a specific
IP address. So it would be helpful to have historical data to
determine when a specific attack started and what poisoning method
they used. If you do set this up, remember to rotate your captures
so they don't consume all the disk space on your sniffer box.
########################################################################
## How do I recover from a DNS cache poisoning attack?
########################################################################
1. You need to be absolutely positive that you have not been infected
with spyware. Many spyware/adware programs today will modify the
DNS settings or local hosts file on Windows machines. So you should
first run your favorite spyware/adware detection tool.
2. Try to find out the IP address(es) of the malicious DNS server(s)
and check our website to determine if this IP address has been
reported. If the IP has not been reported, drop us a quick note at
the following URL: http://isc.sans.org/contact.php
3. You may want to block the IP address(es) of the malicious DNS
server(s) at your border routers/firewalls so that your so that your
cache does not become poisoned again.
4. Cleaning up from a site-wide DNS cache poisoning may require
flushing the cache on all of your DNS servers in your organization
probably starting with the most externally facing DNS boxes first.
5. On Windows DNS servers, you can stop/start the DNS service to clear
the cache. You can also use the dnscmd.exe command from the
Resource Kit:
dnscmd.exe /ClearCache
6. On Windows 2000, XP, and 2003 clients, you can flush the client
cache by running "ipconfig /flushdns". (Please note that this will
do nothing to clean-up a poisoned DNS caching server upstream.)
7. On BIND 9, you can clear the cache by running "rndc" command and
executing the "flush" command. On BIND 8 or below, it appears that
you have to restart the server.
########################################################################
## What software is vulnerable?
########################################################################
We have confirmation that the following software products are
vulnerable:
1. Windows NT4 and 2000 DNS servers.
The default configuration of the DNS server on Windows NT 4 and 2000
IS INSECURE against DNS cache poisoning attacks. By default, the
DNS server does NOT protect you against DNS cache poisoning. If you
run a resolving nameserver on Windows NT 4 or Windows 2000 (2003 is
configured securely by default), you are HIGHLY ADVISED to follow
the instructions here to protect yourself from these attacks:
http://support.microsoft.com/default.aspx?scid=kb;en-us;241352
2. Symantec gateway products.
There was a confirmed bug that allowed DNS cache poisoning in
various Symantec products. A patch was released on March 15, 2005
for the following products:
Symantec Gateway Security 5400 Series, v2.x
Symantec Gateway Security 5300 Series, v1.0
Symantec Enterprise Firewall, v7.0.x (Windows and Solaris)
Symantec Enterprise Firewall v8.0 (Windows and Solaris)
Symantec VelociRaptor, Model 1100/1200/1300 v1.5
The vulnerability information can be found at the following two
URLs:
http://securityresponse.symantec.com/avcenter/security/
Content/2005.03.15.html
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0817
This bug was in addition to a previous bug on the same product set that
was fixed on June 21, 2004:
http://securityresponse.symantec.com/avcenter/security/
Content/2004.06.21.html
We have received reports that Windows 2003 and NT4/2000 (with the proper
registry key settings) are still vulnerable. We are currently working
with Microsoft to determine whether there is a bug or architectural
problem in their DNS software.
Possible theory #1: Windows DNS servers that forward to BIND nameservers
do not ignore the additional authority records in the DNS replies. In
this scenario, we think that the "secure cache against poisoning"
registry keys are just being ignored.
Possible theory #2: The malicious DNS server is currently responding
with .COM entries that have a TTL of 99,999 seconds which is 1 day, 3
hours, 46 minutes, 39 seconds. Perhaps there is a bug where the DNS
server looks at the TTL value it received and realizes that it is
greater than the TTL value for .COM in its cache, so it overrides the
value in cache with the new value?
Additionally, we have received reliable reports from sites that were
poisoned by this attack altough they were running BIND entirely. By
default, the various UNIX-based DNS servers are not vulnerable to this
attack. However, it may be possible to make them insecure through poor
configuration choices. If you have any doubt, test it yourself
following the instructions below.
########################################################################
## I am a dial-up/DSL/cable modem user -- am I vulnerable?
########################################################################
Most likely, no. The major ISPs typically run UNIX-based DNS resolvers
which are not currently vulnerable. However, there are some ISPs
running Windows NT4 or 2000 resolvers and may not have secured their DNS
resolvers. You can test it yourself in the next section.
########################################################################
## Where can I test my site to see if I am vulnerable?
########################################################################
In order to build a "test myself" site, we developed a tool that can
attempt to poison the .COM cache (or any other domain). Unfortunately,
there is no subtle way to deploy this in a testing mode. The danger is
that an end-user at a company or ISP runs the test and if the test is
successful, the cache poisoning will affect all users at that
organization or ISP. We will try to get this worked out and develop a
test methodology that is less intrusive.
And don't ask us for the proof-of-concept tool. We are not distributing
it to anyone at this time.
########################################################################
## What exactly is DNS cache poisoning?
########################################################################
Basically, it is method for an attacker to change the IP address that a
hostname resolves to. For instance the hostname www.cisco.com points to
the IP address 198.133.219.25. A DNS cache poisoning attack allows an
attacker to change the IP address for a host/domain and point it to a
different IP address.
If the above paragraph didn't make any sense, then take a step back and
understand that DNS (Domain Name System) is the method by which you can
resolve a human name like www.google.com into an IP address. An IP
address is a computer's unique location on the Internet. For a very
good explanation of how the global DNS system works, refer to this
article:
http://computer.howstuffworks.com/dns.htm/printable
Second, you must understand that most end-users on the Internet use a
DNS server that is close to them (at their ISP or within their
organization's firewalls) to lookup names for them. For performance
reasons, these DNS servers cache the returned data so that it takes less
time to respond to the next client. If there is a vulnerability or
misconfiguration in the software on these DNS servers, then the cache
poisoning attack is possible. When a victim DNS cache is poisoned, the
attacker will be affecting ALL future lookups of any domain name he
chooses for ALL users of that DNS server. Large ISPs may have thousands
of users referencing a single DNS resolver. So an attack against a
resolver could affect thousands of users, without those users having
done anything wrong.
Here is how the attack works. First, there needs to be a trigger that
forces the victim site's DNS server to query the evil DNS server. There
are several ways to accomplish this. A couple of easy methods are
e-mail to a non-existant user (which will generate an NDR to the source
domain), spam e-mail with an external image, banner ads served from
another site, or perhaps triggering it from a bot network or installed
base of spyware.
Once the trigger executes, the victim's site DNS server queries the evil
DNS server. The attacker includes extra information in the DNS reply
packet. In both attacks, the reply packets contained root entries for
the entire .COM domain. If your DNS server is not configured properly,
then it will accept the new entries for .COM and delete the proper
entries for the Verisign servers (who runs the .COM domain). Once this
has occurred, any future queries that your DNS server makes for .COM
addresses will go to the malicious DNS server. The server can give you
any address it wants. In this attack, any hostname that you request is
returned with a couple of IP addresses that are running a webserver and
attempting to exploit client-side bugs in Internet Explorer to install
spyware.
It is important to note that this attack could be used to hijack other
domain roots besides .COM, like .NET, .ORG, or the country TLDs like .CA
or .DE. The attacker could hijack all of them. A smart attacker would
potentially just hijack specific hostnames and then return the correct
information for all other queries. This type of attack would not be as
noticeable and could potentially be very dangerous.
########################################################################
## What was the motivation for this type of attack?
########################################################################
The motivation for these attacks is very simple: money. The end goal of
the first attack was to install spyware/adware on as many Windows
machines as possible. A good spyware/adware program can generate
significant revenue for the attacker.
There is an excellent write-up by the folks at LURHQ that describes the
pay-per-click (PPC) advertising scheme that is likely behind the
first/third attacks: http://www.lurhq.com/ppc-hijack.html.
The second attack seems to have been launched by a known spammer. But
this is quite a complicated attack for a spammer, so my current theory
is that the attacker(s) are contracting their services for hire.
The motivation for our detailed analyis was because of the DNS cache
poisoning attack, which has the potential for affecting millions of
Internet users and enabling some very dangerous attacks. After
receiving a couple of reliable reports, it became clear to us that we
needed to get to the very bottom of this attack.
########################################################################
## Weren't DNS cache poisoning attacks squashed around 8 years ago?
########################################################################
Taking a trip down memory lane... Cache poisoning has been around for a
very long time. There have been unfortunate bugs in BIND and there have
been design flaws. The DJB fans will note that djbdns has been secure
against cache poisoning for a long time, too.
Basically, the UNIX-based stuff has been secure against cache poisoning
for quite some time, but there may always be a bug or design flaw that
is discovered. We are not quite sure why Microsoft left a default
configuration to be unsecure in NT4 and 2000. (Exercise to reader:
insert Microsoft security comment/opinion/joke here, but keep it to
yourself).
########################################################################
## What was the trigger for the attack?
########################################################################
We haven't been able to isolate the exact trigger for either attack.
There are several methods to trigger a DNS lookup to a malicious DNS
server. There are so many methods to do so, that it doesn't really
matter. It can be accomplished easily, so instead of focusing on the
trigger, security/system administrators should focus on securing their
DNS software.
########################################################################
## How exactly did this DNS cache poisoning attack work?
########################################################################
During the first attack (around Feb 22 to Mar 12, 2005), victims were
being re-directed to one of 3 servers: 217.160.169.87, 207.44.240.79,
216.127.88.131. The domain names for these servers were: www.7sir7.com,
123xxl.com, and abx4.com. These domain names were purchased just prior
to the attack being launched. All of the IP addresses above were UNIX
machines at colocation/web-hosting companies that were compromised.
Most people observed the re-direction because their web-surfing was
obviously affected. But we also received reports of e-mails getting
bounced and subsequent investigation of log files from those machines
indicated that FTP logins, IMAP/POP logins, and SSH traffic was being
re-directed also. The attacker had uploaded to the compromised UNIX
machines two client-side exploits for Internet Explorer. So when users
were re-directed to those servers, the exploit would be launched and if
successful, the victim would be infected with a spyware program.
During the second attack (March 25), there were two malicious DNS
servers that were re-directing people. The malicious DNS servers were
222.47.183.18 and 222.47.122.203. These DNS servers were re-directing
people to themselves, where a website selling popular prescription
medication was found. These webservers did not host any malicious
content. Instead, this was more the work of a spammer. Future
investigation into the IP addresses and domain names registered to those
IP addresses indicate that these servers are probably owned by a spammer
with over 300 domain names registered. It should be noted that the
website advertised indicated "megapowerpills.com", however there is a
real website with that name that is operated on a different IP address.
The third attack is really a continuation of the first attack (March 25
- April 1, 2005), with the same goal of installing a spyware program.
One of the machines from the first attack (216.127.88.131) was never
cleaned-up properly and the attacker came back and changed the poisoning
tool. This time, the DNS server gave out the following IP addresses:
209.123.63.168, 64.21.61.5, 205.162.201.11. All of these servers hosted
the same simple webpage, which redirected people to the following URLs
(which we have neutered):
vparivalka .org /G7 /anticheatsys.php?id=36381
find-it .web-search .la
########################################################################
## What domain names were being hijacked?
########################################################################
We received some logs from two of the machines that were used to launch
the initial attack observed on March 4. Remember, that those machines
were compromised. The log files from those machines indicate the
following statistics over a 3 day period (Mar 2 - 5):
o 1,304 domain names were poisoned/hijacked
o 7,973,953 HTTP get attempts from 966 unique IP addresses.
o 75,529 incoming email messages from 1,863 different mailservers.
o 7,455 failed FTP logins from 635 unique IP addresses (95 unique user
accounts).
o 7,692 attempted IMAP logins (805 unique users, 411 unique IP
addresses).
o 2,027 attempted logins to 82 different webmail (HTTP) servers.
Also during the activity on March 4, 2005, a security administrator who
noticed the attack, exported a copy of his DNS cache, and sent it to us.
For his site, there were 665 hostnames that were poisoned in his DNS
cache. Since the .COM entry was poisoned, any future queries for any
domain name ending in .COM would have re-directed his users to the
hostile servers. I analyzed his cache dump to produce the list of
poisoned domain names below.
The following list shows how far-reaching this attack proved to be. The
list is a small, categorized excerpt of the 665 domain names from his
site (with my short notes) that were being re-directed to hostile web
servers. It is very important to note that e-mail, FTP logins, HTTPS
sessions, and other types of traffic were also being re-directed to the
malicious servers. We do not believe that the attacker was reading
e-mail or collecting passwords, but we have no conclusive proof to
assert either theory.
Please note that the below list is not a list of organizations that had
their DNS cache's poisoned. These organizations were not compromised,
although it is possible that customers of these sites unknowingly gave
out login information or personal information to the malicious servers.
Final disclaimer, this is just a short list of domain names that were
poisoned at a single site. Any domain name could have been poisoned.
Financial Services
------------------
americanexpress.com (credit cards)
citicards.com (credit cards)
billpay.quickbooks.com (financial software/services)
adp.com (data processing)
hrblockemail.com (financial services)
Corporate Presence
------------------
dhl-usa.com (global shipping)
fedex.com (global shipping)
walmart.com (retail)
samsclub.com (retail)
kraftfoods.com (food products)
averydennison.com (paper products, labels)
ppg.com (worlwide commercial products)
nortelnetworks.com (telecommunications)
potterybarn.com (retail)
weightwatchers.com (retail)
dressbarn.com (retail)
moviefone.com (online movie listings/purchase)
nascar.com (car racing)
officemax.com (retail office supplies)
verizonwireless.com (wireless telephone service)
qvc.com (retail)
Media/Entertainment/News
-------------------
cnn.com
nbc.com
abc.com
fox.com
foxnews.com
espn.com
yahoofs.com
starwave.com (part of go.com)
hotjobs.com (job search)
chicagotribune.com
tribune.com
suntimes.com
wgnradio.com
businessweek.com
wired.com
randomhouse.com
imdb.com (online music database)
napster.com (online music)
musicmatch.com (online music)
allofmp3.com (online music)
audible.com (online music)
modblog.com (mobile blogging site)
entertainment.com
courttv.com
Hardware/Software
-----------------
trendmicro.com (anti-virus)
redhat.com (linux vendor)
msoffice.com
microsoftoffice.com
officeupdate.com
giantcompany.com (microsoft's new anti-spyware)
autodesk.com (AutoCAD)
realone.com
realplayer.com
emc.com (enterprise storage)
creative.com (consumer electronics)
lavasoftusa.com (personal firewalls)
tomshardware.com (pc hardware)
ISP/Hosting/Search
------------------
msn.com
compuserve.com
realpages.com
geocities.com
hotbot.com
switchboard.com
cleanmail.com
webex.com
catalog.com
about.com
Health Industry
---------------
webmd.com (online medical advice)
lilly.com (pharmaceuticals)
questdiagnostics.com (medical testing)
Travel
------
orbitz.com
sabre.com
tickets.com
########################################################################
## What were the victim sites?
########################################################################
Unless we receive very explicit approval to publish a victim's name, we
do not publish their name. Instead, we offer some very generic
information. Based on the number of e-mails that we received and by
looking at the log files from the compromised servers, I would
conservatively estimate that 500-1000 medium-to-large size organizations
were affected by these attacks.
There were about 10 organizations that contacted us that have over 1,000
employees. These organizations are from different sectors of the
economy (banking, manufacturing, insurance, telecommunications).
Interestingly, most of the victims appear to be in North or South
America.
########################################################################
## What malware was placed on my machine if I visited the evil servers?
########################################################################
The webservers in the first/third attack tried to drop a spyware program
onto the victim's computer using a Microsoft Internet Explorer
vulnerability for ANI cursor handling. The vulnerability was released
on January 11, 2005 and further technical information can be found
here:
http://www.microsoft.com/technet/security/Bulletin/MS05-002.mspx
Proof of concept exploit code was publicly released soon after the
vulnerability was announced. The filenames being used in this attack
were: abx.ani and abx22.ani. Using VirusTotal, these ANI files were
detected as:
Kaspersky: Trojan-Downloader.Win32.Ani.d
McAfee: Exploit-ANIfile
BitDefender: Exploit.Win32.MS05-002.Gen
The ANI exploit attempted to download one of the following two
executable files (same exact file) on the webserver: abx_search.exe or
mhh.exe. These binaries were detected as:
Kaspersky: AdWare.ToolBar.SearchIt.h
Panda: Adware/AbxSearch
If you were infected by this toolbar, you should run your favorite
spyware/adware program to identify and clean it from your computer.
########################################################################
## Got packets?
########################################################################
Here are packet captures from each attack that shows the DNS reply
packets from the malicious DNS servers. The captures are decoded with
tethereal and hex output is at the end of each packet. Notice that the
second packet of each capture includes and additional RR for "com".
This is the trigger for overwriting the normal "com" entries that are
the official 13 root nameservers.
The first packet capture was taken several days after the March 4
attack. It shows that the attacker has modified the address that is
returned for any query. In this capture, I query for www.cisco.com and
the malicious DNS server returns 209.135.140.198 which is definitely not
the right answer (it should be 198.133.219.25).
Frame 1 (2 on wire, 2 captured)
Packet Length: 73 bytes
Capture Length: 73 bytes
Ethernet II
Destination:
Source:
Type: IP (0x0800)
Internet Protocol, Src Addr: 10.11.12.13 (10.11.12.13), Dst Addr:
216.127.88.131 (216.127.88.131)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 59
Identification: 0x0000
Flags: 0x04
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (0x11)
Header checksum: 0xf397 (correct)
Source: 10.11.12.13 (10.11.12.13)
Destination: 216.127.88.131 (216.127.88.131)
User Datagram Protocol, Src Port: 34899 (34899), Dst Port: 53 (53)
Source port: 34899 (34899)
Destination port: 53 (53)
Length: 39
Checksum: 0x9801 (correct)
Domain Name System (query)
Transaction ID: 0xd4f5
Flags: 0x0100 (Standard query)
0... .... .... .... = Response: Message is a query
.000 0... .... .... = Opcode: Standard query (0)
.... ..0. .... .... = Truncated: Message is not truncated
.... ...1 .... .... = Recursion desired: Do query recursively
.... .... ...0 .... = Non-authenticated data OK:
Non-authenticated data is unacceptable
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 0
Queries
www.cisco.com: type A, class inet
Name: www.cisco.com
Type: Host address
Class: inet
0x0000 4500 003b 0000 4000 4011 f397 0a0b 0c0d E..;..@.@.......
0x0010 d87f 5883 8853 0035 0027 9801 d4f5 0100 ..X..S.5.'......
0x0020 0001 0000 0000 0000 0377 7777 0563 6973 .........www.cis
0x0030 636f 0363 6f6d 0000 0100 01 co.com.....
Frame 2 (2 on wire, 2 captured)
Frame Number: 2
Packet Length: 119 bytes
Capture Length: 119 bytes
Ethernet II
Destination:
Source:
Type: IP (0x0800)
Internet Protocol, Src Addr: 216.127.88.131 (216.127.88.131), Dst Addr:
10.11.12.13 (10.11.12.13)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 105
Identification: 0x0000
Flags: 0x04
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 51
Protocol: UDP (0x11)
Header checksum: 0x006a (correct)
Source: 216.127.88.131 (216.127.88.131)
Destination: 10.11.12.13 (10.11.12.13)
User Datagram Protocol, Src Port: 53 (53), Dst Port: 34899 (34899)
Source port: 53 (53)
Destination port: 34899 (34899)
Length: 85
Checksum: 0x036c (correct)
Domain Name System (response)
Transaction ID: 0xd4f5
Flags: 0x8580 (Standard query response, No error)
1... .... .... .... = Response: Message is a response
.000 0... .... .... = Opcode: Standard query (0)
.... .1.. .... .... = Authoritative: Server is an authority for
domain
.... ..0. .... .... = Truncated: Message is not truncated
.... ...1 .... .... = Recursion desired: Do query recursively
.... .... 1... .... = Recursion available: Server can do
recursive queries
.... .... ..0. .... = Answer authenticated: Answer/authority
portion was not authenticated by the
server
.... .... .... 0000 = Reply code: No error (0)
Questions: 1
Answer RRs: 1
Authority RRs: 1
Additional RRs: 0
Queries
www.cisco.com: type A, class inet
Name: www.cisco.com
Type: Host address
Class: inet
Answers
www.cisco.com: type A, class inet, addr 209.135.140.198
Name: www.cisco.com
Type: Host address
Class: inet
Time to live: 1 day, 3 hours, 46 minutes, 39 seconds
Data length: 4
Addr: 209.135.140.198
Authoritative nameservers
com: type NS, class inet, ns 3sistersmassage.com
Name: com
Type: Authoritative name server
Class: inet
Time to live: 1 day, 3 hours, 46 minutes, 39 seconds
Data length: 18
Name server: 3sistersmassage.com
0x0000 4500 0069 0000 4000 3311 006a d87f 5883 E..i..@.3..j..X.
0x0010 0a0b 0c0d 0035 8853 0055 036c d4f5 8580 .....5.S.U.l....
0x0020 0001 0001 0001 0000 0377 7777 0563 6973 .........www.cis
0x0030 636f 0363 6f6d 0000 0100 01c0 0c00 0100 co.com..........
0x0040 0100 0186 9f00 04d1 878c c6c0 1600 0200 ................
0x0050 0100 0186 9f00 120f 3373 6973 7465 7273 ........3sisters
0x0060 6d61 7373 6167 65c0 16 massage..
At the time of the packet capture - 3sistersmassge.com resolved to
216.127.88.131 which was the same server I was talking to.
Below is a packet capture from the second attack. This one shows
several hostnames (but the same IP address) being returned as the root
nameserver for .com. For this capture, I'm just showing the response
from a query to lookup an obscure domain name (www.leroysprings.com).
In this case, the malicious DNS server returns 222.47.183.18 as the IP
address and it returns the same IP as the root nameserver for .com.
Frame 1
Packet Length: 260 bytes
Capture Length: 260 bytes
Ethernet II
Destination:
Source:
Type: IP (0x0800)
Internet Protocol, Src Addr: 222.47.183.18 (222.47.183.18), Dst Addr:
10.11.12.13 (10.11.12.13)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 246
Identification: 0x0000
Flags: 0x04
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 50
Protocol: UDP (0x11)
Header checksum: 0x9c9d (correct)
Source: 222.47.183.18 (222.47.183.18)
Destination: 10.11.12.13 (10.11.12.13)
User Datagram Protocol, Src Port: 53 (53), Dst Port: 32792 (32792)
Source port: 53 (53)
Destination port: 32792 (32792)
Length: 226
Checksum: 0xfa49 (correct)
Domain Name System (response)
Transaction ID: 0x5494
Flags: 0x8500 (Standard query response, No error)
1... .... .... .... = Response: Message is a response
.000 0... .... .... = Opcode: Standard query (0)
.... .1.. .... .... = Authoritative: Server is an authority for
domain
.... ..0. .... .... = Truncated: Message is not truncated
.... ...1 .... .... = Recursion desired: Do query recursively
.... .... 0... .... = Recursion available: Server can't do
recursive queries
.... .... ..0. .... = Answer authenticated: Answer/authority
portion was not authenticated by the server
.... .... .... 0000 = Reply code: No error (0)
Questions: 1
Answer RRs: 2
Authority RRs: 4
Additional RRs: 4
Queries
www.leroysprings.com: type A, class inet
Name: www.leroysprings.com
Type: Host address
Class: inet
Answers
www.leroysprings.com: type A, class inet, addr 222.47.183.18
Name: www.leroysprings.com
Type: Host address
Class: inet
Time to live: 1 minute
Data length: 4
Addr: 222.47.183.18
www.leroysprings.com: type A, class inet, addr 222.47.183.18
Name: www.leroysprings.com
Type: Host address
Class: inet
Time to live: 1 minute
Data length: 4
Addr: 222.47.183.18
Authoritative nameservers
com: type NS, class inet, ns ns1.m-dns.us
Name: com
Type: Authoritative name server
Class: inet
Time to live: 1 minute
Data length: 14
Name server: ns1.m-dns.us
com: type NS, class inet, ns ns2.com
Name: com
Type: Authoritative name server
Class: inet
Time to live: 1 minute
Data length: 6
Name server: ns2.com
com: type NS, class inet, ns ns1.bizwebb.us
Name: com
Type: Authoritative name server
Class: inet
Time to live: 1 minute
Data length: 14
Name server: ns1.bizwebb.us
com: type NS, class inet, ns ns2.com
Name: com
Type: Authoritative name server
Class: inet
Time to live: 1 minute
Data length: 2
Name server: ns2.com
Additional records
ns1.m-dns.us: type A, class inet, addr 222.47.183.18
Name: ns1.m-dns.us
Type: Host address
Class: inet
Time to live: 1 minute
Data length: 4
Addr: 222.47.183.18
ns2.com: type A, class inet, addr 222.47.183.18
Name: ns2.com
Type: Host address
0x0000 4500 00f6 0000 4000 3211 9c9d de2f b712 E.....@.2..../..
0x0010 0a0b 0c0d 0035 8018 00e2 fa49 5494 8500 .....5.....IT...
0x0020 0001 0002 0004 0004 0377 7777 0c6c 6572 .........www.ler
0x0030 6f79 7370 7269 6e67 7303 636f 6d00 0001 oysprings.com...
0x0040 0001 c00c 0001 0001 0000 003c 0004 de2f ...........<.../
0x0050 b712 c00c 0001 0001 0000 003c 0004 de2f ...........<.../
0x0060 b712 c01d 0002 0001 0000 003c 000e 036e ...........<...n
0x0070 7331 056d 2d64 6e73 0275 7300 c01d 0002 s1.m-dns.us.....
0x0080 0001 0000 003c 0006 036e 7332 c01d c01d .....<...ns2....
0x0090 0002 0001 0000 003c 000e 036e 7331 0762 .......<...ns1.b
0x00a0 697a 7765 6262 c05c c01d 0002 0001 0000 izwebb.\........
0x00b0 003c 0002 c06c c052 0001 0001 0000 003c .<...l.R.......<
0x00c0 0004 de2f b712 c06c 0001 0001 0000 003c .../...l.......<
0x00d0 0004 de2f b712 c06c 0001 0001 0000 003c .../...l.......<
0x00e0 0004 de2f b712 c07e 0001 0001 0000 003c .../...~.......<
0x00f0 0004 de2f b712 .../..
########################################################################
## Got snort?
########################################################################
The following Snort signature should catch poisoning for the .COM
domain. New signatures will be posted to the ISC site as we test and
refine them. Also check http://bleedingsnort.com/ for the latest
signatures.
alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"com DNS cache poison";
content:!"TLD-SERVERS"; nocase; offset:10; depth:50; content:"|c0|";
content:"|00 02|"; distance:1; within:2;
byte_jump:1,-3,relative,from_beginning; content:"|03|com|00|"; nocase;
within:5; classtype:misc-attack; sid:1600; rev:3;)
