Verizon MiFi Invalidated CSRF Token for File Uploads

Advisory IDL9-46-493PublishedFebruary 09, 2022UpdatedFebruary 09, 2022
CategoryRemote File InclusionVendorVerizonProductVerizon MiFi 6620LVersion4.5

Risk Summary

The Verizon Mifi 6620L, version 4.5, allows an unauthenticated threat actor to upload an arbitrary file to any location on the device through the web interface. While a CSRF token is present, it is not validated by the server when uploading the file.

Technical Details

An unauthenticated threat actor can send a multipart/form-data POST request to http://my.jetpack/ with an arbitrary file in the body of the request. By default the file is saved to the ‘/tmp’ directory on the device. However, the ‘filename’ parameter is not correctly sanitized allowing a user to save the file to any location on the device by prepending ‘../’ to the file location. The web interface runs as the ‘lighttpd’ user, which prevents the file from being saved in locations not writable by the ‘lighttpd’ user. There are several sensitive files which are owned by the ‘lighttpd’ user which can be modified through the file upload vulnerable, including the ‘/sysconf/uiconfig.xml’ file. The ‘uiconfig.xml’ file controls certain settings in the web interface as well as the device UI.

HTTP request demonstrating directory traversal when uploading a file

The device's 'webui.log' shows the file was successfully updated

The test file was uploaded to '/sysconfig/uploadtest.txt'

A user could be tricked into clicking on a malicious link, which uses JavaScript to upload a modified ‘uiconfig.xml’. The modified ‘uiconfig.xml’ can alter the device settings such as changing the web interface password, removing web authentication, and modifying ‘QML’ source file used by the device UI.

When this issue is combined with the 'Escalated Privileges through Backup Restore Function', a threat actor could perform a device compromise as demonstrated in the below scenario.

  1. A victim connected to a MiFi device is tricked into clicking on a malicious link.
  2. The malicious link takes the victim to the attacker site which is running JavaScript code.
  3. The JavaScript uploads two files to the device from the victims browser; the first file is a modified ‘WiFi.qml’ file, which is used to replace the ‘Wi-Fi Name/Password’ menu option on the device UI, the second file is a modified ui_config.xml file used to control UI settings including which device UI, 'QML' scripts are loaded, and authorization of device functions.
  4. The web interface will read the ‘uiconfig.xml’ file each time a page is requested, whereas the device UI will only read the ‘uiconfig.xml’ file on reboot. The modified ‘ui_config.xml’ file is therefore configured to disable authentication when restarting the device.
  5. The JavaScript running on the victims’ browser waits until the two files are uploaded then redirects the user to the ‘/restarting’ web page (which can now be called without authentication) causing the device to reboot.
  6. Once the device has rebooted, the device UI loads the modified ‘ui_config.xml’, which has altered the location of the ‘Wi-Fi Name/Password’ menus’ QML file to the malicious ‘WiFi.qml’.
  7. The next time the user clicks on the ‘Wi-Fi Name/Password’ menu the malicious ‘WiFi.qml’ file is executed.
  8. When executed, the malicious QML file sends a GET request to the ‘/backup’ web page to obtain a valid CSRF token. After the CSRF token has been retrieved the QML sends a POST request to upload a modified backup configuration. The modified configuration includes a ‘root’ crontab file and a copy of ‘busybox’ . The crontab file will execute the ‘netcat’ command in ‘ busybox’ to create a reverse shell back to the attackers’ machine
  9. The attacker now has ‘root’ access to the device.