tool: ReadPhysMem

Found on the Twitter feed of the The EFI Monster (@osxreverser):
https://twitter.com/osxreverser/status/639452846090551296

ReadPhysMem is a small utility to read and write to Macs physical memory using default AppleHWAccess.kext. Quoting the readme:

(c) fG! – 2015 – reverser@put.ashttps://reverse.put.asA small utility to read and write to Macs physical memory using default AppleHWAccess.kext.

This kext is loaded by default on Mavericks and Yosemite. It has (finally) been disabled on El Capitan since beta 7 release, since it was a obvious way to bypass and disable the new rootless protection 😉

Trammell Hudson wrote a similar utility using DirectHW.kext (also blacklisted on El Capitan B7). Available at https://github.com/osresearch/rwmem.

The same warning as rwmem applies here. Use with caution, it can easily kernel panic your machine both on reads and writes (particularly on devices mapped areas, SMM ram, etc). If you already know PCI BAR addresses you need to use 4 bytes read size instead of default 8.

It works great to read kernel and other memory, and also BIOS (since it’s mapped/shadowed in physical memory). See also https://github.com/gdbinit/diagnostic_service2 for a real world rootkit application.

DirectHW.kext is a bit more powerful since it allows to read port info. AppleHWAccess.kext only implements memory reads and not ports. For example, it can’t be used to read PCI configuration.

Have fun,

fG!

https://github.com/gdbinit/readphysmem

OS X Yosemite Security Guide

As found on the Twitter feed of David Barroso (‏@lostinsecurity):

DrDuh has a new Github project which is a Mac OSX Yosemite security/privacy guide. There is a brief section on firmware, using Apple’s new Firmware Password feature.

OS X Yosemite Security and Privacy Guide
https://github.com/drduh/OS-X-Yosemite-Security-and-Privacy-Guide

new resource: Broken UEFI Implementations wiki

Watch this site to grow over time (and contribute to it, if you can help):
http://wiki.osdev.org/Broken_UEFI_implementations
http://wiki.osdev.org/index.php?title=Broken_UEFI_implementations&action=history

Apple, Lenovo, GIGABYTE: note that there’s some stuff about your products in the initial database.

As mentioned earlier:

Debian calls for UEFI packaging help

Intel update on Debian and UEFI

Steve McIntyre of the Debian project is working with other open source OS developers to maintain a list of broken UEFI implementations, to help OS vendors:

I’ve been talking to a number of other UEFI developers lately, and we’ve agreed to start a cross-distro resource to help here – a list of known-broken UEFI implementations so that we can share our experiences. The place for this in in the OSDev wiki at http://wiki.osdev.org/Broken_UEFI_implementations. We’re going to be adding new information here as we find it. If you’ve got a particular UEFI horror story on your own broken system, then please either add details there or let me know and I’ll try to do it for you.

See Steve’s blog post for more information:
http://blog.einval.com/2015/08/02

 

Interview with LegbaCore (and: their OpROM checker ships!)

A while ago, I emailed Corey and Xeno of LegbaCore, and sent them a few questions for an ‘interview’ for this blog. Well, here’s the results (also see EOM for URLs):

Q: This October in Singapore you’re giving 3-days of training at HITB. Besides new Apple EFI skills, can you give us some other new things that’ll be in this training?
A: The course introduces the basics of evaluating firmware and SMM on modern platforms for security vulnerabilities, as well as for potential compromises. Specifically we work through methodologies for identifying whether or not your system contains publically known vulnerabilities (which a great majority of them do). We also introduce a firmware forensic and reverse engineering methodology for identifying potential firmware compromises… so say if you got comprised by something like the hacking team UEFI rootkit, we’d talk about the tools and procedures that would be useful for identifying and analyzing this threat both on one particular system and at scale across your enterprise.
    The most important point of the training is it will be focused on real hardware that is deployed in real environments. A large portion of the course will involve evaluating the hardware that students bring with them. This way if you’re in charge of malware detection/response in an enterprise, you’ll walk away with actionable information related to the hardware you are deploying on your network.

Q: You had a Twitter post a few weeks (months?) back, saying that you were going to start releasing information about OEM systems’s vulnerabilities. What’s up with that project, I’m eager to see this data, as Consumer Reports and other computer review sources are useless for this most crucial pre-sales information. Any chance you could give FirmwareSecurity.com a teaser of this information, perhaps one new OEM model released in the last 6 months that’s insecure? 🙂
A: We anticipate that the project to start making some vendors’ firmware security failings more apparent (via a public website) will probably kick off in early 2016. We want to give all vendors that we think may have an interest in improving their security a chance to either talk with us about working with them, or show that they can make measurable security improvements on their own within this timeframe.

Q: You had a Twitter post a few days ago, pointing to a new LegbaCore Github repository for a new Option ROM checking tool. This sounds very interesting! What kinds of Option ROM(s) will it support? What platform(s) will it run on? When can we expect initial release?
A: It will only integrity check the Apple Thunderbolt to Ethernet adapter’s option ROM. It will work in conjunction with a port of the linux tg3 kernel driver to run on Macs to dump the OROM. The “ethtool” command can also be run to dump the OROM on linux systems that have a thunderbolt port and the tg3 driver available. The tool will be released to coincide with the talk at BlackHat, August 6th.

Q: Beyond this new Option ROM checker, does LegbaCore have any additional tool plans in the works? If so, any details to reveal?
A: Our current thinking on tools is that we expect that we will make clean-slate “best effort” tools freely available at some point in the future. These tools would be like all typical security tools, being not particularly trustworthy, and thus vulnerable to attacker subversion. They would mostly be useful for catching attackers as they first enter into the domain, and are not particularly sophisticated. However we will only make those tools available once we have commercial-grade tools available, that have a trust argument for why these paid tools have the ability to stand up to sophisticated and well-resourced adversaries. And in the background we will work with vendors to add capabilities such as SMM Dual Monitor mode, which significantly strengthen the trust arguments

Q: The Copernicus release is mostly Windows-centric, but also includes a cross-platform, bios_diff.py tool in the release. Will the new LegbaCore github tree include a open source bios_diff project, perhaps to get open source patches for improved BIOS parsing beyond EFIPWN, perhaps like that in UEFITool?
A: While bios_diff.py continues to provide the only simple, semantically aware integrity checking capability for BIOS, it has a number of issues. E.g. in the context of our latest work, it simply doesn’t work to integrity check Apple firmware, because Apple firmware update structure does not look the same as the structure on-disk.

Q: Post-October/HITB, what’s the next LegbaCore BIOS/UEFI security training event you’ll be giving?
A: Later in October I’ll be offering a similar training at Ruxcon breakpoint. Beyond that we are fairly busy with private training engagements.

Q: Any hints what kind of new firmware vulnerability research you’re working on, and when we might see some of the results?
A: We are branching out to the security of peripheral devices such as network cards, HDs/SSDs, embedded controllers, GPUs, the Intel Management Engine, etc. We are shooting to have our first talk on one of these topics around December.

Q: Recently Stephan of coreboot mentioned that in the past MITRE said that Chrome OS firmware was more secure than UEFI. Both coreboot+depthcharge’s Verified Boot and UEFI’s Secure Boot both seem pretty similar, in terms of PKI usage. Have you an opinion on the security strength of either of these firmware solutions?
A: We have never evaluated CoreBoot to any level of depth. Hardware-wise, we like the Chromebook requirement to provide physical write protection for the flash chip via a screw. The way that Chromebooks supposedly root their boot trust in the embedded controller hardware, as described to us, sounded like a good idea. But without having actually spent time looking at the platforms, we cannot say much in terms of the security (or lack thereof) relative to UEFI-based systems.

—-[End of interview.]

Thanks Corey and Xeno!
Links:

<blink>THEIR OPROM CHECKER IS RELEASED!</blink>
The code was added 5 days ago, and I missed it!
https://github.com/legbacore/t2e_integrity_check

Upcoming training:
http://gsec.hitb.org/sg2015/sessions/tech-training-6-introductory-bios-smm-attack-defense/
https://ruxconbreakpoint.com/training/bios/
http://www.legbacore.com/Training.html

Stephan’s comment on coreboot security:

quiz: define ‘firmworm’

The pre-conference preview videos are coming out… 🙂 One firmware one that caught my attention:

Thunderstrike 2 “firmworm” for MacBooks Preview Video

https://twitter.com/qrs/status/628346592668598272

US CERT BIOS Vulnerability Note VU#577140!

Today, US CERT released a Vulernability Notice for UEFI firmware:

Vulnerability Note VU#577140
BIOS implementations fail to properly set UEFI write protections after waking from sleep mode

