1 00:00:00,000 --> 00:00:05,040 We wish everyone a safe flight home and travels. 2 00:00:05,600 --> 00:00:06,740 Ducks. 3 00:00:08,140 --> 00:00:16,800 But, no seriously, we hope that we will be all together soon, next, hopefully next year. 4 00:00:18,560 --> 00: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. 5 00:00:28,500 --> 00:00:33,040 Our talk is coming up next. 6 00:00:33,260 --> 00:00:38,940 This next speaker here is a legend and needs no introduction. 7 00:00:39,180 --> 00:00:42,320 He is a friend and a world-class trainer. 8 00:00:42,320 --> 00:00:49,020 It is my pleasure to introduce to you John Hammond with Take Down the Internet with Scappy. 9 00:00:49,020 --> 00:00:50,460 Take it away, John. 10 00:00:59,430 --> 00:01:01,370 Alrighty, hello everyone. 11 00:01:01,470 --> 00:01:02,410 Welcome. 12 00:01:02,410 --> 00:01:03,610 Thank you for tuning in. 13 00:01:03,610 --> 00:01:04,810 I appreciate you being here. 14 00:01:04,810 --> 00:01:09,890 This is a talk and presentation titled Take Down the Internet with Scappy. 15 00:01:09,890 --> 00: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. 16 00:01:15,570 --> 00:01:20,970 So let's dive into the presentation, but before we do, I've got to say this. 17 00:01:21,070 --> 00: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. 18 00:01:27,110 --> 00:01:28,230 Thank you. 19 00:01:28,230 --> 00:01:29,850 Thank you for being here. 20 00:01:29,850 --> 00: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. 21 00:01:38,970 --> 00:01:40,510 Thank you for tuning into this talk. 22 00:01:40,510 --> 00:01:42,170 Thank you for being a part of all this. 23 00:01:42,170 --> 00: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. 24 00:01:48,150 --> 00:01:48,990 Just thank you. 25 00:01:48,990 --> 00:01:50,610 Thanks for being here. 26 00:01:50,610 --> 00:01:52,030 I really, really appreciate it. 27 00:01:52,030 --> 00:01:56,350 Okay, so the classic disclaimer, right? 28 00:01:56,430 --> 00:01:59,250 The start of every talk, it's just how it's got to start. 29 00:01:59,850 --> 00:02:02,850 These are my words, not my employer's. 30 00:02:02,850 --> 00:02:03,850 I don't represent them. 31 00:02:03,850 --> 00:02:05,410 I'm not speaking for them, etc. 32 00:02:05,410 --> 00:02:09,650 This is stuff that I wanted to bring to you, me personally. 33 00:02:10,370 --> 00:02:15,890 Other disclaimer, don't or do try this at home, right? 34 00:02:15,890 --> 00:02:21,670 Anything that we talk about, anything that I showcase here, obviously it's a talk titled, Take Down the Internet. 35 00:02:21,670 --> 00:02:29,990 Don't actually do that, or maybe do it at maybe your own small-scale lab environment, etc. 36 00:02:29,990 --> 00:02:35,510 You can tinker with it and explore with it, but don't actually take down the internet, right? 37 00:02:36,210 --> 00:02:37,090 Cool. 38 00:02:37,410 --> 00:02:40,070 Next, your mileage may vary. 39 00:02:40,350 --> 00:02:43,610 I bring this up with everything that I kind of try and showcase. 40 00:02:43,610 --> 00:02:44,670 Look, I'm talking about it. 41 00:02:44,670 --> 00:02:45,670 I'm showing it to you. 42 00:02:45,670 --> 00:02:47,090 Maybe you'll have different results. 43 00:02:47,090 --> 00:02:51,610 Maybe something will work differently or strangely in the way that you do it, if you do this sort of thing. 44 00:02:51,670 --> 00: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. 45 00:03:04,930 --> 00:03:06,270 Okay, last bit. 46 00:03:06,550 --> 00:03:08,330 We're the good guys here, right? 47 00:03:08,330 --> 00:03:09,550 We talk about security. 48 00:03:09,550 --> 00:03:10,890 We talk about cybersecurity. 49 00:03:11,010 --> 00:03:14,270 We break things for the sake of making them better. 50 00:03:14,330 --> 00:03:16,550 We hack for good. 51 00:03:16,550 --> 00:03:17,930 And I want you to do the same. 52 00:03:17,930 --> 00: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. 53 00:03:24,430 --> 00:03:29,590 I want to reiterate to you and kind of enforce it, hey, hack for good. 54 00:03:31,830 --> 00:03:34,810 Okay, obligatory introduction, right? 55 00:03:34,830 --> 00:03:37,090 Who is this guy talking at you? 56 00:03:37,090 --> 00:03:39,370 Hello, my name is John Hammond. 57 00:03:39,770 --> 00:03:44,050 I'll try and run through this quickly because I know no one cares, not even me. 58 00:03:44,050 --> 00:03:49,430 I used to just do some stuff with the Department of Defense Cyber Crime Center and their Cyber Training Academy. 59 00:03:49,670 --> 00:03:54,930 And I also work with the Defense Threat Reduction Agency as kind of a red team cyber operator. 60 00:03:54,930 --> 00:03:58,650 Right now, I'm working as a senior security researcher over at Huntress Labs. 61 00:03:58,650 --> 00:04:00,350 Again, not speaking for them. 62 00:04:00,350 --> 00:04:02,150 These are my words, not theirs. 63 00:04:02,150 --> 00:04:06,190 And in my free time, I like to play a little bit of capture the flag. 64 00:04:06,190 --> 00: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. 65 00:04:17,470 --> 00:04:21,210 On that same coin, I do produce some cheesy YouTube videos. 66 00:04:21,250 --> 00:04:27,630 I publish and showcase some capture the flag write-ups or programming tutorials, video guides, stuff like that. 67 00:04:27,630 --> 00:04:30,670 But that's all nerdy stuff that you don't really have to care about. 68 00:04:30,670 --> 00:04:34,210 Let's talk about what we're going to talk about. 69 00:04:34,270 --> 00:04:35,530 Kind of meta, right? 70 00:04:35,530 --> 00:04:39,410 So here's the agenda, the roadmap, the outline for our discussion. 71 00:04:39,510 --> 00:04:41,510 First, we'll lay the groundwork. 72 00:04:41,510 --> 00: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. 73 00:04:45,770 --> 00:04:49,010 I'm going to be talking a little bit about Python, right? 74 00:04:49,050 --> 00: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. 75 00:04:58,910 --> 00: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, 76 00:05:14,690 --> 00: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. 77 00:05:20,170 --> 00:05:23,230 We're going to do that with Scapey inside of Python. 78 00:05:23,230 --> 00:05:27,750 So we'll talk about how to install it, some documentation, syntax and use cases, etc. 79 00:05:27,950 --> 00:05:31,510 Then we'll get into the real meat of the conversation. 80 00:05:31,510 --> 00: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. 81 00:05:41,710 --> 00:05:46,950 I do want to showcase a couple of IRL, or in real life cases, right? 82 00:05:46,950 --> 00:05:51,590 Stuff that we've really seen out in the real world that is real. 83 00:05:51,890 --> 00: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. 84 00:06:01,290 --> 00: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. 85 00:06:12,350 --> 00: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. 86 00:06:17,850 --> 00:06:21,790 And we'll have the boilerplate template slides, how you can contact me. 87 00:06:21,790 --> 00:06:24,690 And of course, I will thank you again and again. 88 00:06:24,690 --> 00:06:27,150 I'm really, really appreciative that you're here. 89 00:06:27,810 --> 00:06:28,990 All right, let's get into it. 90 00:06:29,130 --> 00:06:32,190 To get things rolling, let's lay the foundation. 91 00:06:32,250 --> 00:06:35,130 We're going to be talking about packets, right? 92 00:06:35,250 --> 00:06:37,070 We're here in the packet hacking village. 93 00:06:37,570 --> 00:06:39,350 We're talking about network-oriented stuff. 94 00:06:39,350 --> 00:06:44,130 So naturally, we're going to be talking about packets, using Scapey, using Python. 95 00:06:44,130 --> 00:06:45,650 And we'll dive into that more. 96 00:06:45,650 --> 00: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. 97 00:06:56,930 --> 00:07:03,510 It's about obnoxious, annoying, adversarial, and disruptive attacks. 98 00:07:03,510 --> 00: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. 99 00:07:15,470 --> 00:07:17,990 We're trying to recklessly break stuff. 100 00:07:17,990 --> 00:07:23,930 I want to showcase some of this to you, because really I want to show you just how easy it is. 101 00:07:23,930 --> 00:07:31,850 And how Python, the same scripting language that's about on every Unix system, can do this stuff. 102 00:07:31,850 --> 00:07:37,450 And how you could do it, if you really wanted to, but you shouldn't, you don't have to, right? 103 00:07:37,450 --> 00:07:44,030 Take down the internet, obnoxious, annoying, adversarial, and disruptive attacks. 104 00:07:44,630 --> 00:07:45,970 That's the background. 105 00:07:47,810 --> 00:07:50,070 All right, now let's talk a little bit about Python. 106 00:07:50,070 --> 00:07:53,910 I'm going to be using Python as the vessel for this talk, right? 107 00:07:53,910 --> 00: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. 108 00:08:01,850 --> 00:08:05,250 So, I want to lay the foundation again with Python. 109 00:08:05,390 --> 00:08:09,230 Python is a wonderful hacker's language. 110 00:08:09,230 --> 00: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. 111 00:08:16,390 --> 00: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. 112 00:08:24,630 --> 00: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. 113 00:08:36,430 --> 00:08:38,350 So, there's some conversations, right? 114 00:08:38,350 --> 00: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. 115 00:08:46,790 --> 00:08:49,230 It's not on the table anymore. 116 00:08:49,310 --> 00:08:55,470 Python 2 reached end of life at the start of this year, and now Python 3 is the officially supported version. 117 00:08:55,470 --> 00: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. 118 00:09:02,930 --> 00:09:05,770 And of course, Python is part of Linux. 119 00:09:05,770 --> 00:09:10,790 It's typically shipped, and natively built into a lot of common Linux distributions. 120 00:09:11,070 --> 00:09:13,670 And honestly, you should be using Linux. 121 00:09:13,670 --> 00:09:15,270 I don't know why you wouldn't be. 122 00:09:15,270 --> 00: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. 123 00:09:27,770 --> 00: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, 124 00:09:41,890 --> 00:09:46,890 go fix that up, and hop over to Python 3, now as the officially supported version. 125 00:09:46,990 --> 00: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, 126 00:10:01,610 --> 00:10:07,730 just as an automated tool, not manually working through the interpreter, or the interactive shell there. 127 00:10:07,730 --> 00: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. 128 00:10:18,010 --> 00: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. 129 00:10:26,170 --> 00:10:30,970 Scapey is incredible, fantastic, phenomenal. 130 00:10:30,970 --> 00: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. 131 00:10:42,330 --> 00: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, 132 00:11:02,410 --> 00:11:04,150 and that's super-duper cool. 133 00:11:04,150 --> 00: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. 134 00:11:21,410 --> 00:11:27,830 Now, you can run Scapey in one of two ways, very, very similar to what we talked about in Python, right? 135 00:11:27,830 --> 00: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. 136 00:11:39,130 --> 00: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. 137 00:11:56,770 --> 00: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. 138 00:12:12,710 --> 00:12:17,910 I always want to point people to the real documentation, because that's where the real stuff is, right? 139 00:12:18,190 --> 00:12:20,370 I'm not going to be the expert, sorry. 140 00:12:20,430 --> 00: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? 141 00:12:30,610 --> 00:12:32,690 Documentation is the real accurate stuff. 142 00:12:32,690 --> 00: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. 143 00:12:39,750 --> 00:12:43,070 Obviously, there's a man page for the command, if you wanted to fire that up. 144 00:12:43,070 --> 00: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. 145 00:12:55,390 --> 00:12:58,790 It's open source, it's awesome, it's all Python, good stuff. 146 00:12:58,790 --> 00:13:00,610 The website is actually fantastic. 147 00:13:00,610 --> 00: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. 148 00:13:08,390 --> 00: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, 149 00:13:24,090 --> 00:13:27,370 or stuff from CRAC, the attack against WPA2. 150 00:13:27,370 --> 00:13:30,310 Super duper cool, really recommend you go check that out. 151 00:13:31,750 --> 00: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. 152 00:13:38,670 --> 00: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? 153 00:13:48,030 --> 00: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? 154 00:14:00,630 --> 00:14:04,090 Functions and variables, just with kind of a different, decorated name. 155 00:14:04,090 --> 00: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. 156 00:14:16,530 --> 00:14:20,310 So you can see I'm working in like a little bit of a script here, right? 157 00:14:20,310 --> 00: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. 158 00:14:37,170 --> 00:14:40,270 So I can interact with it, and I can work with it through Python. 159 00:14:40,330 --> 00: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. 160 00:14:51,250 --> 00:14:55,650 And it's going to be a packet, and I can define how that packet looks. 161 00:14:55,650 --> 00:15:00,470 Maybe I don't want to use an IP, or maybe it's that specific header for that protocol. 162 00:15:00,470 --> 00:15:01,910 I could zoom in on other things 163 00:15:05,130 --> 00:15:06,530 other than Scapey or anything else. 164 00:15:06,530 --> 00: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. 165 00:15:14,130 --> 00: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. 166 00:15:20,530 --> 00:15:26,270 So, note inside here, I'm creating this IP object, and I'm passing in a keyword argument. 167 00:15:26,270 --> 00:15:30,090 I'm saying DST, or the destination, the destination IP address. 168 00:15:30,090 --> 00: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? 169 00:15:40,930 --> 00: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. 170 00:15:54,030 --> 00:15:59,810 So, I'm going to say, this is simply going to be an ICMP packet, or ping packet, right? 171 00:15:59,810 --> 00: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. 172 00:16:05,610 --> 00: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, 173 00:16:26,670 --> 00:16:27,010 right? 174 00:16:27,010 --> 00:16:31,750 It literally took one line of Python code, and now I have a ping packet. 175 00:16:31,750 --> 00: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. 176 00:16:41,550 --> 00:16:49,790 All in a script, all automated and extensible, whatever way that I want, and super duper short, right? 177 00:16:49,790 --> 00:16:54,110 One line of that Python code, easy to read, easy to write. 178 00:16:54,470 --> 00: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. 179 00:17:06,590 --> 00: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. 180 00:17:16,810 --> 00:17:21,650 Okay, last slide on Scapey, I promise, then I'll shut up about it and we can move on. 181 00:17:21,650 --> 00: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. 182 00:17:28,690 --> 00:17:37,070 Obviously, in this last slide, we have a super duper small, minuscule example of one thing that Scapey could do. 183 00:17:37,070 --> 00: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, 184 00:17:53,350 --> 00:18:00,550 or we could sniff and listen and actually capture live packets and dissect them or forge new ones, etc. 185 00:18:01,750 --> 00:18:05,950 Import and exports, create graphs, reports, tables, etc., etc. 186 00:18:05,950 --> 00:18:11,350 And obviously, all of those specific different protocols that we would want to work with, we can. 187 00:18:11,870 --> 00:18:15,690 And then, maybe we could turn it into more of the offensive side. 188 00:18:15,690 --> 00:18:22,550 We could probe or scan or attack networks, fuzz specific aspects of a protocol, or send malformed packets. 189 00:18:22,550 --> 00:18:29,490 And we could do crazy tricks like, okay, art poisoning, or do some specific kinds of scans, etc., etc. 190 00:18:29,490 --> 00: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. 191 00:18:42,670 --> 00: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. 192 00:18:50,850 --> 00:18:52,870 So, that's super-duper cool. 193 00:18:54,070 --> 00:18:56,090 Now, let's get into the good stuff. 194 00:18:56,090 --> 00:19:01,450 Let's get into the really cool attacks that could potentially take down the Internet. 195 00:19:01,650 --> 00:19:03,430 So, we'll start small. 196 00:19:03,430 --> 00:19:08,030 We'll start with some simple things and then we'll slowly kind of zoom in onto more complex stuff. 197 00:19:08,030 --> 00:19:12,590 But just to kind of whet your appetite, let's start with the ping of death. 198 00:19:13,470 --> 00:19:14,690 Interesting name, right? 199 00:19:14,690 --> 00: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. 200 00:19:25,430 --> 00:19:28,570 So large, in fact, that the machine can't handle it. 201 00:19:28,570 --> 00:19:29,750 It'll choke. 202 00:19:29,790 --> 00: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. 203 00:19:37,670 --> 00: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. 204 00:19:49,350 --> 00:19:52,610 So, typically, ping packets are very small. 205 00:19:52,610 --> 00:20:02,870 But IPv4 ping packets have a maximum allowable packet size of 65,535 bytes. 206 00:20:02,870 --> 00: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. 207 00:20:13,430 --> 00:20:15,870 They'll choke and they'll fall over. 208 00:20:15,890 --> 00: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. 209 00:20:26,910 --> 00: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. 210 00:20:42,330 --> 00:20:44,910 It'll freeze, it'll choke, it'll crash. 211 00:20:45,750 --> 00:20:51,010 So, we're using this example where the ICMP echo or that ping packet could be used for this attack. 212 00:20:54,590 --> 00: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. 213 00:21:04,310 --> 00:21:08,690 That could be TCP or UDP or any IPX stuff. 214 00:21:09,110 --> 00: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. 215 00:21:25,910 --> 00:21:29,330 So, with that said, let's take a look at the source code here. 216 00:21:29,510 --> 00:21:33,630 You can see I'm using the send function which is part of Scapey. 217 00:21:33,630 --> 00:21:36,430 We say we've imported everything into our namespace. 218 00:21:36,690 --> 00: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. 219 00:21:48,710 --> 00:21:51,970 We'll create a fragment as kind of we discussed earlier. 220 00:21:54,590 --> 00:22:00,890 It could be rebuilt and reassembled by the victim machine that could potentially cause it to crash and choke. 221 00:22:01,510 --> 00:22:07,430 And inside of that, we'll build this ICMP packet just as we've done before in that previous example. 222 00:22:07,430 --> 00: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. 223 00:22:14,650 --> 00:22:17,030 And I just use a simple dummy string. 224 00:22:17,030 --> 00:22:18,130 I just use the letter X 225 00:22:24,590 --> 00: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. 226 00:22:33,630 --> 00:22:36,530 It'll choke and it'll fall right over. 227 00:22:36,530 --> 00:22:43,210 I did mention though that this ping of death attack is less common today. 228 00:22:44,310 --> 00:22:49,970 More so now, you'll see other kinds of attacks that are still this denial of service attack. 229 00:22:49,970 --> 00:22:51,410 We're being a jerk. 230 00:22:51,410 --> 00:22:58,590 We're overwhelming, flooding and it's bogging down the resources on that victim or target. 231 00:22:59,250 --> 00:23:05,350 So one of the more common ones you'll see now is perhaps an ICMP or a ping flood. 232 00:23:05,350 --> 00:23:08,070 And we can certainly send other kinds of floods. 233 00:23:08,070 --> 00:23:11,490 One of the most common ones you might see is a SYN flood. 234 00:23:12,110 --> 00:23:19,930 SYN flood is another denial of service or DOS attack which will make that server, your victim, unavailable to respond. 235 00:23:20,170 --> 00:23:21,730 It'll be just too busy. 236 00:23:21,730 --> 00:23:22,790 It'll be bogged down. 237 00:23:22,790 --> 00:23:29,470 It'll be hosed because something will be consuming all of the available server resources. 238 00:23:29,710 --> 00:23:36,650 We're going to cause that by sending packets with that SYN flag set. 239 00:23:36,650 --> 00:23:39,030 So you know TCP packets, right? 240 00:23:39,310 --> 00:23:47,910 TCP being the Transmission Control Protocol which ensures there is a connection in place by using the three-way handshake, right? 241 00:23:48,290 --> 00: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. 242 00:24:00,810 --> 00: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. 243 00:24:11,350 --> 00: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. 244 00:24:21,730 --> 00:24:25,570 On a packet or the acknowledgement, okay, someone is listening and we can talk. 245 00:24:25,570 --> 00:24:27,150 We can have this conversation. 246 00:24:27,910 --> 00: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. 247 00:24:47,850 --> 00:24:50,750 So the attack is simple. 248 00:24:50,750 --> 00:24:56,250 We just send a ton of SYN packets where we're just starting all these conversations. 249 00:24:56,250 --> 00:25:00,170 We're dialing the phone, but once someone answers, we don't care. 250 00:25:00,170 --> 00:25:03,050 We don't respond to them with an ACK packet. 251 00:25:03,050 --> 00:25:05,310 So they're just, they're overwhelmed, right? 252 00:25:05,310 --> 00:25:06,670 The phone keeps ringing. 253 00:25:06,670 --> 00: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. 254 00:25:10,470 --> 00:25:16,070 They're just not having this conversation, but they're still holding the phone and more are ringing. 255 00:25:17,010 --> 00:25:20,070 That will hog all the resources. 256 00:25:21,210 --> 00: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. 257 00:25:32,290 --> 00:25:35,430 All those resources are being utilized right now. 258 00:25:35,890 --> 00:25:41,890 Because this attack brings that server to the halfway point in the three-way handshake, right? 259 00:25:41,890 --> 00:25:46,390 They started the communication, but have not responded to the server's acknowledgement. 260 00:25:46,670 --> 00:25:50,170 That means that it's halfway communicated. 261 00:25:50,170 --> 00:25:53,090 That's why it's called that half-open attack. 262 00:25:53,430 --> 00:25:54,690 Kind of interesting. 263 00:25:54,970 --> 00:25:57,150 So let's take a look at the source code, right? 264 00:25:57,150 --> 00:26:00,170 Scapey, again, makes this super-duper easy. 265 00:26:00,250 --> 00: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. 266 00:26:11,850 --> 00:26:13,810 We could just pass that to the function. 267 00:26:13,970 --> 00:26:17,810 So I'm creating this SYN flood object, or variable, right? 268 00:26:17,810 --> 00:26:20,750 I send in a keyword argument for the destination. 269 00:26:20,750 --> 00:26:22,610 Again, just an IP address we'll use. 270 00:26:22,610 --> 00:26:27,010 We'll set an ID number for that packet and we'll specify the time to live. 271 00:26:27,010 --> 00:26:34,870 These values aren't extremely important for kind of just our discussion, but obviously that next layer certainly is. 272 00:26:34,870 --> 00: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. 273 00:26:51,510 --> 00:26:56,790 That'll return something to make it look like, okay, we're coming from a different port every time. 274 00:26:57,130 --> 00:27:01,890 The D-port, or the destination port, will be passed in as a list, or a little Python array. 275 00:27:01,890 --> 00:27:04,450 We'll just send this over to port 80, HTTP. 276 00:27:04,510 --> 00:27:09,410 You could specify this to whatever you wanted to, maybe SSH or anything specifically. 277 00:27:09,710 --> 00:27:13,630 Specify a sequence number, specify an acknowledgement number. 278 00:27:13,630 --> 00:27:19,650 Again, for this example, those don't really matter all that much, but maybe they could in other scenarios. 279 00:27:19,650 --> 00:27:27,650 A window size, and the most important thing here, the flags that are set on this TCP packet. 280 00:27:27,690 --> 00:27:35,610 Obviously, I'm just passing in a string here with that capital S, and certainly enough, that stands for SYN, right? 281 00:27:35,610 --> 00:27:39,430 The SYN flag has been set on this packet. 282 00:27:39,430 --> 00:27:44,810 So we have created one packet that is just a SYN packet. 283 00:27:44,810 --> 00:27:49,310 The very, very first step in that TCP three-way handshake. 284 00:27:49,570 --> 00: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. 285 00:27:59,410 --> 00:28:03,910 So we will repeatedly, over and over and over again, send this packet. 286 00:28:04,890 --> 00:28:10,070 The keyword arguments there, that enter or the interval, we'll send those at three-tenths of a second. 287 00:28:10,070 --> 00:28:15,630 We'll retry every two seconds if that kind of gets dropped, and we'll have a timeout of four seconds. 288 00:28:15,710 --> 00: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. 289 00:28:26,110 --> 00:28:31,850 We are flooding that target victim server with this SYN flood attack. 290 00:28:31,850 --> 00: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. 291 00:28:39,590 --> 00:28:45,010 That'll just return a tuple, okay, or a list of what packets actually had a response and what didn't. 292 00:28:46,210 --> 00: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. 293 00:28:55,110 --> 00:28:57,390 All you've done is outlined the structure. 294 00:28:57,390 --> 00:29:00,930 You've orchestrated this packet, and now you can put it to work. 295 00:29:01,850 --> 00:29:03,750 You can use it as a SYN flood. 296 00:29:04,590 --> 00: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. 297 00:29:15,890 --> 00:29:17,650 One machine. 298 00:29:18,130 --> 00:29:26,430 So, potentially, that endpoint or that target, the victim server, once it realizes, hey, I'm under attack, right? 299 00:29:26,430 --> 00:29:27,810 I'm in danger. 300 00:29:27,810 --> 00: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. 301 00:29:34,910 --> 00:29:36,900 I can just block it off. 302 00:29:37,710 --> 00:29:39,010 Well, you're totally right. 303 00:29:39,010 --> 00:29:40,990 That's absolutely doable. 304 00:29:40,990 --> 00:29:46,990 For that reason, this kind of thing isn't often done just with one host. 305 00:29:47,310 --> 00:29:49,770 Just with one attacking machine. 306 00:29:49,770 --> 00: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. 307 00:29:57,560 --> 00: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. 308 00:30:10,820 --> 00:30:16,260 That might make it a little bit harder to do, harder to track down, harder to trace. 309 00:30:16,260 --> 00:30:18,380 However, we could do even more. 310 00:30:18,380 --> 00: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. 311 00:30:26,120 --> 00:30:27,380 We want to hide it. 312 00:30:27,380 --> 00:30:30,580 We want to mask it and obfuscate that just a little bit more. 313 00:30:30,760 --> 00:30:36,620 But you can tell with Scapey, we are crafting our packets at the granular level. 314 00:30:36,620 --> 00: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? 315 00:30:46,080 --> 00:30:53,640 We could say that our source IP address comes from a different IP address, comes from a different host. 316 00:30:53,640 --> 00:30:58,020 We can spoof our IP address simply by passing in the keyword argument. 317 00:30:58,020 --> 00:31:04,720 Just as you see the example there, we specify that DST keyword argument as an IP address string. 318 00:31:04,720 --> 00: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. 319 00:31:14,360 --> 00:31:19,340 We can spoof our IP address super easily with Scapey. 320 00:31:19,360 --> 00:31:25,320 And we can use that as a segue into the next attack, DNS amplification attacks. 321 00:31:25,320 --> 00: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. 322 00:31:40,540 --> 00: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. 323 00:31:52,260 --> 00: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. 324 00:32:07,760 --> 00: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. 325 00:32:23,540 --> 00:32:26,260 You can see this here in the source code, right? 326 00:32:26,260 --> 00:32:30,660 We're defining, again, another object or variable to keep track of our packet. 327 00:32:30,660 --> 00: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. 328 00:32:42,120 --> 00:32:44,820 Note, this will act as our victim. 329 00:32:44,820 --> 00:32:51,640 This is the target machine that will have the domain name, and attack that large request. 330 00:32:51,640 --> 00: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? 331 00:32:59,400 --> 00: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. 332 00:33:11,700 --> 00:33:16,580 Here, I'll just ask for anything regarding google.com or that domain. 333 00:33:16,580 --> 00: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. 334 00:33:24,480 --> 00: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. 335 00:33:34,300 --> 00: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. 336 00:33:43,980 --> 00:33:46,660 The DNS server will respond accordingly. 337 00:33:46,660 --> 00:33:54,120 It will give all the information it can, but send it to that source IP address, not our actual attacker. 338 00:33:54,120 --> 00:33:59,820 That will flood and overwhelm, choke, that target victim server. 339 00:34:00,140 --> 00:34:05,400 Obviously, you'd want to have more than one attack or one attacking machine doing this. 340 00:34:05,400 --> 00:34:12,600 You could perform this distributed denial of service, that DDoS, or send this request multiple times. 341 00:34:12,600 --> 00:34:15,760 But I think this attack is really cool and really interesting. 342 00:34:15,760 --> 00: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. 343 00:34:27,840 --> 00: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. 344 00:34:39,340 --> 00:34:43,660 Typically, that job of the teller will read back your order, right? 345 00:34:43,660 --> 00:34:46,480 So, envision this scenario. 346 00:34:46,480 --> 00:34:48,060 You as the driver, right? 347 00:34:48,060 --> 00:34:52,160 You as the attacker, you say, I want everything on the menu. 348 00:34:52,160 --> 00: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. 349 00:35:01,080 --> 00: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. 350 00:35:13,660 --> 00: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. 351 00:35:27,440 --> 00:35:28,740 Kind of cool. 352 00:35:28,860 --> 00:35:35,840 And obviously, another added benefit to this is that the attacker is performing this attack indirectly. 353 00:35:35,840 --> 00: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. 354 00:35:46,080 --> 00:35:51,500 The attacker doesn't really leave any fingerprints or trace on the target. 355 00:35:51,660 --> 00:35:53,660 It's not reaching it directly. 356 00:35:53,660 --> 00:35:55,600 It is an indirect attack. 357 00:35:55,600 --> 00: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. 358 00:36:04,760 --> 00:36:08,680 Okay, now let's talk about our finale attack. 359 00:36:08,680 --> 00:36:11,900 I want to discuss BGP abuse. 360 00:36:11,900 --> 00:36:21,080 So BGP is the Border Gateway Protocol, and that is the standard routing protocol of the internet today. 361 00:36:21,660 --> 00: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? 362 00:36:32,880 --> 00: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. 363 00:36:45,020 --> 00: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. 364 00:36:58,240 --> 00:37:02,760 This is important because it's the backbone of the internet. 365 00:37:02,760 --> 00:37:03,660 It's the freeway. 366 00:37:03,660 --> 00:37:04,320 It's the highway. 367 00:37:04,320 --> 00:37:06,780 It's how our packets get from one place to another. 368 00:37:06,780 --> 00:37:11,660 It's what makes that large scale growth of the internet possible. 369 00:37:11,800 --> 00:37:15,020 I mentioned this freeway and highway analogy, right? 370 00:37:15,020 --> 00:37:18,580 And that's the easiest way to kind of envision this attack. 371 00:37:19,200 --> 00: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? 372 00:37:30,120 --> 00:37:37,800 Obviously, this routing table that these routers are using with BGP has to be correct and accurate. 373 00:37:37,800 --> 00:37:44,780 Otherwise, traffic, things might be directed and routed to the wrong and incorrect place. 374 00:37:44,780 --> 00: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. 375 00:38:04,480 --> 00:38:07,780 BGP was not designed with security in mind. 376 00:38:07,800 --> 00:38:14,400 With that said, obviously, there is a lot of room for potential abuse and danger. 377 00:38:14,400 --> 00: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, 378 00:38:32,560 --> 00: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. 379 00:38:46,720 --> 00: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. 380 00:38:54,980 --> 00: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. 381 00:39:07,260 --> 00:39:14,800 All we were simply going to do is send a packet with that RST or reset flag set. 382 00:39:14,820 --> 00: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. 383 00:39:28,680 --> 00:39:31,640 You can kind of note that here in the comments of the code. 384 00:39:31,640 --> 00: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. 385 00:39:44,500 --> 00:39:52,060 The sequence number and the acknowledgement number also have to match what that victim would be expecting. 386 00:39:52,360 --> 00:39:56,560 This is where we get into the conversation of being blind. 387 00:39:56,560 --> 00:39:57,980 We might not know that. 388 00:39:57,980 --> 00:39:59,540 Maybe it could be fuzz. 389 00:39:59,540 --> 00:40:02,680 Potentially you could just hammer this until you get a hit. 390 00:40:02,680 --> 00:40:09,040 But at the end of the day, what we're doing is we're sending packets in between these two routers. 391 00:40:09,040 --> 00: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. 392 00:40:20,140 --> 00:40:27,340 We're sending in that RST flag or the reset signal and notification part of this communication. 393 00:40:27,340 --> 00:40:29,160 You can note that in the flags there. 394 00:40:29,160 --> 00:40:32,940 Again, R to represent that RST and A for ACK. 395 00:40:32,940 --> 00:40:36,880 And of course passing in the appropriate sequence number and acknowledgement number. 396 00:40:36,880 --> 00:40:47,040 We send this packet and that target or victim will suddenly believe, okay, this BGP session was just shut down. 397 00:40:47,080 --> 00:40:50,340 They just hung up the phone and we're not going to talk anymore. 398 00:40:51,080 --> 00:40:55,720 Obviously, there's another router at play, the peer router. 399 00:40:55,720 --> 00:41:03,640 And this BGP protocol, the way that it's working is that it's sending any type of four potential messages. 400 00:41:03,640 --> 00:41:11,900 BGP could work with an open message or a notification message or a keep alive message or an update message. 401 00:41:11,900 --> 00:41:14,960 We'll tune into that update message soon. 402 00:41:14,960 --> 00: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. 403 00:41:22,040 --> 00:41:27,560 And yet the other router, our victim, is down with that RST flag. 404 00:41:27,560 --> 00:41:28,950 It's no longer talking. 405 00:41:29,440 --> 00:41:38,800 Because of BGP, there might be some keep alive messages in the conversation and that other victim router will restore. 406 00:41:38,800 --> 00:41:39,880 It will recover. 407 00:41:39,880 --> 00:41:42,640 This might take a minute, but it'll happen. 408 00:41:42,640 --> 00:41:50,880 So we could momentarily disrupt the communication, but maybe that will again be revived. 409 00:41:50,880 --> 00:41:53,580 If you wanted to, I don't know. 410 00:41:53,580 --> 00:41:56,280 Again, we're working in blind territory. 411 00:41:56,280 --> 00:42:01,780 You could potentially be hammering this over and over and over again and trying to keep shutting it down. 412 00:42:01,940 --> 00:42:06,180 Maybe that could be a worthwhile attack with BGP. 413 00:42:08,160 --> 00: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. 414 00:42:26,280 --> 00: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. 415 00:42:54,540 --> 00: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. 416 00:43:10,180 --> 00: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 417 00:43:23,900 --> 00:43:28,960 the most interesting thing here is that path update variable down at the bottom. 418 00:43:28,960 --> 00: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. 419 00:43:39,040 --> 00:43:43,220 Then we'll go ahead and send this packet with that path update. 420 00:43:43,500 --> 00:43:49,500 Now this is interesting because it could realistically result in one of three different things. 421 00:43:49,500 --> 00:43:56,820 The first case, if all the stars aligned, we have the source number and acknowledgement numbers right in the session. 422 00:43:56,820 --> 00: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. 423 00:44:08,740 --> 00: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. 424 00:44:18,400 --> 00:44:24,720 In the other case, I guess I'll call this case number three, we fail. 425 00:44:24,720 --> 00:44:26,020 It doesn't work. 426 00:44:26,040 --> 00: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. 427 00:44:33,200 --> 00:44:38,740 Kind of a bummer, but we know, okay, that might be natural with our blind attack here. 428 00:44:38,840 --> 00: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. 429 00:44:53,900 --> 00: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. 430 00:45:02,540 --> 00:45:06,100 You can mentally map that to a client and server, I suppose. 431 00:45:06,100 --> 00:45:12,100 Maybe an external or third party router still present, working with all these routes. 432 00:45:12,340 --> 00: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. 433 00:45:23,900 --> 00:45:30,280 Maybe that other third party router, it will receive that new information to take in this route. 434 00:45:30,280 --> 00:45:35,400 It could potentially, again, just not being in sync within the conversation. 435 00:45:35,400 --> 00:45:43,640 The receiving number might not match the kind of victim and target sending number in the sequence and conversation. 436 00:45:43,640 --> 00: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. 437 00:45:53,900 --> 00:45:57,120 I might send an acknowledge or a notification this is wrong. 438 00:45:57,120 --> 00: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. 439 00:46:04,360 --> 00:46:07,480 And those two will get in a little bit of an ACK war. 440 00:46:07,480 --> 00:46:10,060 They'll be repeatedly sending acknowledgements to one another. 441 00:46:10,060 --> 00:46:16,600 And this will happen at least until a timeout occurs and the session will be disrupted. 442 00:46:16,680 --> 00:46:18,500 It'll just shut down and stop. 443 00:46:23,900 --> 00:46:28,940 And eventually a keep alive will be in the midst of the conversation and it will restore. 444 00:46:29,320 --> 00: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. 445 00:46:36,920 --> 00: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. 446 00:46:44,360 --> 00: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. 447 00:46:55,760 --> 00:46:57,900 So we've talked about a few attacks. 448 00:46:57,900 --> 00:47:04,300 I hope some of those were kind of cool and kind of interesting in the conversation to take down the internet. 449 00:47:04,300 --> 00:47:11,240 I wanted to showcase some IRL cases or some real stuff where these sort of things actually happened. 450 00:47:11,240 --> 00:47:17,760 Maybe not an attack but at least a mishap that showcases some of the weakness between these protocols. 451 00:47:17,760 --> 00:47:21,880 Especially BGP or that Border Gateway Protocol. 452 00:47:21,880 --> 00:47:24,980 This was June 24th of 2019. 453 00:47:24,980 --> 00:47:26,880 Some of you might remember this. 454 00:47:26,880 --> 00:47:33,720 It seemed like all of the internet was being funneled through some small shop in like Pennsylvania or something. 455 00:47:33,720 --> 00: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. 456 00:47:41,560 --> 00: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. 457 00:47:52,760 --> 00: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. 458 00:48:04,620 --> 00:48:10,100 And that would take down a decent amount of stuff even between Amazon, Linode, and more. 459 00:48:10,100 --> 00:48:17,300 It was crazy to see that this was worldwide and CloudFlare I think at the point lost about 15% of traffic. 460 00:48:17,300 --> 00: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. 461 00:48:39,780 --> 00: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. 462 00:48:52,820 --> 00:48:58,540 This other case is even more recent over on July 17th of this year just a month back. 463 00:48:58,600 --> 00:49:01,340 Again, a BGP leak. 464 00:49:01,340 --> 00:49:02,440 CloudFlare is reporting on. 465 00:49:02,440 --> 00:49:04,040 You can check out their blog. 466 00:49:04,240 --> 00: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. 467 00:49:15,120 --> 00: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. 468 00:49:23,300 --> 00:49:31,180 CloudFlare actually does put a disclaimer and hey, we just want to enforce this is not the result of an attack. 469 00:49:31,180 --> 00: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. 470 00:49:48,500 --> 00:49:55,640 So again, just the reliance on how that protocol works and how much faith we end up putting in it. 471 00:49:55,740 --> 00: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. 472 00:50:04,220 --> 00: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. 473 00:50:10,100 --> 00:50:14,380 But how could we try to prevent some of this stuff? 474 00:50:14,380 --> 00:50:19,660 We talked about the ping of death and I mentioned that is generally protected today. 475 00:50:19,660 --> 00: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. 476 00:50:28,000 --> 00:50:31,360 That could really potentially be done just adding a check. 477 00:50:31,360 --> 00:50:35,300 Make sure, hey, are we not exceeding that maximum packet size? 478 00:50:35,960 --> 00:50:41,860 Another option with that is actually kind of allocating a memory buffer to be able to handle that packet size. 479 00:50:41,860 --> 00:50:47,420 I feel like that, I don't know, might not have the real intended effect that we want. 480 00:50:47,420 --> 00:50:53,840 I think the protections that we have to just verify and check, hey, are we dealing with an overblown, oversized packet? 481 00:50:53,840 --> 00:50:55,520 That makes the most sense. 482 00:50:56,240 --> 00: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. 483 00:51:08,600 --> 00:51:13,020 And that would obviously need to be returned and responded back with a response. 484 00:51:13,020 --> 00:51:19,580 Or maybe you could recycle the older previous half-open TCP connections that were started. 485 00:51:19,580 --> 00: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. 486 00:51:31,000 --> 00:51:39,900 For DNS amplification attacks, this one is almost, it seems just natural, right? 487 00:51:40,300 --> 00: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. 488 00:51:53,480 --> 00: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. 489 00:52:00,300 --> 00:52:04,840 Another technique is actually verifying, okay, who is requesting this information? 490 00:52:04,840 --> 00: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? 491 00:52:11,860 --> 00:52:15,120 We have the conversation of DNSSEC, right? 492 00:52:15,120 --> 00:52:23,460 But the gimmick with that DNS amplification attack is that it's just the natural functionality of DNS. 493 00:52:23,460 --> 00: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. 494 00:52:32,340 --> 00: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. 495 00:52:45,340 --> 00:52:46,340 BGP. 496 00:52:46,500 --> 00:52:47,960 Oh, man. 497 00:52:48,460 --> 00:52:51,860 BGP abuse protection is kind of tough, right? 498 00:52:51,860 --> 00:52:56,440 Just because, again, this is how it has to work. 499 00:52:56,460 --> 00: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. 500 00:53:07,820 --> 00: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. 501 00:53:17,880 --> 00:53:21,180 And BGP itself was not designed with that security in mind. 502 00:53:21,180 --> 00:53:24,280 It's working off of TCP as it needs to. 503 00:53:24,280 --> 00: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. 504 00:53:31,080 --> 00: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. 505 00:53:42,300 --> 00: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. 506 00:53:52,960 --> 00:54:01,440 If you are struck by random to whatever BGP attack, you will know it, right? 507 00:54:01,440 --> 00:54:08,760 Obviously, okay, signs of increased latency, your network's moving slow, degraded network performance, and just misdirected traffic. 508 00:54:08,800 --> 00:54:13,400 That should be a big indicator, an alarm going off in your head. 509 00:54:13,400 --> 00:54:14,600 Maybe something's wrong. 510 00:54:14,600 --> 00:54:16,820 Potentially, BGP hijack. 511 00:54:16,820 --> 00:54:19,940 The internet has been muffed up. 512 00:54:19,940 --> 00:54:23,540 All these things we can take into consideration, right? 513 00:54:23,540 --> 00: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. 514 00:54:47,460 --> 00:54:52,700 Maybe we can be a little bit more knowledge about it and we won't take down the internet. 515 00:54:54,080 --> 00: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. 516 00:55:00,740 --> 00:55:05,320 You could hopefully be able to sort through this by kind of the topic or discussion that I've showcased. 517 00:55:05,320 --> 00: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. 518 00:55:13,700 --> 00:55:18,420 But some of the specific things, some of the research papers, there's a lot of really cool stuff in here. 519 00:55:19,140 --> 00:55:19,700 Cloudflare, of 520 00:55:27,220 --> 00: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. 521 00:55:34,760 --> 00:55:36,600 There are some really, really cool stuff in here. 522 00:55:36,600 --> 00:55:44,580 The Naval Postgraduate School had a research paper out I think back in 2017 that discussed these BGP blind attacks. 523 00:55:44,580 --> 00:55:49,820 There's some University of California stuff out there and there's even a black hat presentation that discusses this 524 00:55:57,220 --> 00:55:59,220 and more worthwhile stuff over there. 525 00:55:59,220 --> 00:56:04,160 And if you're interested, I do, do recommend you do some of that research. 526 00:56:04,160 --> 00:56:06,140 Check out some of these references and resources. 527 00:56:06,140 --> 00:56:08,160 I hope they are helpful to you. 528 00:56:09,200 --> 00:56:10,880 Okay, I'm going to wrap it up. 529 00:56:10,900 --> 00:56:15,500 If you have any questions or comments or feedback, I'd love to hear from you. 530 00:56:15,700 --> 00:56:18,320 Obviously, I'm putting this out here for you. 531 00:56:18,600 --> 00:56:23,300 I'm happy to be part of the community and jamming and meeting everyone and seeing everyone here at DEF CON. 532 00:56:27,220 --> 00:56:30,640 If you want to hang out, just want to discuss, please do reach out. 533 00:56:30,640 --> 00:56:33,040 You've got my email address, my silly YouTube channel. 534 00:56:33,080 --> 00:56:36,080 If you want to see any of my code, that's on GitHub and of course Twitter. 535 00:56:36,080 --> 00:56:40,520 And if you want to do some real-time instant messaging, that's my Discord server there. 536 00:56:40,880 --> 00:56:41,540 Okay. 537 00:56:41,880 --> 00:56:42,900 Holy cow. 538 00:56:42,900 --> 00:56:44,840 Thank you so, so much, everybody. 539 00:56:44,840 --> 00: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. 540 00:56:50,280 --> 00:56:51,160 Thank you. 541 00:56:51,160 --> 00:56:51,560 Thank you. 542 00:56:51,560 --> 00:56:52,180 Thank you. 543 00:56:52,180 --> 00:56:53,200 This has been a blast . 544 00:56:53,200 --> 00:56:55,200 I hope you enjoy the talk and presentation. 545 00:56:55,200 --> 00:56:59,740 I hope you enjoy DEF CON Safe Mode and please stay safe and enjoy yourself . 546 00:56:59,740 --> 00:57:00,920 Take care, everybody. 547 00:57:00,920 --> 00:57:01,740 Thank you.