The Attack

Let’s get the details out of the way so that we can wander over to the hand waving. The attacks involved a technique knows as SQL injection. For those of you that usually skip over tech details, fast-forward the next two paragraphs. SQL injection involves taking advantage of the way in which SQL statements are executed on the database by the web application, a more detailed breakdown is available after the article. A SQL injection usually means that an attacker can take near full control of the database, the machine hosting it and any applications using the database as a backend.

In this instance, the bad guys were using Google to search for vulnerable web sites, then injecting Microsoft SQL specific statements to insert a remote JavaScript include to the end of every table. This has a good chance of getting that JavaScript inserted into any web pages that are pulling their content from a database (i.e. most of them). When a user visits an infected page, the JavaScript would then try and break into it by using a variety of attacks against outdated versions of iTunes, AIM, RealPlayer, Acrobat Reader, Shockwave Flash among others. Once successful, some form of malicious software is installed to the user’s computer, most commonly a password stealer. Once an injection has occurred, the attacker can vary what it does to users. So, if your anti-virus program updates to detect the evilware, the bad guy can just change it and is more likely to be able to rapidly modify his app than the anti-virus guys are able to discover, analyse and block it. Although, we did not see too much of the latter stuff.

To summarise the attack:
Search Google -> SQL Injection on Web Site -> User Visits Website -> User’s Computer is Infected -> Bad Guys Steal User’s Passwords -> Bad Guys Steal User’s Money

In the security world this attack falls squarely into the category of ‘lame’. What I mean is, they did nothing complex for which there aren’t good, easy to implement solutions. Searching Google for potentially vulnerable sites is in this case not even targeting the low hanging fruit, closer to the old rotten fruit slowly dying around the base of the tree. Using SQL which only works against MS SQL, when SQL as a language is generic enough to craft something that works against Oracle, PostGres, Sybase and MySQL. Using the injection point to squirt in some JavaScript and ‘wasting’ the full power of SQL injection. Exploiting vulnerabilities in applications for which updates have already been released to fix them and a decent anti-virus program should pick up. Stealing something as simple as a password instead of doing something incredible like injecting an advanced rootkit that makes your Second Life character look like Michael Jackson. Finally, using single domains with no fast-flux survivability like those infuriating bot-herder, is all just boring. Then again, criminals do not need to be innovative when it is this easy.

The Outcome

These attacks have been wildly successful. Without using any of the advanced techniques we have seen botnet developers put together over the last year, or any decent ‘worm-like’ activity, they managed to hit 3.5 million web pages. In addition, they are not done yet. It seems tools are being distributed to do this stuff for you, and they only cost a few Yuan. It is more likely that we’ve seen so many successful attacks because the costs of running them are so low, and there are a few hundred people doing it. Whenever we see attacks that are successful and easy to do, they tend to continue for the next couple of months or years until they stop being successful. In short, expect more of these, and expect them to get more advanced.

The Response

The response has not been very varied from the South African online practitioners. Most of the time, when I contacted the developers, they knew about the problem and were working on it. This consisted of removing that instance of the infected web page, which was shortly re-infected. Worse still, often only the ‘known’ infected web pages were cleaned, so an organisation may have had 10 pages infected, but only cleaned 7 because they had not see the others.

However, the ‘real’ impact of something like this is not at a technical level, this has the potential to affect the business. There’s a real risk to the business’ reputation; most want to be known as safe, honest, well controlled companies; hosting viruses on behalf of Chinese bad guys does not reconcile well with that. There is a legal and compliance risk, whether it is industry mandated compliance such as Sarbanes Oxley and the Payment Card Industry’s Data Security Standard or legislative requirements such as the up-coming Protection of Personal Information Act, the risks of non-compliance in these cases, or worse, legal action arising from it, can be quite dire. Finally, there is a financial risk, especially from web sites that rely on their online presence. Some of the affected media organisations, where having Google mention that ‘this site may harm your computer’, could have their ad revenue seriously dented along with their readership. However, right now, this just sounds like fear mongering, as we have not seen any of this happen. Maybe it still will, but it doesn’t seem that many of the affected company’s IT management have got wind of this, or we wouldn’t have seen the fix-the-symptom patch-ups we have, and I am fairly certain there are no CFOs losing sleep over this.

The hand waving

The conclusion I draw from all of this is that, at least in the large corporate space, no one important in South Africa really cares about the Web. The companies are not too worried that this will amount to any sort of real risk to them, and users are mostly too clueless about security to realise, let alone protest, the fact that their favourite radio station’s website is trying to steal their passwords. Worse still, the new importance-making-push into Web 2.0 is going to exacerbate this security problem, as a new wave of more complex and poorly secured tech washes over the IT industry. In the meantime, watch this space and if you are lucky enough to have not been infected because you were not using Microsoft’s SQL server (make no mistake, it was luck), start getting your devs trained up in writing secure code.

Appendix

SQL injection involves taking advantage of the way in which SQL statements are executed on the database by the web application. If, for example, you have an input field asking me for my name, and slap my input into a piece of SQL such as:

INSERT INTO names VALUES ('Dominic'); 

Then, if I enter my name as: Dominic’); DROP TABLE names;– , the resulting SQL statements becomes:

INSERT INTO names VALUES ('Dominic'); DROP TABLE names; --'); 

The name will be inserted, but the database will also delete the entire table. This is a fairly tame example, and in reality, a SQL injection usually means that an attacker can take near full control of the database and the machine hosting it.

The ‘right’ way to defend against it is to use parameterised and pre-compiled SQL statements so that anything you input cannot ‘break out’ and run awry. It always pays to be safe, and so making sure the application account has minimum database privileges, the database has been securely configured and you have firewalled properly goes a long way to either stopping an attacker in their tracks or making it easier to spot them. Please note that ‘input validation’ is not the right way to stop this, and those expensive Intrusion Prevention Systems and Web Application Firewalls will not be able to either.

This was originally posted for TechLeader at the following URL.