Apr 30 2012

Targeting ZeroAccess Rootkit’s Achilles’ Heel

Proliferation

ZeroAccess is one of the most talked and blogged,[1][2] about rootkits in recent times. It is also one of the most complex and highly prevalent rootkits we have encountered, and it is continuing to evolve. The ZeroAccess rootkit is distributed via both social engineering as well as by exploitation. A recent blog post by our colleagues at McAfee describes some of the odd methods this rootkit adopts to get installed on machines without getting noticed.

One of the goals of this rootkit is to create a powerful peer-to-peer botnet, which is capable of downloading additional malware on the infected system. This botnet is reportedly [3] involved in click fraud, downloading rogue antivirus applications, and generating spam.

This Google map of the United States shows McAfee VirusScan consumer nodes reporting unique ZeroAccess detections during the past week.

Our consumer data for the past month shows close to 4,000 unique systems detecting ZeroAccess daily. And the trend is continuing upward.

Installation

In my recent analysis of this rootkit, I wanted to understand its initial installation mechanism. The installation of ZeroAccess involves overwriting a legitimate driver on disk with the malicious rootkit driver. Usually Step 1 varies in different variants. Some variants directly overwrite a legitimate driver and others first inject the malicious code in trusted processes like explorer.exe and then, from the injected code, overwrite the driver (this is done to bypass various security products and to make analysis more challenging). During Step 1, the original driver code is kept in memory. The driver that is overwritten in Step 2 is randomly selected (details here[1]). In our discussion below we assume CDROM.sys is being overwritten. Step 2 to Step 8 are fairly static in variants of ZeroAccess. Once the driver is overwritten by malicious code, it is loaded in kernel space. The first task of the kernel mode code is to ensure that it sets up the malware to survive reboots and to forge the view of overwritten driver (CDROM.sys).

Lets move on to see how this scheme works in Step 5 through Step 8. In Step 5,  ZeroAccess intercepts disk i/o by hooking the DeviceExtension->LowerDeviceObject field in the \driver\disk DEVICE_OBJECT. So now any disk i/o would go through the rootkit’s malicious routine. In Step 6, the kernel mode code has access to a clean image of the CDROM.sys driver stored in memory. To survive reboots it flushes the file to disk using the ZwFlushVirtualMemory API. The request to flush the clean image is, interestingly, sent to the file CDROM.sys, which at first glance looks counterintuitive. Why would the rootkit want to write the clean image to the file it just infected in Step 2?  Looking more closely, the rootkit actually uses its disk i/o redirection framework. So, when this request to store the clean image of the file on disk travels through the virtual driver stack shown in Step 7, it is encrypted and redirected (Step 8) to the rootkits “protected” folder that it created in Step 3, instead of going to the actual CDROM.sys.

 

 

Once the original encrypted image of CDROM.sys is stored in the protected folder, the infection becomes persistent and can easily survive reboots. Any attempt to read the infected CDROM.sys would have to traverse the hijacked i/o path, in which the rootkit on the fly decrypts the original file from its protected storage and presents the clean image, thus forging the view of the file to security tools. Also, during a reboot the infected file would first load the malicious code in kernel, which can refer to its “protected” folder, and load the original file in kernel, thus ensuring the uninterrupted functionality of the original device.

To clean this threat, security tools have to take several steps in repairing either memory or decrypting the file in its protected folder so that they can restore the original file. Also once the rootkit is active in kernel mode, it takes lot of evasive steps to kill or circumvent the security tools as described by our colleagues in this Virus Bulletin article. So repair becomes even more challenging and research more costly.

 

Impact of real-time kernel monitoring

I tested for more than a year many variants of this rootkit family against McAfee’s Deep Defender technology, which provides real-time protection against unauthorized kernel-memory modifications. The following screenshot shows Deep Defender blocking the DeviceExtension hijack attempt in Step 5, which was critical to the rootkit’s survival. Once this hook was blocked, the machine was cleaned after a reboot, without any fancy repairs. This move shaved off days of reverse engineering and writing custom repairs against this rootkit and its multiple variants. It seems Deep Defender has found the Achilles heel of this rootkit.

 

