Reversing Prince Harming’s kiss of death

The suspend/resume vulnerability disclosed a few weeks ago (named Prince Harming by Katie Moussouris) turned out to be a zero day. While (I believe) its real world impact is small, it is nonetheless a critical vulnerability and (another) spectacular failure from Apple. It must be noticed that firmware issues are not Apple exclusive. For example, Gigabyte ships their UEFI with the flash always unlocked and other vendors also suffer from all kinds of firmware vulnerabilities.

As I wrote in the original post, I found the vulnerability a couple of months ago while researching different ways to reset a Mac firmware password. At the time, I did not research the source of the bug due to other higher priority tasks. One of the reasons for its full disclosure was the assumption that Apple knew about this problem since newer machines were not vulnerable. So the main question after the media storm was if my assumption was wrong or not and what was really happening inside Apple’s EFI.

The bug is definitely not related to a hardware failure and can be fixed with a (simple) firmware update. The initial assumptions pointing to some kind of S3 boot script failure were correct.
Apparently, Apple did not follow Intel’s recommendation and failed to lock the flash protections (and also SMRR registers) after the S3 suspend cycle. The necessary information is not saved, so the locks will not be restored when the machine wakes up from sleep.

This also allows finding which Mac models are vulnerable to this bug.
All machines based on Ivy Bridge, Sandy Bridge (and maybe older) platforms are vulnerable. This includes the newest Mac Pro since its Xeon E5 CPU is still based on Ivy Bridge platform. All machines based on Haswell or newer platforms are not vulnerable.

Now let’s jump to the technical part and understand why the bug occurs. I am also going to show you how to build a temporary fix.
Continue reading

The Empire Strikes Back Apple – how your Mac firmware security is completely broken

If you are a rootkits fan the latest Chaos Communication Congress (CCC) in 2014 brought us two excellent presentations, Thunderstrike by Trammell Hudson and Attacks on UEFI security, inspired by Darth Venami’s misery and Speed Racer by Rafal Wojtczuk and Corey Kallenberg.

The first one was related to the possibility to attack EFI from a Thunderbolt device, and the second had a very interesting vulnerability regarding the UEFI boot script table. The greatest thing about the second vulnerability is that it allows to unlock flash protections by modifying the boot script executed after a S3 suspend-resume cycle.

Dmytro Oleksiuk aka Cr4sh released proof of concept code regarding this attack against an Intel DQ77KB motherboard. His very interesting blog post is “Exploiting UEFI boot script table vulnerability”. You should definitely read it.

My interest in EFI has been mostly about unlocking a firmware password that I forgot. While Trammell didn’t release the proof of concept code for Thunderstrike he did release an awesome tool, a SPI Flash reader for Teensy 2.x that is extremely fast reading the BIOS contents (takes a few minutes). This was a great improvement versus BusPirate which took hours to just read the BIOS memory. Months before I tried to get into EFI world but the BusPirate was so slow it was impossible to use it for trial and error testing. The new tool got my interest back into EFI. Anyway, enough bla bla.

Trammell on his presentation mentioned the possiblity that Macs could also be vulnerable to the Dark Jedi attack. After Cr4sh blog post I decided to give it a try and explore the same attack.

The attack requires you to reverse the boot script implementation, which is a royal pain in the ass. EFI binaries are a bit annoying to reverse even with the assistance of Snare’s EFI utils. IDA also has some bugs regarding EFI binaries.
While doing some experiments with flashrom I finally noticed something big. I couldn’t believe it the first time so I tried it in other Macs and it was indeed true. Macs have an even bigger hole than Dark Jedi.

Drum roll…

What is that hole after all? Is Dark Jedi hard to achieve on Macs?
No, it’s extremely easy because Apple does all the dirty work for you. What the hell am I talking about?
Well, Apple’s S3 suspend-resume implementation is so f*cked up that they will leave the flash protections unlocked after a suspend-resume cycle. !?#$&#%&!#%&!#

