Author: hucktech

Dell iDRAC CVE-2016-5685, bash vulnerability (old news)

~ hucktech ~ Leave a comment

http://www.securiteam.com/securitynews/5XP3B0UKUU.html

SecuriTeam confused me by reposting a 2016 Dell iDDRAC vulnerability today, but I don’t see anything new. Just in case you weren’t aware of this issue, and you have a Dell system, here’s info on this older vulnerability, see the last link for a PDF-based response from the Dell iDRAC team.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-5685
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-5685
http://www.securityfocus.com/bid/94585
http://en.community.dell.com/techcenter/extras/m/white_papers/20443326

“Dell iDRAC team’s response to Common Vulnerabilities and Exposures (CVE) ID CVE-2016-5685 [16 November 2016]
Summary: an authenticated user could gain Bash shell access through a string injection.
Dell Response: update to the latest iDRAC firmware, which remediates this potential vulnerability.”

 

scan_thinkpwn: searches for ThinkPwn vulnerability

~ hucktech ~ Leave a comment

THINKPWN SCANNER: This program is used to scan UEFI drivers extracted from firmware image for ThinkPwn vulnerability in vendor/model agnostic way.
AUTHORS:
@d_olex (aka Cr4sh) — initial Vivisect based version of the program;
@trufae (aka pankake) — radare2 based version (this one);

Read the source code for more user docs, including a detailed source comment about how the code works.

https://github.com/Cr4sh/ThinkPwn/blob/master/scan_thinkpwn.py

More info:
https://github.com/Cr4sh/ThinkPwn
http://blog.cr4.sh/2016/06/exploring-and-exploiting-lenovo.html

AMI announces TCG Pyrite support

~ hucktech ~ Leave a comment

AMI has announced support for Pyrite Password Protected Drives.
[…]The Trusted Computing Group (TCG) releases a specification called the “Opal SED Specification” that governs hard drive protection and encryption standards. AMI previously announced support for Opal and Opalite and now AMI has added password support for Pyrite. With the support for Pyrite, AMI enables drives that have a hardware mechanism to protect access without the need to carry out encryption of user data. AMI has worked with several industry partners to develop and validate the support for Pyrite. By introducing this support, OEMs can create solutions at lower costs than Opal or Opalite while maintaining the security of the data.[…]

Full PR:
https://ami.com/news/press-releases/?PressReleaseID=381

See-also:

TCG and NVMe release Opal for SEDs


https://trustedcomputinggroup.org/tcg-storage-security-subsystem-class-pyrite/
https://trustedcomputinggroup.org/tcg-storage-opal-nvme/
https://trustedcomputinggroup.org/tag/pyrite/

Finbarr’s TPM 2.0 PCR Tool

~ hucktech ~ Leave a comment

Finnbarr P. Murphy has a new blog post about a new UEFI-based TPM tool he’s written.

[…]By the way, if you have access to the Intel TXT (Trusted Execution Technology) EFI compliance testing toolkit, the included utility, pcrdump.efi, provides similar functionality to the utility described in this post.[…]

http://blog.fpmurphy.com/2017/01/uefi-utility-to-read-tpm-1-2-pcrs.html

See more of his UEFI Utilities:

FPMurphy’s UEFI Utilities has 2016 fork

https://github.com/fpmurphy/UEFI-Utilities

https://github.com/fpmurphy/UEFI-Utilities-2016

Apple seeks Core EFI Manager and Mac EFI Bring Up Engineer

~ hucktech ~ Leave a comment

The Mac Platform Software team is looking for a talented engineering manager to lead a team of firmware and systems software engineers responsible for developing Apple’s UEFI implementation and related technologies for the Mac product line. Mac Platform Software is responsible for bringing up macOS and Windows on all new Mac products, including the development and integration of firmware and systems software for macOS and Windows, the development of platform-level features for the Mac, and the leadership of cross-functional debug and optimization efforts across hardware and software teams.[…]

https://jobs.apple.com/search?job=56058298&openJobId=56058298#&openJobId=56058298

The Mac Platform team in Core OS is looking for a talented UEFI engineer to work on the bring-up of new Mac products. Breathe life into new Mac products by developing firmware across all phases of development, from pre-silicon to product ramp.[…]

https://jobs.apple.com/search?job=56058163&openJobId=56058163#&openJobId=56058163

CHIPSEC gets new UEFI Whitelist command

~ hucktech ~ Leave a comment

CHIPSEC already has a Blacklist command. Now there is a UEFI whitelist command.

USG: firewall for USB ports

~ hucktech ~ Leave a comment

The USG is Good, not Bad

