Before I got into the security field full time, I made it my goal to someday discover a previously unpublished exploit that would warrant the assignment of a CVE. I was always amazed at the constantly updated Exploit-DB list and wanted to be able to make my own contribution to the database. This month, I was finally able to accomplish my goal and submit my first two vulnerabilities in two different applications. In this blog, I plan to chronicle my steps from beginning to end in the hopes that this will help make the process easier to follow for someone who has not done this before.
Discovery
Although some people choose to focus their attention on one particular piece of software, I discovered my vulnerabilities through the broad course of a penetration test. For CVE-2017–6550 (SQL Injection), one of the major giveaways was the passing of raw SQL commands like SELECT FROM, and UNION through web requests. In CVE-2017–6443 (Persistent XSS), I happened to notice that a user was able to set the value of a field (Administrator Name) that was directly output in the body of the page. Both of these cases were relatively low-hanging fruit, but I noticed that neither of these issues had any advisories published for them yet. Because it was during the course of a legally authorized penetration test, I felt justified to be able to safely report this issue.
Reporting
After I discovered these issues, I immediately reached out to generic security emails, including security@, info@, and any contacts in the WHOIS data of the domain. One vendor responded back immediately but the other did not. I reached out on Twitter to see where I could report a security vulnerability, but I was instructed to email an account that I had already previously contacted. This was somewhat frustrating and certainly not what I had pictured in my head when it came to reporting a somewhat serious security issue.
For both issues, I chose to reach out via the CERT form to help coordinate the disclosure, since I wanted to make sure all my bases were covered. In both cases, CERT provided some guidance but generally recommended that I continue with my slated 90-day disclosure timeline.
Assigning a CVE
The actual process of getting a CVE assigned was somewhat easier than I expected. I used the contact form at https://cveform.mitre.org/ and was pleased to receive a response within a day. In the form, there is a section to paste your PGP public key in order to receive an encrypted response — I used my key from Keybase.io, which made the whole process relatively painless. I provided lots of detail in my report, and spent a fair amount of time on trying to come up with a phrase in the following structure as recommended by MITRE:
[Vulntype] in [Component] of [Product] [Version] allows [Attacker] to [Impact] via [Vector]
The original description I provided looked like this:
Persistent cross-site scripting (XSS) in the web interface of Epson’s TMNet WebConfig Ver 1.00 application allows a remote attacker to introduce arbitary Javascript via manipulation of an unsanitized POST parameter.
In both cases, I received a short email that indicated which CVE to use to discuss the issue. I was prepared to be able to defend my findings to ensure its validity, but I was not required to do so.
Disclosure
Before disclosure, I wanted to make sure that the vendor who replied was kept in the loop. I constructed an email informing of my intent to disclose after 90 days, but I did not receive a response back.
I chose to submit to two directories as part of my disclosure — Exploit-DB and the Full Disclosure mailing list. In order to submit to Exploit-DB, it was as simple as creating a text file in their provided format and then emailing submit@offsec.com:
# Exploit Title: [title] # Google Dork: [if applicable] # Date: [date] # Exploit Author: [author] # Vendor Homepage: [link] # Software Link: # Version: [app version] (REQUIRED) # Tested on: [relevant os] # CVE : [if applicable]
Although not required, I added the disclosure timeline information on each to verify that I followed a reasonable due diligence before publicly publishing details.
For the FD list, it was necessary to sign up before posting to it. Using the form found here, I was able to create an account and submit the vulnerability details by emailing fulldisclosure@seclists.org. Here there were less restrictions on the formatting, but I chose to maintain a relatively consistent level of detail between each submission.
Next Steps
I submitted to both sites on a Friday, and saw they were posted on the following Monday. After the submission was accepted, I noticed that the details were scraped by other sites quite quickly. For example, SecurityFocus classified the issue as an HTML injection vulnerability and generated their own description. At the time of writing this blog, the official CVE site had not updated with their description or an official CVSS score.
Lessons Learned
- Contacting vendors is a more difficult experience than I previously thought. I expected security / IT personnel to want to immediately remediate the issues, but this proved to not be the case.
- Submitting a CVE request through the MITRE form is the fastest way to get a CVE assigned if you provide enough detail in your report.
- It was helpful to have a PGP key to establish encrypted communication, but the vendors in question did not have a published key.
- Disclosure is a hurry up and wait process. 90 days passed extremely slowly, especially without conversation flowing back and forth.
Advice to Software Vendors
- Create dedicated emails for reporting security vulnerabilities such as security@
- Provide a PGP key to allow encryption of a vulnerability’s technical details
- Have an automated response explaining the typical timeline for confirmation (For example, “Thank you for your submission. Your request will be validated within 10 business days”). This helps to let the researcher know they are communicating with a valid account, instead of casting doubt as to whether or not the email will actually be read at that inbox.
- Communicate details clearly. Most security researchers are willing to accommodate your timetable if you clearly spell it out to them.