And you ask, what the hell does this mean? It means that you can overwrite the contents of your BIOS from userland and rootkit EFI without any other trick other than a suspend-resume cycle, a kernel extension, flashrom, and root access.

Wait, am I saying Macs EFI can be rootkitted from userland without all the tricks from Thunderbolt that Trammell presented? Yes I am! And that is one hell of a hole :-).

Let me show you how it happens. The following is the flashrom output of a freshly rebooted MacBook Pro Retina 10,1 running the latest EFI firmware available (this is the firmware that was released to “fix” Thunderstrike).

sh-3.2# ./flashrom -r biosdump -V -p internal
flashrom v0.9.7-r1711 on Darwin 14.3.0 (x86_64)
flashrom is free software, get the source code at http://www.flashrom.org
 
(...)
Found chipset "Intel HM77" with PCI ID 8086:1e57.
(...)
BIOS_CNTL = 0x01: BIOS Lock Enable: disabled, BIOS Write Enable: enabled
Root Complex Register Block address = 0xfed1c000
GCS = 0xc21: BIOS Interface Lock-Down: enabled, Boot BIOS Straps: 0x3 (SPI)
Top Swap : not enabled
SPIBAR = 0xfed1c000 + 0x3800
0x04: 0xe008 (HSFS)
HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1, FLOCKDN=1
Warning: SPI Configuration Lockdown activated.
Reading OPCODES... done
0x06: 0x0004 (HSFC)
HSFC: FGO=0, FCYCLE=2, FDBC=0, SME=0
0x50: 0x0000ffff (FRAP)
BMWAG 0x00, BMRAG 0x00, BRWA 0xff, BRRA 0xff
0x54: 0x00000000 FREG0: Flash Descriptor region (0x00000000-0x00000fff) is read-write.
0x58: 0x07ff0190 FREG1: BIOS region (0x00190000-0x007fffff) is read-write.
0x5C: 0x018f0001 FREG2: Management Engine region (0x00001000-0x0018ffff) is read-write.
0x74: 0x866f0190 PR0: Warning: 0x00190000-0x0066ffff is read-only.
0x78: 0x9fff0692 PR1: Warning: 0x00692000-0x01ffffff is read-only.
Writes have been disabled for safety reasons. You can enforce write
support with the ich_spi_force programmer option, but you will most likely
harm your hardware! If you force flashrom you will get no support if
something breaks. On a few mainboards it is possible to enable write
access by setting a jumper (see its documentation or the board itself).
0x90: 0xc0 (SSFS)
SSFS: SCIP=0, FDONE=0, FCERR=0, AEL=0
0x91: 0xf94000 (SSFC)
SSFC: SCGO=0, ACS=0, SPOP=0, COP=0, DBC=0, SME=0, SCF=1
0x94: 0x0606     (PREOP)
0x96: 0x3c6c     (OPTYPE)
0x98: 0x0103029f (OPMENU)
0x9C: 0xffd82005 (OPMENU+4)
0xA0: 0x00000000 (BBAR)
0xC4: 0x00800000 (LVSCC)
LVSCC: BES=0x0, WG=0, WSR=0, WEWS=0, EO=0x0, VCL=1
0xC8: 0x00002005 (UVSCC)
UVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20, VCL=0
0xD0: 0x00000000 (FPB)
(...)

What we can see here is that the flash lockdown is active (FLOCKDN=1) and that the BIOS region is mostly read-only. The hole that is writable is the NVRAM portion that is necessary for setting boot options, crash logs and so on. The addresses where EFI binaries are located is lock down by the flash protections (PR0/PR1). The Dark Jedi attack would allow to unlock these areas and make them writable.

After I close the MacBook and let it sleep for a few seconds (30 seconds or something is best, sometimes it doesn’t work and needs to sleep some extra time), we get the following flashrom output after waking up the machine:

sh-3.2# ./flashrom -r biosdump2 -V -p internal
flashrom v0.9.7-r1711 on Darwin 14.3.0 (x86_64)
flashrom is free software, get the source code at http://www.flashrom.org
(...)
Found chipset "Intel HM77" with PCI ID 8086:1e57.
(...)
BIOS_CNTL = 0x01: BIOS Lock Enable: disabled, BIOS Write Enable: enabled
Root Complex Register Block address = 0xfed1c000
GCS = 0xc21: BIOS Interface Lock-Down: enabled, Boot BIOS Straps: 0x3 (SPI)
Top Swap : not enabled
SPIBAR = 0xfed1c000 + 0x3800
0x04: 0x6008 (HSFS)
HSFS: FDONE=0, FCERR=0, AEL=0, BERASE=1, SCIP=0, FDOPSS=1, FDV=1, FLOCKDN=0
Programming OPCODES... done
0x06: 0x0004 (HSFC)
HSFC: FGO=0, FCYCLE=2, FDBC=0, SME=0
0x50: 0x0000ffff (FRAP)
BMWAG 0x00, BMRAG 0x00, BRWA 0xff, BRRA 0xff
0x54: 0x00000000 FREG0: Flash Descriptor region (0x00000000-0x00000fff) is read-write.
0x58: 0x07ff0190 FREG1: BIOS region (0x00190000-0x007fffff) is read-write.
0x5C: 0x018f0001 FREG2: Management Engine region (0x00001000-0x0018ffff) is read-write.
0x90: 0xc0 (SSFS)
SSFS: SCIP=0, FDONE=0, FCERR=0, AEL=0
0x91: 0xf94000 (SSFC)
SSFC: SCGO=0, ACS=0, SPOP=0, COP=0, DBC=0, SME=0, SCF=1
0x94: 0x5006     (PREOP)
0x96: 0x463b     (OPTYPE)
0x98: 0x05d80302 (OPMENU)
0x9C: 0xc79f0190 (OPMENU+4)
0xA0: 0x00000000 (BBAR)
0xC4: 0x00800000 (LVSCC)
LVSCC: BES=0x0, WG=0, WSR=0, WEWS=0, EO=0x0, VCL=1
0xC8: 0x00002005 (UVSCC)
UVSCC: BES=0x1, WG=1, WSR=0, WEWS=0, EO=0x20, VCL=0
0xD0: 0x00000000 (FPB)
(...)

This time we have FLOCKDN=0 and the protected range registers (PR0/PR1) without any contents. The flash is unlocked and now you can use flashrom to update its contents from userland, including EFI binaries. It means Thunderstrike like rootkit strictly from userland.

Which Macs are vulnerable to this?

I have tested against a MacBook Pro Retina 10,1, a MacBook Pro 8,2, and a MacBook Air 5,1, all running latest EFI firmware available. And every single one is vulnerable. The Late 2013 Mac Pro (aka Trashcan), MacBook Pro 9,1 are also tested to be vulnerable.
It appears that latest MacBook models are not vulnerable but I’m not 100% sure about this. I couldn’t fully test it on a recent model (the owner was afraid of giving me root access ;-)). The first impression was that the bug was silently fixed by Apple but this requires extensive testing to be sure (or some EFI binary disassembling).
I expect all mid/late 2014 machines and newer to not be vulnerable. Apple either fixed it by accident or they know about it. It’s not something you just fix by accident, just sayin’.

I’m pretty sure Apple is aware of the bug or at least it would be quite irresponsible from them to not test if their BIOS implementation was vulnerable to the Dark Jedi attack. I had no issues doing PoC tests with it but definitely needs other people to test it out (at least to find which other Macs are vulnerable).

How can you protect yourself from this?
Do not let your computer sleep and always shutdown it.
You should also email Apple and demand firmware security fixes for this bug and others to be presented at Defcon 23 – ThunderStrike 2: Sith Strike.
This is not full protection since the full Dark Jedi is most probably still possible to execute. The only real fix is Apple to update the firmware.

Unfortunately I never finished reversing the S3 suspend-resume EFI binaries so I can’t show exactly where the bug is inside the code. It requires some improvements to current EFI reversing tools and other matters got higher priority than this.

