36C3 - How to Break PDFs

36c3 preroll music

Herald: The next talk is on how to break
PDF's, breaking the encryption and the

signatures, by Fabian Ising and Vladislav
Mladenov. Their talk was accepted at CCS

this year in London and they had that in
November. It comes from research that

basically produced two different kinds of
papers and it has been... people worldwide

have been interested in what has been
going on. Please give them a great round

of applause and welcome them to the stage.

Applause

Vladi: So can you hear me? Yeah. Perfect.
OK. Now you can see the slides. My name is

Vladislav Mladenov, or just Vladi if you
have some questions to me and this is

Fabian. And we are allowed today to talk
about how to break PDF security or more

special about how to break the
cryptography operations in PDF files. We

are a large team from university of
Bochum, Mue nster and Hackmanit GmbH. So as

I mentioned: We will talk about
cryptography and PDF files. Does it work?

Fabian: All right. OK. Let's try that
again. Okay.

Vladi: Perfect. This talk will consist of
two parts. The first part is about

digitally signed PDF files and how can we
recognize such files? If we open them we

see the information regarding that the
file was signed and all verification

procedures were valid. And more
information regarding the signature

validation panel and information about who
signed this file. This is the first part

of the talk and I will present this topic.
And the second part is regarding PDF

encrypted files and how can we recognize
such files? If you tried to open such

files, the first thing you see is the
password prompt. And after entering the

correct password, the file is decrypted
and you can read the content within this

file. If you open it with Adobe,
additional information regarding if this

file is secured or not is displayed
further. And this is the second part of

our talk, and Fabian, will talk: how can
we break the PDA encryption? So before we

start with the attacks on signatures or
encryption, we first need some basics. And

after six slides, you will be experts
regarding PDF files and you will

understand everything about it. But maybe
it's a little bit boring, so be patient:

there are only 6 slides. So the first is
quite easy. PDF files are... the first

specification was in 1993 and almost at
the beginning PDF cryptography operations

like signatures and encryption was already
there. The last version is PDF 2.0 and it

was released in 2017. And according to
Adobe 1.6 billion files are on the web and

perhaps more exchange beyond the web. So
basically PDF files are everywhere. And

that's the reason why we consider this
topic and tried to find or to analyze the

security of the features. If we have some
very simple file and we open it with Adobe

Reader, the first thing we see is, of
course, the content. "Hello, world!" in

this case, and additional information
regarding the focused page and how many

pages this document has. But what would
happen if we don't use a PDF viewer and

just use some text editor? We use the
Notepad++ to open and later manipulate the

files. So I will zoom this thing... this
file. And the first thing we see is that

we can read it. Perhaps it's quite, quite
funny. And but we can still extract some

information of this file. For example,
some information regarding the pages. And

here you can see the information that the
PDF file consists of one page. But more

interesting is that we can see the
content of the file itself. So the lessons

we learned is that we can use a simple
text editor to view and edit PDF files.

And for our attacks, we used only this
text editor. So let's go to the details.

How PDF files are structured and how they
are processed. PDF files consist of 4

parts: header, body and body is the most
important part of the PDF files. The body

contains the entire information presented
to the user. And 2 other sections: Xref

section and trailer. Very important think
about processing PDF files, is that

they're processed not from the top to the
bottom, but from the bottom to the top. So

the first thing is that the PDF viewer
analyses or processes is the trailer. So

let's start doing that. What information
is starting this trailer? Basically, there

are two very important informations. On
the first side this is the information:

what is the root element of this PDF? So
which is the first object which will be

processed? And the second important
information is where the Xref section

starts. It's just a byte offset pointing
to the position of the XRef section within

the PDF file. So this pointer, as
mentioned before, points to the Xref

section. But what is the Xref section
about? The Xref section is a catalog

pointing or holding the information where
the objects defined in the body are

contained or the byte positions of this
object. So how can we read this weird Xref

section? The first information we extract
is that the first object, which is defined

here, is the object with ID 0 and we have
5 further elements or objects which are

defined. So the first object is here. The
first entry is the byte position within

the file. The second is its generation
number. And the last charter points, if

this object is used or not used. So
reading it, reading this Xref section, we

extract the information that the object
with ID 0 is at byte position 0 and is not

in use. So the object with ID 1 is at the
position 9 and so on and so forth. So for

the object with ID 4 and the object number
comes from counting it: 0 1, 2, 3 and 4.

