Android security and locked devices

Secure or configurable, pick one. 😦 On the Windows PC world, this shows up as UEFI with Secure Boot. On the Chrome PC world, this shows up as coreboot with Verified Boot. Mobile device vendors are also having to deal with it, as this article on XDA Developers discusses:

[…] The truth has been there for some time. The more we rely on these same devices to handle very secure data and tasks, the more we have to make sure that they’re secure. Let’s take the recent kerfuffle with Samsung. Secure boot features from Qualcomm block anything with an improper signature being run on the system, including custom recoveries, kernels and ROMs. That may be frustrating for those of you who want to do that, but we have to realize that a much larger part of the market share neither wants, needs or even expects the system to allow such a lack of security. It’s not what’s actually being done that’s the problem; it’s what is made possible by the reduced security that poses the greater risk. To further reinforce the fact that this is becoming the norm, readers only have to understand UEFI Secure Boot and how that is doing the same thing in the PC world. What does that mean for those of us who want to see open development on those mainstream devices? Just like PCs still have options that don’t require UEFI Secure Boot we will continue to see options in the world of Android that will remain open.  […]

Full article:
http://www.xda-developers.com/opinion-why-end-user-devices-are-locked-down-for-security-and-why-they-have-to-be/

Samsung S6 Modem firmware reversing

Reverse Engineering Samsung S6 Modem
04 Mar 2016

So I was a little late to the game, and just got my hands on a Samsung Galaxy S6, specifically the SM-G920F which will be the topic of discussion in this post. I am quite curious as to understanding the structure of the device’s modem.bin file. While I haven’t been able to get a de-obfuscated/decrypted version of modem.bin yet, hopefully this post will help others quickly get up-to-speed and assist in the pursuit of one. Anyone interested in helping or contributing can hit me with the Tweets @theqlabs or submit a PR.

TL;DR – i do not have a decrypted modem.bin yet, but here are all my notes, send help. ❤

[…]
Full post:

http://arm.ninja/2016/03/04/reverse-engineering-samsung-s6-modem/

Updating Android devices

Sam Varghese has a story on ITWire about how Android-based devices are hard to update, including some conversation about firmware:

[…] x86 processors have a long history of standardisation. An x86 processor is mostly made of the CPU and an interface to the BIOS/UEFI firmware on the motherboard. From there the operating system can gather the information about the hardware components present in the system. In comparison, ARM processors, especially in the Android/embedded market are System-on-Chips (SoCs). This means, apart from the CPU the SoC provides most to all peripheral components on one die (e.g. network chip, USB chip, display chip, etc). Apart from that, although ARM has standard components for the core system (e.g. interrupt controller, timers etc), most ARM SoCs implement their custom components here, which needs their own drivers in the kernel. The reason is because many companies which produce ARM-based processors have a long history in the mobile phone market in the pre-smartphone era. They have core components which were developed years ago and they want to re-utilise them, as they have a deep knowledge on how they work and their custom software drivers. Third, especially in the embedded world, the ARM processors don’t use the Unified Extensible Firmware Interface (UEFI) to communicate with the firmware. To tell the Linux kernel which components are present, the bootloader passes a device tree blob to the kernel. So there is no dynamic way to tell the kernel which components are present. This is changing a lot and the Linux community are putting a big effort in standardising the firmware interface (EFI, PSCI, ACPI). […]

http://www.itwire.com/business-it-news/open-source/71698-why-updating-android-without-vendor-help-is-a-nightmare.html

February’s Google Nexus security bulletin is out

The Google Nexus Security team has released their monthly security bulletin.

We have released a security update to Nexus devices through an over-the-air (OTA) update as part of our Android Security Bulletin Monthly Release process. The Nexus firmware images have also been released to the Google Developer site. Builds LMY49G or later and Android M with Security Patch Level of February 1, 2016 or later address these issues. Refer to the Nexus documentation for instructions on how to check the security patch level.
[…]
We would like to thank these researchers for their contributions:
* Android and Chrome Security Team: CVE-2016-0809, CVE-2016-0810
* Broadgate Team: CVE-2016-0801, CVE-2015-0802
* David Riley of the Google Pixel C Team: CVE-2016-0812
* Dongkwan Kim (dkay@kaist.ac.kr) of System Security Lab, KAIST: CVE-2015-6614
* Gengjia Chen (@chengjia4574) of Lab IceSword, Qihoo 360: CVE-2016-0805
* Hongil Kim (hongilk@kaist.ac.kr) of System Security Lab, KAIST: CVE-2015-6614
* Qidan He (@Flanker_hqd) of KeenLab (@keen_lab), Tencent: CVE-2016-0811
* Seven Shen (@lingtongshen) of Trend Micro (www.trendmicro.com): CVE-2016-0803
* Weichao Sun (@sunblate) of Alibaba Inc: CVE-2016-0808
* Zach Riggle (@ebeip90) of the Android Security Team: CVE-2016-0807
[…]

