 breaking the encryption and the signatures by Fabien Heising 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. Okay, now you can see the slides. My name is Vladislav Ladinov or just Vlad if you have some questions. 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 the University of Bochum, Mensta and Hackmanit GameBehar. So, as I mentioned, we will talk about cryptography in PDF files. Does it work? All right, let's try that again. Okay, 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 the information procedures were valid, 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 how to distort it. And the second part is regarding PDF and inclusive files and how can we recognize such files? If you try to open such files, the first thing you see is the password prompt, 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 experts regarding PDF files and how to understand everything about it. But maybe it's a little bit boring, so be patient. There are always six slides. So the first is quite easy. PDF files are, the first specification was in 1993 and almost at the beginning of 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 try 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 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 file and the first thing we see is that we can read it. Perhaps it's quite funny and you can still extract some information of this file. For example, you can see the information that one page, the PDF file consists of one page. But the more interesting thing 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 the Files. And for our attacks, we use 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 and the body contains the entire user. And two other sections, extra sections and the trailer. The very important thing about PDF files is that their process is not from the top to the bottom, but from the bottom to the top. So the first thing is that the PDF viewer analyzes the process of this trailer. So let's start from doing that. What information is stored in this trailer? Basically, there are two very important information on the first side. The first thing is what is the root element of this PDF. So which is the base of the PDF, which will be processed. And the second important information is where each transaction starts. It's just a point in the list of these transactions within the PDF file. So this pointer, as mentioned before, points to the extra section. What is the extra section about? The extra section is capital of the pointing or upholding the accumulation where the objects defined in the body are contained or the back of the object. So how can you read this weird extra section? The first information we extract is that the first object defined here is the object with a zero and we have five further elements or objects which are aligned. So the first object is here. The first entry is the byte position within the file. The second entry is the direction number and the last character point if this object is used or not used. So reading this extra section, we extract the information that the object with a zero is the byte position zero and it's like zero. So the object with a D1 is at the position nine and so on and so forth. So the object with a D4 and the object number comes from the object with a D4, one, two, three and four. So the object with a D4 can be found at the position 184 and is used. In other words, the PDF viewer knows where each object is defined and can properly displace it. Now, it comes 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 for zero is this one. And as you can see, it contains the world hello world. The other object I reference to, 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 start with the ID number, we can add the generational as the word object. So you can now know where the object is start and when it ends. Now, how can we process this body? As mentioned before in the trailer, there was a reference regarding the root element. This element was with the ID one and generation number zero. So we now we start with the document here. And we have a catalog and a reference to some pages. And it 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 one, so we have only one page. And a reference to the page object contains the entire information in the description of the page. If we have multiple pages, then we will have your multiple elements. Then we have one page and here we have the contents which is a reference to the screen we already saw. Perfect. If you understand this, then you know almost everything about VF files. Now you can just use your editor and open the 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 we use. For example, in our case, 1.4 for the last version we will be stated as 1.4. 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? I'm technically, it's called incremental update. I just thought we're doing master and bachelor thesis of my students. We can't actually do that. I follow. I just do that and highlight something as far as the information I put in there. Technically, by putting such a sticky note, this additional information is appended after I've entered the file. So we have 40 updates which contains exactly the information only of the job of the additionally of the new objects and of course new extension of the new trailer pointing this new object. Okay, we are done. Considering incremental update, we saw that it is used mainly for sticky notes or highlighting but we observe something which is very important because incremental update, we can redefine existing objects. For example, we can redefine the object before and put new content. So we replace, in this manner, the world, hello world with another sentence. And of course, the exact section and the trailer world point to this new object. So this is very important. So we are not using incremental update. We are not sticking to only adding some highlighting or notes. We can redefine already existing content and perhaps redefine the existing content. So, let's talk about EF signatures. First, we need a difference between electronic signature and digital signature. Electronic signature from electronic 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 or I could be doing something from cryptographic point of view is the same. It does not provide any security, any cryptographic security. What we will talk here is about digital signed files. So if you open such files, you have the additional information regarding the validation about the signatures and to design this PDF file. So, as mentioned before, this talk will concentrate only on this digital signed PDF files. What kind of process is behind digital signing PDF files? Imagine we have this abstract overview of a PDF document. We have the header, body, extra 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 there is a new catalog and more important a new signature object meaning the signature value and the information about who signed the PDF file. And of course there is an extra section and trailer. And for you, the entire file is now protected by the PDF signature. So manipulations within this area should not be possible, right? Okay, let's talk about 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 assume in our research that the attacker possess this size PDF file. This could be an old contract received or in our case a bill from Amazon. And if we open this file, the signature is valid. So everything is free, no warning cards are thrown and everything is fine. What we try to do is take this file manipulated somehow and then send it to the victim. And now the victim expects to receive a digital signed PDF file. So just grouping 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 cards are thrown and the entire left side is exactly the same from the normal behavior. On the other side, the content was exchanged so we manipulated the received 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 by incremental updates we can add, 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. Why is this 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 this exactly means but we did not consider this attack as successful because the warning is not the same a message that is not the same. So what we did is to evaluate this first against 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 but then we asked ourselves ok the other viewers are quite secure but who they detect this incremental updates and from the developer point of view the latest thing we can do is just to check if another extract table and trailer were added after the signature was applied. So we just put our body update and we just needed the other two parts. This is not a standard compliant PDF file, it's long but our hope was that the PDF were fixed, this kind of stuff for us and that this was an error caller and we were quite successful because the verification logic and trailer after the signature was applied no, ok everything is fine, the signature is fine and no warning was found but then the location logic so that incremental updates were applied and fixed this for us and in the process of this body update and no warning was found. Some of the viewers were quiet to have a trailer I don't know why it was a black box testing so we just removed the table but the trailer was there and we were able to work for the 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 to validate this signed content twice and still our body updates were implemented over the process for example Foxit or Master PDF were vulnerable against this type of attack So the violation of our attacks we consider it as part of our violation 22 different viewers among others would be different versions Foxit and so on and we can see 11 of 22 were vulnerable against incremental updates 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 the consequences 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 clicks on one additional window and if the victim 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 also just outvalid so this was the first layer and the viewers were vulnerable against this So let's talk about the second attack class because it's signature writing attack and this is the most complex attack of 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 plans, the original document and our header with our original document 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 one of these times only two elements are relevant the contents and the bytes, the contents contains the signature value it's a PICCA signature and the certificates used to validate the signature and 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 and this is how the byte range is used and 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 taken and we are specified for the two pages C and D so now we have everything protected besides the signature value itself but what we want to try is to create additional space for our attack so our idea was to move the second signed area and how can we do this? 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 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 xref section pointing to this malicious object the important thing was that this malicious xref section, 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 chart and the question is now how many PDF viewers were overwhelmed against this attack? and as you can see, this is the signature writing column 17 out of 22 applications was more vulnerable against this attack this was a 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 prefer to use another definition for this attack I call them stupid implementation flaws we are coming from the pen testing area and I know a lot of you are pen testers 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 try to do some stupid values or remove references and see what happens 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 removing this byte range we have some signature value but we don't know what is exactly signed so we tried this attack 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 4 of 22 viewers were vulnerable against this attack and only Adobe Unlimited for the others there was limitation 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 there were vulnerable against this attack and this gives the hope of our approach in summary we were able to break 21 of 22 pdf viewers the only... 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 users and that's the reason why you consider it so I'm done with the talk about pdf signatures and now Fabian and talk about pdf encryption thank you ok now that we've dealt with signatures let's talk about more cryptographic let's talk about pdf 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 attack techniques targeting pdf encryption that have never been applied to pdf encryption before so one of them is the so-called direct exfiltration where we break the cryptography without even touching the cryptography so no ciphertext manipulation here the second one is the 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 it good it's good of course we didn't stop here but we didn't stop there obviously so they use cbc mode of information so cipherblock chain and what's more important is that they don't use any targeted protection so it's unintegrated protected is cbc and you might remember the scenario from the attack against encrypted emails so against openpgp and asmime 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 pdf as a drop-in replacement for asmime or openpgp because their customers might not want to deal with set with the setup of encrypted email second one where 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 send 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 pdf and I have exactly no idea how they got the password but at least they are allowed so as we are from academia let's take a step back and look at our take a model so we've got Alice and 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 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 this storage so again they use it into an 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 document 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 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 a nutshell pf encryption so you have seen the structure of a pdf document there's a header with a version number here where all the interesting objects live so there's all the confidential content that we want to actually to actually exfiltrate as an attacker and finally there's exfiltrate and the trader so what changes if we decide to encrypt the data? well actually not a whole lot so instead of the confidential data of course there's now obviously instead of our data 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 the stature again so there's pretty much of the structure left unencrypted and we took a look at the standard so this is an extract from the pf specification and I've highlighted an interesting part 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 part of the whole document before actually showing page 16 of the encrypted document is kind of reasonable 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 that's for one the number and size of pages that's the number of objects in the document and that's also including any links so hyperlinks in the document that are actually there so that's a lot of information and attackers 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 crypt filters this basically means as an attacker I can change a document to say 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 encrypted content that means there's support for partial encrypted content with actual encrypted content and we found 18 different techniques to do that with different readers so there's a lot of ways to do that 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 and we see it's IS encrypted with a 32 byte queue so it's IS 256 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 oh well, this is a different quote 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 a use case but we thought maybe we can somehow exfiltrate the plain text so again we took a step back and we took the PDF specification the first thing we found were so-called submit form actions and that's basically in the same form on the 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 screens and remember that is everything that is encrypted in a document and of course you can also send that back to an attacker well, to a legitimate use case of course via clicking a button so we again looked at the standard and found the so-called open action and this action is called submitting a form that can be performed upon opening the document so how might this look this is how a PDF form looks already ready to have applied we've got an URL here that is unencrypted because all strings in this document are unencrypted and we've got the value object2o 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 close request with a confidential content let's have a demo 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 by 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 for the form 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 hopefully show us a warning but they will already click the button for remembering that and if you accept that, you will see your secret message on the attacker server that is pretty bad the same works for hyperlinks of course there are links in pf documents 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 we can define any object as a URL so any object we prepare this way can be sent as a URL and that will trigger a GET request upon opening the document again if we define an open action for the same object so again, pretty bad, it makes the confidentiality and of course everybody loves JavaScript and pdf files and that works ok, let's talk about ciphertext attacks no more not touching the crypto so you might remember the e-fail attacks on OpenBGP and Asmime and those are basically three prerequisites, one, ciphertext mediability so it's called mediability gadgets that's why we need ciphertext mediability and we've got no integrity protection, that's plus 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 all check that 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 encryption function of cbc so cipherblock chaining and 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 explore that under the first block and basically get all zeros or what we call a gadget or a blank sheet of paper and write on that and exploring that onto this result and this way we can for example construct URLs in the actual ciphertext 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 and multiple places in the ciphertext if you do that, there's always a launch effect of cbc so you will have some random binding here but the URLs, they remain the same let's ciphertext mediability done as I've said, we need some plaintext and as a pdf standard it has been pretty helpful up until now in breaking pdf encryption let's take a look again and what we found were permissions so a 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 if it was left unencrypted so in the newest version it was decided this should be encrypted as a 16.4 so what do we need for extension? we need to look like 16.8 first we need a virtual permission value with all the encrypted files in the document then we need one of the permissions on 4.8 and for some reason we need some actually I'll leave it to you to figure out what that stands for and finally we've got four random bytes so if we take all of that encrypted and oh well we know a lot of that and that is basically no plaintext by design which is bad let's look at how this looks like 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 beside 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 hopefully all of this is encrypted under the same document-wide key in the newest version of the specific thing and that means we can reuse this plaintext anywhere in the document we want and we can reuse this to build widgets to some 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 no non-plaintext is available to attackers so that's basically all of the correctly it's 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 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 what do you want? what do you want? we took a look at 27 viewers and found all of them were able to use one of all the text 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've seen with Adobe with the warning but generally all viewers are 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 oh no not really why is that? well for one, a broken signature does not prevent opening the document so it will still be exfiltrated 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 infiltration channels the answer is 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 remove javascript? 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 told you to add a dialogue for one user and you show the whole URL with the encrypted plain text and Google decided to stop trying to fix the unfixed exfiltration 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 exfiltration from unencrypted encrypted objects and against the gadget attacks we have to use authenticated encryption like ISGC and don't install 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 pocket but 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 like how would this actually be able to be misused in practice 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 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 I would like to put a very motivated user to be able to implement this kind of attack and so we have a micro question you said that the next standard might have a fix do you know a time frame or how long it takes to build such a standard well 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 number 5 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 of part of the signature is there a technical reason for that because the byte offset is predictable did the byte range is protected by the signature but we just defined the second one and just decided to validate 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 4 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 on the web which is distributed through various means that is also what the Department of Homeland Security does and we have a lot of questions 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 you know of any fast easy ways to scan documents for the presence of this kind of attack I don't know if that is true but I mean scanning for the gadget attacks is actually possible if you try to do some entropy detection because you re-use ciphertext you will have less entropy in your ciphertext but that's pretty hard to do diode acceleration 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 2 please thank you for a very interesting presentation one message and one question the mitigation is if you simply run your PDF reader in a virtual machine that's firewalled away so your firewall will alert you to anybody but for the signature of the internet I'm not sure if it's actually a stupid idea but if you consider faking the certificate because the signature is faking by the signature it's faking the certificates that are used for the signature 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 on the 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 with reporting systems for the first time we started we we asked the third team from BSI 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 the communication and there was a lot of communication so I'm not aware of the entire communication but only about the technical stuff we were asked to retest the fix and so on so there was a reaction from Adobe, Foxit and a lot of viewers reacted on our attacks and 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 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