Author: hucktech

Google NERF: Non-Extensible Reduced Firmware

~ hucktech ~ Leave a comment

 

Open Source Summit North America 2017
September 11-14, 2017 – Los Angeles, CA
Replace Your Exploit-Ridden Firmware with Linux – Ronald Minnich, Google

With the WikiLeaks release of the vault7 material, the security of the UEFI (Unified Extensible Firmware Interface) firmware used in most PCs and laptops is once again a concern. UEFI is a proprietary and closed-source operating system, with a codebase almost as large as the Linux kernel, that runs when the system is powered on and continues to run after it boots the OS (hence its designation as a โ€œRing -2 hypervisor”). It is a great place to hide exploits since it never stops running, and these exploits are undetectable by kernels and programs. Our answer to this is NERF (Non-Extensible Reduced Firmware), an open source software system developed at Google to replace almost all of UEFI firmware with a tiny Linux kernel and initramfs. The initramfs file system contains an init and command line utilities from the u-root project (http://u-root.tk/), which are written in the Go language.

https://ossna2017.sched.com/event/BCsr/replace-your-exploit-ridden-firmware-with-linux-ronald-minnich-google?iframe=no&w=100%&sidebar=yes&bg=no

https://www.linkedin.com/pulse/open-hardware-servers-step-forward-jean-marie-verdun

Click to access Denver_2017_coreboot_u-root.pdf

U-Root: firmware solution written in Go

https://linuxfr.org/news/un-pas-en-avant-pour-les-serveurs-libres-le-projet-nerf

Baidu releases SGX SDK for Rust

~ hucktech ~ Leave a comment

Rust SGX SDK, v0.2.0 Release

This Rust SGX SDK helps developers write Intel SGX enclaves in Rust programming language. We are proud to have our v0.2.0 Rust SGX SDK released. It is now providing more threading functions, thread local storages, exception handling routines and supports unwind mechanism, as well as support of LARGE ENCLAVE MEMORY with the help of Intel SGX v1.9 (31.75 GB enclave memory tested). Please refer to release notes for further details. And we are working on a white paper for technical details about this project.[…]

https://github.com/baidu/rust-sgx-sdk/releases/tag/v0.2.0

Porting UEFI to Apple PowerPC…

~ hucktech ~ 1 Comment

Porting UEFI to a new architecture:
So it turns out that blogging about something after the fact is pretty tough. I really wanted to blog about my PoC port of UEFI to the OpenPower ecosystem, but it’s incredibly difficult to go back and try to systematize something that’s been a few years back. So let’s try this again. This time, our victim will be a G4 12″ PowerBook6,8 with a 7447A. That’s a 32-bit PowerPC. Now, I’ll go in small steps and document everything. For added fun, we’ll begin porting on the target itself, at least until that gets too tedious. Also, I’ve a few OldWorld machines, a spare G4 12″ for parts and a G5, so hopefully this odyssey won’t be interrupted by old and failing hardware ;-). Keep in mind that each part is checked in along with the source code, so look at the entire commit. Each blog post will focus on the most important details.[…]

http://osdevnotes.blogspot.com/2017/07/porting-uefi-to-xxx-step-1.html
https://github.com/andreiw/ppcnw-edk2
https://github.com/andreiw/ppcnw-edk2/blob/master/PortingHowTo_p1.md

See-also:

Interview with Andrei Warkentin, OpenPOWER UEFI porter

Tianocore for OpenPOWER

 

CVE-2017-11472: Linux kernel ACPI KASLR vulnerability

~ hucktech ~ Leave a comment

The acpi_ns_terminate() function in drivers/acpi/acpica/nsutils.c in the Linux kernel before 4.12 does not flush the operand cache and causes a kernel stack dump, which allows local users to obtain sensitive information from kernel memory and bypass the KASLR protection mechanism (in the kernel through 4.9) via a crafted ACPI table.

