ORIGINALLY POSTED BY NOKIA FOR THETAZZONE/TAZFORUM HERE
Do not use, republish, in whole or in part, without the consent of the Author. TheTAZZone policy is that Authors retain the rights to the work they submit and/or post…we do not sell, publish, transmit, or have the right to give permission for such…TheTAZZone merely retains the right to use, retain, and publish submitted work within it’s Network
- Code: Select all
Soda_Popinsky has very kindly allowed this tutorial of his to be hosted on the TAZ.
(at least how I do it)
When one comes across a vulnerability, they can do one of four things:
2.Ethical Disclosure to vendor/author
4.0-Day Exploitation of vulnerability
This is the process I use for disclosure of vulnerability, and it’s pretty simple. I believe that the first party to receive technical information about a vulnerability should be the vendor/author or service responsible for creating the vulnerabilty.
First off (after I discover a vulnerability) I confirm that the vulnerability exists so I don’t waste anyone’s time or ruin my own credibiltiy with a false alarm. Afterwards, I make two contacts:
Vendor or author of the asset with vulnerability
Why contact Secunia? Because there’s always the chance that the author or vendor won’t have the capacity to handle (or give a shit) about the vulnerability. I make contact with Secunia so they can use their muscle (aka an @secunia.com email address) to convince a vendor to turn their wheels with a fix. This doesn’t happen as much as you might think, however.
I give everything regarding the vulnerability over to Secunia, and they then hold on to the vulnerability information and delay the advisory until I give them the go-ahead to release it. Secunia can obviously be replaced by another advisory service (like iDefense to whore it out), except for something like BugTraq or Full Disclosure mailing lists, but I can’t vouch for their willingness to delay an advisory the way Secunia does. I delay the advisory, and I then move on to the vendor…
Dealing with the Vendor
If you are looking for a place to contact the vendor, first browse the website for any email address that looks at all relevant (developers, security) or general (info, general, contactus@). If that’s a no-go and can’t be found… whois their domain, and look for the abuse contact (usually
Be prepared to speak over PGP encrypted email. If you don’t have a key, get one (this isn’t a public key tutorial, you figure it out).
If possible, ask them to sign their emails so they can’t deny that you contacted them. (You might be talking to a help desk cronie that doesn’t have a clue) Just a precaution for later. Send them whatever is needed (PoC code, text, etc) for them to understand the vulnerability once they ask for it… the quicker they understand, the quicker the response.
If they ask for it, they imply they are in a position to deal with it. Don’t just randomly send off PoC exploits to all the email addresses you can find at a vendor.
If the vendor is cooperative, then delay the release of the advisory until there is an official fix available. Ask them for this time frame and offer your help in the development of the fix.
There is always the possibility that they won’t understand the threat, won’t have a functioning bug reporting system, or are just straight up unresponsive… In that case…
…They Don’t Care!
This is where our contact to Secunia/Wherever is useful. After the initial email to the vendor, I’ll give 2 weeks to the vendor to respond. I’ll then tell Secunia that they aren’t responsive, and Secunia will also attempt to make the contact. (they have connections )
Two weeks later, I’ll tell Secunia to (or Secunia will themselves) release the advisory and the news will travel to Full Disclosure or Bugtraq soon after.
Getting credit for published advisories is common. For the infosec analyst, an advisory isn’t worth much except for childish/worthless IRC/Forum/Classroom street cred or whatever… unless it’s done responsibly. It has landed me a few jobs and I’m glad I’ve been handling them the way I have. It shows character and proves that an individual is worth trusting.
This process lowers the amount of exploitation to an amount that’s acceptable for my own concious, allows the vendor to respond at their own rate, and gives sysadmins full details of the vulnerability when an official fix is ready (as opposed to dirty hacks, like we saw with the WMF exploit).
Web services are tough… because users can’t apply fixes (such as Antionline). I don’t have the answers for that, but I’ve been lucky to not have to deal with an unresponsive provider in that area.
That’s all I got. I’m sure there will be discussion considering the events that have happened over the past week or so. Regardless, I’m selfish and have a huge ego, so I prefer this method for my own reputation.