this is virus name <sipt src=http://www.example.com/b.js></script>
Please note I have chnaged <sipt.

[edited by: jatar_k at 12:02 pm (utc) on May 23, 2008]
[edit reason] no virus links thanks [/edit]

Is this a real sql injection, is it trying to insert sql commands to exploit a possible security problem? Or is it just inserting some javascript in each field of a form on your site?

its inserting just javascript in each field of sql server tables.

example : a danish site which provides information......and then <sipt src=http://www.example.com/b.js></script> like that

[edited by: jatar_k at 3:51 am (utc) on May 28, 2008]
[edit reason] no URLs or specifics, please [/edit]

I've just found the same problem in my SQL database. I know it was introduced between 07.54 and 9.00 today as this is when the login problems started. I am about to go through my web logs to see if I can see when it was introduced.

I have already removed all occurances of it from my DB by doing a find and replace (using Access to connect to the SQL DB) and have checked the user securities for the DB removing any data writing capabilities from those that don't require it (or can do without it for now).

I have also noticed that if you put the offending script in google there are several sites that come up which are obviously not aware they are affected.

If I work out how it was introduced I'll post it here.

[edited by: jatar_k at 1:13 pm (utc) on May 26, 2008]

This is rampant right now. Same script being called from a variety of domains.

It was introduced by your dynamic sql statements allowing the sql injection. You need to clear the input, or preferably move to parameterized procs.

Same here with a site of one of my clients - happened sometime on may 24th, but I can't find where or when exactly.

It appends the script-tags mentioned above to every text-field in the database large enough to hold it.

If anyone has more info - please post it!

I wrote a script that walks every table, checks every text-column for presence of the script-tag, and removes it, so that takes care of the consequences.

Now the sweet task of finding the leak...

Hi all,

Yep we've got this too...

<sript src=http://www.example.com/b.js></sript><sript src=http://www.example.com/b.js></sript>

(removed the sCript)

Zaphod: any chance of putting your clean up code here?

All: can someone expand on how to prevent this from happening please?

Thanks

[edited by: jatar_k at 3:52 am (utc) on May 28, 2008]

[edited by: txbakers at 8:08 pm (utc) on May 28, 2008]
[edit reason] url [/edit]

Welcome to WebmasterWorld andy1!

Create a new user in the DB with read-only access, then update the connection strings in the asp pages to use that account.

The above were instructions that we sent to someone who experienced the same attack. I believe you'll also need to restore the db to a date prior to the hack.

Its a rather nasty one too. I believe it inserts the actual scripts into the sql records. It happens due to the way the sql statements are set up on the actual asp page. Apparently there is an exploit there and it all goes back to how the page was programmed. I'm not a programmer so I know just enough to get me into trouble. ;)

Thanks for the welcome. :)

Yep you're right, my fields are full of that script (appended).

Am I right in thinking that to prevent this I need to get the ASP form verification code changed to detect the script string, for example, and then deny it? And more importantly, block their IP.

andy1, I'm going to let someone with a bit more experience jump in on the topic. That is about as far as I can take it without getting "others" involved. I have an old client site that got hit. Its one of those "information sites" that gets updated once every year or so. Pretty much a trouble free third party host too. And then the sql injection attack. That's how I became aware of it and what was done to address it. I believe the pages are being rebuilt to remove any further risks. Again, it all goes back to the original programming of the page and how the sql statements are constructed. I have a sneaky suspicion that I'm "only partially correct" in this particular instance and that is why I need to bow out now gracefully before I get in too deep. ;)

I'd like to send out a plea to all Webmasters to double check your website installations. This is a rather nasty hack and the payload is a bit unfriendly. A landing page with multiple <iframes> each one doing something different to the user. Scary stuff.

For those of you on Windows, I'll bet some of you have a big gaping hole in some of your asp pages and don't even know it. Check your sql records for the .js scripts. It is truly viral.

Here is a bit more information related to this sql injection hack. This is a must read for all Microsoft folks, as we are at the forefront again...

2008-04-28 - No New IIS Or Microsoft SQL Server Vulnerabilities, Despite Claims
[webmasterworld.com...]

