European Parliament Kills Global Anti-Piracy Accord ACTA

European Parliament members applaud Wednesday’s vote defeating ACTA. Photo: European Parliament

The European Parliament on Wednesday declared its independence from a controversial global anti-piracy accord, rejecting the Anti-Counterfeiting Trade Agreement.

The vote, 478-39, means the deal won’t come into effect in European Union-member nations, and effectively means ACTA is dead.

Its fate was also uncertain in the United States. Despite the Obama administration signing its intent to honor the deal last year, there was a looming constitutional showdown on whether Congress, not the administration, held the power to sign on to ACTA.

Overall, not a single nation has ratified ACTA, although Australia, Canada, Japan, Morocco, New Zealand, Singapore and South Korea last year signed their intent to do so. The European Union, Mexico and Switzerland, the only other governments participating in ACTA’s creation, had not signed their intent to honor the plan.

More than three years in the making and open for signing until May 2013, ACTA exports on participating nations an intellectual-property enforcement regime resembling the one in the United States.

Among other things, the accord demands governments make it unlawful to market devices that circumvent encryption, such as devices that copy encrypted DVDs without authorization. That is akin to a feature in the Digital Millennium Copyright Act in the United States, where the law has been used by Hollywood studios to block RealNetworks from marketing DVD-copying technology.

ACTA, which the Obama administration maintains does not require Congressional approval, also calls on participating nations to maintain extensive seizure and forfeiture laws when it comes to counterfeited goods that are trademarked or copyrighted. Most important, countries must carry out a legal system where victims of intellectual property theft may be awarded an undefined amount of monetary damages.

In the United States, for example, the Copyright Act allows for damages of up to $150,000 per infringement. A Boston jury has dinged a college student $675,000 for pilfering 30 tracks on Kazaa, while a Minnesota jury has awarded the Recording Industry Association of America $1.5 million for the purloining of 24 songs online.

A U.S.-backed footnote removed from the document more than a year ago provided for “the termination” of internet accounts for online infringers.

Until European Union authorities began leaking the documents text more than a year ago, the Obama administration was claiming the accord was a “national security” secret.

Trojan.Milicenso: Infection through .htaccess Redirection

Due to additional research of the Trojan.Milicenso threat (a.k.a "Printer Bomb"), we have determined that the threat is downloaded by an .htaccess redirection Web attack and that at least 4,000 websites have been compromised by the gang responsible for the threat.
 

Redirection using the .htaccess file

The .htaccess file is a configuration file for Web servers that can be used by Web administrators to control network traffic, for example: restrict access to certain Web pages, redirect access from mobile devices to special sites, etc. In order to monitor network traffic to legitimate websites, attackers (and some exploit kits) break into vulnerable Web servers and modify the .htaccess file.

The following image illustrates the flow of .htaccess redirection.

Figure 1. Infection flow

  1. When a user clicks the link for the website, the Web browser accesses the compromised website.
  2. The Web server then redirects the access to a malicious website based on the .htaccess file.
  3. The malicious site may then download more threats onto the compromised computer by exploiting certain vulnerabilities.

The redirection that happens at #2 typically goes unnoticed and the user does not know what has happened behind the scenes in the browser.
 

The .htaccess file

Below is an image of a malicious .htaccess file. The attacker has inserted more than 800 blank lines at both the top and the end of the file in an attempt to avoid attracting attention from network administrators.

Figure 2. Overview of a modified .htaccess file

The configuration is also very carefully crafted in order to prevent exposure of infection by external users or researchers. Access to the compromised website will be redirected to a malicious website only if all of the following conditions are met:

  1. It is the first time that the website has been visited.
    Note: There is no redirection after the first visit.
  2. The website is visited by clicking on a link in search engine results, SNS, or email.
    Note: There is no redirection if the user visits the website from a bookmark or by pasting the URL into the browser address field.
  3. The threat is running on the Windows platform.
    Note: There is no redirection if the threat is running on any other platform.
  4. A popular web browser is being used.
    Note: There is no redirection for unconventional web browsers or search engines.

The attacker can track where the traffic comes from by inserting the original URL into the redirect request.

Figure 3. Configuration of a redirection to a malicious website in the .htaccess file.
 

Malicious websites

