I recently researched a relatively new 5G-capable modem from Quectel: the RG500Q-EA. I identified a security issue with how the OTA download procedure operates which allows an attacker to execute commands on the modem as root.

Previous research

I've previously posted about an issue affecting older Quectel modems present in the PinePhone. The issue, which was assigned the CVE ID CVE-2021-31698, is similar to the one described in this article. The article presents some background on how the modem and the mainboard (the "host" machine) communicate - usually, the mainboard sends AT commands over a serial line to the modem, which runs its own black-box operating system entirely independent of the mainboard. These AT commands are parsed by a daemon running on the modem, which then indicates whether the command executed successfully and optionally returns some data.

Analyzing the daemon

In the previously mentioned issue, I described that the AT commands were parsed by a daemon on the modem called atfwd_daemon. While this is still technically somewhat true, a bulk of the core functionality is offloaded to other components or libraries. Some AT commands are executed by the modem's QDSP processor, which is at the time of writing still quite difficult to reverse engineer. The library we're interested in is libql_atcop.so, which is an ARMv8 shared library present on the modem's host OS.

I identified the vulnerable command AT+QFOTADL. In practice, this command is used to point to an OTA download link, for example:

AT+QFOTADL="https://sif.ee/Quectel-OTA.bin"

The modem downloads the OTA, extracts it, verifies whether it's installable, and finally installs it on the modem device.

This command is handled in libql_atcop.so by a procedure named ql_exec_qfotadl_cmd_proc():

This procedure first matches the provided schema and checks to see which protocol is being used (plain HTTP, HTTPS, or FTP):

Code flow is then passed to another procedure, which formats the provided URL into a system command using snprintf() and initiates the download:

Disassembling the binary further revealed that there is no user input sanitization in place and the provided user input is used in the command as-is, which is executed using system() (provided by a wrapper function in another library).

Code execution

From this, we can deduce that arbitrary command execution is possible. We can, for example, enter a valid schema and use backticks to execute our commands in a subshell. As an example, to reboot the modem:

AT+QFOTADL="http://`reboot`"

Due to the fact that the daemon runs as root, the code is also being executed as the root user on the modem.

As an example, in this Asciinema recording, I use the nc binary present to establish a reverse shell (over 5G!) to my server.

It's very possible that this vulnerability affects other Quectel products as well, as firmware is commonly reused, but I do not possess other hardware to test it on. Most probably, it affects all RG50xQ products, if not more. Vendor did not clarify which products this vulnerability affects.

As I mentioned towards the end of my previous blog post, where I detailed running my blog on the PinePhone's GSM/WWAN/GPS modem, I suspected that the daemon responsible for parsing AT commands on the modem's side is susceptible to OS command injection, as it uses a lot of system() calls. My hunch turned out to be true.

Communication with the PinePhone

Among other channels, the PinePhone communicates with the Quectel modem by sending AT commands to the modem over a serial line - /dev/ttyUSB2 on the PinePhone's side and /dev/ttyHSL0 on the modem's side.

The modem, which runs a full Linux install separate from the PinePhone's main OS, receives these commands, parses them, and executes them according to program logic. After this, the modem either returns OK or ERROR over the serial line back to the PinePhone. The daemon primarily responsible for this is atfwd_daemon.

Analyzing atfwd_daemon

Getting the daemon is easy. It's possible to set up adb access and extract it using adb. It's also possible to simply extract it from the firmware's update packages, as it's not encrypted in any way.

Loading atfwd_daemon in Ghidra reveals that the executable uses system() in 233 different places across the file. That's… quite a lot.

While using system() with user input is never a good idea, most of the calls cannot be exploited due to being hardcoded or the fact that user input is converted to an integer using sprintf():

However, there are a few places where user input is sprintf()-d as %s and no checks or sanitization is performed on user input.

One of these places is in a routine called quectel_handle_fumo_cfg_command():

Here we can see that param1[1] is being formatted as ipth_dme -dmacc %s &, which is then passed to system(). What's interesting to note here is that ipth_dme does not exist on the system at all, so this program would never run.

Traversing the program execution flow, we can see that the switch case in the previous screenshot is triggered when some part of user input begins with "dmacc". This is checked in a routine called quectel_parse_fumo_cfg_cmd_params():

The rest of the input remains relatively untouched.

Going further up the program flow, we can see that the command in question which parses this input is +QFUMOCFG:

Code execution

From this, we can deduce that arbitrary command execution is possible. We can, for example, use backticks to execute our commands in a subshell. As an example, to reboot the modem:

AT+QFUMOCFG="dmacc","`reboot`"

Due to the fact that the daemon runs as root, the code is also being executed as the root user on the modem.

