Exploit Reporting Guidelines

Exploit development to me seems like a world without rules and guidelines. Any one can do what ever he or she wants to do. When I look at exploitdb it seems there are no guide lines for exploits being development for software application.

Any there are guideline for reporting exploits if you find them?

2 Likes

In general I’d categorize exploit development into two major categories:

1. Research/Fun

  • You’re either a (professional) researcher or hobbyist.
  • You take apart software/hardware stacks for vulnerability research purposes/bug hunting.
    • Bug Bounty programs may require a working PoC exploit to make the vuln fit the scope of such a program.
    • A PoC can increase payout and decrease time until a fix is released due to “real world attack scenario”.
  • Sometimes you just drop your stuff on e.g.: social media channels because vendors may not care and responsible disclosure then becomes a nightmare. Putting it out there increases the pressure for them (Also you get dem internet fame points :wink: ).

2. Black hat activities

I guess in this category there are no rules, you do exploit dev and vuln research for e.g. monetary gains, defacing/political statements, …
Then again you’d probably not drop your exploits on social media channels or services like exploitDB, because you’re not in the game for security fixes.

2 Likes

I’m going to assume you meant to say

When I discovered my first few vulnerabilities, I was also kinda confused as to how to approach reporting them to the vendor. In my opinion, you should come up with your own disclosure policy as @ricksanchez has mentioned:

Everyone has different beliefs so you can either drop them sick 0dayz or disclose them responsibly, whatever tickles your pickle. Here are some responsible disclosure policies: Google, Rapid7, CISA. Since I do responsible disclosure, I will show you my reporting procedure (software vulnerabilities).

  1. Try and find a security contact for the vendor. If none exists, try to go through general support lines or Twitter,
  2. Report the existence of a vulnerability in their product,
  3. If the vendor does not reply in 7 days, try and contact them again,
  4. If the vendor does not reply in 14 days of initial contact, publish all information about the vulnerability,
  5. If the vendor replies within the 14 days, report the details of the vulnerability,
  6. If the vendor confirms the vulnerability, provide them 90 days to develop a patch and reserve a CVE with MITRE (if the vendor is not CNA),
  7. If the vendor fails to patch the vulnerability within 90 days, extra time may be given if appropriate for the vulnerability, otherwise, publicise the vulnerability and publish CVE (no technical details),
  8. When the vendor patches, confirm the fix and then publish all information about the vulnerability.

If I notice that a certain vendor has a history of not responding to reports, I will immediately go full disclosure. Same to the vendors who have attitude.

When publishing a CVE and you require a link to an advisory, you can use Exploit DB or Packet Storm (each have rules on what can be submitted, e.g. Exploit DB does not allow DLL hijacking). Personally, I’ve found that using my own GitHub to host the details of the vulnerability also suffices.

Just a little personal thoughts about this disclosure thing, you should be wary of what you do. If a vendor does not like researchers giving “bad publicity” from publishing vulnerabilities, there can be some… issues. Full disclosure is usually looked down upon by the general community from my experience. Know your rights and what you can or cannot do. Avoid ending up on the wrong side of the law. That being said, I do not believe that selling your vulnerabilities or exploits to others is “black hat”.

Correct me if I’m wrong but vulnerabilities are your intellectual property. You are legally allowed to do whatever you want with them, except using them in an illegal manner of course.

8 Likes

According to all your statement it seems there are not standardized guideline out there. It seems each giant company has it’s own policies.

This probably vary among countries but afaik anything can be considered as an intellectual property. For example if your company have some copyrighted material (pdf, videos etc.) about how to exploit an sql injection, it’s considered an IP despite the content “SQLi exploitation techniques” is very common knowledge. So IP is rather an umbrella term.

About vulnerability research, it all depends on the product’s EULA. Some vendors outright prohibit anyone from conducting vulnerability research on their products.
Most vendors prohibit reverse engineering of their products. This does not particularly prohibit anyone from doing VR, but good luck writing an exploit after finding a vuln w/o doing any RE.

So what happens if you do RE/VR on one of these products and actually found a 0day? Nowadays, most vendors won’t sue you just for that (but they certainly would in the past).
When you report a vulnerability (outside a bug bounty program) most probable outcomes are like the following;

  • Vendor responds in a positive manner. They fix the vulnerability and reward you for it.
  • Vendor responds in a positive manner. They fix the vulnerability and thank you for it.
  • Vendor responds in a positive manner. They thank you for it but they won’t fix it in near time.
  • Vendor completely ignores your vulnerability report.
  • On very rare occasions, vendor tries to force you into signing an NDA by saying that they’ll take legal actions if you don’t sign it.

TL;DR - Although vulnerability research is very welcomed nowadays, if you’re conducting it outsite of a bug bounty program or pentest, vendor reserves every right to take legal actions.

5 Likes

For Money : Report To Official Vendor
For Backdoor / Hacking : Just Use It ( Don’t Report)

Greetings @BL4CKH47H4CK3R