DNS cache poisoning again!

Published: 2006-05-02
Last Updated: 2006-05-03 13:34:10 UTC
by donald smith (Version: 1)
0 comment(s)
DNS cache poisoning report.
For background you may wish to review this report  http://isc.sans.org/presentations/dnspoisoning.php
and this issue about BIND 4 or 8 not being suitable as forwarders http://isc.sans.org/diary.php?date=2005-04-28

Next, a request. PLEASE review your dns servers logs and cache for 65.23.154.2 If you find it listed as authoritative for .com please send us an email with a dump of the dns cache. Directions for dumping, cleaning and protecting your cache are available in the write-up above.

Serverhome.com (65.23.154.2) is being reported for Kashpureff-style cache poisoning for the .com TLD.

This report shows there are about 16k domains hosted on this server.
http://www.ipwalk.com/webhost/total_domains/webhost_name/serverhome.com

Be careful if you look up one of those domains there is a good chance you will see extra RR records including ones that claim they are authoritative for .com.

Sample packet showing the cache poisoning in action. Note the extra .com servers.
No.     Time        Source                Destination           Protocol Info
19 12.201047   65.23.154.2           192.168.0.3           DNS      Standard query response A 65.23.154.2
Frame 19 (542 bytes on wire, 542 bytes captured)
Ethernet II, Src: Actionte_58:9d:0a (00:0f:b3:58:9d:0a), Dst: HonHaiPr_1d:cc:b4 (00:14:a4:1d:cc:b4)
Internet Protocol, Src: 65.23.154.2 (65.23.154.2), Dst: 192.168.0.3 (192.168.0.3)
User Datagram Protocol, Src Port: domain (53), Dst Port: 3918 (3918)
Domain Name System (response)
    Transaction ID: 0x0029
    Flags: 0x8580 (Standard query response, No error)
    Questions: 1
    Answer RRs: 1
    Authority RRs: 15
    Additional RRs: 10
    Queries
        www.ibm.com: type A, class IN
    Answers
        www.ibm.com: type A, class IN, addr 65.23.154.2
            Name: www.ibm.com
            Type: A (Host address)
            Class: IN (0x0001)
            Time to live: 1 day
            Data length: 4
            Addr: 65.23.154.2
    Authoritative nameservers
        com: type NS, class IN, ns a.gtld-servers.net
            Name: com
            Type: NS (Authoritative name server)
            Class: IN (0x0001)
            Time to live: 1 day
            Data length: 20
            Name server: a.gtld-servers.net
<SNIP b-m gtld-server list >
com: type NS, class IN, ns ns1.serverhome.com
            Name: com
            Type: NS (Authoritative name server)
            Class: IN (0x0001)
            Time to live: 1 day
            Data length: 17
            Name server: ns1.serverhome.com
        com: type NS, class IN, ns ns2.serverhome.com
            Name: com
            Type: NS (Authoritative name server)
            Class: IN (0x0001)
            Time to live: 1 day
            Data length: 6
            Name server: ns2.serverhome.com
    Additional records
        a.gtld-servers.net: type A, class IN, addr 192.5.6.30
            Name: a.gtld-servers.net
            Type: A (Host address)
            Class: IN (0x0001)
            Time to live: 1 day, 21 hours, 4 minutes, 21 seconds
            Data length: 4
            Addr: 192.5.6.30

        <SNIP b-gtld ? g-gtld>

        h.gtld-servers.net: type A, class IN, addr 192.54.112.30
            Name: h.gtld-servers.net
            Type: A (Host address)
            Class: IN (0x0001)
            Time to live: 1 day, 21 hours, 4 minutes, 21 seconds
            Data length: 4
            Addr: 192.54.112.30

I provided this information to the hosting provider Rackmounted.Com. They stated that
"Returning unexpected answers to queries that will never occur in the wild is not abuse"

