Intel ATR releases UEFI firmware training materials!

Good news: the Intel Advanced Threat Research (ATR) team has release some of their UEFI security training materials!

This repository contains materials for a hands-on training ‘Security of BIOS/UEFI System Firmware from Attacker and Defender Perspectives’. A variety of attacks targeting system firmware have been discussed publicly, drawing attention to the pre-boot and firmware components of the platform such as BIOS and SMM, OS loaders and secure booting. This training will detail and organize objectives, attack vectors, vulnerabilities and exploits against various types of system firmware such as legacy BIOS, SMI handlers and UEFI based firmware, mitigations as well as tools and methods available to analyze security of such firmware components. It will also detail protections available in hardware and in firmware such as Secure Boot implemented by modern operating systems against bootkits. The training includes theoretical material describing a structured approach to system firmware security analysis and mitigations as well as many hands-on exercises to test system firmware for vulnerabilities. After the training you should have basic understanding of platform hardware components and various types of system firmware, security objectives and attacks against system firmware, mitigations available in hardware and firmware. You should be able to apply this knowledge in practice to identify vulnerabilities in BIOS and perform forensic analysis of the firmware.

0 Introduction to Firmware Security
1 BIOS and UEFI Firmware Fundamentals
2 Bootkits and UEFI Secure Boot
3 Hands-On Platform Hardware and Firmware
4 System Firmware Attack Vectors
5 Hands-On EFI Environment
6 Mitigations
7 System Firmware Forensics
N Miscellaneous Materials

https://github.com/advanced-threat-research/firmware-security-training

FWTS 17.05.00 released

Ivan Hu of Canonical announced the 17.05.00 release of FWTS.

New Features:
  * Support SMBIOS 3.1.1 tests
  * dmi: dmicheck: check new offset in spec 3.11
  * dmi: dmicheck: check reserved bits of Type 7 offset 0x5
  * dmi: dmicheck: check reserved bits of Type 7 offset 0xd
  * dmi: dmicheck: add a function to verify reserved bits
  * dmi: dmicheck: add a helper function to check word min/max value
  * dmi: dmicheck: check pci(e) slot and segment, bus and dev/func
  * dmi: dmicheck: check reserved bits of offset 0x5 in type 13
  * dmi: dmicheck: add a helper function to check a reserved offset
  * dmi: dmicheck: check reserved bits in type 15 & type 17
  * dmi: dmicheck: check reserved fields in type 22, 23, 30, 32, 38 and 39
  * dmi: dmicheck: add 64-bit integer to dmi_reserved_bits_check
  * dmi: dmicheck: add checks for new type 43
  * dmi: dmicheck: check reserved bits in Type 0
  * fwts/opal: Power management DT Validation tests.
  * fwts/opal: Reserved memory DT validation tests.
  * Add snapcraft rules to build a fwts snap

See the list of bugfixes in the full announcement.

http://fwts.ubuntu.com/release/fwts-V17.05.00.tar.gz
https://launchpad.net/~firmware-testing-team/+archive/ubuntu/ppa-fwts-stable
https://wiki.ubuntu.com/FirmwareTestSuite/ReleaseNotes/17.05.00
https://launchpad.net/ubuntu/+source/fwts

NEZHA fuzzer open-sourced

NEZHA is an evolutionary-based efficient and domain-independent differential testing framework developed at Columbia University. NEZHA exploits the behavioral asymmetries between multiple test programs to focus on inputs that are more likely to trigger semantic bugs. NEZHA features several runtime diversity-promoting metrics used to generate inputs for multi-app differential testing.[…]

https://github.com/nezha-dt/nezha

Click to access 390.pdf

initroot: Bypassing Nexus 6 Secure Boot through Kernel Command-line Injection

initroot: Bypassing Nexus 6 Secure Boot through Kernel Command-line Injection
By Roee Hay (@roeehay)
In the May 2017 Android Security Bulletin, Google released a patch to a critical and unique vulnerability CVE-2016-10277 in the Nexus 6 bootloader we had found and responsibly disclosed. By exploiting the vulnerability, a physical adversary or one with authorized-ADB/fastboot USB access to the (bootloader-locked) device (such as PC malware awaiting for an ADB-authorized developer’s device to be hooked via USB) could break the Secure/Verified Boot mechanism, allowing him to gain unrestricted root privileges, and completely own the user space (which may also lead much more), by loading a tampered or malicious initramfs image. Moreover, exploitation does not lead to a factory reset hence user data remains intact (and still encrypted). It should be noted that we do not demonstrate an untethered attack. During this research we also uncovered a 18-year-old Linux Kernel bug (not affecting Nexus 6 and probably does not affect any Android device): CVE-2017-1000363[…]

https://alephsecurity.com/2017/05/23/nexus6-initroot/

MASCAB: a Micro-Architectural Side-Channel Attack Bibliography

https://twitter.com/rspreitzer_/status/858310012317335552