The USG is a firewall for your USB ports, protecting your computer from BadUSB. It connects between your computer and your untrusted USB device, isolating the badness and keeping your computer safe. This is the firmware branch for the pre-assembled USG v1.0. If you want to build your own USG out of development boards, clone the v0.9 branch instead. USG v1.0 hardware now available. You can now order your own USG hardware by contacting the developer. Pricing is NZ$80 each (approx US$60) plus shipping to your country of choice. It will ship fully tested and pre-loaded with the latest firmware.[…]

https://github.com/robertfisk/USG

https://github.com/robertfisk/USG/wiki

https://github.com/robertfisk/USG/wiki/Hardware-(DIY-v0.9)

McAfee on CHIPSEC, post Vault7

~ hucktech ~ Leave a comment

“EFI firmware malware is a new frontier for stealth and persistent attacks which may be used by sophisticated adversaries to penetrate and persist within the organization’s and national infrastructure for very long time. Use open source CHIPSEC to defend from this threat and stay safe.”

https://securingtomorrow.mcafee.com/business/chipsec-support-vault-7-disclosure-scanning/

more on CIA UEFI malware

~ hucktech ~ Leave a comment

Some comments from Yuriy of the Intel ATR team:

more on CIA UEFI wikileaks pages

~ hucktech ~ Leave a comment

More on CIA UEFI wikileaks pages:

EDB, Embedded Development Branch (includes UEFI):

https://wikileaks.com/ciav7p1/cms/space_753667.html

Active UEFI projects:

https://wikileaks.org/ciav7p1/cms/page_26968082.html

DerStarke project:

https://wikileaks.org/ciav7p1/cms/page_3375125.html

QuarkMatter project:

https://wikileaks.org/ciav7p1/cms/page_21561431.html

https://wikileaks.org/ciav7p1/cms/page_9535555.html

https://wikileaks.org/ciav7p1/cms/index.html

tutorial on using UDK with Linux:

https://wikileaks.org/ciav7p1/cms/page_27262984.html

Wikileaks on CIA UEFI malware

~ hucktech ~ Leave a comment

https://wikileaks.org/ciav7p1/cms/page_26968080.html

https://wikileaks.org/ciav7p1/cms/page_36896783.html

https://wikileaks.org/ciav7p1/cms/page_29851664.html

https://wikileaks.org/ciav7p1/cms/page_29851664.html

https://wikileaks.org/ciav7p1/cms/page_27721733.html

https://wikileaks.org/ciav7p1/cms/page_27262984.html

https://wikileaks.org/ciav7p1/cms/page_26968084.html

 

https://twitter.com/osxreverser/status/839110834496364544

https://wikileaks.org/ciav7p1/cms/page_11629096.html

UEFI gets AMD Secure Encrypted Virtualization (SEV) support

~ hucktech ~ Leave a comment

AMD has submitted a similar patch to the Linux kernel, now there is support for AMD SEV in UEFI.

[RFC PATCH v1 0/5] x86: Secure Encrypted Virtualization (AMD)

This RFC series provides support for AMD’s new Secure Encrypted Virtualization (SEV) feature. SEV is an extension to the AMD-V architecture which supports running multiple VMs under the control of a hypervisor. The SEV feature allows the memory contents of a virtual machine (VM) to be transparently encrypted with a key unique to the guest VM. The memory controller contains a high performance encryption engine which can be programmed with multiple keys for use by a different VMs in the system. The programming and management of these keys is handled by the AMD Secure Processor firmware which exposes a commands for these tasks. SEV guest VMs have the concept of private and shared memory.  Private memory is encrypted with the guest-specific key, while shared memory may be encrypted with hypervisor key.  Certain types of memory (namely instruction pages and guest page tables) are always treated as private memory by the hardware. For data memory, SEV guest VMs can choose which pages they would like to be private. The choice is done using the standard CPU page tables using the C-bit, and is fully controlled by the guest. Due to security reasons all the DMA operations inside the  guest must be performed on shared pages (C-bit clear). Note that since C-bit is only controllable by the guest OS when it is operating in 64-bit or 32-bit PAE mode, in all other modes the SEV hardware forces the C-bit to a 1. KVM SEV RFC [1] extends the KVM_FEATURE cpuid instruction to indicate whether SEV is enabled. When SEV is enabled then OVMF can use cpuid Fn8000_001F[BX] to get the C-bit position in PTE.

AMD Memory Encryption whitepaper:

Click to access AMD_Memory_Encryption_Whitepaper_v7-Public.pdf

AMD64 Architecture Programmer’s Manual (SME is section 7.10, SEV is section 15.34):

