Little Snitch was among the first software packages I tried to reverse and crack when I started using Macs. In the past I reported some weaknesses related to their licensing scheme but I never audited their kernel code since I am not a fan of I-O Kit reversing. The upcoming DEF CON presentation on Little Snitch re-sparked my curiosity last week and it was finally time to give the firewall a closer look.
Little Snitch version 3.6.2, released in January 2016, fixes a kernel heap overflow vulnerability despite not being mentioned in the release notes – just a “Fixed a rare issue that could cause a kernel panic”. (Hopefully Little Snitch’s developers will revise this policy and be more clear about the vulnerabilities they address, so users can better understand their threat posture.) Are there any more interesting security issues remaining in version 3.6.3 (current at the time of research) for us to find?
You are reading this because the answer is yes!
What is Little Snitch?
Little Snitch is an application firewall able to detect applications that try to connect to the Internet or other networks, and then prompt the user to decide if they want to allow or block those connection attempts. It is a super-useful addition to OS X because you directly observe and control the network traffic on your Mac, expected and unexpected.
It is widely popular: I personally make sure it’s the first thing I install when configuring new OS X images.
My original goal when I started poking around Apple’s EFI implementation was to find a way to reset a MacBook’s firmware password. My preliminary research found references to a “magical” SCBO file that could be loaded onto a USB flash drive and booted to remove the password. The normal process workflow is to first contact Apple support. Since I don’t have the original sales receipt of this specific Mac, I assume this option isn’t possible, since anyone with a stolen Mac could get the password reset. Things got more interesting when I found a website that allegedly sold the SCBO files – just send them the necessary hash (more on this later), pay USD100, and get a working SCBO file in return. There are videos (in Portuguese but you can watch the whole process) of people claiming this works, and even some claims about an universal SCBO that unlocks multiple Macs.
Since there was (stil holds true) virtually no information about the SCBO contents, this aroused my curiosity but I never followed up until now. Upon my return from SyScan360 Singapore, I needed a new research direction to kickstart my brain back into work, and this fit the bill.
The core question I wanted to answer was if it was really possible for someone to build a SCBO file key generator. If this were true, it would imply that Apple’s EFI contains a significant vulnerability. Understanding how SCBO files work in the first place was also intriguing. So let’s start another EFI reversing engineering adventure…
At the time I could only find a single SCBO file on the Internet, which is bad (impossible to visualise differences between files) but better than no file at all. The sample file can be downloaded here SCBO_original.zip.
This picture shows us the full contents of the sample file. The ‘SCBO’ string is clearly visible in the first four bytes, which is a magic number (0x4F424353). A couple of bytes later and we see another string. It appears to be some kind of serial number. This information can be verified because part of this string can be found in the motherboard of each Mac (my sample is only composed of MacBooks but I guess iMacs and others will contain the same information). The rest of the string and binary data that follows are unknown for now. The total file length is 324 bytes.
How are the SCBO files generated?
The exploit for the bug I presented last March at SyScan360 is today one year old so I decided to release it. I wasn’t sure if I should do it or not since it can be used in the wild but Google Project Zero also released a working version so it doesn’t really make a difference.
I’m also publishing here the final version of the slides that differ slightly from the version made available at the corporate blog.
You can find the slides here and the PoC code at GitHub.
The exploit code is slight different from Ian Beer exploit so you probably might want to give it a look. It’s a pretty clean and neat exploit :-).
You can find Ian Beer’s blog post about this bug here. Bug collisions are not fun, I expected this bug to be alive for a lot longer but Ian Beer is awesome, so hat tip to him.
The bug itself is super fun since it allows you to exploit any SUID binary or entitlements, meaning you can escale privileges to root and then bypass SIP and load unsigned kernel extensions with the same bug. Essentially, massive pwnage with a single bug. The only thing missing is remote code execution. Ohhhhh :-(.
Every OS X version except El Capitan 10.11.4 is vulnerable so if you are running older systems you should consider upgrading asap (they are also vulnerable to other unpatched bugs anyway!).
HackingTeam was deeply hacked in July 2015 and most of their data was spilled into public hands, including source code for all their sofware and also some 0day exploits. This was an epic hack that shown us their crap internal security but more important than that, their was of doing things and internal and external discussions, since using PGP was too much of an annoyance for these guys (Human biases are a royal pain in the ass, I know!). You can consult the email archives on this Wikileaks online and searchable archive. I had some love on those emails although they never sent that promised Playboy subscription (not interested anymore guys, they gave up on nudes!). For an epic presentation about their OS X RCS malware give a look at these slides.
Last Friday a new OS X RCS sample was sent to me (big thanks to @claud_xiao from Palo Alto Networks for the original discovery, and as usual to @noarfromspace for forwarding it to me). My expectations weren’t big since all the public samples were rather old and know we had their source code so if it were an old sample it was totally uninteresting to analyse. But contrary to my expectations there are some interesting details on this sample. So let’s start once more our reverse engineering journey…
Two days ago El Capitan 10.11.3 was released together with security updates for Yosemite and Mavericks. The bulletin available here describes nine security issues, most of them related to kernel or IOKit drivers. The last security issue is about a memory corruption issue on syslog that could lead to arbitratry code execution with root privileges. I was quite curious about this bug mostly because it involved syslogd, a logging daemon.
This post is about reversing the vulnerability and finding how it could be exploited. Unfortunately for us Apple is very terse on its security updates – for example they say nothing about if it is exploitable on default OS X installations or requires particular conditions. As we will see later on, this bug is not exploitable on default OS X installations.
While Apple makes available the source code for many components used in OS X, most of the time there is a significant delay so we need to use binary diffing to find out the differences between the vulnerable and updated binary. The usual tool for this purpose is BinDiff but there is also a free alternative called Diaphora made by Joxean Koret. Both tools require IDA and on this post we are going to use Diaphora. For this purpose we will need a copy of the vulnerable and patched binaries. The easiest way is to copy the syslogd binary (found at /usr/sbin/syslogd) before the updates are installed (usually it’s a good idea to have virtual machines snapshots for each version) and then after (or just extract the new binary from the update packages – El Capitan, Yosemite, Mavericks). This post will focus on Yosemite binaries.
Last month Patrick Wardle presented “Exposing Gatekeeper” at VB2015 Prague.
The core of the presentation deals with Gatekeeper bypasses originating in the fact that Gatekeeper only verifies the code signatures of the main binary and not of any linked libraries/frameworks/bundles.
This means it is possible to run unsigned code using dynamic library hijacking techniques also presented by Patrick in code that should be protected by Gatekeeper. His exploit uses an Apple code signed application that is vulnerable to dylib hijacking and his modified to run unsigned code when downloaded from the Internet. In this scenario Gatekeeper enters into action and should verify if the download is code signed (assuming the default OS X scenario where it is enabled). But in this case Gatekeeper will fail to verify the linked code and effectively is bypassed.
The core of the problem is that Gatekeeper only deals with the main binary code, and never verifies any linked code. This is obviously a flaw and hopefully a fix by Apple should be out sooner or later. Meanwhile we can try to build ourselves a fix using the TrustedBSD framework. For this I created Gatekeerper, a proof of concept kernel extension for Yosemite 10.10.5 (can be easily adapted to work with El Capitan, but I don’t want to release that code).