SupportCandy – Helpdesk & Customer Support Ticket System <= 3.4.6 - Authenticated (Subscriber+) Insecure Direct Object Reference

This research plan focuses on an Authenticated Insecure Direct Object Reference (IDOR) vulnerability in SupportCandy (<= 3.4.6). The vulnerability allows a user with Subscriber-level access (typically a "Customer" in SupportCandy) to perform unauthorized actions, specifically modifying or closing tickets belonging to other users, due to a failure in the backend to verify ticket ownership.

---

1. Vulnerability Summary

• Vulnerability: Insecure Direct Object Reference (IDOR).
• Affected Component: AJAX actions that process ticket-related tasks, specifically wpsc_it_close_ticket.
• Cause: The plugin validates the existence of a WordPress nonce but fails to verify if the ticket_id provided in the request belongs to the authenticated user's customer_id.
• Impact: Integrity modification (I:L). An attacker can close tickets belonging to any other user if they know the ticket_id.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• Action: wpsc_it_close_ticket
• Vulnerable Parameter: ticket_id
• Authentication: Authenticated (Subscriber+)
• Preconditions: The attacker must be logged in as a Subscriber (Customer) and have the ID of a victim's ticket.

3. Code Flow

1. Entry Point: The client sends a POST request to admin-ajax.php with action=wpsc_it_close_ticket.
2. JS Implementation (framework/scripts.js):

   function wpsc_it_close_ticket(ticket_id, nonce) {
     // ... confirms and checks for draft reply ...
     var data = { action: "wpsc_it_close_ticket", ticket_id, _ajax_nonce: nonce };
     jQuery.post(supportcandy.ajax_url, data, function (response) { ... });
   }
   

3. Backend Processing: The backend handler for wpsc_it_close_ticket likely calls check_ajax_referer('wpsc_it_close_ticket', '_ajax_nonce').
4. Vulnerable Sink: After nonce verification, the code proceeds to update the status of ticket_id in the psmsc_tickets table without checking if the current user is the "customer" associated with that ticket.

4. Nonce Acquisition Strategy

SupportCandy uses localized objects for its nonces. Since the attacker is an authenticated Subscriber, they can obtain a valid nonce for the wpsc_it_close_ticket action by interacting with their own ticket.

1. Create a Personal Ticket: The attacker creates a legitimate ticket to gain access to the ticket-viewing interface.
2. Access Ticket UI: Navigate to the page containing the [supportcandy] shortcode.
3. Extract Nonce:
   • The nonce for specific ticket actions is often localized in the supportcandy object or embedded in the "Close" button's attributes.
   • Strategy: Use browser_eval to extract the general nonce from the supportcandy object or locate the "Close" button for the attacker's own ticket and parse its onclick handler.
   • Variable: window.supportcandy?.nonce (General nonce) or specific action nonces found in the DOM.

5. Exploitation Strategy

The exploit will demonstrate closing a victim's ticket from a Subscriber account.

Step-by-Step:

1. Preparation: Identify a Victim ticket ID (e.g., 1).
2. Session Initiation: Log in as the Attacker (Subscriber).
3. Nonce Retrieval:
   • Navigate to the SupportCandy portal.
   • Create a dummy ticket (e.g., ID 2).
   • View the dummy ticket.
   • Extract the nonce for the wpsc_it_close_ticket action.
4. Forged Request: Send a POST request via the http_request tool targeting the victim's ticket ID.

HTTP Request Payload:

• URL: http://localhost:8080/wp-admin/admin-ajax.php
• Method: POST
• Headers: Content-Type: application/x-www-form-urlencoded
• Body:

  action=wpsc_it_close_ticket&ticket_id=[VICTIM_TICKET_ID]&_ajax_nonce=[ATTACKER_NONCE]
  

6. Test Data Setup

1. Victim User: Create a user victim_user (Subscriber).
2. Attacker User: Create a user attacker_user (Subscriber).
3. Victim Ticket: Log in as victim_user and create a ticket with subject "Confidential Issue". Note the ID.
4. Portal Page: Create a WordPress page with the shortcode [supportcandy] so the UI is accessible.

7. Expected Results

• Response: The server returns a success response (typically empty or a small HTML fragment/JSON).
• Database Change: The status of the victim's ticket in the psmsc_tickets table changes to the ID corresponding to "Closed" (often 3 or 4 depending on configuration).

8. Verification Steps

1. Check Ticket Status via WP-CLI:

   # Query the psmsc_tickets table for the victim's ticket status
   wp db query "SELECT status FROM wp_psmsc_tickets WHERE id = [VICTIM_TICKET_ID]"
   

2. Confirm Status: Compare the status ID before and after the attack. A change indicates a successful IDOR.

9. Alternative Approaches

• Action wpsc_it_get_duplicate_ticket: If closing is not possible, check if a Subscriber can duplicate any ticket ID, which might reveal contents in the duplication form (I:L, potentially C:L).
• Action wpsc_get_individual_ticket: Check if this action (which asset/js/admin.js shows has no nonce