Friendly Functions for Welcart <= 1.2.5 - Cross-Site Request Forgery to Settings Update

This research plan outlines the process for analyzing and exploiting a Cross-Site Request Forgery (CSRF) vulnerability in the Friendly Functions for Welcart plugin (versions <= 1.2.5).

1. Vulnerability Summary

The plugin fails to implement proper nonce validation on its administrative settings page. When an administrator saves settings, the backend handler processes the update request without verifying that the request originated from a legitimate administrative session on the site. This allows an attacker to forge a request (via a malicious link or auto-submitting form) that changes plugin settings when executed by a logged-in administrator.

2. Attack Vector Analysis

• Target Endpoint: Likely wp-admin/admin-post.php or the plugin settings page directly (wp-admin/admin.php?page=friendly-functions-for-welcart).
• Vulnerable Action: A function hooked to admin_init or admin_post_{action} that calls update_option().
• Preconditions:
  1. The attacker must know the parameter names used in the settings form.
  2. An administrator with manage_options capabilities must be logged in.
  3. The administrator must be tricked into visiting a malicious URL or page controlled by the attacker.
• Authentication: Requires an active administrator session (leveraged via CSRF).

3. Code Flow (Inferred)

Since source files are not provided, the following trace is based on standard WordPress development patterns for settings pages:

1. Entry Point: The plugin registers a settings page using add_menu_page or add_options_page with the slug friendly-functions-for-welcart (inferred).
2. Hook Registration: The plugin likely uses add_action('admin_init', ...) or add_action('admin_post_...', ...) to handle form submissions.
3. Submission Logic:
   • The handler checks for a specific POST parameter (e.g., $_POST['submit'] or a hidden action field).
   • Vulnerability: The code proceeds to update_option() without calling check_admin_referer() or wp_verify_nonce().
4. Sink: update_option('ffw_settings', ...) (inferred option name).

4. Nonce Acquisition Strategy

According to the vulnerability description, no nonce is validated (or it is incorrectly validated). Therefore, no nonce is required to perform the exploit.

If the agent finds that a nonce is present in the form but suspected to be "incorrectly validated" (e.g., the result of wp_verify_nonce is not checked), the agent should:

1. Navigate to the settings page: wp-admin/admin.php?page=friendly-functions-for-welcart (inferred slug).
2. Inspect the HTML for a hidden field named _wpnonce or similar.
3. Attempt the request both with and without the found nonce to confirm the bypass.

5. Exploitation Strategy

Step 1: Discovery
Identify the exact settings page slug and the POST parameters.

• Execute grep -r "add_menu_page" . to find the slug.
• Execute grep -r "update_option" . to find which options are modified.
• Search for the form handling function to see which $_POST keys it reads.

Step 2: Verification of Missing Nonce Check
Check the identified handler function for the absence of check_admin_referer or wp_verify_nonce.

Step 3: PoC Execution
Using the http_request tool, simulate an administrator's browser submitting the settings form without a nonce.

• URL: http://localhost:8080/wp-admin/admin.php?page=friendly-functions-for-welcart (or the identified admin-post.php handler).
• Method: POST
• Headers: Content-Type: application/x-www-form-urlencoded
• Body: (Example based on inferred Welcart logic)

  ffw_custom_css=/*Hacked*/&ffw_save_settings=1&action=ffw_update_options
  

6. Test Data Setup

1. Install and activate the plugin (v1.2.5).
2. Ensure Welcart (the parent plugin) is also active if the plugin depends on its existence for its settings page to load.
3. Verify the current state of the plugin settings using WP-CLI:
   • wp option get ffw_settings (or the identified option name).

7. Expected Results

• The http_request (sent with admin cookies but no nonce) should return a 302 redirect (common after saving settings) or a 200 OK.
• The plugin settings in the database should be updated with the attacker-supplied values.

8. Verification Steps

After the exploit attempt, verify the change via WP-CLI:

# Check if the option has been modified to the payload value
wp option get <identified_option_name>

If the option reflects the /*Hacked*/ or similar payload, the CSRF is confirmed.

9. Alternative Approaches

If the plugin uses the WordPress Settings API (register_setting, settings_fields, do_settings_sections):

• The vulnerability might exist because the developer manually handles the POST request in admin_init before the Settings API's built-in nonce check runs.
• Alternatively, the developer might have implemented a custom AJAX handler (wp_ajax_save_ffw_settings) without calling check_ajax_referer.
• If admin_init is used, the agent should check if the code filters by current_user_can('manage_options'). If it does, but lacks a nonce, it is still CSRF-vulnerable. If it lacks both, it might be an Unauthenticated Settings Update.

Grep Commands for Discovery:

# Find the settings slug
grep -rn "add_submenu_page" .

# Find where settings are saved
grep -rn "update_option" .

# Check for nonce functions
grep -rn "wp_verify_nonce" .
grep -rn "check_admin_referer" .