iZooto <= 3.7.20 - Missing Authorization

This research plan outlines the process for identifying and exploiting a missing authorization vulnerability in the iZooto – Web Push Notifications plugin (versions <= 3.7.20).

1. Vulnerability Summary

The iZooto plugin fails to implement proper capability checks on certain AJAX or initialization handlers. This "Missing Authorization" vulnerability allows unauthenticated attackers to invoke functions that were intended for administrative use, potentially leading to unauthorized modification of plugin settings, such as the iZooto App ID or integration keys.

2. Attack Vector Analysis

• Endpoint: wp-admin/admin-ajax.php or a hook on admin_init / init.
• Action (Inferred): Likely iz_save_settings, izooto_save_settings, or sync_izooto_settings.
• Payload Parameter: action, nonce (if applicable), and setting fields like izooto_app_id.
• Authentication: Unauthenticated (as per the vulnerability description).
• Preconditions: The plugin must be active.

3. Code Flow (Inferred)

1. The plugin registers an AJAX action or an admin_init hook in the main plugin file or an includes class (e.g., izooto.php or includes/class-izooto.php).
2. Entry Point: An unauthenticated request is sent to admin-ajax.php?action=[VULNERABLE_ACTION].
3. Missing Check: The handler function (e.g., iz_save_settings()) is invoked. It likely lacks a current_user_can( 'manage_options' ) check.
4. Sink: The function processes user-supplied input from $_POST and passes it to update_option(), allowing settings to be overwritten.

4. Nonce Acquisition Strategy

To determine if a nonce is required and how to obtain it:

1. Locate Registration: Search for the action registration:
   grep -rn "wp_ajax_" .
2. Analyze Handler: Check if the handler uses check_ajax_referer() or wp_verify_nonce().
3. Identify Localization: If a nonce is required, find where it is passed to the frontend:
   grep -rn "wp_localize_script" .
4. Extraction:
   • Identify the script handle and the object name (e.g., izooto_ajax_obj).
   • Find which page enqueues this script (typically the plugin settings page, but sometimes the public frontend for subscriber tracking).
   • If available on the frontend, create a post/page to trigger the script if necessary:
     wp post create --post_type=page --post_status=publish --post_content='[izooto_shortcode]' (Verify actual shortcode name via grep -r "add_shortcode" .).
   • Navigate to the page using browser_navigate.
   • Execute: browser_eval("window.izooto_ajax_obj?.nonce") (Replace izooto_ajax_obj and nonce with the actual keys found in the code).

5. Exploitation Strategy

The goal is to modify the plugin's configuration unauthenticated.

1. Discovery: Use the following to find the exact vulnerable action and parameter:

   grep -rnE "update_option|update_site_option" . -A 5 | grep -B 5 "wp_ajax"
   

2. Target Settings: Identify the option name used to store the iZooto App ID (likely izooto_settings or iz_app_id).
3. HTTP Request (Example):
   • Method: POST
   • URL: http://localhost:8080/wp-admin/admin-ajax.php
   • Headers: Content-Type: application/x-www-form-urlencoded
   • Body:

     action=iz_save_settings&iz_app_id=ATTACKER_APP_ID&nonce=[EXTRACTED_NONCE]
     

     (Note: If the check is entirely missing, the nonce parameter can be omitted or sent as a dummy value.)

6. Test Data Setup

1. Install and activate iZooto <= 3.7.20.
2. Configure a legitimate App ID via the WordPress admin UI initially to establish a baseline:
   wp option update izooto_settings '{"app_id":"12345"}' (Example structure).
3. Identify the required parameters by inspecting the settings form in the admin dashboard.

7. Expected Results

• The server should return a 200 OK or a JSON success response (e.g., {"success":true}).
• The targeted WordPress option (e.g., izooto_settings) should be updated with the attacker's value.

8. Verification Steps

After sending the exploit request, verify the state change via WP-CLI:

# Check if the option value has changed
wp option get izooto_settings

Expected output: The data should now reflect the ATTACKER_APP_ID.

9. Alternative Approaches

• Check admin_init Hook: If no wp_ajax_nopriv is found, the vulnerability may exist in a function hooked to admin_init. Since admin_init runs for every request to wp-admin/admin-ajax.php (even for unauthenticated users), an unprotected hook here is a common source of "Missing Authorization."
  • Look for: add_action( 'admin_init', 'vulnerable_function' ).
  • Check if vulnerable_function processes $_POST without checking current_user_can.
• REST API: Check for registered REST routes:
  grep -rn "register_rest_route" .
  Inspect the permission_callback. If it is __return_true or missing, the endpoint is unauthenticated.