Rapid7 throws JetBrains under the bus for uncoordinated vulnerability disclosure

Agreed, this feels a bit like extortion based on the way this article was written. Especially if they were engaged in a paying contract, why would Jetbrains accept disclosure?

That would be insane terms for an audit

>… then there’s no reason…

The reason is to avoid getting dragged by Rapid 7. If you don’t play by the generally accepted community standards for coordinated vulnerability disclosure, you can expect the researchers to point that out as loudly as possible.

It’s extortion, but the alternative is going back to companies ignoring security issues and not telling users about problems.

This seems extortion adjacent enough that, if I was counsel for JetBrains, I'd advise a call to the FBI.

In the latter scenario it's not a good look for either party. JB looks like they want to slide under the radar but R7 looks like it's extorting them.

From a biz perspective, though, why would anyone go to R7 if there's a possibility of them disagreeing with you a throwing you under the bus?

The ideal way is to release a security advisory that some CVE patches are coming with no details, so that upgrades can be prepped coordinated for a known patch day.

The common practice is to hold off disclosure until a patch is ready and has been tested, that way competent organizations will be able to jump on the problem and patch ASAP.

If you release a patch without disclosure there is a good chance many competent organizations will hold off applying it waiting for others to be the canary.

Releasing a patch and mentioning it fixes security issues while delaying vulnerability details is not much better - malicious actors with enough resources will figure out what has been changed and where the problem is. At the same time there will be a strong incentive to downplay the severity.

The issue is JetBrains was trying to avoid having the issues disclosed, or at least significantly delay it. They would have been communicated an explicit timeline and Rapid7s entire process up front. Rapid7 would have let them patch and released the vulnerability details on a generous timeline if JetBrains had continued to communicate with Rapid7. The reason Rapid7 is doing this is because there are so many companies out there that will ghost you and ignore that your firm exists trying to delay the release of your vulns indefinitely. I have released vulns at my company and coordinated dozens of them. Before coordinated disclosure was a thing it was the wild west and companies often did shady things expecting they could muscle or ignore security researchers.

>I'm very much in-favour of the private vulnerability research and responsible disclosure, but the "no silently patching vulnerabilities" sounds more like dick swinging to me than actually wanting to improve people's security.

Rather than dick-swinging, it's generally an acknowledgement that large organizations move slowly and need a bit of prodding to apply patches in a timely manner.

If you're a big-and-slow company, there is a significant difference in how quickly you'll worry about applying the patch that says "here's a minor patch" and the patch that says "here's a patch for a severe vulnerability".

I have worked with several companies which simply will not update something unless they are either mandated to or it is a large enough security risk.

Read more about Rapid7s opinion on silent patching at https://www.rapid7.com/blog/post/2022/06/06/the-hidden-harm-...

The general theory is that there's really no such thing as silently patching. Consider:

- Company silently patches issue. Patches have to be applied, which can take some time if people don't know they need to apply them. Even in the case of automatic updates, patching can be delayed if it requires an app restart, for example. - Malicious actors examine patches, work out exploit, begin exploiting in the wild. - Customers left in the dark. - Company assumes that having issued patches is good enough, substantially delays disclosure.

Co-ordinated disclosure aims to prevent all of that by ensuring everyone knows about it at the same time. That removes some of the ability of threat actors to exploit and allows SOCs, EDRs, etc., to update as well, so anything unpatched gets caught. If there are workarounds or other defenses that can be implemented until patching is possible, those can be employed as well.

Marketing. Companies like rapid7 use that to say “only we detect this live threat, buy us fast!”.

It's the trolley problem.

If you don't disclose the vulnerability, users are potentially open to attack because you didn't tell them about a vulnerability that you knew about. If you do disclose the vulnerability, you potentially alert attackers to take advantage of a vulnerability in the short time before users can address it.

From the perspective of someone discovering a vulnerability, disclosing it is the more ethical thing to do because users should know that they are vulnerable and have the opportunity to prevent harm to themselves, even if it means making a service unavailable or degraded for a short period. If you tell them about it and they are attacked, that's on them. If you don't tell them and they are attacked, that's kind of on you.

I agree there's some grey area if there no known exploits, but a lot of times these vulnerabilities are found in response to an actual out-in-the-wild exploit.

Rapid7's article on the topic[1] mostly focuses on the need for providing enough information to IT admins so they can understand the severity of the problem. There are other unsaid reasons for this (credit/payment I'd imagine is part of it), but on face value doesn't this make sense? When Metabase[2] says "Upgrade your instance NOW" and they have a vuln that "allows unprivileged access to any Metabase instance" I upgraded immediately. When JetBrains[3] says "4 security problems have been fixed. We highly recommend installing this update as it includes a fix for a critical security vulnerability" then many people are not going to upgrade as quickly. Jetbrains eventually gave more information[4] but would they have done this if Rapid7 wasn't threatening to disclose it themselves?

^1: https://www.rapid7.com/blog/post/2022/06/06/the-hidden-harm-...

