HBGary Incident – Anatomy Of The Attack

February 22, 2011
  1. CEO Aaron Barr decided to unmask who he thought was behind the leadership of attacks against MasterCard, Visa, and other perceived enemies of WikiLeaks.
  2. Before unmasking this individual, Barr spilled the beans and communicated his intended actions to this person.
  3. A custom written CMS application (http://www.hbgaryfederal.com) suffered from SQL injection, SQL injection in a URL parameter no less. This site is down now but the same exact, vulnerable, parameters are visible in Google queries (https://encrypted.google.com/search?q=inurl:http://www.hbgaryfederal.com/pages.php%3F&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a)
  4. This was exploited and the usernames/passwords were dumped from the users table.
  5. The passwords were hashed with MD5 but not salted so simple rainbow tables cracked some of the passwords.
  6. One non C-level accounts cracked had SSH non-root access to support.hbgary.com.
    1. This was elevated to root access using a known local privilege-escalation vulnerability for which written exploits were already available. Root was gained on support.hbgary.com.
    2. Gigabytes of support and research-related information was removed promptly.
  7. As is typical, two of the passwords cracked were the CEO’s and COO’s. Executives often have a rather demanding way of being exempted from password complexity policies =). To be specific, these passwords were six lower-case letters and two numbers.
    1. Again, as is typical, these passwords were used all over the place including in Google, Twitter, and LinkedIn. Now the attackers had access to the CMS plus other applications like email.
    2. The CEO’s credentials became of use when it was noticed he was the administrator for the company’s Google Apps Mail services and that access to other employees mail accounts could easily be gained by resetting their passwords. This was done to Greg Hoglund’s mail account.
    3. Greg Hoglund’s account disclosed two potential root account passwords to a rootkit.com server as well as the fact that a Nokia employee had SSH access to that server. Since SSH as root wasn’t allowed to the server, as it shouldn’t be, the attackers still needed a non-root user to SSH with and then elevate to root. That’s where some SMTP-based social engineering comes in.
    4. The correspondence between the attacker impersonating “Greg Hoglund” and the Nokia employee with SSH pretty much tells the rest of the story.

So I guess the morals of the story are….. the same morals you’d learn from a lot of security incidents…. the same thing the security community, HBGary included, has been touting:

 

  1. Assess your web applications, especially those exposed publicly. SQL injection is a serious flaw and there is no excuse in 2011 to have a single instance of it exposed to the internet.
  2. Hash your passwords column but salt the values as well.
  3. Patch your systems, especially those that are public. Even local privilege escalation vulnerabilities that don’t seem like a threat, can be a threat.
  4. Enforce the use of strong password complexity and change requirements, even, well, especially for V-I-Ps.
  5. Don’t reuse your passwords across organizations, applications, etc. Just don’t reuse them. Don’t iterate through your 5 passwords, add a number by 9 to the end, or use some ROT13 scheme that you think is going to protect one password from an attacker who owns another.
  6. Ironically, hosting mail in the “cloud” with Google, didn’t play a part in this incident. It could have been any mail system. Credentials are credentials. Reuse is Reuse. I guess it at least, by using a publicly accessible interface, allowed the attackers to skip having to visit an Exchange Server and open the MMC up.

As always, I’m not bashing on anyone. The folks at rootkit.com are no slouches, no doubt. Everyone has a vulnerability in their closet but there are lessons to be learned from candor where there is any these days.