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 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

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!!!!

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.

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

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.– Email– 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

• 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

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.

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 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

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…

Security Experts

• Didn’t follow basic security best practices.

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