WEBVTT

1
00:00.000 --> 00:00.050 align:middle line:84%


2
00:00.050 --> 00:01.830 align:middle line:90%
The buffer overflow
is yet one more

3
00:01.830 --> 00:04.950 align:middle line:90%
common attack that's used
against us, because sometimes,

4
00:04.950 --> 00:08.130 align:middle line:90%
older applications and
older hardware wasn't really

5
00:08.130 --> 00:10.475 align:middle line:90%
built to handle too
much data at once.

6
00:10.475 --> 00:12.600 align:middle line:90%
So what we're going to do
in this particular Nugget

7
00:12.600 --> 00:14.310 align:middle line:90%
is just draw at the
whiteboard and talk

8
00:14.310 --> 00:16.890 align:middle line:90%
for a second about how
the buffer overflow works

9
00:16.890 --> 00:19.140 align:middle line:90%
and what type of
data or information

10
00:19.140 --> 00:20.830 align:middle line:90%
the hackers trying
to take from us.

11
00:20.830 --> 00:21.730 align:middle line:84%
Let's get going.

12
00:21.730 --> 00:22.910 align:middle line:84%
The buffer overflow attack.

13
00:22.910 --> 00:24.660 align:middle line:90%
Another oldie but
goodie, but in this one,

14
00:24.660 --> 00:27.360 align:middle line:90%
there's no real way that I
could demonstrate how it works,

15
00:27.360 --> 00:30.180 align:middle line:90%
because this could actually
jeopardize the system
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

15
00:27.360 --> 00:30.180 align:middle line:90%
because this could actually
jeopardize the system

16
00:30.180 --> 00:32.040 align:middle line:84%
when you perform this attack.

17
00:32.040 --> 00:34.262 align:middle line:90%
You see, the idea
is that the hacker--

18
00:34.262 --> 00:35.720 align:middle line:90%
instead of a smiley
face, I'm going

19
00:35.720 --> 00:38.310 align:middle line:90%
to put a bad face,
because they're hackers.

20
00:38.310 --> 00:42.210 align:middle line:90%
The hacker is going to try and
send in data into a website,

21
00:42.210 --> 00:46.248 align:middle line:90%
maybe they're using a JavaScript
injection or SQL injection,

22
00:46.248 --> 00:47.790 align:middle line:90%
or maybe they're
just doing something

23
00:47.790 --> 00:50.790 align:middle line:90%
as simple as sending in too big
of a ping, something like that.

24
00:50.790 --> 00:56.060 align:middle line:90%
The idea is they're trying to
overflow the applications RAM

25
00:56.060 --> 00:56.670 align:middle line:84%
buffer.

26
00:56.670 --> 01:00.870 align:middle line:90%
You're trying to send in more
data than the actual device.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

26
00:56.670 --> 01:00.870 align:middle line:90%
You're trying to send in more
data than the actual device.

27
01:00.870 --> 01:04.290 align:middle line:90%
The actual application has
been allotted to handle.

28
01:04.290 --> 01:05.620 align:middle line:84%
So let's make up a number here.

29
01:05.620 --> 01:07.530 align:middle line:90%
Let's say this
particular server.

30
01:07.530 --> 01:09.600 align:middle line:90%
We sent in just a huge
amount of information,

31
01:09.600 --> 01:12.600 align:middle line:90%
and this particular server
was set to handle something

32
01:12.600 --> 01:15.600 align:middle line:90%
like 60,000 bytes
of data at once,

33
01:15.600 --> 01:18.900 align:middle line:90%
but we've just sent
in 80,000 bytes.

34
01:18.900 --> 01:23.310 align:middle line:90%
The idea here is that additional
or excess 20,000 bytes now

35
01:23.310 --> 01:28.080 align:middle line:90%
has to overflow into other
sections of the application

36
01:28.080 --> 01:29.680 align:middle line:84%
or the server itself.

37
01:29.680 --> 01:32.580 align:middle line:90%
And once we've got our
20,000 bytes within there,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

