News: 1609998789

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

JetBrains' build automation software eyed as possible enabler of SolarWinds hack

(2021/01/07)


The SolarWinds security breach disclosed last month, which US authorities [1]believe was of [2]Russian origin and led to the compromise of at least 18,000 organizations, may have been enabled in part by software from JetBrains.

The company, founded by Russian software developers and based in the Czech Republic, makes software development tools. One of these, build management and continuous integration system TeamCity, is used by SolarWinds as part of its application build process.

The New York Times on Wednesday [3]reported that unidentified sources familiar with the SolarWinds investigation say investigators are looking into whether JetBrains' software was involved. Separately, Reuters [4]said the FBI is scrutinizing TeamCity to see whether the software played a role in the compromise of the SolarWinds build system.

These reports have not suggested JetBrains personnel played a willing role in the compromise. Rather, investigators appear to be concerned that a poorly secured, improperly configured, or vulnerable TeamCity instance may have helped the attackers plant their malicious code somewhere in the software supply chain. TeamCity, like other software, is regularly [5]patched for vulnerabilities.

Ah, right on time: Hacker-slammed SolarWinds sued by angry shareholders [6]READ MORE

In [7]a statement on Wednesday, JetBrains CEO Maxim Shafirov emphasized that JetBrains has not been accused of any wrongdoing.

"First and foremost, JetBrains has not taken part or been involved in this attack in any way," he said. "SolarWinds is one of our customers and uses TeamCity, which is a Continuous Integration and Deployment System, used as part of building software. SolarWinds has not contacted us with any details regarding the breach and the only information we have is what has been made publicly available."

Shafirov said JetBrains has not been contacted by any government or security agency, and said while the company is unaware of any investigation, it stands ready to cooperate if approached.

Who's responsible?

In an email to The Register , Johannes Ullrich, Dean of Research for SANS Technology Institute, argued that JetBrains itself was not responsible for what happened.

“JetBrains was not affected by the SolarWinds breach or used was to breach SolarWinds as far as I can tell,” said Ullrich.

“There are some implications that a development tool JetBrain makes was used to breach Solarwinds, but JetBrains stated that if the tool was involved, it was likely a misconfiguration of the tool and not a problem with JetBrains being compromised. JetBrains makes very popular development tools. A breach of JetBrains would be yet another huge supply chain type attack.”

Absent any evidence of collusion between the company and the attackers, the focus should remain on whether SolarWinds was diligent in its security practices, [8]not all of which have been stellar.

SolarWinds last month [9]acknowledged that the security breach involved two separate attacks: Supernova, which involved a malicious library targeting the SolarWind Orion Platform build system and a vulnerability that allows the malware to be deployed; and Sunburst, a supply chain attack that involved the insertion of a vulnerability into builds of SolarWinds' Orion Platform software.

Separately on Wednesday, the US Department of Justice said that its Microsoft Office 365 email system had been compromised as a result of the SolarWinds attack. In a statement, DoJ spokesman Marc Raimondi said, "At this point, the number of potentially accessed O365 mailboxes appears limited to around three per cent and we have no indication that any classified systems were impacted."

Raimondi said the DoJ's CIO learned of the email compromise on December 24, 2020, and is treating the compromise as a major incident under the Federal Information Security Modernization Act. Further reports to federal agencies, Congress, and the public may follow as required. ®

Get our [10]Tech Resources



[1] https://www.cisa.gov/news/2021/01/05/joint-statement-federal-bureau-investigation-fbi-cybersecurity-and-infrastructure

[2] https://www.theregister.com/2020/12/20/solarwinds_update_trump_contradicts_pompeo_russia_attribution/

[3] https://www.nytimes.com/2021/01/06/us/politics/russia-cyber-hack.html

[4] https://www.reuters.com/article/us-global-cyber-jetbrains/fbi-probe-of-major-hack-includes-project-management-software-from-jetbrains-sources-idUSKBN29B2RR

[5] https://www.cvedetails.com/vulnerability-list/vendor_id-15146/product_id-30795/Jetbrains-Teamcity.html