So the object with ID 4 can be found at
the offset 184 and it's in use. In other

words, the PDF viewer knows where each
object will be found and can properly

display it and process it. Now we come to
the most important part: the body, and I

mentioned it that in the body the entire
content which is presented to the user is

contained. So let's see. Object 4 0 is
this one and as you can see, it contains

the word "Hello World". The other objects
are a reference, too. So each pointer

points exactly to the starting position of
each of the objects. And how can we read

this object? You see, we have an object
starting with the ID number, then the

generation number and the word "obj". So
you now know where the object starts

and when it ends. Now how can we process
this body? As I mentioned before in the

trailer, there was a reference regarding
the root element and this element was with

ID 1 and generation number 0. So, we now
we start reading the document here and we

have a catalog and a reference to some
pages. Pages is just a description of all

the pages contained within the file. And
what can we see here is that we have this

number count once or we have only one page
and a reference to the page object which

contains the entire information
inscription of the page. If we have

multiple pages, then we will have here
multiple elements. Then we have one page.

And here we have the contents, which is a
reference to the string we already saw.

Perfect. If you understand this then you
know everything or almost everything about

PDF files. Now you can just use your
editor and open such files and analyze

them. Then we need one feature... I forgot
the last part. The most simple one. The

header. It should just one line stating
which version is used. For example, in our

case, 1.4. For the last version of Adobe
here will be stated 2.0. Now, we need this

one feature called "Incremental Update".
And I call this feature - do you know this

feature highlighting something in the PDF
file or putting some sticky notes?

Technically, it's called "incremental
update." I just call it reviewing master

and bachelor thesis of my students because
this is exactly the procedure I follow. I

just read the text and highlight something
and store the information I put at it.

Technically by putting such a sticky note.
this additional information is appended

after the end of the file. So we have a
body update which contains exactly the

information additionally of the new
objects and of course, new Xref section

and a new trailer pointing to this new
object. Okay, we are done. Considering

incremental update, we saw that it is used
mainly for sticky notes or highlighting.

But we observed something which is very
important because an incremental update we

can redefine existing objects, for
example, we can redefine the object with

ID 4 and put new content. So we replace in
this manner the word "Hello World" with

another sentence and of course the Xref
section and the trailer point to this new

object. So this is very important. With
incremental update we are not stuck to

only adding some highlighting or notes. We
can redefine already existing content and

perhaps we need this for the attacks we
will present. So let's talk about PDF

signatures. First, we need a difference
between electronic signature and digital

signature. Electronic signature. From a
technical point of view, it's just an

image. I just wrote it on my PC and put it
into the file. There is no cryptographic

protection. It could be me lying on the
beach doing something. From cryptographic

point of view is the same. It does not
provide any security, any cryptographic

security. What we will talk about here is
about digitally signed files, so if you

open such files, you have the additional
information regarding the validation about

the signatures and who signed this PDF
file. So as I mentioned before, this talk

will concentrate only on these digitally
signed PDF files. How? What kind of

process is behind digitally signing PDF
files? Imagine we have this abstract

overview of a PDF document. We have the
header, body, Xref section and trailer. We

want to sign it. What happens is that we
take this PDF file and via incremental

update we put additional information
regarding that. There is a new catalog and

more important, a new signature object
containing the signature value and

information about who signed this PDF
file. And of course, there is an Xref

section and trailer. And relevant for you:
The entire file is now protected by the

PDF signature. So manipulations within
this area should not be possible, right?

Yeah, let's talk about this: why it's not
possible and how can we break it? First,

we need an attack scenario. What we want
to achieve as an attacker. We assumed in

our research that the attacker possesses
this signed PDF file. This could be an old

contract, receipt or, in our case, a bill
from Amazon. And if we open this file, the

signature is valid. So everything is
green. No warnings are thrown and

everything is fine. What we tried to do is
to take this file, manipulate it somehow

and then send it to the victim. And now
the victim expects to receive a digitally

signed PDF file, so just tripping the
digital signature is a very trivial

scenario and we did not consider it
because it's trivial. We considered that

the victim expects to see that there is a
signature and it is valid. So no warning

casts are thrown and the entire left side
is exactly the same from the normal

behavior. But on the other side, the
content was exchanged so we manipulated

the receipt and exchanged it with another
content. The question is now: how can we

do it on a technical level? And we came up
with three attacks: incremental saving

attacks, signature wrapping and universal
signature forgery. And I will now

