7 ms·

Rapid7 throws JetBrains under the bus for uncoordinated vulnerability disclosure

90 points by el_duderino 3y ago

pierat 3y ago
Seems like infosuck folks are squabbling over "who can be the most-est-est ethical". Im like, if I do a reporting over a vuln, you can pay me. Ive been stiffed over the last 2 where a real vuln is claimed as "not a problem", and then patched. Im looking at selling to graymarket dealers my vulns instead. At least they pay.
- piva00 3y ago
  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?
  - saltyspaghetti 3y ago
    I really hate this take. If a company refuses to pay more than the gray market is offering, then they are the ones at fault for putting their users at risk. Go and guilt trip the entities who are undervaluing the time and effort spent finding vulnerabilities. I place zero blame on researchers selling vulns unless the software company is willing to pay at least as much as the gray market.
    - piva00 3y ago
      And I really hate this take. It's basically a hostage situation then "pay us as much as those criminals there would pay or else... Your users will suffer the consequences". Yes, it's the company's fault for putting the users at risk by creating an exploitable issue, there's the other side of the coin where it will be the "researcher's" fault for selling it to the highest bidder damned be the consequences. Both sides have their ethical issues, I think the company should pay but also that researchers should look quite deep into their souls if it's ethical to fuck with users because an entity they have no control over (the company) fucked up. To me it sounds like an immature tantrum, unfortunately from my experience with security researchers it feels to be a field with quite a few rage-tantrums. Ethics do matter, on both sides.
      - saltyspaghetti 3y ago
        Why shouldn’t there be bidding wars to determine the value of an exploit? These large software companies have zero issue with exploiting capitalism when it benefits their bottom line, and yet it’s suddenly unethical for a researcher to demand to be paid market value for their work? Look at Google, a 1.6 trillion dollar company. They have virtually limitless resources when it comes to paying for secure software, and yet they offer less than half the $ for an Android zero click when compared to Zerodium. Pay people the fair market value for their work and all of this becomes a non-issue. They can afford to do it.
        piva00 3y ago
        The ethical issue is when this capitalist fight between market prices for exploits have very real damaging consequences for unwitting users that have nothing to do with the bullshit. Why should they pay the ultimate price because a company is trying to fleece security researchers? Is that the only way to make them pay, to cause damage to what amount to "civilians" in this war? That's my point, these people, very real people, have nothing to do with the whole bullshit, they trusted in a 3rd party to use their product, they can't audit every single 3rd party they use for security holes, even less research themselves ways to exploit them before using their products, you are saying that it's ok for these people to suffer because Google didn't want to pay for an exploit that was discovered. It boils down to the same question: why are the researchers doing this job? If it's because they believe they are helping make software more secure then ethically they shouldn't be putting unwitting end users into harm. If they are just looking for a paycheck then it's just morally corrupt to use users as hostages to get a ransom. I repeat what I said: this is the ethical discussion I'd like to see happening, not this immature "they didn't pay me, so fuck all the users, I will blow it all!", that just sounds like children throwing tantrums. Again: why do researchers do this job? Underneath that you can judge if it's ethical to just sell to the highest bidder, capitalism is amoral, we as humans imbue some sense of morality into it... This approach of "pay what the market is paying or else I will fuck your users" is, in my opinion, ethically wrong, if a researcher is serious about the job they are performing to make the world a less shit place then they need to have some moral guideline to follow, if not it's all bullshit and they are just mercenaries, and I don't support mercenaries.
denotational 3y ago
> According to the cybersecurity company, it replied by saying it wouldn't agree to swift disclosure, and pointed JetBrains to its policy against silently patching vulnerabilities, which stipulates that if companies violate that policy, Rapid7 will itself release the full details of the vulnerability, including enough information to allow people to develop exploits, within 24 hours. Did JetBrains engage Rapid7 to conduct an audit? If not, I think describing this as a “violation” is a step too far: if two companies have no pre-existing relationship then there’s no reason for one of them to start complying with arbitrary policies set by the other. If on the other hand JetBrains engaged Rapid7 to audit TeamCity and then tried to wriggle out of their contract when a vulnerability was found, then this isn’t a great look.
- kevml 3y ago
  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?
- deleted 3y ago
  [deleted]
- yread 3y ago
  That would be insane terms for an audit
  - c0pium 3y ago
    It’s not uncommon for security researchers to require coordinated disclosure (although often with longer timelines) even in paid engagements.
    - hiatus 3y ago
      Any basis for this statement? Having been through multiple pentests I have never seen any clause like that in a contract. Given the commoditized nature of security vendors these days, I would be surprised to see such an anti-customer clause become commonplace.
