WordPress Paid Business Listings 1.0.2 Blind SQL Injection Explained

What this paper is

This paper details a security vulnerability found in version 1.0.2 of the WordPress Paid Business Listings plugin. The vulnerability is a Blind SQL Injection. This means an attacker can infer information from the database by observing the application's response to crafted SQL queries, even though the database's direct output isn't shown to the attacker. The attacker uses the presence or absence of a listing on a webpage to determine if their injected SQL statement evaluated to true or false.

Simple technical breakdown

• The Vulnerability: The plugin takes information submitted through a form (like business name, description, contact details) and uses it to create a listing. Crucially, it doesn't properly check or clean this input before using it in a database query.
• The Attack: An attacker can insert malicious SQL code into the form fields.
• Blind SQL Injection: The attacker doesn't see the database's raw output. Instead, they observe a side effect:
  • If the injected SQL code makes the database query evaluate to TRUE, the business listing appears on the website.
  • If the injected SQL code makes the database query evaluate to FALSE, the business listing does not appear.
• How it works: By sending many such requests with slightly different SQL code, the attacker can ask the database questions (e.g., "Does the database name start with 'w'?"). Based on whether the listing appears or not, the attacker can deduce the answer, character by character, to extract sensitive data.

Complete code and payload walkthrough

The provided paper does not contain executable code or a specific payload in the traditional sense of a shellcode. Instead, it describes an injection technique that is applied to the plugin's existing functionality. The "code" here refers to the crafted HTTP request parameters that exploit the vulnerability.

The core of the exploit lies in manipulating the POST request parameters sent to the WordPress backend when a user submits the business listing form.

Let's break down the example injection provided:

Original Request Parameters (Simplified):

action=paypal_form
pbl_listing_name=My+Company+Name
pbl_listing_description=My+business+description
... (other listing details) ...
pbl_listing_pkg_id=2

Exploited Request Parameters (with AND 1=1):

action=paypal_form
pbl_listing_name=My+Company+Name
pbl_listing_description=My+business+description
... (other listing details) ...
pbl_listing_pkg_id=2 AND 1=1

Exploited Request Parameters (with AND 1=0):

action=paypal_form
pbl_listing_name=My+Company+Name
pbl_listing_description=My+business+description
... (other listing details) ...
pbl_listing_pkg_id=2 AND 1=0

Explanation of Parameters:

• action=paypal_form: This parameter likely tells the plugin which function or handler to execute. In this case, it's related to processing a form submission, possibly for payment integration.
• pbl_listing_name, pbl_listing_description, etc.: These are standard parameters for submitting business listing details. The vulnerability is that the plugin does not properly sanitize the data submitted for these fields before incorporating them into a SQL query.
• pbl_listing_pkg_id=2 AND 1=1: This is the injected part. The attacker is appending AND 1=1 to the pbl_listing_pkg_id parameter.
  • pbl_listing_pkg_id=2: This is the legitimate value for the package ID.
  • AND 1=1: This is a SQL clause. In SQL, 1=1 is always true. When appended to a WHERE clause in a SQL query, it effectively makes the entire condition true, regardless of the original condition.
• pbl_listing_pkg_id=2 AND 1=0: Similarly, this appends AND 1=0. In SQL, 1=0 is always false. When appended to a WHERE clause, it makes the entire condition false.

How the plugin likely uses this:

The plugin's backend code would take the submitted pbl_listing_pkg_id value and use it in a SQL query, something like:

INSERT INTO business_listings (..., package_id, ...)
VALUES (..., '2 AND 1=1', ...);

(Note: This is a simplified representation. The actual query might be more complex, and the injection might occur in a WHERE clause during a retrieval operation, but the principle of injecting SQL is the same. The paper implies the injection affects whether the listing is added or displayed, suggesting it might be part of an INSERT or a SELECT query that determines display status.)

If the pbl_listing_pkg_id is treated as a string and directly concatenated into a SQL query, the injected AND 1=1 or AND 1=0 would alter the query's logic.

Mapping list:

• action=paypal_form: Triggers the form submission processing logic.
• pbl_listing_name, pbl_listing_description, etc.: User-provided data that is not properly sanitized.
• pbl_listing_pkg_id=2 AND 1=1: Injected SQL. AND 1=1 makes the condition true, leading to the listing appearing.
• pbl_listing_pkg_id=2 AND 1=0: Injected SQL. AND 1=0 makes the condition false, leading to the listing not appearing.

Shellcode/Payload Segment Explanation:

