Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/639 Thanks!
And the next talk is about
the drone attack.
It's secured, I said it will
be fun, he said, and smash it with a
computer camera.
So my Ascension Sentience has been
interested in I.T.
security since a long time.
His sir PHC at their
prime minster.
And you may recall his talks
back at thirty one.
Twenty eight or
even twenty nine.
C three.
Today he will talk about the drone attack
and how to attack
s. By making use of a server
that supports s us ldv to please
Volcom with an anniversary edition.
Applause substantial into.
OK, so thank you very much for the
introduction.
It's great to be back.
And I'm very glad that no one is leaving
right now because we're presenting
a new vulnerability.
And it's a celebration, too, right?
That is kind of old.
The attack has a name.
It has a Web page and it has even a logo.
And having said that, I am really glad
that no one's leaving the
room right now as well.
The talk will be unbreaking tearless.
And so pretty much everyone here in this
room uses tearless,
probably at this very at this very
moment while your mobile
phone is checking whatever is
going on on Twitter or Facebook.
So over HDP s or you're checking your
emails and stuff like that.
Right.
So.
So tell us this.
It's really important.
The drone attack has 15 offers and
they obviously couldn't.
Couldn't all come here.
The six of us here is like the
most people that got on
on like on
on on a single picture.
And if you look closely, we are very
happy to have received the
first PONI award
for the best cryptographic attack in
2016, said, we are we are really
happy about this, but.
So when we talk about SSL version two,
what is what is really SSL version two?
So SSL version two was
was created in 1995
and it was immediately broken in 1995.
Right. So in the same year, just a few
months later. So how did the Internet
look like during these ages?
Pretty. Pretty. Pretty much like this.
Right. This is the Internet of
of the 1990s with
some cryptographic primitives like DNS
and RC for an RC two
and so on and so on.
Most of them are broken.
And there's also some really interesting
things like here, export 40
bits, something like this.
Right. That's
like a cipher, a primitive that was
created because of like politics.
Right. Cryptographic regulations
in the 90s sent that you're only
supposed to export crypto
cryptography with a certain strength,
with a certain maximum strength out of
the US. And this is what we see here.
Right.
So in 1995, as this aversion to
immediately died.
And the reason for that is that
like the creators of SSL version
two, it was published by Netscape.
They they didn't authenticate the
handshake. So an active man
in the middle could just intercept
the handshake and force
you and the server you as a client and
the server to negotiate a very weak
encryption.
And there was no fix for that.
So this is nothing that you could
fix off because it was a protocol issue.
And so, therefore, in 1996,
one year later, they came up with SSL
version three, which is still the basis
on the protocol level for the tearless
that we see that we see today
and that we use every day.
Right.
So now you could say, OK, SS Aubuchon two
was published in 1995
and it was broken in 1995.
No one's no one's ever gonna use
this right now.
I've got some data for you.
So this is the Internet white
scan of the whole IP
before Internet.
In February 2016.
And what do you see here? Is not the
amount of holes. That's the percentage
of all the tearless
and SSL supporting
systems in on the Internet.
And there you see, for example, that 28
percent of all service
listening on Port 25, which is assumptive
p use SSL version
two, which is really, really strange.
Right. I'll I'll I'll come later
to this point. What was the reason for
that. And even for
for HTP.
S support for for three, we still see 17
percent of all the hosts
out there directly support as
a solution to. Which is really, really
strange. Right.
So you could even say.
Right. These all dinosaurs, all
are coming back somehow
to haunt us.
Ah ah ah ah.
See users on the Internet.
Right.
Okay.
So to give you an overview, what is
thrown all about.
So drawn is a fairly sophisticated
exploit chain.
And I will.
It will take me some time to to explain
all the puzzle pieces.
So therefore, this is just a short
overview of that,
like the requirements that an attacker
needs to do in order to
in order to to run a drone exploit.
So first of all, we can break one in 1000
tearless connections. So not everyone,
not every tailless connection, but only
one in 1000.
That basically means.
So in order to break
one of your tearless connections,
the attacker has on average.
To collect 1000 tearless
connections from you.
These can be connections that were
recorded long before Brown
was No. Right.
So we're not talking about an active
attack. It's a passive attack.
And so, therefore, just clicking we
caught in your wireshark
is already sufficient.
And you did this like on a Congress
three or four years ago.
You can break the tearless connections
that you recorded back then, maybe under
certain conditions right now.
OK.
It doesn't come for free.
So we need to perform to to the 50
encryptions, which is which is a lot.
We can do this, but we need Rava
beefy hardware in order in order to do
this. And there's one more requirement.
We need to do around 40000 connections
to that, to that server
that supports SSL wishing to.
Right. So we need one server that
supports SSL version two.
And one very important thing is that
clients don't support SSL
version two for for very long
time. So the last browser that supported
SSL version two was Internet Explorer six
on XP.
Right. And even Internet Explorer six
would always prefer SSL version three.
Right. So if there is a way to to to
negotiate SSL version three, it
would it would also always use that.
So I'm sorry.
We are really breaking tearless
connections. So the connections that
Europe very recent to
tearless client does right now
under the condition that the same server
is supporting SSL Washington, which is
really strange.
Right. So we break tearless
using SSL.
Okay.
So we did an exploit.
And also we put a lot of effort
into optimizing the attack.
And the best thing that we could do was
breaking a single tearless connection on
Amazon. Easy to for
440 U.S.
dollars. So which is pretty.
Right. So if everyone here gives
like maybe 50 cents or so, that
will be already sufficient to break a
single tearless connection.
So I don't need to break a lot of
tearless connection.
I just need to break a single
tearless connection that your
pop three client does every
minute or so to get your email because
they're you your password is is
in there. And if you get your password
right, we can break all the residual.
Right.
So breaking just a single one is
sufficient in most cases.
OK. I said there's a lot of
puzzle pieces that we that we need to
do. And I tried to cluster them to
two to make them more digestible.
So the first thing that I'm going to
talk about is it's a special attack that
I've already talked about two years ago.
I will just go briefly into it, if you're
interested, more into the details of
placing bathetic.
Just look, watch or more from our talk
in 31 C three.
I will show you a new protocol flaw
in SSL version two.
And I need to explain what is it with
a 40 bit expert ciphers.
So when we combine these three
puzzle pieces, we have a practical attack
against SSL version two, which
is not relevant at all because no
one is speaking as a single version two
on the Internet anymore.
We just have servers that support it
generally, but usually this we couldn't
find any any client that still
negotiates SSL wishing.
Okay.
The second thing that we have to look at
is shared keys
among the different SSL until
s versions. So when you set up an
SSL server and it
supports as a solution to version three
and tearless 1.0 up to
one to two, it will always
use the same RSA key here.
Right. And when we take this into
account.
All of a sudden, drone becomes a
practical attack against many
tearless servers.
Right. It's practical in an academic
sense. It still means it's an expensive
attack. But we can do it right.
We can afford it. We all here can afford
it.
And then we have two implementation
errors. So all of the above
practically means that we can attack
every SSL wishing to implementation
that is out there.
Now, here we are looking into
two implementation errors in open
SSL. And if we take which we combine
these with the already existing drone
attack, we all of a sudden get
a trivial attack.
Really trivial. That means it takes
minutes on this laptop against
a lot of tearless servers.
OK.
So let's start with Oblation Bihar's
1998 attack.
And before I start with that, I just
want to quickly repeat
the RSA based key exchange
for tearless.
So there's
various ways of negotiating
like a key.
And when I see a key, it always means
a symmetric key.
Right. So as a metric encryption,
for example, with RSA is pretty
expensive.
So therefore, we just do the key
exchange, like we
exchange a symmetric key over RSA,
which is not that not that much data.
And then the actual content that will be
transferred over the SSL
or Quiles connection.
This will use a yes or triple deaths
or deaths or C4 or something like
this. And what we are looking at is
right now only the part where we
negotiate this key for this symmetric
encryption.
So we have a tearless client, we have a
tailor server.
The tearless client always starts with
a client. Hello.
And it contains a client random number.
This will be like this changes
with every request.
So the client changes this number with
every request and it will be sent in
clear text so the attacker knows this.
The second message, the response
of the tearless server will be the
server. Hello.
It will generate
a random number as well.
It's a server random.
And this will also change with every
with every new connection.
And it's also sending clear text so the
attacker knows claimed random and server
random.
And then it also sends this certificate
that you buy for Comodo or
at Comodo or even that lets encrypt or so
you get it for free.
And in this very cert, there's an RSA
public key.
Right. And this is a public he will
be also sent with a certificate.
And with the next message, the client key
exchange that he'll?
S client generates a thing that
is called a pre massive secret.
And this is the only part that is really
secret in this whole in this whole
exchange.
It will not send this Prima's a secret
in clear. But it will encrypted with
RSA and the key from the
certificate that it just received from
the server and sent this over.
And the next step, and this is a very
important step, that he'll a server
decrypts the prematch, the secret that
it just received, and from this pretty
massive secret, both the client
and the server can generate the same
symmetric key.
OK, so that means
the the this the
attacker knows the client random.
It knows the server random, and it gets
an encrypted version of the pre premises
secret.
And if the attacker can can can
decrypt this, Prima's a secret.
He knows the massive secret, this
symmetric key that is used for RC, for
ice and stuff like that.
Right. So this is the Holy Grail that we
want to break right now and blacken.
BEHÃ‡ET achieves exactly this.
Right. So that's important.
What I need to mention here is this
decryption can fail.
So when the attacker sends,
let's say, an arbitrary ciphertext,
some some drunk data or so,
the server first has to decrypt
this ciphertext in order to find out
whether this is a valid premises,
secret or not.
OK.
So in order to conduct the blasphemous
attack, we need an oracle, so
that's a cryptographic term
for nothing else than a service
that accepts an arbitrary ciphertext
and it will decrypt this cipher text.
So it needs to have the RSA private key
and it responds with one or zero.
So true or false, depending
on the successful decryption.
Right. So if the decryption was
successful and the premises secret
looks somehow valid,
it looks somehow
then it will say, OK, it's true or
otherwise it's false.
So we only get one bit of information
from from this oracle.
So we have a client here and a server.
We have an attacker that
eavesdrops on this connection.
And then it changes
certain parameters of this connection and
sent it over to the Oracle.
The Oracle decrypted
parses it and then says, OK, decryption
or successful or or not.
That's the only information that the
attacker gets gets from the Oracle.
So every time the Oracle answers with a
one or withdrew,
the attacker learns a tiny fraction
of the RSA ciphertext.
So there's a mathematical formula where
you could put everything in.
And if the attacker only does this,
let's say, a few thousand times or so, he
can learn the full ciphertext.
He doesn't get the RSA private key.
We only get like we only
can decrypt this. This the single RSA
ciphertext.
OK, so
in the original paper of Dacian Bahah
from 1998, he
was exploiting the fact that
common tearless implementations,
what would like they had like
an explicit error message for this
type of decryption failure,
which is really bad.
And so they didn't actually
fix the the SSL
or the tearless standard.
They just said, okay, here's an
implementation fix so that the blazing
the high tech won't work anymore.
And it works like this.
So we pretend that the decrypted
prematch, the secret that we have
received was correct
and we proceed with a random pre massive
secret.
So in case that the
the the ciphertext that we have just
received was in mail, it would
just generate a random prima's a secret
and continue with with with the flow.
And this will obviously lead
us lead to some later Iran, because
the symmetric key that comes out here is
different for the client and the server.
So they simply speak with a different key
and can decrypt each other.
And then it comes to an arrow.
Right.
So this looks like this.
So the server will decrypt the premises
secret.
He will always generate a random,
pretty massive secret.
And then depending of whether
the decryption
succeeded or not,
when it succeeded, it will proceed with
a decrypted Premer premise.
And in the case where the decryption
failed, it will proceed with a random
premises secret that it just generated.
And so
this makes all the implementations
that we looked at like it's
indistinguishable, whether the decryption
succeeded or whether it failed.
So it's an implementation fix that is
written in the in the AFC.
Now, we exploit that this very
countermeasure for oblation bahah attack
for blessin because attack in order to
conduct a new bludgeon Barkhouse attack.
Right. And it works like this.
OK.
So let's look at the SSL Worsham to
protocol. It changes.
It's it's it's slightly different
from SSL version three, but it doesn't
doesn't really matter. So we also have a
client. Hello. We also have our server.
Hello. We also have this kind of
client key exchange.
It has just a different name
where we send this symmetric
key that was generated by the client.
And then both would
then both would generate those symmetric
keys.
And what is interesting here is
that the first one that responds
with an encrypted message will be the
server.
And this has very one
very important implication.
That means the
client gets one ciphertext
or the server verify is an encrypted
message with a key.
So with that, Masaaki, that both client
and server should know better by now.
And the client gets
this message without proving
that it has the same symmetric key
in SSL version three and and tearless
this is different.
So this this
message here will only be sent
after the client proved with with a
finished message that he possesses the
same symmetric key.
So the attacker gets one ciphertext
that is encrypted with an unknown key
because we don't know the.
We don't know the key yet.
The question and please accept
it, that this is now an important
an important question that we need to
raise. And I'll explain it in a lot in
the next two slides.
Can we learn this key so we get a cipher
text?
And the question is, can we learn the key
that was used to encrypt that message?
Now, when we look at the specifications
of SSL should, too.
We learned that there are so-called
export ciphers that only have
40 bits of strength.
So this is how a cipher suite looks
like. And it keeps on looking like this
always has the same format.
It tells us there's so
the symmetric key
algorithm that we use as RC two.
It uses 128 bit keys.
It uses a CBC as a
as a mode of encryption.
And it uses export 40
with MDT five as hash as some hash
algorithm.
So that means we have 128 bit
key, but only 40 bit of those
are encrypted.
I told you, the client generates
the symmetric key and sent encrypted
with the public key off the server and
sends it over.
And here it doesn't fully encrypted
128 bit, but only the
40 bits on 40 bits
will be encrypted and 88 bits
are sent in clear.
So everyone can read it.
And in the 90s, the Clinton
administration did this regulation.
They said, OK, so 40 bid is enough
to protect like people
with online banking stuff and
so on and so on.
But the obviously the US government
wanted to look into the into the SSL
connections of whatever country
this this cryptographic hold will be
exported.
When you look at the implementation, the
master key will be built
in a way that the clear bits,
the eighty-eight clear bits will be
concatenated to the decrypted
40 bit secret keys.
Right.
And obviously for nonexperts
cyphers. So you get the same cipher suite
without the export 40 here for nonexperts
cyphers, the length of M.K..
Clear. So the bits that are sending
clear is zero.
OK, fair enough, right?
OK. Maybe not the best idea to do
something like this from.
From a politician's viewpoint.
But still, OK, it makes sense.
OK. At least in the 90s.
OK, so let's look at this
server, verify.
This single message that
we get and where we
want to know the key,
when we look at the specifications, we
learn that the server verify
is nothing else than the
client random that it
sent us in the client.
Hello. So we know the clear takes because
it was sent in a clear and it was
encrypted with a master key.
So we know the plain text and we know
the cipher text.
And we also know when we negotiate this
with an a 40 bit expert
ciphers which which we can
do, then only 40 of those bits
of this masses, Masaki, are secret,
which means we
we can do a brute force search for the
key.
We know the plain text.
We know the ciphertext.
Then we can look for the key because
there's only two to the 40 possibilities
of of the key size, which takes
on beefy hardware.
A few seconds or a few minutes.
Right. But you can even do it on this
laptop. May be finished in a day or so.
OK. So there's nothing nothing really
nothing really critical.
OK,
so let me show you why this is important
and why this forms a new
blash in the Oracle.
So let's assume we are
we create a new ciphertext, a
new encrypted prematch, a secret using
export 40 bits and
send it to the server.
And we do that. We do it twice with
the same ciphertext.
Then we get to server, verify messages
and we break the key that was used to
create the server, verify messages
in case that the Prima's secret was
correct.
We followed this path
there. We proceed with a decrypted pimps
and as we didn't change the ciphertext,
the Prima's a secret is the same.
So therefore the massive secret is the
same. So therefore, right, we get we get
the same Masaki in case
the premises secret is invalid.
We follow this path here,
which means that the master keys
for both server verifies will
be different because it will be generate
a new prematch. The secret is generated
for each and every request that comes in.
And this we could distinguish.
Right. So this forms
a new blash in Bohol Oracle with
the only condition. So we don't get any.
We don't get any error messages from from
the server. Right.
Everything is correctly implemented as
any RC.
But if we sent to
ciphertext,
the problem here is
so when the server verify the key
true to to generate the server, verify
was the same for both messages.
Then we know it was invalid.
Otherwise it was it was valid.
OK, so
when we had this and was a much
larger group that came up with this with
this attack.
So we had a practical attack as against
SSL version two.
And now you need to imagine, like a bunch
of academics in their ivory
tower, you know, like high five things.
Yeah, we do.
We did in you attack new cryptographic
attack, but it has zero relevance
by itself. We were missing each other.
Something like this.
So we need to look further.
That's not sufficient.
Okay. It's a cool it's a cool academic
attack, but it's not relevant at all for
for the Internet.
So let's look at how
people use SSL
and tearless, how they configure it.
When you set up a new
server using Apache or engines
or ISIS or whatever,
at least to my knowledge, there is no way
of saying if a client comes
in and he connects using tearless
one or.
Then he gets Kia and the if
when he connects with SSL
version three, he gets a different key.
That doesn't seem to be possible.
So that means when you set up a system
with a key pair, they always
use the same key material.
It's always the same RSA
public key and private key pair
that will be served independently with a
protocol virginities.
Okay, so that's an important insight.
What is also very interesting is
it a valid question would be
will people use the same
tearless certificates for different
protocols?
So are there people out there
that buy a certificate or get a
certificate from from let's encrypt or so
and use it for HDP?
S for SMP, P for I meant for Pop
three and all the different
other other ports
and it
it turns out they do.
OK.
Which is the problem because everyone is
looking at the secure configuration of
HTP s.
So everyone is looking at actually Pierce
and no one really is looking at the
security of the tearless configurations
of a map pop three as
A.P. and and so on and so on.
So which leads
to the fact I said oblation perhaps
attack works against RSA
ciphertext.
It's nothing written that this is
specific to a a
specific tearless version.
It's a generic RSA, a
decryption Arcam.
Right.
So which which means if we have
10 systems and
these 10 systems all share the
same certificate and only one
of those 10 systems is vulnerable to
drone, then the connections to
all 10 systems can be broken.
Because it's a generic, it's a generic,
a generic iris, a decryption oracle.
So it looks like this.
This is pretty clear, right?
So when we have a server
and it accepts tearless connections
and SSL wish to connections,
then an attacker can eavesdrop
on this tearless connection recorded
and use the server as oblation
bahah oracle over SSL wooshing to
in order to break it.
So there we are.
So if a system supports as this
old version to all the Teil as
connections that go there can be broken
as well. That's pretty clear.
What is new here is let's have,
let's say we have to worship that were
two servers and both
use the same RSA key
material, maybe the same certificate or
even the same certificate actually,
or a different certificate.
So what we saw with
with Heartbleed was
at the Heartbleed attack, what
compromised the keys?
So using a Heartbleed occur, how to
attack an attacker could learn
the private key off that teller server.
So you had to apply for a new
a new certificate. You had to buy a new
certificate.
What many people did is they used the
same ah as a key pair that was
compromised and in a previous certificate
and bought a new certificate with the
same keys that was
compromised before.
Right. Which is not a very good idea.
OK. So it could be it could even
be that both use a different certificate
but have the same RSA key here.
Right. We saw this on the Internet as
well. So in this case,
let's assume this server here
doesn't support SSL version two.
So it's not directly vulnerable to drone.
The attacker can still eavesdrop
on the tearless connections that it sees
here and breaks
it afterwards by making SSL
wishing to connections to this server,
which uses the same key material and
supports SSL wishing to.
Right. So.
And when we
when we scanned the Internet,
what what how this affects
the amount of homes that are vulnerable
to a drone.
This was pretty, pretty dramatic.
But before before we look into this,
let me just not go through
all the numbers that you see here.
I just put on all the numbers that you
see that it's really a substantial amount
of of our as a key pair
sharing on the Internet.
So you have to read this table like this.
For all the S.A.
piece servers.
We collected the Attila's certificates
and then looked, where did we see
this public key
in maybe a different certificate or the
same certificate on some other port.
And there we saw, for example, from all
the tailor certificates that we
encountered on some TV,
30 percent we found on a map.
No, that's pop three.
Twenty nine percent we found on them
on a map and so on and so on.
And so what is really interesting here is
people seem to share
a substantial amount of keys across
protocols, which is pretty
substantial.
This is very interesting here.
So when you look, for example, for HDD
Pierce. So a lot of servers
on actually pierce where we're
vulnerable.
But as I said, actually, yes,
many people look at the configuration of
actually Pierce.
No one seems to care about the teal as
configuration of s.m DP.
It's even like this that people say
for some T.P, if you
can't negotiate a tearless
connection.
If you can't negotiate a tearless
connection, it will fall back to
plaintext.
So for s.m T.P bad encryption
that cryptography is better than
plaintext.
Right. But what we have here right now
is when people have a bad
assembly, PTL s connection
and use the same key material for a
cheap yes, we can break here at
HDB s connections by exploiting
the weaknesses in your assumptive P
configuration.
Which is pretty, pretty substantial.
So when we look at the numbers,
this in most cases it doubles.
So we had, let's say, for a
port. Twenty five.
Twenty eight percent of all the
SMP peace servers that support encryption
on the Internet were vulnerable to drop.
Now, when we extend this attack
and say, okay, we have
this system here and we want to attack
it, the system itself is not
vulnerable to a drone.
But the public key is used on some other
system, on the Internet, on a different
port.
We can do the attack there.
And that obvious that this year means
that 50 percent of all SMP servers,
encryption wise, can can be broken
for Port 43, for example.
It's one third of
all the Internet that support encryption.
We could break tearless connections to
these systems by exploiting some
other system that happens to use
the same ah as a key peer and supports
SSL Washington.
That's a really substantial,
substantial effect that we encountered
here.
OK, so
I said that drone itself
is not a cheap attack.
So it's actually quite complex.
And we thought about how can we.
How can how can we make efficient
attacks for for
drone. We need to do this like
we need to to perform to to the 40
exhaustive searches.
So encryptions or descriptions.
And we need to do this for around 1000
Oracle crews.
So that's a that's a lot to the
50.
And so we basically
we basically took the code.
We took some code parts of open SSL
and did an IEF implementation
using the RC two code and the
ANDE five code of open SSL.
That was the chief implementation of
everything.
And then we had like OK, for the full
attack, it would take us some fact 50
days or so.
Which is pretty long and we wanted to be
better. Then we asked the people
from Hash Cat.
So the hash kit,
the hash cat team, one of the one of
the offers of hash cat is also co author
of Drone.
And so we sent him the code and ask him,
can you. Can you help us?
Because it is pretty similar to password
cracking. What we're doing right drone
is pretty similar to to
cryptography ys with
password cracking.
And then you took the code overnight and
made something like AFACT or 30
or so improvement to it, which is really
like, okay. This is crazy.
Absolutely stunning.
Right. And so so we posted this
on Amazon AC2 and
and found out that for the cost of 440
dollars, we could break one tearless
connection in eight hours.
So this is a pretty substantial
improvement.
OK, cool.
So now we have a practical attack against
many TLR servers.
And this works. This is this is like the.
This is the drone attack that works
against every
SSL wishing to implementation out there.
Now we have two implementation errors in
open SSL, which are
interesting enough so that we have to
show them because they make drone really,
really easy.
The first one we adopted
cyphers with selection back works
like this.
Before we can understand this, Buck.
We need to understand that there is when
you when you do SSL configuration or
tearless configuration, you always have a
protocol version and you
have a cipher suite.
And with every new
protocol version, there was a bunch
of cipher suites released.
Right. And so what many people
did is they always configure
their cipher suites.
So they said, okay, we only use this
secure cipher suites.
And and then we disable
the ports of here, for example, we
disable SSL version three in order
to prevent the poodle attack.
But SSL version two was not
explicitly disabled.
Right. Which meant the
open SSL behind that.
It would enable SSL version two.
But there was not all the experts.
Cyphers would be forbidden.
Right. So this cipher suite configuration
here would forbid export
40 bits of cipher
suites. So therefore drown shouldn't
work.
OK.
So how does a like SSL
version to do the cipher
suite negotiation.
Right.
It works like this in the client.
Hello. The client asks,
Hey server, do you want to talk
with export ciphers and the SSL
wishing to would respond.
Sorry I don't do expert ciphers.
Right. And then the center complaint as a
wishing to client would say OK, are too
bad. OK, bye.
See you next time.
Or maybe try another protocol version or
saw something like this.
Now, this is the relevant court
that will that will be used
afterwards after the handshake that I've
showed you right now.
So let's just assume the client wouldn't
say, OK, bye.
Sorry.
It's really bad that we can't talk
exports.
So if the client says afterwards, OK, I
want to talk. Export.
Anyway, let's have a look how the what
the court does.
So here we receive the
data from the network.
This is like this.
This is that message that contains
the encrypted pre message secret.
And that also contains the cipher
suite that the client just selected.
It will get the SSL
cipher suite by that chart
that came in.
So each cipher suite has one byte
or put it differently.
So there's a byte that denotes a certain
cipher suite.
And this function will just get a pointer
to this particular crypto code.
If this was not successful
and not successful means the
cipher suite was selected.
That is not compiled in.
Okay.
And it is compiled in.
It will simply be used.
So who sees the part that checks
the configuration?
So we haven't read and certainly found
it right. So it's not there.
Okay. So basically what happens is
a nonstandard, compliant SSL version,
too, can force that handshake.
So we say one to talk expert Cyprus
and on two experts say four.
Sorry, OK.
We go. Right.
OK. Let's let's talk.
Export 40 anyway.
And he would say, OK, sure, we can do
that.
Sure.
The story behind here is like this.
Nimrod did this, you
Sappi a very bad
SEPI implementation of off
hour of like some kind of
a scanner in order to to
look how many systems on the Internet
supported SSL wishing to.
And I did the first scan and I felt like
this huge amount of numbers of SSL
watching to scanners.
And then I used a different scanner that
just looked for SSL wishing to and I
would say no as a solution to it's not
supported.
And I debulked in a deep pocket and
doctors took us weeks.
And then I saw that mnemba, it was just
too he was simply
too lazy to pass this message.
So he would just say, hey, you want to
talk? Expert cyphers.
Yeah, yeah, yeah.
Let's just talk export.
Right. He didn't just care what they're
what the server was was responding.
And so this took us.
Yeah. So we were lucky.
Okay.
If we didn't have this
this implementation back, we probably
wouldn't have found many of those.
We wouldn't even have found this back.
So independent, independently of your
SSL configuration of
your cipher suite configuration, using
this back against open SSL, we can
negotiate whatever you want over SSL
wishing to.
Okay, but using a nonstandard
compliant SSL client.
Okay. So this means the server is
vulnerable to drought and this is even
though you're disabled, SSL version two
expert cyphers, which is cool.
The second one is a special drone,
and this is really it's really very
special.
It's also an implementation flaw.
It's not a it's not a Ertz.
It's an implementation flaw.
So let's again use this cipher suite.
So we use RC to with 128
bit keys, but we transfer
all except the 40 bits and clear.
We have talked about this before.
Right.
An implementation flaw allowed
to use these clear bits.
So the bits that are sent in clear
with non export ciphers.
So for nonexperts cyphers, we said
M.K. Clear needs to be zero.
This is not the case here.
So a standard conforming
client would
like.
Right. So for nonexperts effort that
we have here, we would use all the 16
bytes.
So the hundred one hundred and twenty
eight bits would be filled
with the secret parts that we
just extracted from this render fun from
this encrypted pre massive secret.
OK.
If we sent four clear
bites along
with a 16 by prematch, the secret
that was encrypted, it will still
pre pended to the actual encrypted
prematch. The secret.
So that means K 13, k
fourteen fifteen would simply
fall off.
Okay. Which becomes really interesting
when we sent fifteen clear bites
because then all of a sudden we,
we have a server verify that was
encrypted with a 128 bit
key where we know
all but one byte and then we
can brute force on average.
One hundred and twenty eight encryptions.
Right.
So and now we do this like
in a in, in, in a stepping mode.
Right. So we
we sent fifteen zero bytes as MKC
clear. We break this ciphertext.
We learned K one in a second step.
We sent 14 zero bytes.
We know K one from the previous step.
So we brute force K two
in the next step. We sent 13
zero bytes. We know K one.
We know K two.
We want to brute force K three.
And we do it right.
And then like
for this case where we send
zero zero bytes,
we have learned K one to K 15
and only have one byte and we need to
brute force it.
It's again, 128 bit.
Right. OK.
So that means.
So we tap this special round because it's
a special, a special version of this
attack. The generic drawn stealer has to
to the 40 complexity per
Oracle request.
And we need to have something like 1000
Oracle requests.
That's pretty substantial.
But this, too, to the 40 in case of
special drone goes down
to 50 probe connections and
altogether approximately less than
two thousand encrypted encryptions,
encryptions that this can be done
with. The full attack can be done within
a few minutes
on on just a normal Linux
laptop. Right.
Which is very, very critical.
So what is interesting here is
this spark has been fixed
by an openness, this developer,
without knowing that it was fixed.
So Nimrod and I, we submitted a buck that
was totally unrelated to Drom.
We didn't even know Dromm dislike
one and four years ago or so and openness
as L did a patch and
they patched this back without knowing
what it what it actually was.
So it wasn't really a silent fix because
no one was really noticing
what was going on here.
But later, later we figured out
that it's that this is pretty
substantial.
Why I'm explaining this to you is
we can scan we can scan again
the Internet for this and
we can look at who didn't
patch.
They are open SSL.
When we submitted the patch like one
and a half years before.
Right. And so this here means
this is like the.
This is the amount of Internet hosts
that run some kind of
some kind of encryption and that use
SS open SSL that is more than one
year old.
So these people don't really patch.
And when you when you go
when you compare this to the two to
the amount of service that are vulnerable
to drone, you will see that most of them
are open SSL actually, because
the numbers are very similar.
Okay.
So in summary, that's just one sentence
that I can say here.
Ancient SSL Bushin to breaks
current tearless and we can do nothing
else than than just disabling
SSL Bushin tool.
Right. It's dead forgood.
But an important discussion
is also what's also who's to blame
for, for drone.
So what was the fault here.
So for the first one is is pretty
obvious. So we have some crypto design
flaws were done in the 90s.
OK. That's nothing.
That is really too surprising.
OK. Right.
Twenty years ago, many things happened
between them.
We have some crypto implementation flaws
from the 90s. And like the openness, SSL
guys were like, okay, I've never looked
at has the SSL version too cold.
It's been there forever.
Nobody has looked at it.
And so it's really old implementation
code.
What is more a problem is the crypto
configuration Flosse.
So people where where we're
configuring their their SSL
servers in a in a pretty bad May.
And what is also quite interesting
is the export
export cyphers export.
Forty bits is a thing is an is
an essential part to drones,
so drone wouldn't be a practical attack
if we hadn't.
The Clinton administration who forced
this crypto regulation that only
exports expert cryptography may
only have like 40 bits in secret.
OK, so what are the mitigations
for for the administrators here?
So this able SSL version two
and SSL version three while you're at it.
Right. Because it's also.
So SSL is insecure, right.
Don't use the word SSL anymore.
Telesis, the real thing.
Okay. And then obviously update,
update here, open SSL regularly,
which is a thing that you should do for
every library that is in some kind of
security relevant.
Okay.
So this is the mitigation for the Atman.
The mitigation for the citizen, in my
opinion, is vote against crypto vectors.
Right.
Thank you so much.
Thank you, Sebastian.
Do we have questions from
the audience?
OK, well, one question, I think
we started with microphone three, please.
Yeah, actually, two questions.
One is how specific this is for
RSA.
I mean, would it work also for deeply
held lambaste crypto?
And also, after they had
Heartbleed, a lot of people start
looking into the openness, a so-called an
even forum started and so on.
So has the situation improved
since then?
So the first question was, is it is
it limited to RSA?
Yes, it is somehow.
We can we can impersonate
the server with
like when we have substantial hardware,
we can impersonate the server
simply.
Well, it's hard to explain
like this without ah,
like without sleights for this.
So, so, so look at the paper.
So we have broken quick using this.
We can break it if he hulman.
But this needs to.
This is not an off-line attack.
It needs to be an active men in the
middle. Okay, so your first
question and it's limited to RSA.
Yeah. So.
So for example.
Yeah. So difficult and doesn't work.
And your second question was.
Excuse me.
If the situation is open, SSL
or other assali implementations has
improved since Heartbleed.
Okay. So this back hasn't popped up
in one of the audits.
Probably because people didn't care about
SSL wishing to because it's already
messed up. Right.
So people were doing a focused audit,
which is what I would expect.
They did a good job there.
OK. Thank you.
Do we have questions from the Internet?
No. OK.
Microphone one, please.
More of a note.
When you say you have to update or open a
cell regularly.
Something that's important is that you
actually restart all your services
because if you just update your old
message, cell implementation, all the
running processes are still linked
against the old version.
That's a deleted file.
And you're still vulnerable unless you
actually restart every single one of your
services that links against openness SSL.
But there goes your uptime, right?
1000 days uptime.
Yeah.
Thank you. Microphone four, please.
You mentioned that there's a factor
of 1000 that you have to apply to the
twenty two to the four touch of the 40.
Where does that come from?
I think I missed it.
It comes from an algorithm.
Right. So it's when blind.
But has the algorithm from 1998 was
published? It was dubbed the Million
Questions Attack because you used
to have to send like one million
on average one million messages between
client and server in order to
to decrypt the ciphertext.
This has changed dramatically in
the years between. So there are several
papers that it improvements to
the to the attack.
And now it's boiling down to two.
A thousand approximately.
It depends on the size.
It depends on a pre massive secret.
But on average, 1000
connections is what we need.
OK.
Thank you. And the next question is on
microphone one, please.
Hi. This is just a paranoid question
about if you're using the open SSL
library when you said
disable the protocols.
I presume that means when you do the
function, call where you pass in no
tearless version or no SSL
version, there's no asset.
Has someone checked that?
They're actually checking that if they're
not checking the protocol, sir.
If they're not checking the cipher
suites, rather.
Are we guaranteed that doing that means
you're protected? Can I if if I've
if I've said no SSL
V2 when I pass it, when I
set up the context in
the library, does that mean I can
breezy breathe easy.
So open SSL deleted the SSL version
to code after we did the
OK, we told them to try and just
update open SSL and you'll be fine.
It will be deleted.
It's not there in the repository and
that's what I wanted to hear.
And restart your server.
You're sorry. Service.
Microphone five five in the back, please.
Yes. Thank you.
I wanted to ask,
have you looked into a other
group, the Cloudberries?
Except SSL?
Yeah. So most of the modern
crypto libraries, some with
modern. I mean, the ones that appeared in
the last few years, they didn't implement
SSL version two at all anymore.
So Lieber SSL, for example, they just
deleted the code.
Boring SSL deleted the code
like the Python libraries and so they
didn't even implemented and so on and so
on.
But all the ones that were
that we looked at, for example, the code
that is in ISIS s channel,
it has it still supports SSL
version two and it has the same
the same protocols loss.
So if you support SSL
version two, you are vulnerable.
Independently of of of the
implementation, at least how we looked at
it.
Okay. Thank you.
Welcome. And I think microphone one,
please. Why the name drown?
That's a good question. So there's.
I think so.
So, Nima, what came up with the initial
idea and he has this like his favorite
movie where this plays a role.
And then we did a backroom, which which
which I don't remember anymore.
It's written in the paper.
Sorry about it. I don't even know
that the background of many anymore.
It's just a working name.
And then it got like viral and.
Yeah.
And, of course, then for more information
is provided under our plan.
So any other questions?
OK, in this case, I have
a question.
Usually you say, OK,
the which which politician
was it that said, OK, please, we can
the strength, the bladder security
that we veto security.
I'm sorry, I don't get the audio.
Oh, yeah. Of course, the audio under
stage is not that good.
Let's say more.
And in general information, um,
we have the politicians that try to
weaken the security.
So which one was it again?
And this was the Clinton deklin.
OK. This is not true.
I mean, every every politician obviously
wants to wants to do this because of
terrorism. Yes, of course.
Know. Because you're all that bad people.
Yeah. And so if we do this right now, if
you have Krypto regulations right now, we
at least make sure that maybe in 10
years, maybe five years, maybe maybe
fifteen years, we have another bunch of
crypto students who can write their
thesis on it, how to break them.
I'd say it's maybe one good thing about
it, but it's and generally it's not a
good idea.
OK.
Any other questions in the meantime?
I think microphone five is.
Is this a question?
No, this is just down.
There is a question.
For please.
You said that four were
from maidservants, it's still
a good idea to sop support or crypto,
so with a drone attack, it isn't anymore,
I expect.
Or did I misunderstand?
So there's an argument of supporting SSL
version three, even though it's broken,
but it's broken in a sense.
So the poodle attack is still
it's it's obviously more effort
breaking SSL version three than
reading the plain text.
Okay. With the drone attack, it's
different because even
when you use security, less connections,
you can still break it by exploiting SSL
version two.
So and third, the word
for this is opportunistic encryption.
So some bad encryption is even better
than no encryption.
And this change for drone and I think
this is the first attack where where this
works cross protocol.
But don't you compromise?
Oh, yeah. And you don't compromise.
You are as a private key battleground.
Okay. Yeah, then I get it.
So you don't need to buy a new piece for
it. Right. You can still use your same
key. Just just
remove SSL version two from your
configuration and restart the server
in your file or update open SSL.
OK.
Any other questions?
In this case, please give an anniversary
edition applause to us by sentients or.