How did Deep Defender clean the machine?

You did not miss part of this article. The interesting point is that Deep Defender did not have to do any custom repairs to clean this threat. It just blocked in real time the core functionality of the rootkit. Let’s revisit the attack strategy to understand what happened.

 

 

When the rootkit attempted to hijack the DeviceExtension pointer in Step 5, Deep Defender’s real-time kernel-memory protection saw the attempted change and recognized it as a malicious attempt to modify a critical structure and blocked the hijack attempt. With the hook gone, the rootkit could not hijack the disk i/o path, which means it could not store any files in its “protected” folder and could not survive any reboots without getting noticed. It certainly cannot forge the view of the file anymore. But the most interesting part is that the attempted hijack block by Deep Defender actually redirected the rootkit’s write attempt in Step 7 to its original location. So Step 8 would actually overwrite the original file that it just infected from user mode, thus forcing the rootkit to clean up for us. After a reboot, the system will be back in the clean state.

This strategy from Deep Defender works against all the current  ZeroAccess variants. It would be challenging for the rootkit authors to fully bypass this defense without either leaving the system in a corrupted state or being noticed by security tools, which would catch them red handed if they could no longer forge the view of the file.

 

Apr 30 2012

Congress Should Grill the FCC Over Redacted Google Wi-Fi Snooping Report

Google released a mostly uncensored version of the FCC’s report on the Street View privacy debacle over the weekend, and the new revelations in the document will undoubtedly prompt privacy groups and Congress to demand further investigations and sanctions. And justifiably so. The full FCC report reveals that Google’s systematic interception of Wi-Fi content was intentional, and not the “mistake” that senior executives have repeatedly claimed in the past.

But while Google should certainly be raked over the coals by privacy hawks on Capitol Hill, I don’t think Congress should stop there. The FCC must be next in line.

Chris Soghoian

For several years, Google has repeatedly insisted that the capture of payload data by the company was unbeknownst to them, the work of a single engineer acting on his own initiative. The FCC report (.pdf) states, however, that the code “was deliberately written to capture payload data” and that the engineer who wrote it (in his 20% time), told several colleagues about its capabilities — including, in writing, a senior manager.

None of those details emerged when the FCC first released its post-investigation report two weeks ago. That’s because the FCC opted to use page-long black redaction boxes — the kind commonly seen in CIA torture memos – to bury those sections of the report, keeping the public from learning about the extent to which Google had lied about its deliberate collection of Wi-Fi content data.

The FCC’s redactions led the media to focus on far less important issues, such as the number of seconds that it would take Google to pay off the pathetic $25,000 fine the FCC levied for Google’s reluctance to cooperate in the investigation, and the fact that the still-unnamed engineer invoked his 5th Amendment rights.

The FCC redacted the most incriminating portions of its report on Google's Wi-Fi sniffing (top). Google wound up releasing the redacted text itself (bottom). Click for full size.

The media didn’t screw up. It was essentially misled by a federal agency, which for some reason found it necessary to shield Google’s reputation.

Google ultimately decided to publish the more complete version of the report this weekend (initially via an exclusive provided to the Los Angeles Times), just a few days after the Electronic Privacy Information Center, a Washington, D.C. public interest group, filed a Freedom of Information Act request with the FCC for a copy of the full report. Had the group not filed the request and forced Google’s hand, the public still might not know the full story.

The FCC can and should have told the public

Now that Google’s prior statements have been shown to be less than truthful, I’m sure that some advocates will criticize the FCC for shuttering its investigation.

