Hyper-V UEFI bootloader complexities

[…]Forcing GRUB installation to EFI removable media path does basically the same thing as when Ubuntu installer asks you if you want to force UEFI installation: it installs to the removable media path in the ESP (EFI System Partition). This is fine for environment where no other operating system is present. However if there is another operating system present on the device which depends on this fallback location “removable media path” it will make this system temporary unbootable (you can manually configure GRUB later to boot it if necessary though). Windows installer for example *also* installs to the removable media path in the ESP. All OS installers installing things to this removable media path will conflict with any other such installers and that’s why in Debian (and Ubuntu) installers don’t do this by default. You explicitly have to select UEFI mode during the normal installation (what I did).[…]

https://blog.jhnr.ch/2017/02/23/resolving-no-x64-based-uefi-boot-loader-was-found-when-starting-ubuntu-virtual-machine/

NATO on UEFI attack vectors

Glad to see forensic community realizing that there is more under the hood than they’ve been paying attention to. A new PDF in the SANS Digital Forensics reading room:

Analysis of the building blocks and attack vectors associated with the Unified Extensible Firmware Interface (UEFI)
Author: Jean-François Agneessens (jean.agneessens@ncirc.nato.int)
Advisor: Manuel Humberto Santander Pelaez

While Operating Systems have seen tremendous and very visible developments, driven by the evolution of hardware components, there are still some remnants from the 8086-era, one of which is the BIOS. Led by a consortium of vendors, the industry is now implementing a new style of BIOS which, by design, appears to overcome all the issues introduced by the Intel 8086 engineering decisions back in 1978. The Unified Extensible Firmware Interface (UEFI), replacement of the legacy BIOS, is a blank-sheet design based on modular pieces of code following the well-known Portable Executable/Common Object File Format (PE/COFF), found on all Microsoft OS-based executable code. The UEFI code can therefore be reverse-engineered using similar techniques learned during GREM. The concepts of UEFI, and some of its VMware implementation, are presented here, as well as an insight into the possible paths open for further exploitation of the extended capabilities offered by UEFI.

https://www.sans.org/reading-room/whitepapers/services/analysis-building-blocks-attack-vectors-unified-extensible-firmware-34215

 

somewhat related:

http://www.nato.int/cps/en/natohq/news_118855.htm

 

HP seeks firmware pentester

Application Security Engineer – Firmware
HP Cloud Solutions and Operations (CSO) Security is an engineering organization specializing in secure development practices and penetration testing. We are organized as an internal consulting business, enabling our customers to develop and launch a diverse range of customer-facing products including mobile, eCommerce, web services, and embedded. It’s our job to analyze the design, audit the source code, and attempt to break the final product before potential adversaries do. We’re hiring an application security engineer with firmware experience and penetration tester at our new Vancouver, WA office. We have openings for a full-time engineer. Ideally, you have a passion for learning new attack vectors and implementing working exploits. Given your past experience you can improve the security of the architecture, design, authorship, and testing of code. If many of the following apply, you’re probably a good fit.[…]

https://h30631.www3.hp.com/job/-/-/3544/4119219

Trapezoid on lack of firmware security standards

Trapezoid CTO Jose Gonzalez has written a new article on LinkedIn about lack of firmware security in government standards.

[…]What’s the problem? Firmware is powerful code that persists from device restart to restart, sitting below operating systems and driver layers where it can fool anything else on the system – including existing security tools – into thinking everything is working fine. The problem is that very few people are paying attention to protecting the firmware.[…]

Developing a NY DFS Cybersecurity Program? Pay attention to firmware!

https://www.linkedin.com/pulse/developing-ny-dfs-cybersecurity-program-pay-attention-gonzalez

http://articles.trapezoid.com/

Timothy Pearson of Raptor on closed-source firmware

Timothy Pearson of Raptor Engineering has a blog post talking about the security issues of closed-source firmware ‘blobs’.

[…]So, what are your thoughts on the current x86 proprietary software situation? Are you willing to continue to use FOSS software inside the ever-shrinking x86 “software jail”, or are you possibly willing to give up some cost or performance advantages in order to retain full control of the software running on your hardware? This is a question that will need to be answered soon; the long-term consequences of a fully TiVo-ized computing world are not to be taken lightly, and thus far the free software community has put up very little resistance to the antifeatures being forced into modern x86 platforms. I hope to provoke wider discussion on these topics via this message.

