Participating in the field of IT security exposes you to the chance that you stumble upon services, software or hardware which you may find vulnerable. Either the logic of the objective is broken ("Why am I able to edit this text?!"), or you can inject arbitrary SQL or Shell ("Haha, sleep(100) breaks my connection!"), or maybe something else. You then start to search on the internet for that vulnerability. Maybe you'll find a CVE number matching that vulnerability? Or a blog post? A tweet? At least a confirmation notice written by the vendor?

In most cases, you find something. Nice, time to search for a publicly available exploit!

But in some cases, you find nothing.

But what now?

First of all, you need to be aware of the responsibility you carry from now on. Sure, one could argue that there are many skilled people out there who may also find that vulnerability - or already have found it in the past! - and who may process that vulnerability responsible-minded. Another argument could be: "But it's not my responsibility to disclose that vulnerability!"

It's obvious that both arguments are weak and can't hold up against a closer look. The moment you search for vulnerabilities and other security issues, you need to be aware of your obligation, to inform the vendor, to inform others, to make that vulnerability public. Short: to minimize the impact, the damage the vulnerability may create.

"But I wasn't aware of that!". Well, your problem. Try to cope with that. Let's draw a comparison: The moment you get your drivers license, buy a car and start the engine, you need to be aware of the fact, the possibility, that you may hit someone or something with it - maybe injure someone with that car. Maybe you hit someone so hard that it's a fatal injury? May be! It doesn't even need to be your fault, however, if you would've avoided to drive that car, you may have prevented the injury of said person. Of course, many drivers out there will never ever fatally injure someone in their driver's lifetime, thus keeping in mind that it may happen could slowly fade from your mind, taking just the backseat of your car if you drive with it.

Maybe you find that comparison a bit uneven. However, it shows that, if you are not aware of your responsibly all the time when you actively search for security issues, then you miss out an important aspect of the whole operation. You rely on others disclosing security vulnerabilities you didn't search for, like in the Linux Kernel (how many CVEs did you pull out of the Kernel? None? Ah, okay), your ISP's mail server (I heard Exim is secure?) or your IP-connected camera (greetings to twink0r, a2nkf and me). You never searched every bit of source code you are using, either directly used in your projects, or indirect in your Smart Fridge, Internet-connected Tooth Brush, your car, on your server, in your CPU, ... you name it. You simply believe that If there is a security issue, it will become public sooner or later. And yes, that may happen. But if you encountered security issues, you are part of the process - it may depend on you if it becomes public sooner or later. What about EternalBlue, KRACK, Meltdown, ShellShock, DirtyCow, DROWN, Heartbleed? All of them: attacks that were possible over a long time, some of them utilizing a single line of faulty code which was there over years. Nobody can surely tell if someone attacked me - or you? - with one of these attacks. We will never know.

Even if you will never find a security issue with an impact as wide-spread as the named ones: you need to publicize your knowledge as soon as possible.

But how?

First of all, try to get more information about the security issue. If you encountered it in the wild, try to find the faulty source code lines, if you have access to it. Try to compile or build it, try to run it, try to rebuild the attack scenario in which you identified the security issue in the first place. More simple, try to replicate the attack. Maybe write a small exploit for it. That ensures that you are doing the exact same steps on different targets, that the attack is comparable over different machines.

To be honest, I can't write a step-by-step guide on verifying vulnerabilities - it's mostly a matter of the specific case. But it's a good idea to keep your playground as local and isolated as possible. Don't simply attack other people's services.

Small paranthesis about finding the same (and, identified by yourself, faulty) service on different machines: Don't simply attack services you found with search engines like Shodan. Why? Because you are unable to determine whether or not you are generating side effects. Exploiting an undiscovered vulnerability, for example on the mail server of a company, may trigger processes you didn't know about in the first place. Do you know what time-critical processes are relying on that mail server? Maybe a whole production line stops for hours if you kill the process. Maybe a firewall, IPS or Security Gateway kills your connection and cuts off the uplink of the server, for security reasons? Maybe you attacked a power plant without your knowledge and risk an electricity cut? Or you hit a hospital and risk health of many? ... That's why you should never hit on services or machines that you don't know enough about. And that's the case for nearly any host found on search engines like Shodan. And no, you can't know about every side effect you may generate. Oh, and just to mention it: it's illegal to attack other peoples services...

If you found a vulnerability in an open-sourced project, try to send the creator or the company/NGO behind it an e-mail, informing about the issue. I'd advice against opening an issue in GitHub as a first step: that's a public disclosure, and you're not granting the vendor enough time to fix the issue and release updates. You risk 0day exploits, with unknown impact. Even if that was not your intention, because "Creating an issue is the best way to tell the project that they have a problem". But it's not.