Daily Archives: November 17, 2015

Microsoft Patches Windows Authentication Vulnerability Used To Bypass BitLocker Encryption

During Microsoft’s scheduled release of security updates earlier this month, they issued an update MS15-122 to resolve a security vulnerability responsibly disclosed (defined) to them by security researcher Ian Haken of Synopsys Inc.

How this does flaw work?
Apologies but this explanation is as short as I can make it while explaining what’s happening as we go along:

This authentication bypass succeeds since an artefact used by the Kerberos protocol (defined) is used for malicious intentions.

In a standard scenario where a legitimate user logins onto their organizations domain using their device, their hashed password (defined) is checked against the corresponding password hash stored on the domain controller (defined). However, when the user is away from the office and cannot connect to the domain controller, the user’s hashed credentials (stored within the device) are used to log them on to their device.

A machine/device hashed password is also created and stored on the device. This device password is a defence in depth measure (defined)(PDF) used to prevent a scenario such as a stolen laptop being connected to a purposefully created domain controller in order to access the contents of the stolen device. Since the domain controller would not have any corresponding device password for this stolen device (i.e. it has no prior knowledge of this device), the device remains secure since the attacker can’t logon to it.

In a similar manner to the user’s password as mentioned above however this check of the device password with the domain controller can’t happen if the legitimate user is away from the office. This fact is exploited by this authentication bypass to access the contents of the device.

As discussed above a purposefully created domain controller can be created by the attacker with the same account name used by the owner of the device (this can be obtained by just looking at the login username on the screen of the device or by using a man-in-the-middle attack (defined) to sniff the network (obtain information from passing data packets on a network connection) since DNS and Kerberos send the account username in plaintext (not encrypted)). The attacker also creates a corresponding password for the user’s account on the domain controller that has a creation date many years in the past (in the example code provided on page 8 within this report (PDF), the year 2001 was used).

If the attacker were to connect the device to the newly created domain controller (which is under their control) and try to logon as mentioned above the logon should fail since the domain controller would not have any prior knowledge of that device (no corresponding machine password would be present on the controller). But this check never happens because the account password is checked first and as we will see below, this account password check will eventually succeed (it was never thought that the account password could be changed) resulting in the device being unlocked.

Next; the attacker enters the password they set earlier using the code mentioned above; the password is rejected since it’s very old (the domain controller the device is connected to informs the device of this) and the attacker is asked to set a new password, once they do so, they have access to the device and all the data it contains. The device unlocked the encrypted drive since it received the correct password and did not detect that anything was wrong.

Why Should This Issue Be Considered Important?
In order for this attack to succeed it needs to assume the following:

  • The Windows device to be attacked has been joined to a Windows domain (defined) and a legitimate user from that domain has previously successfully logged in.
  • Microsoft Windows BitLocker is enabled without pre-boot authentication i.e. no PIN or USB drive is required for the Windows login password prompt to be displayed. This is often the case since its more convenient for the users of the device to login.
  • Assumes the attacker has physical access to the target device for a short period of time.

This attack can be executed in a matter of seconds using a set of commands based on the example within page 8 of this report (PDF).

How Can I Protect Myself From This Issue?
You should ensure that all of your Microsoft Windows devices have the update mentioned in Microsoft’s security bulletin MS15-122 installed. This update resolves the issue discussed above.

I recommended installing this update as part of the scheduled November Microsoft updates discussed in a recent blog post. The steps for installing this update and the other November updates are also provided in that blog post.

Thank you.

Blog Post Shout Out (mid November 2015)

Late last week, the security firm CyberArk published a blog post summarizing the findings of a report they have written:

What percentage of your Windows network is exposed to credential theft attacks? By Amy Burnis (CyberArk)

This report details the consequences that can result when an attacker compromises a Microsoft Windows based computing device within your organization’s network and then uses the credentials of the person logged into that device to access further Windows devices and data within your network.

If an attacker can use privileged credentials to laterally traverse a network (i.e. move from device to device compromising more and more credentials as they do so), eventually the attackers can obtain the credentials of a Windows Domain Administrator account (used to administer your Windows Server based domain controller (defined)), with these the Windows based devices on your network can be completely taken over by an attacker.

This method of attack used to obtain privileged credentials is known as a Pass-the-Hash (PtH) attack. Mitigations to protect against Windows credential theft attacks are discussed on pages 10 and 11 of CyberArk’s report.

I hope that the mitigations and advice discussed in the report mentioned above assist with hardening your organization against such attacks.

Thank you.

Further Google Android Stagefright Vulnerabilities Patched

Update: 10th January 2016:
Further updates addressing newer issues within libstagefright have been made available. Please see this more recent blog post for details.

Thank you.

