15-year-old bug allows malicious code execution in all versions of Windows
Microsoft just patched a 15-year-old bug that in some cases allows attackers to take complete control of PCs running all supported versions of Windows. The critical vulnerability will remain unpatched in Windows Server 2003, leaving that version wide open for the remaining five months Microsoft pledged to continue supporting it.
The flaw, which took Microsoft more than 12 months to fix, affects all users who connect to business, corporate, or government networks using the Active Directory service. The database is built into Windows and acts as a combination traffic cop and security guard, granting specific privileges to authorized users and mapping where on a local network various resources are available. The bug—which Microsoft classifies as MS15-011 and the researcher who first reported it calls Jasbug—allows attackers who are in a position to monitor traffic passing between the user and the Active Directory network to launch a man-in-the-middle exploit that executes malicious code on vulnerable machines.
"All computers and devices that are members of a corporate Active Directory may be at risk," warned a blog post published Tuesday by JAS Global Advisors, one of the firms that (along with simMachines) reported the bug to Microsoft in January 2014. "The vulnerability is remotely exploitable and may grant the attacker administrator-level privileges on the target machine/device. Roaming machines—Active Directory member devices that connect to corporate networks via the public Internet (possibly over a Virtual Private Network (VPN))—are at heightened risk."
In a Web post of its own, Microsoft provided the following example of how Jasbug might be exploited on a machine connected over open Wi-Fi at a coffee shop:
Additional details from Microsoft are here.A vulnerability in the Group Policy component of Active Directory allowed attackers to remotely execute malicious code received when connecting to a domain. At the same time, a separate Group Policy flaw could cause it to fail to retrieve valid security policies and instead apply a less secure default group policy. By exploiting the bugs together, attackers could disable the authorization mechanism normally enforced by the domain the targeted user was intending to connect to.
- In this scenario, the attacker has observed traffic across the switch and found that a specific machine is attempting to download a file located at the UNC path: \\10.0.0.100\Share\Login.bat.
- On the attacker machine, a share is set up that exactly matches the UNC path of the file requested by the victim: \\*\Share\Login.bat.
- The attacker will have crafted the contents of Login.bat to execute arbitrary, malicious code on the target system. Depending on the service requesting Login.bat, this could be executed as the local user or as the SYSTEM account on the victim’s machine.
- The attacker then modifies the ARP table in the local switch to ensure that traffic intended for the target server 10.0.0.100 is now routed through to the attacker’s machine.
- When the victim’s machine next requests the file, the attacker’s machine will return the malicious version of Login.bat.This scenario also illustrates that this attack cannot be used broadly across the internet – an attacker need to target a specific system or group of systems that request files with this unique UNC.
It's not yet clear exactly how the attack would work against people using a VPN to funnel traffic through an encrypted tunnel. In theory a VPN prevents man-in-the-middle attackers from being able to read or tamper with Active Directory transactions unless the attackers were first able to decrypt the data. Most likely, the described coffee shop works against VPNs that perform domain-name lookups locally, that is, using the domain name system servers assigned to the local network. Many VPNs are configured this way to make user connections faster and to ease congestion on company or government networks.
This Windows vulnerability isn't as simple as most to fix because it affects the design of core Windows functions rather than implementations of that design. Microsoft said admins should review this link for further guidance. The vulnerability poses at least a
Promoted Comments
This is a pretty crazy series of bugs. MS is already ostensibly
using kerberos to auth all this stuff, and kerberos has good
anti-spoofing crypto.
So both bugs are variations on a theme: The client can be tricked, or just willingly ignores, the configuration to use strong kerberos crypto when talking to the login script SMB server (and other scary cases).
Insert a man-in-the-middle, trick the client into accepting no server authentication and Bob's your Uncle.
Essentially it is a forced downgrade attack like we've seen with SSL/TLS/etc
It also looks like even if these updates are installed, you had better opt into hardened UNC access in your group policy. Which seems completely bonkers - out of the box fully patched windows will not fix this class of vulnerability unless specific configuration has been done to the GPO? Woah.
So why did MS take 12 months to fix this? It appears it is exactly to support the ability to *disable these security checks* and have them *off by default*. Clearly they have significant customers that cannot run with SMB signing turned on for some reason, so the majority of users had to be at risk while MS figured out how to accommodate those special few.
Taken in that light their comments about 'Coordinated Vulnerability Disclosure' seem incredibly self serving, even dangerous.
So both bugs are variations on a theme: The client can be tricked, or just willingly ignores, the configuration to use strong kerberos crypto when talking to the login script SMB server (and other scary cases).
Insert a man-in-the-middle, trick the client into accepting no server authentication and Bob's your Uncle.
Essentially it is a forced downgrade attack like we've seen with SSL/TLS/etc
It also looks like even if these updates are installed, you had better opt into hardened UNC access in your group policy. Which seems completely bonkers - out of the box fully patched windows will not fix this class of vulnerability unless specific configuration has been done to the GPO? Woah.
So why did MS take 12 months to fix this? It appears it is exactly to support the ability to *disable these security checks* and have them *off by default*. Clearly they have significant customers that cannot run with SMB signing turned on for some reason, so the majority of users had to be at risk while MS figured out how to accommodate those special few.
Taken in that light their comments about 'Coordinated Vulnerability Disclosure' seem incredibly self serving, even dangerous.
15-year-old bug allows malicious code execution in all versions of Windows
Reviewed by Unknown
on
2/11/2015
Rating: