WEBVTT

00:00:00.000 --> 00:00:06.330 align:middle line:90%


00:00:06.330 --> 00:00:10.450 align:middle line:84%
Welcome to Insecure
Deserialization session.

00:00:10.450 --> 00:00:14.150 align:middle line:84%
In this first part, we will
focus on threat analysis.

00:00:14.150 --> 00:00:16.554 align:middle line:84%
We will take our time to
discuss what serialization

00:00:16.554 --> 00:00:18.610 align:middle line:90%
and deserialization is.

00:00:18.610 --> 00:00:21.550 align:middle line:84%
Then we will discuss how
the system can be harmed,

00:00:21.550 --> 00:00:24.190 align:middle line:84%
the impact of
successful exploitation,

00:00:24.190 --> 00:00:26.290 align:middle line:84%
and give you some
insights to identify who

00:00:26.290 --> 00:00:28.460 align:middle line:90%
may want to harm your system.

00:00:28.460 --> 00:00:31.030 align:middle line:84%
Let's start with
serialization, the process

00:00:31.030 --> 00:00:33.400 align:middle line:84%
of turning some object
into a data format that

00:00:33.400 --> 00:00:35.440 align:middle line:90%
can be restored later.

00:00:35.440 --> 00:00:38.740 align:middle line:84%
Usually, this is done in order
to save objects to storage

00:00:38.740 --> 00:00:41.820 align:middle line:84%
or to send them as
part of communications.

00:00:41.820 --> 00:00:44.250 align:middle line:84%
Some programming languages
have native support

00:00:44.250 --> 00:00:46.920 align:middle line:84%
for serialization
and deserialization,

00:00:46.920 --> 00:00:50.580 align:middle line:84%
but others require external
libraries to do it.

00:00:50.580 --> 00:00:52.980 align:middle line:84%
Since PHP supports
it natively, we

00:00:52.980 --> 00:00:55.620 align:middle line:84%
will discuss the topic
using some PHP snippets,

00:00:55.620 --> 00:00:57.770 align:middle line:84%
but keep in mind, I'm
not saying that PHP

00:00:57.770 --> 00:01:01.420 align:middle line:84%
is less secure than any
other programming language.

00:01:01.420 --> 00:01:04.920 align:middle line:84%
So on the left, we have the
person class definition.

00:01:04.920 --> 00:01:07.140 align:middle line:84%
It has a private
property called name,

00:01:07.140 --> 00:01:09.870 align:middle line:84%
and a public constructor
which accepts a name

00:01:09.870 --> 00:01:13.380 align:middle line:84%
to be passed as argument to
set the private property.

00:01:13.380 --> 00:01:16.500 align:middle line:84%
Instances of person will be
able to bring their name,

00:01:16.500 --> 00:01:19.860 align:middle line:84%
calling it display
underscore name method.

00:01:19.860 --> 00:01:23.840 align:middle line:84%
Then we have a class
instance whose name is Paulo.

00:01:23.840 --> 00:01:26.500 align:middle line:84%
Finally, we serialize
our instance.

00:01:26.500 --> 00:01:29.900 align:middle line:84%
This means that, later on, we
may want to recreate our person

00:01:29.900 --> 00:01:33.020 align:middle line:84%
instance exactly as it
is now with the same name

00:01:33.020 --> 00:01:34.550 align:middle line:84%
and being able to
call the display

00:01:34.550 --> 00:01:37.700 align:middle line:84%
underscore name method
to get it printed.

00:01:37.700 --> 00:01:39.650 align:middle line:84%
And this is our
serialized instance

00:01:39.650 --> 00:01:42.470 align:middle line:84%
ready to be stored or shared
through some communication

00:01:42.470 --> 00:01:43.710 align:middle line:90%
channel.

00:01:43.710 --> 00:01:45.955 align:middle line:84%
Take your time to
figure out the format.

00:01:45.955 --> 00:01:48.620 align:middle line:84%
PHP uses a mostly human
readable string format

00:01:48.620 --> 00:01:51.470 align:middle line:84%
with letters representing
the data type and numbers

00:01:51.470 --> 00:01:54.410 align:middle line:84%
representing the
length of each entry.

00:01:54.410 --> 00:01:56.390 align:middle line:84%
When we want to
rebuild person instance

00:01:56.390 --> 00:01:58.850 align:middle line:84%
from its textual
representation, then we

00:01:58.850 --> 00:02:02.600 align:middle line:84%
need deserialization; the
reverse of serialization

00:02:02.600 --> 00:02:05.930 align:middle line:84%
process, taking data
structured from some format

00:02:05.930 --> 00:02:08.600 align:middle line:84%
and rebuilding it
into an object.

00:02:08.600 --> 00:02:12.320 align:middle line:84%
If we want to deserialize custom
object like our person class,

00:02:12.320 --> 00:02:14.810 align:middle line:84%
then you need to
have its definition.

00:02:14.810 --> 00:02:17.900 align:middle line:84%
PHP provides an unserialize
function to do it.

00:02:17.900 --> 00:02:20.120 align:middle line:84%
It takes a textual
representation,

00:02:20.120 --> 00:02:22.100 align:middle line:84%
parses it, and
creates an instance

00:02:22.100 --> 00:02:24.350 align:middle line:84%
of a person based on the
information retrieved

00:02:24.350 --> 00:02:26.270 align:middle line:90%
from that representation--

00:02:26.270 --> 00:02:29.700 align:middle line:84%
all this out of the box
with a single line of code.

00:02:29.700 --> 00:02:31.940 align:middle line:90%
Very convenient, right?

00:02:31.940 --> 00:02:34.310 align:middle line:84%
The problem is the
unserialize function

00:02:34.310 --> 00:02:37.310 align:middle line:84%
did it all based on what was
stored in the storable data

00:02:37.310 --> 00:02:38.390 align:middle line:90%
variable.

00:02:38.390 --> 00:02:40.550 align:middle line:84%
A new person
instance was created

00:02:40.550 --> 00:02:43.880 align:middle line:84%
because that was the object type
in the textual representation

00:02:43.880 --> 00:02:47.930 align:middle line:84%
after deleting capital
O and number 6.

00:02:47.930 --> 00:02:50.000 align:middle line:84%
If the value of
storable data variable

00:02:50.000 --> 00:02:51.890 align:middle line:84%
is something
attackers can control,

00:02:51.890 --> 00:02:54.170 align:middle line:84%
for example, a cookie
value, then they

00:02:54.170 --> 00:02:57.770 align:middle line:84%
can create instances of any
other available class providing

00:02:57.770 --> 00:03:01.700 align:middle line:84%
a valid string according to
PHP serialization formats.

00:03:01.700 --> 00:03:03.650 align:middle line:84%
Any source of user
controlled data

00:03:03.650 --> 00:03:05.840 align:middle line:84%
which is deserialized
by the application

00:03:05.840 --> 00:03:08.000 align:middle line:90%
represents an attack vector.

00:03:08.000 --> 00:03:10.347 align:middle line:84%
Typically, serialized
data is stored client side

00:03:10.347 --> 00:03:13.070 align:middle line:84%
in cookies or local
storage and later sent

00:03:13.070 --> 00:03:16.550 align:middle line:84%
on subsequent requests in
request headers or body.

00:03:16.550 --> 00:03:18.650 align:middle line:84%
If attackers can
tamper such values,

00:03:18.650 --> 00:03:22.010 align:middle line:84%
then they might be able to
compromise the application.

00:03:22.010 --> 00:03:25.490 align:middle line:84%
Serialized values are
commonly stored in databases--

00:03:25.490 --> 00:03:27.680 align:middle line:90%
for example, session objects--

00:03:27.680 --> 00:03:31.100 align:middle line:84%
or exchanged between
integrated services.

00:03:31.100 --> 00:03:33.710 align:middle line:84%
Exploiting
deserialization, attackers

00:03:33.710 --> 00:03:36.240 align:middle line:84%
might be able to
access arbitrary files.

00:03:36.240 --> 00:03:38.130 align:middle line:84%
Imagine that custom
deserialization

00:03:38.130 --> 00:03:42.560 align:middle line:84%
loads some files from file
system based on provided path.

00:03:42.560 --> 00:03:44.720 align:middle line:84%
Quite often, serialized
data includes

00:03:44.720 --> 00:03:47.240 align:middle line:90%
roles or privileged details.

00:03:47.240 --> 00:03:49.940 align:middle line:84%
Modifying serialized
data may allow attackers

00:03:49.940 --> 00:03:52.870 align:middle line:90%
to escalate their privileges.

00:03:52.870 --> 00:03:55.870 align:middle line:84%
In some cases, special
crafted serialized objects

00:03:55.870 --> 00:03:59.380 align:middle line:84%
may cause denial-of-services
during deserialization.

00:03:59.380 --> 00:04:03.580 align:middle line:84%
Circular references are good
candidates to exploit it.

00:04:03.580 --> 00:04:05.680 align:middle line:84%
In some cases,
remote code execution

00:04:05.680 --> 00:04:08.530 align:middle line:84%
might be possible, allowing
attackers to gain control

00:04:08.530 --> 00:04:11.160 align:middle line:90%
over the system.

00:04:11.160 --> 00:04:13.200 align:middle line:84%
Technical skills are
required to exploit

00:04:13.200 --> 00:04:15.240 align:middle line:90%
insecure deserialization.

00:04:15.240 --> 00:04:17.970 align:middle line:84%
Off the shelf
exploits rarely work,

00:04:17.970 --> 00:04:22.230 align:middle line:84%
requiring changes or tweaks to
the underlying exploit code.

00:04:22.230 --> 00:04:24.900 align:middle line:84%
Based on successful
exploitation impact,

00:04:24.900 --> 00:04:27.900 align:middle line:84%
threats agents may be after
sensitive information or gain

00:04:27.900 --> 00:04:29.880 align:middle line:90%
control over the system.

00:04:29.880 --> 00:04:31.890 align:middle line:84%
Knowledge about the
system internals

00:04:31.890 --> 00:04:33.870 align:middle line:84%
will greatly help
attackers exploit

00:04:33.870 --> 00:04:35.880 align:middle line:90%
insecure deserialization.

00:04:35.880 --> 00:04:38.550 align:middle line:84%
You'll find this table
in the OWASP Top 10.

00:04:38.550 --> 00:04:42.240 align:middle line:84%
Pause the video and take your
time to carefully read it.

00:04:42.240 --> 00:04:44.040 align:middle line:84%
In the next part,
we will exploit

00:04:44.040 --> 00:04:47.220 align:middle line:84%
insecure deserialization on
our intentionally vulnerable

00:04:47.220 --> 00:04:49.370 align:middle line:90%
application.

00:04:49.370 --> 00:04:50.000 align:middle line:90%