Android: Untethered initroot

Untethered initroot (USENIX WOOT ’17)
By Roee Hay (@roeehay)
August 30, 2017
CVE-2016-10277 ALEPH-2017024

In USENIX WOOT ‘17, that took place earlier this month in Vancouver, we presented our paper, “fastboot oem vuln: Android Bootloader Vulnerabilities in Vendor Customizations”, covering a year’s work in Android bootloaders research. Our paper also includes some previously undisclosed details on CVE-2016-10277, a critical kernel command-line injection vulnerability in the Motorola Android Bootloader (ABOOT) that we had found and blogged about. In the previous couple of blog posts, we demonstrated a tethered unrestricted root exploit against that vulnerability, that we later extended to other Moto devices – G4 & G5. Additional Moto devices have also been confirmed by the community. In the WOOT’17 paper we describe a natural continuation of that exploit – a second stage untethered secure boot & device locking bypass (tested to be working on the vulnerable versions of Nexus 6, Moto G4 & G5). Moreover, we also present in the paper and this blog post other second stage exploits, such as persistent kernel code execution in Nexus 6, the ability to downgrade critical partitions (such as the bootloaders chain and TrustZone), unlocking a re-locked Nexus 6 bootloader, and more. As usual, our PoC exploit is publicly available in our GitHub repo. DISCLAIMER: Unlike the previous ephemeral jailbreak, the one presented today may brick your device. For example, during the development of it, we had to unlock our (luckily unlockable!) Moto G5 device in order to unbrick it.[…]

Android Oreo docs on keymaster3 and HIDL

In Android 8.0, Keymaster 3 transitioned from the old-style C-structure Hardware Abstraction Layer (HAL) to the C++ HAL interface generated from a definition in the new Hardware Interface Definition Language (HIDL). As part of the change, many of the argument types changed, though types and methods have a one-to-one correspondence with the old types and the HAL struct methods.[…]

Android Oreo Verified Boot’s Rollback Protection

This flew under our radar back at I/O, but it’s big news. On compatible devices, the new Verified Boot changes in Android 8.0 Oreo will prevent a device from booting should it be rolled back to an earlier firmware. The new feature is called Rollback Protection. So if your phone is flashed with older software, you (and your data) are protected from whatever potential security vulnerabilities may have been present in earlier versions. For 99% of users, the new Rollback Protection is great news. If a phone is lost or stolen, it further decreases the number of potential attacks which could be used to gain access, providing better safety for your data.[…]


Collabora: Changing the Android boot animation

Quick hack: Changing the Android boot animation

Posted on 21/04/2017 by Robert Foss

For various reasons you might want to change the Android boot animation to something other than the stock one, this is how you do it. There exists official documentation for how to create a custom boot animation, but unfortunately it is lacking in actual examples. So this guide is a bit more hands-on. Without covering too much of the same gound as the documentation, let’s have a quick look at what is in a simple[…]

Huawei boot loader vulnerability

3 boot loader/smartphone security vulnerabilities from Huawei. Text of two and links to all 3 are below:

Security Advisory – Out-of-Bounds Memory Access Vulnerability in the Boot Loaders of Huawei Mobile Phones
SA No:huawei-sa-20170816-01-smartphone
Initial Release Date: 2017-08-16
The boot loaders of some Huawei mobile phones have an out-of-bounds memory access vulnerability due to the lack of parameter validation. An attacker with the root privilege of an Android system may trick a user into installing a malicious APP. The APP can modify specific data to cause buffer overflow in the next system reboot, causing out-of-bounds memory read which can continuous system reboot. (Vulnerability ID: HWPSIRT-2017-01070)
This vulnerability has been assigned a CVE ID: CVE-2017-8149. Huawei has released software updates to fix this vulnerability. Successful exploit could cause out-of-bounds memory read, leading to continuous system reboot.
This vulnerability can be exploited only when the following conditions are present: 1) The attacker has gained the root privilege of an Android system and successfully tricked a user into installing the malicious APP. 2) An attacker with the root privilege of an Android system may trick a user into installing a malicious APP. The APP can modify specific data to cause out-of-bounds memory read, leading to continuous system reboot. This vulnerability was reported to Huawei PSIRT by Aravind, Machiry. Huawei would like to thank Aravind, Machiry for working with us and coordinated vulnerability disclosure to protect our customers.[…]

