new Windows UEFI security protections deciphered

Microsoft added some new UEFI protections to Windows, but it is not well-documented, so the firmware security researcher community is guessing at what it does:

https://twitter.com/mattifestation/status/904849903934873600

Intel AMT Upgradable to Vulnerable Firmware

Intel AMTĀ® Upgradable to Vulnerable Firmware
Intel ID: INTEL-SA-00082
Product family: Intel AMTĀ®
Impact of vulnerability: Elevation of Privilege
Severity rating: Moderate
Original release: Sep 05, 2017
Last revised: Sep 05, 2017

IntelĀ® Active Management Technology, IntelĀ® Standard Manageability, and IntelĀ® Small Business Technology firmware versions 11.0.25.3001 and 11.0.26.3000 can be upgraded to firmware version 11.6.x.1xxx which is vulnerable to CVE-2017-5689 and can be performed by a local user with administrative privileges.This version of firmware can potentially impact IntelĀ® Active Management Technology (AMT), IntelĀ® Standard Manageability (ISM) or IntelĀ® Small Business Technology (SBT). Consumer PCs with consumer firmware and data center servers using IntelĀ® Server Platform Services are not affected by this vulnerability. Intel recommends that users contact their system manufacturers for updated firmware which mitigates this issue. This issue was discovered during Intel internal validation.[…]

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

 

SigThief: PE signature tool

I’ve noticed during testing against Anti-Virus over the years that each is different and each prioritize PE signatures differently, whether the signature is valid or not. There are some Anti-Virus vendors that give priority to certain certificate authorities without checking that the signature is actually valid, and there are those that just check to see that the certTable is populated with some value. It’s a mess. So I’m releasing this tool to let you quickly do your testing and feel free to report it to vendors or not. In short it will rip a signature off a signed PE file and append it to another one, fixing up the certificate table to sign the file. Of course it’s not a valid signature and that’s the point![…]

https://github.com/secretsquirrel/SigThief

 

Passmark’s memtest86 issues [with Minnowboards]

You might want to re-run memtest on some machines before discarding systems as broken. Some Minnowboards were failing memory tests. Intel looked into it and says:

We have tracked down the issue and found that memtest86 tool is using a function call with rare but legitimate NULL value which causes memory test failure.
Currently we are working to update BIOS firmware with fix to prevent this memory test function call failure from memtest86 tool.
Again this is protocol interface issue between memtest86 and our FW driver, there is no hardware issue found with memory on Minnowboard.

See elinux-minnowboard thread for details:

https://www.memtest86.com/troubleshooting.htm

https://www.memtest86.com/technical.htm

http://lists.elinux.org/pipermail/elinux-minnowboard/Week-of-Mon-20170828/thread.html

 

Oracle kills off SPARC/Solaris

https://www.theregister.co.uk/2017/08/31/oracle_stops_prolonging_inevitable_layoffs/

https://www.thelayoff.com/t/P23GpT5

https://www.thelayoff.com/t/P2twa2w

static analysis of Linux kernel

Colin has a new blog post about static source analysis of the Linux kernel:

Static analysis on the Linux kernel
There are a wealth of powerful static analysis tools available nowadays for analyzing C source code. These tools help to find bugs in code by just analyzing the source code without actually having to execute the code. Over that past year or so I have been running the following static analysis tools on linux-next every weekday to find kernel bugs: cppcheck, smatch, sparse, clang scan-build, CoverityScan, and The latest gcc. Typically each tool can take 10-25+ hours of compute time to analyze the kernel source; fortunately I have a large server at hand to do this. The automated analysis creates an Ubuntu server VM, installs the required static analysis tools, clones linux-next and then runs the analysis. The VMs are configured to minimize write activity to the host and run with 48 threads and plenty of memory to try to speed up the analysis process.[…]

http://smackerelofopinion.blogspot.com/2017/09/static-analysis-on-linux-kernel.html

 

SisyphOS: UEFI-based Rust kernel

sisyphos-kernel-uefi-x86_64: UEFI-based Rust kernel

A Rust kernel running on bare UEFI (no separate bootloader). Very early stage. Basically, the eventual goal is to build a non-opinionated microkernel that can load regular ELF64 programs as kernel “modules”. Actually, just fairly conventional processes, except running in kernel space (they are assumed to be written in Rust and reproducible, so that hardware protections are unnecessary, similar but unrelated to Microsoft’s Singularity project). The core micro/nano/whateverkernel will link up the loaded applications with a builtin dynamically linked library that exposes its functionality, moving the responsibility for higher-level problems (such as syscalls) into these loadable binaries, and also allowing simple emulation without virtualization for debugging purposes.[…]

https://github.com/le-jzr/sisyphos-kernel-uefi-x86_64
https://github.com/le-jzr/sisyphos-kernel-uefi-x86_64/wiki/Random-notes

 

Attify’s Firmware Analysis Toolkit and AttifyOS VM

Attify has a Firmware Analysis Toolkit (FAT). Apparently they include a pre-built version of it in their AttifyOS VM, and use it in their IoT training:

Firmware Analysis Toolkit: FAT is a toolkit built in order to help security researchers analyze and identify vulnerabilities in IoT and embedded device firmware. This is built in order to use for the “Offensive IoT Exploitation” training conducted by Attify. As of now, it is simply a script to automate Firmadyne which is a tool used for firmware emulation. In case of any issues with the actual emulation, please post your issues in the firmadyne issues.

Attify OS – Distro for pentesting IoT devices: Instead of spending time installing, configuring and setting up various tools required for IoT pentesting, here is a pre-made distro for you containing the tools that would come handy during any Internet of Things Security Assessment or Penetration testing.

