We wish everyone a safe flight home and travels.
Ducks.
But, no seriously, we hope that we will be all together soon, next, hopefully next year.
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.
Our talk is coming up next.
This next speaker here is a legend and needs no introduction.
He is a friend and a world-class trainer.
It is my pleasure to introduce to you John Hammond with Take Down the Internet with Scappy.
Take it away, John.
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 Scappy.
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 throughout the presentation.
Thank you. Thank you for being here.
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. 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 employer's.
I don't represent them. I'm not speaking for them, etc.
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, etc.
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. 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.
And 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 the Defense Threat Reduction Agency as 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,
try and improve everyone's cyber security skill.
On that same coin, I do produce some cheesy YouTube videos.
I publish 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 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.
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 PCAPs,
if you would take a look at it in Wireshark or TCP dump, etc.
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, etc.
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,
like fraud, DNS attacks, BGP, etc.
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, the same scripting 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 hacker's 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's 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 too.
And of course, Python is part of Linux.
It's typically shipped, and natively 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.
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.
Okay, let's move on, because you probably all already know about Python,
and this is boring, so let's talk about Scapey.
Scapey is incredible, fantastic, phenomenal.
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.
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, 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 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.
Now, you can run Scapey in one of two ways,
very, very similar to what we talked about in Python, right?
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.
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.
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.
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 is 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 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.
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 Scapey,
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 CRAC, the attack against WPA2.
Super duper cool, really recommend you go check that out.
Okay, now let's talk about the basic syntax of Scapey,
because if we want to use it, we have to know how to.
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?
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 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 Scapey.all import everything,
or the asterisk, the star, the wildcard,
to pull in everything that that Scapey module has
into my current namespace.
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 the IP,
this big class name, right,
you can see the capital letters there,
that's going to return a Scapey 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 it's that specific header
for that protocol.
I could zoom in on other things
other than Scapey or anything else.
And Scapey 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 could 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 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 Scapey uses
to actually add layers in
or kind of build them into
that packet that we're crafting.
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 send this packet,
I could receive the information that comes back,
maybe a little echo, a 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,
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.
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 Scapey,
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 Scapey can do.
Obviously, in this last slide,
we have a super duper small,
minuscule example of one thing
that Scapey 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.
Import and exports,
create graphs, reports, tables, etc., etc.
And obviously,
all of those specific different protocols
that we would 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 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.
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 whet 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
have a 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.
It 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 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.
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.
It could 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 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'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.
More so now,
you'll see other kinds of attacks
that are still this denial of service attack.
We're being a jerk.
We're overwhelming, flooding
and it's 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 SYN flood.
SYN flood is another denial of service
or DOS attack
which will make that server,
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 SYN 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 SYN 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 SYN ACK 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 ACK 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 SYN ACK packet,
it will wait and wait to receive
that ACK packet from the client
so that it can begin having this conversation.
So the attack is simple.
We just send a ton of SYN 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 ACK 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 acknowledgement.
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?
Scapey, 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 SYN flood.
We could just pass that to the function.
So I'm creating this SYN 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 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.
That'll return something to 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 wanted 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 SYN, right?
The SYN flag has been set on this packet.
So we have created one packet that is just a SYN 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 Scapey 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 enter or the interval,
we'll 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 SYN packet being sent
over and over and over again.
We are flooding that target victim server
with this SYN 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, okay,
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 use it as a SYN flood.
You might notice, though,
in this example, with this setup right here,
we're sending this SYN 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 could figure 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,
a 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, D-D-O-S.
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,
and attack 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 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.
Here, I'll just ask for anything regarding google.com
or that domain.
You could, of course, ask for any type
of 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 along.
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,
that DDoS, or send this request multiple times.
But I think this attack is really cool
and really interesting.
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.
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 this 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,
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 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, Scapey 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 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,
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 a 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
and 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, R to represent that RST
and A for ACK.
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,
is 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 the 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 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.
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
the most interesting thing here
is that path update variable
down at 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 have the source 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 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,
we fail.
It doesn't work.
Maybe our timing was off,
maybe the variables at 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.
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.
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.
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 like,
hey, I can't compute this.
I 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 ACK and acknowledgement.
And those two will get in a little bit
of an ACK war.
They'll be repeatedly sending
acknowledgements to one another.
And this will happen at least
until a timeout occurs
and the session will be disrupted.
It'll just shut down and stop.
And eventually 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've 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 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
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,
oversized packet?
That makes the most sense.
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.
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 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.
For DNS amplification attacks,
this one is almost,
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 DNSSEC, 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 BGPSEC, 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
track that.
If you are struck by
random 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,
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.
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 sources 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 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. 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
and more worthwhile stuff over
there. And if you're interested,
I do, 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'd 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.
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 through it a little
bit. Thank you. Thank you.
Thank you. This has been a
blast. I hope you enjoy the
talk and presentation. I hope
you enjoy DEF CON Safe Mode
and please stay safe and enjoy
yourself. Take care, everybody.
Thank you.