DVWA CVE musings
Recently infosec social media was bubbling over with regards to CVE-2023-39848 (SQL injection in DVWA). One thing I find somewhat amusing is the various strong opinions people have regarding CVE identifiers that are often self-informed, such as assigning importance to CVE identifiers. If you’re going to have a CVE hot take on social media, I would urge you to ensure your argument is still solid if you replaced bug/CVE-id with house/street-number. So instead of saying something like: That house is so stupid, why does it have a street number? you might rephrase your argument better. With that in mind, let’s take some time to look at what happened and think about the problem this represents.
Some background first. The CVE identifiers are issued by Numbering Authorities (CNA) and ultimately managed through MITRE’s CVE Program. The CVE program mission states:
The mission of the CVE® Program is to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities
The rules that govern assignment of CVE identifiers by a CNA are public and can be accessed at: https://www.cve.org/ResourcesSupport/AllResources/CNARules. One item that may surprise you is section 7.1:
The CVE Program does not adhere to a strict definition of a vulnerability. For the most part, CNAs are left to their own discretion to determine whether something is a vulnerability.
Also relevant is section C2, which is one of the reasons it’s not really a big deal to have a CVE identifier issued. Rejecting CVE ids are part of the formal process and not a rare occurrence.
There are many reasons why a CVE ID may be rejected, such as: further research determines the issue is not a vulnerability
So, with the understanding that CVE assignments is a process that allows for correcting mistakes. The potential tracking of vulnerabilities in vulnerable apps still presents an opportunity to think about the what, why and how of issuing ID numbers for vulnerabilities. Here are some aspects of this assignment that I found interesting:
Is it a vulnerability?
- Yes, the entire point of DVWA is to have vulnerabilities.
Could it get you owned?
- Yes, people run DVWA on the internet or on localhost. Many of the vulnerabilities contained within DVWA could get you compromised from a website if it’s running on localhost via something like
<img src="http://localhost/vulnerabilities/sql/?id='+union+select+...into+outfile..."> - If someone in your organisation installed DVWA to learn and forgot about it, would you know?
- Would your vulnerability scanner detect it?
Was it publicly disclosed?
But it’s intentional!
- If it was an unintentional vulnerability in DVWA it should get a CVE?
- Is this argument significantly different from its a feature not a bug?
- Can the same argument be made by a large software vendor to avoid having a CVE identifier assigned for their product?
CTF targets shouldn’t receive CVE identifiers!
- Is there any value to tracking vulnerabilities in CTF targets?
- The CVE-2023-39848 identifier was updated to rejected status
- What about pwn2own or realworldctf targets?
Why does CVE assignments matter?
- Compared to other vulnerability tracking schemes?
- Anyone can get an OVE id simply by clicking a button on the website
- Anyone can issue their own tracking id, such as JAHx101
By now you have hopefully discarded any preconceived notions around CVE ids being more than a tracking number for a vulnerability. Like how a street number or tracking number for an online order works. Hopefully understanding the many complexities of vulnerability tracking you might understand why broad approaches don’t work. So the next time you see a CVE assignment you disagree with perhaps you can trust in it the rejection process and complain about the increasing volume of fake exploits on exploit-db instead.