Connect Box CH7465LG: Unauthenticated Remote Code Execution (CVE-2019-13025)
October 1, 2019
The following work was conducted on the Connect Box
CH7465LG with the firmware version
Linux 3.12.14 on a Intel XScale CPU (armv6b). The device was supplied to me in February 2019 by Unitymedia as the default cable modem for new customers.
According to Unitymedia itself there are currently about 1.8 million customers using the Connect Box alone in Germany. 1 Since the Connect Box is also used by other ISPs such as KabelBW, UPC Austria and more the number of affected customers is even higher.
The device and firmware itself is produced by Compal and only branded by the different ISPs.
It is important to note, that the vulnerability listed below need access to the web interface of the cable modem. This can be achieved in two different ways:
- Being a client in the local network of the device.
- Accessing the web interface over the Internet via the remote maintenance feature.
A quick search of devices with open ports revealing the web interface with the help of Shodan shows several thousand affected devices. Not to mention that every single device is vulnerable if local access is available.
Remote Code Execution
The web interfaces offers
traceroute functions to test the network connection to other hosts. Although the web interface is protected by a password, most of the APIs do not require any form of authentication.
Internally the implementation on both functions builds upon calling the
traceroute binaries on the shell provided by the operating system. The input parameters are only verified on the client-side in the web interface but not correctly escaped or verified within API endpoint itself. Therefore the endpoint is vulnerable to command injection by manipulating the POST parameters sent to the endpoint by including an escape sequence as well as the desired command(s).
The ping and traceroute function both can be found in
cbn_http_xml_start_tracert. I’ve attached the shared library for readers which may be interested in having a closer look on their own.
Furthermore I’m planning to release a more detailed post about the whole process of:
- Finding the first vulnerability while examining the web interface.
- Gaining remote code execution.
- Dumping the firmware of the device.
- Further analysis of the firmware and the discovery of more vulnerabilities.
Nevertheless, I would like to point out (even if it should be obvious) that it is essential to always escape and verify the user input arguments when executing commands on the shell. It’s also recommended to avoid invoking the shell in general by using
exec() instead of
Proof of Concept
A PoC to sent arbitrary commands to be executed on the shell of the device can be found in my GitHub repository. By doing so we can for example start a telnet server on the device and connect to the provided debug CLI.
25 June 2019: First message to an employee from Liberty Global.
26 June 2019: First response as well as transfer of my issue to a superior.
28 June 2019: Submission of a written report to the proposed file sharing platform. Proposed date for full-disclosure is +90 days.
28 June 2019: Submission of the CVE ID request (CVE-2019-13025).
22 September 2019: I noticed an automatic firmware update (
CH7465LG-NCIP-188.8.131.52-2p6-NOSH) on my device which patches the vulnerability.
24 September 2019: Since I did not receive any confirmation or update since I submitted my report back in June, I asked whether there are any updates regarding the vulnerabilities.
On the same day I received the following message:
Our CPE security teams were already aware of the issue and in process of rolling out a solution to it via an update to these routers.
The first sentence of the message is obviously not verifiable for me. All I can say is, that I would have wished for more communication, regardless of whether the security team was already aware of the vulnerabilities or not. Still, I find it odd that a vulnerability as severe as a unauthenticated remote code execution affecting hundreds of thousands is allegedly already known for months and then finally patched a few days before the full-disclosure deadline.
Nonetheless I’m glad that the vulnerabilities have been fixed and that I’m finally able to publish my work.
25 September 2019: Originally planned date for full-disclosure (90-day deadline) of the vulnerabilities.
1 October 2019: Publication of this article and the GitHub Repository. Request sent to the CVE team to release the CVE entry to the public.