As an example, in this Asciinema recording, I cat /etc/passwd and run id, and return the data to the PinePhone's OS over a serial line:

It's very possible that this vulnerability affects other Quectel products as well, as firmware is commonly reused, but I do not possess other hardware to test it on.

No, really. Despite the timing of this article, this is not an April Fool's joke.

PinePhone's GPS/WWAN/LTE modem

While developing software on the PinePhone, I came across this peculiar message in dmesg:

[   25.476857] modem-power serial1-0: ADB KEY is '41618099' (you can use it to unlock ADB access to the modem)

For context, the PinePhone has a Quectel EG25-G modem, which handles GPS and wireless connectivity for the PinePhone. This piece of hardware is one of the few components on the phone which is closed-source.

When I saw that message and the mention of ADB, I immediately thought of Android Debug Bridge, the software commonly used to communicate with Android devices. "Surely," I thought, "it can't be talking about that ADB". Well, turns out it is.

The message links to an article which details the modem in question. It also links to an unlocker utility which, when used, prints out AT commands to enable adbd on the modem.

$ ./qadbkey-unlock 41618099
AT+QADBKEY="WUkkFzFSXLsuRM8t"
AT+QCFG="usbcfg",0x2C7C,0x125,1,1,1,1,1,1,0

These can be sent to the modem using screen:

# screen /dev/ttyUSB2 115200 

For whatever reason, my input wasn't being echoed back, but the screen session printed out "OK" twice, indicating it had executed the commands fine.

After setting up proper udev rules and adb on my "host machine", which is the PinePhone, the modem popped up in the output for adb devices, and I could drop into a shell:

$ adb devices
List of devices attached
(no serial number)	device

$ adb shell
/ #

Because adbd was running in root mode, I dropped into a root shell. Neat.

It turns out the modem runs its own OS totally separate from the rest of the PinePhone OS. With the latest updates, it runs Linux 3.18.44.

Running a webserver

For whatever reason, I thought it'd be fun to run my blog on this thing. Since we were working with limited resources (around 48M of space and the same amount of memory), and the fact that my blog is just a bunch of static files, I decided that something like nginx (as lightweight as it is) would be a bit overkill for my purposes.

darkhttpd seemed to fit the bill well. Single binary, no external dependencies, does GET and HEAD requests only. Perfect.

I used the armv7l-linux-musleabihf-cross toolchain to cross compile it for ARMv7 and statically link it against musl. adb push let me easily push the binary and my site assets to the modem's /usrdata directory, which seems to have a writable partition about 50M big mounted on it.

The HTTP server works great. I decided to use ADB to expose the HTTP port to my PinePhone:

$ adb forward tcp:8080 tcp:80

As ADB-forwarded ports are only bound to the loopback interface, I also manually exposed it to external connections:

# sysctl -w net.ipv4.conf.all.route_localnet=1
# iptables -t nat -I PREROUTING -p tcp --dport 8080 -j DNAT --to-destination 127.0.0.1:8080

I could now access my blog on http://pine:8080/. Cool!

Throughput?

I ran iperf over ADB port forwarding just to see what kind of throughput I get.

$ iperf -c localhost
------------------------------------------------------------
Client connecting to localhost, TCP port 5001
TCP window size: 2.50 MByte (default)
------------------------------------------------------------
[  3] local 127.0.0.1 port 44230 connected with 127.0.0.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.6 sec  14.4 MBytes  11.4 Mbits/sec

So around 10Mb/s. Not great, not terrible.

The PinePhone itself is connected to the network over USB (side note: I had to remove two components from the board to get USB networking to work). Out of interest, I ran iperf over that connection as well:

$ iperf -c 10.15.19.82
------------------------------------------------------------
Client connecting to 10.15.19.82, TCP port 5001
TCP window size:  136 KByte (default)
------------------------------------------------------------
[  3] local 10.15.19.100 port 58672 connected with 10.15.19.82 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.4 sec  25.8 MBytes  20.7 Mbits/sec

Although I was expecting more, it doesn't really matter, as I was bottlenecking at the ADB-forwarded connection.

Further thoughts

I wonder how secure the modem is. It turns out a lot of AT commands use system() on the modem. I suspect some of those AT commands may be vulnerable to command injection, but I haven't looked into this further. It also doesn't really matter when dropping into a root shell using ADB is this easy.

At first glance, this seems like a perfect method to obtain persistence for malware. With root access on the host system, malware could implant itself into the modem, which would enable it to survive reinstalls of the host OS, and snoop on communications or track the device's location. Some of the impact is alleviated by the fact that all interaction with the host OS happens over USB and I2S and only if the host OS initiates it, so malware in the modem couldn't directly interact with the host OS.