_cenw 3y ago
>Such a move is typically seen as a no-no by the infosec community, which favors transparency. Transparency, sure, but since when do we release CVE details before a patch? Even in open source projects, there often is only an announcement that there will be an important patch, and the writeup / CVE content is at earliest published the day after the patch is available. Giving some notice on a closed source product seems even more sensible because it's much harder to extract a vulnerability from a point release.
- gurchik 3y ago
  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-of-silent-patches/ https://www.rapid7.com/blog/post/2022/06/06/the-hidden-harm-... ^2: https://discourse.metabase.com/t/upgrade-your-metabase-instance-now/26062 https://discourse.metabase.com/t/upgrade-your-metabase-insta... ^3: https://www.jetbrains.com/help/teamcity/teamcity-2023-11-4-release-notes.html#Security https://www.jetbrains.com/help/teamcity/teamcity-2023-11-4-r... ^4: https://blog.jetbrains.com/teamcity/2024/03/additional-critical-security-issues-affecting-teamcity-on-premises-cve-2024-27198-and-cve-2024-27199-update-to-2023-11-4-now/ https://blog.jetbrains.com/teamcity/2024/03/additional-criti...
  - lolinder 3y ago
    This is a decent explanation for issuing a CVE and a clear disclosure immediately after a patch is available, but the claim in the article is that best practice is to reveal immediately regardless of whether there's a patch. That makes no sense to me.
gregoriol 3y ago
Why is there such an urgent need to release details about a vulnerability while services are at risk? Is the glory of security researches to put people and companies at risk? Release a statement when you find it, then the details some weeks after the patches are available.
- liquidpele 3y ago
  Marketing. Companies like rapid7 use that to say “only we detect this live threat, buy us fast!”.
  - c0pium 3y ago
    It’s primarily marketing for sure, but the fig leaf is that the details allow targeted detections and mitigations based on the details of the bug. You can use the PoC code to test WAF rules for instance.
  - gregoriol 3y ago
    So why not inform vendor, release a statement like "found something big" without details, get the marketing from it, and provide the details 30 days after patch is made available. That way it hurts users less.
    - ziddoap 3y ago
      >and provide the details 30 days after patch is made available.That way it hurts users less. The bad guys will figure out how to go about exploiting the vulnerability almost immediately after the patch releases, if they aren't already exploiting it. It makes 0 sense and protects 0 people to hold onto details after the patch is made available.
      - gregoriol 3y ago
        This is true for open-source but not as much for closed-source as in this case. Also, how does it ever help anyone to have the details released? It only helps the researchers for PR and bad actors, never the users who need to apply the patch (and often need some time to, one can't just upgrade something out of nowhere in less than 24 hours).
cp9 3y ago
so rapid7 is mad that jetbrains fixed the vulns they reported? isn't that the point of reporting vulnerabilities? why is rapid7 threatening to release the details in 24 hours?
- ziddoap 3y ago
  >so rapid7 is mad that jetbrains fixed the vulns they reported? No. They are mad that they vulnerabilities were _silently_ fixed.
  - hiatus 3y ago
    Where does the article say that? I see: > Rapid7 says it reported the two TeamCity vulnerabilities in mid-February, claiming JetBrains soon after suggested releasing patches for the flaws before publicly disclosing them. So JetBrains wanted to have a patch ready before disclosing the vulnerability publicly. It seems they were working on it and were working with Rapid7. I am struggling to think how it would be better for users if an unpatched vulnerability is released before a patch is available. What's the thinking here, that users will take additional precautions to secure the application while they wait for a patch?
    - ziddoap 3y ago
      >Where does the article say that? The first sentence. >Security shop Rapid7 is criticizing JetBrains for flouting its policy against silent patching Why Rapid7 doesn't like silent patching can be found here: https://www.rapid7.com/blog/post/2022/06/06/the-hidden-harm-of-silent-patches/ https://www.rapid7.com/blog/post/2022/06/06/the-hidden-harm-...
    - IshKebab 3y ago
      It says it right here: > Rapid7 spotted fresh patches for CVE-2024-27198 and CVE-2024-27199 on Monday, without a published security advisory and without telling the researchers.
      - hiatus 3y ago
lolinder 3y ago
Does anyone have context for why "best practice" would be to disclose before there's a fix available? This is news to me (most of the time I see CVEs it's right after a patch), and it seems backwards—if there's nothing that customers can do about it yet then what good is releasing the details of the vulnerability?
- cp9 3y ago
  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
  - ziddoap 3y ago
    >angry that jetbrains put out a patch to fix the issue They are angry that it was a _silent_ patch. The whole issue revolves around the _silent_ part. More on why Rapid7 doesn't like silent patching here: https://www.rapid7.com/blog/post/2022/06/06/the-hidden-harm-of-silent-patches/ https://www.rapid7.com/blog/post/2022/06/06/the-hidden-harm-...
