New ebook: Platform Firmware Security Defense for Enterprise System Administrators and Blue Teams

Yesterday was SysAdmin Appreciation Day.

PreOS Security has a new free ebook, “Platform Firmware Security Defense for Enterprise System Administrators and Blue Teams”. If you’re new to firmware security issues, this gives an introduction. Advanced readers: there’s a feedback mechanism, so please give some feedback. There’s plans for an updated book.

https://preossec.com/

https://lists.preossec.com/mailman/listinfo/newsletter_lists.preossec.com

The book includes a snapshot of the awesome-firmware-security list as an appendix: https://github.com/PreOS-Security/awesome-firmware-security

Disclaimer: I work at PreOS Security, and helped with book. Paul did most of the work: thanks Paul!

 

UK Gov security guidance for Ubuntu, including Secure Boot

The UK government has guidance on secure usage of Ubuntu. It appears to be newly-written.

Lots of useful information, and it mentions that Secure Boot is only active at some time: nice to see that level of detail.

https://www.ncsc.gov.uk/guidance/eud-security-guidance-ubuntu-1804-lts

Secure Boot section:

Secure boot validates the bootloader, kernel and kernel modules. However, some boot-related files are not protected by default and could be modified by an attacker to tamper with the boot process. Hardening of the boot process can help mitigate the risk.

Ubuntu does not use any dedicated hardware to protect its disk encryption keys. If an attacker can get physical access to the device, they can perform an offline brute-force attack to recover the encryption password.

Encryption keys protecting sensitive data remain available to an attacker when the device is locked. This means that if the device is attacked while powered on and locked, keys and data on the device may be compromised without the attacker knowing the password.

Booting Secure [on Apple systems]

http://michaellynn.github.io/2018/07/27/booting-secure/

PS: A few articles on the new T2 processor as well:

https://www.computerworld.com/article/3290415/apple-mac/the-macbook-pro-s-t2-chip-boosts-enterprise-security.html

https://www.digitaltrends.com/computing/apple-t2-chip-brings-deeper-secuirty-to-macbook-pro/

The MacBook Pro’s T2 chip boosts enterprise security: Secure boot, even for Windows installations on a Mac

Required skills of a nation-state attacker/defender

I occasionally post interesting job postings from security firms or device makers. I usually avoid all of the US military-focused jobs, things that require secret clearance, etc. But there’s a LOT of military postings, a LOT more than the from the device makers and civilian security firms. Below are a few excerpts from a job posting from a US DOD contractor job description, if you’ve any doubt that firmware-level attacks are a thing or not, and what attack skills and tools are being considered, below job posting is fairly verbose. I really wish I knew how to track similar jobs from all governments, not just from US-based job sites, that would be fascinating to compare different state actors in this way.

OEMs: look at how governments are attacking your hardware, it isn’t just hobbyist hackers having fun on Twitter. Please make more secure hardware.

Excerpt from:

https://engility.taleo.net/careersection/ex/jobdetail.ftl?job=1811575&src=JB-10182

Senior Hardware Exploitation Engineer

Overseeing the reverse-engineering, failure analysis, and vulnerability analysis of hardware to identify exploitation opportunities

Leading the modification of hardware to either enable forensic analysis of the media or to change the functionality of the hardware for other purposes.

Managing a microelectronics exploitation laboratory, consisting of state-of-the-art tools for inspection, imaging; decapsulation, deprocessing, and other activities related to hardware-reverse engineering and exploitation

Directing the enhancement and maintenance of frameworks, processes, design patterns, techniques, tools, and standards for conducting hardware exploitation of digital media

Performing full-scope forensic examinations from the hardware aspect of media.

Employing reverse-engineering tools and methods to determine vulnerabilities of the device for technical exploitation purposes.

Determining how a device boots/initializes, and obtaining a binary that can be used for reverse engineering.

Leading teams and participating in the analysis of embedded platform firmware and operating systems to understand security vulnerabilities associated with various platform communication links

Leveraging knowledge gained through the reverse-engineering and other research techniques to enhance low-level C and assembly applications for embedded ARM platforms that interface directly with platform hardware

Reverse-engineering skills on embedded systems with proprietary operating systems for the express purpose of introducing functionally to an already existing fielded system.

Experience examining a hardware platform to understand the software and hardware interaction of embedded systems.

Experience with embedded system design, communication with peripheral devices at the hardware level, and reverse-engineering of system software.

Experience in Microprocessors/Architectures: ARM, MlPS, RISC, PowerPC, XScale, StrongARM, x86. Familiarity with microprocessor instruction sets is highly-desired.

Experience with the following Operating Systems: VxWorks, Integrity, Embedded Linux, JunOS, Linux, Unix, Windows Embedded. Experience with RTOS is highly-desired.

Experience using the following Hardware Tools and Debuggers: Green Hills Probe, SuperTrace Probe, Slingshot, spectrum analyzer, logic analyzer, JTAG, Agilent Technologies equipment.

