How to Get Into CVE Hunting - A Beginner’s Guide to Finding Vulnerabilities

Introduction

Getting started in penetration testing can be intimidating and I think hands-on practice is one of the best ways to learn. Bug bounty hunting is often seen as a starting point in penetration testing. While it may work for some, most will find it challenging to identify their first vulnerability on a program like Bugcrowd of HackerOne. In this blog we will go through how to hunt for Common Vulnerabilities and Exposures (CVEs) through Free Open-Source Software (FOSS) applications.

What Is a CVE and Why Should You Care?

CVEs are a way to help spread awareness about a specific vulnerability using a identifier. CVEs have three sections: The CVE, the year the ID was reserved or issued, and the unique number. An example would look something like CVE-2023-31548. This indicates that this CVE was issued from MITRE in 2023 with the vulnerability identifier 31548.

The benefits of having CVEs are that you can learn on a localized web application and build a reputation. You’ll help improve real-world software security by identifying and responsibly disclosing vulnerabilities. The idea is to learn and grow your skillset while helping developers with their security posture.

One of the most significant benefits of starting with CVE hunting was learning how to easily identify vulnerabilities within a web application. When I first started in web application security, I would go onto a few applications and do black box testing. A black box means you know nothing about the application before testing. I would understand the functionality, identify parameters, and try out only a handful of vulnerabilities, such as Cross-Site Scripting (XSS), SQL Injections, and Insecure Direct Object References (IDORs).

Pre-Requisites

Before looking for applications to test, you’ll need to set up a LAMP stack. I recommend setting up an Ubuntu virtual machine and using the DigitialOcean Tutorial of How to Install LAMP, which goes through a step-by-step setup for a LAMP server.

Ensure your Kali machine and LAMP server are on the same network and can communicate with each other.

Where to Start Looking

Review my methodology for finding a Free Open-Source Software (FOSS) application. Make sure you have a GitHub account. In the search bar, type the following:

stars:>500 language:PHP CMS

You can also go directly using this link.

This search ensures that the CMS we’re testing is used by many people, indicated by the star count. I see many people in the cybersecurity space obtain CVEs from college student projects. Student projects often lack robust security practices and are not maintained, making them less impactful targets. In contrast, if you test a project that people use, the developers will likely work with you to fix the vulnerability.

It’s not just CMS’s that you can look for on GitHub; you can look for:

• Human Resource Management System (HRM)
• Customer Relationship Management (CRM)
• Firmware
• WordPress Plugins
• School Management System (SMS)

Additionally, we set the language to PHP, but you can choose any language you’d like to test. After searching, you should sort by Recently Updated.

For demonstration purposes, we will use the CraftCMS application.

Within GitHub, there is a security tab. Suppose a repository you find does not have a SECURITY.md file. In that case, it either doesn’t have a way to report security vulnerabilities or has a website that goes in-depth about what to do if you find a vulnerability, almost like a Vulnerability Disclosure Program (VDP).

The GitHub Security Tab will have a security policy for that repository. Be sure to read the policy carefully to avoid violating program rules. Some applications don’t want you to test previous versions, while others want you to test only specific branches of the repository. Each repository has a different way of reporting vulnerabilities as well. Some will require you to email the developer directly, while others want you to report the vulnerability using the Report a vulnerability button in GitHub. Within the Security policy, there may be a scope in place. Follow the scope, and don’t break the rules. We are helping developers secure their applications. They will lose respect if you go out of scope, so read the scope carefully.

After finding the FOSS application you want to begin testing, you can install the application onto your LAMP server. Most GitHub repositories will go through how to install the application. Look through the README.md until you find the installation section. Some may take you to an external site, so be careful when clicking links.

After installing the application to your LAMP server, you can begin testing!

How to Report and Get a CVE Assigned

Now that you’ve set up your environment, found a target, and identified a vulnerability, let’s look at how to report vulnerabilities and get a CVE assigned.

