[01:35.180 --> 01:38.820]  Make sure it's not just me who's seeing it weird.
[01:44.560 --> 01:47.100]  So now they should see the three of us.
[01:52.330 --> 01:54.290]  Oh yeah, I see us.
[01:54.650 --> 01:55.770]  You see us?
[01:55.910 --> 01:57.670]  Yeah, I just went to the Twitch stream.
[01:57.670 --> 01:59.510]  Oh, excellent. Which Twitch stream?
[02:02.190 --> 02:04.730]  I hear myself now, too.
[02:05.410 --> 02:10.050]  Okay, that's fantastic. We are a professional organization here on a Friday night.
[02:11.190 --> 02:14.950]  Yeah, we're going to call that one my fault. Okay, cool.
[02:16.310 --> 02:19.450]  Welcome to Q&A with Patrick Wardle.
[02:19.450 --> 02:26.330]  We are going to be talking about some macOS stuff and some stuff kind of adjacent to Microsoft Office.
[02:27.470 --> 02:31.970]  I am Jurist, and the other goon that you see here is Fallible.
[02:32.110 --> 02:35.770]  And we're going to be helping ask Patrick some questions this evening.
[02:35.770 --> 02:38.470]  And it's good to see you all in the chat.
[02:38.470 --> 02:43.290]  Patrick, why don't you take a minute to introduce yourself to everybody?
[02:43.290 --> 02:47.890]  Because I know that in your talk, you kind of dove right in into your content.
[02:47.890 --> 02:51.590]  So take a minute, say hello to everybody, tell us a little bit about yourself.
[02:52.210 --> 02:55.130]  Sure. Aloha, my name is Patrick Wardle.
[02:55.130 --> 02:58.630]  I am a principal security researcher at Jamf.
[02:58.630 --> 03:05.110]  I'm also the creator of the Mac security website and tool suite, Objective-C.
[03:05.110 --> 03:09.430]  I have been fortunate enough to talk at a few DEF CONs in the past.
[03:09.430 --> 03:13.610]  It's always one of my favorite events to talk nerdy at.
[03:13.970 --> 03:18.750]  This year, virtual, you know, a little bummed we didn't all get to hang out together in Vegas.
[03:18.750 --> 03:21.830]  But I think it's important that we're all staying safe and healthy.
[03:21.890 --> 03:26.010]  And actually connecting online is kind of super hacker-ish.
[03:26.010 --> 03:31.250]  So I'm stoked you're all here to chat a little bit more about my talk, open Q&A.
[03:31.390 --> 03:32.750]  Again, welcome.
[03:33.590 --> 03:36.890]  Well, thank you for being here. We really appreciate it.
[03:36.890 --> 03:41.610]  It's nice to get some folks who want to come present this way.
[03:41.750 --> 03:47.110]  So Sneakernet gave us what they're considering to be a softball question.
[03:47.110 --> 03:51.270]  Is SYLK the old file format you've come across?
[03:51.270 --> 03:57.810]  Is there a way to programmatically scan macOS apps for what kind of files they handle?
[03:57.810 --> 04:00.810]  Entitlements? Particular API usage?
[04:01.890 --> 04:03.870]  Yeah, so that's a great question.
[04:03.870 --> 04:09.650]  The first place I would look at is in something called the Launch Services Database.
[04:09.650 --> 04:14.130]  And you can enumerate this with the ls register command.
[04:14.130 --> 04:23.130]  And what it will basically do is it will dump all the file type and application associations on your macOS system.
[04:23.130 --> 04:27.690]  So for example, you can see what applications have registered for HTML files.
[04:27.690 --> 04:31.170]  What applications have registered to handle documents.
[04:31.190 --> 04:36.730]  In this case, what type of applications perhaps support these SYLK files.
[04:36.730 --> 04:41.050]  So that's kind of where I would start. It gives you a global overview of that.
[04:41.250 --> 04:44.910]  So if you just Google ls register, again, it's a macOS command.
[04:44.910 --> 04:48.310]  You run it with the dash dump flag and it will dump this database.
[04:48.490 --> 04:54.430]  You can also look at an application's info.plist file, which is something that all applications have.
[04:54.430 --> 04:59.770]  And in there, they can have a set, it's actually an array, a dictionary of key value pairs
[04:59.770 --> 05:06.750]  that kind of tell the operating system what type of applications, sorry, what kind of files they support.
[05:06.750 --> 05:10.170]  And this is actually how that database gets populated.
[05:10.290 --> 05:15.970]  So for example, Microsoft Office lists the doc files and file formats it supports.
[05:15.970 --> 05:21.250]  Obviously a browser will have a large list including HTML files, probably PDFs, etc.
[05:21.250 --> 05:26.010]  That's a great place to start because then you can see the file formats.
[05:26.010 --> 05:31.110]  And then I would look at the more esoteric or unrecognized ones and start fuzzing or playing with that.
[05:31.110 --> 05:36.790]  Because it's kind of mentioned in my talk, the reason that this vulnerability existed,
[05:36.790 --> 05:43.150]  specifically the automatic execution of macros, was that Microsoft actually has two separate code paths
[05:43.150 --> 05:46.690]  for handling macros based on these file types.
[05:46.690 --> 05:52.150]  Obviously the main one for documents, and then a whole separate archaic code path
[05:52.150 --> 05:55.530]  that probably no one ever looked at for these older file formats.
[05:55.530 --> 05:59.670]  Always a good idea to look for these more esoteric, ancient file formats
[05:59.670 --> 06:01.950]  because there's a lot of security bugs there.
[06:01.950 --> 06:06.490]  Because they were created in a time when security wasn't really a priority.
[06:07.450 --> 06:14.710]  Any time an afterthought gets pulled forward into what's happening now is probably an interesting space.
[06:14.710 --> 06:15.750]  Exactly.
[06:17.930 --> 06:21.870]  Cool. Next question coming in also from Sneakernet.
[06:21.930 --> 06:24.770]  Is there a way to programmatically scan Mac apps?
[06:24.770 --> 06:28.270]  Oh, we did that one already. Let's see here.
[06:28.270 --> 06:32.710]  Have you considered trying to do something similar to this kind of research with iPad OS
[06:33.330 --> 06:39.070]  or any other kind of non-Windows OS or mobile OS?
[06:40.070 --> 06:44.450]  That's a great question. I predominantly focus on Mac for two reasons.
[06:44.450 --> 06:50.330]  First, my personal opinion is it's really good to get really niche in whatever area that interests.
[06:50.330 --> 06:56.550]  That's just something that I've found to kind of have a lot of success in my InfoSec security career.
[06:56.850 --> 07:05.950]  The other fact, and yes, I will admit this, is hacking Mac is far simpler than hacking an iOS operating system or iPad OS.
[07:06.070 --> 07:10.010]  Largely, this is just because of how locked down that operating system is.
[07:10.010 --> 07:15.510]  So I think there has been some research done in the past based on custom URL handling,
[07:15.510 --> 07:22.510]  which is largely how applications and certain file formats are kind of connected in a way on iOS.
[07:22.790 --> 07:28.410]  But even if you found some interesting issues there, you would have to break out of the sandbox
[07:28.410 --> 07:35.490]  and then deal with a lot of the extra constraints that iOS and iPad OS kind of stack on top.
[07:35.490 --> 07:39.030]  That with Mac OS, you really don't have to worry about compulsion.
[07:39.030 --> 07:44.250]  We did have to find a new sandbox escape, but we showed that was pretty trivial to do.
[07:44.250 --> 07:46.030]  And there's been kind of history of that.
[07:46.170 --> 07:51.130]  So, you know, the TLDR, iOS is just really a hard target.
[07:51.510 --> 07:54.470]  So I'll probably just stick with Macs for now.
[07:54.730 --> 08:04.310]  So that's an interesting statement, though, that you found that getting really niche is the thing that helps you continue to find new interesting vulnerabilities.
[08:04.310 --> 08:07.730]  So you're keeping your target list really small.
[08:07.730 --> 08:10.130]  Can you talk about that any more?
[08:10.130 --> 08:15.250]  And what are some of the strengths that that's bringing you?
[08:15.250 --> 08:21.130]  And can you think of anything that you're missing that maybe if there was one more thing you wanted to add?
[08:22.190 --> 08:27.770]  Yeah, I know. And that's something that, you know, as I grow older and wiser, it's something that resonates really well with me.
[08:27.770 --> 08:36.310]  So, you know, a long time ago, I used to work at the NSA, National Security Agency, everyone's favorite U.S. government spy agency.
[08:36.310 --> 08:38.850]  And I remember when I got there, I was an intern.
[08:39.130 --> 08:45.970]  And the intern program, you kind of bounce around from different offices, kind of sampling different activities, let's say.
[08:46.010 --> 08:55.950]  And I remember thinking, I want to be good at all of this, like crypto and like mercenary malware, writing Windows exploits and hacking satellites, like all the really cool stuff the NSA does.
[08:56.430 --> 09:02.290]  And I got to a point where I was like, you know, it's just impossible to have depth in so much breadth.
[09:02.570 --> 09:05.750]  So I said, look, I'm going to kind of focus on one specific thing.
[09:06.350 --> 09:11.430]  And actually, it was only when I left the NSA was when I really started focusing on Macs.
[09:11.650 --> 09:17.910]  The reason for that was, at the NSA, I did predominantly Windows stuff.
[09:18.290 --> 09:25.130]  And so when I left, I wanted to still use my foundational skills of reverse engineering, vulnerability discovery, exploit development.
[09:25.130 --> 09:27.270]  But I didn't want to do it on the same platform.
[09:27.270 --> 09:31.550]  I was kind of poking around with the NSA, just it's good not to cross any lines.
[09:31.550 --> 09:33.470]  And, you know, you don't want to piss off the NSA.
[09:33.470 --> 09:35.470]  I said, hey, look, let me focus on Mac.
[09:35.690 --> 09:40.670]  I can use my same skill sets, but it's a separate platform, so I probably won't step on any of those.
[09:42.030 --> 09:45.630]  And moving forward with that, I really kind of doubled down on that.
[09:45.630 --> 09:49.490]  And it really allowed me to get a lot of depth in the topic.
[09:49.490 --> 10:01.310]  And I've noticed for, you know, finding new vulnerabilities, giving conference talks, right, at least for me, having that depth has really allowed me to become somewhat of an expert in the space, I would say.
[10:01.310 --> 10:09.990]  And allowed me to really dig more into maybe the more esoteric parts of the operating system where a lot of vulnerabilities lie.
[10:09.990 --> 10:18.110]  Whereas if I was trying to do that across maybe multiple operating systems and multiple platforms, it's just, I think, impossible to gain that much depth.
[10:18.110 --> 10:20.630]  So that's something that's just really worked for me.
[10:20.630 --> 10:30.030]  I would say the one downside is sometimes you might miss attacks that work on one platform that might have a conceptually similar vulnerability on that class.
[10:30.030 --> 10:34.150]  One great example I can think of is DLL or dynamic hijacking.
[10:34.150 --> 10:37.610]  This is a very common kind of attack scenario on Windows.
[10:37.890 --> 10:49.190]  And I, you know, when I was still kind of coming into the Mac space, I decided to see if macOS was vulnerable, at least conceptually, to the idea of hijacking dynamic libraries based on search path.
[10:49.190 --> 10:54.710]  And it turned out it was, and I just happened to be the first person that kind of dug into that and talked about it.
[10:54.710 --> 11:00.630]  So I still think it's good to keep your eyes and ears open and see what other research other people are doing.
[11:01.290 --> 11:05.870]  Just to be inspired and then kind of say, hey, is this something I can bring into my platform?
[11:06.350 --> 11:13.990]  But again, I've had a lot of success really focusing just on one platform, you know, macOS, not even iOS as much.
[11:14.030 --> 11:18.350]  So again, to me, that's worked really well, and I think it's a good nugget of advice.
[11:18.350 --> 11:26.770]  Yeah, thank you for talking about that a bit, because it's nice to hear somebody who's gotten a lot of success with a pattern like that,
[11:26.770 --> 11:31.930]  because there's many different patterns that I've been hearing about even this weekend.
[11:31.930 --> 11:35.030]  So it's nice to get that reinforcement.
[11:35.230 --> 11:38.510]  Yeah, I would agree with that, because I do a lot of digital forensics, right?
[11:38.590 --> 11:44.470]  And, you know, so I see a lot of Windows stuff come across, and I see a lot of iOS stuff, and it's kind of difficult to know,
[11:44.470 --> 11:50.310]  hey, you know, if I'm going to dedicate some time to build up some skills, you know, should it be broad-based, should it be targeted?
[11:50.310 --> 11:54.050]  And again, I'm digging what you're throwing down there.
[11:55.530 --> 12:01.670]  Next question. Okay, so you showed how putting a zip file into the login items,
[12:01.670 --> 12:06.270]  that in turn contains a plist with a launch agent, right?
[12:06.270 --> 12:11.470]  So does macOS really register launch agents on the creation of the file?
[12:11.470 --> 12:14.910]  In this case, creating it via an on-zip.
[12:17.110 --> 12:22.110]  Almost. So actually what it does is it automatically processes it on the next login.
[12:22.110 --> 12:27.450]  So it doesn't trigger it right away on creation, but on the next login,
[12:27.450 --> 12:33.630]  macOS will automatically just enumerate all the property lists that are created in the launch agent directory.
[12:33.630 --> 12:38.570]  It does the same thing with launch statements. And any property list it finds, it just runs it.
[12:38.570 --> 12:47.550]  So that's really kind of a neat thing that we were able to leverage as a mechanism to get this kind of code execution outside the sandbox.
[12:47.550 --> 12:53.470]  The only downside is you then have to kind of wait until the user re-logs in.
[12:53.470 --> 12:59.970]  But, you know, I like to say, you know, humans are impatient, but our exploits, our malware, you know, don't have to be, right?
[12:59.970 --> 13:10.050]  If we drop this launch agent and we have to wait two or three days, or even a week, until the user re-logs in, and then we get a callback, like, so be it, right?
[13:10.050 --> 13:12.770]  Generally we're not in that much of a rush.
[13:12.770 --> 13:20.610]  But it is interesting that macOS kind of automatically runs those, and something that we can, in this scenario, leverage to our own benefit.
[13:22.210 --> 13:25.110]  Sure. Follow-up from the same person that asked the question.
[13:25.110 --> 13:28.450]  Any plist it can find on the file system?
[13:29.870 --> 13:41.450]  No, it actually has to be in the launch agent directory, which is either in tilde user slash library launch agent or slash library slash launch agents.
[13:41.450 --> 13:44.690]  So macOS will look in those specific directories.
[13:44.690 --> 13:48.150]  It looks for other items in other directories.
[13:48.150 --> 13:53.890]  For example, there are other launch daemon directories, which it looks for other property lists.
[13:53.890 --> 13:57.830]  But again, those have to be in those specific directories.
[13:58.450 --> 14:04.350]  Cool. So, you know, a lot of this starts by you talking about macro attacks.
[14:04.350 --> 14:08.010]  And macro attacks have been popular on Windows for a long time.
[14:08.010 --> 14:17.350]  In fact, using macros inside of Office documents, I mean, you and I are roughly the same age, that's how you would get out of, like, the net nanny kind of stuff?
[14:17.350 --> 14:25.390]  Or you get around the stuff that they put on stuff at high school or middle school so you couldn't get on the internet, right?
[14:25.390 --> 14:26.370]  You know? Yeah.
[14:26.370 --> 14:29.150]  Sensual limitations is good? Well, it's fine now.
[14:30.290 --> 14:35.470]  So it is bananas to me that this stuff kind of persists now.
[14:35.830 --> 14:42.330]  Do you think that this is kind of a trend towards macro-based attacks towards macOS?
[14:42.330 --> 14:51.270]  Or is this just kind of a situation where, you know, the guys are, you know, if you've got a hammer in your hand, everything looks like a nail kind of a situation?
[14:52.410 --> 14:57.710]  Yeah, no, it's interesting because I think, well, we see two things happening.
[14:57.710 --> 14:59.490]  Maps are definitely becoming more prevalent.
[14:59.810 --> 15:05.130]  You know, we've seen this, especially in the consumer space, but now also in the enterprise space.
[15:05.130 --> 15:08.110]  And I think that's one of the reasons this is very anecdotal.
[15:08.110 --> 15:10.270]  I don't have necessarily data to back this up.
[15:10.270 --> 15:15.730]  But, you know, you go to a college campus even three or four or five years ago, everyone has Macs, right?
[15:15.890 --> 15:20.290]  And now those students have graduated or entered the workforce.
[15:20.370 --> 15:22.110]  What do they want? They want Mac computers.
[15:22.370 --> 15:23.490]  Understandably so, right?
[15:23.570 --> 15:28.110]  So we're kind of starting to see growth in the enterprise of Macs as well.
[15:28.110 --> 15:32.510]  Apple obviously also pushes for Macs in the enterprise.
[15:32.510 --> 15:35.210]  They have great hardware, great software.
[15:35.750 --> 15:38.830]  So hackers are obviously very opportunistic.
[15:38.830 --> 15:43.190]  So as they see an increase in targets, they're obviously going to start attacking them.
[15:43.190 --> 15:47.390]  So one of the things we see is we see hackers developing Mac-specific attacks.
[15:47.390 --> 15:51.750]  And we've seen this trend, I would say, in the last year or two, almost taking off.
[15:51.750 --> 16:07.330]  At the same time, in parallel, the other thing we see, and macros is a great example, is we see Windows-based attackers or Windows-based malware that have had success on the Windows platform kind of hoarding those techniques over.
[16:07.330 --> 16:14.790]  So obviously, as you mentioned, macros on Windows has a very illustrious history, a lot of success.
[16:14.790 --> 16:18.890]  So those same attacks can work on macros.
[16:18.890 --> 16:22.050]  So hackers are kind of like, hey, we know how these macros work.
[16:22.050 --> 16:24.610]  We have the infrastructure. We have experience.
[16:24.670 --> 16:27.290]  Why not target Mac users using this?
[16:27.290 --> 16:36.910]  So macros is probably the best example of traditionally Windows infection vector, let's say, being hoarded over or brought over to macros.
[16:36.910 --> 16:41.030]  I think in a direct response to Macs increasing in the enterprise.
[16:41.030 --> 16:44.630]  Because these macro-based attacks still require Microsoft products.
[16:44.630 --> 16:51.310]  And the average consumer is probably going to be using Apple's Office apps, which aren't susceptible to macro-based attacks.
[16:51.310 --> 17:01.390]  Whereas in the enterprise, I think that's where we see the uptick in the installation of these Microsoft products on Macs, thereby opening the door for these macro-based attacks.
[17:01.390 --> 17:13.490]  However, though, we also see, for example, adware that's been predominantly targeting Windows via Chrome on Windows or Edge or Internet Explorer.
[17:13.530 --> 17:15.190]  Same kind of idea, right?
[17:15.190 --> 17:21.430]  Hackers and malware writers have success on that and say, hey, we can port these to Mac pretty easily.
[17:21.430 --> 17:27.010]  It's kind of cross-platform, these techniques and these malicious extensions we create.
[17:27.010 --> 17:32.370]  So, you know, why don't we start targeting Mac users because they're growing in numbers.
[17:32.370 --> 17:42.990]  So we're definitely seeing more and more of these Windows, these kind of like old school or very well-known Windows-based infection vectors and attacks now kind of showing up targeting Macs specifically.
[17:42.990 --> 17:55.490]  And it's interesting because I think Mac users maybe are at more risk because, you know, it's like what Mac user thinks that they can get a macro virus on their Mac, like zero, right?
[17:55.490 --> 18:01.450]  Traditionally, Apple's marketing has kind of put out the message that Macs are immune.
[18:01.790 --> 18:04.250]  And so a lot of Mac users believe that.
[18:04.250 --> 18:10.530]  So whereas someone on a Windows computer might not open a Word document from a random email, a Mac user might.
[18:10.530 --> 18:20.210]  So hackers may be having a better success rate actually by targeting Mac users, you know, using these kind of well-known techniques that might not fly on Windows anymore.
[18:20.210 --> 18:28.470]  Or for that matter, not know that the office on the Mac can support some of that stuff that would be also running over on the Windows side, right?
[18:28.730 --> 18:34.410]  You know, I wouldn't expect a VPK macro to just go ahead and run okay. It's crazy town.
[18:35.310 --> 18:36.450]  We love it.
[18:38.110 --> 18:44.930]  There was a little bit of a follow up from JKBCKR who asked the plist question.
[18:44.930 --> 18:46.870]  I'll just pop this out here.
[18:46.870 --> 18:58.330]  Oh, I got it. The zip was placed into the library and extracted a folder called launch agents with the plist inside, which is the correct location for launch agents.
[18:58.870 --> 19:02.070]  Okay, so a quick follow up if that's okay.
[19:02.130 --> 19:05.990]  Does this only work if there was a no launch agents initially?
[19:05.990 --> 19:11.170]  Otherwise, archive utility would rename that launch agents to, right?
[19:11.310 --> 19:13.550]  Yes, and that's actually a really good point.
[19:13.550 --> 19:22.750]  So the reason this generally works is because on a default install of macOS, there's no launch agent directory under the user's directory.
[19:23.230 --> 19:26.450]  So there is one in the slash library directory.
[19:26.450 --> 19:29.250]  We couldn't write to that location from the sandbox.
[19:29.250 --> 19:32.590]  So what we could do, though, is we could write to the user's library directory, right?
[19:32.590 --> 19:40.850]  To the slash library, put a specially crafted zip file there, and then the archive utility would create the launch agent directory for us.
[19:40.850 --> 19:49.550]  Because, again, we could also not create or write a plist to that directory because Microsoft's patch specifically forbade that.
[19:49.550 --> 19:55.250]  So, yes, if that launch agent directory is already there, this specific attack venue would fail.
[19:55.250 --> 20:07.530]  What we could possibly do, though, is create files in other locations and perhaps create a .bashrc file or some other file that leads to code execution.
[20:07.530 --> 20:15.030]  Someone also mentioned perhaps you could do something with symlinks, so maybe make a zip file with symlinks.
[20:15.030 --> 20:16.850]  I haven't really dug into that.
[20:16.950 --> 20:26.670]  But I think the fact that we can, outside the sandbox, create kind of arbitrary files, the launch agent path was really just the first one I tried that worked.
[20:26.670 --> 20:35.870]  But there might be other venues that are more globally applicable that, for example, wouldn't fail if the launch agent directory was already there.
[20:35.870 --> 20:39.910]  So that's a really good question and an excellent point to make.
[20:42.150 --> 20:43.510]  Excellent. Okay.
[20:43.810 --> 20:47.690]  We'll step back for a second to Sneakernet has another question.
[20:47.690 --> 20:51.230]  Are there any Apple-specific protocols you found really interesting?
[20:51.230 --> 20:55.590]  Protocols can be either in a process in the same system or between devices.
[20:55.590 --> 20:59.330]  This is, for example, Sidecar between laptop and iPad.
[21:00.210 --> 21:10.410]  Yeah, so the IPC mechanisms in macOS are full of security vulnerabilities or have been in the past.
[21:10.490 --> 21:15.290]  So one great example is just the handling of these custom URL schemes.
[21:15.290 --> 21:23.330]  So it turns out that if an application supports a file format or supports a custom URL scheme,
[21:23.330 --> 21:27.750]  a custom URL scheme can be like blah, colon, slash, slash, anything.
[21:28.310 --> 21:29.790]  You know, HTTP would be one example.
[21:29.790 --> 21:36.270]  But applications can also create their own custom URL handlers as a kind of lightweight IPC mechanism.
[21:36.270 --> 21:37.910]  And this is used legitimately.
[21:38.550 --> 21:49.470]  If an application contains a custom URL handler, as soon as it hits the file system, macOS actually parses that application and registers it as a custom URL handler.
[21:49.470 --> 21:53.350]  A URL can then be launched from the browser.
[21:53.450 --> 22:02.690]  Luckily, recent versions of browsers now will alert the user, basically saying, hey, a web page is trying to make a custom URL request.
[22:02.690 --> 22:04.890]  But in the past, that was not the case.
[22:04.890 --> 22:11.710]  And we actually saw the Wingtail APT group abuse this technique to target Mac users specifically.
[22:11.730 --> 22:14.350]  So their exploit, you browse through a website.
[22:14.350 --> 22:18.890]  In the background, it would download an application that handled a custom URL scheme.
[22:18.890 --> 22:25.830]  macOS would automatically register that behind the scenes as soon as that application hit the file system.
[22:26.230 --> 22:32.150]  Their exploit code would then just make a URL request from the malicious website, which is totally legitimate.
[22:32.150 --> 22:33.230]  It's something you can do.
[22:33.930 --> 22:36.950]  macOS would look and say, hey, yeah, I have an application that can handle that.
[22:36.950 --> 22:42.730]  And then blindly and naively launch the malware, which had just been downloaded because it had this custom URL.
[22:42.730 --> 22:53.510]  So these custom URL schemes are kind of a Mac-specific protocol or an IPC mechanism where there are some interesting issues, especially in the past.
[22:53.670 --> 22:58.910]  I think my other favorite protocol or IPC mechanism is XPC.
[22:59.170 --> 23:02.970]  Ian Beer at Google has done some great work finding all sorts of vulnerabilities.
[23:03.270 --> 23:08.810]  Some other Google Project Zero, such as Brandon, researchers have found bugs as well.
[23:08.810 --> 23:14.050]  And basically, XPC is just a way where a client can talk to usually a privileged server.
[23:14.710 --> 23:21.010]  And so it's really good to kind of enumerate the API endpoints that the server has.
[23:21.010 --> 23:32.550]  And the biggest issue is usually it doesn't correctly validate the client, which means once you're on the system, you perhaps can talk to a trusted service and do all sorts of nasty things.
[23:32.550 --> 23:37.130]  It's often application-specific based on the XPC server.
[23:37.150 --> 23:39.810]  But Apple has had all sorts of issues here.
[23:39.810 --> 23:44.650]  So, for example, the well-known root pipe vulnerability was a great example.
[23:44.650 --> 23:48.710]  There was an XPC service running on macOS as root.
[23:48.830 --> 23:54.870]  And it would, I think, create random arbitrary files and run arbitrary commands as root.
[23:54.870 --> 23:56.650]  And it didn't validate the client.
[23:56.650 --> 24:03.650]  So as soon as you were on the box, you could just send this XPC protocol request to this XPC service that was running.
[24:03.650 --> 24:05.670]  And it would be like, yeah, I'll run whatever you say.
[24:05.670 --> 24:09.710]  And so it was like the easiest, best privileged escalation vulnerability.
[24:09.910 --> 24:13.610]  So XPC, great protocol, Apple-specific.
[24:13.890 --> 24:22.010]  I always look at what kind of servers and applications, if they have an XPC interface, and start auditing those because oftentimes there are security issues there.
[24:23.210 --> 24:25.690]  That's your big blinking red light, huh?
[24:25.690 --> 24:28.650]  Yeah, like poke on that hard.
[24:29.910 --> 24:33.170]  Okay, so we have found ourselves in the last five minutes on this.
[24:33.170 --> 24:37.670]  If we have any more really good questions you want to drop in here, then please do.
[24:37.670 --> 24:44.150]  In the meantime, this is when I've taken to asking people if they have a general call to action,
[24:44.150 --> 24:51.990]  something you would like us to take away from the presentation that you've done, something that you'd like us all to consider and move forward with.
[24:52.690 --> 25:03.390]  Yeah, I mean, I think, you know, this is probably obvious to anyone listening here, but a lot of Mac users think that Macs are infallible.
[25:03.390 --> 25:15.750]  And this actually puts themselves at risk because, you know, a lot of Windows users will maybe participate in best cyber-safe practices, whatever that means.
[25:15.750 --> 25:21.430]  You know, don't download random apps, click random links in emails, run random applications.
[25:21.430 --> 25:24.910]  Whereas on macOS, people are prone to do that a little more.
[25:24.930 --> 25:28.410]  So, you know, just realizing Macs are just as hackable as Windows.
[25:28.410 --> 25:33.750]  It's an operating system that runs code, so just kind of stick with that.
[25:33.790 --> 25:38.270]  The other thing, and this is kind of a self-plug, but it's for free content, so I don't feel bad.
[25:38.570 --> 25:45.330]  In my presentation, I announced the free macOS book series I'm working on.
[25:45.330 --> 25:54.950]  So if you go to taomm.org, theartofmacmalware.org, I'm working on a free book about Mac malware analysis.
[25:54.950 --> 26:00.610]  So it talks a lot about infection vectors, these property lists, this XPC stuff.
[26:00.610 --> 26:05.450]  So if you're interested in, you know, Mac malware, vulnerability research, check it out.
[26:05.450 --> 26:10.110]  It's all free. The content, I've published the first part of the first volume.
[26:10.110 --> 26:12.930]  It's actually commentable on.
[26:12.930 --> 26:17.070]  So, you know, if you see an error or you want some input, you can just add a little comment,
[26:17.070 --> 26:19.910]  and I will add that into the content.
[26:20.150 --> 26:21.470]  And again, it's a free resource.
[26:21.470 --> 26:25.710]  It's basically trying to help provide more information for the community
[26:25.710 --> 26:32.410]  so that we can combat kind of the rising tide of Mac malware that's definitely coming.
[26:32.930 --> 26:34.850]  Well, that's something I can look forward to as well.
[26:34.850 --> 26:35.370]  So thank you.
[26:35.370 --> 26:40.090]  If you would be so kind as to drop the URL for that in the track one,
[26:40.090 --> 26:45.890]  and if you are willing to do so with any other contact information for you or a Twitter profile
[26:45.890 --> 26:49.370]  or something you want people to follow, that would be a good place for that.
[26:49.750 --> 26:52.850]  Yeah, and I'll put my Twitter, my DMs are open.
[26:52.850 --> 26:54.530]  Obviously, I'm very passionate about this.
[26:54.530 --> 26:56.870]  I love to nerd out, talk about this.
[26:56.870 --> 27:00.630]  So any questions, shoot me a DM, and we'll chat.
[27:00.830 --> 27:03.590]  Excellent. Thank you.
[27:03.850 --> 27:09.210]  We've gotten to the end of the questions in the live Q&A chat.
[27:10.270 --> 27:13.450]  I think that you've been a fantastic guest here,
[27:13.450 --> 27:17.290]  and we really appreciate your willingness to come and build a presentation
[27:17.290 --> 27:20.250]  and then spend some time with us in the Q&A.
[27:20.990 --> 27:22.530]  Yeah, thank you.
[27:22.530 --> 27:24.610]  Like I said, it's always an honor to talk at DEF CON.
[27:24.610 --> 27:29.730]  I just feel super appreciative to be able to share my research with just the DEF CON community.
[27:29.730 --> 27:32.350]  I mean, they're just the best.
[27:33.010 --> 27:36.510]  Well, we're the best because of the people who decide to come out and do this stuff.
[27:36.510 --> 27:37.770]  So thank you all.
[27:39.130 --> 27:41.810]  It seems like that's about all we have.
[27:41.810 --> 27:47.730]  So anybody who wants to do any follow-up on this one, you'll have some contact information showing up.
[27:47.730 --> 27:50.850]  And thank you all for showing up, and we'll do more later.
[27:50.850 --> 27:53.250]  Cool. See you guys later. Thanks for coming.
[27:53.330 --> 27:54.070]  Aloha.