Responsible Disclosure update

We have been running a responsible disclosure program since 2013 and I regularly get asked: “Is is worth it”. Well, I only have to look at our Hall of Fame  or on our t-shirt wall to see it is…
But, lets look at the data

Each email to creates a ticket in our ABUSE queue in Jira. In 2014 a total of 371 tickets were created. Despite our anti-spam solutions we could still close 68 of them as downright spam.
A big portion of them are, what I have labeled, advisory services, notifications from our national CERT, ShadowServer and project HoneyPot that we need to look into something.
Of the 208 bonafide appeals to our responsible disclosure policy, about one third, 68 tickets, were valid reports that highlighted an issue in something we manage, ranging from Cross Site Scripting, directory listing, SSL configuration issues, to click jacking.
So what makes this hard to do?
Handling the abuse watch is a chore to our Schuberg Philis Team that is rotated because we do not always get a lot of energy from. Many of the issues we have with reports are laid out here but lately we have seen a phenomenon we have labeled “drag-net disclosure” an example is below.
Hi Team
The application does not set a new Session ID in the cookie after what
appears to be an authentication attempt by the user. If this was a
successful login and the Session IDs are stored in cookies then this
application is affected by Session Fixation vulnerability.
that your cookies are actually being fixed before an after login this
allows an attacker to perform a sessino fixation attack and hijack the
user's session by capturing the cookies before logging in of the user and
replaying it afterwars.
Here are my fixed cookies

<Name withheld to protect the guilty>

A generic message with a description of a generic vulnerability is sent out to multiple responsible disclosure programs in the hope that one of them recognises the issues, believes it is a valid finding and sends swag (or money).

We have to respond to these, politely, to ask where the session was identified and how the “researcher” obtained a valid username and password (most sites we run are closed user communities) and usually do not hear back.
Even if we have to deal with this stuff in the end it is still worth it.
And now the stat’s you have all been waiting for, the spam. We only kept 43 of the 68 spam messages, but:
44% contained eastern language characters in the subject (It’s all Chineese to me)
7% hand a topic referring to sex (I guess abuse handling isn’t sexy after all)
9% is about IP address acquisition (I guess IP addresses are more sexy)
2% (1 message) was in Dutch 
44% had an attachment (and I’m not stupid enough to open any of them)


Thanks for this update, sharing experiences makes life easier to all of us!
Yassine AB
It is always a pleasure to read about your experience dealing with self-claimed security researchers. I am wondering when are you going to update your hall of fame ?


Not Published

0/1000 characters
Go Top