Compliance Impact

The vulnerability allows an authenticated user to modify existing shadow attributes that they should not have access to, potentially altering proposals associated with events improperly.

Such unauthorized modification and potential exposure or movement of proposal data across event contexts could lead to violations of data integrity and confidentiality requirements found in common standards and regulations like GDPR and HIPAA.

However, the provided information does not explicitly describe the direct impact on compliance with these standards.

Useful 0 Not Useful 0

Executive Summary

This vulnerability exists in the ShadowAttribute proposal creation workflow of MISP. When adding a ShadowAttribute, the system accepted user-supplied data including an 'id' field without removing it. Because the underlying framework treats a provided primary key ('id') as an instruction to update an existing record, an authenticated user submitting a shadow attribute proposal could supply the identifier of an existing ShadowAttribute and cause that existing record to be updated instead of creating a new one.

This means an attacker could modify existing shadow attributes that they should not have permission to change, potentially affecting proposals linked to events they are not authorized to alter.

The root cause is trusting client-supplied primary keys during object creation. The fix involves removing the 'id' field from incoming ShadowAttribute data before processing, ensuring new proposals are created rather than updating existing records.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can lead to unauthorized modification of existing shadow attributes within the MISP platform. An attacker with authenticated access who can submit shadow attribute proposals might alter data associated with events they should not be able to change.

Depending on how the system is configured and what API responses are accessible, this issue might also expose or move proposal data across different event contexts, potentially leading to data integrity issues or information leakage.

Useful 0 Not Useful 0

Mitigation Strategies

To mitigate this vulnerability, you should update your MISP installation to version 2.5.38 or later, where the issue has been fixed.

The fix involves removing the 'id' field from incoming ShadowAttribute data before processing to prevent unauthorized modification of existing shadow attributes.

Specifically, the patch unsets the 'id' field in the ShadowAttributesController.php add method, ensuring that new proposals are created rather than updating existing records.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability involves the unauthorized modification of existing ShadowAttribute records by submitting proposals with a client-supplied 'id' field. Detection would involve monitoring for ShadowAttribute add requests that include an 'id' field in the request data, which should normally be removed before processing.

To detect exploitation attempts, you can inspect logs or capture network traffic for API requests to the ShadowAttribute add endpoint that contain an 'id' field in the payload.

Example commands to detect such requests might include:

• Using grep on server logs to find requests containing 'ShadowAttribute' and 'id': grep -i 'ShadowAttribute' /var/log/misp/api.log | grep 'id'
• Using tcpdump or Wireshark to capture HTTP POST requests to the ShadowAttribute add endpoint and filter for payloads containing 'id': tcpdump -A -s 0 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)' | grep 'ShadowAttribute' | grep 'id'
• If using curl or similar tools for manual testing, check if the request payload includes an 'id' field when adding ShadowAttributes.

Note that the vulnerability was fixed by unsetting the 'id' field in the server-side code before processing, so detection focuses on identifying requests that attempt to exploit this by including the 'id' field.

Useful 0 Not Useful 0