2008-04-28 - Half a million sites hit by huge web hack
[techworld.com...]

2008-05-15 - Phishing botnet turns to SQL-injection attack
[techworld.com...]

It's so bad, in fact, that while security companies urged website administrators to check their server logs for evidence of a compromise, and told corporate security staffs to block several malware-hosting sites at their companies' perimeters, they didn't have much useful advice for end-users.

This was interesting...

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. It then hits those pages with a SQL-injection attack and, if successful, plants a malicious IFRAME on the site.

Emphasis mine. Search Google for Goolag.

this is sweeping the internet right now.

i think robots are searching for asp pages that use querystrings such as:
?prodid= or ?productid= or ?id= [and probably more]

it is then requesting those pages using a querystring such as:

?productID=10;DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST(0x440045004 [+ hundreds more characters]

to combat this you need to clean your data before you query the database.

eg.

if you are doing something like

select * from table where productid=" & request["productid"]

then you are in BIG trouble

you must first test request["productid"] to see that it is a value you expect it to be, perhaps an integer only, or a string but it won't be longer than 20 characters for instance.

you should also use stored procedures as well.

note that cleaning your db table fields is only temporary, unless you clean up the way you query the database it will just be reinfected.

also i'm not sure if this attack is targeted at forms as well, but it is certainly targetted at parameters passed in querystrings.

as an aside, most of these attacks seem to be coming from china, but not all of them.

as pageoneresults says what this is doing is actually placing the javascript include on your pages.

this js then builds the iframe and so on.

the damage to you is just the loss of data in your db when the injection attack happens - it writes the code for the js include into database fields it thinks are appropriate.

you then serve the pages - the person that visits your page with js turned on is the one who really sufers, their computer is potentially comprimised

You then serve the pages - the person that visits your page with js turned on is the one who really sufers, their computer is potentially comprimised.

And, if you are one of the unfortunate ones where the hack has been present for more than one or two indexings, you may be the recipient of this...

[google.com...]

[edited by: pageoneresults at 11:31 am (utc) on May 27, 2008]

Can we be absolutely clear about what systems are infected here?

Operating system, scripting / CGI language, database type?

Can we be absolutely clear about what systems are infected here?

According to my Lead Programmer, no. I've got him reviewing this topic as we have an interest here. He's been dealing with sql injection attacks since the late 90s.

Here is some of the commentary I am currently having with him via IM...

the last comment on that is good. "note that cleaning your db table fields is only temporary, unless you clean up the way you query the database it will just be reinfected."

unfortunatley for mysql and most beginner sites are still using sql statement inside the asp/php scripts especially when mysql is free and designed for begining sites, and they don't offer stored procedures (or the advanced paid version only offers limited stored procedure options.

also, i'll need to check the latest mysql. they might have added a few more features. but the problem are most users prefer "Select * from tblUsers" than to create a stored procedure, set the parameters and call it. to them its additional steps.

btw, this issue can happen on any system (asp, jsp, asp.net, php) and any database (mysql, access, Mssql, oracle). it's always about best coding practices and knowing how to set the security. that's why dba gets paid $$$$$.

if walmart's database is down and the latest one they can restore is 1 hr ago. they're in huge trouble. that's several terabytes of transactions lost.

Of course I'll share my quick & dirty solution, but remember that's what it is. You'll almost certainly need to modify it, and it's no doubt not the most optimal script conceiveable, but it worked for me.

[edited by: jatar_k at 11:59 am (utc) on May 27, 2008]
[edit reason] no urls thanks [/edit]

More related links along with links from MSN on how to protect and prevent...

2008-05-05 - Under Attack! Hacker attacked DB with link to virus
[webmasterworld.com...]

2007-11-19 - Avoiding SQL injection attacks without the need to replace words
[webmasterworld.com...]

From the above topic, Ocean10000 posted these links...

How To: Protect From SQL Injection in ASP.NET
[msdn.microsoft.com...]

How To: Protect From Injection Attacks in ASP.NET
[msdn.microsoft.com...]

Anti-Cross Site Scripting Library
[msdn.microsoft.com...]

And then a slightly older topic. Apparently this is not something new...

2006-02-19 - SQL Injection Vulnerability - What measures Should be Taken Against
[webmasterworld.com...]

Did a quick search on the Google for the script term posted above and found mostly public service pages with it, like, the city of Pittsburg, high schools, and loads of sites with the .org tld.

Can someone let me know how to clean this up? Basically I want to search/replace a particular string in all the tables, columns please?

I know this bit is the temporary solution but I've fixed the ASP code now and restricted the SQL user's access.

We've had quite a few(!) new records since the last "good" backup so it will be easier to find/replace all the "script" code that's been appended.

Thank you.

Can we be absolutely clear about what systems are infected here?

Operating system, scripting / CGI language, database type?

SQL injection can happen with any OS, any scripting language, and any SQL database as soon as there is an SQL database around.

It is very common in PHP, as PHP programmers are used to do this like:

(BAD BAD BAD DON'T DO IT)
mysql_query("SELECT * FROM table WHERE id=" . $_GET[id]);

which means that if the id passed is not checked, it may contain additional SQL, and the attacker can do anything they want on your database.

In the majority of other languages (and now in PHP as well I believe, but it requires a switch to more recent APIs), you can use placeholders. E.g. in perl:

$dbh->selectrow_array("SELECT * FROM table WHERE id=?",undef,$vars{id})

This means the driver or abstraction layer will make sure that the ? will be replaced by the value passed, but correctly quoted so it can only be considered a value (usually an integer or a string), and can't be interpreted as SQL code.

However, even in languages or with APIs that do provide placeholder syntax, many developpers still insert unchecked input directly into SQL queries, which is a very bad idea.

So, the advice is:
- if at all possible, switch to using a syntax with placeholders and separate values. Make sure you never insert a variable received from a web client directly into an SQL query, always use a placeholder

- if not, always check your input (e.g. that integers are actually integers), and for text always use the appropriate "quoting"/"escaping" function (that will make sure that the value passed is considered as a literal and nothing else) before inserting it into a query

Of course, the worst case scenario is with the tons of software "out there" containing such code that has been copied thousands if not millions of times by webmasters all over the world who have no idea of what this all means :-(

Jacques.

Let's say for example that I catch the IP address of a box that is propogating this attack, is there anywhere useful that I should forward this information?

You should search for a vulnerability scanning system and signup for a daily scan.
This is the only way you can know about your security holes before hackers find them.
I was hit myself and learned it the hard way. It's not that my system is safer now, it's just that I have a good alarm system that tells me if I left a [back] door open.

We operate a sizeable ecommerce store with heavy traffic so naturally we've come under this sort of attack on a routine basis.

We've found installing Mod_Security for Apache and keeping your conf file uptodate eliminates the vast majority of automated injection,xmlrpc,tmp,shell,foreign css and other attacks you will face .

It's quite easy to install and keeps a decent log of when, where and what was blocked for debuging .

Checkin it out : [modsecurity.org...]

Just to make sure I understand this correctly, this is just an ordinary MySQL injection attack on a really big scale, right?

In other words, the fact that I validate all user input and run it through

mysql_real_escape_string

before I use it in a query should mean I'm still safe?

that's my understanding as well MatthewHSE, if you're security basics are covered then this is a non issue

>> the problem are most users prefer "Select * from tblUsers" than to create a stored procedure, set the parameters and call it

well, that isn't very concise. Properly processing all data from outside sources is the issue, whether you use a standard select or a stored procedure has little to do with it.

sorry pageone, that's been sticking in my craw since this morning. :)

>> if at all possible, switch to using a syntax with placeholders and separate values. Make sure you never insert a variable received from a web client directly into an SQL query

again, you don't need to switch to any particular system, the second part is the important part but I would take it a step farther

Never trust data from any outside source

Is this only occuring in text fields?

One of the things we noticed is that they appeared to be using the errors that were being returned to determine what values they were needing to parse through the database. A simple way to fix/prevent this is to disable IIS from "Send[ing] detailed ASP error messages to client" under the Application Configuration>Debugging. This is by no means an overall fix for the application, all input should be sanitized and verified, but it may slow down the bot.