Security Advisory – Authentication Bypass Vulnerability in Huawei Honor 5S Smart Phones
SA No:huawei-sa-20170816-03-smartphone
Initial Release Date: 2017-08-16
Huawei Honor 5S smart phones have an authentication bypass vulnerability due to the improper design of some components. An attacker can get a user’s smart phone and install malicious apps in the mobile phone, allowing the attacker to reset the password and fingerprint of the phone without authentication. (Vulnerability ID: HWPSIRT-2017-07037). This vulnerability has been assigned a CVE ID: CVE-2017-8151. Huawei has released software updates to fix this vulnerability. Successful exploit could allow the attacker to reset the password and fingerprint of the phone. This vulnerability can be exploited only when the following conditions are present: 1) The attacker obtains a user’s smart phone in unlocked state. An attacker can get a user’s smart phone and install malicious apps in the mobile phone, allowing the attacker to reset the password and fingerprint of the phone without authentication. This vulnerability was reported to Huawei PSIRT by security researcher Zhang Qing. Huawei would like to thank Zhang Qing for working with us and coordinated vulnerability disclosure to protect our customers.


Android 8.0 (“Oreo”) security changes


The Android boot process

The Android boot process
Punya Vashist

[…] Android, by the looks of it, seems to be a simplistic Operating System. However, in contrast, the processes and functions that add up to the OS a majority of the smartphone consumer uses are a lot more complex. The boot process, for starters, is nothing but a bunch of fancy images and animations for the end user. This post aims at breaking the boot process down for those very end users. And I promise a thorough read is all you need to understand the process. Nothing is too complicated if explained the right way.[…]

SELinux Switch for Android

The SELinux Switch is a New Tool for Toggling SELinux Between Enforcing and Permissive
by Doug Lynch
Some applications and modifications for Android require that SELinux be set to Permissive instead of Enforcing. Many who want this on their phone or tablet likely know of an alternative called SELinuxModeChanger or The SELinux Toggler. So XDA Senior Member Ibuprophen came out with a new tool called The SELinux Switch that lets you change a device’s SELinux state without having to permanently modify the boot script files. So your device will still boot with SELinux in Enforcing mode, but will then automatically launch and change the devices SELinux Mode after the boot process is completed.[…]


BootStomp: Android bootloader vulnerability finder

BootStomp is a boot-loader bug finder. It looks for two different class of bugs: memory corruption and state storage vulnerabilities. For more info please refer to the BootStomp paper. To run BootStomp’s analyses, please read the following instructions. Note that BootStomp works with boot-loaders compiled for ARM architectures (32 and 64 bits both) and that results might slightly vary depending on angr and Z3’s versions. This is because of the time angr takes to analyze basic blocks and to Z3’s expression concretization results.[…]

print [!] Usage: + sys.argv[0] + <oeminfo.img> <exploit_oeminfo.img>\n

Lots of links to read at the end of the github readme web page.


Roee Hay’s abootool: fuzzer for Android bootloader

fastboot oem vuln: Android Bootloader Vulnerabilities in Vendor Customizations:
We discuss the fastboot interface of the Android bootloader, an area of fragmentation in Android devices. We then present a variety of vulnerabilities we have found across multiple Android devices. Most notable ones include Secure Boot & Device Locking bypasses in the Motorola and OnePlus 3/3T bootloaders. Another critical flaw in OnePlus 3/3T enables easy attacks by malicious chargers – the only prerequisite is a powered-off device to be connected. An unexpected attack vector in Nexus 9 is also shown – malicious headphones. Other discovered weaknesses allow for data exfiltration (including a memory dumping of a Nexus 5X device), enablement of hidden functionality such as access to the device’s modem diagnostics and AT interfaces , and attacks against internal System-on-Chips (SoCs) found on the Nexus 9 board.

abootool: Simple fuzzer for discovering hidden fastboot gems. Modus Operandi: Based on static knowledge (strings fetched from available bootloader images), dynamically fuzz for hidden fastboot OEM commands.


Dorian Cussen’s Android Security Reference

I just noticed this Android Security Reference. It has a few pages on boot phase:

Aleph Security: Secure Boot vuln in Qualcomm OnePlus 2

OnePlus 2 Lack of SBL1 Validation Broken Secure Boot
Aleph Research Advisory

OnePlus 2 (a 2015 Qualcomm Snapdragon 810 device) successfully boots with a tampered Secondary Bootloader (sbl1) partition although it is digitally-signed, hence it is not validated by its Primary Bootloader (PBL), maybe due to lenient hardware configuration. Attackers capable of tampering with the sbl1 partition can then disable the signature validation of the rest of the bootloader chain and other SBL-validated partitions such as TrustZone and ABOOT.[…]