Expliot gets SPIflashwrite plugin

Re: https://firmwaresecurity.com/2018/06/13/expliot-exploitation-framework/

https://gitlab.com/expliot_framework/expliot

NetSpectre

Click to access netspectre.pdf

Dynamic Binary Instrumentation Primer

The purpose of this post is to document my dive into the “world” of Dynamic Binary Instrumentation. I’ll cover some of the most well known and used DBI frameworks. That is Pin, DynamoRIO, and Frida. From these three I’ll mainly focus on Pin. There are other DBI frameworks that I won’t touch at all, like Valgrind, Triton (uses Pin), QDBI, BAP, Dyninst, plus many others. You might want to have a look at them. Some are more mature, some are less mature. Some have more features, some have fewer features. You’ll have to do some research yourself and see which ones fit your needs. Even though Valgrind is one of the most widely know, and used DBI frameworks, it’s only available for Linux. So, I won’t touch it at all.[…]

http://deniable.org/reversing/binary-instrumentation

 

 

I Know What You Did Last Month: A New Artifact of Execution on macOS 10.13

Analysts that perform macOS forensics have had few, if any, artifacts of program execution to rely on during investigations — until now. In macOS 10.13 (High Sierra), Apple introduced CoreAnalytics, which is a system diagnostics mechanism that maintains a record of Mach-O programs that have executed on a system over approximately one month. CoreAnalytics can serve a number of valuable analytical purposes for both insider threat investigations and incident response.[…]

https://www.crowdstrike.com/blog/i-know-what-you-did-last-month-a-new-artifact-of-execution-on-macos-10-13/

A collection of links to PDFs of papers on Micro-Architectural Side-Channel Attacks (sorted by date, going back to 1993)

See also:

https://github.com/danpage/mascab/

Spectre Returns! Speculation Attacks using the Return Stack Buffer

The recent Spectre attacks exploit speculative execution, a pervasively used feature of modern microprocessors, to allow the exfiltration of sensitive data across protection boundaries. In this paper, we introduce a new Spectre-class attack that we call SpectreRSB. In particular, rather than exploiting the branch predictor unit, SpectreRSB exploits the return stack buffer (RSB), a common predictor structure in modern CPUs used to predict return addresses. We show that both local attacks (within the same process such as Spectre 1) and attacks on SGX are possible by constructing proof of concept attacks. We also analyze additional types of the attack on the kernel or across address spaces and show that under some practical and widely used conditions they are possible. Importantly, none of the known defenses including Retpoline and Intel’s microcode patches stop all SpectreRSB attacks. We believe that future system developers should be aware of this vulnerability and consider it in developing defenses against speculation attacks. In particular, on Core-i7 Skylake and newer processors (but not on Intel’s Xeon processor line), a patch called RSB refilling is used to address a vulnerability when the RSB underfills; this defense interferes with SpectreRSB’s ability to launch attacks that switch into the kernel. We recommend that this patch should be used on all machines to protect against SpectreRSB.

https://arxiv.org/abs/1807.07940

NetBSD 8.0 released

Some General changes in latest NetBSD release:
* USB stack rework, USB3 support added.
* PaX MPROTECT (W^X) memory protection enforced by default on some architectures with fine-grained memory protection and suitable ELF formats: i386, amd64, evbarm, landisk.
* PaX ASLR (Address Space Layout Randomization) enabled by default on: i386, amd64, evbarm, landisk, sparc64.

Some Intel/AMD-centric changes:
* Meltdown mitigation: SVS (Separate Virtual Space), enabled by default.
* SpectreV2 mitigation: retpoline (support in gcc), used by default for kernels. Other hardware mitigations are also available.
* SpectreV4 mitigations available for Intel and AMD.
* PopSS workaround: user access to debug registers is turned off by default.
* Lazy FPU saving disabled on vulnerable Intel CPUs (“eagerfpu”).
* Improvement and hardening of the memory layout: W^X, fewer writable pages, better consistency, better performance.
* (U)EFI bootloader.

https://www.netbsd.org/releases/formal-8/NetBSD-8.0.html

http://netbsd.gw.com/cgi-bin/man-cgi?mcp3kadc+4.i386+NetBSD-8.0

http://blog.netbsd.org/tnf/entry/netbsd_8_0_released

https://wiki.netbsd.org/Installation_on_UEFI_systems/

Red Hat: SPECTRE Variant 1 scanning tool

As part of Red Hat’s commitment to product security we have developed a tool internally that can be used to scan for variant 1 SPECTRE vulnerabilities. As part of our commitment to the wider user community, we are introducing this tool via this article. […] The tool currently only supports the x86_64 and AArch64 architectures. We do hope to add additional architectures in the future.[…]

https://access.redhat.com/blogs/766093/posts/3510331

https://people.redhat.com/~nickc/Spectre_Scanner/scanner.tar.xz