Apple seeks Core EFI Manager and Mac EFI Bring Up Engineer

The Mac Platform Software team is looking for a talented engineering manager to lead a team of firmware and systems software engineers responsible for developing Apple’s UEFI implementation and related technologies for the Mac product line. Mac Platform Software is responsible for bringing up macOS and Windows on all new Mac products, including the development and integration of firmware and systems software for macOS and Windows, the development of platform-level features for the Mac, and the leadership of cross-functional debug and optimization efforts across hardware and software teams.[…]

https://jobs.apple.com/search?job=56058298&openJobId=56058298#&openJobId=56058298

The Mac Platform team in Core OS is looking for a talented UEFI engineer to work on the bring-up of new Mac products. Breathe life into new Mac products by developing firmware across all phases of development, from pre-silicon to product ramp.[…]

https://jobs.apple.com/search?job=56058163&openJobId=56058163#&openJobId=56058163

more on Apple/SuperMicro story

Re: https://firmwaresecurity.com/2017/02/24/apple-rejects-supermicro-due-to-bad-firmware/

An update from the Ars Technica story:

Update: A source familiar with the case at Apple told Ars that the compromised firmware affected servers in Apple’s design lab, and not active Siri servers. The firmware, according to the source, was downloaded directly from Supermicro’s support site—and that firmware is still hosted there.

Apple issued the following official comment: Apple is deeply committed to protecting the privacy and security of our customers and the data we store. We are constantly monitoring for any attacks on our systems, working closely with vendors and regularly checking equipment for malware. We’re not aware of any data being transmitted to an unauthorized party nor was any infected firmware found on the servers purchased from this vendor.

https://arstechnica.com/information-technology/2017/02/apple-axed-supermicro-servers-from-datacenters-because-of-bad-firmware-update/

https://www.theinformation.com/apple-severed-ties-with-server-supplier-after-security-concern?shared=516084

https://twitter.com/osxreverser/status/835673513528819713

Apple rejects Supermicro due to bad firmware

https://arstechnica.com/information-technology/2017/02/apple-axed-supermicro-servers-from-datacenters-because-of-bad-firmware-update/

http://appleinsider.com/articles/17/02/23/server-firmware-security-incident-in-2016-forced-apple-to-sever-ties-with-vendor-super-micro

https://www.macrumors.com/2017/02/23/apple-ends-relationship-with-super-micro/

Hurray for a vendor for checking the security of the hardware, and rejecting it for not being secure. If you are a big enough vendor, demand the output of CHIPSEC’s security tests and FWTS’s test results, before you buy it.  If CHIPSEC is failing, do not buy it. This is the only way some OEMs will learn to build secure systems. Unfortunately, no end user consumer has this ability. Large enterprises do, and I wish more would be doing it, and demanding the results be public. OEMs which build secure systems should be proactively showing their test results, so that savvy customers will realize this huge market advantage over competitors.

I wonder what kind of incident this was, firmware malware or something else???

PCIleech -vs- Apple Mac OS X

It appears Mac OS X 10.12.2 has some firmware-related security updates, with some defense against PCILeech:

http://blog.frizk.net/2016/12/filevault-password-retrieval.html
https://github.com/ufrisk/pcileech

https://twitter.com/aionescu/status/809590186447228928

 macOS FileVault2 Password Retrieval

“macOS FileVault2 let attackers with physical access retrieve the password in clear text by plugging in a $300 Thunderbolt device into a locked or sleeping mac. The password may be used to unlock the mac to access everything on it. To secure your mac just update it with the December 2016 patches. Anyone including, but not limited to, your colleagues, the police, the evil maid and the thief will have full access to your data as long as they can gain physical access – unless the mac is completely shut down. If the mac is sleeping it is still vulnerable. Just stroll up to a locked mac, plug in the Thunderbolt device, force a reboot (ctrl+cmd+power) and wait for the password to be displayed in less than 30 seconds!
[…]
Recovering the password is just one of the things that are possible unless the security update is applied. Since EFI memory can be overwritten it is possible to do more evil …
[…]
December 13th: Apple released macOS 10.12.2 which contains the security update. At least for some hardware – like my MacBook Air.
[…]”

Look at recent Tweets from Xeno Kovah, he has multiple posts with information about the 10.12.2 update:

https://twitter.com/XenoKovah/

Firmware passwords:
https://support.apple.com/en-us/HT202796
https://support.apple.com/en-us/HT204455
https://support.apple.com/en-us/HT203409

I’ll admit, I didn’t find any firmwaer information in their release:
https://support.apple.com/en-us/HT207423

