UEFI Notes: CS2AI, UEFI Plugfest and the Zimmer Anniversary Post

After some gentle ribbing from colleagues at the UEFI plug-fest in Bellevue, WA, I've decided to try to keep track of recent trends in UEFI here again.

My collaborator on the UEFI shell book, Vincent Zimmer has posted some thoughts on open source and open platforms in his anniversary blog post here. He has a long history within the UEFI community and is currently working to lower the barrier of entry to server firmware design. And for the record, it is U-E-F-I (not YOO-FI or micro-EFI) and A-C-P-I (not AK-PIE). On a side note about competing acronym pronunciations, in the early days of the EISA (Extended ISA) bus architecture, it was pointed out that while English speakers naturally pronounced EISA as EEE-SA and ISA as AY-SA, other European languages had would naturally pronounce it exactly opposite (EISA as AY-SA and ISA as EE-SA).

Meanwhile, on the firmware security front, some focused industry organizations are doing a great job of bring the reality of these issues to professionals and college students. For example, CS2AI (with more than 15 chapters worldwide) zeroes in on control systems and how they present unique challenges for security, as well as the recent impacts of the Meltdown and Spectre with excellent Q&A afterwards.

The UEFI plugfest in Seattle this past week brought a host of security related presentations. I presented on "UEFI and the Security Development Lifecycle". Many of the same process disciplines are becoming a requirement in the BIOS world because of the attention BIOS security is now getting from hackers, academics and professionals. This is also raising interesting business issues for a low-margin industry that has traditionally assumed its obscurity made it a low-priority target.

Intel's CHIPSEC team had a great presentation on how their threat models have now expanded to include attackers who have physical access to the hardware. There was a lot of other good stuff, which I'll talk about when the presentations become publicly available.

So What Does Security In IoT With UEFI Really Look Like?

As usual, security continues to dominate the news about UEFI. DEFCON had several presentations related to firmware security. There is a good overview of the hardware and firmware attacks discussed over at Dark Reading. This included one by my friend Vincent Zimmer and his colleagues at Intel analyzing over 90 reported firmware vulnerabilities over the past 3 years. He discusses his experience on his blog. Another, by security researcher Alex Matrosov described exploits and called out specific computer models. Then there was some stuff on using CHIPSEC to detect improperly configured chipsets.

As often as I deal with security issues in firmware, I am still ignorant of how the types of exploits that are available and the tools that are used by cyber-security professionals. There are always new kits coming out, with new features. But where do you get them and how do you use them safely without making you and your computer system a target-rich environment? Recently the CS2AI of Sacramento hosted two lectures. The first lecture focused on giving the nuts and bolts (step-by-step) of setting up your own environment, including virtual machines, TOR and Kali and even configuring a cheap Raspberry Pi as an analysis tool. The second lecture focused on the tools available under Kali, such as password hash crackers (with an up-close hack that used it), Sparta and Wireshark for network analysis and then an introduction to using Tor to venture onto the dark net with Tor. Why the dark net? So that you can see how much it costs to buy a hack of your company or a company that you care about!

Next month will be wireless attacks and the tools that sniff out vulnerabilities. Good stuff.

Security today has a lifespan-in hours, or maybe in months or years. My firmware job is to keep your system secure for the duration of one boot.

UEFI Security In The News: Craigslist, Zimmer & Cyber-Security Meet Ups

Using a UEFI-based BIOS on a MacBook Pro/Air and forgot your password and live in New York, New Jersey or Connecticut? Craigslist to the rescue! From the ad:

REMOVAL PROCESS: the password removal process will NOT damage your Macbook or VOID your Apple warranty in any way we do not modify any hardware nor do we use any software to remove the password a professional external password analyser will be used to remove the EFI Firmware BIOS Password and/or the iCloud System Lock PIN Code the repair turnaround will take 1 HOUR

Not sure how this works and I don't have a Mac, but some people have done extensive reverse engineering to look at it and found it pretty solid. Barring access to a hardware flash programmer "...there is no way for an outsider to generate the codes to reset your Mac firmware. So please stop sending me emails and comments asking for it."

Meanwhile, everyone seems to be trying to hack the firmware, even to the point where firmware guys are starting to worry about how solid the firmware written by other guys really is. My friend and co-author Vincent Zimmer gives a pretty good round up of the current findings and presentations, including some of his own.

Meanwhile, the local chapter of CS2AI is sponsoring a series of security meetings that gathers local industry practitioners and educators together to discuss different topics surrounding IT and control-system security. Last time the focus was on "The Mind of a Cyber Attacker" The next topic will be Defensive Tools for Cyber-Security, hosted by Prof. Jun Dai at Sacramento State University. Recent sessions have been hosted by speakers from McAfee, Palo Alto Networks and Grimm. Good stuff, practical from the physical, hardware, software and network attacks.

Some OEMs are more paranoid than others. In the firmware world, that keeps us on our toes to engineer creative solutions that make systems buildable, shippable and usable but not vulnerable.