[HN Gopher] Breaking VeraCrypt: Obtaining and Extracting On-the-...
___________________________________________________________________
Breaking VeraCrypt: Obtaining and Extracting On-the-Fly Encryption
Keys
Author : polar
Score : 62 points
Date : 2021-06-03 16:43 UTC (6 hours ago)
(HTM) web link (blog.elcomsoft.com)
(TXT) w3m dump (blog.elcomsoft.com)
| upofadown wrote:
| I guess the interesting thing for a VeraCrypt user is that
| Elcomsoft can't grab keys from memory if RAM encryption of keys
| and passwords is turned on. So that means such a user is immune
| to Elcomsoft forensics software if they have a strong passphrase.
|
| I am not sure why Elcomsoft would want to write a blog article
| informing the world of this fact...
|
| Anyway, here is the direct link to how VeraCrypt does their RAM
| encryption:
|
| * https://sourceforge.net/p/veracrypt/discussion/technical/thr...
| devit wrote:
| That doesn't prevent extraction by someone with
| supervisor/hypervisor access (so if Elcomsoft can't extract it
| it's only because they are lazy), it just tries to make it less
| likely that an attacker can extract it from a locked machine
| they have physical access to (by rebooting into a boot image of
| their choice and reading the RAM, the so-called "cold boot"
| attack).
|
| It's mathematically impossible to prevent key extraction unless
| you put the key in an HSM (the TPM might function as such, but
| it may not have good performance) and use that for decryption
| (the most you can do is make the key larger up to the amount of
| RAM you have, at the costing of wasting RAM).
|
| Even if you use an HSM, the malware can just extract the data
| itself or even on-the-fly decrypt the disk with the HSM and re-
| encrypt with a known key and then exfiltrate the known key, so
| all this does is make the attack slower since you need to
| read/write the whole disk.
| gruez wrote:
| >To capture an image of the computer's RAM, run EFDD on the
| computer on which the VeraCrypt disk is currently mounted.
|
| This seems like a pointless exercise. If the disk is already
| decrypted and mounted, plus you have access to the computer, why
| not just... directly read the disk? Or initiate the decryption
| routine?
| hdbdhr66 wrote:
| People buy VPS from linode/digitalocean/vultr or worse some
| solusvm based provider and believe such crytps give them a
| secure area
| nacs wrote:
| As long as the VPS owner don't leave the Veracrypt image
| mounted and give a stranger root access to the server, this
| wouldn't work.
|
| Also, if a hacker has admin/root access as is required for
| this tool to work, you have all kinds of other problems.
| aborsy wrote:
| VPS provider has the keys through RAM.
|
| I would be interested to know if VPS providers actually go
| as far as dumping and snapshoting RAM (most of them claim
| they don't even access disk or monitor traffic). It would
| be big deal for systems such as EC2.
| hdbdhr66 wrote:
| You can scan the memory of a guest from the hypervisor
| afaik
| jcrawfordor wrote:
| The advantage isn't huge but it does exist. Stealing encryption
| keys out of memory is a reasonably common thing for more
| sophisticated malware to do, because if you can
| opportunistically do it once it generally confers permanent
| access to the encrypted data whenever you want.
|
| Copying the contents out isn't very desirable because 1) it is
| slow and bandwidth intensive which means it is less likely to
| succeed opportunistically and more detectable, 2) you will not
| be able to examine the data again in the future (including
| changes) without finding an opportunity to copy it out again.
| It is also often just easier for someone with malicious intent
| to subtly capture the encrypted volume (can be sent out very
| slowly without worrying about user behavior) and then examine
| it remotely (easier and safer to use/iterate on custom tools
| when you're not shipping them to the compromised machine).
|
| This way malware, especially like a plugin-based botnet, can
| continuously check for the key and grab it whenever it's in
| memory. Then later on, as convenient, plugins can search the
| encrypted volume for specific signatures whenever they want.
| That includes loading more signatures in the future, rescanning
| for changes, etc. All in all, the ability to extract the key
| from memory violates the fundamental assumption of the user
| that the data is not accessible when they have not mounted the
| volume... it means that if the volume has _ever_ been mounted,
| unauthorized software _might_ have captured the information
| necessary to examine it as desired, in a subtle way.
|
| Elcomsoft is also principally a forensic vendor, and this kind
| of thing is very useful in forensics scenarios when you
| encounter a live machine (e.g. law enforcement seizure). If you
| can capture the key from the live machine quickly, you can do
| your analysis later at leisure and with less risk of
| contamination of the evidence. This minimizes the need for
| complex and risky methods like transporting the machine without
| power interruption.
|
| Obviously this kind of problem is not necessarily completely
| solvable... if the data was decrypted then there was, at some
| point, the material to decrypt it present on the system. But
| more modern disk and file encryption solutions tend to use
| various solutions like the TPM and operating system features to
| avoid the key being available in memory.
|
| Finally, as always, password reuse is an issue here. If you can
| get the key material there's a good bet it might work on other
| volumes as well if you can recompute for whatever the volume
| salt is... this may be more or less practical depending on how
| TrueCrypt/VeraCrypt derives the key which I don't remember
| well.
| nitrogen wrote:
| Speculating: if you have the key, you can make a read-only copy
| of the disk and analyze it on your own time without risk of
| altering it.
| gruez wrote:
| If you want a read-only copy, can't you plug in an external
| hard drive and then run dd on the raw block device?
| nacs wrote:
| Agreed, the encrypted image has to be mounted and you have to
| admin/root access to capture the RAM contents.
|
| This isn't what I would call "Breaking" Veracrypt.
| aborsy wrote:
| The title (breaking veracrypt) is misleading (and probably a
| click bait).
|
| Any mounted encrypted data has keys in RAM or an HSM. If you have
| access to inside of those, you have access to keys. This is not
| breaking anything.
|
| You can encrypt or obfuscate data in RAM, but then the keys
| should be stored in disk, ram or HSM, which is subject to the
| same problem. Actually, TPM/secure enclave merely binds the key
| to the device, and doesn't help with key extraction, since it
| trusts the root, unless you set a PIN, which makes automated
| access impractical, or a max number of trials.
|
| I liked some posts in this blog, particularly the one on synology
| which turned out to be consequential, but I think the authors
| should title their posts more modestly.
|
| -----------------------------------
|
| VeraCrypt FAQ answers a question on root privilege, reading RAM
| and support for TPM:
|
| "No. Those programs use TPM to protect against attacks that
| require the attacker to have administrator privileges, or
| physical access to the computer, and the attacker needs you to
| use the computer after such an access. However, if any of these
| conditions is met, it is actually impossible to secure the
| computer (see below) and, therefore, you must stop using it
| (instead of relying on TPM).
|
| If the attacker has administrator privileges, he can, for
| example, reset the TPM, capture the content of RAM (containing
| master keys) or content of files stored on mounted VeraCrypt
| volumes (decrypted on the fly), which can then be sent to the
| attacker over the Internet or saved to an unencrypted local drive
| (from which the attacker might be able to read it later, when he
| gains physical access to the computer)."
| unnouinceput wrote:
| This is a non-issue for most users. If you're part of the users
| who need fast dismount then an additional hardware can be
| deployed, as paranoid as turning your back to a camera and the
| eyes reading very primitive algorithm will shut down your PC.
| parsecs wrote:
| What does "as paranoid as turning your back to a camera and the
| eyes reading very primitive algorithm will shut down your PC"
| mean?
| ndury wrote:
| If I understood correctly he means that you can write a
| simple tool that reads input from the camera, capture the
| eyes and as soon as you turn away the pc will shutdown.
| CompuHacker wrote:
| This concept was described in Cryptonomicon (1999). I have
| seen no proof of concept for such an application as of yet,
| but it would indeed be simple.
| unnouinceput wrote:
| You mean a very simple algorithm to detect eyes using the
| OpenCV (https://en.wikipedia.org/wiki/OpenCV) written on
| a RaspberryPi that has a tiny camera which connects to
| your desired computer via network (be it WiFi or cable)
| and sends a shutdown command once it no longer detects
| them? I am pretty sure you can find on SlackOverflow /
| RaspberryPi forums desired bits of software and make do
| in maximum one day.
| y7 wrote:
| This is such a weird article. It's basically an ad for software
| that claims to "break" VeraCrypt by extracting encryption keys
| from a memory dump. And apparently it doesn't even work if you
| set VeraCrypt to encrypt keys in memory.
| jonnycomputer wrote:
| Can I just complain for a moment about this site's popup with two
| buttons labeled, "Subscribe" and "Keep Receiving our News" with
| no close button or deny available.
| netr0ute wrote:
| "Keep Receiving our News" seems to do nothing when clicked (no
| browser-level modal) so that has to be the worst-labeled "No"
| button on any website.
| brightsize wrote:
| Yeah hugely annoying. Thank $deity for uBlock Origin -> Element
| Zapper Mode FTW.
| wussboy wrote:
| I went back just to try that out. Such fun!
___________________________________________________________________
(page generated 2021-06-03 23:01 UTC)