How to avoid headaches when publishing a CVE
You have discovered a vulnerability. Congratulations! So, what happens next?
Finding a CVE (Common Vulnerabilities and Exposures) is the first step in a process which starts with the identification of a zero-day and could end with fame and glory – if the discovery is significant enough.
Newcomers to the security research field will know that publishing a CVE can be a great career move. But they may not necessarily understand just how to get the vulnerability published and alert fellow researchers and businesses or users affected by the problem. It can take a lot of trial and error to master the craft of CVE publication. So where should researchers start to make this a seamless and pain free experience?
Ensure the vulnerability is new
A zero-day is not a zero-day if it has been previously identified. Before researchers try to get a CVE published, they must perform due diligence to find out whether it has already been reported by another researcher.
The first place to check is the MITRE database. Searching GitHub, ExploitDB and PacketStorm can also prove whether the vulnerability is new. Even a quick Google search can work wonders. Once a researcher has proved that they have discovered something no-one else has spotted, it is time to move onto the next stage of the process.
Contact the product owner
It is good practice to alert the vendor or product owner to disclose the vulnerability before taking further action. This typically results in one of two scenarios:
a) If a researcher manages to contact the right person, the next stage involves building a relationship and working together to coordinate disclosure with mitigation and the issuing of a patch.
If the vendor is cooperative, it is a good idea to agree on how and when the disclosure will be revealed. Each company will have its own policy on this which will also change depending on the nature of the CVE.
Responsible disclosure is important because threat actors will seize upon any CVE made public. That is why being patient and contacting the vendor in the proper manner is key.
If the vendor offers a bug bounty, the journey may end at this stage because researchers may be forbidden from disclosing the vulnerability, often in exchange for a reward.
b) A vendor may ignore the researcher. In which case, the person who discovered a vulnerability should try other methods of communications.
If a message to the main email address does not garner a response, it is worth finding a personal address or making a phone call – being sure to note the time and date of each contact attempt so that you have evidence and an auditable trail of communication should it be required further down the line.
Social media is also a useful way of contacting vendors or product owners. Try tagging a company on Twitter or Facebook and ask to be put in touch with the security team. Some enticing “curiosity gap” writing can help on social media. Make sure a post is enticing and concerning enough to be noticed by the social team but does not give away the exact nature of the vulnerability.
If these attempts don’t end up working and the vendor continues to ignore you, the best approach is to wait for a set length of time after attempting to contact the vendor. Researchers tend to wait for 30, 60, 90 or 120 days – but there are no rules about disclosure, so this is up to individual researchers.
At this stage, it is worth filing a CVE request form on the MITRE website because waiting for it to respond can introduce delays to the process. MITRE refers to most companies as a CVE Numbering Authority (CNA) and you will be able to select which CNA the vulnerability applies to. If the vendor does not appear on the CVE form, fill out this vulnerability request form.
Our experience suggests that a CVE will be accepted in roughly 30 days. When it is approved, researchers will receive a CVE ID by email and the vulnerability will be in a “reserved” state – which means it is accepted by not published. At this stage, MITRE has acknowledged the CVE is genuine but is awaiting disclosure.
If MITRE does not respond – just file another request later but be sure to mention that the vendor has not acknowledged the communication and mark the message “other” in the drop-down menu.
Publish the CVE
If MITRE has accepted the CVE it is time to disclose. However, while waiting for MITRE to make its decision, it is worth trying to contact the vendor again if they have been silent. Then, after you have waited for a period you consider appropriate – or which has been agreed with the vendor – it is time to publish.
A POC/ exploit can be sent to PacketStorm Security/CX Security. Be sure to include the ID MITRE number and follow these guidelines to make sure your message has the correct header.
When the vulnerability is published, send the links to MITRE by replying to its email with a link to the published exploit. MITRE will either email you to confirm it has changed the CVE status from “reserved” or simply make the change on its website.
And that is it – a vulnerability has been published! Now it is time to find the next one.