Before we obtain the CVE ID, we will have to contact the project’s developer. To start, write up your identified vulnerability and use the template below.

# [Vulnerability Name]

#### Severity Score: [Severity]
#### CVSS Score: [CVSS Score]

## Description

[Description About the Vulnerability]

## Impact

[Impact Statement]

### POC

[Reproduction Steps]

## Remediation

[Remediation Steps]

In your report, ensure you include details of reproduction steps. If you have the experience, find the vulnerable code within the application to showcase to the developer. After filling out the template, export it to a PDF and send it to the project developer. Again, read the Security Policy because it may tell you to wait before publishing. A good rule I always follow is to continue reaching out to the developer for several months (between 6 and 8 months) before publishing a CVE.

To obtain a CVE ID, navigate to MITRE’s CVE Request Form.

Before submitting to MITRE, make sure the application isn’t owned by a CVE Numbering Authority (CNA). These vendors have permission from MITRE to assign CVE IDs and public CVE Records. If a CNA owns the product, the CVE request should be sent to the CNA, not MITRE.

Insert your email address in the form and select Report Vulnerability/Request CVE ID. Scroll down and fill out the different required fields. I also recommend putting in the description, which is your description that will show up in NIST and the MITRE Database. After completing the form, click Submit, and you should see an email from [email protected].

The request will be sent to MITRE, and it could take a few days to 2 months to receive your CVE IDs. You’ll receive another email from [email protected] with the vulnerability and CVE ID information.

Now that you have the CVE ID wait for the duration you feel is necessary before publishing the CVE. I generally wait 6-8 months, depending on the project and the severity of the vulnerability. If the developer is in communication with me, I’ll wait until the vulnerability is patched and confirmed to be remediated. To publish your CVE, you’ll need a publication site. Some people use Packetstorm or ExploitDB, but GitHub is a better option. You can check out my CVE Disclosure GitHub page to take inspiration about what it should look like. Once you uploaded the write-up of the vulnerability to a public source, navigate back to MITRE’s CVE Form and select Notify CVE about a publication.

Fill out the form and submit it. The CVE will be published within a day, and people can start referring your vulnerability to the CVE identifier.

Common Mistakes to Avoid

When I first started to do CVE hunting, I was lost for the first week. I would install an application, find nothing, and feel discouraged. However, I realized that these are real-world applications. If the developer knows how to implement security controls, the application will be challenging to penetrate. It’s good to find these kinds of applications to learn how to bypass filters and begin thinking outside the box. Don’t give up if you can’t find anything on an application; it happens! There are plenty of other applications you can test to identify a vulnerability.

I often see the mistake of not validating vulnerabilities and assuming they are impactful. Understand the impact of the vulnerability and the severity it has on the application. For instance, if you identify a self-XSS, consider the vulnerability’s impact on the application. Unless you can escalate the self-XSS to a Reflected or Stored XSS, it’s an informational finding because the impact is extremely low.

Another mistake is ignoring the disclosure guidelines. Remember when I said something about following the rules in the security policy. If the security policy tells you to contact someone within the company, and you publish the CVE without making them aware, it can lead to problems. Make sure to read everything before testing. In the past, I have seen a minimum duration before publication of a CVE within the security policy.

Don’t look for every web application vulnerability. That is too broad of a scope. Find 1-3 vulnerabilities you enjoy and become an expert within those vulnerabilities to start. Learn everything there is to know about them. From there, you can slowly expand your search. When I started, I tried to find every vulnerability, leading to headaches and confusion when testing.

Final Thoughts

CVE hunting is a fantastic way to learn and grow within web application security. It will teach you new techniques that can be used in real-world engagements. The proper focus of CVE hunting should be to learn and grow your skillset. Cybersecurity is all about learning, and what better way to learn than hands-on practical experience with real-world FOSS applications. Getting your first CVE may take a few weeks; stay persistent, and you’ll stumble upon one.