Tag: Windows

Peter Jones on Secure Boot failures and mitigations

~ hucktech ~ Leave a comment

I just now came across a blog post written by Peter Jones from LAST MONTH on that “Microsoft Secure Boot Golden Key” news reports that is worth reading. Peter owns the Linux shim, so he knows a bit about UEFI’s boot process.

https://blog.uncooperative.org/blog/2016/08/18/secure-boot-failures-and-mitigation/

Especially because I’ve had nearly nothing useful in this blog on this post:

more on Microsoft UEFI Secure Boot golden key news

 

Microsoft UEFI Secure Boot key problem

Also note other articles in Peter’s blog: he makes regular canary posts about the state of his Shim code. I wish all of the boot/firmware code required all contributes to have canaries!

Alex’s SimpleVisor now supports EPT and VPID

~ hucktech ~ Leave a comment

Re: Alex’s Intel x64 Windows-based hypervisor:

SimpleVisor: new hypervisor for Intel x64 Windows

it now supports more features:

https://twitter.com/aionescu/status/769280829805645824

https://github.com/ionescu007/SimpleVisor/commit/fd1d7e043a24fd4afd72dc5f040d04475f9e5acd

https://github.com/ionescu007/SimpleVisor

https://twitter.com/aionescu/status/769726204387602437

I hope he targets UefiVisor next. I am guessing that UEFI will get more interesting as an OS — and not just a bootloader — once someone ports a VM to a UEFI app.

PeiBackdoor: new UEFI payload/backdoor tool

~ hucktech ~ 1 Comment

Dmytro Oleksiuk (aka Cr4sh) has created a new UEFI security researcher tool: PeiBackdoor, which hooks into the init code of UEFI. (PEI is the Pre-uEfi-Init phase, before all the UEFI protocols are in place, the init code of UEFI.) It uses Capstone, and requires Windows.

PEI stage backdoor for UEFI compatible firmware

This project implements early stage firmware backdoor for UEFI based firmware. It allows to execute arbitrary code written in C during Pre EFI Init (PEI) phase of Platform Initialization (PI). This backdoor might be useful for low level manipulations with the target platform configuration when the most of the platform configuration registers are not locked yet. […]

PEI backdoor project includes:

* PeiBackdoor.py – Python program that allows to infect raw flash images or individual UEFI PEI drivers with the backdoor code.
* PeiBackdoor_IA32.efi, PeiBackdoor_IA32.pdb – 32-bit PEI backdoor binary compiled with ACTIVE_PLATFORM = IA32.
* PeiBackdoor_X64.efi, PeiBackdoor_X64.pdb – 64-bit PEI backdoor binary compiled with ACTIVE_PLATFORM = X64.
* PeiBackdoor.inf – PEI backdoor project configuration for EDK2 build environment.
* config.h – PEI backdoor build options.
* payload.c – Put your own PEI stage code into this source file and call it from Payload() function.
* src/ – Rest of the PEI backdoor code.

PeiBackdoor.py is using Capstone engine and pefile Python libraries, you need to install them with pip install capstone pefile command.
[…]

https://github.com/Cr4sh/PeiBackdoor

VBoxHardenedLoader

~ hucktech ~ Leave a comment

[…]What we will target:
– DMI Information;
– IDE/AHCI devices (harddisks, cd-rom’s);
– ACPI OEM Information;
– Ethernet Adapter MAC address;
– PXE Boot data;
– ACPI DSDT (Differentiated System Description Table);
– ACPI SSDT (Secondary System Descriptor Table);
– VGA Video BIOS data;
– BIOS data;
– VM splashscreen (optional, just for nice looking).
[…]

https://github.com/hfiref0x/VBoxHardenedLoader

http://www.kernelmode.info/forum/viewtopic.php?f=11&t=3478

It requires Visual Studio and only targets Microsoft Windows. No Linux, FreeBSD, Mac OS X support. 😦

Somewhat related, there are also these 2 projects:

UEFI VirtualBox tutorial

VirtualBox hardened loader

UEFI Forum updates Secure Boot revocation database?

~ hucktech ~ Leave a comment

I wish I knew some more authoritative sources of news for this Microsoft Secure Boot story… 😦 The below post implies that the UEFI Forum’s Secure Boot recovation list file has been updated in response to recent news.

