Unless youve been living under a stone for last couple of weeks, you heard about the HBGary Federal hack. Seeing everything that was published about this probably make every security professional think for at least a second: Could this happen to me too?.
As most details about how the attack was actually carried out were published already (for example, see http://arstechnica.com/tech-policy/news/2011/02/anonymous-speaks-the-inside-story-of-the-hbgary-hack.ars) we can now look at all exploited vulnerabilities.
SQL injection on a public web site
Im sure that everyone who has done at least a little bit about security of web applications heard about SQL injection. SQL injection vulnerabilities (or general injection vulnerabilities) are at the #1 place of OWASP top ten vulnerabilities for 2010.
A lot of web applications are vulnerable to SQL injection so one must be very careful when picking a web application for your web site. HBGary unfortunately had a vulnerable web application which allowed attackers to retrieve information directly from the backend database this information included MD5 hashes of passwords of users that had access to the administration web interface.
Ill get back to MD5s later, lets stick with the web application for now. Successfully cracking one of the passwords would allow attackers to modify the web page (since it was a CMS). While this is bad (especially for reputation of a security company), it is still not as bad as things that happened later.
Also, according to the information that was posted, the SQL injection in the application was really simple I wouldnt be surprised if the attackers used a powerful tool such as sqlmap, which should be able to exploit this.
Using same (weak) password for multiple applications
Now this turned out to be a major issue. After the attackers cracked the password, they (logically) tried it on all other applications/sites. And it turned out that the same password was valid for e-mail, as well as other applications such as Twitter and Linkedin.
Since we all depend on e-mail for daily communication, it is obvious how the attackers took over the initiative at this point they were able to read HBGarys CEOs e-mails and even send them pretending to be him.
After carefully checking individuals that he was sending e-mails to, the attackers decided to use social engineering to attack one of the system administrators an obvious weak spot since he holds all the keys to the kingdom.
And this social engineering attack was what impressed me the most (the SQL injection was really simple) the attackers sent a carefully crafted e-mail, asking the administrator to open SSH on a weird port and set the root password to something he knows.
Could this happen in your company? I hope not all of us, while doing various consulting gigs, such as ISO 27001 and similar, always stress out that all changes must be approved and documented. However, when a CEO asks your administrator to do something, would he do that? Something to think about.
When the administrator opened SSH and changed the password, the game was over. The attackers had full access to the system and they downloaded e-mail backups and all other things weve been reading about for last couple of weeks.
So what can we learn from this hack?
A lot of things that we already preach (or should be preaching):
Do not use same passwords for multiple applications/sites. A lot of free, good utilities, such as Password Safe exist that will allow you to automatically generate strong passwords and store them in an encrypted key chain.
No matter if your company is big or small, you should have change management processes that require all changes to be approved by appropriate personnel. While a CEO can request your administrator to open a port on the firewall, really the security person in charge should approve that. If you dont have multiple roles for this then make sure that appropriate authentication is in place i.e. verifying such critical requests through other channels.
You should regularly test your web applications not only external, but also internal. While this does not guarantee that you will identify and eliminate all security vulnerabilities, it will certainly raise the overall security.
Encrypt your backups and think twice if you need all those e-mails at one place. Gmail is certainly attractive for storing years of e-mails and searching through them quickly, but imagine what would happen if someone gets access to all your e-mail.
When were at encryption encrypt sensitive e-mails too. While it is a nuisance, it can save the day and PGP is not that hard to use. There are downsides, of course, so you should balance between usability and security.
If you are a web application developer, and have a need to store (hashed) user passwords remember that algorithms such as MD5 were built for speed! By using todays GPUs, it is possible to crack hundreds of millions of MD5 passwords per second. Besides this, remember to salt the passwords to make rainbow tables useless (otherwise its usually a matter of seconds).
Finally, when talking about storing hashed passwords, try to use multiple algorithms to store passwords something like sha1(sha1(sha1(password))) will still be unnoticeable for your applications users and at the same time you not only made rainbow tables useless but increased time need for cracking as well (and the attacker will have to make a custom cracking module for his program).
–
Bojan
INFIGO IS
(c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
