Cleaning Up After a SQL Injection Attack

In October 2010, a customer’s website was being actively exploited. It was a custom-built PHP site, and 6 other developers had worked on its code over the previous 5 years. The attacker had found a handful of SQL injection points, and one Execution After Redirect flaw on an admin page: the page sent visitors who weren’t logged in to the login page, but kept running the code below the redirect, so anyone who ignored the redirect could use the page anyway.

The cleanup took 5 days.

What I Did

• Stopped the attack (half a day). I worked out what the attacker had reached from the changes they had made to the site’s content and from the server logs. Then I closed the holes they had found and restored from backups.
• Turned the code’s habits into a list (a day and a half). The earlier developers had their own patterns for getting at the database, and several of them were unsafe. I identified those patterns and wrote a script to find every use of them. It was slightly smarter than grep for the job, and it listed each file and problem on its own line.
• Worked the list (two days). I went down that list opening and fixing files as fast as I could, adding sanitization to more than 200 SQL queries.
• Looked for the next weak point (one day). The last day went to other checks, which turned up 4 more Execution After Redirect flaws, the same kind the attacker had used on the admin page. I also found a way to bypass the login on the admin file upload tool, and closed it. I checked the logs to make sure the attacker hadn’t found it.

I’ve answered more than a dozen calls like this, each one different and each on a codebase new to me.