There is no distinct shellcode or payload bytes in this paper. The "payload" is the crafted HTTP request itself, designed to manipulate the application's logic through SQL injection. The "stages" are conceptual:

1. Initial Probe: Sending a request with AND 1=1 to see if a listing appears.
2. Negative Probe: Sending a request with AND 1=0 to confirm that the absence of a listing is the indicator for a false condition.
3. Data Extraction (Implied): Subsequent requests would use more complex AND conditions to extract data, e.g., AND (SELECT SUBSTRING(password, 1, 1) FROM wp_users WHERE ID = 1) = 'a'. The attacker would iterate through characters and positions until the listing appears, revealing one character of the extracted data at a time.

Practical details for offensive operations teams

• Required Access Level: Low. This is a web application vulnerability exploitable via a public-facing form. No authenticated access is strictly required to initiate the injection, though understanding the pbl_listing_pkg_id values might require some reconnaissance or guessing.
• Lab Preconditions:
  • A vulnerable WordPress installation with the Paid Business Listings plugin (version 1.0.2) installed and activated.
  • A "free listing" package configured in the plugin's admin panel. This is crucial because free listings appear immediately, providing the necessary feedback mechanism for the blind SQL injection.
  • The "Business Listings page" must be accessible and configured to display submitted listings.
• Tooling Assumptions:
  • Web Proxy: Essential for intercepting, modifying, and replaying HTTP requests. Burp Suite or OWASP ZAP are standard.
  • SQL Injection Tools (Optional but Recommended): Tools like sqlmap can automate the process of blind SQL injection once the vulnerability is confirmed. However, understanding the manual process is key.
  • Browser: To view the results on the Business Listings page.
• Execution Pitfalls:
  • Incorrect Package ID: If the pbl_listing_pkg_id is not correctly identified or if the "free listing" setup is not done, the feedback mechanism will not work.
  • WAF/IDS Evasion: Modern Web Application Firewalls (WAFs) or Intrusion Detection Systems (IDS) might detect common SQL injection patterns. Attackers may need to use encoding, alternative syntax, or character-by-character extraction to bypass these.
  • Timing: Blind SQL injection can be slow, especially when extracting large amounts of data. Patience and robust scripting are required.
  • Database Errors: While this is a blind injection, unexpected database errors could potentially reveal information or break the injection process if not handled carefully.
  • Plugin Updates: The vulnerability is specific to version 1.0.2. Later versions are likely patched.
• Tradecraft Considerations:
  • Reconnaissance: Identify the target plugin and version. Understand the form fields and their purpose.
  • Initial Testing: Use simple AND 1=1 and AND 1=0 tests to confirm the vulnerability and the feedback mechanism.
  • Payload Development: Craft payloads to extract specific data (e.g., usernames, hashed passwords, database version). This often involves using SQL functions like SUBSTRING, ASCII, CHAR, GROUP_CONCAT (depending on the database type).
  • Stealth: Avoid overly aggressive scanning. Use delays between requests. Consider using a proxy chain.
  • Post-Exploitation: If sensitive data is obtained (e.g., user credentials), plan for further exploitation steps (e.g., WordPress admin login).

Where this was used and when

• Context: This vulnerability was found in a WordPress plugin, a very common platform for websites. It would be exploited on any website using version 1.0.2 of the Paid Business Listings plugin.
• Approximate Dates: The paper was published on June 30, 2012. Therefore, the vulnerability existed and was likely exploitable in the period leading up to and around this date. Exploits of this nature can remain unpatched for extended periods on less actively managed websites.

Defensive lessons for modern teams

• Input Validation and Sanitization: This is the most critical lesson. All user-supplied input, especially data that will be used in database queries, must be rigorously validated and sanitized. Use parameterized queries (prepared statements) to prevent SQL injection entirely.
• Principle of Least Privilege: Ensure the database user account used by the web application has only the necessary permissions. This limits the damage an attacker can do even if they achieve SQL injection.
• Web Application Firewalls (WAFs): While not a silver bullet, WAFs can provide a layer of defense against common attack patterns. Keep WAF rules updated.
• Regular Patching and Updates: Keep WordPress core, themes, and plugins updated to the latest secure versions. This vulnerability was specific to an older version.
• Security Audits and Code Reviews: Regularly audit custom code and third-party plugins for vulnerabilities.
• Monitoring and Logging: Implement robust logging for web server and database activity. Monitor logs for suspicious patterns indicative of SQL injection attempts.
• Understand Blind SQLi: For defensive teams, understanding how blind SQL injection works is crucial for detecting and responding to such attacks. Look for unusual patterns of requests to the same URL with varying parameters, especially those that might be interpreted as SQL.