- throw0101d 3y ago
  > 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).
- codexb 3y ago
  There's always a way to prevent or mitigate harm. You can suspend or degrade service temporarily until a fix is applied.
FinnKuhn 3y ago
"Rapid7 says it reported the two TeamCity vulnerabilities in mid-February, claiming JetBrains soon after suggested releasing patches for the flaws before publicly disclosing them. Such a move is typically seen as a no-no by the infosec community,..." As far as I am aware the majority of the infosec community would prefer to release a patch before releasing a security issue, but what do I know...
- TheGeminon 3y ago
  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.
- c2h5oh 3y ago
  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.
- bitexploder 3y ago
  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.
gtirloni 3y ago
Does Rapid7 get paid by customers to do that for 3rd-party software the customers use and then they report it to the upstream vendor (JetBrains in this case)?
suddenclarity 3y ago
This case aside, the real issue is Rapid7 having a written policy of throwing users under the bus to gain publicity by publishing vulnerabilities before they have a chance to update. Contrary to what the "security journalist" claims, this isn't the norm.
- c0pium 3y ago
  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.
- bitexploder 3y ago
  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.
015a 3y ago
I don't know what "norms" Rapid7 is expecting JetBrains to have followed, but this article certainly makes them come off in an entitled, power-tripping light, like their glory is more important than security. I'll be adding them to my list of "companies I'll never do business with".
- bitexploder 3y ago
  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.
  - yegnau 3y ago
    Everyone has their coordinated disclosure policies, but not all of them are as harsh as Rapid7's. You mentioned Project Zero, it's a great example: >Project Zero follows a 90+30 disclosure deadline policy, which means that a vendor has 90 days after Project Zero notifies them about a security vulnerability to make a patch available to users. If they make a patch available within 90 days, Project Zero will publicly disclose details of the vulnerability 30 days after the patch has been made available to users. https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html https://googleprojectzero.blogspot.com/p/vulnerability-discl... Giving vendors 30 days after a fix is a much more user-friendly thing to do then releasing ready-made exploits simultaneously with a patch, isn't it?
    - bitexploder 3y ago
      Yes, I agree, but Rapid7 does not normally do that. https://www.rapid7.com/security/disclosure/ https://www.rapid7.com/security/disclosure/ “ If the responsible organization is showing consistent good-faith effort to develop and ship an update, but cannot complete this work within 60 days, a 30-day extension may be granted at Rapid7’s sole discretion under the Default Policy (or for any of the enumerated exceptions below).” They do this with good faith as far as I have seen. The issue as I see it is that JetBrains decided to stop communicating, eliminating the “good faith” on their end.
robomartin 3y ago
JetBrains will do the right thing. They have been doing so for years. It's amazing to see how, time after time, the internet loves to destroy anything and anyone and utterly ignores the rest of their existence. It excels at bringing out humanity's lowest forms to the forefront. No association other than being a happy paying customer.
jamescun 3y ago
Why is silently patching considered a "no-no by the infosec community"? If your product's automatic update functionality can reach most users within the responsible disclosure window, that sounds like a net positive? We still learn about the vulnerability but limits the potential fallout of the disclosure. I'm very much in-favour of the private vulnerability research and responsible disclosure, but the "no silently patching vulnerabilities" sounds more like wanting to own the press to me than actually wanting to improve people's security.
- ziddoap 3y ago
  >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-of-silent-patches/ https://www.rapid7.com/blog/post/2022/06/06/the-hidden-harm-...
- BeefWellington 3y ago
  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.
deleted 3y ago
[deleted]
damm 3y ago
It will take 30-180 days for some enterprise orgs to upgrade Teamcity to mitigate the vulnerability. That grace period used to exist before publishing a vulnerability unless it was being actively exploited.
uticus 3y ago
see also https://news.ycombinator.com/item?id=39606973 https://news.ycombinator.com/item?id=39606973

