How was British Airways payroll data stolen if it was "encrypted at rest"?
Thousands of British Airways, BBC and Boots employees have had their personal information stolen due to a weakness in file transfer software, MOVEit Transfer, used by their payroll provider, Zellis. Scanning by Shodan finds 2,515 publicly available instances of MOVEit, with the majority in the United States and 129 in the UK, and semi-anonymous reports on Reddit confirm that the weakness has been actively exploited. It's logged as CVE-2023-34362.
MOVEit Transfer claims to "secure enterprise data in transit and at rest". Their documentation shows that it supports customer-supplied keys, with a key rotation feature, and that they use AES-256.
That sounds really good - so how was the data stolen? The payroll data will almost certainly have been in the form of flat files, which are particularly easy to encrypt.
How does the attack work?
Security provider Huntress re-created the exploit and documented their findings on their blog. They haven't released the full script, but it started with an SQL injection vulnerability, which they used to insert a fake user session into the MOVEit database, which allowed unfettered access via the web interface, which then enabled file uploads (it's a file transfer tool), and this was used to upload DLL files that then unpacked an exploit. So the SQL Injection vulnerability led to Remote Code Execution (RCE).
While the attackers could upload and execute any exploit package they want, the path they chose was to install a targeted backdoor script called "human2.aspx" that uses MOVEit's internal libraries directly. The backdoor listens for further requests and is designed to reveal:
- Credentials for the Azure blob storage account backing the MOVEit Transfer instance, if one is configured, at which point the attacker can bypass MOVEit to download files directly from Azure.
- Full listings of files, folders, uploaders, and partner organisations.
- The contents of any file, given its ID and folder ID, which are obtainable from the listings.
Can we learn more from the backdoor?
Since the attacker's script is publically available, we can see how it works and how the data was encrypted.
Firstly, file names and folder names are not encrypted in the backing database at all. Maybe that's not a big deal in this case, as payroll files tend to be named things like payroll-05-2023.csv, but in general, filenames can include the names of individuals or anything else, so it's better to encrypt them unconditionally.
Secondly, crucially, the file data itself is being decrypted without the need for the attacker to provide any keys or secret information. The important lines from the backdoor script are:
SILGlobals siGlobs = new SILGlobals();
EncryptedStream st = Encryption.OpenFileForDecryption(dataFilePath, siGlobs.FileSystemFactory.Create());
st.CopyTo(gzipStream);
All of MOVEit's claims may be true: the data is encrypted at rest, using AES256, with customer-controlled keys. But this amounts to nothing, as the keys are readily available to the MOVEit application itself, via a global "SILGlobals" object. Since the application itself has on-demand access to keys, the attacker's code does as well, and so the data being "encrypted at rest" provided no protection whatsoever.
Don't store the keys
The way to make "encryption at rest" useful is to ensure that an attacker can't possibly gain access to the keys, even if they compromise the application and exfiltrate the databases and all of the encrypted files. The way to do that is for the application not to have access to the keys at all. If it's a managed service, the application's provider shouldn't have them either.
It's possible - here's how we did it at Safelink. Admittedly the challenges are significant: key management is tricky, and implementing search and sort becomes very interesting, but by not storing keys you rule out entire breach scenarios, which is well worth the effort.
Would you like to learn more about how we protect your data? Reach out to us here.