health data of ‘at least’ 8 million individuals accessed by hackers says US government contractor Maximus

[yayIHaveAUserName]

Summary

 

US government contractor Maximus has confirmed that health data of "up to 11 million individuals" has been accessed. The hack uses a vulnerability in MOVEit Transfer, an enterprise file transfer software.

Maximus administers programs "such as Medicaid, Medicare, healthcare reform and welfare-to-work".

The russian group 'Clop' claims to have stolen 169 gigabytes of data. The data has not yet been published.

Maximus says it has already informed direct customers as well as relevant government agencies. They will inform the affected individuals "probably" in the future. (german source (Heise))

 

According to Wikipedia the vulnerability seems to be a SQL injection CVE-2023-34362. Both the cloud and on prem version are affected.

 

 

Quotes

Quote

 In an 8-K filing on Wednesday, Maximus confirmed that the personal information of a “significant number” of individuals was accessed by hackers exploiting a zero-day vulnerability in MOVEit Transfer, which the organization uses to “share data with government customers pertaining to individuals who participate in various government programs.”

Quote

the organization [Maximus] said it believes hackers accessed the personal data, including Social Security numbers and protected health information, of “at least” 8 to 11 million individuals.

Quote

Clop, the Russia-linked data extortion group responsible for the MOVEit mass-hacks, claims to have stolen 169 gigabytes of data from Maximus, which it has not yet published.

Quote

According to the latest figures from cybersecurity company Emsisoft, more than 500 organizations have so far been impacted by the MOVEit mass-hacks, exposing the personal information of more than 34.5 million people.

 

My thoughts

• The fact that an exploit in the data base enabled this suggests that files are not properly end-to-end encrypted (This is a file transfer software, not storage) -> WHY?!
• "Data exfiltration [...] may have been primarily focused on data stored using Microsoft Azure" (Wikipedia) another example why such infrastructure DOES NOT BELONG IN A PUBLIC CLOUD!
• Why were those data bases accessible from the internet at all? Access to these files should only be possible from strongly segmeneted Networks, interconnected via VPNs, SD-WAN or something similar. Not some computer on the internet with the client software or a mobile app! With proper network planning, none of these systems should have even be exposed to the internet. (Assuming of course that the cloud version was not used (which would even be more stupid)).
• MOVEit was in this case a single point of failure. Do we need some kind of regulation that requires a multi-layer, multi-vendor security approach for highly sensitive data (i.e. you need to first connect via vpn (from a different vendor) to the internal network before you can access any of the components related to MOVEit)?
• Would segmentation of data have been feasible and would it have reduced the impact?

 

Sources

Techcrunch

Heise

Edited July 29, 2023 by yayIHaveAUserName
Based on incorrect assumption, see thread.

[leadeater]

24 minutes ago, yayIHaveAUserName said:

"Data exfiltration [...] may have been primarily focused on data stored using Microsoft Azure" (Wikipedia) another example why such infrastructure DOES NOT BELONG IN A PUBLIC CLOUD!

Azure really doesn't have much at all to do with it here. MOVEit just utilizes a storage layer but access was through MOVIEit. Direct access to Azure to get whatever data may have been there, not strictly necessary I think since you could get it through the MOVEit itself, was only gained by the compromise and obtaining Azure blob access/secret keys. While I do have my personal opinions on public cloud and data like this it actually has nothing to do with any of this other than MOVEit cloud being a central point to access a majority of data rather than going around finding privately hosted MOVEit instances and attacking them one by one which may or may not have also used Azure blob (private on-prem would have multiple storage layer choices).

 

Centralization made this simpler although that doesn't negate the issue that if that couldn't be used then a distributed wide scale attack against all known MOVEit instance be done instead.

 

Also from the quick reading I have done for this MOVEit and the database itself stores none of this stolen sensitive data, that data was obtained by getting access to the MOVEit database and getting locations and credentials of the backend storage locations being used. It's not like a service such as MOVEit would be ingesting sensitive data like this in to it's database just to transfer it between organizations. MOVEit is a file transfer service, it moved files. If those files aren't protected or encrypted that is the data owners fault.

[yayIHaveAUserName]

14 minutes ago, leadeater said:

Also from the quick readin I have done for this MOVEit and the database itself stores none of this stolen sensitive data, that data was obtained by getting access to the MOVEit database and getting locations and credentials of the backend storage locations being used.

If I understand the explanation of the attack correctly, the problem is indeed not that MOVEit stores files itself but rather that a compromised instance of the MOVEit server can be used for RCE. There do not even necessarily need to be specific credentials in the database since the hole server/vm it is running on is compromised. And according to this diagramm it is supposed to be in the same network segment as the file storage. The storage is probably even mounted in that system. Bonus points if installed on the storage server itself.

55 minutes ago, yayIHaveAUserName said:

The fact that an exploit in the data base enabled this suggests that files are not properly end-to-end encrypted (This is a file transfer software, not storage) -> WHY?!

I was focused on file transfers from (MOVEit)-client to (MOVEit)-client, and had not realised that the server instance itself has access to the storage. That is why I thought there might not have been proper end-to-end encryption. Altough I still don't know if there is, due to the RCE the attack would still have been possible even with end-to-end encryption and the database not storing any files.

40 minutes ago, leadeater said:

Azure really doesn't have much at all to do with it here. MOVEit just utilizes a storage layer but access was through MOVIEit. Direct access to Azure to get whatever data may have been there, not strictly necessary I think since you could get it through the MOVEit itself, was only gained by the compromise and obtaining Azure blob access/secret keys. While I do have my personal opinions on public cloud and data like this it actually has nothing to do with any of this other than MOVEit cloud being a central point to access a majority of data rather than going around finding privately hosted MOVEit instances and attacking them one by one which may or may not have also used Azure blob (private on-prem would have multiple storage layer choiced).

The attack requires MOVEit to be accessible via http/https. A self hosted instance not exposing those protocols directly to the internet would need a breach of the network / vpn access or similar prior to being able to be attacked.

 

While there are probably similar security solutions for Azure also, the control is in the hand of the cloud provider, not the user. And as we saw with Microsoft recently that can render many customers vulnerable at once without them really being able to do something about it.

Besides, I feel there is a tendency to "just yeet the service into the cloud without thinking about it" which I really don't like.

 

You are correct, the attack is not specifically related to it being hosted in Azure (which I never said), self hosted instances exposing the web interface where exactly as vulnerable. My point was that in my opinion using public cloud infrastructure inherently carries a greater risk. I am also aware that this is by far not an unanimous opinion it the IT space and I respect other opinions regarding it, there are definitely arguments to be made for both sides.

 

58 minutes ago, leadeater said:

If those files aren't protected or encrypted that is the data owners fault.

agree.

[leadeater]

20 hours ago, yayIHaveAUserName said:

The attack requires MOVEit to be accessible via http/https. A self hosted instance not exposing those protocols directly to the internet would need a breach of the network / vpn access or similar prior to being able to be attacked.

I haven't used MOVEit but publishing to the internet may be required to actually achieve it's purpose and how it's used. Relying on VPNs isn't that great either, those can and have been compromised and the setup of the VPN greatly impacts the risk of a VPN breach whether that be a vulnerability or account compromise. MOVEit being compromised is less worse than VPN access to entire internal network, using known easy to use tools to get Domain Admin account or any other account with decent access to a lot of things and taking or breaking much more.

 

Again I don't use MOVEit, likely never will, but without knowing how it actually works in real life usage there isn't much point criticizing that the web portal is internet accessible as that may be exactly how it's supposed to be. The diagram you linked to basically shows internet access to the gateway server/service is required and that is seemingly likely what was breached.

 

20 hours ago, yayIHaveAUserName said:

the attack is not specifically related to it being hosted in Azure (which I never said)

 

21 hours ago, yayIHaveAUserName said:

"Data exfiltration [...] may have been primarily focused on data stored using Microsoft Azure" (Wikipedia) another example why such infrastructure DOES NOT BELONG IN A PUBLIC CLOUD!

It is how your framed it though, mistakenly or not. You focused pretty much all on Azure and other comments related back to that context. I'm by no means a fan of public cloud but lets not forget that absolutely huge wide scale attacks on on-perm Exchange server have happened as an example. If you have a mindset predisposed to not liking or blaming "the cloud" then you end up here in this type of situation.

 

Government, healthcare etc all use different part of Azure, they do not actually use "Public Azure" and services and resources in Azure (Public or Government) do not have to be exposed and internet accessible at all. There are a lot of controls customers of Azure have and a lot of the services are only as secure as configured by the customer not Azure.

 

All things will have flaws and vulnerabilities, people will create S3 buckets open to everyone by mistake, bad things happen and will always happen. That's why security/defense through layers is more important than picking things out like on-perm vs cloud. If the data was encrypted in the first place the MOVEit breach would have constituted only customer notification, urgent patching and beach analysis.

 

The data custodians are responsible for the data security, they own it and control it so the liability is with them. MOVEit is not to blame for poor data security practices of their customers. Transferring sensitive files that aren't encrypted is bad always and I don't mean encrypted data traffic, the actual files. Sure it's much more of a pain to do that but if that is put in as a policy requirement then a suitable easy to use solution will be implemented fit for that purpose. I for one hate having to send files outside the network to software vendors no matter the method (SFTP, HTTPS etc) because you don't know how they are going to handle that file and if it's just going to be unencrypted in place defeating the point of encrypting it.

 

For example for a lot of medical information data you can use HL7 protocol over dedicated private network (my country has this) between healthcare providers or if that is not sufficient use this same network and setup database replication with protected views etc. Passing around information using file transfers is a very old and often lazy way of doing things, not that it doesn't have it's place but still a lot default to it as the go to method of getting data between between organizations rather than implementing a better more secure way that doesn't risk files laying around being handled improperly.

 

The biggest detractor for public cloud for me is the ungodly prices and the now more than decade worth of the world best marketing targeting CEOs, CFOs, COOs that "cloud" TCO is cheaper always for everything forever and that is a battle I still have to fight today. A hammer is not a saw, don't try and saw wood with a hammer. Just because "the cloud" advertises themselves as a one stop shop, one size fits all, doesn't mean it's the best or cheapest. This common sense is understood at those executive levels for many things but for whatever reason just gets way sided when it comes to IT.

 

20 hours ago, yayIHaveAUserName said:

My point was that in my opinion using public cloud infrastructure inherently carries a greater risk. I am also aware that this is by far not an unanimous opinion it the IT space and I respect other opinions regarding it, there are definitely arguments to be made for both sides.

Whether it was say 10,000 MOVEit installations installed at on-prem locations or 10,000 separate installations hosted in Azure it wouldn't actually result in any difference. They would all have their own servers managed by themselves, in private not accessible networks, published to the internet using the same MOVEit architecture resulting in exactly the same risk. 

 

MOVEit SaaS is a different situation.