Compliance Impact

This SQL injection vulnerability allows authenticated users with specific permissions to execute arbitrary SQL commands, including data exfiltration, modification, and deletion. Such unauthorized access and manipulation of sensitive data can lead to breaches of confidentiality and integrity.

Because the vulnerability enables potential exposure and alteration of sensitive personal or organizational data, it can negatively impact compliance with common standards and regulations such as GDPR and HIPAA, which require protection of data confidentiality, integrity, and availability.

Failure to remediate this vulnerability could result in unauthorized data disclosure or modification, leading to regulatory non-compliance, legal penalties, and reputational damage.

Useful 0 Not Useful 0

Executive Summary

This vulnerability is a critical SQL injection issue in ChurchCRM's PropertyTypeEditor.php file prior to version 7.1.0. It occurs because the POST parameters "Name" and "Description" are sanitized only by removing HTML tags (using strip_tags()) but are then directly concatenated into SQL queries without proper escaping of SQL special characters.

As a result, authenticated users with the "Manage Properties" permission can inject arbitrary SQL commands. These commands can lead to unauthorized data exfiltration, modification, and deletion within the database.

The injected malicious data persists in the database and is reflected across multiple application pages without proper output encoding, increasing the risk of data exposure.

The root cause is misuse of a sanitization function intended for preventing cross-site scripting (XSS), not SQL injection, leading to improper neutralization of SQL special elements.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can have severe impacts including unauthorized access to sensitive data, data modification, and data deletion within the ChurchCRM database.

An attacker with "Manage Properties" permission can execute arbitrary SQL commands, potentially extracting confidential information such as admin credentials.

Because the injected data persists and is reflected across multiple pages without proper encoding, it can lead to widespread data integrity issues and exposure.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability can be detected by checking for the presence of vulnerable ChurchCRM versions (7.0.5 and earlier) and by inspecting the PropertyTypeEditor.php file for unsafe usage of InputUtils::sanitizeText() on the 'Name' and 'Description' POST parameters without proper SQL escaping.

To detect exploitation attempts or test for the vulnerability, you can monitor HTTP POST requests to PropertyTypeEditor.php containing suspicious SQL injection payloads in the 'Name' or 'Description' parameters.

• Use network monitoring tools (e.g., Wireshark, tcpdump) to capture POST requests to PropertyTypeEditor.php and search for SQL injection patterns.
• On the server, grep the source code for the vulnerable function usage: `grep -n 'InputUtils::sanitizeText' PropertyTypeEditor.php` and verify if it is used without SQL escaping.
• Check the ChurchCRM version installed by running: `grep 'version' path/to/ChurchCRM/version.php` or similar to confirm if it is older than 7.1.0.
• Look for suspicious database entries in the propertytype_prt table that contain injected SQL payloads or unexpected data patterns.

Useful 0 Not Useful 0

Mitigation Strategies

Immediate mitigation steps include upgrading ChurchCRM to version 7.1.0 or later, where the vulnerability is fixed.

If upgrading immediately is not possible, apply a quick fix by replacing the unsafe sanitization function InputUtils::sanitizeText() with InputUtils::legacyFilterInput(), which properly escapes SQL inputs.

• Replace code lines: `$sName = InputUtils::sanitizeText($_POST['Name']);` and `$sDescription = InputUtils::sanitizeText($_POST['Description']);`
• With: `$sName = InputUtils::legacyFilterInput($_POST['Name'], 'string');` and `$sDescription = InputUtils::legacyFilterInput($_POST['Description'], 'string');`

For a more robust and recommended fix, refactor the code to use prepared statements with parameterized queries to eliminate SQL injection risks entirely.

Additionally, restrict the 'Manage Properties' permission to trusted users only, as the vulnerability requires authenticated users with this permission.

Useful 0 Not Useful 0