Automated Vulnerability Disclosure with upSploit
Recently there have been a number of high profile vulnerabilities and problems found in software as well as in hardware. The way they have been disclosed has varied greatly. This leads to confusion for vendors, who obviously do not want to offer services with critical vulnerabilities in them — that would just be stupid.
Some researchers release a vulnerability without allowing any time for the vendor to fix the problem, referred to as full disclosure. Someone else may allow 30 / 60 / 180 days, referred to as responsible or coordinated disclosure. When it comes to these disclosure types, each researcher has their own way of doing things and relies on their own judgment as to what is an appropriate delay. They are not bound by any laws or ethics other than their own.
The aim of the upSploit service is to provide a platform for vulnerability researchers — and other people who come across a vulnerability out of the blue — to be able to alert the vendor to the problem in the most ethical way possible while also automating the process.
Creating and Submitting an Advisory
When visiting a vulnerability database like OSVDB, PacketStorm and Milw0rm all of the entries provided by the researchers take the form of what is known as an advisory. As the name suggests, the document is aimed to advise the vendor of the problem that is occurring so that they can fix it as soon as possible. All advisories are different, again like I mentioned before, they are not bound by any rules except the researcher’s and a misinterpretation of terms can easily occur.
When building upSploit, our main priority was to build a service that somebody could use who wasn’t necessarily in information security or who had never disclosed a vulnerability before. We needed to build a template for the researcher so that they could “fill in the blanks” and not have to worry about what needed to be included.
The advisory section is currently split into five sections (with a view to change this in the near future to one page). The current fields that are being asked for are:
- Advisory Title
- Advisory Summary
- Vendor
- Vendor Software
- Software Description
- Description of Issue
- Proof of Concept
- Credits
- References
Once all the details have been entered by the user it then takes the user to the Advisory Summary page. This page lists everything that was entered and shows how the advisory is going to be structured. If, when reading through this, the researcher decides that they have made a mistake or want to add something they can by clicking on to one of the edit buttons next to each heading of the advisory.
By clicking the submit button on this page the user automatically sends the advisory to the vendor and saves it within their account area as shown in the image below at the bottom of the screen. The view button allows them to view their advisory on the website itself. They will also have been emailed a copy for their own records.
The email is sent out to the vendor immediately (if the vendor is in the database, more about that later on). The user is BCC’d into the email so that they can see upSploit has taken its first step in contacting the vendor. The email states information about upSploit, why they are being contacted, the date the advisory will be released, the amount of days they have left to fix / respond, a contact email and a .TXT attachment of the advisory. An email like this is sent and BCC’d to the vendor and researcher each month respectively with alterations to the date the advisory will be released and the amount of days they have left to fix / respond.
An example of an advisory that has been released and is in our database can be found in the image below. It can either be viewed as a .TXT document via the browser / downloaded or within the web application itself as shown below.
Disclosure / Time Limits
As mentioned above, it is decided by the researcher how long they want to wait before an advisory gets released to the public without a fix or a solution plan in place. upSploit aims to help vendors by giving them as much time as ethically possible to fix the issue found. Unless the researcher specifies differently, upSploit gives the vendor up to 180 days from when they acknowledge the receipt of the advisory. It is then decided on a case by case basis whether the vendor should be given longer to fix that vulnerability. For example, have they communicated a compelling reason to delay the disclosure or the vulnerability will take longer to fix (a solution in the next version of the software, for example).
A number of people that I speak with say that it is unethical for a researcher to release their findings before the vulnerability has been fixed by the vendor. It is my belief that it unethical not to release findings if the vendor is uncooperative because people are going to be vulnerable without realizing it and carry on using the service / software. A great example of this is the Skype vulnerability on Mac OS X that has recently been released; although Skype is fixing that problem it was deemed so important by the researcher to alert the community to it so that they would stop using the Skype application until the update was available. The article regarding this can be found here: http://www.purehacking.com/blogs/gordon-maddern/skype-0day-vulnerabilitiy-discovered-by-pure-hacking
In the case of upSploit, the vendor is reminded of the problem every 30 days until only 30 days are remaining in the countdown. When this occurs, the vendor is then reminded every 7 days until only 7 days remain. Within the final 7 days of disclosure the vendor is reminded every day. The following is the final email sent to Web Calendar, a vendor who did not respond to one of the advisories that we sent.
As can be seen here, the vendor is told every day that they were reminded about the advisory (This image only shows 10 emails sent. This was what upSploit used to use before a recent change). They are then told the following: “We are releasing the “Multiple XSS Vulnerabilities in WebCalendar” bug / vulnerability to our database. upSploit does not confirm vulnerabilities and therefore a voting system will be used to determine if the advisory is valid or not.”
What this means is that upSploit does not disclose a confirmed vulnerability to the public, it discloses an unconfirmed vulnerability. A plus and minus sign are shown next to the title in the database.
The aim here is to have a peer review system where people who use the database can confirm or deny the existence of the vulnerability. The results of user peer review is shown by either a positive or negative number on the database.
Vendor Contacts
A big problem that researchers can face is finding a security contact for the vendor they want to disclose to. Sometimes it can just be as easy as security@vendor.com. Other times, it can be a lot more difficult to find, like the name of a specific employee, for example. upSploit has tried to tackle this issue by having a huge database of vendors available to choose from when submitting an advisory as shown below:
Since the service is still in its early stages, the amount of vendors isn’t that large. To contact vendors who are not in the database yet, we have a number of options available to the admins and the researchers.
The first option for researchers is when they are choosing the vendor to click — Not Listed—. This option brings a new field on the submission stage called vendor name and alerts the admin so that they can find the email to add to the database and send the advisory off.
Another option for the researcher is to request the vendor using the request feature on the homepage. This request page asks just for the name and website of the vendor so that the administrators can search and enquire about the email contact. The request page is shown below:
The final method is for the administrator’s benefit. This is where users find contacts themselves and add it to the database for everyone else to use. The form requests for vendor name, vendor email, vendor website and the PGP key. The reason the PGP key is requested is because in a future update we will be supporting sening all vulnerability advisories PGP encrypted. The image of the add vendor section is below:
Current advisories in the system
There are a number of different advisories in the system ready to be released. The following is a list of dates for release if no contact has been received from the vendor:
Saturday 4th June 2011
Wednesday 31st August 2011
Friday 16th September 2011
Saturday 17th September 2011 (x2)
Sunday 2nd October 2011 (x2)
We currently have one vulnerability in the system that is being disclosed and coordinated with a vendor patch on 25 May 2011.
For more information and to see current advisories in the database please check: https://www.upsploit.com/index.php/advisories
Conclusion
The one thing that I haven’t mentioned while going through all of this is that it is all automated: the advisory submission, the constant reminders to the vendor and the publication to the database. The only thing that needs user input is adding the vendors to the database. We believe that upSploit is a great service for security researchers that a) submit a lot of vulnerabilities and need to organize them and b) do not have all the time in the world and research is their second calling (so to speak).
This service is currently free and will always stay free of charge. There is some internal talk of adding features like changing disclosure policy per account for an additional fee. But, at the moment, we are focused on completing everything the way we want it for the free users, like implementing the PGP encryption, for example.
We do offer a commercial product / service that I will not into much detail about but it is known as the upSploit Research License. Simply put, the upSploit Research License is a in-house version of the service described above designed for security research teams. The biggest difference is that the administrator of this team has an admin console that allows them to overview exactly what their team is up to at any given point and comment on each advisory and make revisions. For more information about this please visit the following link:https://www.upsploit.com/index.php/upsploit/story/26