Tag: Dmytro Oleksiuk

PeiBackdoor

~ hucktech ~ Leave a comment

Re: https://firmwaresecurity.com/2016/08/28/peibackdoor-new-uefi-payloadbackdoor-tool/

N0where.net has a new story showing how to use this backdoor, and various Twitter news sites are also covering this. 🙂

https://github.com/Cr4sh/PeiBackdoor

https://n0where.net/pei-stage-backdoor-for-uefi-compatible-firmware-peibackdoor/

BTW, the blog site for Dmytro has been down for a few days. A few months ago, it was down for about a week. Hopefully it’ll come back again.
http://blog.cr4.sh/

 

 

PCI Express DIY hacking toolkit

~ hucktech ~ Leave a comment

This repository contains a set of tools and proof of concepts related to PCI-E bus and DMA attacks. It includes HDL design which implements software controllable PCI-E gen 1.1 endpoint device for Xilinx SP605 Evaluation Kit with Spartan-6 FPGA. In comparison with popular USB3380EVB this design allows to operate with raw Transaction Level Packets (TLP) of PCI-E bus and perform full 64-bit memory read/write operations. It’s early version of my first much or less complicated FPGA project, so the speed is quite slow (around 1-2 Mb/s), but in upcoming releases it will be significantly increased by connecting PCI-E endpoint to MicroBlaze soft processor with AXI DMA engine. However, even such low speed is more than enough for reliable implementation of various practical attacks over PCI-E bus: to demonstrate applied use cases of the design, there’s a tool for pre-boot DMA attacks on UEFI based machines which allow executing arbitrary UEFI DXE drivers during platform init. Another example shows how to use pre-boot DMA attacks to inject Hyper-V VM exit handler backdoor into the virtualization-based security enabled Windows 10 Enterprise running on UEFI Secure Boot enabled platform. Provided Hyper-V backdoor PoC might be useful for reverse engineering and exploit development purposes, it provides an interface for inspecting of hypervisor state (VMCS, physical/virtual memory, registers, etc.) from guest partition and perform the guest to host VM escape attacks.

https://github.com/Cr4sh/s6_pcie_microblaze

Cr4sh’s DmaHvBackdoor.c: Hyper-V backdoor for UEFI

~ hucktech ~ Leave a comment

Cr4sh is having fun with Windows Device Guard:

DmaHvBackdoor.c comments:

Part of UEFI DXE driver code that injects Hyper-V VM exit handler backdoor into the Device Guard enabled Windows 10 Enterprise. Execution starts from new_ExitBootServices() — a hook handler for EFI_BOOT_SERVICES.ExitBootServices() which being called by winload!OslFwpKernelSetupPhase1(). After DXE phase exit winload.efi transfers exeution to previously loaded Hyper-V kernel (hvix64.sys) by calling winload!HvlpTransferToHypervisor(). To transfer execution to Hyper-V winload.efi uses a special stub winload!HvlpLowMemoryStub() copied to reserved memory page at constant address 0x2000. During runtime phase this memory page is visible to hypervisor core at the same virtual and physical address and has executable permissions which makes it a perfect place to store our Hyper-V backdoor code. VMExitHandler() is a hook handler for VM exit function of hypervisor core, it might be used for interaction between hypervisor backdoor and guest virtual machines.

WordPress chokes on Github gist-based URLs, so click on initial Tweet above for URL. Or look for entry that matches date:

https://gist.github.com/Cr4sh

Dmytro on Apple PCI-E Thunderbolt

~ hucktech ~ Leave a comment

Dmytro on PCI-E/SMM vulnerability

~ hucktech ~ Leave a comment

Dmytro has an interesting 6-part twitter post on PCI-e security:

Intel NUC SMM exploit

~ hucktech ~ Leave a comment

Intel® Branded NUC’s Vulnerable to SMM exploit
Intel ID:      INTEL-SA-00068
Product family:      Intel® NUC Kits
Impact of vulnerability:      Elevation of Privilege
Severity rating:      Important
Original release:      May 02, 2017
Last revised:      May 02, 2017

Intel is releasing updated BIOS firmware for a privilege escalation issue. This issue affects Intel® NUC Kits listed in the Model Number section below. The issue identified is a method that enables malicious code to gain access to System Management Mode (SMM). A malicious attacker with local administrative access can leverage vulnerable BIOS to execute arbitrary code outside of SMRAM while system is running in System management mode (SMM), potentially compromising the platform. Intel products that are listed below should apply the update. Intel highly recommends updating the BIOS of all Intel® NUC’s to the recommended BIOS or later listed in the table of affected products. Intel would like to thank Security Researcher Dmytro Oleksiuk for discovering and reporting this issue.

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00068&languageid=en-fr

