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.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.
Never heard of Rubrik, so reading their about us blurb: https://www.rubrik.com/why-rubrikRubrik is a backup company, not a security company (unless every company is considered a security company).
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.
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.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.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.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?
"GoAnywhere," indeed, lmao.
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?
Rubrik is a backup company, not a security company (unless every company is considered a security company).
Back in the day we used to say "All hat, and no cattle."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.
Yeah, data lifecycle management is how I would categorize them. Not security.Rubrik is a backup company, not a security company (unless every company is considered a security company).
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?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.
The linux kernel (and oss in general) provides clear insight into this: it is unavoidable.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.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.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?
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.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?
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.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.
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."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.
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.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.
YesA 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?