from Securelist - Information about Viruses, Hackers and Spam
Mobile phones. Nowadays, they are our constant companions, our confidants. They know everything about our everyday lives. Every day, whether we’re on our way to or from work or just wandering around the city, mobile phones collect this information. We take photos, share our impressions on social networks, send work and non-work related mails, text messages, and make calls. All this information makes our smartphones a treasure trove for data thieves.
And we are confident that all this data is secure.
Manufacturers assure us that their devices and the data on them are safe. They release updates containing security fixes.
We also take steps to protect our privacy. Tinkering users install custom firmware, discover operating system mechanisms, acquire root access to have deeper control over their phone and use software that, according to them, is more secure and convenient.
The average user who prefers to just use his phone without digging any deeper, sets a PIN code, a complex password or fingerprint scanner, and sticks to official app stores.
Most users believe these measures make their data safe. But is that really the case?
The following experiment displays, that sometimes just charging your device may bring you trouble.
Data transmission
A while ago I started to dig a bit deeper into what happens when you connect your phone to your computer. Usually, when your phone is protected, you will only see the phone name on your PC. If it has no PIN/password, you’ll be able to access all the media files on the device.
The amount of data exchanged varies depending on manufacturer, OS version, low-level firmware. But data is always present. Even if it’s a phone with the latest Android OS (Marshmallow), or iOS 9.
Data transmission – comparison table
Here is a comparison table on the data exchange between a computer and connected mobile phone during the handshake. It varies depending on the mobile and desktop OS combination:
Codes:
DN – Device Name
DM – Device Manufacturer
DT – Device Type
SN – Serial Number
FW – Firmware info
OS – Operating System info
FS – File system info/file list
ECID – Electronic Chip ID
| Device | Device OS | Mode | Host OS | Data size (bytes) | Data type |
| Nexus 5 | Android 4.4 | MTP (default) | Windows 8.1 | 32 336 | DN, DM, DT, SN, FS |
| MTP (unblocked) | Windows 8.1 | 32 155 | DN, DM, DT, SN, FS | ||
| MTP + ADB | Windows 8.1 | 11 946 | DN, DM, SN | ||
| MTP (default) | Windows 10 | 8 827 | DN, SN | ||
| MTP (unblocked) | Windows 10 | 242 206 | DN, SN, FS | ||
| MTP + ADB | Windows 10 | 10 582 | DN, SN, FW | ||
| MTP (default) | OSX 10.9 | 1 213 | DN, DM, DT, SN | ||
| MTP (unblocked) | OSX 10.9 | 581 | DN, DM, DT, SN | ||
| Nexus 6 | Android 6.0.1 | Charging only (default) | Windows 8.1 | 8 965 | DN, DM, SN |
| MTP (unblocked) | Windows 8.1 | 39 418 | DN, DM, DT, SN, FS | ||
| Charging only (default) | Windows 10 | 8 975 | DN, SN | ||
| MTP (unblocked) | Windows 10 | 91 342 | DN, SN, FS | ||
| Charging only (default) | OSX 10.9 | 14 000 | DN, DM, DT, SN | ||
| MTP (unblocked) | OSX 10.9 | 7 674 | DN, DM, DT, SN | ||
| Samsung Galaxy S4 | Android 5.0.1 | MTP (default) | Windows 8.1 | 4 098 | DN, DM, DT, SN |
| MTP (default) | Windows 10 | 7 740 | DN, DM, DT, SN, FS, FW | ||
| Apple iPhone 5 | iOS 9.1 | Default (locked) | Windows 8.1 | 5 001 | DN, DM, SN |
| Default (locked) | OS X 10.9 | 83 272 | DN, DM, DT, SN, OS, ECID, device public key | ||
| Unblocked + Paired | Windows 8.1 | 1 829 145 | UniqueChipID, device class, iOS version, SessionID, device model, File System total size, File system free space | ||
| Unblocked + Paired | OS X 10.9 | 23 223 | DN, DM, DT, SN, OS, ECID, device public key |
All in all, that’s quite a fair amount of information about the device.
What else?
While I was conducting this minor research, I stumbled upon one very peculiar feature in a smartphone from a very popular manufacturer. I found out that while installing the CDC driver (I was using a normal Windows PC and completely standard microUSB cable) this phone also installs a COM-port, labelling it as a modem. At first glance it doesn’t look like anything unusual. However, this phone had no USB tethering enabled, and no Developer mode or ADB (USB debugging) enabled either.
This COM-port is available for connection using default methods.
So, we reached the modem. Or not. What we reached is probably just an interface layer that allows us to talk to the modem; it’s not a direct connection.
Now for the theory. Android consists of different layers, one of which is RIL. RIL stands for Radio Interface Layer. It is responsible for allowing Application level apps (e.g. Android telephony framework) to interact with modem hardware via specific commands (both send requests and receive answers).
To avoid going too deep into the details, I won’t describe the RIL Java sub-layer that talks to the rild daemon, or Vendor RIL. Let’s just call it RIL (Radio Interface Layer).
Historically, all modems use a command set called the Hayes command set, developed by Dennis Hayes way back in 1981. The commands used to talk to the modem are called AT-commands. The commands that are available for applications to call through RIL, and for RIL to transmit to the modem, vary depending on the modem firmware limitations set by the manufacturer, RIL limitations, etc. Many manufacturers also implement their own vendor-specific commands for their modems. For example, Qualcomm uses AT$Q<command> extension, Infineon – AT+X<command>
ATI1-9 commands return general information about the device and modem, e.g.
ATI1 returns the software version code.
ATI2 returns IMEI numbers. From here we can see that the device has a dual-sim.
You can dig up more info with the other AT commands.
Digging, digging
By digging a bit further, we can find all the commands available for the modem. Note that many of them are restricted and/or require parameters and will return an “Error” otherwise.
By the way, vendor-specific commands won’t be listed here!
We can check the mobile signal level by AT+CSQ, battery level, etc.
There is also one very interesting command – a default for modems – that allows any number to be dialed regardless of whether the screen is locked or not. This is a very peculiar feature for phones locked with a PIN code, because you can usually only call an emergency service from a locked screen.
There are commands that allow you to read the SIM card’s phonebook. The phonebook is not accessible on this particular phone, but who knows about other vendors?
The scary part
You may think: “So what? What can be done with this information?” But just think about it, you can pull vendor information, firmware details. That gives you enough data to analyze the device’s security. You can find out the owner’s mobile phone number – by calling your number. By finding out the battery level you can predict how long the user will keep the charger plugged in. Not bad at all, I’d say.
But there’s more that you can do with this information.
Experimenting further I stumbled across one more command – it actually performs a phone reboot to the firmware update mode. This mode actually allows an infiltrator to perform all kinds of actions with the user’s device, given the right circumstances.
So I conducted an experiment. I restored the phone to the factory firmware, reset it to default settings to ensure no other interface like ADB was available outside.
First, I connected the phone to my computer.
Then I pulled the firmware data with AT commands, to determine the device type and OS.
After that I entered that last command I came across and the phone rebooted to the firmware update mode!
What happened next?
With the information gathered via AT commands, I identified the device.
And then I used an easy-to-use root solution as a proof-of-concept. So I found the appropriate package for the device, fired up the firmware update application, and here’s what happened next:
The update took around a minute (the file is very small). The phone rebooted to perform an actual root installation:
Root package was installed, and it cleaned itself up.
The phone rebooted again, and what do we see –
All the user’s data is safe, but now he has one more app that cannot be uninstalled with default measures and it has root access to file system. I checked the timer – it took a little under 3 minutes for the whole procedure, and that’s taking into account that I was pressing buttons manually.
Imagination time
Now it’s time to use your imagination. What if?
What if that package didn’t have a generic purpose (with lots of additional features), but had one specific task to install a specific application or change the device configuration?
That would make it possible to minimize the package size and script, thus reducing the installation time.
What if it installed a system daemon, instead of some package? What if it installed a backdoor? What if it was some kind of Android Trojan – which are very common nowadays – and worked in the background, sharing everything on your phone with someone sitting on the other side of the world?
What if it enabled developer mode and ADB, and added the computer’s fingerprint to a trusted database? These changes wouldn’t be detected by a security solution (if one was installed), since they are default phone functions. It also wouldn’t take very long to execute.
And what can we do from a trusted computer via ADB to the connected phone?
The answer is – a lot. We can install and delete applications. We can back up the message database, photos and videos, the applications cache and data files. And it can be done pretty fast.
And these scenarios are only those that involve data theft.
There are other possible destructive actions such as wiping the phone, deleting data, encrypting data and asking for a ransom. The possibilities are infinite.
So let’s imagine a scenario where you are on a trip and you just got off the plane after a flight of 5-8 hours. Your phone is almost dead. You find a charging station with USB – a blessing!
You connect your phone to start charging, put it down and mind your own business for 20-30 minutes, or more. Or less. It doesn’t matter.
Now look at what has been described above. How long do you think it will take for a script to perform those actions, download every bit of data from your phone and/or infect it with malware?
With that sort of data you can be hacked, you can be tracked, your data (including corporate data) can be compromised or destroyed.
Simple as that.
Conclusion
There are large communities around the world that specialize in exploring operating system internals, modifying them and releasing the results of their hard work to the public.
Other people use the results of this work to upgrade their devices. But there is no guarantee that the firmware they have just installed on their phone is free from vulnerabilities and backdoors. They may forget to disable the developer or debugging mode. They may be installing a hidden package, or background service for data collection and transfer.
Despite all manufacturer’s efforts, absolute security of mobile devices is virtually unreachable.
Our experiment proves it. It has been conducted on just one vendor, but there’s nothing to say that holes like this don’t exist on the phones of other vendors. All of the above was done using public information only.
I dug around and found that this vulnerability was found at Black Hat and reported some time back in 2014. It did not create much of a buzz, as far as research of the news and social media shows, and it still exists, even on the very latest models.
While working on this article I found that these guys also discovered this hole, to some extent.
Stealing data from connected to a computer mobile phone technique has been utilized, for example, during ill-known cyberespionage campaign Red October in 2013.
Possibility of data theft from mobile phone when using public charging spots has been described by our experts in 2014. You may think that it is paranoid to think that no one will bother with installing malicious charging stations at airports, cafes, bus stations. But we think differently.
