How to stop Blackhole Exploit Kit by using its vulnerability

This is an explaination of the blackhole exploit kit vulnerability to be use to make the DoS attack to the blackhole service itself to make these evil service goes down.
It was released in the internet that the latest zeroday java is in used already in the blackhole malware pack service. And the infection is in Epidemic now. Those blackhole server list was released like in the articles below:
http://blog.fireeye.com/research/2012/08/java-zero-day-first-outbreak.html
http://www.malwaredomains.com/wordpress/?p=2837
http://community.websense.com/blogs/securitylabs/archive/2012/08/28/new-java-0-day-added-to-blackhole-exploit-kit.aspx

It has a lot of hosts serving mass blackhole army, it will be tough to make it down one by one, this is the analysis to outsmart the lowlife who serve it by making them to have the mass DoS to themself.

Most of the unwanted visited IP with the wrong parameter, while accessing blackhole main.php will be redirected w/ the PHP code to the other site (google.com by default)
Below is the example:

--00:23:54--  http://91.220.35.52/main.php
           => `main.php'
Connecting to 91.220.35.52:80... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily <=====THIS
Location: http://google.com [following]
--00:23:56--  http://google.com/  <=====THIS
           => `index.html.2'
Resolving google.com... 173.194.38.103, 173.194.38.110, 173.194.38.104, ...
Connecting to google.com|173.194.38.103|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://www.google.com/ [following]
--00:23:56--  http://www.google.com/
           => `index.html.2'
Resolving www.google.com... 173.194.38.116, 173.194.38.115, 173.194.38.114, ...
Connecting to www.google.com|173.194.38.116|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://www.google.co.jp/ [following]
--00:23:56--  http://www.google.co.jp/
           => `index.html.2'
Resolving www.google.co.jp... 173.194.38.120, 173.194.38.127, 173.194.38.119
Connecting to www.google.co.jp|173.194.38.120|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
    [ <=>                                 ] 11,201        --.--K/s
00:23:57 (892.23 KB/s) - `index.html.2' saved [11201]

I was analyzing the blackhole to confirm this vulnerability, found the windows base VPS hosting was used for this evil service:
---------------------------
PORT     STATE    SERVICE
---------------------------
21/tcp   open     ftp
22/tcp   open     ssh
25/tcp   open     smtp
53/tcp   open     domain
80/tcp   open     http<-----------ngnix
110/tcp  open     pop3
135/tcp  filtered msrpc
136/tcp  filtered profile
137/tcp  filtered netbios-ns
138/tcp  filtered netbios-dgm
139/tcp  filtered netbios-ssn
143/tcp  open     imap
445/tcp  filtered microsoft-ds
587/tcp  open     submission
993/tcp  open     imaps
995/tcp  open     pop3s
3306/tcp open     mysql

---------------------------
The other ones....
---------------------------
PORT     STATE    SERVICE
21/tcp   open     ftp
22/tcp   open     ssh
25/tcp   filtered smtp
53/tcp   open     domain
80/tcp   open     http <-----------ngnix
110/tcp  open     pop3
135/tcp  filtered msrpc
136/tcp  filtered profile
137/tcp  filtered netbios-ns
138/tcp  filtered netbios-dgm
139/tcp  filtered netbios-ssn
143/tcp  open     imap
445/tcp  filtered microsoft-ds
587/tcp  open     submission
993/tcp  open     imaps
995/tcp  open     pop3s
3306/tcp open     mysql


Q: What OS is these infected machines?
A: Windows, Poc:
---------------------------
TCP/IP fingerprint:
---------------------------
blackhole server #1:
TSeq(Class=TR%IPID=Z%TS=1000HZ)
T1(Resp=Y%DF=Y%W=1380%ACK=S++%Flags=AS%Ops=MNNTNW)
T2(Resp=N)
T3(Resp=Y%DF=Y%W=1380%ACK=S++%Flags=AS%Ops=MNNTNW)
T3(Resp=Y%DF=Y%W=1380%ACK=O%Flags=A%Ops=NNT)
T4(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
PU(Resp=Y%DF=N%TOS=0%IPLEN=164%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)

blackhole server #2:
T1(Resp=Y%DF=Y%W=1380%ACK=S++%Flags=AS%Ops=MNNTNW)
TSeq(Class=TR%IPID=Z%TS=1000HZ)
T1(Resp=Y%DF=Y%W=1380%ACK=S++%Flags=AS%Ops=MNNTNW)
T2(Resp=N)
T1(Resp=Y%DF=Y%W=1380%ACK=S++%Flags=AS%Ops=MNNTNW)
T2(Resp=N)
T3(Resp=Y%DF=Y%W=1380%ACK=S++%Flags=AS%Ops=MNNTNW)
T2(Resp=N)
T3(Resp=Y%DF=Y%W=1380%ACK=O%Flags=A%Ops=NNT)
T4(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T3(Resp=Y%DF=Y%W=1380%ACK=O%Flags=A%Ops=NNT)
T4(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
T4(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T5(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
T6(Resp=Y%DF=Y%W=0%ACK=O%Flags=R%Ops=)
T7(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
PU(Resp=Y%DF=N%TOS=20%IPLEN=164%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)
T7(Resp=Y%DF=Y%W=0%ACK=S++%Flags=AR%Ops=)
PU(Resp=Y%DF=N%TOS=20%IPLEN=164%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)
PU(Resp=Y%DF=N%TOS=20%IPLEN=164%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)

Just simply check from the http service;
---------------------------
HTML/HEAD
---------------------------
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 29 Aug 2012 16:02:45 GMT
Content-Type: text/html
Content-Length: 13
Last-Modified: Thu, 23 Aug 2012 07:24:12 GMT
Connection: close
Accept-Ranges: bytes


Let's check the ngix version by requesting baaaad request:

$ echo -e "GET http://146.185.236.183/ HTTP/1.0\n\n" | nc 146.185.236.183 80 | less
HTTP/1.1 500 Internal Server Error
Server: nginx/1.1.18
Date: Wed, 29 Aug 2012 16:26:35 GMT
Content-Type: text/html
Content-Length: 193
Connection: close

<html>
<head><title>500 Internal Server Error</title></head>
<body bgcolor="white">
<center><h1>500 Internal Server Error</h1></center>
<hr><center>nginx/1.1.18</center>
</body>
</html>
(END)


then compare w/ different IP of up/alive blackhole:

$ echo -e "GET http://91.220.35.52/ HTTP/1.0\n\n" | nc 91.220.35.52 80 | less
HTTP/1.1 200 OK
Server: nginx
Date: Wed, 29 Aug 2012 16:46:41 GMT
Content-Type: text/html
Content-Length: 13
Last-Modified: Thu, 23 Aug 2012 07:24:12 GMT
Connection: close
Accept-Ranges: bytes

404 Not Found
(END)

OK, we have information like Windows NGNIX 3version behind, with PHP was used..
We have two different setting of ngnix here.
They are all using ngnix, but they don't set it with the common setting.
The first one is what I saw yesterday, and day before yesterday is using default setting, which shows version, html base error etc, the second one is a cutomized set of ngnix.
As you can see I just ask for the root access via IP address.
So let's try to request the main.php to the previous blackhole IP and see what happen.

$ nc 146.185.236.183 80
GET htttp://146.185.236.183/main.php HTTP/1.0

HTTP/1.1 302 Moved Temporarily
Server: nginx/1.1.18
Date: Wed, 29 Aug 2012 16:37:13 GMT
Content-Type: text/html
Connection: close
X-Powered-By: PHP/5.3.10
Location: http://google.com

$ nc 91.220.35.52 80
GET http://91.220.35.52/main.php HTTP/1.0

HTTP/1.1 302 Moved Temporarily
Server: nginx
Date: Wed, 29 Aug 2012 16:53:56 GMT
Content-Type: text/html
Connection: close
X-Powered-By: PHP/5.3.5
Location: http://google.com

Yes, it confirmed the theory.
in 146.185.236.183 is using the default setting, and in additional PHP/5.3.10
while 91.220.35.52 is using better set of ngnix with PHP/5.3.5
It is sure that character used for redirection is the same, the typo of http://google.com this look like a default string implemented in blackhole to redirect request.
In additional, let's make a PoC of A nice unix trick to perform PoC of this crafted strings of blackhole. I create a text file myblackholetest.txt as per below:

//---------------start
HTTP/1.1 302 Moved Temporarily
Server: nginx
Date: Wed, 29 Aug 2012 16:53:56 GMT
Content-Type: text/html
Connection: close
X-Powered-By: PHP/5.3.5
Location: http://google.com
// end-------------

Let's put it as a daemon in the unix server w/ IP x.x.x.x bind to the port 8886 w/the netcat below:

$ cat boobytrap.txt |  nc -l -p 8886

Then use the neighbor browser to access:

$ lynx http://x.x.x.x:8886
(incoming answer start from here)
HTTP/1.1 302 Moved Temporarily <--- response 1
(and google page redirected)

In the server side goes like the below capture:

$ cat boobytrap.txt |  nc -l -p 8886
(incoming request for browser starts here)
GET / HTTP/1.0
Host: x.x.x.x:8886
Accept: text/html, text/plain, audio/mod, image/*, application/msword, application/pdf, application/postscript, text/sgml, */*;q=0.01
Accept-Encoding: gzip, compress
Accept-Language: en
User-Agent: Lynx/2.8.5dev.16 libwww-FM/2.14 SSL-MM/1.4.1 OpenSSL/0.9.7a

Wowie it works just like the answer of the blackhole itself.

It is proved that blackhole written w/simple TCP/socket bind coded in main.php or other PHP files to redirect, all we have to do attack this evil service is to change the "location:" into the IP address of the blackhole server or servers.. will be an interesting chain reaction.

How to make this work? Please see the above HTTP response coming. The first one is the default setting of ngnix, the next is the one with the better configuration. For what we know by the above analysis is the version of ngnix used (1.1.18) has 3 or 4 flaws in it, well the simple File upload arbitary w/ a little SQLi of the PenTest tools will do the work just fine. For your conveniences below is the list of vulnerability affected.

Possible arbitrary code execution with null bytes in URI
https://bugzilla.redhat.com/show_bug.cgi?id=717078

Possible Arbitrary Code Execution with Null Bytes, PHP, and Old Versions of nginx
https://nealpoole.com/blog/2011/08/possible-arbitrary-code-execution-with-null-bytes-php-and-old-versions-of-nginx/

nginx fix for malformed HTTP responses from upstream servers
http://seclists.org/bugtraq/2012/Mar/65

nginx security advisory: mp4 module vulnerability
http://www.openwall.com/lists/oss-security/2012/04/12/9

*) This material is for the research purpose only.

------
 - Anonymous care citizen (not related to the anonymous group at all) -