Uncategorized

Team Security on UEFI malware

Team Security has an article on firmware malware, focusing on UEFI-centric malware, with many references to VirusTotal.com-based images.

[…]”We would like to specially thank Teddy Reed, developer of the UEFI firmware python parser, he has been instrumental in helping us overcome our ignorance about BIOS, UEFI, and its ecosystem.”

https://tsecurity.de/de/109335/IT-Security/Malware-Trojaner-Viren/Putting-the-spotlight-on-firmware-malware/

Standard
Uncategorized

Teddy Reed’s intro to ARM-TF, OP-TEE, and ARM UEFI

“This is a walkthrough for flashing custom ARM Trusted Firmware, OP-TEE, and the ARM UEFI Platform code on the Hikey board. Custom means code we’ve built it on our development machine, we’re not making any changes to these reference implementations just yet.[…]

https://prosauce.org/blog/2016/11/25/hands-on-introduction-to-arm-firmware-using-the-hikey

Standard
Uncategorized

Teddy Reed on firmware attacks TONIGHT

Short notice, but if you are reading this immediately and are in Bay Area, then you might be able to attend. The rest of us will have to hope they videotape this and share the archive.

Defending, detecting, and responding to hardware and firmware attacks

This presentation takes a different approach to hardware and firmware security by exploring how our enterprise defenders can recognize vulnerable systems and potential compromise. Defense begins with visibility, that means baselining kernel drivers, kernels, boot loaders, ACPI table content, SMBIOS metadata; it then continues into logging real time OS API-generated hardware events. This data and pipeline can fuel existing correlation and IoC collections to identify known good and eventually known bad. Creating production deployable and repeatable recipes for these somewhat esoteric features is essential. We will present a summary of immediate tools and actions for “deep systems defense”, an analysis of where our defenders remain blind to compromise, and recommendations on where our industry can focus tailored effort to generate massive impact.

Teddy is a Security Engineer at Facebook developing production security tools. He is very passionate about trustworthy, safe, and secure code development. He loves open source and collaborative engineering when scale, resiliency, and performance enable defensive and protective software design.

https://www.eventbrite.com/e/fastly-security-speaker-series-part-2-tickets-25216388898

Standard
Uncategorized

U-Boot Verified Boot to get security improvements

Teddy Reed is proposing a change to U-Boot to support multiple levels of signing keys. Currently this is still at discussion phase, here’s Teddy’s initial post.

I’m looking to support “multiple levels” of keys within u-boot’s verified boot. I need something similar to UEFI’s key enrollment key (KEK) and db/dbx model such that I can support on-line signing of new kernels/rootfs/configurations. To make this work we need a KEK that is not online (kept in a safe), that can be used to sign expirations (revocations) of on-line signing keys in the case of compromise or private key reveals. I know Chrome’s Coreboot verified boot model supports this, wondering if there’s any staged / WIP for u-boot? Off the top of my head I’d imagine this requires extending the FIT to include sets of public keys and a blacklist of keys and expired or bad kernel/rootfs/etc hashes. Then either extending the boot code to inspect multiple FITs or extending mkimage to combine multiple sources to amalgamate a FIT containing the PK-signed set of keys + hashes and the on-line key-signed kernels/rootfs/configurations.

P.S. This may be strongly linked to the need for a TPM to prevent rollbacks. But as far as I can tell, the two features are distinct and a TPM is not completely required for a multi-level key approach to signing FITs.

Full post/thread:
http://lists.denx.de/mailman/listinfo/u-boot

Standard
Uncategorized

Facebook on defending against firmware threats (and osquery)

Ted Reed of Facebook — aka the Teddy Reed who creates UEFI Firmware Parser and related tools — posted a VERY GOOD article on how Facebook defends systems against hardware and firmware attacks, including coverage of Facebook’s osquery tool, and his recent Usenix Enigma presentation. Excerpt of introduction (with whitespace editing by me, sorry):

Hardware and Firmware Attacks: Defending, Detecting, and Responding

The attack landscape for firmware is maturing and needs more attention from defense and detection communities. Recent examples of firmware attacks include the Equation Group’s attacks on drive firmware, Hacking Team’s commercialized EFI RAT, Flame, and Duqu. Simple tools like osquery give defenders important insights about what’s happening on their network so they can quickly detect a potential compromise. Facebook released osquery as an open source project in 2014. Facebook recently added hardware monitoring to osquery, which already aids security teams in vulnerability management, incident response, OS X attacks, and IT compliance. Firmware on commodity laptops and servers is interesting to me as a security engineer for several reasons. This code often bootstraps trust protocols and protective architecture primitives. At the same time, it is a target for vulnerabilities aimed at bypassing those exact controls to unlock, jailbreak, and homebrew — for either good or malicious purposes. Firmware is also a vector for virtualization escapes, hypervisor attacks, and extreme persistence. That risk is magnified by the same fragmentation problem plaguing Android devices, but with an even more complex ecosystem of developers and supported devices. Recent examples of firmware attacks include the Equation Group’s attacks on drive firmware, Hacking Team’s commercialized EFI RAT, Flame, and Duqu. Trammell Hudson’s Thunderstrike-style local system takeover is fast and effective. Drew Suarez’s demonstrations of firmware flashing of Android devices take four seconds of a distracted local user’s attention. Additionally, Computrace has used a UEFI DXE driver capable of injecting a RAT onto unencrypted NTFS partitions for several years. All of this makes firmware security critical for protecting your enterprise. This week, I shared recent work on firmware security at the Enigma 2016 Conference, hosted by USENIX. Since releasing osquery to open source in 2014, I’ve been using it to explore new ways to recognize vulnerable systems and potential compromise. Defensive security professionals should begin scoping firmware components and use simple tools like osquery to gather insight and signal from their corporate network. […]

Full post:
https://code.facebook.com/posts/182707188759117

I’ve not used Facebook’s osquery before, so I have a lot of catching up to do. ;-(
https://github.com/facebook/osquery
https://osquery.io/
https://code.facebook.com/projects/658950180885092/osquery/
https://code.facebook.com/posts/844436395567983/introducing-osquery/
https://osquery-slack.herokuapp.com/

Standard