The Lessons We Should All Relearn From HBGary

Ars technica published a long (by Web standards) story yesterday about the hacking of HBGary by Anonymous. It is absolutely, positively, must-read information for all beginner Web developers — for that matter, for experienced Web developers, too.

For those unfamiliar with the story, HBGary is an information systems security consultancy. It’s not huge, but it’s been successful getting work with the federal government and several other companies.

But HBGary wanted to get bigger; to exploit the headlines and prove itself worthy of major government and corporate contracts. So HBGary hatched a couple of schemes.

One was to help Bank of America discredit WikiLeaks with a disinformation campaign and character assassinations. The other was to “unmask” the Anonymous hackers who set off several DDoS attacks against Visa, Bank of America, and others perceived as having harmed WikiLeaks.

Unfortunately, HBGary boss Aaron Barr decided to go public with his plans to expose the alleged hackers. So Anonymous decided to attack HBGary, and the rest are our lessons for the day.

An aside on Anonymous: Ars technica does a nice job of explaining how Anonymous works, but I want to be even clearer.

The press, and people like Barr, often speak about Anonymous as though it is a fixed group of specific people, led in a traditional, top-down manner. In fact, Anonymous is the exact opposite of such a structure.

Anonymous is a convenient term to apply to online flash mobs that serve grassroots efforts, the way tsunami is a convenient way to label a series of big waves caused by seismic events.

No two tsunamis are caused by the same event; none maintain a constant state as they are created, travel and make landfall; and none are exactly like one before. The same is true of Anonymous: Who is in any given Anonymous undertaking and who is leading that effort is almost never the same for any two events, and usually is constantly changing during any one undertaking.

An Anonymous effort is never dictated; the surest way to disinterest Anonymous is by asking for a personal army. Anonymous lives by hive mind, not by imposed structure. Whatever Anonymous does and however effective that effort proves is entirely subject to the whim of the moment keeping a sufficient number of individuals interested in its outcome.

So any time you hear someone talking about “Anonymous” as though it was a fixed group of purposeful people, that’s someone who doesn’t understand Anonymous at all.

Lesson 1: Protect Against SQL Injection

HBGary’s subsidiary Web side,, used a custom content management system. The authors of that system failed to property sanitize navigation query string variables, allowing for a SQL injection attack.

Specifically, the attackers grabbed the user database from the CMS—the list of usernames, e-mail addresses, and password hashes for the HBGary employees authorized to make changes to the CMS.

Clearly, as ars technica notes, there was no unit testing of this Web site.

Even the most remedial system that involves a database should employ some sort of input sanitation. It’s doubly unforgivable in this case because the query string variables that were exploited — — clearly were supposed to always be integers.

As my colleague Greg Howe says, it’s important to learn how to protect your code against SQL injection. The best advice I’ve found about armoring against SQL attacks is in the PHP documentation’s overview of SQL injection, under “Avoiding techniques.”

I especially expound the very first point: Always connect to the database server with a bare minimum of permissions necessary. Make read-only and read-write only DB users and employ only the ones you need. Better yet, create stored procedures to handle your DB tasks, and limit access to specific users. If your Web host only lets you have one DB user, find a better Web host. Period.

Lesson 2: Don’t Recycle Passwords

A while back I reposted a great xkcd cartoon that notes the real issue in password security isn’t entropy (e.g., the password getting stale), it’s reuse (e.g., the same password being used for everything). HBGary found that out the hard way.

Neither Aaron nor Ted followed best practices. Instead, they used the same password in a whole bunch of different places, including e-mail, Twitter accounts, and LinkedIn. For both men, the passwords allowed retrieval of e-mail. However, that was not all they revealed.

Like everyone else, I was this kind of lazy, too, until LastPass came along, which I now use for everything. I also like the color-coded PasswordCard noted at lifehacker, if you don’t trust LastPass.

Lesson 3: Use Complex Password Encryption Patterns

The reason Anonymous got those passwords was because the CMS developers simply applied an MD5 hash to the passwords it stored, without salting them, requiring complexity or using a multiple-step algorithm.

The result was that the downloaded passwords were highly susceptible to rainbow table-based attacks, performed using a rainbow table-based password cracking website. And so this is precisely what the attackers did; they used a rainbow table cracking tool to crack the CMS passwords.

