0:00:00.000,0:00:19.480
36c3 preroll music
0:00:19.480,0:00:25.090
Herald: The next talk is on how to break[br]PDF's, breaking the encryption and the
0:00:25.090,0:00:32.910
signatures, by Fabian Ising and Vladislav[br]Mladenov. Their talk was accepted at CCS
0:00:32.910,0:00:37.750
this year in London and they had that in[br]November. It comes from research that
0:00:37.750,0:00:43.660
basically produced two different kinds of[br]papers and it has been... people worldwide
0:00:43.660,0:00:47.540
have been interested in what has been[br]going on. Please give them a great round
0:00:47.540,0:00:51.758
of applause and welcome them to the stage.
0:00:51.758,0:00:59.150
Applause
0:00:59.150,0:01:11.590
Vladi: So can you hear me? Yeah. Perfect.[br]OK. Now you can see the slides. My name is
0:01:11.590,0:01:15.220
Vladislav Mladenov, or just Vladi if you[br]have some questions to me and this is
0:01:15.220,0:01:20.670
Fabian. And we are allowed today to talk[br]about how to break PDF security or more
0:01:20.670,0:01:28.230
special about how to break the[br]cryptography operations in PDF files. We
0:01:28.230,0:01:36.590
are a large team from university of[br]Bochum, Mue nster and Hackmanit GmbH. So as
0:01:36.590,0:01:46.159
I mentioned: We will talk about[br]cryptography and PDF files. Does it work?
0:01:46.159,0:01:57.720
Fabian: All right. OK. Let's try that[br]again. Okay.
0:01:57.720,0:02:02.070
Vladi: Perfect. This talk will consist of[br]two parts. The first part is about
0:02:02.070,0:02:07.829
digitally signed PDF files and how can we[br]recognize such files? If we open them we
0:02:07.829,0:02:16.230
see the information regarding that the[br]file was signed and all verification
0:02:16.230,0:02:20.690
procedures were valid. And more[br]information regarding the signature
0:02:20.690,0:02:27.220
validation panel and information about who[br]signed this file. This is the first part
0:02:27.220,0:02:35.660
of the talk and I will present this topic.[br]And the second part is regarding PDF
0:02:35.660,0:02:41.280
encrypted files and how can we recognize[br]such files? If you tried to open such
0:02:41.280,0:02:47.080
files, the first thing you see is the[br]password prompt. And after entering the
0:02:47.080,0:02:51.800
correct password, the file is decrypted[br]and you can read the content within this
0:02:51.800,0:02:57.720
file. If you open it with Adobe,[br]additional information regarding if this
0:02:57.720,0:03:04.420
file is secured or not is displayed[br]further. And this is the second part of
0:03:04.420,0:03:11.650
our talk, and Fabian, will talk: how can[br]we break the PDA encryption? So before we
0:03:11.650,0:03:19.450
start with the attacks on signatures or[br]encryption, we first need some basics. And
0:03:19.450,0:03:22.700
after six slides, you will be experts[br]regarding PDF files and you will
0:03:22.700,0:03:28.820
understand everything about it. But maybe[br]it's a little bit boring, so be patient:
0:03:28.820,0:03:34.830
there are only 6 slides. So the first is[br]quite easy. PDF files are... the first
0:03:34.830,0:03:42.250
specification was in 1993 and almost at[br]the beginning PDF cryptography operations
0:03:42.250,0:03:48.920
like signatures and encryption was already[br]there. The last version is PDF 2.0 and it
0:03:48.920,0:03:57.610
was released in 2017. And according to[br]Adobe 1.6 billion files are on the web and
0:03:57.610,0:04:06.140
perhaps more exchange beyond the web. So[br]basically PDF files are everywhere. And
0:04:06.140,0:04:11.790
that's the reason why we consider this[br]topic and tried to find or to analyze the
0:04:11.790,0:04:19.730
security of the features. If we have some[br]very simple file and we open it with Adobe
0:04:19.730,0:04:25.390
Reader, the first thing we see is, of[br]course, the content. "Hello, world!" in
0:04:25.390,0:04:32.060
this case, and additional information[br]regarding the focused page and how many
0:04:32.060,0:04:39.630
pages this document has. But what would[br]happen if we don't use a PDF viewer and
0:04:39.630,0:04:48.210
just use some text editor? We use the[br]Notepad++ to open and later manipulate the
0:04:48.210,0:04:56.400
files. So I will zoom this thing... this[br]file. And the first thing we see is that
0:04:56.400,0:05:04.500
we can read it. Perhaps it's quite, quite[br]funny. And but we can still extract some
0:05:04.500,0:05:10.910
information of this file. For example,[br]some information regarding the pages. And
0:05:10.910,0:05:19.740
here you can see the information that the[br]PDF file consists of one page. But more
0:05:19.740,0:05:27.350
interesting is that we can see the[br]content of the file itself. So the lessons
0:05:27.350,0:05:34.960
we learned is that we can use a simple[br]text editor to view and edit PDF files.
0:05:34.960,0:05:43.900
And for our attacks, we used only this[br]text editor. So let's go to the details.
0:05:43.900,0:05:51.560
How PDF files are structured and how they[br]are processed. PDF files consist of 4
0:05:51.560,0:05:59.170
parts: header, body and body is the most[br]important part of the PDF files. The body
0:05:59.170,0:06:03.820
contains the entire information presented[br]to the user. And 2 other sections: Xref
0:06:03.820,0:06:11.490
section and trailer. Very important think[br]about processing PDF files, is that
0:06:11.490,0:06:18.020
they're processed not from the top to the[br]bottom, but from the bottom to the top. So
0:06:18.020,0:06:23.700
the first thing is that the PDF viewer[br]analyses or processes is the trailer. So
0:06:23.700,0:06:28.981
let's start doing that. What information[br]is starting this trailer? Basically, there
0:06:28.981,0:06:35.540
are two very important informations. On[br]the first side this is the information:
0:06:35.540,0:06:41.410
what is the root element of this PDF? So[br]which is the first object which will be
0:06:41.410,0:06:47.860
processed? And the second important[br]information is where the Xref section
0:06:47.860,0:06:54.000
starts. It's just a byte offset pointing[br]to the position of the XRef section within
0:06:54.000,0:07:00.201
the PDF file. So this pointer, as[br]mentioned before, points to the Xref
0:07:00.201,0:07:05.710
section. But what is the Xref section[br]about? The Xref section is a catalog
0:07:05.710,0:07:11.180
pointing or holding the information where[br]the objects defined in the body are
0:07:11.180,0:07:18.741
contained or the byte positions of this[br]object. So how can we read this weird Xref
0:07:18.741,0:07:25.540
section? The first information we extract[br]is that the first object, which is defined
0:07:25.540,0:07:34.610
here, is the object with ID 0 and we have[br]5 further elements or objects which are
0:07:34.610,0:07:41.090
defined. So the first object is here. The[br]first entry is the byte position within
0:07:41.090,0:07:46.610
the file. The second is its generation[br]number. And the last charter points, if
0:07:46.610,0:07:53.200
this object is used or not used. So[br]reading it, reading this Xref section, we
0:07:53.200,0:08:00.590
extract the information that the object[br]with ID 0 is at byte position 0 and is not
0:08:00.590,0:08:08.650
in use. So the object with ID 1 is at the[br]position 9 and so on and so forth. So for
0:08:08.650,0:08:18.370
the object with ID 4 and the object number[br]comes from counting it: 0 1, 2, 3 and 4.
0:08:18.370,0:08:29.430
So the object with ID 4 can be found at[br]the offset 184 and it's in use. In other
0:08:29.430,0:08:35.449
words, the PDF viewer knows where each[br]object will be found and can properly
0:08:35.449,0:08:42.329
display it and process it. Now we come to[br]the most important part: the body, and I
0:08:42.329,0:08:48.810
mentioned it that in the body the entire[br]content which is presented to the user is
0:08:48.810,0:08:58.220
contained. So let's see. Object 4 0 is[br]this one and as you can see, it contains
0:08:58.220,0:09:04.870
the word "Hello World". The other objects[br]are a reference, too. So each pointer
0:09:04.870,0:09:10.119
points exactly to the starting position of[br]each of the objects. And how can we read
0:09:10.119,0:09:15.910
this object? You see, we have an object[br]starting with the ID number, then the
0:09:15.910,0:09:24.999
generation number and the word "obj". So[br]you now know where the object starts
0:09:24.999,0:09:32.259
and when it ends. Now how can we process[br]this body? As I mentioned before in the
0:09:32.259,0:09:40.970
trailer, there was a reference regarding[br]the root element and this element was with
0:09:40.970,0:09:48.769
ID 1 and generation number 0. So, we now[br]we start reading the document here and we
0:09:48.769,0:09:55.910
have a catalog and a reference to some[br]pages. Pages is just a description of all
0:09:55.910,0:10:02.889
the pages contained within the file. And[br]what can we see here is that we have this
0:10:02.889,0:10:09.779
number count once or we have only one page[br]and a reference to the page object which
0:10:09.779,0:10:15.170
contains the entire information[br]inscription of the page. If we have
0:10:15.170,0:10:22.230
multiple pages, then we will have here[br]multiple elements. Then we have one page.
0:10:22.230,0:10:29.850
And here we have the contents, which is a[br]reference to the string we already saw.
0:10:29.850,0:10:35.139
Perfect. If you understand this then you[br]know everything or almost everything about
0:10:35.139,0:10:39.360
PDF files. Now you can just use your[br]editor and open such files and analyze
0:10:39.360,0:10:50.310
them. Then we need one feature... I forgot[br]the last part. The most simple one. The
0:10:50.310,0:10:56.129
header. It should just one line stating[br]which version is used. For example, in our
0:10:56.129,0:11:04.779
case, 1.4. For the last version of Adobe[br]here will be stated 2.0. Now, we need this
0:11:04.779,0:11:13.699
one feature called "Incremental Update".[br]And I call this feature - do you know this
0:11:13.699,0:11:19.629
feature highlighting something in the PDF[br]file or putting some sticky notes?
0:11:19.629,0:11:24.119
Technically, it's called "incremental[br]update." I just call it reviewing master
0:11:24.119,0:11:30.680
and bachelor thesis of my students because[br]this is exactly the procedure I follow. I
0:11:30.680,0:11:38.100
just read the text and highlight something[br]and store the information I put at it.
0:11:38.100,0:11:46.970
Technically by putting such a sticky note.[br]this additional information is appended
0:11:46.970,0:11:53.160
after the end of the file. So we have a[br]body update which contains exactly the
0:11:53.160,0:12:01.369
information additionally of the new[br]objects and of course, new Xref section
0:12:01.369,0:12:15.610
and a new trailer pointing to this new[br]object. Okay, we are done. Considering
0:12:15.610,0:12:23.860
incremental update, we saw that it is used[br]mainly for sticky notes or highlighting.
0:12:23.860,0:12:29.679
But we observed something which is very[br]important because an incremental update we
0:12:29.679,0:12:36.930
can redefine existing objects, for[br]example, we can redefine the object with
0:12:36.930,0:12:45.730
ID 4 and put new content. So we replace in[br]this manner the word "Hello World" with
0:12:45.730,0:12:51.699
another sentence and of course the Xref[br]section and the trailer point to this new
0:12:51.699,0:13:00.100
object. So this is very important. With[br]incremental update we are not stuck to
0:13:00.100,0:13:06.220
only adding some highlighting or notes. We[br]can redefine already existing content and
0:13:06.220,0:13:14.399
perhaps we need this for the attacks we[br]will present. So let's talk about PDF
0:13:14.399,0:13:23.339
signatures. First, we need a difference[br]between electronic signature and digital
0:13:23.339,0:13:28.699
signature. Electronic signature. From a[br]technical point of view, it's just an
0:13:28.699,0:13:36.369
image. I just wrote it on my PC and put it[br]into the file. There is no cryptographic
0:13:36.369,0:13:40.890
protection. It could be me lying on the[br]beach doing something. From cryptographic
0:13:40.890,0:13:45.509
point of view is the same. It does not[br]provide any security, any cryptographic
0:13:45.509,0:13:52.739
security. What we will talk about here is[br]about digitally signed files, so if you
0:13:52.739,0:14:00.290
open such files, you have the additional[br]information regarding the validation about
0:14:00.290,0:14:08.309
the signatures and who signed this PDF[br]file. So as I mentioned before, this talk
0:14:08.309,0:14:16.689
will concentrate only on these digitally[br]signed PDF files. How? What kind of
0:14:16.689,0:14:22.879
process is behind digitally signing PDF[br]files? Imagine we have this abstract
0:14:22.879,0:14:28.639
overview of a PDF document. We have the[br]header, body, Xref section and trailer. We
0:14:28.639,0:14:35.480
want to sign it. What happens is that we[br]take this PDF file and via incremental
0:14:35.480,0:14:41.899
update we put additional information[br]regarding that. There is a new catalog and
0:14:41.899,0:14:46.379
more important, a new signature object[br]containing the signature value and
0:14:46.379,0:14:52.100
information about who signed this PDF[br]file. And of course, there is an Xref
0:14:52.100,0:14:58.970
section and trailer. And relevant for you:[br]The entire file is now protected by the
0:14:58.970,0:15:06.860
PDF signature. So manipulations within[br]this area should not be possible, right?
0:15:06.860,0:15:15.879
Yeah, let's talk about this: why it's not[br]possible and how can we break it? First,
0:15:15.879,0:15:21.370
we need an attack scenario. What we want[br]to achieve as an attacker. We assumed in
0:15:21.370,0:15:27.839
our research that the attacker possesses[br]this signed PDF file. This could be an old
0:15:27.839,0:15:35.989
contract, receipt or, in our case, a bill[br]from Amazon. And if we open this file, the
0:15:35.989,0:15:41.440
signature is valid. So everything is[br]green. No warnings are thrown and
0:15:41.440,0:15:48.329
everything is fine. What we tried to do is[br]to take this file, manipulate it somehow
0:15:48.329,0:15:56.319
and then send it to the victim. And now[br]the victim expects to receive a digitally
0:15:56.319,0:16:01.779
signed PDF file, so just tripping the[br]digital signature is a very trivial
0:16:01.779,0:16:07.600
scenario and we did not consider it[br]because it's trivial. We considered that
0:16:07.600,0:16:13.240
the victim expects to see that there is a[br]signature and it is valid. So no warning
0:16:13.240,0:16:20.420
casts are thrown and the entire left side[br]is exactly the same from the normal
0:16:20.420,0:16:28.109
behavior. But on the other side, the[br]content was exchanged so we manipulated
0:16:28.109,0:16:33.790
the receipt and exchanged it with another[br]content. The question is now: how can we
0:16:33.790,0:16:41.079
do it on a technical level? And we came up[br]with three attacks: incremental saving
0:16:41.079,0:16:45.929
attacks, signature wrapping and universal[br]signature forgery. And I will now
0:16:45.929,0:16:51.209
introduce the techniques and how these[br]attacks are working. The first attack is
0:16:51.209,0:16:56.839
the incremental saving attack. So I[br]mentioned before that via incremental
0:16:56.839,0:17:06.439
saving or via incremental updates, we can[br]add and remove and even redefine already
0:17:06.439,0:17:14.650
existing objects and the signature still[br]stays valid. Why is this happening?
0:17:14.650,0:17:21.110
Consider now again our case. We have some[br]header, body, Xref table and trailer and
0:17:21.110,0:17:27.559
the file is now signed and the signature[br]protects only the signed area. So what
0:17:27.559,0:17:32.600
would happen if I put a sticky note or[br]some highlighting? An incremental update
0:17:32.600,0:17:39.169
happens. If I open this file, usually this[br]happens: We have the information that this
0:17:39.169,0:17:45.799
signature is valid, when it was signed and[br]so on and so forth. So our first idea was
0:17:45.799,0:17:53.250
to just put new body updates, redefine[br]already existing content and with a Xref
0:17:53.250,0:17:59.419
table and trailer we point to the new[br]content. This is quite trivial because
0:17:59.419,0:18:04.820
it's a legitimate feature in PDF files, so[br]we didn't expect to be quite successful
0:18:04.820,0:18:11.760
and we were not so successful. But the[br]first idea: we applied this attack, we
0:18:11.760,0:18:22.080
opened it and we got this message. So it's[br]kind of a weird message because an
0:18:22.080,0:18:27.970
experienced user sees valid, but the[br]document has been updated and you should
0:18:27.970,0:18:33.580
know what does this exactly mean. But we[br]did not consider this attack as successful
0:18:33.580,0:18:41.110
because the warning is not the same or the[br]status of the signature validation is not
0:18:41.110,0:18:50.909
the same. So what we did is to evaluate[br]this first against this trivial case,
0:18:50.909,0:18:56.860
against older viewers we have, and Libre[br]office, for example, was vulnerable
0:18:56.860,0:19:01.769
against this trivial attack. This was the[br]only viewer which was vulnerable against
0:19:01.769,0:19:07.440
this trivial variation. But then we asked[br]ourselves: Okay, the other viewers are
0:19:07.440,0:19:14.250
quite secure. But how do they detect these[br]incremental updates? And from developer
0:19:14.250,0:19:22.410
point of view, the laziest thing we can do[br]is just to check if another Xref table and
0:19:22.410,0:19:28.330
trailer were added after the signature was[br]applied. So we just put our body updates
0:19:28.330,0:19:37.450
but just deleted the other two parts. This[br]is not a standard compliant PDF file. It's
0:19:37.450,0:19:44.789
broken. But our hope was that the PDF[br]viewer fixes this kind of stuff for us and
0:19:44.789,0:19:51.210
that these viewers are error-tolerant. And[br]we were quite successful because the
0:19:51.210,0:19:56.320
verification logic just checked: Is there[br]an Xref table and trailer after the
0:19:56.320,0:20:01.580
signature was applied? No? Okay.[br]Everything's fine. The signature is valid.
0:20:01.580,0:20:05.450
No warning was thrown. But then the[br]application logic saw that incremental
0:20:05.450,0:20:13.580
updates were applied and fixed this for us[br]and processed these body updates and no
0:20:13.580,0:20:21.159
warning was thrown. Some of the viewers[br]required to have a trailer. I don't know
0:20:21.159,0:20:25.350
why - it was a Black box testing. So we[br]just removed the Xref table, but the
0:20:25.350,0:20:32.030
trailer was there and we were able to[br]break further PDF viewers. The most
0:20:32.030,0:20:38.490
complex variation of the attack was the[br]following: We had the PDF viewers checked
0:20:38.490,0:20:47.330
if every incremental update contains a[br]signature object. But they did not check
0:20:47.330,0:20:53.200
if this signature is covered by the[br]incremental update. So we just copy-pasted
0:20:53.200,0:21:01.290
the signature which was provided here and[br]we just forced the PDF viewer to validate
0:21:01.290,0:21:10.100
this signed content twice - and still our[br]body updates were processed and for
0:21:10.100,0:21:18.669
example, Foxit or Master PDF were[br]vulnerable against this type of attack. So
0:21:18.669,0:21:24.909
the evaluation of our attack: We[br]considered as part of our evaluation 22
0:21:24.909,0:21:31.050
different viewers - among others, Adobe[br]with different versions, Foxit, and so on.
0:21:31.050,0:21:41.140
And as you can see 11 of 22 were[br]vulnerable against incremental saving. So
0:21:41.140,0:21:47.160
50 percent, and we were quite surprised[br]because we saw that the developers saw
0:21:47.160,0:21:51.639
that incremental updates could be[br]dangerous regarding the signature
0:21:51.639,0:22:01.070
validation. But we were still able to[br]bypass their considerations. We had - a
0:22:01.070,0:22:07.769
full signature bypass means that there is[br]no possibility for the victim to detect
0:22:07.769,0:22:14.269
the attack. A limited signature bypass[br]means that the victim, if the victim
0:22:14.269,0:22:23.470
clicks on one - at least one - additional[br]window and explicitly wants to validate
0:22:23.470,0:22:31.520
the signature, then the viewer was[br]vulnerable. But the most important thing
0:22:31.520,0:22:38.080
is by opening the file, there was a status[br]message that the signature validation and
0:22:38.080,0:22:44.289
all signatures are valid. So this was the[br]first layer and the viewers were
0:22:44.289,0:22:51.390
vulnerable against this. So let's talk[br]about the second attack class. We called
0:22:51.390,0:22:57.970
it "signature wrapping attack" and this is[br]the most complex attack of the 3 classes.
0:22:57.970,0:23:04.580
And now we have to go a little bit into[br]the details of how PDF signatures are
0:23:04.580,0:23:10.450
made. So imagine now we have a PDF file.[br]We have some header and the original
0:23:10.450,0:23:15.549
document. The original document contains[br]the header, the body, the Xref section and
0:23:15.549,0:23:21.919
so on and so forth. And we want to sign[br]this document. Technically, again, an
0:23:21.919,0:23:28.700
incremental update is provided and we have[br]a new catalog here. We have some other
0:23:28.700,0:23:35.159
objects, for example, certificates and so[br]on and the signature objects. And we will
0:23:35.159,0:23:38.720
now concentrate on this signature object[br]because it's essential for the attack we
0:23:38.720,0:23:45.399
want to to carry out. And the signature[br]object contains a lot of information, but
0:23:45.399,0:23:51.460
we want for this attacks only two elements[br]are relevant: The contents and the byte
0:23:51.460,0:23:57.940
range. The contents contains the signature[br]value. It's a PKCS7 container containing
0:23:57.940,0:24:05.710
the signature value and the certificates[br]used to validate the signature and the
0:24:05.710,0:24:11.299
bytes range. The byte range contains four[br]different values and what how these values
0:24:11.299,0:24:23.090
are being used. The first two, A and B[br]define the first signed area. And this is
0:24:23.090,0:24:29.159
here from the beginning of the document[br]until the start of the signature value.
0:24:29.159,0:24:35.370
Why we need this? Because the signature[br]value is part of the signed area. So we need
0:24:35.370,0:24:42.780
to exclude the signature value from the[br]document computation. And this is how the
0:24:42.780,0:24:49.179
bytes range is used. The first part is[br]from the beginning of the document until
0:24:49.179,0:24:54.629
the signed the signature value starts and[br]after the signature ends until the end of
0:24:54.629,0:25:04.759
the file is the second area specified by[br]the two digits C and D. So, now we have
0:25:04.759,0:25:13.500
everything protected besides the signature[br]value itself. What we wanted to try is to
0:25:13.500,0:25:21.889
create additional space for our attacks.[br]So our idea was to move the second signed
0:25:21.889,0:25:30.350
area. And how can we do it? So basically[br]we can do it by just defining another byte
0:25:30.350,0:25:40.240
range. And as you can see here, the byte[br]range points from area A to B. So this
0:25:40.240,0:25:46.889
area we didn't made any manipulation in[br]this part, right? It was not modified at
0:25:46.889,0:25:53.309
all. So it's still valid. And the second[br]part, the new C value and the next D
0:25:53.309,0:26:00.169
bytes, we didn't change anything here,[br]right? So basically, we didn't changed
0:26:00.169,0:26:06.750
anything in the signed area. And the[br]signature is still valid. But what we
0:26:06.750,0:26:13.980
created was a space for some malicious[br]objects; sometimes we needed some padding
0:26:13.980,0:26:20.960
and a new extra section pointing to this[br]malicious objects. Important thing was
0:26:20.960,0:26:27.559
that this malicious Xref sections, the[br]position is defined by the trailer. And
0:26:27.559,0:26:32.799
since we can not modify this trailer, this[br]position is fixed. So this is the only
0:26:32.799,0:26:42.880
limitation of the attack, but it works[br]like a charm. And the question is now: How
0:26:42.880,0:26:49.730
many PDF viewers were vulnerable against[br]this attack? And as you can see, this is
0:26:49.730,0:26:58.169
the signature wrapping column. 17 out of[br]22 applications were vulnerable against
0:26:58.169,0:27:06.000
this attack. This was quite expected[br]result because the attack was complex we
0:27:06.000,0:27:14.789
saw that many developers didn't, were not[br]aware of this threat and that's the reason
0:27:14.789,0:27:22.600
why so many vulnerabilities were there.[br]Now to the last class of attacks,
0:27:22.600,0:27:28.580
universal signature forgery. And we called[br]it universal signature forgery, but I
0:27:28.580,0:27:33.879
preferred to use another definition for[br]this attacks. I call them stupid
0:27:33.879,0:27:40.909
implementation flaws. We are coming from[br]the PenTesting area and I know a lot of
0:27:40.909,0:27:49.880
you are PenTesters, too. And, many of you[br]have experience, quite interesting
0:27:49.880,0:27:58.460
experience with zero bytes, null values or[br]some kind of weird values. And this is
0:27:58.460,0:28:06.309
what we tried in this kind of attacks.[br]Just tried to do some stupid values or
0:28:06.309,0:28:13.100
remove references and see what happen.[br]Considering the signature, there are two
0:28:13.100,0:28:18.389
different important elements: The contents[br]containing the signature value and the
0:28:18.389,0:28:25.220
byte range pointing to what is exactly[br]signed. So, what would happen if we remove
0:28:25.220,0:28:30.679
the contents? Our hope was that the[br]information regarding the signature is
0:28:30.679,0:28:37.779
still shown by the viewer as valid without[br]validating any signature because it was
0:28:37.779,0:28:45.169
not possible. And by just removing the[br]signature value is quite obvious idea. And
0:28:45.169,0:28:48.899
we were not successful with this kind of[br]attack. But let's proceed with another
0:28:48.899,0:28:57.090
values like for example, contents without[br]any value or contents like equals NULL or
0:28:57.090,0:29:04.710
zero bytes. And considering this last[br]version, we had two viewers which were
0:29:04.710,0:29:15.049
vulnerable against this attack. And[br]another, another case is, for example, by
0:29:15.049,0:29:19.929
removing the byte range. By removing this[br]byte range we have some signature value,
0:29:19.929,0:29:29.590
but we don't know what is exactly signed.[br]So, we tried this attack and of course,
0:29:29.590,0:29:38.390
byte range without any value or NULL bytes[br]or byte range with a minus or negative,
0:29:38.390,0:29:46.169
negative numbers. And usually this last[br]crashed very a lot of viewers. But the
0:29:46.169,0:29:51.800
most interesting is that Adobe made this[br]mistake by just removing the byte range.
0:29:51.800,0:29:56.990
We were able to bypass the entire[br]security. We didn't expect this behavior,
0:29:56.990,0:30:00.950
but it was a stupid implementation flaw,[br]allowing us to do anything in this
0:30:00.950,0:30:08.190
document and all the exploits we show in[br]our presentations were made on Adobe with
0:30:08.190,0:30:14.909
this attack. So let's see what were the[br]results of this attack. As you can see,
0:30:14.909,0:30:21.110
only 4 of 22 viewers were vulnerable[br]against this attack and only Adobe
0:30:21.110,0:30:26.280
unlimited; for the others, there was[br]limitation because if you click on the
0:30:26.280,0:30:32.760
signature validation, then a warning was[br]thrown. It was very easy for Adobe to fix.
0:30:32.760,0:30:37.540
And as you can see, Adobe didn't mistake,[br]made any mistake regarding incremental
0:30:37.540,0:30:40.820
saving, a signature wrapping, but[br]regarding controversial signature forgery.
0:30:40.820,0:30:48.169
There were vulnerable against this attack.[br]And this was the hope of our approach. In
0:30:48.169,0:30:56.029
summary, we were able to break 21 of 22[br]PDF viewers. The only
0:30:56.029,0:31:00.850
Applause[br]Thanks.
0:31:00.850,0:31:08.149
Applause[br]The only secure PDF viewer is Adobe 9,
0:31:08.149,0:31:12.860
which is deprecated and has remote code[br]execution. The only
0:31:12.860,0:31:18.039
Laugh[br]The only users allowed to use them or are
0:31:18.039,0:31:25.450
using it are Linux users, because this is[br]the last version available for Linux and
0:31:25.450,0:31:31.779
that's the reason why you consider it. So,[br]I'm done with the talk about PDF
0:31:31.779,0:31:36.644
signatures and now Fabian can talk about[br]PDF encryption. Thank you.
0:31:36.644,0:31:42.540
Fabian: Yes[br]Applause
0:31:42.540,0:31:46.759
OK, now that we have dealt with the[br]signatures, let's talk about another
0:31:46.759,0:31:52.759
cryptographic aspect in PDFs. And that is[br]encryption. And some of you might remember
0:31:52.759,0:31:58.481
our PDFex vulnerability from earlier this[br]year. It's, of course, an attack with a
0:31:58.481,0:32:03.720
logo and it presents two novel tech[br]techniques targeting PDF encryption that
0:32:03.720,0:32:08.029
have never been applied to PDF encryption[br]before. So one of them is these so-called
0:32:08.029,0:32:12.549
direct exfiltration where we break the[br]cryptography without even touching the
0:32:12.549,0:32:18.840
cryptography. So no ciphertext[br]manipulation here. The second one as so-
0:32:18.840,0:32:24.690
called malleability gadgets. And those are[br]actually targeted modifications of the
0:32:24.690,0:32:31.240
ciphertext of the document. But first,[br]let's take a step back and let again take
0:32:31.240,0:32:39.519
some keywords in. So PDF uses AES. OK.[br]Well, AES is good. Nothing can go wrong,
0:32:39.519,0:32:44.220
right? So let's go home. Encryption is[br]fine. Well, of course, we didn't stop
0:32:44.220,0:32:52.160
here, but took a closer look. So they use[br]CBC mode of operation, so cipher block
0:32:52.160,0:32:58.309
chaining. And, what's more important is[br]that they don't use any integrity
0:32:58.309,0:33:04.120
protection. So it's unintegrity protected[br]AES-CBC. And you might remember the
0:33:04.120,0:33:08.909
scenario from the attacks against[br]encrypted e-mail, so against OpenPGP and
0:33:08.909,0:33:15.999
S-MIME, it's basically the same problem.[br]But first, who actually uses PDF
0:33:15.999,0:33:20.940
encryption? You might ask. For one, we[br]found some local banks in Germany use
0:33:20.940,0:33:26.030
encrypted PDFs as a drop-in replacement[br]for S-MIME or OpenPGP because their
0:33:26.030,0:33:34.899
customers might not want to deal with uhm,[br]set, with the setup of encrypted e-mail.
0:33:34.899,0:33:39.740
Second one, were some drop-in plugins for[br]encrypt e-mail as well. So there are some
0:33:39.740,0:33:44.570
companies out there that produce product[br]that you can put into your outlook and you
0:33:44.570,0:33:51.330
can use encrypted PDF files instead of[br]encrypted email. We also found that some
0:33:51.330,0:33:57.919
scanners and medical devices were able to[br]send encrypted PDF files via e-mail. So
0:33:57.919,0:34:02.990
you can set a password on that machine and[br]they will send the encrypted PDF via
0:34:02.990,0:34:10.369
e-mail and you have to put in the[br]password some other way. And lastly, we
0:34:10.369,0:34:14.639
found that some governmental organizations[br]use encrypted PDF documents, for example,
0:34:14.639,0:34:20.409
the US Department of Justice allows for[br]the send, sending in some claims via
0:34:20.409,0:34:25.280
encrypted PDFs. And I've exactly no idea[br]how you how they get the password, but at
0:34:25.280,0:34:30.850
least they allow it. So as we are from[br]academia, let's take a step back and look
0:34:30.850,0:34:36.860
at our attacker model. So we've got Alice[br]and Bob. Alice wants to send a document to
0:34:36.860,0:34:42.120
Bob. And she wants to send it over an[br]unencrypted channel or a channel she
0:34:42.120,0:34:48.610
doesn't trust. So of course, she decides[br]to encrypt it. Second scenario is, they
0:34:48.610,0:34:53.020
want to upload it to a shared storage. For[br]example, Dropbox or any other shared
0:34:53.020,0:34:57.190
storage. And of course, they don't trust[br]the storage. So, again, they use end-to-
0:34:57.190,0:35:05.120
end encryption. So let's assume that this[br]shared storage is indeed dangerous or
0:35:05.120,0:35:11.420
malicious. So, Alice will, of course,[br]again upload the encrypted document to the
0:35:11.420,0:35:17.490
attacker in this case, will perform some[br]targeted modification of that, and will
0:35:17.490,0:35:22.290
send the modified documents back to Bob,[br]who will happily put in the password
0:35:22.290,0:35:26.800
because from his point of view, it's[br]undistinguishable from the original
0:35:26.800,0:35:32.880
document and the original plain text will[br]be leaked back to the attacker, breaking
0:35:32.880,0:35:39.730
the confidentiality. So let's take a look[br]at the first attack on how we did that.
0:35:39.730,0:35:43.410
That's the direct exfiltration, so[br]breaking the cryptography without touching
0:35:43.410,0:35:51.360
any cryptography, as I like to say. But[br]first, encryption in, in a nutshell, PDF
0:35:51.360,0:35:54.570
encryption. So you have seen the structure[br]of the PDF document. There is a header
0:35:54.570,0:35:59.990
with a version number. There's a body[br]where all the interesting objects live. So
0:35:59.990,0:36:06.820
there is our confidential content that we[br]want to actually, well, to actually
0:36:06.820,0:36:14.740
exfiltrate as an attacker. And finally,[br]there is Xref table and the trailer. So
0:36:14.740,0:36:19.730
what changes if we decide to encrypt this[br]document? Well, actually, not a whole lot.
0:36:19.730,0:36:24.080
So instead of confidential data, of[br]course, there's now some encrypted
0:36:24.080,0:36:29.010
ciphertext. Okay. And the rest pretty much[br]remains the same. The only thing that is
0:36:29.010,0:36:36.960
added is a new value in the trailer that[br]tells us how to decrypt this data again.
0:36:36.960,0:36:43.560
So there's pretty much of the structure[br]left unencrypted. And we thought about:
0:36:43.560,0:36:50.120
Why is this? And we took a look at the[br]standard. So, this is an excerpt from the
0:36:50.120,0:36:55.940
PDF specification and I've highlighted the[br]interesting parts for you. Encryption is
0:36:55.940,0:37:00.690
only applied to strings and streams. Well,[br]those of the values that actually can
0:37:00.690,0:37:07.640
contain any text in the document and all[br]other objects are not encrypted. And that
0:37:07.640,0:37:12.270
is because, well, they want to allow[br]random access to the whole document. So no
0:37:12.270,0:37:17.600
parsing the whole document before actually[br]showing page 16 of the encrypted document.
0:37:17.600,0:37:24.560
Well, that seems kind of reasonable. So,[br]but that also means that the whole
0:37:24.560,0:37:27.970
documents structure is unencrypted and[br]only the streams and strings are
0:37:27.970,0:37:31.380
encrypted. This reveals a lot of[br]information to an attacker that he or she
0:37:31.380,0:37:36.420
shouldn't have probably. That's for one[br]the number and size of pages, that's the
0:37:36.420,0:37:42.610
number and size of objects in the document[br]and that's also including any links, so
0:37:42.610,0:37:48.120
any hyperlinks in document that are[br]actually there. So, that's a lot of
0:37:48.120,0:37:55.260
information an attacker probably shouldn't[br]have. So, next we thought maybe we can do
0:37:55.260,0:38:01.270
some more stuff. Can we add our own[br]unencrypted content? And we took a look at
0:38:01.270,0:38:05.910
the standard again and found that our so-[br]called crypt filters, which provide finer
0:38:05.910,0:38:10.750
granularity control of the encryption.[br]This basically means as an attacker, I can
0:38:10.750,0:38:15.920
change a document to say, hey, only[br]strings in this document are encrypted and
0:38:15.920,0:38:21.340
streams are unencrypted. That's what the[br]identity filter is for. I have no idea why
0:38:21.340,0:38:27.190
they decided to add that to a document[br]format, but it's there. So that means
0:38:27.190,0:38:31.570
their support for partial encryption and[br]that means attackers content can be mixed
0:38:31.570,0:38:36.880
with actual encrypted content. And we[br]found 18 different techniques to do that
0:38:36.880,0:38:42.290
in different readers. So there is a lot of[br]ways to do that in the different readers.
0:38:42.290,0:38:48.150
So let's have a look at a demo. So we have[br]this document, this encrypted document, we
0:38:48.150,0:38:54.170
put in our password and get our secret[br]message. We now open it again in a text
0:38:54.170,0:39:00.140
editor. We see, in object 4 0 down here,[br]there's the actual ciphertext of the
0:39:00.140,0:39:06.110
object, so of the message, and we see it's[br]AES encrypted, with a 32 byte key, so it's
0:39:06.110,0:39:15.670
AES-256. OK. Now we decide to add a new[br]object that contains, well, plaintext.
0:39:15.670,0:39:22.220
And, well, we simply add that to the[br]contents array of this document. So, we
0:39:22.220,0:39:28.241
say "Display this on the first page", save[br]the document. We open it, and we'll put in
0:39:28.241,0:39:38.300
our password and, oh well, this is indeed[br]awkward. OK. So, now, we have broken the
0:39:38.300,0:39:44.160
integrity of an encrypted document. Well,[br]you might think maybe they didn't want any
0:39:44.160,0:39:49.190
integrity in the encrypted files. Maybe[br]that's the use case people have, I don't
0:39:49.190,0:39:55.060
know. But we thought, maybe we can somehow[br]exfiltrate the plaintext this way. So
0:39:55.060,0:40:00.040
again, we took a step back, and looked at[br]the PDF specification. And the first thing
0:40:00.040,0:40:06.080
we found were so-called submit-form[br]actions. And that's basically the same as
0:40:06.080,0:40:10.550
a form on a website. You can put in data.[br]You might have seen this in a contract, in
0:40:10.550,0:40:14.740
a PDF contract, where you can put in your[br]name, and your address, and so on, and so
0:40:14.740,0:40:23.330
on, and the data that is saved inside of[br]that is saved in strings and streams. And
0:40:23.330,0:40:27.760
now remember that is everything that is[br]encrypted in a document. And, of course,
0:40:27.760,0:40:32.101
you can also send that back to an[br]attacker, or well, to a legitimate use
0:40:32.101,0:40:37.890
case, of course, via clicking a button,[br]but clicking buttons is pretty lame. So we
0:40:37.890,0:40:42.120
again looked at the standard and found the[br]so-called open action. And that is an
0:40:42.120,0:40:47.190
action, for example, submitting a form[br]that can be performed upon opening a
0:40:47.190,0:40:54.980
document. So how might this look? This is[br]how a PDF form looks, already with the
0:40:54.980,0:41:01.390
attack applied. So, we've got an URL here[br]that is unencrypted, because all strings
0:41:01.390,0:41:07.400
in this document are unencrypted, and[br]we've got the value object 2 O, where the
0:41:07.400,0:41:13.335
actual encrypted data lives. So, that is[br]the value of the form fields. And what
0:41:13.335,0:41:17.120
will happen on the attacker side as soon[br]as this document is opened? Well, we'll
0:41:17.120,0:41:24.540
get a post request with a confidential[br]content. Let's have a demo. Again, we have
0:41:24.540,0:41:30.620
this document. We put in our password.[br]It's the original document you have
0:41:30.620,0:41:36.160
already seen. We reopen it in a text[br]viewer, or a text editor, again see it's
0:41:36.160,0:41:44.160
encrypted, and we decide to change all[br]strings to the identity filter. So, no
0:41:44.160,0:41:49.480
encryption is applied to strings from now[br]on. And then we add a whole blob of
0:41:49.480,0:41:55.940
information for the open action, and for[br]the form. So this will be op- this will be
0:41:55.940,0:42:00.350
performed, as soon as the document is[br]opened. There is a URL, p.df, and the
0:42:00.350,0:42:07.540
value is the encrypted object 4 0. We[br]start an HTTP server on the domain we
0:42:07.540,0:42:12.970
specified, we open the document, put in[br]the password again, and as soon as we open
0:42:12.970,0:42:17.770
the document Adobe will helpfully show us[br]a warning, but they will already click the
0:42:17.770,0:42:22.170
button for remembering that for the[br]future. And if you accept that, you will
0:42:22.170,0:42:29.390
see your secret message on the attacker[br]server. And that is pretty bad already.
0:42:29.390,0:42:36.480
OK. The same works for hyperlinks, so, of[br]course, there are links in PDF documents,
0:42:36.480,0:42:43.600
and as on the Web, we can define a base[br]URL for hyperlinks. So we can say all URLs
0:42:43.600,0:42:49.940
from this document start with http://p.df.[br]And of course we can define any object as
0:42:49.940,0:42:57.260
a URL. So any object we prepared this way[br]can be sent as a URL, and that will, of
0:42:57.260,0:43:01.180
course, trigger a GET request upon opening[br]the document again, if you defined an open
0:43:01.180,0:43:08.750
action for the same object. So again,[br]pretty bad and breaks confidentiality. And
0:43:08.750,0:43:16.380
of course, everybody loves JavaScript in[br]PDF files, and that works as well. Okay.
0:43:16.380,0:43:21.350
Let's talk about ciphertext attacks, so[br]actual cryptographic attacks, no more not
0:43:21.350,0:43:29.190
touching the crypto. So you might remember[br]the efail attacks on OpenPGP and S/MIME,
0:43:29.190,0:43:34.160
and those had basically three[br]prerequisites. 1: Well, ciphertext
0:43:34.160,0:43:38.690
malleability, so it's called malleability[br]gadgets. That's why we need ciphertext
0:43:38.690,0:43:43.850
malleability, and we've got no integrity[br]protection, that's a plus. Then we need
0:43:43.850,0:43:48.680
some known plaintext for actual targeted[br]modifications. And we need an exfiltration
0:43:48.680,0:43:53.070
channel to send the data back to an[br]attacker. Well, exfiltration channels are
0:43:53.070,0:43:59.730
already dealt with as we have hyperlinks[br]and forms. So we can already check that.
0:43:59.730,0:44:05.800
Nice. Let's talk about ciphertext[br]malleability, or what we call gadgets. So,
0:44:05.800,0:44:10.180
some of you might remember this from[br]crypto 101, or whatever lecture you ever
0:44:10.180,0:44:15.290
had on cryptography. This is the[br]decryption function of CBC, so cipher
0:44:15.290,0:44:24.030
block chaining. And it's basically, you've[br]got your ciphertext up here, and your
0:44:24.030,0:44:29.730
plaintext down here. And it works by[br]simply decrypting a block of ciphertext,
0:44:29.730,0:44:35.850
XORing the previous block of ciphertext[br]onto that, and you'll get the plaintext.
0:44:35.850,0:44:41.070
So what happens, if you decide to change a[br]single bit in the ciphertext, for example,
0:44:41.070,0:44:47.530
the first bit of the initialization[br]vector? Well, that same bit will flip in
0:44:47.530,0:44:53.110
the actual plaintext. Wait a second. What[br]happens, if you happen to know a whole
0:44:53.110,0:45:00.150
plaintext block? Well, we can XOR that[br]onto the first block, and basically get
0:45:00.150,0:45:05.890
all zeros, or what we call a gadget, or a[br]blank sheet of paper, because we can write
0:45:05.890,0:45:14.130
on that by taking a chosen plaintext and[br]XORing that onto this results. And this
0:45:14.130,0:45:18.740
way we can, for example, construct URLs in[br]the actual ciphertext, or in the actual
0:45:18.740,0:45:24.420
resulting plaintext. What we can also do[br]with these gadget is, gadgets is moving
0:45:24.420,0:45:28.580
them somewhere else in the document,[br]cloning them, so we can have multiple
0:45:28.580,0:45:34.150
gadgets, at multiple places in the[br]ciphertext. But remember, if you do that,
0:45:34.150,0:45:37.800
there's always the avalanche effect of[br]CBC, so you will have some random bytes in
0:45:37.800,0:45:45.590
here, but the URL still remains in place.[br]Okay. That's ciphertext malleability done.
0:45:45.590,0:45:50.610
As I've said we need some plaintext. We[br]need to have some known plaintext. And as
0:45:50.610,0:45:54.460
the PDF standard has been pretty helpful[br]up until now, in breaking PDF encryption,
0:45:54.460,0:46:02.071
let's take a look again. And what we found[br]here: Permissions. So a PDF documents can
0:46:02.071,0:46:08.040
have different permissions for the author,[br]and the user of the document. This
0:46:08.040,0:46:11.020
basically means the author can edit the[br]document and the users might not be able
0:46:11.020,0:46:16.060
to do that. And of course, people started[br]to change with that- started to tamper
0:46:16.060,0:46:20.220
with that value, if it was left[br]unencrypted, so in the newest version, it
0:46:20.220,0:46:27.310
was decided this should be encrypted as a[br]16 byte value. So we've got 16 bytes. How
0:46:27.310,0:46:30.890
do they look? Well, at first, we need room[br]for extension. We need lots of
0:46:30.890,0:46:36.100
permissions. Then we put 4 bytes of the[br]actual permission value - That is also in
0:46:36.100,0:46:42.270
unencrypted form in document. Then we need[br]one byte for encrypted metadata, and for
0:46:42.270,0:46:46.840
some reason we need some acronym, "adb",[br]I'll leave it to you to figure out what
0:46:46.840,0:46:52.700
that stands for. And finally, we've got[br]four random bytes, because we have to fill
0:46:52.700,0:47:00.260
up 16 bytes, and we have run out of ideas.[br]Okay. We take all of that, encrypt it, and
0:47:00.260,0:47:05.980
oh well, we know a lot of that, and that[br]is basically known plaintext by design.
0:47:05.980,0:47:12.940
Which is bad. Let's look at how this looks[br]in a document. So, you see the perms
0:47:12.940,0:47:16.410
value, I've marked it down here. That is[br]the actual extended value I've shown you
0:47:16.410,0:47:22.750
on the last slide. And above that you'll[br]see the unencrypted value that's inside
0:47:22.750,0:47:28.030
this perms value, so the minus 4 in this[br]case, it's basically a bit field. On the
0:47:28.030,0:47:33.610
right side you see the actual encrypted[br]contents, and helpfully, all of this is
0:47:33.610,0:47:37.750
encrypted under the same document-wide key[br]in the newest version of the
0:47:37.750,0:47:43.510
specification. And that means we can you[br]reuse this plaintext anywhere in the
0:47:43.510,0:47:48.930
document we want, and we can reuse this[br]to build gadgets. To sum that last point
0:47:48.930,0:47:53.190
up for you: Adobe decided to add[br]permissions to the PDF format, and people
0:47:53.190,0:47:56.950
thought of tampering with them. So they[br]decided to encrypt these permissions to
0:47:56.950,0:48:06.360
prevent tampering, and now known plaintext[br]is available to attackers. All right. So
0:48:06.360,0:48:14.330
that's basically all of the prerequisites[br]done, and let's again have a demo. So, we
0:48:14.330,0:48:20.180
again open this document, put in our[br]password, well, as soon as Chrome decides
0:48:20.180,0:48:26.740
to open this document, we put in our[br]password. It's the same as before. Now,
0:48:26.740,0:48:31.630
I've prepared a script for you, because I[br]really can't do this live, and it
0:48:31.630,0:48:35.400
basically does what I've told you. It's[br]getting a blank gadget from the perms
0:48:35.400,0:48:39.670
value. It's generating a URL from that.[br]It's generating a field name, so that it
0:48:39.670,0:48:45.410
will look nice on the server side, we[br]regenerate this document and put a form in
0:48:45.410,0:48:50.080
there. We start a web server, open this[br]modified document, put in the password
0:48:50.080,0:48:55.540
again and oh well, Chrome doesn't even[br]ask. So as soon as this document is opened
0:48:55.540,0:48:59.160
in Chrome and the password is put in,[br]we'll get our secret message delivered to
0:48:59.160,0:49:07.080
the attacker.[br]Applause
0:49:07.080,0:49:13.510
So we took a look at 27 viewers and found[br]all of them vulnerable to at least one of
0:49:13.510,0:49:18.390
our attacks. So some of them work with no[br]user interaction as we have seen in
0:49:18.390,0:49:22.730
Chrome. Some work with user interaction in[br]specific cases, as you've seen with Adobe
0:49:22.730,0:49:30.660
with a warning, but generally all of these[br]were attackable in one way or the other.
0:49:30.660,0:49:35.670
So what can be done about all of this?[br]Well, you might think signatures might
0:49:35.670,0:49:40.250
help. That's usually the first point[br]people bring up: "A signature on the
0:49:40.250,0:49:46.550
encrypted file will help." Well, no, not[br]really. Why is that? Well, for one, a
0:49:46.550,0:49:50.332
broken signature does not prevent opening[br]the document. So we'll still be able to
0:49:50.332,0:49:54.360
exfiltrate as soon as a password is put[br]in. Signatures can be stripped because
0:49:54.360,0:49:57.700
they're not encrypted. And as you have[br]seen before, they can also be forged in
0:49:57.700,0:50:02.960
most viewers. Signatures are not the[br]answer. Closing exfiltration channels is
0:50:02.960,0:50:08.360
also not the answer because for one, it's[br]hard to do. And how would you even find
0:50:08.360,0:50:14.690
all exfiltrations channels in an 800 pages[br]standard? And I mean, we have barely
0:50:14.690,0:50:18.430
scratched the surface of exfiltration[br]channels. And should we really remove
0:50:18.430,0:50:24.290
forms and hyperlinks from documents? And[br]should we remove JavaScript? OK, maybe we
0:50:24.290,0:50:28.700
should. And finally, if you have to do[br]that, please ask the user before
0:50:28.700,0:50:34.300
connecting to a web server. So let's look[br]at some vendor reactions. Apple decided to
0:50:34.300,0:50:38.680
do exactly what I've told you: to add a[br]dialog to warn the user and even show the
0:50:38.680,0:50:44.460
whole URL with the encrypted plaintext.[br]And Google decided to stop trying to fix
0:50:44.460,0:50:49.830
the unfixable in Chrome. They fixed the[br]automatic exfiltration, but there's really
0:50:49.830,0:50:54.290
nothing they can do about the standard. So[br]this is a problem that has to be done in
0:50:54.290,0:51:00.230
the standard. And that is basically that.[br]For mitigating wrapping attacks, we have
0:51:00.230,0:51:04.110
to deprecate partial encryption and[br]disallow access from unencrypted to
0:51:04.110,0:51:08.450
encrypted objects. And against the gadget[br]attacks, we have to use authenticated
0:51:08.450,0:51:16.221
encryption like AES-GCM. OK. And Adobe has[br]told us that they were escalating this to
0:51:16.221,0:51:19.980
the ISO working group that's now[br]responsible for the PDF standard and this
0:51:19.980,0:51:24.710
will be taken up in the next revision. So[br]that's a win in my book.
0:51:24.710,0:51:30.950
Applause
0:51:30.950,0:51:36.330
Herald: Thank you so much, guys. That was[br]really awesome. Please queue up by the
0:51:36.330,0:51:41.290
microphones if you have any questions, we[br]still have some time left for Q and A. But
0:51:41.290,0:51:45.180
I think your research is really, really[br]interesting because it opens my mind to
0:51:45.180,0:51:51.490
like how would this actually be able to be[br]misused in practice? Like, and I don't
0:51:51.490,0:51:54.760
know, like, what's your take? I guess[br]since you've been working so much with
0:51:54.760,0:51:59.020
this, you must have some kind of idea as[br]to what devious things you could come up
0:51:59.020,0:52:02.680
with.[br]Fabian: I mean, it's still an attacker
0:52:02.680,0:52:08.080
scenario that requires a lot of resources[br]and a very motivated attacker. So this
0:52:08.080,0:52:13.680
might not be very important to the normal[br]user. Let's be real here. So most of us
0:52:13.680,0:52:19.100
are not targeted by the NSA, I guess. So[br]you need an active attacker, an active man
0:52:19.100,0:52:21.070
in the middle to actually perform these[br]attacks.
0:52:21.070,0:52:25.800
Herald: Great. Thank you. And then I think[br]we have a question from microphone number
0:52:25.800,0:52:28.850
four, please.[br]Microphone 4: Yes. You'll said that the
0:52:28.850,0:52:32.700
next standard might have a fix.[br]Do you know a time frame on how long it
0:52:32.700,0:52:41.450
takes to build such a standard?[br]Fabian: Well, no, we don't really know. We
0:52:41.450,0:52:44.640
have talked with Adobe and they told us[br]they will show the next version of the
0:52:44.640,0:52:48.950
standard to us before actually releasing[br]that, but we have no time frame at all
0:52:48.950,0:52:51.950
from them.[br]Microphone 4: OK. Thank you.
0:52:51.950,0:52:57.400
Herald: Thank you.[br]Microphone number five, please.
0:52:57.400,0:53:02.300
Microphone 5: Thank you for a very[br]interesting talk. You showed in the first
0:53:02.300,0:53:09.140
part that the signature has like these[br]four numbers with the byte range. And why
0:53:09.140,0:53:15.580
is this, like four numbers, not part of a[br]signature? Is there a technical reason for
0:53:15.580,0:53:18.480
that? Because the byte offset is[br]predictable.
0:53:18.480,0:53:24.470
Vladi: It is! The bytes ranges protected[br]by the signature. But we just defined the
0:53:24.470,0:53:31.710
second one and just moved the signed one[br]to be validated later. So there are two
0:53:31.710,0:53:37.530
byte ranges. But only the first one, the[br]manipulated one, will be processed.
0:53:37.530,0:53:42.580
Microphone 5: Thank you.[br]Herald: Thank you so much. Microphone
0:53:42.580,0:53:47.940
number four, please.[br]Microphone 4: Oh, this is way too high for
0:53:47.940,0:53:53.870
me. OK. I have an answer and a question[br]for you. You mentioned during the talk
0:53:53.870,0:53:58.690
that you weren't sure how the Department[br]of Justice did distributes the passwords
0:53:58.690,0:54:07.940
for encrypting PDFs. The answer is: in[br]plain text, in a separate email or as the
0:54:07.940,0:54:14.300
password of the week, which is distributed[br]through various means. That is also what
0:54:14.300,0:54:20.370
the Department of Homeland Security does,[br]and the military is somewhat less stupid.
0:54:20.370,0:54:27.030
As a question: I have roughly a half[br]terabyte of sensitive PDFs that I would
0:54:27.030,0:54:36.910
like to scan for your attack and also for[br]redaction failures. Do you know of any
0:54:36.910,0:54:45.560
fast, feasible ways to scan documents for[br]the presence of this kind of attack?
0:54:45.560,0:54:51.970
Fabian: I don't know of any tools, but I[br]mean, scanning for the gadget attacks is
0:54:51.970,0:54:58.390
actually possible if you tried to do some[br]entropy detection. So, because you reuse
0:54:58.390,0:55:01.870
ciphertext, you will have less entropy in[br]your ciphertext, but that's pretty hard to
0:55:01.870,0:55:07.350
do. Direct exfiltration should probably be[br]detectable by scanning simply for words
0:55:07.350,0:55:12.300
like "identity". Well, beyond that, 18[br]different techniques that we provided in
0:55:12.300,0:55:15.980
the paper. But I don't know of any tools[br]to do that automatically.
0:55:15.980,0:55:21.560
Microphone 4: Thank you.[br]Herald: Great. Thank you. And microphone
0:55:21.560,0:55:24.200
number two, please. Microphone 2: Thank[br]you for your very interesting
0:55:24.200,0:55:30.220
presentation. I have one suggestion and[br]one question for the mitigation scheme. If
0:55:30.220,0:55:33.810
you simply run your PDF reader in a[br]virtual machine, that is firewalled away,
0:55:33.810,0:55:38.660
so your firewall won't led you to anybody[br]going out. But for the signature
0:55:38.660,0:55:43.020
forgeries, I had an idea. I'm not sure if[br]this is actually a stupid idea, but did
0:55:43.020,0:55:47.440
you consider faking the certificate?[br]Because presumably the signature is
0:55:47.440,0:55:52.250
protected by the seller's certificate. You[br]make up your own, signing with that. Does
0:55:52.250,0:55:57.670
it catch it and how?[br]Vladi: We considered it but not in this
0:55:57.670,0:56:04.900
paper. We assume that the certificate and[br]the entire chain of trust for this path is
0:56:04.900,0:56:11.750
totally secure. It was just an assumption[br]to just concentrate only on the attacks we
0:56:11.750,0:56:19.600
already found. So, perhaps there will be[br]further research provided by us in the
0:56:19.600,0:56:22.810
next months and years.[br]Herald: We might just hear more from you
0:56:22.810,0:56:27.890
in the future. Thank you so much. And now[br]questions from the Internet, please.
0:56:27.890,0:56:34.800
Signal Angel: I have two questions to the[br]first part of your talk from the Internet.
0:56:34.800,0:56:40.540
The first one is you mentioned a few[br]reactions, but can you give a bit more
0:56:40.540,0:56:46.510
detail about your experience with vendors[br]while reporting these issues?
0:56:46.510,0:56:58.480
Vladi: Yeah. We, ... for the first time we[br]started, we asked the CERT team from BSI,
0:56:58.480,0:57:04.790
CERT-Bund, to help us because there were a[br]lot of affected vendors and we were not
0:57:04.790,0:57:13.580
able to provide the support in a feasible[br]way. So they supported us the entire way.
0:57:13.580,0:57:19.880
We first created the report with,[br]containing the exact description of the
0:57:19.880,0:57:26.190
vulnerabilities and old exploits. Then, we[br]distributed it to the BSI and they
0:57:26.190,0:57:32.540
contacted the vendors and just proxied to[br]the communication and there was a lot of
0:57:32.540,0:57:36.680
communication. So I'm not aware of the[br]entire communication, but only about the
0:57:36.680,0:57:45.930
technical stuff where we were asked to[br]just retest the fix and so on. So there
0:57:45.930,0:57:52.810
was some reaction from Adobe, FoxIt and a[br]lot of viewers reacted on our attacks and
0:57:52.810,0:57:58.210
contacted us, but not everybody.[br]Herald: Thank you so much. Unfortunately,
0:57:58.210,0:58:01.670
that's the only time that we have[br]available for questions today. I think you
0:58:01.670,0:58:06.080
guys might stay around for a couple of[br]minutes, just if someone has any more
0:58:06.080,0:58:10.930
questions. Fabian, I thank ... and[br]Vladislav, not enough. Thank you so much.
0:58:10.930,0:58:13.040
It was very interesting. Please give them[br]a great round of applause.
0:58:13.040,0:58:14.793
Valdi: Thank you.[br]Applause
0:58:14.793,0:58:20.299
36c3 postroll music
0:58:20.299,0:58:43.000
subtitles created by c3subtitles.de[br]in the year 2019. Join, and help us!