Uncategorized

status of MITRE Copernicus

AFAIK, Copernicus was the first firmware vulnerability analysis tool. MITRE’s research in this area is required reading for anyone learning x86 firmware security. But then, half of the 4-person team left MITRE to create LegbaCore, and have since both joined Apple. These days, AFAIK, Copernicus is not actively maintained.  I was not sure of status of MITRE Copernicus (or Copernicus2), so I asked MITRE, and K. Wright, their Public Affairs Lead gave me the current status of Copernicus:

“MITRE continues to research security risks associated with UEFI and firmware. However, development and feature enhancements on the proof-of-concept known as Copernicus is no longer active. Many of the emerging commercial offerings coming to the market show promise similar to what had been demonstrated in Copernicus as an off-the-shelf option.”

More information:

http://www.mitre.org/research/technology-transfer/technology-licensing/copernicus

 

Without fresh builds of Copernicus, Intel CHIPSEC is probably the main (only?) firmware vulnerability analysis tool actively maintained. It would be nice if there were a few other tools, ESPECIALY for non-Intel systems: ARM, AMD, MIPS, OpenPOWER, etc. I wish MITRE would open source their PoC so the open source community could help maintain/extend it (eg., port it to Linux).

Standard
Uncategorized

Apple EFI security update for Mac OS X 10.9.5

Apple has announced an EFI securtity update for Mac OS X 10.9.5, apparently due to LegbaCore/MITRE research.

APPLE-SA-2015-10-21-6 Mac EFI Security Update 2015-002

Mac EFI Security Update 2015-002 is now available and addresses the following: EFI
Available for:  OS X Mavericks v10.9.5
Impact:  An attacker can exercise unused EFI functions
Description:  An issue existed with EFI argument handling. This was addressed by removing the affected functions.
CVE-ID: CVE-2015-7035 : Corey Kallenberg, Xeno Kovah, John Butterworth, and Sam Cornwell of The MITRE Corporation, coordinated via CERT
Installation note: Mac EFI Security Update 2015-002 may be obtained from the Mac App Store.

Full message:

http://support.apple.com/kb/HT1222
https://support.apple.com/en-us/HT205317
https://support.apple.com/en-us/HT204934

In addition to this EFI update, Apple has released Multiple Security Updates:
https://www.us-cert.gov/ncas/current-activity/2015/10/21/Apple-Releases-Multiple-Security-Updates

Standard
Uncategorized

LegbaCore adds BIOS/SMM training to OpenSecurityTraining.Info!

They’ve added a 2-day training course on BIOS/SMM, “Advanced x86: Introduction to BIOS & SMM”! The BIOS researchers at MITRE — and half of them now at LebaCore — are one of the main pioneers of BIOS research, and this is one of ther main training sessions. Wow!

“Around 2011, the trustworthy system measurement research project that Xeno Kovah was running at MITRE decided to start digging deeper than the Windows kernel and rootkit detection, to try and detect malicious software at the BIOS level. Xeno & Corey Kallenberg continued to work on Kernel, while team member John Butterworth was tasked with starting to learn about BIOS in parallel. John’s work led to the “BIOS Chronomancy” work (published at both BlackHat and ACM CCS), porting the team’s existing Timing-Based Attestation system from the kernel level down to the BIOS. Xeno then asked John to start making an open source training class to capture his knowledge, the same way that Xeno & Corey had captured their past knowledge on the project and uploaded it to OST. John created a 2 day Intro BIOS class and got it public released from MITRE. The intention originally was that it would cover all basics of BIOS which would be applicable to both legacy BIOS, CoreBoot, or UEFI-based systems. And then it was expected there would be a follow on class digging deeper into the specifics of UEFI. Unfortunately time prohibited the creation of that 2nd 2 days of classes focusing on UEFI, so you can see that some minimal UEFI content was eventually shoehorned into this class, though frequently there isn’t enough time to get to it within 2 days. It is our hope that this Introductory BIOS & SMM class will help demystify how x86 systems work at the low levels, so that people can better understand the BIOS/SMM/SecureBoot vulnerabilities described in the team’s work while at MITRE, and later after Xeno & Corey founded LegbaCore. With this knowledge in hand, hopefully students can fully appreciate and explain to others why it is so critical that BIOS patch management be performed by organizations, to eliminate the vulnerabilities that lurk at this level.

http://opensecuritytraining.info/IntroBIOS.html

Standard
Uncategorized

MITRE Copernicus

MITRE Copernicus was — AFAICT — the first public firmware vulnerability analysis tool. I’ve not given it enough coverage here, only a single post:

https://firmwaresecurity.com/2015/05/22/mitre-copernicus/

I presume that everyone already knows about it. If you don’t know about it, it is worth investigating

It appears that MITRE hasn’t updated Copernicus, in a while, at least I can’t find any. I just noticed that Xeno of LebaCore, formerly of MITRE and one of the Copernicus developers, gave an URL to the latest version of it, which is a public download:

The same URL to that zip is in the below mini-review for BIOS Diff, a cross-platform open source firmware utility that is included in Copernicus:

https://firmwaresecurity.com/2015/05/21/tool-mini-review-bios_diff-py/

Copernicus is Windows-centric, and public release is closed-source, including the driver. I wish there was another host for it, in addition to blackhat.com, a domain commonly attacked by hacker. I wish it was hosted in another place, and included a .SHA256 and OpenPGP .ASC sidecar files for verfication. I REALLY wish the sources to the Windows driver were published!

Looking forward to another version of Copernicus, or some other new tools from LegbaCore!

 

Standard
Uncategorized

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

Standard
Uncategorized

MITRE Copernicus

So far, in this new blog, I’ve been mostly focusing on open source tools and open source operating systems, so I’ve not focused on MITRE’s Windows-centric non-open source tool, Copernicus[1]. But the tool is extremely powerful, and deserves more attention.

“Copernicus is the first tool to provide BIOS configuration management and integrity checking capabilities throughout an enterprise. The tool is implemented as a kernel driver that creates a file containing the BIOS dump and a file containing the raw configuration information. When deployed in enterprise environments, scripts can send the raw BIOS dump and configuration information to a server for post-processing. This processing can indicate whether a given BIOS differs from an expected baseline, and it can also indicate whether the BIOS or the computer’s System Management RAM (where some code loaded by BIOS continues running after boot).”

An excerpt from a G+ post in 2013 from Dragos Ruiu on Copernicus:

“IMHO Copernicus BIOS verification tool, is one of the most important new security tools in recent history. We’ve already found some persistent BIOS malware that survives re-flashing with it.”

I wish it were available for Linux, not just for Windows, so I could use it! And I wish it were open source (alas, all security tools are not): trusting any native kernel driver on your system, or especially to deploy to all systems in you enterprise, whether it is natively installed or from another boot media, has issues. I hope licensees from MITRE have the option to review the code and compile it themselves.

[Intel’s CHIPSEC also has some similar features. When run as an OS-present tool — instead of a live-boot or UEFI Shell booted — CHIPSEC also includes a native driver on Windows, and on Linux. With CHIPSEC, the kernel driver sources are provided.]

If you have Windows-based enterprise, you should investigate out Copernicus.

Windows-centric code aside, Copernicus distribution includes bios_diff.py, which works on Linux. This is a wonderful tool[2].

Even if you don’t care about Windows, you should study the Copernicus research, is it amazing.

Two of the creators of Copernicus have left MITRE and have started LegbaCore. Their last talk on using Copernicus at RSA conference last month[3] was excellent, talking about using Copernicus usage in enterprises.

More Information:

[1]http://www.mitre.org/publications/project-stories/going-deep-into-the-bios-with-mitre-firmware-security-research
http://www.mitre.org/capabilities/cybersecurity/overview/cybersecurity-blog/copernicus-question-your-assumptions-about
http://www.mitre.org/publications/technical-papers/copernicus-2-senter-the-dragon
http://www.mitre.org/capabilities/cybersecurity/overview/cybersecurity-blog/playing-hide-and-seek-with-bios-implants
http://www.mitre.org/research/technology-transfer/technology-licensing/copernicus
[2]https://firmwaresecurity.com/2015/05/21/tool-mini-review-bios_diff-py/
[3]https://firmwaresecurity.com/2015/05/19/legbacore-releases-new-firmware-research-at-rsa-conference/

Standard
Uncategorized

Tool mini-review: bios_diff.py

I recently became of a tool that I didn’t know worked on Linux: bios_diff.py, included with Copernicus. The MITRE Corporation’s Copernicus is a very powerful firmware security tool. I’ve been focusing more on non-Windows tools and open source tools, so I’ve not been giving Copernicus tools enough emphasis, something I’ll correct in future posts. I’ll start with this post, on bios_diff.py, which is distributed with Copernicus. This tool is not Copernicus-centric, nor Windows-centric.

If you’ve a dump of a BIOS ROM image, created by CHIPSEC or Copernicus or Coreboot’s FlashROM, you can use bios_diff.py to help determine what has changed. The tool parses the EFI Firmware Filesystem, to break out the files. It can also do smart diff’ing based on GUIDs in case files were added/removed, and will provide additional semantically relevant things like the file name, PE sections, and size of differences found (where each is applicable.)

This tool is a very useful addition to your open source firmware security toolbox.

This free tool does have some limits, EFIPWN is not as good as the newer UEFITool w/r/t some parsing. Perhaps someone has time to integrate UEFTool into a newer version of this tool? 🙂

Usage:

  bios_diff.py [-crs] [-i IGNORE] [-d [-a [-p]] [-n [-u UNIQUE]] [-l SIZELIMIT] [-m NUMBYTES]] [-o OUT] [-e EFIPWN] <file1> [<file2>]
  bios_diff.py (-h | –help)

The files are BIOS dumps to be compared.  <file2> may be a single file, or it may be a directory which contains several BIOS dumps against which we will diff <file1>.  Also, <file1> can be a directory by itself.  In this case, the first file found in this directory will be compared against all of the others.

Options:
  -c            delete the directories when the diff is complete
  -r            reuse parsed directories previously generated by EFIPWN if they appear to exist
  -s            print out all sha1 hashes of files in BIOS dump
  -i IGNORE     file containing list of regular expressions (one per line) for filenames we should ignore
  -d            do hash diffing of extracted files
  -a            print all unique ranges per file
  -n            print number of unique bytes per file
  -u UNIQUE     exclude diffs which have less than UNIQUE unique bytes for both files
  -l SIZELIMIT  dont compute unique ranges or bytes on files which exceed this size
  -p            print the PE information about diffs if the files are PE files
  -m NUMBYTES   merge regions which are within NUMBYTES of eachother
  -o OUT        output directory [default: temp]
  -e EFIPWN     the location of EFIPWN files [default: EFIPWN]

More information:

https://www.blackhat.com/docs/us-13/US-13-Butterworth-BIOS-Security-Code.zip

Standard