Security firm Rubrik is latest to be felled by GoAnywhere vulnerability

meta.x.gdb

Ars Scholae Palatinae
1,354
The very nature of what GoAnywhere provides to their clients always made me leery of their offerings. The ads made it seem like you could have a complete virtual desktop that accesses everything on your company server computers. It always sounds like a great big single-point utterly complete exploit waiting to happen.
 
Upvote
27 (29 / -2)
Does the information breached sound typical for a 'non-production IT testing environment'?

I usually associate those with either 'nothing but barebones configuration under test and tumbleweeds; or 'a copy of the production database that's maybe a week old'; depending on whether the testing involved a new infrastructure/configuration matter or whether it was someone more on the apps side who needed to futz with real world CRM data or something. Having real but partial information rather than either hello world or complete-but-slightly-old information is not what I would expect.
 
Upvote
11 (12 / -1)
The very nature of what GoAnywhere provides to their clients always made me leery of their offerings. The ads made it seem like you could have a complete virtual desktop that accesses everything on your company server computers. It always sounds like a great big single-point utterly complete exploit waiting to happen.
On the one hand, you aren't wrong. On the other hand, what you describe is a reasonably sought-after functionality in plenty of valid contexts.

I guess an ideal secure computer would have zero external i/o functionality at all and sit locked in a vault. But when a couple hundred (or thousand) people want to work together with the benefits of a shared computer network without being physically tied to an office LAN, some type of solution to provide external user access to needed resources on the internal servers is inevitable.

It is also necessary to provide support for whatever hardware/software tools users are using. Virtual desktops help mitigate many of the issues caused by the myriad devices users will inevitably try to bring to the table once untethered from the physical office (even if the company issues hardware). Virtual desktops can be a great tool to help standardize support across an organization.

Honestly, this isn't inherently a terrible service ... particularly if the software vendor is providing users tech support to keep external devices connected. It could offload a huge chunk of overhead from a smaller tech staff to be handled by experts focused entirely on the remote access product. That would typically be significantly more secure than trying to roll and maintain your own remote access solution.

Access causes risk. Period. Different approaches offer different attack surfaces, but simply providing a remote desktop to access server resources doesn't feel inherently more/less risky than other approaches.

I'd need to see evidence to agree having a server provide/control access to resources via virtual desktop is, by nature, dangerous.
 
Upvote
3 (9 / -6)

rhavenn

Ars Tribunus Militum
1,814
Subscriptor++
Rubrik is a backup company, not a security company (unless every company is considered a security company).
Never heard of Rubrik, so reading their about us blurb: https://www.rubrik.com/why-rubrik

Not sure why you're getting down voted. They're a "Cloud Backup" company that has "Secure" in the title of their product because they do some auditing and tout being able to recover you from ransomware and air gap your stuff, but literally many other higher end commercial "Cloud Backup" products do that.

Their page reads like buzzword bingo for tech marketing / sales bros to sell to MBA c-suites who don't know any better.

They're not a "security" company which is something like Mandiant or CloudStrike or whatever.
 
Upvote
25 (26 / -1)

LauraW

Ars Scholae Palatinae
1,020
Subscriptor++
Without knowing when the intrusion occurred, it’s impossible to determine if the vulnerability was a zero-day at the time it was exploited against Rubrik, or whether the breach was the result of Rubrik failing to install an available patch or take other mitigation measures in a timely manner.

The fact that they're not disclosing the date of the intrusion almost certainly means that it was after patches were available. If the flaw had still been a zero-day when the intrusion happened, they'd want to tell us that in order to exonerate themselves.
 
Upvote
27 (27 / 0)

foxyshadis

Ars Praefectus
5,087
Subscriptor
A question for the software engineers here: Do you believe that zero-day vulnerabilities like this are an inevitable consequence of the complexity of software developement, or an avoidable issue caused by companies that don't commit adequate time and resources towards security as part of their development processes?
We the users, from the C-suite to the peons, even us developers, always demand new and improved features first, but they also shouldn't change our workflow too much. (Too much ranging from not at all to only taking a couple days to relearn, depending on tinkering appetite and workload.) Only when the ship gets too creaky to even use properly, with new bugs, long waits, and crashes, do we ever start demanding that it be replumbed, at which point it might be too late to save all the debt.
 
Upvote
10 (10 / 0)
A question for the software engineers here: Do you believe that zero-day vulnerabilities like this are an inevitable consequence of the complexity of software developement, or an avoidable issue caused by companies that don't commit adequate time and resources towards security as part of their development processes?
The first one.

