Invision Power Board 2.0.3 'login.php' SQL Injection: A Practical Guide

What this paper is

This paper is a tutorial explaining how to exploit a SQL injection vulnerability in Invision Power Board (IPB) version 2.0.3. Specifically, it details how to use a previously released exploit (referenced as exploit ID 1013) to extract a user's password hash. Once the hash is obtained, the tutorial guides the user on how to manually inject this hash into their browser's cookies to gain unauthorized access to the targeted IPB forum as that user.

Simple technical breakdown

The core of this exploit relies on a SQL injection vulnerability in the login.php script of IPB 2.0.3. This vulnerability allows an attacker to manipulate the database query that the application uses to authenticate users.

1. Exploitation: A Perl script (from exploit ID 1013) is used to send specially crafted requests to the vulnerable login.php page. These requests are designed to trick the database into returning sensitive information, in this case, the password hash associated with a specific user ID.
2. Data Extraction: The Perl script captures and displays the extracted password hash.
3. Session Hijacking (via Cookie Manipulation): The attacker then manually edits their web browser's cookie file. They add new cookie entries for the target website, specifically member_id and pass_hash, using the values obtained from the exploit.
4. Access: By making the browser present these forged cookies, the web application believes the user is already authenticated with the stolen credentials, granting access.

Complete code and payload walkthrough

The provided text is not a complete exploit script with code and payload bytes in the traditional sense. Instead, it's a tutorial that references an external exploit script (exploit ID 1013) and describes manual steps to achieve unauthorized access.

Let's break down the instructions provided:

• # danica jones <danica6699@gmail.com>: This is the author's name and contact information.
• Tutorial for the recent exploit released by Petey Beege.: States the purpose of the document and credits the original exploit author.
• 1. Get the exploit from http://www.milw0rm.com/id.php?id=1013 (https://www.exploit-db.com/exploits/1013/): This is a crucial instruction. It directs the user to obtain the actual Perl script that performs the SQL injection. The paper itself does not contain this script.
• 2. Make sure you have LWP::UserAgent perl module if not do this::
  • a. perl -MCPAN -e 'shell': This command opens an interactive Perl module installer (CPAN shell).
  • b. inside the perl shell, do this 'install LWP::UserAgent': This command within the CPAN shell installs the LWP::UserAgent Perl module. This module is essential for the external Perl exploit script to make HTTP requests to the target web server.
• 3. Run the exploit. Get the password hash for the desired login id: This is the execution phase of the external exploit.
  • ex. inv.pl http://forums.example.com 2 2: This is an example command line for running the external Perl script (inv.pl).
    • inv.pl: The name of the exploit script (not provided in this paper).
    • http://forums.example.com: The target URL of the vulnerable Invision Power Board installation.
    • 2: The member_id (user ID) for which to retrieve the password hash.
    • 2: The version of IPB. This likely helps the exploit script tailor its SQL injection payload to the specific version's database schema or vulnerabilities.
  • Where 2 is the login id and 2 for version 2 of IPB.: Clarifies the arguments for the example command.
  • Get the password hash: The output of this command is expected to be the password hash of the user with the specified member_id.
• 4. Open wordpad. Edit Mozilla Firefox's cookie file. Mine is located at C:\Documents and Settings\the1\Application Data\Mozilla\Firefox\Profiles\vspyhjb9.default\cookies.txt": This section describes the manual session hijacking step.
  • Open wordpad: A simple text editor.
  • Edit Mozilla Firefox's cookie file: The target is the browser's cookie storage. The path provided is specific to an older Windows version and a particular Firefox profile name, highlighting the manual and somewhat brittle nature of this step.
  • Add the following entries:: These are the lines to be added to the cookies.txt file.
    • forums.example.com FALSE / FALSE 1148708747 member_id 1: This line creates a cookie named member_id with a value of 1 for the domain forums.example.com. The 1148708747 is likely a Unix timestamp for the cookie's expiration. The FALSE values are standard cookie attributes.
    • forums.example.com FALSE / FALSE 1148708747 pass_hash ecb735f70028a9cdb819828f4aced78c: This line creates a cookie named pass_hash with the extracted password hash as its value. The timestamp is the same, implying the cookies are set to expire at the same time.
  • Notice the value of member_id and pass_hash taken from the values generated by the exploit.: Emphasizes that the member_id (which might be the same as the one targeted, or a default/admin ID) and the pass_hash must be the exact values obtained from the exploit script.
