 on how to break PDFs, breaking the encryption, and the signatures by Fabian Ising and Vladislav Ladinov. 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. So can you hear me? Yeah, perfect. OK, now you can see the slides. My name is Vladislav Ladinov. I'm just Vlad 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 on Bochum, Mönster, and Haakmanit Gehenbeha. So as I mentioned, we will talk about cryptography in PDF files. Does it work? All right. OK, let's try that again. OK, 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 try 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, we will talk how can we break the PDF encryption. So before we start with the attacks on signatures or encryption, we first need some basics. And after six slides, you will be expert regarding PDF files, and you will understand everything about it. But maybe it's a little bit boring, so be patient. There are only six 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 considered 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, the Hello World in this case, and additional information regarding the focus 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 funny, 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 one page, 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 four 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 two other sections, XF section and trailer. Very important thing about processing PDF files is that they are processed not from the top to the bottom, but from the bottom to the top. So the first thing the PDF viewer analyzes or processes is the trailer. So let's start doing that. What information is stored in 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 XF section starts. It's just a byte offset pointing to the position of these XF sections within the PDF file. So this pointer, as mentioned before, points to the XF section. But what is the XF section about? The XF section is a catalog pointing or holding the information where the objects defined in the body are contained or the byte positions of these objects. So how can we read this weird XF section? The first thing, the first information we extract is that the first object which is defined here is the object with the ID 0 and we have five 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 character points if this object is used or not used. So reading this XF section, we extract the information that the object with the ID 0 is the byte position 0 and it's not in use. So the object with the ID 1 is at the position 9 and so on and so forth. So for the object with the ID 4 and the object number comes from counting it 0, 1, 2, 3, and 4. So the object with the ID 4 can be defined at the offset 184 and is in use. In other words, the PDF viewer knows where each object will be defined and can properly displace 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 world, hello world. The other objects are referenced 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 object starting with the ID number, with then the generation number, and the word object. So you can 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 the 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 1. So we have only one page. And a reference to the page object, which contains the entire information in the description 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 sew. Perfect. If you understand this, then you know 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's 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 these features 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 theses 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 only of the new objects and of course, new Xref section and of a new trailer pointing to these new objects. OK, 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 in Incremental Update, we can redefine existing objects. For example, we can redefine the object with the D4 and put new content. So we replace, in this manner, the world, hello world with another sentence. And of course, the Xref section and the trailer point to these new objects. So this is very important. So we are not with Incremental Update, we are not stick to only adding some highlighting or notes, we can redefine already existing content. And perhaps we need this for the text 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, is 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 a cryptographic point of view is the same. It does not provide any security, any cryptographic security. What we will talk 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 this 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, extra section, and trailer. And we want to sign it. What happens is that we take this PDF file and via incremental update, we put additional information regarding the 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 extra 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 attacker scenario, what we want to achieve. As an attacker, we assumed in our research that the attacker possess this signed PDF file. This could be an old contract, receipt, in our case, a bill from Amazon. And if we open this file, the signature is valid. So everything is green, no warning are thrown, and everything is fine. What we try 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 consider that the victim expects to see that there is a signature, and it is valid. So no warning 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 received and exchanged 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, extract table, and trailer. And the file is now signed. And the signature protects only this 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 the extract 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 weird message because an experienced user sees valid, but the document has been updated, and you should know what this exactly means. 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 trivial case against all the viewers we have. And LibreOffice, 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, OK, 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 extra 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 would fix 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 extra table and trailer after the signature was applied? No. OK, everything is fine. The signature is valid. No warning was thrown. But then the application logic so that incremental updates were applied and fixed this for us. And processed this 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 extra table, but the trailer was there. And we were able to broke 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 the 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 an attack. So the evaluation of our attacks, we consider it 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%. 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 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 call it signature wrapping attack and this is the most complex attack of the all three classes. And now we have to go a little bit into the details 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 extra 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 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 pica CS7 container containing the signature value and the certificates used to validate the signature. And the byte range. The byte range contains four different values and 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 byte range is used. The first part is from the beginning of the document until 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 make any manipulation in this part. 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. So basically, we didn't change 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 XRF section pointing to these malicious objects. Important thing was that these malicious XRF sections, the position is defined by the trailer. And since we cannot 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 complexed. We saw that many developers 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 prefer to use another definition for these 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 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 try to do some stupid values or remove references and see what happened. 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, it's 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 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 minus or negative numbers. And usually, this last crashed 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 four 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 warning was thrown. It was very easy for Adobe to fix. And as you can see, Adobe made any mistake regarding incremental saving and signature wrapping, but regarding universal signature forgery, they 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. Thanks. The only secure PDF viewer is Adobe 9, which is deprecated and has remote code execution. 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. Yes. OK, now that we've dealt with signatures, let's talk about another cryptographic aspect in PDFs. And that is encryption. And some of you might remember our PDFX 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 the so-called direct excretion, where we break the cryptography without even touching the cryptography. So no ciphertext manipulation here. The second one are so-called mediability 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 IS. OK, well, IS is good. Nothing can go wrong, right? So let's go home. Encryption is fine. Well, of course, we didn't stop here. But take a closer look. So they use CBC mode of operation, so cipherblock chaining. And what's more important is that they don't use any integrity protection. So it's an integrity-protected ISCBC. And you might remember the scenario from the attacks against encrypted emails, so against OpenPGP and SMIME. 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 SMIME or OpenPGP, because their customers might not want to deal with the setup of encrypted email. Second one were some drop-in plugins for encrypted email 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 email. So you can set a password on that machine, and they will send the encrypted PDF via email, 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 sending in some claims via encrypted PDFs. And I have exactly no idea how they get the password, but at least they're allowed. So as we are from academia, let's take a step back and look at our attacker model. So we've got Alison Bob. Alice wants to send documents 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. We'll perform some targeted modification of that, and we'll send the modified document back to Bob, who we'll happily put in the password because from his point of view, it's undistinguishable from the original document, and the original plaintext 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 excitation. So breaking the cryptography without touching any cryptography, as I like to say. But first, encryption in a nutshell, PDF encryption. So you have seen the structure of a PDF document. There's a header with a version number. There's a body where all the interesting objects live. So there's our confidential content that we want to actually exfiltrate as an attacker. And finally, there's exfiftable and the trailer. So what changes if we decide to encrypt this document? Well, actually, not a whole lot. So instead of the confidential data, of course, there's now some encrypted ciphertext. OK. 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 are the values that actually can contain any text in a 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 in the whole document before actually showing page 16 of an encrypted document. Well, that seems kind of reasonable. So but that also means that the whole document 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 or any hyperlinks in the 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 there are so-called Crip 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 there's support for partial encryption. And that means attacker's content can be mixed with actual encrypted content. And we found 18 different techniques to do that in different readers. So there's a lot of ways to do that in the different readers. So let's have a look at the 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 the text editor. We see an object for 0 down here. There's the actual ciphertext of the object, so of the message. And we see it's IS encrypted with a 32 byte key, so it's IS 256. OK. Now we decide to add a new object that contains plain text. And we simply add that to the contents array of this document. So we say, display this on the first page, save the document, reopen 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 their encrypted files. Maybe that's the use case people have. I don't know. But we thought maybe we can somehow extra trade the plain text 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's saved inside of that is saved in strings and streams. And I 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, while 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 its strings in this document are unencrypted. And we've got the value, Object 2.0, where the actual encrypted data lives. So that is the value of the form field. 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 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 performed as soon as the document is opened. There's a URL, p.df. And the value is the encrypted object 4.0. We start an HTTP server. On the domain we've 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 prepare this way can be sent as a URL. And that will, of course, trigger a GET request upon opening the document again if we defined an open action for the same object. So again, pretty bad and breaks the confidentiality. And of course, everybody loves JavaScript and PDF files. And that works as well. OK. Let's talk about ciphertext attacks, so actual cryptographic attacks. No more not touching the crypto. So you might remember the eFail attacks on OpenBGP and Asmime. And those are basically three prerequisites. One, well, ciphertext mediability. So it's called mediability gadgets. That's why we need ciphertext mediability. 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 mediability 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 cipherblock 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, exploring the previous block of ciphertext under 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 we 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 result. 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 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 our launch effect of CBC, so you will have some random bytes in here, but the URLs still remains in place. OK, that ciphertext mediability done. As I've said, we need some plaintext. We need to have some known plaintext. And as a PDF standard has been pretty helpful up until now in breaking PDF encryption, let's take a look again. And what we found were permissions. So PDF document 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 value, 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 four bytes of the actual permission value that is also an unencrypted form in document. Then we need one byte for encrypted metadata. And for some reason, we need some actual new 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. OK, 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 see the unencrypted value that's inside this perms value. So the minus 4 in this case is basically a bit filled. 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 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 started tampering with them. So they decided to encrypt these permissions to prevent tampering. And now, plaintext is available to attackers. All right. So that's basically all of the project was 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 palms 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 will get our secret message delivered to the attacker. OK, 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 you have seen in Chrome. Some work with user interaction in specific cases, as you have seen with Adobe, with Warning. But generally, all viewers 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 it will still be extratrated as soon as the password is put in. Signatures can be stripped because they are 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 exfiltration channels in 800 pages standard? And I mean, we have barely scrapped the surface of exfiltration channels. And should we really move forms and hyperlinks from documents? And should we move 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 dialogue, 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 ISGCM. OK. And Adobe has told us that they will be 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. 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&A. But I think your research is really, really interesting, because it opens my mind to how would this actually be able to be misused in practice? And I don't know. 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. 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. Great. Thank you. And then I think we have a question from microphone number four, please. Yes. You 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? 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 for them. OK, thank you. Thank you. Microphone number five, please. Thank you for the 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 the signature? Is there a technical reason for that? Because the byte offset is predictable? It is. The byte range is 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. OK. But only the first one, the manipulated one, will be processed. Thank you. Thank you so much. Microphone number four, please. 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 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? I don't know of any tools, but I mean, scanning for the gadget attacks is actually possible if you try 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 excitation should probably be detectable by scanning simply for words like identity or the other 18 different techniques that we provided in the paper. But I don't know of any tools to do that automatically. Thank you. Great, thank you. And microphone number two, please. Thank you for a 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's firewalled away, so your firewall will alert 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 certificate. You make up your own, sign it with that. Does it catch it and how? We consider it, but not in this paper. We assume that the certificate and the entire chain of trust for this part is totally secure. It was just an assumption to just concentrate only on attacks we already found. So perhaps there will be further research provided by us in the next months and years. We might just hear more from you in the future. Thank you so much. And now, questions from the internet, please. 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? Yeah, for the first time we started, we asked the third team from BSI, let's say, at 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 a report containing the exact description of the vulnerabilities and all the exploits. Then we distributed it to the BSI and they contacted the vendors and just proxied 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 a reaction from Adobe, Foxit, and a lot of viewers reacted on our attacks. And they contacted us, but not everybody. 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 Isink and Vladislav Mladenov, thank you so much. It was very interesting. Please give them a great round of applause. Thank you.