Tag Archives: Microsoft Windows

Protecting Against the Microsoft JET Database Zero Day Vulnerability

====================
Update: 9th January 2019:
====================
Microsoft have now resolved the unpatched JET vulnerability. It has been designated as CVE-2019-0579. It appears it took extra time since binary differential analysis shows that larger sections of the file msrd3x40.dll have been re-designed to proactively mitigate future vulnerabilities.

Further details are located here. Thank you.

====================
Update: 3rd January 2019:
====================
As of the 19th of December; the firm 0patch have confirmed the incomplete patch for this vulnerability has not yet been revised by Microsoft.

====================
Update: 24th October 2018:
====================
According to Acros Security CEO Mitja Kolsek the fix for this vulnerability from Microsoft is incomplete and mitigates but does not resolve the vulnerability.

As before; my assessment of the difficulty an attacker would face in exploiting this vulnerability remains accurate. The attack first needs you to take an action you wouldn’t otherwise take; if you don’t they can’t compromise your system.

Details of the incomplete nature of the vulnerability are not being disclosed while the patch is re-evaluated. Acros Security has notified Microsoft of this incomplete fix and is awaiting a response. In the meantime; their micropatch completely mitigates the vulnerability.

I’ll keep this post updated as more details become available. Thank you.

=======================
Update: 9th October 2018:
=======================
Microsoft’s scheduled updates for October 2018 resolve this vulnerability. Thank you.

=======================
Original Post:
=======================
In the latter half of last week; Trend Micro’s Zero Day Initiative publically disclosed (defined) a zero day vulnerability (defined) within the Microsoft JET Database Engine (defined).

Why should this vulnerability be considered important?
This vulnerability should be considered high but not critical severity. When exploited it can allow an attacker to execute code (to carry out any action of their choice) but they cannot initiate this automatically/remotely. They must socially engineer a potential victim into opening an attachment ( most likely sent over email or via instant messaging etc.). This attachment would need to be a specific file containing data stored in the JET database format. Another means would be visiting a webpage but 0patch co-founder Mitja Kolsec could not successfully test this means of exploit.

This vulnerability exists on Windows 7 but is believed to also exist on all versions of Windows including the Server versions.

How can I protect my organization/myself from this vulnerability?
At this time; a patch/update from Microsoft is pending and is expected to be made available in October’s Update Tuesday (9th October).

In the meantime; please continue to exercise standard vigilance in particular when using email; e.g. don’t click on suspicious links received within emails, social media, via chat applications etc. Don’t open attachments you weren’t expecting within an email (even if you know the person; since their email account or device they access their email may have been compromised) and download updates for your software and devices from trusted sources e.g. the software/device vendors. This US-CERT advisory also provides advice for safely handling emails.

If you choose to; the firm 0patch has also issued micro-patch for this vulnerability as a group of two patches. This was the same firm who micro-patched the recent Windows Task Scheduler vulnerability. As with the above mitigations; if you wish to deploy this micropatch please test how well it works in your environment thoroughly BEFORE deployment.

Thank you.

Adobe Issues Further Security Updates

Early last week Adobe made available a further un-scheduled emergency security update available for download affecting Creative Cloud Desktop Application version 4.6.0 and earlier. This vulnerability impacts both Apple macOS and Windows systems.

If an attacker were to exploit this they could elevate their privileges (defined). As with the previous security update the vulnerability was responsibly disclosed (defined) to Adobe by Chi Chou of AntFinancial LightYear Labs.

Please follow the steps within this security bulletin to check if the version of Creative Cloud Desktop Application you are using is impacted and if so; follow the steps to install the relevant update.

Thank you.

Adobe Issues Critical Photoshop CC Security Updates

On Wednesday Adobe made available an out of band (un-scheduled) emergency update available for Photoshop CC for both Apple macOS and Windows systems.

Photoshop CC 2018 (versions 19.1.5 and earlier) and Photoshop 2017 (versions 18.1.5 and earlier) are affected by two critical memory corruption vulnerabilities. If an attacker were to exploit these they could achieve remote code execution (defined: the ability for an attacker to remotely carry out any action of their choice on your device). The vulnerabilities were responsibly disclosed (defined) by Kushal Arvind Shah of Fortinet’s FortiGuard Labs to Adobe.

Please follow the steps within Adobe’s security bulletin to install the applicable updates as soon as possible if you use these products.

Thank you.

Intel Lazy Floating Point Vulnerability: What you need to know

====================
Update: 24th July 2018:
====================
I have updated the list of vendor responses below to include further Red Hat versions and CentOS:

Red Hat Enterprise Linux 6:
https://access.redhat.com/errata/RHSA-2018:2164

Red Hat Enterprise Linux 5 and 7:
https://access.redhat.com/solutions/3485131

