PeiBackdoor

December 16, 2017 ~ 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. 🙂

PEI Stage Backdoor for UEFI Compatible Firmware: PeiBackdoor https://t.co/cBOu8R5Yot #InfoSec #CyberSecurity #Security

— CyberPunk (@Hackers_toolbox) December 16, 2017

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/

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

August 19, 2017August 19, 2017 ~ hucktech ~ Leave a comment

Cr4sh is having fun with Windows Device Guard:

Thanks to UEFI and winload it's quite easy to implement such pre-boot intrusion things in reliable way, see my code snippet for more details

— Dmytro Oleksiuk (@d_olex) August 18, 2017

Device Guard enabled Win 10 doesn't allows to debug the Hyper-V core, so I'm planning to introspect it from guest VM using this backdoor

— Dmytro Oleksiuk (@d_olex) August 18, 2017

Btw, winload level backdoors are also convenient for injecting arbitrary code into the VSM secure kernel running in VTL1 pic.twitter.com/GWPd8WGaoJ

— Dmytro Oleksiuk (@d_olex) August 18, 2017

Also, this HvlpBelow1MbPage constant address thing might work for ASLR/NX bypass during exploitation of Hyper-V kernel vulnerabilities

— Dmytro Oleksiuk (@d_olex) August 18, 2017

Made an interesting payload for my evil PCI-E device, VM exit handler backdoor for Hyper-V based on UEFI DXE driver: https://t.co/EdALr4RxlN pic.twitter.com/ZGxXsiaDWi

— Dmytro Oleksiuk (@d_olex) August 18, 2017

Hypervisor introspection from guest VM with the help of DIY Hyper-V backdoor from my previous tweets pic.twitter.com/7oolndxe2M

— Dmytro Oleksiuk (@d_olex) August 19, 2017

Injecting code into *secure* kernel running in *secure* mode on top of *secure* boot??? OMG, we totally need more of that secure stuff!!! https://t.co/3RXeEvyLB1

— Yuriy Bulygin (@c7zero) August 19, 2017

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’s Rogue PCI-E device

April 7, 2017 ~ hucktech ~ Leave a comment

Wow.

Now my rogue PCI-E device can inject DXE phase UEFI drivers into the victim machine boot sequence while IOMMU is still not configured by OS pic.twitter.com/sGJUxHV0K1

— Dmytro Oleksiuk (@d_olex) April 6, 2017

And if anyone is curious — here's full log of TLP packets on PCI-E bus during DMA attack: https://t.co/2rTpfx7IPC https://t.co/5KKsj35SaU

— Dmytro Oleksiuk (@d_olex) April 7, 2017

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

scan_thinkpwn: searches for ThinkPwn vulnerability

March 14, 2017 ~ hucktech ~ Leave a comment

Here’s a Python program by @trufae and me that allows to scan unpacked EFI firmware image for ThinkPwn vulnerability https://t.co/4jfRHdoCBa

— Dmytro Oleksiuk (@d_olex) March 14, 2017

THINKPWN SCANNER: This program is used to scan UEFI drivers extracted from firmware image for ThinkPwn vulnerability in vendor/model agnostic way.
AUTHORS:
@d_olex (aka Cr4sh) — initial Vivisect based version of the program;
@trufae (aka pankake) — radare2 based version (this one);

Read the source code for more user docs, including a detailed source comment about how the code works.

https://github.com/Cr4sh/ThinkPwn/blob/master/scan_thinkpwn.py

More info:
https://github.com/Cr4sh/ThinkPwn
http://blog.cr4.sh/2016/06/exploring-and-exploiting-lenovo.html

Intel updates NUC for SMM vulnerability

December 1, 2016 ~ hucktech ~ Leave a comment

An update to this:

https://firmwaresecurity.com/2016/11/16/intel-nucs-vulnerable-to-smm-exploit/

Intel has updated bits for NUC users:

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

Intel NUC’s Vulnerable to SMM Exploit

November 16, 2016 ~ 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

October 22, 2016October 22, 2016 ~ 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

Another perfect example of how dangerous write-something-where vulns really are: one buggy memory write in SMM leads to total FW pwnage. https://t.co/WWGvDIHyY9

— Nikolaj Schlej (@NikolajSchlej) October 22, 2016

Quick summary on vulnerable Intel and AMI UEFI drivers from my recent article: 1) https://t.co/juJ8mkUSw5
2) https://t.co/qHEbGVbYyu

— Dmytro Oleksiuk (@d_olex) October 22, 2016

PeiBackdoor: new UEFI payload/backdoor tool

August 28, 2016 ~ 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.

I made another small backdoor/infector for UEFI compatible firmwares, this time for PEI phase https://t.co/tihRxIjZsF

— Dmytro Oleksiuk (@d_olex) August 28, 2016

