Website errors and poor authentication processes appear to be the biggest technical lessons learned from the HBGary Federal hacking fiasco, according to Bojan Zdrnja of Croatia-based security consultancy INfigo.
Writing in the SANS Institute’s Internet Storm Center Diary, Zdrnja highlights some common security mistakes made by HBGary Federal that his team frequently come across during penetration tests. These are mistakes that are frequently mentioned by security experts, repeatedly mentioned in reports in nearly every security media outlet and highlighted by security education firms.
SQL injection vulnerabilities:
“HBGary unfortunately had a vulnerable Web application which allowed attackers to retrieve information directly from the back-end database – this information included MD5 hashes of passwords of users, that had access to the administration web interface.”
SearchSecurity has a SQL injection protection Learning Guide on how to protect your website from SQL injection errors.
Manual inspection has given way to some pretty popular automated tools that can detect these common errors (Web application scanners). In addition automated toolkits have made it easy for cybercriminals to find and exploit SQL injection errors. There are security technologies that can defend against these automated attacks – a properly deployed and tuned Web application firewall (WAF) would do the trick. I say properly deployed, because I hear about many companies installing a WAF for PCI compliance, but failing to really use it for its intended purpose.
HBGary Federal used the same passwords to access different systems. This made it easier for members of the “Anonymous” group to access connected systems and ultimately steal email messages and other files. In addition, the passwords were used for other – outside – social networks, such as Twitter and LinkedIN.
There are a plethora of two-factor authentication options, one time password tokens and other methods that can be used by firms to keep systems locked down and make it more difficult for fraudsters to access systems.
While it’s understandable that some firms don’t need the added secure password measures and wouldn’t want to disrupt business processes with them, it’s painfully troubling that firms that work with government agencies or deal with other sensitive data clearly aren’t deploying these authentication measures. Safeguarding intellectual property – the lifeblood of every company – begins with the most basic security steps. Requiring some kind of hardened password protection to gain access to critical systems should be part of the foundation of any security program.
“The attackers used social engineering to attack a system administrator of another system (rootkit dot com) – an obvious weak spot since he/she holds “all the keys to the kingdom” … 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…”
That kind of change management, according to Zdrnja, is a big NO NO, but is probably all too common at enterprises.
When the administrator opened SSH and changed the password, it was game over.