Any given Android device supports a multitude of different radio-based wireless technologies. Almost all devices support Wi-Fi and Bluetooth. Many of those also support Global Positioning System (GPS). Devices able to make cellular telephone calls support one or more of the standard cell technologies, such as Global System for Mobile communications (GSM) and Code Division Multiple Access (CDMA). Newer Android devices also support Near Field Communication (NFC). Each of the supported wireless technologies has specifi c frequencies associated with them and thus is only reachable within certain physical proximi-ties. The following sections will dive deeper into each technology and explain
the associated access requirements. Before diving into those details, let’s look at concepts that apply to all of these mediums.
All wireless communications are susceptible to a wide range of attacks, both active and passive. Active attacks require an attacker to interfere with the normal fl ow of information and include jamming, spoofi ng, and man-in-the-middle (MitM). Because Wi-Fi and cellular networking are used to access the Internet at large, MitM attacks against these mediums provide access to an extremely rich attack surface. Passive attacks, like sniffi ng, enable attackers to compromise the information fl owing through these mediums. Stolen information is powerful.
For example, compromising keystrokes, authentication credentials, fi nancial data, or otherwise can lead to further and more impactful attacks.
GPS
GPS, which is often referred to as location data in Android, allows a device to determine where it is on the planet. It works based on signals from satellites that orbit the planet. The GPS receiver chip receives these signals, amplifi es them, and determines its location based on the result. Most people know GPS because it is often used to enable turn-by-turn navigation. In fact, devices designed specifi cally for navigation are often called GPS devices. In modern times, GPS has become an important tool in travelers’ toolboxes.
However, having GPS so widely available is not without controversy. Though GPS is a one-way communications mechanism, location data is exposed to Android applications through the Android Framework (android.location API) and Google Play Services (Location Services API). Regardless of which API is used, many Android applications do not respect end-user privacy and instead monitor the user’s location. Some of the authors of such apps are believed to sell access to the data to unknown third parties. This practice is truly concerning.
Under the hood, the hardware and software that implements GPS varies from one device to the next. Some devices have a dedicated chip that provides GPS support while others have GPS support integrated into the System-on-Chip (SoC). The software that supports the hardware varies accordingly and is usu-ally closed source and proprietary. This fact makes enumerating and digging deeper into the exposed attack surface diffi cult, time consuming, and device specifi c. Like any other communications mechanism, software that deals with the radio itself represents a direct attack surface. Following the data as it fl ows up the software stack, additional attack surfaces exist.
Because GPS signals emanate from outer space, an attacker could theoretically be very far away from his target device. However, there are no known attacks that compromise an Android device via the GPS radio. Because Android devices don’t use GPS for security, such as authentication, the possibilities are limited.
The only known attacks that involve location data are spoofi ng attacks. These
attacks could mislead a user using turn-by-turn navigation or allow cheating at games that use the location data as part of their logic.
Baseband
The single part of a smartphone that sets it apart from other devices the most is the ability to communicate with mobile networks. At the lowest level, this functionality is provided by a cellular modem. This component, often called the baseband processor, might be a separate chip or might be part of the SoC. The software that runs on this chip is referred to as the baseband fi rmware. It is one of the software components that comprise the Android telephony stack. Attacks against the baseband are attractive because of two things: limited visibility to the end user and access to incoming and outgoing cellular voice and data. As such it represents an attractive attack surface in a smartphone.
Although an attack against the baseband is a remote attack, an attacker must be within a certain proximity to a victim. In typical deployments, the cell modem can be several miles away from the cell tower. Mobile devices will automatically connect to and negotiate with the tower with the strongest signal available.
Because of this fact, an attacker only needs to be close enough to the victim to appear to be the strongest signal. After the victim associates with the attacker’s tower, the attacker can MitM the victim’s traffi c or send attack traffi c as they desire. This type of attack is called a Rogue Base Station attack and has garnered quite a bit of interest in recent years.
Android smartphones support several different mobile communications technologies like GSM, CDMA, and Long Term Evolution (LTE). Each of these are made up of a collection of protocols used to communicate between vari-ous components within a cellular network. To compromise a device, the most interesting protocols are those that are spoken by the device itself. Each protocol represents an attack vector and the underlying code that processes it represents an attack surface.
Digging deeper into the attack surface exposed by the baseband not only requires intense application of tools like IDA Pro, but also requires access to specialized equipment. Because baseband fi rmware is typically closed source, proprietary, and specifi c to the baseband processor in use, reverse-engineering and auditing this code is challenging. Communicating with the baseband is only possible using sophisticated radio hardware like the Universal Software Radio Peripheral (USRP) from Ettus Research or BladeRF from Nuand. However, the availability of small, portable base stations like Femtocells and Picopops could make this task easier. When the hardware requirement has been fulfi lled, it’s still necessary to implement the necessary protocols to exercise the attack sur-face. The Open Source Mobile Communications (Osmocom) project, as well as
several other projects, provides open source implementations for some of the protocols involved.
In Android, the Radio Interface Layer (RIL) communicates with the baseband and exposes cellular functionality to rest of the device. More information about RIL is covered in Chapter 11.
Bluetooth
The Bluetooth wireless technology widely available on Android devices supports quite a bit of functionality and exposes a rich attack surface. It was originally designed as a wireless alternative to serial communications with relatively low range and power consumption. Although most Bluetooth communications are limited to around 32 feet, the use of antennae and more powerful transmitters can expand the range up to 328 feet. This makes attacks against Bluetooth the third-longest-range wireless medium for attacking Android devices.
Most mobile device users are familiar with Bluetooth due to the popularity of Bluetooth headsets. Many users do not realize that Bluetooth actually includes more than 30 profi les, each of which describes a particular capability of a Bluetooth device. For example, most Bluetooth headsets use the Hands-Free Profi le (HFP) and/or Headset Profi le (HSP). These profi les give the connected device control over the device’s speaker, microphone and more. Other commonly used profi les include File Transfer Profi le (FTP), Dial-up Networking Profi le (DUN), Human Interface Device (HID) Profi le, and Audio/Video Remote Control Profi le (AVRCP).
Though a full examination of all profi les is outside the scope of this book, we recommend you do more research for a full understanding of the extent of the attack surface exposed by Bluetooth.
Much of the functionality of the various Bluetooth profi les requires going through the pairing process. Usually the process involves entering a numeric code on both devices to confi rm that they are indeed talking to each other. Some devices have hard-coded codes and therefore are easier to attack. After a pairing is created, it’s possible to hijack the session and abuse it. Possible attacks include Bluejacking, Bluesnarfi ng, and Bluebugging. In addition to being able to pair with hands-free devices, Android devices can be paired with one another to enable transferring contacts, fi les, and more. The designed functionality provided by Bluetooth is extensive and provides access to nearly everything that an attacker might want. Many feasible attacks exploit weaknesses in pairing and encryp-tion that is part of the Bluetooth specifi caencryp-tion. As such, Bluetooth represents a rather rich and complicated attack surface to explore further.
On Android devices, the attack surface exposed by Bluetooth starts in the kernel. There, drivers interface with the hardware and implement several of the low-level protocols involved in the various Bluetooth profi les like Logical Link
Control and Adaptation Protocol (L2CAP) and Radio Frequency Communications (RFCOMM). The kernel drivers expose additional functionality to the Android operating system through various Inter Process Communication (IPC) mecha-nisms. Android used the Bluez user-space Bluetooth stack until Android 4.2 when Google switched to Bluedroid. Next, code within the Android Framework implements the high-level API exposed to Android apps. Each component rep-resents a part of the overall attack surface. More information about the Bluetooth subsystem in Android is available at https://source.android.com/devices/
bluetooth.html.
Wi-Fi
Nearly all Android devices support Wi-Fi in its most basic form. As newer devices have been created, they have kept up with the Wi-Fi standards fairly well. At the time of this writing, the most widely supported standards are 802.11g and 802.11n. Only a few devices support 802.11ac. Wi-Fi is primarily used to connect to LANs, which in turn provide Internet access. It can also be used to connect directly to other computer systems using Ad-Hoc or Wi-Fi Direct features. The maximum range of a typical Wi-Fi network is about 120 feet, but can easily be extended through the use of repeaters or directional antennae.
It’s important to note that a full examination of Wi-Fi is beyond the scope of this book. Other published books, including “Hacking Exposed Wireless,” cover Wi-Fi in more detail and are recommended if you are interested. This section attempts to briefl y introduce security concepts in Wi-Fi and explain how they contribute to the attack surface of an Android device.
Wi-Fi networks can be confi gured without authentication or using several dif-ferent authentication mechanisms of varying strength. Open networks, or those without authentication, can be monitored wirelessly using completely passive means (without connecting). Authenticated networks use various encryption algorithms to secure the wireless communications and thus monitoring without connecting (or at least having the key) becomes more diffi cult. The three most popular authentication mechanisms are Wired Equivalent Privacy (WEP), Wi-Fi Protected Access (WPA), and WPA2. WEP is broken relatively easily and should be considered roughly equivalent to no protection at all. WPA was created to address these weaknesses and WPA2 was created to further harden Wi-Fi authentication and encryption.
The Wi-Fi stack on Android is much like the Bluetooth stack. In fact, some devices include a single chip that implements both technologies. Like Bluetooth, the source code for the Wi-Fi stack is open source. It begins with kernel drivers
that manage the hardware (the radio) and handle much of the low-level proto-cols. In user-space, wpa_supplicant implements authentication protocols and the Android operating system manages memorized connections. Like Bluetooth, these components are exposed to untrusted data and thus represent an exposed attack surface that’s interesting to explore further.
In addition to connecting to Wi-Fi access points (APs), most Android devices are capable of assuming the AP role, too. In doing so, the device increases its attack surface signifi cantly. Additional user-space code, more specifi cally hostapd and a DNS server, is spun up and exposed to the network. This increases the remote attack surface, especially if an attacker is able to connect to the AP hosted by the Android device.
Other than generic Wi-Fi attacks, no successful attacks against the Wi-Fi stack of an Android device are known. Viable generic attacks include rogue hotspots and MitM attacks.
NFC
NFC is a wireless communications technology that builds upon Radio Frequency Identifi cation (RFID). Of the wireless technologies supported by Android devices, NFC has the shortest range, which is typically limited to less than 8 inches.
There are three typical use cases for NFC on Android devices. First, tags that are usually in the form of stickers are presented to the device, which then reads the tag’s data and processes it. In some cases, such stickers are prominently displayed in public places as part of interactive advertising posters. Second, two users touch their Android devices together to beam data, such as a photo.
Finally, NFC is routinely used for contactless payments.
The Android implementation of NFC is fairly straightforward. Figure 5-6 depicts an overview of Android’s NFC stack. Kernel drivers speak to the NFC hardware. Rather than doing deep processing on received NFC data, the driver passes the data to the NFC Service (com.android.nfc) within the Android Framework. In turn, the NFC Service delivers the NFC tag data to Android apps that have registered to be the recipient of NFC messages.
NFC data comes in several forms, many of which are supported by Android by default. All of these supported implementations are very well documented in the Android SDK under the TagTechnology class. More information about NFC on Android is available at http://developer.android.com/guide/
topics/connectivity/nfc/index.html.
NFC Transmitter/Receiver Android Kernel libpn544_fs.so
NFC Service (com.android.nfc) libnfc_jni.so
Android App Android App Android App
libnfc.so libnfc_ndef.so
NFC Tag Data:
(Nodef, MiFare, etc.)
NFC Tag
Figure 5-6: NFC on Android
The most popular message format is NFC Data Exchange Format (NDEF).
NDEF messages can contain any data, but are typically used to transmit text, phone numbers, contact information, URLs, and images. Parsing these types of messages often results in performing actions such as pairing Bluetooth devices, launching the web browser, dialer, YouTube, or Maps applications, and more.
In some cases these operations are performed without any user interaction, which is especially attractive to an attacker. When beaming fi les, some devices launch the default viewer for the received fi le based on its fi le type. Each of these operations is an excellent example of an additional attack surface that lies beneath NFC.
Several successful attacks leveraged NFC to compromise Android devices.
As demonstrated by Charlie Miller, NFC can be used to automatically set up connections using other wireless technologies such as Bluetooth and Wi-Fi Direct. Because of this, it could be used to enable access to an attack surface that would otherwise not be available. Georg Wicherski and Joshua J. Drake dem-onstrated a successful browser attack that was launched via NFC at BlackHat USA in 2012. Also, as mentioned earlier, researchers from MWR Labs utilized
NFC to exploit a fi le format parsing vulnerability in the Polaris Offi ce document suite at the 2012 Mobile Pwn2Own. These attacks demonstrate that the attack surface exposed by NFC support on Android can defi nitely lead to successful device compromises.