The Fail of HBGary

HBGary Federal - FAIL
Analysis of the Hacks that took down a corporation
Created by Matthew Benton
matthew.r.benton@gmail.com

http://arstechnica.com/tech-policy/news/2011/02/anonymous-speaks-the-inside-story-of-the-hbgary-hack.ars/
- Great article from an interview with members of anonymous. Most other articles will point to or reference this article.
http://watchguardsecuritycenter.com/2011/02/22/the-hbgary-vs-anonymous-saga-what-can-we-learn/
http://isc.sans.edu/diary/HBGary+hack+lessons+learned/10438
http://www.lightbluetouchpaper.org/2011/02/09/measuring-password-re-use-empirically/
http://www.pcworld.com/businesscenter/article/221504/8_security_tips_from_the_hbgary_hack.html
http://en.wikipedia.org/wiki
- searched for simple definitions
References

Aaron Barr, CEO of HBGary Federal Inc, claimed to have information pertaining to the actual members and leaders of Anonymous
Anonymous is a loose coalition of internet ‘hacktivist’, who are using hacking as a form of protest
Anonymous is the group that supported wikileaks
They are regarded by some as a cyber terrorist group with no clear leadership
Barr had made announcements that he was going to sell this information
Overview according to Colbert
http://www.colbertnation.com/the-colbert-report-videos/375428/february-24-2011/corporate-hacker-tries-to-take-down-wikileaks
Greg Hoglund – Founder and CEO of HBGary. Security research that ran a website called rootkit.com
HBGary Federal was a partially-owned subsidiary of HBGary.
Background Information

SQL (Structured Query Language) Injection on a poorly coded and untested custom Content Management System (CMS)
Cracking attack on badly encrypted or chosen passwords
Weak passwords used by high value targets
Rampant reuse of passwords by high value targets (access to other systems and accounts)
Elevation of privilege attack on an unpatched system
Information gathering through emails
Social Engineering attack to gather additional information to go after rootkit.com
The Attack (Basics)

hbgaryfederal.com was powered by a custom built content management system (CMS)
A CMS is “a system designed to simplify the publication of web content to web sites and mobile devices..”
The custom CMS was poorly written and had a bug that allowed for SQL Injection
Vulnerability most likely would have been discovered by any vulnerability test against the software (services HBGary offered)
Common for CMSs is to store the data in an SQL database. The site makes queries and retrieves the data from the database and provides the information form the user.
Some queries are fixed, others use parameters (variables) that allow the user to send values to the database to retrieve information.
An example – a query to retrieve a specific article will send a parameter with a corresponding ID number to the database. The database will return the information requested in the parameter
SQL injection can occur when specially crafted statements or values can be sent to the database and are unexpectedly executed.
SQL injection is possible when user input is not validated prior to being sent to the database, resulting in an unexpected results.
SQL Injection of hbgaryfederal.com

Exact URL used for the injection:
http://www.hbgaryfederal.com/pages.php?pageNav=2&page=27
The two parameters are pageNav and page
Values were set to 2 and 27 respectively
The CMS incorrectly handled the parameters allowing the hackers to retrieve data from the database
Hackers got the user database from the CMS (usernames, e-mail addresses, and password hashes) for employees that could make changes to the CMS
SQL Injection of hbgaryfederal.com

Hashes are a common way to store passwords so that they are not plain readable
Hash Function – designed to be a one way process (defined process or mathematical function) which will take a variable input and yield a output from which the original input can’t be deciphered.
Common hashes are MD5 and SHA-1
The MD5 hash of “password” is 5f4dcc3b5aa765d61d8327deb882cf99
Hashes can be created with a SALT – a random psuedo value added to make the hash harder to crack.
Password Hashes

Hashes are design to not go backwards – the password hash value can not be mathematically converted back into the password
Two common methods - Brute Force or Rainbow Tables
Brute Force
Try every possible password, hash that password and then compare to the stolen password hash
Takes a lot of resources and time
Rainbow Tables
Large precomputed tables full of values and their hashes. All a hacker needs to do is then compare the hash to the hashes available. If a match then password available.
Each table only spans a given “pattern” – ie, 1-8 characters with lower case values and numbers or 1-12 characters and special characters
Larger the pattern and the possible characters the larger the table must be.
It is believed at this time, a 14 or more characters with a full range of 95 typeable characters is unlikely to be found in a full rainbow table.
Cracking the Passwords

Hackers used a rainbow table with a password cracking tool and were able to crack some of the CMS passwords
Two employees passwords cracked – CEO Aaron Barr and COO Ted Vera
Very simple passwords
Each was just six lower case letters and two numbers
These compromised accounts would only allow the hackers to deface or run a muck on the CMS.
Of course the problems did not stop there…
Cracked CMS passwords

So many passwords I have to know and remember, what do I do? Ill just use the same one everywhere…Fail!
Barr and Vera used these same simple passwords on many systems, ie. Their LinkedIn, their Twitter accounts, etc
Two other systems that had password reused on were their support.hbgary.com site as well their full GoogleApps Email service
Password Reuse