• 5. Fire up Mozilla Firefox and login to http://forums.example.com: After modifying the cookie file, the user is instructed to open Firefox. When Firefox requests the target URL, it will send the modified cookies.
• Enjoy!: A concluding remark.
• # milw0rm.com [2005-05-27]: Publication details.

Mapping of code fragments/blocks to practical purpose:

• inv.pl http://forums.example.com 2 2 (Example Command) -> Executes the external SQL injection exploit against a specific IPB forum, targeting user ID 2.
• install LWP::UserAgent (Perl CPAN command) -> Ensures the necessary Perl library is available for the exploit script to perform network requests.
• forums.example.com FALSE / FALSE 1148708747 member_id 1 (Cookie Entry) -> Manually injects a cookie to impersonate a user with member_id 1.
• forums.example.com FALSE / FALSE 1148708747 pass_hash ecb735f70028a9cdb819828f4aced78c (Cookie Entry) -> Manually injects a cookie with the stolen password hash, allowing the browser to bypass authentication for the targeted user.

Shellcode/Payload Segments:

There are no explicit shellcode or payload bytes presented in this paper. The "payload" is effectively the crafted SQL query sent by the external Perl script, and the "shellcode" is the act of manipulating browser cookies to achieve unauthorized access. The password hash itself (ecb735f70028a9cdb819828f4aced78c in the example) is the sensitive data extracted by the exploit.

Practical details for offensive operations teams

• Required Access Level: No initial access to the target system is required. The exploit targets a web application accessible over HTTP/HTTPS.
• Lab Preconditions:
  • A local or remote machine with Perl installed.
  • The LWP::UserAgent Perl module installed.
  • A text editor capable of editing plain text files (like WordPad, Notepad, or vim/nano).
  • Mozilla Firefox (or another browser whose cookie format is understood and can be manually edited).
  • Knowledge of the target IPB forum's URL.
  • Knowledge of a valid member_id for a user on the target forum.
  • The actual exploit script (inv.pl or similar) that performs the SQL injection. This tutorial assumes you have it.
• Tooling Assumptions:
  • Perl interpreter.
  • CPAN module installer.
  • A web browser (Firefox in the example).
  • A text editor.
  • The external exploit script (e.g., inv.pl).
• Execution Pitfalls:
  • Exploit Script Availability: The primary pitfall is not having the actual exploit script. This tutorial is useless without it.
  • IPB Version Mismatch: The exploit is specific to IPB 2.0.3. Using it against different versions may fail or cause unexpected behavior.
  • Incorrect member_id: Targeting a non-existent member_id will result in no hash being returned.
  • Cookie File Location/Format: The path to the cookie file is highly specific to the user's operating system and Firefox profile. Finding and correctly editing this file can be challenging. Cookie formats can also change between browser versions.
  • Timestamp Validity: While the timestamp is often ignored by modern browsers for session cookies, an invalid or extremely old timestamp could theoretically cause issues.
  • Server-Side Protections: Modern web applications often have WAFs (Web Application Firewalls) or other intrusion detection systems that could flag or block the SQL injection attempts.
  • Cookie Security: Modern web applications use more robust session management, often involving server-side session tokens and secure, HTTP-only cookies, making this manual cookie injection method less effective.
  • Hash Type: The tutorial assumes the extracted hash is directly usable. If the application uses salted hashes or a different hashing algorithm, this method would likely fail. The example hash ecb735f70028a9cdb819828f4aced78c appears to be a raw MD5 hash, which was common at the time.
• Tradecraft Considerations:
  • Reconnaissance: Identifying the IPB version is critical. This can often be done by looking at the HTML source code for version-specific comments or JavaScript files.
  • Anonymity: The Perl script will make direct connections to the target. Ensure appropriate anonymization techniques are used if required by the engagement rules.
  • Post-Exploitation: Once logged in, the operator has the privileges of the compromised user. Further actions would depend on the user's role and the engagement objectives.
  • Cleanup: Removing any temporary files or logs created during the operation.

Where this was used and when

