One aspect to always keep in mind when introducing third-party software in your organisation is security. Any third-party application should ideally undergo an independent security assessment before adaptation, to ensure that no misconfigurations and vulnerabilities are inadvertently introduced in the security ecosystem. If, during this process, a vulnerability is identified, it should then be promptly and responsibly disclosed to the relevant vendor, whose responsibility is to apply proper mitigation actions and roll out fixes for their customer base.
Microsoft Dynamics 365 is a CRM software solution, which has gained a lot of traction recently as it helps organisations efficiently maintain customer information under a centralised platform. During a recent engagement whose focus was to assess the security of a Microsoft Dynamics 365 application, SECFORCE consultants identified several instances where the application was susceptible to Cross-Site-Scripting attacks.
Upon discovery, the established policies were followed, and the issue was shared with Microsoft’s security team through their responsible disclosure program. The vulnerability was confirmed by Microsoft’s engineers and a fix was deployed shortly after.
But what was the issue?
Microsoft Dynamics offers a rich text editor in various parts of the application, which allows users to include notes within certain areas, such as the Opportunities section. When performing a security assessment, such functionalities are of great interest as they can allow the inclusion and rendering of HTML content by design. Therefore, they are often a good candidate for mounting Cross Site Scripting attacks.
What is Cross-site scripting (XSS)?
Cross-site scripting (XSS) occurs when an attacker is able to inject malicious code (usually in the form of a script) into a webpage viewed by other users. This code can then be executed in the context of the victim's browser, allowing the attacker to steal sensitive information, manipulate the victim's session, or perform other malicious actions. XSS attacks can be prevented through a combination of input validation, output encoding, and other security measures.
It is common practice for off-the-shelf products to have defense mechanisms in place, such as validation of user input to prevent code injection attacks (e.g. XSS).
In this instance, while reviewing the functionality of the Rich Text Editor, it was identified that it was possible to include links and URLs in user content, via the <a href> HTML tag. Additionally, the editor allowed the user to select a protocol for the URL, through a list of options or even set a custom one as can be observed in the evidence below.
A common vector for XSS is to use the "javascript:" protocol when crafting a link. This can allow JavaScript execution once a user clicks on the included link. While attempting to do so, it was identified that the application had taken this attack vector into consideration, as there was a client-side check to disallow the usage of this protocol as can be observed below.
The next step was to validate whether there was also a server-side check for the same attack vector. To that end, the client-side check was trivially bypassed by intercepting the request and injecting the payload in the notetext parameter, and the request was subsequently submitted to the server.
As demonstrated here, the request appeared to have been accepted, however when trying to load the new note entry, it was observed that the malicious payload had been removed and replaced with the ‘#’ character. Therefore, it was concluded that there was also server-side validation that removed such malicious content.
The challenge was to identify if there was a way to bypass the validations performed by the application which could allow us to conduct an XSS attack. There are a few ways to do this, and most of them involve trying to identify if a regex pattern check is being used for the filtering and if it can be bypassed. One of the first things to do in these cases, is to verify if the filtering can distinguish between case sensitive input. In other words, what if our payload used a combination of lower and uppercase characters – e.g. JaVaSCrIpT:. Will the filtering mechanism in place still be able to detect and remove our injection?
Having this in mind, the following payload was submitted JaVaScRiPt:alert() through the application’s UI, as shown below. The client-side check was bypassed and the application accepted the new entry without errors.
The next step was to identify whether our malicious entry had bypassed the existing server-side validation. Checking the source code for our new note entry, confirmed that the payload had also bypassed any server-side checks and was stored in the application’s page. This means that if a victim:
- visited that page
- attempted to use the Rich Text Editor
- and clicked on the provided URL
The stored malicious JavaScript code would be executed under the context of the victim user.
Upon clicking on the malicious link, the alert popup will get triggered in a new page within the same domain’s context. This attack method can be leveraged in multiple ways, and if a user with appropriate privileges is targeted, it can allow escalation of privileges via calling the relevant API endpoints that Dynamics utilizes.
As per Microsoft’s engineer team review, the issue is considered of “Important” status.
Timeline
04/04/2023 - Issue reported
19/04/2023 - Issue verified and report state changed to a fix being developed
20/04/2023 - Severity set to Important
26/05/2023 - Fix released
TLDR
It was possible to bypass the implemented client-side and server-side filters of the Dynamics 365 Rich Text editor and achieve XSS by using a combination of lowercase and uppercase letters. The main reason that allowed such an attack was the fact that there wasn’t an effective regex mechanism implemented to take into consideration case sensitive input.
