Threat Level: green Handler on Duty: Xavier Mertens

SANS ISC: InfoSec Handlers Diary Blog - Internet Storm Center Diary 2006-04-28 InfoSec Handlers Diary Blog


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

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)

and little flaws in IVE

Published: 2006-04-28
Last Updated: 2006-04-28 19:01:24 UTC
by donald smith (Version: 2)
0 comment(s)
Juniper Networks released a vulnerability announcement today.
From: http://www.juniper.net/support/security/alerts/PSN-2006-03-013.txt
"Title: IVE ActiveX client vulnerability
Date: 25 April 2006
Version: 1.0
Impact: Client side code execution in context of Internet Explorer
Affected Products: IVE OS 1.x to 5.x
Max Risk: High
Recommended Actions: Upgrade the IVE software to any of the following fixed versions: 5.3r2.1, 5.2r4.1, 5.1r8, 5.0r6.1, 4.2r8.1"

It appears that an activeX control that is installed when using IVE can be remotely exploited.
The exploit described by eeye looks fairly trivial.

IVE is  Instant Virtual Extranet which provides SSL VPN control with centralized reporting, monitoring and configuration management. It is basically a host security auditor and can be used as an element of their netscreen remote client. It can verify things like recent virus signatures and scans. Which  is important before letting some machine on to your corporate network!

eeye has published the details here:
http://www.eeye.com/html/research/advisories/AD20060424.html


Bleeding Edge Snort team has developed a signature for this.
http://blog.gmane.org/gmane.comp.security.ids.snort.bleedingsnort

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"BLEEDING-EDGE WEB CLIENT JuniperSetup Control Buffer Overflow"; flow:established,from_server; content:"E5F5D008-DD2C-4D32-977D-1A0ADF03058B"; nocase; content:"ProductName"; nocase; content:"PARAM "; nocase; content:"NAME"; nocase; distance:0; content:"ProductName"; nocase; pcre:"/value[\s'"]*=[\s'"]*[^'"]{100}/i"; reference:
www.eeye.com/html/research/advisories/AD20060424.html; classtype:attempted-user; sid:515151515; rev:1; )

Keywords:
0 comment(s)
Diary Archives