It's been an interesting year for those following information security news. We started the year with the Vodafone breach, one of the largest privacy breaches ever experienced within Australia.
Then RSA were compromised using a zero-day exploit off the back of a poorly crafted social engineering experiment. Sony promptly followed, and then a slew of others were hit by Lulzsec, Anonymous and similar hacktivist groups.
HBGary Federal was looted and pillaged in what can only be described as the worst "ownage" of any company I've ever seen or heard about (although the number of times Sony was owned should be humiliating).
The list this year grows long and large, and these are only a few of the bigger examples.
Looking at these breaches, I think it is a useful exercise to examine how they were attacked, and how they might have prevented it. In most instances, the attacks could have been avoided with a little consideration.
- SQL Injection
The attacks against Sony were found to be caused by SQL injection vulnerabilities on most of their websites. As the attackers pointed out, such vulnerabilities could be found using automated software, and because these could be conducted blind, it suggests that that Sony never conducted any penetration testing of their sites.
The foothold Anonymous held on the HBGary Federal network was also via SQL injection. Without this vulnerability, the HBGary Federal hack may have never been possible.
- Sloppy Password Practises
Weak passwords are an open invitation to hackers and pen-testers alike. A weak password can be guessed or brute-forced. Password hashes for weak passwords can easily be determined using rainbow tables. If those passwords are known and used on other systems, an attacker can leapfrog from host to host, application to application and pillage an entire network.
The HBGary Federal scandal was a remarkable example of how bad password re-use can be. Anonymous gained access to most of HBGary Federal's infrastructure via staff accounts on websites like LinkedIn and Twitter. Likewise, sharing passwords was ultimately, what led to the Vodafone privacy scandal as well.
- Social Engineering
It's almost impossible to develop a strategy for managing social engineering. Skilled attackers can target specific individuals within an organisation and tailor their attack to the intended victim. The RSA attack was triggered by deceiving RSA staff into opening an email purportedly containing pay details of RSA staff in an Excel spreadsheet, which contained the exploit. While stopping zero-day exploits are virtually impossible, I will suggest that social engineering attacks are a far more likely scenario everyone should work to prevent.
Likewise, a system administrator for rootkit.com was tricked into providing the root password which resulted in rootkit.com being compromised. Detecting such attacks can be challenging, it often requires more than an ability to spot poor grammar and spelling, but it’s not impossible.
For any organisation serious about evaluating its existing security posture, conducting a penetration test that evaluates internal and external controls is crucial. Allowing testers to conduct social engineering attacks should also be encouraged. Attackers gunning after your network will not be constrained — why would you try to constrain your testers? Broadly scoped tests give businesses the best bang-for-buck. And all of the attacks detailed hear could have been identified by any moderately skilled penetration tester in advance.
While many IT Security Managers and CSOs often fear the findings, they should be viewed as an annual health check and accepted as part of good governance. After all, if a serious vulnerability in your network can be described as cancerous, when would you rather find out? Early days when you can fix it, or at the last minute on the front page news, after an attacker has found it for you?
My next article, I will explore mitigating defenses against these attacks in more detail.
Follow @CSO_Australia and sign up to the CSO Australia newsletter.