I REALLY wish the UEFI Forum would *announce* when they update their Secure Boot revocation list, and include version history to the changes, and keep older releases available for diffing against current one. It seems something this important should not be under public version control so you can see when keys come and go, and why. The current web page on this database should include information about the entries in the current database, and show changes and why. The page for this database should include end-user information for sysadmins to apply this to their systems, I see no real documentation on this page on how to properly use this database.
http://uefi.org/revocationlistfile

excerpt from https://blog.uncooperative.org/blog/2016/08/18/secure-boot-failures-and-mitigation/

[…] In response, UEFI is distributing an updated version of the Secure Boot revocation list, aka dbx. dbx is used to remove previously granted access from a UEFI driver or application, or from a signing certificate, declaring that signature invalid or signatures with the blacklisted certificate to be invalid. This update adds 64 new new individual signature entries into dbx, raising the total to 77.  […]

more on Microsoft UEFI Secure Boot golden key news

~ hucktech ~ Leave a comment

There are a few news stories coming out saying that the recent Microsoft Secure Boot stories are mostly false, pointing to a Steve Gibson video podcast.

If someone had some good technical background on this story, please leave a Comment to this post, thanks!

https://redmondmag.com/articles/2016/08/17/windows-secure-boot-slip-up.aspx

Kurt Mackie has a story in Redmond Magazine about the recent Microsoft Secure Boot news:

[…] There were no actual software keys involved when anonymous researchers claimed that Microsoft had leaked so-called “golden keys” to the Windows secure boot protection scheme, according to an industry veteran. That point of view was offered by Steve Gibson, president and founder of Gibson Research Corp., a small software development firm in Laguna Hills, Calif. “It was completely wrongly reported” by the press, Gibson said in a “Security Now” show yesterday. Gibson is cohost on the show, which is published by the Twit network. “It was nice work,” Gibson said about the researchers’ findings, “but the whole golden key was an absolute red herring referring to the notion of backdoor systems. But this wasn’t that. It was a mistake.” […] “What this actually was was an implementation design error in the handling of boot permission policies which can be used to trick older versions of the UEFI secure boot manager using some components of an update. So the so-called ‘Redstone’ version of Windows 10, which is version 1607, we know it as the ‘anniversary update,’ it added some new technology in the concept of supplemental secure boot policies, which can, for example, be used for test-signing development code. And of course, that could also be [used for running] malicious rootkits and so on.” […]

http://www.winbeta.org/news/microsofts-golden-key-agenda-actuality

Kareem Anderson of WinBeta has a similar story:

Microsoft’s ‘Golden key’ is more agenda than actuality “None of that is true. Complete misreporting.”

ThinkPwn updated

~ hucktech ~ Leave a comment

https://github.com/Cr4sh/ThinkPwn/commit/d496e7d9a4bbb1e2903a94802760d52c1e46c037
https://github.com/Cr4sh/ThinkPwn/

Microsoft UEFI Secure Boot key problem

~ hucktech ~ Leave a comment

Chris Williams has a story in The Register about some problems that Microsoft is having with UEFI Secure Boot:
Bungling Microsoft singlehandedly proves that golden backdoor keys are a terrible idea
Redmond races to revoke Secure Boot policy

Updated Microsoft leaked the golden keys that unlock Windows-powered tablets, phones and other devices sealed by Secure Boot – and is now scrambling to undo the blunder.

These skeleton keys can be used to install non-Redmond operating systems on locked-down computers. In other words, on devices that do not allow you to disable Secure Boot even if you have administrator rights – such as ARM-based Windows RT tablets – it is now possible to sidestep this block and run, say, GNU/Linux or Android. […]

http://www.theregister.co.uk/2016/08/10/microsoft_secure_boot_ms16_100/

Secure Boot and driver signing changes in latest Windows 10

~ hucktech ~ Leave a comment

Joshua Baxter of Microsoft posted a new article in the Windows hardware certification blog, about changes in Win10 driver signing:

Driver Signing changes in Windows 10, version 1607
Last year, we announced that beginning with the release of Windows 10, all new Windows 10 kernel mode drivers must be submitted to the Windows Hardware Developer Center Dashboard portal (Dev Portal) to be digitally signed by Microsoft. However, due to technical and ecosystem readiness issues, this was not enforced by Windows Code Integrity and remained only a policy statement. Starting with new installations of Windows 10, version 1607, the previously defined driver signing rules will be enforced by the Operating System, and Windows 10, version 1607 will not load any new kernel mode drivers which are not signed by the Dev Portal. OS signing enforcement is only for new OS installations; systems upgraded from an earlier OS to Windows 10, version 1607 will not be affected by this change. We’re making these changes to help make Windows more secure. These changes limit the risk of an end-user system being compromised by malicious driver software. […]