90 points by el_duderino 3y ago

Seems like infosuck folks are squabbling over "who can be the most-est-est ethical". Im like, if I do a reporting over a vuln, you can pay me. Ive been stiffed over the last 2 where a real vuln is claimed as "not a problem", and then patched. Im looking at selling to graymarket dealers my vulns instead. At least they pay.

piva00 3y ago
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?
- saltyspaghetti 3y ago
  I really hate this take. If a company refuses to pay more than the gray market is offering, then they are the ones at fault for putting their users at risk. Go and guilt trip the entities who are undervaluing the time and effort spent finding vulnerabilities. I place zero blame on researchers selling vulns unless the software company is willing to pay at least as much as the gray market.
  - piva00 3y ago
    And I really hate this take. It's basically a hostage situation then "pay us as much as those criminals there would pay or else... Your users will suffer the consequences". Yes, it's the company's fault for putting the users at risk by creating an exploitable issue, there's the other side of the coin where it will be the "researcher's" fault for selling it to the highest bidder damned be the consequences. Both sides have their ethical issues, I think the company should pay but also that researchers should look quite deep into their souls if it's ethical to fuck with users because an entity they have no control over (the company) fucked up. To me it sounds like an immature tantrum, unfortunately from my experience with security researchers it feels to be a field with quite a few rage-tantrums. Ethics do matter, on both sides.
    - saltyspaghetti 3y ago
      Why shouldn’t there be bidding wars to determine the value of an exploit? These large software companies have zero issue with exploiting capitalism when it benefits their bottom line, and yet it’s suddenly unethical for a researcher to demand to be paid market value for their work? Look at Google, a 1.6 trillion dollar company. They have virtually limitless resources when it comes to paying for secure software, and yet they offer less than half the $ for an Android zero click when compared to Zerodium. Pay people the fair market value for their work and all of this becomes a non-issue. They can afford to do it.
      - piva00 3y ago
        The ethical issue is when this capitalist fight between market prices for exploits have very real damaging consequences for unwitting users that have nothing to do with the bullshit. Why should they pay the ultimate price because a company is trying to fleece security researchers? Is that the only way to make them pay, to cause damage to what amount to "civilians" in this war? That's my point, these people, very real people, have nothing to do with the whole bullshit, they trusted in a 3rd party to use their product, they can't audit every single 3rd party they use for security holes, even less research themselves ways to exploit them before using their products, you are saying that it's ok for these people to suffer because Google didn't want to pay for an exploit that was discovered. It boils down to the same question: why are the researchers doing this job? If it's because they believe they are helping make software more secure then ethically they shouldn't be putting unwitting end users into harm. If they are just looking for a paycheck then it's just morally corrupt to use users as hostages to get a ransom. I repeat what I said: this is the ethical discussion I'd like to see happening, not this immature "they didn't pay me, so fuck all the users, I will blow it all!", that just sounds like children throwing tantrums. Again: why do researchers do this job? Underneath that you can judge if it's ethical to just sell to the highest bidder, capitalism is amoral, we as humans imbue some sense of morality into it... This approach of "pay what the market is paying or else I will fuck your users" is, in my opinion, ethically wrong, if a researcher is serious about the job they are performing to make the world a less shit place then they need to have some moral guideline to follow, if not it's all bullshit and they are just mercenaries, and I don't support mercenaries.

denotational 3y ago

> According to the cybersecurity company, it replied by saying it wouldn't agree to swift disclosure, and pointed JetBrains to its policy against silently patching vulnerabilities, which stipulates that if companies violate that policy, Rapid7 will itself release the full details of the vulnerability, including enough information to allow people to develop exploits, within 24 hours. Did JetBrains engage Rapid7 to conduct an audit? If not, I think describing this as a “violation” is a step too far: if two companies have no pre-existing relationship then there’s no reason for one of them to start complying with arbitrary policies set by the other. If on the other hand JetBrains engaged Rapid7 to audit TeamCity and then tried to wriggle out of their contract when a vulnerability was found, then this isn’t a great look.

kevml 3y ago
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?
deleted 3y ago
[deleted]
yread 3y ago
That would be insane terms for an audit
- c0pium 3y ago
  It’s not uncommon for security researchers to require coordinated disclosure (although often with longer timelines) even in paid engagements.
  - hiatus 3y ago
    Any basis for this statement? Having been through multiple pentests I have never seen any clause like that in a contract. Given the commoditized nature of security vendors these days, I would be surprised to see such an anti-customer clause become commonplace.

