by Dancho Danchev
As part of its quarterly patch update, today Adobe issued a critical security update plugging multiple security holes in its Acrobat Reader, and Adobe Acrobat software applications.
More details:
Tag Archives: adobe reader
This blackhole exploit kit gives you Windows Media Player and a whole lot more
As a follow-up to the Blackhole Exploit posting, I thought I would share one aspect of my job that I truely enjoy: Discovery.
While investigating some active urls being served up via a blackhole kit, I noticed something quite odd, as I would end up on sites that had malicious code injected into their webpages.
Once the redirection to the blackhole kit was initiated, I saw the usual exploits taking place, first being Internet Explorer and Adobe Flash, then onto Adobe Reader and Java.
This time, the kit didn’t stop there. Internet Explorer proceeded to launch Windows Media Player. Since I had never used it on this test machine, the Windows Media Player install sequence initiated, causing the windows media player setup screen to appear in order to finalize its installation.
I became curious as to what Windows Media Player is being used for. Unfortunately in this case, I couldn’t see where any files were called down to the machine and did not have any type of network analyzer running.
Zero-Day Malware Drops Payloads Signed with a Forged Microsoft Certificate
By Andrew Brandt
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.
One Click, and the Exploit Kit’s Got You
By Andrew Brandt
After all the brouhaha surrounding the NYTimes.com website hosting ads which spawned rogue antivirus Fakealerts last weekend, I spent a considerable amount of time looking at so-called exploit kits this week. These are packages, made up of custom made Web pages (typically coded in the PHP scripting language), which perform a linchpin activity for malware distributors. Namely, they deliver the infection to the victim, using the most effective methods, based on parameters which help identify particular vulnerabilities in the victim’s browser, operating system, or applications.
There’s no indication that an exploit kit was used by the attackers in the NYTimes.com incident, but it easily could have gone that way. All an exploit kit needs in order to begin the process of foisting an infection is for a potential victim to visit its specially crafted Web page. The end result is what we call a drive-by download.
According to reports, the code injected into the Times website’s ad calls simply spawned another browser window, which in turn displayed fake alert and virus scan results messages. It wasn’t even a website hack; the site’s ad sales department were fooled into accepting a paid advertisement containing the code.
This time, that browser window was used to trick the site’s visitors into executing, and eventually buying, the rogue product. It could have been far worse.
After spending a day investigating a relatively new package, which calls itself (with a total lack of irony) the Liberty Exploit System, it’s easy to see how something like what was done on the Times website could have led news enthusiasts down a much deeper, scarier rabbit hole.