So I did a dig for serverhome.com a domain they own.
dig @65.23.154.2 serverhome.com
; <<>> DiG 9.2.1 <<>> @65.23.154.2 serverhome.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8745
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 15,
ADDITIONAL: 2
;; QUESTION SECTION:
;serverhome.com. IN A
;; ANSWER SECTION:
serverhome.com. 86400 IN A 65.23.154.2
;; AUTHORITY SECTION:
com. 86400 IN NS i.gtld-servers.net.
com. 86400 IN NS j.gtld-servers.net.
com. 86400 IN NS k.gtld-servers.net.
com. 86400 IN NS l.gtld-servers.net.
com. 86400 IN NS m.gtld-servers.net.
com. 86400 IN NS ns1.serverhome.com.
com. 86400 IN NS ns2.serverhome.com.
com. 86400 IN NS a.gtld-servers.net.
com. 86400 IN NS b.gtld-servers.net.
com. 86400 IN NS c.gtld-servers.net.
com. 86400 IN NS d.gtld-servers.net.
com. 86400 IN NS e.gtld-servers.net.
com. 86400 IN NS f.gtld-servers.net.
com. 86400 IN NS g.gtld-servers.net.
com. 86400 IN NS h.gtld-servers.net.
;; ADDITIONAL SECTION:
ns1.serverhome.com. 86400 IN A 65.23.154.2
ns2.serverhome.com. 86400 IN A 65.23.154.2


Highlights from the original Email thread reportng a DNS cache poisoning event.

"I have been investigating a DNS problem my company experienced late
last week. Users were reporting that no matter what site they attempted to access they would receive a page indicating that the domain was for sale.

I did some basic troubleshooting and found that all requests that were resolved against our internal DNS server were answered with the same address 65.23.154.2. I began digging in the DNS logs and found that NS record for the "com." zone had been inserted at what seemed to be a higher priority then the common TLD servers in the "com." domain.


After the cache became corrupted it caused our internal name servers to query 65.23.154.2 as a name server for the "com." zone. It would reply with the 65.23.154.2 address to any request that was requested.

I was out of town at the time of the event and without understanding what it was I was
dealing with I blocked access to 65.23.154.2 at our firewall, cleared the cache on all internal DNS servers and cleared the cache on our proxy.

I then contacted the ISP and left word that I thought they may have
a misconfigured host on their network but I did not receive a response.

Today, I was able to find the time to confirm these findings in a VM environment that I placed on our external network. The server is a MS Windows 2003 with SP1 installed and the "secure cache against pollution" check box was enabled.

I contacted MY_ISP yesterday and inquired as to what version of DNS they
were running on our forwarders. They would only admit that they had
version(8.something) and seem quite defensive about the notion that they
had forwarded corrupt cache info that caused my company so much trouble
late last week. It seemed as if they were insistent on saying that
their cache was not corrupted. I tried to explain that I didn't think
that it was only that poisoned authority records had been passed to us
from them as a result of an authoritative response from a malicious
server.

I am going to recommend that my company install its own DNS cache servers in our DMZ running the latest version of BIND and to NOT allow internal DNS servers to conduct recursive lookups."

Additional DNS information.

There are a lot of other systems that are currently setup to do dns cache poisoning.
http://dns.measurement-factory.com/surveys/200603-poison.txt
Cornell did a dns survey their report is available here:
http://www.cs.cornell.edu/People/egs/beehive/dnssurvey.html
ISC.com's DNS survey results
http://www.isc.org/index.pl?/ops/ds/

Keywords:
0 comment(s)

New Version of PHP, Cisco Advisory, BurstNET DoS'd

Published: 2006-05-02
Last Updated: 2006-05-02 21:31:32 UTC
by John Bambenek (Version: 1)
0 comment(s)
PHP has released version 5.1.3 which has several important security fixes that will help prevent much of the abuse that PHP has gotten lately.  I'd encourage those of you using PHP to seriously consider upgrading when you can.

There is a privilege escalation in Cisco Unity Express that allows an authenticated but unprivileged user to reset the password of any expired account.  This could be used to gain a higher level of access or even administrator access.  This doesn't strike me as a very critical issue as you need to have access to the HTTP management interface to execute this attack.  Those environments that practice least privilege (i.e. not giving people access they don't need and removing access when no longer needed) shouldn't be affected by in a big way.

Earlier today, a popular hosting/colocation company was the target of a denial of service attack and was down for a little bit.  They seemed to take care of the problem pretty quickly. 

