Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Discuss recently disclosed firmware attacks #213

Closed
drduh opened this issue Mar 24, 2017 · 10 comments
Closed

Discuss recently disclosed firmware attacks #213

drduh opened this issue Mar 24, 2017 · 10 comments

Comments

@drduh
Copy link
Owner

drduh commented Mar 24, 2017

Taking into consideration Wikileaks' recent release of CIA hacking tools (https://wikileaks.org/vault7/darkmatter/?cia), we ought to attempt to better document UEFI promiscuity and make a recommendation for hardening against various firmware attacks, which will only become more ubiquitous from now on.

For instance, we may wish to make a suggestion as to whether it's best to leave a Mac suspended (halt cpu/power ram/acpi s3) or hibernating (halt cpu/halt ram/acpi s4) or powered off altogether (acpi s5) when anticipating an implant, e.g. at border crossings. It may also be prudent to specifically caution against Option ROMs from peripheral devices outside of one's physical control (e.g., Ethernet adapters at a hotel).

I would be delighted with a helping hand or review from @gdbinit, @snare and other well-know experts.

@ghost
Copy link

ghost commented Mar 24, 2017

one of the things about Dark Matter described in WikiLeaks's revelations:
"...which contains documentation for several CIA projects that infect Apple Mac firmware (meaning the infection persists even if the operating system is re-installed)".

How this is going to be solved?

–M

@gripedthumbtacks
Copy link

there is no reliable way to recover if the low-level firmware is compromised. it could get installed into the battery firmware too. because the firmware would then control all future execution, it could hide itself from attempts to overwrite to a known good firmware, etc. or it could add additional backdoors into your BIOS, TPM keys, DVD drive, monitor or displays via HDMI, video card, etc. Just throw it out and buy a new one and take any legal actions without your means to penalize the attackers, if known.

@ghost
Copy link

ghost commented Mar 24, 2017 via email

@gripedthumbtacks
Copy link

unfortunately, the firmware can reactivate inside your OS at any time in the future.

@ghost
Copy link

ghost commented Mar 24, 2017 via email

@gdbinit
Copy link

gdbinit commented Mar 24, 2017

Hi,

A MacBook should always be left completely powered off in crossing borders scenarios and others. Hell, you shouldn't go back home with your laptop in sleep mode if you care about this (remember the guy that got his phone stolen by the police while he was talking because that way it was unlocked?).

For tips on chasing and fixing EFI rootkits you can refer to my slides from 2015: https://papers.put.as/papers/macosx/2015/CodeBlue_2015_-_Efi_Monsters.pdf

As long you have a known good copy (which can be obtained from Apple EFI updates or my EFI Vault https://github.com/gdbinit/firmware_vault) and some hardware (presentation slides has some pointers for this, Arduino works) you can easily recover from EFI attacks. It's just a matter of reflashing the flash that holds EFI. This is easier in older models that SOIC flash chips with the pins exposed versus newer machines that are BGA so no easy access. On these newer machines there is a debug port but with "proprietary" Apple connector. That port has functionality to talk SPI to the flash chip and dump it.

One thing that needs to be clear is that you can only chase this kind of rootkits from hardware dumps. Chipsec is a great tool but not going to help you fight against a good rootkit that has anti-forensics capabilities. You can't win a battle in software when a rootkit started to run long before your kernel and userland apps.

Apple is also working on a software tool that was present in some Sierra 10.12.4 betas but recently removed. Its greated feature is a huge database of all their firmware versions, meaning a known good point of comparison. They also dump the flash but it's still from software so not really good for chasing this kind of rootkits.

The best line of defense is to assure you have a point zero and then regularly dump the flash and compare results to see if any infection happened between.

Another area of interest is the SMC chip. There's research from Alex Ionescu and Andrea Barisani about this topic. Another very good place to put a Mac implant.

And last but not least, not everyone is a special snowflake that deserves to be attacked with EFI and other hardware rootkits. That is usually reserved for really high valuable targets ;-)

Feel free to copy & paste whatever you need from here and ask any questions :-)

Best,
fG!

@ghost
Copy link

ghost commented Mar 24, 2017 via email

@TraderStf
Copy link
Contributor

TraderStf commented Mar 24, 2017

https://github.com/chipsec/chipsec
CHIPSEC is a framework for analyzing the security of PC platforms including hardware, system firmware (BIOS/UEFI), and platform components. It includes a security test suite, tools for accessing various low level interfaces, and forensic capabilities. It can be run on Windows, Linux, Mac OS X and UEFI shell.

@ghost
Copy link

ghost commented Mar 24, 2017 via email

@hazcod
Copy link
Contributor

hazcod commented Aug 20, 2018

I suppose with the arrival of the T2 chip in newer models, the firmware is being checked.
http://michaellynn.github.io/2018/07/27/booting-secure/

@drduh drduh closed this as completed in 4cee71c Jan 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants