Pligg CMS 1.0.4 'story.php' SQL Injection Explained

What this paper is

This paper details a SQL injection vulnerability found in Pligg CMS version 1.0.4 and earlier. The vulnerability exists in the story.php file, specifically when handling the id parameter. By manipulating this parameter, an attacker can inject SQL commands to extract sensitive information from the database, such as user credentials.

Simple technical breakdown

The core of the vulnerability lies in how the story.php script processes the id parameter. It appears to use this id directly in a SQL query without proper sanitization.

An attacker can exploit this by:

1. Disrupting the original query: They add AND 1=2 to make the original query condition false.
2. Injecting a UNION SELECT: This allows them to combine the results of their malicious query with the (likely empty) results of the original query.
3. Specifying columns: They need to guess the number of columns the original query was expecting. The exploit uses 0,1,2,... up to a certain number.
4. Extracting data: They then use concat() to combine specific database fields (like user_login and user_pass from the pligg_users table) into a single output.
5. Terminating the query: The -- at the end comments out any remaining part of the original SQL query.

Complete code and payload walkthrough

The provided "code" is actually a crafted URL that acts as the exploit payload. There is no executable code or shellcode provided in the traditional sense within this paper. The exploit is delivered via a web request.

Let's break down the exploit URL:

http://server/path/story.php?id=2+AND+1=2+UNION+SELECT+0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,concat(user_login,0x3a,user_pass),17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34+from+pligg_users--

Here's a breakdown of each part:

• http://server/path/story.php?id=: This is the standard URL path to the vulnerable script and the beginning of the parameter we are targeting.
• 2: This is likely the original, legitimate id value that would normally be passed to story.php. The exploit assumes a valid ID exists, and this is a placeholder.
• +AND+1=2: This part is crucial. It appends a condition to the original SQL query that will always evaluate to FALSE. For example, if the original query was SELECT ... FROM stories WHERE id = 2, this modifies it to SELECT ... FROM stories WHERE id = 2 AND 1=2. This effectively ensures that no rows from the original query will be returned, making room for our injected UNION SELECT.
• +UNION+SELECT+: This is the core of the SQL injection. UNION is used to combine the result set of two or more SELECT statements. SELECT then specifies the columns we want to retrieve.
• 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,: These are placeholder values. The attacker is trying to determine the correct number of columns the original SQL query expects. By providing a sequence of numbers, they are testing how many columns the database can handle in the UNION SELECT statement. The exploit assumes the original query selects at least 15 columns before the vulnerable one.
• concat(user_login,0x3a,user_pass): This is the payload for extracting data.
  • concat(): This is a SQL function that concatenates (joins) multiple strings together.
  • user_login: This is a column name from the pligg_users table, likely storing the username.
  • 0x3a: This is the hexadecimal representation of the colon character (:). It's used as a separator between the username and password.
  • user_pass: This is another column name from the pligg_users table, likely storing the user's password.
  • Practical Purpose: This part of the query instructs the database to fetch the user_login and user_pass for each user, join them with a colon in between, and return this combined string.
• ,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34: These are more placeholder values. The exploit continues to provide numbers to match the expected column count of the original query. The total number of SELECT items (numbers and the concat function) must match the number of columns in the original query. This exploit assumes the original query has 34 columns.
• +from+pligg_users: This specifies the table from which to retrieve the data. pligg_users is a common table name for storing user information in web applications.
• --: This is a SQL comment marker. It tells the database to ignore any characters that follow it in the query. This is essential to comment out the rest of the original SQL statement, preventing syntax errors.

Mapping list:

• http://server/path/story.php?id=2: Target script and a presumed valid ID.
• +AND+1=2: Condition to make the original query return no results.
• +UNION+SELECT+: Operator to combine query results and start selecting specific data.
• 0,1,2,...15: Placeholder values to match the column count of the original query.
• concat(user_login,0x3a,user_pass): The core data extraction payload, concatenating username and password.
• 17,18,...34: More placeholder values to complete the column count.
• +from+pligg_users: The target table containing user credentials.
• --: SQL comment to terminate the original query.

Practical details for offensive operations teams

• Required Access Level: Unauthenticated (remote, unauthenticated access). This is a classic web application vulnerability.
• Lab Preconditions:
  • A running instance of Pligg CMS version 1.0.4 or earlier.
  • A web server (e.g., Apache, Nginx) configured to serve the Pligg CMS.
  • A database (e.g., MySQL) accessible by the web server.
  • At least one user account created in the Pligg CMS, populating the pligg_users table.
• Tooling Assumptions:
  • A web browser for manual testing or a scripting language (like Python with requests) for automation.
  • SQL injection tools (e.g., sqlmap) can automate the process of finding the correct column count and data extraction.
• Execution Pitfalls:
  • Column Count Mismatch: The most common failure point. If the attacker guesses the wrong number of columns for the UNION SELECT statement, the query will fail with a syntax error. The exploit provides a specific number (34 columns in this case), but this might need adjustment based on the exact Pligg CMS installation and its database schema.
  • Database Type Differences: While the exploit uses standard SQL syntax, some database systems might have slight variations in functions or syntax. This exploit is likely tailored for MySQL, which is common for PHP applications.
  • Web Application Firewalls (WAFs): Modern WAFs can detect and block common SQL injection patterns like UNION SELECT and keywords. The attacker might need to use obfuscation techniques or bypass methods.
  • URL Encoding: Spaces and special characters in the URL need to be URL-encoded (e.g., + for space, %3A for colon). The provided exploit uses + for spaces, which is common but might not always be interpreted correctly by all web servers or browsers.
  • Data Format: The extracted user_login:user_pass will be returned as part of the HTML output of the story.php page. An attacker needs to parse this output to find the credentials.
