Thoughts from The Cuckoo's Egg

, 2007-04-06

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





Related content

Database Mirroring FAQ: Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup?

Question: Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup? This question was sent to me via email. My reply follows. Can a 2008 SQL instance be used as the witness for a 2005 database mirroring setup? Databases to be mirrored are currently running on 2005 SQL instances but will be upgraded to 2008 SQL in the near future.


1,567 reads

Networking - Part 4

You may want to read Part 1 , Part 2 , and Part 3 before continuing. This time around I'd like to talk about social networking. We'll start with social networking. Facebook, MySpace, and Twitter are all good examples of using technology to let...


1,530 reads

Speaking at Community Events - More Thoughts

Last week I posted Speaking at Community Events - Time to Raise the Bar?, a first cut at talking about to what degree we should require experience for speakers at events like SQLSaturday as well as when it might be appropriate to add additional focus/limitations on the presentations that are accepted. I've got a few more thoughts on the topic this week, and I look forward to your comments.


360 reads