March's Patch Tuesday brings five patches to us, fixing Internet Explorer, DirectShow, Silverlight, kernel-mode drivers, and the Security Account Manager Remote Protocol.
MS14-012 fixes 18 unique vulnerabilities, one of which has been publicly disclosed:
CVE-2014-0322. This vulnerability has been exploited as early as January 20, 2014, being used in targeted attacks against visitors to the U.S. Veterans of Foreign Wars' website, as well as organizations associated with the French aerospace association, GIFAS. More information about these attacks is available at the
FireEye and
Websense blog posts. Microsoft has released an
advisory about this vulnerability, as well as an
MSHTML Shim Workaround to mitigate this vulnerability until the patch can be applied. Reports confirm that at least one of the attacks aborted the exploitation process if EMET is installed, rather than trying to bypass it, so if you were using EMET and were attacked during these campaigns, you would have been protected. While this vulnerability has received much public attention, it is also worth noting that another vulnerability patched in this bulletin,
CVE-2014-0324, has been exploited in targeted attacks. Suffice it to say that it is extremely important to install
MS14-012 as soon as possible.
MS14-013 fixes a critical vulnerability in DirectShow. This vulnerability was not publicly disclosed, nor was it exploited in the wild. The vulnerability itself lies within how JPEG images are parsed by DirectShow, which means that exploits targeting this vulnerability will likely be delivered through compromised web pages or embedded within documents that are sent as part of a targeted email campaign. Because the vulnerable code exists outside of the kernel, users that are running with least privileges (non-admin), will be least affected by this vulnerability, because the attacker will not be able to do as much on a machine compromised by exploiting this vulnerability. Attackers will be particularly interested in this vulnerability because DirectShow has seen little activity over the last year in terms of vulnerabilities patched, with the only patch to DirectShow in 2013 being provided in MS13-056.
MS14-014 fixes one important vulnerability in Silverlight 5. The vulnerability permits attackers to bypass ASLR and DEP, two effective exploit mitigation technologies when combined with each other. In order to take advantage of the vulnerability fixed by
MS14-014, however, an attacker would require the use of a secondary exploit in order to achieve code execution on the system. From that point, they would leverage this vulnerability to bypass ASLR/DEP. We saw an ASLR bypass fixed in the .NET framework back in January with
MS14-009, and the month before that with
MS13-106 fixing an ASLR bypass with Office, so security feature bypass vulnerabilities are being actively investigated and subsequently fixed. While this was privately disclosed and no exploits have been observed to target this vulnerability in the wild, until you can get the patch deployed, simply block Silverlight from running in Internet Explorer, Firefox, and Chrome.
MS14-015 addresses two separate vulnerabilities in Windows kernel-mode drivers.
CVE-2014-0300 is a privately reported elevation of privilege vulnerability, whereas
CVE-2014-0323 is an information disclosure that was publicly disclosed; no reports of exploitation of either vulnerability have surfaced. It's worth noting that
CVE-2014-0323 is an information disclosure vulnerability only for older versions of the affected versions of Windows; in newer versions of Windows, the vulnerability only manifests as a denial of service. In order to exploit either of these vulnerabilities, an attacker must be able to locally authenticate against the system, which is common among kernel-mode driver vulnerabilities.
MS14-016 addresses a security feature bypass vulnerability in the Security Account Manager Remote (SAMR) protocol. This vulnerability exists because Windows fails to correctly validate user lockout states, meaning that an attacker can brute-force username/password combinations without fear of locking out a user account, which would prevent the attacker from guessing further passwords for that account. While an attacker can use this vulnerability to gain access to an account via brute-forcing, the attacker must already know a target's username and be able to connect to the domain controller. This will be a large deterrent for attackers considering investigating this vulnerability, since other more lucrative and less noticeable attacks are made possible with this month's collection of vulnerabilities.
Be sure to patch Internet Explorer (
MS14-012), followed by DirectShow (
MS14-013), Silverlight (
MS14-014), kernel-mode drivers (
MS14-015), followed lastly by the SAMR protocol (
MS14-016). Also, be sure to join us for the Vulnerability Expert Forum tomorrow, Wednesday, March 12 at 1pm PT, where we cover these patches, as well as other security news. Sign up
here.
>> Hello VEF Attendees! Participate in our monthly giveaway here. Answer the question in the comments to win an iPad Mini!
Are you ready to say “Adios!” to XP?
Most insightful and/or awesome answer wins!
>> VEF News Articles
IE10 0day
In the Wild
Linksys Worm "TheMoon"
Do Not Pass QA, Do Not Goto Fail: Catching Subtle Bugs In The Act
EMET 5.0 Technical Preview
Yahoo Email Crossdomain Info Leak
I Know Why You Went to the Clinic: Risks and Realization of HTTPS Traffic Analysis
>> VEF Questions & Comments
Mona was interested about, "...the difference between a privately and publicly disclosed exploit?" Exploit and vulnerability can be used interchangeably here. Public disclosure involves a researcher or InfoSec person (IT Admin, CSO, etc. etc.) that has publicly announced the existence of a vulnerability and/or exploit. A privately disclosed vulnerability/exploit is usually one that has been responsibly disclosed to the vendor responsible for fixing the problem. There are a few variations regarding publicly and privately disclosed issues, but most fall into these two categories.
Joseph wanted to know, "when you state that Chrome has not seen active exploits that is for that particular KB correct?" We mean that Chrome has not had *ANY* in the wild exploits... that have been discovered. Companies like VUPEN have Chrome 0day in their repositories, and sell exploits like that to state-like entities with deep pockets. There may be exploits for Chrome actively being used out there, just like there may be exploits for any piece of software used in the wild. The difference between Internet Explorer/Firefox and Chrome is that no exploits for Chrome are publicly available. No attack campaigns have specifically leveraged a weakness in Chrome. No exploit frameworks or exploit kits have exploits for Chrome either.
Dan asks, "Who is Pinkie Pie?" Answer:
he's a legit teenage hacker that has repeatedly pwned Chrome.
Thank you to all who attended this month’s VEF! We appreciate all the questions and comments. If there was a question you asked that we did not answer on the VEF, or did not mention in this blog post, please contact us directly
research@BeyondTrust.com.