• Context: This exploit targets Invision Power Board (IPB), a popular forum software. The vulnerability is a classic SQL injection in the login mechanism.
• Timeframe: The paper was published in May 2005. This indicates the exploit was relevant and likely used around that period. IPB 2.0.3 was released prior to this date. SQL injection was a prevalent and highly effective attack vector against web applications in the early to mid-2000s.

Defensive lessons for modern teams

• Input Validation and Sanitization: This is the most critical lesson. All user-supplied input (including login credentials, IDs, and any parameters passed to login.php) must be rigorously validated and sanitized to prevent SQL injection. This includes using parameterized queries or prepared statements.
• Web Application Firewalls (WAFs): Implement and properly configure WAFs to detect and block common SQL injection patterns. However, WAFs are not a silver bullet and can be bypassed.
• Secure Session Management:
  • Avoid relying solely on client-side cookies for authentication.
  • Use server-side session management with unique, unpredictable session IDs.
  • Implement session timeouts and secure session fixation prevention.
  • Use HTTP-only and secure flags for cookies.
• Regular Patching and Updates: Keep all web applications and their underlying frameworks (like IPB) updated to the latest stable versions to patch known vulnerabilities.
• Least Privilege: Ensure that the database user account used by the web application has only the necessary permissions. It should not have privileges to extract sensitive data like password hashes if it's not strictly required for its function.
• Strong Hashing and Salting: Use modern, strong password hashing algorithms (e.g., bcrypt, scrypt, Argon2) with unique salts for each password. This makes stolen hashes significantly harder to crack.
• Monitoring and Logging: Implement robust logging for web server and database activity. Monitor logs for suspicious patterns, such as unusual query structures or repeated failed login attempts.

ASCII visual (if applicable)

This exploit involves a client-side interaction with a web server and a manual manipulation step. A simple flow diagram can illustrate the process:

+-----------------+      +---------------------+      +-------------------+
| Attacker's      |----->| Target IPB Forum    |----->| Database          |
| Machine         |      | (login.php)         |      | (User Credentials)|
| (Perl Exploit)  |      +---------------------+      +-------------------+
+-----------------+               |
        |                       | (SQL Injection)
        |                       v
        |      +---------------------+
        |      | Attacker's Machine  |
        |      | (Edit Cookie File)  |
        |      +---------------------+
        |               |
        |               | (Inject Cookies)
        |               v
        |      +---------------------+
        |      | Attacker's Browser  |
        |      | (Firefox)           |
        |      +---------------------+
        |               |
        |               | (Send Request with Forged Cookies)
        |               v
        +-------------->+---------------------+
                        | Target IPB Forum    |
                        | (Authentication Bypass)|
                        +---------------------+

Source references

• Paper ID: 1014
• Paper Title: Invision Power Board 2.0.3 - 'login.php' SQL Injection (Tutorial)
• Author: Danica Jones
• Published: 2005-05-27
• Paper URL: https://www.exploit-db.com/papers/1014
• Raw URL: https://www.exploit-db.com/raw/1014
• Referenced Exploit: https://www.exploit-db.com/exploits/1013 (milw0rm.com ID 1013)

Original Exploit-DB Content (Verbatim)

# danica jones <danica6699@gmail.com>

Tutorial for the recent exploit released by Petey Beege.

1. Get the exploit from http://www.milw0rm.com/id.php?id=1013 (https://www.exploit-db.com/exploits/1013/)
2. Make sure you have LWP::UserAgent perl module if not do this:
     a. perl -MCPAN -e 'shell'
     b. inside the perl shell, do this 'install LWP::UserAgent'
3. Run the exploit. Get the password hash for the desired login id

ex. inv.pl http://forums.example.com 2 2

Where 2 is the login id and 2 for version 2 of IPB.

4. Open wordpad. Edit Mozilla Firefox's cookie file. Mine is located at

C:\Documents and Settings\the1\Application Data\Mozilla\Firefox\Profiles\vspyhjb9.default\cookies.txt"

Add the following entries:

forums.example.com        FALSE        /        FALSE		1148708747	  member_id        1
forums.example.com        FALSE        /        FALSE		1148708747        pass_hash        ecb735f70028a9cdb819828f4aced78c

Notice the value of member_id and pass_hash taken from the values
generated by the exploit.

5. Fire up Mozilla Firefox and login to http://forums.example.com

Enjoy!


# milw0rm.com [2005-05-27]