There is also something funny. Flashrom requires DirectHW.kext to work. The funny thing is that this kext is on Apple’s exception list so no kext signature is required to load this one on Mavericks/Yosemite ;-).

Oh, is this irresponsible disclosure? Well I’m pretty sure Apple knows about this one but I could be very wrong. I’m confident Corey and Trammell disclosed this one to Apple and they will discuss it on their upcoming Defcon talk. If I’m wrong I just wasted a nice and valuable bug. Ooops!!!!
Either way the goal is to pressure them to fix their firmware. It doesn’t seem they are in a hurry ;-).

Why no fancy logo and name?
Well, because this is a variation of the Dark Jedi attack and I’m old school. I still believe knowledge should be shared for everyone to learn instead of PR whoring. And I already get enough PR from this blog ;-).

Update:

It appears I miscalculated this thing and appears to be an effective 0day. Doesn’t really matter since I always wanted to disclose it and not sell it due to its very powerful nature (and not working in newer machines). Never assume all bugs are shallow.

You might ask if I am into something against Apple judging by the tone of some posts. I am not. I like OS X and I respect Apple security people who I met a few times. My goal is to make OS X better and more secure.
The issue at stake is that I believe Apple has a corporate culture problem regarding security (like Microsoft had many years ago) and they only seem to react when pushed against a corner. If they indeed knew about the bug – because I don’t believe it’s a coincidence not working in latest machines – then they keep their pattern of not patching older versions. This is a bad policy and at least if they want to put it in practice at least be straightforward with customers and warn them about the issues. People can then take informed decisions about their risks. Of course this is wishful thinking and they will not shoot their own foot coming forward with things like this. But that’s a philosophical discussion about management around the world and why it’s so wrong these days.

How can you mitigate/detect a possible EFI compromise?

You can build a SPI dumper and use Trammell’s software to directly dump the BIOS chip. Then you can compare its contents against the firmware files provided by Apple. I asked Apple to start publishing these files and their signatures so we can have a good baseline to compare against. Hopefully they will do this one day. I built some tools for this purpose but they aren’t public.
This solves the EFI problem but others are left. For example there is SMC. Alex Ionescu made a very interesting presentation about it a few years ago at NoSuchCon. SMC has a very interesting potential for compromise so it’s also something that needs more research. And now we have PoC regarding GPU rootkits. Every single chip that has firmware and somehow talks to the operating system is open for compromise. We need to think different and start a trust chain from hardware to software. Everyone is trying to solve problems starting from software when the hardware is built on top of weak foundations.
Apple has a great opportunity here because they control their full supply chain and their own designs. I hope they finally see the light and take over this great opportunity. Google is trying with Chromebook.

Is physical access required to exploit this bug?

No, there’s no physical access required to exploit this. You can trigger sleep with “sudo pmset sleepnow” (thanks Trammell). And then you just wait to come back from sleep and continue exploitation.

How to test for this bug?

Downloading DarwinDumper and load the DirectHW.kext kernel extension. Then you can use flashrom with “flashrom -r biosdump -V -p internal” to dump the bios and show the register contents. Else you can compile yourself DirectHW.kext and also flashrom. DarwinDumper just works out of the box and its kext appears to be legit (it’s on Apple exclusion list so at least Apple trusts it ;-)).

Should you be worried about this bug?

As a general user you shouldn’t, in theory, be much worried with this bug more than you were with Thunderstrike. This is a bug more interesting to attack targeted users than mass exploitation, although a drive-by exploit is definitely feasible.
There are easier and cheaper attacks available against you the general user. As a reminder the latest Mac botnet infected around 17k users just by asking them for administrator privileges. Sophisticated attacks are not required when simple things still work.

Have fun,
fG!

P.S.: The bug can be used with a Safari or other remote vector to install an EFI rootkit without physical access. The only requirement is that a suspended happened in the current session. I haven’t researched but you could probably force the suspend and trigger this, all remotely. That’s pretty epic ownage ;-).

