VWar 1.50 R14 'online.php' SQL Injection Explained

What this paper is

This paper, published by brOmstar from the Insecurity Research Team in August 2006, details a SQL injection vulnerability in the VWar application, specifically in the extra/online.php file, affecting versions up to v1.50 R14. The vulnerability allows an attacker to manipulate database queries by injecting malicious SQL code through the n parameter in the URL.

Simple technical breakdown

The online.php script in VWar versions up to 1.50 R14 constructs a database query using a variable named n. This variable is directly concatenated into the SQL query string without proper sanitization. An attacker can exploit this by providing specially crafted input for the n parameter. This input can alter the intended SQL query, allowing the attacker to extract sensitive information from the database, such as user credentials, or even modify data.

The core issue is that the application trusts user-supplied input ($n) and uses it to build a database query. When $n is used like this: FROM vwar".$n."_member, if $n contains SQL commands, they become part of the query executed by the database.

Complete code and payload walkthrough

The exploit paper provides a code snippet and an example exploit URL.

Code Snippet:

line 63: $query = $vwardb->query("
line 64:	SELECT memberid, name, lastactivity
line 65:	FROM vwar".$n."_member WHERE lastactivity > ".(time() -
line 66:                $onlinetime * 60)."
line 67: ");

Explanation:

• Lines 63-67: This block of PHP code constructs a SQL query.
  • $vwardb->query(...): This is a method call on a database object ($vwardb) to execute a SQL query.
  • SELECT memberid, name, lastactivity: This part selects three columns (memberid, name, lastactivity) from a table.
  • FROM vwar".$n."_member: This is the critical part. It constructs the table name by concatenating the string vwar, the user-supplied variable $n, and the string _member. This is where the SQL injection occurs because $n is not sanitized.
  • WHERE lastactivity > ".(time() - $onlinetime * 60)." : This is a standard WHERE clause that filters records based on the lastactivity column. It compares it to a calculated time (current time minus $onlinetime minutes).

Mapping:

