Rapid7 throws JetBrains under the bus for 'uncoordinated vulnerability disclosure'
- Reference: 1709644507
- News link: https://www.theregister.co.uk/2024/03/05/rapid7_jetbrains_vuln_disclosure_dispute/
- Source link:
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, which favors transparency, but there's apparently a time and a place for these things.
[1]
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.
[2]
[3]
Rapid7 claims that after more than a week of radio silence from JetBrains on the coordinated disclosure matter, Rapid7 spotted fresh patches for CVE-2024-27198 and CVE-2024-27199 on Monday, without a published security advisory and without telling the researchers.
Following what sounds like a sternly worded email from Rapid7, JetBrains released a blog detailing the vulnerabilities, but the security researchers say it continued to ignore inquiries about why it violated coordinated vulnerability disclosure norms.
[4]
The details can all be found at the bottom of Rapid7's [5]security advisory .
A glass-half-full onlooker may consider JetBrains' behavior and consider how silently patching the vulnerabilities could have been positive. It's well-known that alerting attackers to vulnerabilities before organizations can apply patches often leads to exploits at a scale that leaves a trail of victims behind.
JetBrains may just have wanted to avoid this scenario, but as it says in its own [6]security advisory , it was well aware that Rapid7 would publish within 24 hours, so this optimism doesn't hold up much to scrutiny.
[7]
Further, according to internet monitoring biz Shadowserver, exploits of the vulnerabilities are already [8]well underway , starting at 2200 UTC the same day the vulnerabilities were disclosed.
Glass-half-empty types will think JetBrains sought to avoid negative press, especially given the [9]other recent TeamCity issues , or that it was just being generally ignorant of the disclosure norms.
We sent some questions about this over to JetBrains but they didn't immediately respond.
[10]QNAP vulnerability disclosure ends up an utter shambles
[11]Atlassian cranks up the threat meter to max for Confluence authorization flaw
[12]Critical Apache ActiveMQ flaw under attack by 'clumsy' ransomware crims
[13]'Mass exploitation' of Citrix Bleed underway as ransomware crews pile in
While JetBrains prepares to tell its side of the story*, members of the infosec community have [14]shamed the TeamCity vendor over the supposed uncoordinated disclosure with Rapid7.
"The Rapid7 blog on JetBrains TeamCity is savage – especially the disclosure timeline," [15]said security researcher Ron Bowes on Mastodon.
"I know from previously working on that team that we tried hard to be friendly and cooperative with vendors. The fact that Rapid7 calls them out on their behavior means it must have been bad."
Inside the TeamCity vulnerabilities
JetBrains said the two vulnerabilities, both discovered by Stephen Frewer, are "critical," although the National Vulnerability Database (NVD) has only assigned one with critical status.
CVE-2024-27198: An authentication bypass flaw enabled by an alternative path issue. It's located in the web component of TeamCity and has a critical CVSS rating of 9.8.
CVE-2024-27199: An authentication bypass flaw enabled by a path traversal issue. It's also located in the web component of TeamCity and has a high CVSS rating of 7.3.
It's worth noting that CVE-2024-27198 attracts a higher severity score because it could allow attackers to take full administrative control of a TeamCity server and achieve unauthenticated remote code execution.
Rapid7 says CVE-2024-27199 only allows for a "limited amount" of information disclosure and system modification. This includes an unauthenticated attacker being able to replace a server's HTTPS certificate with their own, thus opening up the possibility of man-in-the-middle (MITM) attacks.
Severity score aside, CVE-2024-27198 will certainly be the main cause of concern for CI/CD server admins given the potential for [16]supply chain attacks to take hold.
JetBrains says these only affect the on-prem version of TeamCity. Cloud versions are already patched and weren't attacked prior to disclosure.
All on-prem versions through to 2023.11.3 are impacted by the flaws, JetBrains says. So the best route to protection is to either upgrade to version 2023.11.4 or install its security patch plugin. ®
*Updated to add at 1619 UTC:
"The most important part is the following," said a JetBrains spokesperson, referencing a [17]blog post discussing its side of events. "We never had any intention to release a fix silently without making the full details public. As a CVE Numbering Authority (CNA), we assigned CVE IDs for both issues a day after receiving the report. "We suggested disclosing the details of the vulnerabilities in the same way we have followed in the past (with a time delay between releasing a fix and making a full disclosure), which allows our customers to upgrade their TeamCity instances. "This suggestion was rejected by the Rapid7 team who published full details of the vulnerabilities (and how to exploit them) a few hours after we had released a fix to TeamCity customers."
Get our [18]Tech Resources
[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/patches&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZedPt17pPAZMXQUlFYWnAgAAAdQ&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/patches&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZedPt17pPAZMXQUlFYWnAgAAAdQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/patches&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZedPt17pPAZMXQUlFYWnAgAAAdQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/patches&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZedPt17pPAZMXQUlFYWnAgAAAdQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[5] https://www.rapid7.com/blog/post/2024/03/04/etr-cve-2024-27198-and-cve-2024-27199-jetbrains-teamcity-multiple-authentication-bypass-vulnerabilities-fixed/
[6] 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/
[7] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/patches&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZedPt17pPAZMXQUlFYWnAgAAAdQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[8] https://twitter.com/Shadowserver/status/1764960110659478012
[9] https://www.theregister.com/2024/02/07/jetbrains_teamcity_critical_vuln/
[10] https://www.theregister.com/2024/02/13/qnap_latest_vulnerabilities/
[11] https://www.theregister.com/2023/11/08/atlassian_confluence_flaw_upgraded/
[12] https://www.theregister.com/2023/11/02/apache_activemq_vulnerability/
[13] https://www.theregister.com/2023/10/31/mass_exploitation_citrix_bleed/
[14] https://infosec.town/notes/9qh48skggghuv29l
[15] https://infosec.exchange/@iagox86/112039430348676154
[16] https://www.theregister.com/2023/11/23/north_korea_attacks/
[17] https://blog.jetbrains.com/teamcity/2024/03/our-approach-addressing-recently-discovered-vulnerabilities-in-teamcity-on-premises/
[18] https://whitepapers.theregister.com/
Re: and these are the good guys?
Agreed. I’m not sure anyone comes out of this looking good.
I get what Rapid7 are trying to achieve but IMO saying “you must behave as we dictate or we’ll publicly drop exploits for your software” doesn’t exactly look great.
Re: and these are the good guys?
Yes, these are the good guys. Their policy on silent patching is the industry norm.
Their policy isn't "release details of the vulnerability prior to a patch being available" it's "Don't patch without publicly, LOUDLY disclosing the vulnerability and how it functions" the reason for this is actually really straightforward. The only people who reverse engineer patches on the regular are sophisticated attackers. A silent patch does not hide a vulnerability from attackers, it only hides vulnerabilities from people with other things to do: pen testers, IT personnel who are responsible for scheduling and prioritizing patches on their networks, threat detection developers, adaptive threat mitigation services, news agencies and exploit disclosure outlets that are responsible for helping to timely inform all the previous individuals. Silent patches lead to longer exploit windows overall and allow attackers to establish footholds that they can leverage in future to increase their compromise of the exploited networks, even long after the patch for the original exploit has been applied. The IT personnel none the wiser as to the need to be on the lookout.
This is why threat researchers across the industry have adopted the policies they have. When you patch an issue, disclose that issue in full technical detail. That helps all the good guys to do their jobs, while giving the bad guys no more information than they would have obtained on their own in a few hours.
Re: and these are the good guys?
An easily understood "here's how the vulnerability works" gives everyone (bad guys included) enough information to use that vulnerability during the time it takes for the patch to be applied everywhere.
Patches have never been deployed instantly, so those "few hours (days/weeks)" they have are definitely a problem.
I'm not sold on the idea of "if you patch silently, we'll tell everyone what you patched, and how it was vulnerable" being even slightly a good idea.
Doesn't JetBrains have ties to Russia?
In which case, though I have no blame for the individuals involved on the ground; meddling by the state is surely a concern to your IT estate.
In what way? Specifics please or it’s just fear mungering
Kaspersky and FSB meddling are well documented.
There is no reason to believe any other Russki software outfit is not also compromised. Gawd knows all the big US ones are compromised by the NSA as well.
So it’s just fear mungering then
I am a Kaspersky fan, it is one of if not the best security tools out there. I had to remove them just before putin attacked Ukraine due to putin killing people that don't do what he tells them. If he took the staff and said do this or I will kill you and your family - everyone knows he has and will.
So far Kaspersky has been 'allowed' to not be involved in the war, and the product and company still has it's integrity (less being associated with putin by being in the same country)
I hope they out last putin (please someone end the madman) with their reputation in tact. If so I will GLADLY rip MS defender from our systems and put K back in. If they do just one dirty dead it will kill the company permanently.
But until then,,, I wish them luck.
From https://www.forbes.com/sites/thomasbrewster/2021/01/07/meet-the-super-rich-czech-tech-company---and-its-russian-ceo--denying-links-to-the-huge-solarwinds-hack/?sh=74af8ec74eb9:
JetBrains has some links back to Russia. Shafirov (previous CEO) is Russian, as are its three cofounders: Sergey Dmitriev, Eugene Belyaev and Valentin Kipiatkov. Three of its six research and development centers are also based in Russia, alongside its bases in Germany, the Netherlands, the U.S. and the Czech Republic.
As I understand, they no longer have ties to Russia - all the devs relocated elsewhere long ago, and their St Petersburg offices have also been closed. This Reddit thread from last year details some of this and contains a link to their blog post giving full disclosure: [1]https://www.reddit.com/r/dotnet/comments/yt1bm2/jetbrains_and_russia/
[1] https://www.reddit.com/r/dotnet/comments/yt1bm2/jetbrains_and_russia/
all the devs relocated elsewhere long ago
If they have family or assets in Russia they can be pressured into slipping backdoors in etc.
No, it's based in Prague.
Tangential to the article
I use JetBrains IntelliJ for my Java/React stuff today and I noticed it's got AI for an additional fee. There was an El Reg article a few weeks ago about it that was critical of the inclusion.
I mention that because, as I peruse the Reg's homepage, I notice a shitload of AI-generated images instead of the standard stock images over articles including this one. I assume it's cheaper to use AI, but the images are all strange. (The URL still shows shutterstock - https://regmedia.co.uk/2024/03/05/shutterstock_screen.jpg)
Icon because murderbots are less unsettling.
Re: Tangential to the article
If you are curious as to the status of 'bundled' uninstallable AI that phones home, here's an interesting thread:
https://youtrack.jetbrains.com/issue/LLM-1973/Provide-the-possibility-to-remove-a-plugin-completely-from-the-system
and these are the good guys?
" 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 "
I absolutely accept that patching without disclosure is bad news, but to insist that disclosure precedes patching merely contributes to global vulnerability. It should be sufficient to disclose immediately after release of a patch -- to give customers the opportunity to protect themselves properly.
I detect many cases of an increasing detachment between vulnerability investigators and the realities of ensuring security, ranging from (let's face it -- threatening) stipulations of this kind to disclosure of obscure attack vectors with recommendations that could interfere disproportionately with legitimate operations (such as a recent suggestion that thermal imaging cameras should be prevented from viewing keypads because they might be used to crack entry codes, thereby also preventing their use in, for example, forensic examination).
But it's all the more problematic when the discoverer of a vulnerability attempts to place a vendor over a barrel. I know there's an (often valid) argument that vendors are negligent and unresponsive when alerted, but I'm quite convinced that threats and "protection" tactics are not the answer -- they perpetuate an antagonistic culture that exacerbates any non-cooperation.