Why bother assessing popular software?

Thanks. Hello everyone. Um, so first of all before I get started, I'd like to ask a quick question of the audience. Um, just to get do a quick straw poll. So could you put your hands up if you use Adobe Reader? Oh, a few people. Okay, keep your hand um right, keep your hand up if you use Adobe Reader, right? And put it down if you understand the attack surface. Okay, so it's kind of mixed. It's kind of what I expected. And there's probably a lot less in this room here um of people who use Adobe Reader perhaps because we're in the security industry. Um so that's kind of what I expected from that. Uh and the fact that

you perhaps there's few people here who perhaps don't understand the software. Um the the understand the attack surface of the software. Um so that's interesting and hopefully you'll you'll learn something from this talk which which something we'll cover. So I'm David Middlehurst and I'm joined with my colleague James Lorero from MWR and we're both security consultants. Um my background is conducting security assurance projects and simulated attacks on a day-to-day basis. My specialisms are application security tool development and vulnerability research. Um James has more of a background in vulnerability research, reverse engineering, industrial control systems and embedded systems. Um so first of all how did this um presentation come about? Well earlier in the year bides launched

its call for papers and there was three topics where that they suggested for the call for papers. There was operational security um attribution and making a difference and the final one making a difference was where um we thought we'd try and do a presentation. Um so at the time earlier in the year we were looking at the pone to own competition at MWR. So myself, James and a few others at MWR were looking at um pone to own and one of the targets for Pone to Home was Adobe Reader. Um and so we began looking at this and Adobe Reader is um a good example of a of a piece of software which has had its fair share of scrutiny

over the years from our industry and we thought that um we'd share our approach and the methodology we took in assessing this piece of software. So a quick overview of the agenda for today. So first of all, we're going to start with um software security in general today where what you might expect from a piece of popular software um from a security perspective. What what what perhaps is happening behind the scenes before the software even makes it to release. Um then we're going to take Adobe Reader as a case study. Um we're going to explore its um attack surface. We're going to have a look at the um areas such as the JavaScript API um how you might fuzz um to try and find

um vulnerabilities in in the PDF file format. We'll then move on to some mitigations such as the sandbox and then we'll draw some conclusions. So how are vendors um improving security? Um generally vendors of popular software have have improved um their security posture of the software. Um and they're they're a lot more switched on with security. Generally with SEC um if you've got a piece of popular software, you'd expect some of these things to be happening behind the scenes. So you'd have an in-house security team um carrying out some of these other activities. So they might do their own security research. They might get independent testing. Um they might do code review, implement a strong um secure development life cycle.

Um they might look at implementing um exploit mitigation techniques and perhaps do their own fuzzing. So as with the Chromium project, um Chrome and Google, the Chromium project and Google do a lot of fuzzing be um and find a lot of bugs before other third parties do. So they do a lot of fuzzing themselves and and this is um to be expected for some popular software nowadays. So why bother assessing popular software? You know, you've perhaps got Project Zero, you've got some big names looking at, you know, pieces of software like like Adobe Reader, you know, are you going to find bugs? Well, we like to think so. And we this is when we started this project we

thought well we didn't have a great time frame um for the pone to own competition from when the target list got released. Um so we we started looking at it and we thought well we'll give it a stab and see see where we get with it and and we really wanted to share to the community our general approach of how we approached Adobe Reader um and hopefully share some of some of the things we found. So moving on to the the case study of Adobe Reader then. So Adobe Reader is implicitly trusted by enterprise and home users. Um so I I had a look online at at some resources um to to try and establish the market share that Adobe

Reader has and there was a recent secunior article which suggested that it could be greater than 80% market share that Adobe Reader has of the PDF reader market. So, it's not hardly surprising that we had a few hands in the air um that that you use it. Whether that's your choice or it's your employer who who forces you to use it, I don't know. But um I don't know. Um so, but PDFs in themselves are generally trusted. They're built around the internet. Um we all use them every day. People generally aren't too afraid of clicking on a PDF. But despite Adobe doing some of this good security stuff, so probably some of the stuff from what we were talking

