New SQL Injection Attack Fuses Malware, Phishing 202
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 (Score:5, Insightful)
Re:Sigh... (Score:1, Insightful)
It's so easy to protect from sql injection without using stored procedures too. Only someone not understanding the details involved would claim otherwise.
Re:$conn_id = mysql_connect("microsoft.com") (Score:5, Insightful)
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:Sigh... (Score:2, Insightful)
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 =)
Re:Not really new (Score:4, Insightful)
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:DELETE FROM USER* (Score:1, Insightful)
By default, that is switched off.
So, no - you can't do that out of the box.
Re:Not really new (Score:3, Insightful)
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.)
Queue The MSSQL Bashing (Score:3, Insightful)
Re:Not really new (Score:4, Insightful)
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.
Re:Not really new (Score:3, Insightful)
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.
Re:Not really new (Score:2, Insightful)
You've never actually held a real job, it would seem.
Re:Not really new (Score:3, Insightful)
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.