How to fix rootpipe in Mavericks and call Apple’s bullshit bluff about rootpipe fixes

The rootpipe vulnerability was finally fully disclosed last week after a couple of months of expectation since the first announcement. It was disclosed as a hidden backdoor but it’s really more something related to access control and crap design than a backdoor. Although keep in mind that good backdoors should be hard to distinguish from simple errors. In this case there are a lot of services using this feature so it’s hardly a hidden backdoor that just sits there waiting for some evil purpose. Apple doesn’t have a stellar security record so the simple explanation has a good chance to prevail over the backdoor story.

Anyway that’s not what really matter for this post. The most important issue is that a fix was made available only for Yosemite 10.10.3. Every other OS X version is left vulnerable. While this is a local privilege escalation vulnerability there are many scenarios where it can be used (you don’t audit every single installer and software that runs on your Mac, do you?). It is extremely reliable and can be used in different ways other than just creating a suid binary.
The vulnerability author wrote the following regarding this issue:
“Apple indicated that this issue required a substantial amount of changes on their side, and that they will not back port the fix to 10.9.x and older.”

So essentially Apple refuses to patch this in all versions except the latest one because it’s apparently too much work. There is no official statement from Apple regarding the EOL (End of Life) status about all previous OS X versions so this course of action is quite strange. Even stranger when Apple backports some security patches to those older versions so they are implicitly not yet dead versions.

In this situation what can we do?
We can try to verify what is the real impact of Apple’s fix and call their bluff if we can prove that we are able to produce a fix without significant changes to the operating system. Challenge accepted!
Continue reading

How to bypass Google’s Santa LOCKDOWN mode

Santa is a binary whitelisting/blacklisting system made by Google’s Macintosh Operations Team. While I refer to it as Google’s Santa it is not an official Google product. It is based on a kernel extension and userland components to control the execution of binaries in OS X systems.
It features two interesting modes of execution, monitor and lockdown. The monitor mode is a blacklisting system, where all binaries except those blacklisted can run. The lockdown mode is a whitelisting system, where only the whitelisted binaries can run and everything else will be blocked. This is the mode we want to attack and bypass since it’s the most interesting one from an attacker’s perspective.

The system works by having the kernel extension to notify the userland daemon about every new process that is executed in the system. The kernel extension retrieves this information using the Kernel Authorization (kauth) feature available since OS X 10.4. Essentially a callback is installed and the Santa driver will be notified every time a process is executed. This means that exec() and variants will result in a notification to the driver that will then decide to send the event to userland or not.

The userland component has an associated database that can whitelist or blacklist binaries based on path, certificate, and hashes (I think I’m not wrong on this). The code signature feature is interesting because it allows you to whitelist or blacklist an entire publisher. For example a company could easily restrict all the software that is allowed to run in their systems based on their code signing certificate. By default the lockdown mode install will whitelist Apple’s and Google’s certificates, else the system would enter a deadlock. Assuming we are not tampering with Santa’s binaries and attacking its implementation (if we can run kernel exploit code we can easily disable it) can we bypass the lockdown mode if we want to run our code that is not allowed to run?

Yes we can, and it’s very easy to do it :-)

What Santa essentially controls and restricts is exec and variants. But that’s not the only possible way to run arbitrary code. There is the obvious way of exploiting something and running our shellcode/ROP payload, and there are also dynamic libraries. Because Santa only controls exec we can run whatever code we want via a dynamic library injected using DYLD_INSERT_LIBRARIES without tampering with any Santa binary. We can go further and instead of putting all our code inside a dynamic library we can use it to run regular binaries that are not authorized to in lockdown mode.

We simply need to piggyback on any Apple signed binary (remember the system deadlock problem) with DYLD_INSERT_LIBRARIES to inject our library. For example any command line utility such as /bin/ls will do the job.
How can we execute other binaries using an injected dynamic library? That’s quite easy using some obscure and deprecated dyld functions. For example NSCreateObjectFileImageFromMemory and NSLinkModule would allow us to load an arbitrary executable into memory and execute it (please refer to Mac Hackers Handbook Chapter 9 and MemoryBasedBundle example by Apple).

