>Um this is Patrick Wardle, we've got 99 problems but a little snitch aint one. And I
will just let him take his talk away. [Applause] >> Aloha. So let's talk about owning little
snitch. As he mentioned my name is Patrick Wardle. I worked at a bunch of Acronymed places,
currently the director of R&D at Synack. So synack does crowdsourced vulnerability
discovery with vetted security researchers. So if you are interested in getting paid to
find bugs in our customers web apps, mobile apps, IOT devices and network endpoints then check
out synack.com. Alright we only have 20 minutes so we are gonna jam through a good amount of
stuff. We are gonna start by briefly talking about what little snitch is. We are then
gonna talk about how to bypass it, how to exfiltrate data or talk to a Command and control
server without being detected by the firewall. Then i'm gonna talk about reverse engineering
the kernel component looking for a security vulnerability and then talk about a bug that I
found. Now before attacking any technology it's good to have basic understanding, so let's
briefly talk about what little snitch is. So what is little snitch? Well little snitch is
basically a firewall. Basically its goal is to alert the user if its sees any unauthorized
traffic. So this couple be a piece of malware, connecting to a command and control centre or
an attacker trying to exfiltrate data. It has various components. There is a kernel driver or a
kernel extension that runs in ring 0, and we are going to be focusing mostly on this, because
this is where the security vulnerability I found lies. There's also some pieces that
run in user mode, so there is a daemon that runs in the root session that does some rules
managment, and then there is some interactive components that run in the user session. Most
notably there is a launch agent that is responsible for displaying the alert anytime the
firewall core detects unauthorized traffic. So it's gonna pop up telling the user
process x is trying to connect to IP address y, then the user can confirm or deny it. Alright
so little snitch is a firewall, so how can we bypass it. That is to say how can we exfiltrate
data without being detected or connect to a command and control server without generating any
popups which would alert the user to what we are doing. So the first thing is, let's look
at the little snitches' firewall rules. What is this, there is a default undeletable system rule
that says anyone can talk to Icloud. So what we can do is reverse engineer the iCloud
protocol, and its pretty basic, its JSON based. And once we understand the protocol what we
can do is set up a Command and control server on iCloud then we can write our custom code that's
trying to exfiltrate data or write some malware that connects to a Command and control server
that is then on iCloud. Now little snitch will see this traffic but since it conforms to
that rule, it won't generate an alert. So basically now we can exfiltrate data, talk to Command
and control server without alerting the user at all. Another way to bypass little
snitch is by abusing its process level trust. So little snitch in terms of granularity, assigns
trust at the process level. This means the process is allowed to talk to the internet,a ny code
or threads of dynamic libraries within that process, can talk to the internet as well. So this
means if we can find any way to inject malicious code into any of the processes that little
snitch trusts or allows to talk to the internet, we can connect out without the user being
alerted. So for example on my box gpg keychain is allowed to talk to the internet, which
makes sense. It does key management, checks for updates, stuff like that. Fortunately gpg
keychain is vulnerable to a dialling hijack attack. This means we can plant a malicious
dynamic library on the filesystem and then every time this application is started,
either by the user or programmatically by some malware in the background, the dynamic
library will be loaded automatically by the OS loader into context. Into the process
context of this trusted application. At that point we can then connect out to the
internet. Again little snitch will see this connection, but since it conforms to a rule it
will allow it without alerting the user. Finally another way to bypass little snitch is to
simply turn it off. So I reverse engineered what happens when the user clicks on stop network
filter. And basically what happens is the user mode component of the firewall
connects and authenticates to the kernel component and we will talk about how to do that in a
minute. But once it's connected and authenticated it simply invokes method B. Method B takes
a single parameter, a 0 to turn off the firewall, or a 1 to turn it on. So we can write our own
code to do this ourselves. So the best part about this bypass is, is it's invisible to the UI.
so if malware invokes method B with a 0 to turn off the firewall to exfiltrate data and
then connect to a command and control server. If the user looks at the status of the
firewall it will show that it is on. Alright so let's talk about how to reverse engineer little
snitch. Specifically its kernel extension. With the goal of finding a exploitable a kernel
vulnerability. Bypassing a firewall, bypassing any security product is you know pretty easy.
You target a certain anti-virus product you target a certain firewall you are going to be
able to get around it. Little snitch makes it really easy, but still they should not have
exploitable security bugs. Right these are security tools. So in my opinion that's kinda what we
want to find, because that a lot bigger of a problem. So little snitch kernel extension lives in
slash library slash extensions. its signed and its started automatically every time the
system starts. We look at its info dot plist file which has characteristics about it. We can
see it's a IOkit driver. So what is IOkit? IOkit is basically apple's device driver
environment. So it's a object oriented programming model that's implemented in a subset
of C++. And there is a lot of good resources on it, so I am not gonna spend a lot of time
talking about details, but on the slide we can see this is a skeleton hello world driver.
Basically you implement a bunch of C++ methods, you compile this, load it into the kernel,
and then the kernel proper will invoke these methods. SO we can see for example invokes you know
init, proc, start, and obviously you can put code in these methods to do whatever you want
your driver to do. Now in terms of reversing specifically looking for exploitable kernel
vulnerabilities I always like to see how and where user mode data is processed. The idea here is
if we can pass in user mode date code to the kernel mode driver and it processes it in a
vulnerable way we might be able to find a security vulnerability. So it's important
to understand what mechanisms IOkit provides to pass in user mode data that's processed by an
IOkit driver. So as the slide shows there's a variety of mechanisms, we are only going to
focus on sending control requests. Because this is what little snitch does and this is
also the mechanism where you pass larger structures that might have pointers, sizes,
interesting things that the kernel driver might not validate or use correctly. So first let's
kinda talk about a conceptual overview of how a user can invoke a method in the kernel
driver. So in this slide we see at the bottom there's a user or some user mode, and say it wants
invoke a method for example: method 1. How does it do this, well it makes a request to the
kernel with a selector. A selector is simply an integer and as we will see its an index.
So this request gets routed into the kernel and then the kernel proper will forward to the
correct IOKit driver. Specifically it will call that IOkit driver's external method
function. What the external method function does is use the selector that integer as an
index into array of function pointer. These are the methods that the driver exports or
exposed to user mode. So if we want to invoke method 1, we pass in 1. So once the external
method has extracted that function pointer, calls it the dispatch method, it invokes its
super class. The super class performs some basic validation, uhh and for example if method 1
picks a strucutre of size x, and makes sure the user also passed in a structure, and that
structure they passed in is of size x.Now it doenst validate whats in that strucutre and we
will see in a minute thats kinds of a problem. Now once that parameter validation is
successful, the super class then will directly invoke the dispatch method. So will then
actually invoke method 1. So here's an example of some user mode code of how to actually do
this. So there's basically 3 steps. Step one is you use find the driver you want to connect
to and you do this by the driver's name. You then connect to it to create connection
object and then finally you invoke the method. Um and there is a bunch of api how you invoke
the um kernel mode method. In this example we are passing in a structure so we call the IO
connect call structure method. This again gets routed into the kernel, the kernel will invoke
the external method of the driver, that will validate the parameters and the call the
function that the selector indicated. Okay so let's get back to little snitch and talk
about how to connect to its IOkit driver and then how to enumerate the methods and then
audit them. So if we reverse engineer the user mode components, specifically the
user mode daemon of little snitch we can see it connecting to the little snitch driver via
the string at_obdev_lsnke. So what we can do is write our own custom code that tries to
connect to that kernel extension as well. And when we compile and run that, low and behold we are
allowed to connect to the kernel extension. So what dispatch methods can we call, that is to
say what methods does the little snitch kernel driver export or expose that we can invoke from
user mode. So if we reverse engineer the external method of the little snitch IOkit driver,
we can see where it uses that selector. And in the disassembly you can see there is an array of
function pointers called s method that IDA pro has flagged. So we double click on that and
follow the cross reference we can see there are all the methods that we can invoke, you
just invoked. So there is 17 of them or so. So I started auditing these methods cause
again these are the methods we can reach from user mode. And when I got to method 7 I found
an interesting bug. So method 7 calls a bunch of helper functions and one of these
helper functions processes the data that gets passed in from user mode. So what method 7 is
trying to do is simply copy some bytes from user mode into kernel mode. So it takes a structure
that has a size of these bytes and then the user mode address of where to copy from. Now if
you look at the pseudo code it's probably easiest to see unless you prefer to read assembly. But
you can see it extracts the size out of the user mode structure, allocates a buffer, and then if
that allocation is successful it copies the data of that same size into the kernel. So you
might look at this and took me a while and I didn't really see that there was a problem and
this looked like normal valid code. Well the problem is size matters. Why? Well the
allocation function they use which is OS_malloc takes a 32 bit integer. Well the copy
function which is copy_in takes a 64 bit integer. So obviously if you pass in a 64 bit size,
which is what little snitch extracts from that structure it's gonna truncate that when it
allocates it. So for example if we pass in one with a bunch of zeros and a two, basically 64bit
value, it's actually gonna truncate that when it goes to allocate that. So in this case
it's going to only allocate a buffer of 2 bytes. Then when it goes to the copy, copy_in uses
the entire 64 bit value. There is no truncation that occurs. So obviously we get a massive heap
overflow, because it tries to copy some 2 to the 31 or 4 billion bytes into that. Alright
so can we exploit this bug? Well turns out first before the vulnerable there is actually a
check in the little snitch driver. And what the check does it checks some value which turns
out to be a authentication flag and if that is not set to 1 it fails, it does not even invoke
the buggy code. So we have to figure out how to set the flag so we can reach the buggy code.
So I reverse engineered the remaining piece or methods in the little snitch kernel driver
and I found out that method 8 is the code that sets this flag. Basically what methods 8 does is
it's expects a hash from user mode and then it computes a secondary hash itself and then
compares these hashes. If the hashes match it sets the flag to 1. So this is exactly how we can
pass in the correct hash so that those both match , so we can set the authentication flag. So we
connect to the little snitch driver, we invoke method 4, which passes back some 16 bytes
of random data, we then hash that with md5 and a hard coded salt. The hard coded salt is
embedded in the user mode components of the little snitch firewall. An then we invoke
method 8, again method 8's gonna recompute or compute the secondary hash, and since we
know how to generate that hash, it will now match and authenticate. So it's basically
kinda like security through obscurity for authentication purposes. Okay so we can now
authenticate, but can we trigger this bug? So I found this bug in 2013 and when I was stepping
through the code in a kernel debugger I saw yes they extracted a 64 bit value, passed
that to a allocation routine that truncated that down to 32bits, so for example it would
only allocate a buffer of 2 bytes or 3 bytes. But then when I stepped over the copy routine
it actually only also copied 3 or 4 bytes. So you know that was sad, right? Did Not actually
trigger the bug. So I looked into the copy_in routine to figure out what it was doing. Um
copy_in is a function written by Apple and under the hood it calls underscore bcopy. If you
look at the assembly for underscore bcopy, it's a handwritten assembly routine.
You can see although function definition says hey I take a vm size T, which is a 64 bit value
on 64bit systems, and even the comment says I am going to use rdx which is again a 64 bit
register. You look at the assembly code they actually only ECX register. So this means that
64 value that gets passed in, that size is also gonna get truncated. So unfortunately this
at the time wasn't really a bug. Well I did what any normal person did and I filed bug
report with apple. I basically said hey guys [Laughter] your bcopy routine is [clapping] is
buggy. And we all know how Apple is, they take their time. So I had to wait 2 and a half years
for them to fix this. That's why I am only talking about it now. So they fixed it which is good,
so if you look at bcopy now and look at the assembly, you can see they correctly use RDX or
the 64 bit registers. As the function definition says it should. So awesome. So we can
authenticate and we can trigger the bug. But it's still gonna try to copy some massive amount
of bytes into a small allocated buffer. Which is gonna trash the kernel and cause a kernel panic.
So basically we need to figured out a way to how exactly control the number of bytes, so we can
maybe overflow it by 6 or 7 bytes. You know we need a tactical solution here. So how
can we take this whole kernel copy. Well turns out that bcopy is actually fault tolerant,
which is a good thing, so bcopy again is copying data from user mode into kernel mode. So what
happens if it hits an unmapped page it handles this gracefully and stops copying. So we can
exploit this fact by passing in an address that's close to a page boundary of an unmapped
page. So we can map two pages in user mode, unmap the seconds page, and then pass in pointer
that say like 5 bytes before that unmapped page, and what's gonna happen is that copy
routine is going to try and copy 4 billion bytes in, but as soon as it hits that unmapped page
it's gonna stop. So that's perfect cause now we control the exact number of bytes that are
copied. So now we have all the components needed for an exploitable heap overflow. We
control the size of an allocation buffer in the kernel. We control the values of the
bytes copied, there is no constraints. We can put in 0s, nulls, whatever we want. And
most importantly we can copy the number of bytes that get copied into this buffer. So what we can
do to exploit this, is we can perform a heap spray, some heap feng shui, and basically get a
C++ object that we own to be immediately adjacent to this little snitch buffer. We can
then overflow the little snitch buffer into that C++ object and if you know how a C++ object is
laid out in memory, it has a vtable which is a pointer to all its function pointers. So we can
corrupt that or control that vtable. And once you control the vtable of an object you control,
if you can invoke methods on that, it will use the corrupted vtable. Which basically give you
RIP. So here is a screenshot of the kernel broken on instruction, it's a call
instruction uses RAX. I've blown it up a little bigger so you can see the values. But if we look
at what RAX is, its 41 41 41 41, so basically we control the instruction pointer in kernel
mode. Now firstly we dont have the time to talk to how to weaponize this exploit, but
there's been a great number of really awesome talks articulating exactly how to do
this if you have such a heap overflow. So they talk about how to groom the heap, how to get
these C++ objects, where you need to be, how to bypass kslr, [inaudible], smap, that kind of
stuff and some payload. Now one interesting weaponization technique you can maybe use with
this, is that even if the bug patched, this is still a valuable bug. So in modern
versions of OS 10, even if you have root access, you can't bypass system integrity
protection and you can't load unsigned code into the kernel. However this is a signed driver,
so as long as we have a buggy version of this driver, we can bring this to a target, load the
driver and then exploit the vulnerability. Once we exploited it, we have arbitrary code
execution in the context of ring 0, in the kernel. Now we can bypass system integrity
protection or even run unsigned code in the kernel. Alright so let's wrap this up. So what did
the vendor do, so the good news is they fixed the bug pretty quickly. So I said hey guys you
should probably just pull out the 32 bit value and pass that to both the allocation and the
copy function, then you don't really have to care about what it's doing under the hood. So
that's exactly how they patched it. Fortunately then they really down played the bug, so the
exact quote was they fixed a rare issue that could cause a kernel panic. This is bullshit.
It's not a rare issue, this was in all versions of little snitch. Its also not a kernel
panic. it's a exploitable security vulnerability. So I was a little urked, because I was
like come one guys you are a security company. You Are providing payed security tools,
if someone reports you a security bug, at least you know like lets your users know that
they should update. So you know that was a little of a bummer, but I think they've got better.
Alright um I'M assuming you guys are interested in Mac stuff, which is why you are here. So
I'm just briefly going to mention my personal Mac security website, I apologize for the
shameless plug. But everything is free, lot of opensource Mac security tools. There's a bunch
of modern Mac malware samples if you want to reverse engineer, the AV guys don't always like to
share. So I try to share. And also I blog about this stuff, so feel free to check it out, if
not, no worries. Alright so we have 54 seconds so there's time for one or two questions, i'll
hang around afterwards if any of you want to chat. So are there any questions about little
snitch kernel exploitation? Anything else? Anything Else? [applause] That one slide. Yes
[applause] Awesome well thanks again, feel free to shoot me email any time. Ummm I love
talking about all this stuff. Um and thank you again I really appreciate you attending my
talk. [applause]
Không có nhận xét nào:
Đăng nhận xét