https://decentralize.today/uncorrectable-freedom-and-security-issues-on-x86-platforms-2e6220fa07ed#.nznipc24t

 

Nikolaj on AMD AGESA/PSP

Nikolaj Schlej made a comment on the recent Snowden/AMD thread. The comment is on Twitter, so it is in multiple messages. I hope that AMD proves him wrong, AMD can change course, so can Intel, if they choose.

https://twitter.com/NikolajSchlej/status/837751682226405379

https://twitter.com/NikolajSchlej/status/837752203490308096

https://twitter.com/NikolajSchlej/status/837752948004388865

https://twitter.com/NikolajSchlej/status/837753773737000960

https://twitter.com/NikolajSchlej/status/837754171642286081

https://twitter.com/NikolajSchlej/status/837754489843109888

https://twitter.com/NikolajSchlej/status/837755046825713666

https://twitter.com/NikolajSchlej/status/837755976887468034

https://twitter.com/NikolajSchlej/status/837756570733793281

Syscall-Monitor for Windows

Syscall Monitor is a system monitor program (like Sysinternal’s Process Monitor) using Intel VT-X/EPT for Windows7+

https://github.com/hzqst/Syscall-Monitor

It requires Intel x86/x64 systems with Intel VT-x and EPT support, running Microsoft Windows.

 

6th RISC-V Workshop: call for papers

Registration and the call for presentations / posters is open for the 6th RISC-V Workshop, co-hosted by NVIDIA and the Shanghai Jiao Tong University (SJTU) in Shanghai China on May 8-11, 2017.  As with past workshops, our goals for these events are to bring the RISC-V community together to share information about recent activity in the various RISC-V projects underway around the globe, and build consensus on the future evolution of the instruction set. This will be a four day event broken down as follows[…]

https://riscv.org/2017/03/6th-risc-v-workshop-registration-and-call-for-papers/

Users ask firmware vendors for open source option

Vendors, your compiled code is an firmware attack vector, and makes it harder to trust your product. Secure Boot and signed images are not silver bullets. If you made golden images available, as per NIST 147, we could at least tell if your blobs have changed. But trusting blobs is not enough, there’s enough HW/FW vulnerabilities, and opportunities for attackers to subvert the supply chain. Only open source firmware will solve the firmware blob security problem. Intel has FSP, AMD has AGESA. All IBVs ship closed-source products, no open source vendors, and OEMs/IHVs ship closed-source drivers. Giving us an open source option would solve this problem. IBM claims the OpenPOWER is blob-free, but I’ve yet to verify this. RISC-V is also an ISA that also may be blob-free at the firmware level, depending on the manufacturer. Both OpenPOWER and RISC-V may offer some alternatives to current processors, if they wish to keep with status quo. I hope to see more security standards require the option to build firmware from source, and user ability to reinstall from their own locally-compiled version. And at least requiring that vendors ship hashes for all the blobs they ship.

 

Dear AMD, could you please release the Platform Security Processor (PSP) source code to the Coreboot / Libreboot project? (or publicly)
[…]
Thanks for the inquiry. Currently we do not have plans to release source code but you make a good argument for reasons to do so. We will evaluate and find a way to work with security vendors and the community to everyone’s benefit.
–AMD_jamesProduct Manager 487 points 4 hours ago 

https://www.coreboot.org/Binary_situation https://libreboot.org/faq/#amd

Comment
byu/AMD_Robert from discussion
inAmd

 

Microsoft seeks Senior UEFI Engineer

The Surface Team focuses on building devices that fully express the Windows vision. Be part of the team that brings to life experiences in Microsoft Windows and Office through the hardware of its Microsoft Surface product line.   Our team develops the UEFI and firmware that connects the operating system to the hardware. Candidate will be a member of the Surface SW/FW team and be responsible for developing, adapting and fixing code related to UEFI. As a member of the team, candidate will actively participate on development practices such as task planning/sizing and scheduling, bug triage and bug management.   Candidate will actively participate in SCRUM meetings, documenting progress and updating tasks. Candidates are expected to collaborate and familiarize with other functions within the team in order to develop BIOS code that adapts the HW to platform requirements. […]

https://careers.microsoft.com/jobdetails.aspx?jid=275588&job_id=1016471

 

Malware Guard Extension: Using SGX to Conceal Cache Attacks