[…]This causes a security threat because the old kernel (<= 4.9) shows memory locations of kernel functions in stack dump, therefore kernel ASLR can be neutralized. To fix ACPI operand leak for enhancing security, I made a patch which removes the ACPI_EXEC_APP define in acpi_ns_terminate() function for executing the deletion code unconditionally.[…]

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11472
https://nvd.nist.gov/vuln/detail/CVE-2017-11472
https://vuldb.com/?id.104315
https://github.com/acpica/acpica/commit/a23325b2e583556eae88ed3f764e457786bf4df6
https://github.com/torvalds/linux/commit/3b2d69114fefa474fca542e51119036dceb4aa6f

 

APT monitoring & analysis …below Ring 0

~ hucktech ~ Leave a comment

Applying Provenance in APT Monitoring and Analysis Practical Challenges for Scalable, Efficient and Trustworthy Distributed Provenance
Jenkinson G, Carata L, Bytheway T, Sohan R, Watson RNM, Anderson J, Kidney B, Strnad A, Thomas A, Neville-Neil G

[…] Below Ring 0 – hardware primitives can potentially support provenance capture in a number of ways. Trusted Computing primitives such as Intel SGX (Software Guard Extensions) can be used provide stronger non-repudiation (even in the presence of a compromised OS). And new hardware primitives could directly support provenance capture, for example providing an append only log for use by the kernel to store provenance records prior to sending over a network.[…]

https://www.usenix.org/conference/tapp17/workshop-program/presentation/jenkinson

Click to access tapp17_paper_jenkinson.pdf

https://www.researchgate.net/publication/317827922_Applying_Provenance_in_APT_Monitoring_and_Analysis_Practical_Challenges_for_Scalable_Efficient_and_Trustworthy_Distributed_Provenance

UEFI:NTFS

~ hucktech ~ Leave a comment

UEFI:NTFS is a generic bootloader, that is designed to allow boot from an NTFS partition, in pure UEFI mode, even if your system does not natively support it. This is primarily intended for use with Rufus, but can also be used independently. In other words, UEFI:NTFS is designed to remove the restriction, which most UEFI systems have, of only providing boot support from a FAT32 partition, and enable the ability to also boot from NTFS partitions. This can be used, for instance, to UEFI-boot a Windows NTFS installation media, containing an install.wim that is larger than 4 GB (something FAT32 cannot support) or to allow dual BIOS + UEFI boot of ‘Windows To Go’ drives. […] Secure Boot must be disabled for UEFI:NTFS to work.[…]

https://github.com/eventus77/uefi-ntfs-boot

http://efi.akeo.ie/
https://rufus.akeo.ie/

 

coreboot security slides from REcon available

~ hucktech ~ Leave a comment

Digging Into the Core of Boot by Yuriy Bulygin, Oleksandr Bazhaniuk

Click to access RECON-MTL-2017-DiggingIntoTheCoreOfBoot.pdf

https://recon.cx/2017/montreal/slides/

See-also the SGX talk…

KLEE 1.4.0 released

~ hucktech ~ Leave a comment

Cristian Cadar announced the 1.4.0 release of KLEE.

KLEE 1.4.0 is now available at
https://github.com/klee/klee/releases/tag/v1.4.0