_cenw 3y ago

>Such a move is typically seen as a no-no by the infosec community, which favors transparency. Transparency, sure, but since when do we release CVE details before a patch? Even in open source projects, there often is only an announcement that there will be an important patch, and the writeup / CVE content is at earliest published the day after the patch is available. Giving some notice on a closed source product seems even more sensible because it's much harder to extract a vulnerability from a point release.

gurchik 3y ago
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-of-silent-patches/ https://www.rapid7.com/blog/post/2022/06/06/the-hidden-harm-... ^2: https://discourse.metabase.com/t/upgrade-your-metabase-instance-now/26062 https://discourse.metabase.com/t/upgrade-your-metabase-insta... ^3: https://www.jetbrains.com/help/teamcity/teamcity-2023-11-4-release-notes.html#Security https://www.jetbrains.com/help/teamcity/teamcity-2023-11-4-r... ^4: https://blog.jetbrains.com/teamcity/2024/03/additional-critical-security-issues-affecting-teamcity-on-premises-cve-2024-27198-and-cve-2024-27199-update-to-2023-11-4-now/ https://blog.jetbrains.com/teamcity/2024/03/additional-criti...
- lolinder 3y ago
  This is a decent explanation for issuing a CVE and a clear disclosure immediately after a patch is available, but the claim in the article is that best practice is to reveal immediately regardless of whether there's a patch. That makes no sense to me.

gregoriol 3y ago

Why is there such an urgent need to release details about a vulnerability while services are at risk? Is the glory of security researches to put people and companies at risk? Release a statement when you find it, then the details some weeks after the patches are available.

liquidpele 3y ago
Marketing. Companies like rapid7 use that to say “only we detect this live threat, buy us fast!”.
- c0pium 3y ago
  It’s primarily marketing for sure, but the fig leaf is that the details allow targeted detections and mitigations based on the details of the bug. You can use the PoC code to test WAF rules for instance.
- gregoriol 3y ago
  So why not inform vendor, release a statement like "found something big" without details, get the marketing from it, and provide the details 30 days after patch is made available. That way it hurts users less.
  - ziddoap 3y ago
    >and provide the details 30 days after patch is made available.That way it hurts users less. The bad guys will figure out how to go about exploiting the vulnerability almost immediately after the patch releases, if they aren't already exploiting it. It makes 0 sense and protects 0 people to hold onto details after the patch is made available.
    - gregoriol 3y ago
      This is true for open-source but not as much for closed-source as in this case. Also, how does it ever help anyone to have the details released? It only helps the researchers for PR and bad actors, never the users who need to apply the patch (and often need some time to, one can't just upgrade something out of nowhere in less than 24 hours).

cp9 3y ago

so rapid7 is mad that jetbrains fixed the vulns they reported? isn't that the point of reporting vulnerabilities? why is rapid7 threatening to release the details in 24 hours?

ziddoap 3y ago
>so rapid7 is mad that jetbrains fixed the vulns they reported? No. They are mad that they vulnerabilities were _silently_ fixed.
- hiatus 3y ago
  Where does the article say that? I see: > Rapid7 says it reported the two TeamCity vulnerabilities in mid-February, claiming JetBrains soon after suggested releasing patches for the flaws before publicly disclosing them. So JetBrains wanted to have a patch ready before disclosing the vulnerability publicly. It seems they were working on it and were working with Rapid7. I am struggling to think how it would be better for users if an unpatched vulnerability is released before a patch is available. What's the thinking here, that users will take additional precautions to secure the application while they wait for a patch?
  - ziddoap 3y ago
    >Where does the article say that? The first sentence. >Security shop Rapid7 is criticizing JetBrains for flouting its policy against silent patching Why Rapid7 doesn't like silent patching can be found here: https://www.rapid7.com/blog/post/2022/06/06/the-hidden-harm-of-silent-patches/ https://www.rapid7.com/blog/post/2022/06/06/the-hidden-harm-...
  - IshKebab 3y ago
    It says it right here: > Rapid7 spotted fresh patches for CVE-2024-27198 and CVE-2024-27199 on Monday, without a published security advisory and without telling the researchers.
    - hiatus 3y ago

lolinder 3y ago

Does anyone have context for why "best practice" would be to disclose before there's a fix available? This is news to me (most of the time I see CVEs it's right after a patch), and it seems backwards—if there's nothing that customers can do about it yet then what good is releasing the details of the vulnerability?

