Windows Exploit Edition | TechSNAP 274

chris

6 years ago

On this weeks episode we cover a UEFI firmware bug that is affecting computers including ThinkPads, tell you how your windows box can be totally pwned even if it’s fully encrypted & talk about the shortcomings of the MD5 checksum. Plus the feedback, the roundup & more!

Thanks to:

Get Paid to Write for DigitalOcean

Direct Download:

RSS Feeds:

Become a supporter on Patreon:

Show Notes:

ThinkPwn, Lenovo and possible other vendors vulnerable to UEFI bug

“This code exploits 0day privileges escalation vulnerability (or backdoor?) in SystemSmmRuntimeRt UEFI driver (GUID is 7C79AC8C-5E6C-4E3D-BA6F-C260EE7C172E) of Lenovo firmware. Vulnerability is present in all of the ThinkPad series laptops, the oldest one that I have checked is X220 and the neweset one is T450s (with latest firmware versions available at this moment). Running of arbitrary System Management Mode code allows attacker to disable flash write protection and infect platform firmware, disable Secure Boot, bypass Virtual Secure Mode (Credential Guard, etc.) on Windows 10 Enterprise and do others evil things.”
an attacker can “disable flash write protection and infect platform firmware, disable Secure Boot, [and] bypass Virtual Secure Mode
“Vulnerable code of SystemSmmRuntimeRt UEFI driver was copy-pasted by Lenovo from Intel reference code for 8-series chipsets.”
“Lenovo is engaging all of its IBVs as well as Intel to identify or rule out any additional instances of the vulnerability’s presence in the BIOS provided to Lenovo by other IBVs, as well as the original purpose of the vulnerable code”
Lenovo Advisory
The vulnerable code has also been found in HP Pavilion Laptops, some Gigabyte Motherboards (Z68, Z77, Z87, Z97), Fujitsu, and Dell.
Exploring and exploiting Lenovo firmware secrets
ThinkPWN, proof of concept exploit

From zero to SYSTEM on a fully encrypted Windows machine

