[General Questions and Answers] YuriRM:
BootStomp + DUAL RECOVERY for locked BOOTLOADER + Reverse Engineering Xiaomi OTA

[MENTION=5922272]Rafostar[/MENTION]

Can we use these concepts and BootStomp ?

A test on Nvidia Tegra K1 with 6 seeds and 1 sink reveals 12 Entry Points, performing 7 loops and returning 1 zero-day bug in under 25 minutes (see Table 2, eight attached images at the bottom, read the Redini PDF).

"The particular vulnerabilities found consisted mostly of memory corruption and privilege escalation bugs, including a part of NVIDIA’s bootloader code that could end up becoming user-accessible under the right OS conditions, as one example. Essentially, most of the vulnerabilities would either unlock the bootloader, preventing it from enforcing key security policies, or hand over control of key processes to the user privilege level. Tests were inconclusive on MediaTek hardware due to the bootloader’s unique structure, while an older Qualcomm bootloader fell victim to a known old bug, and the NVIDIA bootloader was only found to be vulnerable to the aforementioned privilege escalation bug. "

"NVIDIA’s Tegra-based devices ship with a bootloader known as hboot. This bootloader is very similar to Qualcomm’s, in that it runs at EL1, and implements only the fastboot functionality at this stage. BOOTSTOMP also discovered a vulnerability in NVIDIA’s hboot. hboot operates at EL1, meaning that it has equivalent privilege on the hardware as the Linux kernel, although it exists earlier in the Chain of Trust, and therefore its compromise can lead to an attacker gaining persistence. We have reported the vulnerability to NVIDIA, and we are working with them on a fix. Our tool did not identify any path to non-volatile storage for the NVIDIA’s or MediaTek’s bootloaders. Upon manual investigation, we discovered that these two bootloaders both make use of memory-mapped I/O to write the value, which could map to anything from the flash to special tamper-resistant hardware. Thus, we cannot exclude the presence of vulnerabilities."

EDIT - Should we challenge this BootStomp team at the University of California or instead Roee Hay (Aleph Research, a team of ex-IBM researchers) to defeat sealime in all Toshiba tablets? He has achieved amazing exploits even on Nvidia Tegra K1 (Nexus 9).

EDIT - We must run BootStomp on Nvidia Tegra 4 (T114) to uncover vulnerabilities that may be different. It is an older SoC than Nvidia Tegra K1. Are you able to perfom the BootStomp test?

1 - BootStomp: Find Mobile Device Bootloader Vulnerabilities

http://pentestit.com/bootstomp-find-mobile-device-bootloader-vulnerabilities/

Oh boy! This post is going to be interesting as it is about an interesting topic – mobile bootloaders. Specifically, this post is about BootStomp, which helps you find vulnerabilities in the bootloader. All of us know; as the name suggests, that bootloader is a program loads the operating system. It does so by accessing the non-volatile memory to load the operating system into the RAM. You also might be aware that bootloaders come in two flavours – digitally locked and unlocked.

A locked bootloader only allows authorized operating systems with a digital signature to be loaded. Unlocked bootloaders do not verify digital signatures before loading the software.

What is BootStomp?

With the above mentioned information, it must be now clear as to why it is an important part of any operating system. Now, let’s get on the to meaty part about this open source tool in Python. BootStomp uses a combination of static analysis and dynamic symbolic execution engines to build a taint analysis system, that is capable of identifying bootloader vulnerabilities. It aims to ﬁnd following classes of vulnerabilities:

- Memory corruption vulnerabilities.

- Insecure state storage vulnerabilities.

It depends on the able IDA Pro debugger to help debug the bootloader and the results are then presented to you for further analysis and research. At the core of BootStomp, is a taint analysis engine, which tracks the ﬂow of data within a program that searches for paths within the program where an attacker will be possibly able to inﬂuence a sensitive memory operation. You are alerted for each such potentially vulnerable paths. BootStomp is already market tested, as using this tool, the authors were able to discover vulnerabilities in the following devices:

HuaweiP8ALE-L23(Huawei/HiSiliconchipset)

Sony Xperia XA (MediaTek chipset)

Nexus 9 (NVIDIA Tegra chipset)

An un-named Qualcomm Little Kernel based device

Keep in mind that this is not your click and forget kinds. You need to be able to correctly configure it and understand the output you get from BootStomp. In addition to the project, the authors have also been kind enough to include a few of their tools that can be used to work with the bootloaders like bootsplitter.py which is used to split the extracted aboot.img into IDA loadable binary. Python scripts specific to the Huawei P8 are also included. They help you perform the following:

dump_nvme.py – used to dump the contents of nvme.img (/dev/block/platform/hi_mci.0/by-name/nvme

dump_oeminfo.py – used to dump the contents of oeminfo.img (/dev/block/platform/hi_mci.0/by-name/oeminfo

oeminfo_exploit.py – create an exploit oeminfo image for Huawei P8 Lite phones, so that if you flash this back you could perform stack buffer overflow

Download BootStomp:

This open source bootloader vulnerability finding tool can be checked out from its GitHub repository. Additionally, there is a technical paper (bootstomp.pdf) published by the authors, which can be found here.

2 - BootStomp: On the Security of Bootloaders in Mobile Devices

https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/redini

Redini PDF

https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-redini.pdf

GitHub - BootStomp: a bootloader vulnerability finder

https://github.com/ucsb-seclab/BootStomp

3 - DUAL RECOVERY for locked BOOTLOADER

https://xdaforums.com/showthread.php?t=2261606

Announcement from [NUT]: The installer contains a ROOT EXPLOIT, this will trip A/V tools (e.g. ESET NOD32), disable it to download!!

-=[XZDualRecovery]=-

TWRP 2.8.7.0 & PhilZ Touch 6.59.0

*** For Locked and Unlocked BOOTLOADERS! ***

I proudly present you the first and only DUAL RECOVERY for locked boot loaders on our lovely Xperia phones!

If you have an unlocked bootloader and chose to keep the STOCK Sony kernel, you can also use this MOD.

4 - Reverse Engineering Xiaomi OTA Updates to Find Unreleased Updates

https://www.xda-developers.com/reverse-engineering-xiaomi-ota-updates/

In an attempt to gain access to Xiaomi‘s nightlies—the unreleased, in-house versions of Xiaomi’s MIUI operating system — XDA Senior Member duraaraa reverse-engineer the China-based company’s over-the-air (OTA) update framework. The two work-in-progress exploits force Xiaomi devices to pull a nightly build instead of the latest commercial firmware, which in theory could be installed on off-the-shelf devices if (1) MIUI’s OTA application was reverse engineered and (2) the test builds were signed with the same keys as the official builds.

5 - OnePlus OTAs: Analysis & Exploitation

By Roee Hay (@roeehay)

May 11, 2017 * CVE-2017-5948; CVE-2017-8850; CVE-2017-8851; CVE-2016-10370

https://alephsecurity.com/2017/05/11/oneplus-ota/

In this blog post we present new trivial vulnerabilities found on OnePlus One/X/2/3/3T OxygenOS & HydrogenOS. They affect the latest versions (4.1.3/3.0) and below. The vulnerabilities allow for a Man-in-the-Middle (MitM) attacker to intervene in the OTA update process in order downgrade OxygenOS/HydrogenOS to older versions and even to replace OxygenOS with HydrogenOS (and vice versa), both without a factory reset, allowing for exploitation of now-patched vulnerabilities. Moreover, the OnePlus X ROM can be installed over OnePlus One and vice versa, leading to Denial-of-Service. In addition, the vulnerabilities can also be exploited by physical attackers allowing for easy exploitation of some of the vulnerabilities we previously disclosed.

6 - (Nvidia Tegra K1) - Attacking Nexus 9 with Malicious Headphones

By Roee Hay (@roeehay)

March 8, 2017 * CVE-2017-0510; CVE-2017-0563; CVE-2017-0582

In the March 2017 Android Security Bulletin, Google released a patch to CVE-2017-0510, a critical severity vulnerability in Nexus 9 we discovered and responsiblity disclosed a few months ago. This vulnerability has a very unusual attack vector – headphones. By exploiting this vulnerability we managed to leak stack canaries, derandomize ASLR, conduct a factory reset, and even access HBOOT, allowing for communication with internal System-on-Chips (SoCs) through I2C.

7 - (Nvidia Tegra K1) - Nexus 9 vs. Malicious Headphones, Take Two

By Roee Hay (@roeehay)

June 13, 2017 * CVE-2017-0648; CVE-2017-0510; CVE-2017-0563; CVE-2017-0582

In March 2017 we disclosed CVE-2017-0510, a critical vulnerability in Nexus 9, that allowed for quite unique an attack by malicious headphones. Interestingly, its patch was insufficient. We had responsibly reported that finding (CVE-2017-0648) to Google, that patched it in the June 2017 Android Security Bulletin.

In this blog post we will begin with a short recap of CVE-2017-0510, analyze why its original patch is insufficient (CVE-2017-0648), and demonstrate a sample attack against it. We will end by presenting CVE-2017-0648’s patch, which seems to completely block the attack.

8 - Going Inside an Arbitrary Kernel Write Vulnerability in the Nexus 9 (CVE-2016-3873)

https://securityintelligence.com/go...ry-kernel-write-vulnerability-in-the-nexus-9/

The IBM X-Force Application Security Research Team recently discovered an arbitrary write vulnerability in Nexus 9’s kernel (the Tegra kernel branch). Google’s Android Security Team acknowledged the vulnerability, which allows a privileged attacker to arbitrary write values within kernel space, and assigned it a high severity rating.

Kernel arbitrary write primitives can be used to achieve kernel code execution, which completely compromises the security of the device, not including TrustZone. It increases the TrustZone attack surface and allows attackers to access application data and override the Security-Enhanced Linux (SELinux) policy.

9 - 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.

10 - Aleph Research (by Roee Hay)

Security Research by HCL Technologies

https://alephsecurity.com/

[MENTION=5922272]Rafostar[/MENTION] should we challenge Roee Hay to defeat sealime in all Toshiba tablets?

11 - [Update: OnePlus Responds] OnePlus Accidentally Pre-Installed an App that acts as a Backdoor to Root Access

https://www.xda-developers.com/oneplus-root-access-backdoor/