• $query = $vwardb->query(" ... "); -> Executes a SQL query against the database.
• FROM vwar".$n."_member -> Vulnerable code fragment. This is where the attacker can inject SQL commands by manipulating the $n variable. The intention was likely to query a table named vwar_member (or similar, depending on $n's intended purpose, which is unclear from the snippet alone).

Exploit Example:

http://www.vwar.de/demo/extra/online.php?n=_member%20WHERE%20memberid=-999%20UNION%20SELECT%200,CONCAT(memberid,0x3A,name,0x3A,password),2%20FROM%20vwar_member%20%20/*

Explanation of the Exploit URL:

The exploit URL targets the online.php script and manipulates the n parameter. Let's break down the injected value for n:

_member%20WHERE%20memberid=-999%20UNION%20SELECT%200,CONCAT(memberid,0x3A,name,0x3A,password),2%20FROM%20vwar_member%20%20/*

URL-decoded:
_member WHERE memberid=-999 UNION SELECT 0,CONCAT(memberid,0x3A,name,0x3A,password),2 FROM vwar_member /*

Now, let's see how this injected string fits into the vulnerable code:

$query = $vwardb->query("SELECT memberid, name, lastactivity FROM vwar _member WHERE memberid=-999 UNION SELECT 0,CONCAT(memberid,0x3A,name,0x3A,password),2 FROM vwar_member /* _member WHERE lastactivity > ... ");

This is where it gets tricky. The original code expects $n to be a simple string to form a table name. The exploit uses _member as the start of the injected string, which might be intended to complete the table name vwar_member_member (which is likely not a real table, but the injection continues).

The crucial part is the UNION SELECT statement. This is a standard SQL injection technique.

• WHERE memberid=-999: This part is likely an attempt to make the original WHERE clause evaluate to false or to be bypassed. The -999 is an arbitrary value unlikely to exist.
• UNION SELECT 0,CONCAT(memberid,0x3A,name,0x3A,password),2: This is the core of the data exfiltration.
  • UNION SELECT: This combines the results of the original query (which is likely to return no rows due to memberid=-999) with the results of this new SELECT statement.
  • 0: This is a placeholder for the memberid column from the original SELECT. It's a dummy value.
  • CONCAT(memberid,0x3A,name,0x3A,password): This function concatenates (joins) several values together.
    • memberid: The user ID.
    • 0x3A: This is the hexadecimal representation of a colon (:). It's used as a separator.
    • name: The username.
    • password: The user's password (presumably stored in MD5 hash format, as hinted by the paper).
  • 2: This is a placeholder for the lastactivity column from the original SELECT. It's a dummy value.
  • FROM vwar_member: This specifies that the data for the UNION SELECT should be retrieved from the vwar_member table.
• /*: This is a SQL comment. It terminates the rest of the original query, effectively ignoring the WHERE lastactivity > ... part.

Payload Interpretation:

The injected payload attempts to:

1. Bypass or invalidate the original WHERE clause.
2. Perform a UNION operation with a crafted SELECT statement.
3. The crafted SELECT statement extracts memberid, name, and password from the vwar_member table.
4. It concatenates these values with colons as separators (memberid:name:password).
5. It returns dummy values for the other selected columns (0 and 2).
6. The /* comment ensures that the original query's remaining parts are ignored.

The output of this query, when executed by the web server, would be displayed on the webpage, revealing the concatenated user credentials. The paper also suggests encrypting the MD5 password again with MD5 and throwing it in a cookie, which is a further step to potentially bypass other security mechanisms or to use the stolen credentials.

Practical details for offensive operations teams

• Required Access Level: Unauthenticated remote access to the vulnerable web application.
• Lab Preconditions:
  • A running instance of VWar <= v1.50 R14.
  • A web server configured to serve the VWar application.
  • A database backend (e.g., MySQL) accessible by the web application.
  • Populated vwar_member table with at least one user record.
• Tooling Assumptions:
  • A web browser for manual testing or reconnaissance.
  • A web proxy (e.g., Burp Suite, OWASP ZAP) to intercept and modify HTTP requests.
  • SQL injection tools (e.g., sqlmap) could potentially automate this, but manual crafting is often necessary for complex injections or specific database versions.
• Execution Pitfalls:
  • URL Encoding: The exploit uses URL-encoded characters (%20 for space, 0x3A for colon). Ensure correct encoding/decoding when crafting payloads.
  • Database Specifics: The CONCAT function and hexadecimal notation (0x3A) are common in MySQL. If the target uses a different database (e.g., PostgreSQL, SQL Server), the syntax for concatenation and hex representation might differ.
  • Table/Column Names: The exploit assumes specific table (vwar_member) and column names (memberid, name, password). These might vary in different VWar installations or if the attacker doesn't know them precisely. The n parameter's role in forming the table name is crucial; if n was intended to be something else, the injection might need adjustment.
  • Output Display: The success of this specific exploit relies on the output of the SELECT query being displayed directly on the webpage. If the output is suppressed or logged elsewhere, the attacker might not see the stolen data.
  • WAF/IDS Evasion: Modern Web Application Firewalls (WAFs) and Intrusion Detection Systems (IDS) would likely flag the UNION SELECT pattern. Evasion techniques might be required.
  • Application Logic: The online.php script's overall logic might filter or process the output in ways that obscure the injected data.
• Tradecraft Considerations:
  • Reconnaissance: Identify the VWar version and confirm the vulnerable file (extra/online.php) and parameter (n). Use search engines with specific dorks (as provided in the paper: intext:"Powered by: Virtual War v1.5.0") to find potential targets.
  • Payload Crafting: Start with simple injections to confirm vulnerability (e.g., injecting a single quote ' to cause a syntax error). Then, build up to UNION SELECT for data extraction.
  • Data Exfiltration: The paper suggests a two-step process for passwords (re-encrypting MD5). This indicates a need to understand the application's authentication mechanisms.
  • Stealth: Avoid excessive requests that could trigger alerts. Use comments (/* */) to minimize the query's footprint.

Where this was used and when

• Context: This vulnerability was found in the "Virtual War" application, a tool for gaming clans. The exploit targets the extra/online.php script, which likely displays online members or related information.
• Timeframe: The paper was published on August 10, 2006. Therefore, the vulnerability existed and was exploitable around this period. It's a classic example of SQL injection prevalent in web applications of that era.

Defensive lessons for modern teams

• Input Validation and Sanitization: This is the most crucial lesson. Never trust user input. All data received from external sources (URL parameters, form fields, cookies) must be rigorously validated and sanitized before being used in database queries.
  • Parameterized Queries/Prepared Statements: Use these whenever interacting with a database. They separate SQL code from data, preventing injected code from being executed.
  • Whitelisting: Define acceptable input formats and reject anything that doesn't match.
• Principle of Least Privilege: Ensure the database user account used by the web application has only the necessary permissions. It should not have privileges to drop tables, modify schema, or access sensitive system tables unless absolutely required.
• Web Application Firewalls (WAFs): While not a silver bullet, WAFs can provide a layer of defense against common attack patterns like SQL injection by detecting and blocking malicious requests. Keep WAF rules updated.
• Regular Patching and Updates: Keep all applications, frameworks, and libraries updated to the latest secure versions. This vulnerability was in an older version of VWar, highlighting the importance of staying current.
• Secure Coding Practices: Train developers on secure coding principles, including how to prevent common vulnerabilities like SQL injection.
• Database Auditing and Monitoring: Implement logging and monitoring for database activities to detect suspicious queries or unauthorized access attempts.

