- Zte Zxdsl 931wii Firmware Latest Version Free
- Zte Zxdsl 931wii Firmware Latest Version Download
- Zte Zxdsl 931Wii Firmware Latest Version
- Zte Zxdsl 931wii Firmware Latest Version Windows 10
- Zte Zxdsl 931wii Firmware Latest Version Update
Quite some time ago (late 2011) I got sufficiently bored to poke and prod the firmware of a ZTE ZXDSL 931WIIA brand VDSL2 device, primarily to find out if it had a usable telnet interface and/or a convenient way to run arbitrary code. I always meant to write up a description of what was hiding under this particular rock, but never got around to. Well, here we (belatedly) are.
Zte Zxdsl 931wii Firmware Latest Version Free
Disclaimers: Most things in the following are likely to be — more or less — particular to the exact model and firmware version (ZXDSL931WIIA_ElisaV2.8.2a_Z40_FI) I have. The model is probably discontinued by now, but perhaps the illustrated principles may be helpful for someone. If you still have one, don't try any of this at home if you're very attached to the device. Finally, the approach taken is a very 'manual' one (GNU binutils, dd, etc.), and more intelligent tools could well make it simpler.
tl;dr? There is a telnet interface (in this version), with hardcoded ZTE 'debugging' username:password pairs, allowing for full root shell access.
Getting Started
Out of the box, my device answered with a HTTP admin interface at port 80, and a telnet login prompt at port 23. However, the user names and passwords for the web admin interface did not work at all for the telnet login, which was a shame. The scant documentation available for the device did not mention the telnet side at all. The most straight-forward way to find out what the telnet login prompt was expecting seemed to be to obtain a copy of the firmware running on the device, and take look around.
The PPPoE client is a ZTE ZXDSL 931WII router. Broadband, militarized and I'd like 5 years back. ZTE Version, ZXDSL 831AIIV1.0.1i D18 IN Image with integrated Updater software. The Internal network has to use the private IP and for Internet access NATing happens in modem. Ams-user - Free ebook download as PDF File.pdf, Text File.txt or read. In May 2018, the OpenWrt forum suffered a total data loss. This archive is an effort to restore and make available as much content as possible. Content may be missing or not representing the latest edited version. Topic: Zte Zxdsl 931wii.
Below you can download zxdsl 531b firmware update driver for Windows. File name: zxdsl531bfirmwareupdate.exe Version: 1.0.5 File size: 10.371 MB Upload source: original install disk Antivirus software passed: McAfee Download Driver (click above to download). ZTE Zxdsl 831cii Firmware security vulnerabilities, exploits, metasploit modules, vulnerability statistics and list of versions (e.g.: CVE-2009-1234 or 2010-1234 or 20101234) Log In Register. ZTE ZXDSL 931VII v2 telnet blocked. I have this ZTE 931VII v2 HGW (BCM6368). In the past the telnet was enabled, so I got the line stats. 8) Now the device has a new firmware and telnet is disabled. I disassembled it and found UART port, connected it by USB, but it needs password even on the console.
Zte Zxdsl 931wii Firmware Latest Version Download
It would have been, of course, possible to start poking around looking for potential holes in the HTTP interface 'empirically'. Clearly, though, having access to a copy of the firmware on a real computer would make things significantly easier. However, the ISP who provided the device (Saunalahti/Elisa) had decided not to provide any firmware upgrade images available for downloading, opting instead to unilaterally push upgrades over a TR-069 remote management session.
After some searching, I located an image of a different firmware version (listed as V1.5.0c_Z31_FI2) from the (now defunct) ztefinland.com website. Based on circumstantial evidence, this seemed to be a version used by a different ISP (Sonera). Under the assumption that many bugs/misfeatures would be common to all versions, starting from this file felt like a reasonable plan.
Looking For a Hole
Zte Zxdsl 931Wii Firmware Latest Version
The firmware upgrade file format is likely to be common to several devices, but it was also mostly self-evident.
It seemed quite safe to say the file was a combination of some headers, followed by an executable image of some kind, followed by a squashfs-lzma filesystem image (the magic string of which is 'qshs'). For the record, squashfs-lzma was a (now discontinued) set of patches to the squashfs file system to make it support the LZMA compression algorithm; more recent versions of squashfs include this feature natively. A short dd if=firmware.img of=squashfs.img bs=56680 skip=1 (quick tip: modern GNU dd has a useful iflag=skip_bytes option) and unsquashfs later, I had an obvious root file system to play around in.
In order to dump the root filesystem of the firmware actually in my unit, any method for running arbitrary shell commands would do. A shell injection vulnerability in the HTTP admin interface seemed like a logical place to start from. Fortunately (or is that unfortunately?), it did not take long to find one.
I've misplaced my notes on the details of this middle part, so the following is an approximate overview of what happened. The (later) analysis for the login prompt of the telnet interface will be carried out in more detail, however.
In general, good candidates for shell injection vulnerabilities are any features involving operations that need root privileges. The HTTP interface has a page for configuring static routing table entries, which sounded like a promising candidate. After disassembling the httpd and following its references to lib/private/libcms_core.so, it became clear that to add a new static route, the box executed something to the tune of system('route add -net N netmask M gw G dev D');. The parameters N, M and G were verified to be IP addresses, but D was passed as-is, presumably because it was selected using a drop-down box in the HTTP interface.
As closely as I can recall, I plugged in a USB stick with a built-for-MIPS BusyBox on it (the version on the device was too stripped down), and ran a suitable route-adding command to get a remote shell open over netcat. After that, it was a simple matter of tar ... | nc to extract the contents of the existing firmware.
Telnet Login
Theoretically speaking, the task (getting access over telnet, running arbitrary code) was in a sense accomplished at this point. However, the shell injection method was both cumbersome and inelegant, especially given that there was a perfectly good telnet interface just waiting for acceptable login credentials. It was clearly time to go look at still more MIPS assembly.
The message given as the telnet login prompt was found only in the file lib/private/libcms_cli.so. As an educated guess, that seemed likely to contain the code for the command-line interface. Further, bin/telnetd linked against the library, and used symbols such as cmsCli_printWelcomeBanner and cmsCli_authenticate from it. Going purely on the name, the last sounded especially relevant.
$ mips-elf-readelf -Da lib/private/libcms_cli.so
Based on the above, the code for cmsCli_authenticate can be found by extracting 872 bytes at offset 0x2c68 in the file. That can be done with e.g. dd if=lib/private/libcms_cli.so of=auth.bin bs=1 skip=11368 count=872; mips-elf-objdump --architecture=mips:isa32 -EB -b binary -D auth.bin --adjust-vma=0x2c68. The full disassembly, along with the comments I wrote for myself, can be found in cmsCli_authenticate.txt. To make a long story short, however, it is essentially equivalent to the following C code. (Some minor details have been omitted.)
Zte Zxdsl 931wii Firmware Latest Version Windows 10
In other words, regardless of what user accounts have been configured in the HTTP interface, the telnet login prompt accepts either root:public or ztedebug:ztedebug (and nothing else) as valid credentials.
Zte Zxdsl 931wii Firmware Latest Version Update
Further Discussion
The telnet interface is not very polished, but it allows you to drop into a (root) shell with the sh command, which is nice. There is no reasonable way (that I know of) to register code to be executed automatically at startup, which is less nice, as it means all customizations that cannot be performed by setting NVRAM variables are lost on reboot. It is quite possible that some shell injection trick could be used by setting one of the NVRAM variables, but I have not investigated this further.
As far as I have been able to determine, both the telnet and HTTP interfaces are only visible to the physical Ethernet and local wifi interfaces, not the DSL/WAN side. So you do not have to worry about random people from the Internet logging in as ztedebug. On the other hand, if you have untrusted local clients in the network, you do have to worry about them.
There are a number of other curiosities in the firmware (for example, a rather bizarre way of doing DNS for clients behind a NAT), but those fall outside the scope of this text.
I've since heard anecdotally that there exists a newer Elisa-branded firmware version (ZXDSL931WIIA_ElisaV2.8.3_Z40_FI) that possibly disables the telnet interface entirely.
Comments are closed.