Modem interface exposed via USB
- Authors: Roberto Paleari (@rpaleari) and Aristide Fattori (@joystick)
- Samsung ID: SVE-2016-5301
- ID: CVE-2016-4030, CVE-2016-4031, CVE-2016-4032
- Notification date: 11/12/2015
- Release date: 11/04/2016
Some months ago we tweeted a video showing a "lock screen bypass" on a Samsung Galaxy S6 phone. In this post we provide the technical details behind that attack.
In a nutshell, when connected to a USB master (e.g., a normal laptop), Samsung Android phones expose (or can be forced to expose) a serial interface which can be exploited to communicate with the USB modem.
This communication channel is active even when both USB tethering and USB debugging (i.e., ADB) are disabled, and can be accessed even when the device is locked. An attacker who gains physical access to a (possibly locked) device can thus use this interface to send arbitrary AT commands to the modem. This permits to perform several actions that should be forbidden by the lock mechanism, including placing phone calls or sending SMS messages.
As a foreword, consider that in the following we assume that "USB debugging" is not enabled on the target device. When ADB is enabled, things are way too easy :-)
How does it work?
For old Samsung devices and firmware versions, such as the GT-I9192 (Samsung S4
Mini with build I9192XXUBNB1), just plugging the smartphone into a Linux host
exposes a usb-serial modem, accessible using the corresponding Linux device
/dev/ttyACM0). After connecting to the modem through this interface,
it is possible to send certain AT commands, some of which are delivered to the
baseband modem while others are processed by user-space applications.
Exploitation of this vulnerability on more recent firmware versions (e.g., latest versions of the Samsung S4 and Samsung S6 software) is not so straightforward: in the default configuration, when the device is connected it exposes to the host only a MTP interface, used for file transfer.
However, we discovered that an attacker can still access the modem by switching to secondary USB configuration. As an example, consider our test Galaxy S6 device. When USB debugging is off, the device exposes two USB configurations, with the CDC ACM modem accessible via configuration number 2.
$ lsusb -v ... Bus 001 Device 007: ID 04e8:6860 Samsung Electronics Co., Ltd Galaxy (MTP) Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x04e8 Samsung Electronics Co., Ltd idProduct 0x6860 Galaxy (MTP) ... bNumConfigurations 2 Configuration Descriptor: ... Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 6 Imaging bInterfaceSubClass 1 Still Image Capture bInterfaceProtocol 1 Picture Transfer Protocol (PIMA 15470) iInterface 5 MTP ... Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 105 bNumInterfaces 3 bConfigurationValue 2 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 96mA ... Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 2 Communications bInterfaceSubClass 2 Abstract (modem) bInterfaceProtocol 1 AT-commands (v.25ter) iInterface 6 CDC Abstract Control Model (ACM) ...
Thus, before being able to connect to the modem the attacker has to switch the device to USB configuration number 2. This operation can be performed by the host PC without the need to unlock the device.
For our PoC we developed a very rough C tool,
that switches any attached Samsung device to USB configuration #2 (this is fine
for the devices we tested, but your mileage might vary). The tool uses
libusb to do the job, but the same task can probably
be accomplished using the
The trick we used to force the phone to switch the configuration is to first
reset the USB device (via
usb_reset()), and then switching the configuration
usb_set_configuration()). Sometimes it doesn't work at the first try, so
usbswitcher twice to ensure the configuration is switched properly
The most obvious consequence of accessing the modem is the possibility to place phone calls and send SMS messages. For the former, the following AT command can be used:
This command starts a phone call to destination
+123456, even when the device
is locked. This is the very same command we issued for the
demo video we tweeted.
As a response to our tweet, people asked if this vulnerability can be also exploited to gain access to the device, e.g., to access the phonebook, photos, and the internal storage. Well, theoretically AT commands should be directly processed by the baseband processor, which normally should not be able to access the "Android world". However, as we mentioned before, the journey of an AT command is more convoluted and some AT commands are eventually interpreted by user-space applications, so things may be different than what expected.
As an example, during our tests we observed that the S4 mini (build
I9192XXUBNB1) supports several AT commands that could be abused to control some
Android settings. Among these,
AT+USBDEBUG command permits to enable "USB
debugging" (i.e., ADB),
AT+WIFIVALUE enables and disables the Wi-Fi, and so
On more recent phones and firmware versions, Samsung probably became aware of
the risks related to such commands and introduced a blacklist-based
mechanism (enforced by the
ddexe binary application) to filter out dangerous
ones. As an example, issuing an
AT+USBDEBUG on the Galaxy S6 results in the
following messages to be recorded to the system log:
D/DataRouter( 302): write  bytes of data to USB fd D/DataRouter( 302): After the usb select D/DataRouter( 302): read usb data[len:12] D/DataRouter( 302): read usb data message:AT+USBDEBUG D/DataRouter( 302): Not allowed AT cmd!! D/DataRouter( 302): Before the usb select
We confirm this issue affects the following device models. Other models and firmware versions are probably affected as well, but they were not tested.
- SM-G920F, build G920FXXU2COH2 (Galaxy S6)
- SM-N9005, build N9005XXUGBOK6 (Galaxy Note 3)
- GT-I9192, build I9192XXUBNB1 (Galaxy S4 mini)
- GT-I9195, build I9195XXUCOL1 (Galaxy S4 mini LTE)
- GT-I9505, build I9505XXUHOJ2 (Galaxy S4)