Malware Guard Extension: Using SGX to Conceal Cache Attacks
Michael Schwarz, Samuel Weiser, Daniel Gruss, Clémentine Maurice, Stefan Mangard
(Submitted on 28 Feb 2017 (v1), last revised 1 Mar 2017 (this version, v2))
In modern computer systems, user processes are isolated from each other by the operating system and the hardware. Additionally, in a cloud scenario it is crucial that the hypervisor isolates tenants from other tenants that are co-located on the same physical machine. However, the hypervisor does not protect tenants against the cloud provider and thus the supplied operating system and hardware. Intel SGX provides a mechanism that addresses this scenario. It aims at protecting user-level software from attacks from other processes, the operating system, and even physical attackers. In this paper, we demonstrate fine-grained software-based side-channel attacks from a malicious SGX enclave targeting co-located enclaves. Our attack is the first malware running on real SGX hardware, abusing SGX protection features to conceal itself. Furthermore, we demonstrate our attack both in a native environment and across multiple Docker containers. We perform a Prime+Probe cache side-channel attack on a co-located SGX enclave running an up-to-date RSA implementation that uses a constant-time multiplication primitive. The attack works although in SGX enclaves there are no timers, no large pages, no physical addresses, and no shared memory. In a semi-synchronous attack, we extract 96% of an RSA private key from a single trace. We extract the full RSA private key in an automated attack from 11 traces within 5 minutes.

https://arxiv.org/abs/1702.08719

Raptor meets OpenBMC crowdsourcing pledge goal!

Overall Goal:    $50,000 USD
Raptor’s Contribution:    $30,000 USD
Community Goal:    $20,000 USD
Current Pledges:    $20,000 USD
Remaining Deficit:    $0 USD
 Overall Funding Status:    100.0%
Community Funding Status:    100.0%

https://www.raptorengineering.com/coreboot/kgpe-d16-bmc-port-offer.php

 

Qualcomm seeks Firmware Security Researcher

I’m going to try and start to post the occasional relevant interesting job postings for security researchers or developers. I will try to use ‘job-posting” for the tag for all of them. If you think it’s a bad idea for this blog, or if you get the job based on this blog, leave a Comment. 😉

[…]Qualcomm Hardware Security team is looking for a Firmware Security Researcher to help drive security efforts in our System-On-Chip (SOC) solutions. In this role, the Firmware Security Researcher will work closely with the Hardware Design Team, Hardware Verification team, and the Software team to help find vulnerabilities in our products. This role entails using best practices to evaluate, asses, and report vulnerabilities in QUALCOMM products. A systematic approach to vulnerability discovery is essential. Knowledge gained will leverage into new security mitigations for our SOC solutions used in a wide range of products, including mobile devices, IOT, automotive, consumer networking gear, wearables, and embedded medical devices. As a firmware security researcher, it is essential that the candidate be able to develop proof-of-concepts to demonstrate the impact of the vulnerabilities that are discovered, to enable proper prioritization and communication of issues to internal teams and external customers. Communication skills are highly valued as the role will entail cross-department coordination with the various groups involved in Cybersecurity initiatives, and possibly presenting findings at security conferences.[…]

https://jobs.qualcomm.com/public/jobDetails.xhtml?requisitionId=1950936

Linux Foundation workstation security ebook

[…]Now, before you even start with your operating system installation, there are a few things you should consider to ensure your pre-boot environment is up to snuff. You will want to make sure:
* UEFI boot mode is used (not legacy BIOS) (ESSENTIAL)
* A password is required to enter UEFI configuration (ESSENTIAL)
* SecureBoot is enabled (ESSENTIAL)
* A UEFI-level password is required to boot the system (NICE-to-HAVE)

https://www.linux.com/news/linux-workstation-security/2017/3/4-security-steps-take-you-install-linux

http://go.linuxfoundation.org/workstation_security_ebook

Sounds interesting, but I don’t see any actual download link for this ebook. I guess I need some sleep.

There is also this: https://firmwaresecurity.com/2015/08/31/linux-foundation-it-security-policies-firmware-guidance/

 

Exploiting Samsung’s Secure Bootloader (S-Boot) for Android

Exploiting Android S-Boot: Getting Arbitrary Code Exec in the Samsung Bootloader (1/2)
Nitay Artenstein (@nitayart) and Gilad Goldman (@gnull00)

