SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

Thoughts from The Cuckoo's Egg

The Cuckoo's Egg
by Clifford Stoll has been around for a while, having been published in 1989. It details how a system administrator (a trained astronomer who had to find something else to do) tracked a malicious hacker through his system and numerous others including defense contractors and unclassified DoD systems. It's one of those books a lot of folks who work security say should be read if you're in the field. When I was a cadet at The Citadel, one of the other guys in my company was reading it and said it was a good thriller of a book. I meant to borrow it from him and never did. Then I meant to read it for some time but every time I thought about it, I would subsequently forget to go look for it or check it out from the library. Well, I finally did read it and found that my friend's assessment was a good one. I think my wife would agree as she swiped it away from me before I was done and finished it first.

As I went through the book I watched for security principles in play and what was true in 1989 in large part holds true today. Some of the things that were revealed as Mr. Stoll went through his meticulous process of tracking the intruder who was working for the KGB:

  • Honeypots are effective to attract an attacker and learn about his or her methods. In the book Stoll's roommate comes up with an idea to place what look to be classified documents on a military defense system on one of the servers and to keep it updated so as to look like a regular project that is progressing. This is ultimately how they get the attacker to stay connected long enough to trace him. Honeypots are used today to attract attacks, especially automated ones, so we can analyze them and learn to defend against them.
  • Dictionary based passwords don't work. The attacker in the tale kept grabbing the password file from the servers he was attacking. Stoll at first couldn't figure out why because the passwords were encrypted with a one way function which meant if you had the actual password it was easy to get the encrypted hash, but the opposite, where you have the hash and want to get the actual password wasn't true. However, the algorithm used to encrypt the passwords was well know. So if you calculate all the hashes for a set of words, you can compare the hashes and figure out what the passwords are. BTW, this is an issue with Windows passwords. Do a search for rainbow tables and you'll find several sites that have rainbow tables for Windows-based passwords.
  • Just because you can't see the monitoring devices doesn't mean you aren't being watched. Stoll put a line printer before the server itself, meaning he got an output of everything that was going back and forth on the line. this allowed him to watch the attacker as he came and went. Nothing was running on the server itself. This is analogous to two things in today's world: sniffers and rootkits. Sniffers watch the wire and from the server you can't tell you're being watched. This is why encrypting sensitive data across untrusted lines is important. Rootkits are running at a level where they can intercept any calls you make to try and detect them. That's why there was so much concern over rootkits (and still is).
  • When doing forensics work, keep a log. This is a no-brainer. Log everything you do, who you speak to, every step. Time and time again Stoll went back to his log. Because he had it, he was able to connect a lot about the attacker's behavior, prove he had informed the right people of what happened, etc. This is actually a good rule for troubleshooting. Log everything you do because you (a) want to be able to undo anything that didn't work and (b) you want to know how exactly you fixed a problem.
  • Don't assume your system has no value. Stoll's system didn't have classfied secrets on it. But it did represent a jumping off point to attack other systems. Frequently I have conversations with folks about securing development servers. To the attacker, a development server may be just as valuable as a production server. If a system is on your production network, it needs to be secured.
  • Don't assume you are secure. Stoll found several folks who assumed their systems were secured. The evidence showed otherwise. Paranoia is good in the security field. Let me rephrase that... controlled and focused paranoia is good.
  • Check your logs frequently and investigate inconsistencies. Stoll stumbled onto the hacker because of a 75 cent accounting error. That's what started the whole trace. The better an attacker is, the less likely he or she is to leave clues. Therefore, even the smallest details are important.
  • Change default accounts and passwords. The attacker kept breaking into systems because administrators had left default accounts and passwords active. Blank passwords, passwords of password (or some derivative), and default passwords are all bad. If an attacker is knowledgeable of the defaults and we leave them active, we've opened the door. It was amazing how many systems the attacker got into using this simple method.

Technorati Tags: Security | Database Security | | | SQL Server Security

K. Brian Kelley - Databases, Infrastructure, and Security

IT Security, MySQL, Perl, SQL Server, and Windows technologies.


Posted by D Rickard on 9 April 2007
That was a great book. I haven't read it in over ten years - I think I'll go back and read it again.
Posted by CyberArachnid on 14 April 2007
That was and still is a great reading material.
Leave a Comment

Please register or log in to leave a comment.