ASCII visual (if applicable)

This vulnerability is primarily about data flow and manipulation within a web application and its backend database. An ASCII visual can illustrate the flow of data and the point of injection.

+-----------------+      +-------------------+      +--------------------+
| Attacker's Input|----->| WordPress Plugin  |----->| Database (SQL Query)|
| (Form Fields)   |      | (Paid Business    |      |                    |
+-----------------+      | Listings v1.0.2)  |      |                    |
                         +--------+----------+      +---------+----------+
                                  |                        |
                                  | (Unsanitized Data)     | (Query Logic)
                                  |                        |
                                  v                        v
                         +--------------------+     +--------------------+
                         |  Web Server Logic  |     |  Database Engine   |
                         | (Processes Request)|     | (Executes Query)   |
                         +--------+-----------+     +---------+----------+
                                  |                        |
                                  | (Conditional Response) | (True/False Result)
                                  |                        |
                                  v                        v
                         +--------------------+     +--------------------+
                         |  Business Listings |<----|  Application Logic |
                         |       Page         |     | (Determines Display|
                         +--------------------+     +--------------------+
                                  ^
                                  |
                                  | (Listing Appears/
                                  |  Doesn't Appear)
                                  |
                         +--------------------+
                         |  Attacker Observes |
                         |    the Page        |
                         +--------------------+

Explanation of the Diagram:

1. Attacker's Input: The attacker crafts malicious input through the form fields.
2. WordPress Plugin: The vulnerable plugin receives this input.
3. Web Server Logic: The server processes the request, and the plugin's code attempts to use the input.
4. Database (SQL Query): The unsanitized input is incorporated into a SQL query.
5. Database Engine: The database executes the query.
6. Application Logic: Based on the result of the SQL query (whether it evaluated to true or false), the application logic decides whether to display the listing.
7. Business Listings Page: The page is rendered, either showing the listing (if the SQL condition was true) or not showing it (if the SQL condition was false).
8. Attacker Observes: The attacker watches the Business Listings page to infer the result of their injected SQL.

Source references

• Paper ID: 19481
• Paper Title: WordPress Plugin Paid Business Listings 1.0.2 - Blind SQL Injection
• Author: Chris Kellum
• Published: 2012-06-30
• Paper URL: https://www.exploit-db.com/papers/19481
• Raw Exploit URL: https://www.exploit-db.com/raw/19481
• Vendor Homepage: http://www.blazingtorch.com/
• Software Link: http://downloads.wordpress.org/plugin/paid-business-listings.1.0.2.zip

Original Exploit-DB Content (Verbatim)

# Exploit Title: WordPress Paid Business Listings v1.0.2 Blind SQL Injection
# Date: 6/29/12
# Exploit Author: Chris Kellum
# Vendor Homepage: http://www.blazingtorch.com/
# Software Link: http://downloads.wordpress.org/plugin/paid-business-listings.1.0.2.zip
# Version: 1.0.2

==============
Plugin Details
==============

This plugin has a 3 stage process, which includes a submission form page, a submission status page, and a business listings page.

The results of the form injection can be determined by viewing whether the listing appears on the business listings page.

===============
Testing Details
===============

When recreating this vulnerability, create a "free listing" package (leave the cost field blank) in the admin panel and select that package when submitting the form.

Free listings are added to the Business Listings page immediately after form submission, so this will allow you to immediately verify how your SQL statement was evaluated.

=====================
Vulnerability Details
=====================

Input data from the form submission is not properly sanitized.

Using blind SQL injection techniques, true statements will result in the listing appearing on the business listings page, while false statements will not.

=================
Injection Example
=================

Using Burp Suite or other proxy, intercept the post request when submitting the form and add AND 1=1 to the request before forwarding:

action=paypal_form&pbl_listing_name=My+Company+Name&pbl_listing_logo_url=&pbl_listing_description=My+business+description
&pbl_listing_phone=123-456-7890&pbl_listing_url=http%3A%2F%2Fwww.mywebsite.com%2F&pbl_listing_email=myemail%40address.com
&pbl_listing_address=123+Main+Street&pbl_listing_city=Durham&pbl_listing_state=North+Carolina&pbl_listing_zip=27707
&pbl_listing_cat_id=1&pbl_listing_pkg_id=2 AND 1=1

Submission of this request will result in the listing appearing on the business listings page. 

When submitting the request with AND 1=0, the listing will not appear on the business listings page.