HBGary hack: lessons learned

Published: 2011-02-22
Last Updated: 2011-02-22 15:31:37 UTC
by Bojan Zdrnja (Version: 1)
10 comment(s)

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.


Keywords: hbgary
10 comment(s)


How about these:

Why do you allow access to your content management system from some 4.3 billion IP addresses? VPN in or two factor the login with client certificates. (HBGary was hacked through their CMS.)

It's not always the main web site the attackers go after. Look at Heartland Payment Systems. You need to protect everything equally.

User name and password as the sole authentication mechanism is worthless. The only reason they are still used is because they're free. And you get the security you're paying for.

Their emails are now archived on a site using a Switzerland .ch domain. If you were one of their customers, your "private" communications are now public. Spear phishing, anyone?
Yep. I still don't know if it was right to search their database, but since HBGary isn't alerting their customers directly (yet?) I felt I had to know what might be exposed. All my contact info at my company is out there now. I think it's worth a look if you've used any of their products.

As for lessons learned: There are a lot of examples of "the human factor" allowing this breach to happen, but I think the most interesting is Barr's hubris. If he'd had a healthy level of paranoia preventing him showing his adversary his hand, would Anonymous have retaliated so severely?
I'm wondering more about the human factor. Was the CEO the type of person who would understand having to go through the proper procedures for such a change or was he the kind that would take offense at such a request?

If everyone EXCEPT the guy at the top has to follow the procedures, all you have to do is crack the account of the guy at the top.

As was done in that attack.

Because HBGary wasn't really about security, it probably was pretty low on the list. If any of the emails point us to their real revenue engine, it was surveillance and corporate/governmental astroturfing. And they believed their own PR engine to the point they spouted off and their bluff got called.
A page from my notebook:

As a fellow Information Security SME and owner of the Cybersecurity consulting firm Black & Berg, I can say that this attack on HBGary has raised some serious questions. We all need to take a closer look at our individual security postures and make the necessary adjustments to reflect the hostile environment that we currently find ourselves in.

Joe Black CISSP CISM NSA-4011 Security+
Certified Ethical Hacker
Christian In Action
A US citizen with the ability to obtain a Security Clearance
Senior Cybersecurity Advisor / CEO
Black & Berg Cybersecurity Consulting, LLC
W: (402) 608-1783
Stop | Think | Connect
One point about the social engineering attack...yes it should never have happened but the red flag and the point at which I would have hoped the attack should have been detected/failed was where, having requested a password reset, "Greg" asked what his user name was again...
arstechnica describes a classic penetration in the article. SQL inject, password/hash cracking w/rainbow tables, pivoting to subsequent exploitable target systems, and even some sneaky social engineering, and finally! exfil and site defacing. This could have been a white paper. The Anonymous hacker should submit it for his GPEN Gold. :o)
When people ask me what I do for a living, I tell them:

1. I get paid to sit in meetings.

2. I learn about bad things that happened to other companies and try to keep them from happening to us.

Rhetorical question: If we each substituted our company's name for "HBGary", how nervous would we be? And what can we do about it TODAY?
My thoughts:

1. The CMS should have had a staging server where data was entered before putting on a public website. The user tables should not have been replicated to the live website's database.

2. A Single Sign On (SSO) type solution that passed off authentication to a Kerberos, LDAP or AD server would have kept password hashes out of the public website database, while still maintaining the usability users were expecting.
The CMS shouldn't have been publicly accessible in the first place. What bothers me the most is that you linked the story from Ars Technica where Anonymous tells how the hack went and then you manage to understand it wrong (assuming it got facts straight).

www.rootkit.com social engineering didn't provide "the keys to the kingdom", it is a totally different site not related or connected to HBGary or HBGary Federal systems. Only thing in common was that Greg owns it.

It wasn't used to store the data you refer to, the data was on the support site and the email service which the Anonymous got access to.

Diary Archives