Original Post:
In early November Google began rolling out an update to it’s Android smartphone operating system to resolve 7 CVEs (defined)(2x critical severity, 4x high severity and 1x moderate severity). This update brings Android to Build version LMY48X The newest version of Android version 6.0 (known as Marshmallow) also includes these fixes if it’s patch level is dated the 1st of November or later. This update includes 4 fixes relating to more vulnerabilities in Stagefright (discussed in a previous blog post).

Why Should These Issues Be Considered Important?

The 4 issues related to Stagefright were assigned critical and high severity by Google. Such critical flaws will allow an attacker the ability to have the device carry out any instruction they wish (otherwise known as remote code execution). Google provides more specifics in it’s Google Groups post which includes that attackers could try to exploit these flaws when playing back media in a web browser or via an MMS message (defined).

How Can I Protect Myself From These Issues?
Fixes for these issues began to be made available on the 5th of November to Google Nexus devices. Manufacturers such as Samsung received these updates on the 5th of October.

As mentioned by Sophos you may need to ask your device manufacturer or mobile carrier when this update will be made available to you. As discussed in my previous post on Android updates, please ensure to only apply updates from your mobile carrier or device manufacturer.

Thank you.

Symantec Issues Security Updates for Endpoint Protection Products

Early last week Symantec issued security updates to address 3 critical CVEs (defined) within their Endpoint Protection Manager and Endpoint Protection Client products.

Why Should These Issues Be Considered Important?
Symantec Endpoint Protection Manager (SEPM) was found to be vulnerable to arbitrary Java command execution if an unauthenticated (i.e. a person with no previous access to your Symantec EPM) could access the Java port of the EPM console. In addition, this server was found to not properly handle external data which could lead to code execution with elevated privileges.

The third and final vulnerability was located in the Symantec Endpoint Protection (SEP) clients; which were susceptible to a DLL preloading attack (defined). If an attacker had access to a client and placed a DLL of their choice into an install package for the client, this could have resulted in an attacker being able to run/execute code (allow code of their code to be carried out) of their choice but with System (defined) level privileges meaning that the code could cause a lot more damage than if it had only obtained administrative privileges.

How Can I Protect Myself From These Issues?
Symantec issued a security advisory which contains details of the necessary updates to address these 3 critical issues which were responsibly disclosed (defined) to Symantec. Please note the download link for these updates requires the serial number of your Symantec product in order to proceed.

Moreover, Symantec provides further best practice advise to minimize the impact of these issues within their advisory. They have also released updated IPS (Intrusion Prevention System)(defined) signatures to prevent attempts to exploit the Java Code Execution Elevation of Privilege issue.

If you make use of the affected Symantec corporate anti-malware products within your organization, please install the relevant updates as soon as possible.

Thank you.

Cisco Issues Web Security Appliance Security Updates

In early November Cisco made available security updates to resolve 3 CVEs (defined)(1x critical and 2x high severity) within their Web Security Appliances (WSA).

Why Should These Issues Be Considered Important?
The first and most serious vulnerability could allow an authenticated user (a user already with some level of access to your Cisco appliance) if they pass specific commands as arguments (parameters, defined) to the system scripts used to create certificates that will result in them obtaining root level access (defined) to your security appliance.

The remaining 2 high severity issues could result in a denial of service (DoS, defined) condition when exploited by a remote unauthenticated attacker (i.e. someone with no initial access to your security appliance). These issues are caused by failures to free (make available for use) memory during “opening multiple connections that request file ranges” and retrieving “data from the proxy server cache to terminate a TCP connection.” The result of these denial of service attacks would be your security appliance being temporarily unavailable to carry out it’s role within your organization.

The most severe security issue has no available workaround but the high severity issues have workarounds and indicators of compromise (IOC)(defined) to detect if attacks using these issues have occurred. At this time, the Cisco Product Security Incident Response Team (PSIRT) is not aware of any of these issues being used to attack its customers.

The affected appliances are as follows:

  • Critical issue: Cisco AsyncOS for the WSA versions 8.0 and later, both virtual and hardware versions
  • High severity issues: Cisco AsyncOS versions 8.0 through 8.8 for Cisco WSA on both virtual and hardware appliances.

Steps to determine if your appliances are affected are provided in the 3 Cisco security advisories mentioned below.

How Can I Protect Myself From These Issues?
If your organization uses any of the above mentioned Cisco Web Security Appliances please follow the directions within the 3 Cisco security advisories mentioned below to install the necessary security updates:

Cisco Web Security Appliance Certificate Generation Command Injection Vulnerability
Cisco Web Security Appliance Range Request Denial of Service Vulnerability Advisory 1
Cisco Web Security Appliance Range Request Denial of Service Vulnerability Advisory 2

Thank you.