Intel ATR on firmware security threats

Jim Walter, Director of Advanced Threat Research for Intel Security, with contributions from Yuriy Bulygin and John Loucaides, wrote a blog for Dark Reading that summarizes some recent firmware attacks.

Vulnerable From Below: Attacking Hypervisors Using Firmware And Hardware
Malicious attacks with firmware privileges can compromise an entire system, so it is especially important to apply measures to reduce the risks.

Read the full article here:

http://www.darkreading.com/partner-perspectives/intel/vulnerable-from-below-attacking-hypervisors-using-firmware-and-hardware/a/d-id/1321834

 

 

CHIPSEC on DEF CON Conference CD


Apparently CHIPSEC is on the DEF CON 23 CD:

The DEF CON home page has a link to download the Conference CD. I’ve not done a diff yet, but it appears to still be version 1.21. If it has anything newer than 1.21, it is newer than their Github public release, and should be checked out immediately! There is a new S3bootscript security test in the works…

As much as I trust the DEF CON Goons, I might not run any binaries from this CD, and would diff the sources against the public CHIPSEC github release before running it. 🙂

https://defcon.org/

Conference CD, Direct Download:
https://media.defcon.org/DEF CON Conference CD DVD/DEF CON 23 Original Hacking Conference DVD.rar”
https://media.defcon.org/DEF%20CON%20Conference%20CD%20DVD/DEF%20CON%2023%20Original%20Hacking%20Conference%20DVD.rar

Conference CD, Directory of Files:
https://media.defcon.org/DEF%20CON%2023/DEF%20CON%2023%20presentations/Extras/1o57/Extras/chipsec-master/source/tool/chipsec/modules/common/”
https://media.defcon.org/DEF%20CON%2023/DEF%20CON%2023%20presentations/Extras/1o57/1o57.txt”

Intel ATR research on hypervisor vulnerability

As mentioned earlier, one of the interesting firmware talks at DC/BHB was on hypervisor vulnerabilities. The slides from the talk are now available:

Attacking Hypervisors Using Firmware and Hardware
Yuriy Bulygin, Mikhail Gorobets, Alexander Matrosov, Oleksandr Bazhaniuk, Andrew Furtak

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.

Click to access AttackingHypervisorsViaFirmware_bhusa15_dc23.pdf

http://www.intelsecurity.com/advanced-threat-research/index.html

Intel ATR research on CERT VU 976132

Earlier today I posted on US-CERT’s recent vulnerability note for multiple UEFI vulnerabilties:
https://firmwaresecurity.com/2015/07/30/us-cert-bios-vulnerability-note-vu577140/

Later today, Intel has released new research about this:

Technical Details of the S3 Resume Boot Script Vulnerability

“This paper describes technical details of a vulnerability (VU #976132 / CVE-2014-8274) in the protection of EFI based system firmware and platform configuration when resuming from the S3 sleep state.  The issue was independently discovered and presented at 31C3 in December 2014. After discovering this issue, the Advanced Threat Research team has been working to notify BIOS developers and ensure that mitigations are created. We are releasing a test module for the open source CHIPSEC platform security assessment framework. This will assist users in identifying whether their platforms might be affected by this issue.

Read the full report here:

Click to access WP_Intel_ATR_S3_ResBS_Vuln.pdf

Note the part about a new CHIPSEC test, to test for this vulnerability, so watch the CHIPSEC Github for an update. I don’t see an update as of yet.

OEMS: please watch the security talk from Phoenix from the last UEFI Forum plugfest, especially the advise to run CHIPSEC before you ship any new systems. Please ensure your QA team uses fresh CHIPSEC builds.

Consumer Reports and other PC reviewers: Please add the CHIPSEC pass/fail data for any new systems. OEMs will improve their internal QA once they realize that the first thing the public reviewers will be calling out the OEMs on known-bad products.

More information:

https://firmwaresecurity.com/2015/07/30/us-cert-bios-vulnerability-note-vu577140/

Click to access WP_Intel_ATR_S3_ResBS_Vuln.pdf

Intel analysis of Hacking Team UEFI malware

[[
UPDATE: IntelSecurity.com web site has changed, the ATR blog URL is broken. Updated URL:
http://www.intelsecurity.com/advanced-threat-research/ht_uefi_rootkit.html_7142015.html
]]

A quick follow-up to the Hacking Team UEFI malware story. There’s been a lot of mainstream coverage on this news. I just found out about this blog entry by the Intel Advanced Threat Research (ATR) team:

http://www.intelsecurity.com/advanced-threat-research/blog.html

It’s analysis of the malware is excellent, and worth reading. Unlike other news stories on Hacking Team, this blog shows you how to check if your system is infected. They used CHIPSEC[1] and UEFItool[2] to analyse this malware, two excellent tools for UEFI forensic analysis. Study this Intel blog post for a very topical example of how to use CHIPSEC to protect your system from bootkits.

[1] https://firmwaresecurity.com/2015/06/10/chipsec-v1-2-0-released/
https://github.com/chipsec/chipsec
[2] https://firmwaresecurity.com/2015/05/25/tool-mini-review-uefitool/
https://github.com/LongSoft/UEFITool

Hacking Tool should remind people that they don’t have a clue what modules are burned into their firmware. Many firmware solutions target enterprise sales, so they’re happy to have phone-home style technology in their systems, to track their assets. Malware authors can take advantage of these remote control features, like Hacking Team is doing. Windows OEMs generally screw up Windows with various bloatware; unlike with OS software, you cannot undo firmware bloatware, the OEM won’t permit you to rebuilt the firmware image (unless you have a Tunnel Mountain or MinnowBoard), and the OEM doesn’t provide standalone UEFI drivers/services so that you could rebuilt your firmware from coreboot.org and/or tianocore.org plus the delta of blobs (OEM/IHV drivers). Then, we could focus on reliability of the open source codebase and the handful of closed-source firmware drivers, instead of relying on the IBV/OEM to give us black-box fimware updates when they feel like it. OEMs: give us better firmware options!