Android Things

Supported hardware: Intel® Edison, Intel® Joule, NXP Pico i.MX6UL, Raspberry Pi

https://github.com/androidthings
https://developer.android.com/things/hardware/index.html
https://developer.android.com/things/index.html
https://developer.android.com/things/preview/index.html
https://developer.android.com/things/hardware/developer-kits.html
https://android-developers.googleblog.com/2017/02/android-things-developer-preview-2.html

 

 

OnePlus bootloader vulnerabilities

 

Owning a Locked OnePlus 3/3T: Bootloader Vulnerabilities
Feb 08, 2017 • Roee Hay
In this blog post I disclose two vulnerabilities in the OnePlus 3/3T bootloader. The first one, CVE-2017-5626, is a critical severity vulnerability affecting OxygenOS 3.2-4.0.1 (4.0.2 is patched). The vulnerability allows for a physical adversary (or one with ADB/fastboot access) to bypass the bootloader’s lock state, even when Allow OEM Unlocking is disabled, without user confirmation and without triggering a factory reset. This vulnerability allows for kernel code execution (albeit with a 5 seconds warning upon boot). The second vulnerability, CVE-2017-5624, affecting all versions of OxygenOS to date (Feb 10 UPDATE: OxygenOS 4.0.3, released Feb 09, seems to be patched), allows the attacker to disable dm-verity. The combination of the vulnerabilities enables a powerful attack – persistent highly privileged code execution without any warning to the user and with access to the original user’s data (after the victim enters his credentials). Both issues were responsibly disclosed to and acknowledged by OnePlus Security. The first vulnerability, CVE-2017-5626, was reported on January 23rd. It was also found independently by a OnePlus engineer. CVE-2017-5624, reported on January 16th, should be fixed in a future OxygenOS release – the reason for its today’s public disclosure is because someone already published it on January 24th. Disclaimer: I tested the vulnerabilities on OnePlus 3 only, but OnePlus 3T contains the vulnerable code too.[…[

https://securityresear.ch/2017/02/08/oneplus3-bootloader-vulns/

https://oneplus.net/3t

 

aboot-parser: Android bootloader parser

Script to parse Android bootloader (aboot) images, extract certificates and verify image signature. May not work on aboot from latest devices. Signature verification follows the ‘Secure Boot and Image Authentication Technical Overview’ whitepaper by Qualcomm. Cf.  https://www.qualcomm.com/documents/secure-boot-and-image-authentication-technical-overview/ Aboot header format as described in  http://newandroidbook.com/Articles/aboot.html See above article for more details about aboot. Inspired by https://github.com/kayrus/kc_s701_break_free
[…]

https://github.com/nelenkov/aboot-parser

IBM on attacking Android Custom Boot Modes

IBM’s SecurityIntelligence has a story on attacking Android’s Custom Boot Modes.

Android Vulnerabilities: Attacking Nexus 6 and 6P Custom Boot Modes
By Roee Hay
Co-authored by Michael Goberman.

In recent months, the X-Force Application Security Research Team has discovered several previously undisclosed Android vulnerabilities. The November 2016 and January 2017 Android Security Bulletins included patches to one high-severity vulnerability, CVE-2016-8467, in Nexus 6 and 6P. Our new paper, “Attacking Nexus 6 & 6P Custom Bootmodes,” discusses this vulnerability as well as CVE-2016-6678.[…]

Android Vulnerabilities: Attacking Nexus 6 and 6P Custom Boot Modes

CyanogenMod dies

https://www.xda-developers.com/the-death-of-cyangenmod-and-whats-in-store-for-the-future/

http://www.androidcentral.com/remembering-cyanogenmod

https://cyngn.com/blog/the-future-of-cyanogen-and-the-untapped-power-of-mobile

https://cyngn.com/blog/cyanogen-services-shutting-down

Limitations of Android N encryption

The limitations of Android N Encryption
Over the past few years pixelphonewe’ve heard more about smartphone encryption than, quite frankly, most of us expected to hear in a lifetime. We learned that proper encryption can slow down even sophisticated decryption attempts if done correctly. We’ve also learned that incorrect implementations can undo most of that security. In other words, phone encryption is an area where details matter. For the past few weeks I’ve been looking a bit at Android Nougat’s new file-based encryption to see how well they’ve addressed some of those details in their latest release. The answer, unfortunately, is that there’s still lots of work to do. In this post I’m going to talk about a bit of that. […]

The limitations of Android N Encryption

 

Nathan: security-centric Android emulator

Nathan is an Android 5.1.1 SDK 22 AOSP Android emulator customized to perform mobile security assessment that works on x86 and soon will on ARM.

The emulator is equipped with the Xposed Framework and the following pre-installed modules:
* SSLUnpinning, to bypass SSL Certificate pinning.
* Inspeckage, to perform the dynamic analysis of an application.
* RootCloak, to bypass root detection.

The following tools are already installed:
* #SuperSU: Superuser access management tool
* Drozer: Comprehensive security and attack framework for Android

Features:
* Only python 2.7.x required
* Hooking ready with Xposed
* Pre-installed tools for application analysis
* Fully customizable
* Snapshot and restore of user data

https://github.com/mseclab/nathan

Android Verified Boot enforced with 7.0

Sami Tolvanen of Google posted a blog about Android Verified Boot and how things have changed with Android 7.0:

Android uses multiple layers of protection to keep users safe. One of these layers is verified boot, which improves security by using cryptographic integrity checking to detect changes to the operating system. Android has alerted about system integrity since Marshmallow, but starting with devices first shipping with Android 7.0, we require verified boot to be strictly enforcing. This means that a device with a corrupt boot image or verified partition will not boot or will boot in a limited capacity with user consent. Such strict checking, though, means that non-malicious data corruption, which previously would be less visible, could now start affecting process functionality more. By default, Android verifies large partitions using the dm-verity kernel driver, which divides the partition into 4 KiB blocks and verifies each block when read, against a signed hash tree. A detected single byte corruption will therefore result in an entire block becoming inaccessible when dm-verity is in enforcing mode, leading to the kernel returning EIO errors to userspace on verified partition data access. This post describes our work in improving dm-verity robustness by introducing forward error correction (FEC), and explains how this allowed us to make the operating system more resistant to data corruption. These improvements are available to any device running Android 7.0 and this post reflects the default implementation in AOSP that we ship on our Nexus devices.[…]

Full post:
http://android-developers.blogspot.com/2016/07/strictly-enforced-verified-boot-with.html

June Android security update

Google does monthly security updates for Android, but not all carriers take updates [that quickly].

 

The June update includes multiple hardware-related updates.

https://source.android.com/security/bulletin/2016-06-01.html

https://source.android.com/security/bulletin/

https://groups.google.com/forum/#!forum/android-security-updates

 

Excerpt of acks to researchers from this month:

We would like to thank these researchers for their contributions:

Di Shen (@returnsme) of KeenLab (@keen_lab), Tencent: CVE-2016-2468
Gal Beniamini (@laginimaineb): CVE-2016-2476
Gengjia Chen (@chengjia4574), pjf (weibo.com/jfpan) of IceSword Lab, Qihoo 360 Technology Co. Ltd.: CVE-2016-2492
Hao Chen, Guang Gong, and Wenlin Yang of Mobile Safe Team, Qihoo 360 Technology Co. Ltd.: CVE-2016-2470, CVE-2016-2471, CVE-2016-2472, CVE-2016-2473, CVE-2016-2498
Iwo Banas: CVE-2016-2496
Jianqiang Zhao(@jianqiangzhao) and pjf (weibo.com/jfpan) of IceSword Lab, Qihoo 360 Technology Co. Ltd.: CVE-2016-2490, CVE-2016-2491
Lee Campbell of Google: CVE-2016-2500
Maciej Szawłowski of the Google Security Team: CVE-2016-2474
Marco Nelissen and Max Spector of Google: CVE-2016-2487
Mark Brand of Google Project Zero: CVE-2016-2494
Mingjian Zhou (@Mingjian_Zhou), Chiachih Wu (@chiachih_wu), and Xuxian Jiang of C0RE Team: CVE-2016-2477, CVE-2016-2478, CVE-2016-2479, CVE-2016-2480, CVE-2016-2481, CVE-2016-2482, CVE-2016-2483, CVE-2016-2484, CVE-2016-2485, CVE-2016-2486
Scott Bauer (@ScottyBauer1): CVE-2016-2066, CVE-2016-2061, CVE-2016-2465, CVE-2016-2469, CVE-2016-2489
Vasily Vasilev: CVE-2016-2463
Weichao Sun (@sunblate) of Alibaba Inc.: CVE-2016-2495
Xiling Gong of Tencent Security Platform Department: CVE-2016-2499
Zach Riggle (@ebeip90) of the Android Security Team: CVE-2016-2493

ARM on OEM impact of Android apps on Chromebooks

bfuller has a post ARM’s Android Community blog, with a whitepaper for OEMs on how to deal with Google making Android apps run on ChromeOS systems:

Google on May 19 announced that Android apps are coming to Chromebook. Here is a backgrounder on what the move means for developers, OEMs and consumers. […] The move is likely to have a profound impact on the Chromebook market but also more broadly on clamshell, two-in-one and hybrid form factors. In some ways, the move echoes the impact that the Android development community and ARM ecosystem had in 2009, at the dawn of the smart phone era. What exactly the announcement mean for developers, OEMs and consumers? We’ve posted a detailed article (Android Apps on Chromebook.pdf) that dives into the possibilities and implications of making Android apps available on Chromebooks. Check it out and let us know how the news will affect your work! […]

https://community.arm.com/groups/android-community/blog/2016/05/19/android-apps-on-chromebook-what-it-means-for-developers-oems
https://chrome.googleblog.com/2016/05/the-google-play-store-coming-to.html
https://community.arm.com/docs/DOC-11574

Keen Security on Android kernel defenses

James Fang of Keen Security has a blog post about Android kernel mitigations:

Emerging Defense in Android Kernel:
There was a time that every Linux kernel hacker loves Android. It comes with a kernel from stone-age with merely any exploit mitigation. Writing exploit with any N-day available was just a walk in the park. Now a days Google, ARM and many other SoC/device vendors have put many efforts hardening the security of Android, including its kernel, which is (in most cases) the last defense against attack. As a group of Android gurus focusing on rooting, we probably facing these defense more than researchers in other fields. In this post we are going to summarize kernel exploit mitigations appeared in the recent 2 years, and sharing our opinions on their effectiveness. Note that we are going to focus on the implementation of mitigations in this post. We may point out its weakness, but we are not going to detail bypassing techniques for each mitigation. […]

http://keenlab.tencent.com/en/2016/06/01/Emerging-Defense-in-Android-Kernel/

Security updates in Android N

Lucian Armasu has a story in Toms Hardware about Android N security changes, summarizing a presentation from Adrian Ludwig of Android at the recent Google I/O event. The story has a link to the Google I/O video, as well. Outline of Lucian’s story:

Hardware-Backed Keystore (Now Mandatory)
Fingerprint And Smart Lock Authentication
Secure Networking
Storage Encryption
Strictly Enforced Verified Boot
Checking Device Health
Sandboxing
Other System Restrictions & Improvements

“[…] Ludwig said that a major security feature of Android these days is the hardware-backed ‘keystore’, which is available in the vast majority of Android devices thanks to various implementations of ARM’s TrustZone. Although TrustZone has been mainly implemented by chip makers and OEMs to enable stricter DRM protection, Google started making it available to application developers in the past few years. […]”

“[…] If in Android M the phone would warn the user only that the boot was modified by unknown code, in version N the device will not boot if the boot process has been maliciously modified. Google also introduced bit-level error correction in the verified boot feature, which can erase changes that would, for instance, keep a device rooted after it’s been rooted. […]”

Full story:
http://www.tomshardware.com/news/google-android-n-security-improvements,31846.html

Android Nexus 5 Monitor Mode

Vincent recently tweeted this pointer to a blog from Frédéric Basse, talking about Android Nexus 5’s Monitor Mode:

Analysis of Nexus 5 Monitor mode
This article will first describe how to locate the Monitor mode code in Nexus 5 firmware (hammerhead-ktu84p-factory-35ea0277, bootloader-hammerhead-hhz11k : c32f8bec310c659c1296739b00c6a8ac). Then, we will try to understand what it does (its functionalities). Finally, you will have to find bugs by yourself because I didn’t find any…so far !
[…]

Full article:
http://www.fredericb.info/2014/12/analysis-of-nexus-5-monitor-mode.html?spref=tw

Metaphor: Android statefright

Metaphor – Stagefright with ASLR bypass By Hanan Be’er from NorthBit Ltd.

Metaphor’s source code is now released! The source include a PoC that generates MP4 exploits in real-time and bypassing ASLR. The PoC includes lookup tables for Nexus 5 Build LRX22C with Android 5.0.1. Server-side of the PoC include simple PHP scripts that run the exploit generator – I’m using XAMPP to serve gzipped MP4 files. The attack page is index.php. The exploit generator is written in Python and used by the PHP code.

https://blog.zimperium.com/reflecting-on-stagefright-patches/

https://github.com/NorthBit/Metaphor

Click to access NorthBit-Metaphor.pdf