Summary

A critical privilege escalation vulnerability exists in ChurchCRM version 6.3.0 and earlier. An authenticated user with specific mid-level permissions ("Edit Records" and "Manage Properties and Classifications") can inject a persistent Cross-Site Scripting (XSS) payload into an administrator's profile. The payload executes when the administrator views their own profile page, allowing the attacker to hijack the administrator's session, perform administrative actions, and achieve a full account takeover.

This vulnerability is a combination of two separate flaws: an Insecure Direct Object Reference (IDOR) that allows any user to view any other user's profile, and a Broken Access Control vulnerability that allows a user with general edit permissions to modify any other user's record properties.

Details

The attack chain is as follows:

1. IDOR in PersonView.php: There is no authorization check at the beginning of PersonView.php. Any authenticated user can view the profile page of any other user (e.g., PersonView.php?PersonID=1 for the admin) simply by knowing their ID.

2. Broken Access Control in PropertyAssign.php: The "Assign a New Property" functionality, accessible from another user's PersonView.php page, directs the user to PropertyAssign.php. This script correctly checks if the user has the general isEditRecordsEnabled() permission, but it fails to perform an object-level authorization check to verify if the user is allowed to edit the specific PersonID passed in the URL. This allows a user with "Edit Records" to modify properties of any person in the system, including an administrator.

3. Stored XSS Vector: An attacker can leverage these two flaws to navigate to the administrator's profile page and use the "Assign a New Property" form to save a malicious XSS payload to the administrator's record. The Value field for text-based properties is not properly sanitized on input (only strip_tags is applied, which does not remove event handlers) and is not encoded on output, leading to Stored XSS.

   • Input Handling (src/PropertyAssign.php): Saves the property value after only applying strip_tags(), which allows event handler attributes like onerror.
   • Vulnerable Output Sink (src/PersonView.php): Renders the stored property value directly into the HTML without htmlspecialchars(), causing the payload to execute.

     // src/PersonView.php, line ~722
     <td><?= $r2p_Value ?></td> // Vulnerable: Raw output

PoC

This Proof of Concept demonstrates how a user with specific mid-level permissions can inject a Stored XSS payload into the main administrator's profile.

Prerequisites:

• An attacker has an account with two specific permissions enabled:
  1. Edit Records
  2. Manage Properties and Classifications

Scenario:

1. Login as Attacker: Log in as the user with the permissions listed above.

2. Target the Administrator: Navigate directly to the administrator's profile page, which is typically PersonID=1.

   http://localhost:8101/PersonView.php?PersonID=1
   

   (Access is granted due to the IDOR in PersonView.php).

3. Inject Payload:
   • On the administrator's profile page, scroll down to the Assigned Properties tab.
   • In the "Assign a New Property" form, select the text-based property e.g. ("Test"). (The form is visible due to the "Edit Records" permission).
   • In the Value textarea that appears, enter the following XSS payload:

     <img src=x onerror=alert('XSS_on_ADMIN_Profile')>

   • Click the "Assign" button. The payload is now stored on the administrator's record. (The assignment is possible due to the Broken Access Control in PropertyAssign.php).

4. Trigger the Attack:
   • The attacker can now wait for the administrator to log in and view their own profile.
   • When the administrator navigates to their own profile page (PersonView.php?PersonID=1), the payload will execute immediately, and an alert box will appear. The attacker could use a more advanced payload to steal the administrator's session cookie.

Impact

This is a critical privilege escalation vulnerability. It allows a user with specific, elevated (but non-admin) permissions to gain full control over an administrator's account. By hijacking the admin's session, the attacker can perform any action available to an administrator, including creating new admin accounts, deleting data, and potentially chaining this with other vulnerabilities to achieve full server compromise.

Attribution

Reported by: Łukasz Rybak