ASCII visual (if applicable)

This vulnerability is primarily about how a web application constructs a database query. An ASCII visual can illustrate the flow of data and the point of injection.

+-----------------+      +-----------------+      +-----------------+
| Attacker's Input| ---> | Web Server      | ---> | Database Server |
| (URL Parameter 'n')|      | (Vulnerable PHP |      | (vwar_member table)|
+-----------------+      |  script)        |      +-----------------+
                         +-------+---------+
                                 |
                                 | (Constructs SQL Query)
                                 v
                         +-----------------+
                         | Malicious SQL   |
                         | Query Generated |
                         +-----------------+

Explanation:

1. The attacker sends a request with a malicious value in the n parameter.
2. The vulnerable PHP script on the web server receives this input.
3. Instead of sanitizing n, the script directly concatenates it into a SQL query string.
4. This results in a malformed or malicious SQL query being sent to the database server.
5. The database server executes the query, potentially revealing sensitive data or performing unintended actions.

Source references

• Paper ID: 2170
• Paper Title: VWar 1.50 R14 - 'online.php' SQL Injection
• Author: brOmstar
• Published: 2006-08-10
• Keywords: PHP, webapps
• Paper URL: https://www.exploit-db.com/papers/2170
• Raw URL: https://www.exploit-db.com/raw/2170

Original Exploit-DB Content (Verbatim)

.:[ insecurity research team ]:.
     .__..____.:.______.____.:.____ .
 .:. |  |/    \:/  ___// __ \:/   _\.:.
   : |  |   |  \\____\\  ___/\   /__ :. .
 ..: |__|___|  /____  >\___  >\___  >.:
   .:.. ..  .\/   .:\/:.  .\/.  .:\/:
 .   ...:.    .advisory.    .:...
         :..................: 1o.o8.2oo6 ..
 
 
  Affected Application: VWar <= v1.50 R14
 
 
 . . :[ contact ]: . . . . . . . . . . . . . . . . . . . . . . . . . . .
 
 
  Discoverd by: brOmstar
 
  Team: Insecurity Research Team
 
  URL: http://www.insecurityresearch.org
 
  E-Mail: brom0815@gmx.de
 
 
 
 . . :[ insecure application details ]: . . . . . . . . . . . . . . . . .
 
 
  Typ: Remote [x]  Local [ ]
 
       Remote File Inclusion [ ]  SQL Injection [x]
 
  Level: Low [ ]  Middle [ ]  High [x]
 
  Application: VWar
 
  Version: <= v1.50 R14
 
  Vulnerable File: extra/online.php

  Vulnerable Variable: n
 
  URL: http://www.vwar.de
 
  Description: Virtual War is a tool for gaming clans.
 
  Dork: intext:"Powered by: Virtual War v1.5.0"



 . . :[ code snippet ]: . . . . . . . . . . . . . . . . . . . . . . . . .


  line 63: $query = $vwardb->query("

  line 64:	SELECT memberid, name, lastactivity

  line 65:	FROM vwar".$n."_member WHERE lastactivity > ".(time() - 

                $onlinetime * 60)."

  line 66: ");

 

 . . :[ exploit ]: . . . . . . . . . . . . . . . . . . . . . . . . . . .
 

  example: if you want a list of userid/username/password's try this:


  http://www.vwar.de/demo/extra/online.php?n=_member%20WHERE%20memberid=-999%20UNION%20SELECT%200,CONCAT(memberid,0x3A,name,0x3A,password),2%20FROM%20vwar_member%20%20/*
 
  
  encrypt the md5-password again with md5 and throw it in a cookie... :-)
 


 . . :[ how to fix ]: . . . . . . . . . . . . . . . . . . . . . . . . . .
 
 
  o1.) open extra/online.php
 
  o2.) take a look at the following lines:

       41: if( !defined ("VWAR_COMMON_INCLUDED") )
 	
       42: {

       43: $vwar_root = $vwar_xroot;

       44: require_once ( $vwar_root . "includes/functions_common.php" );

       45: }
 
  o3.) add between line 44 and 45 this:

       require_once ( $vwar_root . "includes/_config.inc.php" );
 
  o4.) done!
 
 
 
 . . :[ greets ]: . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 
 
  buzzdee, camino and my lovely, sexy girlfriend!

# milw0rm.com [2006-08-10]