34C3 - Defeating (Not)Petya's Cryptography

Music

Herald: And give a great round of applause
to Sebastian Eschweiler!

Applause

Sebastian: So hi everyone. So I want to
talk about how I defeated not (Not)Petya's

cryptography. Some I'd say that (Not)Petya
would be Ukraine's scourge, and for those

of you who don't know what the word
scourge means: this guy right here doesn't

know either. And quick trivia quiz - does
anyone know what this movie is? What's the

name of the movie? So, in the next scene
Johnny Depp enters. Does ring a bell? Jim,

a movie by Jim Jarmusch. Soundtrack by
Neil Young? Dead Man, right! Great! It's a

great movie. So if you want to know what a
scourge is then you could watch the movie.

So let's begin with my with my talk. So
this is what actually the official Ukraine

Twitter account tweeted some time ago in
at the end of June 2017. And there was an

outbreak of a ransomware attack which was
noticed mostly in Ukraine but also all

over the world. So millions of users and
also companies large companies were

affected, and the damage went into the
billions of dollars. So, the problem there

is, I mean, this is this is not the
everyday ransomware outbreak you have

there. And I want to give you a short
glimpse into the the (Not)Petya universe.

And also how I could decrypt all these
stuff that, yeah, actually was encrypted

by the this ransomware outbreak. So first
I want to begin my talk with a

differentiation. I want to draw a
demarcation line because all this

(Not)Petya universe - there's much sub-
summarised under under this whole label.

And I really, I'm just talking about a
small fraction of this whole universe. So

I will first distinguish between what my
talk will be in what my talk will not be

about. Next I will describe (Not)Petya's
cryptography, and especially (Not)Petya's

cryptographic failures. Which I then will
be exploiting in the remainder of the talk

and see how can the users get their, yeah,
vacation photos back. So what was this

whole thing? The outbreak started, as I
said, in June 2017, and it started as fake

update or as malicious update from a
software called Madoc

- this is a tax software, one of the two
official tax softwares in the Ukraine. So

almost every company has it installed on
tax accounts on their computers many

private persons have it installed. It was
pushed and then site loaded this file

perfc that was then downloaded to the
computers and it comprises several parts.

And some parts are more interesting than
then as others, so one component ever like

half an hour time it would start
encrypting the files depending on the

access level. So, if there wasn't any
access to infect the computer with well

this MBR infector. then it would just
based on the current user level encrypt

the files based on that current user. In
lack of a better name I would call this

"Mischa" component I know it's usually
somewhat different, something different.

However, this was the best name I could
find there. So it's basically just a

finite crypter with AES. My talk will not
go about this this part - this file

infector. The next very interesting
component was the spreader part - it's

basically based on the
EternalBlue/EternalRomance exploits that

had been leaked by the Shadow Brokers. My
talk will not go about this as well. This

is a whole different universe as well.
What my talk will be about is the actual

(Not)Petya component and this is an MBR
encrypter and I will show you in the next

slide what it's actually about. So, the
user will see something like this upon

reboot. So if the access rights are
granted so if there is some local admin

installed on the computer or the correct
password could be guessed by some attack

and then this dropper, the perfc that
would infect the system by overwriting the

Master Boot Record with a custom boot
loader. And it would reboot the system

after a predefined time - usually being
about 10 minutes. And then the the actual

(Not)Petya compound would kick into
action. This infected MBR, the bootloader

shows this decoy CheckDisk screen, and in
the background would find and iterate the

old files on the file system and

encrypt all these files.
So the main takeaways of this slide are

that we are dealing with 16-bit code here.
So we're we're in 16-bit real mode - so

this means no proper file system it means
no 32-bit or 64-bit code. There are no

windows APIs-- so debugging all this and
analyzing this is a tedious work. However,

we have something on the plus side which
is a BIOS, you know, the basic

input/output system and with that comes a
range of interrupts that are very well

described and a really nice thing is
having Bochs and being able to debug all

this in in IDA. So this was a really neat
plugin that had been developed by the

authors. So let's analyze a bit and check
the cryptography and why implementing

crypto is really hard. So I will start
this part with describing in short words

the theory of Salsa20 and then check that
compare that against the (Not)Petya

