{"id":21285,"date":"2023-06-27T13:53:20","date_gmt":"2023-06-27T17:53:20","guid":{"rendered":"https:\/\/me-en.kaspersky.com\/blog\/how-to-protect-ram\/21285\/"},"modified":"2023-07-13T20:13:38","modified_gmt":"2023-07-13T16:13:38","slug":"how-to-protect-ram","status":"publish","type":"post","link":"https:\/\/me-en.kaspersky.com\/blog\/how-to-protect-ram\/21285\/","title":{"rendered":"How to protect RAM secrets"},"content":{"rendered":"<p>Recently, developers of the KeePass password manager closed a vulnerability that allowed the master password to be <a href=\"https:\/\/nvd.nist.gov\/vuln\/detail\/CVE-2023-32784\" target=\"_blank\" rel=\"nofollow noopener\">retrieved from RAM<\/a>, 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 \u201cscraped\u201d from memory. KeePass\u2019s 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.<\/p>\n<p>A memory attack sounds exotic and complex, but it\u2019s actually rather easy for cyber-baddies to pull off a successful one \u2013 if administrators fail to adopt special protection measures.<\/p>\n<h2>How someone can access computer memory<\/h2>\n<p>Areas of RAM used by different applications are largely isolated from each other by the OS and the hypervisor. Therefore, it\u2019s not possible to read a fragment of memory in which another application is running. However, processes with kernel privileges (<em>system<\/em> in Windows, <em>root<\/em> in *nix) are able to do this. And there are more than a few ways to <a href=\"https:\/\/www.kaspersky.com\/blog\/nokoyawa-zero-day-exploit\/47788\/\" target=\"_blank\" rel=\"noopener nofollow\">escalate privileges<\/a> to the required level, with vulnerabilities in either the OS or <a href=\"https:\/\/www.kaspersky.com\/blog\/genshin-driver-attack\/45494\/\" target=\"_blank\" rel=\"noopener nofollow\">device drivers<\/a> being the most common.<\/p>\n<p>Another way to get into the RAM is through a <a href=\"https:\/\/www.kroll.com\/en\/insights\/publications\/cyber\/what-is-dma-attack-understanding-mitigating-threat\" target=\"_blank\" rel=\"nofollow noopener\">DMA attack<\/a>. 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\u2019t a hypothetical threat; there\u2019ve been real cases (<a href=\"https:\/\/en.wikipedia.org\/wiki\/DMA_attack\" target=\"_blank\" rel=\"nofollow noopener\">FinFireWire<\/a>).<\/p>\n<p>But even without sophisticated devices and vulnerabilities, it\u2019s still doable! Because the OS writes RAM content to files, information in it can be accessed simply by reading those files.<\/p>\n<p>There are several such types of files in Windows:<\/p>\n<ul>\n<li>Temporary swap files (pagefile.sys)<\/li>\n<li>Hibernation save files (hiberfil.sys)<\/li>\n<li>Crash and debug memory dumps (memory.dmp, minidump). And such files can be generated <a href=\"https:\/\/learn.microsoft.com\/en-us\/troubleshoot\/windows-client\/performance\/generate-a-kernel-or-complete-crash-dump\" target=\"_blank\" rel=\"nofollow noopener\">manually<\/a>.<\/li>\n<\/ul>\n<p>On Linux, <em>swap<\/em> and <em>hibernation<\/em> use a dedicated disk partition shared for these purposes.<\/p>\n<p>Getting to one of these files usually requires physical access to the computer, but it\u2019s 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.<\/p>\n<h2>How to prevent an attack on memory<\/h2>\n<p>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.<\/p>\n<h3>Straightforward measures<\/h3>\n<p>Let\u2019s start with some relatively simple measures, which are recommended in all cases bar none.<\/p>\n<ul>\n<li><strong>Implement the principle of least privilege<\/strong>. All users should work without administrator rights. Even administrators themselves should be granted administrator privileges only for the duration of maintenance procedures when they\u2019re really needed.<\/li>\n<li><strong>Deploy protection systems<\/strong> on all physical and virtual computers. Companies must have <a href=\"https:\/\/me-en.kaspersky.com\/enterprise-security\/edr-security-software-solution?icid=me-en_kdailyplacehold_acq_ona_smm__onl_b2b_kasperskydaily_wpplaceholder_______\" target=\"_blank\" rel=\"noopener\">EDR systems<\/a> 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.).<\/li>\n<li>Keep the OS and all key applications <strong>up-to-date<\/strong>.<\/li>\n<li><strong>Make sure that computers boot in UEFI mode, not BIOS.<\/strong> Regularly update UEFI firmware on all computers.<\/li>\n<li><strong>Configure secure UEFI settings<\/strong>. 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.<\/li>\n<\/ul>\n<h2>Ambiguous measures<\/h2>\n<p>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.<\/p>\n<ul>\n<li>TPM 2.0-based <strong>hardware key storage<\/strong> 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. <strong>Potential pitfalls<\/strong>: lack of TPM on some computers; incompatible OS\/hardware combinations; difficulties with centralized key management (due to different systems and TPM versions).<\/li>\n<li><strong>Full disk encryption<\/strong>. This measure drastically reduces the risk of data leakage, especially from lost or stolen laptops; so it\u2019s recommended even for those who don\u2019t fear memory attacks that much. Microsoft\u2019s native implementation is <a href=\"https:\/\/learn.microsoft.com\/en-us\/windows\/security\/operating-system-security\/data-protection\/bitlocker\/\" target=\"_blank\" rel=\"nofollow noopener\">BitLocker<\/a>, 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 <a href=\"https:\/\/ubuntu.com\/core\/docs\/uc20\/full-disk-encryption\" target=\"_blank\" rel=\"nofollow noopener\">Ubuntu version 20 and up<\/a>), and it\u2019s usually based on <a href=\"https:\/\/www.redhat.com\/sysadmin\/disk-encryption-luks\" target=\"_blank\" rel=\"nofollow noopener\">LUKS<\/a>. A combination of TPM and FDE offers maximum reliability. <strong>Potential pitfalls<\/strong>: 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\u2019s a noticeable slowdown in drive performance, especially when booting the computer up.<\/li>\n<li><strong>Disabling sleep\/standby mode<\/strong>. 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 <strong>downside of this solution<\/strong> is also obvious, as sleep mode happens to be the quickest, most convenient way to \u201cturn off\u201d 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.<\/li>\n<li><strong>Disabling hibernation mode<\/strong>. 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\u2019ll be little chance left for memory attacks; but the inconvenience to users would be considerable, so it\u2019s worth thinking seriously about which cases justify such an approach.<\/li>\n<\/ul>\n<h2>Telling it straight<\/h2>\n<p>If you decide that disabling sleep or hibernation is justified for security\u2019s sake, carefully consider for which users this policy needs to be enforced. It\u2019s unlikely to be 100% of employees; rather \u2013 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 \u201cuse an antivirus\u201d and \u201cavoid such-and-such sites\u201d are not enough to avert serious security incidents.<\/p>\n<p>It\u2019s a good idea to say a few words about each security measure \u2013 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 <a href=\"https:\/\/www.kaspersky.com\/blog\/evil-maid-attack\/37901\/\" target=\"_blank\" rel=\"noopener nofollow\">\u201cevil maid\u201d<\/a> attacks \u2013 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.<\/p>\n<input type=\"hidden\" class=\"category_for_banner\" value=\"kasap\">\n","protected":false},"excerpt":{"rendered":"<p>What can get stolen from RAM, and what\u2019s hiberfil.sys got to do with it?<\/p>\n","protected":false},"author":2722,"featured_media":21286,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1318,1916,1917],"tags":[111,2661,533,2662,187,2607,2235,113],"class_list":{"0":"post-21285","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-attacks","11":"tag-dumps","12":"tag-linux","13":"tag-memory","14":"tag-passwords","15":"tag-ram","16":"tag-uefi","17":"tag-windows"},"hreflang":[{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/how-to-protect-ram\/21285\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/how-to-protect-ram\/25844\/"},{"hreflang":"en-us","url":"https:\/\/usa.kaspersky.com\/blog\/how-to-protect-ram\/28542\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/how-to-protect-ram\/26143\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/how-to-protect-ram\/26487\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/how-to-protect-ram\/28964\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/how-to-protect-ram\/35642\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/how-to-protect-ram\/48518\/"},{"hreflang":"fr","url":"https:\/\/www.kaspersky.fr\/blog\/how-to-protect-ram\/20793\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/how-to-protect-ram\/21495\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/how-to-protect-ram\/30302\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/how-to-protect-ram\/26456\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/how-to-protect-ram\/32153\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/how-to-protect-ram\/31837\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/me-en.kaspersky.com\/blog\/tag\/ram\/","name":"RAM"},"_links":{"self":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/21285","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/users\/2722"}],"replies":[{"embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/comments?post=21285"}],"version-history":[{"count":1,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/21285\/revisions"}],"predecessor-version":[{"id":21352,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/21285\/revisions\/21352"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/media\/21286"}],"wp:attachment":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/media?parent=21285"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/categories?post=21285"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/tags?post=21285"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}