Insider Attack Resistance in the Android Ecosystem

https://twitter.com/rene_mobile/status/1099877929318641665

The threat model for a mobile device ecosystem is complex. In addition to the obvious physical attacks on lost or stolen devices and malicious code threats, typical mobile devices integrate a significant amount of code from different organizations into their system images, which are in turn executed on an increasingly complex hardware infrastructure. Both benign mistakes, as well as malicious attacks, could happen on any of these layers, by any of these organizations. Therefore, users as well as app developers and service providers currently have to trust every single one of these organizations. Note that OEMs (original equipment manufacturers) in their role as integrators typically verify their supply chain and components they integrate. However, there are also other parties in the full chain that can tamper with devices after they leave an OEM and before they are in the hands of users. Summarizing, many people could—by honest mistake or malicious intent—tamper with components of a modern smartphone to compromise user security. We call such attacks insider attacks, independently of the motivation or association of these insiders. The basic threat is that insiders have privileged access to some components during the manufacturing or update chain that would allow them to make modifications that third parties could not. This talk will introduce the complexity of the insider attack problem (which is not unique to Android) and introduce some defenses that have already been put in place. In Android, we counter such insider attacks on multiple levels and aim to remove or limit the capability of insiders to harm users, which implies the limiting required trust in many of the involved parties. At the secure hardware level, Android Pie 9.0 introduced insider attack resistance (IAR) for updates to tamper-resistant hardware such as secure elements that is used to validate the user knowledge factor in authentication and for deriving, storing, and using cryptographic key material. Even Google and the respective OEM are technically incapable of distributing modified firmware to such tamper-resistant hardware to exfiltrate user keys without their cooperation. On the system software level, some devices make the hash of their currently running firmware available for (anonymous) local and remote verification. The combination of these features already provide transparency on the system software level and severely limit the possibility of targeted attacks on firmware and system software levels. We continue to work on this problem, and this talk is partially a call to action for the security community to devise additional novel methods to mitigate against insider attacks on components in the mobile device landscape.

https://www.mayrhofer.eu.org/talk/enigma2009/

Click to access enigma2019.pdf

Simple-UEFI-Bootloader:  UEFI bootloader for bare-metal x86-64 applications, including a minimal cross-platform UEFI development environment

This bootloader is like a much simpler version of GRUB/Elilo/Windows Boot Manager, but mainly meant for writing your own operating system-less 64-bit programs, kernels, or full operating systems. It supports Windows, Linux, and Mac executable binaries (PE32+, 64-bit ELF, and 64-bit Mach-O formats). It also supports… Well, I’ll let you figure that one out yourself. 😉 […]

https://github.com/KNNSpeed/Simple-UEFI-Bootloader

See-also:

https://github.com/KNNSpeed/Simple-Kernel/

Chipsec-based integration tests for the Bareflank Hypervisor

Re: https://firmwaresecurity.com/2019/01/14/bareflanks-hypervisor-lightweight-hypervisor-sdk-written-in-c-with-support-for-windows-linux-and-uefi/

This repository contains a Bareflank extension that aims to prove-out the concept of using chipsec as an integration testing tool for Bareflank-based VMMs. The chipsec_modules directory contains python modules for the Chipsec framework. Each module represents one integration test that verifies a specific behaviour of a loaded VMM.[…]

https://github.com/JaredWright/chipsec_integration_tests

https://github.com/Bareflank/hypervisor

BareflankLovesChipsec

 

Get-USBHistory: get history of a USB flash driving using PowerShell

https://gallery.technet.microsoft.com/scriptcenter/Get-USBHistory-707e43a3

Use PowerShell to Find the History of USB Flash Drive Usage

Fedora: Flicker Free Boot

Fedora 30 now contains all changes changes for a fully Flicker Free Boot. Last week a new version of plymouth landed which implements the new theme for this and also includes a much improved offline-updates experience, following this design. At boot the display will seamlessly transit from the firmware boot-splash into the new plymouth theme, which uses the firmware boot-splash as background[…]

https://fedoraproject.org/wiki/Changes/FlickerFreeBoot

https://hansdegoede.livejournal.com/20119.html

UEFI Forum webinar: Secure Coding

The inherent nature of firmware makes it an appealing target for hackers as the hardening of traditional exploit vectors (e.g., operating systems and the applications) is leading to new routes of attack. Join the UEFI Forum Secure Coding webinar to hear the panel of security experts discuss tips and best practices.

Moderator:
Brian Richardson, Intel Corporation

Panelists:
Dick Wilkins, Phoenix Technologies
Trevor Western, Insyde Software
Eric Johnson, American Megatrends Inc.

https://register.gotowebinar.com/register/8562801240869758977

https://uefi.org/

nanoBench: A tool for running small microbenchmarks on recent Intel and AMD x86 CPUs.

Re: https://firmwaresecurity.com/2018/11/04/upos-info-latency-throughput-and-port-usage-information-for-instructions-on-recent-intel-microarchitectures/

nanoBench is a Linux-based tool for running small microbenchmarks on recent Intel and AMD x86 CPUs. The microbenchmarks are evaluated using hardware performance counters. The reading of the performance counters is implemented in a way that incurs only minimal overhead. There are two variants of the tool: A user-space implementation and a kernel module. The kernel module makes it possible to benchmark privileged instructions, and it can allow for more accurate measurement results as it disables interrupts and preemptions during measurements. The disadvantage of the kernel module compared to the user-space variant is that it is quite risky to allow arbitrary code to be executed in kernel space. Therefore, the kernel module should not be used on a production system. nanoBench is used for running the microbenchmarks for obtaining the latency, throughput, and port usage data that is available on uops.info.

https://github.com/andreas-abel/nanoBench

http://uops.info/

RAVENS: Resilient Architecture for Very Efficient firmware updates of Network-connected Systems

RAVENS (Resilient Architecture for Very Efficient firmware updates of Network-connected Systems) is a software ecosystem built on top of two main components, Hugin and Munin. […] Properly used, Hugin and Munin enable secure and efficient firmware updates of very small IoT devices.

https://github.com/Orange-OpenSource/RAVENS

 

mesos: a simple, debugger-based code coverage and crash monitoring harness

Mesos is a tool to gather binary code coverage on all user-land Windows targets without need for source or recompilation. It also provides an automatic mechanism to save a full minidump of a process if it crashes under mesos. Mesos is technically just a really fast debugger, capable of handling tens of millions of breakpoints. Using this debugger, we apply breakpoints to every single basic block in a program. These breakpoints are removed as they are hit. Thus, mesos converges to 0-cost coverage as gathering coverage only has a cost the first time the basic block is hit.

https://github.com/gamozolabs/mesos

CmpCov – an instrumentation module for clang/SanitizerCoverage

CompareCoverage (CmpCov in short) is a simple instrumentation module for C/C++ programs and libraries, which extracts information about data comparisons taking place in the code at run time, and saves it to disk in the form of standard .sancov files. It is based on the SanitizerCoverage instrumentation available in the clang compiler, which itself is tightly related to AddressSanitizer. Specifically, the library implements the instrumentation callbacks defined by the Tracing data flow feature of SanitizerCoverage.

https://github.com/googleprojectzero/CompareCoverage

The Intel 80386, part 17: Future developments

Re: https://firmwaresecurity.com/2019/01/22/raymond-chen-the-intel-80386-blog-series/

https://blogs.msdn.microsoft.com/oldnewthing/20190212-00/?p=100915

Wow, this new blog series is up to 17-parts now!