implementation of this cipher. So Salsa20
is a stream cipher. So basically you will

have a plaintext, it's it's about here and
then you will have some kind of random

number generator or pseudo-random number
generator and then apply some operations

on the plaintext and out comes the
ciphertext. And what you put in there are

four different variables, or four
different inputs, because there's the

constant part which is obviously not
variable. But we'll see about that in a

bit. So you have these key and the nonce,
and then there's this really nifty thing

called counter. What's so nifty about that
is if you were choose to stream a Salsa 20

encrypted stream and you would lose some
frames then you could adjust this counter

variable which would de-mark the offset of
the current stream in the current stream

and then could continue needlessly with
with the decryption of the stream. So this

is a very nice feature. The size of the
counter is 64-bits and the hash size here,

so what salsa does is create a 64-byte
hash for every different of these inputs

and with that then apply to the input. If
you want any more details about this salsa

cipher, the inventor of salsa should be in
this room, and should be in at the

convention. He is at the convention: I
just rode the train with him, so I guess

you can ask him the the gory details of
salsa 20. So it's a really nice crypto

cipher and you should hit him up and ask
him. I shouldn't have said that, right?

Sorry. So basically what a very important
thing is to note is for every invocation

of this this or for every instance of this
(Not)Petya encryption and you would have

these three variables or these three
inputs be constant so (Not)Petya would

would patch during the infection process
the key, the nonce, and the constants into

a configuration sector. The constants, not
these are somewhat different. And then the

counter would only change throughout every
iteration. So the interesting thing or the

interesting question was first - what is
the length of the key stream? So, the key

stream, you know the the number of
different outputs that that would come out

of this hashing function. And I mean for
this implementation for the theory this

is quite clear it's 64-bits here eight
bytes times the 64 bytes of output so it

would be about two to the seventy of a
periodicity. One different about the

actual implementation in (Not)Petya on the
theory would be that this constants thing

here had been changed to I string a
reading out invalid sect ID. So this would

break the official implementation. So the
very first failure I saw in (Not)Petya was

something like this. So I think I can slip
this slide because it's obvious for

everyone that this is a fail right? So who
sees the fail? So, not many hands? Okay,

then then I'll explain it. So I was just
kidding , I'm almost not not expecting for

for you to grasp of that first. So
remember, we're in 16-bit code. We have

here this shift left operation which would
shift a register by N-bytes. The register

with here is 16 bits, so it only has 16
digits so to speak and you would shift it

by 16 - by 10 hex - sixteen. And this
would effectively null the register, and

even worse is here. So

you would shift a an 8-bit register for
sixteen. So this is something you you

wouldn't expect from my proper
cryptographic implementation. And I was

was really intrigued why that is, because
it wouldn't make any sense in source code

and and did the (Not)Petya or the Petya
authors really implement that on purpose,

or what was the gist with it. And I looked
up the (Not)Petya, the salsa 20

implementation um I just googled it and
funny a nice website that had a

implementation of salsa 20. And there you
would see this code. So you see here it

sits in the the endianness conversion. And
you see here these these shifting of bits

of registers and you see here this this
uint fast 16 or 32 type. So it becomes

quite clear that this is a broken
implementation right? So everyone can see

that right? No, not right now because you
need to know some things more about this.

There are two important facts that make
this implementation broken and the two

facts are: you need to compile this code
for 16 bits, and you need to look up what

Visual Studio makes of these these type
definitions here. And when you look that

up, this is from Visual Studio and it's in
the standard int.h header file. And there

you see it's interpreted or translated as
unsigned int, so this is the base type.

And this base type, unsigned int, in
16-bit code is a 16-bit variable or a

16-bit register. And then everything makes
sense. And this was somewhat of a a

failure here - the authors didn't really
check if their code was actually working

against the test vectors. And this guy who
wrote the code here on this salsa 20

implementation made this mistake also. On
this slide you see two bugs off of the

(Not)Petya implementation of salsa 20. And
I quickly want to to explain both to you

because they are of some somewhat in
importance throughout the remainder of the

talk. So, both revolve around the the
counter variable. Just remember - this

counter variable is the only dynamic input
the only variable input throughout all

