SAM BOWNE: So I'm Sam Bowne.
This is Matthew Prince.
I'm the attack side which in my opinion is the most fun
but the least practical.
He is the guy that can actually save you from all this garbage.
I just make trouble.
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 Chase.
I do not appear to be able to proceed to the next slide.
So I will make this smaller and see if that works.
I'm Sam Bowne.
I teach at city College of San Francisco.
This is Matthew Prince.
Can't see the slide.
SAM BOWNE: They had a problem with this before.
Guys, I have no video.
That's what I thought.
By the way, I'm going to need your help and tell me when
the video dies because I have to move to another machine later
and the system appears to be have some defects.
Do you see anything right?
Well, I can tell you a story.
I'm in contact with a lot of criminals which
is really great because I'm on Twitter and
they often tell me interesting information.
In fact, I recently hired a felon even though he is not
all that criminal.
So I gave a talk with Matthew here two years ago
about denial of service and I gave some criminal
attacks a criminal saw those and he said, I was checking
out your stuff and why do you teach BackTrack.
That stuff is garbage.
What are you lame?
And socks tress is a great attack.
I thought BackTrack was fine and I didn't know socks tress exist.
Remember five years ago they said there was
a new security attack that would kill eastbound that used HTTP routers
and we thought it was the end of world.
And then nothing.
I couldn't find the source code.
I thought that was just vaporware.
It was real but the man who wrote it died
before he could go to the CONs before he could do
a dog and pony show and show everybody how it works.
The black hats, some of them knew.
And this guy knew.
You can take down servers with sockstress and take it
down permanently is a claim I have seen many
people make.
And I think I understand what that means.
You could not take down a professional company.
Do I have slides?
Let me talk about how this works.
Here's how TCP works?
Slides!
SAM BOWNE: All right.
So TCP, TCP let's the receiver control
the flow of information.
So first you have to handshake to make sure the person is really there.
The server sends you a syn ak.
The data sends you 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 is good, right?
No.
SAM BOWNE: Died again?
Well, anyway, I'm going to have to keep going.
Hopefully did someone notice and doing something about it perhaps?
Onward we go.
Anyway ...
so there is 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 0.
What that means is I can only accept zero more bytes.
You have to stop sending me whatever you're
sending me and wait to get it working.
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 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 back syn ak but the syn ak has a window size
of the server.
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.
If you keep it up for 20 minutes in practice from real attackers.
It can damage the server so you have to pull the plug.
This is why the Blacks tell me that this will kill servers
and they're gone forever.
You can't kill Yahoo!
with a nuclear bomb.
They have backups.
So a professional place can't be taken down with an attack like this.
On an amateur site with shared hosting, you could kill it.
So we are trying again for video here which would be nice
because I have demos to show you.
The slides are more expendable than the demos.
Anyway, let me get down here.
That's the joy of Sockstress.
Well, life is tough.
(laughter).
I don't think it's me.
It's up.
He got it.
(applause).
They fixed something.
Good, great, thank you.
So you can see it now.
Life is good.
All right.
Can you see it now?
I'm glad I brought up the slide.
You have to use an old version of Slackware
to make this thing really go.
I kept saying this is garbage and the black hat said, No, it is not garbage.
You are just stupid.
He was right.
With enough work I got it working.
Let me show you this in all its glory.
I have some virtual machines here.
Okay.
And so here's my attacker and here's my target.
So (speaker off microphone.) SAM BOWNE:
Yeah, yeah.
I don't have a dog, ha.
All right.
Let me tell you something about this attack.
There are two parts to it.
Some of the software written by the people that designed this attack
didn't work for me.
I had to write it myself in Scapey.
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 listening on many ports
and you have to attack it from a whole botnet worth of I.P.
addresses.
But you can simulate it for testing vulnerability
on a LAN this way.
You run an art poisoning script here which will just tell anybody that asks
any I.P.
address is me.
So I can pretend to be 127 I.P.
addresses and it will just believe they're
all on this machine.
That's important.
That simulates the botnet.
And the attacker is over here.
This is a normal handshake with a size of zero but it sends it
from 126 possible I.P.
addresses and to about a dozen ports so it can really
make a lot of connections.
Let me get my target here.
And this looks good.
This is a Windows 2012 Server, the latest version, 64 bit,
and it has got 1 gig.
As you can see it is using about a third of a gig right now
and almost no CPU because it is 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.
You see this number of connections per second being made
going up to 2,000.
I have seen it get up to maybe 3 or 4,000 which you
will never see unless you use Slackware and there's the effect.
It just starts chewing up the available memory.
You can run it against a server with 4 gigs.
I have tried and I don't think there is a limit.
You can run it against as many gigs as you want and it will use
up all the RAM.
When the attack stops, that RAM does not come back any
time soon.
It just stays consumed.
If you wait until the RAM is all gone and let it keep going
for 120 minutes the server becomes unresponsive
and all you can do is pull out the plug.
It works over the Internet.
It is a layer 4.
It is really scary.
You can see under these conditions it has not taken
long to use up all the RAM I have got available.
Let me go back to my slides.
And we'll that would stop the attack.
As you can see the memory doesn't become
available again.
It seems to me this is a design flaw in the operating systems that
they could have a garbage collection process going on.
Almost any device that uses TCP is vulnerable
because nobody popularized this attack.
Everybody thought it wasn't real, the people I knew.
That's one thing you should know.
It is in current use by criminals to take down servers right now.
I'm not aware of anybody paying attention of how
to stop it.
It seems to me you can block packets
with small sizes at your firewall.
You could patch your operating systems in various ways.
It is time for people to pay attention to it.
I made a version of it that runs on Kali.
It runs at 1/3 the speed so it is not as dramatic but it is enough
to test defense tools.
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 I.P.
addresses a while ago.
It is a non renewable resource.
In about a year North America will run
out and more people should notice.
Projected ARIN data is April 2014.
IPv6 countdown counter.
(laughter).
As you can see we have got enough of them for a little while.
That's why we are trying to move forward on this.
That's live on my Web site, by the way.
You can catch it count down.
So I talked about this two years ago.
This has been around for a while.
This is the old, old fashioned attack from 2011.
In I.P.
version 4 if you want an I.P.
address, you boot up the laptop, get the I.P.
from the router and that's the end of the game.
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 are a little bit sloppy.
Every ping that receives that packet has to create an I.P.
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 numbers in only a few clock cycles
but Windows can only do five of these per second without using
up 100% CPI and that's true of one of the BSD versions.
It is a IPv6 packet going to FF02:1.
And it has a prefix telling it what network to join.
If you run this flood for a while, then your Windows machine will use
up a lot of CPU and that was the old attack in 2011.
Now that draws 100% CPU and no effect on Linux or Mac,
which 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 Web Server 2012 and the chaos communication
in Germany came out with a new version
of this attack tool.
The person that wrote the tool told Microsoft that Web server
2008 and Server 2012 were much more resistant to the flood.
This is something I found out because I have a student who
is nuts and set up a real IPv6 lab and a lot of real equipment
and would not stop he had everything going
the way it was to use it.
We found 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.
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
if you send a lot of those in, it is quite dramatic.
If you just turn on that flood alone and send it to Windows 8
and Web 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 I.P.
version 6.
So let me just demonstrate this thing.
It is good clean fun.
You can do this run from BackTrack.
Get rid of these unnecessary machines.
And this one.
All right.
Here's good old BackTrack.
And I have got a target here.
All right.
I'm going to show you the attacker and then I will move the cable
all to the target.
I don't know what will happen to the video.
I will need your help to tell me if the video dies.
So I am I have got a cable here.
I will pull this out.
This is very important, by the way.
This attack will kill a Mac.
It will kill the host underneath my VM.
That interferes with my testing.
The solution is to use a USB nick.
When you plug it in, 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, if it continues
to annoy me it asks me where to send it.
I can send the USB to Kali Linux which
is a good idea because the traffic that passes
through the Mac ethernet will be USB and it won't kill the Mac.
If it was using VMware networking and passing the network
through the host, it would kill the host.
So now that I have got networking in my virtual machine,
let's see what I have.
My config is deprecated.
I.P.
address shows eth1.
This is my connection to this Web 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 have got defco3o here.
I'm advertising a network starting with defco3o.
Let me show you what happens to the target.
Okay.
So hopefully let's see, this might work.
Hopefully you are now seeing a Web 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.
How about now?
Yeah!
SAM BOWNE: Oh, good.
That's good.
I appreciate your help.
Now, so I go to my glorious Power Shell window
which is the replacement for command prompt and do I.P.
config which is not deprecated, thank God.
If I can only spell.
Okay.
All right.
And now I have joined a network called def3oc3.
This machine is receiving IPv6 router advertisements
and obeying them.
Let me turn this around because it is facing you
because the next part is fun.
That's looking good.
It is not subtle.
So if you are seeing it from the back row,
the point should be clear.
I have joined a network and sending some router
advertisements and now I just send a flood which is as many packets
as it can possible send of those new router advertisements that
advertise 35 routes and prefixes each.
What happens is in about 30 seconds this thing should
die a gruesome death.
7, 8.
I can't see it.
I have to move this thing around.
All right.
Now, by the way just check it.
Okay.
Been about 15 seconds.
Now, the mouse moves but I.P.
addresses cannot change Windows in front.
I click and nothing happens.
Pretty soon the mouth won't move and then it dies
a horrible blue screen of death.
Anyway, that's what I wanted to show you.
Those are two scary attacks.
(applause).
SAM BOWNE: Oh, good.
Thank you.
I'm glad it worked.
So the that's kind of rude.
So my point is Microsoft has to go back to the drawing board.
They put out an update but the update works
for Windows 7 and Web server R2.
They didn't put it on 2012 or 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.
Try to record a YouTube video, it wouldn't work.
Then it would work.
He said it only works when the real router is on the network.
That's true.
I have tested it against Android phones including
the Mac.
Ubuntu sales right through.
Apple and Google could fix their junk.
It is possible to survive this attack.
You just ignore all the router advertisements
after the first 10 or so.
All right.
And I got a bunch of video showing you how to do it.
If you want to mitigate it, of course, you can 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 the existing mitigations
in the industry like RA Guard and Cisco switches are effective
but weak.
It is trivial to get past them.
All you have to do is put extension headers
on the router advertisements 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 is very flimsy.
Anyway ...
So I think that's enough of this.
And I'm going to pass it on to Matthew tell you
about defense and hopefully a few minutes to talk about cookies
at the end.
(applause).
MATTHEW PRINCE: Thank you, Sam.
Let's see if I can get video.
SAM BOWNE: Exactly.
Let me go take a look.
Nothing yet.
MATTHEW PRINCE: Give me one second.
How's that?
No?
Yeah, okay, let's try it one more time.
SAM BOWNE: This is the hardest part.
MATTHEW PRINCE: Apologize for this.
Any better?
SAM BOWNE: No.
MATTHEW PRINCE: I'm going to try changing the screen resolution.
(applause).
SAM BOWNE: There you go.
MATTHEW PRINCE: Just have to select scare it into behaving.
Okay.
So I gave this talk at Blackhat which was lessons
from surviving a 300 gigabyte denial of service attack.
And I don't know about all of you, but Blackhat is kind
of a dull conference.
(laughter) 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.
(applause).
MATTHEW PRINCE: So you don't have to be as smart as Sam
is it turns out to do this.
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 in one of our customers.
It was publicized in a media and it was Spamhaus which
we had a love/hate relationship with.
They do some good things and once upon a time I used
to be their lawyer.
On Monday, March 18th, this was what their Web site looked
like because they pissed off the wrong person.
They called us and signed up for CloudFlare and CloudFlare
is good at stopping some of these attacks.
From March 18th to March 21st we saw annoyance
attacks which is anything that sets off an alarm
in our system which takes about 10 gigs.
We got 156 of those last week.
We're pretty good at stopping attacks of this size.
To give you some scale, big DoS attacks that knocked
the banks offline was around 60 gigs.
These are not trivial attacks but this is pretty big.
This is what it looks like.
This is a couple ports on our network.
The blue line represents egress traffic out of our network.
It should always because we are
a caching proxy it should be higher than the green line.
This is ingress traffic coming into our network.
This is what a 75 gigabyte DDoS attack looks like.
There is no real software we write lots of cool software.
These are simply volume based attacks.
They are simply filling the pipe.
You're dead at layer 3 under one of these attacks and we do a lot
of things to stop it.
But it is not cleverness that stops it.
It is actually the size of the pipe that you have.
And unfortunately that means it is 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 309 gigabytes
per second.
That probably wasn't all of the traffic hitting our network
because some of it was congesting upstream
and causing problems.
And so those are UTC time.
On March 23rd, I was on a date in little restaurant on Fulsom Street
in San Francisco.
And I should have actually brought the woman 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 providers were
calling us saying, You have a problem, it is starting to become our problem.
And it sucked because I spent the entire time writing emails
and talking on the phone.
And as I will explain later, talking to lawyers makes any dinner suck.
One of my (laughter).
I'm a recovering lawyer so I can say that.
One of my favorite emails 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
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.
(laughter) MATTHEW PRINCE: This, by the way, if I ever call you
and am 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 is 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 botnets because they're sort of a pain
in the ass to build.
You don't need a lot of people 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
is something that's fairly easy to find these days and you need servers
running on network that allow I.P.
address spoofing and you don't need very many of these servers.
Let me describe what these two things are so I know a lot of you
in the audience have a sense but I want to make sure everybody
is on the same page.
What is an open DNS resolver.
This is not 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, you know, Google should be slightly ashamed
of the fact that, you know, how do you create
an open DNS resolver if you have an Android phone in your pocket
and you turn it on to WiFi as a WiFi sharing point.
It by default becomes an open DNS resolver.
So if you have a publicly routable I.P.
address, you have just contributed one more ingredient
to helping create these kinds of attacks.
There are a number of home WiFi devices that have
these things.
And then people who say, wow, it would be fun to install BIND
but don't set it up correctly can create
all kinds of problems.
So these are these misconfigured DNS servers running on the Internet.
I think of them as slutty DNS servers.
They respond to anything you send to them.
What you need to take down the Internet is amplification.
You only have certain resources and you need
to make those resources significantly better.
Here's how it works with open DNS resolvers.
So that I.P.
address, 63.217.84.76 as of, I don't know, noon today was
an open DNS resolver runs on PCCW's network.
There are a lot of these.
They are 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 it returns is it returns all of the resources.
So dissecting this query and returns any
of the DNS records that's there, EDNS equals zero means give me
all of the things like DNSSEC and everything else.
TCP says send it all over UDP and set your buffer size to 4096,
is the largest buffer you can set for a UDP packet, meaning give me
as much as you can.
It is a 64 byte query.
This is what it results in when you query it.
So that's a 3,363 byte response.
In other words, it is a 50X amplification factor.
You send a little bit up.
You get 50 times as much back at you.
The second thing that you need if you just if you are
like Sam and you just want to knock your own computers offline
all day, then you have 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 I.P.
address spoofing.
And as, you know, probably good networks and "good"
in quotations because we are on the dark side,
good networks don't let originating I.P.
addresses, they don't let egress out of their network.
They don't let them leave it.
This is BCP38.
BCP is 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 that don't follow
the best common practice and we will enumerate some.
Many networks are naughty, in other words.
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, cool.
As long as the router is on the network announcing that,
you can pretend to be anyone you want.
In other words, that's an I.P.
address on CloudFlare's network that Spamhaus 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,
what it is going to be is it will result in that response getting sent back
to the source.
In fact, you have reflected the attack back
at your intended victim and your attack is 50 times the size
of whatever volume you're able to generate.
If you can generate a gig of traffic, that means you can generate 50 gigs
of attack.
This is sort of similar to the old Smurf attacks
if people remember them.
IMCP packet that is are bounced off.
The good news with smurf attacks
because vendors were consolidated they could patch them.
You don't see many IMCP smurf attacks anymore.
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 will take a lot of exotic skill
a bunch of time?
Generally people are lazy so we want to make this easy.
The good news is for us 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 you would think four straight days of "New York Times" coverage might
get people cleaning this up and so this would be
a less effective attack.
What I'm happy to report is that today they're actually (laughter)
there are actually 28 million open resolvers.
(applause).
MATTHEW PRINCE: So have at it.
You can also with not much challenge, there is a little bit of protection
on the open resolver project.
You can sleeves put a/24 at a time and all kinds of things.
If you don't want to query the Internet because that's hard,
you can write a crawler to crawl the open resolver 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 we need to find a network that allows I.P.
address spoofing and Comcast and big eyeball networks, you
will 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 a MIT project,
do allow network spoofing.
So, again, 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 Spamhaus attack and we look at what was actually involved, 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.
Again, this is a really interesting thing.
At one point, they stopped targeting us
and targeted the London Internet Exchange,
which counts as infrastructure.
Which targeting it is a terrorist offense.
So those eyebrows, I love them.
(laughter).
MATTHEW PRINCE: So the Spamhaus ingredients,
how hard was it?
Again, what did this brain trust do?
Spamhaus generate 309 gigabytes for 28 minutes.
They use 30,956 open resolver I.P.
addresses and they only use three networks that
allowed spoofing.
So, again, not so tough, right?
So, in other words, there's one attacker with one laptop.
It actually turns out it wasn't the Sven guy,
but I can't tell you who it was which is sad because it is a great story.
There were five to seven compromised servers
on three networks that allowed spoofing.
They sent about 9 gigabytes of DNS requests to 0.1%
of the open resolvers and resulted in a 300 gigabyte per second attack that
was painful.
You can see, though, how there's opportunity here.
So create .2% and you are at 600 gigs.
Get up to 1% and you can send three terabytes.
8% and is 12 terabytes.
The entire U.S.
Internet backbone is 24 terabytes.
So someone may notice that.
(laughter).
And you don't need to necessarily like we are pain in the ass
to realize because we use Anycast and do things that make it tough.
The attack was against our I.P.
addresses at first.
But most people don't correctly configure their networks,
you can actually target intra networks.
You can actually address the I.P.s inside someone's network,
not just the edge.
Like, the London Internet Exchange, that's a routable I.P.
You can send the traffic to the choke points on the Internet
and it turns out that the biggest, baddest router that Juniper Cisco buys
has 100 gig ports.
How many of those can you take offline with a 12 terabyte attack?
So an alternative talk, which we could give, would be how
to stop Internet Armageddon.
Again, I gave some version of this at Blackhat.
Implement BCP38 if you are running a network, clean
up the open resolvers, clean up your upstream,
work with CloudFlare.
These are all good suggestions (laughter).
MATTHEW PRINCE: But frankly blah, blah, blah, blah, blah.
And so let's give something a little more DEF CONy.
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.
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 he said, we could just make all the open resolvers attack each other.
(laughter).
And so I called our lawyer.
(laughter).
We have a really cool lawyer.
Like, Sam Coates at Cooley is pretty good.
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 terabyte, it would have been interesting.
So we created this little C program called self destruct.c which, again,
the lawyers told me I can't give out the code but here it is.
(laughter).
(applause).
MATTHEW PRINCE: It's 50 lines of c.
It's nothing, right?
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.
And this is kind of the beauty of it.
You will break it in the meantime.
(laughter).
MATTHEW PRINCE: So, you know, use some discretion.
Anyway, thanks for having me, Sam.
It is always fun to give your talks.
I will let you talk a little bit more about cookie reuse.
(applause).
SAM BOWNE: 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 Matthew put something on the screen that
he really shouldn't show you because I'm really showing you stuff
that I really shouldn't show you.
Is it working?
No.
SAM BOWNE: Of course not.
Let's try Yes!
SAM BOWNE: Good.
So.
That's fine.
This only takes about three minutes.
I did this at Besides.
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.
Let me just show you what happens here.
I'm logged in.
This is Sam Bowne and there's stuff about my account.
And I'm going to take the cookie off of this site with this is chrome
and I got the extension that it is easy to get the cookies.
It is something called "get this cookie."
Now the cookie is in a clipboard.
I will log off.
And they would like me to click that button
as if it was actually doing something but it is not doing anything.
It's just there to waste my time.
The only thing it does is that Matthew comes up and uses
the computer he can't get into my account.
Now, if I try to go back to my Chase Manhattan
personalized page.
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!
(applause).
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 just tempting me to click it 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 American Express
page, hey, whoa, that's interesting.
This one timed out.
That's only fair.
These two credit card companies do a 10 minute timeout on the cookies.
I was trying to keep it alive down there, then you time out.
That's defense in depth.
They have multiple controls.
One compensates for a control that failed.
This is a bad idea.
The point that log out button should cancel the cookie
on the server.
When I click that button, my intention is 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 Web site.
I made some videos.
Gave these guys a week to fix it.
They told me they would get back in 24 hours and
they never got back to me.
I put it on YouTube and they never did something.
I said maybe if I show it at DEF CON they will fix it.
I tried a lot of sites.
There are a lot of good ones and a lot of bad ones.
I checked CloudFlare and they were vulnerable and
they patched it.
They do that pretty often.
(applause).
SAM BOWNE: The only person that has ever moved from the bad side
to the good side.
But, anyway, I'm hoping they will 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 that it's more that they don't care.
There is a lot of them.
One that really surprised me Gmail was not vulnerable.
Some other people tried other Google services.
And the Chrome app store is vulnerable.
I cloud is completely vulnerable.
Microsoft office 365, you can log out and then change your password
and wait till tomorrow and the old cookie still works.
So that is really rude because you know it is easy
to steal cookies.
My students to do it for homework.
It is better to have the cookie than the password.
This is wrong.
If you would like to help, please send in more reports.
Test Web sites, tweet them to me at Sam Bowne.
You can gain eternal fame like some other people.
I have a bunch of notes who tested it.
So we might as well make a list of shame.
I should mention, of course, it is not original.
It is not new.
This is the same thing fire sheep did.
Cookie reuse is an endless annoying problem that we
have to keep pounding on people.
I have five minutes left.
I have said everything I had to said.
I go he is we are done.
If you want to ask questions, meet us outside in the hall and we
will go find some place.
Okay.
Very well.
(Applause).