Entries Tagged "malware"

Page 33 of 50

Aggressive Social Engineering Against Consumers

Cyber criminals are getting aggressive with their social engineering tactics.

Val Christopherson said she received a telephone call last Tuesday from a man stating he was with an online security company who was receiving error messages from the computer at her Charleswood home.

“He said he wanted to fix my problem over the phone,” Christopherson said.

She said she was then convinced to go online to a remote access and support website called Teamviewer.com and allow him to connect her computer to his company’s system.

“That was my big mistake,” Christopherson said.

She said the scammers then tried to sell her anti-virus software they would install.

At that point, the 61-year-old Anglican minister became suspicious and eventually broke off the call before unplugging her computer.

Christopherson said she then had to hang up on the same scam artist again, after he quickly called back claiming to be the previous caller’s manager.

Posted on May 30, 2011 at 6:58 AM • View Comments

Blackhole Exploit Kit

It’s now available as a free download:

A free version of the Blackhole exploit kit has appeared online in a development that radically reduces the entry-level costs of getting into cybercrime.

The Blackhole exploit kit, which up until now would cost around $1,500 for an annual licence, creates a handy way to plant malicious scripts on compromised websites. Surfers visiting legitimate sites can be redirected using these scripts to scareware portals on sites designed to exploit browser vulnerabilities in order to distribute banking Trojans, such as those created from the ZeuS toolkit.

Posted on May 25, 2011 at 11:55 AM • View Comments

New Siemens SCADA Vulnerabilities Kept Secret

SCADA systems—computer systems that control industrial processes—are one of the ways a computer hack can directly affect the real world. Here, the fears multiply. It’s not bad guys deleting your files, or getting your personal information and taking out credit cards in your name; it’s bad guys spewing chemicals into the atmosphere and dumping raw sewage into waterways. It’s Stuxnet: centrifuges spinning out of control and destroying themselves. Never mind how realistic the threat is, it’s scarier.

Last week, a researcher was successfully pressured by the Department of Homeland Security not to disclose details “before Siemens could patch the vulnerabilities.”

Beresford wouldn’t say how many vulnerabilities he found in the Siemens products, but said he gave the company four exploit modules to test. He believes that at least one of the vulnerabilities he found affects multiple SCADA-system vendors, which share “commonality” in their products. Beresford wouldn’t reveal more details, but says he hopes to do so at a later date.

We’ve been living with full disclosure for so long that many people have forgotten what life was like before it was routine.

Before full disclosure was the norm, researchers would discover vulnerabilities in software and send details to the software companies—who would ignore them, trusting in the security of secrecy. Some would go so far as to threaten the researchers with legal action if they disclosed the vulnerabilities.

Later on, researchers announced that particular vulnerabilities existed, but did not publish details. Software companies would then call the vulnerabilities “theoretical” and deny that they actually existed. Of course, they would still ignore the problems, and occasionally threaten the researcher with legal action. Then, of course, some hacker would create an exploit using the vulnerability—and the company would release a really quick patch, apologize profusely, and then go on to explain that the whole thing was entirely the fault of the evil, vile hackers.

I wrote that in 2007. Siemens is doing it right now:

Beresford expressed frustration that Siemens appeared to imply the flaws in its SCADA systems gear might be difficult for a typical hacker to exploit because the vulnerabilities unearthed by NSS Labs “were discovered while working under special laboratory conditions with unlimited access to protocols and controllers.”

There were no “‘special laboratory conditions’ with ‘unlimited access to the protocols,'” Beresford wrote Monday about how he managed to find flaws in Siemens PLC gear that would allow an attacker to compromise them. “My personal apartment on the wrong side of town where I can hear gunshots at night hardly defines a special laboratory.” Beresford said he purchased the Siemens controllers with funding from his company and found the vulnerabilities, which he says hackers with bad intentions could do as well.

That’s precisely the point. Me again from 2007:

Unfortunately, secrecy sounds like a good idea. Keeping software vulnerabilities secret, the argument goes, keeps them out of the hands of the hackers…. But that assumes that hackers can’t discover vulnerabilities on their own, and that software companies will spend time and money fixing secret vulnerabilities. Both of those assumptions are false. Hackers have proven to be quite adept at discovering secret vulnerabilities, and full disclosure is the only reason vendors routinely patch their systems.

With the pressure off, Siemens is motivated to deal with the PR problem and ignore the underlying security problem.

Posted on May 24, 2011 at 5:50 AM • 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

Hijacking the Coreflood Botnet

Earlier this month, the FBI seized control of the Coreflood botnet and shut it down:

According to the filing, ISC, under law enforcement supervision, planned to replace the servers with servers that it controlled, then collect the IP addresses of all infected machines communicating with the criminal servers, and send a remote “stop” command to infected machines to disable the Coreflood malware operating on them.

This is a big deal; it’s the first time the FBI has done something like this. My guess is that we’re going to see a lot more of this sort of thing in the future; it’s the obvious solution for botnets.

