Unless you’ve been living under a stone for last couple of weeks, you will have heard about the HBGary Federal hack. Seeing everything published about this probably makes every security professional think for at least a second, 'Could this happen to me too?'.

As most details about how the attack was carried have been published already (for example, see http://arstechnica.com/tech-policy/news/2011/02/anonymous-speaks-the-inside-story-of-the-hbgary-hack.ars) we can now look at all exploited vulnerabilities.

SQL injection on a public web site

I’m sure anyone who has done at least a little bit about security of web applications have heard about SQL injection. SQL injection vulnerabilities (or general injection vulnerabilities) are at the #1 place of OWASP top ten vulnerabilities for 2010.

A lot of web applications are vulnerable to SQL injection so one must be very careful when picking a web application for your web site. HBGary unfortunately had a vulnerable web application which allowed attackers to retrieve information directly from the back-end database – this information included MD5 hashes of passwords of users, that had access to the administration web interface.

I’ll get back to MD5 later, let’s focus on the web application for now. Successfully cracking one of the passwords would allow attackers to modify the web page (since it was a CMS). While this is bad (especially given it was a security company), it is still not as bad as what happened next.

According to the information that posted, the SQL injection in the application was really simple – I wouldn’t be surprised if the attackers used a powerful tool such as sqlmap, which should be able to exploit this.

Using same (weak) password for multiple applications

This turned out to be a major issue. After the attackers cracked the password, they (logically) tried it on all other applications/sites. Turns out  that the same password was valid for e-mail & other applications, such as Twitter and Linkedin.

Since we all depend on e-mail for daily communication, it is obvious how the attackers took over the initiative at this point – they were able to read HBGary’s CEO’s e-mails and even send e-mail purporting to be him.

After carefully checking individuals that he was sending e-mails to, the attackers used social engineering to attack a system administrator of another system (rootkit.com) – an obvious weak spot since he/she holds “all the keys to the kingdom”.

It was this social engineering attack which impressed me the most (given the SQL injection was really simple) – the attackers sent a carefully crafted e-mail, asking the administrator to open SSH on a weird port and set the root password to something he knows (he allegedly being Greg Hoglund).

Could this happen in your company? I hope not – all of us - while doing various consulting gigs, such as ISO 27001 and similar, always stress, "that all changes must be approved and documented". However, when another person, or even a CEO asks an administrator to do something, ignoring all processes, would he/she that? Something to think about.

When the administrator opened SSH and changed the password, it was game over. The attackers had full access to the system and they downloaded e-mail backups and all other things we’ve been reading about over the last couple of weeks.

So what can we learn from this hack?

A lot of things that we already preach (or should be preaching):

• Do not use same passwords for multiple applications/sites. A lot of free, good utilities, such as Password Safe exist that will allow you to automatically generate strong passwords and store them in an encrypted key chain.
• No matter the size of your company, you should have change management processes that require all changes to be approved by appropriate personnel. While a CEO can request to open a port on the firewall, a security person in charge should approve any such request. If you don’t have multiple roles for this then make sure that appropriate authentication is in place – i.e. verifying such critical requests through other channels.
• You should regularly test your web applications – not only external, but also internal. While this does not guarantee that you will identify and eliminate all security vulnerabilities, it will certainly raise the overall security.
• Encrypt your backups and think twice if you need all those e-mails at one place. Gmail is certainly attractive for storing years of e-mails and searching through them quickly, but imagine what would happen if someone gets access to all your e-mail.
• While we’re on encryption – encrypt sensitive e-mails too - it may seem a nuisance, but it could save the day. PGP Encryption is not difficult to use, there are downsides, of course, so you should balance between usability and security.
• If you are a web-application developer, and have a need to store (hashed) user passwords remember that algorithms such as MD5 were built for speed! By using today’s GPUs, it is possible to crack hundreds of millions of MD5 passwords per second. Remember to use passwords salts to make rainbow tables useless (otherwise it’s usually a matter of seconds before a password is cracked).
  Finally on storing hashed passwords, try to use multiple algorithms to store passwords – something like - sha1(sha1(sha1(password))) will be unnoticeable for the end user, but will make rainbow tables useless and increase the time needed to crack a password (and increase the likelihood an attacker will have to make a custom cracking module for their purpose).

And thanks to Sauj for fixing my grammar :)

Update: fixed some errors - I didn't try to go over what happened in every detail, I wanted us to think about "vulnerabilities" that have been exploited here.

--
Bojan
INFIGO IS