introduce the techniques and how these
attacks are working. The first attack is

the incremental saving attack. So I
mentioned before that via incremental

saving or via incremental updates, we can
add and remove and even redefine already

existing objects and the signature still
stays valid. Why is this happening?

Consider now again our case. We have some
header, body, Xref table and trailer and

the file is now signed and the signature
protects only the signed area. So what

would happen if I put a sticky note or
some highlighting? An incremental update

happens. If I open this file, usually this
happens: We have the information that this

signature is valid, when it was signed and
so on and so forth. So our first idea was

to just put new body updates, redefine
already existing content and with a Xref

table and trailer we point to the new
content. This is quite trivial because

it's a legitimate feature in PDF files, so
we didn't expect to be quite successful

and we were not so successful. But the
first idea: we applied this attack, we

opened it and we got this message. So it's
kind of a weird message because an

experienced user sees valid, but the
document has been updated and you should

know what does this exactly mean. But we
did not consider this attack as successful

because the warning is not the same or the
status of the signature validation is not

the same. So what we did is to evaluate
this first against this trivial case,

against older viewers we have, and Libre
office, for example, was vulnerable

against this trivial attack. This was the
only viewer which was vulnerable against

this trivial variation. But then we asked
ourselves: Okay, the other viewers are

quite secure. But how do they detect these
incremental updates? And from developer

point of view, the laziest thing we can do
is just to check if another Xref table and

trailer were added after the signature was
applied. So we just put our body updates

but just deleted the other two parts. This
is not a standard compliant PDF file. It's

broken. But our hope was that the PDF
viewer fixes this kind of stuff for us and

that these viewers are error-tolerant. And
we were quite successful because the

verification logic just checked: Is there
an Xref table and trailer after the

signature was applied? No? Okay.
Everything's fine. The signature is valid.

No warning was thrown. But then the
application logic saw that incremental

updates were applied and fixed this for us
and processed these body updates and no

warning was thrown. Some of the viewers
required to have a trailer. I don't know

why - it was a Black box testing. So we
just removed the Xref table, but the

trailer was there and we were able to
break further PDF viewers. The most

complex variation of the attack was the
following: We had the PDF viewers checked

if every incremental update contains a
signature object. But they did not check

if this signature is covered by the
incremental update. So we just copy-pasted

the signature which was provided here and
we just forced the PDF viewer to validate

this signed content twice - and still our
body updates were processed and for

example, Foxit or Master PDF were
vulnerable against this type of attack. So

the evaluation of our attack: We
considered as part of our evaluation 22

different viewers - among others, Adobe
with different versions, Foxit, and so on.

And as you can see 11 of 22 were
vulnerable against incremental saving. So

50 percent, and we were quite surprised
because we saw that the developers saw

that incremental updates could be
dangerous regarding the signature

validation. But we were still able to
bypass their considerations. We had - a

full signature bypass means that there is
no possibility for the victim to detect

the attack. A limited signature bypass
means that the victim, if the victim

clicks on one - at least one - additional
window and explicitly wants to validate

the signature, then the viewer was
vulnerable. But the most important thing

is by opening the file, there was a status
message that the signature validation and

all signatures are valid. So this was the
first layer and the viewers were

vulnerable against this. So let's talk
about the second attack class. We called

it "signature wrapping attack" and this is
the most complex attack of the 3 classes.

And now we have to go a little bit into
the details of how PDF signatures are

made. So imagine now we have a PDF file.
We have some header and the original

document. The original document contains
the header, the body, the Xref section and

so on and so forth. And we want to sign
this document. Technically, again, an

incremental update is provided and we have
a new catalog here. We have some other

objects, for example, certificates and so
on and the signature objects. And we will

now concentrate on this signature object
because it's essential for the attack we

want to to carry out. And the signature
object contains a lot of information, but

we want for this attacks only two elements
are relevant: The contents and the byte

range. The contents contains the signature
value. It's a PKCS7 container containing

the signature value and the certificates
used to validate the signature and the

bytes range. The byte range contains four
different values and what how these values

are being used. The first two, A and B
define the first signed area. And this is

here from the beginning of the document
until the start of the signature value.

Why we need this? Because the signature
value is part of the signed area. So we need

to exclude the signature value from the
document computation. And this is how the

bytes range is used. The first part is
from the beginning of the document until

the signed the signature value starts and
after the signature ends until the end of

the file is the second area specified by
the two digits C and D. So, now we have

