Discuss recently disclosed firmware attacks

[drduh]

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]

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]

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]

Or simply, reinstall a fresh new copy, follow the instructions OFFLINE, and just live peacefully with the fact that a malware might be living in your firmware.

–M

On Mar 24, 2017, at 7:49 AM, DtpEJsaYXDU4GDH8dE4MyI9VrieF0UZpPZ0K76K notifications@github.com wrote:

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.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/drduh/macOS-Security-and-Privacy-Guide/issues/213#issuecomment-288932714, or mute the thread https://github.com/notifications/unsubscribe-auth/AZaHQLGmLsHs0iszYm5f1Ps8dXHkkoPHks5ro0tdgaJpZM4Mnhc_.

[gripedthumbtacks]

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

[ghost]

Anything like “flushing” firmware? resetting? think of it the say way of DNS Flush.

Fear is not from government, to be honest, but from stories like "This American Surveillance Tool Helped Russians Spy On Androids And iPhones” https://www.forbes.com/sites/thomasbrewster/2017/03/22/iphone-android-malware-from-las-vegas-in-russia-cybercrime-links/#d22da0e2a8ae https://www.forbes.com/sites/thomasbrewster/2017/03/22/iphone-android-malware-from-las-vegas-in-russia-cybercrime-links/#d22da0e2a8ae

I’m sure, kinda sure, these tools or at least the source code has fallen into many many wrong hands.

–M

On Mar 24, 2017, at 8:04 AM, DtpEJsaYXDU4GDH8dE4MyI9VrieF0UZpPZ0K76K notifications@github.com wrote:

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

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[gdbinit]

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]

Thanks a lot for the defensive and really stunning details, and big thanks for sharing the slides.

I don’t want to be ignorant or lazy, but most of the tools available now like Chipsec are not safe to tun on production machines, we can’t predict the result and it will be painful to recover (if recovery is possible) from a kernel failure.

I mean to say, in other words, we need the public to be able test/check their Macs with a certain tool that at least, and I am satisfied with at least, gives us an indication or sign something was altered, changed, or added. I believe this is Apple’s responsibility to solve this, and inform the public of countermeasures.

My mind need to learn more if you can provide input regarding factory-level infection.

From WikiLeaks piece:

Also included in this release is the manual for the CIA's "NightSkies 1.2" a "beacon/loader/implant tool" for the Apple iPhone. Noteworthy is that NightSkies had reached 1.2 by 2008, and is expressly designed to be physically installed onto factory fresh iPhones. i.e the CIA has been infecting the iPhone supply chain of its targets since at least 2008.

How?!

–M

On Mar 24, 2017, at 11:42 AM, fG! notifications@github.com wrote:

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.

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

Best, fG!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[TraderStf]

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]

As some friends who tested it, it causes kernel panic in various cases.

–M

On Mar 24, 2017, at 3:30 PM, Stéphane Moureau notifications@github.com wrote:

https://github.com/chipsec/chipsec 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.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/drduh/macOS-Security-and-Privacy-Guide/issues/213#issuecomment-289010251, or mute the thread https://github.com/notifications/unsubscribe-auth/AZaHQCOH2e593FBPgocoFxqNJV3WmZmyks5ro7dKgaJpZM4Mnhc_.

[hazcod]

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/