about in a few slides ago, there's still bugs found and there's no real sign of decline. This is the graph of CVES um for the past since 1999 to 2015. So far this year, there's there's a decent number and for the past number of years, there's it's been quite sporadic. There's no no real sign of slowing down. Um, and we'll maybe come on to this a little bit more with the attack surface of why this might be because the the attack surface is perhaps quite vast. So, in terms of high-risisk CV CVEes with a score of CVS 7 or more, there's actually 31 bins reported to date this year. Um, 37 in 2014 and 65 in that was a good year in

2013. So before we start looking at um Adobe and trying to going for bug hunting with this product um let's look at the latest um Adobe security bulletin which was released in May. This is how they classified the vulnerabilities which they fixed in that release. Um as you can see 14 um JavaScript API security bypasses. There was 10 unclassified um memory corruption bugs. Five five use after freeze. um a couple of buffer overflows and an XXE vulnerability. Um so that these are the types of areas where we might expect to find vulnerabilities in this product when we start looking at it. So before we got started with this product, we'd obviously looked at this, you know, CVES, we'd looked at some of

the output from project zero on on this target and other other useful things, but these are the key resources that we really referred to before we got started approaching the target. So we obviously went to Adobe for their standards and documentation and some of their engineering teams output is extremely useful especially if you're you know for some of their sample files and you um exercising some of the functionality. Um Corki um he does a good course called PDF 101 um which which uh describes some of the intricacies of the PDF file format and some of the tips and tricks that you can use to to to create PDFs. Um Diddius Stevens has good done some

good research over the years and we'll perhaps touch on some of his um research in in embedding an exe. So he found that you know embedding an exe in in a PDF and that was bad. You could dress up the the dialogue which comes up to launch the the exe. So that that's generally a bad thing. Um and then three presentations in particular helped us out a great deal with different aspects of the attack surface. So the life of a JavaScript um bug that's a brilliant presentation. um it takes you right through from um for privilege escalation um right through to some of the things you could do with that and we used that in when we looked at the JavaScript API

um for the sandbox. These two presentations um one at Blackat Europe and one at Canet West were um incredibly useful. Finally, I mentioned government hardening guidelines because these are quite useful. Um so the the notable ones for Adobe were NSA and DSD. Essentially this is the information that Adobe puts out um to give advice to government their government departments um how they think that the product should be locked down and hence why where they perceive the attack surface to be. So this is useful um knowing where what they tell you to switch off essentially. Um so what did we perceive the attack surface to be? So we mentioned so there's a JavaScript API which it we'll come on to in more detail

later. um passing and rendering of PDF files themselves. So file format type bugs um extensions. So there's a lot of inbuilt extensions with with Adobe Reader and they also open up an SDK for to allow you to develop ext um extensions for the product. Um but one of the extensions which comes as standard is XML forms. So that's something you could you could approach. Um I mentioned embedded files and that's something that Diddia Stevens did with um embedding an exe. Can you embed other dangerous content within PDFs? That might be an option. And final, there's some security features such as document signing and the concept of a trusted publisher. And perhaps if you trust a

publisher, then it's maybe gives you more permissions within Adobe Reader when you open a PDF file coming from a trusted publisher. So essentially with the attack surface we shared this out among the team and we all we all kind of worked together but one of the things which I looked at was the JavaScript um API. So um as it says here this is from Adobe site JavaScript and Adobe um reader you know is it a good idea I don't know but it it sounds so it essentially means that you can generate PDFs which are interactive they perhaps have a form and they connect to a database to store the results. This allows developers to do weird and

wonderful things with PDFs and and and so it's based on JavaScript um version 1.5 ECMA script and this is very much similar to the JavaScript you might expound uh find in a web browser um and you know could be invoked from a HTML page. So before we uh looked at the JavaScript um API, some useful documentation was the JavaScript API documentation. And we'll come on to this a bit a little bit later, but you can also decompile the spider monkey bite code. Um and and in the presentation I mentioned the life of a JavaScript bug. It gives you a bit of that background on how there's how how you might do this. Um to play with

