WEBVTT 0:00:03.840000 --> 0:00:07.800000 All right, so I'm currently in my Kali Linux system. 0:00:07.800000 --> 0:00:18.480000 And as you can see, I have the basic serialization or just a basic Python 0:00:18.480000 --> 0:00:25.240000 script here that serializes an object and deserializes it using pickle. 0:00:25.240000 --> 0:00:27.380000 So Python, you can see it's exactly the same. 0:00:27.380000 --> 0:00:28.860000 We have the example object. 0:00:28.860000 --> 0:00:32.800000 This is the data or object we want to serialize. 0:00:32.800000 --> 0:00:36.420000 And again, we're not looking into what we're doing with it, storing it 0:00:36.420000 --> 0:00:40.520000 or whatever. In this case, it's going to be storing it. 0:00:40.520000 --> 0:00:44.900000 And we want to serialize it with pickle and then deserialize it. 0:00:44.900000 --> 0:00:46.720000 So this is Python. 0:00:46.720000 --> 0:00:48.320000 You just import the pickle. 0:00:48.320000 --> 0:00:52.440000 We just import pickle right over here. 0:00:52.440000 --> 0:00:57.260000 And in this particular case, I can change this to whatever I want. 0:00:57.260000 --> 0:01:00.840000 And this would just be an example of user information or what, let's say, 0:01:00.840000 --> 0:01:03.500000 you would find in a cookie. 0:01:03.500000 --> 0:01:07.860000 And let's say the web app is serializing it and then storing it. 0:01:07.860000 --> 0:01:11.880000 And then we just have deserialization here just to show you the whole 0:01:11.880000 --> 0:01:16.400000 process. So I'll just navigate into my terminal and I have it here. 0:01:16.400000 --> 0:01:20.320000 It's called, let's see, not under app. 0:01:20.320000 --> 0:01:22.860000 That's for the second demo, but pickle basic. 0:01:22.860000 --> 0:01:30.240000 So I say Python 3 or just Python pickle basic.py hit enter. 0:01:30.240000 --> 0:01:34.160000 And you can see the first thing it does is it serializes the data. 0:01:34.160000 --> 0:01:39.000000 So remember, this is, remember the format I mentioned in the slides. 0:01:39.000000 --> 0:01:41.900000 This is not plain text or JSON. 0:01:41.900000 --> 0:01:43.060000 This is byte stream. 0:01:43.060000 --> 0:01:47.640000 So serialize data, you can see B byte stream right over here. 0:01:47.640000 --> 0:01:49.840000 And this is actually pretty nice. 0:01:49.840000 --> 0:01:53.480000 This is very, very suitable for transmission. 0:01:53.480000 --> 0:01:55.100000 And then it deserializes it. 0:01:55.100000 --> 0:01:59.860000 So you can see very, very important that you see that nothing has changed. 0:01:59.860000 --> 0:02:03.440000 Nothing at all. It's back to the original object. 0:02:03.440000 --> 0:02:06.880000 Right? In this case, it would just be data. 0:02:06.880000 --> 0:02:09.100000 But nothing has changed at all. 0:02:09.100000 --> 0:02:10.320000 Exactly how it was. 0:02:10.320000 --> 0:02:11.880000 That's the key. Right? 0:02:11.880000 --> 0:02:16.120000 And the bottom line is that in the case of transmission, this particular 0:02:16.120000 --> 0:02:24.760000 data stream here should be deserialized by the recipient without any issues. 0:02:24.760000 --> 0:02:31.060000 So very, very simple to understand what deserialization looks like or 0:02:31.060000 --> 0:02:32.800000 serialization looks like. 0:02:32.800000 --> 0:02:34.080000 And there we are. 0:02:34.080000 --> 0:02:38.340000 So I can actually change this to something like my own name here. 0:02:38.340000 --> 0:02:42.600000 If I run it again, you can see that right over here. 0:02:42.600000 --> 0:02:45.300000 So quite easy to understand. 0:02:45.300000 --> 0:02:47.480000 You obviously have your hex here. 0:02:47.480000 --> 0:02:49.200000 Very, very simple. 0:02:49.200000 --> 0:02:53.620000 But you can see that we are still able to make out information from the 0:02:53.620000 --> 0:02:57.360000 byte stream, like user, admin, etc. 0:02:57.360000 --> 0:03:02.800000 So another key point, serialization typically by default is not used or 0:03:02.800000 --> 0:03:09.920000 does not include encryption or does not make the data, does not change 0:03:09.920000 --> 0:03:17.920000 the serialized format into one that is encrypted or cannot be interpreted. 0:03:17.920000 --> 0:03:19.580000 And yeah, so there we are. 0:03:19.580000 --> 0:03:20.440000 Deserialized data. 0:03:20.440000 --> 0:03:21.860000 So that's the first example. 0:03:21.860000 --> 0:03:28.220000 Now, the second example here is a web app that I developed here called 0:03:28.220000 --> 0:03:29.380000 Pickla. All right. 0:03:29.380000 --> 0:03:32.940000 Now what it does, it's really very, very simple to understand. 0:03:32.940000 --> 0:03:34.200000 Extremely simple. 0:03:34.200000 --> 0:03:40.620000 So what it does, it's a web app that asks a user to submit a username 0:03:40.620000 --> 0:03:44.280000 via a form. So there's a field for your username. 0:03:44.280000 --> 0:03:49.800000 And then it serializes the username into a cookie using pickle. 0:03:49.800000 --> 0:03:57.360000 And when the user visits or revisits the page, the application deserializes 0:03:57.360000 --> 0:03:59.920000 the cookie to restore their username. 0:03:59.920000 --> 0:04:03.420000 So the bottom line is you specify username and then it uses the cookie 0:04:03.420000 --> 0:04:07.480000 to ensure that your username is always remembered and it greets you with 0:04:07.480000 --> 0:04:09.740000 the username that you selected. 0:04:09.740000 --> 0:04:10.640000 Very, very simple. 0:04:10.640000 --> 0:04:13.280000 You know, and this is actually used quite a bit. 0:04:13.280000 --> 0:04:16.860000 Let me just toggle word wrap here. 0:04:16.860000 --> 0:04:20.200000 There we are. And I'll just zoom out so you can see everything a little 0:04:20.200000 --> 0:04:24.540000 bit clearer. So we have an HTML template because this is using Flask. 0:04:24.540000 --> 0:04:28.580000 So there's an HTML template that will serve as the front end or will be 0:04:28.580000 --> 0:04:35.360000 rendered here. You can see we have a form just username right over here. 0:04:35.360000 --> 0:04:40.840000 And you just hit submit, sorry, in this case, save, which actually submits. 0:04:40.840000 --> 0:04:44.380000 Now moving down, you have the default, you know, the app route here. 0:04:44.380000 --> 0:04:48.820000 So just the root of the web server methods allowed are get and post. 0:04:48.820000 --> 0:04:55.440000 If the request method is, um, is post, so that means you're submitting 0:04:55.440000 --> 0:04:59.620000 your username. It saves your user preferences. 0:04:59.620000 --> 0:05:04.100000 So username is equal to request form dot get username guest. 0:05:04.100000 --> 0:05:10.060000 Okay. Um, and then user data is equal to username username. 0:05:10.060000 --> 0:05:13.600000 And then it's, this is the, uh, what's vulnerable here. 0:05:13.600000 --> 0:05:15.540000 So serialize user data with pickle. 0:05:15.540000 --> 0:05:18.680000 So serialize data is equal to pickle dot dumps. 0:05:18.680000 --> 0:05:23.260000 Uh, user data. So this value here responds is equal to make response. 0:05:23.260000 --> 0:05:28.280000 Render template string HTML template username is equal to username response 0:05:28.280000 --> 0:05:33.440000 dot set cookie. So this is where it's being set user data, serialize data, 0:05:33.440000 --> 0:05:39.320000 hex. So save serialize data in a cookie, uh, return response. 0:05:39.320000 --> 0:05:41.140000 Uh, and then this is where it's loaded. 0:05:41.140000 --> 0:05:44.980000 So once you've set a username, user data cookie is equal to request dot 0:05:44.980000 --> 0:05:47.020000 cookies dot get user data. 0:05:47.020000 --> 0:05:49.920000 If user data cookie, try. 0:05:49.920000 --> 0:05:51.860000 So do the following deserialize it. 0:05:51.860000 --> 0:05:54.960000 So insecure deserialization here. 0:05:54.960000 --> 0:05:59.000000 Um, you can see user data is equal to pickle dot loads, bytes from hex, 0:05:59.000000 --> 0:06:00.860000 user data cookie. 0:06:00.860000 --> 0:06:04.560000 Uh, username is equal to user data dot get username guest. 0:06:04.560000 --> 0:06:09.320000 Okay. Except, uh, exception where the username is guest else, username 0:06:09.320000 --> 0:06:10.660000 is equal to guest. 0:06:10.660000 --> 0:06:15.480000 So basically just handling, um, you know, exception handling in the event 0:06:15.480000 --> 0:06:19.000000 you don't just keep calling you guest. 0:06:19.000000 --> 0:06:24.340000 Um, and then return render template string, HTML template, uh, username 0:06:24.340000 --> 0:06:25.440000 equals username. 0:06:25.440000 --> 0:06:28.300000 So let me show you how, or what this looks like. 0:06:28.300000 --> 0:06:33.660000 Okay. So I'm just going to clear this out and, uh, in here, I'm just going 0:06:33.660000 --> 0:06:35.420000 to navigate into app. 0:06:35.420000 --> 0:06:44.040000 And I'll just say python app dot pi to set up a simple dev server here. 0:06:44.040000 --> 0:06:48.620000 And in my, uh, browser here, you can see we have, uh, welcome guests. 0:06:48.620000 --> 0:06:51.240000 This is the web app running local host port 5000. 0:06:51.240000 --> 0:06:54.860000 You can see it's getting this from somewhere very interesting. 0:06:54.860000 --> 0:06:57.360000 And you can then view the source here. 0:06:57.360000 --> 0:06:58.940000 You can see, oh, uh, very nice. 0:06:58.940000 --> 0:07:03.200000 This looks like it's dynamically generated based on some parameters. 0:07:03.200000 --> 0:07:04.640000 What are these parameters? 0:07:04.640000 --> 0:07:05.960000 Where can they be found? 0:07:05.960000 --> 0:07:07.100000 Maybe they're a cookie. 0:07:07.100000 --> 0:07:08.400000 Yeah, doesn't have a cookie. 0:07:08.400000 --> 0:07:10.500000 Interesting. Let's reload this a little bit here. 0:07:10.500000 --> 0:07:13.800000 If I hit save, ah, that changes. 0:07:13.800000 --> 0:07:15.080000 Okay. Any cookie? 0:07:15.080000 --> 0:07:18.860000 Yes. We have user data and this is saved. 0:07:18.860000 --> 0:07:20.820000 Uh, you can see this is serialized. 0:07:20.820000 --> 0:07:25.720000 This is a very, very good example of at least in the case of a python 0:07:25.720000 --> 0:07:28.400000 based web apps where pickle is used. 0:07:28.400000 --> 0:07:32.740000 Um, I'm not saying that, you know, you're going to find cookies, uh, or, 0:07:32.740000 --> 0:07:35.320000 you know, the value of a cookie being serialized. 0:07:35.320000 --> 0:07:40.480000 But whenever you see funny or zany cookies like this, uh, most likely 0:07:40.480000 --> 0:07:43.780000 you're dealing with something, something's going on, right? 0:07:43.780000 --> 0:07:47.540000 So, okay, here we go. 0:07:47.540000 --> 0:07:52.900000 Now, you know, what, what exactly can we, you know, I don't know, exploit 0:07:52.900000 --> 0:07:54.300000 this or something? 0:07:54.300000 --> 0:07:56.760000 Well, let's take a look. 0:07:56.760000 --> 0:08:02.040000 So I'll go back into Visual Studio code here. 0:08:02.040000 --> 0:08:06.280000 And if I take a look at the exploit I developed called pickler, it really 0:08:06.280000 --> 0:08:09.000000 is very, very simple. 0:08:09.000000 --> 0:08:14.180000 What this exploit does is it exploits the insecure deserialization vulnerability 0:08:14.180000 --> 0:08:18.660000 to essentially execute arbitrary code. 0:08:18.660000 --> 0:08:21.740000 So here we have a class called malicious payload. 0:08:21.740000 --> 0:08:25.380000 Uh, what it does is it utilizes os dot system. 0:08:25.380000 --> 0:08:31.020000 Um, and it, uh, essentially saves, um, it creates a file called exploit 0:08:31.020000 --> 0:08:35.780000 dot txt in the root of the web server or the web application. 0:08:35.780000 --> 0:08:40.700000 Um, and in that, uh, militia exploit dot txt file, it just has the following 0:08:40.700000 --> 0:08:45.360000 text malicious code executed as a POC to, to actually prove exploitation. 0:08:45.360000 --> 0:08:51.660000 So the first thing that needs to happen is, uh, right over here. 0:08:51.660000 --> 0:08:54.320000 Let's see if I can show you. 0:08:54.320000 --> 0:08:56.460000 So we have serialized the malicious payload. 0:08:56.460000 --> 0:08:59.700000 So payload is equal to pickle dot dumps malicious payload. 0:08:59.700000 --> 0:09:03.900000 Malicious payload is essentially, you know, the content, uh, or this file 0:09:03.900000 --> 0:09:05.120000 right over here. 0:09:05.120000 --> 0:09:10.220000 Okay. Um, so it prints the malicious payload in hex, uh, print payload 0:09:10.220000 --> 0:09:11.600000 dot hex. There we are. 0:09:11.600000 --> 0:09:13.680000 And then saves the payload to use it in a cookie. 0:09:13.680000 --> 0:09:19.160000 So with open, it creates a text file called malicious cookie, uh, dot 0:09:19.160000 --> 0:09:22.760000 txt. Um, and you know, it writes it there. 0:09:22.760000 --> 0:09:28.840000 So we then can utilize this cookie generates for us to exploit the insecure 0:09:28.840000 --> 0:09:32.800000 deserialized authorization vulnerability, which will consequently in the 0:09:32.800000 --> 0:09:37.000000 root of the web application or web server, create this exploit dot txt 0:09:37.000000 --> 0:09:41.420000 file, which we can just call it, you know, POC, for example, right? 0:09:41.420000 --> 0:09:42.960000 Let's just call it POC. 0:09:42.960000 --> 0:09:49.700000 So the bottom line is if I go into the root of the web application, I'll 0:09:49.700000 --> 0:09:54.380000 just open up a folder here, desktop, and we go into pickler. 0:09:54.380000 --> 0:09:58.900000 So first things first, the web app is being stored in the app directory. 0:09:58.900000 --> 0:10:00.440000 There's nothing else in here. 0:10:00.440000 --> 0:10:02.100000 You can see it's just app.py. 0:10:02.100000 --> 0:10:08.320000 So hopefully if successful, uh, POC dot txt will be saved in here, therefore 0:10:08.320000 --> 0:10:13.820000 verifying successful exploitation of the, you know, uh, insecure deserialization 0:10:13.820000 --> 0:10:18.060000 vulnerability. Pickle dot basic is just the basic demo I showed you and 0:10:18.060000 --> 0:10:20.020000 pickler is the exploit, right? 0:10:20.020000 --> 0:10:23.960000 So what should happen firstly when we run pickler is it should create 0:10:23.960000 --> 0:10:29.440000 a file, a txt file called, is essentially the payload just called malicious 0:10:29.440000 --> 0:10:34.360000 cookie dot txt within open up that file, copy the value of that cookie, 0:10:34.360000 --> 0:10:36.380000 which is, uh, you know, what we want. 0:10:36.380000 --> 0:10:40.660000 And then in our browser will replace the original one with this new one, 0:10:40.660000 --> 0:10:46.980000 which will consequently trigger the web application to create this txt 0:10:46.980000 --> 0:10:52.840000 file here, the POC, therefore verifying that there's successful exploitation 0:10:52.840000 --> 0:10:56.820000 of the insecure deserialization vulnerability. 0:10:56.820000 --> 0:11:00.120000 So what we do is, uh, I'll open up a new tab. 0:11:00.120000 --> 0:11:04.640000 There we are. And we want to run pickler dot pie. 0:11:04.640000 --> 0:11:08.940000 So Python pickler dot pie, we hit enter. 0:11:08.940000 --> 0:11:12.720000 There we are malicious payload in the format that we want, which is hex, 0:11:12.720000 --> 0:11:17.540000 right? So this is the cookie or the value of the cookie for user data. 0:11:17.540000 --> 0:11:21.800000 So we copy this and by the way, now we'll see that we have malicious cookie 0:11:21.800000 --> 0:11:25.920000 dot txt, which just contains exactly what we generated. 0:11:25.920000 --> 0:11:28.680000 Make sure, you know, we don't want anything trailing there, but we've 0:11:28.680000 --> 0:11:32.640000 already copied the proper version or correctly formatted one. 0:11:32.640000 --> 0:11:34.720000 So I'll reload this again. 0:11:34.720000 --> 0:11:37.980000 You can see right now it's not set to anything. 0:11:37.980000 --> 0:11:41.040000 And by the way, we'll analyze this with burp suite in a second, but, you 0:11:41.040000 --> 0:11:45.740000 know, we can actually, um, let me open up dev tools here. 0:11:45.740000 --> 0:11:47.400000 Um, there we go. 0:11:47.400000 --> 0:11:51.280000 We go to the inspector console right over here. 0:11:51.280000 --> 0:11:53.860000 We can disregard the cookie security options. 0:11:53.860000 --> 0:11:58.100000 Not really important or applicable here. 0:11:58.100000 --> 0:11:59.620000 We go to the debugger. 0:11:59.620000 --> 0:12:02.600000 Actually, sorry network. 0:12:02.600000 --> 0:12:05.120000 No, no, let's go into. 0:12:05.120000 --> 0:12:05.920000 Yeah, let's check. 0:12:05.920000 --> 0:12:09.460000 Take a look at the debugger here. 0:12:09.460000 --> 0:12:13.940000 I'm not sure that outline storage cookies. 0:12:13.940000 --> 0:12:16.760000 There we are. So we have the cookie here. 0:12:16.760000 --> 0:12:17.900000 Just zoom in so you can see. 0:12:17.900000 --> 0:12:26.680000 So this is the one that, um, um, this particular cookie here is the one 0:12:26.680000 --> 0:12:30.160000 that is tied to, you know, this particular username. 0:12:30.160000 --> 0:12:35.980000 So the bottom line is, uh, what we can do is just replace this here with 0:12:35.980000 --> 0:12:40.800000 the one we, you know, the pickle exploit generated and I'll hit enter. 0:12:40.800000 --> 0:12:42.280000 Okay. There we go. 0:12:42.280000 --> 0:12:43.880000 Very nice. Very nice. 0:12:43.880000 --> 0:12:47.840000 All right. Now we'll just hit enter. 0:12:47.840000 --> 0:12:49.760000 Okay. And it says welcome guest. 0:12:49.760000 --> 0:12:50.720000 All right. Interesting. 0:12:50.720000 --> 0:12:55.240000 Let's take a look at, uh, what's stored in the app folder. 0:12:55.240000 --> 0:12:57.960000 And there we are, BOC.txt. 0:12:57.960000 --> 0:13:01.040000 And if we open this up, you can see malicious code executed. 0:13:01.040000 --> 0:13:07.240000 So that is in a nutshell, uh, you know, how to identify and exploit a, 0:13:07.240000 --> 0:13:09.700000 an insecurity serialization vulnerability. 0:13:09.700000 --> 0:13:16.280000 In this case, this is limited to, uh, this is limited to pickle, uh, in 0:13:16.280000 --> 0:13:19.580000 Python, Python based web applications. 0:13:19.580000 --> 0:13:21.480000 Um, we go into cookies. 0:13:21.480000 --> 0:13:24.040000 You can now see we have that one there. 0:13:24.040000 --> 0:13:27.540000 And that's typically how it is used. 0:13:27.540000 --> 0:13:30.920000 So what does the exploit do if we revisit it? 0:13:30.920000 --> 0:13:36.740000 Well, what it does is just taking or utilizing, let's say, knowledge of, 0:13:36.740000 --> 0:13:46.580000 um, you know, what this exploit does is it is factoring in. 0:13:46.580000 --> 0:13:52.900000 Or essentially taking advantage of the fact that the, you know, um, the 0:13:52.900000 --> 0:13:58.980000 serialization function or the serialization process, I should say, or 0:13:58.980000 --> 0:14:02.160000 deserialization process has no validation. 0:14:02.160000 --> 0:14:07.100000 Um, right over here, you can see deserialize. 0:14:07.100000 --> 0:14:11.700000 And, uh, in this particular case, you can see what it does pretty much, 0:14:11.700000 --> 0:14:15.120000 you know, it's just giving you a, a cookie value. 0:14:15.120000 --> 0:14:21.900000 Um, and, uh, in this particular case, malicious payload comes into play. 0:14:21.900000 --> 0:14:26.700000 Uh, right. Of you, we have a class that's doing something malicious. 0:14:26.700000 --> 0:14:31.560000 In this case, actually writing a file to the file system of the underlying 0:14:31.560000 --> 0:14:34.660000 server. In this case, we're not doing anything malicious. 0:14:34.660000 --> 0:14:38.220000 We're just saving it as poc.txt, but that's how dangerous it is. 0:14:38.220000 --> 0:14:43.220000 And then we have saying our payload is going to be equal to, I want you 0:14:43.220000 --> 0:14:48.520000 to use pickle to serialize the malicious payload, which is essentially 0:14:48.520000 --> 0:14:55.800000 a function that, you know, performs, it's essentially, uh, you know, um, 0:14:55.800000 --> 0:15:02.260000 executing commands, uh, on the system and then just print it out in hex 0:15:02.260000 --> 0:15:07.100000 format. And based on that, because of how the deserialization process 0:15:07.100000 --> 0:15:11.920000 works, you can see right over here just directly says pickle.loads bytes. 0:15:11.920000 --> 0:15:14.220000 From hex user data cookie. 0:15:14.220000 --> 0:15:15.680000 There's no validation of anything. 0:15:15.680000 --> 0:15:17.740000 There's no sanitization. 0:15:17.740000 --> 0:15:20.220000 Um, and, uh, there we are. 0:15:20.220000 --> 0:15:22.520000 So this is quite dangerous. 0:15:22.520000 --> 0:15:26.920000 So in essence, the issue is the deserialization. 0:15:26.920000 --> 0:15:31.660000 So the application pretty much blindly deserializes data from the cookie, 0:15:31.660000 --> 0:15:33.980000 assuming it is safe. 0:15:33.980000 --> 0:15:37.360000 And you know, as a result of that, as a result of that, the attacker can 0:15:37.360000 --> 0:15:41.520000 replace the serialized cookie with a malicious payload, uh, still in a 0:15:41.520000 --> 0:15:43.340000 cookie format, right? 0:15:43.340000 --> 0:15:46.180000 Um, and, uh, yeah. 0:15:46.180000 --> 0:15:49.900000 So the reason why this works or, you know, what caused the vulnerability 0:15:49.900000 --> 0:15:52.320000 is a blind trust in user input. 0:15:52.320000 --> 0:15:56.500000 So the application assumes that data in the cookie is safe and directly 0:15:56.500000 --> 0:15:57.680000 deserializes it. 0:15:57.680000 --> 0:16:03.160000 And then, uh, another reason why this works or as, you know, as to what 0:16:03.160000 --> 0:16:07.300000 caused this is pickles execution capability. 0:16:07.300000 --> 0:16:12.140000 So during deserialization, pickle can execute arbitrary code via the reduce 0:16:12.140000 --> 0:16:15.300000 method, which is what we used in our exploit here. 0:16:15.300000 --> 0:16:19.960000 So we're sort of taking advantage of the serialization framework, which 0:16:19.960000 --> 0:16:23.340000 is pickle, and some of its capabilities. 0:16:23.340000 --> 0:16:27.660000 Uh, and if that is left unchecked, um, then you can actually leverage 0:16:27.660000 --> 0:16:32.400000 pickle itself to do malicious things, which in this case, we did. 0:16:32.400000 --> 0:16:35.960000 So that's pretty much it, uh, in terms of the practical demonstration. 0:16:35.960000 --> 0:16:40.740000 Hopefully you learned a little bit about what serialization and, uh, deserialization 0:16:40.740000 --> 0:16:45.320000 is all about, as well as, uh, again, through the use of a basic example, 0:16:45.320000 --> 0:16:49.400000 what, um, you know, insecure deserialization looks like, uh, with that 0:16:49.400000 --> 0:16:52.680000 being said, that brings us to the end of the practical demonstration section 0:16:52.680000 --> 0:16:55.940000 of this video. All right. 0:16:55.940000 --> 0:16:59.560000 So that was an introduction to insecure deserialization. 0:16:59.560000 --> 0:17:03.400000 We've covered a lot of ground and I'm very glad that we did because now 0:17:03.400000 --> 0:17:08.820000 as we move into the, uh, language specific deserialization vulnerabilities, 0:17:08.820000 --> 0:17:14.720000 you know, in Java, PHP.net, et cetera, you'll be, uh, I think you're well 0:17:14.720000 --> 0:17:20.060000 equipped, uh, not only, uh, in terms of understanding, um, you know, all 0:17:20.060000 --> 0:17:24.820000 the nuances associated with these languages in the context of, you know, 0:17:24.820000 --> 0:17:30.580000 deserialization, but, uh, I think you understand exactly what this, a 0:17:30.580000 --> 0:17:32.660000 mystical process is all about. 0:17:32.660000 --> 0:17:36.580000 And, uh, hopefully you have an idea now as to where the vulnerabilities 0:17:36.580000 --> 0:17:40.860000 arise from through that, uh, pickle example, pickle, as I call it. 0:17:40.860000 --> 0:17:44.200000 Uh, with that being said, that's going to be it for this video and I'll 0:17:44.200000 --> 0:17:45.820000 be seeing you in the next video.