I have been closely monitoring the recently disclosed vulnerability in the method that all versions of Windows use to render shortcuts. Fortunately, no major attacks aside from Stuxnet have had much success, but we are starting to see malware authors experimenting with its potential.
First we saw Troj/Chymin-A. This new sample is a keylogger, and fortunately is not a worm. It uses the shortcut out of convenience.
Then we discovered W32/Dulkis-A. This virus uses VB Script obfuscation to disguise itself and is in fact a replicator. It will infect removable devices with malicious shortcut files to facilitate its spread.
Things were reasonably quiet over the weekend and started up at the beginning of Monday UTC. We came across a Zbot (Zeus) variant attempting to use the exploit that I found downright entertaining. It is being disseminated via email and pretends to be a Microsoft security advisory. The email contains a .zip attachment and requires you to extract the Zip file to the C:\ drive in order for it to successfully exploit you. Fortunately, the authors seem to have completely missed the point. Why on earth would you use an attack vector that requires loads of user intervention when you have an exploit that doesn't?
Microsoft's mitigation advice will certainly provide protection, but as I noted in my blog last week the results are undesirable. That is why Sophos launched a free shortcut exploit mitigation tool to both enterprises and consumers today. The tool protects against malware targeting the exploit without the undesirable side effect of disguising your shortcuts. In addition to anti-virus, this is a great way to protect yourself and it has no impact on productivity. Be sure to apply the Microsoft patch once it is available, but this should help in the meantime.
I have also seen a lot of discussion as to whether this exploit requires AutoRun or AutoPlay to be enabled. The answer is: absolutely not. In today's Ask Chet, I will demonstrate how a simple web link can infect an unprotected PC. Others have asked whether they're safe if they avoid using USB drives. Again, no. This will even work on your hard drive if a correctly malformed shortcut is placed there.
Time to pack my bags as I am off to Black Hat 2010 and Defcon. If you'll be there as well. drop me a note and maybe we can have a chat over a root(beer).
In the past week I've garnered a lot of press attention from my ongoing research into the Windows shortcut vulnerability. Apparently this has brought my name to the attention of the SEO poisoners who continually target Google.
There were more results than shown here, so I did some poking around to see what they were. The most common poisoning and the one shown here leads to some hacked websites that are chock full of tasty keywords for search engine manipulation. None of the sites I investigated had any malicious content themselves; they appear to be using hacked blogs and sites to enhance the search rank of someone who was foolish enough to hire them to increase their Google PageRank.
Another of the poisoned pages redirected to a fake Google results page.
Following the link displayed takes you through a series of redirects, all of which have some sort of affiliate ID number in the URL, landing you eventually at fake Canadian pharmacy websites. The Canadian pharmacy sites are on a rotation so you get a different one each time you click the link.
The attack must be related to insecure versions of WordPress, since the source code shows that the pages were created using WordPress/MU. As you can see, my name is the title of this particular page.
The cat-and-mouse game between the con artists and Google continues. Throughout the day I have watched many of the poisoned results disappear as Google catches on to their techniques and puts them out of commission. Simply because a site is in a Google search result does not make it legitimate. Think before you click and take advantage of the summaries Google provides to determine whether something smells a bit phishy.
Posted on July 24th, 2010 by Chester Wisniewski, Sophos
Filed under:
Editorial, Internet, Spam
Adobe has become the whipping boy for many security pundits over the last 24 months, but today they have made the most public move to change that opinion since announcing a new security strategy in May 2009. Brad Arkin their Senior Director, Product Security & Privacy made a blog post today announcing Adobe Reader Protected Mode.
In a nutshell Adobe's next major release of Reader will default to using a sandbox method of isolating Adobe Reader from modifying your computer if a vulnerability is exploited. I must say I am disappointed that we are not getting this now, but it is great news to see Adobe taking a progressive step to stop malware writers from using its large foothold on our desktops to their advantage.
In his blog Brad mentioned that his team has been working with the Microsoft Office 2010 team and the Google Chrome team to develop this release. These are two of the most successful sandbox implementations currently in widespread use. Neither have a perfect track record, but this implies Adobe can learn from the lessons Microsoft and Google have already paid the price for.
A date for the release has not yet been set, but you can count on plenty of coverage from Sophos when it becomes available. Here's to hoping they implement a similar technique for Adobe Flash leaving all of us a whole lot more secure.
A lot of other researchers have covered this story, but I think some of the important details have been neglected or scattered about. First, the certificate that was used to sign the malware expired on June 11th. I will explain the significance of this later. Second, this particular component of the threat was signed on January 25th, 2010. This implies the perpetrators of this attack have been planning their strategy for quite some time.
There was a lot of fanfare on Saturday when Microsoft and Verisign announced that they had worked together with Realtek to revoke the certificate in question, implying that this somehow improved the safety and security of users. One of our researchers, Mike Wood, who will be presenting a paper this year at Virus Bulletin on the use of certificates by cybercriminals, helped me out by looking into the specifics of how Windows treats signed drivers and DLLs.
Mike came to two conclusions. One was that a driver signed with a certificate during its validity period will never expire. That the signing certificate is now expired is irrelevant because the rootkit was signed when the certificate was valid.
Second, Mike determined that the conclusion I had drawn in this week's Sophos Security Chet Chat was incorrect. I thought that when the certificate was revoked this would prevent drivers that had been signed by it from loading into Windows. This is only partially true; it will only prevent drivers from loading that were signed after the certificate was revoked. This means all existing copies of Stuxnet that are in the wild will still happily load.
Why revoke the certificate at all? I have no clue. It accomplishes absolutely nothing as far as I can tell, except giving the appearance that the powers-that-be are taking actions to protect us. I contacted Verisign's public relations department this afternoon for clarification, but I have yet to receive any response.
As if that weren't enough drama, Eset blogged this morning about another variant of this malware that has been signed with another compromised legitimate certificate, belonging to JMicron Technology. The date of compilation is July 14th, the day before the world found out about the previous variant. In an interesting twist, it turns out that JMicron's offices are in the same office park as Realtek Semiconductor.
Sophos detects this alternative version as Troj/Stuxnet-D as well as detecting malicious shortcuts as Troj/Cplink-A. We have created a central location for information about this vulnerability and the related threats. You can bookmark http://www.sophos.com/cplink for links to all the latest information.
Microsoft has updated their knowledgebase today to include an easy-to-use "Fix it" download that implements their mitigation advice. This download will disable the rendering of icons to ensure your copy of Windows will not be infected. Before you use this fix I recommend checking out the screenshot I posted yesterday showing the effect it has on a standard Windows 7 installation.
I have spent the last three days looking at how we can best protect ourselves against the latest Windows zero day vulnerability, aside from running up to date anti-virus software. We have named this exploit CPLINK within SophosLabs referring to the fact that it is a Control Panel .lnk exploit. To begin the exercise I followed Microsoft's advice and disabled the rendering of icons...
You will see that my taskbar is nearly entirely unusable and I won't even expose you to My Documents. While Microsoft's advice seems to hold true (The iTunes icon actually rendering makes me suspect) it seriously degrades the usability of the Windows desktop. It is necessary if you have a complicated Windows deployment, but if you have a good standard for application deployment you can try a less drastic mitigation. I mentioned in my previous article that the use of Software Restriction Policies via GPOs is a realistic and more practicable solution to avoiding infection while awaiting a patch from Microsoft.
Michael Shannon and I had our weekly Chet Chat and talked about this in detail. Michael is a threat researcher in SophosLabs and shared his thoughts on the risk, mitigation, and how it might have happened.
If you decide you need to disable the rendering of icons to avoid the risk of infection it is quite simple. Open regedit.exe and browse to HKEY_CLASSES_ROOT\lnkfile\shellex\IconHandler. Click the file menu to export the key so you have a backup and then clear the value.
My advice is that if you have a controlled Windows deployment you will likely know where your users are executing software that is approved. In this case you can simply create a GPO that defines where software is allowed to run and if that does not include network shares this will provide you an equivalent level of protection without the nastiness of making all your icons turn into white sheets.
Microsoft provides guidance on Software Restriction policies on their TechNet website. By creating a SRP that only allows executable files to run from designated locations (C:\, C:\Program Files, C:\Windows) or specific network locations you can reduce the risk of infection without disabling icons.
Fortunately we have not seen a lot of malware attempting to exploit this vulnerability yet. Unfortunately I predict it is only a matter of time. SANS apparently agrees as they have elevated their threat level to yellow.
Aside from the risks of this exploit we have seen a lot of drama on the cloak and dagger side of this story, mostly related to the original malware distributed using this exploit. It might be interesting reading, but my head is down trying to do what I can to understand the risk and provide sensible advice. Godspeed to Microsoft in providing us a fix, and as always SophosLabs are working on your behalf to provide the best protection we can.
It's been a busy 24 hours looking into this newest flaw in Windows. Lots of research has gone into it and most of the results are not good news for Windows users. It is important to think about this attack as two separate pieces, one that is a new zero-day vulnerability that could easily be adopted by any malware author, the other a unique payload that appears to be designed to go after some very specific infrastructure targets.
For corporate users (unless you run a power plant, water system or other SCADA system) the important part is the zero-day flaw. Warning: I am about to go a bit geeky.
The flaw is in how shell32.dll tries to load control panel icons from applets. By making a specially crafted shortcut pointing to a malicious file, you can make Windows Explorer blindly execute the malicious file when the location of the shortcut is merely browsed to. In this case the malicious file is a rootkit and a dropper that immediately hide the special shortcut (.lnk) files. Allowing executable code to load in the process of trying to retrieve an icon seems like a major oversight in the design of Windows.
Here is a photo of the directory listing I made on a Linux box in SophosLabs using an infected USB device. You can see that there are 4 different malicious shortcuts that are all called "Copy of ... Shortcut to.lnk". The tmp files you see are the actual rootkit/dropper.
The following (hastily captured, apologies for the quality) video shows the automatically executed rootkit in action. You can see that I in no way interact with the device other than to "explore" it. This will work even with AutoRun and AutoPlay disabled. I don't know why you would plug in a USB storage device if you weren't going to view it in Explorer...
This rootkit is particularly nasty as it infects all Windows versions since XP, and as you see here it bypasses all Windows 7 security mechanisms, including UAC, and doesn't require administrative privilege to run. The user I am logged in as in this video is "Bob," a standard user. I expressed concerns last November about people mistaking UAC for a security feature and this unfortunately seems to still hold true.
A few hours ago Microsoft released their security advisory and mitigation advice. Microsoft confirms what I discovered during my testing, that this vulnerability affects all currently supported Windows releases. However, noticeably absent from the list are Windows 2000 and Windows XP SP2 as they are no longer supported since Tuesday. They are, however, definitely still vulnerable.
This exploit affects more than just USB devices. According to Microsoft's advisory, it also affects Windows file shares and WebDav, making a very bad situation worse. Let's hope Microsoft has their best team on this to get us a dependable fix very soon.
For now, Microsoft advises that you disable icons for shortcuts. Unfortunately, this is highly impractical for most environments. While it would certainly solve the problem, it would also cause mass confusion among many users and might not be worth the support calls. Microsoft also suggests disabling the WebClient service that is used for WebDav. If you are not a Microsoft SharePoint customer this may be a solution, but many organizations rely on SharePoint so this is limiting as well.
Today, a colleague suggested the best mitigation I have heard so far: deploying a GPO disallowing the use of executable files that are not on the C: drive. This will work for most environments, and you really shouldn't be running executables from USB drives and network shares anyway. We tested this solution against the vulnerability and it does in fact provide protection.
The malware originally distributed with this flaw is not a big concern unless you run a nuclear power plant and Homer Simpson is using Windows and clicking whatever he pleases (D'oh!). Expect the exploit, on the other hand, to be widely used in short order. Having had the opportunity to play with it and see the simplicity with which it can be used, I suspect it will be too juicy a target to ignore.
If you are a Sophos customer, the good news is that you are protected against the exploit and the payload. Even the WebDav angle will be stopped by the Sophos Web Appliance. As a backup measure, or for people not fortunate enough to have our software, I recommend using the GPO to disable execution on devices other than the system and program drives.
Update: Some people have pointed out that they are required to execute files from network shares as part of their standard operations. If this is true, the above suggestion can still work you simply need to adjust the GPO to allow execution for the specific network paths you may require. This solution is not ideal, but it is the simplest method to try and prevent infection from this flaw .
A special shout-out to SophosLabs and Mike, Niall, and Paul. Your help investigating this was invaluable and we all appreciate your dedication to helping the public defend their PCs.
The security community was buzzing today about a potential new zero-day vulnerability in Windows. The attack that exploits the vulnerability was originally discovered by VirusBlokAda in Belarus. It contains several components and is still being analyzed by SophosLabs.
It starts with a yet unexplained flaw in Windows that allows a Windows shortcut file (.lnk) placed on a USB device to run a DLL simply by being viewed. This means that, even with AutoRun and AutoPlay disabled, you can open a removable media device (USB) and execute malicious code without user interaction. The danger associated with this attack is large considering how many computers were infected through USB devices by Conficker using the AutoPlay functionality. If you can execute malware even when AutoPlay is disabled, the risk is very high. Sophos detects these malicious .lnk files as W32/Stuxnet-B.
Although analysis is not complete, it would appear that the flaw is in how Windows Explorer loads the image to display when showing a shortcut. This feature is being used to exploit a vulnerability and execute a DLL to load the malware on the system.
The DLL that is loaded in this case is a rootkit dressed up as a device driver. It is able to load undetected into the system because it is digitally signed by RealTek Semiconductors, a legitimate hardware vendor. Why RealTek would digitally sign a driver that is in fact a rootkit, or whether their systems were compromised has yet to be determined. The rootkit, once loaded, disguises the malicious files on the USB device, making further investigation difficult.
The .lnk files used to spread the infection via USB are specific to each USB key infected. The malware dynamically generates the .lnk file for each device it infects. At this time it is unclear whether this is necessary for the exploit to work, or whether it is a control mechanism for the perpetrators of this attack.
Brian Krebs reported on his blog that the payload appears to be looking for content specific to Siemens SCADA software. SCADA systems control much of our nations' critical infrastructure. If this is the case, it's a disturbing turn of events. The implication would be that the samples that we are looking at are part of a true "Advanced Persistent Threat" attack against specific targets. Knowledge of this exploit could also lead to widespread adoption by opportunistic malware writers similar to what happened in the Google Aurora attacks.
This is why we need to be careful not to call every data-stealing piece of malware an Advanced Persistent Threat. We need to be sure that when a wolf really does come along -- when our adversaries target critical infrastructure providers with malware designed to steal information or disrupt their operations -- our cries don't go unheeded.
A friend and colleague just tipped me off to the defacement/spamming of the Wikipedia page for the FIFA 2010 World Cup. Of course, anyone can edit a Wikipedia page, but usually high profile pages like this are protected from being modified by just anyone.
Unlike most Wikipedia defacements, this one has spam in mind. Unlike the usual spam for penis pills and cheap Canadian drugs that uses a couple of "medical professionals" to promote the site, this campaign uses a photo of a satisfied couple.
Unauthorized Wikipedia edits are nothing new, but it appears there is an ongoing struggle between the forces of order and the forces of Viagra. Several corrections have been made to the page to remove the spam, but more and more "confirmed" accounts keep reverting it back to the original spam message. Wikipedia has a rather complex system for determining how a page is locked and who can edit it, and this page is marked with semi-protection.
Fortunately the page being linked to does not contain malware and is only trying to sell you a good time in the sack. This does, however, demonstrate that there is no such thing as "safe surfing" and once again busts Sophos Web Security Myth #4: "Only porn, gambling, and other “dodgy” sites are dangerous." For more information on web security myths, visit our hot topics page.
For those administrators anxiously awaiting a fix for the zero day flaw in Windows Help Center disclosed by Tavis Ormandy last month your patch is ready. Microsoft released four patches today and their standard summary with priority and severity ratings.
MS10-042 fixes the Help Center vulnerability, while MS10-043 resolves the bug in Windows 7/2008 R2 in the Windows Aero interface that could lead to remote code execution.
Microsoft also resolved two flaws in Microsoft Office 2003/2007, MS10-044 addresses a flaw in Microsoft Access while MS10-045 fixes a vulnerability in Microsoft Outlook. All are listed as Critical except for the Outlook bug, but I would make it a priority as well considering it can be exploited by a malicious email.
Even Mozilla had some bad news today with a warning about two insecure plugins for it's Firefox browser. The first one called "Mozilla Sniffer" was simply malicious and would steal any usernames and passwords entered into the browser and send them off to a remote server. The second is a widely deployed vulnerable plugin called "CoolPreviews".
Mozilla advises users to patch their "CoolPreviews" to a newer release and in time will disable the vulnerable versions. Considering the inclusion of a genuinely malicious add-on making it into their site they are reviewing their policies concerning public publication before code review.
Last week Rami Jebara our Technical Product Manager for endpoint web security joined me for the Sophos Security Chet Chat. Rami and I discussed the new functionality in Endpoint Security and Control 9.5 and how we can now protect PCs against web threats using real-time detection.
Today Michael Argast and I discussed patch Tuesday, the whole full disclosure debate and the debate around anti-malware testing and whether all of the tests overlook important factors such as ease of management and breadth of protection.
I just came across another phish in which the scammers take the tactic of asking you for everything they possibly can while they have you "on the hook."
The text of the email reads
Dear AOL Member,
We were unable to process your most recent payment. Did you recently changed your bank, phone number or credit card ?
To ensure that your service is not interrupted, please update your billing information today by following this steps,
1. Visit http://bill.aol.com
2. Enter all your information
3. Click Submit to update your billing information
PS: The link in this massage will be expire within 24 Hours . You have to update your payment information.
Sincerely, AOL Member Services
Of course, tricking you requires that you are a paying AOL customer... and that you won't notice the stereotypically bad grammar. Clearly, they should have better targeted their attack, perhaps only sending it to AOL email addresses. The domain name the email redirects you to seems to be a bit of a phishing haven, having hosted Paypal phishes only a few days ago.
Looking more deeply into the WHOIS details, I found a whole string of scams that appear to operate over Amazon's affiliate payment system. Some IPs associated with this attack are storing pre-populated WordPress SQL files containing all the wonderful fake comments about the products they purchased through this series of bogus blogs. All they need to do is search and replace a product name, import the SQL, and voilà, instant website.
Like most phishes, this one borrows a lot from the real AOL website. It takes some liberties with the form to ask you for a surprising quantity of information: Name, address, home and work phone, Social Security Number, mother's maiden name, birthday, drivers' license, credit card, ATM PIN, bank, bank phone, bank account number/routing number and AOL screen name and password.
I have talked about this tactic before in relation to bank phishing attacks. If the scammers can convince you that they are who they say they are, they might as well ask you for every last detail you are willing to surrender. This one might go far enough, though, to tip off a suspicious victim.
I have to thank the criminals for leaving a public copy of all of their website code lying around so I could see what they were up to. Once you fill out the form, it's emailed to a series of Hotmail addresses that still appear the be active.
Never trust emails purporting to confirm account details, and continue to encourage your user community to avoid clicking links within emails. Despite the predictions of visionary Bill Gates, the spam problem has not been solved... Stay vigilant.