The recent Gawker Media LLC data breach is a good illustration of the various things that can go wrong when an organization isn't prepared and doesn't have a mature information security infrastructure that includes people, processes and technology.
The attack on Gawker, like many recent public attacks, was classified as a result of an advanced persistent threat. Given how easily Gnosis (the hacking group that claimed credit for the breach) said it was able to penetrate Gawker, Gnosis may not have needed to use advanced attacks to compromise the security of the organization. However, Gnosis appears to have been persistently attacking Gawker in order to completely compromise the security of its network, generally using more traditional attack methods like SQL injection or a buffer overflow. The exact attack methods are unknown, but reports note that Gnosis first used a local file inclusion attack and then moved to attack the content management system directly. From there, it was able to compromise the rest of the systems. In this tip, we'll discuss how to handle a Gawker-type data breach and explain how enterprises can fend off similar attacks in the future.
Current state of publically reported Gawker security
One of the most-discussed aspects of the data breach was the exposure of Gawker's password file . Along with the password file, the source code to Gawker's content management system was also released, which could allow other attackers to audit the source code for vulnerabilities. In response, Gawker has said it will implement the bcrypt hash for passwords, making it significantly more difficult to crack the credentials of any member of a Gawker-run website and of internal users . However, if weak or common passwords are still allowed, using a strong password-storage mechanism for Web password security will not prevent potential exposure of passwords via brute force attacks . Even if strong passwords are implemented, once an attacker has root access, he or she could capture any password as it is being entered into the system.
The most effective method to prevent exposure of passwords is not to use passwords at all. Using a protocol such as OAuth can provide greater security for user logins to websites. OAuth is an open protocol that creates secure authorization for Web applications, by allowing Web applications not to store the passwords themselves, but only store authorization records. The Gawker accounts that used Facebook Connect for their logins did not have their passwords exposed in this incident, and, if something like this incident were to happen again, using OAuth, OpenID, or other federated identity mechanisms could prevent passwords from being exposed. If an organization has higher value accounts, it might want to investigate multifactor authentication.
What else could an enterprise do?
While it's necessary to improve the security of passwords and accounts, there are additional technologies and procedures that could be used to prevent, detect and respond to serious Gawker-like security incidents. According to reports, there were many holes in the security at Gawker: from old operating systems to poor patch management and potential weaknesses in its content management system. Implementing a patch management process would help address potentially out-of-date operating systems. A penetration test or code review could have identified the local file inclusion vulnerability, and a Web application firewall could have prevented the local file inclusion regardless. Implementing a vulnerability management procedure could have also helped detect the vulnerabilities in both cases. For detection, Gawker could have used an intrusion detection or prevention system to detect network connections to systems that were not locally reporting malicious connections. These technologies are common examples: Many others could have been used, but if any of these technologies had been in place, the damage from the data breach could have been minimized.
Also, Gawker could have responded much differently to this incident. At a minimum, it could have immediately looked more closely at its systems and informed its users that it was investigating the potential security reported issues when its Twitter account was taken over on Dec 11th, 2010, rather than reporting that there were no problems. It could have also notified all of the potentially affected parties as soon as the company knew the accounts were compromised. These steps should be a part of standard incident response plans and data breach procedures.
Examining what went wrong with the Gawker data breach is a good way for enterprises to identify areas where they could improve their procedures. While Gawker doesn't appear to have had a robust information security program, if it had implemented and followed guidelines or standards that most enterprises consider minimum effective information security practices -- for example PCI DSS or other compliance requirements -- it could have prevented or minimized the impact of the data breach.
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 January 2011