Title: Unauthenticated RCE via Angular-Base64-Upload
Severity: Critical - 10.0 (CVSS 4.0)
Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
Researcher: Ravindu Wickramasinghe | rvz (@rvizx9)
Product: angular-base64-upload
Vulnerable Versions:
< v0.1.21
Fixed Versions: >= v0.1.21
CVE: CVE-2024-42640
PoC Exploit: CVE-2024-42640
Exploit
The angular-base64-upload library, created by Adones
Pitogo, is a tool designed to simplify the process of uploading base64-encoded files in
Angular applications.
While it provides valuable functionality for developers, versions <=
v0.1.20, include critical security vulnerability that can lead to unauthenticated remote code
execution (RCE).
This blog article will explore the structure of the library, highlight these vulnerabilities, exploitation and provide
recommendations for mitigation.
This security issue was identified during a penetration test. It's important to note that this is not an inherent flaw in the library itself. Instead, it arises from the installation of a vulnerable version, particularly due to the presence of the demo folder included with the library installation. Recognizing that this vulnerability could potentially affect any server application that meets the relevant criteria to run the vulnerable component without the knowledge of users utilizing this library, it was decided to report it to MITRE after conducting an analysis of the library. Hope this address any concerns regarding this security issue.
The file structure of the angular-base64-upload library is as follows. For this angular-base64-upload, v0.1.20 version was used.
The versions up to v0.1.20, including itself, include a demo folder to demonstrate and test the functionality. This demo folder contains a PHP file named server.php. This file takes two parameters, base64 and filename, as user input to upload files to the server, and the uploaded content will be saved inside the demo/uploads directory.
The server.php code lacks any kind of file upload valdiations (assuming it's developed in that way because this suppose to be only a demo). This allows an attacker to write any file content with any filename to the server. The server.php code lacks any kind of file upload validations (assuming it's developed in that way because this is supposed to be only a demo). This allows an attacker to write any file content with any filename to the server. If there's an application using this vulnerable version of the angular-base64-upload library, and it's accessible through node_modules or bower_compontent directory, this allows attackers to write file content on the server. This will lead to unauthenticated remote code execution.
angular-base64-upload versions prior to v0.1.21 are vulnerable to unauthenticated remote
code execution via the
angular-base64-upload/demo/server.php endpoint. Exploitation of this vulnerability
involves uploading arbitrary file content to the server, which can subsequently accessed through
the angular-base64-upload/demo/uploads endpoint.
This leads to the execution of previously uploaded content which enables the attacker to achieve
code execution on the server.
The information and exploitation steps provided in this document are intended for educational
and research purposes only. The author disclaims any responsibility for the misuse of
this information or for any consequences that may arise from its application. By accessing this
content, you agree to use it responsibly and ethically. Any malicious use of the information
presented is strictly prohibited, and the author will not be held liable for any
damages or illegal activities resulting from the use of this information.
In this article two methods will be explained.
The automated script will look for vulnerable endpoints according to the base URL provided,
(Example: node_modules/angular-base64-upload/...)
and if the vulnerable demo folder is found it will proceed with exploitation.
By default the script will upload a php command shell (web shell) to the server. After that a terminal-like
interface will be provided to continously execute the commands on the victim server.
The script also have an option to provide a --rev flag when executing it. This will attempt
to upload a php reverse shell to the target server.
It will take the listener IP address and port to update the PHP-reverse-shell that will be
downloaded from @pentestmonkey
Then it will send the PHP file to the server.php After that it will send a request to the uploaded
php-reverse-shell and you'll get the reverse shell on the target. (Please note that the PoC exploit script and the security issue fix and verification scripts may be subject to updates with varying functionalities. You can refer to the README file in the GitHub repository for more information.)
Github PoC Exploit for Automated Exploitation:
https://github.com/rvizx/CVE-2024-42640
1. Send a curl request to the
{node_modules/bower_components}/angular-base64-upload/demo/server.php endpoint to see whether
it's the server is not responding with a HTTP response code 404. You'll probably get a 500. This can
be used to ideitify whether the target is
vulnerable or not. You can also test this with angular-base64-upload/demo/index.html (just
like in the poc exploit).
2. Send another curl POST request with a PHP command shell (This is discussed in the next
steps)
or a php-reverse-shell to the server. Write or
download the payload, then encode the content of the payload to base64.
Example:
3. Convert the payload in to Base64 format
4. Send the following request, which has shell.php as the filename and it's content as the base64 parameter values.
5. Now, access the shell.php uploaded to the server folder.
6. This will execute the cat /etc/passwd command on the server and its output will be shown in the HTTP response body (the content of the /etc/passwd file of the victim).
In order to fix the security issue,
In order to fix the security issue you can use the fix.sh provided below, this will find the
vulnerable directory structure, which is angular-base64-upload/demo
and it'll delete those directories. This script also identifies potential prior exploitations if there
are any remaining or unexpected file content present in the upload directory.
Please make sure to execute the script twice to verify the issue was fixed proerply.
GitHub Repository: (Fix and Verification):
Fix
and Verification Section
21/07/2024 - Requested a CVE from MITRE
22/07/2024 - Informed the Vendor (The project was not maintained anymore, the verndor
created
an issue looking
for
a new maintiner in 2022")
26/07/2024 - Tried to contact the vendor again (No response)
01/08/2024 - Informed MITRE that the libirary doesn't seem to be maintained anymore and I
didn't get any response from vendor so far.
22/08/2024 - MITRE Team Assigned CVE-2024-42640
11/10/2024 - Publicly disclosed the security issue details.