Modem Flaw Exposes Encrypted Device to Hacking
The Blackphone is generally considered the most secure smartphone available today. Unfortunately, no matter how secure a system is designed to be, it remains vulnerable to security flaws. We recently discovered a vulnerability that could allow an attacker to remotely control the phone’s modem functions.
Developed by SGP Technologies, a wholly owned subsidiary of SilentCircle, the Blackphone provides users control over app permissions, such as the bundled Silent Phone and Silent Text services that anonymise and encrypt communications so no one can eavesdrop on voice, video and text calls.
As part of reverse engineering exercise to prepare for a Red Naga training session we discovered this socket was left open and accessible on the Blackphone (BP1)
shell@blackphone:/dev/socket $ ls -l at_pal
srw-rw-rw- radio system 2015-07-31 17:51 at_pal
There is almost no mention of this socket anywhere on the internet – except for file_contexts used by SELinux on Android. It appeared to be for the nVidia Shield tablet, which is the only other Android device that seems to be used in the wild with an Icera modem and has since been abandoned by nVidia. As we dug deeper we found a few applications which interact with this socket, specifically agps_daemon, which has more elevated privileges than a normal shell/app user since it is a system/radio user.
Prior to reversing anything and looking at system logs we can see agps_daemon reveals some interesting details;
I/AGPSD ( 219): agps_PortParseArgs: Getting property (agpsd.dev_path=/dev/ttySHM3) from environment
I/AGPSD ( 219): agps_PortParseArgs: Getting property (agpsd.socket_path=/dev/socket/at_pal) from environment
D/AGPSD ( 219): Kernel time: [9.408745]
D/AGPSD ( 219): vendor/nvidia/tegra/prebuilt/ceres/../../icera/ril/agpsd/agps_daemon.c Version : 1.12
D/AGPSD ( 219): vendor/nvidia/tegra/prebuilt/ceres/../../icera/ril/agpsd/agps_daemon.c Built Dec 2 2014 12:00:30
D/AGPSD ( 219): agps_uplinkThread: Entering
I/AGPSD ( 219): open_tty_port: Opening /dev/ttySHM3
I/AGPSD ( 219): agps_downlinkThread: Entering
According to the logs, this appears to be an nVidia Icera modem binary, which is listening to a “socket_path” /dev/socket/at_pal and also opening a tty_port on /dev/ttySHM3. After we open agps_daemon in IDA Pro this is quickly confirmed, and we can see that this privileged process listens on the at_pal socket and writes anything that is received from the socket to the ttySHM3 port. Looking around the binary we can also see that the ttySHM3 port is being listened to by the radio. This means we’ve found a way to talk directly to the modem! We can easily confirm that this works by actually just running the agps_daemon from the command line as shell, since we can see a “test” thread that has been left inside the code;
Running the binary from the command line we can see that these fake commands are being sent to the modem. This would allow an attacker to either run as a shell user and send commands to the radio, or potentially have an Android application with an internet permission send commands to the radio.
Since the commands began with “AT” and looked like modified Hayes commands, we began Googling for combinations of codes that might be more interesting to use. At the same time, we pulled all the files from the device and started grepping for “AT” style codes. From here we found that the binary /system/bin/fild appears to open the socket /dev/ttySHM3 and also loads the shared library file /system/lib/libicera-ril.so. By digging into these two binaries we found usable codes without too much effort, including the following interesting AT codes;
- AT+CMUT – Set modem muted or not (prevents ringing)
- ATD – Set called ID enabled or not on outgoing calls
- AT+CMGT + AT+CMGS – Send an SMS, not visible to the Android device
- AT+CCFC – Set call forwarding on this device, prevents incoming calls from showing
- AT+CSCS + AT+CUSD – Send USSD code
Along with the above codes, there were many more which didn’t seem to be standardized or perform any visible actions. After further investigation we were able to find additional code paths which would allow an attacker to:
- Send and receive text messages (which will not get passed to the main Android UI or be noticeable to the user in any way)
- Dial or connect calls (this is apparent to the user as the UI dialogs will pop up, however this will often lead to freezing and non-cancellable calls which must be hung up via modem interaction)
- Check the state of phone calls silently (what number the call is connected to, was it incoming or outgoing)
- Reset APN/SMSC/Power settings
- Force conference calls with other numbers
- Mute the modem speaker
- Force/unforce caller ID settings
- Kill modem (hard reboot required to restore modem)
- Find neighboring cell towers connected to
- Silently register a call forwarding number (Blackphone will not notice any calls incoming, incoming caller will not be notified of forwarding)
There are likely other methods we have not bothered enumerating – and some of the code looks potentially exploitable.
Once we validated these findings, we requested a CVE and contacted SilentCircle. They requested we submit the issue through Bugcrowd. The issue was assigned CVE-2015-6841 and has been fixed through the Bugcrowd bug bounty for SilentCircle.
This vulnerability illustrates the breadth and depth of the attack surface on this and other devices. It also raises some important considerations for security professionals. First, even the most “secure” systems can be vulnerable to attacks. Second, the increasing proportion of third party technology (hardware, drivers, software libraries, etc.) used in today’s devices makes detecting and remediating flaws more difficult than ever. And finally, virtually all vulnerabilities require some form of malware in order to be remotely exploited. Monitoring processes on a device can provide an important layer of detection and response when apparently legitimate requests to perform system functions originate from anomalous sources.
Timeline
2015-08-25 – Contact vendor, vendor requests going through Bugcrowd, issue submitted via Bugcrowd, CVE requested
2015-09-04 – Issue triaged under bugcrowd
2015-09-10 – Issue assigned CVE-2015-6841 via MITRE CERT
2015-09-30 – Vendor acknowledges and accepts submission
2015-11-02 – Issue marked as resolved, Awarded $ and vendor patches issue
2015-12-07 – Patch 1.1.13 RC3 released including fix for the issue
Special Thanks
Caleb Fenton, Jacob Soo and Jon Sawyer (Red Naga Proper) for assisting in developing the Red Naga training materials which led to this discovery. @Netsecrex (CSO of SilentCircle) for continually checking in on the disclosure process and keeping it going. Kymberlee Price and Bugcrowd for assisting in disclosing this issue