these salsa 20 invocations.

And the the first error is: so you read
a sector, a sector number into the memory.

So a bit about the the low-level aspects
of a hard drive. A hard drive from the

view of the BIOS would look somewhat like
a bunch of different sectors. So these are

512 byte chunks of data, and they they
come one after another. So if you were to

read a sector, you would actually read a
512 bytes about me a byte long portion of

data. And this is obviously not the offset
in the stream, and this is somewhat of a

problem there. So, you see here the same
variable is used to decrypt or encrypt the

data. And, I mean, this this is it doesn't
it isn't really apparent to to the

implementer of this cipher. However, if
you were to analyze it, it would look

something like this. So you would have the
key stream of two different sectors, two

different consecutive sectors here. So it
would start with with FF and then

continues with D7 and so on. And the next
sector would have almost all of the bytes

identical. And this is yeah a really big
failure because this really nice salsa 20

implementation, this really nice salsa
algorithm will then be, from would then be

converted from a one-time pad to a many
times pad. And this is the first fine I

wanted to show you in this very few lines
of code. The second part is, the second

bug is here this large keyword. Remember,
we are in 16-bit code so this large

keyword here does not push a 64-bit
variable as we would suspect to do it, but

a 32-bit variable. So only 32 bits of this
this nice counter variable are actually

used in this case. So, these two failures
are somewhat of a problem for this salsa

20 implementation. So, in this slide I
took two different hex dumps, and these

hex times were are within this expand key
function. And they they are well basically

two snapshots - one right before these
bugs become apparent: so before this this

endianness conversion, and right after on
the lower half. So you very nicely see the

different variables being put into all the
different key inputs being put into these

this memory blocks. So here, it would

spell out invalid sect ID, you know, the
constants (Not)Petya uses. Here you would

see the key and here, so it's broken into
two halves. Additionally you would see the

nonce here. And what really sticks out is
this bunch of zeros here. So this this

higher part of this a 64-bit variable
isn't even used - is it's not even filled.

So this is well the first problem here,
and after the endianness conversion you

see that it's not really an endianness
conversion but it's more of a nulling of

of bytes. So the result would be that this
initially 64 bit variable would be just

16-bit in length. And, as I said earlier,
the original salsa implementation would be

2^70s key lengths. And right now we have
16 bits times 64 bytes in in key lengths

which would result an in 26 bits in key
lengths. Which would be a measly 4

megabytes in key lengths. So this is the
this was a very interesting observation I

made there and this would be possible then
to decrypt together with the many times

pad properties of this cipher which make
it really easy to break. So to quickly

summarize this part of the talk - so we
have a very very short key stream of just

4 megabytes, it's highly repetitive
repetitive. So for each secretary progress

you would only have a progress of one byte
at a time. So only 26 bits remain of the

whole stream. And as I said, the many
times pad property's a very nice thing to

to analyze. I could come around to
implement a small joke here, so this salsa

implementation I would only call "LOLsa"
from now on. Sorry, is a bad joke sorry!

So, the the main goal is to derive the
keystream, and as I'm not really a crypto

expert, the basically the only attack I
know it would be a known plaintext attack

so this was my goal there because it's so
straightforward to do that. And in the

remainder of the talk I will tell you how
I did that. So without further ado, let's

exploit these failures and see how much of
the plaintext we can actually get from a

(Not)Petya infected drive.
So the modulus operandi

of (Not)Petya would look
somewhat like that. This, so let's let's

stop with the with the left hand side of
the of this slide, and concentrate on the

right hand side. For those of you who you
are not really intimately familiar with

NTFS - I wasn't before analyzing Petya or
(Not)Petya as well so no worries. It's

quite simple - so every NTFS partition has
something called an master file table.

MFT, abbreviated. And it would contain
some metadata about the file. For example,

the file name, the file size, and if the
file is small enough, it would even fit

the actual content of the file into this
record. So, as I said, MFT is just list of

records. And if the file is larger it
would have a pointer, a so called data

run, which would point to a cluster or
sector on the disk on the partition which

would then actually be the the payload
data. One of these MFT records is one

kilobyte in size. So now to the actual
implementation. So let's zoom out a bit

