Tag Archives: HBGary

Password Security, How Does It Work?

I’m sure that the HBGary executives were thinking the same thing most of us do: “I’m kind of busy right now, and I’ll change it to something stronger when I have a little more time.” I’ve done that more times than I care to think about, as I noted in December when the Gawker story broke. Since then, I’ve become a little bit better at resisting the temptation to slap a quick and dirty password on an account. But I’m still doing it from time to time, as I realized the last time I ordered a cable from my new favorite vendor for such things.

Long ago, I came up with a system for creating and remembering unique credentials for sites, only to be stymied by sites that refused to allow non-alphanumeric characters in either the password or username field.  Even now, there’s a surprising number of sites that refuse to accept  the plus sign in a gmail address (ex: myemail+salt@gmail.com) which is completely legitimate!

KeePass and similar utilities are a great help in this regard.

via Password Security, How Does It Work? – Security – News & Reviews – eWeek.com.

Anonymous speaks: the inside story of the HBGary hack

It’s been very interesting watching the HBGary vs Anonymous event unravel in such a public way, with such well-known hacker methodology used to compromise the systems of security specialists.  Anonymous uses SQL injection on HBGary’s public CMS to find a few usernames and passwords, and with a non-privileged user account they were able to compromise an otherwise fairly secure Linux system that was behind on its patches:

The only way they can have some fun is to elevate privileges through exploiting a privilege escalation vulnerability. These crop up from time to time and generally exploit flaws in the operating system kernel or its system libraries to trick it into giving the user more access to the system than should be allowed. 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.

Aaron’s password yielded even more fruit. HBGary used Google Apps for its e-mail services, and for both Aaron and Ted, the password cracking provided access to their mail. But Aaron was no mere user of Google Apps: his account was also the administrator of the company’s mail. With his higher access, he could reset the passwords of any mailbox and hence gain access to all the company’s mail—not just his own. It’s this capability that yielded access to Greg Hoglund’s mail.

PCI DSS requires that patches be installed monthly.  In addition, could Google Apps’ two-factor authentication have helped prevent that portion of the attack?

Regardless:

So what do we have in total? A Web application with SQL injection flaws and insecure passwords. Passwords that were badly chosen. Passwords that were reused. Servers that allowed password-based authentication. Systems that weren’t patched. And an astonishing willingness to hand out credentials over e-mail, even when the person asking for them should have realized something was up.

    It’s not enough to know security if you don’t actually implement it.

    via Anonymous speaks: the inside story of the HBGary hack.