CHIPSEC ported to Apple Mac OS X!

Wow, CHIPSEC is ported to Mac OS X! This is great news for Mac owners! CHIPSEC requires a native kernel driver to support CHIPSEC’s HAL. Before this, there was only Linux and Windows HAL drivers for CHIPSEC, so Mac OS X users had to reboot with a Linux-based distro which had CHIPSEC (eg, LUV-live). Live use aside, this also probably means you’ll be able to use CHIPSEC on OS X for offline analysis of blobs.

OSX Driver for Chipsec. This driver is currently in alpha release. It is not signed and you will need to disable the System Integrity Protection to load it. It is only compatible with x86_64 kernels, that is any release >= 10.7. How to:
1. (optional) Build the Driver using Xcode (chipsec.xcodeproj)
2. Turn the System Integrity Protection off: see
    https://developer.apple.com/library/mac/documentation/Security/Conceptual/System_Integrity_Protection_Guide/ConfiguringSystemIntegrityProtection/ConfiguringSystemIntegrityProtection.html
3. Reboot and load the driver
   # kextutil chipsec.kext
4. Within the source/tool directory, run:
   # python chipsec_util.py spi info
   # python chipsec_util.py spi dump rom.bin
5. Unload the driver

https://github.com/chipsec/chipsec/blob/master/source/drivers/osx/README

https://github.com/chipsec/chipsec/pull/69

https://github.com/chipsec/chipsec/commit/b00c037101523212725c60d35f3f70b168a44e1c

With an OS X port of the CHIPSEC HAL, Apple’s OS is starting to catch up with Linux and Windows. I hope Apple paid @tweksteen for the effort, Apple should have done this port long ago. FreeBSD/OpenBSD/NetBSD: time for you to catch up too! 🙂

Nikolaj joins Apple!!

WOW!!, Nikolaj joins Apple!! First they hired Legbacore, now Nikolaj!

As well, UEFITool has new maintainers, Alex and Dmytro!!

additional Apple device property support for Linux efistub

Lukas Wunner submitted a 6-part patch to the Linux-(EFI,Kernel) lists with additional Apple EFI firmware support.

Apple device properties
Apple EFI drivers supply device properties which are needed to support Macs optimally. This series extends the efistub to retrieve the device properties before ExitBootServices is called (patch [1/6]). They are assigned to devices in an fs_initcall (patch [5/6]). As a first use case, the Thunderbolt driver is amended to take advantage of the Device ROM supplied by EFI (patch [6/6]). A by-product is a parser for EFI Device Paths which finds the struct device corresponding to a given path. This is needed to assign properties to their devices (patch [3/6]). […]

For more info:
https://github.com/l1k/linux/commits/apple_properties_v1
http://vger.kernel.org/majordomo-info.html

Apple patents kill switch for iPhone camera

Patent issues aside, government misuse aside, this infrared interface to iPhone is also a potential new OOB vector for attackers. I’m sure the concert recording industry will keep the technology secret, along with law enforcement. 🙂 If other phone/camera vendors compete with Apple, they will have to create a second attack vector, or license this patented method.

 

https://www.yahoo.com/tech/apple-patents-kill-switch-iphone-062022866.html
https://www.aclunc.org/blog/will-apples-new-patent-push-delete-ability-record-police

Can Apple’s New Infrared Patent Really Disable Your iPhone?

Patent issues a

List of UEFI vendors who care about security

Which UEFI vendors care — or at least may care — about security? The list (alphabetically) is shorter than you might expect:

AMD
AMI
Apple
Dell
Hewlett Packard Enterprises
HP Inc.
Insyde Software
Intel Corp.
Lenovo
Microsoft
Phoenix Technologies

Nobody else. If your vendor is not listed above, ask them why you should purchase a UEFI-based system from them.

The above list is from the list of vendors who have feedback mechanisms listed on the UEFI Forum’s security contact page.

http://uefi.org/security

Apple, FBI, Security Enclaves, and firmware

Security Enclave was first described in the Apple iOS Security Guide, listed below.

Apple updates iOS Security Guide

Apple can comply with the FBI court order

https://www.quora.com/What-is-Apple%E2%80%99s-new-Secure-Enclave-and-why-is-it-important

Apple acquires Legbacore — in the news again!

Back in November, Apple hired Legbacore’s hardware/firmware experts to help secure Apple hardware.

Apple acquires LegbaCore!!

