Wednesday, February 16, 2011

Lessons to Learn From the HBGary Federal Hack

Via (Naked Security Blog) -

The Anonymous attack on HBGary may have amused some who enjoyed the sight of a security firm left embarrassed and exposed, but it should send a shiver down the spine of any IT administrator responsible for securing their own company.

Because can you honestly put your hand on your heart and say a hack like the one against HBGary couldn't happen at your organisation too?

As Ars Technica explains, a weakness in a third-party CMS product used by HBGary's website allowed Anonymous hackers to steal passwords that employees used to update the webpages.

Unfortunately they were passwords that weren't encrypted strongly enough, and were possible to crack with a rainbow-table based attack. Amongst those exposed were CEO Aaron Barr and COO Ted Vera.

Worse still, it appears that Aaron Barr and Ted Vera were using the same passwords for their Twitter and LinkedIn accounts, and even for an account which administered the entire company's email.

By exploiting software vulnerabilities, poor passwords and even some tried-and-trusted social engineering it was trivial for the hackers to steal the entire company's email and deface its website.


According to Anonymous, here are the details on the rather simple SQLi that was found in HBGary's homepage (in the CMS used to run it).
HBGary Federal's website,, was powered by a content management system (CMS)....Unfortunately for HBGary, this third-party CMS was poorly written. In fact, it had what can only be described as a pretty gaping bug in it. A standard, off-the-shelf CMS would be no panacea in this regard—security flaws crop up in all of them from time to time—but it would have the advantage of many thousands of users and regular bugfixes, resulting in a much lesser chance of extant security flaws.

The custom solution on HBGary's site, alas, appeared to lack this kind of support. And if HBGary conducted any kind of vulnerability assessment of the software—which is, after all, one of the services the company offers—then its assessment overlooked a substantial flaw. The CMS was susceptible to a kind of attack called SQL injection.

The exact URL used to break into was The URL has two parameters named pageNav and page, set to the values 2 and 27, respectively. One or other or both of these was handled incorrectly by the CMS, allowing the hackers to retrieve data from the database that they shouldn't have been able to get.
Given the simple nature of the injection, I would assume even free tools (like Paros Attack Proxy or OWASP Zed Proxy) would have discovered this SQLi flaw.

After the discovery of the SQLi flaw, a series well-known techniques and hacks (e.g. cracking MD5, re-used passwords, excessive privilege, unpatched local priivielge esclation vulnerability, informed and targeted SE attack) were used by Anonymous to dig deeper and gather more and more information - which they turned around and used to get more information (SE attack).

In the end, the author of the Ars Techica article says it best...
So there are clearly two lessons to be learned here. The first is that the standard advice is good advice. If all best practices had been followed then none of this would have happened. Even if the SQL injection error was still present, it wouldn't have caused the cascade of failures that followed.

The second lesson, however, is that the standard advice isn't good enough. Even recognized security experts who should know better won't follow it. What hope does that leave for the rest of us?

No comments:

Post a Comment