WEBVTT 1 00:00:00.040 --> 00:00:02.720 Welcome back. Everybody ready for another deep dive? 2 00:00:03.200 --> 00:00:04.440 Always awesome. 3 00:00:04.919 --> 00:00:09.599 Today we're taking a look at the security of MACOSX. Specifically, 4 00:00:09.679 --> 00:00:12.400 we'll be looking at the mac Hacker's Handbook to see 5 00:00:12.400 --> 00:00:14.599 what it can teach us. I feel like this is 6 00:00:14.640 --> 00:00:16.280 something a lot of us want to know, right, Like, 7 00:00:16.640 --> 00:00:19.320 beyond all the marketing, how secure are Max? 8 00:00:19.519 --> 00:00:20.399 Yeah? Great question. 9 00:00:20.839 --> 00:00:23.000 So what's interesting about this book is it doesn't just 10 00:00:23.160 --> 00:00:25.960 talk about the theory of MAX security. It actually goes 11 00:00:26.000 --> 00:00:28.519 deep into the nuts and bolts of how things work 12 00:00:28.600 --> 00:00:30.120 and how those things can be exploited. 13 00:00:30.280 --> 00:00:30.960 Yeah, exactly. 14 00:00:31.039 --> 00:00:33.359 Like one of the things the book explores is how 15 00:00:33.399 --> 00:00:36.759 something as simple as Monjeur can actually be a security risk. 16 00:00:36.920 --> 00:00:39.520 Okay, so for those of us who aren't network gurus, 17 00:00:39.759 --> 00:00:41.359 remind us what is manjeour again? 18 00:00:41.479 --> 00:00:45.039 So Bonjeour it's all about making networking easy. Like you 19 00:00:45.079 --> 00:00:47.399 know how you can easily find printers and other devices 20 00:00:47.399 --> 00:00:49.880 on your network without having to mess around with IP addresses, Right, 21 00:00:50.000 --> 00:00:53.719 that's Bonjeour at work. It uses a technology called mDNS, 22 00:00:54.039 --> 00:00:58.039 which basically lets devices and services announce themselves on the network, 23 00:00:58.479 --> 00:01:00.479 no need for like a central directory anything. 24 00:01:00.600 --> 00:01:03.439 Oh, I see, super convenient. But you're saying it's not 25 00:01:03.520 --> 00:01:04.200 so secure. 26 00:01:04.480 --> 00:01:07.239 Well, that convenience can be a double edged sword. The 27 00:01:07.239 --> 00:01:10.239 book actually shows you how to exploit that no central 28 00:01:10.239 --> 00:01:13.280 directory thing to spoof service advertisements, so. 29 00:01:13.359 --> 00:01:15.959 Like you could create a fake printer on the network 30 00:01:15.959 --> 00:01:16.719 that's actually a. 31 00:01:16.680 --> 00:01:19.519 Trap exactly, and the book walks you through how to 32 00:01:19.519 --> 00:01:22.680 do it using a command line tool called DNS dash 33 00:01:22.879 --> 00:01:25.079 SD which comes built into MACOSX. 34 00:01:25.480 --> 00:01:28.560 WHOA, Okay, that's a little unsettling. So if Bonjeur is 35 00:01:28.680 --> 00:01:32.239 just blindly trusting whatever is advertised, is there any way 36 00:01:32.280 --> 00:01:33.200 to use it safely? 37 00:01:33.560 --> 00:01:36.760 That's the question, right, And the book delves into the 38 00:01:36.760 --> 00:01:40.599 source code of the background process mDNS responder to try 39 00:01:40.640 --> 00:01:43.280 and figure out how secure it really is. It's pretty 40 00:01:43.319 --> 00:01:45.760 interesting actually because they're able to do this because some 41 00:01:45.799 --> 00:01:49.079 parts of macosx are actually built on open source software. 42 00:01:49.239 --> 00:01:51.079 So anyone can just go and look at that code. 43 00:01:51.159 --> 00:01:54.280 Yep, anyone can study how those core parts work, which 44 00:01:54.319 --> 00:01:57.239 is useful for analyzing security. But it's also interesting because 45 00:01:57.359 --> 00:02:00.000 MACOSX also uses a lot of closed source components. 46 00:02:00.239 --> 00:02:02.840 Oh so it's like a mix of open and closed. 47 00:02:02.719 --> 00:02:06.319 Exactly, and that can actually make assessing security a lot 48 00:02:06.359 --> 00:02:09.439 more complicated because you only have the full picture for 49 00:02:09.520 --> 00:02:10.919 some parts of this system. 50 00:02:10.719 --> 00:02:13.400 Right, I see? So, Like take Safari for example, it 51 00:02:13.520 --> 00:02:17.400 uses the open source WebKit engine for rendering web pages. Yeah, 52 00:02:17.439 --> 00:02:20.319 but Safari itself is closed source. Right, so you can 53 00:02:20.360 --> 00:02:23.800 look at the code for WebKit, but not Safari itself exactly. 54 00:02:24.159 --> 00:02:26.879 And that distinction actually plays out in some interesting ways 55 00:02:26.919 --> 00:02:30.759 when you compare Apple software on MACOSX to their software 56 00:02:30.759 --> 00:02:34.120 on Windows. Oh how so well, the book points out 57 00:02:34.120 --> 00:02:37.080 that Apple software on Windows, like iTunes, doesn't have the 58 00:02:37.080 --> 00:02:40.840 same security features as the Mac versions, like sandboxing for example. 59 00:02:41.000 --> 00:02:44.000 Really so does that mean using iTunes on Windows is 60 00:02:44.159 --> 00:02:44.879 less secure? 61 00:02:45.360 --> 00:02:47.199 It's a question, the book raises. It's one of those 62 00:02:47.199 --> 00:02:49.840 things people often don't think about. Security isn't just about 63 00:02:49.879 --> 00:02:52.960 the software itself, It's also about the environment it's running in. 64 00:02:53.120 --> 00:02:56.120 Yeah that makes sense. Okay, So we've got this mix 65 00:02:56.240 --> 00:03:00.000 of open and closed source components, and the attacks are 66 00:03:00.319 --> 00:03:03.080 can vary depending on where the software is running. It 67 00:03:03.120 --> 00:03:05.599 sounds like hackers have a lot of potential angles to 68 00:03:05.639 --> 00:03:09.439 work with. But how do they even find these vulnerabilities 69 00:03:09.439 --> 00:03:10.240 in the first place. 70 00:03:10.680 --> 00:03:13.759 That's another thing the Mac Hacker's Handbook goes into. It 71 00:03:13.800 --> 00:03:17.599 covers both static and dynamic analysis for finding security bugs. 72 00:03:17.639 --> 00:03:20.159 And what's the difference, Like, what's static analysis? 73 00:03:20.199 --> 00:03:22.599 Static analysis is kind of like looking at the blueprints 74 00:03:22.599 --> 00:03:25.199 of a building. You're going through the code itself looking 75 00:03:25.199 --> 00:03:28.039 for any patterns or flaws that might indicate a vulnerability. 76 00:03:28.520 --> 00:03:31.039 I see. And what about dynamic analysis? 77 00:03:31.080 --> 00:03:33.639 That's more about observing the software in action, seeing how 78 00:03:33.639 --> 00:03:36.879 it behaves under different conditions. You're essentially looking for any 79 00:03:37.199 --> 00:03:40.719 unexpected or suspicious behavior that might point to a problem. 80 00:03:40.800 --> 00:03:43.039 So it's a combination of reading the code and actually 81 00:03:43.120 --> 00:03:44.000 testing the system. 82 00:03:44.159 --> 00:03:47.479 Yeah, exactly. The book gives you real examples of how 83 00:03:47.520 --> 00:03:50.560 both approaches are used. One thing I found interesting is 84 00:03:50.560 --> 00:03:53.520 that Leopard, which is an older version of Maco as X, 85 00:03:54.120 --> 00:03:56.000 doesn't use something called the xd bit. 86 00:03:56.319 --> 00:03:58.159 Okay, I'm going to need a refresher on that one. 87 00:03:58.240 --> 00:03:59.479 What's the xd bit again? 88 00:03:59.639 --> 00:04:03.199 The x st bit stands for execute disabled bit. It's 89 00:04:03.240 --> 00:04:06.120 a hardware feature that stops code from running in certain 90 00:04:06.159 --> 00:04:10.039 memory regions, like where data is stored. It's a common 91 00:04:10.080 --> 00:04:13.520 security feature in modern operating systems, but it's not used 92 00:04:13.520 --> 00:04:16.560 in Lembard. Why does that matter? It means that certain 93 00:04:16.600 --> 00:04:21.680 types of exploits, particularly ones that involve injecting malicious code 94 00:04:22.000 --> 00:04:24.759 into data segments can be much easier to pull off. 95 00:04:24.920 --> 00:04:27.399 Wow, so even small details like that can have a 96 00:04:27.399 --> 00:04:30.680 big impact on security. But I'm guessing the book doesn't 97 00:04:30.680 --> 00:04:33.759 just talk about finding vulnerabilities. It probably also explains how 98 00:04:33.759 --> 00:04:34.920 they're actually exploited. 99 00:04:35.000 --> 00:04:35.319 Right. Oh. 100 00:04:35.360 --> 00:04:35.800 Absolutely. 101 00:04:35.879 --> 00:04:38.120 The book covers a bunch of different exploit types, but 102 00:04:38.199 --> 00:04:41.319 two that are particularly common are stack buffer overflows and 103 00:04:41.439 --> 00:04:46.279 heat manipulation. These techniques involve overflowing memory in specific ways 104 00:04:46.839 --> 00:04:49.439 to basically hijack the program's execution flow. 105 00:04:49.600 --> 00:04:52.879 Okay, I'm going to need a simpler explanation for that one. 106 00:04:52.759 --> 00:04:56.160 Sure, So imagine a stack of plates. Each plate represents 107 00:04:56.160 --> 00:04:58.279 a piece of data, and the top plate is where 108 00:04:58.319 --> 00:05:02.000 the program is currently working. A stack buffer overflow is 109 00:05:02.040 --> 00:05:04.199 like piling too much food on the top plate so 110 00:05:04.279 --> 00:05:05.480 it spills over onto. 111 00:05:05.240 --> 00:05:05.920 The plates below. 112 00:05:06.040 --> 00:05:07.519 Okay, I can picture that. 113 00:05:07.480 --> 00:05:10.920 And in this case, the spilled food is malicious code. 114 00:05:11.040 --> 00:05:14.199 The attacker crafts their input to overflow the space on 115 00:05:14.240 --> 00:05:18.279 the stack, overwriting critical data that controls how the program runs. 116 00:05:18.439 --> 00:05:21.120 So it's like replacing the chef's instructions with their own 117 00:05:21.199 --> 00:05:22.720 recipe for disaster. 118 00:05:22.560 --> 00:05:25.720 Exactly, And the book shows you techniques for crafting these 119 00:05:25.759 --> 00:05:30.439 malicious inputs, even techniques for bypassing security features like stack cookies, 120 00:05:30.600 --> 00:05:32.519 which are designed to prevent this kind of attack. 121 00:05:32.639 --> 00:05:34.920 Stack cookies is that like those little umbrellas you get 122 00:05:34.959 --> 00:05:35.800 in fancy drinks. 123 00:05:36.040 --> 00:05:39.319 Not quite, haha. Think of stack cookies as a canary 124 00:05:39.360 --> 00:05:41.920 in a coal mine. They're is special value placed on 125 00:05:41.959 --> 00:05:45.839 the stack. If they get overwritten during a buffer overflow, 126 00:05:46.120 --> 00:05:49.199 the program knows something is wrong and can shut down 127 00:05:49.240 --> 00:05:50.800 before the exploit takes hold. 128 00:05:50.800 --> 00:05:53.360 So attackers have to get creative to get around them. 129 00:05:53.439 --> 00:05:57.680 What about heat maipulation? Is that similar to a stack buffer. 130 00:05:57.360 --> 00:06:01.439 Overflow, it also involves overflowing memory, but the target is 131 00:06:01.480 --> 00:06:04.560 a different part of memory called the heap. The heap 132 00:06:04.600 --> 00:06:07.399 is like a big storage area where programs can request 133 00:06:07.920 --> 00:06:09.519 chunks of memory as they need them. 134 00:06:09.680 --> 00:06:12.600 So it's less organized than the stack exactly, and. 135 00:06:12.560 --> 00:06:14.279 That makes it a little trickier to work with. But 136 00:06:14.480 --> 00:06:18.600 the Mac Hacker's Handbook goes deep into how Leopard's heat manager, 137 00:06:18.839 --> 00:06:21.920 called the zone Allocator works and shows you how to 138 00:06:21.959 --> 00:06:25.800 manipulate it. Sounds complicated, it definitely can be, but the 139 00:06:25.800 --> 00:06:29.199 book actually breaks down how the JavaScript engine and WebKit 140 00:06:29.600 --> 00:06:32.160 can be used to very precisely control the layout of 141 00:06:32.160 --> 00:06:34.920 the heap, which makes this technique even more powerful. 142 00:06:35.360 --> 00:06:38.600 So even something as innocent as JavaScript can be turned 143 00:06:38.600 --> 00:06:39.279 into a weapon. 144 00:06:39.600 --> 00:06:42.680 It can, Unfortunately, let's face it, all this theoretical stuff 145 00:06:42.720 --> 00:06:45.759 is interesting, but seeing how these vulnerabilities play out in 146 00:06:45.800 --> 00:06:48.600 the real world is what really drives it home. Does 147 00:06:48.639 --> 00:06:50.639 the book cover any real world examples? 148 00:06:51.160 --> 00:06:51.639 It does. 149 00:06:52.160 --> 00:06:55.759 One of the examples it analyzes is the QuickTime RTSP 150 00:06:55.959 --> 00:06:57.519 content type header overflow. 151 00:06:57.639 --> 00:06:59.600 Okay, that sounds pretty technical. Can you break that down 152 00:06:59.639 --> 00:06:59.959 from here? 153 00:07:00.160 --> 00:07:02.879 So this was a vulnerability in quick time that allowed 154 00:07:02.920 --> 00:07:06.199 attackers to execute code on a target system just by 155 00:07:06.199 --> 00:07:09.120 sending them a specially crafted RTSP stream. 156 00:07:09.319 --> 00:07:11.639 Wow. So basically you could get hacked just by opening 157 00:07:11.680 --> 00:07:12.399 a video file. 158 00:07:12.560 --> 00:07:15.759 Yeah, exactly. That's how serious this one was. And the 159 00:07:15.759 --> 00:07:18.199 book walks you through how to create the exploit, how 160 00:07:18.199 --> 00:07:21.040 to bypass those stack cookies, even how to use the 161 00:07:21.120 --> 00:07:24.439 technique code return to lib to execute the malicious code. 162 00:07:24.519 --> 00:07:26.000 Return to lib. What's that? 163 00:07:26.160 --> 00:07:29.480 Basically, it's a way to hijack the program's execution by 164 00:07:29.519 --> 00:07:33.199 redirecting it to existing code in a system library instead 165 00:07:33.199 --> 00:07:36.079 of injecting their own malicious code. The attacker uses pre 166 00:07:36.160 --> 00:07:38.399 existing code that already has the permissions to do. 167 00:07:38.360 --> 00:07:38.879 What they want. 168 00:07:39.120 --> 00:07:42.480 So it's like using the system's own tools against itself. 169 00:07:42.639 --> 00:07:42.959 Yeah. 170 00:07:43.000 --> 00:07:45.600 Pretty sneaky. Does a book have any other real world 171 00:07:45.639 --> 00:07:46.399 examples like this? 172 00:07:46.600 --> 00:07:47.160 Absolutely? 173 00:07:47.160 --> 00:07:49.439 Another one that comes to mind is the mDNS responder 174 00:07:49.920 --> 00:07:53.959 UPnP vulnerability. This one allowed for a remote root exploit. 175 00:07:54.120 --> 00:07:56.560 Whoa remote root exploit? That sounds bad. 176 00:07:56.759 --> 00:07:59.079 Yeah, it's as bad as it sounds. An attacker could 177 00:07:59.120 --> 00:08:03.040 gain complete control your system without even needing physical access. 178 00:08:03.720 --> 00:08:05.839 And this was all through a flaw in the service 179 00:08:06.160 --> 00:08:09.319 that helps you find printers and other devices on your network. 180 00:08:09.639 --> 00:08:13.360 Wow. So even the most basic features can have serious 181 00:08:13.399 --> 00:08:16.720 security implications if they're not designed and implemented properly. 182 00:08:17.120 --> 00:08:17.759 Absolutely. 183 00:08:18.000 --> 00:08:20.879 And it's not just about finding and exploiting vulnerabilities. It's 184 00:08:20.879 --> 00:08:23.879 also about what an attacker can do once they've gained 185 00:08:23.879 --> 00:08:26.600 that initial access. That's what we call post exploitation. 186 00:08:26.879 --> 00:08:28.879 Okay, so they've got a foothold in the system. What 187 00:08:28.959 --> 00:08:29.639 happens next? 188 00:08:29.959 --> 00:08:34.440 Post exploitation is all about maintaining access, covering their tracks, 189 00:08:34.519 --> 00:08:37.600 and expanding their control over the system. The Mac Hacker's 190 00:08:37.639 --> 00:08:41.000 Handbook covers some really advanced techniques for doing this, things 191 00:08:41.039 --> 00:08:45.559 like injecting code, hooking functions, and even manipulating objective sea 192 00:08:45.600 --> 00:08:46.240 method calls. 193 00:08:46.639 --> 00:08:50.480 Manipulating objective sea method calls. That sounds crazy, like, what 194 00:08:50.480 --> 00:08:51.799 would that even be used for? 195 00:08:52.200 --> 00:08:55.559 So the book describes this tool called SSL spy, which 196 00:08:55.639 --> 00:08:59.039 uses a technique called function hooking to INTERSCEP and log 197 00:08:59.200 --> 00:08:59.960 SSL traffic. 198 00:09:00.240 --> 00:09:03.360 Wait, SSL traffic isn't that the encrypted stuff used for 199 00:09:03.399 --> 00:09:05.559 like online banking and secure website? 200 00:09:05.639 --> 00:09:08.200 Yep, that's the one. And while SSL is designed to 201 00:09:08.200 --> 00:09:12.519 protect your privacy, SSL spy shows that even supposedly secure 202 00:09:12.600 --> 00:09:15.679 communication can be snooped on if you can get the 203 00:09:15.759 --> 00:09:19.039 right tools in access. The book also makes it clear 204 00:09:19.080 --> 00:09:21.639 that SSL spy can be a useful tool for security 205 00:09:21.679 --> 00:09:25.080 testing and research, but it definitely shows the potential for abuse. 206 00:09:25.519 --> 00:09:27.960 Yeah, that's a bit scary. It makes you realize there's 207 00:09:27.960 --> 00:09:31.000 always a way if someone is determined enough. What about 208 00:09:31.039 --> 00:09:33.799 that objective C method swizzling thing you mentioned? Can you 209 00:09:33.840 --> 00:09:35.320 give an example of how that would be used? 210 00:09:35.360 --> 00:09:38.840 Sure? The book talks about this tool called iChat spy 211 00:09:39.399 --> 00:09:42.559 that uses method swizzling to basically monitor I chat messages 212 00:09:42.600 --> 00:09:45.720 without anyone knowing. It could be used for things like forensics, 213 00:09:45.759 --> 00:09:48.840 but also for just plain spying on people. Imagine all 214 00:09:48.840 --> 00:09:51.120 your conversations being recorded without you ever knowing. 215 00:09:51.240 --> 00:09:54.240 Oh that's creepy. Okay, So post exploitation is all about 216 00:09:54.240 --> 00:09:56.919 being stealthy and pulling strings from behind the scenes. 217 00:09:57.039 --> 00:09:58.240 Yep, that's a good way to put it. 218 00:09:58.440 --> 00:10:00.720 And speaking of stealthy, I think it's time we talk 219 00:10:00.720 --> 00:10:01.519 about root kits. 220 00:10:01.879 --> 00:10:02.440 Rootkits. 221 00:10:02.600 --> 00:10:05.279 Yeah, those are the ultimate tools for hiding an attacker's 222 00:10:05.279 --> 00:10:10.000 presence on a system, and the Mac Haacker's Handbook goes 223 00:10:10.000 --> 00:10:13.360 into a lot of detail about creating rootkits on MACOSX, 224 00:10:13.960 --> 00:10:16.360 especially curnal level rootkits kernel level. 225 00:10:16.399 --> 00:10:18.919 That sounds intense. What makes those so powerful? 226 00:10:19.159 --> 00:10:21.759 Kernel level root kits can manipulate core functions of the 227 00:10:21.759 --> 00:10:24.960 operating system and are very good at hiding. The book 228 00:10:24.960 --> 00:10:27.519 gives an example of creating a rootkit that hides specific 229 00:10:27.559 --> 00:10:28.600 files from the finder. 230 00:10:29.000 --> 00:10:31.440 Wait, so you could have malicious files on your computer 231 00:10:31.519 --> 00:10:33.159 that are completely invisible to you. 232 00:10:33.360 --> 00:10:36.519 Yeah, that's right, and it highlights how deeply these root 233 00:10:36.559 --> 00:10:39.600 kits can burrow into the system. There's even this technique 234 00:10:39.639 --> 00:10:42.919 called hyperjacking that's mentioned in the book, where an attacker 235 00:10:42.960 --> 00:10:46.879 can actually run a whole second hidden operating system underneath 236 00:10:46.919 --> 00:10:47.960 the main one. Wow. 237 00:10:48.000 --> 00:10:50.559 So it's like a whole secret operating system exactly, and. 238 00:10:50.480 --> 00:10:52.440 It's incredibly difficult to detect. 239 00:10:52.519 --> 00:10:55.120 That's nuts. So are there any defenses against this kind 240 00:10:55.159 --> 00:10:55.600 of attack? 241 00:10:56.000 --> 00:11:00.200 Detecting and removing rootkits, especially kernel level ones, can be 242 00:11:00.399 --> 00:11:05.200 extremely difficult. They're designed to evade detection, so traditional security 243 00:11:05.240 --> 00:11:08.559 software often can't find them. This is where knowledge and 244 00:11:08.559 --> 00:11:10.039 awareness are really important. 245 00:11:10.240 --> 00:11:12.840 So again, the more you know about how this stuff works, 246 00:11:12.960 --> 00:11:13.679 the better. 247 00:11:14.080 --> 00:11:17.399 Absolutely, the better equipped you are to spot the signs 248 00:11:17.440 --> 00:11:21.279 and protect yourself. And the mac Hacker's Handbook provides a 249 00:11:21.360 --> 00:11:24.960 lot of that knowledge, including techniques for analyzing and reverse 250 00:11:25.000 --> 00:11:26.120 engineering rootkits. 251 00:11:26.320 --> 00:11:28.440 It's like learning to think like the enemy exactly. 252 00:11:28.480 --> 00:11:30.759 The more you understand how they operate, the better you 253 00:11:30.759 --> 00:11:31.679 can defend against them. 254 00:11:31.960 --> 00:11:34.320 The mac Hacker's Hammock really does a great job of 255 00:11:34.360 --> 00:11:37.200 showing you both sides of the coin, right, the attacker's 256 00:11:37.240 --> 00:11:39.159 perspective and the defender's perspective. 257 00:11:39.279 --> 00:11:41.639 Definitely, it gives you a much deeper understanding of how 258 00:11:41.679 --> 00:11:43.320 MACOSX security works. 259 00:11:43.519 --> 00:11:46.679 I'm starting to realize this book isn't just for hackers. 260 00:11:46.279 --> 00:11:48.759 Right, not at all. It's for anyone who uses a 261 00:11:48.799 --> 00:11:50.679 Mac and cares about their security. 262 00:11:50.840 --> 00:11:55.879 Yeah, it's a great reminder that security is everyone's responsibility. Okay, well, 263 00:11:55.919 --> 00:11:58.120 we've covered a lot of ground in this first part 264 00:11:58.120 --> 00:12:00.320 of our deep dive. We've only just scratched which the 265 00:12:00.360 --> 00:12:02.919 surface of what the Mac Hacker's Handbook has to offer. 266 00:12:03.000 --> 00:12:04.559 But I think we need to take a break and 267 00:12:04.639 --> 00:12:06.639 let everyone process all this information. 268 00:12:06.919 --> 00:12:09.200 Yeah, good idea. There's a lot to untack here. 269 00:12:09.240 --> 00:12:10.960 So thanks for joining us for this first part of 270 00:12:10.960 --> 00:12:13.000 our deep dive into MACOSX security. 271 00:12:13.200 --> 00:12:16.120 We'll be back soon with part two, where we'll dive 272 00:12:16.200 --> 00:12:19.240 even deeper into the world of macOS X security. 273 00:12:19.759 --> 00:12:22.799 Stay tuned, see you then, welcome back to our deep 274 00:12:22.840 --> 00:12:25.120 dive into the world of MACOSX security. 275 00:12:25.440 --> 00:12:28.360 I'm ready for more. Last time, we talked about how 276 00:12:28.440 --> 00:12:32.679 even simple features like bonjour can be exploited. And don't 277 00:12:32.720 --> 00:12:35.639 even get me started on those real world vulnerabilities like 278 00:12:35.759 --> 00:12:38.120 you're telling me I could get hacked just by opening 279 00:12:38.120 --> 00:12:38.840 a video file. 280 00:12:39.000 --> 00:12:41.080 Yep, scary stuff it is. 281 00:12:41.720 --> 00:12:43.320 But today I want to talk about something that's been 282 00:12:43.399 --> 00:12:46.559 kind of bugging me. The book mentions. 283 00:12:46.159 --> 00:12:46.919 Mock a lot. 284 00:12:47.120 --> 00:12:48.360 Ah, yes, mock it. 285 00:12:48.320 --> 00:12:51.039 Sounds kind of intimidating, like is that a supervillain or 286 00:12:51.080 --> 00:12:55.120 a part of the operating system? Well, sort of both, haha. 287 00:12:55.360 --> 00:12:58.480 Mock itself is a microkernel. It's a core part of 288 00:12:58.480 --> 00:12:59.960 how mac OSX. 289 00:12:59.519 --> 00:13:03.279 Is built, so like the foundation of the OS, right, yeah, 290 00:13:03.320 --> 00:13:03.919 you could say that. 291 00:13:04.360 --> 00:13:07.159 But what makes it interesting from a security perspective is 292 00:13:07.200 --> 00:13:10.080 that it introduces this whole different way of thinking about 293 00:13:10.120 --> 00:13:14.440 how to protect things. Instead of traditional Unix permissions, it's 294 00:13:14.480 --> 00:13:15.879 all about capabilities. 295 00:13:15.919 --> 00:13:18.120 Capabilities. Okay, you're gonna have to explain that one. 296 00:13:18.159 --> 00:13:20.279 Okay, So imagine you're trying to get into a building. 297 00:13:20.840 --> 00:13:23.840 In a traditional Unix system, security is like having a 298 00:13:23.879 --> 00:13:26.519 single key that can unlock all the doors. If you 299 00:13:26.519 --> 00:13:29.000 have a right key, you're in. But with MOCK, it's 300 00:13:29.039 --> 00:13:31.600 more like having a key ring with different keys for 301 00:13:31.639 --> 00:13:32.159 each room. 302 00:13:32.679 --> 00:13:36.600 So instead of general access, you have very specific permissions exactly. 303 00:13:37.240 --> 00:13:40.039 Each process or task as they're called in Mock has 304 00:13:40.080 --> 00:13:42.799 its own port kind of like a doorway, and to 305 00:13:42.840 --> 00:13:45.120 communicate with that task, you need to have the right 306 00:13:45.200 --> 00:13:48.559 capability or key to send a message to its port. 307 00:13:49.000 --> 00:13:51.320 Interesting, so it's not just about who you are, it's 308 00:13:51.360 --> 00:13:53.120 about what specific permissions you. 309 00:13:53.080 --> 00:13:55.679 Have exactly, and that makes it much harder for an 310 00:13:55.720 --> 00:13:58.639 attacker to escalate their privileges because they can't just get 311 00:13:58.679 --> 00:14:00.080 one key and have access to every. 312 00:14:00.240 --> 00:14:03.200 Okay, that makes sense. It's like having multiple layers of security. 313 00:14:03.279 --> 00:14:04.399 That's a good way to think about it. 314 00:14:04.679 --> 00:14:08.039 Yeah, and the Macacor's handbook really goes into detail about 315 00:14:08.279 --> 00:14:12.240 how this works, how tasks acquire capabilities, how those capabilities 316 00:14:12.240 --> 00:14:15.240 can be manipulated, and what the security implications of all 317 00:14:15.320 --> 00:14:15.679 that are. 318 00:14:16.200 --> 00:14:19.639 So you're telling me, even with this capability based system, 319 00:14:19.799 --> 00:14:22.480 there are still ways for an attacker to exploit it. 320 00:14:22.799 --> 00:14:26.039 Unfortunately. Yeah, nothing's perfect, right. One of the things the 321 00:14:26.080 --> 00:14:29.399 book talks about is gaining control of the task's kernel port. 322 00:14:29.960 --> 00:14:32.320 Think of that as the master key for that task. 323 00:14:32.480 --> 00:14:34.039 Oh so if you get that, you have. 324 00:14:34.039 --> 00:14:38.440 Full control pretty much, And the book discusses various techniques 325 00:14:38.480 --> 00:14:41.279 for getting that kind of access, some of which involve 326 00:14:41.320 --> 00:14:44.360 exploiting vulnerabilities in the mock subsystem itself. 327 00:14:44.519 --> 00:14:47.120 Yikes, that's not good. So it's kind of like finding 328 00:14:47.159 --> 00:14:48.600 a way to forge that master key. 329 00:14:48.919 --> 00:14:52.559 Yeah, it's definitely a serious threat, but understanding these techniques 330 00:14:52.679 --> 00:14:56.639 is also crucial for defenders. By knowing how attackers might 331 00:14:56.639 --> 00:14:59.440 try to gain control of tasks. We can build better 332 00:14:59.480 --> 00:15:02.120 defenses and try to prevent those attacks from happening. 333 00:15:02.279 --> 00:15:05.000 So it's like studying a lock picking manual to learn 334 00:15:05.000 --> 00:15:07.320 how to build a better lock exactly. 335 00:15:07.720 --> 00:15:11.360 And the mac Hacker's Handbook goes beyond the theory here. 336 00:15:11.440 --> 00:15:15.399 It actually provides practical examples and tools that demonstrate how 337 00:15:15.399 --> 00:15:19.720 to interact with mock ports, manipulate port rights, even inject 338 00:15:19.759 --> 00:15:21.240 code into running processes. 339 00:15:21.279 --> 00:15:24.120 Hold on, inject code into running processes. That sounds like 340 00:15:24.159 --> 00:15:25.279 some next level stuff. 341 00:15:25.320 --> 00:15:28.039 It might sound crazy, but it's a very real technique. 342 00:15:28.360 --> 00:15:30.480 The book walks you through how to use something called 343 00:15:30.519 --> 00:15:34.000 mock injection to basically hijack a process and make it 344 00:15:34.000 --> 00:15:34.600 do what you want. 345 00:15:34.799 --> 00:15:36.440 So you're telling me, I can just take over a 346 00:15:36.440 --> 00:15:38.559 program that's already running and make it do my bidding. 347 00:15:38.840 --> 00:15:41.960 Well, it's not quite that simple, but essentially yeah, and 348 00:15:42.200 --> 00:15:44.200 the book actually shows you how to do it using 349 00:15:44.240 --> 00:15:46.840 this tool called inject bundle. You basically take a specially 350 00:15:46.879 --> 00:15:50.080 crafted bundle of code and inject it into the running process. 351 00:15:50.559 --> 00:15:53.639 Wow. So like sneaking in a trojan horse into an 352 00:15:53.720 --> 00:15:55.720 already fortified city exactly. 353 00:15:55.879 --> 00:15:59.519 And once that bundles in it can access that process's memory, 354 00:16:00.080 --> 00:16:02.840 execute its own code, maybe even take control of the 355 00:16:03.000 --> 00:16:03.720 entire process. 356 00:16:03.799 --> 00:16:05.759 Okay, now I'm really getting worried, Like, what kind of 357 00:16:05.840 --> 00:16:08.159 damage could an attacker do with something like this. 358 00:16:08.279 --> 00:16:11.320 It's pretty scary to think about. Actually, attacker could use 359 00:16:11.360 --> 00:16:14.639 my conjection to do all sorts of things, install keyloggers, 360 00:16:14.840 --> 00:16:17.720 steal sensitive data, or even take over the whole system. 361 00:16:18.039 --> 00:16:20.919 It's why understanding how mock works and how it can 362 00:16:20.960 --> 00:16:24.360 be exploited is so important. It's not just theoretical, it's 363 00:16:24.519 --> 00:16:25.000 very real. 364 00:16:25.200 --> 00:16:27.480 The Mac Hacker's Handbook really does a good job of 365 00:16:27.519 --> 00:16:30.279 bringing those real world attacks to light, doesn't it. 366 00:16:30.279 --> 00:16:30.600 It does. 367 00:16:30.679 --> 00:16:32.679 It's like getting a behind the scenes look at how 368 00:16:32.720 --> 00:16:34.840 both the attackers and the defenders think. 369 00:16:35.000 --> 00:16:38.200 Speaking of attacks, I remember that the book also covers rootkits, 370 00:16:38.240 --> 00:16:40.799 which are those programs that hide themselves on your system. 371 00:16:40.879 --> 00:16:41.200 Right. 372 00:16:41.360 --> 00:16:44.679 Rootkits are all about being stealthy and persistent, and the 373 00:16:44.720 --> 00:16:47.720 book goes deep into how to create them on Mac OSX, 374 00:16:48.200 --> 00:16:49.360 especially kernel level. 375 00:16:49.399 --> 00:16:53.039 Rootkits kernel level, so they operate at the heart of 376 00:16:53.039 --> 00:16:55.320 the operating system. That's terrifying. 377 00:16:55.639 --> 00:16:58.799 Yeah, they can be incredibly powerful and really hard to detect. 378 00:16:59.360 --> 00:17:03.240 Kernel level root kits can do things like hide files, 379 00:17:03.799 --> 00:17:08.039 intercept network traffic, even manipulate other parts of the operating system. 380 00:17:08.119 --> 00:17:11.400 It's like having a ghost in the machine, silently controlling everything. 381 00:17:11.640 --> 00:17:14.240 That's actually a good analogy, and the book gives an 382 00:17:14.279 --> 00:17:17.160 example of creating a root kit that can hide files 383 00:17:17.160 --> 00:17:19.960 from the finder. You could have all sorts of bad 384 00:17:19.960 --> 00:17:21.799 stuff in your computer and you'd never even know it 385 00:17:21.839 --> 00:17:22.160 was there. 386 00:17:22.240 --> 00:17:24.160 Okay, I'm starting to feel a little paranoid now, like, 387 00:17:24.200 --> 00:17:26.200 how do you even defend against something like that? 388 00:17:26.599 --> 00:17:30.319 Detecting and removing rootkits, especially those kernel level ones can 389 00:17:30.359 --> 00:17:34.400 be really, really tough. They're designed to be invisible and 390 00:17:34.480 --> 00:17:37.960 to avoid the typical security software. This is where understanding 391 00:17:38.000 --> 00:17:39.960 how they work becomes crucial. 392 00:17:40.160 --> 00:17:42.559 So it's back to knowledge is power exactly. 393 00:17:43.160 --> 00:17:45.480 The more you know about how root kits work, the 394 00:17:45.480 --> 00:17:47.680 better chance you have of spotting them and getting rid 395 00:17:47.680 --> 00:17:51.160 of them. The Mac Hacker's Handbook gives you that knowledge 396 00:17:51.319 --> 00:17:54.279 and techniques to analyze and reverse engineer them so you 397 00:17:54.319 --> 00:17:55.720 can figure out what they're doing. 398 00:17:56.000 --> 00:17:59.119 So it's about learning to speak the attacker's language. 399 00:17:59.200 --> 00:18:02.160 You got it. The better you understand how they think, 400 00:18:02.359 --> 00:18:05.640 the better you can defend against them. This whole conversation 401 00:18:05.720 --> 00:18:09.359