WEBVTT

0:00:03.600000 --> 0:00:06.460000
 Hello everyone and welcome.

0:00:06.460000 --> 0:00:12.200000
 In this video we're going to be taking a
 look at Java in security serialization.

0:00:12.200000 --> 0:00:17.580000
 So we're going to start off by getting
 an understanding of what the typical

0:00:17.580000 --> 0:00:25.100000
 serialization slash deserialization
 process looks like in Java based web

0:00:25.100000 --> 0:00:28.960000
 applications and Java in general.

0:00:28.960000 --> 0:00:36.620000
 And we'll also be exploring some of
 the key things to look out for, sort

0:00:36.620000 --> 0:00:44.420000
 of how to detect Java serialization as
 well as how to utilize Wysos serial,

0:00:44.420000 --> 0:00:50.060000
 specifically in this case for
 Java insecure deserialization.

0:00:50.060000 --> 0:00:52.300000
 So there's quite a bit to cover.

0:00:52.300000 --> 0:00:57.300000
 We'll start off with the theoretical
 stuff first and then the practical

0:00:57.300000 --> 0:01:02.220000
 section will involve the use of
 a live lab on the INE platform.

0:01:02.220000 --> 0:01:05.900000
 So you know this video has
 a lab associated with it.

0:01:05.900000 --> 0:01:10.840000
 And that's what we're going to be using
 to explore the process of exploiting,

0:01:10.840000 --> 0:01:16.980000
 identifying exploiting a an insecure
 deserialization vulnerability and

0:01:16.980000 --> 0:01:18.740000
 a Java based web application.

0:01:18.740000 --> 0:01:24.580000
 So to kick things off, let's get an
 understanding of the serialization

0:01:24.580000 --> 0:01:27.280000
 and deserialization process in Java.

0:01:27.280000 --> 0:01:32.840000
 So in Java serialization is the process
 of again like we saw in the previous

0:01:32.840000 --> 0:01:38.000000
 video converting an object's state into
 a byte stream so that it can be

0:01:38.000000 --> 0:01:40.720000
 stored or transmitted.

0:01:40.720000 --> 0:01:44.380000
 The serialized data can later be deserialized
 to recreate the original

0:01:44.380000 --> 0:01:50.020000
 object in memory and Java utilizes
 the serializable interface to mark

0:01:50.020000 --> 0:01:53.080000
 objects that can be serialized.

0:01:53.080000 --> 0:01:58.320000
 So Java provides built-in support for
 serialization and deserialization

0:01:58.320000 --> 0:02:03.440000
 through object output stream and
 object input stream classes.

0:02:03.440000 --> 0:02:05.120000
 So keep that in mind.

0:02:05.120000 --> 0:02:10.000000
 Now before we dig into exploiting insecure
 deserialization in Java, let's

0:02:10.000000 --> 0:02:14.680000
 take a look at how to create a serialized
 object in order to understand

0:02:14.680000 --> 0:02:18.340000
 the process better or to understand
 the serialization, deserialization

0:02:18.340000 --> 0:02:23.140000
 process. So nothing to do with insecure
 deserialization just in general

0:02:23.140000 --> 0:02:25.920000
 how it's typically performed in Java.

0:02:25.920000 --> 0:02:30.380000
 Now this will be theoretical but if
 you want to recreate it, you can.

0:02:30.380000 --> 0:02:36.760000
 If so, you pretty much just need Java
 compiler and a text editor or you

0:02:36.760000 --> 0:02:39.380000
 can be fancy and use an IDE.

0:02:39.380000 --> 0:02:44.300000
 And if you want to get access to Java
 compiler, just install the latest

0:02:44.300000 --> 0:02:49.960000
 JDK and JRE on your operating
 system, whatever that may be.

0:02:49.960000 --> 0:02:54.660000
 So in the case of this example, we're
 going to be creating two files or

0:02:54.660000 --> 0:02:56.260000
 taking a look at two files.

0:02:56.260000 --> 0:02:58.020000
 The first one is item to Java.

0:02:58.020000 --> 0:03:02.720000
 That's going to hold the code for a
 class called or class named item.

0:03:02.720000 --> 0:03:07.040000
 So it's just called item and then serialize
 dot Java will contain the

0:03:07.040000 --> 0:03:14.300000
 serialization logic or the code that
 essentially perform or serialize

0:03:14.300000 --> 0:03:21.080000
 the object. So in order to utilize
 serialization in Java, the program

0:03:21.080000 --> 0:03:24.260000
 must import the Java IO
 serializable package.

0:03:24.260000 --> 0:03:29.340000
 Moreover, for the class to be serialized,
 it must implement a serializable

0:03:29.340000 --> 0:03:34.580000
 interface. So if you want a class to
 be serialized, you must, as it says

0:03:34.580000 --> 0:03:38.700000
 here, implement a serializable interface
 and you'll see what this looks

0:03:38.700000 --> 0:03:43.720000
 like shortly. So in this case, we're
 starting off with item dot Java.

0:03:43.720000 --> 0:03:48.300000
 So item dot Java is a symbol class
 that has two fields ID and name.

0:03:48.300000 --> 0:03:52.840000
 So you can see them here, we have the serialization,
 sorry, not serialization,

0:03:52.840000 --> 0:03:59.360000
 the serializable interface, as it states
 here, implemented or initialized.

0:03:59.360000 --> 0:04:03.420000
 Firstly, you know, we can see import
 Java IO serializable, public class

0:04:03.420000 --> 0:04:08.500000
 item implements, serializable, and
 then the two fields ID and name, ID

0:04:08.500000 --> 0:04:12.180000
 is integer, the name is string.

0:04:12.180000 --> 0:04:14.780000
 And you can see public,
 we have a function here.

0:04:14.780000 --> 0:04:18.880000
 So public item that takes
 in the ID and the name.

0:04:18.880000 --> 0:04:23.640000
 And we can say this dot ID is equal
 to ID, this dot name equals name.

0:04:23.640000 --> 0:04:28.120000
 So serializable classes can contain
 many fields and methods.

0:04:28.120000 --> 0:04:34.160000
 And now we'll take a look at the other
 file that'll essentially, you know,

0:04:34.160000 --> 0:04:37.840000
 facilitate the serialization here.

0:04:37.840000 --> 0:04:41.520000
 So this is the serialized or Java file.

0:04:41.520000 --> 0:04:46.540000
 As you can see, first, we will create
 an instance of the item class.

0:04:46.540000 --> 0:04:57.960000
 So instance, sort of like calling, if
 you will, if you have a two file,

0:04:57.960000 --> 0:05:03.400000
 so you can see serialize Java class,
 serialize, you know, we have the

0:05:03.400000 --> 0:05:04.760000
 object right over here.

0:05:04.760000 --> 0:05:07.780000
 So item S one is equal to new item.

0:05:07.780000 --> 0:05:10.700000
 And the ID is just going to be 123.

0:05:10.700000 --> 0:05:14.220000
 And then book, so essentially, you
 know, creating the object and then

0:05:14.220000 --> 0:05:19.160000
 next to it, or after that, sorry, creating
 the stream and writing the

0:05:19.160000 --> 0:05:25.040000
 object. So file output stream, F out
 is equal to new, file output stream,

0:05:25.040000 --> 0:05:31.300000
 you know, we're saving it as data
 dot sir, or se are if you will.

0:05:31.300000 --> 0:05:36.180000
 So object output stream out is equal
 to new object output stream, F out.

0:05:36.180000 --> 0:05:42.700000
 So out, right object S one out, flush,
 close the stream, close, outdoor

0:05:42.700000 --> 0:05:47.020000
 close. And then you can see just, you
 know, prints out of the screen,

0:05:47.020000 --> 0:05:50.600000
 the serialized data,
 save to data dot sir.

0:05:50.600000 --> 0:05:55.700000
 Very simple. So the serialize class
 makes use of the item class, as it

0:05:55.700000 --> 0:06:00.260000
 converts the instance of the item class
 into a stream of bytes, much harder

0:06:00.260000 --> 0:06:05.500000
 to do in Java than, than with Python
 as we saw in the previous video.

0:06:05.500000 --> 0:06:10.820000
 Anyway, it's pretty much following
 the same sort of methodology here.

0:06:10.820000 --> 0:06:16.400000
 And, you know, before compilation, in this
 case, I've just given you instructions,

0:06:16.400000 --> 0:06:19.860000
 how you can sort of recreate it, but
 you know, before compiling it with

0:06:19.860000 --> 0:06:23.780000
 Java C or the Java compiler, just ensure
 they're in the same directory

0:06:23.780000 --> 0:06:26.700000
 as one is calling the other, if you will.


0:06:26.700000 --> 0:06:31.240000
 And you can see right over here,
 after after the compilation.

0:06:31.240000 --> 0:06:36.900000
 So, you know, Java, C item, item dot Java
 serialize, or Java, Java serialize,

0:06:36.900000 --> 0:06:41.260000
 serialize data saved to data dot sir.

0:06:41.260000 --> 0:06:47.180000
 And then we, when we cut that out, you
 can see that that now is, you can

0:06:47.180000 --> 0:06:50.840000
 see that data dot sir, or the data
 dot sir file is in binary format.

0:06:50.840000 --> 0:06:54.840000
 And apart from some strings that disclose
 what the serialized data might

0:06:54.840000 --> 0:06:57.220000
 be, they're also some
 non ASCII characters.

0:06:57.220000 --> 0:07:01.300000
 If you ever looking at detecting or
 identifying whether you're looking

0:07:01.300000 --> 0:07:11.500000
 at a serialized data, you know, you
 can look for the file begins with,

0:07:11.500000 --> 0:07:16.360000
 you know, the following string of bytes,
 hex in this case, which is a

0:07:16.360000 --> 0:07:19.480000
 standard Java serialized
 format signature.

0:07:19.480000 --> 0:07:23.000000
 So, the bottom line is that whenever
 you see binary data starting with

0:07:23.000000 --> 0:07:29.080000
 those bytes, you can suspect or it's
 fairly obvious that, you know, it

0:07:29.080000 --> 0:07:31.500000
 contains serialized Java objects.

0:07:31.500000 --> 0:07:36.040000
 So, this is now the file or the code that
 will perform the deserialization.

0:07:36.040000 --> 0:07:37.720000
 You can see fairly simple.

0:07:37.720000 --> 0:07:42.460000
 We have a class here called deserialize,
 creating the stream to read objects

0:07:42.460000 --> 0:07:47.580000
 object input stream in is equal to new
 object input stream new file input

0:07:47.580000 --> 0:07:49.300000
 stream. We're just loading the file.

0:07:49.300000 --> 0:07:50.740000
 So data dot sir.

0:07:50.740000 --> 0:07:54.880000
 And then item s is equal to
 item dot in a red object.

0:07:54.880000 --> 0:07:59.160000
 So we're now reading the object and then
 printing the date of the serialized

0:07:59.160000 --> 0:08:06.440000
 objects, we just say system dot our print
 line s dot id, then concatenate

0:08:06.440000 --> 0:08:11.900000
 plus, you know, s name, we close the
 stream and that's pretty much it.

0:08:11.900000 --> 0:08:15.280000
 So this code will retrieve the serialized
 data, you know, essentially

0:08:15.280000 --> 0:08:19.860000
 deserialize the serialized
 data from the binary file.

0:08:19.860000 --> 0:08:25.520000
 And in this case, I've just called the
 file or this Java file deserialize

0:08:25.520000 --> 0:08:30.580000
 dot Java. So fairly simple to run this
 yourself, you can see after compilation

0:08:30.580000 --> 0:08:34.300000
 and running the deserialize class, we
 can see that the object was properly

0:08:34.300000 --> 0:08:37.240000
 reconstructed without losing any data.

0:08:37.240000 --> 0:08:42.540000
 So 123 book, if you remember, that's
 what we put in the just go back here

0:08:42.540000 --> 0:08:46.240000
 as a few steps. So you can see that
 here, what we put in serialized or

0:08:46.240000 --> 0:08:50.740000
 Java. So when we created the object,
 it was 123 book 123 being the ID

0:08:50.740000 --> 0:08:52.420000
 book being named.

0:08:52.420000 --> 0:08:59.040000
 And now if we go in here, you can see
 after deserialization, it pretty

0:08:59.040000 --> 0:09:02.920000
 much, you know, reconstructs the object
 without, you know, any changes

0:09:02.920000 --> 0:09:04.300000
 or losing anything.

0:09:04.300000 --> 0:09:08.080000
 Now there's a couple of conditions you
 need to be aware of in order for,

0:09:08.080000 --> 0:09:14.620000
 you know, insecure deserialization to,
 to bear itself in Java based web

0:09:14.620000 --> 0:09:19.700000
 applications. And in essence, what I'm
 listing out here is what to look

0:09:19.700000 --> 0:09:23.840000
 out for. So a potentially exploitable
 condition in Java occurs when the

0:09:23.840000 --> 0:09:29.120000
 read object or similar function is called
 on user controlled object and,

0:09:29.120000 --> 0:09:32.480000
 and later a method on
 that object is called.

0:09:32.480000 --> 0:09:36.500000
 What that means is that an attacker is
 able to craft an object containing

0:09:36.500000 --> 0:09:41.680000
 multiple nested properties that upon being
 called will do something completely

0:09:41.680000 --> 0:09:45.180000
 different. For example, hijack the
 the called method by implementing,

0:09:45.180000 --> 0:09:50.820000
 let's say a dynamic proxy and an invocation
 handler in the serialized

0:09:50.820000 --> 0:09:52.720000
 objects properties.

0:09:52.720000 --> 0:10:00.400000
 So that brings us to an important aspect
 of, you know, insecure deserialization

0:10:00.400000 --> 0:10:02.980000
 in Java. And that is gadgets.

0:10:02.980000 --> 0:10:09.120000
 So every property or method that is
 part of a nested exploit object is

0:10:09.120000 --> 0:10:10.220000
 called a gadget.

0:10:10.220000 --> 0:10:14.520000
 All right. Now there are some specific
 libraries that were found to contain

0:10:14.520000 --> 0:10:19.700000
 some universal gadgets used to build
 serialized exploit objects.

0:10:19.700000 --> 0:10:24.540000
 These libraries are called gadget libraries
 informally, of course, but

0:10:24.540000 --> 0:10:28.560000
 the concept of gadgets, if you want to
 learn more about them, was presented

0:10:28.560000 --> 0:10:34.860000
 at the following talk, a link to which
 has been added to the slides here.

0:10:34.860000 --> 0:10:45.240000
 But you can see, you know, it's pretty
 much just a little bit more about

0:10:45.240000 --> 0:10:48.920000
 gadgets. Now there's a set of common
 libraries that have been identified

0:10:48.920000 --> 0:10:51.020000
 as gadget libraries.

0:10:51.020000 --> 0:10:54.820000
 It's very important to note that this
 does not mean that they are insecure

0:10:54.820000 --> 0:10:57.680000
 by design, which you might
 have been thinking.

0:10:57.680000 --> 0:11:04.240000
 It only means this is very important that
 in the event insecure deserialization

0:11:04.240000 --> 0:11:08.940000
 is performed while these libraries are
 loaded into the class path of the

0:11:08.940000 --> 0:11:12.440000
 running application, the attacker can
 abuse them to construct a known

0:11:12.440000 --> 0:11:16.860000
 gadget chain that will result
 in successful exploitation.

0:11:16.860000 --> 0:11:21.100000
 For example, common libraries that
 were identified as vulnerable are,

0:11:21.100000 --> 0:11:23.520000
 you know, it's called common collections.


0:11:23.520000 --> 0:11:24.580000
 And then you have one to six.

0:11:24.580000 --> 0:11:28.420000
 So it'll be common collections one,
 two, three, four, five, six, for,

0:11:28.420000 --> 0:11:35.280000
 you know, it's essentially used to, to
 specify a different set or different

0:11:35.280000 --> 0:11:37.880000
 collection of these libraries.

0:11:37.880000 --> 0:11:42.720000
 But how are these used or implemented?

0:11:42.720000 --> 0:11:49.700000
 Or, you know, in what context do we
 get to sort of utilize or test for,

0:11:49.700000 --> 0:11:54.460000
 you know, some of these common
 libraries that are vulnerable?

0:11:54.460000 --> 0:11:58.880000
 Well, that's where the infamous
 tool comes into play.

0:11:58.880000 --> 0:12:05.060000
 And that is why so serial, very,
 very nice, very cool name.

0:12:05.060000 --> 0:12:10.000000
 So why so serial, you know, can be used
 to perform exploitation of insecure

0:12:10.000000 --> 0:12:13.860000
 Java deserialization vulnerabilities
 among others.

0:12:13.860000 --> 0:12:18.140000
 And why so serial contains multiple
 modules that are suited to various

0:12:18.140000 --> 0:12:21.060000
 Java deserialization exploitation
 scenarios.

0:12:21.060000 --> 0:12:25.460000
 So that begs the question, what, you know,
 tell me more about why so serial

0:12:25.460000 --> 0:12:31.000000
 while, well, why so serial is a Java based
 tool designed to generate malicious

0:12:31.000000 --> 0:12:36.400000
 serialized payloads that can be used
 to exploit insecure deserialization