and see how this LOLsa implementation is
used in (Not)Petya. So it would basically

just iterate over over all of these MFT
records, and then check if this record

would put into would point to a file. If
that is the case, it would encrypt the

first kilobyte of the file, and then would
encrypt the record itself. This

implementation is good for a bunch of
reasons - it's very fast: You would only

need to encrypt the first kilobyte, and
this is this first kilobyte contains

really really important information. For
example, headers, or especially compressed

files have these really important header
structures there. Additionally, your file

recovery tools wouldn't be able to work
anymore because most of them rely on this

very header. And the second thing is this
MFT is can be considered as table of

contents. So with no metadata, with with
no pointers to these to the files, you

won't have anything there to work with to
recover from. And this is a I mean from

from the implementation standpoint it's
very neat, because it's fast and it's a

somewhat thorough. As the MFT is

really important, my idea was to to
recover that first and then check what

what comes out from there and see how I
can can further progress there with the

decryption of the files. So the metadata
would would be of most importance there.

I'm a visual person, and here I took two
disk dumps from a from one of my test

disks. So I infected a clean system with
(Not)Petya and let it encrypt the hard

drive. And on the left-hand side you see
the plaintext on and on the right-hand

side you see the encrypted data. So to
just get a better picture about the

encryption process. On the far left-hand
side fancy PowerPoint altered animation,

you see some kind of indicator so which
which would tell you at which offset, how

much of the of the data has actually been
different. And you see the whole disk is

more or less being encrypted. However, you
see at the far bottom part here it's more

dark red. And this is actually the MFT, so
the MFT is towards the end of the disk

sometimes. But this might be a
misconception. So my my idea was something

like this: we have two input sizes, right?
We have the the encrypted MFT, and we have

encrypted files. And first i would analyze
the MFT, and then derive the key stream

from that. After that analysis stage had
been finished I would put the key stream

back into the this this little box here,
and actually decrypt that. And then out

comes the decrypted MFT. And with that and
the key stream I would be able to find the

encrypted files on the disk, and then be
able to decrypt them; then be ready with

it right? So this was my initial idea
there and so let's start with the

decryption of the MFT. Known plaintext
attack, right? So an MFT you looks for

from from the viewpoint of the keystream,
somewhat like this. So you would have here

the first, the second and so on MFT
records. And on the on the column you will

have the actual byte that is used as key
to encrypt the key stream. Remember, the

operation that that encrypts the you know
the the key stream and the the plaintext

is just a mirror XOR operation.
So you have the the key

stream and the plaintext, and it's plainly
- so you can switch forth and back between

plaintext and ciphertext and even the key
stream with a with just applying an XOR

operation. So what you see here is for the
very first records you only have very few

key stream bytes or very few sample bytes.
However, as the progress as you make

progress with the analysis and then you
will have more and more of these sample

bytes to collect from and this this will
give you more confidence in the in the

result, and the may be known key stream
then. The question is, does the MFT hold

enough plaintext to do some some kind of
known plaintext attack? So let's look into

the specification. The MFT record has
basically two fields. So there is this the

standard information, which is a well-
defined structure and there's something

else called attribute list, which is a
quite dynamic structure and this would be

a somewhat more different, difficult to
clean plan text from. So I concentrate on

this first part. And the first part
quickly turned out to be quite constant

for many or most of the MFT records. And
you see it starts with FILE and then as

some some hex digits after that. And
although on the far bottom part of the

slide, I added my yeah certainty level. So
the the certainty level would be the

number of different sample bytes I would
have multiplied by the confidence I would

have in that sample byte being actually
this this plain text. So you see for the

very first record, we would have a quite
low, of a low certainty. I mean, it's just

one byte, right? Oh, the two byte skipping
is I mean quite a forward considering you

would have usually 512 bytes per sector on
a disk, and the MFT record is one kilobyte

in size, so the stream would progress two
bytes. And for record 100, so for if for

the 100th record I would have a certainty
of four. You know, I would just assume

these eight plaintext bytes here, divided
by 2, with an resulting 4. This wasn't

really satisfactory.
The problem there was towards

the end I would have many many unknown
records because I would was concentrating

