Hacker Halted is an IT security conference with the intention of educating the attendees in security and ethics. Last year, the conference was held in Atlanta on October 16-17.
What VERT Presented at Hacker Halted
VERT presented an implementation of a protocol independent fuzzer, which was built using python. We developed a fuzzer because we noticed some oddities when we were developing an RDP (Remote Desktop Protocol) library for Tripwire IP360 vulnerability management. The fuzzer works by sending manipulated packets to a host and seeing how the service responds. Ultimately, we did find an issue that was fixed in the April 2014 Patch Tuesday, a vulnerability with the verification of the MAC Signature that we responsibly disclosed to Microsoft.
What I Hope the Audience Gained...
The audience seemed shocked when I answered a question about how long it took Microsoft to fix the vulnerability. It took Microsoft about 5 months since the initial date of when the vulnerability was reported to produce a patch. What we need to remember is that it does take time to produce a patch. A vendor can have many things that could come up that could interrupt the development and testing of a patch. Say, for example, a vulnerability is publicly disclosed and exploited in the wild, I would expect the vendor to patch that vulnerability first. Testing can also take time as a patch could cause unforeseen results, especially when accounting for all the third party applications that could interact with the patched system. I hope, if anything was taken out of the presentation, that it was the idea of responsible disclosure. I know some people would disagree with me, but the best use of information is sometimes to minimize the audience that knows about an issue. Giving out information about a vulnerability to the wrong people can have unforeseen and serious consequences depending on the vulnerability.
Remember: it may take time to properly produce a patch for a privately reported vulnerability.
Responsible Disclosure
There are a few steps to properly disclose a vulnerability to a vendor.
- Determine if the vendor is a CVE Numbering Authority (CNA). If they are (Mitre maintains a list at: https://cve.mitre.org/cve/cna.html), you can contact the vendor directly. If they aren’t, you can request a CVE from Mitre.
- Determine the vendor security contact.
- Send all relevant information to the contact.
- You now have to follow up with the vendor until the issue has been resolved. Once resolved and a patch has been released you can release your information about the vulnerability to the public.
If we don’t properly disclose vulnerabilities, we not only hurt ourselves but we hurt others. It’s like driving home drunk -- the moment you get into your vehicle you put your life, and others, at risk. While a vulnerability may not be as dire, we need to work together with the vendors to properly disclose and fix vulnerabilities.