See the full bulletin for specifics on each of the CVEs:

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

Zero perms to TrustZone: Android mediaserver CVEs discussion

https://pbs.twimg.com/media/CZgC2lkUEAA16RP.png:large

Android privilege escalation to mediaserver from zero permissions (CVE-2014-7920 + CVE-2014-7921)

In this blog post we’ll go over two vulnerabilities I discovered which, when combined, enable arbitrary code execution within the “mediaserver” process from any context, requiring no permissions whatsoever. How bad is it? The first vulnerability (CVE-2014-7921) was present in all Android version from 4.0.3 onwards. The second vulnerability (CVE-2014-7920) was present in all Android versions from 2.2 (!). Also, these vulnerabilities are not vendor specific and were present in all Android devices. Since the first vulnerability is only needed to bypass ASLR, and ASLR is only present (in a meaningful form) from Android 4.1 onwards, this means that these vulnerabilities allow code execution within “mediaserver” on any Android device starting from version 2.2. Although I reported both vulnerabilities in mid October 2014, they were unfortunately only fixed much later (see “Timeline” for full description, below) – in Android version 5.1!  This means that there are many devices out there which are still vulnerable to these issues, so please take care. You can find the actual patches here. The patches were pushed to AOSP five months after the vulnerabilities were reported. That said, the Android security team was very pleasant to work with, and with other vulnerabilities I reported later on, were much more responsive and managed to solve the issues within a shorter time-frame.
[…]

Full post:
http://bits-please.blogspot.com/2016/01/android-privilege-escalation-to.html

Sigh, it seem harder to track ARM firmware bugs, since they’re often hidden in the description of an app bug. And SCAP has no firmware OVAL definitions for CVEs to mention things like TrustZone. 😦

Google Android Nexus debug cable is open source

Google has specs for the Nexus debug cable:

USB debug cable design documents:  Eagle schematics and PCB, gerber files, and BOM for a debug cable
for the headset serial port found on most Nexus devices.

https://android.googlesource.com/device/google/debugcable/+/master

new Linux/Android kernel vulnerability

Linux Kernel Vulnerability: US-CERT is aware of a Linux kernel vulnerability affecting Linux PCs and servers and Android-based devices. Exploitation of this vulnerability may allow an attacker to take control of an affected system. US-CERT recommends that users and administrators review the Redhat Security Blog  and the Debian Security Bug Tracker for additional details and refer to their Linux or Unix-based OS vendors for appropriate patches.

https://www.us-cert.gov/ncas/current-activity/2016/01/19/Linux-Kernel-Vulnerability

https://access.redhat.com/security/cve/CVE-2016-0728

https://security-tracker.debian.org/tracker/CVE-2016-0728

X-Ray, Duo Labs Android vulnerability tool

https://twitter.com/jonoberheide/status/689526256388476928

Duo has a new article on Android security out. The article mentions an Android vulnerability detection tool that Duo Labs has:

Another tool that can help users detect for known Android vulnerabilities is X-Ray, a Duo Labs tool that anyone can download and run on their Android-based phone and/or tablet. Now in version 2.0, this app safely scans for vulnerabilities and allows you to assess your current mobile security risk.

 

https://duo.com/blog/duo-analytics-android-device-security-article

https://labs.duosecurity.com/xray

Copperhead OS blocked by missing Google Nexus blobs

Copperhead OS is a hardened verison of Android, including PaX and other security features beyond ASOP, mainly targetting Google Nexus devices. It appears they’re having some problems with availability of ASOP blobs from Google on some new Nexus devices:

https://copperhead.co/android/
https://copperhead.co/docs/technical_overview
https://github.com/copperheados

Google Ubiquity and IoT security

Google’s Ubiquity Dev Summit just ended, some of the video is online. There is one talk on IoT security:

https://ubiquity.withgoogle.com/

https://ubiquity.withgoogle.com/stream

https://ubiquity.withgoogle.com/schedule

