[00:00.000 --> 00:05.040]  We wish everyone a safe flight home and travels.
[00:05.600 --> 00:06.740]  Ducks.
[00:08.140 --> 00:16.800]  But, no seriously, we hope that we will be all together soon, next, hopefully next year.
[00:18.560 --> 00:27.780]  Before we begin, we want to give a huge shout out and a big thank you to AWS, who is sponsoring this year's Packet Hacking Village.
[00:28.500 --> 00:33.040]  Our talk is coming up next.
[00:33.260 --> 00:38.940]  This next speaker here is a legend and needs no introduction.
[00:39.180 --> 00:42.320]  He is a friend and a world-class trainer.
[00:42.320 --> 00:49.020]  It is my pleasure to introduce to you John Hammond with Take Down the Internet with Scappy.
[00:49.020 --> 00:50.460]  Take it away, John.
[00:59.430 --> 01:04.810]  Alrighty, hello everyone. Welcome. Thank you for tuning in. I appreciate you being here.
[01:04.810 --> 01:09.890]  This is a talk and presentation titled Take Down the Internet with Scappy.
[01:09.890 --> 01:15.570]  I'm presenting this as part of DEF CON 28, or DEF CON Safe Mode, and I'm here at the Packet Hacking Village.
[01:15.570 --> 01:20.970]  So let's dive into the presentation, but before we do, I've got to say this.
[01:21.070 --> 01:26.790]  I've said it before, I'm about to say it now, and I'm certainly going to say it again many, many times throughout the presentation.
[01:27.110 --> 01:29.850]  Thank you. Thank you for being here.
[01:29.850 --> 01:36.390]  Honestly, seriously, I know things are a little crazy and weird and not how we're used to them being at DEF CON,
[01:36.390 --> 01:40.510]  but thank you so, so much for being here. Thank you for tuning into this talk.
[01:40.510 --> 01:42.170]  Thank you for being a part of all this.
[01:42.170 --> 01:47.910]  I usually say this at the end, and I'm certainly going to, but now especially, I think it's really important.
[01:48.150 --> 01:52.030]  Just thank you. Thanks for being here. I really, really appreciate it.
[01:52.030 --> 01:56.350]  Okay, so the classic disclaimer, right?
[01:56.430 --> 01:59.250]  The start of every talk, it's just how it's got to start.
[01:59.850 --> 02:02.850]  These are my words, not my employer's.
[02:02.850 --> 02:05.410]  I don't represent them. I'm not speaking for them, etc.
[02:05.410 --> 02:09.650]  This is stuff that I wanted to bring to you, me personally.
[02:10.370 --> 02:15.890]  Other disclaimer, don't or do try this at home, right?
[02:15.890 --> 02:21.670]  Anything that we talk about, anything that I showcase here, obviously it's a talk titled, Take Down the Internet.
[02:21.670 --> 02:29.990]  Don't actually do that, or maybe do it at maybe your own small-scale lab environment, etc.
[02:29.990 --> 02:35.510]  You can tinker with it and explore with it, but don't actually take down the internet, right?
[02:36.210 --> 02:37.090]  Cool.
[02:37.410 --> 02:40.070]  Next, your mileage may vary.
[02:40.350 --> 02:43.610]  I bring this up with everything that I kind of try and showcase.
[02:43.610 --> 02:45.670]  Look, I'm talking about it. I'm showing it to you.
[02:45.670 --> 02:47.090]  Maybe you'll have different results.
[02:47.090 --> 02:51.610]  Maybe something will work differently or strangely in the way that you do it, if you do this sort of thing.
[02:51.670 --> 02:57.710]  I can't promise, and I don't mean to make this any written-in-stone gospel or anything,
[02:57.710 --> 03:04.590]  the stuff that comes out of this talk, it might be different for you and your mileage may vary.
[03:04.930 --> 03:06.270]  Okay, last bit.
[03:06.550 --> 03:08.330]  We're the good guys here, right?
[03:08.330 --> 03:10.890]  We talk about security. We talk about cybersecurity.
[03:11.010 --> 03:14.270]  We break things for the sake of making them better.
[03:14.330 --> 03:16.550]  We hack for good.
[03:16.550 --> 03:17.930]  And I want you to do the same.
[03:17.930 --> 03:21.430]  The stuff that we're going to talk about and showcase in this presentation,
[03:21.430 --> 03:24.370]  maybe it's a little bit on the different side of the fence.
[03:24.430 --> 03:29.590]  I want to reiterate to you and kind of enforce it, hey, hack for good.
[03:31.830 --> 03:34.810]  Okay, obligatory introduction, right?
[03:34.830 --> 03:37.090]  Who is this guy talking at you?
[03:37.090 --> 03:39.370]  Hello, my name is John Hammond.
[03:39.770 --> 03:44.050]  I'll try and run through this quickly because I know no one cares, not even me.
[03:44.050 --> 03:47.790]  I used to just do some stuff with the Department of Defense Cyber Crime Center
[03:47.790 --> 03:49.430]  and their Cyber Training Academy.
[03:49.670 --> 03:54.930]  And I also work with the Defense Threat Reduction Agency as kind of a red team cyber operator.
[03:54.930 --> 03:58.650]  Right now, I'm working as a senior security researcher over at Huntress Labs.
[03:58.650 --> 04:02.150]  Again, not speaking for them. These are my words, not theirs.
[04:02.150 --> 04:06.190]  And in my free time, I like to play a little bit of capture the flag.
[04:06.190 --> 04:10.190]  I like to develop and create and host capture the flag events or competitions
[04:10.190 --> 04:13.770]  or exercises and training sets to try and make people better,
[04:14.050 --> 04:17.230]  try and improve everyone's cyber security skill.
[04:17.470 --> 04:21.210]  On that same coin, I do produce some cheesy YouTube videos.
[04:21.250 --> 04:25.830]  I publish and showcase some capture the flag write-ups or programming tutorials,
[04:25.830 --> 04:27.630]  video guides, stuff like that.
[04:27.630 --> 04:30.670]  But that's all nerdy stuff that you don't really have to care about.
[04:30.670 --> 04:34.210]  Let's talk about what we're going to talk about.
[04:34.270 --> 04:35.530]  Kind of meta, right?
[04:35.530 --> 04:39.410]  So here's the agenda, the roadmap, the outline for our discussion.
[04:39.510 --> 04:41.510]  First, we'll lay the groundwork.
[04:41.510 --> 04:43.610]  We'll put down a little bit of a background,
[04:43.610 --> 04:45.770]  really set the scene for what we're going to be discussing.
[04:45.770 --> 04:49.010]  I'm going to be talking a little bit about Python, right?
[04:49.050 --> 04:50.390]  Python is kind of my weapon of choice,
[04:50.390 --> 04:55.150]  but we need to make a distinction between Python 2 versus Python 3
[04:55.150 --> 04:58.910]  and what we'll kind of be using as our vessel throughout this talk.
[04:58.910 --> 05:00.510]  Then I'm going to introduce Scapey,
[05:00.510 --> 05:03.630]  one really, really cool Python module or library
[05:03.630 --> 05:06.590]  that you can pull into your Python source code,
[05:06.590 --> 05:09.090]  use with your projects, your other scripts,
[05:09.090 --> 05:11.810]  whatever you're working on to do really, really cool,
[05:11.810 --> 05:14.690]  low-level stuff with network packets,
[05:14.690 --> 05:17.090]  with the stuff that you would find in PCAPs,
[05:17.090 --> 05:20.170]  if you would take a look at it in Wireshark or TCP dump, etc.
[05:20.170 --> 05:23.230]  We're going to do that with Scapey inside of Python.
[05:23.230 --> 05:24.750]  So we'll talk about how to install it,
[05:24.750 --> 05:27.750]  some documentation, syntax and use cases, etc.
[05:27.950 --> 05:31.510]  Then we'll get into the real meat of the conversation.
[05:31.510 --> 05:33.690]  We'll talk about different attacks that we could perform
[05:33.690 --> 05:36.230]  and we'll kind of zoom in or zoom out as appropriate
[05:36.230 --> 05:37.990]  on some of these different things,
[05:39.090 --> 05:41.230]  like fraud, DNS attacks, BGP, etc.
[05:41.710 --> 05:44.970]  I do want to showcase a couple of IRL,
[05:44.970 --> 05:46.950]  or in real life cases, right?
[05:46.950 --> 05:51.590]  Stuff that we've really seen out in the real world that is real.
[05:51.890 --> 05:55.150]  All about the stuff that we're kind of laying the foundation with here,
[05:55.150 --> 05:58.110]  Python, Scapey, and these network attacks
[05:58.110 --> 06:00.770]  when we're trying to take down the internet.
[06:01.290 --> 06:04.250]  We'll also discuss some of the defense and mitigation,
[06:04.250 --> 06:05.810]  some things that we could do,
[06:05.810 --> 06:07.570]  some things that we might consider
[06:08.110 --> 06:12.350]  when we take note of all these network attacks we're going to be looking at.
[06:12.350 --> 06:14.650]  Finally, I'll showcase some of the resources and references
[06:14.650 --> 06:17.850]  that I use to put together this conversation, this talk for you.
[06:17.850 --> 06:20.550]  And we'll have the boilerplate template slides,
[06:20.550 --> 06:21.790]  how you can contact me.
[06:21.790 --> 06:24.690]  And of course, I will thank you again and again.
[06:24.690 --> 06:27.150]  I'm really, really appreciative that you're here.
[06:27.810 --> 06:28.990]  All right, let's get into it.
[06:29.130 --> 06:32.190]  To get things rolling, let's lay the foundation.
[06:32.250 --> 06:35.130]  We're going to be talking about packets, right?
[06:35.250 --> 06:37.070]  We're here in the packet hacking village.
[06:37.570 --> 06:39.350]  We're talking about network-oriented stuff.
[06:39.350 --> 06:42.470]  So naturally, we're going to be talking about packets,
[06:42.470 --> 06:44.130]  using Scapey, using Python.
[06:44.130 --> 06:45.650]  And we'll dive into that more.
[06:45.650 --> 06:49.090]  But I want to say, the title of this talk, right,
[06:49.090 --> 06:51.530]  the whole theme, take down the internet,
[06:52.290 --> 06:56.790]  that's going to be doing a lot of kind of jerk stuff.
[06:56.930 --> 07:03.510]  It's about obnoxious, annoying, adversarial, and disruptive attacks.
[07:03.510 --> 07:09.510]  So nothing like leet, super cool, zero days, crazy, like,
[07:09.510 --> 07:11.510]  ninja warrior cyber hacker stuff,
[07:11.510 --> 07:15.470]  but really just being mean and breaking stuff.
[07:15.470 --> 07:17.990]  We're trying to recklessly break stuff.
[07:17.990 --> 07:19.410]  I want to showcase some of this to you,
[07:19.410 --> 07:23.930]  because really I want to show you just how easy it is.
[07:23.930 --> 07:30.530]  And how Python, the same scripting language that's about on every Unix system,
[07:30.530 --> 07:31.850]  can do this stuff.
[07:31.850 --> 07:34.870]  And how you could do it, if you really wanted to,
[07:34.870 --> 07:37.450]  but you shouldn't, you don't have to, right?
[07:37.450 --> 07:44.030]  Take down the internet, obnoxious, annoying, adversarial, and disruptive attacks.
[07:44.630 --> 07:45.970]  That's the background.
[07:47.810 --> 07:50.070]  All right, now let's talk a little bit about Python.
[07:50.070 --> 07:53.910]  I'm going to be using Python as the vessel for this talk, right?
[07:53.910 --> 07:56.290]  We want to make this a little bit of a technical talk,
[07:56.290 --> 07:58.710]  and showcase some code, showcase some real stuff,
[07:58.710 --> 08:01.250]  rather than just pointing at numbers on a graph.
[08:01.850 --> 08:05.250]  So, I want to lay the foundation again with Python.
[08:05.390 --> 08:09.230]  Python is a wonderful hacker's language.
[08:09.230 --> 08:12.950]  Yes, it's a scripting language, it's not compiled, it's read through an interpreter,
[08:12.950 --> 08:16.390]  but it is easy to read, and easy to write.
[08:16.390 --> 08:18.730]  That means that it's super duper friendly,
[08:18.730 --> 08:22.090]  it's really easy to knock out quick testing scripts,
[08:22.090 --> 08:24.630]  or to rapidly prototype some ideas.
[08:24.630 --> 08:27.850]  It's just handy and useful, and has a lot of support
[08:27.850 --> 08:31.290]  between all the different libraries, and modules, and packages
[08:31.290 --> 08:35.830]  that you could pull into your code, and do some really, really neat stuff.
[08:36.430 --> 08:38.350]  So, there's some conversations, right?
[08:38.350 --> 08:42.410]  Because now we are in a new era, we are in 2020,
[08:42.410 --> 08:46.790]  and Python 2, the older version of Python, is dead.
[08:46.790 --> 08:49.230]  It's not on the table anymore.
[08:49.310 --> 08:52.130]  Python 2 reached end of life at the start of this year,
[08:52.130 --> 08:55.470]  and now Python 3 is the officially supported version.
[08:55.470 --> 08:57.630]  Please don't hate me for screaming about that,
[08:57.630 --> 09:00.770]  I just want to make sure, hey, everyone knows, we're using Python 3,
[09:00.770 --> 09:02.250]  and you should be too.
[09:02.930 --> 09:05.770]  And of course, Python is part of Linux.
[09:05.770 --> 09:10.790]  It's typically shipped, and natively built into a lot of common Linux distributions.
[09:11.070 --> 09:13.670]  And honestly, you should be using Linux.
[09:13.670 --> 09:15.270]  I don't know why you wouldn't be.
[09:15.270 --> 09:19.090]  And because it is part of Linux, it's really, really easy to access it,
[09:19.090 --> 09:21.830]  just from the command line, you can simply type in Python,
[09:21.830 --> 09:25.790]  and then you're inside of an interactive shell, or interpreter,
[09:25.790 --> 09:27.770]  to work with the Python language.
[09:27.770 --> 09:30.790]  I'm kind of being explicit here, I'm using Python 3,
[09:30.790 --> 09:32.650]  with that suffix 3 at the end,
[09:32.650 --> 09:35.290]  you probably will just be able to invoke it as regular Python,
[09:35.290 --> 09:37.790]  and maybe that would spin up Python 3 for you,
[09:37.790 --> 09:41.890]  but if it does fire up Python 2, hey, you should know better,
[09:41.890 --> 09:44.590]  go fix that up, and hop over to Python 3,
[09:44.590 --> 09:46.890]  now as the officially supported version.
[09:46.990 --> 09:50.330]  Python, while we could be working inside of the language,
[09:50.330 --> 09:52.830]  within the interpreter, or within that shell,
[09:52.830 --> 09:55.650]  oftentimes you'll likely want to create a script,
[09:55.650 --> 09:59.030]  or file with a .py extension, maybe a shebang line,
[09:59.030 --> 10:01.610]  and you can invoke it and run it with Python,
[10:01.610 --> 10:05.630]  just as an automated tool, not manually working through the interpreter,
[10:05.630 --> 10:07.730]  or the interactive shell there.
[10:07.730 --> 10:10.150]  In a lot of our conversations, what we'll be discussing,
[10:10.150 --> 10:13.670]  I'm assuming you're going to end up using this inside of a script,
[10:13.670 --> 10:18.010]  with a .py extension, and you don't need that interactive interpreter.
[10:18.010 --> 10:22.410]  Okay, let's move on, because you probably all already know about Python,
[10:22.410 --> 10:26.070]  and this is boring, so let's talk about Scapey.
[10:26.170 --> 10:30.970]  Scapey is incredible, fantastic, phenomenal.
[10:30.970 --> 10:34.830]  It is a module, it's a library, it's something you can just install,
[10:34.830 --> 10:36.790]  pull into use with your Python code,
[10:36.790 --> 10:42.330]  and it gives you the ability to craft network packets.
[10:42.330 --> 10:46.950]  You can customize them, you can forge them, you can create them,
[10:46.950 --> 10:49.190]  whatever you want, your wildest dreams,
[10:49.190 --> 10:53.430]  whatever sort of network layers or protocols or things that you want to use,
[10:53.950 --> 10:59.950]  you can get that fine-tuned, zoomed-in, microscopic customization
[11:00.650 --> 11:04.150]  of what that packet looks like, and that's super-duper cool.
[11:04.150 --> 11:06.930]  It's easy to install, I'm showcasing some commands here,
[11:06.930 --> 11:10.630]  I'm assuming, okay, a Debian-based distribution, maybe Ubuntu,
[11:10.630 --> 11:14.390]  you'll do a little sudo apt update, and you'll install pip,
[11:14.390 --> 11:17.830]  if you're working with that little handy Python package manager,
[11:17.830 --> 11:20.730]  and let's use pip install scapey.
[11:21.410 --> 11:25.090]  Now, you can run Scapey in one of two ways,
[11:25.090 --> 11:27.830]  very, very similar to what we talked about in Python, right?
[11:27.830 --> 11:31.830]  Scapey could be interactive, and you could work inside of an interpreter
[11:31.830 --> 11:36.450]  with a manual, like, typing in commands and getting that returned back to you,
[11:36.450 --> 11:38.510]  like, interactive shell.
[11:39.130 --> 11:43.230]  Or, you could work with it inside of a script,
[11:43.230 --> 11:47.150]  and have Python just import Scapey as a whole module,
[11:47.150 --> 11:50.590]  and you can access all of the code, the functions, the variables,
[11:50.590 --> 11:55.570]  all of that functionality that Scapey offers inside of your Python scripts,
[11:55.570 --> 11:56.690]  inside of Python.
[11:56.770 --> 12:01.670]  Now, this is crazy cool, because we can work with TCP packets,
[12:01.670 --> 12:06.030]  UDP packets, any other network stuff, maybe CAN bus protocols or Bluetooth,
[12:06.030 --> 12:11.670]  there's so much more, and we could dive into some of the documentation for Scapey.
[12:12.710 --> 12:15.810]  I always want to point people to the real documentation,
[12:15.810 --> 12:17.910]  because that's where the real stuff is, right?
[12:18.190 --> 12:20.370]  I'm not going to be the expert, sorry.
[12:20.430 --> 12:22.950]  I don't think you would call yourself the expert,
[12:22.950 --> 12:25.070]  and I'm not saying that to be mean, I'm just trying to say,
[12:25.750 --> 12:29.630]  the source code is the truth, right?
[12:30.610 --> 12:32.690]  Documentation is the real accurate stuff.
[12:32.690 --> 12:34.690]  That's what's really there, really built in,
[12:34.690 --> 12:38.450]  and the official source is what's good to go to when you need help
[12:38.450 --> 12:39.750]  or you're trying to learn something new.
[12:39.750 --> 12:41.630]  Obviously, there's a man page for the command,
[12:41.630 --> 12:43.070]  if you wanted to fire that up.
[12:43.070 --> 12:45.290]  Obviously, they've got an online web presence,
[12:45.290 --> 12:47.090]  you can check them out at scapey.net,
[12:47.090 --> 12:51.170]  and they have official documentation over at readthedocs.io,
[12:51.170 --> 12:53.910]  and of course, a GitHub page,
[12:53.910 --> 12:55.390]  so you can go take a look at the source code.
[12:55.390 --> 12:58.790]  It's open source, it's awesome, it's all Python, good stuff.
[12:58.790 --> 13:00.610]  The website is actually fantastic.
[13:00.610 --> 13:03.130]  They have a page over there called Awesome Scapey,
[13:03.130 --> 13:05.490]  and that will showcase other tools, exploits,
[13:05.490 --> 13:08.390]  and some sample code to use, and it's really, really cool.
[13:08.390 --> 13:10.290]  They have some good stuff on Wi-Fi,
[13:10.290 --> 13:14.430]  like mapping and tracking Wi-Fi networks through 802.11,
[13:14.430 --> 13:15.930]  making a rowing access point,
[13:15.930 --> 13:17.470]  performing some man-in-the-middle attacks,
[13:17.470 --> 13:20.190]  some TOR, Onion Router Protocol stuff,
[13:20.190 --> 13:21.850]  tons and tons of great stuff,
[13:21.850 --> 13:24.090]  even CVEs and exploits for common attacks,
[13:24.090 --> 13:27.370]  or stuff from CRAC, the attack against WPA2.
[13:27.370 --> 13:30.310]  Super duper cool, really recommend you go check that out.
[13:31.750 --> 13:35.090]  Okay, now let's talk about the basic syntax of Scapey,
[13:35.090 --> 13:37.590]  because if we want to use it, we have to know how to.
[13:38.670 --> 13:41.170]  I say that Scapey is Pythonic,
[13:41.170 --> 13:43.030]  in that the syntax that it uses,
[13:43.030 --> 13:44.650]  when you're working with the module,
[13:44.650 --> 13:48.030]  you're working with Python objects, right?
[13:48.030 --> 13:50.590]  The same way most everything in Python really is,
[13:50.590 --> 13:53.890]  is that you're interacting and working with an object
[13:54.330 --> 13:56.830]  that has methods and properties
[13:57.190 --> 13:59.050]  and all these attributes and things you could work with
[13:59.050 --> 14:00.630]  that are really under the hood, right?
[14:00.630 --> 14:03.250]  Functions and variables, just with kind of a different,
[14:03.250 --> 14:04.090]  decorated name.
[14:04.090 --> 14:06.330]  But being object-oriented means we can do
[14:06.330 --> 14:08.290]  some kind of nifty things with it,
[14:08.290 --> 14:09.490]  maybe not all the time,
[14:09.490 --> 14:11.990]  I'm not trying to say OOP is the way,
[14:11.990 --> 14:14.170]  but it's nice to have that
[14:14.170 --> 14:16.470]  kind of built into the language when necessary.
[14:16.530 --> 14:18.150]  So you can see I'm working
[14:18.150 --> 14:20.310]  in like a little bit of a script here, right?
[14:20.310 --> 14:22.630]  I've got a shebang line set up,
[14:22.630 --> 14:25.690]  I'm going to work with Python 3 as my interpreter,
[14:25.690 --> 14:26.570]  and I'm going to use that
[14:26.570 --> 14:29.790]  from Scapey.all import everything,
[14:29.790 --> 14:32.210]  or the asterisk, the star, the wildcard,
[14:32.210 --> 14:35.130]  to pull in everything that that Scapey module has
[14:35.130 --> 14:37.170]  into my current namespace.
[14:37.170 --> 14:38.330]  So I can interact with it,
[14:38.330 --> 14:40.270]  and I can work with it through Python.
[14:40.330 --> 14:41.710]  So here I'm going to create an object,
[14:41.710 --> 14:42.670]  or a little variable,
[14:42.670 --> 14:45.530]  ping equals, and the IP,
[14:45.530 --> 14:47.090]  this big class name, right,
[14:47.090 --> 14:48.390]  you can see the capital letters there,
[14:48.390 --> 14:51.250]  that's going to return a Scapey object.
[14:51.250 --> 14:53.070]  And it's going to be a packet,
[14:53.070 --> 14:55.650]  and I can define how that packet looks.
[14:55.650 --> 14:57.630]  Maybe I don't want to use an IP,
[14:57.630 --> 14:59.370]  or maybe it's that specific header
[14:59.370 --> 15:00.470]  for that protocol.
[15:00.470 --> 15:01.910]  I could zoom in on other things
[15:05.130 --> 15:06.530]  other than Scapey or anything else.
[15:06.530 --> 15:08.710]  And Scapey already has support
[15:08.710 --> 15:10.830]  for all those crazy cool protocols
[15:10.830 --> 15:11.790]  and layers,
[15:11.790 --> 15:14.130]  and you could just pull them in and work with them.
[15:14.130 --> 15:15.770]  Or, if you really wanted to,
[15:15.770 --> 15:17.790]  you could go do a little deep dive,
[15:17.790 --> 15:20.110]  get in the internals, and build your own.
[15:20.530 --> 15:22.250]  So, note inside here,
[15:22.250 --> 15:23.770]  I'm creating this IP object,
[15:23.770 --> 15:26.270]  and I'm passing in a keyword argument.
[15:26.270 --> 15:27.590]  I'm saying DST,
[15:27.590 --> 15:30.090]  or the destination, the destination IP address.
[15:30.090 --> 15:32.310]  I've simply set that to a string,
[15:32.310 --> 15:34.950]  192.168.1.1
[15:35.130 --> 15:38.330]  And I've had a little division symbol,
[15:38.330 --> 15:39.610]  or that forward slash,
[15:39.610 --> 15:40.930]  which looks weird, right?
[15:40.930 --> 15:43.410]  Because we're not dividing these objects,
[15:43.410 --> 15:45.950]  but I'm using that syntax,
[15:45.950 --> 15:48.250]  and that is the syntax that Scapey uses
[15:48.250 --> 15:50.490]  to actually add layers in
[15:50.490 --> 15:51.870]  or kind of build them into
[15:51.870 --> 15:54.030]  that packet that we're crafting.
[15:54.030 --> 15:54.990]  So, I'm going to say,
[15:54.990 --> 15:58.170]  this is simply going to be an ICMP packet,
[15:58.170 --> 15:59.810]  or ping packet, right?
[15:59.810 --> 16:02.190]  I've assigned that to that ping variable,
[16:02.190 --> 16:03.090]  or the object,
[16:03.090 --> 16:05.490]  and I'm just going to print that out on the screen.
[16:05.610 --> 16:08.010]  If I were to run that script,
[16:08.010 --> 16:09.910]  check out down below,
[16:09.910 --> 16:11.310]  now I have that kind of B prefix
[16:11.930 --> 16:13.970]  to note that this is a binary string,
[16:13.970 --> 16:16.430]  or I'm just including real raw bytes here,
[16:16.430 --> 16:17.750]  and that backslash X,
[16:17.750 --> 16:19.390]  the backslash X everything,
[16:19.390 --> 16:22.830]  all those are the bytes to this packet
[16:22.830 --> 16:24.690]  that I've just formulated and created
[16:24.690 --> 16:27.010]  in a super duper simple way, right?
[16:27.010 --> 16:30.290]  It literally took one line of Python code,
[16:30.290 --> 16:31.750]  and now I have a ping packet.
[16:31.750 --> 16:32.850]  And I could do this,
[16:32.850 --> 16:34.610]  I could send this packet,
[16:34.610 --> 16:36.650]  I could receive the information that comes back,
[16:36.650 --> 16:39.290]  maybe a little echo, a request, reply ping,
[16:39.290 --> 16:41.530]  that's very, very cool.
[16:41.550 --> 16:42.970]  All in a script,
[16:42.970 --> 16:45.310]  all automated and extensible,
[16:45.310 --> 16:46.990]  whatever way that I want,
[16:47.590 --> 16:49.790]  and super duper short, right?
[16:49.790 --> 16:51.890]  One line of that Python code,
[16:51.890 --> 16:54.110]  easy to read, easy to write.
[16:54.470 --> 16:55.590]  Obviously,
[16:55.590 --> 16:56.870]  Scapey is abundant,
[16:56.870 --> 16:58.710]  and there are more examples
[16:58.710 --> 17:00.670]  of this sort of thing on their website
[17:01.750 --> 17:02.830]  and that's really, really why
[17:03.410 --> 17:05.090]  I'm pointing you all towards it,
[17:05.090 --> 17:06.590]  because that's where the good stuff is.
[17:06.590 --> 17:08.450]  We're going to cover some cool stuff in the talk,
[17:08.450 --> 17:10.490]  but if you want to go deeper,
[17:10.490 --> 17:12.150]  learn more, do some more research,
[17:12.150 --> 17:14.270]  I'd recommend, hey, go check out
[17:14.270 --> 17:16.230]  that documentation.
[17:16.810 --> 17:18.770]  Okay, last slide on Scapey,
[17:18.770 --> 17:20.630]  I promise, then I'll shut up about it
[17:20.630 --> 17:21.650]  and we can move on.
[17:21.650 --> 17:24.470]  I'm not trying to sound like an evangelist here,
[17:24.470 --> 17:25.810]  but I am trying to show you
[17:25.810 --> 17:28.670]  all of the cool things that Scapey can do.
[17:28.690 --> 17:30.390]  Obviously, in this last slide,
[17:31.750 --> 17:33.350]  we have a super duper small,
[17:33.350 --> 17:35.330]  minuscule example of one thing
[17:35.330 --> 17:37.070]  that Scapey could do.
[17:37.070 --> 17:39.050]  What we could do with that packet,
[17:39.050 --> 17:41.290]  or with many other packets,
[17:41.290 --> 17:44.090]  is put that together into a PCAP file,
[17:44.090 --> 17:46.630]  write it out to a packet capture archive,
[17:46.630 --> 17:49.470]  or we could read in a packet capture archive
[17:49.470 --> 17:50.730]  or a PCAP file,
[17:50.730 --> 17:52.090]  read through it, loop through it,
[17:52.090 --> 17:53.350]  do interesting things with it,
[17:53.350 --> 17:55.090]  or we could sniff and listen
[17:55.090 --> 17:57.790]  and actually capture live packets
[17:57.790 --> 18:00.550]  and dissect them or forge new ones, etc.
[18:01.750 --> 18:03.070]  Import and exports,
[18:03.070 --> 18:05.950]  create graphs, reports, tables, etc., etc.
[18:05.950 --> 18:07.150]  And obviously,
[18:07.150 --> 18:08.990]  all of those specific different protocols
[18:08.990 --> 18:11.350]  that we would want to work with, we can.
[18:11.870 --> 18:13.490]  And then, maybe we could turn it
[18:13.490 --> 18:15.690]  into more of the offensive side.
[18:15.690 --> 18:18.230]  We could probe or scan or attack networks,
[18:18.230 --> 18:20.470]  fuzz specific aspects of a protocol,
[18:20.470 --> 18:22.550]  or send malformed packets.
[18:22.550 --> 18:24.250]  And we could do crazy tricks like,
[18:24.250 --> 18:25.470]  okay, art poisoning,
[18:25.470 --> 18:27.630]  or do some specific kinds of scans,
[18:27.630 --> 18:29.490]  etc., etc.
[18:29.490 --> 18:32.610]  The benefit behind all of this,
[18:32.610 --> 18:35.170]  and this is what makes it so awesome,
[18:35.170 --> 18:37.310]  is that it can all be automated
[18:37.310 --> 18:38.430]  and you can write it
[18:38.430 --> 18:40.270]  and you have that fine-tuned control
[18:40.810 --> 18:42.630]  all within Python.
[18:42.670 --> 18:44.210]  You have the entire arsenal
[18:44.210 --> 18:45.710]  of the Python language
[18:45.710 --> 18:48.110]  and libraries, modules,
[18:48.110 --> 18:49.490]  other tools that you can use
[18:49.490 --> 18:50.850]  and pull into it.
[18:50.850 --> 18:52.870]  So, that's super-duper cool.
[18:54.070 --> 18:56.090]  Now, let's get into the good stuff.
[18:56.090 --> 18:57.710]  Let's get into the really cool attacks
[18:57.710 --> 18:59.190]  that could potentially
[18:59.670 --> 19:01.450]  take down the Internet.
[19:01.650 --> 19:03.430]  So, we'll start small.
[19:03.430 --> 19:04.750]  We'll start with some simple things
[19:04.750 --> 19:06.270]  and then we'll slowly kind of zoom in
[19:06.270 --> 19:08.030]  onto more complex stuff.
[19:08.030 --> 19:10.170]  But just to kind of whet your appetite,
[19:10.170 --> 19:12.590]  let's start with the ping of death.
[19:13.470 --> 19:14.690]  Interesting name, right?
[19:14.690 --> 19:16.070]  So, the ping of death attack
[19:16.070 --> 19:17.770]  is a denial-of-service attack
[19:17.770 --> 19:20.170]  where the attacker will
[19:20.870 --> 19:22.090]  stop a machine
[19:22.090 --> 19:25.430]  by sending a large ping packet.
[19:25.430 --> 19:26.770]  So large, in fact,
[19:27.710 --> 19:28.570]  that the machine can't handle it.
[19:28.570 --> 19:29.750]  It'll choke.
[19:29.790 --> 19:32.070]  There's so much data in that packet
[19:32.070 --> 19:34.310]  that the machine doesn't know what to do with it
[19:34.310 --> 19:35.330]  and it'll freeze up
[19:35.330 --> 19:37.610]  or just fall over or crash.
[19:37.670 --> 19:39.530]  We talked about ping packets
[19:39.530 --> 19:40.830]  in the previous example
[19:40.830 --> 19:42.450]  or that script and source code
[19:42.450 --> 19:43.390]  that I showed you earlier
[19:43.390 --> 19:46.030]  when we were looking at that ICMP protocol
[19:46.030 --> 19:49.050]  or the Internet Control Message Protocol.
[19:49.350 --> 19:50.570]  So, typically,
[19:50.570 --> 19:52.610]  ping packets are very small.
[19:52.610 --> 19:54.730]  But IPv4 ping packets
[19:57.710 --> 19:59.170]  have a maximum allowable packet size
[19:59.170 --> 20:02.870]  of 65,535 bytes.
[20:02.870 --> 20:03.970]  Some systems
[20:03.970 --> 20:06.210]  might not be designed to actually handle
[20:06.530 --> 20:08.410]  packets larger than this maximum
[20:08.410 --> 20:10.290]  and they might be vulnerable to packets
[20:10.290 --> 20:11.530]  at that size
[20:11.530 --> 20:13.430]  and they're sensitive to it.
[20:13.430 --> 20:15.870]  They'll choke and they'll fall over.
[20:15.890 --> 20:17.630]  When this large evil packet
[20:17.630 --> 20:20.190]  is sent from the attacker to the victim,
[20:20.190 --> 20:21.550]  the packet becomes fragmented
[20:21.550 --> 20:23.170]  into different segments,
[20:23.170 --> 20:24.590]  each of which will be smaller
[20:24.590 --> 20:26.550]  than the maximum size limit.
[20:26.910 --> 20:28.390]  When the target and victim
[20:28.390 --> 20:30.050]  actually attempts to put these pieces
[20:30.050 --> 20:31.650]  all back together,
[20:31.650 --> 20:33.430]  eventually that total size
[20:33.430 --> 20:35.630]  will exceed that maximum size limit
[20:35.630 --> 20:38.490]  and maybe a buffer overflow occurs
[20:38.490 --> 20:40.070]  or something goes wrong
[20:40.070 --> 20:42.330]  and that machine can't handle it.
[20:42.330 --> 20:43.690]  It'll freeze, it'll choke,
[20:43.690 --> 20:44.910]  it'll crash.
[20:45.750 --> 20:46.930]  So, we're using this example
[20:46.930 --> 20:48.530]  where the ICMP echo
[20:48.530 --> 20:49.570]  or that ping packet
[20:49.570 --> 20:51.010]  could be used for this attack.
[20:54.590 --> 20:56.310]  It can hold more data
[20:56.310 --> 20:59.490]  or can have this attached information
[20:59.490 --> 21:02.050]  that extends beyond that maximum size
[21:02.050 --> 21:04.310]  could be used for this attack.
[21:04.310 --> 21:06.570]  That could be TCP or UDP
[21:06.570 --> 21:08.690]  or any IPX stuff.
[21:09.110 --> 21:10.950]  Admittedly, the ping of death attack
[21:10.950 --> 21:12.070]  is kind of old
[21:12.070 --> 21:13.510]  and a little outdated,
[21:13.510 --> 21:16.290]  but I think it works as a really cool
[21:16.290 --> 21:18.610]  and simple quick jumping off point
[21:18.610 --> 21:19.970]  or starting point for us
[21:19.970 --> 21:21.690]  to take a look at some of these evil,
[21:21.690 --> 21:23.610]  nefarious things that we could do
[21:24.590 --> 21:25.910]  with Python and Scapey.
[21:25.910 --> 21:26.830]  So, with that said,
[21:26.830 --> 21:29.330]  let's take a look at the source code here.
[21:29.510 --> 21:31.590]  You can see I'm using the send function
[21:31.590 --> 21:33.630]  which is part of Scapey.
[21:33.630 --> 21:35.050]  We say we've imported everything
[21:35.050 --> 21:36.430]  into our namespace.
[21:36.690 --> 21:38.910]  You could also send just one packet
[21:38.910 --> 21:40.370]  and receive the information back
[21:40.370 --> 21:42.430]  or send packets inside of a loop,
[21:42.430 --> 21:44.690]  but for just one quick shot
[21:44.690 --> 21:46.250]  firing the gun,
[21:46.250 --> 21:48.690]  we can use this send function here.
[21:48.710 --> 21:50.070]  We'll create a fragment
[21:50.070 --> 21:51.970]  as kind of we discussed earlier.
[21:54.590 --> 21:56.210]  It could be rebuilt and reassembled
[21:56.210 --> 21:57.390]  by the victim machine
[21:57.390 --> 21:59.410]  that could potentially cause it
[21:59.410 --> 22:00.890]  to crash and choke.
[22:01.510 --> 22:02.390]  And inside of that,
[22:02.390 --> 22:04.830]  we'll build this ICMP packet
[22:04.830 --> 22:06.030]  just as we've done before
[22:06.030 --> 22:07.430]  in that previous example.
[22:07.430 --> 22:09.510]  However, you can see there at the end
[22:09.510 --> 22:10.730]  we use another divider
[22:10.730 --> 22:12.190]  or add in another layer
[22:12.190 --> 22:13.130]  or some more information
[22:13.130 --> 22:14.630]  into this packet.
[22:14.650 --> 22:17.030]  And I just use a simple dummy string.
[22:17.030 --> 22:18.130]  I just use the letter X
[22:24.590 --> 22:26.270]  and I've strapped to this ping packet
[22:26.270 --> 22:28.230]  so that I can send a ping of death
[22:28.230 --> 22:30.190]  that's just a little too big
[22:30.190 --> 22:31.390]  and maybe that machine
[22:31.390 --> 22:33.610]  is biting off more than it can chew.
[22:33.630 --> 22:36.530]  It'll choke and it'll fall right over.
[22:36.530 --> 22:38.050]  I did mention though
[22:38.750 --> 22:40.370]  that this ping of death attack
[22:40.370 --> 22:43.210]  is less common today.
[22:44.310 --> 22:45.530]  More so now,
[22:45.530 --> 22:47.130]  you'll see other kinds of attacks
[22:47.130 --> 22:49.970]  that are still this denial of service attack.
[22:49.970 --> 22:51.410]  We're being a jerk.
[22:51.410 --> 22:53.270]  We're overwhelming, flooding
[22:54.590 --> 22:56.510]  and it's bogging down the resources
[22:56.510 --> 22:58.590]  on that victim or target.
[22:59.250 --> 23:00.450]  So one of the more common ones
[23:00.450 --> 23:01.150]  you'll see now
[23:01.150 --> 23:05.350]  is perhaps an ICMP or a ping flood.
[23:05.350 --> 23:06.550]  And we can certainly send
[23:06.550 --> 23:08.070]  other kinds of floods.
[23:08.070 --> 23:09.730]  One of the most common ones you might see
[23:09.730 --> 23:11.490]  is a SYN flood.
[23:12.110 --> 23:14.410]  SYN flood is another denial of service
[23:14.410 --> 23:15.330]  or DOS attack
[23:15.330 --> 23:17.010]  which will make that server,
[23:17.010 --> 23:19.930]  your victim, unavailable to respond.
[23:20.170 --> 23:21.730]  It'll be just too busy.
[23:21.730 --> 23:22.790]  It'll be bogged down.
[23:22.790 --> 23:23.810]  It'll be hosed
[23:23.810 --> 23:26.110]  because something will be consuming
[23:26.110 --> 23:29.470]  all of the available server resources.
[23:29.710 --> 23:30.690]  We're going to cause that
[23:30.690 --> 23:32.730]  by sending packets
[23:33.650 --> 23:36.650]  with that SYN flag set.
[23:36.650 --> 23:39.030]  So you know TCP packets, right?
[23:39.310 --> 23:42.130]  TCP being the Transmission Control Protocol
[23:42.590 --> 23:44.970]  which ensures there is a connection in place
[23:44.970 --> 23:47.910]  by using the three-way handshake, right?
[23:48.290 --> 23:50.730]  The client on one side of the conversation
[23:51.730 --> 23:53.150]  will send to the server
[23:53.850 --> 23:55.850]  a packet with the SYN flag set
[23:55.850 --> 23:58.040]  to synchronize or start the conversation
[23:58.310 --> 24:00.810]  and begin requesting communication.
[24:00.810 --> 24:02.910]  The server over on the other end
[24:02.910 --> 24:04.390]  of the conversation
[24:04.390 --> 24:06.550]  will say and respond back
[24:06.550 --> 24:08.370]  with a SYN ACK packet
[24:08.370 --> 24:11.290]  or a packet sent with those flags set.
[24:11.350 --> 24:13.690]  Finally, the client,
[24:13.690 --> 24:15.410]  knowing that the server has responded,
[24:15.410 --> 24:17.570]  that someone actually answered the phone,
[24:17.570 --> 24:19.750]  it will respond once more
[24:19.750 --> 24:21.710]  with an ACK flag set.
[24:21.730 --> 24:23.510]  On a packet or the acknowledgement,
[24:23.510 --> 24:25.570]  okay, someone is listening and we can talk.
[24:25.570 --> 24:27.150]  We can have this conversation.
[24:27.910 --> 24:29.930]  Interesting thing though,
[24:29.930 --> 24:31.870]  on step two of that process
[24:31.870 --> 24:35.270]  or in the middle of the three-way handshake communication,
[24:35.270 --> 24:38.610]  the server, while it sends that SYN ACK packet,
[24:38.610 --> 24:41.690]  it will wait and wait to receive
[24:41.690 --> 24:43.390]  that ACK packet from the client
[24:43.390 --> 24:46.170]  so that it can begin having this conversation.
[24:47.850 --> 24:50.750]  So the attack is simple.
[24:50.750 --> 24:53.930]  We just send a ton of SYN packets
[24:53.930 --> 24:56.250]  where we're just starting all these conversations.
[24:56.250 --> 24:57.510]  We're dialing the phone,
[24:57.510 --> 25:00.170]  but once someone answers, we don't care.
[25:00.170 --> 25:03.050]  We don't respond to them with an ACK packet.
[25:03.050 --> 25:05.310]  So they're just, they're overwhelmed, right?
[25:05.310 --> 25:06.670]  The phone keeps ringing.
[25:06.670 --> 25:08.010]  Someone, they're going to pick it up
[25:08.010 --> 25:09.250]  and they're going to want to talk to someone,
[25:09.250 --> 25:10.470]  but no one will be there.
[25:10.470 --> 25:12.650]  They're just not having this conversation,
[25:12.650 --> 25:13.870]  but they're still holding the phone
[25:13.870 --> 25:16.070]  and more are ringing.
[25:17.010 --> 25:20.070]  That will hog all the resources.
[25:21.210 --> 25:23.330]  That will cause that target victim
[25:24.030 --> 25:27.790]  to not be able to respond to other legitimate traffic
[25:27.790 --> 25:32.290]  because, okay, hey, they're busy, tied up with other stuff.
[25:32.290 --> 25:35.430]  All those resources are being utilized right now.
[25:35.890 --> 25:38.750]  Because this attack brings that server
[25:38.750 --> 25:41.890]  to the halfway point in the three-way handshake, right?
[25:41.890 --> 25:43.430]  They started the communication,
[25:43.430 --> 25:46.390]  but have not responded to the server's acknowledgement.
[25:46.670 --> 25:50.170]  That means that it's halfway communicated.
[25:50.170 --> 25:53.090]  That's why it's called that half-open attack.
[25:53.430 --> 25:54.690]  Kind of interesting.
[25:54.970 --> 25:57.150]  So let's take a look at the source code, right?
[25:57.150 --> 26:00.170]  Scapey, again, makes this super-duper easy.
[26:00.250 --> 26:01.950]  We're performing this attack
[26:01.950 --> 26:04.710]  in, realistically, two lines of code
[26:05.210 --> 26:07.070]  that could even be shortened to one
[26:07.070 --> 26:09.050]  because, hey, maybe we could abstract out
[26:09.050 --> 26:11.850]  that object that's not necessary for that SYN flood.
[26:11.850 --> 26:13.810]  We could just pass that to the function.
[26:13.970 --> 26:17.810]  So I'm creating this SYN flood object, or variable, right?
[26:17.810 --> 26:20.750]  I send in a keyword argument for the destination.
[26:20.750 --> 26:22.610]  Again, just an IP address we'll use.
[26:22.610 --> 26:24.690]  We'll set an ID number for that packet
[26:24.690 --> 26:27.010]  and we'll specify the time to live.
[26:27.010 --> 26:29.050]  These values aren't extremely important
[26:29.050 --> 26:31.130]  for kind of just our discussion,
[26:31.130 --> 26:34.870]  but obviously that next layer certainly is.
[26:34.870 --> 26:37.790]  We create a TCP portion of this packet
[26:37.790 --> 26:41.830]  and that SPORT, or S-port is how you should read that,
[26:41.830 --> 26:43.810]  for our source port,
[26:43.810 --> 26:47.230]  that's just going to be a random, ephemeral port
[26:47.230 --> 26:48.890]  that Scapey will help us generate
[26:48.890 --> 26:51.410]  with that RANDSHORT function there.
[26:51.510 --> 26:54.330]  That'll return something to make it look like,
[26:54.330 --> 26:56.790]  okay, we're coming from a different port every time.
[26:57.130 --> 26:59.310]  The D-port, or the destination port,
[26:59.310 --> 27:00.770]  will be passed in as a list,
[27:00.770 --> 27:01.890]  or a little Python array.
[27:01.890 --> 27:04.450]  We'll just send this over to port 80, HTTP.
[27:04.510 --> 27:06.770]  You could specify this to whatever you wanted to,
[27:06.770 --> 27:09.410]  maybe SSH or anything specifically.
[27:09.710 --> 27:12.010]  Specify a sequence number,
[27:12.010 --> 27:13.630]  specify an acknowledgement number.
[27:13.630 --> 27:17.490]  Again, for this example, those don't really matter all that much,
[27:17.490 --> 27:19.650]  but maybe they could in other scenarios.
[27:19.650 --> 27:23.210]  A window size, and the most important thing here,
[27:23.210 --> 27:27.650]  the flags that are set on this TCP packet.
[27:27.690 --> 27:29.450]  Obviously, I'm just passing in a string here
[27:29.450 --> 27:31.230]  with that capital S,
[27:31.610 --> 27:35.610]  and certainly enough, that stands for SYN, right?
[27:35.610 --> 27:39.430]  The SYN flag has been set on this packet.
[27:39.430 --> 27:44.810]  So we have created one packet that is just a SYN packet.
[27:44.810 --> 27:49.310]  The very, very first step in that TCP three-way handshake.
[27:49.570 --> 27:51.110]  The next line below,
[27:51.110 --> 27:53.730]  we're going to end up using that SR loop function
[27:53.730 --> 27:55.550]  that Scapey makes available to us,
[27:55.550 --> 27:59.410]  and that is going to send and receive packets in a loop.
[27:59.410 --> 28:02.070]  So we will repeatedly, over and over and over again,
[28:02.070 --> 28:03.910]  send this packet.
[28:04.890 --> 28:08.030]  The keyword arguments there, that enter or the interval,
[28:08.030 --> 28:10.070]  we'll send those at three-tenths of a second.
[28:10.070 --> 28:12.870]  We'll retry every two seconds if that kind of gets dropped,
[28:12.870 --> 28:15.630]  and we'll have a timeout of four seconds.
[28:15.710 --> 28:18.150]  Again, those are a little extraneous,
[28:18.150 --> 28:20.530]  but the point that we're getting across right now
[28:20.530 --> 28:24.050]  is that we are looping a SYN packet being sent
[28:24.050 --> 28:26.110]  over and over and over again.
[28:26.110 --> 28:29.270]  We are flooding that target victim server
[28:29.690 --> 28:31.850]  with this SYN flood attack.
[28:31.850 --> 28:34.170]  In the case of the line of code there,
[28:34.170 --> 28:36.650]  we have an answered and unanswered information
[28:36.650 --> 28:39.590]  that's being stored as a return value of that SR loop.
[28:39.590 --> 28:41.290]  That'll just return a tuple, okay,
[28:41.290 --> 28:43.990]  or a list of what packets actually had a response
[28:43.990 --> 28:45.010]  and what didn't.
[28:46.210 --> 28:47.930]  The point that I'm trying to get across
[28:47.930 --> 28:50.730]  is that just these two lines of code
[28:50.730 --> 28:53.050]  are putting together this attack,
[28:53.050 --> 28:55.110]  and it's super-duper simple.
[28:55.110 --> 28:57.390]  All you've done is outlined the structure.
[28:57.390 --> 28:59.510]  You've orchestrated this packet,
[28:59.510 --> 29:00.930]  and now you can put it to work.
[29:01.850 --> 29:03.750]  You can use it as a SYN flood.
[29:04.590 --> 29:06.750]  You might notice, though,
[29:06.750 --> 29:09.930]  in this example, with this setup right here,
[29:09.930 --> 29:12.090]  we're sending this SYN flood attack
[29:12.690 --> 29:15.670]  just with our attacker machine.
[29:15.890 --> 29:17.650]  One machine.
[29:18.130 --> 29:19.910]  So, potentially,
[29:19.910 --> 29:21.830]  that endpoint or that target,
[29:21.830 --> 29:23.230]  the victim server,
[29:23.230 --> 29:26.430]  once it realizes, hey, I'm under attack, right?
[29:26.430 --> 29:27.810]  I'm in danger.
[29:27.810 --> 29:29.630]  If they kind of had the opportunity
[29:29.630 --> 29:30.650]  to look through some logs
[29:30.650 --> 29:32.550]  or could figure something out and determine,
[29:32.550 --> 29:34.810]  oh, I know the source of this attack.
[29:34.910 --> 29:36.900]  I can just block it off.
[29:37.710 --> 29:39.010]  Well, you're totally right.
[29:39.010 --> 29:40.990]  That's absolutely doable.
[29:40.990 --> 29:42.790]  For that reason, this kind of thing
[29:42.790 --> 29:46.990]  isn't often done just with one host.
[29:47.310 --> 29:49.770]  Just with one attacking machine.
[29:49.770 --> 29:51.690]  So you bring in the conversation,
[29:51.690 --> 29:54.710]  okay, we're performing a denial-of-service attack,
[29:54.770 --> 29:56.900]  a DOS attack or a DOS attack.
[29:57.560 --> 30:01.740]  But if we had more machines in this pool,
[30:01.740 --> 30:04.100]  if we were attacking with multiple hosts,
[30:04.100 --> 30:07.500]  we could be performing a distributed denial-of-service attack
[30:07.500 --> 30:10.600]  or that DDoS, D-D-O-S.
[30:10.820 --> 30:14.420]  That might make it a little bit harder to do,
[30:14.420 --> 30:16.260]  harder to track down, harder to trace.
[30:16.260 --> 30:18.380]  However, we could do even more.
[30:18.380 --> 30:19.960]  We could go one step beyond that
[30:19.960 --> 30:23.460]  when we say our source IP address,
[30:23.460 --> 30:26.120]  we don't want that to look like it's coming from us.
[30:26.120 --> 30:27.380]  We want to hide it.
[30:27.380 --> 30:30.580]  We want to mask it and obfuscate that just a little bit more.
[30:30.760 --> 30:32.900]  But you can tell with Scapey,
[30:32.900 --> 30:36.620]  we are crafting our packets at the granular level.
[30:36.620 --> 30:40.620]  What's to stop us from specifying just that information,
[30:40.620 --> 30:43.700]  just the bytes, the real, real information that we need
[30:43.700 --> 30:46.000]  within that header of the packet?
[30:46.080 --> 30:48.860]  We could say that our source IP address
[30:48.860 --> 30:52.480]  comes from a different IP address,
[30:52.480 --> 30:53.640]  comes from a different host.
[30:53.640 --> 30:55.520]  We can spoof our IP address
[30:56.120 --> 30:58.020]  simply by passing in the keyword argument.
[30:58.020 --> 30:59.660]  Just as you see the example there,
[30:59.660 --> 31:04.720]  we specify that DST keyword argument as an IP address string.
[31:04.720 --> 31:10.740]  We could just as easily specify SRC or the source IP address
[31:10.740 --> 31:14.360]  and make it look like we are coming from a different location.
[31:14.360 --> 31:19.340]  We can spoof our IP address super easily with Scapey.
[31:19.360 --> 31:22.840]  And we can use that as a segue into the next attack,
[31:22.840 --> 31:25.320]  DNS amplification attacks.
[31:25.320 --> 31:29.360]  A DNS amplification attack is a really interesting technique
[31:29.360 --> 31:33.360]  that abuses the regular functionality of DNS,
[31:33.360 --> 31:34.880]  or the domain name system,
[31:34.880 --> 31:40.540]  to again overwhelm, spam, and flood a target or victim machine.
[31:40.540 --> 31:42.940]  The way that this works is that the attacker
[31:42.940 --> 31:46.180]  actually sends a legitimate regular request
[31:46.180 --> 31:52.260]  to a DNS name server asking for as much information as they can.
[31:52.260 --> 31:57.020]  So their request is a regular kind of small, tiny packet
[31:57.020 --> 31:58.560]  just asking for information,
[31:58.560 --> 32:00.880]  and the domain name server will respond
[32:00.880 --> 32:03.920]  with as much information as possible,
[32:03.920 --> 32:07.760]  and that way you get a much larger packet in response.
[32:07.760 --> 32:12.320]  The trick here is that with this DNS amplification attack,
[32:12.320 --> 32:16.480]  the attacker sets their IP address, the source,
[32:16.480 --> 32:20.080]  back to the actual victim or the target server
[32:20.080 --> 32:23.360]  that they're aiming to overwhelm and choke.
[32:23.540 --> 32:26.260]  You can see this here in the source code, right?
[32:26.260 --> 32:28.960]  We're defining, again, another object or variable
[32:28.960 --> 32:30.660]  to keep track of our packet.
[32:30.660 --> 32:34.660]  We're defining an IP header, but interestingly enough,
[32:34.660 --> 32:37.500]  we supply that SRC, keyword value,
[32:37.500 --> 32:39.880]  or the source IP address of the packet
[32:39.880 --> 32:41.880]  that we're going to be formulating.
[32:42.120 --> 32:44.820]  Note, this will act as our victim.
[32:44.820 --> 32:49.420]  This is the target machine that will have the domain name,
[32:49.420 --> 32:51.640]  and attack that large request.
[32:51.640 --> 32:53.920]  You can see, again, our division symbol
[32:53.920 --> 32:55.940]  or the forward slash to add new layers,
[32:55.940 --> 32:59.400]  and we're adding a UDP packet portion, right?
[32:59.400 --> 33:02.400]  We'll set the D port or the destination port to 53,
[33:02.400 --> 33:05.960]  the default port for the domain name system or DNS servers,
[33:05.960 --> 33:09.040]  and what we're going to query from this DNS
[33:09.040 --> 33:11.700]  is anything we'd particularly like.
[33:11.700 --> 33:15.260]  Here, I'll just ask for anything regarding google.com
[33:15.260 --> 33:16.580]  or that domain.
[33:16.580 --> 33:18.820]  You could, of course, ask for any type
[33:19.420 --> 33:21.060]  of resource record you'd like,
[33:21.060 --> 33:24.260]  an A record, a text record, a CNAME record.
[33:24.480 --> 33:26.240]  Generally, with this attack,
[33:26.240 --> 33:29.760]  you could expect to see the attacker request for any,
[33:29.760 --> 33:34.300]  as in return all of the resource records you could give me.
[33:34.300 --> 33:36.400]  We'll have that packet formulated,
[33:36.400 --> 33:40.380]  stored, and encapsulated in that DNS AMP object and variable,
[33:40.380 --> 33:43.820]  and again, we will just send that packet along.
[33:43.980 --> 33:46.660]  The DNS server will respond accordingly.
[33:46.660 --> 33:48.720]  It will give all the information it can,
[33:48.720 --> 33:52.120]  but send it to that source IP address,
[33:52.120 --> 33:54.120]  not our actual attacker.
[33:54.120 --> 33:57.480]  That will flood and overwhelm, choke,
[33:57.480 --> 33:59.820]  that target victim server.
[34:00.140 --> 34:02.820]  Obviously, you'd want to have more than one attack
[34:02.820 --> 34:05.400]  or one attacking machine doing this.
[34:05.400 --> 34:08.080]  You could perform this distributed denial of service,
[34:08.080 --> 34:12.600]  that DDoS, or send this request multiple times.
[34:12.600 --> 34:14.440]  But I think this attack is really cool
[34:14.440 --> 34:15.760]  and really interesting.
[34:15.760 --> 34:19.000]  But if you put it in kind of layman's term
[34:19.000 --> 34:21.780]  or normal human explanation,
[34:21.780 --> 34:26.540]  say you are at the drive-thru ordering some fast food to go,
[34:26.540 --> 34:27.840]  or whatever the case may be.
[34:27.840 --> 34:30.800]  Let's say you ask the person or the teller
[34:30.800 --> 34:33.500]  that's chatting with you and taking your order,
[34:33.500 --> 34:37.200]  I want one burger, or I want one drink,
[34:37.200 --> 34:38.700]  or whatever, whatever, whatever.
[34:39.340 --> 34:41.040]  Typically, that job of the teller
[34:41.040 --> 34:43.660]  will read back your order, right?
[34:43.660 --> 34:46.480]  So, envision this scenario.
[34:46.480 --> 34:48.060]  You as the driver, right?
[34:48.060 --> 34:49.860]  You as the attacker, you say,
[34:49.860 --> 34:52.160]  I want everything on the menu.
[34:52.160 --> 34:55.620]  And then, before they can read your order back to you,
[34:55.620 --> 34:57.960]  you drive away and let that next person
[34:57.960 --> 35:00.940]  go ahead and actually hear all that information.
[35:01.080 --> 35:03.300]  So, while you just ask for a small, tiny thing
[35:03.300 --> 35:06.220]  and a simple, hey, give me everything you've got,
[35:06.220 --> 35:08.880]  the next person or your target or your victim
[35:08.880 --> 35:11.100]  is going to be read and enumerated
[35:11.100 --> 35:13.100]  and receive all of the information.
[35:13.660 --> 35:15.520]  So, maybe, I don't know,
[35:16.700 --> 35:19.020]  a one scale for your packet
[35:19.020 --> 35:22.480]  could respond to a 10 in the response
[35:22.480 --> 35:24.780]  and what that teller will read out
[35:24.780 --> 35:27.420]  to that other person or that individual.
[35:27.440 --> 35:28.740]  Kind of cool.
[35:28.860 --> 35:31.480]  And obviously, another added benefit to this
[35:31.480 --> 35:35.840]  is that the attacker is performing this attack indirectly.
[35:35.840 --> 35:37.980]  They make this request out to an open
[35:37.980 --> 35:40.180]  and accessible DNS resolver,
[35:40.180 --> 35:42.560]  and it will respond and just send that information
[35:42.560 --> 35:46.080]  out to the actual target or victim themselves.
[35:46.080 --> 35:48.540]  The attacker doesn't really leave any fingerprints
[35:48.540 --> 35:51.500]  or trace on the target.
[35:51.660 --> 35:53.660]  It's not reaching it directly.
[35:53.660 --> 35:55.600]  It is an indirect attack.
[35:55.600 --> 35:58.080]  You can see that here again with that syntax,
[35:58.080 --> 36:00.340]  but as always, Scapey is making this
[36:00.340 --> 36:03.880]  really, really simple and honestly, really easy.
[36:04.760 --> 36:08.680]  Okay, now let's talk about our finale attack.
[36:08.680 --> 36:11.900]  I want to discuss BGP abuse.
[36:11.900 --> 36:16.860]  So BGP is the Border Gateway Protocol,
[36:16.860 --> 36:19.100]  and that is the standard routing protocol
[36:19.100 --> 36:21.080]  of the internet today.
[36:21.660 --> 36:25.300]  That means that it's actually telling your computers
[36:25.780 --> 36:27.580]  where these packets are going to go
[36:27.580 --> 36:29.400]  when you're working on the internet
[36:29.400 --> 36:32.880]  or at a large scale, the wide area network, right?
[36:32.880 --> 36:35.360]  So routers using this BGP
[36:35.360 --> 36:37.100]  or the Border Gateway Protocol
[36:37.620 --> 36:40.380]  store a routing table with the best routes
[36:40.380 --> 36:45.020]  in between autonomous systems or AS as an acronym.
[36:45.020 --> 36:48.940]  These autonomous systems are large groups of networks
[36:48.940 --> 36:51.980]  or just a giant large network itself
[36:51.980 --> 36:55.120]  kind of owned and managed by a specific organization
[36:55.120 --> 36:58.240]  or maybe an ISP, an internet service provider.
[36:58.240 --> 37:02.760]  This is important because it's the backbone of the internet.
[37:02.760 --> 37:04.320]  It's the freeway. It's the highway.
[37:04.320 --> 37:06.780]  It's how our packets get from one place to another.
[37:06.780 --> 37:09.280]  It's what makes that large scale growth
[37:09.280 --> 37:11.660]  of the internet possible.
[37:11.800 --> 37:15.020]  I mentioned this freeway and highway analogy, right?
[37:15.020 --> 37:18.580]  And that's the easiest way to kind of envision this attack.
[37:19.200 --> 37:24.200]  What if someone were to, without anyone else knowing,
[37:24.200 --> 37:27.420]  change or modify the road signs or the exits
[37:27.420 --> 37:30.040]  or the different locations on the map?
[37:30.120 --> 37:32.180]  Obviously, this routing table
[37:32.180 --> 37:34.500]  that these routers are using with BGP
[37:34.500 --> 37:37.800]  has to be correct and accurate.
[37:37.800 --> 37:40.560]  Otherwise, traffic, things might be directed
[37:40.560 --> 37:44.780]  and routed to the wrong and incorrect place.
[37:44.780 --> 37:49.020]  On top of that, BGP is working off of TCP,
[37:49.020 --> 37:50.700]  that transmission control protocol
[37:50.700 --> 37:54.220]  that relies on a persistent long-term connection
[37:54.800 --> 37:58.720]  that could potentially offer an attacker a long window
[37:58.720 --> 38:02.180]  or a decent amount of time to be able to tweak things
[38:02.180 --> 38:04.480]  and get in the way and abuse it.
[38:04.480 --> 38:07.780]  BGP was not designed with security in mind.
[38:07.800 --> 38:10.740]  With that said, obviously,
[38:10.740 --> 38:14.400]  there is a lot of room for potential abuse and danger.
[38:14.400 --> 38:16.920]  There could be BGP hijacking,
[38:16.920 --> 38:18.960]  another classic denial of service,
[38:18.960 --> 38:20.880]  or some kind of interesting ones
[38:20.880 --> 38:23.480]  where you can do blind BGP attacks
[38:23.480 --> 38:25.380]  to disrupt sessions,
[38:25.380 --> 38:28.460]  taking advantage of that TCP three-way handshake
[38:28.460 --> 38:30.060]  or the communications and conversation
[38:30.060 --> 38:32.560]  that has to happen within that protocol,
[38:32.560 --> 38:35.620]  or even more dangerously,
[38:35.620 --> 38:37.980]  inject routing misconfigurations
[38:37.980 --> 38:40.640]  and change that highway sign,
[38:40.640 --> 38:42.540]  change that exit so that traffic
[38:42.540 --> 38:45.940]  is going to or through a bad place.
[38:46.720 --> 38:48.240]  Okay, so let's zoom in
[38:48.240 --> 38:50.660]  on one of the potential attacks we could use
[38:50.660 --> 38:52.540]  trying to do some blind disruption
[38:52.540 --> 38:54.980]  with these BGP routers.
[38:54.980 --> 38:56.960]  What we're going to do is actually abuse
[38:56.960 --> 38:59.860]  and take advantage of the regular TCP communication
[39:00.320 --> 39:01.860]  and settings and functionality
[39:01.860 --> 39:03.900]  that that protocol would require
[39:03.900 --> 39:07.260]  to keep this BGP session alive.
[39:07.260 --> 39:09.100]  All we were simply going to do
[39:09.100 --> 39:14.800]  is send a packet with that RST or reset flag set.
[39:14.820 --> 39:18.020]  Granted, the situation kind of means
[39:18.020 --> 39:19.940]  our attacking host has to be
[39:19.940 --> 39:21.620]  in the middle of a conversation
[39:21.620 --> 39:23.280]  or listening or eavesdropping in
[39:23.280 --> 39:26.320]  on the conversation between two of the routers
[39:26.700 --> 39:28.580]  using BGP.
[39:28.680 --> 39:30.340]  You can kind of note that here
[39:30.340 --> 39:31.640]  in the comments of the code.
[39:31.640 --> 39:33.220]  I'm specifying a D port
[39:33.220 --> 39:35.020]  or destination port as a value
[39:35.520 --> 39:37.620]  that would ideally match
[39:37.620 --> 39:39.420]  the expected destination port
[39:39.420 --> 39:42.220]  that's being used in an active BGP session
[39:42.220 --> 39:44.500]  or conversation between these two routers.
[39:44.500 --> 39:46.840]  The sequence number and the acknowledgement number
[39:47.220 --> 39:49.940]  also have to match what that victim
[39:50.340 --> 39:52.060]  would be expecting.
[39:52.360 --> 39:54.480]  This is where we get into the conversation
[39:54.480 --> 39:56.560]  of being blind.
[39:56.560 --> 39:57.980]  We might not know that.
[39:57.980 --> 39:59.540]  Maybe it could be fuzz.
[39:59.540 --> 40:00.980]  Potentially you could just hammer this
[40:00.980 --> 40:02.680]  until you get a hit.
[40:02.680 --> 40:04.700]  But at the end of the day,
[40:04.700 --> 40:06.940]  what we're doing is we're sending packets
[40:06.940 --> 40:09.040]  in between these two routers.
[40:09.040 --> 40:12.340]  So I have a source set to one router
[40:12.340 --> 40:14.060]  that is going to act as the peer
[40:14.060 --> 40:15.660]  or one in this conversation
[40:15.660 --> 40:16.600]  and communication
[40:16.600 --> 40:20.140]  and the destination as our victim router.
[40:20.140 --> 40:22.840]  We're sending in that RST flag
[40:22.840 --> 40:25.580]  or the reset signal and notification
[40:25.580 --> 40:27.340]  part of this communication.
[40:27.340 --> 40:29.160]  You can note that in the flags there.
[40:29.160 --> 40:31.540]  Again, R to represent that RST
[40:31.540 --> 40:32.940]  and A for ACK.
[40:32.940 --> 40:34.860]  And of course passing in the appropriate
[40:34.860 --> 40:36.880]  sequence number and acknowledgement number.
[40:36.880 --> 40:38.080]  We send this packet
[40:38.080 --> 40:41.520]  and that target or victim
[40:41.520 --> 40:43.120]  will suddenly believe,
[40:43.120 --> 40:47.040]  okay, this BGP session was just shut down.
[40:47.080 --> 40:48.200]  They just hung up the phone
[40:48.200 --> 40:50.340]  and we're not going to talk anymore.
[40:51.080 --> 40:53.360]  Obviously, there's another router
[40:53.360 --> 40:55.720]  at play, the peer router.
[40:55.720 --> 40:58.600]  And this BGP protocol,
[40:58.600 --> 40:59.480]  the way that it's working
[40:59.480 --> 41:01.280]  is that it's sending any type
[41:01.280 --> 41:03.640]  of four potential messages.
[41:03.640 --> 41:05.860]  BGP could work with an open message
[41:05.860 --> 41:07.880]  or a notification message
[41:08.300 --> 41:10.040]  or a keep alive message
[41:10.040 --> 41:11.900]  or an update message.
[41:11.900 --> 41:14.960]  We'll tune into that update message soon.
[41:14.960 --> 41:17.140]  But what's going to happen here
[41:17.140 --> 41:18.720]  is that that peer router
[41:18.720 --> 41:21.000]  will notice it's still trying to work
[41:21.000 --> 41:22.040]  and have this conversation.
[41:22.040 --> 41:24.900]  And yet the other router, our victim,
[41:25.720 --> 41:27.560]  is down with that RST flag.
[41:27.560 --> 41:28.950]  It's no longer talking.
[41:29.440 --> 41:31.140]  Because of BGP,
[41:31.140 --> 41:33.600]  there might be some keep alive messages
[41:33.600 --> 41:34.860]  in the conversation
[41:34.860 --> 41:36.720]  and that other victim router
[41:37.610 --> 41:39.880]  will restore. It will recover.
[41:39.880 --> 41:41.540]  This might take a minute,
[41:41.540 --> 41:42.640]  but it'll happen.
[41:42.640 --> 41:45.020]  So we could momentarily
[41:45.590 --> 41:46.970]  disrupt the communication,
[41:47.300 --> 41:50.880]  but maybe that will again be revived.
[41:50.880 --> 41:52.720]  If you wanted to,
[41:52.720 --> 41:53.900]  I don't know. Again,
[41:53.900 --> 41:56.280]  we're working in blind territory.
[41:56.280 --> 41:57.960]  You could potentially be hammering this
[41:57.960 --> 41:59.200]  over and over and over again
[41:59.200 --> 42:01.780]  and trying to keep shutting it down.
[42:01.940 --> 42:04.100]  Maybe that could be a worthwhile attack
[42:04.620 --> 42:06.180]  with BGP.
[42:08.160 --> 42:10.320]  Let's take a look at another example
[42:10.320 --> 42:12.100]  where we go a little bit more in depth
[42:12.100 --> 42:14.060]  and this gets a little bit more complicated
[42:14.060 --> 42:16.580]  because we're going to try and do a blind inject
[42:16.580 --> 42:19.960]  or supplying fake, malicious,
[42:19.960 --> 42:21.520]  bad routing information
[42:21.520 --> 42:23.100]  or hijacking the routes
[42:23.900 --> 42:26.280]  that the BGP protocol will use.
[42:26.280 --> 42:27.900]  So again, we're working in the scenario
[42:27.900 --> 42:29.820]  of an attacker machine
[42:29.820 --> 42:31.360]  within the conversation
[42:31.360 --> 42:33.280]  of two routers that are working
[42:33.900 --> 42:35.440]  with this BGP protocol
[42:35.440 --> 42:37.700]  and in the source code with Scapey,
[42:37.700 --> 42:39.120]  you can see I've ran this
[42:39.120 --> 42:40.580]  load contrib function
[42:40.580 --> 42:42.760]  to load a contributed package
[42:42.760 --> 42:44.780]  or a portion of Scapey
[42:44.780 --> 42:46.920]  to actually access more of the BGP
[42:47.820 --> 42:49.600]  functions and variables
[42:49.600 --> 42:50.960]  and work that we could do
[42:50.960 --> 42:53.440]  to actually modify BGP packets
[42:53.900 --> 42:54.500]  within our code.
[42:54.540 --> 42:56.620]  Again, my destination port
[42:56.620 --> 42:58.420]  sequence number and acknowledgement number
[42:58.420 --> 43:00.000]  might need to be tweaked or modified
[43:00.000 --> 43:01.680]  to match this conversation
[43:01.680 --> 43:03.700]  and they potentially could be
[43:03.700 --> 43:05.280]  perhaps fuzzed,
[43:05.280 --> 43:06.620]  but what we'll be doing
[43:06.620 --> 43:10.180]  is we'll be defining a whole new BGP packet.
[43:10.180 --> 43:11.620]  We'll set up an origin,
[43:11.620 --> 43:13.540]  we'll set up a note for our AS
[43:13.540 --> 43:14.860]  or autonomous system
[43:14.860 --> 43:17.240]  and specify the next individual
[43:17.240 --> 43:18.940]  or that router IP address
[43:18.940 --> 43:20.500]  that we'll be sending this to
[43:23.900 --> 43:25.660]  the most interesting thing here
[43:25.660 --> 43:27.760]  is that path update variable
[43:27.760 --> 43:28.960]  down at the bottom.
[43:28.960 --> 43:31.580]  We're going to be specifying a new malicious route
[43:31.580 --> 43:34.180]  5.5.5.0
[43:34.180 --> 43:35.300]  slash 24
[43:35.300 --> 43:37.080]  which you can kind of decipher
[43:37.080 --> 43:39.040]  from that syntax there.
[43:39.040 --> 43:41.260]  Then we'll go ahead and send this packet
[43:41.260 --> 43:43.220]  with that path update.
[43:43.500 --> 43:44.440]  Now this is interesting
[43:44.440 --> 43:46.820]  because it could realistically result
[43:46.820 --> 43:49.500]  in one of three different things.
[43:49.500 --> 43:50.720]  The first case,
[43:50.720 --> 43:52.780]  if all the stars aligned,
[43:53.900 --> 43:54.120]  we have the source number
[43:54.120 --> 43:56.820]  and acknowledgement numbers right in the session.
[43:56.820 --> 43:58.880]  And if we were within the correct window
[43:58.880 --> 44:00.280]  of that conversation,
[44:00.280 --> 44:03.020]  our malicious route could be inserted
[44:03.020 --> 44:05.120]  and injected into the routing table
[44:05.120 --> 44:06.880]  and traffic could potentially
[44:06.880 --> 44:08.740]  flow through that.
[44:08.740 --> 44:10.680]  We may have very well changed
[44:10.680 --> 44:11.760]  the highway signs
[44:11.760 --> 44:14.020]  and we're directing packets and communication
[44:14.020 --> 44:15.880]  now going to or through
[44:16.300 --> 44:17.920]  a different place.
[44:18.400 --> 44:20.520]  In the other case,
[44:20.520 --> 44:22.820]  I guess I'll call this case number three,
[44:23.900 --> 44:24.720]  we fail.
[44:24.720 --> 44:26.020]  It doesn't work.
[44:26.040 --> 44:27.380]  Maybe our timing was off,
[44:27.380 --> 44:28.940]  maybe the variables at play
[44:28.940 --> 44:30.920]  just weren't matching in the conversation
[44:30.920 --> 44:33.120]  and that didn't take.
[44:33.200 --> 44:34.400]  Kind of a bummer,
[44:34.400 --> 44:35.660]  but we know, okay,
[44:35.660 --> 44:36.740]  that might be natural
[44:36.740 --> 44:38.740]  with our blind attack here.
[44:38.840 --> 44:41.020]  And what I'll call case number two
[44:41.020 --> 44:42.960]  or kind of the other scenario
[44:42.960 --> 44:44.040]  we can keep in mind
[44:44.040 --> 44:47.360]  is we're showcasing conversation
[44:47.360 --> 44:50.620]  between two BGP routers right now.
[44:53.900 --> 44:54.580]  We have a BGP router in place
[44:54.580 --> 44:57.240]  that is not part of this conversation
[44:57.460 --> 44:59.260]  or not pertinent to this attack
[44:59.260 --> 45:01.200]  happening between our source
[45:01.200 --> 45:02.540]  and destination.
[45:02.540 --> 45:04.100]  You can mentally map that
[45:04.100 --> 45:06.100]  to a client and server, I suppose.
[45:06.100 --> 45:08.900]  Maybe an external or third party router
[45:08.900 --> 45:10.440]  still present,
[45:10.440 --> 45:12.100]  working with all these routes.
[45:12.340 --> 45:14.300]  If our victim,
[45:14.300 --> 45:16.500]  if our target upon success
[45:16.500 --> 45:18.240]  of getting this injected
[45:18.240 --> 45:20.940]  new malicious routing information,
[45:20.940 --> 45:23.700]  that will try and propagate it out.
[45:23.900 --> 45:27.020]  Maybe that other third party router,
[45:27.020 --> 45:29.060]  it will receive that new information
[45:29.060 --> 45:30.280]  to take in this route.
[45:30.280 --> 45:32.540]  It could potentially, again,
[45:32.540 --> 45:33.860]  just not being in sync
[45:33.860 --> 45:35.400]  within the conversation.
[45:35.400 --> 45:37.220]  The receiving number
[45:37.220 --> 45:39.820]  might not match the kind of victim
[45:39.820 --> 45:41.140]  and target sending number
[45:41.460 --> 45:43.640]  in the sequence and conversation.
[45:43.640 --> 45:44.840]  And that third party router
[45:44.840 --> 45:47.340]  will identify the mismatch
[45:47.820 --> 45:49.520]  and it will try and acknowledge
[45:49.520 --> 45:51.120]  and send responses like,
[45:51.120 --> 45:52.920]  hey, I can't compute this.
[45:53.900 --> 45:54.740]  I might send an acknowledge
[45:54.740 --> 45:57.120]  or a notification this is wrong.
[45:57.120 --> 45:58.700]  That other router is still trying
[45:58.700 --> 46:00.120]  to send over this update,
[46:00.120 --> 46:01.020]  but it's still receiving
[46:01.020 --> 46:02.300]  and now it's going to send
[46:02.300 --> 46:04.360]  its own ACK and acknowledgement.
[46:04.360 --> 46:05.860]  And those two will get in a little bit
[46:05.860 --> 46:07.480]  of an ACK war.
[46:07.480 --> 46:08.660]  They'll be repeatedly sending
[46:08.660 --> 46:10.060]  acknowledgements to one another.
[46:10.060 --> 46:11.500]  And this will happen at least
[46:11.500 --> 46:13.020]  until a timeout occurs
[46:13.020 --> 46:16.600]  and the session will be disrupted.
[46:16.680 --> 46:18.500]  It'll just shut down and stop.
[46:23.900 --> 46:24.880]  And eventually a keep alive
[46:24.880 --> 46:27.140]  will be in the midst of the conversation
[46:27.140 --> 46:28.940]  and it will restore.
[46:29.320 --> 46:32.500]  That might not be a minute in length
[46:32.500 --> 46:34.260]  as opposed to our previous example
[46:34.260 --> 46:36.920]  with that RST or reset flag being set.
[46:36.920 --> 46:38.360]  But this could take maybe four
[46:38.360 --> 46:40.000]  or five minutes for that session
[46:40.000 --> 46:41.080]  to come back to life
[46:41.080 --> 46:44.360]  after they've realized this mismatch.
[46:44.360 --> 46:46.000]  So maybe that could be
[46:46.280 --> 46:47.500]  a bit more of a dangerous
[46:47.500 --> 46:49.540]  or maybe worthwhile
[46:49.540 --> 46:50.660]  depending on your avenue
[46:50.660 --> 46:52.260]  or your outlook here
[46:52.260 --> 46:54.980]  for this attack.
[46:55.760 --> 46:57.900]  So we've talked about a few attacks.
[46:57.900 --> 46:59.580]  I hope some of those were kind of cool
[46:59.580 --> 47:00.440]  and kind of interesting
[47:00.440 --> 47:04.300]  in the conversation to take down the internet.
[47:04.300 --> 47:07.380]  I wanted to showcase some IRL cases
[47:07.380 --> 47:08.420]  or some real stuff
[47:08.420 --> 47:11.240]  where these sort of things actually happened.
[47:11.240 --> 47:12.760]  Maybe not an attack
[47:12.760 --> 47:14.400]  but at least a mishap
[47:14.400 --> 47:16.360]  that showcases some of the weakness
[47:16.360 --> 47:17.760]  between these protocols.
[47:17.760 --> 47:18.940]  Especially BGP
[47:19.800 --> 47:21.880]  or that Border Gateway Protocol.
[47:21.880 --> 47:24.980]  This was June 24th of 2019.
[47:24.980 --> 47:26.880]  Some of you might remember this.
[47:26.880 --> 47:28.780]  It seemed like all of the internet
[47:28.780 --> 47:29.940]  was being funneled through
[47:29.940 --> 47:32.620]  some small shop in like Pennsylvania
[47:32.620 --> 47:33.720]  or something.
[47:33.720 --> 47:36.200]  This is over on CloudFlare's blog
[47:36.200 --> 47:38.060]  if you're interested and you might have seen
[47:38.060 --> 47:39.860]  I've already referenced some CloudFlare stuff
[47:39.860 --> 47:41.560]  as we've gone through the talk.
[47:41.560 --> 47:43.240]  This dives into a little bit more
[47:43.240 --> 47:45.880]  of the BGP optimizer that was in use
[47:45.880 --> 47:47.520]  and that would kind of split
[47:47.520 --> 47:49.800]  or segment different routes
[47:49.800 --> 47:52.760]  or giant networks into smaller pieces.
[47:52.760 --> 47:54.500]  And it seemed that there was a little bit
[47:54.500 --> 47:56.060]  of a leak from Verizon
[47:56.060 --> 47:58.160]  where some of the BGP output
[47:58.160 --> 48:00.080]  was being pushed and propagated
[48:00.080 --> 48:02.980]  and updated again through to DQE
[48:02.980 --> 48:04.620]  and CloudFlare, etc.
[48:04.620 --> 48:06.220]  And that would take down
[48:06.560 --> 48:07.260]  a decent amount of stuff
[48:07.260 --> 48:10.100]  even between Amazon, Linode, and more.
[48:10.100 --> 48:13.020]  It was crazy to see that this was worldwide
[48:13.020 --> 48:14.860]  and CloudFlare I think at the point
[48:14.860 --> 48:17.300]  lost about 15% of traffic.
[48:17.300 --> 48:18.480]  And I think it goes to show
[48:18.480 --> 48:21.020]  just how much trust is really being placed
[48:21.020 --> 48:23.920]  into that BGP or Border Gateway protocol
[48:23.920 --> 48:27.120]  because absolutely these routing tables
[48:27.120 --> 48:29.460]  need to be accurate to ensure that
[48:29.460 --> 48:30.820]  okay, all of the traffic
[48:30.820 --> 48:32.300]  and communications and conversation
[48:32.300 --> 48:33.600]  flowing through these packets
[48:33.600 --> 48:34.860]  is going to the right place
[48:34.860 --> 48:37.520]  so that that infrastructure can handle
[48:37.520 --> 48:39.780]  that load and that amount of traffic.
[48:39.780 --> 48:43.300]  If more than a few fragments
[48:43.300 --> 48:44.260]  and portions of the internet
[48:44.260 --> 48:46.620]  are all funneled through one specific spot
[48:47.180 --> 48:49.060]  that could be potentially bad
[48:49.060 --> 48:52.120]  and take down the internet.
[48:52.820 --> 48:55.160]  This other case is even more recent
[48:55.160 --> 48:57.100]  over on July 17th of this year
[48:57.100 --> 48:58.540]  just a month back.
[48:58.600 --> 49:01.340]  Again, a BGP leak.
[49:01.340 --> 49:02.440]  CloudFlare is reporting on.
[49:02.440 --> 49:04.040]  You can check out their blog.
[49:04.240 --> 49:07.620]  Once again, BGP having an incorrect route
[49:07.620 --> 49:09.640]  that was being propagated and bleeding out
[49:09.640 --> 49:11.440]  and doing damage
[49:12.620 --> 49:14.880]  potentially taking down the internet.
[49:15.120 --> 49:17.120]  I think this blog post is really cool
[49:17.120 --> 49:18.600]  because it showcases a little bit more
[49:18.600 --> 49:20.540]  of the router syntax and talks about
[49:20.540 --> 49:23.100]  the timeline of kind of where things went wrong.
[49:23.300 --> 49:25.220]  CloudFlare actually does put a disclaimer
[49:25.220 --> 49:27.500]  and hey, we just want to enforce
[49:27.500 --> 49:31.180]  this is not the result of an attack.
[49:31.180 --> 49:32.760]  And I want to preface that as well
[49:32.760 --> 49:35.300]  because sure, we've just spent a lot of this talk
[49:35.300 --> 49:37.480]  discussing some of the potential attacks
[49:37.480 --> 49:38.580]  and things we might be doing
[49:38.580 --> 49:40.780]  especially muddling with BGP
[49:41.440 --> 49:43.140]  but this was just again the case
[49:43.140 --> 49:44.920]  of something potentially going wrong
[49:44.920 --> 49:48.500]  with a misconfiguration in those routing tables.
[49:48.500 --> 49:50.100]  So again, just the reliance
[49:50.100 --> 49:52.140]  on how that protocol works
[49:52.140 --> 49:55.640]  and how much faith we end up putting in it.
[49:55.740 --> 49:58.240]  Okay, let's briefly discuss
[49:58.240 --> 50:00.460]  some defense and mitigations
[50:00.460 --> 50:02.560]  at least in regard to some of the attacks
[50:02.560 --> 50:04.220]  and some of the stuff that we've covered.
[50:04.220 --> 50:05.920]  I will breeze through this a little bit
[50:05.920 --> 50:07.160]  or at least kind of go surface level
[50:07.160 --> 50:10.100]  because I'm cognizant we are low on time.
[50:10.100 --> 50:12.440]  But how could we try to prevent
[50:12.440 --> 50:14.380]  some of this stuff?
[50:14.380 --> 50:15.660]  We talked about the ping of death
[50:15.660 --> 50:19.660]  and I mentioned that is generally protected today.
[50:19.660 --> 50:21.560]  Kind of a lot of modern systems and technologies
[50:21.980 --> 50:24.680]  will know how to behave and handle
[50:24.680 --> 50:27.520]  that large ping and packet size.
[50:28.000 --> 50:29.820]  That could really potentially be done
[50:29.820 --> 50:31.360]  just adding a check.
[50:31.360 --> 50:33.080]  Make sure, hey, are we not exceeding
[50:33.080 --> 50:35.300]  that maximum packet size?
[50:35.960 --> 50:37.340]  Another option with that
[50:37.340 --> 50:39.360]  is actually kind of allocating a memory buffer
[50:40.100 --> 50:41.860]  to be able to handle that packet size.
[50:41.860 --> 50:43.760]  I feel like that, I don't know,
[50:43.760 --> 50:46.640]  might not have the real intended effect
[50:46.640 --> 50:47.420]  that we want.
[50:47.420 --> 50:49.000]  I think the protections that we have
[50:49.000 --> 50:50.860]  to just verify and check,
[50:50.860 --> 50:52.840]  hey, are we dealing with an overblown,
[50:52.840 --> 50:53.840]  oversized packet?
[50:53.840 --> 50:55.520]  That makes the most sense.
[50:56.240 --> 50:58.920]  The SYN flood and other flooding attacks,
[50:58.920 --> 51:00.360]  especially with SYN flood,
[51:00.360 --> 51:03.100]  you could be using some server SYN cookies
[51:03.100 --> 51:05.020]  where the server will actually kind of specify
[51:05.300 --> 51:06.980]  a nice token or something specific
[51:06.980 --> 51:08.600]  to that communication.
[51:08.600 --> 51:10.260]  And that would obviously need to be returned
[51:10.260 --> 51:13.020]  and responded back with a response.
[51:13.020 --> 51:14.640]  Or maybe you could recycle
[51:14.640 --> 51:18.220]  the older previous half-open TCP connections
[51:18.220 --> 51:19.580]  that were started.
[51:19.580 --> 51:21.160]  If you realize, okay,
[51:21.160 --> 51:22.700]  this machine is getting overblown
[51:22.700 --> 51:25.480]  with open or half-open connections,
[51:25.480 --> 51:27.220]  we'll roll back to one of the ones
[51:27.220 --> 51:28.100]  that we've got started
[51:28.100 --> 51:31.000]  and just work with that as necessary.
[51:31.000 --> 51:33.740]  For DNS amplification attacks,
[51:33.740 --> 51:36.960]  this one is almost,
[51:36.960 --> 51:39.900]  it seems just natural, right?
[51:40.300 --> 51:41.920]  If the flaw here
[51:41.920 --> 51:43.400]  is that we can just abuse
[51:43.400 --> 51:45.480]  and reach out to the natural behavior
[51:45.480 --> 51:48.000]  of DNS or the domain name systems
[51:48.000 --> 51:49.500]  and those open name servers
[51:49.500 --> 51:51.960]  and resolving servers,
[51:51.960 --> 51:53.420]  limit that number.
[51:53.480 --> 51:55.160]  Maybe we could scope and turn down
[51:55.160 --> 51:56.220]  the stuff that is accessible
[51:56.960 --> 51:59.060]  within your network or a network
[51:59.060 --> 52:00.300]  or what is applicable.
[52:00.300 --> 52:02.460]  Another technique is actually verifying,
[52:02.460 --> 52:04.840]  okay, who is requesting this information?
[52:04.840 --> 52:07.100]  If you check that source IP address,
[52:07.100 --> 52:08.520]  does it come from someone
[52:08.520 --> 52:09.720]  that really should be able
[52:09.720 --> 52:11.860]  to access that and reach that?
[52:11.860 --> 52:15.120]  We have the conversation of DNSSEC, right?
[52:15.120 --> 52:17.160]  But the gimmick
[52:17.160 --> 52:19.200]  with that DNS amplification attack
[52:19.200 --> 52:21.140]  is that it's just the natural
[52:21.140 --> 52:23.460]  functionality of DNS.
[52:23.460 --> 52:24.800]  If someone is asking
[52:24.800 --> 52:26.680]  for all of the resource records
[52:26.680 --> 52:29.680]  you can get by simply requesting any,
[52:29.680 --> 52:31.300]  it's going to give that information
[52:31.300 --> 52:32.340]  back out to you.
[52:32.340 --> 52:33.760]  Just that example that we discussed
[52:33.760 --> 52:35.340]  at the drive-through,
[52:35.340 --> 52:37.100]  you say, hey, I want to know everything
[52:37.100 --> 52:38.980]  on the menu, they have to give you
[52:38.980 --> 52:40.600]  that information because that's
[52:40.600 --> 52:43.600]  just how DNS has to work.
[52:45.340 --> 52:46.340]  BGP.
[52:46.500 --> 52:47.960]  Oh, man.
[52:48.460 --> 52:49.760]  BGP abuse protection
[52:49.760 --> 52:51.860]  is kind of tough, right?
[52:51.860 --> 52:53.660]  Just because, again,
[52:53.660 --> 52:56.440]  this is how it has to work.
[52:56.460 --> 52:58.400]  Knowing that we are assigning
[52:58.400 --> 53:00.340]  the routes and locations
[53:00.340 --> 53:03.140]  and maps for ways
[53:03.140 --> 53:04.760]  to get to places on the internet,
[53:04.760 --> 53:06.920]  that has to be
[53:06.920 --> 53:07.820]  just secure.
[53:07.820 --> 53:09.940]  Unless anyone is monitoring that
[53:09.940 --> 53:12.080]  and knowing when those changes
[53:12.080 --> 53:14.580]  are being put in place,
[53:14.580 --> 53:16.420]  it's hard to
[53:16.420 --> 53:17.880]  lock that down.
[53:17.880 --> 53:19.920]  And BGP itself was not designed
[53:19.920 --> 53:21.180]  with that security in mind.
[53:21.180 --> 53:22.480]  It's working off of TCP
[53:22.480 --> 53:24.280]  as it needs to.
[53:24.280 --> 53:25.500]  Maybe there'll be more developments
[53:25.500 --> 53:27.220]  with BGPSEC, which I believe
[53:27.220 --> 53:28.200]  there are some conversations
[53:28.200 --> 53:29.460]  and research kind of being started
[53:29.460 --> 53:31.080]  in that direction.
[53:31.080 --> 53:33.560]  But anyone that declares
[53:33.560 --> 53:35.900]  changes to routes
[53:35.900 --> 53:38.140]  should be kind of a valid,
[53:38.140 --> 53:39.960]  authoritative, and trusted source,
[53:39.960 --> 53:42.300]  not just a thing that could happen.
[53:42.300 --> 53:44.080]  And when that change
[53:44.080 --> 53:45.640]  does happen,
[53:45.640 --> 53:46.860]  that needs to be monitored
[53:46.860 --> 53:48.880]  and maybe notifications and set
[53:48.880 --> 53:51.320]  aware for individuals to
[53:51.320 --> 53:52.960]  track that.
[53:52.960 --> 53:55.060]  If you are struck by
[53:57.220 --> 53:59.480]  random to whatever BGP attack,
[53:59.480 --> 54:01.440]  you will know it, right?
[54:01.440 --> 54:02.560]  Obviously, okay,
[54:02.560 --> 54:04.040]  signs of increased latency,
[54:04.040 --> 54:05.240]  your network's moving slow,
[54:05.240 --> 54:06.620]  degraded network performance,
[54:06.620 --> 54:08.760]  and just misdirected traffic.
[54:08.800 --> 54:11.840]  That should be a big indicator,
[54:11.840 --> 54:13.400]  an alarm going off in your head.
[54:13.400 --> 54:14.600]  Maybe something's wrong.
[54:14.600 --> 54:16.820]  Potentially, BGP hijack.
[54:16.820 --> 54:19.940]  The internet has been muffed up.
[54:19.940 --> 54:21.920]  All these things we can take
[54:21.920 --> 54:23.540]  into consideration, right?
[54:23.540 --> 54:24.800]  Defense and mitigations,
[54:27.220 --> 54:28.240]  things that we can discuss
[54:28.240 --> 54:30.900]  and talk about and know,
[54:30.900 --> 54:32.740]  just so when we're looking
[54:32.740 --> 54:34.140]  at these attacks and we're kind
[54:34.140 --> 54:35.340]  of taking a look at all these
[54:35.920 --> 54:37.680]  jerk, I don't know,
[54:37.680 --> 54:40.280]  techniques to disrupt,
[54:40.280 --> 54:42.960]  abuse, really annoying,
[54:42.960 --> 54:44.380]  obnoxious denial of service
[54:44.380 --> 54:46.140]  attacks and stuff that is
[54:46.140 --> 54:47.460]  prevalent on the internet.
[54:47.460 --> 54:48.560]  Maybe we can be a little bit
[54:48.560 --> 54:49.940]  more knowledge about it and we
[54:49.940 --> 54:52.700]  won't take down the internet.
[54:54.080 --> 54:56.380]  Okay, this is just a data dump
[54:57.220 --> 54:58.540]  of sources and references that
[54:58.540 --> 54:59.760]  I had kind of used to help put
[54:59.760 --> 55:01.380]  this together. You could
[55:01.380 --> 55:02.720]  hopefully be able to sort through
[55:02.720 --> 55:04.020]  this by kind of the topic or
[55:04.020 --> 55:05.320]  discussion that I've showcased.
[55:05.320 --> 55:06.580]  I didn't include too much stuff
[55:06.580 --> 55:07.960]  in here for Python and Scapey
[55:07.960 --> 55:10.420]  because the documentation and
[55:10.420 --> 55:11.800]  the websites for that you can
[55:11.800 --> 55:13.700]  certainly very easily find online.
[55:13.700 --> 55:15.260]  But some of the specific things,
[55:15.260 --> 55:16.480]  some of the research papers,
[55:16.480 --> 55:17.420]  there's a lot of really cool
[55:17.420 --> 55:19.700]  stuff in here. Cloudflare, of
[55:27.220 --> 55:28.040]  course, has really cool open
[55:28.040 --> 55:29.480]  source tools and utilities that
[55:29.480 --> 55:31.060]  showcase this or even how to
[55:31.060 --> 55:32.700]  defend against it with IP tables
[55:32.700 --> 55:33.860]  or other things that are
[55:33.860 --> 55:35.320]  applicable. There are some
[55:35.320 --> 55:36.260]  really, really cool stuff in
[55:36.260 --> 55:37.900]  here. The Naval Postgraduate
[55:37.900 --> 55:39.360]  School had a research paper out
[55:39.360 --> 55:41.200]  I think back in 2017 that
[55:41.200 --> 55:43.600]  discussed these BGP blind
[55:43.600 --> 55:45.400]  attacks. There's some University
[55:45.400 --> 55:46.520]  of California stuff out there
[55:46.520 --> 55:48.100]  and there's even a black hat
[55:48.100 --> 55:49.820]  presentation that discusses this
[55:57.220 --> 55:58.720]  and more worthwhile stuff over
[55:58.720 --> 56:00.260]  there. And if you're interested,
[56:00.260 --> 56:03.220]  I do, do recommend you do some
[56:03.220 --> 56:04.640]  of that research. Check out
[56:04.640 --> 56:05.580]  some of these references and
[56:05.580 --> 56:06.700]  resources. I hope they are
[56:06.700 --> 56:10.000]  helpful to you. Okay, I'm going
[56:10.000 --> 56:11.980]  to wrap it up. If you have any
[56:11.980 --> 56:13.220]  questions or comments or
[56:13.220 --> 56:14.900]  feedback, I'd love to hear from
[56:14.900 --> 56:16.960]  you. Obviously, I'm putting this
[56:16.960 --> 56:19.700]  out here for you. I'm happy to
[56:19.700 --> 56:20.720]  be part of the community and
[56:20.720 --> 56:22.060]  jamming and meeting everyone and
[56:22.060 --> 56:23.300]  seeing everyone here at DEF CON.
[56:27.220 --> 56:28.220]  If you want to hang out, just
[56:28.220 --> 56:30.140]  want to discuss, please do reach
[56:30.140 --> 56:31.240]  out. You've got my email
[56:31.240 --> 56:32.520]  address, my silly YouTube
[56:32.520 --> 56:33.780]  channel. If you want to see
[56:33.780 --> 56:34.680]  any of my code, that's on
[56:34.680 --> 56:36.080]  GitHub and of course Twitter.
[56:36.080 --> 56:36.900]  And if you want to do some
[56:36.900 --> 56:38.480]  real-time instant messaging,
[56:38.480 --> 56:40.520]  that's my Discord server there.
[56:40.880 --> 56:43.840]  Okay. Holy cow. Thank you so,
[56:43.840 --> 56:45.920]  so much, everybody. I cannot say
[56:45.920 --> 56:47.620]  it enough as I did the beginning
[56:47.620 --> 56:48.640]  of this talk, as I did
[56:48.640 --> 56:49.720]  hopefully through it a little
[56:49.720 --> 56:51.560]  bit. Thank you. Thank you.
[56:51.560 --> 56:53.060]  Thank you. This has been a
[56:53.060 --> 56:54.160]  blast. I hope you enjoy the
[56:54.160 --> 56:55.520]  talk and presentation. I hope
[56:55.520 --> 56:57.840]  you enjoy DEF CON Safe Mode
[56:57.840 --> 56:59.440]  and please stay safe and enjoy
[56:59.440 --> 57:01.240]  yourself. Take care, everybody.
[57:01.240 --> 57:01.740]  Thank you.