Special Anatomy of an Attack Or Layered Security Failure

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

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

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

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.

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

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

Damage Web site defaced. Some 68,000 s 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

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

CMS issues Using a 3 rd 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.

URL Used eNav=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

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

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

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!

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.

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)

Social Engineering ed 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 speaks-the-inside-story-of-the-hbgary-hack.ars/3http://arstechnica.com/tech-policy/news/2011/02/anonymous- speaks-the-inside-story-of-the-hbgary-hack.ars/3

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

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

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

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

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

Social Engineering Yes, someone is asking to reset password via . 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 as the verification

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

Security Experts Didn’t follow basic security best practices.

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