Look at how hard it is to write a secure library that renders an image, or parses some HTML. You'd think we would have bulletproof libraries that are immune to bad data injection, but we keep finding new problems all the time.
 
Upvote
17 (17 / 0)

McTurkey

Ars Tribunus Militum
2,267
Subscriptor
A question for the software engineers here: Do you believe that zero-day vulnerabilities like this are an inevitable consequence of the complexity of software developement, or an avoidable issue caused by companies that don't commit adequate time and resources towards security as part of their development processes?
Breaches are probably never going to be completely unavoidable, but they also happen entirely more often than they should due to poor security and coding practices.
 
Upvote
16 (16 / 0)

Arcticfox

Smack-Fu Master, in training
3
What I haven't seen mentioned in these follow up articles is the method of exploitation. All initial information on this CVE stated it was a vulnerability on the admin interface for the tool, not the user facing side. This means either an attacker was already sitting on the company's admin network which seems like a bigger problem, or they had the admin interface open to the public internet with no restrictions. I don't understand how any company with a security team would allow this.

Has there has been any further information posted that shows the vulnerability is exploitable from the user side?
 
Upvote
5 (5 / 0)

Captain Trips

Smack-Fu Master, in training
45
"GoAnywhere," indeed, lmao.

Previous marketing phrase: "GoAnywhere allows your employees to go anywhere on your company network that they have been given access to."

New marketing phrase: "GoAnywhere allows hackers to go everywhere on your company network. No added charge for the new functionality"
 
Upvote
3 (3 / 0)

mg224

Ars Scholae Palatinae
1,376
Subscriptor
What I haven't seen mentioned in these follow up articles is the method of exploitation. All initial information on this CVE stated it was a vulnerability on the admin interface for the tool, not the user facing side. This means either an attacker was already sitting on the company's admin network which seems like a bigger problem, or they had the admin interface open to the public internet with no restrictions. I don't understand how any company with a security team would allow this.

Has there has been any further information posted that shows the vulnerability is exploitable from the user side?

https://nvd.nist.gov/vuln/detail/CVE-2023-0669
first linked description is very detailed. It is possible to exploit externally using a redirect (and it reads like the intended use case of licensing activation did exactly that in order to send the license blob to the internal admin port from the Forta web server).

The bug is using readObject on an ObjectInputStream - their fix was to use ValidatingObjectInoutStream, which is not supposed to be vulnerable to the same bugs.
 
Upvote
2 (2 / 0)

Fuzzypiggy

Ars Scholae Palatinae
1,108
Rubrik is a backup company, not a security company (unless every company is considered a security company).

Yep, they are, I've used their product for on-prem and cloud backups, it's an OK backup product, little quirky in places but no better or worse than any other you care to name. It has ransomware detection built in, so if in the course of it's monitoring it happens to spot a lot out of the ordinary activites, say too many files being deleted or updated within a short space of time, then it goes into alert mode and starts screaming through whatever alerting tool you have linked to it. You can then ask it to undo the mess by restoring the messed up files.

Nasuni is a cloud NAS solution company, same thing in their ransomware spotter, to much change and you can undo all the messed with files very rapidly while it quarantines the messed up files.
 
Upvote
3 (3 / 0)

enilc

Ars Praefectus
3,900
Subscriptor++
Never heard of Rubrik, so reading their about us blurb: https://www.rubrik.com/why-rubrik

Not sure why you're getting down voted. They're a "Cloud Backup" company that has "Secure" in the title of their product because they do some auditing and tout being able to recover you from ransomware and air gap your stuff, but literally many other higher end commercial "Cloud Backup" products do that.

Their page reads like buzzword bingo for tech marketing / sales bros to sell to MBA c-suites who don't know any better.

They're not a "security" company which is something like Mandiant or CloudStrike or whatever.
Back in the day we used to say "All hat, and no cattle."

More contemporaneously, the phrase we use when we see these products/services/sites is taken from "Office Space"...

"What would ya say...ya do?"

Sitting these companies' sales agents is like interviewing Tom at Initech.
 
Upvote
1 (1 / 0)

Plissken

Ars Scholae Palatinae
756
"Mestrovich left key details out of the disclosure, most notably when the breach happened and when or if Rubrik patched the vulnerability."

