Hello, challenge fans! This is Ed Skoudis, your genial challenge host, here to announce the answers and winners for our Santa Claus is Hacking to Town extravaganza.

As I’ve mentioned in the past, I try to make each of these challenges unique in some way, pushing the envelope a little bit with our challenge format, twiddling with the structure, theme, technical focus, and so forth, just to mix it up. This challenge was no exception. Pretty much every challenge we’ve done so far (28 of them in total) has focused on having readers analyze a hack and talk about what the bad guy did, devising strategies for defending against such wickedness. In this Santa challenge, we reversed roles, having you, the readers, devise an attack strategy to achieve a goal. I even made it a little more open ended than usual by creating a contrivance so you could select one additional tool to download and use in your attack. I flipped things around to make this challenge more offensive in nature, modeling the kinds of improvisation that penetration testers and ethical hackers often need to display.

So, the good news is that you guys got very creative, with different answers posing all kinds of interesting attack strategies, tactics, and tools. But, this flexibility and attack focus introduced a bit of downside for me. With so many different answers using so many different kinds of tools, it took a lot more time to judge this one to determine the winners. I had to test out each tactic you guys threw at me, just to see if it would work, in a lab designed to mimic the Burgermeister’s jail cell.

And that brings us to another aspect of this particular challenge. The quality of answers you guys submitted on this one was astoundingly good. I was seriously impressed with the technical ingenuity, creative flair, and solid writing exhibited in over ten different sets of answers. Quite honestly, this was, by far, the most difficult challenge I’ve ever had to judge because of the large number of really high-quality entries. But, I did carefully look through every single answer, and selected the best quality ones I could.

Not that I'm complaining (really, I'm not), but that -c was intentional there. What I found trough experimentation (and yes, those steps were written after reproducing them in a test environment) was that using the -e switch you couldn't pass parameters, something that I needed. Now, it may not be universally available (for example AFAIK the -L switch is only available under Windows, that's why I had to do some ugly shell scripting), but probably it can be found in the nc version contained in most Linux distros.

You know, that's a really good point! Sorry I overlooked it. I typically use a patched version of the Hobbit nc for Linux/UNIX or Weld Pond's for Windows, and rely on its syntax. To execute a command, I run it with -e [command]. If I want a command with parameters or multiple commands, I use -e followed by a .bat file (Windows) or a .sh file (Linux/UNIX), which contains the command(s) and parameters. Thus, I haven't used the -c option, because it's not included in the Netcat version I use, plus I haven't needed it. However, I do see the value of having the -c option, and now understand why you used it. Thanks for the clarification. Great work, man!

By the way, it took me about 40 hours of testing to go through all of the responses, running their commands to see if they worked. And, if a given command or approach didn't work, I tried alternative versions of Windows (XP, Vista, 2000, 2003) or tried tweaking their syntax to make it work. Because my target Linux had the Hobbit Netcat on it, the -c option wasn't present and therefore failed, so I changed it to a -e to make it work. That's what prompted my comment. But, your point about the commonly installed Netcat on most Linux distros is absolutely right.

On all of my Linux boxen, I typically remove default versions of Netcat and replace them with my own, because I hate that they omit the -p option in Netcat listeners. Leaving off the -p for local port on listeners just looks evil to me.

I've got a question concerning this contest. In the contest it says: "Things got even worse, as Kris explored the machine’s file system only to find that Netcat was not included in this distribution, which appeared to be a stripped down Fedora Linux machine." So there is no netcat on web1.

But in the answers from Wesley to question 1 it shows to use netcat on web1 and also in the answer to question 2 it says: "Well, on web1, you could make another Netcat relay, this time a client-to-client relay, as follows:

I too went at this contest in the same fashion. When I approached this I went at it with the view that if I wanted netcat on web1 that I would need to put it on there myself. I thought it was only in my arsenal, but getting it on the box was up to me. This is why I chose ssh over netcat, since it would already be provided.

Yeah paul, I read your solution it was very nice and i understood it but I don't understand why it is right to use nc on a machine where it isn't. And it seems like I'm not the only one, already thought I overlooked something very obvious

I purposely designed the challenge so that it did not include Netcat on that server so that you'd have to devise a method for moving it there. Sorry that I didn't include that step in my answers. My answers were getting really long (11 typed pages), so I didn't include every single command. I'm glad you guys asked about this one, because it deserves to be talked about in more detail. Thank you! These challenges are all about sharing techniques among security practitioners, and the techniques associated with this one were fantastic.

Mark Baggett's answer did indeed include a method for getting Netcat there, but he actually sent me his solution in multiple parts. I'm sorry, but I did not include the part of Mark's answer that mentioned how he got nc there. I'll mention his technique below (with an excerpt of his submitted answer part that included the transfer) below as I go through the methods for moving nc to web1.

So, let me tell you about how different people (including Mark), got Netcat to web1. All of these techniques relied on the command-injection flaw on web1:

Method i) Inject a command that invokes wget to connect to Santa's laptop and pull down the Linux version of Netcat. This is the method used by Mark Baggett and many other people. Here is the syntax he specified in the other component of his answer:

It was a nice approach, in that he remembered to move index.html into nc (in effect renaming it), and he even chmod'ed it so that any user (including apache) could read, write, and execute it. I gave Mark extra points for remembering the mv and chmod, because several others forgot it. Richard J. used a similar technique, as did Peter Jackson (who also showed how it could be done with curl). Several others did as well.

Method ii) Inject the echo command to build an FTP command file on web1, and then inject a command to invoke an FTP client to run commands from that file. Zoher used a variation of this technique with the lftp command.

Method iii) Use tftp to move the file by injecting a command to invoke the tftp client on web1. This method depends on Santa's Linux box having a tftpd and web1 having a tftp client, which they may or may not have.

Method iv) Using /dev/tcp on web1. I really liked this approach, because it uses the built-in capabilities of bash on many Linuxes for interacting with /dev/tcp via shell redirects. Several people tried this, but many of them had improper syntax. As you may know, /dev/tcp can be used via bash on some Linux systems (typically non-Debian derived Linuxes) to open an outbound TCP connection. You can push data across that connection easily by just cat'ting or echo'ing it into /dev/tcp. But, how can you pull data across it, for file transfer? Raul Siles' answer included syntax for doing that, as follows:

"Kris made available a copy of the Linux netcat binary through [his own laptop] on port TCP/80 (a little stealthy trick to simulate a web server connection in case someone checks outbound traffic from web1) using netcat:

[Santa's_Laptop] $ nc -l -p 80 < /usr/bin/nc

Using the web-based command injection flaw, Kris launched a series of commands to initiate a connection from web1 to [his own laptop] on port TCP/80 and retrieve the Linux netcat binary. The file was copied under /tmp, as a readable and executable file.

These are quite nice techniques, and kudos to Raul and Ryan for using it. Note that both remembered the chmod. Raul even went further and md5sum'med it. Note that Raul, to get the output displayed, must be using an interactive shell, likely delivered via /dev/tcp on another port.

Method iv) Create a perl script that runs on Santa's laptop to encode and move the file. Peter Jackson used this approach, saying it's what he'd rely on if wget or curl were not available. His script base-64 encoded netcat and chopped it up into little parts, transmitting them via the command injection flaw 57 bytes at a time, injecting the echo command into web1 with >> to append the given chunk of Netcat to the file he built on the target. This also was a very cool approach. Here's Peter's code: