Microsoft Patch Tuesday Roundup - September 2010 - "Silent but deadly" Edition
"Silent" Worms: Stuxnet
The vulnerability patched with MS10-061 is perhaps one of the most interesting we've covered in a "Patch Tuesday" post this year. The vulnerability was discovered when antivirus researchers at Kaspersky Lab analyzed malware called "Stuxnet". The malware was one of the first worms to use the LNK vulnerability, and contained code to exploit three other vulnerabilities, the print spooler vulnerability patched by MS10-061 and two other unnamed privilege escalation vulnerabilities that have yet to be patched. Its not everyday that we hear of malware in the wild exploiting 4 0-day vulnerabilities.
I am not easily impressed (in fact, I am even less than impressed) with the capabilities of most malware in the wild. However, there are some facts about the "Stuxnet" malware that do impress me:
- Stuxnet also contains an exploit for a vulnerability from 2008. It will only execute this exploit if it determines it is inside an organization using SCADA systems and not a typical corporation.
- Stuxnet was written specifically to attack control systems, and is the first publicly known malware to contain a rootkit for PLCs, devices that control SCADA systems. The rootkit silently waits for commands.
- Stuxnet gains access to control systems using default passwords and is rumored to have compromised 14 different control systems-based organizations.
- Stuxnet was first thought to primarily use USB devices to propagate (likely to get around "air gapped" security measures)
There was an interesting quote from Symantec that stated, "Symantec gained control of the domain used to send commands to infected machines shortly after Stuxnet was discovered". Apparently, this turned over control of Stuxnet-infected systems to Symantec. I just don't understand the logic behind the malware authors; if they had used fast flux, they may still have control over the botnet they seemed to have worked so hard to implement.
I've been trying to find out exactly what the phrase "privately reported" means with respect to Microsoft bulletins. The question is whether this means a vulnerability was disclosed to Microsoft by a third party, internally reported within Microsoft or if they are not making the distinction. I dug deeper into this month's bulletins and found that 8 out of the 9 bulletins credit third-party security researchers with discovering the vulnerability (some are also listed as "publicly disclosed"). One bulletin, MS10-068, does not have an acknowledgements section at this time.
It would seem that "privately reported" means that Microsoft is not finding and disclosing vulnerabilities themselves. Polling the security community (in my very scientific Twitter post asking for input), I received several reports that stated Microsoft does not issue security vulnerabilities for vulnerabilities discovered "in house" unless also reported by a third party. There is further evidence of this documented in the article titled, "Microsoft admits to silent security patching". Mike Reavey, director of the Microsoft Security Response Center states, "We don't document every issue found". The article goes on to cite two advisories released by Core Security Technologies that uncovered additional patches for undisclosed vulnerabilities in two previous security bulletins, including MS10-024 and MS10-028.
Despite some of the flaws in Microsoft's security practices (several of which we have discussed in previous posts), they do a good job of trying to protect their customers. However, silently fixing vulnerabilities may correct the problem, but leaves customers hanging in the breeze until such a patch is installed and makes it difficult to truly test for a missing patch if they don't know it's part of a bulletin. Furthermore, the silently fixed vulnerability may not be factored into the criticality rating, perhaps influencing would-be low risk bulletins and turning them into high-risk bulletins. For this, we honor the hard working researchers who discovered the vulnerabilities patched this month and credit them below. As for the mysterious discoverer of MS10-068, we thank you (maybe that person is the sixth ninja in the picture above, who knows!).
To further aid in your efforts in evaluating the dangers of the Microsoft Patch Tuesday mayhem, Tenable's Research team has published plugins for each of the security bulletins issued this month:
- MS10-061 - Nessus Plugin ID 49219 (Credentialed Check) - Printer sharing needs to be enabled in order for the system to be vulnerable. More information on configurations that lead to vulnerable systems can be found on the Microsoft Research & Defense Blog. Also note that the credits go to the antivirus researchers, when in reality the vulnerability was in the wild before being patched and was likely discovered, acquired or bought by a malware author.
Credit: Sergey Golovanov, Alexander Gostev, Maxim Golovkin, and Alexey Monastyrsky of Kaspersky Lab, and Vitaly Kiktenko and Alexander Saprykin of Design and Test Lab and Liam O Morchu of Symantec
- MS10-062 - Nessus Plugin ID 49220 (Credentialed Check) - MPEG-4 Codec vulnerability allows for remote code execution. I can foresee attackers putting malicious media files on P2P servers in an attempt to compromise user workstations. A great social engineering technique would be to title it "Unreleased Justin Bieber".
Credit: Matthew Watchinski of Sourcefire VRT
- MS10-063 - Nessus Plugin ID 49221 (Credentialed Check) - I find it interesting that someone from Red Hat found a vulnerability in Windows related to Unicode processing. Microsoft Office products (XP, 2003, and 2007) suffer from this flaw that allows for remote code execution when parsing certain font types.
Credits: Carsten Book of Mozilla Corporation and Marc Schoenefeld of the Red Hat Security Response Team
- MS10-064 - Nessus Plugin ID 49222 (Credentialed Check) - Vulnerability in Outlook that can be exploited when a user opens or previews an email message. This is a particularly dangerous client side attack, as you only have to social engineer the user to open an email message, not an attachment.
Credit: Dyon Balding of Secunia
- MS10-065 - Nessus Plugin ID 49223 (Credentialed Check) - IIS servers with FastCGI enabled are vulnerable to a remote code execution vulnerability that can be exploited by sending HTTP requests (CVE-2010-2730). Two other vulnerabilities were patched (not requiring FastCGi), including a denial of service and privilege escalation vulnerability.
Credit: Jinsik Shim and Travis Raybold of Rubicon West
- MS10-066 - Nessus Plugin ID 49224 (Credentialed Check) - A client-side RPC vulnerability that allows remote code execution.
Credit: Yamata Li of Palo Alto Networks
- MS10-067 - Nessus Plugin ID 49225 (Credentialed Check) - WordPad is vulnerable to a remote code execution flaw that can be triggered when a user attempts to convert Word 97 documents.
Credit: S0lute of iDefense Labs
- MS10-068 - Nessus Plugin ID 49226 (Credentialed Check) - Privilege escalation due to a flaw in LDAP.
Credit: Not given (The credit was not listed in the advisory, so we can spare your Google searches for a hacker with the handle "Not given").
- MS10-069 - Nessus Plugin ID 49227 (Credentialed Check) - Vulnerability in the Client/Server Runtime Subsystem (CSRSS) when using Chinese, Japanese or Korean system locale. It makes sense that this was reported by IBM Japan.
Credit: IBM Japan
- Microsoft Security Bulletin Summary for September 2010
- OSVDB Microsoft Bulletins - Complete Reference
- Microsoft Patch Tuesday Roundup - August 2010 - "Geronimo!" Edition
- Microsoft Patch Tuesday Roundup - July 2010 - "Jedi Mind Trick" Edition
- Microsoft Patch Tuesday - June 2010 - "Everything is Vulnerable" Edition
- Microsoft Patch Tuesday - May 2010 - "Language Barrier" Edition
- Microsoft Patch Tuesday - April 2010 - "Superman" Edition
- Microsoft Patch Tuesday - March 2010 - "It Won't Happen To Me" Edition
- Microsoft Patch Tuesday - February 2010 - "From Microsoft with Love" Edition
- Microsoft Patch Tuesday - January 2010 - "Aged Cheese" Edition