everything protected besides the signature
value itself. What we wanted to try is to

create additional space for our attacks.
So our idea was to move the second signed

area. And how can we do it? So basically
we can do it by just defining another byte

range. And as you can see here, the byte
range points from area A to B. So this

area we didn't made any manipulation in
this part, right? It was not modified at

all. So it's still valid. And the second
part, the new C value and the next D

bytes, we didn't change anything here,
right? So basically, we didn't changed

anything in the signed area. And the
signature is still valid. But what we

created was a space for some malicious
objects; sometimes we needed some padding

and a new extra section pointing to this
malicious objects. Important thing was

that this malicious Xref sections, the
position is defined by the trailer. And

since we can not modify this trailer, this
position is fixed. So this is the only

limitation of the attack, but it works
like a charm. And the question is now: How

many PDF viewers were vulnerable against
this attack? And as you can see, this is

the signature wrapping column. 17 out of
22 applications were vulnerable against

this attack. This was quite expected
result because the attack was complex we

saw that many developers didn't, were not
aware of this threat and that's the reason

why so many vulnerabilities were there.
Now to the last class of attacks,

universal signature forgery. And we called
it universal signature forgery, but I

preferred to use another definition for
this attacks. I call them stupid

implementation flaws. We are coming from
the PenTesting area and I know a lot of

you are PenTesters, too. And, many of you
have experience, quite interesting

experience with zero bytes, null values or
some kind of weird values. And this is

what we tried in this kind of attacks.
Just tried to do some stupid values or

remove references and see what happen.
Considering the signature, there are two

different important elements: The contents
containing the signature value and the

byte range pointing to what is exactly
signed. So, what would happen if we remove

the contents? Our hope was that the
information regarding the signature is

still shown by the viewer as valid without
validating any signature because it was

not possible. And by just removing the
signature value is quite obvious idea. And

we were not successful with this kind of
attack. But let's proceed with another

values like for example, contents without
any value or contents like equals NULL or

zero bytes. And considering this last
version, we had two viewers which were

vulnerable against this attack. And
another, another case is, for example, by

removing the byte range. By removing this
byte range we have some signature value,

but we don't know what is exactly signed.
So, we tried this attack and of course,

byte range without any value or NULL bytes
or byte range with a minus or negative,

negative numbers. And usually this last
crashed very a lot of viewers. But the

most interesting is that Adobe made this
mistake by just removing the byte range.

We were able to bypass the entire
security. We didn't expect this behavior,

but it was a stupid implementation flaw,
allowing us to do anything in this

document and all the exploits we show in
our presentations were made on Adobe with

this attack. So let's see what were the
results of this attack. As you can see,

only 4 of 22 viewers were vulnerable
against this attack and only Adobe

unlimited; for the others, there was
limitation because if you click on the

signature validation, then a warning was
thrown. It was very easy for Adobe to fix.

And as you can see, Adobe didn't mistake,
made any mistake regarding incremental

saving, a signature wrapping, but
regarding controversial signature forgery.

There were vulnerable against this attack.
And this was the hope of our approach. In

summary, we were able to break 21 of 22
PDF viewers. The only

Applause
Thanks.

Applause
The only secure PDF viewer is Adobe 9,

which is deprecated and has remote code
execution. The only

Laugh
The only users allowed to use them or are

using it are Linux users, because this is
the last version available for Linux and

that's the reason why you consider it. So,
I'm done with the talk about PDF

signatures and now Fabian can talk about
PDF encryption. Thank you.

Fabian: Yes
Applause

OK, now that we have dealt with the
signatures, let's talk about another

cryptographic aspect in PDFs. And that is
encryption. And some of you might remember

our PDFex vulnerability from earlier this
year. It's, of course, an attack with a

logo and it presents two novel tech
techniques targeting PDF encryption that

have never been applied to PDF encryption
before. So one of them is these so-called

direct exfiltration where we break the
cryptography without even touching the

cryptography. So no ciphertext
manipulation here. The second one as so-

called malleability gadgets. And those are
actually targeted modifications of the

ciphertext of the document. But first,
let's take a step back and let again take

some keywords in. So PDF uses AES. OK.
Well, AES is good. Nothing can go wrong,

right? So let's go home. Encryption is
fine. Well, of course, we didn't stop

here, but took a closer look. So they use
CBC mode of operation, so cipher block

chaining. And, what's more important is
that they don't use any integrity