• Tradecraft Considerations:
  • Reconnaissance: Before attempting exploitation, understand the target web application's structure and version. Tools like Wappalyzer or manual inspection can help identify Pligg CMS and its version.
  • Enumeration: If the exact column count is unknown, an attacker would first perform column enumeration using a series of UNION SELECT statements with increasing numbers of placeholders until the query succeeds.
  • Data Exfiltration: Once credentials are found, they can be used to log into the Pligg CMS admin panel, potentially leading to further compromise.
  • Stealth: For authorized operations, ensure logging is configured to capture all actions. For unauthorized operations, an attacker would aim to be as stealthy as possible, avoiding excessive requests that could trigger WAFs or IDS.

Where this was used and when

• Context: This exploit targets the Pligg CMS, a social networking software. The vulnerability allows unauthorized access to user credentials.
• Approximate Year/Date: The paper was published on April 28, 2010. Therefore, this vulnerability was actively discussed and likely exploited around 2010. It's possible it existed in earlier versions of Pligg CMS and was exploited before its discovery and publication.

Defensive lessons for modern teams

• Input Validation and Sanitization: This is the most critical defense. All user-supplied input, especially parameters used in database queries, must be rigorously validated and sanitized. This includes:
  • Parameterized Queries (Prepared Statements): Use parameterized queries instead of concatenating user input directly into SQL strings. This separates the SQL code from the data, preventing malicious input from being interpreted as code.
  • Whitelisting: Only allow known-good characters or patterns in input fields.
  • Escaping: Properly escape special characters that have meaning in SQL.
• Web Application Firewalls (WAFs): Deploy and configure WAFs to detect and block common attack patterns, including SQL injection attempts. Keep WAF rules updated.
• Regular Patching and Updates: Keep all web applications and their underlying frameworks/CMS updated to the latest secure versions. Vendors typically release patches for 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 gain access to certain database tables.
• Error Handling: Configure applications to display generic error messages to users. Detailed database error messages can reveal information about the database schema and assist attackers.
• Security Audits and Penetration Testing: Regularly conduct security audits and penetration tests to identify and remediate vulnerabilities before they can be exploited.

ASCII visual (if applicable)

This exploit is a direct manipulation of a web request and database query. A visual representation of the flow is straightforward:

+-----------------+      +--------------------+      +-----------------+
| Attacker's Host |----->| Web Server (Pligg) |----->| Database Server |
+-----------------+      +--------------------+      +-----------------+
       ^                        |
       |                        | (Malicious HTTP Request with SQLi)
       |                        v
       |                +--------------------+
       |                | story.php script   |
       |                +--------------------+
       |                        |
       |                        | (Constructed SQL Query)
       |                        v
       |                +--------------------+
       |                | SQL Query Engine   |
       |                +--------------------+
       |                        |
       |                        | (Returns Data or Error)
       |                        v
       +------------------------+ (HTTP Response with Data)

Explanation:

1. The attacker crafts a malicious HTTP request targeting the story.php script on the web server.
2. The story.php script receives the request and, due to the vulnerability, includes the malicious SQL injection payload in its database query.
3. The SQL query engine on the database server processes the combined query.
4. If successful, the database returns the requested data (in this case, usernames and passwords) as part of the HTTP response.

Source references

• PAPER ID: 12436
• PAPER TITLE: Pligg CMS 1.0.4 - 'story.php' SQL Injection
• AUTHOR: Don Tukulesto
• PUBLISHED: 2010-04-28
• PAPER URL: https://www.exploit-db.com/papers/12436
• RAW URL: https://www.exploit-db.com/raw/12436

Original Exploit-DB Content (Verbatim)

/**************************************************************************

[!] Pligg CMS (story.php?id) SQL Injection Vulnerability
[!] Author	: Don Tukulesto (root@indonesiancoder.com)
[!] Homepage: http://indonesiancoder.com
[!] Date	: Tue, April 27, 2010
[!] Tune in	: http://antisecradio.fm (choose your weapon)

**************************************************************************/

[ Software Information ]

[>] Vendor	: http://www.pligg.com/
[>] Download: http://www.pligg.com/download/
[>] Name 	: Social Networking Software
[>] Version : 1.0.4 and previous
[>] License : GPL
[>] Type	: Non-Commercial ( open source CMS )
[>] Method	: SQL Injection

========================================================

[ Expl0!T ]

http://server/path/story.php?id=2+AND+1=2+UNION+SELECT+0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,concat(user_login,0x3a,user_pass),17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34+from+pligg_users--

[ Proof of Concept ]

http://[site]/story.php?id=2+AND+1=2+UNION+SELECT+0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,concat(user_login,0x3a,user_pass),17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34+from+pligg_users--

========================================================

[ Cheers ]

[>] Hussin X found bugs at Plig CMS Version 9.9.0. See reference:
    http://www.exploit-db.com/exploits/6146
[>] Indonesian Coder Team - AntiSecurity - ServerIsDown - SurabayaHackerLink
[>] My brother M364TR0N - kaMtiEz - Gonzhack - El N4ck0 - ibl13Z - arianom - YaDoY666 - ./Jack-
[>] neng elv1n4 - xshadow - SAINT - Cyb3r_tr0n - M3NW5 - Pathloader - Mboys - Contrex - amxku - inj3ct0r
[>] xnitro @xtremenitro.org - DraCoola - r3m1ck - Senot - ran - CherCut - Ghambass - CyberSector 31
[>] James Brown & Todd @packetstormsecurity.org - Maksymilian & sp3x @securityreason.com

[ Notes ]

[>] WE ARE ONE UNITY, WE ARE A CODER FAMILY, AND WE ARE INDONESIAN CODER TEAM