Linux machine that housed gigabytes of backups and research data
The machine could be accessed with SSH (Secure Shell)
SSH is a network protocol that uses a secure channel to remotely administer or allow the exchange of data between two networked devices
The SSH connection authenticated using only a password and Vera’s was the same previously used password
Vera was only a regular non-superuser. Had limited rights and could not do a lot to the machine
Hackers then decided to get them more rights
Password Reuse on hbgary.support.com

Hackers want to be able to operate as an administrator (Superuser) so they an execute and do whatever they want on the machine.
So they look to exploit a flaw that will allow them to elevate their privileges.
These exploits appear time to time and generally exploit flaws in the operating system kernel or its system libraries to trick the system to giving the current user more access or rights then should be allowed
This system was vulnerable to CVE-2010-3847
The error was published in October in the previous year and most distributions had patches available since November.
The system unpatched allowed for the exploit to occur and gave the hackers elevated credentials.
Hackers purged from the system gigabytes of backups and research data
Privilege Escalation of the Account

HBGary used Google Apps for its email services
Google Apps email services is basically a company that establishes their email services through gmail for their company. Users can access their company account anywhere and less overhead for company to manage.
Both previously cracked passwords allowed access to Vera and Barr’s email
Barr’s account was the administrator of the company’s mail
The administrator account had the capabilities to reset any password of any employee’s email account
Hackers were able to grab all of the Company’s email
The hackers posted the contents of the emails on the web.
Password Reuse on Email Services

Hackers searched the emails for additional information that might lead to more exploitation
Hoglund’s email had reference to two possible root access passwords for his rootkit.com
88j4bb3rw0cky88 or 88Scr3am3r88
Email also referenced another individual that had root access to the rootkit.com machine
JussiJaakonaho - “Chief Security Specialist” at Nokia
This was not enough information to vandalize the site, more information was needed
Needed a regular user account to log-in with
Standard security practice with direct SSH access is disabled for the root account (the passwords found in the email)
Greg Hoglund’s email

Hackers used the already compromised email account (Greg) to email Jussi to gather information
Hackers posed as Hoglund, requesting assistance from his colleague to let him gain access to his site rootkit.com
Confirmed which password was the correct password as well as try to gain validity of who was sending the emails
Got the regular user account password reset
Got a port open through the firewall and confirmed the IP of the system
Then got the username account
To be fair to Jussi – the fake Hoglund was sending email from the legitimate email account and did know the root password. Still apparent fake Hoglunddidn’t know his username or password
Hackers then logged in as Greg, switched to root, and defaced site. And dumped the user database (listings of email addresses and passwords from non-hbgary employees)
Social Engineering for Info

High Risk
Web application vulnerable to SQL injection
Insecure of badly chosen passwords
Password reuse
Unpatched/Up-to-date systems
Employees vulnerable to Social Engineering
Medium risk
Use of only basic MD5 hashing, no salting or iterative hashing
Servers allowed only password-based authentication
Security Flaw Findings

Test your web applications for vulnerabilities
Run vulnerability scanners or SQL injection tools against them
OWASP has SQL Injection as the #1 security risk for web applications
Consider using an off-the-shelf CMS. This will allow for more users reviewing or discovering errors and making changes to keep the system up-to-date
Use a Web Application Firewall
Determine if the CMS needs to be world wide accessible. Through firewall limit what IPs can actual access the site
Web Application Recommendation

Force users to create complex or even longer passwords
Consider using programs such as password vault, keychain or other free utilities that help securely store your passwords if you can not remember
Don’t Reuse
Risk management – if too many passwords to remember, at least ensure high value targets have completely separate and unique passwords (work, banking, etc)
Weak Passwords and Reuse

A great article did an analysis of weak passwords and password reuse
Password databases were used from the hacked rookit.com and Gawker sites
Databases were cross-referenced to show 456 legit accounts between both
44% of those rootkit.com accounts were cracked
54% of the accounts on Gawker.com were cracked
Of those cracked – 43% were the same password with 6% having only a slight variation (eg. ‘password’ and ‘password1’)
Weak Passwords exposed. Out of 400,000 Gawker passwords
200,000 cracked in first hour
Top five passwords from list
123456
password
12345678
qwerty
Abc123
Password Analysis

Have a patch management process
Keep systems patched and up-to-date in a timely manner
If concerned about results from updating patches, first test in a virtual environment before move to the production environment
Unpatched Systems

Educate users on social engineering, continue awareness training
Ensure all employees have to follow same procedures even if the CEO
For certain changes, possible make it a part of the change management process
Ensure all changes are then approved by the appropriate channels
Social Engineering

Salt the hashes or use hash iterative
(SHA1(SHA1(Password)))
(MD5(Password + Random Value)
Use two factor authentication to critical servers if possible
RSA token, or other method
Medium risks

All in all, the HBGary hack was not very sophisticated. Attackers did not use any advanced techniques or leveraged any zero-day vulnerabilities. The only thing that was exploited is the fact that HBGary and its employees were not practicing what they preach.
Summary

QUESTIONS
Insert funny fancy clipart here

The Fail of HBGary

by LaNMaSteR53

Accessibility

Categories

Upload Details

Usage Rights

Statistics

The Fail of HBGary Presentation Transcript