After examining the logs, we were able to determine that the gang has been using the .htaccess redirection technique since at least 2010. The following is a list of some of the latest malicious websites that we have observed:

  • [RANDOM DOMAIN NAME].tedzstonz.com
  • [RANDOM DOMAIN NAME].tgpottery.com
  • [RANDOM DOMAIN NAME].yourcollegebody.com
  • [RANDOM DOMAIN NAME].tgpottery.com
  • [RANDOM DOMAIN NAME].beeracratic.com
  • [RANDOM DOMAIN NAME].buymeaprostitute.com
  • [RANDOM DOMAIN NAME].zoologistes-sansfrontiere.com
  • [RANDOM DOMAIN NAME].zoologistes-sansfrontiere.com
  • [RANDOM DOMAIN NAME].buymeaprostitute.com
  • [RANDOM DOMAIN NAME].wheredoesshework.com
  • [RANDOM DOMAIN NAME].wheredidiwork.com
  • [RANDOM DOMAIN NAME].jordanmcbain.com
  • [RANDOM DOMAIN NAME].bankersbuyersguide.net
  • [RANDOM DOMAIN NAME].findmeaprostitute.com
  • [RANDOM DOMAIN NAME].watchmoviesnchat.com
  • [RANDOM DOMAIN NAME].joincts.info

The attacker changes the domain name often in order to prevent it from being blocked or blacklisted. In 2010 and 2011, the gang moved to a new domain every few months. But in 2012, they changed domains almost every day.
 

Compromised websites

Within the last three days, we have identified approximately 4,000 unique, compromised websites that redirect users to malicious websites. Most of the compromised websites are personal or SMB segment websites; but government, telecom, and financial service websites have also been compromised.

Figure 4. Compromised sites by TLD

The above image illustrates the TLD (top-level domain) of compromised websites. As usual, most of the infection occurs on the .com domain, followed by the .org and .net domains. Although there are over 90 countries from around the world in the list, countries in Europe and Latin America constitute the majority of the compromised sites. This is commensurate with the infection pattern for Trojan.Milicenso that was detailed in a previous post.
 

Mitigation

For Web administrators
Symantec antivirus products detect the malicious .htaccess file as Trojan.Malhtaccess. Delete the malicious .htaccess file, replace it with a known clean backup, and apply patches to all Operating Systems and Web applications, including CMS.

For Users
Further to antivirus signatures listed in the previous post, we have also created the new IPS signature 25799: Web Attack: Malicious Executable Download 6, which protects you from the malicious redirection.

As described in the latest ISTR, the Web-based attack is still a highly active infection vector, which attackers persist in exploiting. Symantec is monitoring these malicious activities and continues to provide protection to all of its customers.

Chrome 20 on Linux and Flash sandboxing

[Very behind on blog posts so time to crank some out]

A week or so ago, Chrome 20 was released to the stable channel. There was little fanfare and even the official Chrome blog didn't have much to declare apart from bugfixes.

There were some things going on under the hood for the Linux platform, though. Security things, and some of them I implemented and am quite excited by.

The biggest item is an improvement to Flash security. Traditionally, Linux -- across all browsers -- hasn't had great Flash security, due to lack of sandboxing options. That just changed: so-called Pepper Flash shipped to the stable channel on Linux with Chrome 20 (other platforms to follow real soon). I went into a little detail about the technical sandbox measures in Pepper Flash for Linux in an older blog post.

As mentioned in the previous blog post, native 64-bit Flash also gives a useful security boost on 64-bit Linux platforms.

There's more. Perhaps you're running 64-bit Ubuntu 12.04? Courtesy of Kees Cook, this release sneaked in Will Drewry's seccomp filter patches, which I blogged about earlier this year in the context of vsftpd-3.0.0's usage of seccomp filter sandboxing.

So why have just one Flash sandbox if you can have two? A bit of double-bagging if you like. Assuming you're running 64-bit Ubuntu 12.04 and Chrome 20 or newer, you'll also have a seccomp filter policy slapped on Flash -- in additional to the chroot() and PID namespace. This may impede attackers trying to perform a local privilege escalation, who can no longer call crazy brand-new syscalls or use socket() to load crazy protocol modules, etc.

No sandbox or combination of sandboxes will ever be perfect, but "some" is better than "none". For people who want to run Flash, Chrome 20 on 64-bit Ubuntu 12.04 is one of the more locked-down ways to do it.