Trust Issues: Exploiting TrustZone TEEs

by Gal Beniamini, Project Zero

Mobile devices are becoming an increasingly privacy-sensitive platform. Nowadays, devices process a wide range of personal and private information of a sensitive nature, such as biometric identifiers, payment data and cryptographic keys. Additionally, modern content protection schemes demand a high degree of confidentiality, requiring stricter guarantees than those offered by the “regular” operating system. In response to these use-cases and more, mobile device manufacturers have opted for the creation of a “Trusted Execution Environment” (TEE), which can be used to safeguard the information processed within it. In the Android ecosystem, two major TEE implementations exist – Qualcomm’s QSEE and Trustonic’s Kinibi (formerly <t-base). Both of these implementations rely on ARM TrustZone security extensions in order to facilitate a small “secure” operating system, within which “Trusted Applications” (TAs) may be executed. In this blog post we’ll explore the security properties of the two major TEEs present on Android devices. We’ll see how, despite their highly sensitive vantage point, these operating systems currently lag behind modern operating systems in terms of security mitigations and practices. Additionally, we’ll discover and exploit a major design issue which affects the security of most devices utilising both platforms. Lastly, we’ll see why the integrity of TEEs is crucial to the overall security of the device, making a case for the need to increase their defences. […]

Shut the HAL Up: Isolating Android HALs

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.[…]

Reverse Engineering Samsung S6 SBOOT – Part II

Reverse Engineering Samsung S6 SBOOT – Part II
By Fernand Lone Sang

In my previous article, I explained how to load Samsung’s proprietary bootloader SBOOT into IDA Pro. The journey to the TEE OS continues in this second article which describes two techniques to locate Trustonic’s TEE <t-base in the binary blob. A few months back, I started digging into various TEE implementations and that led me to reverse engineer Samsung’s proprietary bootloader SBOOT [1]. At that time, I suspected that the Trustonic’s TEE <t-base was somehow embedded in the bootloader’s image of Exynos-based smartphones, and it turned out that my assumptions were good. Back then, I used two techniques to locate <t-base in SBOOT but I did not find enough time to cleanup my notes and blog about it until now. This article describes the two techniques I used.[…]

initroot: Bypassing Nexus 6 Secure Boot through Kernel Command-line Injection

initroot: Bypassing Nexus 6 Secure Boot through Kernel Command-line Injection
By Roee Hay (@roeehay)
In the May 2017 Android Security Bulletin, Google released a patch to a critical and unique vulnerability CVE-2016-10277 in the Nexus 6 bootloader we had found and responsibly disclosed. By exploiting the vulnerability, a physical adversary or one with authorized-ADB/fastboot USB access to the (bootloader-locked) device (such as PC malware awaiting for an ADB-authorized developer’s device to be hooked via USB) could break the Secure/Verified Boot mechanism, allowing him to gain unrestricted root privileges, and completely own the user space (which may also lead much more), by loading a tampered or malicious initramfs image. Moreover, exploitation does not lead to a factory reset hence user data remains intact (and still encrypted). It should be noted that we do not demonstrate an untethered attack. During this research we also uncovered a 18-year-old Linux Kernel bug (not affecting Nexus 6 and probably does not affect any Android device): CVE-2017-1000363[…]

Signing boot images for Android Verified Boot

Signing boot images for Android Verified Boot (AVB)
Various Android devices support Android Verified Boot (AVB). A part of this is more commonly known as dm-verity, which verifies system (and vendor) partition integrity. AVB can however also verify boot images, and stock firmwares generally include signed boot images. Of course this does not mean that all signed boot images are using AVB, many OEMs have their own signature verification scheme. Note: AOSP is moving towards the use of avbtool (taken from Brillo), the following is the old way for signing boot images. Bootloaders might or might not accept unsigned boot images, and might or might not accept boot images signed with our own keys (rather than the OEM’s keys). This depends on the device, bootloader version, and bootloader unlock state. For example, with the bootloader unlocked, the Google Pixel (and XL) devices accepted unsigned boot images up to (but not including) the May 2017 release. From the May 2017 release onwards, the boot images must be signed if flashed (booted works without), but may be signed with your own key rather than the OEM’s. Note: The situation changes when you re-lock the bootloader. I have not tested this, but documentation implies that (one of) the keys used in the current boot image must be used for future flashes until it is unlocked again.[…]

More Info:


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.[…]