protection. So it's unintegrity protected
AES-CBC. And you might remember the

scenario from the attacks against
encrypted e-mail, so against OpenPGP and

S-MIME, it's basically the same problem.
But first, who actually uses PDF

encryption? You might ask. For one, we
found some local banks in Germany use

encrypted PDFs as a drop-in replacement
for S-MIME or OpenPGP because their

customers might not want to deal with uhm,
set, with the setup of encrypted e-mail.

Second one, were some drop-in plugins for
encrypt e-mail as well. So there are some

companies out there that produce product
that you can put into your outlook and you

can use encrypted PDF files instead of
encrypted email. We also found that some

scanners and medical devices were able to
send encrypted PDF files via e-mail. So

you can set a password on that machine and
they will send the encrypted PDF via

e-mail and you have to put in the
password some other way. And lastly, we

found that some governmental organizations
use encrypted PDF documents, for example,

the US Department of Justice allows for
the send, sending in some claims via

encrypted PDFs. And I've exactly no idea
how you how they get the password, but at

least they allow it. So as we are from
academia, let's take a step back and look

at our attacker model. So we've got Alice
and Bob. Alice wants to send a document to

Bob. And she wants to send it over an
unencrypted channel or a channel she

doesn't trust. So of course, she decides
to encrypt it. Second scenario is, they

want to upload it to a shared storage. For
example, Dropbox or any other shared

storage. And of course, they don't trust
the storage. So, again, they use end-to-

end encryption. So let's assume that this
shared storage is indeed dangerous or

malicious. So, Alice will, of course,
again upload the encrypted document to the

attacker in this case, will perform some
targeted modification of that, and will

send the modified documents back to Bob,
who will happily put in the password

because from his point of view, it's
undistinguishable from the original

document and the original plain text will
be leaked back to the attacker, breaking

the confidentiality. So let's take a look
at the first attack on how we did that.

That's the direct exfiltration, so
breaking the cryptography without touching

any cryptography, as I like to say. But
first, encryption in, in a nutshell, PDF

encryption. So you have seen the structure
of the PDF document. There is a header

with a version number. There's a body
where all the interesting objects live. So

there is our confidential content that we
want to actually, well, to actually

exfiltrate as an attacker. And finally,
there is Xref table and the trailer. So

what changes if we decide to encrypt this
document? Well, actually, not a whole lot.

So instead of confidential data, of
course, there's now some encrypted

ciphertext. Okay. And the rest pretty much
remains the same. The only thing that is

added is a new value in the trailer that
tells us how to decrypt this data again.

So there's pretty much of the structure
left unencrypted. And we thought about:

Why is this? And we took a look at the
standard. So, this is an excerpt from the

PDF specification and I've highlighted the
interesting parts for you. Encryption is

only applied to strings and streams. Well,
those of the values that actually can

contain any text in the document and all
other objects are not encrypted. And that

is because, well, they want to allow
random access to the whole document. So no

parsing the whole document before actually
showing page 16 of the encrypted document.

Well, that seems kind of reasonable. So,
but that also means that the whole

documents structure is unencrypted and
only the streams and strings are

encrypted. This reveals a lot of
information to an attacker that he or she

shouldn't have probably. That's for one
the number and size of pages, that's the

number and size of objects in the document
and that's also including any links, so

any hyperlinks in document that are
actually there. So, that's a lot of

information an attacker probably shouldn't
have. So, next we thought maybe we can do

some more stuff. Can we add our own
unencrypted content? And we took a look at

the standard again and found that our so-
called crypt filters, which provide finer

granularity control of the encryption.
This basically means as an attacker, I can

change a document to say, hey, only
strings in this document are encrypted and

streams are unencrypted. That's what the
identity filter is for. I have no idea why

they decided to add that to a document
format, but it's there. So that means

their support for partial encryption and
that means attackers content can be mixed

with actual encrypted content. And we
found 18 different techniques to do that

in different readers. So there is a lot of
ways to do that in the different readers.

So let's have a look at a demo. So we have
this document, this encrypted document, we

put in our password and get our secret
message. We now open it again in a text

editor. We see, in object 4 0 down here,
there's the actual ciphertext of the

object, so of the message, and we see it's
AES encrypted, with a 32 byte key, so it's

AES-256. OK. Now we decide to add a new
object that contains, well, plaintext.

And, well, we simply add that to the
contents array of this document. So, we

say "Display this on the first page", save
the document. We open it, and we'll put in