on on the very first parts of the header.
So the remainder of the key stream, the

very end of the key stream wasn't be able
to being analyzed and eventually

decrypted. So I thought of something
different. And there was something like a

I would call a byte histogram. So for
every offset the MFT record, i would i

will then calculate creatin and a
histogram and check how many different

bytes are there actually for plaintext,
you know, it's a plaintext known plaintext

attack so I would need some kind of
plaintext and would do that for every

offset for every record. And so these the
questions there how to get many MFT

records - it's quite easy if you have some
nice colleagues you just need to hang them

all of the balcony and shake them a bit
then more or less voluntarily they will

give you some MFT keys to work with. And
the result of that is quite nice: you, I

mean for for the very first, there's
nothing much you can do the very first

record will always have very few sample
bytes. But as the stream progresses and

you will have a dramatic change there so
from this relatively low certainty of

four, I could increase that to more than
thirty. So this is somewhat nice, and ever

bit of doing science, this table drops out
from nowhere. So I compared these two

attack types. So, let's read that from
from right to left. On the on the far

right, I have for the first approach about
98% of the MFT records being successfully

recovered. You know, with the good thing
with science and with all this academic

approach is you have a ground truth. So I
have a plaintext an unencrypted hard drive

which were virtually unordered from
something right after infection, and then

you let execute the the whole infection
and encryption process. And then you can

differentiate and take you knows several
snapshots throughout the infection, change

different key values and all the stuff. So
this is a very nice thing about this

academic approach I was taking the other
So I could I could exactly pinpoint how many

of these records were perfectly recovered.
So for the byte histogram approach I could

decrypt almost all of the records, which
is quite nice because then we have a high

quality MFT to work with. What's also
quite nice is that we have zero wrong key

stream bytes. What's not so nice, however,
is that I was only able to recover about

1.3 percent of the overall key stream. And
remember - this this key stream is about 4

megabytes in length and I was able to
recover only 50 kilobytes of that, so we

can't recover all of the the files. Or is
that so? This is this was my next question

there. And so I drew another nice diagram.
This is the key stream; in the this is the

MFT, sorry, in the key stream. So the the
key stream is only filled and in sample

bytes at this 2 megabytes mark. And the
question is, are there many files in this

area being encrypted or is there some
other bug I could exploit. And I checked

where the files would lie into this the
key stream. So I would check how many

files are at which location in the key
stream being encrypted. And you see the

key stream is used all over the place - so
I mean sometimes it's used more, sometimes

it's used just the less, however, it's
basically used all over the place. And so

this much of the key stream could in a
perfect scenario be, I mean, perfect

scenario being a perfect known plaintext
oracle could theoretically be recovered.

However, this is somewhat of a problem
here and in the next part of the talk I

will present you how I was able to solve
this problem as well. So remember when the

file system is actually encrypted by
(Not)Petya, the file system looks somewhat

like this. So you would have the MFT which
is totally garbled so you won't have any

of any nice file pointers or data runs
pointing through those files. You won't

have any nice file names and all the
stuff. But with the first stage being

finished, the MFT looks really nice - I
mean like almost a hundred percent

of the records could be
recovered. So it looks

somewhat like this. So you have a bunch of
metadata you can now use to analyze the

the remainder of the files and the
remainder of the encryption. So all this

MFT or almost always actually decrypted.
And for files you would have the very

first kilobyte being encrypted. The
remainder of the file, the, I mean, most

files are more than a kilobyte in size,
right? So all the rest is not encrypted.

So you would have all this data and
metadata to collect information and to to

use to exploit as-known plaintext as
indicators for known plaintext. So I

thought of three different approaches to
you know to attack this problem. Basically

I was thinking about: okay what different
files are there, and I was quickly

thinking about different file types. And I
mean, there are I mean the file type can

be easily gleaned from this, right?
Because you would have the file extension

and it would be basically the file type.
And you would have two different types of

files - you would have structured files
and unstructured files. So I thought of

these and you would have something like,
yeah, source code, which I would consider

as more or less unstructured. And I was
calculating the histogram, so this would

give me some kind of prevalence towards
different bytes in the key stream. So it

would be somewhat like a guest plaintext
attack or something like that. The next

thing for structured files would be to do
the very same approach as with the MFT

records. I would calculate the histogram
for every offset of the first kilobyte,

and then quickly see how how many
different bytes are there per offset. And

the last approach uses somewhat more data.
It uses some of the metadata, and also

some of the file data. I will go into this
right now. So, what I basically have here

as I said it's only this this little
portion of the files encrypted. The whole

remainder of the file is not encrypted,
which is quite nice. And also the file

name the file sizes not encrypted.
So what I use, what I would do here

is create a database of
known files of known

Windows system files, for example. Y'all
might remember these nice background

images fonts all this stuff - plaintext
is flying around everywhere if you just

look for it. And I would have basically
three different, yeah, three three

different distinctors between those to
know which which is the correct plaintext.

So there is this this key file name, the
file size, and then the hash of this whole

remainder, of this whole tier. So if all
these 3-tuple would match, then I would

consider this as a proper plaintext.
However, there are some collisions, so

this is this is not really something that
is straightforward. So the initial idea of

having of only needing to analyze the MFT
and then could just being being able to

straightforward decrypt files needed to be
altered a bit. So I added this database of

known files there, I added another another
analysis stage in this nice box here, and

then I would be able to decrypt the files,
eventually. So let's do a bit of science

and check if this approach would be
worthwhile pursuing on a real-world

scenario. So let the science cat do its
science, let me have a drink. So whenever

you did do here is to create a database of
known files - I collected a bunch of

default Windows installations, which
resulted in about 340,000 unique files in

it. Then I calculated, you know, the the
different file type histograms I talked

about, I prepared my test setup, I added
there 1000 different files. And you should

note that these files were not part of
this known files database - they were

different from that because otherwise it
would have been easy to do. Then I would

infect this machine and then let its
encrypt by (Not)Petya and then attempting

recovery. And these are the results there.
So, I did this with 4 different runs, so I

tried every approach separately, and then
combined the three approaches. And the

outcome was something like this: So I
would have only two files by the general

histogram approach being able to
be to decrypt. At least 8%

where I will were yet decrypted by the
location histogram approach. And by the

known files approach over 90% of the files
could be successfully recovered. And even

better, the combined outcome would be
almost all files being able to decrypt.

So, so much about academia. So the problem
there is if you apply this to the real

world, you could get into more trouble
there. And there was lots and lots of more

to think about so. There were, for
example, non default windows installations

with the whole history of updates so this
might be really interesting from a

forensics perspective. Moreover, there's
lots of installed programs to derive known

plaintext from - for example, dotnet uses
a vast source of known plaintext or JDK

installations. So, especially the JDK
would would result in about tens of

thousands of different source code and
HTML files. So this is this really was

really quite nice. The drawback there was,
so there was so much data to collect, the

first attempts failed miserably because of
the sheer amount of RAM I was using. And

this would would result in the admins
constantly giving me more more RAM in my

VM so I would eventually end up with, I
think, 128 gigabytes of RAM and my my test

VM. Also you have a much larger master
file table you know because of all these

files that would need to be stored, so to
put them in in comparison. So this nice

working prototype, so this nice test
setup, I mean, would have an MFT of about

26 megabytes. And for real-world scenarios
you would have something like at least 500

megabytes, and even MFT could be even like
a couple of gigabytes in size. So this

means much more plaintext. So for through
these really large MFTs you could quickly

recover the whole key stream, the whole
four megabytes just by looking at the MFT.

And, in summary, this means that the
decryption of (Not)Petya encrypted drives

is possible. So, for for the file systems
the drives, I have looked at it, was

really I mean ever after having all these
these first bugs out of the way,

I was able to decrypt and
recover all the files there. So

there's a good chance the vacation photos
can be recovered as well. And this will

conclude my talk, so quick summary -
(Not)Petya has some severe cryptographic

failures and flaws, so I would only be
able to call this LOLsa and not salsa

anymore. It might be possible to further
look into this, this you know this expand

key and thing. It it has really really a
bunch of more cryptographic failures in

it. I didn't look into that deeper but I
know some of you guys are professors and

this might be a nice homework for your
students to look at this (Not)Petya

