RAM
Recently, developers of the KeePass password manager closed a vulnerability that allowed the master password to be retrieved from RAM, where it was stored in cleartext. In the same way, fragments of other important information, such as recent messages or data from corporate databases, can be “scraped” from memory. KeePass’s developers quickly found a rather unorthodox solution to the problem, but in most other applications, passwords are still stored in RAM in cleartext, making it a general, widespread weak spot of security systems.
A memory attack sounds exotic and complex, but it’s actually rather easy for cyber-baddies to pull off a successful one – if administrators fail to adopt special protection measures.
How someone can access computer memory
Areas of RAM used by different applications are largely isolated from each other by the OS and the hypervisor. Therefore, it’s not possible to read a fragment of memory in which another application is running. However, processes with kernel privileges (system in Windows, root in *nix) are able to do this. And there are more than a few ways to escalate privileges to the required level, with vulnerabilities in either the OS or device drivers being the most common.
Another way to get into the RAM is through a DMA attack. This type of attack is based on the fact that high-speed interfaces (USB 4.0, Thunderbolt, Firewire, etc.) have direct memory access to accelerate I/O processes. A specially designed device can abuse this feature to read any bits of memory. And this isn’t a hypothetical threat; there’ve been real cases (FinFireWire).
But even without sophisticated devices and vulnerabilities, it’s still doable! Because the OS writes RAM content to files, information in it can be accessed simply by reading those files.
There are several such types of files in Windows:
- Temporary swap files (pagefile.sys)
- Hibernation save files (hiberfil.sys)
- Crash and debug memory dumps (memory.dmp, minidump). And such files can be generated manually.
On Linux, swap and hibernation use a dedicated disk partition shared for these purposes.
Getting to one of these files usually requires physical access to the computer, but it’s not necessary to know the access credentials or even turn on the machine. You can simply remove the hard drive and read it on another computer.
How to prevent an attack on memory
Since there are lots of ways to scrape memory, you need to defend yourself on multiple levels simultaneously. Some safeguards will be user-unfriendly, so before applying them, consider the usage scenarios of each computer in your company, and weigh up the risks.
Straightforward measures
Let’s start with some relatively simple measures, which are recommended in all cases bar none.
- Implement the principle of least privilege. All users should work without administrator rights. Even administrators themselves should be granted administrator privileges only for the duration of maintenance procedures when they’re really needed.
- Deploy protection systems on all physical and virtual computers. Companies must have EDR systems in place. Ensure that security policies prevent employees from running legitimate but potentially dangerous utilities that can be used for privilege escalation and memory dumping (Sysinternals, PowerShell, redundant/outdated drivers, etc.).
- Keep the OS and all key applications up-to-date.
- Make sure that computers boot in UEFI mode, not BIOS. Regularly update UEFI firmware on all computers.
- Configure secure UEFI settings. Enable the Input/Output Memory Management Unit (IOMMU) to prevent DMA attacks. Password-protect UEFI and define the correct OS boot order to reduce the risks of the system being started from external malicious media and the settings being changed to unsafe ones. The Secure Boot and Trusted Boot features also prevent untrusted OS code from running.
Ambiguous measures
All the measures listed in this section greatly improve system security, but sometimes negatively impact computer performance, user-friendliness and/or disaster recovery capability. They each need careful consideration in the context of specific roles within the company, and the implementation requires precision and phased deployment with in-depth testing.
- TPM 2.0-based hardware key storage Trusted Platform Module delivers secure OS authentication, uses biometrics for account sign-in, and makes key extraction more difficult. TPM also greatly enhances the protection afforded by full disk encryption, since its keys are also stored in the module. Potential pitfalls: lack of TPM on some computers; incompatible OS/hardware combinations; difficulties with centralized key management (due to different systems and TPM versions).
- Full disk encryption. This measure drastically reduces the risk of data leakage, especially from lost or stolen laptops; so it’s recommended even for those who don’t fear memory attacks that much. Microsoft’s native implementation is BitLocker, but there are third-party solutions out there as well. Full disk encryption (FDE) has also become part of the many Linux-based systems (for example, in Ubuntu version 20 and up), and it’s usually based on LUKS. A combination of TPM and FDE offers maximum reliability. Potential pitfalls: in the event of a major crash, nothing can be restored from the drive. Therefore, a well-functioning backup system is an absolute must. Sometimes there’s a noticeable slowdown in drive performance, especially when booting the computer up.
- Disabling sleep/standby mode. If you disable sleep mode and leave only hibernation mode, situations when attackers have access to a booted and partially decrypted computer vulnerable to DMA attacks and other methods will become extremely rare. The downside of this solution is also obvious, as sleep mode happens to be the quickest, most convenient way to “turn off” the computer after work or when changing location in the office. If you decide to go down this path, always implement FDE; otherwise, employees will most likely use hibernation and the hibernation file will be left defenseless against attacks.
- Disabling hibernation mode. If hibernation is disabled, a memory image cannot be copied from a file on a powered-down computer. For critical computers, you can disable both hibernation and sleep; such machines can only be turned off. In combination with FDE, TPM and other measures, there’ll be little chance left for memory attacks; but the inconvenience to users would be considerable, so it’s worth thinking seriously about which cases justify such an approach.
Telling it straight
If you decide that disabling sleep or hibernation is justified for security’s sake, carefully consider for which users this policy needs to be enforced. It’s unlikely to be 100% of employees; rather – those who work with critical information. You must explain to them that passwords and other data can be stolen in numerous ways, so measures like “use an antivirus” and “avoid such-and-such sites” are not enough to avert serious security incidents.
It’s a good idea to say a few words about each security measure – explaining its purpose to employees. Full disk encryption offers protection against simple copying of data from a left-behind or stolen computer, as well as against the “evil maid” attacks – that is, a stranger with physical access to the machine. Disabling sleep and hibernation reinforces these safeguards, so the extra five minutes needed to turn the computer on and off will help ensure the employee is not scapegoated if their password gets used in a cyberattack.
