Submitted by Last week, The Washington Post reported that hundreds of thousands of IIS webservers were hacked. Code was placed on them that installed malware on visitors’ computers. Among the infectees were websites from the UK government and the United Nations. Initial reports said the attackers used a security vulnerability in Microsoft’s IIS, but the company published more information on the attacks today, and denies IIS was compromised.In an entry on Microsoft’s IIS Blog, Bill Staples explains that despite earlier reports online, the attacks are not related to Security Advisory 951306 or any other security flaw in Microsoft’s IIS 6.0, ASP, ASP.Net or Microsoft SQL technologies. Instead, the crackers used automated SQL injection attacks.
Instead, attackers have crafted an automated attack that can take advantage of SQL injection vulnerabilities in web pages that do not follow security best practices for web application development. While these particular attacks are targeting sites hosted on IIS web servers, SQL injection vulnerabilities may exist on sites hosted on any platform.
Staples links to various websites that give more information on SQL injection attacks, and how to shield yourself from them. In addition, the IIS.net website follows the issue and provides more information as the case develops.
Microsoft’s investigation revealed no unpatched security holes in IIS, SQL Server, Internet Explorer or any other Microsoft client software, so end-users should just install all the latest patches to shield themselves from these attacks.
So stupid title!!!
When IIS suddenly became a “sql server” to manage SQL queries!?!?!
Only stupid “developers” can allow “sql injection attack”.
Always Sanitize Input
I can imagine the IT weekly article:
Businesses: sanitise your programmers!
Two words: stored procedures
Three words: No dynamic SQL
Two words: stored procedures
Two words: Not necessarily.
Three words: No dynamic SQL
Two words: Unless parameterized.
Actually the solution is simple: Always use parameterized queries. Never ever ever use string concatenation. Not everyone is a fan of sprocs, and they’ve actually fallen out of favor more lately now that ORM’s are more mainstream and easier to use.
It’s funny, I was reviewing some of our coding policy docs the other day (basically a 200+ page ppt), one of the many gems I found in it was “Treat all input as evil”.
I want that on a shirt.
Edited 2008-04-28 23:34 UTC
Or – at the *very* least – create a DB user with read-only permissions for the publicly-accessible portions of a web-based app (no write privs. == injection no worky).
The first comment posted on the article already explains the whole issue at hand:
By default this tool searches for Microsoft ASP pages (an IIS specific web development technology) and injects a Microsoft SQL Server specific payload: these defaults, maybe, have generated the false perception that an IIS vulnerability is involved, while the infection is just leveraging trivial coding errors made by the web developers.
So, perhaps some poor default values combined with not-so-good programming caused this. It’s not specifically IIS bug or anything like that at all. Switching to Linux and using Apache won’t help either if you can’t make your code secure. So, remember all web devs out there: ALWAYS check any variables you pass to SQL server that they are fully valid and will not contain any intended characters there.
whats sad is that you don’t even have to. Use parameterized queries or stored procs and the framework will do the checking for you.
There is simply no excuse in the asp world for “SELECT ” + fields + ” FROM Tables” anymore.
I love these Chinese.
I have a suggestion for them:
Make a virus that will completely destroy the infected Windows server after infecting other servers, of course.
Imagine how many will sue Microsoft over data and hardware loss!
It would be awesome!
Microsoft has clauses in their EULA’s that explicitly prohibit anyone suing them for data loss. Actually, almost ALL software/hardware vendors have these clauses, so don’t go thinking they are unique to MS. And don’t think you’re protected if you live in Europe or whatnot. Imagine all the bogus claims that would be made if those clauses didn’t exist.
And this is what I have a real problem with – why should they be protected? If they have produced a flawed product, that results in a loss to me, or my business, they *should* be responsible. Period. Imagine if you bought a new Ford, and due to manufacturing issues the steering wheel collapsed and crashed as a result – you *can* sue Ford for damages etc.
Why should software companies not have the same laws applied to them that every other consumer manufacturer has to agree to?
Dave
And why do you think they don’t? If software causes you tangible harm or loss, you have the same legal recourse as for any other product. EULAs are not a shield against that, in fact, they’re not a shield against much, really.
The same rules apply, you simply need to show a direct cause-effect relationship between the product and your damage, and quantify that damage. The problem is that when it comes to software, that is easier said than done, but it’s doable. Software manufacturers operate under the same laws as every other manufacturer, an EULA doesn’t absolve them of responsibility.
Not from what I see. See Thom’s article on Dutch laws and how EULAs are considered contracts under Dutch law. If you sign that contract saying you won’t sue, then you’re screwed. I suspect a great deal many countries will be the same as the Netherlands, caring more for the big corporations and rich, and bugger all for the average person.
Dave
Why would you assume the people behind these attacks are actually Chinese? Just because the websites that host the vulnerabilities are in China doesn’t mean the people who put those there are as well.
We’re talking about crackers here – they’re not likely to just throw up their malicious code on any old domain they happen to own.
If the issue is that someone attacked the server an injected code into the MS-SQL server, then how are the client systems being infected?
The best I can see is that they injected code to turn on a back door so they could modify the web-server.
Thus the security issue is also on the client pc’s. They are allowing a web site to install anything the server wants on their pc. SQL Injection shouldn’t work on the client since the DB is located on the server.
What types of clients are being infected? And since MS verified that it was a server issue, what is MS’s advice on how to protect the client from the servers?
The client injection is caused by javascript code that’s injected into the database. In other words…
1. SQL injection puts Javascript into he database
2. Injected database content is shown on the page
3. Javascript opens windows with malware
So, the client injection part of this could have been stopped if the web sites used proper HTML encoding of the database output.
Can this occur through both Mozilla and IE or is it just limited to IE?
The issue is with a server-side “exploit”, it has nothing to do with the client browser. You could hack together a script to do the same thing, without even using a browser. The issue is lazy coding on the part of the web developers, it’s not a browser issue.