[6] https://www.theregister.com/2021/01/05/solarwinds_sued/

[7] https://blog.jetbrains.com/blog/2021/01/06/statement-on-the-story-from-the-new-york-times-regarding-jetbrains-and-solarwinds/

[8] https://www.theregister.com/2020/12/16/solarwinds_github_password/

[9] https://www.solarwinds.com/securityadvisory

[10] https://whitepapers.theregister.com/

Bond Villain

Danny 2

"So, Mr. Bond, can you integrate and test this code before the end of the month? Wha haha!" ~Jet Brains

Re: Bond Villain

Korev

Well, he's good at fixing Spectre bugs

Looks like finger pointing

Ashto5

Oh quick everyone look at them ....

Don’t notice that regardless of what software was involved we got hacked ...

Personally I bet it was intel they built the chips or maybe the electric company ...

Re: Looks like finger pointing

iron

They were probably using Supermicro servers with those Chinese "grain of rice" spy chips on the motherboard that Bloomberg was so fond of. The Chinese just gave their login details to the Russians.

/s

Access to business critical systems

Anonymous Coward

The US authorities don't appear to have contacted JetBrains or issued any security advisories around new or existing TeamCitys vulnerabilities (or other JetBrains software products) so is this a vulnerability or just poor implementation?

As a software company, making your build management/continuous integration system accessible from the Internet and not requiring either 2FA and ideally a VPN wrapper with 2FA would seem to indicate poor risk management. Particularly if we find out all the passwords were "solarwinds123" and the hard part is guessing if the username is geoff or jeff...

It's also interesting to compare the FireEye and Solarwinds responses to these compromises/attacks - yes FireEye is a security company, had the resources available to investigate and stands to lose everything if it's security reputation is ruined, so it quickly disclosed a lot of information indicating the steps it had taken/was taking, what went wrong and what it was doing to address the issues within days.

Solarwinds has had around a month and aside from a software update that supposedly addresses the issues, there's still a lot of unknowns around how this happened, whether there systems can be trusted and what Solarwinds are doing to ensure their products can be trusted in future. And then maybe Solarwinds will possibly learn that their security reputation was just as important as FireEyes when their sales dry up and customers move to other platforms.

Re: Access to business critical systems

gggeek

Exposing the CI/Build/Dev systems to the internet only with 2FA and/or VPN is miles beyond the security practices that I've seen implemented at most companies I have been involved with...

I'm speaking about the web dev industry, which might have (hopefully) different practices than other businesses, but what I have often seen, even in recent times, is rather:

- Jenkins/Jira/Stash/Confluence & friends seldom updated to the latest release, even when they have known security bugs

- shared passwords used for all these tools. Worst case scenario is that they are wide open without auth to anyone with intranet access

- auth tokens to customers' systems written down in plaintext in source code, build scripts, developers wikis

- domain credentials for all company employees handed out pre-generated from sysadmins and never rotated

- no offboarding procedures set up, or plain disattended, with hundreds of ex employees and ex customers accounts still active everywhere

- vpn enforced for connecting to the intranet, and assuming that everything on the intranet is secure (because devs run linux laptops instead of windows, ha!)

- etc etc

Luckily these companies do not have tens of thousand of high-value customers, and are thus below the radar of serious supply-chain hacking attempts, but they are ripe for abuse not by nation-state actors, just by joe random script kid.

The reason for all these bad practices are all the usual, with the addition that developers cost a lot of money, so one does not want to have them sitting idle while the CI server is down for an update, or because they are waiting to be communicated a new auth token. Sure, tools like Vault exist, but they are not easy to implement and manage.

Now, think about your average company: how many providers is it employing to implement its websites, cms, intranet, erp, hr, etc... softwares? Plus the external consultants of course! How many of those do practice good security? And how many of them have access to the company's servers and network?

This is what happens when you opt to use overcomplicated setups, now pay the price

el kabong

You lose visibility, errors start popping everywhere and you can't see them all because they are so many and everything is so opaque.

When it inevitably breaks don't blame your poor judgement, it is so much easier to put the blame on someone else.

Real Users never use the Help key.