Main use case — reverse engineering and manipulations with platform configuration of your own PC, so, hardware programmer is needed

— Dmytro Oleksiuk (@d_olex) August 28, 2016

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

August 16, 2016 ~ hucktech ~ Leave a comment

I made ThinkPwn exploit more reliable, now it works on EFI 2.x firmwares with new versions of SMM related protocols https://t.co/8F6EtxQgX2

— Dmytro Oleksiuk (@d_olex) August 16, 2016

Also, on EFI 2.x you don’t need to bruteforce callback handle value to trigger the vuln during RT phase from OS, constant GUID is enough

— Dmytro Oleksiuk (@d_olex) August 16, 2016

Oh, and btw, now you can build ThinkPwn for 32-bit firmwares (not sure that there’s any vulnerable 32-bit boards itw except Intel Galileo)

— Dmytro Oleksiuk (@d_olex) August 16, 2016

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

AMI_SMI_Dump

July 18, 2016 ~ hucktech ~ Leave a comment

New tool: ami_smi_dump.py:
Extract SW SMI handlers information from SMRAM dump of Skylake based AMI Aptio V firmware.

I made a small tool that extracts SMI handlers information from SMRAM + flash image dumps of AMI Aptio V firmware: https://t.co/2V5Y6k3mhD

— Dmytro Oleksiuk (@d_olex) July 17, 2016

Updated ami_smi_dump.py, now it can show even more info from SMRAM dump: https://t.co/qTn23vVjtw https://t.co/2V5Y6k3mhD

— Dmytro Oleksiuk (@d_olex) July 17, 2016

Hmm, WordPress renders Github gist pages to be unviewable. Remove the SPACE character after the TLD in the below URL to make it work. Or click on the links in the Twitter links.

https://gist.github.com /Cr4sh/db43cc6687e737d982d3d1c56472c6b9

exploiting Lenovo firmware, part 2D

July 10, 2016 ~ 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

Lenovo customers will see their ThinkPwn patches this August (not so bad for such vuln). Full disclosure: make the world a better place 🙂

— Dmytro Oleksiuk (@d_olex) July 9, 2016

Lenovo updated #ThinkPwn advisory with information about vulnerable models https://t.co/31rpPiHKNR

— Dmytro Oleksiuk (@d_olex) July 9, 2016

exploiting Lenovo firmware, part 2C

July 5, 2016July 5, 2016 ~ hucktech ~ Leave a comment

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

For non Windows it means flash write protection bypass: attacker can install firmware rootkit from running OS

— Dmytro Oleksiuk (@d_olex) July 5, 2016

, to be deadly honest, SMM security is not relevant at all on non-Dell/HP/Lenovo desktops, just because of no BIOS security at all.

— Nikolaj Schlej (@NikolajSchlej) July 5, 2016

Intel provided reference code with this vulnerability to IBV, IBV provided it’s SDK to OEM

— Dmytro Oleksiuk (@d_olex) July 5, 2016

UEFI exploit readme was updated: https://t.co/8pZgtuFVVs ThinkPwn comes to desktops 😈

— Dmytro Oleksiuk (@d_olex) July 5, 2016

More (vulnerable) examples: Gigabyte Z68-UD3H, Z87MX-D3H and Z97-D3H. Sandy through Broadwell affected 🙂 pic.twitter.com/OTFxZXH2Jt

— alex (@al3xtjames) July 5, 2016

A56897A1-A77F-4600-84DB-22B0A801FA9A has the same function, found on Gigabyte Z77X-UD5H, but MANY others too pic.twitter.com/kvX57xDlM5

— alex (@al3xtjames) July 5, 2016

exploiting Lenovo firmware, part 2B

July 1, 2016 ~ 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:

Dear vendors, “give us your 0day vulnerability for free and don’t publish anything” — it’s not a cooperation request pic.twitter.com/l4Lk1mo1AM

— Dmytro Oleksiuk (@d_olex) July 1, 2016

I agreed to do that, but they haven't accepted my terms and conditions (just for case — I haven't asked them about money)

— Dmytro Oleksiuk (@d_olex) July 1, 2016

Lenovo is blaming it’s IBV, so, it’s 100% that there’s others OEM’s that have this vuln in their products

— Dmytro Oleksiuk (@d_olex) July 1, 2016

It seems that Lenovo released some advisory for my System Management Mode vuln (no technical details, no links): https://t.co/31rpPiHKNR

— Dmytro Oleksiuk (@d_olex) July 1, 2016

exploiting Lenovo firmware, part 2A

July 1, 2016 ~ hucktech ~ Leave a comment

A few bits of news to add to this:

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

https://t.co/fMOvXwBOgD — I updated Lenovo firmware 0day exploit readme with important information about vulnerability history

