Security Issues in ZTE Network Devices

Introduction

I'll start, perhaps, with a little background. My acquaintance with the network devices of Chinese companies dates back to 2006, when, working for one of the mobile operators, I met with Huawei routers. I must say that in that zoo the whole history of formation was clearly visible - from the first line with numbering similar to Cisco, repeating the command syntax and even using Cisco proprietary routing protocols and a bunch of jambs to add to the very “beautiful” and relatively reliable technique with its syntax and implementation features. As a matter of fact, even now I mainly work with the equipment of this company. You should not think that I think the ZTE equipment is much worse, but the software stuffing of subscriber devices is very surprising to me, no less

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 FXS port.

There is more than enough functionality for the home gateway here, I am interested in referring to the documentation, perhaps in this regard I was only upset with the routing when the PPPoE connection in the modem is enabled, because the gateway sends all packets only to this connection, ignoring the other PVCs. But these are still flowers, if you look at how he is doing with security.

In the first circle: telnet

The device responds standardly on port 23, asking for a username / password (root / root), I don’t write by default, below we will understand why. We get 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 telnet mounts the read-only root partition. Accordingly, the / etc / passwd file is mounted read-only, so we cannot change the password simply with the passwd command. Again, looking ahead, I can say that I managed to change this setting by directly editing the config. Having rummaged in a search engine, I found out that through telnet with 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 information about the configured accounts. After some searching, I found the file / var / tmp / version-cfg, which stores all the possible data in an open XML-like form.

A fragment of the configuration file

Unfortunately, this file is also read-only, and the executable files responsible for the operation of the hardware do not give hints, so we are done with the telnet interface.

In the second circle: Web-based interface

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



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

I set a simple task for myself - to automate the process of unloading, loading and editing the config. Armed with Fiddler, I sniffed the HTTP requests that walked in the process of using the interface and found out that after sending the authorization form data, I need to send a multipart / form-data POST request to /getpage.gch?pid=100. And then in the process of debugging I found out that I do not need to log in to download the config. Having looked more closely at the history of requests, I found that even without authorization, by going to the address192.168.1.1/manager_dev_config_t.gch , we get this page:



Backup button worked, Restore no. Nevertheless, I decided to go to the end, and in the end I got a couple of scripts (VBScript for windows), both accept the modem address as a parameter. I won’t bring the code here completely, so as not to produce juvenile kullhackers, this is just an emulation of HTTP requests, here 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 )

conclusions

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