implementation and check out some, you
know, more advanced crypto analysis

methods. And you should note that this
hook this this whole (Not)Petya thing here

I described the whole cryptographic flaws
there are not just in (Not)Petya. They are

you see the brackets there: there they are
in every each and every version of Petya.

So all of the drives that you potentially
have saved can be decrypted. And so my

last point is if any of you or any of us
falls victim to ransomware you really

should keep the drives. You keep them
untouched in a locker and wait for a talk

like this basically. And then hope that
someone comes around and then be able to

decrypt the drives and then, you will have
your vacation photos back. So that's all

folks, thank you for your attention.

Applause

Herald: Thank you very much Sebastian. Now

it's time for questions, please queue up
by the microphones.

Mic 1: Hi, well thank you very much for

sharing your findings with us. I'm from
Rotterdam the largest harbour in Europe,

and as you might know, we were struck by
Petya

Sebastian Yes
Mic 1: Two terminals went down for a

couple of days, a couple of hundred
billion euros of damage. Your approach is

quite theoretically, so now to practice -
if you were there in this summer with

these findings, would you've been able to
help us and decrypt the files and get all

the companies up and running again? Or is
this too academic?

Sebastian: No, it's a practical approach I
mean, I work for CrowdStrike and we had

some occasions where we were able to help
the customers. So it's a very practical

thing to do so. And I was trying to
insinuate this with, you know, this slide

here. So I was talking about the real
world in this scenario. So I looked at

about 50 different encrypted hard drives
with (Not)Petya, and I was able to decrypt

all of them, or most of them. Mostly the
the ones not being able to decrypt or to

some, well, let's say, level 8 mistakes.
Mic 1: Awesome. Have you shared your

findings with nomoreransoms.org?
Sebastian: No, I don't know about this

site
Mic 1: They provide decryption tools for

ransomware. Please do, thank you
Herald: Microphone six, please

Mic 6: Thank you, in the beginning you
mentioned that basically the key was

shortened to what was a 24-bit, something
like that?

Sebastian: 26, yes
Mic 6: 26, yeah. From that point, wasn't a

brute-force attack way faster and way more
reliable?

Sebastian: Oh no no, don't get me wrong
there. So the keystream length was 2^26,

so the keystream length was four
megabytes. So you wouldn't be able to

brute-force that. So sorry, do you get
that? The number of bytes was four

megabytes, and you couldn't be able to
brute-force that.

Mic 6: Yeah but you already mention at the
beginning that you basically shortened it

down to the possibility of at most two to
the power of 26, and it is calculable.

Sebastian: Yes yes, I totally get the
question. But you're you're missing the

point there. So it's not the key space,
2^26, but the key length is 2^26, which

would be something - I I'm not good at
that converting this to decimal. Would be

something like, let me check, two to
the... I mean, here, math guys, computer

guys: how many bits is that?
[Inaudible audience answer]

Sebastian: Say again?
Crowd: A lot?

Sebastian: A lot! So it's, I mean, it's
it's four megabytes of keylength and you

couldn't just brute force that because you
you would have each of these

four megabytes you would have to brute
force. Got that? So the key is not 2^26

but the key length, the keystream length,
is that long. Got that? So yeah, this is

the key space would be longer than the
Bible. You know, and you couldn't just

brute force the Bible, the text of the
Bible. I mean given enough time yes but

you know we will all know the stories with
in monkeys and typewriters. I mean we can

talk about that that offline but you're
you're mixing up two different numbers

there.
Mic 6: Yeah I guess, thank you.

Herald: Questions from the Internet,
please

Signal Angel: Does the MFT encryption work
the same for Petya and (Not)Petya?

Sebastian: Yes, the underlying mechanism
is the same. The cryptography differs in

such a way that the constants number is
different. So, this little guy here - this

is different. It would be usually like
expand key something-something. And here

it's invalid sect ID. So it's somewhat
different, but the the MFT encryption; I

mean the the bytecode the and the
algorithm is the very same.

Signal Angel: Thanks
Herald: Any more questions? Then please

give a great round of applause to
Sebastian

Sebastian: Thank you

Applause

subtitles created by c3subtitles.de
in the year 2018. Join, and help us!