cp9 3y ago
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
- ziddoap 3y ago
  >angry that jetbrains put out a patch to fix the issue They are angry that it was a _silent_ patch. The whole issue revolves around the _silent_ part. More on why Rapid7 doesn't like silent patching here: https://www.rapid7.com/blog/post/2022/06/06/the-hidden-harm-of-silent-patches/ https://www.rapid7.com/blog/post/2022/06/06/the-hidden-harm-...
throw0101d 3y ago
> 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).
codexb 3y ago
There's always a way to prevent or mitigate harm. You can suspend or degrade service temporarily until a fix is applied.

FinnKuhn 3y ago

"Rapid7 says it reported the two TeamCity vulnerabilities in mid-February, claiming JetBrains soon after suggested releasing patches for the flaws before publicly disclosing them. Such a move is typically seen as a no-no by the infosec community,..." As far as I am aware the majority of the infosec community would prefer to release a patch before releasing a security issue, but what do I know...

TheGeminon 3y ago
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.
c2h5oh 3y ago
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.
bitexploder 3y ago
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.

gtirloni 3y ago

Does Rapid7 get paid by customers to do that for 3rd-party software the customers use and then they report it to the upstream vendor (JetBrains in this case)?

suddenclarity 3y ago

This case aside, the real issue is Rapid7 having a written policy of throwing users under the bus to gain publicity by publishing vulnerabilities before they have a chance to update. Contrary to what the "security journalist" claims, this isn't the norm.

c0pium 3y ago
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.
bitexploder 3y ago
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.

015a 3y ago

I don't know what "norms" Rapid7 is expecting JetBrains to have followed, but this article certainly makes them come off in an entitled, power-tripping light, like their glory is more important than security. I'll be adding them to my list of "companies I'll never do business with".

bitexploder 3y ago
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.
- yegnau 3y ago
  Everyone has their coordinated disclosure policies, but not all of them are as harsh as Rapid7's. You mentioned Project Zero, it's a great example: >Project Zero follows a 90+30 disclosure deadline policy, which means that a vendor has 90 days after Project Zero notifies them about a security vulnerability to make a patch available to users. If they make a patch available within 90 days, Project Zero will publicly disclose details of the vulnerability 30 days after the patch has been made available to users. https://googleprojectzero.blogspot.com/p/vulnerability-disclosure-policy.html https://googleprojectzero.blogspot.com/p/vulnerability-discl... Giving vendors 30 days after a fix is a much more user-friendly thing to do then releasing ready-made exploits simultaneously with a patch, isn't it?
  - bitexploder 3y ago
    Yes, I agree, but Rapid7 does not normally do that. https://www.rapid7.com/security/disclosure/ https://www.rapid7.com/security/disclosure/ “ If the responsible organization is showing consistent good-faith effort to develop and ship an update, but cannot complete this work within 60 days, a 30-day extension may be granted at Rapid7’s sole discretion under the Default Policy (or for any of the enumerated exceptions below).” They do this with good faith as far as I have seen. The issue as I see it is that JetBrains decided to stop communicating, eliminating the “good faith” on their end.

robomartin 3y ago

JetBrains will do the right thing. They have been doing so for years. It's amazing to see how, time after time, the internet loves to destroy anything and anyone and utterly ignores the rest of their existence. It excels at bringing out humanity's lowest forms to the forefront. No association other than being a happy paying customer.

jamescun 3y ago

Why is silently patching considered a "no-no by the infosec community"? If your product's automatic update functionality can reach most users within the responsible disclosure window, that sounds like a net positive? We still learn about the vulnerability but limits the potential fallout of the disclosure. I'm very much in-favour of the private vulnerability research and responsible disclosure, but the "no silently patching vulnerabilities" sounds more like wanting to own the press to me than actually wanting to improve people's security.

ziddoap 3y ago
>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-of-silent-patches/ https://www.rapid7.com/blog/post/2022/06/06/the-hidden-harm-...
BeefWellington 3y ago
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.

deleted 3y ago

[deleted]

damm 3y ago

It will take 30-180 days for some enterprise orgs to upgrade Teamcity to mitigate the vulnerability. That grace period used to exist before publishing a vulnerability unless it was being actively exploited.

uticus 3y ago

see also https://news.ycombinator.com/item?id=39606973 https://news.ycombinator.com/item?id=39606973