— Dmytro Oleksiuk (@d_olex) June 30, 2016

Great news: it’s is not a Lenovo backdoor, it’s Intel reference code vuln from 2014 that was copy-pasted by OEM/IBV https://t.co/BF7JJOr63J

— Dmytro Oleksiuk (@d_olex) June 29, 2016

Old EDK2 code from Intel vs code from ThinkPad firmware pic.twitter.com/GK9QgIzSnN

— Dmytro Oleksiuk (@d_olex) June 29, 2016

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

June 29, 2016June 29, 2016 ~ hucktech ~ Leave a comment

New article, “Exploring and exploiting Lenovo firmware secrets”: https://t.co/6ZYlifCNAC Code: https://t.co/lrSUKodQTP #ThinkPwn

— Dmytro Oleksiuk (@d_olex) June 29, 2016

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/

Cr4sh on SMM exploits in Lenovo firmware!

February 24, 2016 ~ hucktech ~ Leave a comment

Dmytro Oleksiuk aka Cr4sh has a new blog post on SMM exploits on Lenovo firmware! Very well written and detailed, with source code!

Exploiting SMM callout vulnerabilities in Lenovo firmware
Hi, everyone. In this article I’ll continue to publish my research in PC firmware security field. In previous article, “Breaking UEFI security with software DMA attacks”, I’ve shown how to exploit UEFI boot script table vulnerability and get access to the SMRAM using software DMA attack under Linux. This time we will talk about discovering and exploitation of SMI dispatch vulnerabilities in UEFI System Management Mode drivers. For anyone who’s not familiar with architecture of SMM phase firmware code on UEFI based platforms I’ll strongly recommend to read my other article “Building reliable SMM backdoor for UEFI based platforms”, especially the part about communicating with SMM code using software SMI.

SMM vulnerabilities that I will talk about in this article aren’t new. Around one year ago LegbaCore and Intel Security published two works: “How Many Million BIOSes Would you Like to Infect?” and “A New Class of Vulnerabilities in SMI Handlers” correspondingly, they rediscovered some security issues in SMI handlers code that was actually a known problem among PC firmware developers (for example, same attacks was described in Loïc Duflot work “System Management Mode Design and Security Issues” presented six years ago). Nevertheless, researchers were able to find and report a lot of firmware vulnerabilities of this class in products like Lenovo, Dell, HP laptops and many others (CERT VU#631788). To play with these vulnerabilities I got ThinkPad T450s laptop. According to original security advisory by Lenovo (apparently, it has a lack of technical details) — some unspecified SMM callout vulnerabilities were patched in the latest version of it’s firmware and everything that we need to do is just find out and exploit one of these vulns. […]

http://blog.cr4.sh/2016/02/exploiting-smm-callout-vulnerabilities.html
https://github.com/Cr4sh/fwexpl

Using UEFI_boot_script_expl on Lenovos

January 25, 2016 ~ hucktech ~ Leave a comment

Dmytro “Cr4sh” Oleksiuk has a conversation on Twitter about using using his CHIPSEC-based exploit module against Lenovo models, noting some firmware vulnerabilities in Lenovo x220/x230 laptops.

Here are 5 tweets, let’s see how the non-deterministic WordPress.com rendering software will show them:
https://twitter.com/d_olex/status/6916255973326315
https://twitter.com/d_olex/status/69162603603585024252

Models with SMM lockbox are interesting: boot script table still accessible from OS but copy that actually executed stored inside SMRAM

— Dmytro Oleksiuk (@d_olex) January 25, 2016

Also, it seems that all ThinkPads uses PRx flash protection: it’s not possible to overwrite certain ROM regions even if SMM was pwned

— Dmytro Oleksiuk (@d_olex) January 25, 2016

However, unrestricted access to NVRAM from SMM is still practically valuable because it means pwed secureboot

— Dmytro Oleksiuk (@d_olex) January 25, 2016

It is nice to hear “The most recent ones looks not vulnerable.” Maybe the Lenovo QA team is improving? 🙂 Looking forward to more research on this, more than just a few Tweets, his research is usually very verbose! Also, he has updated the readme on his update script today:

https://github.com/Cr4sh/UEFI_boot_script_expl

UEFI SMM vulnerability research: SmmBackdoor

July 6, 2015 ~ hucktech ~ 1 Comment

Dmytro ‘Cr4sh’ Oleksiuk has been looking into Intel Systems Management Mode (SMM) on UEFI systems. Yesterday he posted a blog with some information on this research, along with some source code. Check out the blog post, it’s a very long document with lots of figures, very good reading.

More Information:

https://github.com/Cr4sh/SmmBackdoor
http://blog.cr4.sh/2015/07/building-reliable-smm-backdoor-for-uefi.html