The workflow is very simple. We inject our library into a whitelisted binary, load the unauthorized binary with those two dyld functions, and start it by calling its entrypoint (main) function. Because this doesn’t trigger a second exec we just bypass Santa controls. The original process will continue execution in the unauthorized binary and that’s it.

The sample code uses the deprecated APIs, which can be removed anytime (although they have been marked deprecated for quite a few OS X major versions). There’s really no need to use those APIs because we can do all their work ourselves. Most of the work is related to linking, so we could implement ourselves a simplified linker or re implement those functions and have dyld do all the dirty work for ourselves. As long we are able to inject a dynamic library we are able to bypass Santa. The DLL hijacking issue recently presented by Patrick Wardle could be used to plant the library and then execute any APT material.

The easiest way to fix this is to remove the possibility of library injection via DYLD_INSERT_LIBRARIES. The next post contains a kernel extension that implements this by injecting a __RESTRICT segment into certain binaries we want to restrict injection. The real problem is that DYLD_INSERT_LIBRARIES feature should not exist by default and should be instead a system setting disabled by default. Stefan’s SyScan presentation is a good read regarding the problems of default features and unfixed stuff in iOS (and OS X).

Proof of concept code:
Hello Santa Bye Santa – https://github.com/gdbinit/hello_santa_bye_santa

Last time I tested this was a month ago or something. Judging by the commits logs I guess the issue isn’t fixed so it should still work. This is technically a zero day ;-). I wanted to present it a SyScan’s WhiskeyCon but then decided not to, and now I’m disclosing it because the next post about rootpipe fix requires its disclosure :-(.

Enjoy,
fG!

P.S.: Defense is hard, in particular when working on a minefield such as OS X 😉

Update: This is a very nice blog post talking about white-list systems expectations. This is exactly what’s missing from most security products. Right after their features they should discuss their assumptions, shortcomings, and expected scenarios. You know, most of the times the expectations between who builds the product and who uses it are quite far away. Yes, it’s probably more wishful thinking than anything else. Commercial products will never do this, they are too afraid of losing customers ;-).

BadXNU, a rotten apple! – CodeBlue 2014, SyScan 2015 slides and source code

The last SyScan is almost here so it’s time to get again into a plane and travel to Singapore.
This means that the slides and source code can finally be released. Below you can find the archive with both presentations slides (they are slightly different, SyScan fixes/upgrades a few things) and full source code for both rootkit/kext loaders.

I hope you enjoy them; they are quite fun techniques, in particular the second one which now I sort of regret to disclose because it’s so cool.
I’ve also written a book chapter about both techniques (53 pages before editing) which add a few more tricks. I’m working on the book so hopefully it will finally come out this year.

The archive password will be released on the day of my presentation (27th March) so keep an eye on Twitter and SyScan website. If you crack it before that keep its contents private ;-).

If you are at SyScan feel free to have a chat. I’m there to meet new people and also learn.

Hope you enjoy,
fG!

Archive:
https://reverse.put.as/wp-content/uploads/2015/03/syscan_pack.rar
Dropbox Mirror:
https://www.dropbox.com/s/68j5nja80cxxova/syscan_pack.rar?dl=0

Update: The archive password is “syscan_rules_blackhat_sucks!”.
The final version presented at SyScan (really minor changes) can be download here.
The full source code is available at GitHub, diagnostic_service and diagnostic_service2.

https is now (finally) supported!

Hummm this is something that I should have done a long time ago but was always too lazy since there’s not highly critical information here (except some hashes and my PGP key/id).

Anyway, you can finally access the blog over https://reverse.put.as.
I still need to understand if there’s any impact on Google search stuff by moving it to https only.

Better late then never. Oh and fuck you David Cameron and your stupid populist ideas ;-).

Have fun,
fG!