phpMyFamily 1.4.0 Authentication Bypass Explained

What this paper is

This paper details a vulnerability in phpMyFamily version 1.2.5 (and likely 1.4.0 as per the title, though the exploit is tested against 1.2.5) that allows an attacker to log in as the 'admin' user without knowing the password. It achieves this by manipulating the login query through a SQL injection technique.

Simple technical breakdown

The vulnerability lies in how the application handles user input during the login process. When a user tries to log in, the application constructs a SQL query to check the username and password against its database. The exploit uses a specially crafted username that tricks the SQL query into always evaluating the condition for the admin user as true, regardless of the actual password.

Essentially, it's like telling the database: "Find me a user where the username is anything OR 'a' is equal to 'a' (which is always true), AND the user is an admin. If you find such a record, let me in." Since the 'a'='a' part is always true, and the 'admin'='Y' part specifically targets the admin account, the query effectively bypasses the password check for the administrator.

Complete code and payload walkthrough

The provided "code" is not actual executable code in the traditional sense but rather a specific string that is input into the login form.

Login: "' OR 'a'='a' AND admin='Y'/*" (without quotes)
Password: (empty)

Let's break down the login string: "' OR 'a'='a' AND admin='Y'/*"

• ' : This single quote is likely intended to close an existing single quote that the application uses to delimit the username input in its SQL query. For example, if the query was SELECT * FROM users WHERE username = 'INPUT_USERNAME' AND password = 'INPUT_PASSWORD', this initial quote would close the opening quote for INPUT_USERNAME.

• OR 'a'='a' : This is the core of the bypass.

  • OR: This logical operator means that if the condition before it is false, the condition after it will be evaluated.
  • 'a'='a': This is a tautology, meaning it is always true. In SQL, 'a'='a' will always evaluate to true.

• AND admin='Y' : This part targets the administrator account.

  • AND: This logical operator requires both the condition before it and the condition after it to be true for the overall expression to be true.
  • admin='Y': This assumes that the database table storing user information has a column named admin (or similar) and that an administrator account is marked with a value of 'Y' (likely for 'Yes').

• /* : This is the start of a SQL comment. In many SQL dialects, /* ... */ denotes a multi-line comment. By placing this at the end of the crafted string, any subsequent parts of the original SQL query that were intended to check the password or other conditions are effectively ignored by the database.

Mapping of code fragment/block -> practical purpose:

• ' -> Closes the expected opening quote for the username in the SQL query.
• OR 'a'='a' -> Always evaluates to true, ensuring the OR condition is met.
• AND admin='Y' -> Specifically targets the administrator account by checking its designation.
• /* -> Comments out the rest of the original SQL query, effectively disabling password checks and other conditions.

Execution Flow:

1. The attacker enters the crafted string into the username field of the phpMyFamily login form.
2. The web application takes this input and constructs a SQL query. A hypothetical query might look like this:
   SELECT * FROM users WHERE username = '' OR 'a'='a' AND admin='Y'/* ' AND password = ''
3. The database executes this query.
4. The username = '' part is likely false or irrelevant due to the OR.
5. The OR 'a'='a' part makes the first part of the WHERE clause true.
6. The AND admin='Y' part further filters the results to only include rows where the admin column is 'Y'.
7. The /* comments out the rest of the query, including any password verification.
8. The query successfully finds the administrator record.
9. The application, seeing a valid record returned, logs the attacker in as the administrator.

Practical details for offensive operations teams

• Required Access Level: Unauthenticated access to the web application's login page.
• Lab Preconditions:
  • A vulnerable version of phpMyFamily (e.g., 1.2.5) deployed on a web server.
  • A database backend (likely MySQL) configured for the application.
  • An administrator account must exist in the database, marked with 'Y' (or equivalent) in an admin column.
• Tooling Assumptions:
  • A web browser for manual testing.
  • A web proxy (e.g., Burp Suite, OWASP ZAP) to intercept and modify requests if needed, although for this specific exploit, direct form submission is sufficient.
  • A SQL client to inspect the database schema if the admin column name or value is unknown.
• Execution Pitfalls:
  • Incorrect admin column name/value: The exploit relies on the specific naming and value of the administrator flag in the database. If the application uses a different column name (e.g., is_admin, role) or a different value (e.g., 1, true), the exploit will fail.
  • SQL Escaping/Sanitization: Modern web applications often implement robust input sanitization or prepared statements, which would prevent this type of SQL injection. This exploit is effective against applications with weak or no input validation.
  • Database Type Differences: While the syntax /* */ for comments is common, some database systems might use different comment syntaxes (e.g., -- for single-line comments in MySQL). The exploit might need minor adjustments.
  • Application Logic: The application might have additional checks after the SQL query that could prevent login even if the query returns a user record.
