Gawker Media Compromise – Lessons Learned
This past weekend, Gawker Media began notifying more than 1.3 million users, across its variety of website properties, that their user databases and other information assets had been compromised. A complete dump of the user database was being distributed via BitTorrent, and a pastebin.com log of various details was posted (this has since been removed). As details emerge and are analyzed, it appears that the breach was a final act from a group that had gained fairly considerable access to Gawker Media, and had reviewed and extracted a great deal of information for at least a month. As we often do on the Cisco Security Blog, let’s take a look at how we could learn from others’ misfortune.
Know What You Value, and How You Endanger It
If you are a website owner and you are reading the news about the Gawker compromise, or even about Wikileaks and the fallout surrounding its recent disclosures, you need to start asking yourself some questions, particularly if what you publish could be seen by some as threatening or controversial:
- How much value do I assign to users’ goodwill toward my site?
- How much value do I assign to my ability to transact business through my site?
- Will a decline in either users’ goodwill or my ability to transact business through my site affect the other?
I think that the following advice is valuable for all site operators, but especially those whose activities could produce additional risk. If these assets are valuable to you, and what you do regularly might put either or both of these assets at risk, then you should pay particular attention.
For the defender, security is never 100% attainable, because at some point the economics of the risk equation will show that it costs more to defend an asset than it does to bear the cost of losing it. If this unbalanced approach were taken, the defender would lose simply by spending through the value of the asset. Likewise, the attacker knows that the defender’s protections are not impenetrable. They can attack until a weakness is detected and exploited. With every success by an attacker, they have an opportunity to expose a resource whose risk equation may have factored in the protection provided by the asset that the attacker has compromised. That is to say, for example, if your passwords are obfuscated by a custom function stored in your source code, your passwords are only as secure as your source code.
Multiple Failures Led to Breach
- Poor situational awareness of the security landscape within Gawker
- Incomplete and/or ineffective incident response
- Poor password policy for internal users
- Insufficient patch management for known security issues
- Poor handling procedures for sensitive information
- Poor defense-in-depth protections for source code and third-party FTP credentials
- Antiquated encryption on user passwords
- Some indication that site visitors’ (aka “peasants”) security was not highly valued (a weak argument, but embarrassing at the least)
Much can be said about how to address this breach as a user whose credentials were disclosed (albeit in encrypted form). As far as value to the attackers, these credentials, as well as the credentials for other systems or intelligence that could lead to a repeat intrusion (such as source code) are the primary target. Not because Gawker and its related web entities are so valuable, but because human nature remains what it is, and passwords are continually reused from site to site. After all, isn’t poor password diversity part of what got Denton’s account compromised and facilitated this debacle?
But I think it is unfair to focus on users’ education in the wake of this breach. Sure, preliminary analysis shows that many users had simple passwords, and reports indicate that Twitter accounts have been compromised because email addresses and passwords were shared in at least those instances, but with the passwords stored in unsalted, DES hashes, what did the rest of the users do wrong? Perhaps only trust that a website would keep their information safe. Yes, password management is a big issue and an important one for users to take seriously, but the majority of failures do not rest with the users.
Sites that center around engaged and participatory communities derive value from the users that frequent their sites. Failing to protect those users could lead to a direct undermining of the business model. Site operators should understand how users perceive their websites, and employ security practices that reflect what assumptions users might have about their sites.
Controversy Can Put a Target on Your Back
Some sites are driven by a culture of free expression, which can be necessarily controversial. If they would like to keep saying the things they say, they should consider good security a cost of doing business. For example, Gawker.com commenters may be particularly sensitive about privacy, because of the secretive or gossip-centric communication that may be shared; likewise Jezebel.com users may be discussing personal matters. These properties might benefit from some (at least optional) segregation from the other more entertainment-centric sites like Kotaku, Lifehacker, Gizmodo, io9, etc. where user participation may be less sensitive or personal in nature. If multiple sites fall under the control of one operator, but some sites are more privacy-sensitive, or more necessarily expressive, it may make sense to segregate their back-end systems from each other, as these sites could be magnets for an attacker’s attention or abuse.
Don’t Make Your Site a Jumping-Off Point for the Next Attack
Do not use an email address as a username. Just as attacks against a particular organization look for primary and secondary compromises to further penetrate valuable assets, compromises like user database dumps can lead attackers further into the personal details of individuals. If usernames for a particular person are used across several sites, which is more likely if sites rely on the guaranteed-unique key of an email address, then a single compromise can result in pervasive compromise. Gawker did not require e-mail addresses as usernames, but since most sites store email addresses, their exposure could reveal part of the authentication credentials used elsewhere. Site operators should consider what information about users they need to keep, and take steps to proactively protect their users in the event of a major data breach. Data segregation, data encryption, and setting appropriate limits on data retention are also appropriate considerations.
Ongoing, Covert Attacks Wreck Unprotected Businesses
Gawker’s attack was noticed because it was very overtly announced. Sites that are actively monitored and audited are much more resilient to this kind of failure. Consider the same vulnerability scenario, but with an attacker determined to do the most damage to Gawker Media as possible. Such a motivated attacker could have lurked within the network, viewing chat logs, source code, and planting further hooks into the day-to-day operations of the sites. Over time, the attacker could have constructed a picture of what the site operators were most interested in. Imagine what damage could be done if every unique article were first posted elsewhere? Or if advertisements were replaced with malware distribution? And so on. The point here is that if any site considers its ability to satisfy users and advertisers important, then securing the reliability of those services should be a primary cost of doing business.
Protect Users, Protect the Bottom-Line
Many sites rely on engaged user communities to drive commentary, increase readership, and make advertisers see the site as a destination for advertising income. If users become offended by poor security practices, they could take their page views elsewhere. Any site that needs to protect advertising revenue and user loyalty should consider developing a culture of respect for users. DES encryption of user passwords is very poor practice in 2010. If a pervasive culture of valuing users existed, someone should be asking questions like, “How are our users protected? Can they trust us to provide them the protection that they expect?” Certainly a few questions to the developers down this line of thinking would have exposed DES as an utterly useless password hash algorithm, and could lead to other best practices like AES, Blowfish, and salting.