Petrol Pump Management Software v1.0 - Remote Code Execution (RCE)

Petrol Pump Management Software v1.0 — Remote Code Execution (CVE-2024-29410)

This article explains the root cause, impact, detection, mitigation and secure development controls for the Remote Code Execution vulnerability (CVE-2024-29410) discovered in Petrol Pump Management Software v1.0. The vulnerability arises from insecure file upload handling for image/logo fields that allows an attacker to upload and execute arbitrary server-side code. The information below is written to help defenders, system administrators and developers understand and remediate the issue.

Summary and Risk

• Vulnerability type: Unrestricted file upload leading to Remote Code Execution (RCE).
• Affected component: Web-based image upload handler (logo/photos) in the application.
• Impact: An attacker who can authenticate or reach the upload endpoint can place a file that the webserver executes, allowing full takeover of the web application process and potentially the host.
• CVE: CVE-2024-29410.
• Severity: High — RCE in a web application typically allows further lateral movement and data theft.

Root Cause

The application accepted uploaded files and placed them in a web-accessible directory without sufficient validation and without protecting the upload directory from server-side code execution. Typical root-cause patterns observed with this class of vulnerability include:

• No verification of file extension or content-type (MIME) beyond user-supplied metadata.
• Reliance on file extension checks that can be bypassed (renaming or crafting files with double extensions).
• Storing uploaded files directly inside a directory served by the webserver, where files with server-side extensions (e.g., .php) will be executed when requested.
• Insufficient access controls on the upload endpoint (public or weakly authenticated).

Detection and Indicators

Detection should focus on identifying suspicious uploads and unexpected executable files in media directories.

• Search the web root for unexpected server-side files in upload/image directories (e.g., files with .php, .pl, .jsp extensions inside media or assets folders).
• Inspect web server access logs for GET requests to media paths that return 200 and appear to be PHP or other dynamic content.
• Look for POST requests to upload endpoints that include filenames with server-side extensions or content-disposition names that differ from expected image types.
• Monitor for new processes or abnormal outbound connections from the web server process.

Example defensive command (for administrators) to locate potential executable files under a web-accessible uploads directory:

find /var/www/html/uploads -type f \( -iname "*.php" -o -iname "*.phtml" -o -iname "*.jsp" \) -ls

Explanation: This command recursively finds files with server-side extensions under the specified uploads directory. It should be executed by administrators to detect suspicious files left by an attacker. On Windows/IIS, perform a directory search for similar filename patterns.

Mitigation and Immediate Remediation

If you administer a system that may be affected, apply these immediate mitigations while planning a permanent fix:

• Remove or quarantine any unexpected files in upload directories that have executable extensions.
• Prevent execution in upload directories (webserver configuration or .htaccess), see examples below.
• Restrict upload endpoint access: require strong authentication and authorization checks and add rate limiting.
• Audit logs and investigate for signs of compromise; if exploited, assume breach and perform incident response.

Permanent Fixes and Secure Design

Fixes should be applied in a layered manner: validate inputs, limit file capabilities, and configure the server so uploaded files cannot be executed.

• Validate file type server‑side: verify MIME type, file signature (magic bytes), and use strict extension whitelists (e.g., .png, .jpg, .gif).
• Store uploaded files outside the web root, or use a separate domain/subdomain and apply strict content-type headers when serving them.
• Normalize file names and use randomized or hashed filenames to avoid name collisions and path traversal.
• Set restrictive filesystem permissions (remove execute permission and use least-privilege users for the webserver).
• Harden the webserver so that upload directories do not execute server-side code.

Secure PHP File Upload Example

Below is a defensive PHP example that illustrates several good practices: validating the file type via getimagesize(), restricting extensions, storing files outside the web root, and generating randomized filenames.

