Title: Path Traversal in Socket.io-file NPM module
Date: 18/05/2020
CVE-ID: 2020-15779
Advisory: https://www.npmjs.com/advisories/1519
Author: Thomas Sermpinis
Versions: <= 2.0.31
Package URL: https://www.npmjs.com/package/socket.io-file
Tested on: node v10.19.0, Socket.io-file v2.0.31, socket.io v2.3.0
Proof of Concept: https://www.exploit-db.com/exploits/48713
During one of my penetration tests for a local military equipment supplier, I faced a web application running on an embedded device that used web sockets in order to initiate the connection between the server and the client. There are several different technologies that can be used in the back-end system in order to make use of web sockets, but the client made use of Socket.io.
The web application was relatively small, with only a few entry points that did not seem to be vulnerable. All the modules were up to date and my enumeration started to go into a dead end. As there were more days for my pentest, I decided to dig deeper and I started analyzing more the request and researching about the npm modules that were included and were in use in the web application.
One of the functionalities was a configuration file upload, that was stored in a folder in the filesystem, by using the Socket.io-file npm module. Socket.io-file (2.0.31) is a node module for uploading files via the Socket.io module. Playing around with the requests I managed to bypass the restrictions and upload a file in a different folder from the expected one (I knew that as I had access to the backend of the system).
Client and project aside, the upload functionality of socket.io-file is vulnerable to improper input validation, allowing attackers to bypass upload directory restrictions and it allows them to upload files to paths of their choice in the underlying system.
Description of the Vulnerability
The default configuration of Socket.io-file comes with an upload functionality handled by websockets. When a user tries to upload a file with the web application, the following client side request is created in order for the file to be created:
42["socket.io-file::createFile",{"id":"u_0","name":"testfile.mp3","size":1,"chunkSize":10240,"sent":0,"data":{}}]
In order for this file to be created to the underlying system, the code from index.js of Socket.io-file is executed and the following part of the code, manages to merge the file path (supplied by the socket.io-file configuration) with the file name that was supplied by the user:
if(typeof options.uploadDir === 'string') {uploadDir = path.join(options.uploadDir, filename);}
As an example, if the user uploads a file with the name “testfile.mp3” and the server is configured to to store files in the “/home/Documents/socket-app/data” path the resulting path that Socket.io-file will create the file, will be “/home/Documents/socket-app/data/testfile.mp3”.
Because the aforementioned code makes no check on the file name, the upload request can be intercepted and the file name altered in a way that will move in certain paths of the system. The following example exploits this issue:
42["socket.io-file::createFile",{"id":"u_0","name":"../testfile.mp3","size":1,"chunkSize":10240,"sent":0,"data":{}}]
This request will generate the following path for the file to be stored “/home/Documents/socket-app/data/../testfile.mp3”, which means that the file will actually be created in “/home/Documents/socket-app/testfile.mp3” as the ../ characters will move the path one level lower in the filesystem.
From this example we can understand that we can write in several sensitive directories like the ~/ home directory (which includes the .ssh folder which allows us to rewrite the ssh configuration), in the root webserver directory (which can help us get a reverse shell under the right circumstances) and the cron directory (where we can inject cron jobs for code execution). Additionally, if the back-end system runs with superuser privileges (which is not so uncommon), the attacker can use this vulnerability to create files in even more sensitive paths (e.g. /root and /etc). As an example, we can write the /etc/passd file of our implementation like the following:
42["socket.io-file::createFile",{"id":"u_0","name":"../../../etc/passd","size":1,"chunkSize":10240,"sent":0,"data":{}}]
Issue Replication
In order to replicate the issue, the following steps have to be executed:
- Setup a proxy to intercept HTTP and WebSocket requests (e.g. Burp Suite or OWASP Zap)
- Upload a file using the Socket.io-file web application and intercept the websocket request
- Change the “name” parameter by adding ../ and specifying the needed path:
- 42[“socket.io-file::createFile”,{“id”:”u_0″,”name”:”../../../Downloads/testfile.mp3″,”size”:1,”chunkSize”:10240,”sent”:0,”data”:{}}]
- This example will create the testfile.mp3 file in the Downloads directory of the current user (our test server stores files in “/home/ubuntutest/Documents/socket-app/data”)
Remediation
No fix is currently available. Consider using an alternative package until a fix is made available.
Vulnerability Disclosure Timeline
Following the npm guidelines for vulnerability disclosure (“If maintainers are unresponsive after 45 days, npm Security makes the advisory public”), we responsibly disclosed this vulnerability on 18th of May 2020.
- Initial Disclosure: 18th May 2020
- Security Team Validation: 18th May 2020
- Advisory Release: 7th July 2020
- CVE-ID Assignment: 15th July 2020
- PoC Release at exploit-db.com: 27th July 2020