Re: [dm-crypt] LUKS header recovery attempt, bruteforce detection of AF-keyslot bit errors

[protagonist <listdump@depressiverobots.com>]

On 24.04.2017 19:00, Dominic Raferd wrote:
> You seem to have considered the options pretty thoroughly. ​If the
> original owner has come to you, so s/he knows they have been typing in
> the same passphrase until one day it stopped working - and they have
> told you that passphrase, then an error in recording the passphrase can
> be discounted.
This is the case. The disk had been used in a privately owned laptop.

> Is there any possibility that a malicious third party (disgruntled
> ex-sysadmin perhaps) gained root access to the machine during its last
> session and changed the passphrase? As an aside, of no help to OP I'm
> afraid: is a prior backup of the LUKS header a protection against this
> scenario (i.e. against a subsequently deleted, or changed and now
> unknown, passphrase)?

If a malicious program had been able to run as root and deliberately
wrote into the LUKS header sectors to corrupt them, it definitely did so
in a very "plausible" fashion in terms of writing pseudo-random values
in the allowed areas. Given the fact that this was a fairly low-value
target, I doubt there was any reason to do this in such a "stealthy"
fashion if making the disk unusable had been the intention of such a
hypothetical malware. It's basically impossible to find out at this
point whether or not that was the case, but it's a scary thought that
should make everyone do header backups.

Regarding a "change" of passphrases:
A program would need access to the master key of the disk to create a
new, working key slot. As far as I know, a valid passphrase would be
needed during the normal cryptsetup procedures to open one of the
existing key slots, extract the master key and build the new keyslot
data containing a new copy of the master key.
However, I assume it is likely that a determined attacker running as
root might be able to extract the master key from RAM if the encrypted
volume in question is still open at the time of attack, so technically,
there would be a way to do this without the password.

I've asked the owner about mnemonics for the password, and they indeed
checked out, so I'd consider the passphrase integrity question as
settled in this case.

Regards,
protagonist