Today Ricardo Neri of the Intel LUV team announced the release of LUV 2.0-RC2 release.
It updates the bits to fresher ones: Yocto Fido, Linux kernel 4.1, FTWS 15.7.0, BITS 1219, and CHIPSEC 1.2.1, as well as improvements in the HTML output of LUV’s test manager. IMO, fresh test suites are reason enough for updates, beyond additional changes, especially CHIPSEC 1.2.1 update…
PS: There was no checksum in the announce email, nor any on the web site which I could find. It would be nice to include that kind of information in future releases.
Beyond this UEFI malware, Vlad’s analysis of the Wikileaks email revealed at least 2 other firmware exploits that Hacker Team appeared to have been using:
08/19/13, ASUS BIOS device driver LPE, Firefox RCE added
See Vlad’s blog for pointers to other Wikileaks.org-based email articles on these two entries.
I wish there was a list of former 0-days, at least the firmware subset… I also wish there was a safe place to download the “Uefi_windows_persistent.zip” and “Z5WE1X64.fd” files listed in the Intel ATR blog.
BIO Unpack is a small Python tool written by By Anton Kochkov (XVilka) in late 2013. The tool unpacks *.BIO and *.CAP EFI capsule files.
Usage: bio_unpack.py bios.rom [start offset]
Hmm, WordPress doesn’t let me use an HTTPS-prefixed URL for gist.github.com-based URLs, it omits the URL entirely. I had to remove the https prefix to make the below line appear on WordPress:
gist.github.com/XVilka/8163272
PS: I didn’t know about Github’s gist snippets service until today; thanks to DC206’s Osman for the indirect pointer! 🙂
“Apple does not follow Intel’s recommended best practices for protecting their firmware. Consequently Macs are vulnerable to being disabled in such a way that they can never be made bootable again either by attempting to boot off external media (like a DVD/USB) and reinstalling the OS, or by changing the entire HD/SSD with a known working one. The only way to recover from such attacks is to reflash the SPI flash chip with a known-clean copy of the firmware. This attack does not require physical presence. It can be launched via a remote connection to the system (e.g. SSH/VNC).”
LegbaCore has some upcoming training at HackInTheBox Singapore in October, and it appears this 3-day training will cover some of this new Apple EFI research:
TODO: AMD, ARM, other chip makers, OEMs, IHVs, IBVs, other UEFI Forum members…
TODO: Learn WordPress, store link resources on page not as blog entries.
Yesterday, Intel Advanced Threat Research (ATR) released presentations of two recent talks they’ve given on BIOS/SMM/UEFI security.
1) Attacking and Defending BIOS in 2015 Advanced Threat Research, Intel Security RECon 2015
In this presentation we will demonstrate multiple types of recently discovered BIOS vulnerabilities. We will detail how hardware configuration is restored upon resume from sleep and how BIOS can be attacked when waking up from sleep using “S3 resume boot script” vulnerabilities. Similarly, we will discuss the impact of insufficient protection of persistent configuration data in non-volatile storage and more. We’ll also describe how to extract contents of SMRAM using above vulnerabilities and advanced methods such as Graphics aperture DMA to further perform analysis of the SMM code that would otherwise be protected. Additionally, we will detail “SMI input pointer” and other new types of vulnerabilities specific to SMI handlers. Finally, we will describe how each class of issues is mitigated as a whole and introduce new modules to CHIPSEC framework to test systems for these types of issues
2) A New Class of Vulnerabilities in SMI Handlers Advanced Threat Research, Intel Security CanSecWest 2015
This presentation will discuss security of SMI handler components of system firmware including the nature of a new class of vulnerabilities within the SMI handlers of BIOS/UEFI based firmware on various systems. It will also discuss how systems can be tested for these vulnerabilities and what can be done in firmware implementations to mitigate them. Additionally, the presentation will also discuss how S3 resume affects security of the system and problems with S3 resume boot script in some BIOS implementations recently discovered and presented at 31C3.
In this presentation we will demonstrate multiple types of recently discovered BIOS vulnerabilities. We will detail how hardware configuration is restored upon resume from sleep and how BIOS can be attacked when waking up from sleep using “S3 resume boot script” vulnerabilities. Similarly, we will discuss the impact of insufficient protection of persistent configuration data in non-volatile storage and more. We’ll also describe how to extract contents of SMRAM using above vulnerabilities and advanced methods such as Graphics aperture DMA to further perform analysis of the SMM code that would otherwise be protected. Additionally, we will detail “SMI input pointer” and other new types of vulnerabilities specific to SMI handlers. Finally, we will describe how each class of issues is mitigated as a whole and introduce new modules to CHIPSEC framework to test systems for these types of issues.
Speakers: Yuriy Bulygin, Mikhail Gorobets, Andrew Furtak, Oleksandr Bazhaniuk, Alexander Matrosov, Mickey Shkatov
Check out this Twitter post for an URL to the newly-available presentation:
Attacking & Defending BIOS in 2015 @reconmtl presentation discusses attacks on S3 boot script, UEFI vars, SMI.. http://t.co/i6BZv2ueZW [pdf]
Below is a better list. It is still not comprehensive, but a bit better than previous list.
[ Many of you probably already know about this, but I’m a Twitter newbie. I don’t have a Twitter account. I only just starting “using” Twitter, in “digest mode”: I look at these web pages once/day, or each time I’m trying to figure out the latest news in firmware. But I don’t use it interactively, and look at the links as they change, that’s too much data and requires too many interruptions… 🙂 ]
I don’t yet have any good Twitter feeds for AMD or ARM that cover firmware and/or security yet, perhaps in a v0.3 revision of this list, sorry. For other chips, here’s a few:
I need to add feeds for AMD, ARM, and other chip makers, and the list of existing BIOS/UEFI security researchers, and start to work on a list of OEMs/IHVs/IBVs/ISVs. I’ll try to get a 0.3 update in a month or two. I have yet to find a Twitter to NNTP gateway…
Once of these days, I’ll learn how to use WordPress and Php, and WordPress plugins and customizations, and add some web resource links, like blogrolls and Twitter feeds, and vendor press/event/news page links, and archives. Sorry the blog has such a sucky UI, this is the default WordPress.com theme (I’d expected a bit more).
Intel has released a new minor release of CHIPSEC, version 1.2.1. Some of the CHIPSEC team had just been giving pre-conference training at Recon the other week, and apparently this release fixes some bugs found during that training. There’s no additional information in the readme, the text from this Twitter post is the main information we have:
More information:
Check out CHIPSEC 1.2.1 on github with fixes for bugs found at #reconmtl training
One change of plans for the lab: I’ve been having problems getting LUV-live to boot on various machines, so don’t want to tie the lab to booting thumbdrives to use CHIPSEC.
So let’s use CHIPSEC installed natively on your laptop. So please bring a Intel UEFI-based laptop running Windows or Linux, where you can install CHIPSEC on it. (The CHIPSEC kernel driver is not a safe thing to keep loaded, see their warning.txt. Only load it when you are using CHIPSEC.) I’ll bring some scripts to make it easier to use CHIPSEC on Linux systems. Watch the Youtube video of DEFCON22 talk on CHIPSEC to see when/why to use some of it’s commands.
Or, instead of running CHIPSEC from w/i your installed OS, make your own LUV-live thumbdrive and see if it works on your system: if so, use CHIPSEC there.
Regardless, please don’t use your primary laptop, backup anything important, in case you brick the box.
The lab will be fairly free-form, people trying to use CHIPSEC on their system, hopefully to save a ROM and share with others, and to some analysis of the ROM using CHIPSEC, UEFITool, UEFI Firmware Parser. If you are willing to share some ROMs with the rest of the lab attendees, please try to bring a system with a CD-R/DVD-R burner. I’ll bring some blank discs. CHIPSEC and most of the below tools are Python-based, so install CPython 2.7x on your system. Install any of the below tools if you want to use these to examine ROMs:
Most of these tools are Python-based, but UEFITool is a C++-based Qt GUI app. You need to get Qt Creator installed, open Qt Creator, open the UEFI Tools’s .pro file, then Build it. UEFITool builds on most platforms pretty painlessly. If you don’t want to install Qt on your system, you can download pre-built binaries of UEFITool for Windows and Mac OSX. For Linux, no binaries provided, you must build from source. http://www.qt.io/download-open-source/ https://github.com/LongSoft/UEFITool/releases
One potential direction for the lab is to look at Intel’s analysis of the Hacking Team’s UEFI malware, and how to use CHIPSEC and UEFITool, using the GUIDs and strings from the below analysis to see if you have Hacking Team bootkit. http://www.intelsecurity.com/advanced-threat-research/blog.html
Unfortunately, it looks like the PNWFHW (Pacific NorthWest FirmWare Hackers) stickers likely won’t arrive in time, probably next week, so no stickers this time, sorry.
UEFI Spider is a tool that crawls/downloads UEFI/BIOS updates from multiple ISV/OEM distributors. It contains a set of highly specific scripts containing spidering logic for ISV/OEMs providing downloadable UEFI firmware updates. Each spider will attempt to document (in JSON) and download every identified UEFI firmware update. The tool is written in Python, and needs the Python scrapy library to work. It has support for these vendors: ASRock, Dell, Gigabyte, Intel, Lenovo, HP, MSI, and VMware.
“WARNING: Using this tool is dangerous, upon running each spider you will have downloaded well over 50G of firmware updates. This is highly taxing on both your bandwidth and the services hosting the updates. Please read the EULA for each site before spidering. This code is provided for reference only; this project and its authors do not encourage using the spiders.”
The tool is written by Teddy Reed (“theopolis”), who also created the UEFI Firmware Parser.
I’m lazy, I wish one person would keep an online respository of ALL known BIOS/UEFI ROMs, so each security researcher wouldn’t have to crawl each vendors’ site on an ongoing basis.
As reported by Phoronix today, LibreTrend has partnered with Ubuntu Mate, to ship systems with Ubuntu Mate pre-installed. LibreTrend is a relatively new Linux OEM, they apparently launched last year in Portugal. LibreTrend joins the ranks of ThinkPenguin, System76, Purism, Novena, and a few others, OEMs that selling Linux-based systems. Quoting the press release with Ubuntu Mate:
LibreTrend are the designer and manufacturer of the LibreBox, a computer geared towards providing a complete “out of the box” Linux experience, with a heavy focus on hardware compatibility. All the hardware in the LibreBox is Free Software friendly and %100 supported by “blobless” Linux drivers.
The hardware behind this first LibreBox is based on the Intel 1037U Dual Core CPU. I’m not sure what firmware the LibreBox uses. I presume stock BIOS, not coreboot or UEFI.
Again, I don’t know what LibreTrend is doing with their firmware. Most Linux OEMs are merely taking commodity hardware made for Windows PCs, with stock BIOS, many blobs, fairly insecure compared to UEFI. (Novena is an exception, they’ve crowdsourced new Open Hardware development, and don’t use BIOS. Purism may also be exceptional, but I’ve yet to see specifics of what firmware they’re using.) Most other Linux OEMs are not exceptional w/r/t firmware, and could be be improved by using Intel FSP and coreboot, something that Sage Engineering, an open source BIOS vendor, does. That’d be more Open Source firmware (mostly Free Software-based) and fewer blobs than the default BIOS, which their Linux user audience would presumably prefer. Or they could ship a UEFI and get the additional security that Secure Boot brings to the OS; to help with their Linux user audience further, they could remove the Microsoft certs, something they could do as an OEM, or if they worked with their BIOS vendor. Intel and SuSE showed how to have a Microsoft key-free Linux system back at IDF 2013, yet AFAIK no OEM is selling hardware like this to the Linux community. Most Linux OEMs need to improve the firmware of their products.
I’m happy to see LibreTrend selling hardware with Free Software pre-installed, focusing on blobs at the Linux driver level. I hope they start building Open Hardware and use something beyond COTS BIOS, in future models, and also focus on blobs at the firmware level.
Today, WinZent, a Swedish-based BIOS vendor, released wION BIOS and wIOS operating system for the MinnowBoard MAX. The release is registration-required freeware.
Some excerpts from their press release:
“WinZent Technologies AB today announced the general availability of its wION BIOS and wIOS operating system for the MinnowBoard Max open hardware board. WinZent’s software allows the embedded systems developer to use any operating system, from legacy operating systems such as MS-DOS, to most Linux distributions and the latest Microsoft Windows versions. The software also boosts the board with lightening-fast performance. WinZent’s wION BIOS cold boots the MinnowBoard Max in 0.56 seconds, and completes a warm reboot in 0.21 seconds. wION is bundled with WinZent’s real-time POSIX compliant operating system wIOS, which can provide multiples to magnitudes improved performance for applications and programs.”
“WinZent Technologies AB develops and markets the world’s fastest and most compact firmware and kernel software. wION, our BIOS, is characterized by sub-second boot time and full support for both legacy and the latest operating systems. wIOS, our POSIX-compliant operating system, is characterized by its deterministic real-time capabilities and its lightening-fast speed. WinZent Technologies AB is headquartered in Stockholm in Sweden.”
In addition to this Flash-based training, Intel SSG also has a 3-day class for Intel employees, which they upload the labs and presentation materials to the public. They maintain this courseware, new versions of the presentations/labs are occasionally updated. If you are a Windows/Visual Studio user, you’ll be right at home with the labs. If you are a Linux user, there is a small amount of content focused on Linux, otherwise you’ll have to ignore all the screenshots of Visual Studio users clicking and right clicking. In the future, I wish Intel SSG would add audio/video layers, in addition to presentation and labs. Download Lab-Material-FW.zip and the most recent Presentations<YYMMDD>.zip from:
Here’re two resources that you should be tracking, if you care about firmware security. In addition to OEM-specific sites, these are very useful to track updates in UEFI- and Intel-based systems:
The Tianocore Security site has UEFI security vulnerability information impacting most UEFI-based vendors, including non-Intel vendors like ARM. The data is released as PDFs, and announced on their list. Tianocore doesn’t use NIST SCAP CVEs, look for these PDFs instead.
The Intel Security Center site has BIOS/UEFI security vulnerability information impacting Intel-based systems. The data is released as web pages, and announced on their list.
Someone from your IT department should probably be subscribed to these mailing lists, and watch these lists and content for updates that may impact their systems.
Yesterday LegbaCore updated their website to include some more research:
“Added the How Many Million BIOSes Would you Like to Infect whitepaper to our Research page. This document contains more discussion than was provided in the conference talks of what could be done by live OSes like Tails or LPS to be more secure against firmware threats.”
Firmware Security 
You must be logged in to post a comment.