Re: RFC 9205 vs. CL0P

Ransomware gangs are targeting MFT (Managed File Transfer) software, these days. What makes MoveIt different, is the wide-open front door is HTTP all the way from unauthenticated SQL POST queries on Port 80, to passing "mystery headers" to a webshell. I'm wondering if we can do a better job in the Best Current Practices document, of moving away from spec-speak to more Hemingway-esque (as phk put it) speak. Here's a bunch of boxes to check. If you don't think you need to check one of 'em, here's a deep link into HTTP backing up this best practice.



I appreciate your response and perspective. While I agree the problem is not with HTTP protocol per se, I do believe it's in scope to the WG to attempt to mitigate the sort of naive implementations which have led to the recent theft of all my health and financial records.



-Eric







---- On Sat, 19 Aug 2023 01:33:05 -0700 Willy Tarreau <w@1wt.eu> wrote ---



Hi Eric, 
 
On Fri, Aug 18, 2023 at 06:51:46PM -0700, Eric J Bowman wrote: 
> Hundreds more companies and millions more users affected by the MoveIt breach 
> since my last post, which continues to reverberate globally. Yet still, 
> crickets from the HTTP world. Yeah, we're all "experts" at online privacy, 
> but at some point ya gotta share your info with an insurer, hospital, 
> homeowner's association, or whatnot. Even if they aren't using MoveIt, 
> they're probably outsourcing something to someone who does. 
> 
> This isn't me whining about not getting a +1 on updating the best-practices 
> document, I get that I have an abrasive online persona. But I am very 
> disappointed that nobody else in the HTTP world has anything to say about 
> this? I hate being a lone voice in the wilderness, and wonder if I'm the only 
> one free to speak out because my career path has long since diverged from 
> HTTP. Is everyone else in ostrich mode, because their employer/client is 
> breached, or they signed an NDA covering this? Bueller? 
 
It's not this. It's that I don't see the relation between HTTP and the 
thing you shared. I had never heard about that "moveit" thing, apparently 
it's file transfer software affected by an SQL injection attack, how is 
this any relevant to the HTTP protocol ? 
 
These days people share lots of data because: 
 - they're required to by incompetent and lazy services that pretend 
 that it's easier for everyone ("our offices are open tuesdays and 
 thursdays from 11:30 to 15:30, but no need to get there in person, 
 just send us a copy of your ID card"). 
 
 - they're marginalized as annoying people when they don't want to 
 (e.g. try to disable contactless payment on your card in post-covid 
 era) 
 
 - tools are incitating to share a lot (how many times a day do I have 
 to click on "block" in my browser because it asks me to share my 
 location or to record a password for me; how hard is it to add an 
 option that says "never ask any the following questions encouraging 
 morons to share their whole life online") 
 
 - because it makes them famous and gets them a life. 
 
It's just human nature and nothing at all related to anything that can 
technically be solved in a communication protocol. 
 
I know there are idealists who think that security issues are a thing 
of the past that will disappear in the future. History has proven the 
exact opposite, and as frameworks and languages become more and more 
accessible, the need for a certain experience and software culture for 
starting a new project is vanishing, implying that instead the basic 
security issues will become more and more common. So it's a total 
illusion to imagine that we can do something to prevent a data leak in 
software in general. Once the data is stored, it's accessible, either 
by the expected means or by unexpected ones. The rule is: do not share 
what you don't want to leak (which is an important rule for passwords 
by the way). 
 
But nothing in this discussion concerns HTTP at all. HTTP is just 
one of the many vectors used to access, transfer, steal the private 
information and there's nothing it can do against it because the 
problem is elsewhere. 
 
Regards, 
Willy