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?
Our web apps got hammered with this over the weekend... our simple but effective SQL injection block kept them out, but it is also comforting to know that even if it had not, it would not have worked on good ol' MySQL 4.1
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...
sure, send piped UNIX commands to a javascript living in a MSSQL server ...
UPDATE management SET perf_review='Epic Fail' WHERE jobtitle='MSSQL Engineer';
Tubal-Cain smokes the white owl.
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.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
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.
The whole SP vs inline sql debate is an entirely different kettle of fish (btw stored procs suck =P). The easiest way to protect against sql injection is parameterise your sql (yes you can do that with inline sql!). Next easiest thing - realise that everything from outside the system is essentially user input and treat it as such.
I use .NET / Sql Server on a daily basis - it isn't hard to make these kind of attacks a non-event, the problem is the multitude of drag and drop developers who have nfi what they are doing. If only software development required a license to practise =)
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.
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.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
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
-- "So they told me that using the download page to download something was not something they anticipated." - Bill Gates
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
http://www.secureworks.com/research/threats/danmecasprox/?threat=danmecasprox
-dZ.
Carol vs. Ghost
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.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Comment removed based on user account deletion
Comment removed based on user account deletion
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.)
I can't wait to see how many posts will bash Microsoft for the 'obvious' vulnerabilities they left in their SQL Server product..
I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
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.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
You don't need a weatherman to know which way the wind blows.
Only starting in SQL Server 2005 iirc... Do you have any idea how many people use MSDE 2000 still??? It's scary.
Absolutely not true. xp_cmdshell is denied by default in MSDE 2000 (and sql server 2000).
Incidentally, there is nothing inherently wrong with MSDE from a security standpoint. MS still releases patches for it. MSDE is a solid, ACID-compliant database (unlike a popular open-source database that also starts with the letter M). MSDE is the same robust database engine as its bigger brother, sql server 2000.
MSDE does have size limits (2 gig per database) and performance limits (more than 5 concurrent threads and it starts to slow down), but if those limits are acceptable for your application it's great.
Either way, blitzing the server is probably the worst way to turn it into a malware delivery bot.
Poor little Bobby Tables, copping it on the chin again http://xkcd.com/327/
Do not mock my vision of impractical footwear
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."
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.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Who cares what the DBA wants to know (except the DBA). Do we build business processes to access the database, or databases to support business needs? The simple fact is that the demand to use stored procedures is nothing other than a power grab by DBAs. The SQL Injection in the original article was caused by idiot front end developers who made several compounding mistakes. Are you suggesting that these monumental idiots wouldn't have called the stored procedures from the query string if you forced them to use stored procedures?
Don't blame management. If you were asked to make a kid's toy, would you ask 'do you want it the safe way, which will cost an extra $5 per unit, or do you want the cheap way?'.
You are a professional, it is your job to produce software that meets professional standards. If others screw up, fine, but don't deliver an unsafe product just because nobody told you to make it safe.
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.
You've never actually held a real job, it would seem.
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
Bingo. If it takes this hypothetical 4 extra hours to make you application secure, you should have quoted 4 extra hours, and if you didn't it's your fault, not your client's.
I can see those in my webserver's logs dating back to 23rd of July:
Oh, and the hexes decode to:
(phew, I'm lucky to get that through Slashdot's filter!)
You can easily decode that from your webserver logs even on MySQL, just take into account the different CAST syntax:
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.
You are in a maze of twisty little relative jumps, all alike.
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.
878659 - yep its prime.
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
The attack is ancient.
The method of delivery is a bit newer - a few months ago it all got a lot more efficiently delivered - it's pretty mainstream knowledge, even this article from the paper edition of SC Magazine talks about it - and their copy deadlines will be from weeks ago.