Ok, that was months ago. But for the last week, the above URL re-appeared on this blog’s stats as the most visited URL. Then, a few days later, there’s now a slew of stories on this, like it just happened today. Today, this is the top store on Google News for UEFI. Strange, how tech news works.

http://appleinsider.com/articles/16/02/02/apple-hires-firmware-security-experts-who-worked-on-thunderstrike-2-exploit
http://www.macrumors.com/2016/02/02/apple-acquired-legbacore/
http://thenextweb.com/apple/2016/02/03/apple-acquired-the-security-company-that-found-bugs-in-mac-firmware/
http://timesofindia.indiatimes.com/tech/tech-news/Apple-acquired-the-company-that-exposed-flaws-in-its-firmware/articleshow/50837174.cms
http://www.businessinsider.com/apple-hired-the-hackers-who-created-the-first-mac-firmware-virus-2016-2
http://www.engadget.com/2016/02/03/apple-legbacore-thunderstrike-acquisition/
http://www.patentlyapple.com/patently-apple/2016/02/apple-acquired-legbacore-to-advance-security-for-macs.html
http://gadgets.ndtv.com/laptops/news/apple-buys-security-firm-legbacore-that-exposed-vulnerabilities-in-os-x-797979
http://www.bidnessetc.com/62638-apple-inc-acquires-mac-virus-detector-legbacore/

I am eagerly awaiting to see the results of their work, I hope future macs have a “Legbacore”-ready logo on it, or something so I know it’s better than the older hardware. 🙂

Apple security updates for iOS and OSX

Apple has released security updates for iOS, OS X El Capitan, and Safari to address multiple vulnerabilities. Exploitation of some of these vulnerabilities may allow a remote attacker to take control of an affected system.

https://www.us-cert.gov/ncas/current-activity/2016/01/19/Apple-Releases-Security-Updates-iOS-OS-X-El-Capitan-and-Safari

https://support.apple.com/en-us/HT205732

https://support.apple.com/en-us/HT205731

 

MacDBG: new Mac OS X debugger

Tyler Bohan has released a new debugging tool for Mac OS X, including a Capstone-based dissassembler:

Excerpt from readme:

Mac Debugger is simple easy to use C and python debugging framework for OSX. Mac Debugger was created with the focus on giving the programmer a powerful framework to programatically create scripts to debug programs on Mac OSX not found in other products for the platform. The core of macdbg, written in C, is kept as minimal as possible to provide enough basic interaction between the kernel and userland to create powerful features. Higher level functionality is left to the Python implementation such as stack tracing, dissasembly, watchpoints, thread state, and more. A wrapper class is provided for the programmer to create a scripting program. […]

https://github.com/blankwall/MacDBG

EFI_BruteForce: EFI PIN of Apple MacBooks

I just noticed an old article and tool by Kooftness, for brute-forcing the (or an) Apple EFI firmware password.  As I understand the article, the original code didn’t generate results while they had access to the laptop, but since then the code has been revised (7 months ago) and others claim success with the code. I am unclear if this is a 3rd party PIN tool or the main Apple Firmware Password feature.

These Teensyduino sketches (for Teensy embeded boards) and shell scripts are tools to bruteforce EFI or iCloud locks.

Recently I got my hands on a MacBook Pro that after three weeks of being bought the seller desided that he wanted it back. He expressed this by locking it with a 4 digit PIN and a message that stated “Give me back the laptop and give you back the money”, with out calling or anything. […] I was told that an alternative solution would be to get a fresh MBP, extract its firmware and flash it using a PIC programmer. He also told me that there are ways to get around this attacking the thunderbolt port but these two options have a high risk in bricking the $2.000 laptop. […] I have received confirmation that this code is working, as we can see in this thread at MacRumors […]

http://orvtech.com/atacar-efi-pin-macbook-pro-en.html
https://github.com/Kooftness/efi_bruteforce
https://github.com/Kooftness/efi_bruteforce/blob/master/efi_attack_modifyed

https://support.apple.com/en-us/HT204455
https://support.apple.com/en-us/HT203409

“If you can’t remember the firmware password for your Mac, schedule a service appointment with an Apple Retail Store or Apple Authorized Service Provider.”

It appears that any current/former Apple Store  “genius” can most likely bypass the Apple Firmware Password protection. 😦 I suppose any vendor who can reset the PIN can use it like the above merchant, to blackmail the customer for access to their device.

I look forward to seeing the results of LegbaCore working at Apple …though I am afraid that their new models will become less configurable, more like modern Windows boxes, unable to run anything but Apple-approved OSes and pre-OS code (eg, rEFInd).