More info, including a FAQ on how Secure Boot impacts this:

https://blogs.msdn.microsoft.com/windows_hardware_certification/2016/07/26/driver-signing-changes-in-windows-10-version-1607/

Microsoft on TPM Lockout

~ hucktech ~ Leave a comment

Rafal Sosnowski of Microsoft has a new blog post on TPM:

Hello everyone. It’s Rafal Sosnowski from Microsoft Dubai Security PFE Team. Today, I am going to talk about TPM Lockout state. TPM (Trusted Platform Module) is a small chip on the motherboard (discrete TPM) or part of the CPU implementation (firmware TPM) which can be used to securely store small amount of information (certificates, private keys, virtual smartcards, Bitlocker keys etc.). That data is completely isolated from HDD and partially from OS thus giving it maximum protection. To get access to that information from OS level user has to present some kind of authorization value. For example, Bitlocker PIN to get access to the Bitlocker Keys, Virtual smart-card PIN to get access to the certificates and private keys etc. However, TPM has special anti-hammering logic which prevents malicious user from guessing that authorization data indefinitely. Number of possible PIN failures varies across TPM specification: […]

Full post:
https://blogs.technet.microsoft.com/dubaisec/2016/07/10/tpm-lockout/

Microsoft MEX Windbg extension

~ hucktech ~ Leave a comment

Microsoft recently released a new Windows Windbg debugger extension called MEX. It has a variety of features, dozens of commands for many of Microsoft’s products. It appears to have been removed from the download site for a while, but it is up now, at least for the moment.

 

There’s a copy of the MEX help usage listed here:
https://github.com/REhints/WinDbg/tree/master/MEX

 

Intel Graphics Driver for Windows: EOP vulnerability

~ hucktech ~ Leave a comment

Intel has released a security advisory for Intel Graphics Drivers for Windows. Excerpted announcement:

Multiple Potential Vulnerabilities in the Intel® Graphics Driver for Microsoft Windows
Impact of vulnerability:      Elevation of Privilege
Severity rating:      Important

Multiple potential vulnerabilities exist in the Intel® Graphics Driver for Microsoft Windows impacting versions prior to 28MAR2016.  The vulnerabilities can lead to a privilege escalation or denial of service condition. Intel highly recommends that customers of the affected products obtain and apply the latest versions of the driver. Discovered by Piotr Bania of Cisco Talos

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00054&languageid=en-fr
https://downloadcenter.intel.com/product/80939/Graphics-Drivers
http://www.talosintelligence.com/reports/TALOS-2016-0087/

exploiting Lenovo firmware, part 2D

~ hucktech ~ Leave a comment

A bit more on this:

exploiting Lenovo firmware, part 2C

Lenovo has updated their support document. The initial version had no technical details. The update now has a huge list of models which are affected or not. The researcher also mentions that an update from the vendor is expected next month. I’m still waiting to see the IBV’s and other OEMs responses to this.

https://support.lenovo.com/us/en/solutions/LEN-8324

 

WinAFL: AFL fork for Windows

~ hucktech ~ Leave a comment

Excerpt from readme:

[…]
Original AFL code written by Michal Zalewski <lcamtuf@google.com>
Windows fork written and maintained by Ivan Fratric <ifratric@google.com>
Copyright 2016 Google Inc. All Rights Reserved.
[…] Unfortunately, the original AFL does not work on Windows due to very *nix-specific design (e.g. instrumentation, forkserver etc). This project is a fork of AFL that uses different instrumentation approach which works on Windows even for black box binary fuzzing. […] The WinAFL approach: Instead of instrumenting the code at compilation time, WinAFL relies on dynamic instrumentation using DynamoRIO to measure and extract target coverage. This approach has been found to introduce an overhead about 2x compared to the native execution speed, which is comparable to the original AFL in binary instrumentation mode. To improve the process startup time, WinAFL relies heavily on persistant fuzzing mode, that is, executing multiple input samples without restarting the target process. This is accomplished by selecting a target function (that the user wants to fuzz) and instrumenting it so that it runs in a loop. […]

More info:
http://dynamorio.org/
https://github.com/DynamoRIO/dynamorio
https://github.com/ivanfratric/winafl