Frontdoor to the Technicolor 7210

Frontdoor to the Technicolor 7210

In a previous article, I explained how to get root on the embedded Linux part of the Technicolor 7210 router by leveraging a remote code execution (RCE). This article on the other hand, will explain how one can leverage a “frontdoor” to gain the same level of access.

 This blog post was originally written in June 23rd, 2018. The vulnerability disclosed in this blog post, as far as I know is yet to be fixed. I haven't requested a CVE, neither am I aware if Technicolor did so. Disclosure timeline can be found at the end of the blog post.

Control Mechanism

The TC7210 has two operative systems (OS), the eCos real-time OS, and a Linux based embedded OS. The eCos OS is responsible for managing all network functionalities as well as the Network Attached Storage (NAS) functionalities provided by the Linux OS.

For that to happen, the eCos OS needs to be able to communicate with the Linux OS. As discussed in the previous article, the smbapp is the application responsible for managing the NAS functionality. A good indicator of how the application is receiving commands from the eCos OS is the fact that it listens on port 49182 (UDP).

By revisiting the string analysis performed previously it was possible to find other interesting strings in the smbapp application that indicated some sort of functionality to manage a Telnet server. The strings are: smbapp: Launching telnetd. and smbapp: Killing telnetd. It is possible to confirm this by loading smbapp in a disassembler and searching for references to those strings.

Telnetd control
Starting and stopping the Telnet daemon.

The code above is contained in a function called executeCommand which is called from a loop where the UDP packets to port 49182 are received.

Receiving the UDP packets.
Receiving the UDP packets.

Flow and Packets

The next step is to understand what is the format of the packet that needs to be sent to the smbapp in order to start the Telnet daemon. The executeCommand function is quite complex and has an awful amount of branching. As such it is easier to backtrack the flow of code execution taking into consideration all the branching that would lead to the Telnet daemon being launched.

Flow of execution needed to control the Telnet daemon.
Flow of execution needed to control the Telnet daemon.

From the flow of execution depicted above, we can see that the first word of the packet that needs to be sent is 0x107, the following word doesn’t really matter, and the last double word should be 0x00000001.


With this information, the next step was to hack up a script that would send the right bytes to the listening socket of the smbapp.

 The script needs to be executed with Python 3.

Using the script against the NAS functionality of the router, we get an awesome Telnet prompt. Further to the above, it is also possible to control an HTTP server (that exposes some CGI scripts), and whether the Linux OS responds to pings.

Outcomes of the execution of the script.

Hope this has been interesting and insightful!

Disclosure Timeline

  • 2018-06-24: First reported issues to Technicolor
  • 2018-06-24: Technicolor’s security team acknowledged receipt of the report
  • 2018-07-10: Asked for an update
  • 2018-09-06: Asked for an update
  • 2018-09-07: Technicolor’s security theme acknowledged the vulnerability and let me know that they’re in the process of fixing it
  • 2018-09-07: Informed Technicolor’s security team that I will continue to withhold disclosure and suggested a possible fix for this flaw and for a newly discovered way to exploit a previously reported RCE
  • 2018-10-08: Let Technicolor team know I had published the post on how I reversed engineer the firmware, asked if a CVE had been assigned and reminded that the 90 [sic] day grace period will end on October 24th
  • 2018-10-24: Released details through this blog post (120 days after reporting it)