our password and, oh well, this is indeed
awkward. OK. So, now, we have broken the

integrity of an encrypted document. Well,
you might think maybe they didn't want any

integrity in the encrypted files. Maybe
that's the use case people have, I don't

know. But we thought, maybe we can somehow
exfiltrate the plaintext this way. So

again, we took a step back, and looked at
the PDF specification. And the first thing

we found were so-called submit-form
actions. And that's basically the same as

a form on a website. You can put in data.
You might have seen this in a contract, in

a PDF contract, where you can put in your
name, and your address, and so on, and so

on, and the data that is saved inside of
that is saved in strings and streams. And

now remember that is everything that is
encrypted in a document. And, of course,

you can also send that back to an
attacker, or well, to a legitimate use

case, of course, via clicking a button,
but clicking buttons is pretty lame. So we

again looked at the standard and found the
so-called open action. And that is an

action, for example, submitting a form
that can be performed upon opening a

document. So how might this look? This is
how a PDF form looks, already with the

attack applied. So, we've got an URL here
that is unencrypted, because all strings

in this document are unencrypted, and
we've got the value object 2 O, where the

actual encrypted data lives. So, that is
the value of the form fields. And what

will happen on the attacker side as soon
as this document is opened? Well, we'll

get a post request with a confidential
content. Let's have a demo. Again, we have

this document. We put in our password.
It's the original document you have

already seen. We reopen it in a text
viewer, or a text editor, again see it's

encrypted, and we decide to change all
strings to the identity filter. So, no

encryption is applied to strings from now
on. And then we add a whole blob of

information for the open action, and for
the form. So this will be op- this will be

performed, as soon as the document is
opened. There is a URL, p.df, and the

value is the encrypted object 4 0. We
start an HTTP server on the domain we

specified, we open the document, put in
the password again, and as soon as we open

the document Adobe will helpfully show us
a warning, but they will already click the

button for remembering that for the
future. And if you accept that, you will

see your secret message on the attacker
server. And that is pretty bad already.

OK. The same works for hyperlinks, so, of
course, there are links in PDF documents,

and as on the Web, we can define a base
URL for hyperlinks. So we can say all URLs

from this document start with http://p.df.
And of course we can define any object as

a URL. So any object we prepared this way
can be sent as a URL, and that will, of

course, trigger a GET request upon opening
the document again, if you defined an open

action for the same object. So again,
pretty bad and breaks confidentiality. And

of course, everybody loves JavaScript in
PDF files, and that works as well. Okay.

Let's talk about ciphertext attacks, so
actual cryptographic attacks, no more not

touching the crypto. So you might remember
the efail attacks on OpenPGP and S/MIME,

and those had basically three
prerequisites. 1: Well, ciphertext

malleability, so it's called malleability
gadgets. That's why we need ciphertext

malleability, and we've got no integrity
protection, that's a plus. Then we need

some known plaintext for actual targeted
modifications. And we need an exfiltration

channel to send the data back to an
attacker. Well, exfiltration channels are

already dealt with as we have hyperlinks
and forms. So we can already check that.

Nice. Let's talk about ciphertext
malleability, or what we call gadgets. So,

some of you might remember this from
crypto 101, or whatever lecture you ever

had on cryptography. This is the
decryption function of CBC, so cipher

block chaining. And it's basically, you've
got your ciphertext up here, and your

plaintext down here. And it works by
simply decrypting a block of ciphertext,

XORing the previous block of ciphertext
onto that, and you'll get the plaintext.

So what happens, if you decide to change a
single bit in the ciphertext, for example,

the first bit of the initialization
vector? Well, that same bit will flip in

the actual plaintext. Wait a second. What
happens, if you happen to know a whole

plaintext block? Well, we can XOR that
onto the first block, and basically get

all zeros, or what we call a gadget, or a
blank sheet of paper, because we can write

on that by taking a chosen plaintext and
XORing that onto this results. And this

way we can, for example, construct URLs in
the actual ciphertext, or in the actual

resulting plaintext. What we can also do
with these gadget is, gadgets is moving

them somewhere else in the document,
cloning them, so we can have multiple

gadgets, at multiple places in the
ciphertext. But remember, if you do that,

there's always the avalanche effect of
CBC, so you will have some random bytes in

here, but the URL still remains in place.
Okay. That's ciphertext malleability done.

As I've said we need some plaintext. We
need to have some known plaintext. And as