^2: https://discourse.metabase.com/t/upgrade-your-metabase-insta...

^3: https://www.jetbrains.com/help/teamcity/teamcity-2023-11-4-r...

^4: https://blog.jetbrains.com/teamcity/2024/03/additional-criti...

The issue here is that the vendor did release patches, but then tried to hide that they fixed a vulnerability. This is usually called "silent patching", and it's controversial. As with any disclosure discussion, there are lots of opinions here and everyone likes to call everyone else irresponsible.

If you're pro-silent patching, you might argue that it reduces the number of people who know about a vulnerability, so publishing advisories is irresponsible.

If you're anti-silent patching, you might argue that it reveals the vulnerability to the people who monitor patches without giving any warning to the affected users that they need to patch, so not publishing advisories is irresponsible.

Maybe you're just a "minimum details" kind of person, and providing full details is irresponsible. Or maybe you're a "full details" kind of person, and restricting security professionals from accessing the information they need to do their jobs is irresponsible.

In summary, I'm irresponsible for leaving this comment and you're irresponsible for reading it.

They stopped communicating with Rapid7. When you stop, you know, coordinating with the researchers they are free to do what they want. Rapid7 likely gave them their entire process, set expectations and coordinated with JetBrains up front. This is sort of an “ethical standard” most firms and security researchers follow. The timeline’s they use and the exact process they follow varies. The key goal is to keep the vulnerabilities public and properly credit the researchers. Coordinated disclosure is an olive branch, so you know exactly what to expect and how to behave. It is generally very reasonable. If you break the terms or spirit of this process the researchers have no reason or real recourse but to release their info whenever they want and feel is appropriate. Don’t break the faith, the researchers are essentially doing you a favor by following this policy. It really is not hard to communicate and act in good faith on both sides. I have coordinated the release of dozens of vulnerabilities. I have definitely disclosed them after companies ghosted us or threatened us hoping to make the issue go away.

JetBrains got cute and cut the researchers out of the loop. Now future researchers will likely treat JetBrains as a bad faith actor and proceed accordingly.

It very much is the norm, lots of security research companies have similar policies. It’s called coordinated vulnerability disclosure, or CVD. Rapid 7 is throwing the random company under the bus to protect users of that company’s software.

And of course to market Rapid 7.

You sure? Coordinated disclosure works like this. I find a vuln. I give you a timeline of my release. You accept that and work with me to acknowledge it and prepare your users. We negotiate release timing. Sometimes, if there is no evidence of exploitation we can push it out a little. If you stop communicating or act in bad faith I am doing whatever I want. You didn’t pay me and your users deserve to know. There are so many bad faith orgs that will try to avoid disclosure entirely or act downright hostile towards security researchers. Someone’s wires got crossed at JetBrains. Rapid 7 discloses a lot of vulnerabilities using this exact process. Many orgs use coordinated disclosure. They don’t all use the same timelines and processes, but those are the broad strokes. I have helped disclose many vulns using coordinated disclosure so I get where Rapid7 is coming from. It’s like this: It’s my vuln info. I will do whatever I want with it. I decided to give you my entire process and timeline to give you a chance to deal with it. You decided to ignore my “terms” and stop participating in the process. I am free to do what I want with the vuln now as I have exceeded my ethical obligations to help you.

my understanding matches yours. I don't think this article is particularly clear about why rapid7 would threaten to disclose a vulnerability before a patch is ready and then subsequently get angry that jetbrains put out a patch to fix the issue

> Does anyone have context for why "best practice" would be to disclose before there's a fix available?

If it is already being exploited is one reason.

A fix may not be available, but if folks know there's an attack going on, they can make a more informed choice in still whether to allow the code to run: in some cases a loss of service would be better than a compromise.

If the code is externally-facing, then they bring it down; if it is internal-only, then it may be judged that the risk is low(er) and things to be continue to be run (and a maintenance window can be pre-planned for when the fix comes out).

There's always a way to prevent or mitigate harm. You can suspend or degrade service temporarily until a fix is applied.

>so rapid7 is mad that jetbrains fixed the vulns they reported?

No. They are mad that they vulnerabilities were _silently_ fixed.

It’s a bad article trying to spin it. This is business as usual for vulnerability disclosure. The Reg is always sensationalizing things to get clicks. Just add any infosec research firm ever that has disclosed a vulnerability using coordinated disclosure to your list. Like say Google and their Project Zero. They follow very similar policies and if you stop communicating with their researchers they will just drop your bugs.

>I'll be adding them to my list of "companies I'll never do business with".

They are following all industry best practices, so I hope you're prepared to add every reputable infosec company onto your list.

Trying to have some ethics in this space makes sense though, you probably don't want to be directly responsible for causing pain and stress to users, yes, the company developing the software should do better security-wise, it does not remove your responsibility from selling it to the gray market and potentially causing massive issues to end users who have no horse in the race in your fight against the developers, you are potentially making victims for a quick pay off and making a statement.

Are you working on this to make software more secure or is it simply about money? You can make more money if you cozy up with some criminals, where will you draw the line?