A more fitting title for this post could have been “$10 for an XSS” ;), but to summarize, I discovered a Cross-Site Scripting (XSS) vulnerability on the US website of the well-known electronics company TCL and reported it to them.
This issue stemmed from an unpatched Adobe Experience Manager (AEM) vulnerability on TCL’s side.
Adobe Experience Manager is a suite of online cloud-based services provided by Adobe for content and digital asset management. From my limited research and reading a few years ago, I divided AEM into two main parts for my understanding. One part is accessible to the public, such as any content or documents, while the other is enterprise-side and designed to be protected from general public access. This protection is mainly achieved through authentication and an inbuilt Web Application Firewall (WAF) known as AEM Dispatcher.
Occasionally, I use Google dorking to look for known AEM bad patterns, such as sites with the exposed /crx/de endpoint. /crx/de is AEM’s content repository and should not be publicly accessible. While looking for it, I discovered that TCL had this issue. I then checked if the /setPreferences.jsp endpoint was exposed. There was a known vulnerability in AEM where the ‘keymap’ parameter, when passed to this endpoint, was vulnerable to XSS. Although this issue was later resolved by AEM, many sites are still susceptible to it. Most sites block this endpoint via AEM Dispatcher, so extra effort is needed to bypass this dispatcher and access the endpoint.
0ang3el‘s aem-hacker utility also highlights it here and can help in testing out against this AEM XSS attack vector.
I first tested the ‘keymap’ parameter with an HTML <h1> tag. When <h1> rendered on the page, I tried the javascript alert payload, and the alert popped up, confirming the presence of XSS.
I reported this to TCL’s security team.
Later, I realized that since the /crx/de endpoint was already exposed, the ‘..;’ AEM filter bypass wasn’t actually needed for this XSS. I shared the other URL with their security team as well.
Timeline:
- 03/23/2021 – Reported the issue to TCL team.
- 03/29/2021 – Requested an acknowledgment. Also shared that their /crx environment was exposed and another XSS vector that wouldn’t need the ‘..;’ escape.
- 06/28/2021 – Requested an update.
- 08/19/2021 – TCL responded, confirming the issue but deemed it low risk. They offered $10 and requested for my PayPal details.
- 09/13/2021 – I respectfully declined their offer and informed them about my preference to publish a blog post on this once they fix the issue. Asked for a timeline.
- 08/20/2022 – Requested an update.
- Recently – Forgot about this finding for a long time. Noticed recently that the finding was resolved hence shared this post for the knowledge and awareness of my readers.
Pankaj Upadhyay 