Multiple BIOS implementations fail to properly set write protections after waking from sleep, leading to the possibility of an arbitrary BIOS image reflash.
Description

According to Cornwell, Butterworth, Kovah, and Kallenberg, who reported the issue affecting certain Dell client systems (CVE-2015-2890):

    There are a number of chipset mechanisms on Intel x86-based computers that provide protection of the BIOS from arbitrary reflash with attacker-controlled data. One of these is the BIOSLE and BIOSWE pair of bits found in the BIOS_CNTL register in the chipset. When the BIOSLE bit is set, the protection mechanism is enabled. The BIOS_CNTL is reset to its default value after a system reset. By default, the BIOSLE bit of the BIOS_CNTL register is cleared (disabled). The BIOS is responsible for re-enabling it after a reset. When a system goes to sleep and then wakes up, this is considered a reset from the hardware’s point of view.

    Therefore, the BIOS_CNTL register must be reconfigured after waking from sleep. In a normal boot, the BIOS_CNTL is properly configured. However, in some instances BIOS makers do not properly re-set BIOS_CNTL bits upon wakeup. Therefore, an attacker is free to reflash the BIOS with an arbitrary image simply by forcing the system to go to sleep and wakes again. This bypasses the enforcement of signed updates or any other vendor mechanisms for protecting the BIOS from an arbitary reflash.

A similar issue affecting Apple systems (CVE-2015-3692) involves the FLOCKDN bit remaining unset after waking from sleep. For more information, refer to Pedro Vilaça’s blog disclosure.

See URL for full Notice.

http://www.kb.cert.org/vuls/id/577140

DEF CON 23

In DEF CON is happening shortly, or maybe it’s cancelled, I’m not sure. 🙂 Two talks immediately jump out:

ThunderStrike 2: Sith Strike

Trammel Hudson Vice President, Two Sigma Investments
Xeno Kovah Co-founder, LegbaCore, LLC
Corey Kallenberg Co-Founder, LegbaCore, LLC

The number of vulnerabilities in firmware disclosed as affecting Wintel PC vendors has been rising over the past few years. Although several attacks have been presented against Mac firmware, unlike their PC counterparts, all of them required physical presence to perform. Interestingly, when contacted with the details of previously disclosed PC firmware attacks, Apple systematically declared themselves not vulnerable. This talk will provide conclusive evidence that Mac’s are in fact vulnerable to many of the software only firmware attacks that also affect PC systems. In addition, to emphasize the consequences of successful exploitation of these attack vectors, we will demonstrate the power of the dark side by showing what Mac firmware malware is capable of.

and:

 
Attacking Hypervisors Using Firmware and Hardware

Yuriy Bulygin Advanced Threat Research, Intel Security
Mikhail Gorobets Advanced Threat Research, Intel Security
Alexander Matrosov Advanced Threat Research, Intel Security
Oleksandr Bazhaniuk Advanced Threat Research, Intel Security
Andrew Furtak Security Researcher

In this presentation, we explore the attack surface of modern hypervisors from the perspective of vulnerabilities in system firmware such as BIOS and in hardware emulation. We will demonstrate a number of new attacks on hypervisors based on system firmware vulnerabilities with impacts ranging from VMM DoS to hypervisor privilege escalation to SMM privilege escalation from within the virtual machines. We will also show how a firmware rootkit based on these vulnerabilities could expose secrets within virtual machines and explain how firmware issues can be used for analysis of hypervisor-protected content such as VMCS structures, EPT tables, host physical addresses (HPA) map, IOMMU page tables etc. To enable further hypervisor security testing, we will also be releasing new modules in the open source CHIPSEC framework to test issues in hypervisors when virtualizing hardware.

And that’s just the ‘tip of the iceberg, for talks… Teddy Reed (author of UEFI Firmware Parser) has a talk. Joe FitzPatrick (of SecuringHardware.com) has a talk. There’s a talk on hardware side-channel attacks, one on BadUSB-like security, one on hardware trust, on medical device security, and a few other firmware-related talks, around 31 hits to ‘firmware’ in the schedule! Amongst the Workshops, there are some fun ones, including: ARM for pentesters, and Embedded System Design. In the Villages, the Hardware Hacking Village and the IoT Village sound interesting.

More Information:
https://www.defcon.org/html/defcon-23/dc-23-schedule.html

https://plus.google.com/+DefconOrgplus/posts
https://www.defcon.org/html/links/dc-goons.html