A lot of breach disclosures include pertinent dates like when threat activity or intrusions were first detected. This feels like a purposeful omission from Rubrik, possibly because the exploitation came well after the Feb. 2 advisory was issued. If the attack came somewhere between Feb. 2 and Feb. 6 when there was no patch, that's somewhat defensible. But if the attack occured after the 6th, then that looks worse.
 
Upvote
4 (4 / 0)

ripvlan

Ars Scholae Palatinae
1,153
Apparently, GoAnywhere, lives up to its name.

For awhile now I've suggested performing Failure Mode Effect Analysis on these services. Surrounding them or isolating them when possible. Simply asking the question "what if somebody hacks this software? and can be protect (limit scope) against it?" It's like a smash and grab - they'll get in, can we catch/stop them?
 
Upvote
0 (0 / 0)

Mad Klingon

Ars Tribunus Militum
1,882
Subscriptor++
The first one.

Look at how hard it is to write a secure library that renders an image, or parses some HTML. You'd think we would have bulletproof libraries that are immune to bad data injection, but we keep finding new problems all the time.
Except that almost no one writes their own routines. A quick look at the Rubrik link posted earlier shows at least 4 non Rubrik scripts trying to run. If Rubrik can't be bothered to write their own website, how much effort are they putting into their actual products instead of linking to and trusting other out of their control libraries?
 
Upvote
-3 (0 / -3)

bernstein

Ars Scholae Palatinae
755
A question for the software engineers here: Do you believe that zero-day vulnerabilities like this are an inevitable consequence of the complexity of software developement, or an avoidable issue caused by companies that don't commit adequate time and resources towards security as part of their development processes?
The linux kernel (and oss in general) provides clear insight into this: it is unavoidable.

However, the linux kernel and it's network stack (as well as ssh) shows, that with effort it is possible to go very near to almost 0 vulnerabilities. But that only pertains to things that do not change too much over years.

Anyone exposing anything more than ssh/wireguard & a webserver (or other common protocol used by consumers) to the internet is beyond redemption. Other business stuff should always be behind ssh/wireguard.
 
Upvote
1 (1 / 0)
Rubrik is NOT, I repeat is NOT a security firm, or a security company, or anything like that. It's a shitty backup product, just like Coheshitty. Both of these companies are trying to rebrand themselves as "security companies". They are not, in any way or form, security companies. Don't let them fool you. I will wait for Rubrik's army of trolls to reply and tell me how wrong I am, as they are in a blood oath with their fearless leader, should they dissent and be sent back to the old country.
 
Upvote
-4 (1 / -5)
A question for the software engineers here: Do you believe that zero-day vulnerabilities like this are an inevitable consequence of the complexity of software developement, or an avoidable issue caused by companies that don't commit adequate time and resources towards security as part of their development processes?
Neither. Exploitable bugs are an inevitable consequence of the complexity of software development, yes. The degree to which exploitable bugs persist and are so frequently weaponized as zero-day attacks is due to a failure-by-design of the infrastructure we use to protect us from malicious actors.

The extreme prevalence of zero-day attacks are a result of Western intelligence agencies creating a massive secondary market that encourages "security researchers" to weaponize found exploits for commercialization rather than aggressively moving to secure digital infrastructure. The big money for people who discover exploits isn't in fixing them, the big money is in selling those exploits to the government (and any other entity with government-level cash).

In short, the agencies tasked with keeping America's computers safe are more concerned with maintaining their own ability to compromise global digital systems than they are concerned with ensuring global digital systems are secure. As a result, digital systems are always compromised to the greatest extent a number of powerful government agencies can technologically achieve. These exploits are released into the wild and used to spy.

There are dozens of companies collecting and selling exploits to "governments and authorized entities". Basically, known exploits secretly churn at that level until enough governments and corporations purchase a technique that the technique is discovered by legitimate security researchers and disclosed as a zero day ... or until the so-called "security firm" selling these exploits gets hacked directly and their entire horde of exploits is released on the digital ecosystem en-masse.

In short, we'd see a lot less exploits in the wild if the government were to criminalize selling exploits ... rather than serving as the largest consumer of undisclosed critical software flaws. Currently, we're paying the best of the best to NOT tell companies when they find holes in their products.
 
Upvote
2 (2 / 0)

VividVerism