JavaScript in PDFs, um you've got really got two options. You can either make PDFs with JavaScript embedded or you can invoke the JavaScript console within Adobe Reader and you can interact with this directly. I wanted to first of all share some just very simple tricks on how you you you can play with um JavaScript in PDFs. So on the left here is a PDF and that's a valid PDF. We've got a stream here which is a JavaScript stream. Um, and I'm just spawning an alert dialogue. Um, a hello dialogue here within Reader. When you open this PDF, you you get the hello dialogue popping up. Obviously, replace this with whatever payloads you you you know you'd like to um play

around with. And then that's option. So, one way you can do um one simple Python script you can use to create these PDFs is um a script from Ddius Stevens PDFs tool set and make PDF JavaScript. you simply specify the JavaScript file you want to embed in a PDF and it'll it'll um load this JavaScript when when you launch the PDF. So I mentioned um the JavaScript console. So to actually get access to the JavaScript console if you um incorporate this in so the way I did it was that if you create a PDF with simply console.show in it then it invokes the console. There are a few other ways you can save a shortcut within Adobe Reader

itself but this is a simple trick. It will invoke this this dialogue here um which is the JavaScript debugger with this um JavaScript debugger. You can type JavaScript into the console and press control enter and it will execute the JavaScript and this this opens up the JavaScript API to some other trips um tips and tricks which are worth mentioning. You can call a function with the parameter acroel and it'll return some output which looks like this. Um this is useful for fuzzing because it gives you the expected um values expected par parameters that the function expects along with its data type. Um and those in square brackets indicate optional parameters. Um as with all JavaScript

you can iterate through what's there and and to you know enumerate um the objects and functions which are present within Adobe Reader um in a in a quite an active manner. I just use this little sliff snippet to produce a list like this and I'll come on to this a little bit later and um as well but this is um iterating the app object within Adobe Reader which we we know is present and and things like alerts stem from this and this is all the nested OB some of these are objects some of these are functions and we'll come on to a tip now to so so actually yeah so this this is one way you can establish that so if you

call say app alert and then call a string on it. As you can see, you'll get a response um here which indicates that this is implemented in native code. Um this is important for fuzzing because this is this is probably more attractive fuzzing target because it's implemented in native code than other functions like this which are implemented in JavaScript. I'm just calling to string on on this um function the same way as that one, but that indicates that it's implemented in JavaScript rather than native code. And hence some of these calls that that makes will be implemented in native code. So it's still valuable for fuzzing but there's probably other um checks which are going

on in this function which won't so you're probably better off focusing on these for fuzzing if if you want to fuzz this. So to to work with this I developed a proof of concept tool and I'm going to show you a demo in a minute of this tool. Um so essentially it is just a proof of concept. It's not ready. and we will release it once it's you know a little little bit less rough and hopefully the demo will work today. Um so we've got it essentially interacts with the JavaScript console but instead of typing manually into the JavaScript console it interacts with the JavaScript console via the wind32 API. It essentially just grabs a handle to the

um the the JavaScript console and sets sets the text and and then executes with control enter like like I I described in the last slide. So I'll just move on to the demo of this tool um now. So hopefully show you something

working. So first of all I've I've launched the tool here and what I'm going to do is I'm going to click the console button. As you can see it's invoked a PDF with with um the JavaScript debugger active. Um all this is doing behind the scenes is really dropping that that PDF I told you to craft with with console.sh showing it. Once this is running um my tool if you click enumerate it will start typing into the JavaScript console start iterating using introspection um to to get the nested objects and functions within Adobe reader. The reason I did this was I wanted to have a tool which interrogates what's there finds does some enumeration does some information it gathers some as

much information about the the functions which are present and the ones which I might want to target for fuzzing and then and then goes off and fuzzing so I can scale this tool up eventually. So what I want to do is it's a populated tree view here on the the left hand side. If I if I start to expand that out, as you can see within app, here's all the nested. Some of them were objects. So media is an object. Some of them um are functions. If I then double click one of those, it's identified it's a function. It's identified it's in native code. It's identified that it expects a string parameter. If I then flip back to the tool, as you

can see, it's it's it's extracted this information. It's passed out um the some of the parameters. It's found that there's a mandatory parameter of a string, which is a policy file. And then you've got something which you can work with to fuzz this. I've half implemented a fuzzer and as you can see at the top, there's a fuzzer which is isn't quite there yet. And we've not necessarily found some bugs with this alone. Although the enumeration has been useful with this tool, but um I also implemented a reg x fuzzer which fuzzes the reg x engine by basically constructing a simple test case which says oh here's a string let let's try and match this reg x against

the string. Um I just wanted to show you what happens when it's an object rather than so it's identified that's an object. If I click on that, it's found nested objects and functions which are present below app media. And essentially when in the earlier revisions of this tool, I just left it running overnight just finding stuff. There are some loops in there so be careful though. So

So, a final point on the JavaScript API. Um, we'll touch upon some of the security um considerations with the JavaScript API a little bit later in the presentation, but I mentioned you can decompile the um spider monkey bite code. If you follow the steps and the tool which was released in the life of a JavaScript bug, this will enable you to do this. Um when you do this and pritify the JavaScript you end up with 27,000 lines of code which are present within Adobe Reader as standard when you install the product. So as I mentioned Ddia Stevens did some work on embedding dangerous files within PDFs and one thing which we we looked at is um what mitigation Adobe

had put in place. So essentially we launched um a reader um we embedded a file within a PDF and and had a look in CIS internals to see what was going on. We identified this registry key um here which contains a list a blacklist of of bad extensions. Um as with any blacklist there might be gaps and one of the things we we looked at was whether there's any gaps that we could find. We had some success with some um some um theme packs for example for for Windows um but we didn't really get anything which was too valuable out of this but I just thought it was worth sharing because it was something we did when we

approached this piece of software. I'm going to hand over to James now who's going to discuss how we approached the PDF rendering engine. So as Dave said uh we started looking at reader mostly for pone to own um and a lot of our efforts for that were looking at the JavaScript. Um but over the last couple of weeks we decided we'd have a look at the rendering engine uh because this is a huge attack surface. Um the PDF specification for example runs to 740 odd pages and there's an Adobe supplement to that which is another 140 odd pages. So there's a lot of features in the PDF file format. um which means there's going to be a huge number of

potential areas we can start looking at particularly for fuzzing the PDF format. So what we wanted to do here is get as much code coverage from this as is possible. So we wanted to go out and get as many PDFs that could possibly cover all aspects of reader before uh for when we fuzzed the PDF file format. Uh there's kind of a couple of ways I guess we thought we could uh do this. We could either generate the PDFs ourselves. That might take a little while, but you know, we've got the specification. We can probably go do that. Uh the option we chose was just to go out onto the internet and just W get

lots and lots of PDFs. I think we ended up with around two terabytes of PDFs after running W get recursively for about a week or so. Uh now that's great. Um, we have lots and lots of PDFs, but we want to reduce the amount of PDFs we have uh before we fuzz them because, you know, a lot of these PDFs aren't actually going to add new coverage. So, we only want to fuzz PDFs. They're going to add new coverage. Uh, so the way we did that is we wrote a little script around the Dynamo Rio Darchov tool. Uh, what Darov does is it outputs the basic blocks that get covered when you execute an application. And this is quite

useful. So, we ran the PDF through reader. Uh, dive cov just uh injected DL outputs the basic blocks. Then we compare that to a database. If the PDF adds new coverage, great. We'll keep that. Put that in our fuzzer. If it doesn't, well, we don't really care about it. We'll just drop that off. Uh from that I think we ended up with around 4 or 500 megs worth of PDFs um from the original input size of two terabytes which means we're going to be a little bit more likely of finding bugs uh because we're exercising lots of different code paths with the application. Uh one thing before you start fuzzing PDFs that is worth mentioning they're typically compressed.

Um and it's worth uncompressing them first. uh you'll tend to get much better results if you're going to go out and fuzz these formats. Uh which is obviously what we did. Again, lots of free tools online that did that. We just wrote a little wrapper script around one of the freely available ones. Um Reader is happy to accept compressed or uncompressed PDFs, so that's all good. Um although why bother fuzzing? Lots and lots of people spend a lot of effort fuzzing reader. I know Project Zero have a load of bugs on their website where they've just gone out and fuzzed Reader. Adobe do it themselves. The idea is is you need to fuzz a lot smarter. Just grabbing a