CentOS 6:
https://lists.centos.org/pipermail/centos-announce/2018-July/022968.html

CentOS 7:
https://lists.centos.org/pipermail/centos-announce/2018-June/022923.html

====================

On Wednesday of last week, a further vulnerability affecting Intel CPUs (defined) was disclosed.

TL;DR: Keep your operating system up to date and you should be fine.

What makes this vulnerability noteworthy?
According to Intel’s security advisory; this is an information disclosure issue. Similar to Spectre/Meltdown the flaw is the result of a performance optimization (used when saving and restoring the current state of applications as a system switches from one application to another). A feature known as Lazy Floating Point (defined) Unit (FPU) is used to save and restore registers (defined) within the CPU used to store floating point numbers (non-integers numbers, namely decimal numbers).

The issue is that these registers may be accessed by another application on the same system. If the registers are storing for example results of performing cryptographic equations for a key you have just created or used to decrypt data, the attacker could use this data to infer what the actual key is. The same applies for any type of data the registers store; that data can be used to infer what the previous contents were via a speculative execution side channel.

This vulnerability has been rated as moderate since it is difficult to exploit via a web browser (in contrast to Spectre) and the updates will be a software update only; no microcode (defined) and/or firmware (defined) updates will be necessary. With exploitation via a web browser being difficult; this vulnerability will likely instead be exploited from the victim system (at attacker will need to have already compromised your system).

How can I protect myself from this vulnerability?
Please note; AMD CPUs are NOT affected by this vulnerability.

The following vendors have responded to this vulnerability with software updates now in progress. Separately Red Hat has completed their updates for Red Hat Linux 5, 6 and 7 (with further applicable updates still in progress).

Other vendors responses are listed below. Thank you:

Amazon Web Services

Apple (currently release notes for an update to macOS to resolve the vulnerability)

DragonFlyBSD

Intel’s Security Advisory

Linux

Microsoft Windows

OpenBSD

Xen Project

Google Chrome Benefits From Windows 10 Security Mitigations

Earlier this year in February, Google added several new security mitigations (defined within this post) to Google Chrome that work in partnership with lesser known changes within the Windows 10 update (known as Build 10586 or Version 1511) made available by Microsoft in November last year.

How Do These New Techniques Work?
In total 3 new mitigations were added:

    1. Block un-trusted fonts
    On numerous occasions over the last year Microsoft have released security updates that address vulnerabilities related to Windows handling of fonts (examples here, here and here (among others)). Such vulnerabilities are of interest to attackers since when successfully exploited they provide the attacker with kernel mode privileges (defined). The concept of a kernel is defined here. A mitigation designed to make exploiting such vulnerabilities more difficult is present in the most recent version of Microsoft EMET version 5.5 and is discussed in more detail on page 11 of the EMET user guide as well as this TechNet article.

    Windows 10 features a system wide means of blocking the use of fonts to only the Windows Font directory (folder) by default located at: C:\Windows\Fonts However due to the application compatibility issues that this feature can cause it is turned off by default. While the ability to enable this security feature for running applications on a per process (defined) basis is available this is unsuitable for Chrome since it creates multiple processes with different security permissions applied. However, the November 2015 Windows 10 added the ability to enable the blocking of fonts for individual processes of which Chrome can now take advantage of.

    2. Block the creation of child processes
    This mitigation is intended to block an attacker’s exploit from creating new running processes without any restrictions of the Google Chrome sandbox (discussed below) on a Windows device if they are successful at exploiting Google Chrome. Google Chrome has always incorporated a protective sandbox (defined) that prevents malicious code from being able to make changes to the computer upon which Google Chrome is installed.

    To address a vulnerability reported by Google to Microsoft in late 2014; the Windows 10 November update provides the ability to applications (if they choose to use it) to block the ability to create child processes including console processes (disused further in the Google bug report linked to above). This new capability is now utilized by Google Chrome.

    3. Block the loading of DLLs (defined) from network drives
    While Windows provides the ability for an application to load a DLL from a network location (e.g. a mapped network drive); this can be used by an attacker to insert malicious code into a legitimate application (e.g. if they substitute a legitimate DLL in a network location with a malicious DLL of the same name).

    This ability has been disabled within Google Chrome when it’s installed on Windows 10 with the November 2015 update further hardening it against this type of attack. This capability is similar to the defences of Microsoft Edge against DLL injection.

    Conclusion
    All of the above new mitigations provide defence-in-depth (defined)(PDF) security against possible future vulnerabilities and provide further incentive for Windows users to migrate to Windows 10. Please do not misunderstand me I am not trying to advocate that users do so, I am simply pointing out the additional security features that are available if you choose to use Windows 10 (with the November update) and Google Chrome in combination.

    Thank you.

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.