Click to access 24593.pdf

Secure Encrypted Virutualization Key Management:
http://support.amd.com/TechDocs/55766_SEV-KM API_Specification.pdf

KVM Forum Presentation:

Click to access 02x08A-Thomas_Lendacky-AMDs_Virtualizatoin_Memory_Encryption_Technology.pdf

[1] http://marc.info/?l=linux-mm&m=148846752931115&w=2

More info:
https://lists.01.org/mailman/listinfo/edk2-devel

UEFI lab at Cascadia IT Conference in Seattle March 10th

~ hucktech ~ Leave a comment

[DISCLAIMER: FirmwareSecurity is my personal blog. I work at PreOS Security.]

PreOs Security is offering a half-day training lab for System Administrators, SRE/DevOps in the Seattle area at Cascadia IT Conference, for those interested in learning about UEFI/ACPI/BIOS/SMM/etc security. Here’s the text for the training:

Defending System Firmware

Target audience: System administrators, SRE, DevOps who work with Intel UEFI-based server hardware

Most enterprises only defend operating system and application software; system and peripheral firmware (eg., BIOS, UEFI, PCIe, Thunderbolt, USB, etc) has many attack vectors. This workshop targets enterprise system administrators responsible for maintaining the security of their systems. The workshop is: an introduction to UEFI system firmware, an overview of the NIST secure BIOS platform lifecycle model of SP-(147,147b,155) and how to integrate that into normal enterprise hardware lifecycle management, and an introduction to the available open source firmware security tools created by security researchers and others, and how to integrate UEFI-based systems into the NIST lifecycle using available tools, to help protect your enterprise. It will be a 3.5 hour presentation, and at the end, you can optionally can run some tests on your laptop: Intel CHIPSEC, Linux UEFI Validation distribution (LUV-live), FirmWare Test Suite live boot distribution (FWTS-live), and a few other tools. Attendees trying to participate in the lab will need to have a modern Intel x86 or x64-based (not AMD), UEFI-based firmware, running Windows or Linux OS software. That means no AMD systems, no Apple Macbooks, no ARM systems. Any system used in the lab must have all data backed up, in case some tool bricks the device. Attendees should understand the basics of system hardware/firmware, be able to use a shell (eg, bash, cmd.exe, UEFI Shell), and able to use Python-based scripts.

https://www.casitconf.org/casitconf17/tutorials/

announcing PreOS Security Inc.

~ hucktech ~ Leave a comment

FirmwareSecurity.com is my personal blog. I use it to post information about firmware as I come across it, in the hope that it might help others. I try to keep it impersonal and only focus on news/information, but my bias towards open source HW/FW/SW is not hard to find.

I started the blog a few years ago to learn firmware by focusing on the security perspective of firmware and learning from existing security researchers. I’d been doing OS-level driver consulting for a while, and was moving from OS-level moving down into firmware. Along the way, I’ve learned a lot and given talks and training on firmware security at LinuxFest Northwest, B-Sides PDX, SOURCE Seattle, and other places.

With great advice from both firmware engineers as well as firmware security researchers, I’ve seen an opportunity to help secure enterprises at the firmware level.

I’ve started a small new company, PreOS Security Inc.,  https://preossec.com/ . Besides attending the last UEFI Plugfest, we’ve been mostly in ‘stealth mode’, busy working on code. We have a small group of advisors who are teaching us lots of things about security/b2b/tool startups.

We’re creating a product to help enterprises secure their system firmware, as per NIST SP 800-147 guidance. We’re leveraging the expertise of existing firmware security researchers, and some of their tools (for example CHIPSEC). We’re also writing new tools to fill in some of the gaps. Our product is currently in a pre-alpha stage, and are looking for a few enterprises who’re eager to secure their firmware to work on the alpha release.

We have a draft document on ‘enterprise firmware guidance’ that we’ll be publishing on our web site (and Github), as well as that ‘awesome firmware’ links that I’ve been promising in previous blog posts. We have some patches to existing tools that we need to upstream.

We also offer training to UEFI/ACPI device vendor QA teams, data centers, and security-minded enterprises, on using firmware security tools, and consulting to customize/integrate these tools. We’ve got a half-day training event that we’ll announce shortly.

We need a Python developer, either as a partner, or a few as contractors. Currently we have equity to offer. For more information, see:  https://preossec.com/careers/ .

We’re currently self-funded, hoping to fund our product development with training/consulting. But to offer more than equity, we’ve begun looking at some other sources of funding. If there are any firmware-friendly angel investors reading this, we should talk.

https://preossec.com/careers/