Repairing Damage From SQL Injection

The scope of this guide is limited to repairing a web database that has been attacked by SQL injection.

The example used applies directly to mySQL7, but if you generalize the examples this solution can apply to other database formats also. The steps detailed here were uncovered by myself thru limited research so, while the solution is not the most elegant, it is very simple and reproducible. I am not a coder, and I have no prior experience reading/writing ASP or SQL. Someone who knows anything about either language, especially SQL, could have came to this solution easily. The reader should take away from this guide that understanding, locating, and repairing SQL Injection attacks is very manageable for anyone with a basic level of technical experience who is not shy of getting their hands dirty.

Introduction:

The owner of iyawards.com recently contacted me in regards to issues with his website – pages were loading very slowly and Google had stopped serving adwords for his site because it was identified as linking to malicious content. Upon looking into it, I viewed the source of his site to find that malicious javascript was indeed being served when visiting his product pages. The site owner had not put the javascript there, but now they wanted it removed. I had never worked with SQL or ASP previously, which the site uses heavily, but I told the owner I could fix his issue and went to work.

Procedures:

At this point I knew the site used SQL and ASP, but beyond that I had no knowledge of the magic that makes the site work. So my first order of business was to find out where the malicious javascript was hiding in the site. Looking at the source code, it was clear asp was making sql requests to serve its text content and I would need to learn some SQL in order to find out whats in the database.

Solution 1:

I knew the site served content from an SQL database, but I did not know what tables or columns were housed inside of it. I did some research on the basics of mySQL7 and quickly formulated a command to get me started.

List all tables in database:

SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_TYPE = ‘BASE TABLE’ ORDER BY TABLE_NAME

In this specific case I had a webform from the Hosting provider which was powered by javascript, but the same command could be issued thru any interface which allows you to submit queries to the database. Upon issuing this command at the SQL command interface, I was returned the results I needed – a list of all tables which exist in the database. Conceptually, a table within a database is like an Excel spreadsheet – a form with columns and rows holding content. There can be any number of tables within a given database. Now I knew every table in the database, but I still did not know what information was in those tables.

Solution 2:

Knowing what tables exist, I was off to a good start. Listing the content of the tables was simple.

List all columns in table:

SELECT * FROM tablename

In the above command, tablename is a variable – replace tablename with the actual name of a table which exists in the database your working with. After entering this command, I was returned a list of all columns and rows in the table presented right on the webpage where I entered the command. Since I was doing this in a browser, though it displayed all real content in the query results, it did not display the javascript – instead it executed it and the javascript was hidden in the source of the results page, just like it was on the website I was trying to fix. By viewing the source of these results, I could view the actual content AND I could see that the javascript was appended to the right side of the real content inside every row of specific columns in the table.

The injected javascript looked something like this:

This is real website content <script src=thisismaliciousjavascript.org/b.js></script>

Solution 3:

Now that I knew where the content existed in the database, all that was left to do was to remove the javascript from the columns where it existed while leaving the valid content intact. This was a bit challenging as I was not sure how to parse valid content from malicious javascript, but there was a clear and consistent patter which made it easy – javascript was appended at the end of the valid content and no valid content came after the javascript. So I could drop everything that appeared after <script in each row in the column that was infected.

Remove the malicious code from a specific column in the table:

UPDATE table SET column = LEFT(column, CHARINDEX(‘<script’, column) – 1) WHERE column LIKE ‘%<script%’;

Upon issuing this command, all javascript that existed in the column was stripped out, and the valid content was left untouched. I then could reissue the command in Solution 2 and view the source code produced to ensure no javascript was being rendered.

Following these steps for each column that was infected will clean a database from SQL injections if the database has javascript appended to the right side of actual content. If javascript is inserted in the middle or to the left of valid content, you would need to alter Solution 3 to suit your needs. The same rule applies if the injected content is not javascript. Generally tho, these steps can be applied to other infected databases if the SQL code I presented is only slightly modified to be relevant to your issue.

Conclusion:

As a parting note, be warned that this will only clean the database from the damage caused, and it does not resolve the SQL vulnerability in the code of your website. I recommend googling for *protecting against SQL injection* to find more information about preventing this sort of attack.

IMOG

Matt Bidinger

http://imog.us