Armis BlueBorne Vulnerability Scanner

Abstract

After disclosing a new Bluetooth-based attack vector, Armis published an Android app that can be used to check if a device is at risk or if the devices around it are at risk. To test this, the BlueBorne Vulnerability Scanner was downloaded from Google Play Store and installed on a device emulator.

Reverse engineering this app shows the local device risk check simply compares the device security patch date to a hardcoded date around the time of disclosure, and the remote (nearby) devices risk check and rating is a shallow consideration of device manufacturer and type.

Introduction

Refer to Armis resources.

Materials

adb
apktool
d2j-dex2jar
device emulator
jd-gui
Santoku VM

Method

Spin up virtual machine, device emulator, download and install BlueBorne Vuln Scanner app.
Start com.armis.blueborne_detector.SplashActivity. Select Tap to Check:
Wait for result:

Select Check Devices Around Me.
Coarse location permission is requested. Denying the request stops device scan:

Try Again and allow coarse location.
Bluetooth permission is requested. Denying the request stops device scan:

Try Again and allow Bluetooth to be enabled.
Wait for result:
Inspect:

Results

Since no permissions are declared in the Manifest, no permissions are requested at installation. Runtime permissions for coarse device location and Bluetooth adapter use are requested. Runtime permissions include:

android.bluetooth.adapter.action.REQUEST_ENABLE
android.permission.ACCESS_COARSE_LOCATION

Android API version is pulled to check device capabilities, e.g.: Build.VERSION.SDK_INT >= 18

System prop ro.product.model is pulled to display the local device name.

Device scans are performed by an instance of the public BluetoothAdapter class. Public methods called include:

startDiscovery() - Starts the remote device discovery process
cancelDiscovery() - Cancels the current device discovery process

Public methods called on public BluetoothDevice class include:

.getName() - Gets the friendly Bluetooth name of the remote device
.getAddress() - Returns the hardware address of the local BluetoothDevice
.getBluetoothClass() - Gets the Bluetooth class of the remote device
.getType() - Gets the Bluetooth device type of the remote device
.getUuids() - Returns the supported features (UUIDs) of the remote device
.fetchUuidsWithSdp() - Performs a service discovery on the remote device to get the UUIDs supported

Bluetooth device types include:

DEVICE_TYPE_CLASSIC - Classic - BR/EDR devices
DEVICE_TYPE_DUAL - Dual Mode - BR/EDR/LE
DEVICE_TYPE_LE- Low Energy - LE-only
DEVICE_TYPE_UNKNOWN - Unknown

Scan results are caught by a broadcast receiver registered with the following intent filters:

android.bluetooth.device.action.DISCOVERY_STARTED
android.bluetooth.device.action.DISCOVERY_FINISHED
android.bluetooth.device.action.FOUND
android.bluetooth.device.action.UUID
android.bluetooth.device.action.SDP_RECORD
android.bluetooth.device.extra.SDP_SEARCH_STATUS

Local device:
System prop Build.VERSION.SECURITY_PATCH or ro.build.version.security_patch is pulled then compared to GregorianCalendar(2017, 8, 1).getTime(). Local device with a security patch date older than this is considered vulnerable.

Remote devices:
Device scan is started and remote device attrs are pulled as they are discovered. Remote device address prefix is mapped to a manufacturer name from a static list; e.g., "Apple", "HTC" or "Samsung". Remote device is then classified based on manufacturer name; e.g., "ios", "android" or "tizen". Risk is then rated based on remote device classification:

Classification	Rating	Label
"osx"	1	Low
"apple"	1	Low
"ios"	2	Medium
"android"	3	High
"tizen"	3	High
"samsung"	3	High
"pc"	2	Medium
"smartphone"	2	Medium

Remote device with null or unknown manufacturer is considered low risk. Low Energy device DEVICE_TYPE_LE is also considered low risk.

Discussion

Assuming a normal progression though the app, you first check if your device is at risk; it most likely is, since you are checking using an Android app, which likely means you are using an Android device; you are then notified if your device is vulnerable and prompted to check devices around you; importantly, Bluetooth is then enabled (given that runtime permissions are granted), thereby opening your potentially vulnerable device to the attack vector. This brief proximity awareness comes at the cost of making your device more vulnerable than it was before downloading and installing the app.

Overall, the app is somewhat useful, in the sense that having a machine do something for you is useful; in this case, comparing two dates. Truly this is useful if and only if you do not know where to find one of the dates. Given both dates, it takes less time to compare them yourself than it does to download, install and run the app.

Its other function--to "scan and locate" nearby devices to check if they too are at risk--is really a conventional Bluetooth device discovery scan that pulls publicly available device attrs for each device discovered, including device manufacturer and type, which are then used to score the device risk on an interval from 1 to 3 based on an array of static values; e.g., a device manufactured by "Google" is always an "android" device which always has a score of 3 (high risk). This also seems relatively useless since it is already plausible to say, "Android devices are at high risk," or, "iOS devices are at risk, but lower." Armis Labs clearly already has.

But it is a free app designed to help you secure your device, and the local device check can sort of do that. Though it checks the device security patch date against 8/1/2017, and the September security patch is recommended.