Slashdot Mirror
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."
Comment removed based on user account deletion
malware + phishing = phalware?
This attack has been going on for months... http://hackademix.net/2008/04/26/mass-attack-faq/
You don't need a weatherman to know which way the wind blows.
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..
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.
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 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 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!
@ASP.NET's parent-teacher meeting: "Little Johnny.NET is very bright, but he doesn't play well with others."
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.