Since I began my journey of becoming a professional "hacker" and bug bounty hunter, I've always been fascinated by researchers who hunt and look for zero days in web applications. I've envied them, as I felt that having CVEs tied to your name as a security researcher is like a stamp of approval, a trophy, which formalizes you as a top-tier "hacker".

Finally, I'm proud to announce that I have successfully found a valid CVE that is tied to my name, though disputed by the vendor, I feel it is still an accomplishment, and caused them to roll out a new version 2 days later. This vulnerability is for version 1.24.1 and has been patched in their 1.24.2 release.

This is the story of hunting and finding CVE-2023-31045 in the Backdrop CMS application.

Given that this was my first time attempting to hunt for a 0-day, my thought process was to find an open-source project that is actively maintained by a community of developers, along with a decently sized user base of the target application. I felt that an open-source project will allow me to easily access the source code if a code review was required to identify a vulnerability. This led me down the path of Content Management Systems.

I ultimately found Backdrop CMS as a viable candidate that fit my ideal testing parameters. When I landed on the Backdrop CMS homepage, I found that I was able to spin up a live demo with their latest version directly from their site.

In doing so, I was able to authenticate as the Administrator user and began testing the functionality within the dashboard UI. I started by testing for Cross-Site Scripting (XSS) vulnerabilities in the user input fields.

The Backdrop CMS gives administrators the option to use various formatting editors within their CMS, for example, Raw HTML, or Filtered HTML formatting, along with adding custom formatting options, that you can select from a drop-down menu when you are publishing a blog post or any other content type.

After testing various input fields to see how the user input is sanitized by the application, I learned that the CMS is pretty secure for the most part as the application strips out most of the HTML tags, or event handlers that a user inputs. However, after some digging, I landed under the Text Editors and Formats functionality, by following the click path:

Configuration -> Content Authoring -> Text Editors and Formats -> Add Text Format

I realized that if I input special characters, and event handlers in the Name input field when creating a new text format, none of the characters are stripped, and are stored in the application. Though I was not able to escape the filtering, and the payload was not processed or executed, I managed to complete the first step, which is bypassing the filtration of special characters and event handlers.

I inputted the following XSS payload which can be seen below:

serg<details/open/ontoggle=prompt(1337)>

I started thinking in terms of "Second Order". Meaning, maybe the payload can be processed in a different part of the application. If you are unfamiliar with second-order injections, second-order XSS attacks involve the use of databases and occur when developers let attackers elevate input to the command level.

This led me to the Manage Content functionality. As an Administrator user, I followed the click path below:

Content -> Manage Content

This functionality allows you to create, edit, or delete different content types. For testing purposes, I decided to modify a default page, which was the "About" page. When editing, this brings you to a new dashboard, which allows you to make the appropriate changes. I quickly saw my opportunity to fire my stored XSS payload, when I saw the option "Formatting Options" under the "body" field. When you expand this box, you should now see three options to choose from, in the drop-down menu.

If we select the option, which is our stored XSS payload that we set earlier in the Text Editors and Formats section, we will see that the application processes and renders our malicious payload.

The developers forgot to sanitize the user input in the formatting options drop-down menu, which allowed us to execute our malicious JavaScript payload successfully.

I would like to give kudos to the Backdrop CMS Security team, as they responded to my email informing them about the vulnerability in less than 24 hours, and rolled out a patch/updated version of Backdrop CMS in 48 hours. Though they dispute this vulnerability, as they state the Administrator user can control the HTML with the application, the failure to sanitize user input in a drop-down menu that executes a stored XSS payload, still creates an impactful attack vector for attackers looking to exploit the Backdrop CMS application.

Nevertheless, I am proud of this accomplishment, though I wish it was a more advanced attack chain, however, there are more opportunities in the future!

If you have any questions, please do not hesitate to DM me on Twitter at GRuMPzsux

Sergio Medeiros