Tag Archives: 0day

Christmas IE Zero-Day Thwarted. Ho ho ho.

Posted on by

By Andrew Brandt

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to Yahoo BuzzAdd to Newsvine

Yesterday, two different 0 day exploits against Internet Explorer were published, just in time for the holidays when most of you (and many security researchers as well) are taking time off from work. The exploit, named CVE-2010-3971, is fairly serious, affecting the latest builds of IE versions 6 through 8.

Well, I’d normally get all hot and bothered about the fact that this kind of event might force some of our research team to spend their precious vacation time working the problem and coming up with a comprehensive solution. Normally, but not this time.

This time we headed the Black Hats off at the pass, and put a stop to these shenanigans before they started. Word from the Webroot Web Security Service team — the builders of our very slick cloud protection service for businesses — is that their Javascript heuristics engine is able to block any Web page that’s trying to use the exploits to try to take over your computer. The screenshot above shows what happened when we tried to browse to the proof-of-concept exploit page on a machine protected by the Web Security Service.

Of course, that’s great for corporate folks, but what about our home users running Webroot Antivirus or Internet Security Essentials or Complete? Well, we block it there, too. If you happened to stumble upon a Web page with the exploit running inside it, you might see a popup like the screenshot here, which is just telling you that we’ve prevented the page containing the exploit from loading in your browser. For the people playing at home, please ensure that you’re running the latest version of your antivirus with the most current updates, with the File System Shield and the Execution Shield turned on (and turn Gamer Mode off while you’re surfing).

So, tough luck exploit writer guys. Better luck next time. I know someone is getting a bigger lump of coal than usual in his stocking this year, and I can’t think of anybody who deserves it more.

Zero-Day Malware Drops Payloads Signed with a Forged Microsoft Certificate

Posted on by

By Andrew Brandt

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

Security Websites are buzzing with news that a new zero-day exploit against Adobe Reader and Acrobat is circulating today, causing computers to become infected with malware simply by visiting certain Web pages. While the exploit itself is worthy of note, nobody is talking about the payload it downloads: It installs a trio of files dressed up to look like Windows system files which have been digitally signed with a security certificate supposedly issued by Microsoft. The digital signature gives the casual user the impression that the two signed files — an executable and a DLL both named “LNETCPL” — are legitimate Microsoft components.

The fake certificates appear in the properties sheets of both the installer and two of the three executable payloads dropped by the installer. One giveaway is that the sheet identifies the signer as Microsoft but lacks both an email address and a time stamp. Legitimate system files digitally signed by Microsoft identify the signer as Microsoft Corporation and always have a time stamp. The bogus signatures are identified as invalid, but only when you click the Details button on the Properties Sheet’s Digital Signatures tab.

A legitimate Microsoft-signed file is issued by the “Microsoft Code Signing PCA” certificate authority, and will also display a countersignature from Verisign; The fakes have no countersignature, and appear to have been issued by “Root Agency” — a made up name for a nonexistent certificate authority the malware creators are using to generate these files. In fact, the malware creators may actually be using Microsoft’s own Certificate Creation Tool (which is supposed to be used for testing) to facilitate generating these signed files.

While we’ve seen a number of digitally signed files come through our research queue over the years, authors of Trojan horse apps rarely go to the trouble of digitally signing files in this way. It’s not clear why they would be digitally signing files, but clearly the person or people behind this are up to no good. We’ve published a new definition to remove both the installer and these payload files; Trojan-Certispaz will be available to help our customers clean up infections in our next definitions update.

Continue reading →