Unmasked - Ars Technica [21]
-------------------------------------
From: Greg
To: Jussi
Subject: Re: need to ssh into rootkit
if i can squeeze out time maybe we can catch up.. ill be in germany for a little bit. anyway I can’t ssh into rootkit. you sure the ips still 65.74.181.141?
thanks
-------------------------------------
From: Jussi
To: Greg
Subject: Re: need to ssh into rootkit
does it work now?
-------------------------------------
From: Greg
To: Jussi
Subject: Re: need to ssh into rootkit
yes jussi thanks
did you reset the user greg or?
-------------------------------------
From: Jussi
To: Greg
Subject: Re: need to ssh into rootkit
nope. your account is named as hoglund
-------------------------------------
From: Greg
To: Jussi
Subject: Re: need to ssh into rootkit
yup im logged in thanks ill email you in a few, im backed up
thanks
Thanks indeed. 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.
Later on, Jussi did appear to notice something was up:
From: Jussi
To: Greg
Subject: Re: need to ssh into rootkit
did you open something running on high port?
As with the HBGary machine, this could have been avoided if keys had been used instead of passwords. But they weren’t. Rootkit.com was now compromised.
Standard practice
Once the username and password were known, defacing the site was easy. Log in as Greg, switch to root, and deface away! The attackers went one better than this, however: they dumped the user database for rootkit.com, listing the e-mail addresses and password hashes for everyone who’d ever registered on the site. And, as with the hbgaryfederal.com CMS system, the passwords were hashed with a single naive use of MD5, meaning that once again they were susceptible to rainbow table-based password cracking. So the crackable passwords were cracked, too.
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 being asked for them should have realized something was up.
The thing is, none of this is unusual. Quite the opposite. 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.
Nonetheless, their attack was highly effective, and it was well-executed. The desire was to cause trouble for HBGary, and that they did. Especially in the social engineering attack against Jussi, they used the right information in the right way to seem credible.
Most frustrating for HBGary must be the knowledge that they know what they did wrong, and they were perfectly aware of best practices; they just didn’t actually use them. Everybody knows you don’t use easy-to-crack passwords, but some employees did. Everybody knows you don’t re-use passwords, but some of them did. Everybody knows that you should patch servers to keep them free of known security flaws, but they didn’t.
And HBGary isn’t alone. Analysis of the passwords leaked from rootkit.com and Gawker shows that password re-use is extremely widespread, with something like 30 percent of users re-using their passwords. HBGary won’t be the last site to suffer from SQL injection, either, and people will continue to use password authentication for secure systems because it’s so much more convenient than key-based authentication.
So there are clearly two lessons