the PDF standard has been pretty helpful
up until now, in breaking PDF encryption,

let's take a look again. And what we found
here: Permissions. So a PDF documents can

have different permissions for the author,
and the user of the document. This

basically means the author can edit the
document and the users might not be able

to do that. And of course, people started
to change with that- started to tamper

with that value, if it was left
unencrypted, so in the newest version, it

was decided this should be encrypted as a
16 byte value. So we've got 16 bytes. How

do they look? Well, at first, we need room
for extension. We need lots of

permissions. Then we put 4 bytes of the
actual permission value - That is also in

unencrypted form in document. Then we need
one byte for encrypted metadata, and for

some reason we need some acronym, "adb",
I'll leave it to you to figure out what

that stands for. And finally, we've got
four random bytes, because we have to fill

up 16 bytes, and we have run out of ideas.
Okay. We take all of that, encrypt it, and

oh well, we know a lot of that, and that
is basically known plaintext by design.

Which is bad. Let's look at how this looks
in a document. So, you see the perms

value, I've marked it down here. That is
the actual extended value I've shown you

on the last slide. And above that you'll
see the unencrypted value that's inside

this perms value, so the minus 4 in this
case, it's basically a bit field. On the

right side you see the actual encrypted
contents, and helpfully, all of this is

encrypted under the same document-wide key
in the newest version of the

specification. And that means we can you
reuse this plaintext anywhere in the

document we want, and we can reuse this
to build gadgets. To sum that last point

up for you: Adobe decided to add
permissions to the PDF format, and people

thought of tampering with them. So they
decided to encrypt these permissions to

prevent tampering, and now known plaintext
is available to attackers. All right. So

that's basically all of the prerequisites
done, and let's again have a demo. So, we

again open this document, put in our
password, well, as soon as Chrome decides

to open this document, we put in our
password. It's the same as before. Now,

I've prepared a script for you, because I
really can't do this live, and it

basically does what I've told you. It's
getting a blank gadget from the perms

value. It's generating a URL from that.
It's generating a field name, so that it

will look nice on the server side, we
regenerate this document and put a form in

there. We start a web server, open this
modified document, put in the password

again and oh well, Chrome doesn't even
ask. So as soon as this document is opened

in Chrome and the password is put in,
we'll get our secret message delivered to

the attacker.
Applause

So we took a look at 27 viewers and found
all of them vulnerable to at least one of

our attacks. So some of them work with no
user interaction as we have seen in

Chrome. Some work with user interaction in
specific cases, as you've seen with Adobe

with a warning, but generally all of these
were attackable in one way or the other.

So what can be done about all of this?
Well, you might think signatures might

help. That's usually the first point
people bring up: "A signature on the

encrypted file will help." Well, no, not
really. Why is that? Well, for one, a

broken signature does not prevent opening
the document. So we'll still be able to

exfiltrate as soon as a password is put
in. Signatures can be stripped because

they're not encrypted. And as you have
seen before, they can also be forged in

most viewers. Signatures are not the
answer. Closing exfiltration channels is

also not the answer because for one, it's
hard to do. And how would you even find

all exfiltrations channels in an 800 pages
standard? And I mean, we have barely

scratched the surface of exfiltration
channels. And should we really remove

forms and hyperlinks from documents? And
should we remove JavaScript? OK, maybe we

should. And finally, if you have to do
that, please ask the user before

connecting to a web server. So let's look
at some vendor reactions. Apple decided to

do exactly what I've told you: to add a
dialog to warn the user and even show the

whole URL with the encrypted plaintext.
And Google decided to stop trying to fix

the unfixable in Chrome. They fixed the
automatic exfiltration, but there's really

nothing they can do about the standard. So
this is a problem that has to be done in

the standard. And that is basically that.
For mitigating wrapping attacks, we have

to deprecate partial encryption and
disallow access from unencrypted to

encrypted objects. And against the gadget
attacks, we have to use authenticated

encryption like AES-GCM. OK. And Adobe has
told us that they were escalating this to

the ISO working group that's now
responsible for the PDF standard and this

will be taken up in the next revision. So
that's a win in my book.

Applause

Herald: Thank you so much, guys. That was
really awesome. Please queue up by the

microphones if you have any questions, we
still have some time left for Q and A. But

I think your research is really, really
interesting because it opens my mind to

like how would this actually be able to be
misused in practice? Like, and I don't

know, like, what's your take? I guess
since you've been working so much with

