Tip

Hacktivism examples: What companies can learn from the HBGary attack

In one of the most blatant hacktivism examples in recent memory, the security company HBGary Federal was attacked by hacktivist

    Requires Free Membership to View

group Anonymous. Anonymous was able to completely compromise the security of HBGary Federal, including taking control of some HBGary systems. 

Play now:
Download for later:

Download 'Hacktivism examples: What companies can learn from the HBGary attack' here!

  • Internet Explorer: Right Click > Save Target As
  • Firefox: Right Click > Save Link As

This tip will cover what happened in the HBGary Federal hack, technological protections that could have prevented the incident and how to evaluate your environment in an effort to avoid inciting such attacks.

Recap of the HBGary Federal hack
Prior to the attacks, HBGary Federal and its CEO, Aaron Barr, were conducting probing investigations into the Anonymous group, and intended to release the findings at RSA Conference 2011. This provoked Anonymous to attack HBGary Federal systems as a defensive response. Anonymous exploited a basic SQL injection in the HBGary Federal custom content management system and insecure password management practices that made their passwords relatively trivial to crack and reuse across other systems. The group then gained root access to a server via social engineering techniques, namely by posing as founder Greg Hoglund.

Anonymous did not stop at compromising the security of HBGary Federal, however. The group used the root server access as a way to control HBGary servers, Hoglund’s website, rootkit.org and HBGary email accounts. Once Anonymous gained access to all of the systems, the group was able to deface the HBGary website, pilfer sensitive data, including internal emails, and expose passwords of registered users of rootkit.org.

Technological protections that could have prevented the incident
There are many technological protections that could have been implemented to prevent Anonymous from compromising the security of HBGary Federal and associated systems, or at least reduced the impact of the attack. The company could have used a commercial  or widely used open source  CMS that was audited for and free from SQL injection vulnerabilities; instead, it reportedly used its own custom CMS that was highly flawed, providing wide open exploit opportunity for Anonymous.

Also, it could have implemented a technical control for input sanitization to prevent SQL injection vulnerabilities in the CMS. Input sanitization to prevent SQL injection is a control that ensures that only valid and secure input is used by the CMS or passed to the backend database. As such a control wasn't in place at HBGary, Anonymous was able to exploit the SQL injection vulnerability to access sensitive data, which it used to exploit the rest of the system.

The insecure passwords could have been avoided by implementing stricter administrative control over password practices. Specific technical controls also could have forced the creation of more secure passwords, such as requiring longer passwords than those contained in common rainbow tables, or more complex passwords with a mix of letters, numbers and punctuation. Also, the stored passwords could have been salted prior to hashing, which would have severely limited the effectiveness of cracking the passwords or using rainbow tables.

The social engineering attack that was used to gain access to a root account could have been avoided with an administrative policy requiring all password changes can only be completed over the phone, not via email, at least for root or shell accounts. After compromising Hoglund’s email account, Anonymous pretended to be Hoglund, sending an email from his account that successfully tricked an administrator into handing over the root login information. While phone calls are inconvenient for password changes, in a small company of security professionals, this inconvenience should have been acceptable given the level of risk.  There are also many security products that could have been implemented in various parts of the environment to help guard against the human errors that resulted in the vulnerabilities.

How enterprises can avoid inciting attacks
One of the many responsibilities of information security professionals is to protect their organizations from malicious attackers, and sometimes that may include intervening in business endeavors or individual activities that may incite malicious responses by potentially dangerous attackers. However, when engaging with hacktivist groups like Anonymous, it's essential that organizations fully understand the possible repercussions. Some in the information security industry have a history of taunting and inciting the black hat and gray hat communities by stating that their products are “unbreakable,” as Oracle has done. While is it impossible to avoid inciting potential attackers entirely, intentionally antagonizing or challenging attackers -- who may have significant resources and available time -- is generally unwise. This incident makes it clear that any groups working to expose illegal cyberactivity would be wise to keep their operations under wraps at all times, unless there is a compelling reason to expose the operations prior to closure of the investigation.

Conclusion
While no company or individual may deserve to be publically humiliated or potentially put out of business, some of the business practices of HBGary Federal and its CEO Aaron Barr did stir up trouble where they might not have needed to. The HBGary attack was no doubt an interesting read, but it is illustrative of how security companies don’t always practice good security, and clearly shows how motivated attackers can find weaknesses and exploit them if they want to. Enterprises can help prevent or minimize the impact of these types of attacks by implementing standard effective security practices and not intentionally challenging potential attackers.

About the author:
Nick Lewis (CISSP, GCWN) is an information security analyst for a large Public Midwest University responsible for the risk management program and also supports its technical PCI compliance program. Nick received his Master of Science in Information Assurance from Norwich University in 2005 and Telecommunications from Michigan State University in 2002. Prior to joining his current organization in 2009, Nick worked at Children's Hospital Boston, the primary pediatric teaching hospital of Harvard Medical School, as well as for Internet2 and Michigan State University. He also answers your information security threat questions.

This was first published in April 2011

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.