Post SMTP <= 3.8.0 - Missing Authorization to Authenticated (Subscriber+) Office 365 OAuth Configuration Overwrite

This research plan focuses on exploiting a missing authorization vulnerability in the Post SMTP plugin, specifically in the OAuth configuration handling for Microsoft 365.

1. Vulnerability Summary

The vulnerability exists in the handle_office365_oauth_redirect() function (inferred to be located in the Office 365 transport module). This function is hooked to admin_init, a hook that runs whenever a user (including a Subscriber) accesses a page in the /wp-admin/ directory. The function fails to implement any current_user_can( 'manage_options' ) capability check or nonce verification. Consequently, any authenticated user can trigger the function by visiting a crafted URL, allowing them to overwrite the site's email configuration with attacker-controlled Azure/Office 365 OAuth tokens.

2. Attack Vector Analysis

• Entry Point: admin_init hook.
• Vulnerable Function: handle_office365_oauth_redirect() (called on every admin page load).
• Authentication: Authenticated (Subscriber or higher).
• Payload Location: GET parameters.
• Preconditions: The site must have the Office 365 transport mechanism available (typically part of the Pro/Premium features, but the hook registration often exists in the core code).

3. Code Flow

1. Initialization: The plugin initializes and registers various hooks.
2. Hook Registration: The function handle_office365_oauth_redirect is hooked to admin_init.
   • Note: In Postman/Dashboard/NewDashboard.php, we see standard dashboard initialization, but the vulnerable hook typically resides in the transport-specific logic.
3. Trigger: A Subscriber-level user logs in and navigates to /wp-admin/index.php?page=postman&action=office365_auth_callback&....
4. Execution: admin_init fires. The plugin checks if the relevant GET parameters (like action or code) are present.
5. Sink: The function processes the tokens provided in the URL and calls update_option( 'postman_options', ... ) to save the new (malicious) access_token, refresh_token, and user_email without verifying the user's authority.

4. Nonce Acquisition Strategy

According to the vulnerability description, this specific function missing nonce verification. Therefore, no nonce is required to trigger the overwrite.

However, if a researcher needs to verify other parts of the dashboard or REST API (as seen in NewDashboard.php):

1. The plugin localizes the nonce in NewDashboard.php inside the admin_enqueue_scripts method.
2. JS Variable: window.postSmtpNewDashboard
3. Nonce Key: nonce
4. Acquisition:
   • Create a page with a Subscriber user.
   • Access the Post SMTP dashboard (if Subscriber has access) or the main admin dashboard where scripts are enqueued.
   • Execute: browser_eval("window.postSmtpNewDashboard?.nonce").

5. Exploitation Strategy

The goal is to overwrite the Microsoft 365 SMTP configuration with attacker-controlled tokens.

Step-by-Step:

1. Log in as Subscriber: Use the http_request tool to authenticate.
2. Craft the Request: The URL must include the trigger parameters for the Office 365 OAuth callback. Based on the vulnerability description and common Post SMTP patterns:
   • Endpoint: /wp-admin/index.php
   • Parameters:
     • page: postman
     • action: postman_office365_oauth_callback (inferred)
     • access_token: EVIL_ACCESS_TOKEN
     • refresh_token: EVIL_REFRESH_TOKEN
     • user_email: attacker@evil-domain.com
3. Execute the Overwrite:

   # Payload
   GET /wp-admin/index.php?page=postman&action=postman_office365_oauth_callback&access_token=AT-999&refresh_token=RT-999&user_email=attacker@evil.com
   

6. Test Data Setup

1. Install Plugin: Post SMTP <= 3.8.0.
2. Create User: A user with the subscriber role.
3. Initial State: Configure the plugin to use any transport (e.g., PHPMailer) so that postman_options exists in the database.
4. Enable Pro (Optional/Simulated): If the code path is restricted to Pro users, ensure is_plugin_active( 'post-smtp-pro/post-smtp-pro.php' ) returns true via wp plugin activate if available, or simply verify the admin_init hook is registered in the core.

7. Expected Results

• HTTP Response: A 200 OK or a 302 Redirect back to the settings page.
• Data Change: The postman_options entry in the wp_options table will now contain the access_token, refresh_token, and user_email provided in the GET request.

8. Verification Steps

After sending the request, use WP-CLI to inspect the plugin's settings:

# Check the postman_options for the injected values
wp option get postman_options --format=json | jq .

Verify that the user_email is attacker@evil.com and tokens match the payload.

9. Alternative Approaches

If the action parameter postman_office365_oauth_callback does not trigger the function, try alternative triggers discovered by searching the source for the handle_office365_oauth_redirect string:

1. ?office365_auth_callback=1...
2. ?page=postman&state=office365...

The key is that admin_init handlers often look for a specific flag in $_GET to determine if they should process an OAuth return. Once the flag is found, the missing capability check allows the overwrite.