Archive for May, 2008

Did you know crossdomain.xml, introduced by Adobe Flash to allow cross-domain requests, is now supported by Java?

A similar mechanism is being standardized for XMLHttpRequest, and had been implemented in an early Firefox 3 beta (some extra work for your friendly neighborhood NS-Man), but ultimately dropped later in the development cycle...

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?

Yesterday Symantec elevated its ThreatCon rating as a response to an infection involving about 20,000 web pages (250,000 according to other sources), and probably still actively spreading through an automated SQL injection.

The main news is that this time an apparently unpatched vulnerability affecting Adobe Flash Player is being exploited, making the attack on end-users effectively cross-browser and potentially cross-platform:

The attack uses multiple layers of SWF redirection and generates URLs designed to target specific Flash version and browser combinations, supporting both Internet Explorer and Firefox.

The Adobe Product Security Incident Response Team reports of being aware of this problem and cooperating with the antivirus company for a precise assessment.

In the meanwhile, according to Symantec, you should:

Avoid browsing to untrustworthy sites. Consider disabling or uninstalling Flash until patches are available. Deploy script-blocking mechanisms, such as NoScript for Firefox, to explicitly prevent SWFs from loading on all but explicitly trusted sites. Temporarily set the kill bit on CLSID d27cdb6e-ae6d-11cf-96b8-444553540000 until patches availability is confirmed.

Additional notes for NoScript users

Since the offending SWF files are served from external ad-hoc Chinese domains, (wuqing17173.cn, woai117.cn and dota11.cn at this moment,very unlikely to be in your whitelist), even if a trusted site was infected you should still be protected.

However, if you want maximum protection, it's a good time to check NoScript Options|Plugins|Apply these restrictions to trusted sites as well.
This option turns NoScript in an effective security-oriented replacement of the FlashBlock extension, working also with Java, Silverlight and other potentially vulnerable plugins such as QuickTime.
All the active embedded content pieces, no matter where they come from, will be blocked preemptively and you will be able to load them selectively by clicking on visual placeholders.

Update

(from PSIRT's blog):

This exploit appears to be taking advantage of a known vulnerability, reported by Mark Dowd of the ISS X-Force and wushi of team509, that was resolved in Flash Player 9.0.124.0. We strongly encourage everyone to download and install the latest Flash Player update, 9.0.124.0.

Since the currently exploited vulnerability appears to be patched, but the attacking vector explicitly tests for the 9.0.124.0 player and can perform dynamic redirects, I'd obviously upgrade but still stay on the cautious side, deploying preemptive countermeasures just in case they're saving the real zero-day for a second weave...

I wonder why some people is so much shocked by what Cisco's Chief Security Officer John Stewart publicly stated two days ago:

If patching and antivirus is where I spend my money, and I'm still getting infected and I still have to clean up computers and I still need to reload them and still have to recover the user's data and I still have to reinstall it, the entire cost equation of that is a waste.

It's completely wasted money.

I'm sick of blacklisted stuff. I've got to go for whitelisted stuff — I know what that is because I put it there.

Needless to say, antivirus vendors are violently shaking their heads, and Cisco is not exactly super-partes, since it partially competes on the same enterprise security budgets. Also, I wouldn't go so far as saying that you shouldn't be patching your buggy software, or that a free antivirus scanner can't help preventing your mum from getting caught by opening that apparently innocuous PDF attachment, or that the new Firefox 3 anti-malware features are not be greeted as godsend...

But this pretty logical if not just obvious concept is not new at all, even if kept in the dark as a dirty secret -- maybe because you can't build a long-term subcription-based business model around it?
And you can't tell I'm a last-minute convert :)

A fresh FlashGot user emailed me yesterday asking for help: he had previously loaded thousands of URLs in FlashGet (the popular Chinese download manager), but later he found they were unusable for batch downloading because they where redirected through the anonym.to service: FlashGet was unable to follow the redirection and always downloaded the useless anonym.to interstitial page, instead of the real content.

He had mass-imported them before hearing of FlashGot, using Internet Explorer's "Download all by FlashGet" menu item. In facts, FlashGot automatically works around many kinds of redirection and "link protection" services, either simple like tinyurl.com, which just uses a 302 HTTP response, or quite complex like link-protector.com, which deploys a JavaScript-based obfuscation schema.
The best part, from my point of view at least, is that FlashGot doesn't need JavaScript to be enabled on the interstitial page, and does not execute any code embedded in the redirecting page itself, therefore it plays nice with NoScript and prevents users from meeting invasive ads, popups or even malware.
In the anonym.to case, we've got a META refresh, whose main task is hiding the REFERER header, thus "anonymizing" the navigation path. FlashGot handles this situation gracefully, stripping away the header as intended, parsing the destination URL and sending it to the download manager.
But since these "thousands of URLs" had not been collected through FlashGot, and since download managers usually don't parse the content they download, FlashGet could not "see" the META refresh and stopped on the anonym.to page, rather than reaching the real destination.

So this user wanted me to use my supposed knowledge of FlashGet internals to "hack" its database and replace the anonym.to URLs with the actual target addresses "post mortem", since in the meanwhile the page where he had grabbed the links originally had disappeared from the web, so he couldn't use "FlashGot Selection" anymore.
I frankly don't own that knowledge, nor I was in the spirit of hacking a closed binary file format -- not for this purpose, at least: FlashGet is a proprietary software not affiliated to FlashGot, the open source Firefox extension which supports several download managers, and incidentally FlashGet itself -- right, right, I'll never curse enough my name-choosing skills...

But luckily enough, there's a fairly easy and general solution to this problem, thanks to the very simple structure of anonym.to URLs. They always come in the form

http://anonym.to?http://www.destination-site.com

, therefore they can easily be rewritten on the fly by a local proxy.
So I instructed him to do the following:

  • Download Muffin, a quite old but handy open source visual HTTP proxy. No installation needed, just put the JAR file in a writable folder of its own and click it, provided that you've got Java installed.
  • Open Muffin's Edit|Filters menu item.
  • Select Rewrite on the top list and click the Enable button.
  • Select Rewrite on the bottom list and click the Preferences button
  • Add the following rule:
    \?.*(https?://.*) $1
  • Click Apply and Save.
  • Configure your download manager to use Muffin. In FlashGet, FlashGet|Tools|Preferences|Proxy|Add, Title "Muffin", Server "localhost", port "51966", type "HTTP", "Always use default proxy".

I kept the rewrite rule extremely generic, working with every kind of redirected links having the destination HTTP URL somewhere in their query string -- not just anonym.to.
Of course, this trivial trick can also work with any other download manager supporting proxies, i.e. all the ones I know.
Happy downloads!

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