WEBVTT 00:07.370 --> 00:12.140 When we talk about memory, we often refer to memory attacks as buffer overflow attacks. 00:12.170 --> 00:17.000 These attacks frequently develop malware exploiting various attributes and functions of the primary 00:17.000 --> 00:19.130 memory core within the computer system. 00:19.160 --> 00:23.330 When we think about buffer overflow attacks, I really want you to get in your mind that you have memory 00:23.330 --> 00:24.740 what's inside your computer? 00:24.770 --> 00:26.660 We're not just talking about regular storage memory. 00:26.690 --> 00:28.460 We're talking about memory as a whole. 00:28.460 --> 00:35.900 And when that memory overfills, we can commonly see different aspects within our transmission of system 00:35.900 --> 00:40.370 to system communication being let overdone or overfilled. 00:40.400 --> 00:41.420 Through the process. 00:41.420 --> 00:43.910 So let's kind of take a step back and look at this. 00:43.940 --> 00:44.390 Okay. 00:44.420 --> 00:49.430 Within a normal system we have our memory within our computer system. 00:49.430 --> 00:51.500 And in that memory we write data. 00:51.530 --> 00:53.720 Now I want you to imagine that I'm encrypting data. 00:53.750 --> 00:56.150 I'm going from one network over to one server. 00:56.150 --> 01:00.860 And we're going to process that data to make sure that that data isn't compromised. 01:00.860 --> 01:02.210 I'm going to encrypt it. 01:02.210 --> 01:08.070 So I send my encrypted data from my operating system over to a server, and it's encrypted across the 01:08.070 --> 01:09.120 entire pathway. 01:09.120 --> 01:11.640 You think you're good, you've encrypted your data. 01:11.670 --> 01:15.960 However, as it's writing to the memory of the server, we must first unencrypt it. 01:15.960 --> 01:18.180 It's a standard process within a server. 01:18.180 --> 01:21.180 We've unencrypted that data and we start writing it to the memory. 01:21.180 --> 01:22.680 This is where a buffer overflow. 01:23.220 --> 01:25.860 Buffer overflow attack takes place. 01:25.860 --> 01:30.240 The unencrypted data is then trying to write to the memory of the server. 01:30.240 --> 01:33.690 As a malicious actor, I can write to that memory core. 01:33.690 --> 01:39.360 And unlike a normal operating system where I filled up the memory and it stops writing, that memory 01:39.360 --> 01:46.050 then overflows so that encrypted traffic that is now unencrypted is now spilling out of our memory within 01:46.050 --> 01:46.770 our server. 01:46.770 --> 01:49.350 And we refer to this as a buffer overflow attack. 01:49.350 --> 01:50.700 Why is this important? 01:50.700 --> 01:56.130 If I'm trying to log into a server and I'm trying to gain access to that server or to that web page, 01:56.130 --> 01:59.010 I normally put forward a username and password. 01:59.040 --> 02:03.120 Now that username and password is usually done encrypted and it's sent to the server. 02:03.150 --> 02:06.930 The server verifies it and then it lets me gain access just like before. 02:06.930 --> 02:08.190 It's going to let me gain access. 02:08.190 --> 02:11.890 But as it's writing to the memory, it's actually getting spilled out. 02:11.890 --> 02:17.110 So malicious actor that is using a buffer overflow attack can actually see that username and password 02:17.110 --> 02:18.280 in plain text. 02:18.280 --> 02:21.010 But it doesn't just stop at username and passwords. 02:21.010 --> 02:23.260 It could be critical vital information. 02:23.290 --> 02:28.060 The only good piece is not all that information or data is being spilled out at once. 02:28.060 --> 02:32.830 They're only getting tidbits of here and there, which means you can log into the system and be 100% 02:32.830 --> 02:33.550 foolproof. 02:33.550 --> 02:35.080 But the next person couldn't. 02:35.080 --> 02:40.930 Their data, their username and password could accidentally spill out, giving that compromised data 02:40.930 --> 02:42.310 to the malicious actor. 02:42.310 --> 02:48.010 When we talk about attacks directed at heap memory, we're usually talking about the complexity of the 02:48.010 --> 02:52.930 attack being a little bit more complex in nature and not always successful either. 02:52.930 --> 02:58.900 This heap attack takes corrupted data within a normal buffer overflow attack and overwrites it. 02:58.900 --> 03:04.060 So instead of writing the memory, we're then overwriting the memory with what we want to put in, not 03:04.060 --> 03:10.630 just reading the data as we normally see within an integer overflow attack, a normal system only uses 03:10.630 --> 03:13.510 four bits or bytes of information at a time. 03:13.510 --> 03:19.600 If I provide more data, i.e. more than that four bits is capable of than I've exceeded the integer 03:19.600 --> 03:22.000 amount of the data being written to the system. 03:22.000 --> 03:27.550 This then poses a vulnerability to the system, which then provides us with an integer buffer overflow 03:27.550 --> 03:28.270 attack. 03:28.300 --> 03:33.100 When we talk about buffer overflow attacks, we normally need to understand the mitigation that goes 03:33.100 --> 03:35.860 in line with how to defend against such attacks. 03:35.890 --> 03:40.150 One such intimidation technique is simple input validation. 03:40.270 --> 03:45.250 We've seen this time and time again on websites on programs where validating the input. 03:45.280 --> 03:50.200 Obviously, if I'm doing a number only system like you might see in a calculator, I don't want the 03:50.200 --> 03:52.720 user to be able to provide letters as well. 03:52.750 --> 03:55.960 Common input and input validation reflects that. 03:55.960 --> 04:02.620 We're going to stay away from those common slashes, those semicolons, those specific integers, or 04:02.620 --> 04:07.180 those specific keystrokes that would allow for somebody to program a computer. 04:07.210 --> 04:09.820 We also have something that's called least privilege. 04:09.850 --> 04:16.060 The principle of least privilege provides us only the minimal needed data for a user to have access 04:16.060 --> 04:16.510 to. 04:16.540 --> 04:23.280 Obviously, if I'm a janitor, I only need access Maybe to calendar, maybe some office word documents, 04:23.280 --> 04:29.700 maybe some basic principles of of the operating system or of the program that limits my availability. 04:29.700 --> 04:34.200 I'm not going to give a janitor full access to my servers and configuration access. 04:34.200 --> 04:36.420 This is the concept of least privilege. 04:36.420 --> 04:43.230 At the same time, I don't want to give my operating system guys my IT guys access to the CEO's information, 04:43.260 --> 04:48.330 and I don't want the CEO to have access to my its access to configuration of servers. 04:48.330 --> 04:51.360 We call this concept the concept of least privilege. 04:51.360 --> 04:57.210 When we talk about secure coding, we're securely coding our programs and our applications. 04:57.210 --> 04:59.040 We want the coding to be secure. 04:59.040 --> 05:01.440 We want it to handle errors properly. 05:01.440 --> 05:04.800 We won't want it to be just something that I found online. 05:04.800 --> 05:10.470 Maybe ChatGPT wrote me a program code that's not very secure, because anybody could have written anything 05:10.470 --> 05:13.410 in there, and I want it to be secure from the start. 05:13.410 --> 05:18.180 Meaning I'm not doing security before or excuse me, after the coding process. 05:18.180 --> 05:21.000 I'm doing the secure coding during the process. 05:21.030 --> 05:24.870 Secure coding in its full functionality is a very robust topic. 05:24.870 --> 05:29.160 So I just want you to understand that we need secure coding as our mitigation technique for a buffer 05:29.160 --> 05:30.180 overflow attack. 05:30.210 --> 05:38.070 We can also do runtime application self-protection within a runtime self runtime application Self-Protection 05:38.070 --> 05:38.970 or Rasp. 05:39.000 --> 05:43.470 We're really kind of taking this aspect of hey can I run this program. 05:43.470 --> 05:46.260 And it's protected while it's running the process. 05:46.290 --> 05:49.680 We can do Stack Canaries, which are pretty self-explanatory. 05:49.710 --> 05:55.050 Address space layout randomization, where we're laying out the randomization of the address space. 05:55.080 --> 05:56.580 We're not going to put everything in one spot. 05:56.610 --> 05:58.080 We're going to randomize where it is. 05:58.110 --> 06:02.730 We're going to code sign meaning the developer actually signs the code that we're utilizing. 06:02.730 --> 06:07.530 Meaning that if something comes into play or a different code comes into play and we don't know where 06:07.530 --> 06:13.650 it came from, there needs to have a signer to that specific code so that we can verify the authenticity 06:13.650 --> 06:14.400 of that code. 06:14.400 --> 06:16.860 And of course, the last one is heap randomization. 06:16.890 --> 06:18.480 We're going to randomize that heap. 06:18.480 --> 06:24.630 And so it doesn't necessarily be more front and center on our aspect of our memorization to where somebody 06:24.630 --> 06:26.580 has full access to it right off the get go. 06:26.610 --> 06:29.850 We want it to be randomized within the process.