So I'm Sam Bowne, this is Matthew Prince, and we're going to talk about DOS attacks and defenses.
I'm the attack side, which in my opinion is the most fun, but the least practical.
He's the guy that can actually save you from all this garbage. I just make trouble.
So, um, and I'm hoping to have a few minutes at the end to show you something new about cookie reuse.
Hacking into American Express and, uh, Chase.
Chase. So, I do not appear to be able to proceed to the next slide, so I'm going to make this smaller and see if that works.
All right. So I'm Sam Bowne, I teach at City College of San Francisco.
There's Matthew Prince from Cloudflare.
You can't see, oh, the slides are gone?
Aha.
No, but that doesn't matter.
Does it come up?
Does it come up now?
That's what I thought.
They had a problem with this before.
Guys, I've got no video again.
I'll try pulling the plug out and putting it in again.
But that's what I thought.
Yeah, by the way, I'm going to need your help when you tell me when the video dies, because I have to move to another machine later.
And the system here appears to have some defects.
You see anything yet?
Right.
Well, I can tell you a story while they get the video going.
I'm in contact with a lot of criminals now, which is really great, because I'm on Twitter.
Right.
And they often tell me interesting information.
In fact, I recently hired a felon, although he's not that criminal.
But anyway, so I gave a talk two years ago at Matthew here about denial of service attacks, and I gave some similar talks.
And a criminal someplace saw those, and he said, hey, I was checking out your stuff.
And in the first place, why do you teach backtrack?
That stuff is garbage.
What are you, lame?
And in the second place, where's Sockstress?
Sockstress is a great attack, and you don't cover it.
And I said, I thought backtrack is fine.
And I thought Sockstress didn't even exist.
You may not even remember.
Remember this?
Like five years ago, there was a podcast, and they said there was this new scary attack that would kill anything that used TCP routers and servers and everything.
And we thought it was the end of the world.
And then nothing.
I hunted for the source code.
I couldn't find anything that worked.
I thought that was just vaporware.
Well, what happened is it was real, but the man that wrote it died before he could go to the cons and make a dog and pony show like I proposed to do and show everybody how it works.
And the black cats, some of them knew, and this guy knew.
And you can totally take down servers with Sockstress, and you can take them down permanently with Sockstress, is a claim I've seen many people make, and I think I understand what that means.
You could not take down a professional company.
Do I have the slides now?
Thank you.
Good.
All right.
So let me talk about how this works.
If you have ‑‑ here's how TCP works.
TCP ‑‑ okay.
All right.
So TCP, you have ‑‑ TCP lets the receiver control the flow of information.
So first you have the handshake.
To make sure that the person is really there.
They send a SYN up to the server.
The server sends you a SYN ACK.
Then you send an ACK.
Then the server starts sending you data.
It sends you some packets of data, and it waits for you to acknowledge them.
So if your client is slow, it can control the rate of flow.
So that's one form of flow control.
It's good, right?
Died again?
Oh.
Well, anyway, I'm going to have to keep going.
Hopefully, if someone noticed I'm doing something wrong, I'm going to have to keep going.
There's something about it, perhaps.
Onward we go.
Anyway, so there's another form of flow control in TCP, which is not commonly used, but it exists.
You can send a packet with a window size of zero.
And what that means is I can only accept zero more bytes.
You have to stop sending me whatever you're sending me and wait for me to get it working.
And that is available so your client can say I have a buffer and my buffer is full.
Stop sending me whatever you're sending me until I can clear that out.
But you can use it as an attack.
And that's what Sockstress does.
All you do is the TCP handshake.
You send a SYN to the server.
The server sends you a SYN ACK.
You send an ACK.
But the ACK has a window size of zero.
And that means the server will start a process and prepare some memory to send you something and then wait.
And in practice, it will wait for a really long time.
So all you have to do is make a lot of those connections and use up all the RAM on the server.
And if you keep it up for about 20 minutes, in practice, it will wait for a really long time.
If you do this from real attackers against real servers, it will damage the server so much that it freezes and you cannot shut it down normally.
You have to just pull the plug.
And I think this is why the black hats tell me that this will kill servers and they're gone forever.
Now, you couldn't kill Yahoo with a nuclear bomb.
You blow up a whole data center.
They have backups.
They have other servers.
So a professional place cannot be taken down by any kind of attack like this.
But with an amateur site on a shared hosting,
you could kill it.
So we're trying again for the video here.
It would be nice because I definitely have some demos to show you.
The slides are more expendable than the demos.
Anyway, so let me go down here and see.
All right.
That's the joy of Sockstress.
Yeah, I can start the show this way.
It's still no projector, right?
Well, life is tough.
So I don't think it's me.
Oh, he got it.
You did?
Okay.
They fixed something.
Good.
Great.
Thank you.
All right.
Just leave it like that.
All right.
So you can see it now.
All right.
So anyway, I still cannot move from one slide to the next, though.
Let's see.
Can you see it now?
Okay.
Good.
Then we'll keep going.
All right.
So the only thing ‑‑ I'm glad I brought up the slide to remind me of this.
You have to use an old version of Slackware to make this thing really go.
And it took me a lot of tries.
And I kept saying this is garbage.
And the black hat kept taunting me saying, no, it's not garbage.
You're just stupid.
And he was right.
So with enough work, I eventually got it working.
So let me show you this thing in all its glory.
I've got some virtual machines here.
And not that.
But this here.
Okay.
And so here is my attacker.
And here is my target.
So ‑‑ all right.
Yeah.
Yeah.
I don't have a dog.
Ha!
So ‑‑ all right.
Now, let me tell you something about this attack.
There are two parts to this attack.
And that is one of the reasons why I had such trouble doing it.
Because some of the software written by the people that designed this attack didn't work
for me.
I had to write it myself and scape you.
This is art poisoning of a very simple kind.
Your target ‑‑ to get the effect that's really cool where you kill a target dead,
the target has to be lit up.
And you have to attack it from a whole botnet worth of IP addresses.
But you can simulate it for ‑‑ you know, for testing vulnerability on land this way.
You run an art poisoning script here which will just tell anybody that asks that any
IP address is me.
So I can pretend to be 127 IP addresses and it will just believe they're on this machine.
That's important.
That simulates the botnet.
And the attacker is over here.
And this is just going to send a lot of those handshakes I described.
It's a normal handshake except it ends with a window size of zero.
But it sends it from 126 possible IP addresses and to about a dozen ports.
So it can really make a lot of connections.
So let me get my target here.
And this looks good.
This is a Windows 2012 server, the latest version, 64‑bit.
And it's got one gig.
And as you can see, it's using about a third of a gig right now.
And almost no CPU because it's just sitting there.
So when I start this attack.
Let me get to my right window.
Okay.
Let's have these as visible as possible.
Okay.
The attack is here.
Okay.
Now you see this number of connections per second being made going up to 2,000.
And I've seen it get up to maybe 3,000 or 4,000, which you will never see unless you
use Slackware.
And there is the effect.
It just starts chewing up all the available memory.
And you can run it against the server with four gigs I've tried and I don't think there
is any limit.
You can run it against as many gigs as you want.
And it will just use up all the RAM.
And when the attack stops, that RAM does not come back any time soon.
It just stays consumed.
And if you wait until the RAM is all gone and just let it keep going for another 10
or 20 minutes, the server becomes completely unresponsive.
And the only thing you can do is pull out the plug.
And this works over the Internet.
It's a layer 4 attack.
So that's why it's really scary.
That's the first one I wanted to show you.
And you can see under these conditions, it's not taking very long to use up all the RAM
I've got available.
So let me go back to Slackware.
Back to my slides.
And we'll ‑‑ here's some before where I'd fill it up and stop the attack.
And as you can see, the memory doesn't become available again.
So it seems to me that this is a design flaw in the operating systems that they could have
some kind of garbage collection process going on.
But anyway, almost every device that uses TCP is vulnerable because nobody ever did
popularize this attack.
And we all ‑‑ as far as everybody I knew thought it wasn't real.
So that's one thing you should know about.
It is in current use by criminals to take down servers right now.
And I'm not aware of anybody paying much attention to how to stop it.
It seems to me like there are reasonable mitigations available.
You could just block packets with small window sizes at your firewall.
That might be fine.
You could patch your operating systems in various ways.
But it's time for people to pay some attention to it.
And you can ‑‑ I made a version of it that runs on Kali or I found you can pretty
easily do that now.
It runs at one‑third the speed so it's not as dramatic.
But it is enough to test defense tools.
So I'd like to see people pay attention to it.
Anyway, the other thing I wanted to show you is the latest IPv6 attack.
Which is good, clean fun.
As we all know, we ran out of IP addresses a while ago.
It's a non‑renewable resource.
In about a year, North America will run out and more people should notice.
Projected error and exhaustion date is here, April 2014.
IPv6 address is going to last a long time.
I made an IPv6 countdown counter.
As you can see, we got enough of them for a little while.
So that's why we're trying to move forward on this.
That's live on my website, by the way.
You can watch it countdown.
Anyway.
So I talked about this two years ago.
This has been around for a while.
This is the old, old, old‑fashioned attack all the way from 2011.
So in IP version 4, if you want an IP address, you boot up a laptop, it asks the router for
an IP, gets an IP, and that's the end of the game.
But in IPv6, you send router advertisements from the router and they are sent multicast
to all nodes, which is what a normal person would call broadcast if they were just a little
bit sloppy.
And everything that receives that packet has to create an IP address and join the network.
Which amounts to the same thing under normal conditions.
But if you send a lot of router advertisements, the clients are all burdened by making up
a lot of addresses and joining a lot of networks, which burdens them far more than any sensible
person would think.
I would think making up a number is only a few clock cycles.
But you can only ‑‑ Windows can only do five of these per second without using
up 100% CPU.
And that is also true of one of the BSD versions.
So the router advertisement packet is just an IPv6 packet going to FF02 colon, colon,
colon, and it's got a prefix in there telling it what network to join.
So if you run this flood for a while, then your Windows machine will join all these networks
and make a lot of IP addresses and it will use up a lot of CPU.
And that was the old attack in 2011.
Now that drives Windows to 100% CPU and had no effect on Linux or Mac, which just ignored
all the advertising after the first ten addresses or so.
And Microsoft ‑‑ all right.
That was the old flood.
And so then Microsoft came out with Windows 8 and Server 2012, and the chaos communication
Congress in Germany came out with a new version of this attack tool.
But the person that wrote the tool told Microsoft that Windows Server 2008 and Server 2012 were
much more resistant to the flood.
And this is something I only found out because I have a student who is kind of nuts who
set up a real IPv6 lab and a lot of real equipment and would not stop until we had everything
really going the way it really is to use it.
And we found things.
Things that only happen under those conditions.
So now this is the new version of the tool.
Each router advertisement packet can advertise more than one router.
I don't know why, but they allow it.
So now it allows ‑‑ it now advertises 17 routes and 18 prefixes in every packet.
So every one of those packets is like 35 of the previous ones.
And if you send a lot of those in, it's really quite dramatic, but if you just turn on that
flood alone and send it to Windows 8 and Windows Server 2012, it doesn't do much.
There is some kind of defense built into them.
But it doesn't work if you're actually using IPv6.
So let me just demonstrate this thing.
It's good, clean fun.
You can do this one from backtrack.
Let me get rid of these unnecessary machines.
And this one.
All right.
Here's good old backtrack.
And I've got a target here.
All right.
I'm going to show you.
I'm going to show you the attacker and then I'm going to move the cable over to the target
and the Lord only knows what's going to happen to the video.
I will need your help to tell me if the video dies.
All right.
So I am ‑‑ I've got a cable here.
I'm going to pull this out.
This is very important, by the way.
This attack will kill the Mac.
It will kill the host underneath my VMs.
Now that kind of interferes with my testing.
So the solution is to use a USB NIC.
When you plug in the USB NIC, you get this happy message popping up or so I would like
to see.
Asking me where it goes.
To get out to my Mac and plug it in again and if it continues to annoy me ‑‑ there
we are.
It's asking me where to send it.
I can send the USB directly to Kali Linux which is a really good idea because the traffic
that passes through the Mac operating system will not be Ethernet.
It will be USB and therefore it won't kill the Mac.
If it was using VM or networking and passing the networking through the host, it would
kill the host.
All right.
So now that I've got ‑‑.
So now I'm networking in my virtual machine.
Let's see what I have.
IP address show, I have config is deprecated.
I'm attempting to learn to quit using it.
Okay.
IP address show, ETH1.
This is my connection to this Windows Server 2012 machine.
So to make this attack work, you have to send some packets first.
I'm going to put a zero here.
I've got DEF CO30 here.
So now I'm advertising a network starting with DEF CO30.
And let me show you what happens to the target.
Okay.
So hopefully ‑‑.
Let's see.
This might work.
Yeah.
Hopefully you are now seeing a Windows Server 2012 desktop.
Is it happening?
It's, of course, not happening.
I don't think it's necessary.
But I will give it a try.
It's not a 5 on this one.
Windows, it's Windows P?
No.
Okay.
Now there.
Control P.
Duplicate.
All right.
How about now?
Oh, good.
All right.
That's good.
I appreciate your help.
Now, so I go to my glorious PowerShell window, which is the replacement for command prompt,
and do IP config, which is not deprecated.
Thank God.
Okay.
If I can only spell.
Okay.
All right.
And now I have joined a network called DEF CO30.
So this machine is receiving IPv6 router advertisements and obeying them.
And now, let me turn this thing around so it faces you, because the next part is fun.
And it is ‑‑ that's looking pretty good.
Thank you.
All right.
And it is not subtle.
All right.
So now I have joined a network, and I'm sending some router advertisements.
And now I just send a flood, which is as many packets as it can possibly send of those
new router advertisements that advertise 35 routes and prefixes each.
And what happens is, in about 30 seconds, this thing should die a gruesome death.
And 7, 8.
And I can't see it.
I'm going to move this thing around.
All right.
All right.
There's not ‑‑ by the way, let me just check it.
Okay.
In about 15 seconds, now the mouse moves, but I cannot change what window is in the
front anymore.
I click and nothing happens.
Pretty soon the mouse won't even move.
And then it dies a horrible blue screen of death.
So, anyway.
That's what I wanted to show you.
Those are two scary attacks.
This one means the ‑‑ oh, good.
Thank you.
All right.
Good.
All right.
I'm glad it worked.
So the ‑‑ that's kind of rude.
And so my point is Microsoft has to go back to the drawing board.
They put out an update.
But the update only works for Windows 7 and Windows Server 2008 R2.
They did not put the IPv6 readiness update on Server 2012 or Windows 10.
Windows 8 because they thought it was not vulnerable.
But it is under the right conditions, which I really owe that to a student.
I was just going out of my mind.
It would work sometimes.
I would try to record a YouTube video.
It didn't work.
Then it would work and say what's going on here?
He said it only works when the real router is on the network, and that's true.
Anyway.
So that's what happens.
I've tested it against a lot of things like Android phones and the Windows service RT,
and it kills pretty much everything, this IPv6 attack, including the Mac.
Ubuntu sails right through.
Like nothing is happening at all.
So it is possible to fix it.
Apple and Microsoft and Google and everybody can fix their junk and be like Ubuntu Linux.
It's possible to survive this attack.
You just ignore all the router advertisements after the first ten or so.
All right.
And I've got a bunch of videos showing you how to do it.
And if you want to mitigate it, of course, you could turn off IPv6, but that's not very
practical anymore.
And you could filter this with your switch or your router or your firewall.
Only let router advertisements come through from trusted sources.
I should mention that the existing mitigation is not the only way to do this.
There are other applications in the industry like RAGuard and Cisco switches are effective
but very weak.
It is trivial to get past them.
All you have to do is put some extension headers on the router advertisement packets and the
switch will not recognize them anymore and let them go right through.
So that's true of almost the first generation of every security device.
It's very flimsy.
Anyway.
So I think that's enough of this.
And I'm going to pass it on to Matthew to tell you about defense.
And hopefully have a few minutes to talk about cookies at the end.
Sure.
Thank you, Sam.
Let's see if I can get a video.
Give me one second.
How's that?
No.
Yeah.
Okay.
Let's try it one more time.
I apologize for this. Any better? I'm going to try changing the screen resolution.
Just have to select ‑‑ scare it into behaving. Okay. So I gave this talk at Black Hat which
was Lessons from Surviving a 300 Gigabit Denial of Service Attack. And I don't know about
all of you, but Black Hat is kind of a dull conference. So I wanted to sort of retool
it and Sam has been telling me that it's a lot more fun to attack than defend. So in
that spirit, I thought I would teach you how to break the Internet.
.
So you don't have to be as smart as Sam is to do this, it turns out. And we actually
went through a practice run of this a little while ago. So back from March 18th to March
25th, I had a series of really bad days. There was a series of very high volume denial of
service attacks targeting one of our customers. This was fairly well publicized in the media.
And it was a little organization called Spam House which we have a sort of love‑hate relationship
with. But they do a lot of good things. And actually once upon a time I used to be their
lawyer. So when ‑‑ on Monday, March 18th, this was what their website looked like. Because
they had pissed off the wrong person. They called us and signed up for CloudFlare. And
CloudFlare is good at stopping some of these attacks.
And so from March 18th to March 21st, we saw a lot of what we call annoyance attacks.
And annoyance attacks for us are anything that sets off an alarm within our system which
takes about 10 gigs. We got about 156 ‑‑ we got 156 of those last week. We're pretty
good at stopping attacks of this size. But to give you some scale, big DDoS attacks that
knocked the U.S. banks offline last fall were around 60 gigs. So these are not trivial attacks.
But they are ‑‑ that's pretty big. This is what it looks like. This is a couple of
ports on our network. The blue line represents egress traffic out of our network. It should
always ‑‑ because we're a caching proxy, it should be higher than the green line. The
green line is ingress traffic. This is traffic coming into our network. This is what a 75‑gigabit
DDoS attack looks like. There's no real software that we have to ‑‑ we
write lots of cool software and do lots of things. But these are simply volume‑based
attacks. And so they are simply filling the pipe. You're dead at layer three under one
of these attacks. And we do a lot of things to stop it. But it's not clear. We're not
cleverness that stops it, it's actually the size of the pipe that you have.
And unfortunately that means it's really hard to patch.
And so then it got real.
So from March 24th to March 25th, this is traffic coming into our network that got up
to about the peak, about 309 gigabits per second.
That probably is not all of the traffic that was hitting our network because some of it
was actually congesting upstream and causing problems.
And so the ‑‑ those are UTC time.
On March 23rd, I was on a date at a little restaurant on Folsom Street in San Francisco
and I should have actually brought the woman that I was on a date with to tell you how
much dinner that night sucked.
But it sucked in a lot of different ways.
It sucked because our team was calling us.
It sucked because our upstream was calling us.
Our upstream providers were calling us saying, you know, you have a problem and it's starting
to become our problem.
And it sucked because I just spent the entire time writing e‑mails and talking on the
phone and, as I'll explain later, talking to lawyers, which makes any dinner suck.
One of my ‑‑ I'm a recovering lawyer so I can say that.
One of my favorite e‑mails from that period of time came from a network engineer at Google
who I'm friends with.
And he wrote the following.
He said, I've often said, I don't know.
He said, we don't have to prepare for the largest possible attack.
We just have to prepare for the largest attack the Internet can send without causing massive
collateral damage to the others.
It looks like you've reached that point so congratulations.
This, by the way, if I ever call you and I'm freaking out, is not a comforting
message.
So you know, again, since we think that we've decided that we're going to be the bad guys,
not the good guys.
And it's fun to destroy things, not create them, I want to tell you exactly what you
need to launch this attack because all of you can do it probably from here.
What you don't need are bot nets because they're sort of a pain in the ass to build.
You don't need a lot of people, you know, coordinated anonymous attacks are relatively
trivial compared with some of the things we see.
You also don't need a ton of technical skill in order to launch this.
Instead, what you need is a list of open DNS resolvers and this has become something that
is actually fairly easy to find these days.
And then you need some servers running on networks that allow IP address spoofing and
as you'll see you don't actually need very many of these servers.
So let me describe what these two things are just so, again, I know a lot of you in the
audience have a sense of how this works but I want to just make sure that everyone is
on the same page.
So what is an open DNS resolver?
This is not like open DNS the company, they're a great company, they have great limits and
things in place.
This is not like Google DNS.
This is misconfigured DNS resolvers which are running on the network and Google DNS has
great limits.
So you can't abuse it in this way.
But Google should be slightly ashamed of the fact that how do you create an open DNS resolver?
If you have an Android phone in your pocket and you turn it on to Wi‑Fi as a Wi‑Fi
sharing point, it by default becomes an open DNS resolver.
So if you have a publicly routable IP address you have just contributed one more ingredient
to helping create these kinds of attacks.
There are a number of home Wi‑Fi devices that have these things.
And then people who say, wow, it would be really fun to install bind but don't set it
up correctly can create all kinds of problems.
So these are these misconfigured DNS servers that are running on the Internet.
I think of them as slutty DNS servers.
They respond to anyone and anything that you send to them.
And the effect of this, what you really need if you're going to take down the Internet
is you need amplification because you only have certain resources and you need to make
those resources significantly better.
So here's how it works with open DNS resolvers.
That IP address, 63.217.84.76, as of, I don't know, noon today, was an open DNS resolver
running on PCCW's network.
There are a lot of these.
They're not hard to find.
This is just a DNS query.
For those of you who are Windows people in the audience, one, I'm sorry.
And two, this is sort of the equivalent of NS lookup.
And so what this returns is it returns all of the resources.
And so dissecting this query, any says return.
Return any of the DNS records that's there.
EDNS equals zero means give me all of the things like DNSSEC and everything else.
Not TCP says send it all over UDP and then set your buffer size to 4096 is the largest
buffer that you can set for a UDP packet, meaning give me as much as you can.
It's a 64 byte query.
This is what it results in when you query it.
So that's a three.
3,363 byte response or in other words, it's a 50X amplification factor.
You send a little bit up, you get 50 times as much back at you.
So the second thing that you need ‑‑ if you're like Sam and you just want to knock
your own computers offline all day, then you've got everything you need at this point.
If on the other hand you want to attack other people's networks, then what you need is a
network that allows source IP address spoofing.
And as you know, probably good networks ‑‑ good in quotation marks because we're on the
dark side now.
But good networks don't let packets that originate from IP addresses, they don't own egress out
of their network.
They don't let them leave it.
This is something called BCP38.
BCP stands for best common practice.
It has been the best common practice since the early 2000s.
Good for us, again.
There are a lot of networks, however.
Don't follow the best common practice and we'll specifically enumerate some in a second.
Many networks, in other words, are naughty.
And UDP has no handshake.
So unlike TCP, which is really hard to spoof the source addresses of, with UDP you simply
say, the source is this.
And everyone goes, yeah, that's cool.
And so long as the routers on the network are announcing that, then you can pretend
to be anyone you want.
So in other words, that's an IP address that's on Cloudflare's network that Spamhouse, again,
as of noon today sat behind, although it moves around.
If you run that dig.
And, again, you set it to no TCP, which means UDP only, then what it's going to be is it's
going to result in that response getting sent back to the source.
In fact, you've reflected the attack back at your intended victim and your attack is
50 times the size of whatever volume you're able to generate.
So if you can generate a gig of traffic, then that means you can generate 50 gigs of attack.
This is sort of similar to the old Smurf attacks, if people remember that.
That's ICMP packets that are bounced off that.
The good news with the Smurf attacks is that.
Because router vendors were relatively consolidated, they could patch them, and it's really hard.
You don't see many ICMP Smurf attacks anymore.
But because any idiot can install bind and misconfigure it, this is a significant problem.
So how common are these particular ingredients?
Like is this something that's going to take a lot of exotic skill and a bunch of time
and generally people are lazy, so, you know, we want to make this easy.
The good news is for us is that as of the time of the attack.
There were about 21 million of these open resolvers running across the internet.
In fact, not coincidentally, on March 25th, the open resolver project was launched.
It was essentially the nuclear option for the good guys which said, we've always been
terrified of publishing the list of open resolvers because then the bad guys will have
them.
Over the last weekend it became completely clear the bad guys do have them, so damn
the torpedoes.
So damn the torpedoes.
Damn the torpedoes.
Damn the torpedoes.
The New York Times coverage might get people cleaning this up, so this would be a less
effective attack.
What I'm happy to report is today there are actually 28 million open resolvers.
So have at it.
You can also with not much challenge ‑‑ there's a little bit of protection on the
open resolver project.
Like you can only put a slash 24 at a time and all kinds of things.
If you don't want to query the internet because that's hard, you can actually write a crawler
to crawl the open resolver project.
project and pull down the list of open resolvers. So there you go.
The other piece, and this is a little bit harder to find, is that, you know, you want
to see ‑‑ you need to find a network that allows IP address spoofing and Comcast
and big eyeball networks. You're going to have to look around a little bit. But the
good news, again, is that almost 25% of networks AS numbers surveyed on the Internet of 10%
that have been surveyed so far, this is according to an MIT project, do allow network spoofing.
So, again, you know, talk to your neighbors. Chances are one of you is running on a network
that allows this to happen. So, you know, if we go back to a case study
of the spam house attack and we look what was actually involved, so first of all, again,
if you're fearing that you don't have the technical skills involved to launch this,
this is one of the individuals that was involved with it. Not exactly a brain trust. My evidence
that he wasn't a brain trust is he talked on record to the New York Times about launching
a giant denial of service attack.
And, again, this is a really interesting thing. At one point they stopped targeting
us and they started targeting actually links, the London Internet Exchange, which counts
as critical infrastructure, which means targeting it is like a terrorist offense. So those eyebrows,
I love them. So the spam house ingredients, how hard was
it? Again, what did this brain trust do? Spam house, they generate 309 gigabits for
about 28 minutes. They used 30,956 megabytes.
They only used three networks that allowed spoofing. So again, not so tough, right? So
in other words, there was one attacker with one laptop. It actually turns out it wasn't
the Sven guy, but I'm not allowed to tell you who it actually was, which is sad because
it's a great story. There were five to seven compromised servers on three networks that
allowed spoofing. They sent about nine gigabits of DNS requests. So they have to be kind of
beefy servers. To 0.1 percent of the open resolvers and they resulted in a 300 gigabit
per second attack that was painful. You can see, though, how there's opportunity
here. So create 0.2 percent and you're at 600 gigs. Get up to 1 percent and you can
send three terabits. 8 percent and you're at 12 terabits, which may not sound like a
lot except for that the entire U.S. Internet backbone is 24 terabits. So someone may notice
that. And you don't need to necessarily ‑‑ like, we're a pain in the ass to target as
they realize because we use Anycast and we do a bunch of things that make it really tough.
So first the attacks were launched against our IP addresses. But because most people
don't correctly configure their networks, like, you can actually target internal routing
infrastructure, intranetwork, so you can actually address the IPs inside someone's network,
not just the edge. Like, here's the London Internet Exchange. That's a routable IP. So
you could just send the traffic directly ‑‑
Yeah.
‑‑ directly to the choke points on the Internet. And it turns out that, again, the
biggest, baddest router that Juniper or Cisco buys only has 100 gig ports. So how many of
those can you take offline with a 12 terabit attack?
So an alternative talk which we could give would be how to stop Internet Armageddon.
And again, you know, I gave some version of this at Black Hat. You know, implement BCP38
if you're running a network, clean up the open resolvers, work with your upstream, sign
up for Cloudflare. These are all good suggestions.
But frankly, blah, blah, blah, blah, blah. And so let's give something a little more
DEF CON-y. So I want to return to dinner on March 23rd, which, again, sucked. And on
March 23rd, I got a bunch of calls, got a call from a bunch of different people. And
at one point I got a call from one of the people on our systems engineering team, and
they said, I have a solution. And I said, oh? And they said, you know, I have a solution.
And they said, we could just make all the open resolvers attack each other.
And so I called our lawyer, which is ‑‑ and we have a really cool lawyer. Like, Sam
Coates at Cooley is pretty good. And I can't exactly tell you what his advice was. It wasn't,
yeah, absolutely. Go for it.
But it wasn't exactly no, under no circumstance, you should do it. And thankfully, the attack
didn't get much bigger, and we could stop a 300 gig attack. But if it had gotten to
a terabit or something which would have started to cause a problem, it would have been interesting.
And so we created this little C program called selfdestruct.C, which, again, the lawyers
have told me I can't give out the code, but here it is.
It's 50 lines of C. It's nothing, right? And so, you know, again, I don't necessarily
want to actively challenge you to solve this problem yourself. But if you decide that you
want to, in about 50 lines of C, you may save the Internet. But ‑‑ and this is
kind of the beauty of it, you will break it in the meantime. So, you know, use some discretion.
Anyway, thanks for having me, Sam. It's always fun to give your talks, and I'm going to let
you talk a little bit more about cookie reuse.
Great. Well, good. I'm glad we're managing on the time, despite the technical difficulties,
because I have another thing to show you, and I'm glad that Matthew just put something
on the screen that he really shouldn't show you, because I'm really showing you stuff.
That's why I really shouldn't show you. Is it working? Of course not. Okay, good. That's
fine. This only takes about three minutes. I did this at B-Sides, and my talk is not
online yet because they're worried they need to blur it out before they can publish it.
This is my Chase Manhattan credit card statement. I'm logged in for my online banking. And let
me just show you what happens here. So I'm logged in. This is Sam Bown and there's stuff
stuff about my account. And I'm going to take the cookie off of this site. This is Chrome
and I've got an extension here that makes it easy to get the cookies. It's called something
like get it this cookie. There's a bunch of them. So now the cookie is in the clipboard.
So now I'm going to log off. Now there's a nice red log off button there. And they would
like me to click that button as if it was actually doing something. But it's not doing
anything. It's just there to waste my time. The only thing it does is if Matthew comes
up and uses my computer, he can't get in my account. But I can totally get back ‑‑ so
now if I try to go back to my Chase Manhattan personalized page, it won't let me in. It
says you have to log in, which was what I wanted to accomplish by clicking that log
off button. But I did not accomplish it. Because if I just put the cookie back in,
which is there, and then try to go to that link, I'm back in my account, authenticated,
without my password.
Now, this is wrong.
And by the way, since everything is working, here's American Express, and the same thing
is true. If I export the cookie from American Express and then I hit that log out button,
again, just tempting me to click it as if that was going to protect my security in some
way. And then I bring the cookie back. And then I go back to my personalized page. So
American Express page. Hey, whoa, that's interesting. Okay, this one timed out on me.
And this is good because it's only fair. These two credit card companies do have a 10-minute
timeout on the cookies and on other log. If you don't do anything for 10 minutes,
I was trying to keep it alive down there, then you're timed out. So that's defense in depth.
They have multiple controls. One of them compensates for a control that failed. But
anyway, I just wanted to point this out. This is a bad idea. That log out button should cancel
the cookie on the server. When I clicked that button, my intention was that nobody should get
in here again from this device without a password. So I started testing other ones. This came from a
Hacker News article. Everything is on my website, samsclass.info. And here's the cookie reuse stuff.
So I made some videos. I gave these guys a week in secret to fix it. They promptly told me they
would get back to me in 24 hours and then never did. And never did anything. So I put it on
YouTube. And they still did nothing. So I said, well, maybe if I show it at DEF CON, maybe they'll
do something. Or maybe they'll just continue to ignore me. But anyway, I tried a lot of
software. I tried a lot of software. I tried a lot of software. I tried a lot of software.
And there's a lot of bad ones and a lot of good ones. Anyway, so I checked CloudFlare and they
were vulnerable. So I told them. And they patched it. And what I asked them to do, yeah, they do
that pretty often. They're the only person that has ever moved yet from the bad side to the good
side. But anyway, I'm hoping they'll write a blog explaining to these other persons of
questionable efficiency how to do it. Because it's perhaps that they don't know how to do it.
I'm afraid it's more that they don't care. But anyway, there's a lot of them.
And one that really surprised me, I did Gmail. And Gmail was not vulnerable. So I didn't
try other Google services. But some other people did and told me about it. And the Chrome
app store is vulnerable. And so iCloud is completely vulnerable. And by the way, Microsoft
Office 365, you can log out and then change your password and wait until tomorrow and
the old cookie still works. So that is really rude. Because you know it's
easy to steal cookies. My students do it for homework. Cross-site scripting, you steal
the cookie. And it's better to have the cookie than the password because they can change their
password. Ha, ha, ha. You keep using the cookie. This is wrong. Anyway, so if you'd
like to help, please send in more reports. Test websites. Just tweet them in to me. I'll
put you on the list. You can gain eternal fame like some other people have tested. I
have a bunch of notes down here who tested it. So we might as well make a list of shame.
I should mention, of course, this is not original. It's not new. This is the same thing Fire
Sheep did and a million other things before that. I mean, cookie reuse is just one of those
endless annoying problems like plain text login.
Yeah, so I've got five minutes left. I think I've said everything I had to say. I guess
we're done. And they said if you want to ask questions, just meet us outside in the
hall and we'll go find someplace. Okay. Farewell.