“Brillo has a defense-in-depth strategy to device security built around verified boot, software fault isolation, and field updates of devices. Paul Covell explains the architecture of each of these mechanisms and how they work together to help Brillo devices be more resistant to exploit and create mechanisms for recovery if an exploit occurs.

Android deprecates GCC, switch to Clang

From the Android NDK Changelog for NDK Build 2490520:

Clang:
    PSA: Everyone should be switching to Clang.
    Clang has been updated to 3.8svn (r243773, build 2481030).
        Note that this is now a nearly pure upstream clang.
        Also note that Clang packaged in the Windows 64 NDK is actually 32-bit.
    Support for emulated TLS.
        __thread is now supported by the compiler by emulating ELF TLS with pthread thread-specific data.
        C++11 thread_local will work in some cases, but will not work for data with non-trivial destructors except when running on Marshmallow (android-23) or newer because those cases require support from libc.
        Does not yet work with Aarch64 when TLS variables are accessed from a shared library.

GCC:
    GCC in the NDK is now deprecated.
        Time to start using Clang if you haven’t already. If you have problems with Clang, please file bugs!
        The NDK will not be upgrading to 5.x, nor will we be accepting non-critical backports.
        Maintenance for miscompiles and internal compiler errors in 4.9 will be handled on a case by case basis.
    GCC 4.8 has been removed. All targets now use GCC 4.9.

https://android.googlesource.com/platform/ndk.git/+/master/CHANGELOG.md

 

BareDroid: Large-Scale Analysis of Android Apps on Real Devices

To protect Android users, researchers have been analyzing unknown, potentially-malicious applications by using systems based on emulators, such as the Google’s Bouncer and Andrubis. Emulators are the go-to choice because of their convenience: they can scale horizontally over multiple hosts, and can be reverted to a known, clean state in a matter of seconds. Emulators, however, are fundamentally different from real devices, and previous research has shown how it is possible to automatically develop heuristics to identify an emulated environment, ranging from simple flag checks and unrealistic sensor input, to fingerprinting the hypervisor’s handling of basic blocks of instructions. Aware of this aspect, malware authors are starting to exploit this fundamental weakness to evade current detection systems. Unfortunately, analyzing apps directly on bare metal at scale has been so far unfeasible, because the time to restore a device to a clean snapshot is prohibitive: with the same budget, one can analyze an order of magnitude less apps on a physical device than on an emulator. In this paper, we propose BareDroid, a system that makes bare-metal analysis of Android apps feasible by quickly restoring real devices to a clean snapshot. We show how BareDroid is not detected as an emulated analysis environment by emulator-aware malware or by heuristics from prior research, allowing BareDroid to observe more potentially malicious activity generated by apps. Moreover, we provide a cost analysis, which shows that replacing emulators with BareDroid requires a financial investment of less than twice the cost of the servers that would be running the emulators. Finally, we release BareDroid as an open source project, in the hope it can be useful to other researchers to strengthen their analysis systems.

https://dl.acm.org/citation.cfm?id=2818036
https://github.com/ucsb-seclab/baredroid

Console OS: be wary

Console OS is an Intel-based Android-based operating system that is funded via Kickstart. Before you fund/use it, please read this thread, starting with a message from Android-x86’s project leader:

https://lists.01.org/pipermail/android-ia/2015-December/001038.html

Hi all,
[CC this to Android-IA list since the guy continues lying on Android-IA list]

Honestly speaking, I really have no time to check what Christopher Price and his crappy Console OS did recently. But I’m getting more and more private requests to ask me to stop him from stealing the Android-x86 effort. So as the project leader of the Android-x86 project, I think I need to do something. As a background for new comers who haven’t heard the story of Console OS, here is a brief: […]

More info:
https://lists.01.org/pipermail/android-ia/2015-December/thread.html
http://www.android-x86.org/
https://01.org/android-IA
http://consoleos.com/

AndroBugs Framework 1.0 released

Yu-Cheng Lin’s AndroBugs 1.0.0 has been released:

AndroBugs Framework is an Android vulnerability analysis system that helps developers or hackers find potential security vulnerabilities in Android applications. No splendid GUI interface, but the most efficient (less than 2 minutes per scan in average) and more accurate. Features:
*   Find security vulnerabilities in an Android app
*   Check if the code is missing best practices
*   Check dangerous shell commands (e.g. “su”)
*   Collect Information from millions of apps
*   Check the app’s security protection (marked as <Hacker>, designed for app repackaging hacking)

https://github.com/AndroBugs/AndroBugs_Framework

