CrySyS SecChallenge 2020: Secure? Vault
Part 2 Headquaters in Greenland
The cities were evacuated in time, and the now my ex-colleague has been arrested by the police. But unfortunately, he keep the incriminating evidence in an encrypted folder that we haven’t been able to crack yet. As far as I remember he always talked a lot about eCryptfs and I also noticed that he always choose his passwords well, but he don’t really care about other settings. Fortunately we managed to get an image that was next to the encrypted folder. I suspect that the picture may have something to do with the encrypted storage because his memory has been degraded due to a lot of drinking.
Categories
Forensics, Vault
Files
Links
Solution
We already know the two extensionless files are most likely eCryptfs files, so we start off with our image, walk.jpg:
JPEG files aren’t really suitable for steganography due to their lossy nature, however they can have EXIF data instead. Opening up the EXIF panel in nomacs we can see a Description of binwalk. The contents of the picture now make more sense. Unfortunately I haven’t had binwalk on my fresh VM yet, so instead I decided to just shift over the file quickly with a hex editor. During this, I noticed a familiar magic, namely IHDR which marks the begin of an image header in a PNG:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
000037C0 04 04 04 04 04 04 04 04 04 04 04 1F FF D9 89 50 ............ÿÙ‰P
000037D0 4E 47 0D 0A 1A 0A 00 00 00 0D 49 48 44 52 00 00 NG........IHDR..
000037E0 01 F4 00 00 00 64 08 06 00 00 00 70 C7 C2 7D 00 .ô...d.....pÇÂ}.
But wait, this isn’t a PNG. Confirming our suspicions of a PNG being hidden in the file, we can easily notice the PNG magic %PNG not much before IHDR, although split in half by the hex editor. Let’s extract and open this PNG:
Oh great, looks like we found the password already. Time to mount the encrypted folder and see what’s inside. To do this, we open the linked Arch Wiki’s eCryptfs article. After deciding our IQ is too low for this, we open up Ubuntu documentation’s article of the same name, and follow the commands there to mount the folder. Since the description said the guy didn’t care much about the settings, I just decided to mash enter (default answer) on every question:
user@ubuntu:~$ mkdir vault
user@ubuntu:~$ mv second vault
user@ubuntu:~$ mkdir vault_mnt
user@ubuntu:~$ sudo mount -t ecryptfs vault vault_mnt
Passphrase:
Select cipher:
1) aes: blocksize = 16; min keysize = 16; max keysize = 32
2) blowfish: blocksize = 8; min keysize = 16; max keysize = 56
3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24
4) twofish: blocksize = 16; min keysize = 16; max keysize = 32
5) cast6: blocksize = 16; min keysize = 16; max keysize = 32
6) cast5: blocksize = 8; min keysize = 5; max keysize = 16
Selection [aes]:
Select key bytes:
1) 16
2) 32
3) 24
Selection [16]:
Enable plaintext passthrough (y/n) [n]:
Enable filename encryption (y/n) [n]:
Attempting to mount with the following options:
ecryptfs_unlink_sigs
ecryptfs_key_bytes=16
ecryptfs_cipher=aes
ecryptfs_sig=d59f58c491da407f
WARNING: Based on the contents of [/root/.ecryptfs/sig-cache.txt],
it looks like you have never mounted with this key
before. This could mean that you have typed your
passphrase wrong.
Would you like to proceed with the mount (yes/no)? : yes
Would you like to append sig [d59f58c491da407f] to
[/root/.ecryptfs/sig-cache.txt]
in order to avoid this warning in the future (yes/no)? : no
Not adding sig to user sig cache file; continuing with mount.
Mounted eCryptfs
Let’s see what’s inside:
user@ubuntu:~$ ls vault_mnt
second
user@ubuntu:~$ cat vault_mnt/second
second_vault_key:b729ca23
Here we go again. After repeating the previous mounting procedure, we finally get access to the flag:
user@ubuntu:~$ ls vault2_mnt
flag
user@ubuntu:~$ cat vault2_mnt/flag
cd20{7h3_w0rld_15_54v3d_7h4nk_y0u}