Don’t keep your house key at the office!

A few months ago, a colleague of mine who works for a consulting company had his house broken into and some valuables stolen. What was troublesome was that there was no sign of forced entry to the homeowner’s premises. The authorities were puzzled by this until several days later when my colleague found evidence that the desk drawers in his workplace had been rifled. He then remembered that he had left a copy of his house key tucked away in the back of one of the drawers of his office desk as an emergency backup in case he lost the house key he always carried in his pocket. The copy of his house key was of course missing from the desk drawer where he had carefully “hidden” it.

No one likes to have their privacy violated, especially in their home. Was it wise, though, for my colleague to keep a copy of his house key in his office at work? I guess it would have been OK if it had been kept in a safe at work, but how many offices these days have a safe for employees to store their valuables?

This was bad enough, but imagine if the thief had broken into my friend’s home instead of his office. Why, he might find his office key and use it to gain entry to his office. Then, provided he was motivated (and smart) enough, the thief could possibly steal sensitive business information from the company that he could use for (presumably) nefarious purposes. The end result could be that my friend might end up getting fired, or worse — maybe getting sued by management.

What kind of idiot keeps the key to his office at home? We all do of course — at least those of us who have offices that can be locked. But this raises an important question: What other access entity for your business or workplace do you store in your home or at some other site?

Steal my server, please!

Last summer a software company named Inversoft decided to demonstrate how much they knew about server hardening by issuing a challenge to all comers to try and hack their carefully-hardened web server. Brad Buda, a software developer and managing partner at the consulting firm Polynome, decided to take Inversoft up on their challenge. The end result was that he succeeded in penetrating Inversoft’s Linode-based Passport user database and management system and stole the dummy “sensitive” data the company had stored on the honeypot server they had provisioned for their challenge.

Brad’s story of how he and his friend Anton conducted their reconnaissance, strategic planning, and smash-and-grab campaign are well worth reading, especially if you have some familiarization with the LAMP stack. For those readers who aren’t that familiar with Linux or MySQL, it may suffice to read Brad’s recap of how they were able to succeed in their penetration attempt. This paragraph in particular is important for all of us in IT to pay special heed to:

“What could Inversoft have done differently to prevent this? Their hardening guide was and remains correct; there was no way we were getting through the front door of their servers (SSH or HTTPS). The course we took was a common one in targeted attacks; gain access to secrets used by humans, sometimes in ancillary systems, and use that access to bypass security via operator consoles or other magic. The most frequently seen version of this in the wild is to steal access to an email inbox that can be used to reset a password, and although this attack was slightly different, it’s a great reminder that attackers are far more likely to go around your defenses than through them.”

Notice the key phrase “ancillary systems” in Brad’s statement above. After a fruitless first attempt at trying the front door, which was too well-protected to enter through, he decided to try sniffing around in the company’s public-facing documentation in case one of their employees kept some sensitive information stored there, like a password for a user account. While he didn’t find what he had hoped for, what he did discover was a vulnerability in the platform on which the documentation system was being run. This led to him being able to open a command shell that eventually led him to a user’s home directory where some employees had kept information about various projects including the HackThis web server that hosted the challenge.

What can we learn?

Microsoft

What sort of lessons can we learn from my colleague’s unfortunate experience and Brad’s fascinating escapades? The most important thing is that security must be everywhere. Google defines “defense in depth” as “the practice of arranging defensive lines or fortifications so that they can defend each other, especially in case of an enemy incursion.” But instead of thinking of security as a series of layers, it might be better to think of it as a characteristic or attribute that every asset of an organization — networks, systems, services, applications, data, persons, facilities, relationships, and so on — must have clearly defined at all times.

If you store something sensitive like your house key in several places, it must be securely stored at each ancillary location. If you store information somewhere that may not seem to be sensitive, like the public-facing documentation for your company, the ancillary location where that information is stored should be configured as securely as the critical systems your business relies upon. Just because something is sensitive like a house key doesn’t mean that a smart thief won’t know what to do with it if he finds it stored offsite somewhere. And just because something isn’t sensitive, like the help file for your company’s product, doesn’t mean that one of your employees may not have left something valuable sitting around in one of the folders of the system hosting the help file.

Brad won the challenge Inversoft had posed, and as a result he received the promised prize: a MacBook. If anything this also teaches us the secret of human nature, namely that we like stuff and will often go to extremes (including theft) to try and get more of the kinds of stuff we want.

Photo credit: FreeRange Stock

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top