“Whether you want to protect the operating system components or your personal files, a Full Disk Encryption (FDE) solution allows you to keep track of the confidentiality and integrity. One of the most commonly used FDE solutions is Microsoft Bitlocker®, which due to its integration with the Trusted Platform Module (TPM) as well as the Active Directory environment makes it both user-friendly and manageable in a corporate environment.
When the system is protected with a FDE solution, without a pre-boot password, the login or lock screen makes sure attackers with physical access are not able to gain access to the system.”
“In this post we will explain how an attacker with physical access to an active directory integrated system (e.g. through stealing) is able to bypass the login or lock screen, obtain a clear-text version of the user’s password and elevate his privileges to that of a local administrator or SYSTEM. This can be accomplished via two security vulnerabilities which affects all Windows versions (from Vista to 10) and abusing a standard “security” feature.”
“These two vulnerabilities, discovered with the help of my colleague Tom Gilis were reported to Microsoft however only one vulnerability is patched at the time of writing CVE-2016-0049 / MS16-014.
“The other one, which allows you to elevate your privileges to that of a local administrator or SYSTEM is still under investigation by Microsoft and is not yet disclosed here.”
Acknowledgement by Microsoft
Since the time of this post, the patch has been released. It turns out, it is MS16-072
You might remember MS16-072 from TechSNAP #272 as the Windows Update that broke Group Policies!
“Step 1 – Hibernation – Your friendly neighbourhood password dumper”
“Speaking for myself, and probably a lot of other users, shutting down a laptop has become a thing of the past. In order to be able to rapidly start using your system when travelling from one place to another, we put it into sleep (or hibernation) mode, essentially putting all processes on hold to be easily resumed when needed. Although in order to resume your session after sleep or hibernation, you’ll have to enter your password on the lock screen (or at least I hope so), the system has your password stored somewhere in memory in order to resume the different processes. We want the system to dump the contents of the memory on disk so we can recover it later. Hibernation is there to the rescue, but we need to be able to force the system into hibernation, creating the HIBERFIL.SYS.”
“Luckily, the default configuration of a laptop running Windows depicts going into hibernation if the battery hits a critical low. This feature, by default at set 5%, ensures you don’t lose any unsaved documents when your battery dies. Once we force the laptop into hibernation mode we reboot it and move to the next step”
“Step 2 – Bypassing the login or lock screen”
“If the computer is a member of an AD Domain, and the user has logged in on this machine before, so their password is cached locally, all an attacker needed to do is create a rogue Kerberos server with the targets user account’s password set to a value of choice and indicated as expired. Upon login attempt, Windows would then prompt the user to change the password before continuing”
“Once the password change procedure is completed, the cached credentials on the machine are updated with the new password set by the attacker. Because the system is not able to establish a secure connection, the password is not updated on the Kerberos server but still allows the attacker to login when the system no longer has an active network connection (using the cached credentials)”
So, since the attacker set the new password on the Domain Controller (not really, but the computer things they did), they know this password, and when they attempt to login with it, and windows cannot reach the domain controller, it uses this locally cached password, and allows them to login
“Although the authentication has been bypassed, we still only have the (limited) privileges of the victim’s account (taking into consideration this is not an local administrator). This is where the next step comes in, in which we explain how you can obtain full local administrative privileges just by using standard Windows functionalities and thus not relying on any vulnerable installed software.”
“Step 3 – Privilege escalation to SYSTEM”
“We know that the trust between the client and Domain Controller (DC) is not always properly validated, we have a working Active Directory set-up and we have a working rogue DC. The question is are there any other Windows functionality that is failing to properly validate the trust?”
“How about Group Policies? It works on all supported Windows versions. There is no need for any additional (vulnerable) software. No specific configuration requirements”
“There are 2 types of Group Policy Objects (GPO), Computer Configuration and User Configuration Policies.”
“Computer Configuration Policies are applied before logon, the machine account is used to authenticated to the DC in order to retrieve the policies and finally all policies are executed with SYSTEM privileges. Since we don’t know the machine account password using Computer Configuration Policies is not an option.”
“User Configuration Policies are applied after a user is logged in, user’s account is used to authenticated to the DC to retrieved the User Configuration Policies and the policies are either executed as the current logged-on user or as SYSTEM.”
“Now this last type of Policy is interesting because we know the password of the user as we reset it to our likings.”
“Let’s create a Scheduled Task GPO that will execute NetCat as SYSTEM and finally will connect to the listening NetCat service as a the current user.”
On Windows 7, Immediately game over, you own the system
“Windows 7 fails to validate if the DC from where the Group Policies are being applied is indeed a trusted DC. It is assumed that the user credentials are sufficient to acknowledge the trust relationship. In this attack all encrypted traffic remains intact and doesn’t require any modification whatsoever.”
On Windows 10, it didn’t work right out of the box
It turns out, the Rouge DC needs to have a user object matching the SID of the user that is logging in. Luckily, with Mimikatz, you can edit the SID of the user on the Rouge DC to make it match
Additional Coverage: Part 2
Slides
So, Microsoft has patched both of these vulnerabilities, and we are all safe again, right?
“Bypassing patch MS16-014: Yes, you’ve read it right! There is still a way to bypass the Windows Login screen and bypass Authentication 😉 More details will be released soon!”
The author has not released the details yet, as they are waiting on Microsoft to release another patch

The MD5 collision is here

“A while ago a lot of people visited my site (~ 90,000 ) with a post about how easy it is to make two images with same MD5 by using a chosen prefix collision. I used Marc Steven’s HashClash on AWS and estimated the the cost of around $0.65 per collision.”
“Given the level of interest I expected to see cool MD5 collisions popping up all over the place. Possibly it was enough for most people to know it can be done quite easily and cheaply but also I may have missed out enough details in my original post”
A 2014 blog post showed how to create two php scripts with the same MD5
An early 2015 blog post showed two JPGs with the same MD5
So, this version of the tools was able to make two different .jpg images, that had the same MD5 checksum, but different contents, while still being perfectly valid JPG images
The post included instructions and an Amazon AWS images to do the number crunching
That a later follow up post on how to do the same thing with executable files
Same Binaries Blog Post
This example shows a C binary that prints an Angel if a condition is true, and a Devil if it is false
It contains a bunch of filler that can be changed to make the hashes the same in a second version of the file, where the condition is false. The end result is a pair of binaries, with the same MD5 hash, but different output
Using this same technique, Casey Smith (@subtee) managed to make an Angel.exe that is a copy if mimikatz, a windows password dumping utility, and a devil.exe that just says ‘nothing to see here’
Demo of the attack
This means all I need to do is run this tool against my malware, and say, regedit.exe that is on the whitelist in Windows, and now I have a malware binary that will be trusted