New SQL Injection Attack Fuses Malware, Phishing

PainMeds tips a recent post in Secure Computing's research blog describing a new SQL injection attack that had infected thousands of MSSQL-based web servers by last weekend, turning them into malware delivery systems. The attack apparently rewrites the server's Web pages to include JavaScript which pushes malware to the visitor as if it were from the genuine site. Sites using Sybase might possibly be vulnerable, as it uses the same exploited syntax that MSSQL does. The post includes an example of the attack. Unlike most malware attacks, this one appears to originate from the site the user is actually visiting. From the blog: "'Similar to phishing, this attack takes advantage of the website visitor's trust in the site they are visiting. Instead of phishing for information, however, malware is sent to the client, which the client has a higher likelihood of accepting being from a trusted site... These web pages are associated with Web sites from around the world and supplying various content — including government sites, sales sites, real estate sites, and financial information sites among others."

Not really new

They're just inserting the javascript directly into the websites's content, instead of putting an iframe to a hacked server to then run the javascript...

Seriously, did anyone *not* see this coming? I always wondered why they didn't do this to begin with... I guess so they could update the malware being distributed since it was all from a central location.

Re:

Yes, nothing new at all...
People used to do this by compromising the site in other ways, and inserting their malware rather than defacing the site... Some subtle malware tagged to a site is a lot less obvious than a blatant defacement so it lasts a lot longer and gets more hits.

Re:Not really new

Why do you assume all code is new. Many SQL Calls are decades old and were copied and pasted assumed what isn't broke don't fix. Not really taking into account that the interface is not controlled by the server anymore. But can be easily altered by the client. being that the bug is threw Microsoft SQL there is a higher chance that it is threw Mr. Certified .NET Developer who knows .NET but has now clue on how the web works so he assumes that if he puts a size limit on that textbox or make important fields hidden he is safe. As well a bunch of people have a poor understanding on how to use SQL, they just think it is bit more optimized version of a flat file. Where the hard stuff are using joins. So they figure well this data isn't that important.

Re:Not really new

Many SQL Calls are decades old and were copied and pasted assumed what isn't broke don't fix.

All too true. My company maintains some sites that were originally written during the 90s by a different web consulting company. The sites were happily chugging along and serving up pages for upwards of 10 years, until last weekend when they were hit with the exact attack described in this article. Fortunately, the attack was noticed early and we were able to fix the problem quickly, resulting in a minimal impact on our client's users.

I wasn't involved much with the emergency fixes, but our team ended up installing a product called dotDefender [applicure.com] that seems to have done a fantastic job of filtering out malicious requests. It inspects GET and POST data _before_ it's passed on to the vulnerable application and stops the request if it detects things like SQL injection, cross-site scripting, directory traversal, or other attacks. If you use IIS6 and have a lot of vulnerable code; or, like us, some of the bad code is contained within compiled libraries for which you don't possess the original source, I'd definitely recommend checking it out.

Alternatively, there's a free ISAPI filter [codeplex.com] that will perform similar pre-application-level checking of GET and POST data, though I believe it only checks for SQL injection, and I can't vouch for it since I've never seen it in action.

Unfortunately, I don't believe either of these solutions work with IIS7, so if your sites run on IIS7, I wish you luck!

Re:

There is also deliberate gross misconduct. A lot of the code is written by outsourced divisions, I-9 lackeys, or contractors who will be long gone by the time someone discovers the SQL injection bug. Most companies don't pay for audits of their Web code, nor do they care to.

Sad thing is that MS is doing their best to prevent this, but they still get blamed for what their customers do (or fail to do.)

Re:Not really new

Don't blame the contractors, If they mess up it is usually do to bad management on the company. Having worked as a contractor/consultant I can tell you when there is good management at the company I produce really good work. When there is bad management my work isn't that great. The case of leaving a bug and being long gone has a flaw. Because people want return business and a good name. Doing a Hit and run of coding doesn't allow for a good professional credentials. But with contractors they are often under the gun far more then W2 employees to be cost efficient, any work they do needs to be approved as the company doesn't want to pay for extra non-speced work, and if that spec doesn't cover SQL injections or security and they do the right thing and bring it up, bad management will say it isn't an issue and just do what is speced, thus causing the problem. If they did go and take an extra 4 hours to make it secure they will not get paid for it. If the manager was smart and listed to the advice then good quality code can be released.

malware + phishing =

malware + phishing = phalware?

Re:

Phailware. You get it from web sites who phail at security?

Am I in a time warp?

This attack has been going on for months... http://hackademix.net/2008/04/26/mass-attack-faq/ [hackademix.net]

We got hit a few weeks back