I won’t do this. It is quite possible that the FCC staffers quoted anonymously by the New York Times  are correct in their belief that outdated U.S. electronic privacy laws do not provide the FCC with sufficient legal authority to go after a company that intercepts Wi-Fi payload data.  My own former employer, the Federal Trade Commission, similarly closed its own investigation into Google’s Wi-Fi snooping with a mildly worded letter (.pdf). Although I was not permitted to work on the investigation due to a conflict, it is my personal belief that the FTC’s narrow “unfairness” and “deception” authority left it without a legal hook to go after Google for this particular privacy violation, and the FCC might well be in a similar position.

However, even if the FCC lacked the legal authority punish Google, nothing prevented the agency from alerting the public, the media, and Congress to the full extent of Google’s sins. Instead, the agency opted to keep the public in the dark.

The FCC has yet to reveal the reasons why it opted to so heavily redact the most damning portions of the Google WiFi report. Congress should not wait for the FCC to volunteer an explanation. It should demand answers.

Photo: dspain/Flickr

Apr 30 2012

Equipment Maker Caught Installing Backdoor Vows to Fix Following Public Pressure

A RuggedCom switch and server (shown on either side of the electrical outlet) have a manufacturer-installed backdoor in their operating systems. Photo: Courtesy Justin W. Clarke

After ignoring a serious security vulnerability in its product for at least a year, a Canadian company that makes equipment and software for critical industrial control systems announced quietly on Friday that it would eliminate a backdoor login account in its flagship operating system, following public disclosure and pressure.

RuggedCom, which was purchased recently by German-conglomerate Siemens, said in the next few weeks it would be releasing new versions of its RuggedCom firmware in order to remove the backdoor account in critical components used in power grids, railway and traffic control systems, as well as military systems.

The company also said in a press release that the update would disable telnet and remote shell services by default. The latter were two communication vectors that would allow an intruder to discover and exploit a vulnerable system.

Critics say the company should never have installed the backdoor, which was exposed last week by independent security researcher Justin W. Clarke, and has, as a result, exhibited no evidence of security awareness in its development process, raising questions about other problems its products may contain.

“This ‘developer backdoor’ made it into release,” wrote Reid Weightman, a security researcher with Digital Bond, a company that focuses on industrial control system security, in a blog post on Monday. “Nobody and no process at RuggedCom stopped it, and RuggedCom has no process to address security concerns in already-released products. They were not going to fix it at all until Justin went full disclosure.”

Clarke, a San Francisco-based researcher who works in the energy sector, discovered the undocumented backdoor last year in the RuggedCom operating system after purchasing two used RuggedCom devices – an RS900 switch and an RS400 serial server – on eBay for less than $100 each and examining the firmware installed on them.

Clarke discovered that the login credentials for the backdoor included a static username, “factory,” that was assigned by the vendor and couldn’t be changed by customers, and a dynamically generated password that is based on the individual MAC address, or media access control address, for any specific device. He found that the password could be easily uncovered by simply inserting the MAC address, if known, into a simple Perl script that he wrote.

Clarke notified RuggedCom of his discovery in April 2011. A company representative told him that RuggedCom was already aware of the backdoor, but then stopped communicating with him about it. Two months ago, Clarke reported the issue to the Department of Homeland Security’s Industrial Control System Cyber Emergency Response Team and the CERT Coordination Center at Carnegie Mellon University.

Although CERT contacted RuggedCom about the vulnerability, the vendor was unresponsive.

That is, until Clarke threatened to go public with information about the backdoor. RuggedCom then asserted on Apr. 11 that it needed three more weeks to notify customers, but gave no indication that it planned to fix the backdoor vulnerability by issuing a firmware upgrade.

Clarke told the company he would wait three weeks if RuggedCom assured him it planned to issue an upgrade that would remove the backdoor. When the company ignored him, he took the information public on Apr. 18, by posting information about the backdoor on the Full Disclosure security list.

RuggedCom failed to respond to reporter inquiries last week about the issue, but quietly issued its press release late Friday, detailing which versions of the firmware are vulnerable and what it planned to do to fix them.

