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.
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.
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, hbgaryfederal.com, 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 — http://www.hbgaryfederal.com/pages.php?pageNav=2&page=27 — 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.
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 hbgaryfederal.com 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.