Security issues in ZTE network devices

Introduction

I will begin, perhaps, with a small background. My acquaintance with the network devices of Chinese companies dates back to 2006, when, working for one of the mobile operators, I became acquainted with Huawei routers. I must say that the zoo clearly traced the whole history of formation - from the first line with a numbering similar to Cisco, repeating command syntax and even using proprietary routing protocols Cisco and a bunch of jambs in the appendage to a very “beautiful” and relatively reliable technique with its own syntax and implementation features. As a matter of fact, I still work mainly with the equipment of this company. I don’t think that I think ZTE equipment is much worse, but the software stuffing of subscriber devices is quite surprising, not less than the record of the show run command in the startup-config on the first Huawei routers.

Acquaintance

The object of my research was my home gateway ZTE H208L, combining the functions of an ADSL modem, router, WiFi access point, SIP telephony client with an FXS port.

There is more than enough functionality here for the home gateway; I’m referring to the documentation of interest, perhaps in this respect I was only upset by the routing when the PPPoE connection in the modem was turned on, because the gateway sends all packets only to this connection, ignoring other PVCs. But these are flowers, if you look at how things are going with security.

In the first circle: telnet

The device normally responds to port 23, requesting a username / password (root / root), I do not write by default, below you will understand why. We will fall into the shell:

BusyBox v1.01 (2012.03.06-03: 19 + 0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

# cat / proc / cpuinfo
system type: Amazon-S
processor: 0
cpu model: MIPS 34K V4.12
BogoMIPS: 222.00
wait instruction: yes
microsecond timers: yes
tlb_entries: 16
extra interrupt vector: yes
hardware watchpoint: yes
ASEs implemented: mips16 dsp mt
VCED exceptions: not available
VCEI exceptions: not available
# mount
/ dev / mtdblock6 on / type squashfs (ro)
/ proc on / proc type proc (rw)
tmpfs on / var type tmpfs (rw)
tmpfs on / mnt type tmpfs (rw)

So, we see that the root partition is read-only via telnet. Accordingly, the / etc / passwd file is mounted read-only, so we cannot change the password using the passwd command. Again, looking ahead, I can say that I managed to change this setting by direct editing the config. Having rummaged in a search engine, I found out that through telnet using three commands you can activate hidden settings pages, in particular, SIP settings and some others. I was interested in something else - is it possible to get any data about the configured accounts. After a brief search, I found the file / var / tmp / version-cfg, which stores all possible data in an open XML-like form.
')

Fragment of the configuration file

</Row> </Tbl> <Tbl name="TelnetCfg" RowCount="1"> <Row No="0"> <DM name="TS_Enable" val="1"/> <DM name="Wan_Enable" val="0"/> <DM name="Lan_Enable" val="0"/> <DM name="TS_Port" val="23"/> <DM name="TS_UName" val="root"/> <DM name="TS_UPwd" val="root"/> <DM name="Max_Con_Num" val="5"/> <DM name="ProcType" val="0"/> </Row> </Tbl> <Tbl name="RouteSYSRT" RowCount="1"> <Row No="0"> <DM name="Display" val="0"/> </Row> </Tbl> <Tbl name="L2BBridge" RowCount</code> 

Unfortunately, this file is also read-only, and the executable files that are responsible for the operation of the hardware do not give prompts, so this completes the work with the telnet interface.

In the second circle: Web interface

By the 404 error, we find out that we are dealing with the Mini web server 1.0 ZTE corp 2005. We get such a nice green interface after POST authentication (the default login and password is admin / admin)



Yeah, unloading the config file and manually correcting the telnet password in it, I calmed down. Not for long.

I set a task for myself simple - to automate the process of unloading, loading and editing the config. Armed with Fiddler, I sniffed out HTTP requests that walked through the interface and found out that after sending the login form I need to send a POST request to multipart / form-data at /getpage.gch?pid=100. And here, during the debugging process, I found out that I didn’t need to log in to download the config. After reviewing the query history more closely, I discovered that without authorization, by going to 192.168.1.1/manager_dev_config_t.gch , we get the following page:



Backup button worked, Restore no. I nevertheless decided to go to the end, and in the end I received a couple of scripts (VBScript for windows) as the parameter both accept the modem address. I will not give the code completely here, so as not to produce juvenile cool-watchers, this is just an emulation of HTTP requests, this is the main part

 Set HTTP = CreateObject("Msxml2.XMLHTTP.6.0") Set ArgObj = WScript.Arguments URL=ArgObj(0) BOUNDARY="------12345678" HTTP.open "POST", "http://"&URL&"/getpage.gch?pid=100" parameters=BOUNDARY&vbCrLf&"Content-Disposition: form-data; name="&Chr(34)&"config"&Chr(34)&vbCrLf&vbCrLf&"--"&BOUNDARY&"--"&vbCrLf HTTP.setRequestHeader "Content-Type", "multipart/form-data; boundary="&BOUNDARY HTTP.setRequestHeader "Content-Length", Len(parameters) HTTP.send( parameters ) 

findings

Are the problems identified critical? I doubt, in the end, this is a home gateway, and with the correct WiFi settings you will not break it this way. But in application in networks of organizations, given that the vulnerability affects some of the other devices, in particular, PON terminals (although the config there is no longer plain-text) without additional crutches seems to me questionable. My appeal to ZTE technical support was ignored by company representatives. Despite this, I do not feel any prejudice against the company's products - the device is quite competitive in terms of price / functionality. Unpleasantly just somehow, growing pains, or something.