Third MOVEit bug fixed a day after PoC exploit made public Progress Software on Friday issued a fix for a third critical bug in its MOVEit file transfer suite, a vulnerability that had just been disclosed the day earlier. Details of the latest vulnerability, tracked as CVE-2023-35708, were made public Thursday; proof-of-concept (PoC) exploit for the flaw, now fixed today, also emerged …
Okay, so one SQL injection issue was found. As said, that could have been a hang-over from testing or something. Not good but mistakes happen.
Then a second is found. Surely that would ring alarm bells and someone should have thought: 'damn, we better check the rest of the code to see if any more were left in there'. Was that entirely logical rear-guard action simply overlooked or isn't their client base important enough to them to justify assigning resources to looking? How companies respond to problems is often what defines a business relationship and, well, there's clearly some questions that remain unanswered!
"Similarly, Louisiana's Office of Motor Vehicles warned that all residents with a state-issued ID, drivers license, or car registration likely had their name, addresses, social security number, birthdate, height, eye color, license number, vehicles registration, and handicap placard info exposed.
"There is no indication at this time that cyber attackers who breached MOVEit have sold, used, shared or released the OMV data obtained from the MOVEit attack," the Louisiana agency said. "The cyber attackers have not contacted state government. But all Louisianans should take immediate steps to safeguard their identity."
Does this mean any worried Louisianans should sell their car, move home, get a new driving license and SSN issued and then switch their date of birth and eye color, perfect a limp and wear heels? I'm not sure if I'm joking or not - but that glib 'take steps to safeguard your identity' line has all the makings of a farce.
Seems like most times some company or agency has bungled security and let citizen/customer/etc. data out into the wild, their best advice to "safeguard [our] identity" is some amount of "free" (hah) credit report monitoring or some such thing.
As if the likes of Equifax, Experian, and TransUnion really have our best interests in mind.
And, if memory serves, have occasionally had security issues of their own.
Bloody bleak, innit?
Only a passing comment.
You would think if you have software that is written to be public internet facing that they would an internal set of automation tools that continually attempts to exploit their own software
So you would have a segregated network where you would use the same sort of tools that miscreants would use and then coninually attempt attacks at a variety of supported versions of your software.
I know if I was running a software vendor, I would do something like this.
For some internal software in the past, I have done things to try to break it though people moaned about why i was doing this - I said, we need to understand what will happen to all the interconnected components if something goes wrong, e.g. someone accidently deletes the contents of a table in a DB or services fail or servers fail.
Basically, test it into destuction - it's also a fun thing to do and it means that when it goes live to customers you've tried to minimise the chances of failure, though people can be quite good at breaking things by accident!
FTP is not secure
But can be made so (use of ssl, ftp/s and all that jazz). Better than a festering pile of closed-source commercial crap with multiple *known* vulnerabilities (and how many others left to find?).
Difficult to scale, yes. But to say it's not secure it wrong - in its default state sure - but no sysop should *ever* put stuff into production in its default state.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