At a point where it seems overwhelming with all the new attacks, I'm glad that there are other things to worry about than gibbering packet apes kicking over networks with DoS attacks.  At least now the bad guys come with some interesting hacks and there is real stuff on the line (identity theft/fraud, for instance).  In the words of Ed Skoudis, you can think of it as "unlimited job security".

--
John Bambenek, bambenek /at/ gmail /dot/ com

Keywords:
0 comment(s)

What's a super.proxy.scanner and why is it in my logs?

Published: 2006-05-02
Last Updated: 2006-05-02 20:58:42 UTC
by Robert Danford (Version: 2)
0 comment(s)
Disclaimers:
Visit the urls at your own risk.

One of our readers has come across an interesting phenomenon in his proxy logs that we're hoping someone can shed some light on.

Imagine reviewing your webserver or proxy logs and seeing requests for a website completely unrelated to your organization,
but an IP address in your address block appears in the hostname.

(Thanks to Jeremy for the report and the offer to share. I was able to find plenty of examples on the internet without referencing yours specifically)

So here is an example URL that might show up in your logs:

http://check.216.109.136.53.v.80.pw1.super.proxy.scanner.i.thu.cn/Provy_OK.html

running the host command on the above hostname provides:

check.216.109.136.53.v.80.pw1.super.proxy.scanner.i.thu.cn has address 61.135.170.153

Hrm. 216.109.136.53 is a an IP in Hoboken, NJ. Thats about 6800 miles away from the host in China (61.135.170.153).

If you search for the string "super.proxy.scanner" in google you get 3 pages of proxy and web logs showing requests for various URLs that follow the form:

http://check.$ip_address.v.80.(pdx8|PCN22|mt1|pw1).super.proxy.scanner.(i.thu.cn|ii.9966.org)/Provy_OK.html

All of the hostnames resolve to 61.135.170.153.  All of the logs I could find show this activity only in the March-April 2006 timeframe so relatively new.

Visiting one of these hinkey URLs always provides the following (well at least in the few I tried):

"OK0001"

