I scanned a site using a vulnerability scanner and it found a vulnerability with a CVV score of 10. Should I send the report to the company?
-
29Why wouldn't you report? What's the source of your question? – schroeder Nov 08 '19 at 17:13
-
21Report it as opposed to what - hacking it? – Conor Mancone Nov 08 '19 at 17:38
-
19As a n0ob - I think the alternative to reporting it would be *not* reporting it. This question heavily implies that the scan was done without prior authorization from the company. I'm not a lawyer and I'm not saying it's illegal, but I would be concerned about consequences for myself. I know for a fact my ISP (Xfinity) prohibits this activity and reserves the right to immediately suspend my account for violating it. There are local/state laws I might not be aware, and I do know companies could have a civil claim against you for damages as the result of a scan. – Rob P. Nov 10 '19 at 08:40
-
1@RobP. You should see the original question.... – Conor Mancone Nov 10 '19 at 13:12
-
2Possible duplicate of [How to report vulnerabilities without being regarded as a hacker?](https://security.stackexchange.com/questions/71905/how-to-report-vulnerabilities-without-being-regarded-as-a-hacker) – Dmitry Grigoryev Nov 11 '19 at 07:53
-
3@ConorMancone All I see in the edits is "I haven't hacked it"--but that mostly doesn't matter! As other answers have pointed out, if you did not have permission to scan/test that site, you probably already broke the law. If the company is mad about you checking up on them, they can potentially cause real trouble for you. – GrandOpener Nov 11 '19 at 17:05
3 Answers
Quick note: this answer assumes that you have permission to run scanners against the website. Running scanners against a website is illegal in basically all jurisdictions, so if you are doing that then my only suggestion is: "STOP!".
What you shouldn't do
You should never send a vulnerability report from a scanner to a company. 90% of the time those are useless by themselves, and are likely to be ignored by any competent security team. The reason is because scanners can have any number of false positives, so a positive from a vulnerability scanner does not actually mean there is a vulnerability. However, it is common for new bug bounty testers to simply send vulnerability reports from scanners off to companies without any understanding of what the report says, if it is correct, or if it is even applicable. As a result security teams will often just ignore a report that came straight out of a scanner. Most bug bounty programs specifically state this.
What you should do
Instead you should take the time to generate a vulnerability report yourself, which means that you describe the nature of the vulnerability, steps they can take to confirm your findings, the risk the vulnerability creates for the company, and potentially even steps they can take to mitigate the danger. That is what you should send to the company, and sending something like that is almost always a good idea.
If this is a company that doesn't have a public bug bounty program then they are even less likely to be able to make sense of a report out of a scanner, so it will be that much more important for you to take the time and provide an actually vulnerability report detailing the vulnerability, the impact to the business, an estimate of its severity, and suggested mitigation steps. Obviously though that's not the situation you are in, since running automated security scans on a website without explicit approval is illegal in most jurisdictions and a bad idea in general...
tl/dr:
Should you send the results from your scanner to a company? No, because that's often useless. What you should do is verify that the scanner isn't reporting a false positive and then send a report detailing the vulnerability, what they can do to reproduce it, an explanation of its impact, and suggested mitigation steps. You obviously shouldn't "hack" into the system under any circumstances.
- 29,899
- 13
- 91
- 96
-
35I'm one of the security team members who receives random reports like this. I agree that 90% of the time it's a false positive sent by an amature sec researcher who has no idea what the finding means. That said, 10% of the time, it's a tool we don't run and it's useful. Also, 100% of the time it tells us about the PR impact of people scanning our site. We do sometimes make "unnecessary" code changes purely for PR reasons so that our customers get less alarmed when they run a scan. – Mike Ounsworth Nov 08 '19 at 18:15
-
4@MikeOunsworth I went ahead and updated my question to better emphasize my actual suggestion, which is sending a detailed vulnerability report instead of a report from the scanner. Although in doing so the organization of my answer now more closely mirrors yours. :shrug: – Conor Mancone Nov 08 '19 at 18:35
-
6@user1067003 I don't really agree. Expecting to scan sites without permission would be like walking down the street trying to open people's front doors. Then when someone calls the police and they show up you reply with, "I'm just checking to make sure that people locked their doors" and expecting the police to be happy with it. It's a terrible idea. – Conor Mancone Nov 10 '19 at 12:44
-
It is true that current laws make it dangerously easy for misunderstandings to lead to criminal charges for legitimate security researchers that were just trying to help. It would be great to fix that. But being able to perform active penetration testing on sites without permission is not a reasonable solution. – Conor Mancone Nov 10 '19 at 12:45
-
"verify that the scanner isn't reporting a false positive [..] shouldn't "hack" into the system". Not saying it's impossible to verify without breaking into the system, but in many situations that doesn't seem easy to do. – Voo Nov 10 '19 at 13:35
-
@Voo that's not usually too big of a problem. Presuming that you are working with permission or under an established bug bounty program, the extra steps required to verify the report wouldn't be considered hacking and are just part of the job. Also, many times the false positives are easy to verify as such with little extra effort. – Conor Mancone Nov 10 '19 at 13:45
-
@Conor But the premise here is to only contact the people *after* verifying there's no FP. Sure if you have a bug bounty program or permission (and really if you have neither you should never have scanned them in the first place, which makes this point moot) it's simpler, but then I'd think that generally involves contacting someone. But say you get back that there's probably a vulnerable version of Apache installed - how do you figure out whether that's correct or not without trying a vulnerability? (The server might just be configured to send any old information back after all) – Voo Nov 10 '19 at 13:58
-
@user1067003: Please refrain from coarse language on SE. It demeans all of us and it's totally unnecessary. – Transistor Nov 10 '19 at 20:07
-
@Voo my answer is really just approaching this from the perspective of activity with permission or under a bug bounty. As I mention in my answer, scanning websites without permission is illegal, so obviously the OP wasn't asking about that. If someone was scanning illegally then the only advice I have is to stop doing that. – Conor Mancone Nov 10 '19 at 20:20
-
-
2@ConorMancone Please include your last comment in the body of the question, because it's relevant: the question implies that the OP has not contacted the company, and therefore does not have permission. – jpaugh Nov 10 '19 at 23:33
-
1@jpaugh I already had mention of that in my answer, although obviously it wasn't obvious enough. I've put up a small update accordingly. – Conor Mancone Nov 11 '19 at 13:13
-
I'd question the competency of any security team which disregards reports of public-facing 10.0 CVEs just because the reporter is "some skiddie using a scanner". – jdgregson Nov 11 '19 at 17:15
-
@jdgregson A CVE is not something that a "skiddie" would have access to. From what I've heard, you basically have to know the right someone in order to get a new CVE assigned to a vulnerability once you've discovered it. – jpaugh Nov 11 '19 at 23:48
-
@jpaugh I think in this context we're talking about known vulns which happen to be CVE 10. For example, finding a server still vulnerable to Heartbleed. A scanner wouldn't be scanning for -1-days to begin with. – jdgregson Nov 12 '19 at 06:27
-
@jdgregson You mean every common vulnerability has its own CVE? I thought those only applied to specific bugs of specific software. There are any number of ways to incorrectly build & deploy a website (which I would expect a scanner to catch); but I'm surprised to hear that all of those would also have CVEs. – jpaugh Nov 12 '19 at 16:15
-
@jdgregson Now that you mention it, CVV was *probably* a typo. I heard CVSS, while you obviously heard CVE. Both are good guesses... – Conor Mancone Nov 12 '19 at 16:57
Rule one of vulnerability scanning or any other activity that could possibly be interpreted as hostile: get permission in writing signed by senior management first. An unsolicited "vulnerability scan" is indistinguishable from a hacking attempt - and if you used a common tool, and they have any smart monitoring going on, they will have detected that scan, and logged your IP address. And a poorly-worded report of a vulnerability you have found is indistinguishable from a threat. If you're lucky, the existence of a common bug in their site might mean they don't have good monitoring. However such a company is more likely to call the police if they think, however incorrectly, that you are threatening to hack them.
Consider it this way: a random stranger one day tells you that you left your windows unlocked. He or she swears that they didn't go into your house. Would you be grateful or would you wonder why this person was trying your windows?
It is sad to say but this is the reality of the world today - your most sensible option is to do nothing. Consider that you have learned something about vulnerability scanning today, and move on.
- 810
- 6
- 7
-
6
-
18+1 to this. I know someone who ran a vulnerability scanner against a small website just to see what would happen and it destroyed the website. It found a whole load of vulnerabilities but also wrecked the database and the website wouldn't load anymore. Be very, very careful. Nobody should be running vulnerability scans without permission. – niemiro Nov 09 '19 at 15:30
-
7Another +1. Every time I read about someone running a vulnerability scan on some site (not owned by that person), it strikes me as why the hell do they even think they're entitled to do so. It's like using a crowbar on someone's front door only to verify whether it's burglary-resistant. Surely, nobody would have the idea that this is legitimate in the real world. – Damon Nov 09 '19 at 20:28
-
4Yes, it is way too risky to report it. Just ask [one of the authors of the famous book *Programming Perl*](https://en.wikipedia.org/wiki/Randal_L._Schwartz#Intel_case). – Peter Mortensen Nov 09 '19 at 21:19
-
*Would you be grateful or would you wonder why the person was trying your windows?* — the answer probably says a lot about local culture. – gerrit Nov 11 '19 at 12:35
Do you want to be a white-hat or black-hat? The answer may also depend on what laws apply based on what country you are in, what country the company is in.
Things that are always ok
Use a responsible disclosure process to disclose the finding to the company.
See if the company has a vulnerability reporting process. A good place to start is seeing if they have a https://company.com/.well-known/security.txt
. If not then search around and see if they have a security email address for reporting things like this.
Another option if you can't or don't want to deal with the company directly is to report through a middle-man like US Cert.
It should also be stated here that if you want the company to take you seriously, you need to clearly describe the issue, steps to reproduce, describe how pervasive it is in their application, what damage and attacker could cause with it, and what they should do to fix it. If you just send them the report from a scanner, they will likely ignore you, or worse send a lawyer after you (see below).
Things that are sometimes ok
Sometimes it's ok to publish the result without informing the company (for example by filing a CVE, or writing a blog post, github repo).
Depending on the type and severity of the vulnerability, this could end up doing more damage than good if people get hacked before the company has time to fix it.
"Things that are sometimes ok" could include running the scanner in the first place. Unless you are hired to do that or there's a bug bounty program, it could be interpreted as a hacking attempt. (Thanks @EsaJokinen). A quick google-search shows that when you do "security research" without permission you're just as likely get lead to jail time, as to get a thank you:
- Feds Expand Security Researchers' Ability to Hack Without Going to Jail
- Security researcher arrested for disclosing US election website vulnerabilities
- Arrested security researcher’s case takes a turn
- When cybersecurity research leads to jail time
- Protect the White Hat Hackers Who Are Just Doing Their Jobs
Hitting someone else's website with a security scanner can land you in big trouble, so make sure you understand the legal implications before you do it!
Things that are never ok
Hacking the website yourself.
This is undoubtedly illegal in every country that has laws about this.
Be very careful taking this approach because you can lose a lot, and I'm not sure you gain anything (at least from a white-hat perspective).
- 57,707
- 21
- 150
- 207
-
This is the first time I've heard of US Cert. If you have time, would you mind joining me in chat so I can ask you a question about it? Obviously no big deal if you can't – Conor Mancone Nov 08 '19 at 18:37
-
2@ConorMancone Which chat channel? I don't know a ton about US CERT, except that they will act as an intermediary where a researcher is too small to get noticed, wants to maintain anonymity, or the researcher feels they will be legally intimidated by the vendor. From the linked site: _"CISA will attempt to coordinate all reported cyber vulnerabilities with the affected vendor of industrial control systems or information technology products."_ – Mike Ounsworth Nov 08 '19 at 19:07
-
There is a local app here that has some severe weaknesses. I found them without even doing any actual penetration testing - their application effectively has zero security at all. It's a tiny system, but has probably a few thousand users (with passwords) in a database that is wide-open to easy SQLi. I sent a full disclosure report to the vendor but was completely ignore (contacted through multiple channels). They might take it more seriously if someone other than an anonymous person contacted them. – Conor Mancone Nov 08 '19 at 19:27
-
So basically I was wondering if US Cert might be the sort of organization that would get involved in something so tiny, or if they were more interested in "substantial" threats. If you're not sure though then I'll google or maybe just contact them anyway – Conor Mancone Nov 08 '19 at 19:27
-
10"Things that are sometimes ok" could include running the scanner in the first place. Unless you are hired to do that or there's a bug bounty program, it could be interpreted as a hacking attempt. – Esa Jokinen Nov 09 '19 at 11:34
-
1This is the first time I've heard of `.well-known`. Ironic, isn't it? – CJ Dennis Nov 10 '19 at 00:49
-
-
1@ConorMancone the national CERT *will* care about that, enough to forward the report to the proper recipient. In case it wasn't a US company, I would recommend contacting instead the respective national CERT (you can find most of them on [FIRST](https://www.first.org/members/teams/)), but other than that, a working CERT that receives a proper report for a company under their constituency, _will_ (attempt to) report it to the affected party. It is their job! – Ángel Nov 12 '19 at 00:21