• E-mail this page
• |  Print this page
• | 
• | 
• | 

I Just Won Another Game Of Hacker Chess

True security geeks love to one-up each other. In much the same way that Chloe O'Brian one-upped Janeane Garofalo's character, Janis Gold, on 24 last night, I just out-dueled a fellow security pro. Have you ever played a game of hacker chess? If you can find someone you trust to play with, you could be saving your job by engaging in this high-stakes exercise, because it's not a game at all, it's a simple penetration-testing exercise that should be a routine part of your monthly to-do list. Read on to find out how I checkmated my enemy.

If you're a security professional, then you already know this fact. The perimeter of your network is being scanned daily, and possibly right now, for vulnerabilities, open ports, exposed hosts and static NATs, among other things. As you go about your daily life and execute on projects, add to your infrastructure and troubleshoot issues, you could be opening up holes in your security perimeter that accidentally slip by you. It happens to me all the time, and what I usually do is turn to a trusted friend, who's also a security pro, to play a game of hacker chess.

There are just a couple of basic rules when it comes to hacker chess. Firstly, you can't use hacker tools like nmap and IP Scanner; that makes the game too easy. You also can't execute dictionary attacks against the other party; that's simply not fair and is too risky. Lastly, you have to use a DOS shell, NO Unix, no Win32 apps, nothing, but you can use a browser to confirm if a server is a Web server. That leaves you to using any utilities at your disposal within the DOS shell, including any DOS based SSH clients you've installed. The game only lasts five minutes, so I've prepared my DOS environment accordingly so I have a path to all of the tools I'll need.

Here's how you win the game. You expose a host listening on a port it should not be, thus exposing vulnerability. For example, prove to your enemy that you've just determined that one of his, or her, externally accessible servers is listening on TCP 137-139 (NetBIOS). Or maybe you can prove that a Web server is listening for FTP connections. You get the point.

Let the game begin!!!! While I know every IP block I manage by heart, a scary ability in and of itself, I had to look up the IP space of my enemy this time. Here's how I usually approach this game. So let's say I'm attacking my own employer, in this case, InformationWeek.com. The first thing I do is establish the IP space that contains the hosts that I'm going to probe. Via the Web, this is easy to do, but because I can only use a DOS shell, I need to use a DOS based WHOIS client. I found a nice one a while back at http://www.nirsoft.net/utils/whosip.html. Running this tool against InformationWeek.com reveals not only the IP space owned by InformationWeek's ISP, but also the SPECIFIC IP space being used by InformationWeek. Now I'm 10 seconds into the game, and I've already established the range of hosts I'm going to attack, I'm feeling pretty good. I start doing nslookup's on all registered hosts in the subject domain, and I discover all of the A and MX records registered, I'll start there, because ping sweeps can easily be dropped by firewall admins paying attention. If a record is registered, then I know services exist there, and possibly some extra services that could win me this game.

Without giving an entire play by play, about two minutes into the game I had won. After discovering the IP tied to the MX record for this domain, I went to work on this mail server. Of course, it was listening on port 25, no win there. I telnetted to port 80 and got the magic blinking cursor, meaning it was listening on port 80, a possible win, until I verified that this server was a Webmail box. No win there because this is expected behavior. Where I won was with a telnet to port 3389 on this mail server, the Remote Desktop port. Low and behold, the administrator turned on remote desktop to his exchange server a few days back so he could troubleshoot an issue remotely from home. He forgot to turn it off!!!!!! This harmless game exposed a HORRIBLE security vulnerability. NAT'ing remote desktop directly through to your production exchange server from the internet? That's kind of like a frog hopping across 42nd Street: certain suicide.

The moral of the story: Geek games like this among trusted colleagues can prove invaluable for keeping you on your toes as a security admin.

I know there's a lot of people out there better than me, with our very own fearless leader and lead analyst at InformationWeek, Mike Fratto, among them. Leave us a few tips or stories of your own about cool penetration testing tricks that you've used to keep your network secure and safe.

« Evernote For Blackberry Released | Main | Secure360: The Triumph Of Politics (Over Security) »