WEBVTT 00:02.840 --> 00:06.120 Hello everyone, and thank you for joining this course. 00:06.160 --> 00:13.560 My name is Natalie and we are going to explore software exploitation in from one hand a very simple 00:13.560 --> 00:22.400 way and on the other hand, very advanced uh, concepts that we are going to talk about and actually 00:22.400 --> 00:24.240 experience firsthand. 00:24.520 --> 00:33.360 So my goal would be to take you through a journey that covers very sophisticated topics in a very simplified, 00:33.680 --> 00:40.440 easy to understand way, using illustrations and examples from the real world. 00:41.040 --> 00:45.440 So really, thank you for joining and let's jump right in. 00:46.680 --> 00:48.280 So first, who am I? 00:49.160 --> 00:52.240 Um, I started early with computer science. 00:52.400 --> 00:57.680 Uh, but the only connection I had to computers was that I really liked playing FIFA. 00:58.720 --> 01:07.940 Um, and that somehow brought me to a bachelor's degree in computer science when I was 14, and that 01:07.940 --> 01:16.100 paved the way to unit 8200, the Israeli intelligence forces, where I gained a hacker's perspective 01:16.140 --> 01:23.100 practicing cyber security there, which led me to my professional experience in the industry, where 01:23.100 --> 01:29.460 I really was a vulnerability researcher, finding zero day vulnerabilities in Linux kernel and Android 01:29.460 --> 01:30.340 devices. 01:30.700 --> 01:37.540 But more importantly, designed exploitations to actually take advantage of those vulnerabilities to 01:37.580 --> 01:46.580 extract intelligence, which led me to co-founding sternum, which developed a runtime security solution 01:46.580 --> 01:56.060 that can prevent the exploitation stages of different attacks and software attacks. 01:56.100 --> 02:02.870 We use techniques like memory protection, runtime application self-protection and those sorts of things. 02:03.310 --> 02:12.430 And worked on the most advanced devices you can imagine, from medical devices to military drones to 02:12.470 --> 02:17.710 machine vision devices that used our technology to be protected. 02:18.150 --> 02:27.590 And what I want to do here today is to actually simplify very complex topics and talk about how exploitation 02:27.590 --> 02:34.830 really looks like, not just the part of finding a vulnerability or patching a CVE, but what really 02:34.830 --> 02:36.550 happens behind the scenes. 02:36.590 --> 02:41.190 This will give you the tools to understand hands on. 02:41.590 --> 02:43.710 What are attack vectors? 02:44.110 --> 02:51.830 Where should I look for sweet spots in the code that I'm generating, or the product that I'm bringing 02:51.830 --> 02:59.530 to market, and how hackers are actually bypassing different security mitigation Mitigations that I 02:59.530 --> 03:02.690 think I put on my device. 03:02.970 --> 03:08.850 All of these will be explored, and we're going to have a lot of fun actually developing exploitations. 03:10.010 --> 03:17.370 But first, starting from the very beginning, defining vulnerabilities and exploitation. 03:19.050 --> 03:22.970 So what are vulnerabilities in computer security? 03:23.010 --> 03:29.010 A vulnerability is a weakness which can be exploited by a threat actor, such as an attacker, to perform 03:29.050 --> 03:32.250 unauthorized actions within a computer system. 03:32.730 --> 03:36.330 I would say here that not all vulnerabilities can be exploited. 03:36.330 --> 03:42.210 And we are seeing in the field vulnerabilities that can't really be exploited but are still addressed 03:42.210 --> 03:45.410 by military or by companies patching them. 03:45.890 --> 03:52.610 But the key point here is that vulnerability is an option for a malicious user to use a system flow 03:52.610 --> 03:58.300 to gain control of the system, or to use it in a way the developer did not Intend. 03:58.820 --> 04:01.180 Keyword here is an option. 04:01.180 --> 04:07.740 Just the fact that we have a vulnerability does not mean we got attacked or something happened. 04:08.380 --> 04:11.500 And it also doesn't necessarily mean it's exploitable. 04:13.660 --> 04:15.660 So what is exploitation? 04:16.340 --> 04:23.460 To exploit a vulnerability, an attacker must have at least one applicable tool or technique that can 04:23.460 --> 04:25.700 connect to a system weakness. 04:26.140 --> 04:32.260 So what we understand here is that an exploit is actually connected to a very specific vulnerability. 04:32.300 --> 04:34.620 We cannot create a generic exploit. 04:34.860 --> 04:40.020 Each exploit is connected to the vulnerability that we are attempting to exploit. 04:40.300 --> 04:47.140 And the exploit is actually where we take advantage of the vulnerability that we have found to cause 04:47.140 --> 04:49.020 the unintended behavior. 04:49.540 --> 04:57.460 So an exploit from the English verb to exploit, meaning to use something to one's own advantage is 04:57.600 --> 05:03.400 a piece of software, actually a chunk of data or a sequence of commands that takes advantage of a bug 05:03.400 --> 05:08.400 or vulnerability to cause unintended or unanticipated behavior. 05:08.840 --> 05:16.480 And this is also a key part here, because if our exploitation cannot really cause the system to behave 05:16.520 --> 05:22.920 unexpectedly on or unintendedly, then we didn't exploit anything, right? 05:22.920 --> 05:30.400 If the system continues to behave as it was intended by the developers, we didn't really exploit the 05:30.400 --> 05:31.040 system. 05:31.520 --> 05:38.840 So a key part of actually exploiting is causing this unexpected or unintended behavior. 05:40.400 --> 05:44.440 Let's take an example for the real life to just cover those two topics. 05:45.640 --> 05:49.800 Let's say I left the door open in my house. 05:50.480 --> 05:54.480 So the vulnerability in that scenario is leaving the door open. 05:54.960 --> 06:03.770 An attacker scouting out can find that you actually tend to leave your door open, or that you actually 06:03.770 --> 06:10.290 live in the door open every once in a while, and that this is a vulnerability to enter your house. 06:11.610 --> 06:14.050 But now I need to plan the exploitation. 06:14.050 --> 06:18.770 Just knowing that you tend to leave the door open doesn't help me that much. 06:20.010 --> 06:24.330 So at planning, the attack requires. 06:24.330 --> 06:28.890 Basically, let's think about a few things I need to know first. 06:30.170 --> 06:34.570 Making sure that the door is actually open at the time of exploitation. 06:34.570 --> 06:38.130 When I plan to enter your house, that the vulnerability exists. 06:38.570 --> 06:44.290 Second, maybe I want to become familiar with your schedule to know if you're home or not, because 06:44.290 --> 06:48.490 I also need you to be out of the house to exploit it. 06:49.010 --> 06:54.530 Understand your alarm mechanism to know how to bypass it if needed, and so on. 06:54.530 --> 06:55.990 So planning the Planning. 06:55.990 --> 07:00.990 The exploitation is actually very much the same in software as well. 07:00.990 --> 07:06.870 We need to plan and arrange the environment so that we can actually leverage the vulnerability that 07:06.870 --> 07:07.630 we found. 07:08.510 --> 07:16.750 The execution is actually taking this planned exploitation that connects to the specific vulnerability 07:16.750 --> 07:23.070 that we found the door open and actually performing the exploit entering the house while I'm not there, 07:23.510 --> 07:29.150 bypassing the alarm mechanism or anything else that I needed to account for. 07:31.670 --> 07:37.110 So let's talk about the general types of vulnerabilities, because not all vulnerabilities are the same. 07:37.150 --> 07:44.590 And when you choose a security tool to implement in your company or when you are starting to search 07:44.590 --> 07:52.750 for vulnerability, if you are a security researcher, you need to know that, uh, we don't treat all 07:52.750 --> 07:54.150 vulnerabilities the same. 07:54.710 --> 07:59.370 And this is my kind of categories of vulnerabilities. 07:59.370 --> 08:01.810 You might see other things online. 08:02.050 --> 08:10.370 But as I view, uh, most of the world, we have first bucket, uh, of configuration vulnerabilities. 08:10.850 --> 08:16.850 Those actually arise from incorrect system settings, insecure defaults and so on. 08:16.890 --> 08:20.330 Examples could be open ports or services. 08:20.370 --> 08:24.970 Exposing an S3 server to the, uh, to the internet. 08:25.010 --> 08:30.770 Default credentials, weak permissions, uh, and so on and so forth. 08:30.890 --> 08:37.450 So these are vulnerabilities in how we configure our systems across the board. 08:39.330 --> 08:48.450 The second type I call them logical vulnerabilities, which is actually the software designed from the 08:48.490 --> 08:54.250 get go or by intention, not in a secure manner. 08:54.500 --> 09:04.700 This could be, for example, uh, not encrypting data or having a very weak admin password that, uh, 09:05.300 --> 09:10.820 someone can kind of, uh, guess or business logic errors. 09:10.860 --> 09:19.300 This could mean that you actually allow a certain sensitive operation to happen without requiring permissions. 09:19.420 --> 09:25.980 So this is like you didn't design the software in a way that is secure. 09:26.300 --> 09:29.260 And this is why I call them logical vulnerabilities. 09:29.900 --> 09:32.340 The third part are code vulnerabilities. 09:32.420 --> 09:38.740 These are flaws in the actual source code or memory handling, often due to easy to miss programming 09:38.740 --> 09:39.340 bugs. 09:39.380 --> 09:47.500 This could be something that you'll easily miss and static analysis tools sometimes companies use can 09:47.500 --> 09:55.880 only track around 50% of those bugs, and we're still left with 50% that goes out there, uh, into 09:55.880 --> 09:56.600 the field. 09:56.640 --> 09:59.200 Examples are, of course, the most famous one. 09:59.240 --> 10:00.400 Stack overflows. 10:00.720 --> 10:03.520 Buffer overflows in general format. 10:03.520 --> 10:11.240 String vulnerabilities, command injections, basically everything that is within how you handle code. 10:11.920 --> 10:15.400 Not necessarily, uh, application logic. 10:16.440 --> 10:19.480 Our focus will be on code vulnerabilities. 10:19.960 --> 10:20.360 Why? 10:21.280 --> 10:24.760 Because this actually requires advanced exploitations. 10:24.760 --> 10:31.880 Most of the zero days out there that are being exploited are code vulnerabilities, especially if we're 10:31.880 --> 10:34.240 talking about military grade exploits. 10:34.840 --> 10:40.840 IoT exploits that, uh, are more prone to code vulnerabilities and so on. 10:41.640 --> 10:44.000 So this is the most interesting part. 10:44.040 --> 10:46.800 We have a lot of tools to cover this part. 10:46.800 --> 10:55.210 And logical vulnerabilities are something that, uh, at least in advanced systems, MPs are also a 10:55.210 --> 10:58.530 more easy to track, at least the more the important ones. 10:58.530 --> 11:04.690 We're still seeing a lot of system that has these logical vulnerabilities, but in that case, the exploitation 11:04.690 --> 11:06.210 is pretty simple, right? 11:06.210 --> 11:12.210 If you find just a business logic that is not well written, you just need to go in and use that business 11:12.210 --> 11:12.650 logic. 11:12.650 --> 11:16.530 You don't need to really craft a sophisticated exploitation. 11:16.810 --> 11:19.250 So this is where we are going to focus. 11:21.090 --> 11:28.730 Just as a Glimpse Micro actually published every year, the most, uh, the top ten vulnerabilities 11:28.730 --> 11:30.690 that are most common out there. 11:31.370 --> 11:37.690 And you can see that each type of vulnerability has an ID, a CWA, basically. 11:38.250 --> 11:44.570 And what we are going to cover is the number two, uh, which is memory corruption out of bound. 11:44.610 --> 11:45.170 Right. 11:45.170 --> 11:52.410 So this is the second most popular vulnerability out there out of about read use after free. 11:52.590 --> 11:58.030 and we are also going to cover vulnerabilities that are not within that list. 11:58.310 --> 12:05.070 In future courses, we probably going to cover command injections, missing authorization and those 12:05.070 --> 12:05.990 type of things. 12:07.790 --> 12:14.470 Now let's talk about attack vectors, which are really potential paths to exploitable vulnerabilities. 12:14.750 --> 12:16.750 Mark the word exploitable. 12:16.750 --> 12:19.350 It's not just paths to vulnerability. 12:19.390 --> 12:24.470 Sometimes you can have a vulnerability but no path to trigger the vulnerability. 12:24.950 --> 12:33.910 So attack vectors are crafting together, knowing the path to trigger a vulnerability so it becomes 12:33.950 --> 12:34.950 exploitable. 12:35.950 --> 12:38.510 Attack vectors are target dependent. 12:38.630 --> 12:41.270 We don't have a general attack vectors in mind. 12:41.310 --> 12:45.430 Different systems expose different pathways for exploitation. 12:46.030 --> 12:49.030 The interface matters a lot. 12:49.150 --> 12:53.720 How a system connects to the outside world Sidewall determines its vulnerable points. 12:53.920 --> 13:00.360 If we have more interfaces, Wi-Fi, Bluetooth connectivity to different servers, parsing different 13:00.400 --> 13:08.840 types of information coming in and out from our system, these are all attack vectors because those 13:08.840 --> 13:14.960 are interfaces that create communication between our system and the outside world. 13:15.280 --> 13:23.120 Since the attacker is present in the outside world and not in our system, attacker actually relies 13:23.120 --> 13:26.800 on his ways to communicate with our system. 13:27.120 --> 13:31.440 So every time you need to map an attack vector, think about this. 13:31.480 --> 13:40.760 What are all the options that an outside world player can talk, communicate, or influence my system? 13:42.560 --> 13:46.000 This will probably give you a good start of attack vectors. 13:46.960 --> 13:54.260 In this section, we're actually going to briefly review an IoT Example, where we map the various attack 13:54.260 --> 13:57.740 vectors that are present in a. 13:58.340 --> 14:00.420 In a simple IoT device. 14:00.860 --> 14:04.780 So simple breakdown of IoT attack vectors. 14:04.980 --> 14:06.500 Let's say we have a device. 14:06.620 --> 14:09.540 And what you can see here is an illustration of a chip. 14:10.260 --> 14:13.620 And let's talk about the five elements we see here. 14:13.660 --> 14:17.980 The first one is parsing vulnerabilities when dealing with user input. 14:18.380 --> 14:26.300 This is uh basically all the communication channels where we need to break down the packets received. 14:26.820 --> 14:27.660 Received. 14:27.700 --> 14:28.260 Sorry. 14:28.700 --> 14:35.060 And we are not dealing well with the user input or checking sizes, those type of things, and creating 14:35.060 --> 14:39.300 overflows in the memory or other types of vulnerabilities. 14:40.220 --> 14:43.180 The second is communicating with insecure source. 14:43.180 --> 14:44.780 This is something we see a lot. 14:44.820 --> 14:51.030 Our system communicates with a server or a smartphone application, and we trust that the information 14:51.030 --> 14:55.910 coming from this source is legitimate, but we can't really trust it. 14:55.990 --> 15:03.190 What if someone took over the server, or pretending to be the server, and is sending commands to our 15:03.190 --> 15:07.790 IoT device, and our IoT device is just performing the commands? 15:08.310 --> 15:19.030 This is an example of a logical vulnerability securing a trust in a source without legitimate reasons 15:19.030 --> 15:20.030 to trust it. 15:20.870 --> 15:25.670 The third thing is third party libraries in every system, including IoT device. 15:25.670 --> 15:29.710 We actually implement a lot of third party code libraries. 15:29.830 --> 15:33.470 Even the operating system is a type of a third party. 15:34.030 --> 15:40.590 Every vulnerability in this third party code is another attack vector for the attackers. 15:40.590 --> 15:48.430 They can actually find a third party vulnerability and then exploit it in all systems that leveraging 15:48.430 --> 15:49.930 this third party. 15:50.370 --> 15:53.490 We will see an example of it in just a second. 15:54.210 --> 15:57.930 The fourth is encryption and authentication misuses. 15:57.930 --> 16:01.610 This is a very common attack vector for IoT devices. 16:02.090 --> 16:05.010 And fifth is chip level vulnerabilities. 16:05.330 --> 16:10.530 Even the chip set used for Wi-Fi and Bluetooth communication comes with software. 16:10.570 --> 16:11.410 Inside. 16:12.050 --> 16:21.410 That software is responsible for the first layer of analysis of the incoming communication, which means 16:21.410 --> 16:33.490 you can also overflow that, uh, piece of, uh, of input that is being parsed to at least gain control 16:33.490 --> 16:39.050 over the chip and then, uh, find your way into other places. 16:39.730 --> 16:43.010 We don't have to really understand that deeply right now. 16:43.010 --> 16:49.830 But the most important thing to remember here is that everything that has software in it. 16:49.830 --> 16:55.950 Even the smallest chip in your device could be an attack vector. 16:58.590 --> 17:00.110 What is the attack chain? 17:00.430 --> 17:05.390 Um, so we have actually between 4 to 3 stages. 17:05.390 --> 17:08.670 Between 3 and 4 would be a better way to say it. 17:08.790 --> 17:10.710 Uh, of attacking a device. 17:10.870 --> 17:12.990 The first one is a vulnerability. 17:12.990 --> 17:15.070 We need to find a flaw in the system. 17:15.630 --> 17:17.550 The second one is exploit. 17:17.550 --> 17:25.110 We actually weaponized, uh, a code that manipulates the system behavior by leveraging the vulnerability 17:25.150 --> 17:26.190 from stage one. 17:26.910 --> 17:36.230 Now that we were able to do that, we can, uh, inject a shell code that is the first, uh, malicious 17:36.270 --> 17:45.190 code running in the system that is actually opening the gate or installing the malware, which is the 17:45.190 --> 17:53.960 last stage, which is the malicious software that actually, uh, continuously, uh, spying the system 17:53.960 --> 17:56.040 or causing a certain damage. 17:56.640 --> 18:03.720 In some cases, stage three and four are being connected together, and you actually goes from exploit 18:03.720 --> 18:04.520 to a malware. 18:04.960 --> 18:11.160 But if you are looking for more, I would say persistent malware that is present. 18:11.400 --> 18:18.040 Many times you'll go through a shellcode that is then responsible for, uh, safely installing the malware 18:18.040 --> 18:19.640 without being recognized. 18:21.400 --> 18:22.880 Now an example. 18:23.360 --> 18:29.560 Heartbleed, a critical security third party, uh, vulnerability and exploitation. 18:29.840 --> 18:37.240 You probably noticed and heard about it a lot, but just to give you, uh, a glimpse into how it connects 18:37.240 --> 18:44.400 to what we discussed, OpenSSL is a widely used cryptographic library that is actually supposed to protect 18:44.400 --> 18:45.520 sensitive data. 18:46.000 --> 18:52.380 Ironically, it's a software, and it's a software that powers information coming from the outside. 18:52.740 --> 18:56.180 So it had a flow, a code vulnerability. 18:56.660 --> 19:04.700 So while the logical behavior of open SSL is to protect us within the implementation of the library, 19:04.700 --> 19:07.140 there is a simple code vulnerability. 19:07.860 --> 19:15.460 The interface that was exposed is the mechanism called Heartbleed which should basically say, hey, 19:15.460 --> 19:21.340 I'm here, I'm good, and it is exposed to the outside world via https. 19:21.900 --> 19:24.780 The type of vulnerability is out of bound read. 19:26.140 --> 19:32.980 Uh, the critical flow came from improper input validation in the Heartbleed uh extension. 19:33.380 --> 19:36.140 This is actually a third party library vulnerability. 19:36.180 --> 19:45.580 What that means is that every system that is using this version of OpenSSL is exposed to the vulnerability 19:45.580 --> 19:47.670 and to the same exploitation. 19:47.670 --> 19:55.390 So thinking about it from the hacker's perspective here, I can find one vulnerability in a third party 19:55.710 --> 20:00.230 and apply it, uh, almost generically across systems. 20:00.310 --> 20:08.350 This is very powerful attack scenario is attackers crafting packets requesting more data than actually 20:08.350 --> 20:17.470 provided OpenSSL returns basically the memory containing the adjacent memory containing, for example, 20:17.470 --> 20:25.750 passwords and keys and private data, because it starts sending, uh, memory from places that the attacker 20:25.790 --> 20:28.710 should not have any visibility to. 20:30.270 --> 20:32.350 And the impact is is well known. 20:32.350 --> 20:39.950 But let's see the Heartbleed attack chain timeline, as we saw earlier, uh, about the attack chain. 20:39.950 --> 20:41.830 So the vulnerability is out of bounds. 20:41.870 --> 20:51.450 Read the exploitation is the malicious heartbeat request actually requesting larger payload size than 20:51.490 --> 20:55.930 actually provided, which triggers this out of bounds read. 20:56.930 --> 20:59.770 Shellcode in that case was not used. 20:59.890 --> 21:08.170 Uh, using this, uh, malicious packet, we were able to directly extract memory and read this sensitive 21:08.170 --> 21:11.610 information with no, uh, shellcode needed. 21:12.050 --> 21:17.170 The malware or the impact in that case is the sensitive data being exposed. 21:18.930 --> 21:27.090 So this pretty much covers how a real attack is actually reflected in the timeline we discussed earlier. 21:27.690 --> 21:31.810 What is the vulnerability, how the exploitation actually looks like? 21:32.250 --> 21:38.570 What is the attack vector, which is the Https interface that is exposed to the outside world? 21:39.210 --> 21:44.570 To basically wrap up the concepts we talked about with a real example. 21:45.540 --> 21:46.700 What's next? 21:46.780 --> 21:55.380 So we are going to cover stack Overflow's security mitigations like how systems today protect against 21:55.380 --> 22:03.260 code vulnerability exploitations, how attackers handle that with ROP, return oriented programming 22:04.340 --> 22:07.100 to bypass those security mitigations. 22:07.100 --> 22:14.180 And we are going to have a very cool hands on lab where you will actually develop your own exploitations 22:14.540 --> 22:15.660 later in the course. 22:15.660 --> 22:22.740 We will also cover advanced techniques like heap, feng shui and other cool stuff. 22:23.420 --> 22:24.900 So I hope you enjoy. 22:24.900 --> 22:31.860 This was just an introduction, but next in line are going to be really code examples, exploitations 22:32.260 --> 22:41.140 and diving deep into how actually softwares are being exploited and how to design and exploit. 22:41.500 --> 22:42.180 Thank you.