The webserver is running lighttpd/1.4.11 (http://www.lighttpd.net/)

Thats about all I could find. The string "super.proxy.scanner" showed up on a few sites as the top search results so someone or some program is looking for this traffic as well.

So let us know if you have any theories (or maybe you know exactly whats going on here) See Below for new information.  Also if you have any web/proxy log entries (or even better pcaps of all traffic related to one of these IPs) feel free to send them in.  We'll post whatever we find in the diary.

One interesting tidbit, while researching this I fat-fingered a lookup and the DNS server gave me an interesting IP back:

dig any suprt.proxy.scanner.ii.9966.org
;; QUESTION SECTION:
;suprt.proxy.scanner.ii.9966.org. IN    ANY

;; ANSWER SECTION:
suprt.proxy.scanner.ii.9966.org. 300 IN A       61.135.170.153
suprt.proxy.scanner.ii.9966.org. 300 IN NS      ns1.suprt.proxy.scanner.ii.9966.org.
suprt.proxy.scanner.ii.9966.org. 300 IN NS      ns2.suprt.proxy.scanner.ii.9966.org.

;; AUTHORITY SECTION:
suprt.proxy.scanner.ii.9966.org. 300 IN NS      ns2.suprt.proxy.scanner.ii.9966.org.
suprt.proxy.scanner.ii.9966.org. 300 IN NS      ns1.suprt.proxy.scanner.ii.9966.org.

;; ADDITIONAL SECTION:
ns1.suprt.proxy.scanner.ii.9966.org. 300 IN A   61.135.170.159
ns2.suprt.proxy.scanner.ii.9966.org. 300 IN A   61.135.159.152

Here is what I would have gotten without my typo:
dig any super.proxy.scanner.ii.9966.org
;; QUESTION SECTION:
;super.proxy.scanner.ii.9966.org. IN    ANY

;; ANSWER SECTION:
super.proxy.scanner.ii.9966.org. 300 IN A       61.135.170.153

;; AUTHORITY SECTION:
ii.9966.org.            86400   IN      NS      ns2.ii.9966.org.
ii.9966.org.            86400   IN      NS      ns1.ii.9966.org.

Some results from google:
check.216.109.136.53.v.80.pdx8.super.proxy.scanner.i.thu.cn/Provy_OK.html
check.216.109.136.53.v.80.pw1.super.proxy.scanner.i.thu.cn/Provy_OK.html
check.216.109.136.53.v.80.PCN22.super.proxy.scanner.i.thu.cn/Provy_OK.html
check.63.245.201.35.v.80.mt1.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.66.34.248.90.v.80.pcn22.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.147.251.3.78.v.80.PCN22.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.147.251.3.39.v.80.PCN22.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.130.71.96.35.v.80.mt1.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.141.225.152.87.v.80.pdx8.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.207.73.173.23.v.80.pdx8.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.63.245.201.36.v.80.pw1.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.207.73.173.23.v.80.pdx8.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.58.188.232.10.v.80.PCN22.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.63.245.201.35.v.80.PCN22.super.proxy.scanner.i.thu.cn/Provy_OK.html
check.207.210.74.70.v.80.pdx8.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.151.100.18.65.v.80.PCN22.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.212.192.114.3.v.80.mt1.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.128.243.107.6.v.8080.PCN22.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.192.107.81.22.v.80.pw1.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.192.107.81.22.v.80.PCN22.super.proxy.scanner.i.thu.cn/Provy_OK.html
check.130.85.162.106.v.80.pw1.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.130.85.162.106.v.80.pw1.super.proxy.scanner.i.thu.cn/Provy_OK.html
check.167.196.204.113.v.80.pdx8.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.212.192.114.3.v.80.mt1.super.proxy.scanner.ii.9966.org/Provy_OK.html
check.207.210.74.70.v.80.pdx8.super.proxy.scanner.ii.9966.org/Provy_OK.html

Interesting entry from the web log for a webcam:

Camera 1: Security alert:
user from IP address: 61.135.170.159 is trying to read file:
check.70.60.215.15.v.8080.PCN22.super.proxy.scanner.i.thu.cn/Provy_OK.html

Update: 5/2/06:

Thanks to everyone who wrote in with theories and facts.

This activity appears to be related to a scanning tool call "proxy_scanner" which was released in Chinese hacker circles in 2004.
The site was.io8.org was used to distribute this tool and traffic related to that site was sent in to us as well.
 (Note: we don't have a copy of the toolkit yet, so if anyone has a copy we can analyze.....)

proxy_scanner details:
  • Scans for proxies by breaking the sender queries into multiple parallel processes
  • Uses libpcap to listen for responses.
  • Target selection list is randomized

Here's an excerpt from a known Chinese hacker repository:

     http://proxy-scanner.thu.cn/proxy_scanner-0.0.14.tar.gz
     It depends on libevent, and can run on Linux/FreeBSD box.
     No any document here now, all things is in source.
     It's ugly but it's power full. it can scan whole B network in
     60 seconds
     http://was.io8.org/me/project

Related Hosts Details (thanks to Team CYMRU's wicked whois server):
AS Name
AS      | IP               | BGP Prefix          | CC | Registry |

JINGXUN Beijing Jingxun Public Information Technology Co., Ltd
9803    | 211.100.33.61    | 211.100.32.0/19     | CN | apnic    |

CHINANET-BACKBONE No.31,Jin-rong Street
4134    | 61.183.15.41     | 61.183.0.0/19       | CN | apnic    |
4134    | 61.183.15.62     | 61.183.0.0/19       | CN | apnic    |

CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network
4808    | 61.135.159.152   | 61.135.128.0/19     | CN | apnic    |
4808    | 61.135.170.153   | 61.135.0.0/16       | CN | apnic    |
4808    | 61.135.170.159   | 61.135.0.0/16       | CN | apnic    |

Note: If you see an IP you own in one of the above URLs you might want to check your proxy configuration.
Here is are a few resources regarding open proxies and how to secure them:
http://www.ftc.gov/secureyourserver/
http://www.us.sorbs.net/faq/proxy.shtml
http://en.wikipedia.org/wiki/Proxy_server

You can also refer to this list of open proxies and see if your site is listed:
http://www.publicproxyservers.com/page1.html

The background as to why the proxies are entered into DNS is still a little sketchy.
Several bright folks wrote in hypothesizing how this method might be capable of detecting nested proxy networks.

Robert - SANS ISC Handler



Keywords:
0 comment(s)

Comments


Diary Archives