0:12:36.400000 --> 0:12:37.300000
 vulnerabilities.

0:12:37.300000 --> 0:12:41.520000
 So it leverages known vulnerabilities in
 popular Java libraries, for example,

0:12:41.520000 --> 0:12:46.500000
 Apache, Apache Commons collections,
 spring, etc.

0:12:46.500000 --> 0:12:57.100000
 in order to create payloads that are making
 advantage of the deserialization

0:12:57.100000 --> 0:12:59.480000
 process, these payloads.

0:12:59.480000 --> 0:13:05.360000
 So why so serial can be used to test
 for, you know, these, what do you

0:13:05.360000 --> 0:13:10.500000
 call them, these vulnerable, as I mentioned,
 them here, it can be used

0:13:10.500000 --> 0:13:16.840000
 to test for these, these vulnerable libraries,
 and then generate payloads

0:13:16.840000 --> 0:13:20.140000
 appropriate for, you know, for
 the appropriate library.

0:13:20.140000 --> 0:13:26.460000
 But more importantly, create payloads allow
 you to execute arbitrary commands

0:13:26.460000 --> 0:13:29.060000
 during the deserialization process.

0:13:29.060000 --> 0:13:32.940000
 So how does why so serial work?

0:13:32.940000 --> 0:13:36.540000
 Well, it creates serialized payloads
 that trigger malicious behavior when

0:13:36.540000 --> 0:13:40.900000
 deserialize. So in this case, this would
 be an example of how to use why

0:13:40.900000 --> 0:13:49.100000
 so serial. So it's a payload or Java,
 and then you specify the collections,

0:13:49.100000 --> 0:13:53.720000
 in this case, common, commons collections
 one, and then you specify what

0:13:53.720000 --> 0:13:54.880000
 you want executed.

0:13:54.880000 --> 0:13:58.860000
 So, you know, in this case, who am
 I, as a standard system command or

0:13:58.860000 --> 0:14:04.480000
 Linux, your output, you save it as payload
 or so, whatever, and then this

0:14:04.480000 --> 0:14:08.120000
 command pretty much generates a payload
 that executes a system command.

0:14:08.120000 --> 0:14:11.140000
 In this case, who am I, when deserialize?


0:14:11.140000 --> 0:14:14.500000
 So the generated payload is sent to
 the vulnerable application through

0:14:14.500000 --> 0:14:20.580000
 attack vectors, such as cookies, HTTP requests
 or files, when the application

0:14:20.580000 --> 0:14:23.880000
 deserializes the payload,
 the command is executed.

0:14:23.880000 --> 0:14:27.200000
 So very, very powerful,
 very, very useful.

0:14:27.200000 --> 0:14:30.720000
 With that being said now, we're going
 to take a look at an example of

0:14:30.720000 --> 0:14:35.980000
 how to exploit, insecure deserialization
 vulnerability in a Java based

0:14:35.980000 --> 0:14:38.540000
 web application, in this case, Jenkins.

0:14:38.540000 --> 0:14:42.900000
 So in order to do this, we're going
 to be leveraging a lab on the INE

0:14:42.900000 --> 0:14:47.040000
 platform. So this video has
 a lab associated with it.

0:14:47.040000 --> 0:14:49.020000
 It's just below this video.

0:14:49.020000 --> 0:14:53.360000
 And it pretty much contains all documentation
 or walkthrough of, you know,

0:14:53.360000 --> 0:14:54.600000
 all the exploitation steps.

0:14:54.600000 --> 0:14:59.960000
 If you'd like to go through it that way,
 if you prefer reading above listening

0:14:59.960000 --> 0:15:01.380000
 to me, it's totally fine.

0:15:01.380000 --> 0:15:05.240000
 Or you can actually go through the lab first
 and then go through my walkthrough

0:15:05.240000 --> 0:15:07.260000
 entirely up to you.

0:15:07.260000 --> 0:15:11.840000
 The lab will provide you the access
 to a preconfigured calilinic system.

0:15:11.840000 --> 0:15:13.340000
 And we have the target web app.

0:15:13.340000 --> 0:15:16.860000
 So fairly straightforward as you're
 probably used to by now.

0:15:16.860000 --> 0:15:19.180000
 So I'm going to start up my lab.

0:15:19.180000 --> 0:15:21.300000
 And I'll see you in there
 in a couple of seconds.