• Tradecraft Considerations:
  • Reconnaissance: Before attempting the exploit, an operator should try to understand the application's structure and identify potential database interaction points. Observing login behavior and error messages can provide clues.
  • Payload Crafting: If the exact admin column name or value is unknown, an operator might need to perform further SQL injection tests to enumerate database schema and user data.
  • Stealth: Direct form submission is generally noisy. If stealth is paramount, using a proxy to modify the request and then submitting it might be preferred. However, the exploit itself is a single, direct action.
• Likely Failure Points:
  • The application is not running a vulnerable version.
  • The database schema does not match the exploit's assumptions (column names, values).
  • Input validation or parameterized queries prevent the SQL injection.
  • The application performs additional, unbypassable checks after the initial authentication query.

Where this was used and when

This exploit was published in March 2005. At that time, phpMyFamily was a popular web-based application for managing family trees. Exploits like this were common against web applications that did not properly sanitize user input before incorporating it into SQL queries. This type of vulnerability would have been actively exploited by attackers in the mid-2000s to gain unauthorized administrative access to websites running phpMyFamily.

Defensive lessons for modern teams

• Input Validation and Sanitization: Always treat user input as untrusted. Implement strict validation and sanitization routines for all data received from clients.
• Parameterized Queries (Prepared Statements): This is the most effective defense against SQL injection. Use parameterized queries for all database interactions. This separates the SQL code from the data, preventing malicious input from being interpreted as executable SQL.
• Principle of Least Privilege: Ensure that database accounts used by web applications have only the necessary permissions. Avoid granting broad administrative privileges to application database users.
• Regular Patching and Updates: Keep all web applications and their dependencies updated to the latest secure versions. Vulnerabilities like this are often patched in later releases.
• Web Application Firewalls (WAFs): While not a foolproof solution, WAFs can help detect and block common SQL injection attempts by signature matching. However, sophisticated injections can sometimes bypass WAF rules.
• Secure Coding Practices: Train developers on secure coding principles, including the dangers of SQL injection and how to prevent it. Code reviews should include security checks.
• Database Schema Hardening: Avoid using easily guessable column names for sensitive information like administrative flags.

ASCII visual (if applicable)

This exploit is a direct manipulation of data sent to the server, not an architectural interaction. Therefore, an ASCII visual is not directly applicable to illustrate the exploit's mechanism. The interaction is primarily between the attacker's input and the web application's backend SQL query.

Source references

• Paper ID: 892
• Paper Title: phpMyFamily 1.4.0 - Authentication Bypass
• Author: kre0n
• Published: 2005-03-21
• Keywords: PHP, webapps
• Paper URL: https://www.exploit-db.com/papers/892
• Raw Exploit URL: https://www.exploit-db.com/raw/892

Original Exploit-DB Content (Verbatim)

# Tested with version 1.2.5 /str0ke

Login as admin without pass:

Login: "' OR 'a'='a' AND admin='Y'/*" (without quotes)
Password: (empty)

# milw0rm.com [2005-03-21]