Hacking Team had other bootkits

Vlad Tsyrklevich wrote an excellent aritcle on the 0-day market via analyzing the Wikileak’ed Hacking Team emails:

http://tsyrklevich.net/2015/07/22/hacking-team-0day-market/
https://twitter.com/vlad902/status/623950714247749632

Most have already read about the UEFI malware that it used, including this Intel ATR analysis:
http://www.intelsecurity.com/advanced-threat-research/blog.html

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

02/24/14, “Apple iOS Remote Forced Access-Point Association”/“Apple iOS Remote Forced Firmware Update Avoidance” no longer available, OpenPAM (used on BSDs) LPE 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.

Apple issues firmware update

Today, Apple issues an update for MacBook Pro systems:

“MacBook Pro Flash Storage Firmware Update 1.0

This update is recommended for MacBook Pro (mid 2015) models. This update addresses a storage firmware issue that, in rare cases, may cause data corruption.”

I don’t know any more details of any security fixes…

https://support.apple.com/kb/DL1830?locale=en_US
https://support.apple.com/downloads/DL1830/en_US/macbookproflashstoragefwupd1.0.dmg

LegbaCore Mac firmware bricking demo and upcoming training

Yesterday LegbaCore published a video of a bricking demo of a a Mac Mini firmware vulnerability.

https://www.youtube.com/watch?v=LEEEazuc8Dg&feature=youtu.be

“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).”

https://twitter.com/legbacore/status/624062348324528128

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:

https://twitter.com/coreykal/status/624210503766663168

http://www.legbacore.com/Training.html
http://gsec.hitb.org/sg2015/sessions/tech-training-6-introductory-bios-smm-attack-defense/

LegbaCore Summer Tour announced

Apple Mac Mini EFI firmware update 1.8

As reported by Apple Support, and mentioned by Apple Insider and 9to5Mac news sites, Apple just released a firmware update for Mac Mini hardware for some models.

“This update is recommended for Mac mini (late 2012) models. This update addresses an issue that may prevent a USB keyboard from being recognized after the system wakes from sleep.”

I don’t know specifics of this release, and what security implications this has.

More Information:

https://support.apple.com/en-us/HT201518
https://support.apple.com/kb/DL1828?locale=en_US
http://appleinsider.com/articles/15/07/15/apple-releases-mac-mini-emi-firmware-update-to-fix-usb-keyboard-issue

Apple issues Mac mini EFI firmware update 1.8 to address USB keyboard problem

Apple Bitcode

At their recent annual developer conference, Apple mentioned ‘Bitcode’, a new bytecode technology that may give Apple some hardware independence options in the future.

“Bitcode is an intermediate representation of a compiled program. Apps you upload to iTunes Connect that contain bitcode will be compiled and linked on the App Store. Including bitcode will allow Apple to re-optimize your app binary in the future without the need to submit a new version of your app to the store. For iOS apps, bitcode is the default, but optional. If you provide bitcode, all apps and frameworks in the app bundle need to include bitcode. For watchOS apps, bitcode is required.

Will Bitcode show up on OSX or just be in iOS? Will Bitcode impact Apple firmware? Will Apple firmware use Bitcode instead of EBC (uEFI ByteCode)? I wish I knew, no answers just questions… 😦 Perhaps Bitcode will not impact Apple firmware, and this post is off-topic.

https://developer.apple.com/library/prerelease/watchos/documentation/IDEs/Conceptual/AppDistributionGuide/AppThinning/AppThinning.html#//apple_ref/doc/uid/TP40012582-CH35-SW2

Apple UEFI bootkit

There’s stories in multiple news sites today about a UEFI firmware bug in Apple systems, by security researcher Pedro Vilaça (@osxreverser), that is somewhat similar to Thunderstrike.

According to Dennis Fisher’s story at Threatpost, “The vulnerability can be exploited remotely, Vilaca said.” Threatpost also states: “He added that he believes Apple may know about this vulnerability already, as it doesn’t seem to be present on machines sold after about the middle of 2014.

If you have Apple — or perhaps other UEFI-based — hardware, you should follow this story!

More information:

Firmware Bug in OSX Could Allow Installation of Low-Level Rootkits


http://www.pcworld.com/article/2929172/apple-vulnerability-could-allow-firmware-modifications-researcher-says.html
http://www.securityweek.com/efi-zero-day-exposes-macs-rootkit-attacks-researcher