couple of PDFs and throwing them through Reader, you're not going to get great results from it. But if you can exercise lots of different code parts, lots of different code coverage, you might have a better chance of uh attempting of getting bugs. And this is something that um some of you probably know, American Fuzzy LOP, uh which is a really cool fuzzer um manages to do. It it tries to exercise as much of the code as possible and it has a really good feedback engine in there that allows it to do that. Uh if you're on the AFL website, you'll see all the bugs it's found in some pretty high-profile uh bits of software. The other thing that's worth

considering, which isn't actually what we did uh with Reader, but it's worth trying to distribute out your fuzzing runs as much as possible. Uh so, as you'll see, we actually just used a couple of laptops, ran it for a week. If we could run that, you know, cloud scale, get some AWS time uh over lots and lots of boxes, you're probably going to get some good success. So, yeah, we we got a few crashes from doing this. Uh like I said, all we did was a really simple bit flip. Ran it for a week across a couple of laptops. You know, I think we were launching a few uh reader instances every few seconds. So, nothing

particularly quick, but we got a use after free. We got an old pointer dereff, lots of boring rubbish crashes. Um but in total, our fuzzer um identified around 100 crashes which were still triaging. We only ran this not last week, the week before, I think it was. Um, currently I'm just trying to write a proof of concept for the use after free. Um, going to report that to Adobe obviously, but once we've done that, um, just very quickly, it's appears to be a error in the way a font library is being handled. Um, we're going to get that reported off to Adobe and write a little proof of concept. So hopefully keep an eye on our website.

Um, probably publish something on there. Um the other thing though the problem with looking at the uh rendering engine is there are now quite a lot of mitigations in place. So if we' got that use after free and managed to write a cool exploit for it or whatever from reader 9 and below would probably have some uh we would have control of the user machine. From reader 10 we've got this idea of a sandbox. So probably quite a lot of you know about this already but the sandbox limits what uh our abilities of our exploit to call out to the operating system. Uh essentially it goes through a broker process in reader. Now there's been quite a lot of

work already done on the sandbox. Uh these are a couple of papers which uh Dave mentioned at the beginning. Uh ultimately it's not massively changed between reader 10 and reader 11. We have done a little bit of looking at the sandbox uh recently. Um, and we're going to carry on looking at that as well. Uh, it's worth noting as well that the reader sandbox is actually heavily based on the Chrome sandbox, but the differences are that with the Chrome sandbox, we have around 10 calls out to the OS, whereas in Reader, there's 10 and something to support its rich feature set. Uh, obviously, this gives us quite a nice attack surface for when you want to maybe look at the sandbox or

try and fuzz it or something. So with that in mind, there's a few ways that you could consider trying to break out of the sandbox um which we'll go through in a minute. Uh but with uh Adobe, the sandbox essentially looks like this. So um when you launch Adobe, you actually launch two processes. So you get a really low privilege process, which is what renders your PDF. Uh and then a second process, which is this broker process up here, excuse me. uh which hooks well essentially hooks all calls out to the OS to ensure that you know nothing weird and wonderful is going on. Uh again uh the read writes out to like the file

system and registry keys. These are heavily restricted now. You can't just go and arbitrary write to any bit of the file system. You can't just go right to a bit of the registry that you feel like uh you'll get caught out there. Uh so as I mentioned there are a few ways we can consider maybe trying to break out of this sandbox. Um a kernel ode you know probably quite difficult but it's certainly a thing you could consider. Um and certainly that's if you look at some of the pawn to own winners previously that's some of the things that they have done. Uh so you know it's not to say that there aren't any bugs

there. Logical flaws in the cross calls. Yeah. Okay. So reader is continuously adding new meth uh way uh new features uh which need to be implemented in the sandbox that there's you know certainly no reason to think that they wouldn't have made mistakes there but one of the ways we're looking at is um memory corruption in the cross calls. So we're we're looking at building a sandbox fuzzer. Uh this is kind of based on the uh work in the breeding sandworms paper where they implemented something kind of similar um but they only implemented it on one call I think. So we're looking at extending that a little bit and trying to fuzz a lot more of the calls out.

