Why is OpenSSL able to use a key file my user shouldn't have access to?
Why is OpenSSL able to use a key file my user shouldn't have access to?
The following command works even though I really don't think I should have permission to the key file:
$ openssl aes-256-cbc -d -pbkdf2 -in etc_backup.tar.xz.enc -out etc_backup.tar.xz -k /etc/ssl/private/etcBackup.key
I'm unable to even ascertain the existence of the key file under my normal user. I'm a member of only two groups, my own group and vboxusers.
The permissions leading up to that file:
drwxr-xr-x 1 root root 4010 Jul 31 08:01 etc
...
drwxr-xr-x 1 root root 206 Jul 14 23:52 ssl
...
drwx------ 1 root root 26 Jul 31 14:07 private
...
-rw------- 1 root root 256 Jul 31 14:07 etcBackup.key
OpenSSL isn't setuid:
> ls -la $(which openssl)
-rwxr-xr-x 1 root root 1004768 Jul 14 23:52 /usr/bin/openssl
There don't appear to be any ACLs related to that key file:
> sudo getfacl /etc/ssl/private/etcBackup.key
[sudo] password for root:
getfacl: Removing leading '/' from absolute path names
# file: etc/ssl/private/etcBackup.key
# owner: root
# group: root
user::rw-
group::---
other::---
> sudo lsattr /etc/ssl/private/etcBackup.key
---------------------- /etc/ssl/private/etcBackup.key
Finally, it's not just the case that the original file was encrypted with an empty file:
> openssl aes-256-cbc -d -pbkdf2 -in etc_backup.tar.xz.enc -out etc_backup.tar.xz -k /etc/ssl/private/abc.key
bad decrypt
4047F634B67F0000:error:1C800064:Provider routines:ossl_cipher_unpadblock:bad decrypt:providers/implementations/ciphers/ciphercommon_block.c:124
Does anyone know what I've missed here?
The -k argument on my openssl accepts a passphrase, not a file. You likely encrypted with the filename as the secret, not it's contents. Perhaps you should use -kfile instead.
$ openssl aes-256-cbc -help Usage: aes-256-cbc [options] General options: -help Display this summary -list List ciphers -ciphers Alias for -list -e Encrypt -d Decrypt -p Print the iv/key -P Print the iv/key and exit -engine val Use engine, possibly a hardware device Input options: -in infile Input file ** -k val Passphrase** -kfile infile Read passphrase from fileWow, thanks for this. Those are two very similar flags and I missed this entirely.
Everyone - Now that you know my passphrase, be sure to keep it a secret!
On my machine at least
man opensslshows that-kis for specifying the password you want to derive the key from, so in that case I think you are literally using the string/etc/ssl/private/etcBackup.keyas the password. I think the flag you want is-kfile.You can verify this by running the command in
straceand seeing that there is noopenatcall for the file passed to-k.Edit: [email protected] beat me to it while I was writing out my answer :)
I have about 0 experience with openssl, I just looked at the man page (openssl-enc). It looks like this command doesn’t take a positional argument. I believe the etcBackup.key file isn’t being read, as that command simply doesn’t attempt to read any files without a flag like -in or -out. I could be wrong though, see previously stated inexperience.
It seems OP wanted to pass the file name to
-k, but this parameter takes the password itself and not a filename:-k password The password to derive the key from. This is for compatibility with previous versions of OpenSSL. Superseded by the -pass argument.So, as I understand, the password would be not the first line of
/etc/ssl/private/etcBackup.key, but the string/etc/ssl/private/etcBackup.keyitself. It seems that-kfile /etc/ssl/private/etcBackup.keyor-pass file:/etc/ssl/private/etcBackup.keyis what OP wanted to use.Oh that's nasty. I bet a quick github search would turn up some people making the same mistake.