Wightman criticized the company for failing to acknowledge the trouble the backdoor creates for customers who now have to upgrade their firmware to eliminate the vulnerability it created.

“This is bad because RuggedCom’s product is not software, it is hardware and firmware,” he wrote in a blog post. “Upgrading a field-deployed device like this is expensive and can only be done at a time when entire networks of end devices (PLCs, RTUs, relays, etc) can be offline. That is not often. It is a cost that is passed on to RuggedCom’s customers in downtime and risk….”

Dale Peterson, founder and CEO of Digital Bond, said the company needs to provide more explanation to customers about what happened.

“They really need to talk about how this is not going to happen again,” he said. “How did the feature get into the product and why was the [initial] response like it was?”

Peterson, who refers to RuggedCom as the “Cisco of network infrastructure equipment” due to its core role in critical systems, said that because RuggedCom refused to address the issue for a year, other researchers are now taking a look at the company’s products to uncover more vulnerabilities.

“I’m already aware of a couple of [other] RuggedCom vulnerabilities,” he said. “When people see something so blatant and such a disregard for dealing with it, they say, ‘Well, there’s got to be other stuff in here.’ So there’s already people looking at it and things found.”

RuggedCom, on Monday, referred inquiries about its press release to Siemens. Siemens did not immediately respond to questions.

Clarke said in an e-mail to Threat Level that he hoped the incident “makes other vendors realize they need to participate when responsible coordinated disclosure is attempted. Sadly, I doubt this will be the turning point.”

Apr 30 2012

British ISPs Ordered to Block The Pirate Bay

United Kingdom internet service providers must block The Pirate Bay, that nation’s High Court said Monday.

Major record labels, including EMI and Sony, sued the country’s major ISPs claiming they must prevent access to the world’s most notorious file-sharing site because it was facilitating the infringement of its copyrights.

The development comes three months after Sweden’s Supreme Court upheld the prison sentences of the four founders of The Pirate Bay, which has been on Hollywood’s and the recording industry’s most-hated lists following its 2003 inception.

However, it’s not likely the latest blockade order will be effective. The Pirate Bay has been playing a game of cat and mouse with government orders to block access for years. It usually always perseveres and is one of the world’s most heavily trafficked sites, pointing users to free games, music, movies and software, including those uploaded intentionally by their own creators.

Even an order for a Swedish ISP to block access to the Swedish site proved futile.

A proposal in the U.S. Senate, known as SOPA, that would have given the Justice Department the ability to force ISPs to block citizens from visiting sites deemed to be facilitating copyright infringement was sidelined after an angry coalition of internet users and tech companies killed the legislation with an online protest in January.

In response to the High Court’s order giving ISPs weeks to block access, a Pirate Bay “spokesperson” told TorrentFreak that circumventing any blockade will be easy.

“This will just give us more traffic, as always. Thanks for the free advertising,” the spokesperson said.

The United Kingdom’s Pirate Party said it would offer a reverse proxy to enable blocked users to reach The Pirate Bay. Users would also be able to circumvent any ISP blocking by using a VPN service or going to any number of sites that also have lists of torrent files. The order does not cover the bittorrent protocol, just The Pirate Bay’s website.

Virgin Media, a U.K. internet service provider, said the industry should work to change “consumer behavior” to cut down on infringement.

“As a responsible ISP, Virgin Media complies with court orders addressed to the company but strongly believes that changing consumer behavior to tackle copyright infringement also needs compelling legal alternatives, such as our agreement with Spotify, to give consumers access to great content at the right price,” Virgin said.

The affected ISPs include Everything Everywhere, O2, Sky, TalkTalk and Virgin Media, which all must prevent their users from accessing the site.

Geoff Taylor, the British Recorded Music Industry chief executive, said The Pirate Bay, which makes money via advertising, lines “their pockets by commercially exploiting music and other creative works without paying a penny to the people who created them.”

Photo: m.a.r.c./Flickr