An MD5 hash alone is nearly as useless as storing passwords in clear text; there are enough rainbow tables out there, and enough basic computational power available in the average desktop, to pretty much render a single hash pointless.

You have to at least salt a one-time MD5 hash. Better yet, use stronger crypto.

Ars technica is in love with using ssh to control access to *nix boxes, and in this case that seems like a workable solution. I can see where going “passwordless” seems like a great idea, but again, if one simply obfuscates a password a little bit and doesn’t use it in the same place twice, that should be more than sufficient.

Lesson 4: Keep Your Systems Patched

You can’t install a CMS and then ignore it, or never upgrade your PHP3 code. Patch your systems and fix your code when you know it’s not safe.

The only way they [hackers] can have some fun is to elevate privileges through exploiting a privilege escalation vulnerability. … By a stroke of luck, the HBGary system was vulnerable to just such a flaw. The error was published in October last year, conveniently with a full, working exploit. By November, most distributions had patches available, and there was no good reason to be running the exploitable code in February 2011.

Exploitation of this flaw gave the Anonymous attackers full access to HBGary’s system. It was then that they discovered many gigabytes of backups and research data, which they duly purged from the system.

Yes, there’s always a chance things will break if you install a patch or close a security hole. That is why God made sandbox servers: So you can test before deploying.

Lesson 5: Have Clear Security Procedures

Much of what Anonymous could accomplish was as a result of tricking Nokia employee Jussi Jaakonaho, who had access to HBGary’s systems, into opening up SSH access to a remote server, as well as “reminding” a person masquerading as Greg Hoglund, another HBGary executive.

To be fair to Jussi, the fake Greg appeared to know the root password and, well, the e-mails were coming from Greg’s own e-mail address. But over the course of a few e-mails it was clear that “Greg” had forgotten both his username and his password. And Jussi handed them to him on a platter.

I’m not suggesting that one turn every request for help into the Spanish Inquisition. Believe me, I’ve endured enough uptight network admins having conniptions over a simple request for a password reminder or temporary, elevated privileges to last me a lifetime.

I am saying, have a clear and sensible protocol for requesting new passwords, unusual access and the like, and make sure everyone understands and follows that policy.

Lesson 6: Nothing Is Private

If you write it down, photograph or otherwise record it, assume it will eventually be known to everyone, everywhere.

There are 50,000 e-mails in the pile that Anonymous seized, and some of the handful that have been sifted are quite damning.

Take, as example, a message the Daily Kos dredged up, revealing a sockpuppet management system:

(F)or a defense contractor with ties to the federal government, Hunton & Williams, DOD, NSA, and the CIA – whose enemies are labor unions, progressive organizations, journalists, and progressive bloggers, a persona apparently goes far beyond creating a mere sockpuppet.

According to an embedded MS Word document found in one of the HB Gary emails, it involves creating an army of sockpuppets, with sophisticated “persona management” software that allows a small team of only a few people to appear to be many, while keeping the personas from accidentally cross-contaminating each other. Then, to top it off, the team can actually automate some functions so one persona can appear to be an entire Brooks Brothers riot online.

Who knows what dark trade secrets are yet to be revealed?

Lesson 7: It’s Not That They Are Smart, It’s That You Are Sloppy

The Anonymous hack was not exceptional: the hackers used standard, widely known techniques to break into systems, find as much information as possible, and use that information to compromise further systems. They didn’t have to, for example, use any non-public vulnerabilities or perform any carefully targeted social engineering. And because of their desire to cause significant public disruption, they did not have to go to any great lengths to hide their activity.

Enough said.


  1. It does not pay to mess with Anonymous, today.

    Legislative bodies worldwide may soon have their way, however, changing the nature of the tubes; a ‘taming of the wild west’ if you will, to the detriment of all except those who covet power.
    I stand with those Scandinavian communist bastidges who believe that a completely free and open web is the only way to move forward.
    I disconnected my television in 2004 on the grounds that I DETEST others’ attempts to think and deduce on my behalf; I don’t want to have to disconnect my tubes on those same grounds. Where will I go?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  • Check out the Commenting Guidelines before commenting, please!
  • Want to share code? Please put it into a GitHub Gist, CodePen or pastebin and link to that in your comment.
  • Just have a line or two of markup? Wrap them in an appropriate SyntaxHighlighter Evolved shortcode for your programming language, please!