Dealing with Evil Maid exploits and how to protect your company. Giulio D’Agostino August 18, 2018 CyberSecurityMalwareSecurity
An Evil Maid assault is when a device has physically tampered without the device owner’s knowledge. Evil Maid attacks where a bootloader has been installed onto the victim’s computer which defeats full disk encryption. Now, however, thanks to solutions like Edward Snowden’s new Android program, which is called Haven, people can help prevent Evil Maid strikes and protect their devices from physical tampering while they’re not present.[…]This program is vital for those that have sensitive information on their devices and need extra protection against Evil Maid attacks. […]
someone has created some more Mac-centric Evil Maid detection code:
this is lovely! 😍 Via the 'Execute Action' option in DnD, you can specify a command or script to execute when your laptop is opened. Check out @ptrckhbr's neat script that will fire off an email (w/ logs) 📧💻 #StopEvilMaidshttps://t.co/goWVhEuHjT
I wish someone would collect all the various FW/OS-centric ways to check for Evil Maids, and write a tool that covers all of them. Here’re some other ways, via You’ll Never Take Me Alive (YONTMA) from iSEC Partners (now NCC Group):
Anti Evil Maid is an implementation of a TPM-based dynamic (Intel TXT) trusted boot for dracut/initramfs-based OSes (Fedora, Qubes, etc.) with a primary goal to prevent Evil Maid attacks. In short, AEM relies on TPM and a feature found in Intel’s vPro CPUs (TXT) to detect tampering of various boot components.
Even if you don’t use Qubes, this is a good read:
[…]To recap — you need to fully trust: * CPU (Intel, since we’re depending on TXT) + sometimes over-optimizes for performance at the cost of security, see eg. Meltdown/Spectre, cache attacks against SGX enclaves, … * TPM (various vendors) + few known attacks sniffing and injecting commands on the LPC bus; differential power analysis; buggy RSA key generation code + note that any potential TPM exploits (should) have no means of compromising your system directly — a TPM under attacker’s control can only be used to hide the fact that a compromise has occurred (ie. defeating the whole AEM feature) * BIOS (a few vendors) + it’s full of holes! * that the attacker cannot get physically inside your laptop without you noticing (see the glitter hint above) […]
For those who need Evil Maid skills take note: Joe Fitzpatrick has added a BIOS mod lab to his Black Hat training on x86 physical attacks.
Applied Physical Attacks on x86 Systems Joe FitzPatrick, SecuringHardware.com July 30-August 2
This course introduces and explores attacks on several different relatively accessible interfaces on x86 systems. Attendees will get hands-on experience implementing and deploying a number of low-cost hardware devices to enable access, privilege, and deception which is in some cases imperceptible from software. The course has several modules: USB, SPI/BIOS, I2C/SMBus, PCIe, and JTAG. Each begins with an architectural overview of an interface, and follows with a series of labs for hands-on practice understanding, observing, interacting with, and exploiting the interface, finishing with either potentially exploitable crashes or directly to root shells.
Most news sites are reporting about bad security in Western Digital hard drives. As presented at Hardware.io the other week, and from the Full Disclosure mailing list from a few days ago, excerpt below:
Authors: Gunnar Alendal, Christian Kison, modg Vendor notification: The vendor has been informed of the research. Patches: The authors are not aware of any fixes.
Research on Western Digital wide-spread self-encrypting hard drive series “My Passport” / “My Book”. Devices researched utilizes mandatory HW AES encryption. Multiple vulnerabilities, including: * Multiple authentication backdoors, bypassing password authentication * AES factory key recovery attacks, exposing user data on all affected devices, regardless of user password * Exposure of HW PRNGs used in cryptographic contexts * Unauthorized patching of FW, facilitating badUSB/evil-maid attacks
Trust as the no. 1 enemy of security: the client systems study
We are forced to trust a lot of things: the files we receive or websites we visit, that they are not going to exploit bugs in our (trusted) apps, the (trusted) software we use has no backdoors built in or added by 3rd parties. Also that the (trusted) OS components are secure and can protect our data, that the underlying (trusted) firmware and hardware is not subverting security mechanisms implemented by our (trusted) Operating System. The more trust we are forced into, the less secure our digital lives are, of course. Trust is the #1 enemy of security. Is there anything we can do about it? What’s the smallest reasonable amount of trust we need in case of a typical client (desktop) system today? Can trust be distributed?
Bio: Joanna Rutkowska is a founder of Invisible Things Lab and the Qubes OS project, which she has been leading since its inception in 2010. Prior to that she has been focusing on system-level offensive security research. Together with her team at ITL, she has presented numerous attacks on virtualization systems and Intel security technologies, including the famous series of exploits against the Intel Trusted Execution Technology (TXT), the still-only-one software attack demonstrating Intel VT-d escape, and also supervised her team with the pioneering research on breaking into the Intel vPro BIOS and AMT/MT technology. She is also known for writing Blue Pill, the first hardware virtualization-based rootkit, introducing Evil Maid attack, and for her prior work on kernel-mode malware for Windows and Linux in the first half of the 2000s.