Progress Software’s MOVEit file-transfer platform has been causing high-profile data leaks. The Cl0p ransomware group seems to have exploited an RCE zero-day since July 2021.
Cl0p quietly used the flaw to do reconnaissance on future victims. In this week’s Secure Software Blogwatch, we look both ways.
Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Treknobabble II (the wrath of can’t).
What’s the craic? Jessica Lyons Hardcastle reports — “MOVEit supply-chain attack”:
British Airways, the BBC, and UK pharmacy chain Boots are among the companies whose data has been compromised after miscreants exploited a critical vulnerability in deployments of the MOVEit document-transfer app. [The victims] were not hit directly. Instead, payroll services provider Zellis … admitted its MOVEit installation had been exploited, and as a result “a small number of our customers” … had their information stolen.
Zellis … customers include Sky, Harrods, Jaguar, Land Rover, Dyson, and Credit Suisse. [It] blamed the MOVEit vulnerability for the security breach. … The bug has since been assigned a CVE and is now tracked as CVE-2023-34362. [This] is now looking like yet another major supply chain attack.
But wait! There’s more. Jonathan Greig adds — “MOVEit announces second vulnerability”:
The company behind the popular MOVEit file transfer product has announced a second vulnerability within its software as more entities come forward to announce breaches. … The software company Progress said that since the discovery of the first vulnerability … the cybersecurity firm Huntress … has discovered a new issue.
Progress … warned that the new vulnerability could allow a hacker to gain unauthorized access to the MOVEit Transfer database. … All versions of the software are affected by the vulnerability, [CVE-2023-35036].
When was the first bug discovered? Scott Downie, Devon Ackerman, Laurie Iacono and Dan Cox think it’s likely “Since 2021”:
Analysis of this exploitation has confirmed that threat actors are using this vulnerability to upload a web shell and exfiltrate data. [They] were likely experimenting with ways to exploit this particular vulnerability as far back as 2021. [We] found evidence of similar activity occurring … in some cases as early as July 2021.
[There was] a broad swath of activity associated with the vulnerability on or around May 27 and 28, 2023. … This time frame coincided with the observation of Memorial Day weekend in the U.S., reinforcing threat actors’ preference to launch major cyber exploitations during holiday weekends (e.g., the Kaseya supply chain attack on July 3, 2021).
So, two years ago? Jai Vijayan has more detail — “Cl0P Gang Sat on Exploit”:
The Cl0p ransomware group sat on [the] zero-day vulnerability … for nearly two years before starting to exploit it … with devastating effect. … The group periodically launched waves of malicious activity against vulnerable systems to test their access to organizations and to identity the ones to target.
Much of the malicious reconnaissance and testing activity in the early stages — in July 2021 — appears to have been manual in nature. But starting April 2022, Cl0p actors began using an automated mechanism for probing multiple organizations at the same time.
Reports of attack activity targeting a SQL injection vulnerability in MOVEit Transfer began surfacing on June 1. Researchers … found the threat actor exploiting the flaw to steal data [as] a precursor to ransom demands.
Wait. Pause. SQL injection? In 2023? Pier Reviewer blames siloed development:
Parameterising queries still isn’t done every time. Even where it is, dumb stuff happens.
The other week I was reviewing some code. DB interaction looked reasonable on the surface — all the queries were parameterised so it was safe, right? Wrong! They were calling stored procedures safely, but the SPs were then concatenating input and EXEC’ing it.
It’s a fairly common pattern, sadly: Java/.Net/whatever devs do their bit safely, but then the data team who write the SPs do random **** like it’s 1995. Neither team knows or understands what the other team is doing so you end up with trivially discoverable and exploitable SQLi.
But this is a solved problem! bennett_cg requests we exit the grassed area:
The trouble with “solved problems” is that, eventually, the people who actually felt the pain from the problem aren’t around anymore and their replacements never had a chance to learn about it the hard way. So the good practices seem like arcane verbosity and … get discarded.
What can we learn? apjr9 concludes that we’re going to see supply-chain exploits more frequently:
Networked apps are a huge security vulnerability. Your system security is only as good as the security of the least secure networked app running on it.
As OS and network security improves, attacks via networked apps are becoming common. Securing all the networked apps would be a huge cost to industry, so they are furiously trying to ignore the problem and have been for decades.
Is the only answer to only use your own software? No, argues Coppercloud:
Lol, no. … Unless transferring files is your literal entire business you probably want to trust experts instead of building your own, because you’ll **** it up worse than they will. You can criticize MOVEit all you want … but be it MOVEit, OneDrive, DropBox, FTP … you’re likely to be trusting someone else.
Meanwhile, if not MOVEit, then what should you use? This Anonymous Coward has a “better” suggestion:
We always transfer files via torrent sites. It’s fast and you also get free backup service. Win!
You have been reading Secure Software Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or email@example.com. Ask your doctor before reading. Your mileage may vary. Past performance is no guarantee of future results. Do not stare into laser with remaining eye. E&OE. 30.
Article Link: MOVEit supply-chain bug exploited for two years
1 post – 1 participant