 All right Aloha and welcome to my talk on making and breaking Mac firewalls. My name is Patrick. I work at digital security where we are creating cyber security tools for the mac enterprise. I'm also the creator of the mac security website objective c So today Thank you. Thank you We're going to be talking about creating or making a mac firewall and then we're going to kind of shift gears And talk about breaking and bypassing such products So about a year ago, uh, I decided I wanted to write a firewall for mac os because there were no free open source options So in this section of the talk we'll describe this process Creating lulu, which is my free open source mac firewall Now there are many reasons you might want to create or install a firewall. They're actually pretty good security tools Probably the two main reasons are one to protect your privacy Or two to thwart cyber attacks because most firewalls are able to generically detect malware When the malware connects out perhaps to exfiltrate data or connect to a command and control server for tasking So what our firewall is going to do is monitor all network traffic allowing traffic out That's trusted and ideally blocking or prevented unauthorized or malicious traffic Now since we're going to need to monitor all traffic globally, we're going to have to write a kernel extension In mac os apple provides network kernel extensions or n ke's as a way to extend or modify the network infrastructure And one type of n ke is a socket filter, which as its name suggests Allows code to filter network traffic at the socket level which for a firewall is perfect. That's exactly what we need Now there are two steps to register a socket filter First we Populate a socket filter structure And the structure contains various callbacks that once registered will be automatically invoked by the operating system on certain socket operations Which then gives our firewall the ability to examine these socket actions and determine whether they should be allowed or walked So the second step is then to invoke the socket filter register function to install your socket filter Now besides the populated structure. This also takes a socket domain type n protocol Which means if you want to filter all socket domains types and protocols, you should invoke this method or function several times Okay, so now let's talk about these callbacks Which as i mentioned once your socket filter is registered will be automatically invoked by the operating system on socket events The first callback is the attached callback and as we can see on the slide It will be invoked anytime a new socket is created So it's created with a cookie parameter. That's designed to hold any socket specific information You can really put whatever you want there So what we do is we allocate a chunk of memory And based on the pit of the process that's creating the socket We either set it to allow for example, if it's a trusted system daemon or block if it's a process that That the user has chosen to block now if it's a process We don't recognize we set this action to ask and then we're going to have to do some extra logic to determine what action to take So next is the connect out callback. This is called before initiating an outgoing connection Again, it takes the same cookie which we've set to either allow block or ask And the socket and the remote address that the socket is trying to connect to so this obviously allows us to examine the endpoint Now if the action has been set to allow we just return okay This tells the operating system. We are okay with allowing this connection to continue If it's set to block we return an error code from this function Which tells the operating system. We want to block or not allow the connection And if it's set to ask we have to Execute some extra logic to determine what action to take So in other words, we have to figure out whether to allow or block the connection So what we do is we first put the thread to sleep that's trying to perform the socket operation. This will pause the action We then ask our user mode firewall component for assistance and we pass the information From the kernel specifically the pid and the socket via a shared queue Once the daemon gets this request from the kernel socket filter It maps the pid to a path and first checks a rules database to see if that path is in the database If it's not found perhaps it's a brand new application or a piece of malware that has somehow gotten onto your system What it does is it sends a message to another firewall component That's running in the user's session and this is what actually displays the firewall alert to the user Now the user's response they'll either have to click allow or block will then be passed back to the daemon The daemon will save this response to the rules database So moving forward it knows what to do and then also sends this response back to the kernel component via an iokit interface The kernel extension will then wake up the thread that was put to sleep and then apply the action either allowing the connection or blocking it So that's basically all that's needed to create a comprehensive firewall for mac os and putting this all together We have lulu as I mentioned lulu is a free firewall I don't think and users should have to pay for security products And also the full source for the firewall is online on github and as of today you can download and install version 1.0 Awesome. Thank you Very friendly audience today. I really like this All right, so defcon in my opinion is predominantly, you know a hacker conference about breaking things and exploits and vulnerabilities So let's kind of switch gears and talk about now breaking and bypassing such firewall products So imagine you're an attacker or a piece of malicious code that has somehow made it onto an end system Unfortunately, there's a firewall that's installed So if you are going to connect out perhaps the exfiltrate data or connect to a command and control server The firewall is going to detect and block this So your goal is simple. How can you connect out without the firewall blocking this data? So in this section, we'll first look at some firewall aware malware We'll then look at some security vulnerabilities in firewall products and then end with ways to completely bypass the firewalls So first it's definitely important for malware or an implant to detect if a firewall is installed on the box Otherwise it really might be there undoing as the firewall may detect a previously undetected malware when it tries to connect out And as we can see on the slide, this has happened Now i've yet to see any public mac malware that tries to specifically bypass mac firewalls But there are some specimens that are firewall aware And what i mean by that is they will enumerate installed processes or look specifically for firewalls And if they see an installed firewall, they will not persistently infect that system One example of this is devil robber and what devil robber does is it looked for little snitch Which is a popular mac firewall if that was installed. It would not infect the system It would just execute a benign instance of the application. It had infected and then simply exit Okay now on to some security issues Software such as firewalls often very complex and firewalls often run with elevated privileges or even in the kernel Now unfortunately, they're not as well written as the operating system nor have been audited as well Which makes them excellent excellent targets for local privilege vulnerabilities So i talked about this bug uh at defcon a while ago, but just briefly to go over It's kind of a neat kernel bug that affected the little snitch firewall kernel extension Basically the firewall extension took a 64 bit value from user mode and used that in an allocation and a copy routine Unfortunately the allocation routine expected a 32 bit value. So it truncate that However, the copy routine expected a full 64 bit value So it allowed us to have a controllable mismatch between the allocation and then the copy routine Which led to an exploitable heap overflow in the kernel allowing us to execute arbitrary code in ring zero Another issue i found while briefly looking at little snitch affected its installer and updater component In short, the firewall installer did not invalidate the components it was going to install So a local unprivileged attacker could modify these components And then the firewall installer or updater would naively install and execute them as root Again giving a local unprivileged attacker a very reliable way to elevate their privileges All right now on to bypassing firewalls We'll first look at some product specific bypasses But then we'll also look at some more powerful generic ones that can bypass all third party firewalls Again the goal here is network access without being blocked Now i do want to reiterate that in my opinion these bypasses are not security issues per se like they don't deserve a cve But however, they're still very valuable especially for an attacker or piece of malware, which may otherwise be thwarted by the firewall So first up we have radio silence. It's a popular firewall for mac os Kind of takes an interesting approach in that it allows any new process But the user can explicitly blacklist certain applications However, if we look at the blacklisting logic in the kernel extension We can see it looking for a name of a process and it appears if the process is named launch d It cannot be blacklisted nor blocked So let's test this we take some malware We name it launch d again the path doesn't matter just the name and then we manually create a rule to blacklist this process We then run it and as we can see on the slide It's still allowed out because again it is named launch d so kind of lame, but again fully bypasses this firewall Another popular mac firewall is named hands off and it turns out that we can pretty easily bypass this via a synthetic click So for example, if we execute curl, which is something that mac malware often does for example to download additional components As expected the firewall will detect this unauthorized activity and display an alert What the attacker or malware can then do is send a programmatic synthetic click to that allow button Which will click the allow button basically Hiding the alert and allowing the connection and it also turns out there are ways you can do this without the user noticing So there are ways that you can do this invisibly so that the user is not going to see the alert and the synthetic mouse click Next up we have lulu By default lulu trusts Apple binaries. Yeah, you know, I'm picking on everyone including my own tools. I you know, I think it's only fair So lulu by default trusts apple sign processes However, it gray lists certain apple binaries, which could potentially be abused for malicious activity So for example netcat and curl even those those are signed by apple It will still alert anytime anybody executes them So the question is can we find another signed apple utility that is not on the gray list? And the answer is yes, it turns out you can exfiltrate data via the who is utility. This was news to me So as we can see on the slide in the lulu debug log If we execute this the firewall will see the outgoing connection because again, it's global It sees all network traffic. However, because who is is signed by apple proper and is not on the gray list It will be allowed Now note this has been fixed. I've basically added who is to the gray list And finally we have little snitch little snitch is the de facto Most well known firewall for mac os Turns out it has an undeletable rule that says any process can talk to icloud.com domains or URLs This means any process even malware is allowed to talk to apple servers To test this we can manually create a deny rule for curl And then we can execute curl with an icloud url and it is still allowed So a while back I reverse engineered the icloud protocol and built a cnc server on iDrive for testing purposes Don't don't get mad at me apple It actually is a great like Dropbox like a cnc server because you can get alerts when files are uploaded. It's it's really great So once we understand the protocol what we can do is we can write some custom code that we can use to exfiltrate data Now even if little snitch is installed and sees the connection It will be allowed because the endpoint we are talking to matches or maps to an icloud domain Okay, so those were some product specific bypasses kind of neat kind of funny But in my opinion, they're still a little bit lame and they're lame because first an attacker would have to enumerate and determine the Specific firewall product that was installed and then have one of these product specific bypasses Way more powerful are generic bypasses which can just bypass any installed firewall And these are all possible because the firewall is essentially disadvantage It has to allow some network traffic off the box For example trusted system daemons or the user is probably going to fully allow certain things like browsers So the first thing we do to find a generic bypass is once we're on a system as a piece of malware or an attacker Is passively sniff to see what traffic is allowed off the box and we can do this via the lsof utility So if we execute this on this on a box even though I have my firewall installed Obviously, there's going to be some traffic that is allowed out So for example, we can see browsers chat applications some adobe licensing crap, etc, etc So now we know what traffic or what processes are allowed through the firewall So for the first generic bypass, we're going to indirectly exploit the trust of a process via a trusted protocol So on mac os anytime a dns request is made. This is handled by apple's m dns responder This means if a random application or piece of malware tries to resolve a domain The malware the application actually does not generate the network request It's sent locally to the system daemon which then on the application's behalf will resolve the domain So what malware can do is basically abuse this fact because yes, again The firewall is going to see this dns resolution But since it's just a dns request coming from the apple sign trusted dns daemon Which is handling all dns requests for the entire system the firewall is going to allow it So very easily we can build a bidirectional command control protocol purely based on dns Next up let's talk about abusing browsers The simple fact is if you have a browser installed, it's going to be able to access the network You know, even if you maybe say only port 80 and 443 You know, you're probably going to give it indiscriminate access to talk to any web server And again, we can passively determine this via lsof So the first way we can abuse browsers is via apple script So as we can see on the slide, we have kindly asked safari to invisibly browse to an attacker controlled URL and any data we want to exfiltrate we can put in as a get parameter Again, the firewall will see this connection. But as it's safari simply browsing to a url, it will not be locked Now an even better way to bypass any installed firewall is to abuse browsers command line interfaces Really doesn't get any easier than this all major browsers now support a command line interface So you can very easily programmatically execute them from a script piece of malware from the command line And again, the firewall will see this connection But it's just the browser browsing to some url. So it will not block it Yet another way to generically bypass all third party firewall products is to simply inject a library or code into An application or a binary that the firewall trusts again via lsof. We can determine passively what those are Now once this code this library is running in that trusted process from the firewall's point of view It will also be given that same level of trust and thus can access the network For example, if the browser is trusted and you inject code into the browser and that malicious code connects out The firewall will allow it because it just sees it's the browser Now there's many ways on mac os to inject into especially third party applications We don't have time to go into all of them, but i have listed them here on the slide The final way to bypass kernels involves uh or firewalls rather involves getting code into the kernel And the simple fact is if an attacker is able to get code running in the kernel It's completely game over for the firewalls First a lot of firewalls will generically allow traffic that is originated from the kernel And secondarily if malicious code is running in the kernel It can actually unregister or unhook any installed socket filter driver This will then transparently disable the firewall and then the attacker's code even from user mode can connect out without having to worry about the firewall Okay, so let's start wrapping this all up So today we talked about building a firewall for mac os We saw that using a socket filter kernel extension really not that complicated As i mentioned the source code for lulu is on github So if you're interested in more of the details and specifics i would recommend checking that out We then talked about breaking firewalls We showed that a lot of them actually have significant security flaws Which are very problematic because the firewalls often run with root privileges or even in the kernel And then we also showed that the unfortunate reality is these products are all trivial to generically bypass Now this doesn't mean we should uninstall our firewall products But i think it makes a good case for a defense in depth strategy For example, maybe some other host based security products that can perhaps block some of the prerequisites for these attacks For example, uh, preventing dilib injection or perhaps can detect that the browser is running from the command line when the user isn't active Like that's not something a firewall should detect per se, but perhaps another security tool should And finally today i'm really excited to announce a brand new mac security conference called objective by the sea We have a really cool lineup of mac security researchers It's also going to be at this awesome resort in hawaii And if you're a supporter of objective sea, which you can be for one dollar the conference to attend is completely free I just want to reiterate that it's in hawaii. This is the actual resort of where it's going to be November 3rd and 4th, uh, so i would love if you could all attend and uh for more information check out objectivebythesea.com Okay, that's a wrap. I really want to thank you all for attending Also want to thank the friends the partners of objective sea which are digital security and malware bites and we have 13 seconds for questions, but I will be around here after the talk to obviously answer any other questions