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

Comments

Saw this 1 month ago

[Anonymous Coward]

I saw attacks that were the same as this 1 month ago in our webserver logs

We got hit a few weeks back

[G33kDragon]

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:We got hit a few weeks back

[CastrTroy]

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.

Why the missing quotation mark?

[Sloppy]

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.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Sigh...

[SQLGuru]

It depends on your definition of DBA. In the large companies I've worked at, the DBA administers the database but the application developers develop the tables within them. DBA = backup, tablespaces, etc. App Dev = db contents. I'm a database developer and would never claim to be a DBA (although SQL Server is easy enough that I could get by in a pinch).

Layne

Re:Not really new

[_xeno_]

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.

That reminds me of a time when I was asked to help someone add a new feature to a set of reports generated on an internal web app. I take a look, and discover that this system works by generating SQL statements based on the form fields in client-side JavaScript before loading them in a new window via window.open. So you had ?sql=SELECT+*+FROM+TABLE sitting there for all to see.

Checking the JSP (it's not just .NET devs) confirmed that it was just blindly passing whatever it got to the database and essentially dumping the resulting data as an HTML table.

I tried to explain why this is a bad thing, that anyone can run any SQL statement the want through the address bar. And he agrees, that's a bad thing. Fortunately, he immediately saw the solution:

Pass the SQL statements with a POST.

Eventually I was able to convince him that, no, POST requests aren't magic and yes, people can, in fact, create arbitrary POST requests.

Re:Not really new

[warsql]

You sound like a very competent developer. Too bad you will never contract at the company I work for (and many others I know of) because the management can't be convinced that using fixed bid doesn't limit liability. They continue to bid out work - fixed bid only - pay for that project, get a pile of garbage delivered, then pay more to get it fixed. I've given up that fight a while ago.

Re:Not really new

[Anonymous Coward]

As a contractor myself, here's how that scenario sometimes goes:

* Client requests bid for web project
* I produce bid for web project, allowing for secure practices
* Client thinks bid is "high", requests task itemization
* Upon further review, some involved employee of client asks "What would this part cost without all that secure coding stuff?"
* Regardless of my answer, the client responds "We don't need that, redo the bid without it"
* Attempting to "hide" the extra work in the itemization is dishonest, and the likely result is that someone else will get the work, or the client will decide not to do the work
* I can turn down an otherwise good contract, or I can produce insecure web pages; nice choice, that

Sometimes the best you can do is document the client's intent to cut corners.

- T