A look into the LivingSocial Hack
Over the weekend, the New York Times has published an article following the recent hack of LivingSocial. The Washington based company had issued a letter to its employees, citing that 50 million customer records were compromised, the information contained personal information such as names, emails, addresses and birthdates as well as encrypted passwords. Credit card information, which is stored on a different database, was not stolen.
I believe that it is likely, based on the published information about the data and volume of data that was stolen, that the breach was via a web application attack such as SQL Injection or a framework based attack.
Let’s explore these two angles:
The SQL Injection approach
Based on the data structure that LivingSocial said to have been hacked, it is very likely that the attack that was performed was an SQL Injection attack. The very defined category/column data headers that were disclosed (names, addresses, emails, passwords which are hashed) describes a database table in a very clear form. Unfortunately the SQL Injection vector remains to date one of the most common and least handled security problems out there.
LivingSocial has put up a warning message on their website and have informed their customers via email, which ties the database hacked as the database that interacts with their application.
The framework based approach
In 2011, TechCrunch published LivingSocial press release of them acquiring InfoEther, which is a Ruby-On-Rails expert firm. This and Job Seeking posts from LivinSocial looking for Ruby experts, makes me believe that Ruby-On-Rails is a major technology for them and that it is commonly used in their applications and application servers.
Earlier this year, we blogged about some of the latest Ruby vulnerabilities found, which enabled a remote hacker to gain control over an exposed server, execute arbitrary code or use it to hack deeper into the infrastructure.
LivingSocial may have been another victim of unpatched software.
What can companies do to prevent these types of incidents?
Compensating controls such as a Web Application Firewall are key. While many companies rely on SDLC to resolve application security problems, the window of exposure between the time the bug exists, the time it is found and the time that there is a fix to block the security hole is very large and often hackers find their way to that bug way before the company does, it is a race.
Always check if your application relies on a secured framework, if not – do make sure to either patch it quickly, or again deploy an interim solution such as a virtual patch to make sure that the security risk does not affect your application