Bookingor <= 1.0.12 - Missing Authorization

This research plan focuses on identifying and exploiting a Missing Authorization vulnerability in the Bookingor plugin (<= 1.0.12).

Since specific source files were not provided, the plan is designed to guide an automated agent through a systematic discovery and exploitation process based on the known vulnerability type (authenticated unauthorized action).

---

1. Vulnerability Summary

The Bookingor plugin fails to implement proper capability checks (e.g., current_user_can()) on one or more AJAX handlers. This allows any authenticated user, such as a Subscriber, to execute administrative functions. Typical impacts in booking plugins include modifying appointments, deleting schedules, or changing plugin settings.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• Vulnerable Action: An AJAX hook registered via wp_ajax_{action_name}.
• Parameter: Typically action plus specific data parameters (e.g., id, settings, booking_id).
• Authentication: Authenticated (Subscriber level).
• Preconditions: The attacker must have a valid session cookie for a Subscriber-level account.

3. Code Flow (Inferred)

1. Entry Point: The plugin registers an AJAX hook in its main class or an AJAX-specific class: add_action('wp_ajax_bookingor_...', 'handler_function_name');.
2. Lack of Authorization: The handler_function_name contains logic to modify the database or plugin state but does not call current_user_can('manage_options') or an equivalent check.
3. Potential CSRF Check: The function may or may not call check_ajax_referer(). If it does, a nonce must be obtained.
4. Sink: The function interacts with $wpdb or update_option() to perform the unauthorized action.

4. Nonce Acquisition Strategy

If the target AJAX handler requires a nonce, it is likely localized for the WordPress dashboard or specific frontend pages.

1. Identify Potential Nonces: Use grep -r "wp_create_nonce" . to find nonce action strings.
2. Identify Localization: Search for wp_localize_script to see how nonces are passed to the JS context. Look for variable names like bookingor_ajax_obj or bookingor_params.
3. Extraction:
   • Action: Create a subscriber user and log in.
   • Method: Navigate to the plugin's frontend booking page or the Subscriber's dashboard.
   • Execution: Use browser_eval to extract the nonce:

     // Example (inferred variable name)
     window.bookingor_ajax?.nonce || window.bookingor_params?.nonce
     

5. Exploitation Strategy

The agent will first identify the specific vulnerable action and then execute it as a Subscriber.

Step 1: Identify the Vulnerable Action
Search the plugin code for wp_ajax_ hooks that do not contain current_user_can.

grep -r "wp_ajax_" . | cut -d ":" -f 1 | xargs grep -L "current_user_can"

Look for actions like bookingor_save_settings, bookingor_delete_appointment, or bookingor_update_status.

Step 2: Construct the Payload
If a settings update action is found (e.g., bookingor_save_general_settings), the payload would look like this:

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

  action=bookingor_save_settings&nonce=[NONCE]&option_name=users_can_register&option_value=1
  

  (Note: The exact parameters depend on the handler's logic discovered in Step 1).

6. Test Data Setup

1. Create Subscriber: wp user create attacker attacker@example.com --role=subscriber --user_pass=password
2. Create Booking (if needed): If the vulnerability involves modifying bookings, create one first via WP-CLI or the admin interface.
3. Identify Shortcode: grep -r "add_shortcode" .
4. Create Page: wp post create --post_type=page --post_status=publish --post_title="Booking" --post_content="[bookingor_calendar]" (inferred shortcode).

7. Expected Results

• Success Response: The server returns a 200 OK or a JSON success message (e.g., {"success":true}).
• State Change: A setting in wp_options is changed, a booking is deleted, or a new user is created/modified, which should have been restricted to administrators.

8. Verification Steps

1. Check Settings: If the exploit targeted settings: wp option get [option_name].
2. Check Database: If the exploit modified bookings: wp db query "SELECT * FROM wp_bookingor_bookings WHERE id=[ID]" (table name inferred).
3. Check Capabilities: If the exploit modified user roles: wp user get attacker --field=roles.

9. Alternative Approaches

• Unauthenticated Check: If the plugin uses wp_ajax_nopriv_ for a sensitive action, try the exploit without any authentication.
• Blind Exploitation: If the action triggers an export or email, check for file creation in wp-content/uploads/ or use an out-of-band listener if SSRF is suspected within the unauthorized action.
• Global Options: Look for actions that use update_option() with user-supplied keys, which could lead to a full site takeover by enabling registration and setting the default role to administrator.