We were added to the attack list a few weeks back, and one of our largest, most popular websites was hit. Apparently, the developers had never thought to sanitize their data, and we had multiple vulnerabilities throughout the site.

I implemented a transparent reverse proxy server running Apache with mod_security that helped prevent further attacks from getting through, but the developers finally saw the error of their ways and converted hundreds of inline SQL calls into stored procedures.

Since we were added to "the list", I've been seeing the same attack happen across multiple pages every 20 seconds, so they are definitely not letting up anytime soon.

Re:

Let me guess, they converted

"Select * from Users Where UserID='" & Request("UserID") & "'"

To

CREATE PROCEDURE GET_USER_DATA(@UserID varchar(200))
AS
exec('SELECT * FROM Users WHERE UserID=''' + @UserID + '''')
END

Using stored procedures doesn't solve anything if developers don't actually understand what the problem is. You don't even need to use stored procedures. Simply switching to prepared statements would have fixed the problem.

Not new at all

This trojan, called Asprox or Danmec, has been around for a few years. It was originally intended as a Spam distribution system but I believe that sometime in 2007 an SQL Injection tool was installed via its botnet. It has been doing the rounds every so often on the Internet since at least January.

http://blogs.zdnet.com/security/?p=1122 [zdnet.com]
http://www.secureworks.com/research/threats/danmecasprox/?threat=danmecasprox [secureworks.com]

      -dZ.

Why the missing quotation mark?

I just looked and see this in my logs too; looks like they started on August 6 over here.

What's funny is that it looks like they're trying the attack in pairs: once in the "classical" quotation mark form (GET /index.php';SQLCOMMANDSHERE) and then again without the quotation mark (GET /index.php;SQLCOMMANDSHERE). How is that second form supposed to get executed? They've gotta be trying it for a reason.

Queue The MSSQL Bashing

I can't wait to see how many posts will bash Microsoft for the 'obvious' vulnerabilities they left in their SQL Server product..

Re:

sure, send piped UNIX commands to a javascript living in a MSSQL server ...

Re:

Only starting in SQL Server 2005 iirc... Do you have any idea how many people use MSDE 2000 still??? It's scary.

Re:DELETE FROM USER*

Well, it's more scalable then, innit?

Let's see who's laughing when the Political Correctness brigade catch up with the Gregorian Calendar and hold it to task for picking on poor, old February.

Re:

Either way, blitzing the server is probably the worst way to turn it into a malware delivery bot.

Re:DELETE FROM USER*

More likely to work:

del c:\boot.ini

Then, next time it's rebooted... it doesn't come up. It's not something noticeable right away.

Re:Attempts made on our systems...

Also, for what its worth, all of the IPs (100s of them used in the course of 3 days) trace back to ISPs based in Beijing. Hmmm...

The Olympics are trying to hack your webserver?

I wasn't aware that Server CTF was an Olympic sport.

Re:

In Communist China, the Olympics hacks you!

Re:$conn_id = mysql_connect("microsoft.com")

You'd have to be an idiot programmer to have a site succumb to this... It's not even "microsoft specific".

It would affect any site that takes request parameters and passes them straight through to the db engine (well, not specifically this syntax, but the concept behind the attack).

To be fair to Microsoft (heresy here, I know) asp.net built-in validation throws an exception.

In other words, not only would a programmer have to use raw request string data with the db, he would also have had to specifically disabled the default page validation. In other words, an idiot.

My website got hit with this type of attack last week, and the attempts were all rejected by the default validation. Even if the default validation had got past, all of the database queries use parameterized stored procedure calls which pretty much ignore this kind of crap anyway.

Still, it's made me think more about security and additional parameter validation. Maybe the next attack will be a bit sneakier..

Re:

Take a look at the article from this comment, it has a "use at your own risk" procedure. You could probably modify it appropriately.

http://it.slashdot.org/comments.pl?sid=643879&cid=24574393 [slashdot.org]

Re:

I've used that procedure for a couple clients with success. There are two things you have to consider, since if you've been hit once, you've probably been hit multiple times.

1. Some fields have probably hit their maximum length, causing the last injected script tag to be truncated, so this procedure will miss them. Clean these up manually so that the field ends in "</script>" (the closing tag for the previous injected script tag). Of course, you could just manually clean up the whole field at this poi

Re:

declare @wtf varchar(100)
declare holyshit cursor for select name from
sysobjects where xtype='U'
open holyshit
fetch next from holyshit into @wft
WHILE @@FETCH_STATUS = 0
begin select * from @wtf where thehtml like '%code%'
print 'please kill me'
fetch next from holyshit into @wtf
end
close holyshit
deallocate holyshit