Stored XSS in Email Body of SmarterMail (CVE-2023-48114)
Last updated
Last updated
SmarterMail 16.x 8495 through 8664 had a vulnerability in its Anti-XSS mechanism, leading to stored cross-site scripting. With a normal-access account, an attacker could potentially take over other users' accounts by sending an email containing malicious JavaScript code.
In order to mitigate this vulnerability Install the latest application patch (Build 8747).
It is possible to take over a victim's account when they open their inbox.
While auditing the code to gain a fundamental understanding of the application, everything initially appeared to be in order. All user inputs seemed to pass through a sanitization function, designed to filter out any harmful tags and attributes. Curiosity led me to delve deeper into the sanitization function's implementation and logic, aiming to uncover any potential flaws.
After analyzing the sanitization function for a few minutes, something drew my attention. It appeared that the function was invoked with specific whitelists and blacklists.
The flawed code that uses these two lists is as follows:
Looking at the code, we realize that it checks the presence of blacklisted elements in the given text. If an element is blacklisted, the code then checks whether it is an iframe or embed tag with attributes. Subsequently, it inspects whether the src attribute starts with the whitelisted iframe sources. If all the conditions are met, it will allow the element and won't mark it as unsafe code; otherwise, it will remove the element from the text.
There is also a flaw in the URL validation process against the whitelist. Consequently, a URL like this is considered valid by the sanitizer:
I believed I had everything I needed to execute an XSS attack, so I attempted to exploit the vulnerability using an embed tag and a SVG payload on my server. However, that's when CSP came into play. The CSP header was as follows:
The frame-ancestors directive is configured to 'self', preventing us from serving the payload on our server. Consequently, we needed to upload the SVG file directly onto the mail server. The application offers a file storage feature allowing uploads of various file types onto the server. However, upon uploading the file, a new obstacle emerged: the Content-Disposition Header. Its value was set to 'attachment', implying that the file wouldn't render in the browser but trigger a download instead. This presented yet another challenge that needed resolution.
While reviewing the code for an endpoint allowing file uploads and inline viewing, I identified a suitable endpoint that fulfilled my requirements.
Finally we can go for the ultimate payload creation and exploitation. The payload will become as follows:
You need to replace {link} with URL of SVG file you uploaded on the server previously. Then you will put this payload in the messageHTML parameter and send the email to victim. Upon opening their inbox, the payload will execute. I've created an exploit to demonstrate the severity of this vulnerability, allowing the extraction of the victim's accessToken and refreshToken, forwarding them to the attacker's email address. The accompanying image depicts the result of this exploit.
