Entries Tagged "rootkits"

Page 2 of 3

How Antivirus Companies Handle State-Sponsored Malware

Since we learned that the NSA has surreptitiously weakened Internet security so it could more easily eavesdrop, we’ve been wondering if it’s done anything to antivirus products. Given that it engages in offensive cyberattacks—and launches cyberweapons like Stuxnet and Flame—it’s reasonable to assume that it’s asked antivirus companies to ignore its malware. (We know that antivirus companies have previously done this for corporate malware.)

My guess is that the NSA has not done this, nor has any other government intelligence or law enforcement agency. My reasoning is that antivirus is a very international industry, and while a government might get its own companies to play along, it would not be able to influence international companies. So while the NSA could certainly pressure McAfee or Symantec—both Silicon Valley companies—to ignore NSA malware, it could not similarly pressure Kaspersky Labs (Russian), F-Secure (Finnish), or AVAST (Czech). And the governments of Russia, Finland, and the Czech Republic will have comparable problems.

Even so, I joined a group of security experts to ask antivirus companies explicitly if they were ignoring malware at the behest of a government. Understanding that the companies could certainly lie, this is the response so far: no one has admitted to doing so.

Up until this moment, only a handful of the vendors have replied ESET, F-Secure, Norman Shark, Kaspersky, Panda and Trend Micro. All of the responding companies have confirmed the detection of state sponsored malware, e.g. R2D2 and FinFisher. Furthermore, they claim they have never received a request to not detect malware. And if they were asked by any government to do so in the future, they said they would not comply. All the aforementioned companies believe there is no such thing as harmless malware.

Posted on December 2, 2013 at 6:05 AM • View Comments

badBIOS

Good story of badBIOS, a really nasty piece of malware. The weirdest part is how it uses ultrasonic sound to jump air gaps.

Ruiu said he arrived at the theory about badBIOS’s high-frequency networking capability after observing encrypted data packets being sent to and from an infected machine that had no obvious network connection with—but was in close proximity to—another badBIOS-infected computer. The packets were transmitted even when one of the machines had its Wi-Fi and Bluetooth cards removed. Ruiu also disconnected the machine’s power cord to rule out the possibility it was receiving signals over the electrical connection. Even then, forensic tools showed the packets continued to flow over the airgapped machine. Then, when Ruiu removed internal speaker and microphone connected to the airgapped machine, the packets suddenly stopped.

With the speakers and mic intact, Ruiu said, the isolated computer seemed to be using the high-frequency connection to maintain the integrity of the badBIOS infection as he worked to dismantle software components the malware relied on.

“The airgapped machine is acting like it’s connected to the Internet,” he said. “Most of the problems we were having is we were slightly disabling bits of the components of the system. It would not let us disable some things. Things kept getting fixed automatically as soon as we tried to break them. It was weird.”

I’m not sure what to make of this. When I first read it, I thought it was a hoax. But enough others are taking it seriously that I think it’s a real story. I don’t know whether the facts are real, and I haven’t seen anything about what this malware actually does.

Other discussions.

EDITED TO ADD: More discussions.

EDITED TO ADD (11/14): A claimed debunking

Posted on November 4, 2013 at 6:15 AM • View Comments

TDSS Rootkit

There’s a new version:

The latest TDL-4 version of the rootkit, which is used as a persistent backdoor to install other types of malware, infected 4.52 million machines in the first three months of this year, according to a detailed technical analysis published Wednesday by antivirus firm Kaspersky Lab. Almost a third of the compromised machines were located in the United States. With successful attacks on US-based PCs fetching premium fees, those behind the infections likely earned $250,000 on that demographic alone.

TDL-4 is endowed with an array of improvements over TDL-3 and previous versions of the rootkit, which is also known as Alureon or just TDL. As previously reported, it is now able to infect 64-bit versions of Windows by bypassing the OS’s kernel mode code signing policy, which was designed to allow drivers to be installed only when they have been digitally signed by a trusted source. Its ability to create ad-hoc DHCP servers on networks also gives the latest version new propagation powers.

Posted on July 1, 2011 at 12:08 PM • View Comments

Forged Memory

A scary development in rootkits:

Rootkits typically modify certain areas in the memory of the running operating system (OS) to hijack execution control from the OS. Doing so forces the OS to present inaccurate results to detection software (anti-virus, anti-rootkit).

For example rootkits may hide files, registries, processes, etc., from detection software. So rootkits typically modify memory. And anti-rootkit tools inspect memory areas to identify such suspicious modifications and alarm users.

This particular rootkit also modifies a memory location (installs a hook) to prevent proper disk access by detection software. Let us say that location is X. It is noteworthy that this location X is well known for being modified by other rootkit families, and is not unique to this particular rootkit.

Now since the content at location X is known to be altered by rootkits in general, most anti-rootkit tools will inspect the content at memory location X to see if it has been modified.

[…]

In the case of this particular rootkit, the original (what’s expected) content at location X is moved by the rootkit to a different location, Y. When an anti-rootkit tool tries to read the contents at location X, it is served contents from location Y. So, the anti-rootkit tool thinking everything is as it should be, does not warn the user of suspicious activity.

Posted on May 6, 2011 at 12:32 PM • View Comments

Protecting OSs from RootKits

Interesting research: “Countering Kernel Rootkits with Lightweight Hook Protection,” by Zhi Wang, Xuxian Jiang, Weidong Cui, and Peng Ning.

