ProfileGrid – User Profiles, Groups and Communities <= 5.9.9.8 - Cross-Site Request Forgery

This research plan outlines the steps to investigate and exploit a Cross-Site Request Forgery (CSRF) vulnerability in ProfileGrid – User Profiles, Groups and Communities (<= 5.9.9.8).

1. Vulnerability Summary

The ProfileGrid plugin fails to implement or correctly validate WordPress nonces in several of its administrative and group management functions. This allows an unauthenticated attacker to perform sensitive actions (such as modifying site settings, deleting groups, or changing user data) by tricking a logged-in administrator into visiting a malicious webpage that triggers a forged request to the vulnerable endpoint.

2. Attack Vector Analysis

• Endpoints:
  • Primary: /wp-admin/admin-ajax.php (AJAX actions)
  • Secondary: /wp-admin/admin-post.php (Form submissions)
• Vulnerable Actions (Inferred):
  • pm_save_settings (Saving global plugin configurations)
  • pm_save_group_meta (Modifying group details)
  • pm_delete_group (Deleting user groups)
• Authentication Level: Unauthenticated attacker (requires an authenticated Administrator to execute the payload via browser interaction).
• Preconditions: The target site must have ProfileGrid <= 5.9.9.8 installed and an active administrator session.

3. Code Flow

The vulnerability likely resides in how the plugin handles AJAX or admin-post hooks.

1. The plugin registers actions in admin/class-profile-magic-admin.php (inferred) or the main plugin file using add_action( 'wp_ajax_ACTION_NAME', ... ).
2. The callback function for the action is invoked.
3. The callback fails to call check_ajax_referer() or wp_verify_nonce(), or it calls them with the die parameter set to false and fails to check the return value.
4. User-controlled parameters from $_POST or $_REQUEST are passed directly to database modification functions like update_option() or $wpdb->update().

4. Nonce Acquisition Strategy

If the vulnerability is a missing nonce check, no acquisition is necessary. However, if the plugin performs incorrect validation (e.g., using a generic nonce exposed on public pages), follow these steps:

1. Identify Shortcode: ProfileGrid uses shortcodes like [profilegrid_groups] or [profilegrid_profile].
2. Create Setup Page:
   wp post create --post_type=page --post_status=publish --post_title="ProfileGrid Test" --post_content='[profilegrid_groups]'
3. Navigate and Extract: Use browser_navigate to visit the new page.
4. Extract Variable: Use browser_eval to search for localized script data:
   browser_eval("window.pm_ajax_object?.ajax_nonce || window.profilegrid_vars?.nonce") (inferred variable names).

5. Exploitation Strategy

We will target the group creation or settings modification functionality.

Target Action: pm_save_settings (or equivalent).

Step 1: Discover Parameters
Search the plugin code for the pm_save_settings function to identify which options can be modified.
grep -rn "function pm_save_settings" .

Step 2: Construct the Forge Request
Using the http_request tool, simulate a request from the Administrator's browser context.

• URL: {{BASE_URL}}/wp-admin/admin-ajax.php
• Method: POST
• Headers: Content-Type: application/x-www-form-urlencoded
• Body:

  action=pm_save_settings&pm_settings_option_name=users_can_register&pm_settings_option_value=1
  

  (Note: Parameters are inferred; actual parameter names must be confirmed from the pm_save_settings source code.)

6. Test Data Setup

1. Install Plugin: Ensure ProfileGrid version 5.9.9.8 is active.
2. Create Administrator: Create a user with the administrator role.
3. Create a Group: Create at least one ProfileGrid group to test modification/deletion.
   wp profilegrid create_group --title="Target Group" (if CLI support exists, otherwise via UI).

7. Expected Results

• Successful Exploit: The server responds with a success indicator (e.g., {"success":true} or a redirect) despite the absence of a valid _wpnonce.
• Impact: The plugin's configuration or group data is updated in the database according to the attacker's payload.

8. Verification Steps

After sending the forged request, verify the state change using WP-CLI:

1. Check Option: wp option get pm_settings_users_can_register (inferred option name).
2. Check Group Metadata: Use $wpdb to check the wp_pms_groups (inferred) table.
   wp db query "SELECT * FROM wp_pms_groups WHERE group_id = 1"

9. Alternative Approaches

• Group Deletion CSRF: If settings are protected, target group management.
  • Action: pm_delete_group
  • Payload: action=pm_delete_group&group_id=1
• Admin Post CSRF: If AJAX actions are protected, check admin-post.php handlers.
  • grep -r "admin_post_" .
  • Target forms that save tabbed settings in the ProfileGrid dashboard.