Ars Tribunus Angusticlavius
8,666
A question for the software engineers here: Do you believe that zero-day vulnerabilities like this are an inevitable consequence of the complexity of software developement, or an avoidable issue caused by companies that don't commit adequate time and resources towards security as part of their development processes?
I don't know anything about this vulnerability, but some vulnerabilities are pretty much inevitable. I mean...any that are found, almost by definition, could have been found by the developer first, in theory. The problem is that for a lot of the more complex ones, "adequate time and resources" to detect the issue would exceed not only the time and resources needed to develop the product in the first place, but exceed any sort of profits they might be able to make from selling or supporting the software.

And then some (particularly those like what Tavis Ormandy and a few others with Google's Project Zero frequently find) are genius enough to need a real-life wizard on staff in order to find an exploit for, and most companies just don't employ that kind of talent.
 
Upvote
3 (3 / 0)
Except that almost no one writes their own routines. A quick look at the Rubrik link posted earlier shows at least 4 non Rubrik scripts trying to run. If Rubrik can't be bothered to write their own website, how much effort are they putting into their actual products instead of linking to and trusting other out of their control libraries?
A marketing website isn't typically what software engineers are used for. The only thing you can infer about a company's tech stack from a website designer choosing to utilize common frameworks in their design is that a web designer chose to utilize common frameworks in their design.

FWIW, it's typically considered less secure to use roll-your-own script handlers compared to using a vetted/maintained solution such as JQuery. There are plenty of situations where a proprietary implementation has to be utilized (frequently licensing issues), but generally, a well-maintained framework is preferred over a self-maintained proprietary stack for standardized common functionality stuff. It is possible Rubrik's web implementation represents best practice.
 
Upvote
1 (1 / 0)

Bolivar diGriz

Wise, Aged Ars Veteran
152
Subscriptor++
Rubrik is NOT, I repeat is NOT a security firm, or a security company, or anything like that. It's a shitty backup product, just like Coheshitty. Both of these companies are trying to rebrand themselves as "security companies". They are not, in any way or form, security companies. Don't let them fool you. I will wait for Rubrik's army of trolls to reply and tell me how wrong I am, as they are in a blood oath with their fearless leader, should they dissent and be sent back to the old country.
Having never used Rubrik (I've never been keen on cloud backup as a concept) I'm probably only a very low rank in their army of trolls but I do believe that when it comes to security nothing is more important than having backups. Doesn't matter how secure your firewalls are, how persuasive your anti-phishing training, it's all pointless without backups.
 
Upvote
3 (3 / 0)

foxyshadis

Ars Praefectus
5,087
Subscriptor
"Mestrovich left key details out of the disclosure, most notably when the breach happened and when or if Rubrik patched the vulnerability."

A lot of breach disclosures include pertinent dates like when threat activity or intrusions were first detected. This feels like a purposeful omission from Rubrik, possibly because the exploitation came well after the Feb. 2 advisory was issued. If the attack came somewhere between Feb. 2 and Feb. 6 when there was no patch, that's somewhat defensible. But if the attack occured after the 6th, then that looks worse.
There is always either some lag time between patch release and application, someone has to schedule a time to test it, or even just take it down.

But there was a very effective mitigation that was available upon disclosure, before the patch itself.

So you're most likely seeing the real intractable problem: The firehose of vulnerabilities and patches constantly coming out, and lack of admin time/attention to be able to suss out what applies to them and what doesn't. This is among the hardest problems in whitehat infosec today.
 
Upvote
2 (2 / 0)

Arcticfox

Smack-Fu Master, in training
3
https://nvd.nist.gov/vuln/detail/CVE-2023-0669
first linked description is very detailed. It is possible to exploit externally using a redirect (and it reads like the intended use case of licensing activation did exactly that in order to send the license blob to the internal admin port from the Forta web server).

The bug is using readObject on an ObjectInputStream - their fix was to use ValidatingObjectInoutStream, which is not supposed to be vulnerable to the same bugs.
Thank you. I hadn't read that detailed article before. It still states that exploitation requires access to the admin network port (by default tcp/8000) so I am surprised at how many companies are reporting breeches. A managed file transfer tool is critical infrastructure with potential access to all data in a company so I wouldn't expect standard internal users to have access to that port and you would hope admins wouldn't fall victim to phishing messages while logged into an admin terminal.
 
Upvote
1 (1 / 0)

jballou

Ars Scholae Palatinae
889
A question for the software engineers here: Do you believe that zero-day vulnerabilities like this are an inevitable consequence of the complexity of software developement, or an avoidable issue caused by companies that don't commit adequate time and resources towards security as part of their development processes?
Yes
 
Upvote
0 (0 / 0)