Samsung’s Secure Bootloader (S-Boot) for Android lies at the heart of Samsung’s chain of trust concept. An attacker who compromises S-Boot could potentially load an untrusted kernel and system image, therefore bypassing most of the phone’s security mechanisms. This is a well-known attack vector: It’s often used by the Android rooting and modding community, but our guess is that it’s way more popular with law enforcement and government agencies. All the more interesting, then, that S-Boot on contains several memory corruption bugs, one of which could be used to reach full code execution within the bootloader. We can currently confirm the existence of the vulnerability only on Exynos chipsets. It seems universal to approximately 90% of the Samsung Exynos ROMs running on S5, S6 and S7. The very newest ROMs for S7 (February 2017) appear to include a fix for this bug, but we’ll confirm this in a few days. There’s a lot of ground to cover, so we’ll break up this write-up into two posts. In this post we’ll focus on some S-Boot internals, then explore the bootloader’s attack surface and get basic debugging capabilities. We’ll end the post with the discovery of an especially interesting attack surface. In the next post we’ll disclose the actual vulnerability and how we exploited it to get code execution in S-Boot. We won’t go into much detail on the basics of reversing S-Boot, such as how to load it into IDA or find the base address. Fernand Lone Sang (@_kamino_) is about to publish a great article exactly about that and I’ll put a link for it here when it’s out. If you need any help beyond that, just DM me and I’d be glad to give you a hand if I can.[…]

Software Grand Exposure: SGX Cache Attacks Are Practical

Software Grand Exposure: SGX Cache Attacks Are Practical
Ferdinand Brasser, Urs Müller, Alexandra Dmitrienko, Kari Kostiainen, Srdjan Capkun, Ahmad-Reza Sadeghi
(Submitted on 24 Feb 2017)
Side-channel information leakage is a known limitation of SGX. Researchers have demonstrated that secret-dependent information can be extracted from enclave execution through page-fault access patterns. Consequently, various recent research efforts are actively seeking countermeasures to SGX side-channel attacks. It is widely assumed that SGX may be vulnerable to other side channels, such as cache access pattern monitoring, as well. However, prior to our work, the practicality and the extent of such information leakage was not studied. In this paper we demonstrate that cache-based attacks are indeed a serious threat to the confidentiality of SGX-protected programs. Our goal was to design an attack that is hard to mitigate using known defenses, and therefore we mount our attack without interrupting enclave execution. This approach has major technical challenges, since the existing cache monitoring techniques experience significant noise if the victim process is not interrupted. We designed and implemented novel attack techniques to reduce this noise by leveraging the capabilities of the privileged adversary. Our attacks are able to recover confidential information from SGX enclaves, which we illustrate in two example cases: extraction of an entire RSA-2048 key during RSA decryption, and detection of specific human genome sequences during genomic indexing. We show that our attacks are more effective than previous cache attacks and harder to mitigate than previous SGX side-channel attacks.

https://arxiv.org/abs/1702.07521

 

CHIPSEC gets UEFI variable fuzzer

The module is fuzzing UEFI Variable interface. The module is using UEFI SetVariable interface to write new UEFI variables to SPI flash NVRAM with randomized name/attributes/GUID/data/size. Note: this module modifies contents of non-volatile SPI flash memory (UEFI Variable NVRAM). This may render system unbootable if firmware doesn’t properly handle variable update/delete operations.
 
Usage:
    “chipsec_main -m tools.uefi.uefivar_fuzz [-a <options>]“
    
Options:        
    “[-a <test>,<iterations>,<seed>,<test_case>]“
    – “test“        which UEFI variable interface to fuzz “(all, name, guid, attrib, data, size)“
    – “iterations“    number of tests to perform (default = 1000)
    – “seed“        RNG seed to use
    – “test_case“    test case # to skip to (combined with seed, can be used to skip to failing test)
    All module arguments are optional
    
Examples:
>>> chipsec_main.py -m tools.uefi.uefivar_fuzz
>>> chipsec_main.py -m tools.uefi.uefivar_fuzz -a all,100000
>>> chipsec_main.py -m tools.uefi.uefivar_fuzz -a data,1000,123456789
>>> chipsec_main.py -m tools.uefi.uefivar_fuzz -a name,1,123456789,94

https://github.com/chipsec/chipsec/blob/master/chipsec/modules/tools/uefi/uefivar_fuzz.py