<?php
// Defensive image upload handler (simplified)
$allowed_ext = ['jpg', 'jpeg', 'png', 'gif'];
$upload_dir = '/var/www/uploads_images/'; // Prefer outside web root
if (!is_dir($upload_dir)) {
    mkdir($upload_dir, 0755, true);
}
if (!empty($_FILES['image']['tmp_name'])) {
    $tmp = $_FILES['image']['tmp_name'];
    $orig_name = basename($_FILES['image']['name']);
    $info = getimagesize($tmp);
    if ($info === false) {
        http_response_code(400);
        echo "Uploaded file is not a valid image.";
        exit;
    }
    // Determine extension from image type, not user-supplied filename
    $mime = $info['mime']; // e.g. 'image/png'
    $ext_map = ['image/jpeg' => 'jpg', 'image/png' => 'png', 'image/gif' => 'gif'];
    if (!isset($ext_map[$mime])) {
        http_response_code(400);
        echo "Unsupported image type.";
        exit;
    }
    $ext = $ext_map[$mime];
    // Generate randomized filename
    $safe_name = bin2hex(random_bytes(16)) . '.' . $ext;
    $destination = $upload_dir . $safe_name;
    if (!move_uploaded_file($tmp, $destination)) {
        http_response_code(500);
        echo "Failed to save uploaded file.";
        exit;
    }
    // Optionally set safe permissions (no execute)
    chmod($destination, 0644);
    echo "Upload success. Stored as: " . htmlentities($safe_name);
}
?>

Explanation: This snippet ensures the uploaded file is a genuine image by using getimagesize() and derives the extension from the image's MIME type rather than trusting user input. It stores files outside the document root with randomized filenames and sets non-executable permissions. This reduces the chance that a crafted file will be executed by the webserver.

Webserver Configuration to Prevent Execution

Prevent the webserver from executing code in upload directories. Examples for Apache and Nginx follow.

# Apache: disable PHP execution in the uploads directory (in site config or .htaccess)

    Require all granted
    # Disable PHP handler
    
        php_admin_flag engine Off
    
    
        Require all denied
    

Explanation: The configuration above disables PHP engine execution in the uploads directory (if mod_php is present) and denies access to common server-side script extensions. Use the server’s configuration rather than .htaccess where possible for performance.

# Nginx: serve uploads as static files and never pass to PHP backend
location /uploads/ {
    alias /var/www/html/uploads/;
    autoindex off;
    # Do not allow execution of scripts
    location ~* \.(php|phtml|phar|pl|py|jsp|asp)$ {
        return 403;
    }
}

Explanation: For Nginx, the uploads location serves static content and explicitly returns 403 for requests that attempt to access typical server-side file extensions.

Developer Best Practices to Prevent Upload RCE

• Never trust client-provided MIME types or file extensions.
• Check file signatures (magic bytes) for image and document formats.
• Store files outside the webroot or in storage services designed for objects (S3, Azure Blob) and serve via signed URLs or a controlled proxy.
• Use content-disposition and content-type headers when serving files, and set Content-Security-Policy and X-Content-Type-Options: nosniff.
• Perform code reviews and static analysis focusing on file handling logic.

Detection Rules and Monitoring (Defender Guidance)

Focus on detecting uploads containing server-side file extensions and web requests that access newly created files under upload directories. Examples of monitoring actions:

• Alert on POST requests to upload endpoints where Content-Disposition filename contains suspicious extensions (e.g., .php, .phtml).
• Alert on GET requests returning 200 for .php files in directories normally used for images.
• File integrity monitoring on media directories to detect new or modified files with executable extensions.
• Runtime protection: WAF rules blocking file uploads that contain PHP tags (<?php) or other server-side markers.

Response and Incident Handling

If you discover evidence of exploitation:

• Isolate the affected host from networks to prevent further exfiltration or spread.
• Preserve logs and filesystem artifacts for analysis (do not modify originals; copy them securely).
• Conduct a full compromise assessment: check for web shells, scheduled tasks, persistence mechanisms and lateral movement.
• Rebuild or redeploy affected systems from known-good images after ensuring mitigation controls are in place.

References and Responsible Disclosure

This vulnerability has been publicly documented (see vendor and researcher reports). Organizations using the affected software should follow vendor advisories and apply vendor-supplied patches or updates where available. If you are a vendor or developer, prioritize a patch that fixes validation and storage logic and then encourage customers to apply the update and to harden their deployments as noted above.

Conclusion

Unrestricted upload handling remains a frequent source of high-severity vulnerabilities. The most effective defense is a layered approach: validate and sanitize uploads server-side, avoid executing files from upload directories, harden server configuration, and monitor for anomalous uploads or requests. Applying these best practices will protect applications from the kind of RCE described by CVE-2024-29410.