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

A main aspect of the Android platform is Inter-Application Communication (IAC), which enables reuse of functionality across apps and app components via message passing. While a powerful feature, IAC also constitutes a serious attack surface. A malicious app can embed a payload into an IAC message, thereby driving the recipient app into a potentially vulnerable behavior if the message is processed without its fields first being sanitized or validated. We present what to our knowledge is the first comprehensive testing algorithm for Android IAC vulnerabilities. Toward this end, we first describe a catalog, stemming from our field experience, of 8 concrete vulnerability types that can potentially arise due to unsafe handling of incoming IAC messages. We then explain the main challenges that automated discovery of Android IAC vulnerabilities entails, including in particular path coverage and custom data fields, and present simple yet surprisingly effective solutions to these challenges. We have realized our testing approach as the IntentDroid system, which is available as a commercial cloud service. IntentDroid utilizes lightweight platform-level instrumentation, implemented via debug breakpoints (to run atop any Android device without any setup or customization), to recover IAC-relevant app-level behaviors. Evaluation of IntentDroid over a set of 80 top-popular apps has revealed a total 150 IAC vulnerabilities — some already fixed by the developers following our report — with a recall rate of 92% w.r.t. a ground truth established via manual auditing by a security expert.

We present previously unknown high severity vulnerabilities in Android. The first is in the Android Platform and Google Play Services. The Platform instance affects Android 4.3-5.1, M (Preview 1) or 55% of Android devices at the time of writing. This vulnerability allows for arbitrary code execution in the context of many apps and services and results in elevation of privileges. In this paper we also demonstrate a Proof-of-Concept exploit against the Google Nexus 5 device, that achieves code execution inside the highly privileged system_server process, and then either replaces an existing arbitrary application on the device with our own malware app or changes the device's SELinux policy. For some other devices, we are also able to gain kernel code execution by loading an arbitrary kernel module. We had responsibly disclosed the vulnerability to Android Security Team which tagged it as CVE-2015-3825 (internally as ANDROID-21437603/21583894) and patched Android 4.4/5.x/M and Google Play Services. For the sake of completeness we also made a large-scale experiment over 32,701 of Android applications, finding similar previously unknown deserialization vulnerabilities, identified by CVE-2015-2000/1/2/3/4/20, in 6 SDKs affecting multiple apps. We responsibly (privately) contacted the SDKs' vendors or code maintainers so they would provide patches. Further analysis showed that many of the SDKs were vulnerable due to weak code generated by SWIG, an interoperability tool that connects C/C++ with a variety of languages, when fed with some bad configuration given by the developer. We therefore worked closely with the SWIG team to make sure it would generate more robust code -- patches are available.

Android is the most prevalent Linux-based mobile Operating System in the market today. Many features of the platform security (such as stack protection, key generation, etc.) are based on values provided by the Linux Pseudorandom Number Generator (LPRNG) and weaknesses in the LPRNG could therefore directly affect platform security. Much literature has been published previously investigating and detailing such weaknesses in the LPRNG. We build upon this prior work and show that - given a leak of a random value extracted from the LPRNG - a practical, inexpensive attack against the LPRNG internal state in early boot is feasible. Furthermore, the version of the Linux kernel vulnerable to such an attack is used in the majority of Android-based mobile devices in circulation. We also present two real-world exploitation vectors that could be enabled by such an attack. Finally, we mention current mitigations and highlight lessons that can be learned in respect to the design and use of future PRNGs for security features on embedded platforms.

One of the defenses against DNS cache poisoning is randomization of the IP address of the queried name server. We present a newly found vulnerability in BIND, the most widely used DNS software on the Internet, which enables an attacker to easily and deterministically control the queried name server chosen by BIND's resolver. The vulnerability lies in BIND's SRTT (Smoothed Round Trip Time) algorithm. The attack reduces the time and effort required to successfully poison BIND's cache. The general lesson from this vulnerability is that a DNS resolver must never keep a global state shared between different domain names (in our case the SRTT values are kept as a global state).

Area is a part of a large network. If the entire network was consisted of a single set of routers, all with a common database, then calculating the SPF would cost exponential time. The main idea is that a router would have to know only its area topological horizon,thus calculating the SPF on a smaller graph which keeps the CPU less busy. Inter-area routing is done by choosing the path to the closest interconnecting router, without considering the graph outside the area. Thus it trades CPU resources for sub-optimal routing.