All posts by fG!

London and Asia EFI monsters tour!

Finally back home from China and Japan tour, so it’s time to finally release the updated slides about EFI Monsters. After Secuinside I updated them a bit, fixing stuff I wasn’t happy with and adding some new content.

The updated version was first presented at 44CON London. I had serious reservations about going to the UK (not even in transit!) but Steve Lord and Adrian charm convinced me to give it a try. 44CON was great and it’s definitely a must attend European conference. It has the perfect size to meet people and share ideas. I prefer single track conferences, dual track is the max I’m interested in. More than that it’s just too big, too messy, too many choices to be made regarding what to see.

A big thanks to everyone at 44CON who made it possible!

Next was SyScan360 in Beijing. It was the fourth time it happened, and my third time in a row. I do like very much to go there because even with language barriers you can feel what’s happening there. Bought a bunch of (cheap) hardware gear made by 360 Unicorn team. Their “usb condom” is super cheap and super small. Also bought a network tap and a USB to serial (don’t really needed it but it was damn cheap). The SyScan360 badge as usual was super fun, this time with a micro Arduino, Bluetooth and LED modules. Conference went pretty smooth and had lots of fun. They had a gigantic LED panel where slides were displayed at. That was some gigantic TV they had there 🙂

Big thanks to everyone involved in SyScan360 2015.

Last stop, was CODE BLUE happening in my current favorite city outside Portugal, aka Tokyo. Third time happening, my second in a row. Organization is top notch, everything goes smoothly. Congrats to Kana, El Kentaro, Tessy, and everyone else involved.
This year it had two tracks, and a lot more attendees. It’s definitely a conference to put on your calendar. The audience is super interested in learning. Japan is lagging behind in terms of security so they are keen to finally catch up.

Some people approached me and shown some interested about (U)EFI security. This is great, that was the goal of this presentation, to show people (U)EFI research isn’t that hard and that it is really important its issues start to be fixed. We need to start building trustable foundations and not try to solve everything in software on top of platforms we can’t really trust.

Last conference for the year is No cON Name happening in Barcelona next December.

For next year I already got something that hopefully I’ll be able to present at SyScan360 Singapore. Their CFP is open and you should definitely think about submitting.

There were minor changes between 44CON and SyScan360/Code Blue slides. The latter included more references than 44CON version and minor fixes.

Have fun,
fG!

Slides:
44Con 2015 – Efi Monsters.pdf
SyScan360 2015 – Efi Monsters.pdf
CodeBlue 2015 – Efi Monsters.pdf

Rootfool – a small tool to dynamically disable and enable SIP in El Capitan

El Capitan is finally released and System Integrity Protection aka SIP aka rootless is finally a reality we must face. Let me briefly describe SIP (technical details maybe in another post, now that El Capitan is final and out of NDAs). This post by Rich Trouton contains a very good description of its userland implementation and configuration.

What is SIP anyway?

The description that I like to use is that SIP is a giant system-wide sandbox, that controls access to what Apple considers critical files and folders. One of the reasons for this is that most of kernel side SIP implementation exists into the Sandbox.kext, the same TrustedBSD kernel extensions that implements OS X sandbox mechanism.

For example, if we try to write to /System folder we get the following result:

sh-3.2# touch /System/test
touch: /System/test: Operation not permitted

And in system logs:

12/10/15 17:27:20,650 sandboxd[120]: ([424]) touch(424) System Policy: deny file-write-create /System/test

In practice it means that even with root access we are unable to modify those critical files and folders.
Continue reading

Writing Bad @$$ Lamware for OS X

The following is a guest post by noar (@noarfromspace), a long time friend.
It shows some simple attacks against BlockBlock, a software developed by Patrick Wardle that monitors OS X common persistence locations for potential malware. The other day noar was telling me about a few bypasses he had found so I invited him to write a guest post.
The title is obviously playing with one of Patrick’s presentations. I met Patrick at Shakacon last year and this is not an attempt to shame him (that is reserved mostly for Apple ;-)). It just illustrates the problems of building defensive tools and how much trust you put on them. By personal experience I can tell you that building a security product is a much harder task than what you might think initially.

Disclaimer: we both work for an endpoint software company. Together with another colleague I wrote an OS X version from scratch. I know very well the insane amount of problems that need to be solved, and they never end. When you build something you are always at mercy of potential security problems, we are no exception. Humans make mistakes. Offense is way easier ;-).

Anyway, enjoy it and hopefully learn something new!
Thank you noar!
fG!

I remember those days when there were only 3 or 4 security software editors for OS X. As the threat counts increased, the market grew up too. Many products are now selling you a feeling of being secure: most of them are post-mortem detection tools, and none is re-inventing the security paradigm.

This dinosaur fight left some room for an altruistic new hype: free – but not open source – security tools. Should we trust them blindly?

I am dedicating this post to HGDB, a former colleague and friend. Your sudden departure is leaving us in an infinite sadness. May you rest in peace.

BlockBlock

New utilities are emerging to free the user from major companies subscription fees, like the recently acquired Adware Medic or Objective-See tools KnockKnock and BlockBlock. So I had interest in reversing Patrick Wardle’s BlockBlock, a self-proclaimed continual runtime protection.
Continue reading

BSides Lisbon and SECUINSIDE 2015 presentations

I guess my goal for the remaining 2015 of not doing any presentations will not happen.
Two weeks ago I presented at BSides Lisbon 2015 and last week at SECUINSIDE 2015.

I’m very happy to see BSides Lisbon returning after the first edition in 2013. Congrats to Bruno, Tiago, and the rest of the team for making it happen. It’s still a small conference but I’m glad they are making it happen, and I will always do my best to help the Portuguese scene going forward. Everything went pretty well and met some new cool guys. I hope the conference returns in 2016 and keeps growing. Maybe someday it can mutate into something independent of BSides and on its own. Portugal is a great country for conferences, I’m just not the right person to start one, but I’ll definitely help my best anyone who wants to give it a shot.
The presentation is the same as CodeBlue and SyScan since the CFP happened a few months ago. Nothing new in the slides, a fix here and there.

The next was SECUINSIDE in Seoul. This is a very special conference to me because it was the first ever conference I presented at, back in 2012. I never had any plans to ever present at security conferences. I liked my low profile and this blog was good enough to spread the knowledge I wanted to. But I try to be flexible and always open to new adventures, so at the time I accepted HiTCON invitation (they were the first ones) and then SECUINSIDE’s invitation. SECUINSIDE was happening first so at the time I created a different presentation. It was a crazy trip because I did a Porto – Seoul roundtrip, and four days later I went to Taiwan. That was some crazy jetlag!
So this year I went back to SECUINSIDE. Thanks to beist, Ryan, trimo, and everyone else for the great time in Seoul.
The presentation is a new one, made in just a week. It’s essentially an introduction to EFI reverse engineering and hunting for EFI rootkits.

I received yesterday the good news that I was accepted to do the same presentation at 44Con. This is great and I will have enough time to improve the slides. Probably add some new content and tools, since there is good stuff expected out of Thunderstrike 2 presentation.

And here they are:

BSides Lisbon 2015 – BadXNU, A rotten apple!

SECUINSIDE 2015 – Is there an EFI monster inside your apple?

As usual, enjoy and have fun.
fG!

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 ;-).