From training site:
Firmware analysis: IoT devices and embedded systems run on firmware, which often hold a lot of secrets and sensitive information. This module will help you analyze and extract firmware, thus helping you identify vulnerabilities in the firmware for IoT devices. We will also look at firmware emulation using FAT, a custom tool built by Attify with which you can emulate firmware and perform all sorts of ā€œnon-hardwareā€ based attacks. The tool is fully scriptable and hence can be modified and used according to your preference. You also get access to the API, which will allow you to use the tool for your own further research.

https://github.com/attify/firmware-analysis-toolkit
http://tinyurl.com/attifyos
https://www.attify.com/
Offensive IoT Exploitation
https://github.com/adi0x90/attifyos (unsure if this official or not)

 

Microsoft Surface seeks UEFI engineer

Senior Embedded Software Firmware Engineer- Surface

The Surface development team is seeking a talented software development engineer with a strong systems background and experience with hardware and firmware interaction. Job responsibilities will encompass designing and coding drivers, tools and firmware across various technologies in Surface devices within the Surface team as well as with partners to deliver high quality products to market.

A few of the Qualifications:

“High tolerance to ambiguity and ability make progress in the face of it.”

“Ability to quickly ramp-up on complex and unfamiliar code.”

https://careers.microsoft.com/jobdetails.aspx?jid=283564&job_id=1044422

PS: I recently briefly used a Surface Book, USB stopped working after 2 days of use, the only way to get it to work again was to disable UEFI Secure Boot and TPM support. I was expecting a lot more from the modern Microsoft w/r/t hardware QA. I hope the Microsoft OEM unit is also hiring STEs…

CHIPSEC adds RWEverything support on Windows

https://github.com/chipsec/chipsec/commit/60504da1bc06288ea632378f17e60a0d7df99471

“Use RWE/windows helpers when the corresponding driver is present.”

So, for any defending Windows systems, all of the CHIPSEC caution in WARNING.txt against the CHIPSEC HAL driver should also be applied to the RWEverything driver, “C:\Windows\System32\drivers\RwDrv.sys”.

https://github.com/chipsec/chipsec/blob/master/drivers/win7/readme

RWEverything license excerpt:

This utility comes with ABSOLUTELY NO WARRANTY, it allows you to modify hardware settings, this may damage your system if something goes wrong. Author will not take any responsibility about that, you are on your own risk. This utility should not be used in commercial or consumer products.

Home

coreboot and Intel ME

https://www.coreboot.org/

CVE-2017-3753: AMI Lenovo UEFI SMM vulnerability

Lenovo says scope of AMI issue is “Industry-Wide”, which implies that other Intel/AMI-based OEMs may also have this issue, not just Lenovo.

BIOS SMI Handler Input Validation Failures
CVE Identifier: CVE-2017-3753

Lenovo Security Advisory: LEN-14695
Severity: High
Scope of Impact: Industry-Wide
Last Modified: 08/09/2017

Potential Impact: Execution of code in SMM by an attacker with local administrative access

A vulnerability has been identified in some Lenovo products that use UEFI code developed by AMI. With this vulnerability, conditions exist where an attacker with administrative privileges or physical access to a system may be able to run specially crafted code that can allow them to bypass system protections such as Device Guard and Hyper-V. AMI has supplied a fix for this vulnerability to Lenovo. Users should update the BIOS on affected systems to the latest available version to address this issue.

Security-conscious users should consider the following mitigation steps if an immediate BIOS update is not possible to protect themselves to the fullest extent with the understanding that they DO NOT fix or fully protect against an exploit of this vulnerability:

* Enable Secure Boot on your system
* Disable the boot to UEFI shell
* Disable boot from any source but the primary internal hard drive
* Set a BIOS setup password, so Secure Boot cannot be disabled and the boot to the UEFI shell cannot be re-enabled
* Operate as an unprivileged (non-administrator)

https://nvd.nist.gov/vuln/detail/CVE-2017-3753
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-3753
https://support.lenovo.com/us/en/product_security/len-14695
AFAICT nothing on the AMI site on this.

FirmUSB: Vetting USB Device Firmware using Domain Informed Symbolic Execution

FirmUSB: Vetting USB Device Firmware using Domain Informed Symbolic Execution
Grant Hernandez, Farhaan Fowze, Dave (Jing) Tian, Tuba Yavuz, Kevin R. B. Butler
(Submitted on 30 Aug 2017)

The USB protocol has become ubiquitous, supporting devices from high-powered computing devices to small embedded devices and control systems. USB’s greatest feature, its openness and expandability, is also its weakness, and attacks such as BadUSB exploit the unconstrained functionality afforded to these devices as a vector for compromise. Fundamentally, it is virtually impossible to know whether a USB device is benign or malicious. This work introduces FirmUSB, a USB-specific firmware analysis framework that uses domain knowledge of the USB protocol to examine firmware images and determine the activity that they can produce. Embedded USB devices use microcontrollers that have not been well studied by the binary analysis community, and our work demonstrates how lifters into popular intermediate representations for analysis can be built, as well as the challenges of doing so. We develop targeting algorithms and use domain knowledge to speed up these processes by a factor of 7 compared to unconstrained fully symbolic execution. We also successfully find malicious activity in embedded 8051 firmwares without the use of source code. Finally, we provide insights into the challenges of symbolic analysis on embedded architectures and provide guidance on improving tools to better handle this important class of devices.

https://arxiv.org/abs/1708.09114