Abstract: Kernel rootkits have posed serious security threats due to their stealthy manner. To hide their presence and activities, many rootkits hijack control flows by modifying control data or hooks in the kernel space. A critical step towards eliminating rootkits is to protect such hooks from being hijacked. However, it remains a challenge because there exist a large number of widely-scattered kernel hooks and many of them could be dynamically allocated from kernel heap and co-located together with other kernel data. In addition, there is a lack of flexible commodity hardware support, leading to the socalled protection granularity gap ­ kernel hook protection requires byte-level granularity but commodity hardware only provides pagelevel protection.

To address the above challenges, in this paper, we present HookSafe, a hypervisor-based lightweight system that can protect thousands of kernel hooks in a guest OS from being hijacked. One key observation behind our approach is that a kernel hook, once initialized, may be frequently “read”-accessed, but rarely “write”-accessed. As such, we can relocate those kernel hooks to a dedicated page-aligned memory space and then regulate accesses to them with hardware-based page-level protection. We have developed a prototype of HookSafe and used it to protect more than 5, 900 kernel hooks in a Linux guest. Our experiments with nine real-world rootkits show that HookSafe can effectively defeat their attempts to hijack kernel hooks. We also show that HookSafe achieves such a large-scale protection with a small overhead (e.g., around 6% slowdown in performance benchmarks).

The research will be presented at the 16th ACM Conference on Computer and Communications Security this week. Here’s an article on the research.

Posted on November 10, 2009 at 1:26 PM • View Comments

Sears Spies on its Customers

It’s not just hackers who steal financial and medical information:

Between April 2007 and January 2008, visitors to the Kmart and Sears web sites were invited to join an “online community” for which they would be paid $10 with the idea they would be helping the company learn more about their customers. It turned out they learned a lot more than participants realized or that the feds thought was reasonable.

To join the “My SHC Community,” users downloaded software that ended up grabbing some members’ prescription information, emails, bank account data and purchases on other sites.

Reminds me of the 2005 Sony rootkit, which—oddly enough—is in the news again too:

After purchasing an Anastacia CD, the plaintiff played it in his computer but his anti-virus software set off an alert saying the disc was infected with a rootkit. He went on to test the CD on three other computers. As a result, the plaintiff ended up losing valuable data.

Claiming for his losses, the plaintiff demanded 200 euros for 20 hours wasted dealing with the virus alerts and another 100 euros for 10 hours spent restoring lost data. Since the plaintiff was self-employed, he also claimed for loss of profits and in addition claimed 800 euros which he paid to a computer expert to repair his network after the infection. Added to this was 185 euros in legal costs making a total claim of around 1,500 euros.

The judge’s assessment was that the CD sold to the plaintiff was faulty, since he should be able to expect that the CD could play on his system without interfering with it.

The court ordered the retailer of the CD to pay damages of 1,200 euros.

Posted on September 24, 2009 at 6:37 AM • View Comments

Physically Hacking Windows Computers via FireWire

This is impressive:

With Winlockpwn, the attacker connects a Linux machine to the Firewire port on the victim’s machine. The attacker then gets full read-and-write memory access and the tool deactivates Windows’s password protection that resides in local memory. Then he or she has carte blanche to steal passwords or drop rootkits and keyloggers onto the machine.

Full disk encryption seems like the only defense here.

Posted on March 13, 2008 at 11:54 AM • View Comments

Faux Disclosure

Good essay on “faux disclosure”: disclosing a vulnerability without really disclosing it.

You’ve probably heard of full disclosure, the security philosophy that calls for making public all details of vulnerabilities. It has been the subject of debates among
researchers, vendors, and security firms. But the story that grabbed most of the headlines at the Black Hat Briefings in Las Vegas last week was based on a different type of disclosure. For lack of a better name, I’ll call it faux disclosure. Here’s why.

Security researchers Dave Maynor of ISS and Johnny Cache—a.k.a. Jon Ellch—demonstrated an exploit that allowed them to install a rootkit on an Apple laptop in less than a minute. Well, sort of; they showed a video of it, and also noted that they’d used a third-party Wi-Fi card in the demo of the exploit, rather than the MacBook’s internal Wi-Fi card. But they said that the exploit would work whether the third-party card—which they declined to identify—was inserted
in a Mac, Windows, or Linux laptop.

[…]

How is that for murky and non-transparent? The whole world is at risk—if the exploit is real—whenever the unidentified card is used. But they won’t say which card, although many sources presume the card is based on the Atheros chipset, which Apple employs.

It gets worse. Brian Krebs of the Washington Post, who first reported on the exploit, updated his original story and has reported that Maynor said, “Apple had leaned on Maynor and Ellch pretty hard not to make this an issue about the Mac drivers—mainly because Apple had not fixed the problem yet.”

That’s part of what is meant by full disclosure these days—giving the vendor a chance fix the vulnerability before letting the whole world know about it. That way, the thinking goes, the only people who get hurt by it are the people who get exploited by it. But damage to the responsible vendor’s image is mitigated somewhat, and many in the security business seem to think that damage control is more important than anything that might happen to any of the vendor’s customers.

Big deal. Publicly traded corporations like Apple and Microsoft and all the rest have been known to ignore ethics, morality, any consideration of right or wrong, or anything at all that might divert them from their ultimate goal: to maximize profits. Because of this,
some corporations only speak the truth when it is in their best interest. Otherwise, they lie or maintain silence.

Full disclosure is the only thing that forces vendors to fix security problems. The further we move away from full disclosure, the less incentive vendors have to fix problems and the more at-risk we all are.

Posted on August 14, 2006 at 1:41 PM • View Comments

1 2 3

Sidebar photo of Bruce Schneier by Joe MacInnis.