Exploiting Joomla's com_otzivi Component: A Blind SQL Injection Deep Dive

What this paper is

This paper details a Blind SQL Injection vulnerability found in the com_otzivi component for Joomla!. The vulnerability allows an attacker to extract sensitive information, specifically administrator credentials, from the Joomla! database. The exploit presented uses a technique to infer data by observing the application's response to crafted SQL queries.

Simple technical breakdown

The core of the vulnerability lies in how the com_otzivi component handles user input when constructing SQL queries. Specifically, it appears to be vulnerable to SQL injection through the Itemid parameter.

• SQL Injection: This is a common web security vulnerability where an attacker can interfere with the queries an application makes to its database.
• Blind SQL Injection: In this type of SQL injection, the attacker doesn't directly see the database's output (like error messages or query results). Instead, they infer information by observing the application's behavior, such as whether a page loads or displays different content based on the injected query.
• com_otzivi Component: This is a third-party extension for Joomla! that likely handles user reviews or testimonials.
• Itemid Parameter: This parameter is typically used in Joomla! to specify which menu item is being accessed. The vulnerability allows an attacker to manipulate this parameter to inject malicious SQL code.
• UNION SELECT: This SQL statement is used to combine the results of two or more SELECT statements. Attackers use it to append their own data to the original query's results.
• jos_users Table: This is a standard Joomla! table that stores user information, including usernames and passwords.
• concat() Function: This SQL function joins strings together. It's used here to combine different pieces of data (like username and password) into a single string for extraction.
• 0x3a: This is the hexadecimal representation of a colon (:), used as a delimiter to separate concatenated data.

The exploit works by sending a modified URL to the vulnerable Joomla! site. This URL contains an Itemid value that includes a UNION SELECT statement. This statement attempts to extract user information from the jos_users table and concatenate it with delimiters. The application's response (or lack thereof) to these crafted queries allows the attacker to deduce whether the injected condition is true or false, thereby extracting data character by character or field by field.

Complete code and payload walkthrough

The provided exploit snippet is a URL, which is the "payload" in this context, designed to be sent to a vulnerable web server.

http://server/index.php?option=com_otzivi&Itemid=15+and+1=2+union+select+concat(id,0x3a,username,0x3a,password),1+from+jos_users7,8,concat(username,0x3a,password),10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30/**/from/**/jos_users--

Let's break down this URL:

• http://server/index.php?option=com_otzivi: This is the base URL pointing to the Joomla! index file and specifying the com_otzivi component.
• &Itemid=15: This is the legitimate Itemid parameter, likely set to 15 for a normal operation of the com_otzivi component.
• +and+1=2: This part is crucial for the blind SQL injection. It's appended to the original query. The 1=2 condition is always false. When combined with AND, it effectively negates the original query's conditions, causing the application to return no results unless the injected UNION SELECT statement is processed. This is a common technique to force the application to execute the injected query.
• +union+select+concat(id,0x3a,username,0x3a,password),1+from+jos_users7,8,concat(username,0x3a,password),10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30: This is the core of the injection.
  • union select: This combines the results of the original (now negated) query with the results of the injected query.
  • concat(id,0x3a,username,0x3a,password): This function concatenates the id, username, and password fields from the jos_users table, using 0x3a (a colon) as a separator. This is the data the attacker wants to extract.
  • ,1: These are placeholder values. The UNION SELECT statement must have the same number of columns as the original SELECT statement. Since the original query likely selected multiple columns (though not explicitly shown in the snippet), these 1s fill in the remaining column slots. The exact number of these placeholders is critical and often determined through trial and error or by analyzing the application's behavior.
  • from jos_users7,8,concat(username,0x3a,password),10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30: This part is a bit unusual and potentially contains errors or is part of a more complex, less straightforward injection technique.
    • from jos_users7: This looks like an attempt to query a table named jos_users7. It's possible the table name is slightly different or this is a typo. More commonly, it would be from jos_users.
    • ,8,concat(username,0x3a,password),10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30: This section appears to be an attempt to provide more columns for the UNION SELECT statement. The concat(username,0x3a,password) here seems redundant if it's already being selected. The numbers 8 through 30 are likely placeholders for columns that are not directly being extracted but are needed to match the original query's column count. The presence of jos_users7 and then from jos_users suggests a potential confusion or an attempt to bypass filters.
• /**/from/**/jos_users: This is another part of the injected SQL. The /**/ are comments that can sometimes be used to bypass SQL filtering mechanisms that look for keywords like FROM. This part explicitly targets the jos_users table.
• --: This is a SQL comment that terminates the rest of the original query.

Overall Execution Flow (Conceptual):