Dmytro’s Rogue PCI-E device

~ hucktech ~ Leave a comment

Wow.

 

https://www.dropbox.com/s/yxgw0bl241hkt3n/pcie_dxe_backdoor_tlp.log?dl=0

Intel NUC’s Vulnerable to SMM Exploit

~ hucktech ~ Leave a comment

A new Intel Security Center advisory:

Intel® Branded NUC’s Vulnerable to SMM Exploit
Intel ID:      INTEL-SA-00057
Product family:      Intel® NUC Kits
Impact of vulnerability:      Elevation of Privilege
Severity rating:      Important
Original release:      Oct 03, 2016
Last revised:      Nov 15, 2016

Intel is releasing updated BIOS firmware for a privilege escalation issue. This issue affects Intel® NUC Kits listed in the affected products section below. The issue identified is a method that enables malicious code to gain access to System Management Mode (SMM). A malicious attacker with local administrative access can leverage the vulnerable BIOS to gain access to System Management Mode (SMM) and take full control of the platform. Intel products that are listed below should apply the update. Intel highly recommends updating the BIOS of all Intel® NUC’s to the recommended BIOS or later listed in the table of affected products. Intel would like to thank Security Researcher Dmytro Oleksiuk for discovering and reporting this issue.

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00057&languageid=en-fr

https://firmwaresecurity.com/2016/10/22/dmytro-takes-on-the-intel-nuc/

Dmytro takes on the Intel NUC

~ hucktech ~ Leave a comment

Dmytro Oleksiuk has a new blog post with UEFI security issues with an Intel NUC using AMI Aptio UEFI BIOS.

(Sad to see that Intel appears to not appear to run CHIPSEC as part of release management QA their own NUCs.)

Exploiting AMI Aptio firmware on example of Intel NUC
[…] Today I’m sharing with you the story of my next x86 machine hacking — we’re going to talk about UEFI vulnerabilities, exploit mitigation features of System Management Mode and new exploit called Aptiocalypsis. Also, this time I did responsible disclosure to Intel and AMI, so, at the moment of this publication you already can patch some of vulnerable products.

Lots of interesting things happened since release of ThinkPwn exploit. Firstly I supposed that vulnerable code was written by Lenovo or its Independent BIOS Vendor (IBV), but later it turned out that they’ve taken this totally mad driver from Intel reference code. This exact code is not available in public, but open source firmware of some Intel boards has it too. For example, SmmRuntimeManagementCallback() function from Intel Quark BSP it’s exactly the same vulnerable code that I’ve found in firmware of my T450s. It’s also interesting that vulnerable code is quite old (it comes from EFI 1.x era) but nevertheless, it was never present in EDK2 source from public repository — its version of QuarkSocPkg was heavily modified in comparison with vulnerable one. The horrible and vulnerable by design piece of code was removed by Intel somewhere in the middle of 2014, but it seems that there were no security advisories regarding this issue. Due to this IBVs had no chance to fix this vulnerability in their relatively old code base and the bug appeared in modern computers from Lenovo, Intel, GIGABYTE, Dell, HP, Fujitsu and other OEM’s (oops!).

Well, I guess at this point it’s much or less clear that currently there’s nothing to do with ThinkPad anymore, it was pwned with 0day, it has too awkward code base that follows ancient version of EFI specification and 8 series chipset that is not the freshest stuff you can get. As my next target for firmware security adventures I’ve decided to take some Skylake based machine of well-known vendor who might have a decent firmware that would be interesting to break. Because I like all kinds of small x86 compatible computers, I’ve put my eye on the latest generation of Intel NUC. It also looks interesting because platform vendor knows his hardware better than anyone else, so, from firmware security perspective, Intel NUC is definitely not the worst choice.[…]

http://blog.cr4.sh/2016/10/exploiting-ami-aptio-firmware.html

 

Intel issues SMM patches for Intel NUCs

~ hucktech ~ Leave a comment

Intel has updated NUCs for the recent SMM EoP issue. They updated their servers earlier.

https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00057&languageid=en-fr

Recommendations:  Intel highly recommends updating the BIOS of all Intel® NUC’s to the recommended BIOS or later listed in the table of affected products.
 
