 Alrighty, hello everyone. Welcome. Thank you for tuning in. I appreciate you being here. This is a talk and presentation titled Take Down the Internet with Scapey. I'm presenting this as part of DEF CON 28 or DEF CON Safe Mode and I'm here at the Packet Hacking Village. So let's dive into the presentation, but before we do, I've got to say this. I've said it before, I'm about to say it now, and I'm certainly going to say it again many many times for the presentation. Thank you. Thank you for being here. Honestly, seriously, like 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. Thank you for tuning into this talk. Thank you for being a part of all this. I usually say this at the end and I'm certainly going to, but now especially, I think it's really important, just thank you. Thanks for being here. I really, really appreciate it. Okay. So the classic disclaimer, right? The start of every talk, it's just how it's got to start. These are my words, not my employers. I don't represent them. I'm not speaking for them, et cetera. These are just, this is stuff that I wanted to bring to you, me personally. Other disclaimer, don't or do try this at home, right? Anything that we talk about, anything that I showcase here, obviously it's a talk titled take down the internet. Don't actually do that or maybe do it at, maybe your own small scale lab environment, et cetera. You can tinker with it and explore with it, but don't actually take down the internet, right? Cool. Next, your mileage may vary. I bring this up with everything that I kind of try and showcase. Look, I'm talking about it and I'm showing it to you. Maybe you'll have different results. Maybe something will work differently or strangely in the way that you do it. If you do this sort of thing, 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. Okay. Last bit, we're the good guys here, right? We talk about security. We talk about cybersecurity. We break things for the sake of making them better. We hack for good. I want you to do the same. 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. I want to reiterate to you and kind of enforce it. Hey, hack for good. Okay. Obligatory introduction, right? Who is this guy talking at you? Hello. My name is John Hammond. I'll try and run through this quickly because I know no one cares, not even me. I used to just do some stuff with the department of defense cyber crime center and their cyber training academy. And I also work with like the defense start reduction agency as a kind of a red team cyber operator. Right now I'm working as a senior security researcher over at huntress labs again, not speaking for them. These are my words, not theirs. And in my free time, I like to play a little bit of capture the flag. 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 to try and improve everyone's cyber security skill. On that same coin, I do produce some cheesy YouTube videos. I published and showcase some capture the flag write ups or programming tutorials, video guides, stuff like that. But that's all nerdy stuff that you don't really have to care about. Let's talk about what we're going to talk about kind of meta, right? So here's the agenda, the roadmap, the outline for our discussion. First, we'll lay the groundwork, we'll put down a little bit of a background, really set the scene for what we're going to be discussing. I'm going to be talking a little bit about Python, right? Python is kind of my weapon of choice, but we needed to make a distinction between Python two versus Python three, and what we'll kind of be using as our vessel throughout this talk. 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, with the stuff that you would find in P caps, if you take and look at it in a wire shark or TCP dump, et cetera, we're going to do that with scapey inside of Python. So we'll talk about how to install it, some documentation syntax and use cases, et cetera. Then we'll get into the real meat of the conversation. 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, the ping of death, the sin flood, DNS attacks, BGP, et cetera. I do want to showcase a couple of IRL or in real life cases, right? Stuff that we've really seen out in the real world that is real. 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. 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. Finally, I'll showcase some of the resources and references that I use to put together this conversation, this talk for you, and we'll have the boilerplate template slides, how you can contact me. And of course, I will thank you again and again. I'm really, really appreciative that you're here. All right, let's get into it. To get things rolling, let's lay the foundation. We're going to be talking about packets, right? We're here in the packet hacking village. We're talking about network-oriented stuff. So naturally, we're going to be talking about packets using scapey, using Python, and we'll dive into that more. 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. It's about obnoxious, annoying, adversarial, and disruptive attacks. So nothing like leet, super cool, zero days, crazy, like, ninja warrior, cyber hacker stuff, but really just being mean and breaking stuff. We're trying to recklessly break stuff. I want to showcase some of this to you because really, I want to show you just how easy it is and how Python, just the same script in language that's about on every Unix system, can do this stuff and how you could do it if you really wanted to, but you shouldn't. You don't have to, right? Take down the internet, obnoxious, annoying, adversarial, and disruptive attacks. That's the background. All right, now let's talk a little bit about Python. I'm going to be using Python as the vessel for this talk, right? 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. So I want to lay the foundation again with Python. Python is a wonderful hackers language. 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. That means that it's super duper friendly. It's really easy to knock out quick testing scripts or to rapidly prototype some ideas. 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. So there are some conversations, right? Because now we are in a new era. We are in 2020 and Python 2, the older version of Python is dead. It's not on the table anymore. Python 2 reached end of life at the start of this year. And now Python 3 is the officially supported version. 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 2. And of course, Python is part of Linux. It is typically shipped and natively kind of built into a lot of common Linux distributions. And honestly, you should be using Linux. I don't know why you wouldn't be. 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. 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, go fix that up and hop over to Python 3 now as the officially supported version. 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 just as an automated tool, not manually working through the interpreter or the interactive shell there. And a lot of our conversations, what we'll be discussing, I am 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. Okay, let's move on because you probably all already know about Python and this is boring. So let's talk about Scapy. Scapy is incredible, fantastic, phenomenal. It is a module, it's a library, it's something you can just install, pull in to use with your Python code, and it gives you the ability to craft network packets. You can customize them, you can forge them, you can create them, you can, 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 tune, like zoomed in microscopic customization of what that packet looks like. And that's super duper cool. 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 pseudo app update, and you'll install pip, if you're working with that little handy Python package manager, and let's use pip install Scapy. Now you could run Scapy in one of two ways, very, very similar to what we talked about in Python, right? Scapy 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, or you could work with it inside of a script and have Python just import Scapy as a whole module, and you can access all of the code, the functions, the variables, all of that functionality that Scapy offers inside of your Python scripts inside of Python. Now this is crazy cool, because we can work with TCP packets, UDP packets, any other network stuff, maybe Canvas protocols or Bluetooth, there's so much more, and we could dive into some of the documentation for Scapy. I always want to point people to the real documentation, because that's where the real stuff is, right? I'm not going to be the expert, sorry, 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? Documentation is the real accurate stuff, that's what's really there, really built in, and the official source, it's what's good to go to when you need help or you're trying to learn something new. Obviously, there's a man page for the command if you wanted to fire that up, obviously, they've got an online web presence, you can check them out at scapy.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, it's open source, it's awesome, it's all Python, good stuff. The website is actually fantastic, they have a page over there called Awesome Scapy, and that will showcase other tools, exploits, and some sample code to use, and it's really, really cool. 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, or stuff from crack, the attack against WPA2. Super duper cool, really recommend you go check that out. Okay, now let's talk about the basic syntax of scapy, because if we want to use it, we have to know how to. I say that scapy is Pythonic in that the syntax that it uses when you're working with the module, you're working with Python objects, right? 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? Functions and variables just with a kind of a different decorated name. 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. So you can see I'm working in like a little bit of a script here, right? 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 scapy.all import everything or the asterisk, the star, the wild card to pull in everything that that scapy module has into my current name space. So I can interact with it and I can work with it through Python. So here I'm going to create an object or a little variable ping equals and that the IP, this big class name, right? You can see the capital letters there. That's going to return a scapy object. And it's going to be a packet and I can define how that packet looks. Maybe I don't want to use an IP or maybe that specific header for that protocol. I could zoom in on other things between TCP, UDP, HTTP or anything else. And scapy already has support for all those crazy cool protocols and layers. And you could just pull them in and work with them. Or if you really wanted to, you can go do a little deep dive, get in the internals and build your own. So note inside here, I'm creating this IP object and I'm passing in a keyword argument. I'm saying DST or the destination, the destination IP address. I've simply set that to a string, 192.168.1.1. And I've had it a little division symbol or that forward slash, which looks weird, right? Because we're not dividing these objects, but I'm using that syntax and that is the syntax that scapy uses to actually add layers in or kind of build them into that packet that we're craft. So I'm going to say, this is simply going to be an ICMP packet or ping packet, right? I've assigned that to that ping variable or the object. And I'm just going to print that out on the screen. 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, right? It literally took one line of Python code and now I have a ping packet and I could do this. I could, I could send this packet. I could receive the information that comes back, maybe a little echo or request, reply ping. That's very, very cool. All in a script, all automated and extensible, whatever way that I want and super duper short, right? One line of that Python code, easy to read, easy to write. Obviously, escapee is abundant and there are more examples of this sort of thing on their website and their documentation. And that's really, really why I'm pointing you all towards it because that's where the good stuff is. 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. Okay. Last slide on escapee, I promise, then I'll shut up about it and we can move on. I'm not trying to sound like an evangelist here, but I am trying to show you all of the cool things that escapee can do. Obviously, in this last slide, we just looked at a super duper small minuscule example of one thing that escapee could do. 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, or we could sniff and listen and actually capture live packets and dissect them or forge new ones, etc., with filters, important exports, create graphs, reports, tables, etc., etc., and obviously, all of those specific different protocols that we want to work with, we can. And then maybe we could turn it into more of the offensive side. We could probe or scan or attack networks, fuzz specific aspects of a protocol or send a malformed packets, and we could do crazy tricks like, okay, art poisoning or do some specific kinds of scans, etc., etc. 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. You have the entire arsenal of the Python language and libraries, modules, other tools that you can use and pull into it. So that's super duper cool. Now let's get into the good stuff. Let's get into the really cool attacks that could potentially take down the internet, right? So we'll start small, we'll start with some simple things and then we'll slowly kind of zoom in onto more complex stuff. But just to kind of wet your appetite, let's start with the ping of death. Interesting name, right? 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 so large in fact that the machine can't handle it. It'll choke. 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. 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. So typically ping packets are very small but IPv4 ping packets can be much larger up to the maximum allowable packet size of 65,535 bytes. 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. They'll choke and they'll fall over. 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. 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. It'll freeze, it'll choke, it'll crash. So we're using this example where the ICMP echo or that ping packet could be used for this attack but really anything that sends an IP datagram that can hold more data or can have this attached information that extends beyond that maximum size could be used for this attack. That could be TCP or UDP or any IPX stuff. Admittedly the Pingadeth 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. So with that said let's take a look at the source code here. You can see I'm using the send function which is part of Scapey. We say we've imported everything into our namespace. 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. We'll create a fragment as kind of we discussed earlier, okay sending fragments that might be rebuilt and reassembled by the victim machine that could potentially cause it to crash and choke and inside of that we'll build this ICMP packet just as we've done before in that previous example. However you can see there at the end we use another divider or to add in another layer or some more information into this packet and I just use a simple dummy string. I just use the letter x and I multiply it by this large number so I have this data payload, this information that 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, it'll choke and it'll fall right over. I did mention though that this ping of death attack is less common today, right? More so now you'll see other kinds of attacks that are still this denial of service attack, right? We're being a jerk, we're overwhelming, flooding and just bogging down the resources on that victim or target. So one of the more common ones you'll see now is perhaps an ICMP or a ping flood and we can certainly send other kinds of floods. One of the most common ones you might see is a sin flood. Sin flood is another denial of service or DOS attack which will make that server or your victim unavailable to respond. It'll be just too busy, it'll be bogged down, it'll be hosed because something will be consuming all of the available server resources. We're going to cause that by sending packets with that sin flag set. So you know TCP packets, right? TCP being the transmission control protocol which ensures there is a connection in place by using the three-way handshake, right? The client on one side of the conversation will send to the server a packet with the sin flag set to synchronize or start the conversation and begin requesting communication. The server over on the other end of the conversation will say and respond back with a sin AC packet or a packet sent with those flags set. Finally, the client knowing that the server has responded, that someone actually answered the phone, it will respond once more with an AC flag set on a packet or the acknowledgement, okay someone is listening and we can talk, we can have this conversation. 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 sin AC packet, it will wait and wait to receive that AC packet from the client so that it can begin having this conversation. So the attack is simple. We just send a ton of sin packets where we're just starting all these conversations. We're dialing the phone but once someone answers we don't care. We don't respond to them with an AC packet. So they're just, they're overwhelmed, right? The phone keeps ringing, someone, they're going to pick it up and they're going to want to talk to someone but no one will be there. They're just not having this conversation but they're still holding the phone and more are ringing. That will hog all the resources. 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. All those resources are being utilized right now because this attack brings that server to the halfway point in the three-way handshake, right? They started the communication but have not responded to the server's acknowledgment. That means that it's halfway communicated. That's why it's called that half open attack. Kind of interesting. So let's take a look at the source code, right? Skapey again makes this super-duper easy. 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 SIN flood. We could just pass that to the function. So I'm creating the SIN flood object or variable, right? I send in a keyword argument for the destination. Again, just an IP address we'll use. We'll set an ID number for that packet and we'll specify the time to live. These values aren't extremely important for kind of just our discussion but obviously that next layer certainly is. We create a TCP portion of this packet and that SPORT or SPORT is how you should read that for our source port. That's just going to be a random ephemeral port that Skapey will help us generate with that ran short function there. That'll return something that make it look like, okay, we're coming from a different port every time. The D port or the destination port will be passed in as a list or a little Python array. We'll just send this over to port 80, HTTP. You could specify this to whatever you want it to, maybe SSH or anything specifically. Specify a sequence number, specify an acknowledgement number. Again, for this example, those don't really matter all that much but maybe they could in other scenarios. A window size and the most important thing here, the flags that are set on this TCP packet. Obviously I'm just passing in a string here with that capital S and certainly enough that stands for SIN. The SIN flag has been set on this packet. We have created one packet that is just a SIN packet. The very, very first step in that TCP three-way handshake. The next line below, we're going to end up using that SR loop function that Skapey makes available to us and that is going to send and receive packets in a loop. So we will repeatedly over and over and over again send this packet. The keyword arguments there, that inter or the interval will send those at three tenths of a second. We'll retry every two seconds if that kind of gets dropped and we'll have a timeout of four seconds. Again, those are a little extraneous but the point that we're getting across right now is that we are looping a SIN packet being sent over and over and over again. We are flooding that target victim server with this SIN flood attack. 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. That'll just return a tuple or a list of what packets actually had a response and what didn't. 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. All you've done is outlined the structure. You've orchestrated this packet and now you can put it to work. You can weaponize it as a SIN flood. You might notice though, in this example with this setup right here, we're sending this SIN flood attack just with our attacker machine, one machine. So potentially that endpoint or that target, the victim server, once it realizes, hey, I'm under attack, right? I'm in danger if they kind of had the opportunity to look through some logs or configure something out and determine, oh, I know the source of this attack. I can just block it off. Well, you're totally right. That's absolutely doable. For that reason, this kind of thing isn't often done just with one host, just with one attacking machine. So you bring in the conversation, okay, we're performing a denial of service attack at DOS attack or a DOS attack. 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, DDoS. That might make it a little bit harder to do, harder to track down, harder to trace. However, we could do even more. 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. We want to hide it. We want to mask it and obfuscate that just a little bit more. But you can tell with Scapey, we are crafting our packets at the granular level. 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, we could say that our source IP address comes from a different IP address, comes from a different host. We can spoof our IP address simply by passing in the keyword argument, just as you see the example there, we specify that DST keyword argument as an IP address string. We could just as easily specify SRC or the source IP address and make it look like we are coming from a different location. We can spoof our IP address super easily with Scapey, and we can use that as a segue into the next attack, DNS amplification attacks. 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. 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. 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. 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. You can see this here in the source code, right? We're defining, again, another object or variable to keep track of our packet. 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. Note, this will act as our victim. This is the target machine that will have the domain name name server send back that large request. You can see, again, our division symbol or the forward slash to add new layers. And we're adding a UDP packet portion, right? We'll set the deport 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 here, I'll just ask for anything regarding Google.com or that domain. You could of course ask for any type or any resource record you'd like, an A record, a text record, a CNAME record. 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. We'll have that packet formulated stored and encapsulated in that DNS amp object and variable. And again, we will just send that packet long. The DNS server will respond accordingly. It will give all the information it can, but send it to that source IP address, not our actual attacker that will flood and overwhelm choke that target victim server. Obviously, you'd want to have more than one attack or one attacking machine doing this. You could perform this distributed denial of service, right? That DDoS or send this request multiple times. But I think this attack is really cool and really interesting, right? If you put it in kind of layman's term or normal human explanation, say you are at the drive through ordering some fast food to go or whatever the case may be. 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. Typically that job of the teller will read back your order, right? So envision the scenario. You as the driver, right? You as the attacker, you say, I want everything on the menu. 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. 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. So maybe I don't know what 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 kind of cool. And obviously another added benefit to this is that the attacker is performing this attack indirectly. 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. The attacker doesn't really leave any fingerprints or a trace on the target. It's not reaching it directly. It is an indirect attack. You can see that here again with that syntax, but as always, escapee is making this really, really simple and honestly, really easy. Okay, now let's talk about our finale attack. I want to discuss BGP abuse. So BGP is the border gateway protocol. And that is the standard routing protocol of the internet today. 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? 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. 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. This is important because it's the backbone of the internet. It's the freeway. It's the highway. It's how our packets get from one place to another. It's what makes that large scale growth of the internet possible. I mentioned this freeway and highway analogy, right? And that's the easiest way to kind of envision this attack. 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? Obviously, this routing table that these routers are using with BGP has to be correct and accurate. Otherwise, traffic, things might be directed and routed to the wrong and incorrect place. 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. BGP was not designed with security in mind. With that said, obviously, there is a lot of room for potential abuse and danger. There could be BGP hijacking, another classic dial 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, 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. 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. 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. All we were simply going to do is send a packet with that RST or reset flag set. Granted, the situation kind of means our attacking host has to be in the middle of the conversation or listening or eavesdropping in on the conversation between two of the routers using BGP. You can kind of note that here in the comments of the code, 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. The sequence number and the acknowledgement number also have to match what that victim would be expecting. This is where we get into the conversation of being blind. We might not know that maybe it could be fuzz potentially you could just hammer this until you get a hit. But at the end of the day, what we're doing is we're sending packets in between these two routers. So I have a source set to one router that is going to act as the peer or one in this conversation communication and the destination as our victim router. We're sending in that RST flag or the reset signal and notification part of this communication. You can note that in the flags there again are to represent that RST and A for AC and of course passing in the appropriate sequence number and acknowledgement number. We send this packet and that target or victim will suddenly believe, okay, this BGP session was just shut down. They just hung up the phone and we're not going to talk anymore. Obviously, there's another router at play, the peer router. And this BGP protocol, the way that it's working is that it's sending any type of four potential messages. BGP could work with an open message or a notification message or a keep alive message or an update message. We'll tune into that update message soon. But what's going to happen here is that that peer router will notice it's still trying to work and have this conversation. And yet the other router our victim was just shut down with that RST flag. It's no longer talking because of BGP. There might be some keep alive messages in the conversation and that other victim router will restore. It will recover. This might take a minute, but it'll happen. So we could momentarily disrupt the communication, but maybe that will again be revived. If you wanted to, I don't know. Again, we're working in blind territory. You could potentially be hammering this over and over and over again and trying to keep shutting it down. Maybe that could be a worthwhile attack with BGP. 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 this BGP protocol will use. 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 escapee, you can see I've ran this load contrib function to load a contributed package or a portion of escapee to actually access more of the BGP functions and variables and work that we could do to actually modify BGP packets within our code. 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. 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 and we'll be supplying a clean exit value. The most interesting thing here is that path update variable down to the bottom. 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. Then we'll go ahead and send this packet with that path update. Now this is interesting because it could realistically result in one of three different things. The first case, if all the stars aligned, we had our sequence number and acknowledgement numbers right in the session. 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. We may have very well have changed the highway signs and we're directing packets and communication now going to or through a different place. In the other case, I guess I'll call this case number three, right? We fail. It doesn't work. Maybe our timing was off. Maybe the variables that play just weren't matching in the conversation and that didn't take kind of a bummer. But we know, okay, that might be natural with our blind attack here. In what I'll call case number two, or kind of the other scenario we can keep in mind is, well, we're showcasing conversation between two BGP routers right now. If there were potentially another BGP router in place that is not part of this conversation or not pertinent to this attack happening between our source and destination, you can mentally map that to a client and server, I suppose, maybe an external or third party router still present working with all these routes. If our victim, if our target upon success of getting this injected new malicious routing information, that will try and propagate it out. Maybe that other third party router, it will receive that new information to take in this route. It could potentially, again, just not being in sync within the conversation. The receiving number might not match the kind of victim and target sending number in the sequence and conversation. And that third party router will identify the mismatch and it will try and acknowledge and send responses that, Hey, I can't compute this. This doesn't work. So it might send an acknowledge or a notification. This is wrong. 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 act and acknowledgement. And those two will get in a little bit of an act war. They'll be repeatedly sending acknowledgements to one another. And this will happen at least until a time out occurs. And the session will be disrupted. It'll just shut down and stop. Now again, as we've kind of discussed earlier, maybe potentially a keep alive will be in the midst of the conversation and it will restore that might not be a minute in length as opposed to our previous example with that RST or reset flag being set, but this could take maybe four or five minutes for that session to come back to life after they've realized this mismatch. 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. So we talked about a few attacks. I hope some of those were kind of cool and kind of interesting in the conversation to take down the internet. I wanted to showcase some IRL cases or some real stuff where these sort of things actually happened, maybe not an attack, but at least a mishap that showcases some of the weakness between these protocols, especially BGP or that border gateway protocol. This was June 24th of 2019. Some of you might remember this. It seemed like all of the internet was being funneled through some small shop in like Pennsylvania or something. 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. 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. 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. And that would take down a decent amount of stuff, even between Amazon, Linode and more. It was crazy to see that this was worldwide. And in Cloudflare, I think at the point lost about 15% of traffic. 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. 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. This other case is even more recent over on July 17th of this year, just a month back. Again, a BGP leak, Cloudflare is reporting on, you can check out their blog. Once again, BGP having an incorrect route that was being propagated and bleeding out and doing damage, potentially taking down the internet. 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. Cloudflare actually does put a disclaimer and hey, we just want to enforce this is not the result of an attack. 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. So again, just the reliance on how that protocol works and how much faith we end up putting in it. 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. 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, but how could we try to prevent some of this stuff? We talked about the ping of death and I mentioned that is generally protected today. Kind of a lot of modern systems and technologies will know how to behave and handle that large ping and packet size. That could really potentially be done just adding a check, make sure, hey, are we not exceeding that maximum packet size? Another option with that is actually kind of allocating a memory buffer or something to be able to handle that packet size. I feel like that, I don't know, might not have the real intended effect that we want. I think the protections that we have to just verify and check, hey, are we dealing with an overblown oversize packet that makes the most sense. The sin flood and other flooding attacks, especially with sin flood, you could be using some server sin cookies where the server will actually kind of specify a nice token or something specific to that communication. And that would obviously need to be returned and responded back with a response. Or maybe you could recycle the older previous half open TCP connections that were started. If you're realized, okay, this machine is getting overblown with open or half open connections, well, roll back to one of the ones that we've got started and just work with that as necessary. For DNS amplification attacks, this one is almost, I don't know, kind of, it seems, it seems just natural, right? 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. Maybe we could scope and turn down the stuff that is accessible within your network or a network or what is applicable. Another technique is actually verifying, okay, who is requesting this information? If you check that source IP address, does it come from someone that really should be able to access that and reach that? We have the conversation of DNS sec, right? But the gimmick with that DNS amplification attack is that it's just the natural functionality of DNS. 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. 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. BGP, oh man. BGP abuse protection is kind of tough, right? Just because, again, this is how it has to work. 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. Unless anyone is monitoring that and knowing when those changes are being put in place, it's hard to lock that down. And BGP itself was not designed with that security in mind. It's working off of TCP as it needs to. Maybe there'll be more developments with BGP sec, which I believe there are some conversations and research kind of being started in that direction, but anyone that declares changes to routes should be kind of a valid, authoritative and trusted source, not just a thing that could happen. And when that change does happen, that needs to be monitored and maybe notifications and set aware for individuals to detract that. If you are struck by whatever BGP abuse or your victim to whatever BGP attack, you will know it, right? Obviously, okay, signs of increased latency, your network's moving slow, degraded network performance, and just misdirected traffic. That should be a big indicator, an alarm going off in your head. Maybe something's wrong. Potentially, BGP hijack, the internet has been muffed up. All these things we can take into consideration, right? Defense and mitigations, maybe it's not the silver bullet, but these are things 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. Maybe we can be a little bit more knowledge about it and we won't take down the internet. Okay, this is just a data dump of all the resources and references that I had kind of used to help put this together. You could hopefully be able to sort through this by kind of the topic or discussion that I've showcased. 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. But some of the specific things, some of the research papers, there's a lot of really cool stuff in here. Cloudflare of course has a little entry for each of these and some other network attack papers or research that's been done previously or some example, open source tools and utilities that showcase this or even how to defend against it with IP tables or other things that are applicable. There are some really, really cool stuff in here. The Naval Postgraduate School had a research paper out I think back in 2017 that discussed these BGP blind attacks. There's some University of California stuff out there and there's even a black hat presentation that discusses this a little bit and does a fantastic job of it. I put my disclaimer in at the beginning of the talk, right? You might find more worthwhile stuff over there. And if you're interested, I do recommend you do some of that research, check out some of these references and resources. I hope they are helpful to you. Okay, I'm going to wrap it up. If you have any questions or comments or feedback, I love to hear from you. Obviously, I'm putting this out here for you. I'm happy to be part of the community and jamming and meeting everyone and seeing everyone here at DEF CON. This is always just an incredible experience. So if you do want to chat, if you want to hang out, just want to discuss, please do reach out. You've got my email address, my silly YouTube channel. If you want to see any of my code, that's on GitHub and of course Twitter. And if you want to do some real time instant messaging, that's my Discord server there. Okay. Holy cow. Thank you so, so much everybody. I cannot say it enough as I did the beginning of this talk, as I did hopefully threw it a little bit. Thank you. Thank you. Thank you. This has been a blast. I hope you enjoyed the talk and presentation. I hope you enjoy DEF CON safe mode and please stay safe and enjoy yourself. Take care, everybody. Thank you.