Eight security tips from the HBGary Hack

Thanks to Ars Technica and H-online.com, we now have intimate details of the Anonymous attack against security research company HBGary. There are no surprises in how the attacks where carried out, but we can draw many morals from the story, even if we've heard them time and time before.

Here's an executive summary of how the attack was carried out, and how you can defend against the same things happening to your systems.

1. Use Off-the-Shelf Software

HBGary Federal's Website ran a content management system (CMS) that was created especially for the company. There's a debate to be had as to whether off-the-shelf software is more secure that custom-made solutions.

On the one hand, exploits for off-the-shelf solutions are often published far and wide and, in the case of a zero-day exploit, can leave system administrators rushing to fix their systems as quickly as possible.

Commissioning custom software offers security via obscurity -- there isn't a body of knowledge about how to hack the system, and no source code to search through to find vulnerabilities. However, the system will need to be routinely audited for security -- a costly procedure but utterly necessary.

Had HBGary Federal gone for an off-the-shelf solution, it's arguable the first stage of the attack -- a simple SQL injection -- wouldn't have been possible. Most commercial CMS solutions are security audited at source, to avoid end-users having to do so, and are regularly patched when problems are found.

2. Patch Your Systems Regularly

Had HBGary Federal been using an off-the-shelf CMS, it might still have been vulnerable if the system wasn't regularly patched. So, assuming you're running an off-the-shelf system, patch your systems regularly -- both software and the underlying OS. If you haven't already, buy a support contract to make life significantly easier.

Patching a system can introduce problems, of course, but that's why you should be creating copies of your servers, where you can test the patches before rolling them out to your customer-facing systems. Virtualization offers a perfect method of doing this (especially if your original server runs in a virtualized instance), and you can even make use of cloud virtualization solutions to avoid the hassle of keeping a copy of your server locally.

Should the patch go wrong, virtualization lets you roll back to a working state. What more could you want?

3. Test For Really Obvious Holes

As mentioned, HBGary Federal's Website was hacked using an SQL injection attack (SQL being a type of database).

SQL injection involves a URL created by a hacker accessing data in the database underlying the Website. On most Websites this kind of attack is well-known and URLs are 'scrubbed' to ensure this can't happen, beyond and above official and necessary access. For whatever reason, HBGary Federal's site neglected to do this, and Anonymous was able to retrieve the username and password database from the site.

Wise-up on SQL injection techniques and give them a try on your systems (making sure not to use techniques that might involve data loss, of course). You should also learn all about cross-site scripting (XSS) attacks, if you haven't already.

4. Store Passwords Securely

With the username database now in their hands, Anonymous set about cracking it. They could have hit a brick wall but, again, poor security procedures made life easy for them. The HBGary Federal database stored passwords as simple MD5 hashes -- an unsophisticated form of encryption. This allowed Anonymous to use rainbow tables to uncover some passwords. Rainbow tables are 'ready made' databases of prehashed passwords. Put simply, the hashed password list is simply compared side-by-side with a rainbow table until a match is found.

Hashes can be made stronger by avoiding the use of MD5, which generates short password hashes that are relatively easy to crack, and are vulnerable to collision attacks. The government suggests everybody use the SHA-2 family of hashes, such as SHA-256 or SHA-512.

Additionally, or if MD5 just can't be avoided, the password should be iteratively hashed, which is to say, the hash is rehashed thousands of times. Known as key strengthening, this deliberately slows down the hash production, but also slows down attackers to the point of making attacks infeasible. Additionally, hashes can be salted, whereby random data is inserted into the hash to strengthen it. This makes rainbow attacks significantly more difficult, if not impossible.

5. Force Users to Create Complex Passwords

Anonymous was able to decode the passwords of two of HBGary's executive staff (Aaron Barr and Ted Vera). The passwords consisted of eight characters -- six lower-case letters and two numbers.

Had HBGary Federal's systems enforced more complicated passwords, it's less likely that Anonymous would have been able to uncover these passwords. Ideally, HBGary Federal's system should have enforced 10 or 12-character passwords, and insisted that lower and upper-case letters, numbers and symbols appear somewhere in the password.

6. Don't Reuse Passwords

Anonymous now had the username and password details of the executives, and found that the gentlemen concerned had reused the passwords in lots of other places: e-mail accounts, Twitter and a support server, in particular. Thus, Anonymous was able to access their e-mail.

The accounts on the support server were only those of ordinary users but the system wasn't patched against a vulnerability that allowed standard users to use privilege escalation to illicitly get superuser powers. The flaw was patched in November, but the hack took place three months later in February this year (see above -- regularly patch your systems!).

It might have been the case that HBGary admins thought they could trust their users. However, if that's the case, they obviously didn't anticipate a hack attack delivering users they couldn't trust in the slightest.

7. Delete Sensitive E-mails

One of the executives was the administrator of the entire e-mail system, so Anonymous now had control of all HBGary e-mail accounts. Using this they gained access to the account of another executive (Greg Hoglund), where they found an e-mail containing the root password for the rootkit.com site.

Delete any sensitive e-mails you receive, especially those containing passwords. Yes, it's nice to have this kind of info lingering around in your inbox in case you forget, but that's exactly the kind of laziness that hackers exploit.

8. Educate Against Social Engineering

Anonymous had a root password, but they couldn't access the rootkit.com server because it didn't allow root access from outside of the firewall -- a wise security move. They needed to be able to login as a standard user and then switch to root once logged in.

To get this, they used Greg Hoglund's e-mail account to make contact with somebody who had root access to the server. In an entertaining e-mail exchange, Anonymous first suggested they had problems logging in to the server, using their acquired knowledge of the root password to give themselves authority and credibility. Following this they manipulated the root admin into resetting Greg's password, and also revealing his username -- the two pieces of information they needed.

It was a classic example of social engineering. Clearly, the root admin shouldn't have sent the password or login name via e-mail, but "Greg" appeared to have started the trend by revealing the root password in his initial e-mail. This is a typical social engineering trick used to inspire confidence in the victim.

There are many books and articles out there on social engineering, and many consultants who will come in to teach staff all about it. Essentially, unless you're face to face with an individual, there's simply no way of knowing if the person you're speaking to is who they say they are.

Keir Thomas has been making known his opinion about computing matters since the last century, and more recently has written several best-selling books. You can learn more about him at http://keirthomas.com. His Twitter feed is @keirthomas.