Acknowledgements:  Intel would like to thank Security Researcher Dmytro Oleksiuk for discovering and reporting this issue.

As I understand it, this SMM issue impacts many systems, not just Lenovo and Intel-based products. If you have an OEM-based Intel system, check if they have updates. Lenovo and HP may have some, but it is still unclear about all the other OEMs and IBVs.

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

ThinkPwn updated

~ hucktech ~ Leave a comment

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

Nikolaj joins Apple!!

~ hucktech ~ Leave a comment

WOW!!, Nikolaj joins Apple!! First they hired Legbacore, now Nikolaj!

As well, UEFITool has new maintainers, Alex and Dmytro!!

exploiting Lenovo firmware, part 2D

~ hucktech ~ Leave a comment

A bit more on this:
https://firmwaresecurity.com/2016/07/05/4047/

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

 

exploiting Lenovo firmware, part 2C

~ hucktech ~ Leave a comment

A bit more on this:
https://firmwaresecurity.com/2016/07/01/exploiting-lenovo-firmware-part-2b/

exploiting Lenovo firmware, part 2B

~ hucktech ~ Leave a comment

more on this:
https://firmwaresecurity.com/2016/07/01/exploiting-lenovo-firmware-part-2a/

Lenovo has a response:

System Management Mode (SMM) BIOS Vulnerability
Lenovo Security Advisory:  LEN-8324
Potential Impact:  Execution of code in SMM by an attacker with local administrative access
Severity:  High
Scope of Impact: Industry-wide

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

The researcher also has a few responses:

 

exploiting Lenovo firmware, part 2A

~ hucktech ~ Leave a comment

A few bits of news to add to this:

https://firmwaresecurity.com/2016/06/29/exploiting-lenovo-firmware-part-2/

These days, it is nice to know that a firmware bug is probably an accidental defect, rather than some backdoor.  🙂

In 2015, UEFI Forum used to do Security Advisories, with 2 PDFs each containing more than a dozen potential exploits. I wonder how many of those are in today’s vendors codebases? No more advisories from UEFI Forum since 2015, so who knows what other cut-and-paste OEM/IBV bugs are being propogated? I wish UEFI Forum would issue more Security Advisories, multiple bugfixes on the EDK2-devel project appear to merit this kind of attention.

exploiting Lenovo firmware, part 2

~ hucktech ~ Leave a comment

Cr4sh has written the second article in his series on Lenovo firmware security research:

Exploring and exploiting Lenovo firmware secrets
Hi, everyone! In this article I will continue to publish my research of Lenovo ThinkPad’s firmware. Previously I shown how to discover and exploit SMM callout vulnerabilities on example of SystemSmmAhciAspiLegacyRt UEFI driver 1day vulnerability. Also, I introduced a small toolkit called fwexpl that provides API for comfortable development of firmware exploits for Windows platform. My previous Lenovo exploit was able to execute custom code in SMM, such conditions allow relatively easy bypass of BIOS_CNTL security mechanism which protect firmware code stored inside SPI flash chip on motherboard from unauthorized modifications by operating system (BIOS_CNTL bypass also was discussed in my another article “Breaking UEFI security with software DMA attacks”). In addition to BIOS_CNTL, modern Lenovo computers also use SPI Protected Ranges (aka PRx) flash write protection, so, in this article I will present my generic exploitation technique that allows to bypass PRx and turn arbitrary SMM code execution vulnerability into the flash write protection bypass exploit. This technique also can be applied to UEFI compatible computers of other manufacturers — they all use similar design of specific firmware features that responsible for platform security. In second part of the article I will present a new 0day vulnerability in Lenovo firmware that allows arbitrary SMM code execution on a wide range of Lenovo models and firmware versions including the most recent ones. Exploitation of this vulnerability may lead to the flash write protection bypass, disabling of UEFI Secure Boot, Virtual Secure Mode and Credential Guard bypass in Windows 10 Enterprise and other evil things. […]

http://blog.cr4.sh/2016/06/exploring-and-exploiting-lenovo.html
https://github.com/Cr4sh/ThinkPwn
See-also:
https://firmwaresecurity.com/2016/05/16/fwexpl-pc-firmware-exploitation-tool-and-library/
https://firmwaresecurity.com/2016/02/24/cr4sh-on-smm-exploits-in-lenovo-firmware/

new Thinkpad SMM 0day

~ hucktech ~ Leave a comment

Dmytro Oleksiuk has apparently found a new Lenovo/SMM exploit, not much details yet: