It’s been a busy week for security administrators. First, the Lizamoon attack last week. Then, data was stolen from Epsilon.
I first started reading about Lizamoon last Friday (4/1/2011). I was wondering if it was an April Fool’s joke but quickly discovered it was not. Depending upon what estimates you read, Lizamoon infected between 100,000 and more than 1,000,000 pages. In my opinion, the worst part of this attack is that it should have been prevented.
According to WebSense:
We were able to find more information about the SQL Injection itself (thanks Peter) and the command is par for the course when it comes to SQL Injections.
While the attackers did escape many of the characters to make it difficult to decipher what they were doing, SQL injection attacks are easy to prevent:
- Run your web application under an id with limited privileges.
- Use parameters in all SQL statements. This alone would have prevented this attack.
I found this attack disappointing. I remember reading about SQL injection attacks more than 5 years ago along with how to prevent them. How can we have come so far as an industry but still have so far yet to go?
Sometime last week, Epsilon was attacked and had data stolen. I first heard about this when I received an email from BestBuy Reward Zone which included:
On March 31, we were informed by Epsilon, a company we use to send emails to our customers, that files containing the email addresses of some Best Buy customers were accessed without authorization.
We have been assured by Epsilon that the only information that may have been obtained was your email address and that the accessed files did not include any other information. A rigorous assessment by Epsilon determined that no other information is at risk. We are actively investigating to confirm this.
I received a similar email from Chase today. And, according to Engadget, more companies than these two had their data stolen:
A rigorous investigation has concluded that no other personal data was exposed, however it’s not just TiVo that’s affected — other big names, such as JPMorgan Chase, Citi, US Bank, Kroger, and Walgreens have also seen their users’ deets dished out to the unidentified intruder.
The good news is that only names and email addresses were stolen; there was no information stolen that would lead to monetary or identify theft.
But think about what this will do to Epsilon itself. They haven’t published how the hackers got in and stole the data and I could argue that they shouldn’t.
But hackers did break into their systems and steal data. They had to issue a press release stating as much. And, the impacted companies are blaming Epsilon for the security breach as they should. I wonder how much this will hurt Epsilon’s reputation and market share.
So, What’s Next?
The Lizamoon attack was caused by developers not accounting for SQL injection attacks in their code.
We don’t know what was the underlying cause of the Epsilon attack. From the press release and the apology emails being sent out, I think it’s safe to assume it was an exploit as opposed to a social engineering attack. That means it was probably either a developer-created security hole or operations falling behind on patching servers (or both).
So how do we prevent these types of attacks?
First, I think we as developers need to take more ownership of these types of problems and do more to prevent them. The problem with this is that we’ve heard this all before. And many of us do take ownership and work hard to insure our code doesn’t have any exploits. But a lot of us don’t.
Second, we need to educate our management so that security gets taken seriously. If we do find an exploit in existing code, fixing that exploit has to be a top priority. I bet that isn’t always the case. The problem is the risk and that is, I believe, the key to getting management to increase the priority of fixing exploits; by talking about what would happen if the exploit is found.
Third, we need better tools to help us determine if our websites are secure. Most of the tools that I’m aware of do code analysis and are looking for exploits within our code. That doesn’t help us in these cases because the exploits are in how our web site is working and not in how our code is working. Hopefully some good tools will come along shortly and will help us in this area.