this, you must have some kind of idea as
to what devious things you could come up

with.
Fabian: I mean, it's still an attacker

scenario that requires a lot of resources
and a very motivated attacker. So this

might not be very important to the normal
user. Let's be real here. So most of us

are not targeted by the NSA, I guess. So
you need an active attacker, an active man

in the middle to actually perform these
attacks.

Herald: Great. Thank you. And then I think
we have a question from microphone number

four, please.
Microphone 4: Yes. You'll said that the

next standard might have a fix.
Do you know a time frame on how long it

takes to build such a standard?
Fabian: Well, no, we don't really know. We

have talked with Adobe and they told us
they will show the next version of the

standard to us before actually releasing
that, but we have no time frame at all

from them.
Microphone 4: OK. Thank you.

Herald: Thank you.
Microphone number five, please.

Microphone 5: Thank you for a very
interesting talk. You showed in the first

part that the signature has like these
four numbers with the byte range. And why

is this, like four numbers, not part of a
signature? Is there a technical reason for

that? Because the byte offset is
predictable.

Vladi: It is! The bytes ranges protected
by the signature. But we just defined the

second one and just moved the signed one
to be validated later. So there are two

byte ranges. But only the first one, the
manipulated one, will be processed.

Microphone 5: Thank you.
Herald: Thank you so much. Microphone

number four, please.
Microphone 4: Oh, this is way too high for

me. OK. I have an answer and a question
for you. You mentioned during the talk

that you weren't sure how the Department
of Justice did distributes the passwords

for encrypting PDFs. The answer is: in
plain text, in a separate email or as the

password of the week, which is distributed
through various means. That is also what

the Department of Homeland Security does,
and the military is somewhat less stupid.

As a question: I have roughly a half
terabyte of sensitive PDFs that I would

like to scan for your attack and also for
redaction failures. Do you know of any

fast, feasible ways to scan documents for
the presence of this kind of attack?

Fabian: I don't know of any tools, but I
mean, scanning for the gadget attacks is

actually possible if you tried to do some
entropy detection. So, because you reuse

ciphertext, you will have less entropy in
your ciphertext, but that's pretty hard to

do. Direct exfiltration should probably be
detectable by scanning simply for words

like "identity". Well, beyond that, 18
different techniques that we provided in

the paper. But I don't know of any tools
to do that automatically.

Microphone 4: Thank you.
Herald: Great. Thank you. And microphone

number two, please. Microphone 2: Thank
you for your very interesting

presentation. I have one suggestion and
one question for the mitigation scheme. If

you simply run your PDF reader in a
virtual machine, that is firewalled away,

so your firewall won't led you to anybody
going out. But for the signature

forgeries, I had an idea. I'm not sure if
this is actually a stupid idea, but did

you consider faking the certificate?
Because presumably the signature is

protected by the seller's certificate. You
make up your own, signing with that. Does

it catch it and how?
Vladi: We considered it but not in this

paper. We assume that the certificate and
the entire chain of trust for this path is

totally secure. It was just an assumption
to just concentrate only on the attacks we

already found. So, perhaps there will be
further research provided by us in the

next months and years.
Herald: We might just hear more from you

in the future. Thank you so much. And now
questions from the Internet, please.

Signal Angel: I have two questions to the
first part of your talk from the Internet.

The first one is you mentioned a few
reactions, but can you give a bit more

detail about your experience with vendors
while reporting these issues?

Vladi: Yeah. We, ... for the first time we
started, we asked the CERT team from BSI,

CERT-Bund, to help us because there were a
lot of affected vendors and we were not

able to provide the support in a feasible
way. So they supported us the entire way.

We first created the report with,
containing the exact description of the

vulnerabilities and old exploits. Then, we
distributed it to the BSI and they

contacted the vendors and just proxied to
the communication and there was a lot of

communication. So I'm not aware of the
entire communication, but only about the

technical stuff where we were asked to
just retest the fix and so on. So there

was some reaction from Adobe, FoxIt and a
lot of viewers reacted on our attacks and

contacted us, but not everybody.
Herald: Thank you so much. Unfortunately,

that's the only time that we have
available for questions today. I think you

guys might stay around for a couple of
minutes, just if someone has any more

questions. Fabian, I thank ... and
Vladislav, not enough. Thank you so much.

It was very interesting. Please give them
a great round of applause.

Valdi: Thank you.
Applause

36c3 postroll music

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