Microsoft releases nine March Security Bulletins. Four of the Bulletins are rated critical, but of the 20 vulnerabilities being patched, 12 are rated critical and enable remote code execution and elevation of privilege. Microsoft software being patched with critical priority include Internet Explorer, Silverlight, Visio Viewer, and SharePoint. So, pretty much everyone running Windows, and lots of Microsoft shops, should be diligently patching systems today.
Pwn2own attracted top offensive security talent to Cansecwest and awarded a half million in prizes for fresh 0day this year, but the event didn't force much Microsoft fix development for this Bulletin release. Adobe, Java, Firefox and Chrome were all hit this year along with two Internet Explorer 10 0day for full compromise on Windows 8 on a Windows Surface Pro tablet.
Instead, MS013-021 is one giant "Internet Explorer Use-After-Free patch", addressing the longest list of IE use-after-free vulnerabilities in a single monthly Bulletin to date. Knowing that only one of these vulnerabilities was disclosed publicly, it almost looks as though they fixed a fuzzer in their own labs or someone stepped up development of their own.
MS013-022 addresses a memory pointer check in Silverlight component HTML rendering - an unusual problem known as "double de-referencing". The interesting thing here is that this client side RCE enables exploitation across not only all of its supported Windows systems, but across Apple's Mac OS X systems. In the light of OS X mass exploitation this past year and the recent slew of OS X-enabled targeted attacks, this patch is important to folks lugging around systems running OS X.
Microsoft recommends that EMET helps mitigate both the Internet Explorer and the Silverlight issues.
On the server side, altogether different from the client side memory corruption issues above, we see a web service vulnerability in Sharepoint, a pretty widely distributed service in organizations. The eye popper here includes an EoP enabled by an XSS flaw that provides remote users with a method to issue Sharepoint commands in the context of an administrative user on the site. These Sharepoint flaws were all privately reported by an outside researcher, but no public disclosure is known. At the same time, a denial of service and buffer overflow issue is being addressed in the Sharepoint code.
MS012-023 addresses vulnerable code in Visio Viewer 2010, but the vulnerable code also is delivered in components within Microsoft Office. The odd thing is that there is no known code path traversal through the vulnerable code within Microsoft Office. And, Microsoft maintains four or five versions of Visio Viewer, a widely used piece of software for organizations to distribute diagrams and charts of all types. However, this vulnerability only affects one version - Microsoft Visio Viewer 2010. Nonetheless, Microsoft is leaning towards addressing any and all security issues (including unknown future issues), and patching the code everywhere it resides including Microsoft Office, whether or not it is traversed at runtime within Office.
Of the lesser rated vulnerabilities, the kernel mode USB descriptor issue seems the most interesting. And yes, the title of this post is out-of proportion and fairly ridiculous. I don't expect another Stuxnet to rise up simply because of this vulnerability. But, in a flashback to Stuxnet exploit vectors, it provides another vector of delivery for arbitrary code to be executed in kernel mode simply by inserting a USB device into a system.
To clarify, the danger here does not lie in the immediate potential for another Stuxnet. The immediate danger lies in the availability of attack surface demonstrated by Stuxnet to enable highly secured, air gapped industrial environments to be infiltrated with Pearl Harbor style surprise and effectiveness.
Today's February Microsoft Security Bulletin release patches a long list of vulnerabilities. However, only a subset of these vulnerabilities are critical. Four of them effect client side software and one effect server side - Internet Explorer, DirectShow media processing components (using web browsers or Office software as a vector of delivery), OLE automation components (APT related spearphish), and one effecting the specially licensed "Oracle Outside In" components hosted by Microsoft Exchange that could be used to attack OWA users. These critical vulnerabilities all potentially enable remote code execution, as does the Sharepoint server related Bulletin rated "important" this month. The other vulnerabilities enable Elevation of Privilege and Denial of Service attacks. Several of the vulnerabilities have been publicly disclosed, and at least one is known to be publicly exploited. A large number of the CVE being patched are in the kernel code, so this month most everyone should expect to manage a reboot.
The long list of CVE patched by MS-13-016 all address race conditions that were privately reported in win32k.sys, which all enable non-trivial EoP attacks. This lessens the severity of the issue, as evidenced by the recent RDP vulnerability that attracted so much attention at the end of this past year.
So, we should focus immediate efforts on the handful of critical RCE this month.
Microsoft starts the new year with a January Security Bulletin Release of seven Security Bulletins. These seven bulletins cover at least 11 CVE. Three of the vulnerabilities need to be addressed immediately with two of the Bulletins. These three vulnerabilities effect XML Core Service components (MS13-001) that can be abused using Internet Explorer as a vector of attack, and a Print Spooler component (MS13-002) that could be abused once an attacker has infiltrated a network, as described in this Microsoft SRD post. This flaw is important to address for organizations that are victims of targeted attacks. Now that Pass-the-Hash techniques are becoming better understood and mitigated, attackers will look to lateral movement alternatives like these. So, while it's doubtful that we would see a fast-spreading worm resulting from this one, but as with Ramnit, it's important for small and medium businesses to understand what ports and services are exposed to the internet and avoid becoming a victim. Either way, these two Bulletins should be addressed immediately.
It's interesting to note that Microsoft is attending to these vulnerabilities, even though they are not yet being publicly exploited according to the company.
Other Bulletins this month patch SCOM components, .NET, and OData Services, as well as a Windows kernel EoP effecting all versions of Windows and an interesting SSL bypass. SCOM is interesting because it is the Microsoft Security Center Operations Manager, and the patch isn't available as it isn't fully tested just yet. On one hand, Microsoft's testing capabilities are unbelieveably complex and thorough, so it's a surprise that this release isn't delivered alongside the others. On the other hand, it's an XSS vulnerability that would require some unusual scenarios to exploit, and the Internet Explorer XSS filter can be enable to mitigate the issue. So this one is a bit obscure to be widely hit. The .NET vulnerability set is a bit more dangerous, because these vulnerabilities can be exploited in combination via web browsers. These vulnerabilities effect versions 1.1 through 4.5 of the Microsoft .NET framework on all versions of Windows, including Windows Server 2012. And finally, OData (Open Data Protocol) services components support fairly newer network exchange protocols used in business and other backend applications as a part of the Windows Communication Framework Data Services. These services are simply available to a denial of service attack.
The Adobe AIR and Adobe Flash Player Incubator program updated their Flash Platform runtime beta program to version 5, delivered as Flash Player version 11.2.300.130. It includes a "sandboxed" version of the 32-bit Flash Player they are calling "Protected Mode for Mozilla Firefox on Windows 7 and Windows Vista systems". It has been over a year since Adobe discussed the Internet Explorer ActiveX Protected Mode version release on their ASSET blog, and the version running on Google Chrome was sandboxed too.
Adobe is building on the successes that they have seen in their Adobe Reader X software. Its sandbox technology has substantially raised the bar for driving up the costs of "offensive research", resulting in a dearth of Itw exploits on Reader X. As in "none" in 2011. This trend reflects 2011 targeted attack activity that we’ve observed. 2011 APT related attacks nailed outdated versions of Adobe Flash software delivered as "authplay.dll" in Adobe Reader v8.x and v9.x and the general Flash component "NPSWF32.dll" used by older versions of Microsoft Office and other applications. Adobe X just wasn't hit. IE Protected Mode wasn't hit. Chrome sandboxed Flash wasn't hit. If there are incident handlers out there that saw a different story, please let me know.
mwcollectd v4, a next-generation low-interaction malware collection honeypot, has just been released. It's written in C++, but the easy integration of additional Python modules means that malware researchers around the world can easily extend the honeypot with new protocols and features.
We're happy to be sponsoring this project, which was mainly developed by Georg Wicherski (one of our virus analysts in Germany) and Mark Schloesser, from RWTH Aachen University. It's published under the LGPL license. If you want to take a look at mwcollectd, it's here, and libemu, which is used by mwcollectd, is here.
On January 13th we raised the alert level for the Kido family to orange: moderate risk. It's been quite a while since an 'old school' network worm has caused such a stir - Kido's managed it by not only relying on critical Windows SMB vulnerabilities to spread but it also bruteforces weak passwords in order to gain access to other machines in a local network.
Because of this (along with a few other things) Kido can be very painful to get rid of. That's why we've decided to release a free tool which can be used to clean infected machines.
You can grab our KidoKiller tool here.
Feel free to give it a try.
Our previous blog on Gpcode said we'd managed to find a way to restore files in addition to those files that can be restored using the PhotoRec utility.
It turns out that if a user has files that are encrypted by Gpcode and versions of those same files that are unencrypted, then the pairs of files (the encrypted and corresponding unencrypted file) can be used to restore other files on the victim machine. This is the method that the StopGpcode2 tool uses.
Where can these unencrypted files be found? They may be the result of using PhotoRec. Moreover, these files may be found in a backup storage or on removable media (e.g., the original files of photographs copied to the hard disk of a computer that has been attacked by Gpcode may still be on a camera’s memory card). Unencrypted files may also have been saved somewhere on a network resource (e.g., films or video clips on a public server) that the Gpcode virus has not reached.
We can't guarantee that files will be restored, as the method used relies not only on the user having unencrypted versions of the affected files but also on the characteristics of the infected machine. All the same, the results we achieved during testing (80% of encrypted files were restored) suggest that it's worth doing if you need to recover your files.
The more pairs of files that can be found the more data that can be restored.
Detailed instructions on the use of the StopGpcode2 tool can be found in the description of Virus.Win32.Gpcode.ak.
Currently, it's not possible to decrypt files encrypted by Gpcode.ak without the private key. However, there is a way in which encrypted files can be restored to their original condition.
When encrypting files, Gpcode.ak creates a new file next to the file that it intends to encrypt. Gpcode writes the encrypted data from the original file data to this new file, and then deletes the original file.
It's known that it is possible to restore a deleted file as long as the data on disk has not been significantly modified. This is why, right from the beginning, we recommended users not to reboot their computers, but to contact us instead. We told users who contacted us to use a range of utilities to restore deleted files from disk. Unfortunately, nearly all the available utilties are shareware – we wanted to offer an effective, accessible utility that could help restore files that had been deleted by Gpcode.
What did we settle on? An excellent free utility called PhotoRec, which was created by Christophe Grenier and which is distributed under General Public License (GPL).
The utility was originally created in order to restore graphics files (presumably that's why it's called PhotoRec, short for Photo Recovery). Later, the functionality was extended, and the utility can currently be used to restore Microsoft Office documents, executable files, PDF and TXT documents, and also a range of file archives.
You can find a full list of supported formats here. The official PhotoRec utility site is here. The PhotoRec utility is part of the TestDisk package, and you can find the latest version of TestDisk, including PhotoRec here.
It should be stressed the PhotoRec excels at the task it was designed for: restoring file data on a specific disk. However, it has difficulty in restoring exact file names and paths. In order to address this issue, we've developed a small, free program, called StopGpcode.
If you've fallen victim to GpCode, don't pay the author of the virus to restore your data. Use PhotoRec instead – if you want, you can make a donation to the developer of the program.
The description of Gpcode contains detailed instructions on how to manually restore files attacked by the virus using PhotoRec and Stopgpcode.
Exactly two years ago we introduced our extended databases.
These databases protect against AdWare, RiskWare and PornWare. Some people like to refer to the extended databases simply as anti-spyware protection, but we actually detect much more than just that with the help of these databases, most notably RiskWare programs.
Back then we still had cumulative updates and the extended databases consisted of three components: advware.avc, riskware.avc and pornware.avc.
Later two of those names changed to adware.avc and obscene.avc. Since the beginning of this year we simply have combined them into extxxx.avc database, where the x stands for a decimal figure. However, we've actually been detecting these types of threats for much longer than two years.
Before we introduced the extended databases the detection of AdWare etc. was included in x-files.avc.
Two years ago it was special to have a separate option to cover such threats, now it is a much more common feature for antivirus programs.
You can select the extended databases by going to KAV's settings, clicking on Threats and exclusions, and then selecting the extended database.
Be sure to read the pop-up message when choosing a database from the dropdown list.
MSN released version 7 of their Messenger yesterday.
In addition to some other new features, the new version also incorporates functions to prevent the spreading of malware.
The developers have taken some serious steps to prevent the sharing or spreading of .pif files. Any incoming or outgoing message with a ".pif" in it will be blocked completely.
Too bad that MSNM doesn't tell you that this is happening. Messages won't get delivered to the recipient, but neither the recipient nor sender will be notified that the message has been blocked. Not very user-friendly, IMHO.
In addition to filtering messages, MSN 7 also filters incoming file transfers. This filtration applies to files such as executables (with extensions such as .exe, .com, .scr etc) and other potentially dangerous types of file such as .vbs and .reg.
We've already seen IM-worms which spread in the form of a link to .scr files, so the measures that MSN developers have taken won't be 100% effective. But I think the complete blocking of .pif files is the most important innovation, as it's IM-worms spreading as .pif files which have been the most 'successful' to date.
Although some users may not like this kind of filtering, I think in the long run we're better off. IM-worms are becoming more and more common. Sooner or later users will have to learn to live with security measures designed to combat their spread.