JASBUG Fact Sheet

UPDATED: Tue Feb 24 22:26:33 UTC 2015

REFERENCES AND ADDITIONAL INFORMATION:

• US-CERT Vulnerability Note VU#787252
• Microsoft Security Bulletin MS15-011 – Critical
• MS15-011: Vulnerability in Group Policy could allow remote code execution: February 10, 2015
• MS15-011 & MS15-014: Hardening Group Policy
• Guidance on Deployment of MS15-011 and MS15-014
• JASBUG: Improper use of the DNS for Authentication and over-the-Internet exploitation scenarios
• JASBUG: Cutting Through the Fear Uncertainty and Doubt (FUD)

JASBUG Fact Sheet

Here are answers to frequently asked questions about the JASBUG security vulnerability, which was discovered by our firm and was announced by Microsoft on 10 February 2015. (Additional JAS commentary on JASBUG is available here.)

What is this all about?

The Internet Corporation for Assigned Names and Numbers (ICANN) engaged JAS Global Advisors LLC (JAS) and simMachines to research potential technical issues relating to the rollout of new Generic Top Level Domains (New gTLDs) on the Internet. Background is available here.

During the course of the research, JAS and simMachines uncovered a vulnerability not directly related to ICANN’s New gTLD Program nor to new TLDs in general. Once the seriousness of the vulnerability was understood, JAS notified the affected vendor and withheld additional disclosure until the vendor addressed the vulnerability. This response was consistent with ICANN’s Coordinated Vulnerability Disclosure Reporting Process and industry best practices.

The affected vendor, Microsoft, released updated documentation and technical patches as a part of their regular “Patch Tuesday” release on 10 February 2015. Information from Microsoft relating to this issue is available here: https://technet.microsoft.com/library/security/MS15-011.

Since every bug needs a name, this one has been deemed “JASBUG.”

What is the scope of the vulnerability?

Microsoft has classified this vulnerability “Critical” as “…exploitation could allow code execution without user interaction.” This is the most serious rating in Microsoft’s classification taxonomy.

The vulnerability impacts core components of the Microsoft Windows Operating System. All domain-joined Windows Clients and Servers (i.e. Members of a corporate Active Directory) may be at risk. The vulnerability is remotely exploitable and may grant the attacker administrator level privileges on the target machine/device. Roaming machines – domain-joined Windows devices that connect to corporate networks via the public Internet (e.g. from hotels and coffee shops) – are at heightened risk.

Is on-LAN/Man-In-The-Middle the only exploitation scenario?

In this document:

http://blogs.technet.com/b/srd/archive/2015/02/10/ms15-011-amp-ms15-014-hardening-group-policy.aspx

Microsoft does a thorough job explaining the on-LAN attack scenario, “one of the typical attack scenarios.”  “One of” is the operative phrase.

The on-LAN scenario is indeed the most broadly exploitable scenario and is of particular interest given roaming workers taking their corporate machines to a coffee shop or hotel.  These domain-joined Windows machines (i.e. members of a corporate Active Directory) are vulnerable while they’re connected to a non-trusted network without a full (default route) VPN.  While they’re connected to the corporate VPN, they are not vulnerable as far as we know.

It’s worth noting that lots of “folks” and “things” are or can relatively easily be on-LAN.  Just ask Target about their on-LAN fridge vendor.  Ethernet cables running through the ceilings and around the walls of public and semi-public places feeding kiosks and other “interesting stuff” can usually be tampered with fairly easily.

On-LAN is the most easily exploitable scenario, for some definition of easy.  But this is an insidious issue – an issue that keeps on giving – so it’s not the only exploitation scenario.  

We actually found the issue, proved concept, and reported to Microsoft a completely over-the-Internet exploitation scenario.  The on-LAN scenario was developed weeks later as we kept digging into this complex issue.

There are a number of pre-requisites to get that to work – it certainly doesn’t work universally and it depends on some funky misconfigurations and happenstance.  But it works frequently enough to be of concern.  We will release the specifics of the other attack scenarios we’re aware of at some future point, but for now it’s important that folks patch and not become complacent because of a perceived on-LAN requirement.  It’s not a strict requirement.  Go patch.

How was the vulnerability discovered?

The vulnerability was discovered by applying “big data” analytical techniques to very large (and relatively obscure) technical datasets. The analysis revealed unusual patterns in the datasets and focused additional expert inspection. The combination of sophisticated data analytics by simMachines and JAS’ technical security expertise revealed a fundamental design flaw that has remained elusive for at least a decade.

When was it first reported to Microsoft?

The vulnerability was first reported to Microsoft in January 2014. Microsoft immediately understood the seriousness of the vulnerability and began formulating its response.

Why did it take so long to fix?

The circumstances around this vulnerability are unusual — if not unprecedented — necessitating the very long remediation cycle.

Unlike recent high-profile vulnerabilities like Heartbleed, Shellshock, Gotofail, and POODLE, this is a design problem not an implementation problem. The fix required Microsoft to re-engineer core components of the operating system and to add several new features. Careful attention to backwards compatibility and supported configurations was required, and Microsoft performed extensive regression testing to minimize the potential for unanticipated side effects. Additionally, documentation and other communication with IT systems administrators describing the changes were needed.

Additionally, given the nature of the vulnerability, few stopgap mitigation techniques are available. Thus, it was critical to maintain confidentiality such that Microsoft had the time to “fix it right” as opposed to being forced to “fix it fast.” Rushed interim fixes are risky, unreliable, and potentially ineffective.

This is an instance of responsible vulnerability disclosure at its finest. Because of the combined efforts of JAS, simMachines, ICANN, and Microsoft, the Internet is a safer place.

What should IT professionals do?

IT professionals administering Microsoft environments should immediately review the Microsoft documentation available at https://support.microsoft.com/kb/3000483. As remediation involves a new feature that must be configured on Active Directory Clients and Servers, it is important that systems administrators move rapidly but responsibly.

More technical details

http://blogs.technet.com/b/srd/archive/2015/02/10/ms15-011-amp-ms15-014-hardening-group-policy.aspx

When will the Phase Two JAS Name Collisions study be released?

As a result of the vulnerability, the JAS Name Collisions study was split into a Phase One and Phase Two report. Phase One was released in June 2014. JAS and ICANN will work with Microsoft to determine the timeline for release of the Phase Two report.