Over the last few weeks, we have seen a set of incredibly
uncomplicated and simple attacks effectively compromise several hundred
South African web pages, and several million internationally. Many of
the South African sites compromised were important; including major
media organisations, several government institutions, large mining
houses and even one information security company, who still have not
removed the pie from their face. The intention of the attacks was to
use the compromised web pages to infect visitors with a variety of
malware, but most commonly, a trojan which attempts to steal as many
passwords as it can, including specific references to some internet
banking sites.
The response to the incident from both consumers and the affected
companies seems to indicate that when it comes to the web in South
Africa, nobody cares.
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.