Not that the approach is without risks:

“Even if we could absolutely be sure that all of the infected Coreflood botnet machines were running the exact code that we reverse-engineered and convinced ourselves that we understood,” said Chris Palmer, technology director for the Electronic Frontier Foundation, “this would still be an extremely sketchy action to take. It’s other people’s computers and you don’t know what’s going to happen for sure. You might blow up some important machine.”

I just don’t see this argument convincing very many people. Leaving Coreflood in place could blow up some important machine. And leaving Coreflood in place not only puts the infected computers at risk; it puts the whole Internet at risk. Minimizing the collateral damage is important, but this feels like a place where the interest of the Internet as a whole trumps the interest of those affected by shutting down Coreflood.

The problem as I see it is the slippery slope. Because next, the RIAA is going to want to remotely disable computers they feel are engaged in illegal file sharing. And the FBI is going to want to remotely disable computers they feel are encouraging terrorism. And so on. It’s important to have serious legal controls on this counterattack sort of defense.

Some more commentary.

Posted on May 2, 2011 at 6:52 AM • View Comments

HBGary and the Future of the IT Security Industry

This is a really good piece by Paul Roberts on Anonymous vs. HBGary: not the tactics or the politics, but what HBGary demonstrates about the IT security industry.

But I think the real lesson of the hack – and of the revelations that followed it – is that the IT security industry, having finally gotten the attention of law makers, Pentagon generals and public policy establishment wonks in the Beltway, is now in mortal danger of losing its soul. We’ve convinced the world that the threat is real – omnipresent and omnipotent. But in our desire to combat it, we are becoming indistinguishable from the folks with the black hats.

[…]

…While “scare ’em and snare ’em” may be business as usual in the IT security industry, other HBGary Federal skunk works projects clearly crossed a line: a proposal for a major U.S. bank, allegedly Bank of America, to launch offensive cyber attacks on the servers that host the whistle blower site Wikileaks. HBGary was part of a triumvirate of firms that also included Palantir Inc and Berico Technologies, that was working with the law firm of the U.S. Chamber of Commerce to develop plans to target progressive groups, labor unions and other left-leaning non profits who the Chamber opposed with a campaign of false information and entrapment. Other leaked e-mail messages reveal work with General Dynamics and a host of other firms to develop custom, stealth malware and collaborations with other firms selling offensive cyber capabilities including knowledge of previously undiscovered (“zero day”) vulnerabilities.

[…]

What’s more disturbing is the way that the folks at HBGary – mostly Aaron Barr, but others as well – came to view the infowar tactics they were pitching to the military and its contractors as applicable in the civilian context, as well. How effortlessly and seamlessly the focus on “advanced persistent threats” shifted from government backed hackers in China and Russia to encompass political foes like ThinkProgress or the columnist Glenn Greenwald. Anonymous may have committed crimes that demand punishment – but its up to the FBI to handle that, not “a large U.S. bank” or its attorneys.

Read the whole thing.

Posted on February 25, 2011 at 6:14 AM • View Comments

Scareware: How Crime Pays

Scareware is fraudulent software that uses deceptive advertising to trick users into believing they’re infected with some variety of malware, then convinces them to pay money to protect themselves. The infection isn’t real, and the software they buy is fake, too. It’s all a scam.

Here’s one scareware operator who sold “more than 1 million software products” at “$39.95 or more,” and now has to pay $8.2 million to settle a Federal Trade Commission complaint.

Seems to me that $40 per customer, minus $8.20 to pay off the FTC, is still a pretty good revenue model. Their operating costs can’t be very high, since the software doesn’t actually do anything. Yes, a court ordered them to close down their business, but certainly there are other creative entrepreneurs that can recognize a business opportunity when they see it.

Posted on February 7, 2011 at 8:45 AM • View Comments

Trojan Steals Credit Card Numbers

It’s only a proof of concept, but it’s scary nonetheless. It’s a Trojan for Android phones that looks for credit-card numbers, either typed or spoken, and relays them back to its controller.

Software released for Android devices has to request permissions for each system function it accesses—with apps commonly requesting access to the network, phone call functionality, internal and external storage devices, and miscellaneous hardware functions such as the backlight, LED, or microphone. These requests are grouped into categories and presented to the user at the point of installation—helping to minimise the chance of a Trojan slipping by.

Soundminer takes a novel approach to these restrictions, by only requesting access to ‘Phone calls,’ to read phone state and identity, ‘Your personal information,’ to read contact data, and ‘Hardware controls’ to record audio—none of which will ring alarm bells if the app is marketed as a voice recording tool.

Research paper here. YouTube demo. Another blog post. Research paper; section 7.2 describes some defenses, but I’m not really impressed by any of them.

Posted on January 29, 2011 at 7:45 AM • View Comments

1 … 31 32 33 34 35 … 50

Sidebar photo of Bruce Schneier by Joe MacInnis.