 had some spare time at our hands in the last two years because most of travel and daily commute fell away. And some of us started sewing, cooking, baking bread, or doing other hobbies. And then there were people that spent their time slightly differently. One of them is our next speakers. So please give a, and to hear what he spends his last two years on, here's Tormeo with my journey to find vulnerabilities in MacOS. All right, thank you. And it's great to see that there's so many of you here in the tent enjoying the warm weather. And thank you all for coming and especially for you guys who are over here. And also thank you for all the who are watching the stream. First of all, it's great to be here. I've been going to all the camps since the 2011. And I really enjoy this, and it's great to be on the states in this day. But first of all, I want to give another big hand for all the organizers and angels and volunteers over here to making this great event to actually happen. All right, so today I'm going to walk you through some of my hoppy research, what I've done during the last two years. So my name is Mikko Kentela, also known as Tormeo. And I'm a founder and CEO of SensorFu. We built a cybersecurity solution to continuously monitor how well your network isolation is working. But this is nothing related to that in that sense. But this is more about my hobby stuff. So I've done some hobby research related to the Mac OS before. I found on critical vulnerability related to the Mac OS mile application before, which basically provided an attacker to access to change the mile application configuration via email. So only thing what you needed to do was to send an email to the victim and it will exploit the vulnerability and change the configuration in your mile application. You can see and find out all the details from my blog. And this is something what I've done before. But today I'm going to talk about a little bit different vulnerability chain and go through all the parts related to that chain. And just to make sure that you know what you have been coming to watch, I want to show the demonstration immediately at first so you can decide that if you want to see and learn all the details what's happening under the hood. So this is actually the same video what I sent to the Apple. So I just want to show you that this was the beta version of the picture back then and showing that the oops, let's try it again. So you can see that it's the Mac OS picture and it has all the security mechanisms enabled. So the zip protection is enabled. I will explain this later on what it means. And even in your terminal, if you try to read your desktop, you cannot do it because it's protected by other security mechanisms. So let's say the user is tricked to download something. In this case, it's a zip file. And now the zip file is downloaded and it will take a while. And that was the one click related that you need to allow the download to actually happen. And now when the user next time launches a terminal, something went wrong. And you can see that the machine is infected. And you can see that now the terminal was able to read all the files on the desktop and so on. So this basically was the chain of vulnerabilities related to the different security mechanisms. And I'm going to walk you through that what's happening under the hood. But first of all, a little bit background and how I normally find some vulnerabilities. I'm really into logic bugs. So I enjoy finding those the most. And because I find those also somewhat funny, because I'm just using some of the features which might be over there and maybe using those to be clever enough to cause some confusion from the security point of view. So I operate always with this method. I have over 10 years of experience of doing different type of technical security audits. And I've used this basically since the beginning. So at first, learn as much as possible from the target what you are testing or where you try to find out the vulnerabilities, read the documentation, but especially do the reverse engineering. Because many times you find hidden options or hidden services or hidden functions from the application what you are testing. And you get the different kind of point of view compared to maybe the developer who has actually done the software what you are testing. So that's really important, especially for me. And the goal is to know how exactly the system what you are testing is working. I use tools to trace the source codes. When I run the application, I run detrace or something like that to see that what's actually happening in the operating system to find out and learn what is actually going on under the hood. Try to find the anomaly. So if you have a user input somewhere, put something to that, try to cause some troubles, set, maybe add some extra characters, add some code, do whatever, try to cause some malfunction in the application. And that might be it. That might be the vulnerability. Test if you can manipulate it somehow, the operating system or the environment where the application is running, and then try to exploit it. Pretty straightforward, but might take some time to actually get it all done. So in Mac OS, if you want to achieve the code execution, and especially if you want to access all the data in the system, you need to circumvent plenty of different security mechanisms. So in this case, we need to exploit the initial vulnerability, evade the gatekeeper, evade the TCC. And I will go that through in more details later on, and evade the zip protection to access the TCC database. In nutshell, I could spend much more time with this, but the gatekeeper, in general, if you are running the Mac OS, you see the pop-ups, especially if you are downloading something from the internet and you want to run it, applications, and so on. You see some pop-ups which tries to prevent you to actually running it and make this gatekeeper also make sure that the software is signed correctly and so on from the known developer and so on. So it tries to prevent the execution of potential malice binaries or applications in your system. TCC, on the other hand, is the mechanism which is taking care of all your most valuable data in your system. It can be your camera in your Mac. It might be files and other data what you might have in your machine, calendar events, e-mails, and so on. So TCC controls that what application can actually access to some of the data. So it is providing the sandboxing and the controlling the access controls. Then there's SIP, System Integrity Protection, which is actually in kernel. It is protecting the most valuable files and the things related to the operating system. And it's providing extra layer of protection. So even if you are administrator or root in the system, you cannot change some of the files because this SIP kernel module is protecting that. OK. So hopefully you can remember some of that. So let's dive into the actual topic. The main thing related to this vulnerability chain, and this is how everything started, is related to the alias files in Mac OS. So when you saw the video and the user downloaded the ZIP file from the internet, basically that was the one-click part. So when the user hits the potential download link or when you go to the web page which provides the ZIP file, you will be prompted about that. Do you really want to download this file? And this was the one-click related to this vulnerability. What user need to do to actually be infected? So what's happening under the hood? When the ZIP file is downloaded, Safari will actually automatically uncompress the ZIP file. This is because Apple and Mac OS considers that ZIP files are so-called safe. So you can automatically, because that's the thing what you are most likely to do anyway when you download the ZIP files. So you will anyway uncompress it, and that's what it does automatically. So I was starting to think that maybe I can leverage this. And I was doing research before with the mile application, and that was also handling the ZIP file. So this was kind of sidetrack of that vulnerability when I was researching that how I could get some malices done with one click or with zero click. So this was one track of it. And this is basically how the application or the exploit chain starts. So the ZIP file actually includes an application, Mac OS application. And Mac OS applications are basically directories, including multiple files. There's a certain structure, but including the main executable over there. And in my case, that executable was an alias file. So what the heck is Mac OS alias files? So that was actually something a little bit different compared to the Linux and BSD links or Windows link files. So Mac OS has had an alias system since 91. So this is 31 years old feature in the Mac OS, which is still over there. And this is a little bit different compared to the other operating system. So basically, those alias files have extra features which can relate and point out to the files in your file system. And even if you move those to different places, the alias will still work. So it tracks wherever the original file is. But the good option or the cool thing about the alias files is that it can also point to the external resource. So for example, Samba mode or something like that. And that's exactly what is happening in the first phase. So when the application is downloaded, it includes the main executable, which is actually alias file, which is pointing to the external resource, which is the attacker Samba server. So when the alias file is automatically resolved by the LSD, which is one of the background processes in Mac OS, which is taking care of the things like if you want application which will be automatically launched when you boot your Mac, it checks out that kind of things. So your Mac OS will find out that, oh, you have a new application. LSD will go in, index those files, check specific files, like the main binary. It finds out that, oh, this is alias file. So it won't include any data. But since it's capable of triggering the mount, it will automatically trigger the Samba mode. And now attackers have a possibility to mount their own data to the victim's machine. Automatically. So what? Now attacker can trigger Samba mount, but what can you do with that? And that's a tricky question. So I tried to play around multiple things, tried to find out if I can maybe fool the user or find out automatic feature to launch Mali's binaries from that Samba mount. But there was many obstacles, like a gatekeeper, for example, because everything what I tried, gatekeeper was blocking those because it was an external source and so on. So what can I do? I figured out that maybe I tried to find out the way to actually mount the Samba mount to completely different path. And this is important to know that when you normally open any image or network share in your Mac, all the mounts will be done under these last volumes. And the naming goes so that after the volumes, you have a name for the mount. And that is taken from the last path from the URL, which is pointing to the Samba mount, for example. And that will be the name for the directory. However, I tried to do the most obvious things, tried to do dot, slash, and so on. But couldn't get anything like valuable from the hacking point of view to in place, actually. And none of the tricks what I tried actually worked, except there was one anomaly. So I was able to make the file naming logic to fail from the default one if I add a person 0, 0, which is null, at the end of the URL. So something weird happened. And instead of normal logic, the Samba mount was mounted in the way that you have a slash volume and fully qualified domain name of that Samba share. So something definitely went wrong. And I started to think about that. Can I leverage that somehow? And it turned out that I started to think that, well, it's a little bit restrictive to play around with the domains. But then I remembered that, well, you can do wildcard domain names, which basically points always to the same IP address. But you can set anything you like to the domain name. And that should work. So I started to play around a bit more. And this did the trick. I don't know if you can see it. Hopefully you can, but I will walk it through step by step. So first thing, break the default naming method to set the default mount path. So that's the number one thing, which is at the end of that URL, that person 0, 0. So now we are relying to the fully qualified domain name. So next one is to use double encoding for some reason, to fool some of the parsers. So if you'd used just a normal URL encoding, I guess those won't be, oh, some of the parsers didn't accept that. So I used double encoding to cause it to actually, and that way it will be encoded as an dot dot slash. And that was like a valid from the point of view of SambaMount. So that way I could do the same thing, do tests like dot dot slash private slash test. But then there was one problem, which is that you still have the rest of the domain name, which will be included to the path, the name of the path. So for that reason, you need to add another null character to actually terminate the string what you want to use in your path. And with that way, I was able to cause the arbitrary mount path for that SambaMount. So instead of having it mounted to this last volume, slash temp, it would be mounted slash volumes dot dot slash private slash temp slash test. So it's completely different directory then. OK, so now I have a possibility to mount SambaMounts automatically to any path what I want. But what to do next? Still no code execution. How I can leverage this to actually cause and code execution? And in history of exploitation in this part of the exploit chain, it shouldn't be too hard to actually achieve it if you are able to arbitrary mount some external files to any path you want. It shouldn't be too hard. However, it was quite hard, mainly because there was a couple of limitations. So a normal way to leverage this is to actually use some existing software in the system, so maybe do a mount to path which will include plugins or other features which will be automatically loaded. However, I had a huge, and this is actually part of the, I spent most of the time to figuring out this, even though it shouldn't be too hard, but it turned out to be quite hard, mainly because of the fact that the last speed pump over there that the mounting mount point directory need to be new in the system. So all the existing softwares which were in place were actually all the folders and the paths were actually already created. So I couldn't use those. I needed to find out a way to actually create a new directory which will be loaded. But even after that, there was the gatekeeper which was preventing me to get the code execution. However, there's always a way you just need to sit on your laptop or computer and figure it out. And in this phase, I ended up using the ZSH configuration file, which is ZSH is the default shell in your system if you are using the macOS. And it includes the configuration directory related to the keyboard layouts and so on, which will be included every time when the ZSH is initialized. So I went to that path. I mounted my Samba mount, including my special configuration file for the ZSH to the user's folder. And whenever the user will launch a terminal, that will be automatically included. And I have a code execution. So that was quite handy, although it took surprisingly long time to actually find out. And we need to remember that this is not vulnerability. This is just a feature. There's nothing to fix it. It's working as it should be this specific part. So this is not in that sense. This was the trivial obstacle turned out to be quite hard one to actually solve. So now we have a code execution also. But what to do next? I cannot access any personal files since the sandboxing is working as it should be. All the most important user files are still in the protections of the other security mechanisms. So what to do next? And the main target in this phase is the TCC. And the TCC was the one transparent consent and control. So the thing what you use whenever you are launching an application and allowing them to access to your camera or your specific files or so on. So this will block quite a lot of things. So we need to somehow circumvent the TCC to actually find it out. So TCC actually works so that every user has a TCC database in their own home directory and a library in there. The TCC database is actually just SQLite database. Nothing fancy with that, including all the configuration what you might do via graphical user interface. But it is also protected by the SIP. And the SIP is providing the protection to that database in a way that you should be only able to change the configuration from the graphical user interface what you saw beforehand on the previous slide. So that's the normal way to actually control that database. But since that includes heavily the user interaction, that was obviously a problem for me because I wanted to cause some automatic changes in the system and within the TCC database. So we need to find out the way to circumvent the SIP, which is protecting the TCC database. So the SIP is protecting specific file in the system and it's built in the kernel level so I needed to figure out how to solve that. So TCC database is used by the service called TCCD. And the TCCD process is owned by the user. So since I have already access to an arbitrary code in the system with the user permissions, I was thinking of that there has to be a way to actually manipulate the files. But because the SIP is protecting the TCC database, we needed to find out to do some trick to fool all the security measures around it. And turns out this did the trick. So no worries if you are not seeing it, I will walk you through that what's happening over there. So since in the beginning, first we kill the process, TCCD, to force it to load all the environments and all the everything related to that process again. And immediately after that, we mount a new directory to the protected path from the image. So we have an image which includes new database, the TCCD database, and we mount that image to that exact path where the files normally are and where the database are already. So when the TCCD process will start, it will automatically load the TCCD database from the specific path. But now that path, it includes actually our payload and our configuration will be loaded. So SIP is actually still protecting the original files in the file systems. But the trick is that we instead of using those exact files which are now protected by SIP, we actually fooled the TCCD process to load the my new files from the system. And I have to say this was completely lucky strike. This was first thing what I tried when I got this obstacle. So I was thinking of how can I fool this TCCD to actually load some my database, first thing what came to my mind was, let's try to mount something to that directory. Will it work? And it worked. And I was stunned that this was it, really. But it doesn't necessarily mean that it was poorly implemented, but I got the lucky strike because I was playing around previously with the mount. So obviously that was the first thing to come to my mind that what the heck, let's try that. And it worked. And I was like completely surprised that this was it. So success, the puzzle was solved. This was now attacker can use Mac OS alias files to cause one click network mount to arbitrary directory, which will lead the remote or arbitrary code execution with the user privileges. And since we can, after that, we combine that with the evasions related to the other security mechanisms, we can actually access all the users data and sensitive data in the Mac OS. So it turned out that this was, I started as fun, let's play around a bit. And something started to come up. I started to continue to play around a bit more and found the new things. But after the multiple steps, the puzzle was solved and also this would help the 100 million Mac OS users in the world. And we got it fixed in that way. So from the initial access, user will download the zip file. Zip file will be automatically extracted by Safari. LSD process will come in and automatically index the new files, which are over there. It will find out that there's alias, interesting alias file and will resolve that, which will cause the infection of the Mac OS. And now you have the malice mount in your system. And whenever the user launches the terminal, it will trigger the arbitrary code execution because it will load the configuration and immediately do the evasions for the security mechanics in the Mac OS and that way can access all the data in the user's environment and do whatever what the attacker wants with that data, uploading those to third-party servers or so on. So timeline. I actually found this bug in 2020 in the late over there and got the discussion going on with the Apple, reported about it and got the discussions going on with them. They had some troubles to reproduce the issue because it includes the Samba server and they couldn't get it like done in a way. How I was configured it, so I actually prepared the virtual machine for them to use it as a Samba server to actually make the full vulnerability chain to actually fix, or they test it and later on those were fixed in quite early phase. Then it took quite a long time and 2025, just in December, the report was qualified as an Apple security bounty. So it took something like a bit over one year to figure out that if it's eligible for the bounty. Just want to show you that this is how it looked like when they released the fixes and how it looks like in the chain's lock. So mounting malicious craft as Samba server network, network share may lead to arbitrary code execution and the back in the time, a couple of years ago, I think these chain's locks were actually not that exact as they are in the current currently and I'm really happy about that. The second vulnerability, it looks like this and it turned out that there was a bug collision related to this one. However, I did the, it seems so that I did the first one we discussed with the other researchers and it seems so that I found it first, but anyway, there was a multiple researchers doing research, especially the TCC and I guess we have another talk coming today about that also. So go and check that too. But there has been quite a lot of issues related to the TCC and quite heckload of vulnerabilities. So hopefully it's better in future. However, it includes the fundamental issue that you as an user, you have a permission to do the chainsies for that and at the same time it, so it means that you get infected. There might be multiple ways to actually exploit the TCC database. And it seems so at least so far. Let's see how the future will come. So it looks like that I was quite fast related to, compared to the timing what I was trying before. So at this moment, I want to thank you all and take Q&A and if you have some questions later on, I want to show you that we are, I'm from Finland, so we are in the Finnish village. You can find it right next to the sauna. So come and have a chat with me and let's discuss more about this and maybe have a sauna or salmiakki together with us. So thank you. Thank you very much Tumil. If you have any questions, please line up at the two microphones we have here in the middle of the room. Yes, I know it's hot and you have to move. Unfortunately, we can't bring the mics to you. Are there any questions in the audience? If there are, take your time to get to the microphone, just indicate that you're moving. Yes. Don't tap on the mic just close to the microphone and start talking, that should work. Can you hear me? Yes. I just had a simple question. Will the slides be available? Yes, those will be. All right, thanks. Okay, thanks for the great talk and awesome research. So my question maybe is because you have been looking at these things for quite a long time. So what have you been doing after 2020? Let's see, it might be that there will be more trackers. So let's see. But I do this as a hobby, so as you most likely all of your fellow hackers know, your attention goes to someplace, something new always. So there might be some time also, but let's see if there's more coming related to the Mac OS vulnerabilities. But in the meantime, I've been also doing other things. Sometimes even with the family doing something. So at this point I want to thank the family and to be patient with me when I was finding this because those were quite long days and they needed to be flexible also. So thank you. Hi, thanks for the talk. I actually have two questions. Yes, before you start, could you move closer to the mic? Yes, thank you. I can try. I feel like I'm heavy metal. I was quite surprised how simple in quotes this attack was. It was nothing like really what people might imagine what hacking is like. It's the simplest kinds of exploits that you can think of. Yeah, I agree. First question, how was your experience actually in communicating with Apple about this? How did they react? How were the reaction times and stuff like that? So I've reported multiple vulnerabilities for them. But let's say let's pick this email issue and this one. So the email issue was really straightforward because it was so easy to reproduce and it was clear for everybody that was going on. This was a bit more trickier. I get the quick, they replied quite quickly and thanked for it. They were able to reproduce it part of the issues. So that got also fixed quite early on. But I needed to poke around a bit that, hey, what's going on? If there is some issues or because I didn't hear about them from after quite a long time, two months or so. And then they asked that, OK, we have a hard time to reproduce this part related to the Samba mount. And I recorded the video for them and how it actually goes. And then tried to help them to do the Samba server but then figured out that, what the heck, I just do the virtual machine because that's the easiest way and that's the way everything will be in place. And after that, it went rather smoothly. Although, once again, after because there was no comments related to the background, I started to ask around that, hey, when you are able to check out if this is valid for the bug bounty or what's going to happen related to that. And I want to quickly comment since we have some time to the fact that these are rather trivial bugs. But actually, the original idea was that because I'm using Mac OS myself, I follow the security changes and follow what the other researchers are doing. And I started to think about that maybe there's some old things what we used to find out from the unique systems back in the 10 years ago. Maybe it seems that nobody is fighting those kinds of bugs. So let's see what's going on over there. Maybe there's a similar kind of issues because for me, it looks like the security community in general is working so that there's a Sauron's eye which is turning to some direction. Everybody is hacking the same things or at least most of them, not everybody obviously, but most of the persons are finding when there's a new interesting thing, everybody goes there and start to figure out that maybe there's some more vulnerability. So I started to think that I'm not that clever so maybe it's better that I look to other direction and find out if there's some leftovers from the 10 years ago to find out. And there was. And that's also which is a little bit concerning for me is how much there actually is eyes for this kind of logic bugs because it seems that there's a plenty of those on the field still to find out. So even though we have a great CTF over here, so every now and then when you feel that maybe we should do a CTF and participate in some of those competitions, maybe it is a good idea to try to find out vulnerabilities for Mac OS or any other operating systems because there's a similar issues what we have been seeing over last 20 years also in the unique system. So it might be worth to check out and there might be some low hanging fruits. OK, thank you. Quick second question. Since you exploited quite a chain of vulnerabilities, you just found one possible way to execute code by mounting your malicious folder to the ZSH folder. So this means on one hand, the victim has to open the terminal for us just to become effective. It also means that there might potentially be other parts that would automatically execute code without the user having to do anything. This is quite concerning, I think, even more. Yes, absolutely. And I was heavily considering to do more research on that to cause it like a trigger different way. But I decided that because this is not the part where the actual vulnerability is, it's kind of irrelevant because after all, the initial vector is the vulnerability and how I exploit the other security measures later on are those vulnerabilities. I decided that this is good enough for the proof of concept. There should be other options. I was able to do a couple of things also which were like something to maybe do research more in the future. But yeah, there's plenty of speed bumps and obstacles. So whatever worked for me in this case, because this is not the core part of the vulnerability. Thanks. Thanks. Any further questions? I think everyone wants to go for a swim. Well, if there are no further questions, I would like to ask you to give another very cool round of applause to Tormio. Thank you very much. Thank you.