Just very very briefly um just the idea behind uh the sandbox fuzzing is you obviously have your PDF here. It goes to the reader bro uh reader broker process. Um what we want to do is just hook that call and modify data. Um when a PDF is loaded uh as we'll see a bit later um one of the actions you might want to do is try and access a website for example. So you' embed the UR URL in there. What we can do is obviously that's a user controllable value. So we can hook that modify that insert fuzz data there um and try and watch out for some bugs. Um, so that's something we're currently

working on as well along with all the other bugs we're looking at from uh the fuzzing. Uh, so that's actually all I wanted to talk about. So Dave is going to talk about some of the bugs we found in the JavaScript privileges uh system. Thanks James. So back to the JavaScript API, I just wanted to um touch upon um a mitigation which Adobe put in place to safeguard some of the more sensitive um JavaScript functions which are in inbuilt into reader. So in in Adobe Reader, there's a concept of privilege versus non-privileged context. Um this is defined in the Adobe documentation for the JavaScript API here. As you can see, um those um some JavaScript methods

marked with this little S icon, the little red icon, um can only be accessed in a privileged context. So if you crafted a PDF and it's come, you know, you've just download it from the internet, you can't you can't for example use the launch URL method which will launch the URL in a browser. So if you look at the paper I I I discussed about the life of a JavaScript bug, it describes this in more detail, but very simply what after we've done our enumeration, we've we've established what's there and what some of the inbuilt functions within reader look like and also we've compiled the bite code, we can start to do essentially code review of some of these um inbuilt

functions. Some of the functions are marked as trusted. So here we define fu as a trusted function. This has a parameter bar. You you begin the privileged operation which increases the um the privilege of the stack frame. Some privilege stuff happens here and then you you end the privilege. One of the um one of the vulnerabilities which we've reported to Adobe which we identified um basically involves bar being used in the privilege stuff. So you can call one of the trusted functions which is present within within um reader. You can manipulate the bar which is an object which is passed in and then in in turn you get a privilege escalation with something you control something which

happens in in the privilege stuff. So I just wanted to do a quick demo of of our exploit of this.

So first of all I'm going to launch a PDF which tries to launch a URL in a low privilege context. As you can see you get a security warning which which is preventing you from launching the URL which is YouTube. You've got the option to remember this for future reference but I'm not going to click that. I'm going to click cancel just to prove that we're actually doing something here. Here's our exploit PDF. As you can see, there was no security dialogue. And we get a nice song from Ricassi. James, some of the you should have seen some of the PDFs which James was was sending me with meat spinning and all kinds of stuff.

So finally to summarize our talk. So what what have we learned from um our journey with Adobe Reader? Well, we've learned a methodology which can um allow us to understand the attack surfaces product. Um how potentially how this can be reduced through hardening. Um potentially we we've learned some things which can be implemented as security controls um to mitigate the risk. So perhaps on boundary email and web filtering appliances um for an organization you might um flag or increase the risk associated with an attachment which has JavaScript or something like that in it. But the conclusion is that we we've identified a number of bugs. We didn't know if we'd find if we'd get anywhere

with this project but you know with a couple of laptops we managed to get a use after free. with a bit of effort with the JavaScript API. We've managed to get um a privilege escalation and we've got plenty more to triage. So, so the longer and short of it is yeah, you should bother assessing popular software. So, future work then um we we already starting to apply the same a similar sort of methodology for other projects products and the um tactics seem to be working. So, we've already got bugs in um Microsoft Vizio and we're working on other products, but we wanted to share this methodology. So, you know, this is something that you guys can do

as well and pick products and start approaching them just because they're popular and they're used everywhere. They've maybe been looked at to death over the years, it's still worth a stab at them. So, final thanks to um Niels and Young from MWR for their help. and of course the Bides crew for all all their um efforts in getting this event um together and f and also you guys for voting our talk um to be at this um event. So finally um just before I go on to the questions actually um just a note that if you want to come to the MWR afterparty come and see us at the stand um we'll be running the afterparty later

on and yeah come and have a beer with us and have a chat about Adobe but for the time being is there any questions?