WEBVTT 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:01.370 Alrighty, hello everyone. 01:01.470 --> 01:02.410 Welcome. 01:02.410 --> 01:03.610 Thank you for tuning in. 01:03.610 --> 01:04.810 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:28.230 Thank you. 01:28.230 --> 01:29.850 Thank you for being here. 01:29.850 --> 01:38.970 Honestly, seriously, I know things are a little crazy and weird and not how we're used to them being at DEF CON, but thank you so, so much for being here. 01:38.970 --> 01:40.510 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:48.990 Just thank you. 01:48.990 --> 01:50.610 Thanks for being here. 01:50.610 --> 01:52.030 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:03.850 I don't represent them. 02:03.850 --> 02:05.410 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:44.670 Look, I'm talking about it. 02:44.670 --> 02:45.670 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 --> 03:04.590 I can't promise, and I don't mean to make this any written-in-stone gospel or anything, 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:09.550 We talk about security. 03:09.550 --> 03:10.890 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:24.370 The stuff that we're going to talk about and showcase in this presentation, 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:49.430 I used to just do some stuff with the Department of Defense Cyber Crime Center 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:00.350 Again, not speaking for them. 04:00.350 --> 04:02.150 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:17.230 I like to develop and create and host capture the flag events or competitions or exercises and training sets to try and make people better, 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:27.630 I publish and showcase some capture the flag write-ups or programming tutorials, 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:45.770 We'll put down a little bit of a background, 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:58.910 Python is kind of my weapon of choice, but we need to make a distinction between Python 2 versus Python 3 and what we'll kind of be using as our vessel throughout this talk. 04:58.910 --> 05:14.690 Then I'm going to introduce Scapey, one really, really cool Python module or library that you can pull into your Python source code, use with your projects, your other scripts, whatever you're working on to do really, really cool, low-level stuff with network packets, 05:14.690 --> 05:20.170 with the stuff that you would find in PCAPs, 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:27.750 So we'll talk about how to install it, 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:41.230 We'll talk about different attacks that we could perform and we'll kind of zoom in or zoom out as appropriate on some of these different things, like fraud, DNS attacks, BGP, etc. 05:41.710 --> 05:46.950 I do want to showcase a couple of IRL, 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 --> 06:00.770 All about the stuff that we're kind of laying the foundation with here, Python, Scapey, and these network attacks when we're trying to take down the internet. 06:01.290 --> 06:12.350 We'll also discuss some of the defense and mitigation, some things that we could do, some things that we might consider when we take note of all these network attacks we're going to be looking at. 06:12.350 --> 06:17.850 Finally, I'll showcase some of the resources and references that I use to put together this conversation, this talk for you. 06:17.850 --> 06:21.790 And we'll have the boilerplate template slides, 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:44.130 So naturally, we're going to be talking about packets, using Scapey, using Python. 06:44.130 --> 06:45.650 And we'll dive into that more. 06:45.650 --> 06:56.790 But I want to say, the title of this talk, right, the whole theme, take down the internet, 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:15.470 So nothing like leet, super cool, zero days, crazy, like, ninja warrior cyber hacker stuff, 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:23.930 I want to showcase some of this to you, because really I want to show you just how easy it is. 07:23.930 --> 07:31.850 And how Python, the same scripting language that's about on every Unix system, can do this stuff. 07:31.850 --> 07:37.450 And how you could do it, if you really wanted to, 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 --> 08:01.250 We want to make this a little bit of a technical talk, and showcase some code, showcase some real stuff, 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:16.390 Yes, it's a scripting language, it's not compiled, it's read through an interpreter, but it is easy to read, and easy to write. 08:16.390 --> 08:24.630 That means that it's super duper friendly, it's really easy to knock out quick testing scripts, or to rapidly prototype some ideas. 08:24.630 --> 08:35.830 It's just handy and useful, and has a lot of support between all the different libraries, and modules, and packages 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:46.790 Because now we are in a new era, we are in 2020, 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:55.470 Python 2 reached end of life at the start of this year, and now Python 3 is the officially supported version. 08:55.470 --> 09:02.250 Please don't hate me for screaming about that, I just want to make sure, hey, everyone knows, we're using Python 3, 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:27.770 And because it is part of Linux, it's really, really easy to access it, just from the command line, you can simply type in Python, and then you're inside of an interactive shell, or interpreter, to work with the Python language. 09:27.770 --> 09:41.890 I'm kind of being explicit here, I'm using Python 3, with that suffix 3 at the end, you probably will just be able to invoke it as regular Python, and maybe that would spin up Python 3 for you, but if it does fire up Python 2, hey, you should know better, 09:41.890 --> 09:46.890 go fix that up, and hop over to Python 3, now as the officially supported version. 09:46.990 --> 10:01.610 Python, while we could be working inside of the language, within the interpreter, or within that shell, oftentimes you'll likely want to create a script, or file with a .py extension, maybe a shebang line, and you can invoke it and run it with Python, 10:01.610 --> 10:07.730 just as an automated tool, not manually working through the interpreter, or the interactive shell there. 10:07.730 --> 10:18.010 In a lot of our conversations, what we'll be discussing, I'm assuming you're going to end up using this inside of a script, with a .py extension, and you don't need that interactive interpreter. 10:18.010 --> 10:26.070 Okay, let's move on, because you probably all already know about Python, 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:42.330 It is a module, it's a library, it's something you can just install, pull into use with your Python code, and it gives you the ability to craft network packets. 10:42.330 --> 11:02.410 You can customize them, you can forge them, you can create them, whatever you want, your wildest dreams, whatever sort of network layers or protocols or things that you want to use, you can get that fine-tuned, zoomed-in, microscopic customization of what that packet looks like, 11:02.410 --> 11:04.150 and that's super-duper cool. 11:04.150 --> 11:20.730 It's easy to install, I'm showcasing some commands here, I'm assuming, okay, a Debian-based distribution, maybe Ubuntu, you'll do a little sudo apt update, and you'll install pip, if you're working with that little handy Python package manager, and let's use pip install scapey. 11:21.410 --> 11:27.830 Now, you can run Scapey in one of two ways, very, very similar to what we talked about in Python, right? 11:27.830 --> 11:38.510 Scapey could be interactive, and you could work inside of an interpreter with a manual, like, typing in commands and getting that returned back to you, like, interactive shell. 11:39.130 --> 11:56.690 Or, you could work with it inside of a script, and have Python just import Scapey as a whole module, and you can access all of the code, the functions, the variables, all of that functionality that Scapey offers inside of your Python scripts, inside of Python. 11:56.770 --> 12:11.670 Now, this is crazy cool, because we can work with TCP packets, UDP packets, any other network stuff, maybe CAN bus protocols or Bluetooth, there's so much more, and we could dive into some of the documentation for Scapey. 12:12.710 --> 12:17.910 I always want to point people to the real documentation, 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:29.630 I don't think you would call yourself the expert, and I'm not saying that to be mean, I'm just trying to say, the source code is the truth, right? 12:30.610 --> 12:32.690 Documentation is the real accurate stuff. 12:32.690 --> 12:39.750 That's what's really there, really built in, and the official source is what's good to go to when you need help or you're trying to learn something new. 12:39.750 --> 12:43.070 Obviously, there's a man page for the command, if you wanted to fire that up. 12:43.070 --> 12:55.390 Obviously, they've got an online web presence, you can check them out at scapey.net, and they have official documentation over at readthedocs.io, and of course, a GitHub page, 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:08.390 They have a page over there called Awesome Scapey, and that will showcase other tools, exploits, and some sample code to use, and it's really, really cool. 13:08.390 --> 13:24.090 They have some good stuff on Wi-Fi, like mapping and tracking Wi-Fi networks through 802.11, making a rowing access point, performing some man-in-the-middle attacks, some TOR, Onion Router Protocol stuff, tons and tons of great stuff, 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:37.590 Okay, now let's talk about the basic syntax of Scapey, because if we want to use it, we have to know how to. 13:38.670 --> 13:48.030 I say that Scapey is Pythonic, in that the syntax that it uses, when you're working with the module, you're working with Python objects, right? 13:48.030 --> 14:00.630 The same way most everything in Python really is, is that you're interacting and working with an object that has methods and properties and all these attributes and things you could work with that are really under the hood, right? 14:00.630 --> 14:04.090 Functions and variables, just with kind of a different, decorated name. 14:04.090 --> 14:16.470 But being object-oriented means we can do some kind of nifty things with it, maybe not all the time, I'm not trying to say OOP is the way, but it's nice to have that kind of built into the language when necessary. 14:16.530 --> 14:20.310 So you can see I'm working in like a little bit of a script here, right? 14:20.310 --> 14:37.170 I've got a shebang line set up, I'm going to work with Python 3 as my interpreter, and I'm going to use that from Scapey.all import everything, or the asterisk, the star, the wildcard, to pull in everything that that Scapey module has into my current namespace. 14:37.170 --> 14:40.270 So I can interact with it, and I can work with it through Python. 14:40.330 --> 14:51.250 So here I'm going to create an object, or a little variable, ping equals, and the IP, this big class name, right, you can see the capital letters there, that's going to return a Scapey object. 14:51.250 --> 14:55.650 And it's going to be a packet, and I can define how that packet looks. 14:55.650 --> 15:00.470 Maybe I don't want to use an IP, or maybe it's that specific header 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:14.130 And Scapey already has support for all those crazy cool protocols and layers, and you could just pull them in and work with them. 15:14.130 --> 15:20.110 Or, if you really wanted to, you could go do a little deep dive, get in the internals, and build your own. 15:20.530 --> 15:26.270 So, note inside here, I'm creating this IP object, and I'm passing in a keyword argument. 15:26.270 --> 15:30.090 I'm saying DST, or the destination, the destination IP address. 15:30.090 --> 15:40.930 I've simply set that to a string, 192.168.1.1 And I've had a little division symbol, or that forward slash, which looks weird, right? 15:40.930 --> 15:54.030 Because we're not dividing these objects, but I'm using that syntax, and that is the syntax that Scapey uses to actually add layers in or kind of build them into that packet that we're crafting. 15:54.030 --> 15:59.810 So, I'm going to say, this is simply going to be an ICMP packet, or ping packet, right? 15:59.810 --> 16:05.490 I've assigned that to that ping variable, or the object, and I'm just going to print that out on the screen. 16:05.610 --> 16:26.670 If I were to run that script, check out down below, now I have that kind of B prefix to note that this is a binary string, or I'm just including real raw bytes here, and that backslash X, the backslash X everything, all those are the bytes to this packet that I've just formulated and created in a super duper simple way, 16:26.670 --> 16:27.010 right? 16:27.010 --> 16:31.750 It literally took one line of Python code, and now I have a ping packet. 16:31.750 --> 16:41.530 And I could do this, I could send this packet, I could receive the information that comes back, maybe a little echo, a request, reply ping, that's very, very cool. 16:41.550 --> 16:49.790 All in a script, all automated and extensible, whatever way that I want, and super duper short, right? 16:49.790 --> 16:54.110 One line of that Python code, easy to read, easy to write. 16:54.470 --> 17:06.590 Obviously, Scapey is abundant, and there are more examples of this sort of thing on their website and that's really, really why I'm pointing you all towards it, because that's where the good stuff is. 17:06.590 --> 17:16.230 We're going to cover some cool stuff in the talk, but if you want to go deeper, learn more, do some more research, I'd recommend, hey, go check out that documentation. 17:16.810 --> 17:21.650 Okay, last slide on Scapey, I promise, then I'll shut up about it and we can move on. 17:21.650 --> 17:28.670 I'm not trying to sound like an evangelist here, but I am trying to show you all of the cool things that Scapey can do. 17:28.690 --> 17:37.070 Obviously, in this last slide, we have a super duper small, minuscule example of one thing that Scapey could do. 17:37.070 --> 17:53.350 What we could do with that packet, or with many other packets, is put that together into a PCAP file, write it out to a packet capture archive, or we could read in a packet capture archive or a PCAP file, read through it, loop through it, do interesting things with it, 17:53.350 --> 18:00.550 or we could sniff and listen and actually capture live packets and dissect them or forge new ones, etc. 18:01.750 --> 18:05.950 Import and exports, create graphs, reports, tables, etc., etc. 18:05.950 --> 18:11.350 And obviously, all of those specific different protocols that we would want to work with, we can. 18:11.870 --> 18:15.690 And then, maybe we could turn it into more of the offensive side. 18:15.690 --> 18:22.550 We could probe or scan or attack networks, fuzz specific aspects of a protocol, or send malformed packets. 18:22.550 --> 18:29.490 And we could do crazy tricks like, okay, art poisoning, or do some specific kinds of scans, etc., etc. 18:29.490 --> 18:42.630 The benefit behind all of this, and this is what makes it so awesome, is that it can all be automated and you can write it and you have that fine-tuned control all within Python. 18:42.670 --> 18:50.850 You have the entire arsenal of the Python language and libraries, modules, other tools that you can use 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 --> 19:01.450 Let's get into the really cool attacks that could potentially take down the Internet. 19:01.650 --> 19:03.430 So, we'll start small. 19:03.430 --> 19:08.030 We'll start with some simple things and then we'll slowly kind of zoom in onto more complex stuff. 19:08.030 --> 19:12.590 But just to kind of whet your appetite, let's start with the ping of death. 19:13.470 --> 19:14.690 Interesting name, right? 19:14.690 --> 19:25.430 So, the ping of death attack is a denial-of-service attack where the attacker will stop a machine by sending a large ping packet. 19:25.430 --> 19:28.570 So large, in fact, that the machine can't handle it. 19:28.570 --> 19:29.750 It'll choke. 19:29.790 --> 19:37.610 There's so much data in that packet that the machine doesn't know what to do with it and it'll freeze up or just fall over or crash. 19:37.670 --> 19:49.050 We talked about ping packets in the previous example or that script and source code that I showed you earlier when we were looking at that ICMP protocol or the Internet Control Message Protocol. 19:49.350 --> 19:52.610 So, typically, ping packets are very small. 19:52.610 --> 20:02.870 But IPv4 ping packets have a maximum allowable packet size of 65,535 bytes. 20:02.870 --> 20:13.430 Some systems might not be designed to actually handle packets larger than this maximum and they might be vulnerable to packets at that size and they're sensitive to it. 20:13.430 --> 20:15.870 They'll choke and they'll fall over. 20:15.890 --> 20:26.550 When this large evil packet is sent from the attacker to the victim, the packet becomes fragmented into different segments, each of which will be smaller than the maximum size limit. 20:26.910 --> 20:42.330 When the target and victim actually attempts to put these pieces all back together, eventually that total size will exceed that maximum size limit and maybe a buffer overflow occurs or something goes wrong and that machine can't handle it. 20:42.330 --> 20:44.910 It'll freeze, it'll choke, it'll crash. 20:45.750 --> 20:51.010 So, we're using this example where the ICMP echo or that ping packet could be used for this attack. 20:54.590 --> 21:04.310 It can hold more data or can have this attached information that extends beyond that maximum size could be used for this attack. 21:04.310 --> 21:08.690 That could be TCP or UDP or any IPX stuff. 21:09.110 --> 21:25.910 Admittedly, the ping of death attack is kind of old and a little outdated, but I think it works as a really cool and simple quick jumping off point or starting point for us to take a look at some of these evil, nefarious things that we could do with Python and Scapey. 21:25.910 --> 21:29.330 So, with that said, let's take a look at the source code here. 21:29.510 --> 21:33.630 You can see I'm using the send function which is part of Scapey. 21:33.630 --> 21:36.430 We say we've imported everything into our namespace. 21:36.690 --> 21:48.690 You could also send just one packet and receive the information back or send packets inside of a loop, but for just one quick shot firing the gun, we can use this send function here. 21:48.710 --> 21:51.970 We'll create a fragment as kind of we discussed earlier. 21:54.590 --> 22:00.890 It could be rebuilt and reassembled by the victim machine that could potentially cause it to crash and choke. 22:01.510 --> 22:07.430 And inside of that, we'll build this ICMP packet just as we've done before in that previous example. 22:07.430 --> 22:14.630 However, you can see there at the end we use another divider or add in another layer or some more information 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:33.610 and I've strapped to this ping packet so that I can send a ping of death that's just a little too big and maybe that machine 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:43.210 I did mention though that this ping of death attack is less common today. 22:44.310 --> 22:49.970 More so now, you'll see other kinds of attacks that are still this denial of service attack. 22:49.970 --> 22:51.410 We're being a jerk. 22:51.410 --> 22:58.590 We're overwhelming, flooding and it's bogging down the resources on that victim or target. 22:59.250 --> 23:05.350 So one of the more common ones you'll see now is perhaps an ICMP or a ping flood. 23:05.350 --> 23:08.070 And we can certainly send other kinds of floods. 23:08.070 --> 23:11.490 One of the most common ones you might see is a SYN flood. 23:12.110 --> 23:19.930 SYN flood is another denial of service or DOS attack which will make that server, 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:29.470 It'll be hosed because something will be consuming all of the available server resources. 23:29.710 --> 23:36.650 We're going to cause that by sending packets with that SYN flag set. 23:36.650 --> 23:39.030 So you know TCP packets, right? 23:39.310 --> 23:47.910 TCP being the Transmission Control Protocol which ensures there is a connection in place by using the three-way handshake, right? 23:48.290 --> 24:00.810 The client on one side of the conversation will send to the server a packet with the SYN flag set to synchronize or start the conversation and begin requesting communication. 24:00.810 --> 24:11.290 The server over on the other end of the conversation will say and respond back with a SYN ACK packet or a packet sent with those flags set. 24:11.350 --> 24:21.710 Finally, the client, knowing that the server has responded, that someone actually answered the phone, it will respond once more with an ACK flag set. 24:21.730 --> 24:25.570 On a packet or the acknowledgement, okay, someone is listening and we can talk. 24:25.570 --> 24:27.150 We can have this conversation. 24:27.910 --> 24:46.170 Interesting thing though, on step two of that process or in the middle of the three-way handshake communication, the server, while it sends that SYN ACK packet, it will wait and wait to receive that ACK packet from the client so that it can begin having this conversation. 24:47.850 --> 24:50.750 So the attack is simple. 24:50.750 --> 24:56.250 We just send a ton of SYN packets where we're just starting all these conversations. 24:56.250 --> 25:00.170 We're dialing the phone, 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:10.470 Someone, they're going to pick it up and they're going to want to talk to someone, but no one will be there. 25:10.470 --> 25:16.070 They're just not having this conversation, but they're still holding the phone and more are ringing. 25:17.010 --> 25:20.070 That will hog all the resources. 25:21.210 --> 25:32.290 That will cause that target victim to not be able to respond to other legitimate traffic 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:41.890 Because this attack brings that server to the halfway point in the three-way handshake, right? 25:41.890 --> 25:46.390 They started the communication, 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:11.850 We're performing this attack in, realistically, two lines of code that could even be shortened to one because, hey, maybe we could abstract out 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:27.010 We'll set an ID number for that packet and we'll specify the time to live. 26:27.010 --> 26:34.870 These values aren't extremely important for kind of just our discussion, but obviously that next layer certainly is. 26:34.870 --> 26:51.410 We create a TCP portion of this packet and that SPORT, or S-port is how you should read that, for our source port, that's just going to be a random, ephemeral port that Scapey will help us generate with that RANDSHORT function there. 26:51.510 --> 26:56.790 That'll return something to make it look like, okay, we're coming from a different port every time. 26:57.130 --> 27:01.890 The D-port, or the destination port, will be passed in as a list, 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:09.410 You could specify this to whatever you wanted to, maybe SSH or anything specifically. 27:09.710 --> 27:13.630 Specify a sequence number, specify an acknowledgement number. 27:13.630 --> 27:19.650 Again, for this example, those don't really matter all that much, but maybe they could in other scenarios. 27:19.650 --> 27:27.650 A window size, and the most important thing here, the flags that are set on this TCP packet. 27:27.690 --> 27:35.610 Obviously, I'm just passing in a string here with that capital S, 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:59.410 The next line below, we're going to end up using that SR loop function that Scapey makes available to us, and that is going to send and receive packets in a loop. 27:59.410 --> 28:03.910 So we will repeatedly, over and over and over again, send this packet. 28:04.890 --> 28:10.070 The keyword arguments there, that enter or the interval, we'll send those at three-tenths of a second. 28:10.070 --> 28:15.630 We'll retry every two seconds if that kind of gets dropped, and we'll have a timeout of four seconds. 28:15.710 --> 28:26.110 Again, those are a little extraneous, but the point that we're getting across right now is that we are looping a SYN packet being sent over and over and over again. 28:26.110 --> 28:31.850 We are flooding that target victim server with this SYN flood attack. 28:31.850 --> 28:39.590 In the case of the line of code there, we have an answered and unanswered information that's being stored as a return value of that SR loop. 28:39.590 --> 28:45.010 That'll just return a tuple, okay, or a list of what packets actually had a response and what didn't. 28:46.210 --> 28:55.110 The point that I'm trying to get across is that just these two lines of code are putting together this attack, and it's super-duper simple. 28:55.110 --> 28:57.390 All you've done is outlined the structure. 28:57.390 --> 29:00.930 You've orchestrated this packet, 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:15.670 You might notice, though, in this example, with this setup right here, we're sending this SYN flood attack just with our attacker machine. 29:15.890 --> 29:17.650 One machine. 29:18.130 --> 29:26.430 So, potentially, that endpoint or that target, the victim server, once it realizes, hey, I'm under attack, right? 29:26.430 --> 29:27.810 I'm in danger. 29:27.810 --> 29:34.810 If they kind of had the opportunity to look through some logs or could figure something out and determine, 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:46.990 For that reason, this kind of thing isn't often done just with one host. 29:47.310 --> 29:49.770 Just with one attacking machine. 29:49.770 --> 29:56.900 So you bring in the conversation, okay, we're performing a denial-of-service attack, a DOS attack or a DOS attack. 29:57.560 --> 30:10.600 But if we had more machines in this pool, if we were attacking with multiple hosts, we could be performing a distributed denial-of-service attack or that DDoS, D-D-O-S. 30:10.820 --> 30:16.260 That might make it a little bit harder to do, harder to track down, harder to trace. 30:16.260 --> 30:18.380 However, we could do even more. 30:18.380 --> 30:26.120 We could go one step beyond that when we say our source IP address, 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:36.620 But you can tell with Scapey, we are crafting our packets at the granular level. 30:36.620 --> 30:46.000 What's to stop us from specifying just that information, just the bytes, the real, real information that we need within that header of the packet? 30:46.080 --> 30:53.640 We could say that our source IP address comes from a different IP address, comes from a different host. 30:53.640 --> 30:58.020 We can spoof our IP address simply by passing in the keyword argument. 30:58.020 --> 31:04.720 Just as you see the example there, we specify that DST keyword argument as an IP address string. 31:04.720 --> 31:14.360 We could just as easily specify SRC or the source IP address 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:25.320 And we can use that as a segue into the next attack, DNS amplification attacks. 31:25.320 --> 31:40.540 A DNS amplification attack is a really interesting technique that abuses the regular functionality of DNS, or the domain name system, to again overwhelm, spam, and flood a target or victim machine. 31:40.540 --> 31:52.260 The way that this works is that the attacker actually sends a legitimate regular request to a DNS name server asking for as much information as they can. 31:52.260 --> 32:07.760 So their request is a regular kind of small, tiny packet just asking for information, and the domain name server will respond with as much information as possible, and that way you get a much larger packet in response. 32:07.760 --> 32:23.360 The trick here is that with this DNS amplification attack, the attacker sets their IP address, the source, back to the actual victim or the target server 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:30.660 We're defining, again, another object or variable to keep track of our packet. 32:30.660 --> 32:41.880 We're defining an IP header, but interestingly enough, we supply that SRC, keyword value, or the source IP address of the packet that we're going to be formulating. 32:42.120 --> 32:44.820 Note, this will act as our victim. 32:44.820 --> 32:51.640 This is the target machine that will have the domain name, and attack that large request. 32:51.640 --> 32:59.400 You can see, again, our division symbol or the forward slash to add new layers, and we're adding a UDP packet portion, right? 32:59.400 --> 33:11.700 We'll set the D port or the destination port to 53, the default port for the domain name system or DNS servers, and what we're going to query from this DNS is anything we'd particularly like. 33:11.700 --> 33:16.580 Here, I'll just ask for anything regarding google.com or that domain. 33:16.580 --> 33:24.260 You could, of course, ask for any type of resource record you'd like, an A record, a text record, a CNAME record. 33:24.480 --> 33:34.300 Generally, with this attack, you could expect to see the attacker request for any, as in return all of the resource records you could give me. 33:34.300 --> 33:43.820 We'll have that packet formulated, stored, and encapsulated in that DNS AMP object and variable, 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:54.120 It will give all the information it can, but send it to that source IP address, not our actual attacker. 33:54.120 --> 33:59.820 That will flood and overwhelm, choke, that target victim server. 34:00.140 --> 34:05.400 Obviously, you'd want to have more than one attack or one attacking machine doing this. 34:05.400 --> 34:12.600 You could perform this distributed denial of service, that DDoS, or send this request multiple times. 34:12.600 --> 34:15.760 But I think this attack is really cool and really interesting. 34:15.760 --> 34:27.840 But if you put it in kind of layman's term or normal human explanation, say you are at the drive-thru ordering some fast food to go, or whatever the case may be. 34:27.840 --> 34:38.700 Let's say you ask the person or the teller that's chatting with you and taking your order, I want one burger, or I want one drink, or whatever, whatever, whatever. 34:39.340 --> 34:43.660 Typically, that job of the teller 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:52.160 You as the attacker, you say, I want everything on the menu. 34:52.160 --> 35:00.940 And then, before they can read your order back to you, you drive away and let that next person go ahead and actually hear all that information. 35:01.080 --> 35:13.100 So, while you just ask for a small, tiny thing and a simple, hey, give me everything you've got, the next person or your target or your victim is going to be read and enumerated and receive all of the information. 35:13.660 --> 35:27.420 So, maybe, I don't know, a one scale for your packet could respond to a 10 in the response and what that teller will read out to that other person or that individual. 35:27.440 --> 35:28.740 Kind of cool. 35:28.860 --> 35:35.840 And obviously, another added benefit to this is that the attacker is performing this attack indirectly. 35:35.840 --> 35:46.080 They make this request out to an open and accessible DNS resolver, and it will respond and just send that information out to the actual target or victim themselves. 35:46.080 --> 35:51.500 The attacker doesn't really leave any fingerprints 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 --> 36:03.880 You can see that here again with that syntax, but as always, Scapey is making this 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:21.080 So BGP is the Border Gateway Protocol, and that is the standard routing protocol of the internet today. 36:21.660 --> 36:32.880 That means that it's actually telling your computers where these packets are going to go when you're working on the internet or at a large scale, the wide area network, right? 36:32.880 --> 36:45.020 So routers using this BGP or the Border Gateway Protocol store a routing table with the best routes in between autonomous systems or AS as an acronym. 36:45.020 --> 36:58.240 These autonomous systems are large groups of networks or just a giant large network itself kind of owned and managed by a specific organization 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:03.660 It's the freeway. 37:03.660 --> 37:04.320 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:11.660 It's what makes that large scale growth 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:30.040 What if someone were to, without anyone else knowing, change or modify the road signs or the exits or the different locations on the map? 37:30.120 --> 37:37.800 Obviously, this routing table that these routers are using with BGP has to be correct and accurate. 37:37.800 --> 37:44.780 Otherwise, traffic, things might be directed and routed to the wrong and incorrect place. 37:44.780 --> 38:04.480 On top of that, BGP is working off of TCP, that transmission control protocol that relies on a persistent long-term connection that could potentially offer an attacker a long window or a decent amount of time to be able to tweak things 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:14.400 With that said, obviously, there is a lot of room for potential abuse and danger. 38:14.400 --> 38:32.560 There could be BGP hijacking, another classic denial of service, or some kind of interesting ones where you can do blind BGP attacks to disrupt sessions, taking advantage of that TCP three-way handshake or the communications and conversation that has to happen within that protocol, 38:32.560 --> 38:45.940 or even more dangerously, inject routing misconfigurations and change that highway sign, change that exit so that traffic is going to or through a bad place. 38:46.720 --> 38:54.980 Okay, so let's zoom in on one of the potential attacks we could use trying to do some blind disruption with these BGP routers. 38:54.980 --> 39:07.260 What we're going to do is actually abuse and take advantage of the regular TCP communication and settings and functionality that that protocol would require to keep this BGP session alive. 39:07.260 --> 39:14.800 All we were simply going to do is send a packet with that RST or reset flag set. 39:14.820 --> 39:28.580 Granted, the situation kind of means our attacking host has to be in the middle of a conversation or listening or eavesdropping in on the conversation between two of the routers using BGP. 39:28.680 --> 39:31.640 You can kind of note that here in the comments of the code. 39:31.640 --> 39:44.500 I'm specifying a D port or destination port as a value that would ideally match the expected destination port that's being used in an active BGP session or conversation between these two routers. 39:44.500 --> 39:52.060 The sequence number and the acknowledgement number also have to match what that victim would be expecting. 39:52.360 --> 39:56.560 This is where we get into the conversation 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:02.680 Potentially you could just hammer this until you get a hit. 40:02.680 --> 40:09.040 But at the end of the day, what we're doing is we're sending packets in between these two routers. 40:09.040 --> 40:20.140 So I have a source set to one router that is going to act as the peer or one in this conversation and communication and the destination as our victim router. 40:20.140 --> 40:27.340 We're sending in that RST flag or the reset signal and notification part of this communication. 40:27.340 --> 40:29.160 You can note that in the flags there. 40:29.160 --> 40:32.940 Again, R to represent that RST and A for ACK. 40:32.940 --> 40:36.880 And of course passing in the appropriate sequence number and acknowledgement number. 40:36.880 --> 40:47.040 We send this packet and that target or victim will suddenly believe, okay, this BGP session was just shut down. 40:47.080 --> 40:50.340 They just hung up the phone and we're not going to talk anymore. 40:51.080 --> 40:55.720 Obviously, there's another router at play, the peer router. 40:55.720 --> 41:03.640 And this BGP protocol, the way that it's working is that it's sending any type of four potential messages. 41:03.640 --> 41:11.900 BGP could work with an open message or a notification message or a keep alive message or an update message. 41:11.900 --> 41:14.960 We'll tune into that update message soon. 41:14.960 --> 41:22.040 But what's going to happen here is that that peer router will notice it's still trying to work and have this conversation. 41:22.040 --> 41:27.560 And yet the other router, our victim, is down with that RST flag. 41:27.560 --> 41:28.950 It's no longer talking. 41:29.440 --> 41:38.800 Because of BGP, there might be some keep alive messages in the conversation and that other victim router will restore. 41:38.800 --> 41:39.880 It will recover. 41:39.880 --> 41:42.640 This might take a minute, but it'll happen. 41:42.640 --> 41:50.880 So we could momentarily disrupt the communication, but maybe that will again be revived. 41:50.880 --> 41:53.580 If you wanted to, I don't know. 41:53.580 --> 41:56.280 Again, we're working in blind territory. 41:56.280 --> 42:01.780 You could potentially be hammering this over and over and over again and trying to keep shutting it down. 42:01.940 --> 42:06.180 Maybe that could be a worthwhile attack with BGP. 42:08.160 --> 42:26.280 Let's take a look at another example where we go a little bit more in depth and this gets a little bit more complicated because we're going to try and do a blind inject or supplying fake, malicious, bad routing information or hijacking the routes that the BGP protocol will use. 42:26.280 --> 42:54.500 So again, we're working in the scenario of an attacker machine within the conversation of two routers that are working with this BGP protocol and in the source code with Scapey, you can see I've ran this load contrib function to load a contributed package or a portion of Scapey to actually access more of the BGP functions and variables and work that we could do to actually modify BGP packets within our code. 42:54.540 --> 43:10.180 Again, my destination port sequence number and acknowledgement number might need to be tweaked or modified to match this conversation and they potentially could be perhaps fuzzed, but what we'll be doing is we'll be defining a whole new BGP packet. 43:10.180 --> 43:20.500 We'll set up an origin, we'll set up a note for our AS or autonomous system and specify the next individual or that router IP address that we'll be sending this to 43:23.900 --> 43:28.960 the most interesting thing here is that path update variable down at the bottom. 43:28.960 --> 43:39.040 We're going to be specifying a new malicious route 5.5.5.0 slash 24 which you can kind of decipher from that syntax there. 43:39.040 --> 43:43.220 Then we'll go ahead and send this packet with that path update. 43:43.500 --> 43:49.500 Now this is interesting because it could realistically result in one of three different things. 43:49.500 --> 43:56.820 The first case, if all the stars aligned, we have the source number and acknowledgement numbers right in the session. 43:56.820 --> 44:08.740 And if we were within the correct window of that conversation, our malicious route could be inserted and injected into the routing table and traffic could potentially flow through that. 44:08.740 --> 44:17.920 We may have very well changed the highway signs and we're directing packets and communication now going to or through a different place. 44:18.400 --> 44:24.720 In the other case, I guess I'll call this case number three, we fail. 44:24.720 --> 44:26.020 It doesn't work. 44:26.040 --> 44:33.120 Maybe our timing was off, maybe the variables at play just weren't matching in the conversation and that didn't take. 44:33.200 --> 44:38.740 Kind of a bummer, but we know, okay, that might be natural with our blind attack here. 44:38.840 --> 44:50.620 And what I'll call case number two or kind of the other scenario we can keep in mind is we're showcasing conversation between two BGP routers right now. 44:53.900 --> 45:02.540 We have a BGP router in place that is not part of this conversation or not pertinent to this attack happening between our source and destination. 45:02.540 --> 45:06.100 You can mentally map that to a client and server, I suppose. 45:06.100 --> 45:12.100 Maybe an external or third party router still present, working with all these routes. 45:12.340 --> 45:23.700 If our victim, if our target upon success of getting this injected new malicious routing information, that will try and propagate it out. 45:23.900 --> 45:30.280 Maybe that other third party router, it will receive that new information to take in this route. 45:30.280 --> 45:35.400 It could potentially, again, just not being in sync within the conversation. 45:35.400 --> 45:43.640 The receiving number might not match the kind of victim and target sending number in the sequence and conversation. 45:43.640 --> 45:52.920 And that third party router will identify the mismatch and it will try and acknowledge and send responses like, hey, I can't compute this. 45:53.900 --> 45:57.120 I might send an acknowledge or a notification this is wrong. 45:57.120 --> 46:04.360 That other router is still trying to send over this update, but it's still receiving and now it's going to send its own ACK and acknowledgement. 46:04.360 --> 46:07.480 And those two will get in a little bit of an ACK war. 46:07.480 --> 46:10.060 They'll be repeatedly sending acknowledgements to one another. 46:10.060 --> 46:16.600 And this will happen at least until a timeout occurs and the session will be disrupted. 46:16.680 --> 46:18.500 It'll just shut down and stop. 46:23.900 --> 46:28.940 And eventually a keep alive will be in the midst of the conversation and it will restore. 46:29.320 --> 46:36.920 That might not be a minute in length as opposed to our previous example with that RST or reset flag being set. 46:36.920 --> 46:44.360 But this could take maybe four or five minutes for that session to come back to life after they've realized this mismatch. 46:44.360 --> 46:54.980 So maybe that could be a bit more of a dangerous or maybe worthwhile depending on your avenue or your outlook here for this attack. 46:55.760 --> 46:57.900 So we've talked about a few attacks. 46:57.900 --> 47:04.300 I hope some of those were kind of cool and kind of interesting in the conversation to take down the internet. 47:04.300 --> 47:11.240 I wanted to showcase some IRL cases or some real stuff where these sort of things actually happened. 47:11.240 --> 47:17.760 Maybe not an attack but at least a mishap that showcases some of the weakness between these protocols. 47:17.760 --> 47:21.880 Especially BGP 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:33.720 It seemed like all of the internet was being funneled through some small shop in like Pennsylvania or something. 47:33.720 --> 47:41.560 This is over on CloudFlare's blog if you're interested and you might have seen I've already referenced some CloudFlare stuff as we've gone through the talk. 47:41.560 --> 47:52.760 This dives into a little bit more of the BGP optimizer that was in use and that would kind of split or segment different routes or giant networks into smaller pieces. 47:52.760 --> 48:04.620 And it seemed that there was a little bit of a leak from Verizon where some of the BGP output was being pushed and propagated and updated again through to DQE and CloudFlare, etc. 48:04.620 --> 48:10.100 And that would take down a decent amount of stuff even between Amazon, Linode, and more. 48:10.100 --> 48:17.300 It was crazy to see that this was worldwide and CloudFlare I think at the point lost about 15% of traffic. 48:17.300 --> 48:39.780 And I think it goes to show just how much trust is really being placed into that BGP or Border Gateway protocol because absolutely these routing tables need to be accurate to ensure that okay, all of the traffic and communications and conversation flowing through these packets is going to the right place so that that infrastructure can handle that load and that amount of traffic. 48:39.780 --> 48:52.120 If more than a few fragments and portions of the internet are all funneled through one specific spot that could be potentially bad and take down the internet. 48:52.820 --> 48:58.540 This other case is even more recent over on July 17th of this year 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:14.880 Once again, BGP having an incorrect route that was being propagated and bleeding out and doing damage potentially taking down the internet. 49:15.120 --> 49:23.100 I think this blog post is really cool because it showcases a little bit more of the router syntax and talks about the timeline of kind of where things went wrong. 49:23.300 --> 49:31.180 CloudFlare actually does put a disclaimer and hey, we just want to enforce this is not the result of an attack. 49:31.180 --> 49:48.500 And I want to preface that as well because sure, we've just spent a lot of this talk discussing some of the potential attacks and things we might be doing especially muddling with BGP but this was just again the case of something potentially going wrong with a misconfiguration in those routing tables. 49:48.500 --> 49:55.640 So again, just the reliance on how that protocol works and how much faith we end up putting in it. 49:55.740 --> 50:04.220 Okay, let's briefly discuss some defense and mitigations at least in regard to some of the attacks and some of the stuff that we've covered. 50:04.220 --> 50:10.100 I will breeze through this a little bit or at least kind of go surface level because I'm cognizant we are low on time. 50:10.100 --> 50:14.380 But how could we try to prevent some of this stuff? 50:14.380 --> 50:19.660 We talked about the ping of death and I mentioned that is generally protected today. 50:19.660 --> 50:27.520 Kind of a lot of modern systems and technologies will know how to behave and handle that large ping and packet size. 50:28.000 --> 50:31.360 That could really potentially be done just adding a check. 50:31.360 --> 50:35.300 Make sure, hey, are we not exceeding that maximum packet size? 50:35.960 --> 50:41.860 Another option with that is actually kind of allocating a memory buffer to be able to handle that packet size. 50:41.860 --> 50:47.420 I feel like that, I don't know, might not have the real intended effect that we want. 50:47.420 --> 50:53.840 I think the protections that we have to just verify and check, hey, are we dealing with an overblown, oversized packet? 50:53.840 --> 50:55.520 That makes the most sense. 50:56.240 --> 51:08.600 The SYN flood and other flooding attacks, especially with SYN flood, you could be using some server SYN cookies where the server will actually kind of specify a nice token or something specific to that communication. 51:08.600 --> 51:13.020 And that would obviously need to be returned and responded back with a response. 51:13.020 --> 51:19.580 Or maybe you could recycle the older previous half-open TCP connections that were started. 51:19.580 --> 51:31.000 If you realize, okay, this machine is getting overblown with open or half-open connections, we'll roll back to one of the ones that we've got started and just work with that as necessary. 51:31.000 --> 51:39.900 For DNS amplification attacks, this one is almost, it seems just natural, right? 51:40.300 --> 51:53.420 If the flaw here is that we can just abuse and reach out to the natural behavior of DNS or the domain name systems and those open name servers and resolving servers, limit that number. 51:53.480 --> 52:00.300 Maybe we could scope and turn down the stuff that is accessible within your network or a network or what is applicable. 52:00.300 --> 52:04.840 Another technique is actually verifying, okay, who is requesting this information? 52:04.840 --> 52:11.860 If you check that source IP address, does it come from someone that really should be able to access that and reach that? 52:11.860 --> 52:15.120 We have the conversation of DNSSEC, right? 52:15.120 --> 52:23.460 But the gimmick with that DNS amplification attack is that it's just the natural functionality of DNS. 52:23.460 --> 52:32.340 If someone is asking for all of the resource records you can get by simply requesting any, it's going to give that information back out to you. 52:32.340 --> 52:43.600 Just that example that we discussed at the drive-through, you say, hey, I want to know everything on the menu, they have to give you that information because that's 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:51.860 BGP abuse protection is kind of tough, right? 52:51.860 --> 52:56.440 Just because, again, this is how it has to work. 52:56.460 --> 53:07.820 Knowing that we are assigning the routes and locations and maps for ways to get to places on the internet, that has to be just secure. 53:07.820 --> 53:17.880 Unless anyone is monitoring that and knowing when those changes are being put in place, it's hard to lock that down. 53:17.880 --> 53:21.180 And BGP itself was not designed with that security in mind. 53:21.180 --> 53:24.280 It's working off of TCP as it needs to. 53:24.280 --> 53:31.080 Maybe there'll be more developments with BGPSEC, which I believe there are some conversations and research kind of being started in that direction. 53:31.080 --> 53:42.300 But anyone that declares changes to routes should be kind of a valid, authoritative, and trusted source, not just a thing that could happen. 53:42.300 --> 53:52.960 And when that change does happen, that needs to be monitored and maybe notifications and set aware for individuals to track that. 53:52.960 --> 54:01.440 If you are struck by random to whatever BGP attack, you will know it, right? 54:01.440 --> 54:08.760 Obviously, okay, signs of increased latency, your network's moving slow, degraded network performance, and just misdirected traffic. 54:08.800 --> 54:13.400 That should be a big indicator, 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:23.540 All these things we can take into consideration, right? 54:23.540 --> 54:47.460 Defense and mitigations, things that we can discuss and talk about and know, just so when we're looking at these attacks and we're kind of taking a look at all these jerk, I don't know, techniques to disrupt, abuse, really annoying, obnoxious denial of service attacks and stuff that is prevalent on the internet. 54:47.460 --> 54:52.700 Maybe we can be a little bit more knowledge about it and we won't take down the internet. 54:54.080 --> 55:00.580 Okay, this is just a data dump of sources and references that I had kind of used to help put this together. 55:00.740 --> 55:05.320 You could hopefully be able to sort through this by kind of the topic or discussion that I've showcased. 55:05.320 --> 55:13.700 I didn't include too much stuff in here for Python and Scapey because the documentation and the websites for that you can certainly very easily find online. 55:13.700 --> 55:18.420 But some of the specific things, some of the research papers, there's a lot of really cool stuff in here. 55:19.140 --> 55:19.700 Cloudflare, of 55:27.220 --> 55:34.760 course, has really cool open source tools and utilities that showcase this or even how to defend against it with IP tables or other things that are applicable. 55:34.760 --> 55:36.600 There are some really, really cool stuff in here. 55:36.600 --> 55:44.580 The Naval Postgraduate School had a research paper out I think back in 2017 that discussed these BGP blind attacks. 55:44.580 --> 55:49.820 There's some University of California stuff out there and there's even a black hat presentation that discusses this 55:57.220 --> 55:59.220 and more worthwhile stuff over there. 55:59.220 --> 56:04.160 And if you're interested, I do, do recommend you do some of that research. 56:04.160 --> 56:06.140 Check out some of these references and resources. 56:06.140 --> 56:08.160 I hope they are helpful to you. 56:09.200 --> 56:10.880 Okay, I'm going to wrap it up. 56:10.900 --> 56:15.500 If you have any questions or comments or feedback, I'd love to hear from you. 56:15.700 --> 56:18.320 Obviously, I'm putting this out here for you. 56:18.600 --> 56:23.300 I'm happy to be part of the community and jamming and meeting everyone and seeing everyone here at DEF CON. 56:27.220 --> 56:30.640 If you want to hang out, just want to discuss, please do reach out. 56:30.640 --> 56:33.040 You've got my email address, my silly YouTube channel. 56:33.080 --> 56:36.080 If you want to see any of my code, that's on GitHub and of course Twitter. 56:36.080 --> 56:40.520 And if you want to do some real-time instant messaging, that's my Discord server there. 56:40.880 --> 56:41.540 Okay. 56:41.880 --> 56:42.900 Holy cow. 56:42.900 --> 56:44.840 Thank you so, so much, everybody. 56:44.840 --> 56:50.280 I cannot say it enough as I did the beginning of this talk, as I did hopefully through it a little bit. 56:50.280 --> 56:51.160 Thank you. 56:51.160 --> 56:51.560 Thank you. 56:51.560 --> 56:52.180 Thank you. 56:52.180 --> 56:53.200 This has been a blast . 56:53.200 --> 56:55.200 I hope you enjoy the talk and presentation. 56:55.200 --> 56:59.740 I hope you enjoy DEF CON Safe Mode and please stay safe and enjoy yourself . 56:59.740 --> 57:00.920 Take care, everybody. 57:00.920 --> 57:01.740 Thank you.