Keyshuffling Attack for Persistent Early Code Execution in the Nintendo 3DS Secure Bootchain
We demonstrate an attack on the secure bootchain of the Nintendo 3DS in order to gain early code execution. The attack utilizes the block shuffling vulnerability of the ECB cipher mode to rearrange keys in the Nintendo 3DS’s encrypted keystore. Because the shuffled keys will deterministically decrypt the encrypted firmware binary to incorrect plaintext data and execute it, and because the device’s memory contents are kept between hard reboots, it is possible to reliably reach a branching instruction to a payload in memory. This payload, due to its execution by a privileged processor and its early execution, is able to extract the hash of hardware secrets necessary to decrypt the device’s encrypted keystore and set up a persistent exploit of the system.[…]
Month: April 2017
AMI and Gigabyte UEFI vulnerability
I wish more user-mode security researchers would study how OEM/IBV/OSV implementations of UEFI firmware update, from the OS-present appplication, looking for problems. For example: https://firmwaresecurity.com/2016/06/05/asus-liveupdate-of-uefi-sent-authenticated/
IoT security, AR, and VR
[…]On the subject of supply and demand leading to security issues, Ben Smith, CEO of Laduma, stated, “As new developments are rushed to market in order to gain a lead on competitors, there is a risk that mistakes are being made.” Because of the massive popularity that Virtual and Augmented Reality has gained in the last few years, companies were forced to either put out products that were not necessarily secure or forego their inclusion in the massive VR market of 2016. However, it is no surprise that the connection of multiple insecure devices on a network creates a perfect entry for hackers to retrieve the massive amounts of data which Virtual Reality platforms both receive from the users themselves as well as collect without necessary consent for marketing purposes. In fact, Tata Communication’s Srinivasan CR once stated on the subject, “Every device connecting into a network is a potential vulnerability which can be used to infiltrate the network itself and other devices connected to it.”[…]
Virtual and Augmented Reality: Transforming the Way We Look At the Internet and Data Security
Reversing ARM firmware using Radare: scripts/bins available
Re: https://firmwaresecurity.com/2017/03/31/reversing-arm-firmware-using-radare-presentation-available/
The samples for this presentation are also available. Previously, it was just the presentation PDF.
http://radare.org/get/r2snow.zip
Iaito: Radare2 GUI
Intel updates Minnowboard firmware, and Firmware Engine for Windows
Intel has updated their UEFI firmware for the Minnowboard, and has updated Intel Firmware Engine for Windows.
Encrypted Arch UEFI Installation guide
Arch Linux users might want to read this document.
An efficent method to achieve a properly encrypted, UEFI-booting, Arch Linux system. Multi-OS, and VirtualBox, UEFI booting are also supported. OBJECTIVE: Install Arch Linux with encrypted root and swap filesystems and boot from UEFI. Note: This method supports both dedicated Arch installs and those who wish to install Arch on a multi-OS-UEFI booting system. VirtualBox Installers Note: This installation method can also be used to install Arch Linux as an UEFI-booting Guest system in VirtualBox. You must have UEFI-booting enabled in VBox’s Guest System Settings prior to installation.[…]
https://github.com/HardenedArray/Encrypted-Arch-UEFI-Installation
rev.ng
USB Canary
“USB Canary: A Linux tool that uses pyudev to monitor devices while your computer is locked. In the case it detects someone plugging in or unplugging devices it can be configured to send you an SMS or alert you via Slack of the potential security breach.”
OEMs/IBVs aren’t enabling ECC config in boot menus
It looks like most vendors don’t have their boot menus updated to support the new ECC memory they now support…
[…]Once you have an ECC-enabled memory controller, a motherboard with the right traces, and a few sticks of ECC memory, the next step is whether the BIOS/UEFI properly supports ECC. This is where things start getting a little bit iffy. AMD placed all the responsibility for ECC support on the motherboard manufacturers, and they aren’t really willing to step up to the plate and assume that responsibility…you will find out why in the conclusion. As a result, while most motherboard manufacturers have now come to acknowledge that their motherboards are indeed ECC enabled, that is the extent of their involvement. Not one is offering an enable/disable option in the UEFI, and we haven’t seen anyone but ASRock and ASUS have any ECC settings available at the moment.
This lack of settings severely hampers the overall ECC functionality, since a big part of it is that the motherboard should be able to log errors. Right now, no such logging capability exists. Thankfully, there is a possible software solution. The operating system – if it fully supports this new AM4 platform – should have the ability to log errors and corrections. If it does not, the hardware might be silently correcting single-bit errors and even detecting ‘catastrophic’ two-bit errors, but you will never know about it since there will be no log. That’s what we are going to look into next.
To conclude this page, we strongly suspect that just about every AM4 motherboard likely has ECC enabled, or at the very least will in the future. Most motherboard manufacturers certainly aren’t actively supporting it, or even unlocking any of the features that accompany it, but they don’t appear to be maliciously disabling it either. At this point in time, they simply have other way more important things on their plate, like improving memory support, overclocking, ensuring that IOMMU is functional, etc. Furthermore, we strongly suspect that they are presently unable to unlock all of the necessary settings without a newer CPU microcode from AMD.
AMD on AGESA updates for Ryzen
AMD has a blog post on the Ryzen, and it talks about AGESA updates!
[…]Let’s talk BIOS updates:
Finally, we wanted to share with you our most recent work on the AMD Generic Encapsulated Software Architecture for AMD Ryzen™ processors. We call it the AGESA™ for short. As a brief primer, the AGESA is responsible for initializing AMD x86-64 processors during boot time, acting as something of a “nucleus” for the BIOS updates you receive for your motherboard. Motherboard vendors take the baseline capabilities of our AGESA releases and build on that infrastructure to create the files you download and flash. We will soon be distributing AGESA point release 1.0.0.4 to our motherboard partners. We expect BIOSes based on this AGESA to start hitting the public in early April, though specific dates will depend on the schedules and QA practices of your motherboard vendor. BIOSes based on this new code will have four important improvements for you:
* We have reduced DRAM latency by approximately 6ns. This can result in higher performance for latency-sensitive applications.
* We resolved a condition where an unusual FMA3 code sequence could cause a system hang.
* We resolved the “overclock sleep bug” where an incorrect CPU frequency could be reported after resuming from S3 sleep.
* AMD Ryzen™ Master no longer requires the High-Precision Event Timer (HPET).
We will continue to update you on future AGESA releases when they’re complete, and we’re already working hard to bring you a May release that focuses on overclocked DDR4 memory.[…]
https://community.amd.com/community/gaming/blog/2017/03/30/amd-ryzen-community-update-2
Intel NUC and Compute Stick: DCI unlocked
Intel® NUC and Intel® Compute Stick DCI Disable
Intel ID: INTEL-SA-00073
Product family: Intel® NUC and Intel® Compute Stick based on 6th Gen Intel® Core™ processors
Impact of vulnerability: Information Disclosure
Severity rating: Moderate
Original release: Apr 03, 2017
Last revised: Apr 03, 2017
Intel® NUC and Intel® Compute Stick systems based on 6th Gen Intel® Core™ processors do not have DCI debug capability properly locked for BIOS only access. This would allow an attacker with physical possession of the system to potentially enable DCI from outside the BIOS. Intel® Direct Connect Interface (DCI) provides closed chassis access to perform debug for processing OEM and OEM customer returns. DCI is was designed to be enabled only via BIOS settings. Current settings in the referenced product family BIOS may allow an attacker with physical access to the system and an NDA (non-disclosure agreement) controlled software stack from Intel to enable DCI from outside the BIOS. If an attacker were able to gain physical access to a system and enable DCI, it is possible they may gain access to personal information. Intel views this risk as a Moderate (4.7) due to physical access, NDA software stack, and high privileges being required by an attacker.[…]
https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00073&languageid=en-fr
bareBoot
bareBoot: A fork of Clover bootloader
For legacy BIOS computers only. No fancy graphics, no black automagic, no frills, no thrills, no bells & whistles. Bare “metal” aimed to get kernel running. The rest should be done by DSDT, kexts, …
macOS Security and Privacy Guide
If you are have an Apple system, here’s a guide to hardening macOS. Unlike most hardening guides, this one covers some aspects of firmware. I wish each OS vendor maintained a document like this.
https://github.com/drduh/macOS-Security-and-Privacy-Guide#firmware
AMD updates Programmer’s Manual
Last week, AMD updated “AMD64 Architecture Programmer’s Manual Volume 2: System Programming”. The changelog does not give a lot of information, you have to visit all the Tables/Sections to see what was changed:
Modified CR4 Register, Section 3.1.3.
Removed UD2 in Table 6-1.
Added new bullet in Section 7.1.1.
Modified Note in Table 7-1.
Added new Section 7.4.1.
Clarified Self Modifying Code in Section 7.6.1.
Added UD0 and UD1 instructions in Section 8.2.7.
Added Instructions Retired Performance counter in Section 13.1.1.
Modified Table in Section 15.34.9.
http://developer.amd.com/resources/developer-guides-manuals/
CIPSEC Project
Monitor for macOS
Introducing Monitor.app for macOS
March 31, 2017 | by Stephen Davis | Threat Research
As a malware analyst or systems programmer, having a suite of solid dynamic analysis tools is vital to being quick and effective. These tools enable us to understand malware capabilities and undocumented components of the operating system. One obvious tool that comes to mind is Procmon from the legendary Sysinternals Suite from Microsoft. Those tools only work on Windows though and we love macOS. macOS has some fantastic dynamic instrumentation software included with the operating system and Xcode. In the past, we have used dynamic instrumentation tools such as Dtrace, a very powerful tracing subsystem built into the core of macOS. While it is very powerful and efficient, it commonly required us to write D scripts to get the interesting bits. We wanted something simpler. Today, the Innovation and Custom Engineering (ICE) Applied Research team presents the public release of Monitor.app for macOS, a simple GUI application for monitoring common system events on a macOS host.[…]
https://www.fireeye.com/blog/threat-research/2017/03/introducing_monitor.html
PXE and UEFI HTTP Boot article
UEFI Firmware Rootkits: Myths and Reality
HardenedLinux’s Firmware Security
https://github.com/hardenedlinux/firmware-anatomy/blob/master/hack_ME/firmware_security.md
https://github.com/hardenedlinux/firmware-anatomy
Note to self: finish awesome-firmware markdown document and publish it!
Firmware Security 
You must be logged in to post a comment.