Anatomy of an Attack: Lessons in Cybersecurity Failure

1. Special Anatomy of an Attack Or Layered Security Failure

2. Some Background • In case you missed the news in the in 2011 • Anonymous, an decentralized online community acting anonymously in a coordinated manner • Orchestrated Operation Payback, Operation Avenge Assange, and many others

3. Background • Wikileaks support by creating Distributed Denial of Service attack: • Amazon, • PayPal, • MasterCard, • Visa • and the Swiss bank PostFinance

4. HBGary Federal • Security firm had been researching the group Anonymous • Thought they had identified many of the responsible people in Anonymous • On Feb 5-6, 2011, CEO of HBGary Federal, Aaron Barr announces they have this info, but would not hand over to police. • Goal: to reveal findings at a conference

5. Timeline of Activity • Aaron Barr had his work written about in Financial Times on Feb 4. • Strange network traffic was pounding HBGary Federal • Was finishing presentation slides and since the story was in print, confronted who Barr believed to be “CommanderX” on Facebook. Without using an alias.

6. Motives For Confronting • Mitigate the current attack on his company • Try to portray himself as equal to Anonymous • Not at all wise to do to a group like Anonymous

7. Anonymous Reaction • Predictable: • Attack. • Expose as much as possible • When Barr went into an IRC to try to continue “reasoning” attacks escalated.

8. Damage • Web site defaced. • Some 68,000 emails were stolen from HBGary Federal and posted to BitTorrent. • Compromised Barr’s Twitter account • Deleted over 1TB of backups • Claimed to remote wipe Barr’s iPad

9. Attack avenues • SQL Vulnerability on website • Used a 3rd party custom CMS (content management system) • CMS had multiple vulnerabilities • Social engineering to gather key data • Reused passwords!!!!

10. CMS issues • Using a 3rd party, custom CMS, you don’t get other users reviewing the code, like open source would have. • Contained a SQL-injection vulnerability • Detectable by scanning software.

11. URL Used http://www.hbgaryfederal.com/pages.php?pageNav=2&page=27 • The values of either 2 or 27 were not handled by the CMS correctly • Allowed retrieval of data from the database • Specifically: the user database from the CMS in order to glean userid/passwords

12. User Database • Contained hashed passwords • Unsalted MD5 • Susceptible to Rainbow table attacks - provided they are not long, complex passwords • They were not • 2 passwords with high access were weak: 6 lower case chars and 2 numbers

13. Compound the Problem • These two passwords were re-used all over. • Email • Twitter • LinkdIn • SSH accounts on a Linux Support system

14. One SSH Password • Unfortunately, (for the attacker) the SSH account/password did not have elevated privileges on the Linux support system they found. • However, it had an privilege escalation vulnerability that should have been patched months previously • Full access now was available to Anonymous – and they purged data!

15. Barr’s Account/Password • Even more valuable • Company used Google Apps/GMail • Barr’s account on Google was also the Administrator for the entire Google Apps/GMail. • Including resetting passwords on other Gmail accounts.

16. Reset Password • Access to Greg Hoglund’s mail (HBGary employee and operator of rootkit.com site for analyzing rootkits). • Found the root password to rootkit.com • Unfortunately, you have use a non-root account to SSH, which they didn’t have • (direct ssh to root is prohibited on most Linux systems now)

17. Social Engineering • Emailed a security person pretending to be Greg to allow firewall access and reset a password to gain access. • Tricked the security person into giving the local account name with a new password. • Access now theirs to rootkit.com • http://arstechnica.com/tech-policy/news/2011/02/anonymous-speaks-the-inside-story-of-the-hbgary-hack.ars/3

18. Next Steps • Logged in as local account on rootkit.com • Switched to root • Copied the user database, password hashes, email accounts of all registered users of rootkit.com • Defaced the web site.

19. Rootkit.com Hashes • Unsalted MD5 hashes, once again. • One rainbow table search later, more accounts to use. • No information available as to whether any of this data has been used…or exposed

20. In Summary • Vulnerable CMS/SQL injection • Didn’t follow security best practices for security review of CMS software. • Didn’t scan the software for vulnerabilities before going to production • Use of open source would have been better, but not guaranteed. • Picking a reputable/proven firm: best

21. Passwords • Complexity lacking. • Need to use strong passphrases • Reuse • Need to use DIFFERENT passphrases for different accounts • Servers allow basic password authentication • Use of private key for SSH

22. Systems Not Patched • Even if it is a local account privilege elevation: PATCH! • As a security firm, this is just inexcusable.

23. Social Engineering • Yes, someone is asking to reset password via email. It happens. The security person should have had some checks to do: • Verify. Call him back on his established phone number • If that’s not available, have the person prove identity other ways • Not done. Simply accepted the email as the verification

24. Social Engineering (cont.) • Use of Personal Certificates on email • Send back only encrypted mail • Would have forced attacker to try and find the certificate • Many other ideas exist here…

25. Security Experts • Didn’t follow basic security best practices.

26. References • http://arstechnica.com/tech-policy/news/2011/02/anonymous-speaks-the-inside-story-of-the-hbgary-hack.ars • http://en.wikipedia.org/wiki/Greg_Hoglund • And various other links off of these main pages