HBGary hack: lessons learned
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
Comments
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?
JJ
Feb 22nd 2011
1 decade ago
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?
sb
Feb 22nd 2011
1 decade ago
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.
Brandioch Conner
Feb 22nd 2011
1 decade ago
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.
Sean
Feb 22nd 2011
1 decade ago
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
DoD CAGE Code 5ZUU4
http://about.me/JosephBlack
Joe Black
Feb 22nd 2011
1 decade ago
Barry
Feb 23rd 2011
1 decade ago
FT
Feb 23rd 2011
1 decade ago
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?
JJ
Feb 23rd 2011
1 decade ago
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.
Nathan Christiansen
Feb 23rd 2011
1 decade ago
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.
mru
Feb 24th 2011
1 decade ago