1. The web server receives the crafted URL.
2. The Joomla! application processes the request, loading the com_otzivi component.
3. The component's code constructs an SQL query using the Itemid parameter.
4. Due to the injection, the query becomes something like:

   SELECT ... FROM ... WHERE Itemid = 15 AND 1=2 UNION SELECT CONCAT(id,':',username,':',password), 1, ..., 1 FROM jos_users -- [rest of original query]

5. The 1=2 condition makes the original query return no rows.
6. The UNION SELECT part then executes, attempting to fetch id, username, and password from jos_users (or jos_users7 if that's what the component actually queries first).
7. The concat() function formats the extracted data.
8. The application's response is observed. If the injected query successfully returns data, the application might display it, or its behavior might change in a way that indicates success. In a blind SQL injection, the attacker would typically send many such queries, slightly altering them to extract data character by character, observing differences in page load times or content.

Mapping list:

• http://server/index.php?option=com_otzivi&Itemid=15: Base URL and component invocation.
• +and+1=2: Condition to negate original query and force execution of injected UNION SELECT.
• +union+select: SQL keyword to combine results.
• concat(id,0x3a,username,0x3a,password): SQL function to combine and format desired data (ID, username, password) with colons.
• ,1: Placeholder columns to match the expected number of columns in the original query.
• from jos_users7,8,concat(username,0x3a,password),10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30: Potentially malformed or complex FROM clause, likely attempting to satisfy column count requirements and target user data.
• /**/from/**/jos_users: Alternative way to specify the FROM clause, using comments to bypass filters, targeting the jos_users table.
• --: SQL comment to ignore the remainder of the original query.

Practical details for offensive operations teams

• Required Access Level: Unauthenticated access to the target web application. The vulnerability is exposed via a public-facing URL parameter.
• Lab Preconditions:
  • A vulnerable Joomla! installation with the com_otzivi component installed.
  • Knowledge of the Joomla! version and the specific com_otzivi version is highly beneficial for confirming the vulnerability.
  • A web server environment (e.g., Apache, Nginx) running PHP and a MySQL database.
  • The jos_users table must exist and contain administrator credentials.
• Tooling Assumptions:
  • Web Browser: For initial reconnaissance and manual testing.
  • Burp Suite / OWASP ZAP: Essential for intercepting and modifying HTTP requests, automating the injection process, and observing responses.
  • SQLMap: A powerful automated SQL injection tool that can detect and exploit this type of vulnerability, including blind SQL injection, and extract data. It can significantly speed up the process of extracting credentials.
  • Custom Scripts (Python, PHP): For highly targeted or complex data extraction if automated tools fail or require specific logic.
• Execution Pitfalls:
  • Incorrect Column Count: The UNION SELECT statement requires the number of columns to match the original query. If this count is wrong, the query will fail. This often requires enumeration.
  • WAF/IDS Evasion: Web Application Firewalls (WAFs) and Intrusion Detection Systems (IDS) might detect the injected SQL keywords (UNION, SELECT, OR, AND, FROM, CONCAT). Techniques like using comments (/**/), case variations, or encoding might be necessary.
  • Database Specific Syntax: While the provided exploit uses standard SQL, different database systems (MySQL, PostgreSQL, etc.) have variations in functions and syntax. The exploit assumes a MySQL-like environment common for Joomla!.
  • Table/Column Names: The exploit assumes standard Joomla! table names (jos_users) and column names (id, username, password). These can be changed in custom Joomla! installations or by extensions.
  • Blind Extraction Complexity: Extracting data character by character in a blind SQL injection is time-consuming and requires careful scripting or automation. The attacker needs to craft queries that return a boolean result (e.g., "does the first character of the username match 'a'?") and observe the application's response to infer the correct character.
  • jos_users7 vs. jos_users: The presence of jos_users7 in the exploit is unusual. It might be a typo, or it could be an attempt to query a specific, potentially custom, user table. If jos_users is the correct table, the jos_users7 part might cause the exploit to fail.
• Tradecraft Considerations:
  • Reconnaissance: Use search engine dorks (inurl:/index.php?option=com_otzivi) to identify potential targets.
  • Enumeration: Before attempting full data extraction, enumerate the number of columns in the original query. This can be done by sending UNION SELECT NULL, NULL, ... with an increasing number of NULLs until the query succeeds.
  • Data Extraction Strategy: Plan the extraction method. Will you extract all admin credentials at once, or focus on specific users? Blind extraction is slow; consider the time constraints of an engagement.
  • Logging: Be aware of server-side logging. While the exploit itself might not generate much direct log noise beyond a web server request, the subsequent data extraction attempts (especially if automated) can be noisy.
  • Post-Exploitation: Once credentials are obtained, consider the next steps: privilege escalation, lateral movement, or data exfiltration, all within the scope of the authorized operation.

Where this was used and when

• Context: This vulnerability was identified and published in January 2010. It targets a specific Joomla! component (com_otzivi).
• Usage: Such vulnerabilities are typically exploited by attackers to gain unauthorized access to Joomla! websites. The primary goal here is to steal administrator credentials, which can then be used to:
  • Deface the website.
  • Distribute malware.
  • Use the compromised server for further attacks (e.g., as part of a botnet).
  • Steal sensitive user data stored within the Joomla! installation.
• Approximate Years/Dates: The exploit was published in 2010. Vulnerabilities of this nature can remain unpatched and exploitable for months or even years after their discovery, depending on the adoption rate of security updates by website administrators. Therefore, it's plausible this vulnerability was actively exploited in the period immediately following its disclosure and potentially for some time after.

Defensive lessons for modern teams

• Input Validation is Paramount: Always validate and sanitize all user-supplied input before it's used in database queries. This includes parameters in the URL, form data, and cookies.
• Parameterized Queries / Prepared Statements: Use parameterized queries or prepared statements provided by your database driver or ORM. These separate SQL code from data, preventing malicious input from being interpreted as SQL commands.
• Least Privilege Principle: Ensure the database user account used by the web application has only the minimum necessary privileges. It should not have privileges to drop tables, execute arbitrary commands, or access sensitive system tables if not strictly required.
• Regular Patching and Updates: Keep Joomla! core, all components, modules, and plugins updated to the latest stable versions. Vulnerabilities like this are often fixed in later releases.
• Web Application Firewalls (WAFs): Deploy and configure WAFs to detect and block common web attacks, including SQL injection attempts. However, WAFs are not foolproof and can be bypassed.
• Security Audits and Code Reviews: Regularly audit your web application code for security vulnerabilities. This includes looking for insecure handling of user input and potential SQL injection points.
• Monitoring and Logging: Implement robust logging for web server and database activity. Monitor these logs for suspicious patterns that might indicate an attack, such as unusual query structures or repeated failed login attempts.
• Component Security: Be cautious when installing third-party components. Research their security track record and ensure they are from reputable sources.

ASCII visual (if applicable)

This vulnerability is a direct manipulation of the request-response cycle between a client and a web server, without a complex architectural flow. Therefore, a detailed ASCII diagram is not strictly necessary for understanding the core exploit mechanism itself. However, a simplified representation of the request modification can be shown:

+-----------------+      +-----------------+      +-----------------+
| Attacker Client |----->| Web Server      |----->| Joomla! App     |
+-----------------+      | (Receives Req)  |      | (com_otzivi)    |
                         +-----------------+      +-----------------+
                                   |                        |
                                   | (Original Request)     | (Constructs SQL)
                                   v                        v
                         +-----------------+      +-----------------+
                         | Malicious URL   |----->| Vulnerable SQL  |
                         | (with injection)|      | Query           |
                         +-----------------+      +-----------------+
                                   |                        |
                                   | (Modified Request)     | (Executes SQL)
                                   v                        v
                         +-----------------+      +-----------------+
                         | Web Server      |----->| Database Server |
                         | (Forwards Req)  |      | (Returns Data/  |
                         +-----------------+      |  Errors/ Affects|
                                                  |  Response)      |
                                                  +-----------------+

Explanation:

• The attacker crafts a malicious URL that includes SQL injection payloads.
• The web server receives this URL and forwards it to the Joomla! application.
• The Joomla! application, specifically the com_otzivi component, processes the request and constructs an SQL query.
• Due to the injection, the constructed SQL query is altered to include the attacker's UNION SELECT statement.
• The database server executes this modified query.
• The database's response (or lack thereof, or altered behavior) is sent back through the web server to the attacker's client, allowing them to infer information.

Source references

• Paper ID: 10966
• Paper Title: Joomla! Component com_otzivi - Blind SQL Injection
• Author: Cyber_945
• Published: 2010-01-03
• Keywords: PHP, webapps
• Paper URL: https://www.exploit-db.com/papers/10966
• Raw URL: https://www.exploit-db.com/raw/10966

Original Exploit-DB Content (Verbatim)

<------------------- header data start ------------------- >
#############################################################
#        Joomla Component com_otzivi Blind SQL Injection Vulnerability
#############################################################
# Author          : Cyber_945
# Home            : Ar-ge.Org
# Greetz          : By.Danger,D3xer,LionTurk and All Ar-ge.Org Members
# Not3            : Ar-ge.Org Online
# Name            : com_otzivi
# Bug Type        : Blind SQL Injection
# Infection       : Adminin bilgileri alinabilir.
  Dork :          : inurl:/index.php?option=com_otzivi

#############################################################
=======================C=y=b=e=r=_=9=4=5================
< 


-- bug code start -- >
http://server/index.php?option=com_otzivi&Itemid=15+and+1=2+union+select+concat(id,0x3a,username,0x3a,password),1+from+jos_users7,8,concat(username,0x3a,password),10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30/**/from/**/jos_users--

=======================C=y=b=e=r=_=9=4=5================