This report is the continuation of "#root via SMS", a research made by the SCADA Strangelove team in 2014. It was devoted to telecommunications equipment vulnerabilities with modem flaws only partially covered. This document describes vulnerabilities found and exploited in eight popular 3G and 4G modems available in Russia and worldwide. The findings include Remote Code Execution (RCE) in web scripts, integrity attacks, Cross-Site Request Forgery (CSRF), and Cross-Site Scripting (XSS).
The research covers a full range of attacks against carrier customers using these types of modems — device identification, code injection, PC infection, SIM card cloning, data interception, determining subscriber location, getting access to user accounts on the operator's website, and APT attacks.
We analyzed eight modems of the following vendors:
- Huawei (two different modems and a router)
- Gemtek (a modem and a router)
- Quanta (two modems)
- ZTE (one modem)
Not all the modems had vulnerabilities in their factory settings; some of them appeared after the firmware was customized by the service provider.
For convenience, let's call all the network equipment — both modems and routers — collectively, "modems".
Statistics on Vulnerable Modems
The data was gathered passively from SecurityLab.ru between 01/29/2015 and 02/05/2015 (one week). Our statistics lacks information about Huawei modems, but it can be easily found at shodan.io:
All the modem models investigated had critical vulnerabilities leading to complete system compromise. Virtually all the vulnerabilities could be exploited remotely (see the "Modems" table). Description of the detected vulnerabilities ranked by severity:
1. RCE (five devices)
All the modem web servers are based on simple CGI scripts that are not properly filtrated (except for Huawei modems, and even then only after a few security updates since the vulnerabilities have been disclosed).
All the modems work with the file system — they need to send AT commands, read and write SMS messages, configure firewall rules, etc.
Almost no devices had CSRF protection, which allowed remote code execution by power of social engineering and remote requests through a malicious website. Some modems were also vulnerable to XSS attacks.
Combined, these three factors produce a disappointing result — more than 60% of the modems are vulnerable to Remote Code Execution. You could get an updated firmware without all found vulns for only Huawei modems (there's a public description of the vulnerabilities). The other vulnerabilities are still considered to be zero-day.
2. Integrity Attacks (six devices)
Only three modems were protected against arbitrary firmware modifications. Two of them had the same integrity check algorithms (asymmetrically encrypted SHA1 with RSA digital signature), and the third one used the RC4 stream cipher for firmware encryption.
All the cryptographic algorithms proved to be vulnerable to attacks violating integrity and confidentiality. In the former case, we can modify the firmware by injecting an arbitrary code. In the latter case, given the weak implementation of the algorithm, we managed to extract the encryption key and determine the encryption algorithm, which also allows firmware modification.
The other three modems had no protection from integrity attacks, but a local access to COM interfaces was required to update the firmware.
The remaining two modems could be updated only though the carrier's network via Firmware Over-The-Air (FOTA) technology.
3. CSRF (five devices)
CSRF attacks can be used for various purposes, but the primary ones are remote upload of modified firmware and successful arbitrary code injection. Using unique tokens for each request is an efficient protection against this type of attacks.
4. XSS (four devices)
The scope of this attack is quite wide — from host infection to SMS interception. However, our research focuses mainly on its prime target — modified firmware upload bypassing AntiCSRF checks and the Same-Origin Policy.
First, you need to identify a modem for a successful attack. You can send all kinds of requests to exploit RCE or try to upload various updates via all the possible addresses, but it seems to be inefficient and too signally for a target user. The time of infection — from user detection to code injection, modification of modem settings, etc. — is also quite important in the real (not simulated) conditions.
For this very reason, you need to identify the target device properly. To do that, you must use a simple set of picture addresses, which can tell you the model of the modem. This method helped us to identify all the investigated modems 100%. An example of the code:
2. Code Injection
This stage is described in the previous section, points 1 and 2. The code can be injected either though RCE in web scripts, or though uploading infected firmware. The first method allowed us to penetrate five modems, it isn't that complicated.
Let's describe the vectors of the second method in detail.
Two modems used the same algorithm to protect firmware integrity: the digital signature of SHA1 hash sum by an asymmetric RSA key was carried out via an OpenSSL library. The verification was incorrect: after uploading the firmware (an archive), the web server extracted two main files from it — the one specifying the size of the verified data and the one with the signed hash sum. Next, the verification script obtained a public key from the file system and sent a request to OpenSSL functions to decrypt signature and compare hashsum. If hashsums were the same, the update was installed. The firmware compression algorithm had a feature — you could add additional files with the same names to the archive, but its first bytes wouldn't change. In addition, when we extracted the firmware, the later files overrode the earlier files. This allows changing the firmware without affecting data integrity checks.
The firmware of the third modem was encrypted by the RC4 algorithm with a constant keystream. As there were three different firmware versions on the Internet, you could get several bytes of plain text where there were bytes 0x00 in a file of the unencrypted firmware.
Then, we extracted the ISO image of the modem's virtual CDROM, which allowed us to decipher the first several kilobytes of the each firmware image. They contained the encryption algorithm and address of the encryption key. By XORing the two pieces of firmware, we obtained the plain text of the key itself.
Dmitry Sklyarov, an experienced cryptanalyst and reverse engineer from Positive Technologies, helped us a lot to conduct attacks against cryptographic protocols.
You can use CSRF for remote upload and HTML5 functions for transferring multipart/form-data, or XSS if an application is protected against CSRF (Huawei modem). Only three Huawei modems had this kind of protection, which could be bypassed via XSS, though. In all other cases, an attacker could use the HTML5 code located on a special web page (you can download an example from http://blog.kotowicz.net/2011/04/how-to-upload-arbitrary-file-contents.html).
Gemtek modems required a special utility for firmware updates installed on PC. In this case, firmware was uploaded though host internet connection via HTTP. After that, the firmware integrity was verified by checksums uploaded from the server. We failed to test this scenario.
However, it’s no use hoping that a vendor that doesn't properly check firmware integrity during upload protects it well enough.
3. Data Interception
Now we can execute an arbitrary code on the modem. You need to do three things: determine the modem’s location (later you will understand why) plus be able to intercept SMS messages and HTTP/HTTPS traffic.
The easiest way to determine location is to find the base station identifier (CellID). Then, with the operator’s MCC and MNC at hand, you can determine the victim’s exact location by means of some public bases, such as opencellid.org. Another method is to use the modem’s Wi-Fi card to scan nearby networks and determine the victim’s location area more accurately, given that one base station may have quite a broad coverage. We managed to obtain the CellID of six modems; Wi-Fi was available in two devices. We had to recompile and upload new network card drivers for one of the modems. Its previous driver allowed only the Ad Hoc mode, which prevents scanning nearby APs.
We studied two types of modems: with and without SMS support. The first type also didn’t allow SMS reading though AT commands. The second type allowed SMS reading via XSS. The messages are usually stored in the file system, and it’s not so difficult to get access to them for reading or sending SMS messages and USSD requests.
Traffic interception is more interesting. There are several ways to do that: by changing the modem’s DNS server settings, or replacing the modem’s gateway with the Wi-Fi interface and connecting to an hacker’s access point (that’s why you should know the victim’s location). The first method is simpler: changing the settings is a piece of cake, as they are also stored in the file system. We managed to do that for all but one modem. We studied the second method only in theory — switching the network card mode from ad hoc to active, connecting to an access point, and changing modem routing.
Not only HTTP traffic can be intercepted. By injecting and executing a VBS code on an HTML page, you can add your certificate to the Trusted Root Certification Authorities and successfully conduct MITM attacks:
4. SIM Card Cloning and 2G Traffic Interception
The attacks against SIM card applications were described in detail by Karsten Nohl and in the “#root via SMS” research. We still have to send binary SMS messages to SIM cards, as we failed to make modems send commands to SIM card applications via APDU.
It’s not that bad, though — by injecting an arbitrary code to a modem, you can extend the attack scope by means of binary SMS messages. Firstly, you can now send these messages “to yourself” from the target SIM card via the AT interface by switching the modem to the test mode and working with the COM port. You can do that in the background —the web interface will be available to the victim, who will hardly notice mode changeover. Secondly, you need to exchange data with the COM port via injecting a VBS code to the modem page and executing it with user rights with the help of social engineering.
Switching the modem to the test mode
The PowerShell script for sending a binary SMS message
Using FakeBTS is the next attack vector, and you also need to know the victim’s location for it. Having the victim’s exact location and IMSI at hand, we can use a fake base station nearby and wait until the subscriber connects to us, or we can force a base station (it is possible for five devices). If the operation is successful, we will be able to send binary SMS messages to the target SIM card without any restrictions from the operator.
5. PC Infection
If we penetrate a modem, we have very few attack vectors. However, infecting a PC connected to the modem provides us with many ways to steal and intercept the PC user's data.
You may have already heard of the main infection vector — bad USB. There are also some other methods involving social engineering:
- Virtual CDROM. Almost all the modems have a virtual drive image that is enabled for driver installation. You need to replace the image and force its mounting.
- VBS, drive-by-download. Code injection to an HTML page, or forced upload of executable files as updates or “diag utilities”.
- Browser 0-days. As an example, we used Adobe Flash 0-day found in the archives of Hacking Team.
- Vulnerable client software. One of the operators delivered vulnerable diagnostic software together with its modems, which allowed executing an arbitrary code on Windows and OS X PCs. Reference: we'd like to give a special thanks to Mikhail Firstov from Headlight Security for detecting this vulnerability.
Random Code Execution in the client software of a modem
6. APT Attacks
After infecting the modem and host, you need to stay in the systems somehow — save changes in the modem's even after it is switched off and prevent further firmware updates. It would be useful to detect and infect other vulnerable modems as soon as they will be connected to the PC. Most of the devices can be infected right at the phone store during "checking before buying".
There was another attack we failed to conduct — accessing the modem from the operator's network. Most vulnerable web servers listen at *:80, i.e. there's a chance that the modem's web server will be available from the operator's network. Only a few modems restrict connections incoming from the telecom's network or specify the address for listen 192.168.0.1:80.
7. Additional Information
We also studied getting access to a personal account by sending a USSD request and resetting password via an SMS message.
This vector was demonstrated during the "#root via SMS" presentation. The vulnerability was exploited through an XSS attack that could be conducted by sending an SMS message. However, an attacker can also do that in modems that allow SMS reading via RCE.
XSS exploitation results
All in all, we have a full infection cycle of devices and related PCs. Using the infected devices, we can determine location, intercept and send SMS messages and USSD requests, read HTTP and HTTPS traffic (by replacing SSL certificates), attack SIM cards via binary SMS messages, and intercept 2G traffic. Further infection can continue through the operator's networks, popular websites or equipment infected by worms (when connecting a new device).
What can we recommend to those clients who constantly work with such devices? Huawei modems with the latest firmware updates are the most protected. It is the only company that delivers firmware (the operators are only allowed to add some visual elements and enable/disable certain functions) and fixes vulnerabilities detected in its software.
Although 90 days had left since the service providers were informed of the vulnerabilities, many flaws remained unfixed. A crucial point: the vulnerabilities found during the research are not always fault of modem vendors. They can be added by telecom operators during software customization.
Author: Timur Yunusov, Positive Technologies
Credits: Alexey Osipov, Dmitry Sklyarov, Kirill Nesterov, Mikhail Firstov, and the SCADA Strangelove team (http://scadasl.org)