Android attestation API

Shawn Willden of Google recently posted a message to the Android Security Discussions group. Someone had asked if, like a PC, Android smartphones have a TPM or Trusted Execution Environment (TEE), and if this included a public remote attestation API. Shawn’s response:

“One of the features I’m working on adding to Android TEEs for N is an attestation API. It will be implemented in our TEE, Qualcomm’s, Trustonic’s, etc. However, that will only assure the relying party that the device attesting has an officially-blessed TEE, and that the Android OS that was booted was an officially-blessed image as well. It can’t say anything about the state of Android, whether or not it has been compromised in some way that doesn’t involve modifying the boot images. The SafetyNet attestation can theoretically provide some level of assurance that the device is not compromised, though at the moment I believe it really only validates that the device is not an emulator and that it hasn’t been rooted in an obvious way.”

For more information: see the October 25th posting from Shawn on:
http://groups.google.com/group/android-security-discuss

Blackberry’s Priv to get monthly security updates

Jimmy Westenberg has written a story on Android Authority about Blackberry committing to monthly security updates for their Android devices:

In wake of the recent Stagefright vulnerability in Android, many OEMs have been committing to monthly security-focused updates for their devices. Companies such as Samsung, LG and Google have all committed to putting a bigger focus on security patches, and now we can add BlackBerry to that list as well. BlackBerry has just released some detailed information as to how it plans to keep its upcoming Android-powered handset, the Priv, up to date with the latest security patches as they become available to the public. Specifically, the company says it will release monthly updates to users who have purchased the Priv through shopblackberry.com. If you happen to purchase your device from a carrier or authorized retailer, though, you might need to wait a bit longer. […]

Full story:
http://www.androidauthority.com/blackberry-priv-monthly-security-updates-653542/

This is great news, glad to see more than one carrier with this policy.

Google to merge Android and ChromeOS?

http://www.linux.com/news/embedded-mobile/mobile-linux/864465-despite-google-denials-chrome-os-and-android-seem-destined-for-merger

http://chrome.blogspot.com/2015/11/chrome-os-is-here-to-stay.html

Personally, I’d like to see Android Verified Boot and Chrome OS Verified Boot unified! 🙂

 

Android USB-OTG vulnerability

Interesting story from TechWorm on a Samsung-flavored Android security issue, unclear how this impacts other vendor’s flavors of Android:

Samsung lets you hack it smartphone even with factory reset protection enabled with a USB OTG

In order to protect a Android smartphones from theives, Google introduced a new feature in Android 5.0 Lollipop. The new feature allows your phone to stay protected in the event of a factory data reset that occurs from within recovery. Android 5.0 Lollipop gives this root level protection to Android smartphone owners and it will persistently ask for the primary Google account’s password after a phone has been factory reset in this manner. This protection helps the owner in case a thief or a hacker tries to gain access to the phone. However, a Android user, RootJunky has proved that it is easy to bypass this system level protection with just a USB OTG cable and APK within 10 minutes.  RootJunky recently discovered a flaw on Samsung devices which allows you to bypass the system level protection with just that. […]

Full story:

http://www.techworm.net/2015/11/samsungs-factory-reset-protection-bypassed-with-usb-otg-video.html

 

Android Nexus security updates for November

Google is continuing it’s new policy of monthly Android updates for it’s Nexus line.

CVE-2015-6608, Critical, Remote Code Execution Vulnerabilities in Mediaserver
CVE-2015-6609, Critical, Remote Code Execution Vulnerability in libutils
CVE-2015-6611, High, Information Disclosure Vulnerabilities in Mediaserver
CVE-2015-6610, High, Elevation of Privilege Vulnerability in libstagefright
CVE-2015-6612, High, Elevation of Privilege Vulnerability in libmedia
CVE-2015-6613, High, Elevation of Privilege Vulnerability in Bluetooth
CVE-2015-6614, Moderate, Elevation of Privilege Vulnerability in Telephony

https://groups.google.com/forum/#!msg/android-security-updates/n1aw2MGce4E/jhpVEWDUCAAJ
https://source.android.com/devices/tech/security/enhancements/enhancements60.html

In somewhat-related Android security news, there is a new design-time vulnerability:

http://blog.trendmicro.com/trendlabs-security-intelligence/setting-the-record-straight-on-moplus-sdk-and-the-wormhole-vulnerability/
http://www.itproportal.com/2015/11/03/android-sdk-vulnerability-leaves-100-million-users-at-risk/