CVE-2022-24562: Exploiting IOTransfer insecure API CVE-2022–24562 - Tomer Peled - Medium

****Background****

Continuing the series about IPC vulnerabilities today we will look at another Chinese company, IObit.

IOTransfer by IObit is a program that allows the user to transfer files between their iPhone and their PC supposedly competing with apple’s iTunes. In order to operate IObit uses a node JS server for communication. The API is not obfuscated and does not contain any access control checks or any security measures at all. Understanding this communication can lead to arbitrary reading and writing to any location on the computer which can naturally lead to RCE with a bit of creativity.

****Finding the first lead****

Starting with process hacker I found that “IOtransfer” is deploying a process that listens actively over TCP. By its logo it seemed like a node.js application

AirServ listening

Going over the details available in process hacker I found that the process is running with elevated privileges

AirServ Privileges

The process was executed with a command-line ending in “iot_filetransfer.js” and the file details revealed it’s indeed a node.js server.

AirServ command line

Looking at the structure of the folder containing AirServ.exe we can see that the API is comprised from 5 files

folder structure

After opening “iot_filetransfer.js” I could clearly see that:

1. The file was the “main” of the API implementation

2. There is no obfuscation of the code

3. There seems to be two different types of listeners one for GET methods and one for POST methods

GET API Handler init

POST API Handler init

After making sure there is an ‘action’ parameter defined in the request the server will send the request to a dispatch function. This function is a parser for the actual requested method

Among those methods two are particularly interesting: “DOWNLOAD_FILE”, “UPLOAD_FILE”

****Code Review****

AirServ is using a system of tasks to execute its actions it was probably implemented this way so the server will be able to keep track of what was downloaded/uploaded and to perform actions concurrently

In order to upload/download a file, the user must specify a taskID while the userID can be anything…

In order to get a taskid the user first needs to create a new task

The task should contain the following fields:

After sending these fields with the correct request the JS server will conveniently send a new taskID as a response:

After creating the task we need to set the details for it in a follow-up request

Size -the size of the file we want to upload

Savedfilepath -The path we want to upload a file to

Fullpath -not used so it can be any string

MD5 -not checked so it can be any string

Filetype -set to 3 in order to allow path traversal

The last request is for the function “newuploadtask” with the local file we want to upload as the data.

This request will trigger the execution of the task we created coupled with the data we sent to create a file in our desired folder.

This is the complete flow I used to create a payload in the target machine:

A very similar procedure can be used to download files from any location in the target machine to a remote computer

****Conclusion****

IOTransfer’s AirServ lacks any kind of security measures. Even basic security measures such as obfuscation are not present. The fact that the service is running with ADMIN privileges is a major security hole. Blue Team personal should be aware of this and block IOTransfer communication port (7193) when not in use.

Github POC: https://github.com/tomerpeled92/CVE/blob/main/CVE-2022%E2%80%9324562

****Disclosure timeline****

24/01/2022 - disclosed vulnerabilities to Iobit

29/01/2022 - Iobit emailed us saying they will analyze the information

05/02/2022 -RCE disclosed to IOtransfer no response

07/02/2022-2nd mail sent to IOtransfer team

21/02/2022- CVE number received from MITRE for the RCE (CVE-2022–24562)

03/03/2022 -CVE numbers received from MITRE for the 4 other vulnerabilities

07/03/2022-3rd mail sent to IOTransfer team no transfer

08/03/2022 - email sent to iobit again

29/05/2022 - Final email sent to iobit containing this document

15/06/2022- Article published