MASCAB: a Micro-Architectural Side-Channel Attack Bibliography
Cryptography is a fast-moving field, which is enormously exciting but also quite challenging: resources such as the IACR eprint archive and CryptoBib help, but even keeping track of new results in certain sub-fields can be difficult, let alone then making useful contributions. The sub-field of micro-architectural side-channel attacks is an example of this, in part as the result of it bridging multiple disciplines (e.g., cryptography and computer architecture). I’ve found this particularly challenging (and so frustrating) over say the last 5 years; the volume of papers has expanded rapidly, but the time I’d normally allocate to reading them has been eroded by other commitments (as evidenced by a pile of printed papers gathering dust on my desk). In the end, I decided to tackle this problem by progressively a) collating papers I could read, then b) reading them one-by-one, but in no particular order, and attempting to summarise their contribution (and so organise the sub-field as a whole in my head). MASCAB is the result: after starting to advise MSc and PhD students on how to navigate the sub-field, it seems likely to be of use to others as well.[…]

https://github.com/danpage/mascab/

PCILeech 2.0 released

https://github.com/ufrisk/pcileech

 

lk-reducer: Linux Kernel reducer

[…]Enter the Linux Kernel reducer, or lk-reducer for short. This tool helps avoid some of the problems we have discussed thus far. It works by monitoring file system access while building the Linux kernel. (By no means is its utility limited to the Linux Kernel, but it is simply where we found a need.) This is possible because providing the Linux Kernel source code is a legal requirement under the Linux GNU Public License (LGPL). By monitoring the build process, we are able to determine which files from within the source tree have been used to build the final kernel image. Some files will inevitably not get used and thus we can determine that they are not needed. Therefore, they can be eliminated from review during a source code audit. This saves time during both manual and automated source code reviews. The current incarnation of the tool is a slight modification of an implementation by Jann Horn. The first incarnation consisted of using strace(1) and a bunch of shell scripts to monitor calls to the open(2) system call. Jann developed his version around the Linux inotify subsystem. His implementation is much more clean and performant. My only modifications were to let the user decide how to process the monitoring results based on a data file. The tool generates a file called “lk-reducer.out” that shows whether each file was Accessed, Untouched, or Generated. Let us see it in action![…]

http://www.droidsec.org/blogs/2017/05/22/a-simple-tool-for-linux-kernel-audits.html

ltmdm64_poc

https://twitter.com/vpikhur/status/866881935477399552

Windows 7 SP1 x64 Code Integrity Bypass POC using ltmdm64.sys
Bug was found in ltmdm64.sys!DriverEntry driver incorrectly uses RtlQueryRegistryValues API it also lacks security cookies across entire binary except GsDriverEntry function. This PoC was created back in 2014 and submitted later to MSRC they were not able to located the driver authors but also didn’t take any action on fixing the problem. ltmdm64.sys is shipped since Windows Vista and present in digitally signed catalog files. This PoC is detected by Windows Defender as Exploit:Win64/Ropero.A

https://github.com/int0/ltmdm64_poc

 

SSD drive vulnerabilities

SSD Drives Vulnerable to Attacks That Corrupt User Data
By Catalin Cimpanu
NAND flash memory chips, the building blocks of solid-state drives (SSDs), include what could be called “programming vulnerabilities” that can be exploited to alter stored data or shorten the SSD’s lifespan. During the past few years, SSDs have slowly replaced classic disk-based HDDs as […]

https://www.bleepingcomputer.com/news/hardware/ssd-drives-vulnerable-to-attacks-that-corrupt-user-data/

ATM machines and firmware security

An article from the ATM industry on BIOS:

ATM malware attacks: Head them off at the BIOS
May 19, 2017 | by Suzanne Cluckey

[…][Our concern] as a control company is making sure that the network vulnerabilities are sealed up … we continue to see attacks on the BIOS. Finding a toolset that allows you to change the password, change the settings and secure the BIOS of those machines is important to a lot of those customers.[…]

 

https://www.atmmarketplace.com/articles/atm-malware-attacks-head-them-off-at-the-bios/

IBM Monacle and PowerVM firmware updates

[…]Under the Hood of Power Firmware Maintenance

The Service Processor of the server is running an embedded operating system with complex power firmware applications running on it; one of which is an application responsible for handling code updates. […]

https://www.ibm.com/developerworks/community/wikis/home?lang=en_us#!/wiki/Power%20Systems/page/Monocle%20Patch%20Management

AWS CloudHSM firmware updates

[…]In this post, I demonstrate how to update your current CloudHSM devices and client instances so that you are using the most current versions of software and firmware. If you contact AWS Support for CloudHSM hardware and application issues, you will be required to update to these supported versions before proceeding. Also, any newly provisioned CloudHSM devices will use these supported software and firmware versions only, and AWS does not offer “downgrade” options.[…]

https://aws.amazon.com/blogs/security/how-to-update-aws-cloudhsm-devices-and-client-instances-to-the-software-and-firmware-versions-supported-by-aws/