37
01:29.680 --> 01:32.580 align:middle line:90%
And once we've got our
20,000 bytes within there,

38
01:32.580 --> 01:35.760 align:middle line:90%
we could then create these
20,000 bytes to execute

39
01:35.760 --> 01:39.270 align:middle line:90%
JavaScript code or SQL
code or C# or .NET code,

40
01:39.270 --> 01:40.470 align:middle line:84%
whatever the case is.

41
01:40.470 --> 01:43.950 align:middle line:90%
And we could use it to delete
or destroy information,

42
01:43.950 --> 01:47.160 align:middle line:90%
or we could use it to retrieve
or pull information out.

43
01:47.160 --> 01:50.280 align:middle line:90%
Now, application developers
and servers themselves

44
01:50.280 --> 01:53.800 align:middle line:90%
are getting better at defending
against this on their own,

45
01:53.800 --> 01:57.450 align:middle line:90%
but this is another one that's
present in the OWASP top 10

46
01:57.450 --> 01:59.850 align:middle line:90%
threats, and you should
really spend some time digging

47
01:59.850 --> 02:02.130 align:middle line:90%
through the buffer
overflow, because there's
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

47
01:59.850 --> 02:02.130 align:middle line:90%
through the buffer
overflow, because there's

48
02:02.130 --> 02:05.910 align:middle line:90%
a bunch of different ways
they can send data in and then

49
02:05.910 --> 02:09.449 align:middle line:90%
exploit once they've got
into the overflowed section

50
02:09.449 --> 02:11.500 align:middle line:90%
the different languages
they want to use.

51
02:11.500 --> 02:13.440 align:middle line:90%
So quite simply put,
our mitigation steps

52
02:13.440 --> 02:15.690 align:middle line:90%
are just to not accept
any more data beyond that

53
02:15.690 --> 02:17.340 align:middle line:84%
and not let it overflow.

54
02:17.340 --> 02:20.520 align:middle line:90%
This requires some
back end code work here

55
02:20.520 --> 02:22.360 align:middle line:84%
to prevent that from happening.

56
02:22.360 --> 02:25.050 align:middle line:90%
The application server
itself, not the web browser

57
02:25.050 --> 02:26.970 align:middle line:90%
and not the database,
but the application

58
02:26.970 --> 02:29.550 align:middle line:90%
server itself is what's
going to have to stop

59
02:29.550 --> 02:31.200 align:middle line:84%
that overflow from happening.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

59
02:29.550 --> 02:31.200 align:middle line:84%
that overflow from happening.

60
02:31.200 --> 02:34.320 align:middle line:90%
You could simply send a
response back to the web browser

61
02:34.320 --> 02:36.570 align:middle line:90%
and say, look, we've
had a buffer overflow.

62
02:36.570 --> 02:38.640 align:middle line:90%
Here's your error that
says buffer overflow,

63
02:38.640 --> 02:40.880 align:middle line:90%
and we're stopping the
transmission at this point.

64
02:40.880 --> 02:43.650 align:middle line:90%
So the key takeaway with
the buffer overflow attack

65
02:43.650 --> 02:45.630 align:middle line:90%
is that we're just
trying to overwhelm

66
02:45.630 --> 02:48.480 align:middle line:90%
the server with
commands or processes,

67
02:48.480 --> 02:51.270 align:middle line:90%
and by doing so,
injecting or leaking

68
02:51.270 --> 02:54.870 align:middle line:90%
our own commands into other
aspects of the application

69
02:54.870 --> 02:56.197 align:middle line:84%
or server itself.

70
02:56.197 --> 02:58.530 align:middle line:90%
So that's been the quick
overview of the buffer overflow

71
02:58.530 --> 02:58.950 align:middle line:84%
attack.

72
02:58.950 --> 03:00.658 align:middle line:90%
I hope this has been
informative for you,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

72
02:58.950 --> 03:00.658 align:middle line:90%
I hope this has been
informative for you,

73
03:00.658 --> 03:02.960 align:middle line:90%
and I'd like to thank
you for viewing.