Lots of new changes, in particular a new CMake build system, support forย  some missing features for LLVM 3.4 (and partial support for 3.5 andย  3.6), better support for MacOS, support for release documentation (as inย  http://klee.github.io/releases/docs/v1.4.0/) and many otherย  optimizations, features and bug fixes.[…]

Full announcement:
https://mailman.ic.ac.uk/mailman/listinfo/klee-dev
https://klee.github.io/

https://github.com/klee/klee

 

Shut the HAL Up: Isolating Android HALs

~ hucktech ~ Leave a comment

Shut the HAL Up
18 July 2017
Jeff Vander Stoep, Senior Software Engineer, Android Security

Updates are essential for security, but they can be difficult and expensive for device manufacturers. Project Treble is making updates easier by separating the underlying vendor implementation from the core Android framework. This modularization allows platform and vendor-provided components to be updated independently of each other. While easier and faster updates are awesome, Treble’s increased modularity is also designed to improve security. A Hardware Abstraction Layer (HAL) provides an interface between device-agnostic code and device-specific hardware implementations. HALs are commonly packaged as shared libraries loaded directly into the process that requires hardware interaction. Security boundaries are enforced at the process level. Therefore, loading the HAL into a process means that the HAL is running in the same security context as the process it’s loaded into.[…]

https://android-developers.googleblog.com/2017/07/shut-hal-up.html

TI on embedded SoC security

~ hucktech ~ Leave a comment

Where to Start with Embedded Processor Security
July 17th, 2017
By Amrit Mundra, Texas Instruments
The world runs on data, and every bit or byte is a potential target for attack. At the same time, both software and hardware systems are becoming much more complex, connected, and interdependent. And with complexity comes vulnerabilities. The billions or trillions of lines of code and interrelated hardware modules, subsystems, and partitionsโ€”all crammed on tiny slices of siliconโ€”are a hackerโ€™s delight.[…]

Figure 1: Security pyramid

 

 

http://eecatalog.com/chipdesign/2017/07/17/where-to-start-with-embedded-processor-security/

Quarkslab’s vulnerabilitries in NXP i.MX secure boot

~ hucktech ~ Leave a comment

 

Vulnerabilities in High Assurance Boot of NXP i.MX microprocessors
By Guillaume Delugrรฉ Ivรกn Arce

This blog post provides details about two vulnerabilities found by Quarkslab’s researchers Guillaume Delugrรฉ and Kรฉvin Szkudล‚apski in the secure boot feature of the i.MX family of application processors [1] built by NXP Semiconductors. The bugs allow an attacker to subvert the secure boot process to bypass code signature verification and load and execute arbitrary code on i.MX application processors that have the High Assurance Boot feature enabled. These bugs affect 12 i.MX processor families. The vulnerabilities were discovered and reported to the vendor in September 2016 and the technical details included in this blogpost were disclosed in a joint Quarkslab-NXP presentation at the Qualcomm Mobile Security Summit 2017 [2] in May 19th, 2017. National computer emergency response teams (CERTs) from 4 countries were informed about the issues in March, 2017. NXP has issued an Engineering Bulletin and two Errata documents (EB00854, ERR010872 and ERR0108873 respectively) [3] providing a brief description of both vulnerabilities, the list of affected processor models along with resolution plans and possible mitigations. In the rest of the blogpost we describe the relevant features in i.MX processors and the vulnerabilities affecting them.[…]InversePath, vendor of USB Armory [6], an affected device confirmed the vulnerabilities and developed proof of concept programs to demonstrate them.[…]

https://blog.quarkslab.com/vulnerabilities-in-high-assurance-boot-of-nxp-imx-microprocessors.html

https://labsblog.f-secure.com/2017/07/19/break-your-own-product-and-break-it-hard/

https://github.com/inversepath/usbarmory/blob/master/software/secure_boot/Security_Advisory-Ref_QBVR2017-0001.txt

Inception: hacking tool exploiting PCI-based DMA

~ hucktech ~ Leave a comment

Inception has been around since at least 2014, but I just noticed it. ๐Ÿ˜ฆ

Inception is a physical memory manipulation and hacking tool exploiting PCI-based DMA. The tool can attack over FireWire, Thunderbolt, ExpressCard, PC Card and any other PCI/PCIe interfaces. Inception aims to provide a relatively quick, stable and easy way of performing intrusive and non-intrusive memory hacks against live computers using DMA. Inceptionโ€™s modules work as follows: By presenting a Serial Bus Protocol 2 (SBP-2) unit directory to the victim machine over a IEEE1394 FireWire interface, the victim operating system thinks that a SBP-2 device has connected to the FireWire port. Since SBP-2 devices utilize Direct Memory Access (DMA) for fast, large bulk data transfers (e.g., FireWire hard drives and digital camcorders), the victim lowers its shields and enables DMA for the device. The tool now has full read/write access to the lower 4GB of RAM on the victim. Once DMA is granted, the tool proceeds to search through available memory pages for signatures at certain offsets in the operating systemโ€™s code. Once found, the tool manipulates this code. For instance, in the unlock module, the tool short circuits the operating systemโ€™s password authentication module that is triggered if an incorrect password is entered. […] However, vendors generally dismiss DMA attacks as a non-issue, which I hope that the awareness that this tool generates will change. Users deserve secure devices, even when attackers gain physical access.[…]

https://github.com/carmaa/inception
http://www.breaknenter.org/projects/inception/
http://www.breaknenter.org/2014/09/inception-metasploit-integration/

Triton 0.5 released

~ hucktech ~ Leave a comment

Triton is a Dynamic Binary Analysis (DBA) framework. It provides internal components like a Dynamic Symbolic Execution (DSE) engine, a Taint Engine, AST representations of the x86 and the x86-64 instructions set semantics, SMT simplification passes, an SMT Solver Interface and, the last but not least, Python bindings.

https://github.com/JonathanSalwan/Triton/milestone/8
https://github.com/JonathanSalwan/Triton
https://triton.quarkslab.com/
https://triton.quarkslab.com/documentation/doxygen/

Triton's architecture

ARM IETF ID on IoT firmware update architecture

~ hucktech ~ 1 Comment

IETF Internet draft: draft-moran-fud-architecture-00:

A Firmware Update Architecture for Internet of Things Devices
July 18, 2017
Brendan Moran, Milosch Meriac, Hannes Tschofenig
ARM Limited

Vulnerabilities with IoT devices have raised the need for a solid and secure firmware update mechanism that is also suitable for constrained devices. Incorporating such update mechanism to fix vulnerabilities, to update configuration settings as well as adding new functionality is recommended by security experts. This document specifies requires and an architecture for a firmware update mechanism aimed for Internet of Things (IoT) devices. The architecture is agnostic to the transport of the firmware images and associated meta-data. This version of the document assumes asymmetric cryptography and a public key infrastructure. Future versions may also describe a symmetric key approach for very constrained devices.

There’s a mailing list for FUD:

https://www1.ietf.org/mailman/listinfo/fud

https://tools.ietf.org/html/draft-moran-fud-architecture-00

PyREBox

~ hucktech ~ Leave a comment

PyREBox is a Python scriptable Reverse Engineering sandbox. It is based on QEMU, and its goal is to aid reverse engineering by providing dynamic analysis and debugging capabilities from a different perspective. PyREBox allows to inspect a running QEMU VM, modify its memory or registers, and to instrument its execution, by creating simple scripts in python to automate any kind of analysis. QEMU (when working as a whole-system-emulator) emulates a complete system (CPU, memory, devices…). By using VMI techniques, it does not require to perform any modification into the guest operating system, as it transparently retrieves information from its memory at run-time. Several academic projects such as DECAF, PANDA, S2E, or AVATAR, have previously leveraged QEMU based instrumentation to overcome reverse engineering tasks. These projects allow to write plugins in C/C++, and implement several advanced features such as dynamic taint analysis, symbolic execution, or even record and replay of execution traces. With PyREBox, we aim to apply this technology focusing on keeping the design simple, and on the usability of the system for threat analysts.

https://github.com/Cisco-Talos/pyrebox

Cisco on firmware malware

~ hucktech ~ Leave a comment

[…]Instead, security has to be comprehensive and pervasive on every network device (switches, routers, etc.) as hackers get more sophisticated and unpredictable and capable of exploiting both hardware and software vulnerabilities. These attackers, with cutting-edge techniques, can access memory chips, use tools to extract the contents of those chips and then use the content to build/configure systems to act as imposters on the customerโ€™s networrk. Bottom line โ€“ Malware can be installed on a router or switch. Are you protected ?[…]

https://blogs.cisco.com/datacenter/building-data-center-trustworthy-systems