homepage Welcome to WebmasterWorld Guest from 54.227.141.230
register, free tools, login, search, subscribe, help, library, announcements, recent posts, open posts,
Accredited PayPal World Seller

Home / Forums Index / Code, Content, and Presentation / Databases
Forum Library, Charter, Moderators: physics

Databases Forum

This 78 message thread spans 3 pages: 78 ( [1] 2 3 > >     
Sql Injection virus problem.
Virus, Sql Injection.
shoppingsurat




msg:3657202
 10:02 am on May 23, 2008 (gmt 0)

Hi Friends, we have a website and we have constanly been attacked by virus. A malicious script enters into sql server database and stops the site.
can any one please suggest us how we can prevent it. I changed some script but that did not help too. I think it is going from our search field. <script>......</script> and inside website name enters into every fields of sql .Please help!

Thanks,
Umar Rahman

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

 

shoppingsurat




msg:3657208
 10:10 am on May 23, 2008 (gmt 0)

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]

adb64




msg:3657248
 11:15 am on May 23, 2008 (gmt 0)

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?

shoppingsurat




msg:3657263
 11:30 am on May 23, 2008 (gmt 0)

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]

nmorph




msg:3657389
 1:58 pm on May 23, 2008 (gmt 0)

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]

bmcgee




msg:3657896
 12:18 am on May 24, 2008 (gmt 0)

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.

Zaphod Beeblebrox




msg:3659196
 3:03 pm on May 26, 2008 (gmt 0)

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!

Zaphod Beeblebrox




msg:3659432
 10:05 pm on May 26, 2008 (gmt 0)

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...

andy1




msg:3659738
 10:01 am on May 27, 2008 (gmt 0)

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]

pageoneresults




msg:3659741
 10:07 am on May 27, 2008 (gmt 0)

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. ;)

andy1




msg:3659746
 10:25 am on May 27, 2008 (gmt 0)

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.

pageoneresults




msg:3659749
 10:40 am on May 27, 2008 (gmt 0)

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.

pageoneresults




msg:3659766
 11:13 am on May 27, 2008 (gmt 0)

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.

topr8




msg:3659769
 11:22 am on May 27, 2008 (gmt 0)

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.

topr8




msg:3659770
 11:27 am on May 27, 2008 (gmt 0)

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

pageoneresults




msg:3659773
 11:31 am on May 27, 2008 (gmt 0)

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]

vincevincevince




msg:3659774
 11:31 am on May 27, 2008 (gmt 0)

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

Operating system, scripting / CGI language, database type?

pageoneresults




msg:3659779
 11:41 am on May 27, 2008 (gmt 0)

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.

Zaphod Beeblebrox




msg:3659784
 11:55 am on May 27, 2008 (gmt 0)

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]

pageoneresults




msg:3659789
 11:59 am on May 27, 2008 (gmt 0)

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...]

mcneely




msg:3659821
 12:30 pm on May 27, 2008 (gmt 0)

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.

andy1




msg:3659823
 12:38 pm on May 27, 2008 (gmt 0)

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.

jcaron




msg:3659869
 1:42 pm on May 27, 2008 (gmt 0)


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.

Murdoch




msg:3659873
 1:47 pm on May 27, 2008 (gmt 0)

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?

webdudek




msg:3659874
 1:49 pm on May 27, 2008 (gmt 0)

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.

gabidi




msg:3659890
 2:18 pm on May 27, 2008 (gmt 0)

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...]

MatthewHSE




msg:3659901
 2:43 pm on May 27, 2008 (gmt 0)

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?

jatar_k




msg:3659904
 2:46 pm on May 27, 2008 (gmt 0)

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

woop01




msg:3659914
 2:56 pm on May 27, 2008 (gmt 0)

Is this only occuring in text fields?

ebouwsema




msg:3659950
 3:40 pm on May 27, 2008 (gmt 0)

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.

This 78 message thread spans 3 pages: 78 ( [1] 2 3 > >
Global Options:
 top home search open messages active posts  
 

Home / Forums Index / Code, Content, and Presentation / Databases
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About
© Webmaster World 1996-2014 all rights reserved