 Hey everybody, so I guess we'll get started because we're going to be... We went 15 minutes over at Black Hat when we had a lot more time, so... Can you guys hear us okay? Hear me okay? I'm sorry, I've been in Vegas since Tuesday and I already sound like Kathleen Turner from All the Smoke. So my name is Alex Domos, this is Chris Palmer and Chris Ritter, and we're here to talk about the security of computer forensic software and things to be concerned about if you use it and perhaps things to be interested in if you think you'll be used against you. So we'll do a little introduction about the stuff, talking about the attack services for computer forensic software, attack classes, some bug finding techniques that we've used over the last couple months to find what we think are some interesting bugs. We're going to talk about the Sleuth Kit, which is probably the premier open source forensic toolkit out there by Brian Carrier. Is Brian here? He shows up every once in a while. And then we're going to talk about issues with guidance and case forensic and guidance and case enterprise, some conclusions. And then at the end we have an extra special bonus talk by Chris Ritter, who's a fellow at the Stanford Law School Center for Information... Information Society? Internet. Internet and Society. Right, so he works with Jennifer Granick and he's done some interesting research into the impact security issues might have into the immiscibility of evidence and the use of evidence. So kind of before we get started at BNRC to see what the audience is like, who here has ever used forensic software at all to do forensics? Okay, wow. Who here has used guidance and case? Any addition? Who here has used in case enterprise? Wow, pretty good number. Who here has used the Sleuth Kit? Okay. And who here thinks they have a reasonable expectation that in case will eventually be used on their hard drive? Okay, so you can go introduce yourselves, shake hands. So who are we? So Chris Palmer and I are researchers and consultants of a company called ISAC Partners, a little company we started two and a half years ago out of the destruction of at stake. And please send us your resumes. Okay, that's all I'll say about that. We're working consultants. We're not full-time researchers, so kind of the techniques we're talking about came from doing actual black box and gray box penetration testing of real-world applications. And we got into this because we use the Sleuth Kit and NCASE on our day-to-day basis. We're not forensics experts. We don't do a lot of forensics work, but we do have clients that have come to us to do some incident response and try to figure some things out. So we own these products and while using them, we kind of switched our minds from forensic mode to software security people mode and thought, wow, these things are pretty crazy in what they're doing. They're very, very ambitious products and maybe that should be looked into. So as a result, we looked at the two things that we use, the Sleuth Kit and NCASE and we think we have found some interesting bugs. There can be arguments made back and forth of how useful these specific bugs are. I think the point of this talk today is about the amount of the attack surface we touched and the amount of bugs that came out of the attack surface we touched and what that means for the reliability of these products going forward and how people should treat them. We actually found our first bug in about two hours after starting fuzzing of the commercial product. So this is definitely kind of a virgin territory. I think these products don't get looked at from a security perspective too often. I know there's been a lot of anti-forensic stuff about hiding data, playing with your time stamps, stuff like that, but there hasn't been a lot of discussion about attacking them to actually attack the forensic examiner's workstation or change how data is being re-displayed or I've never seen any research about attacking the remote forensic software which is about a third of our talk and we'll do right at the end. We've spent a lot more time on the paper than these slides, considering some of these slides were written about 12 minutes ago, so I strongly recommend that you download our paper. It was co-authored by Jesse Burns and Tim Neuschum of ISAC Partners and they did a ton of work and were very grateful to them. But Jesse went home and Tim prefers surfing to Vegas, so he's not here. But if you go to ISAC Partners.com you can download the paper and tonight we're going to upload a big 16 megabyte tar file of all of the file system fuzzing tools that we created, a bunch of Python scripts and fun stuff, so if you guys want to do your own investigation, it might actually be useful if you want to attack file system drivers and operating systems as well. But if you want to look at forensic software, please take a look and be responsible in your disclosure. What is interesting about forensic software? The interesting thing that we don't have a slide about because it's so obvious is it's really important, right? Community forensic software, you know, the small number of products that are used have almost a court-enforced monopoly because the ones that get used over and over again get accepted by courts over and over again. And so there's a small group of pieces of software that are extraordinarily important. There's a lot of people sitting in jail today because those products work, right? And we're not up here saying that these products don't work. They generally, the vast majority of the time work, right? And the vast majority of the evidence that pops out of them is really very accurate. What we're talking about is the corner cases, right? Which is whenever you're talking about security. One of the other interesting things about these products is the attack surface. The attack surface on N-case forensic is absolutely stunning when you think of the percentage of code that is doing dangerous parsing against attacker-controlled data. And when we talk about attacker-controlled data, you're talking about somebody who is generally either who's either being sued in a civil case or who's suspected of being a criminal by the criminal justice system, right? So you're already talking about kind of a population of not nice people, perhaps. You know, this product doesn't load up generally the hard drives of fourth graders. It's used on people that maybe know and want to do some bad things. And if you think about, you know, Microsoft Word does a couple different file formats, but they're one major file format that Microsoft invented. They've had, what, six, seven remotely explitable buffer overflows from one file format. In N-case forensic, it claims to be able to read something like eight or 10 different file systems and over 270 different file types can be displayed within the application. And I leave it as a challenge for you to try to write something that parses 270 file types in C++ securely. That is not an easy thing to do, as we'll see. So the attack surface is huge. The attack surface in some of these cases is automatically looked at by the product. If you look at a file system, obviously a lot of the file system structures will be parsed automatically. And then products like, you know, the Sleuthkit's a lot less ambitious, but a product like N-case, you can click a lot of buttons and it goes and does all your work for you. It automatically finds exchange databases. It automatically finds Outlook files, PSTs. It automatically goes and finds your Thunderbird mail spool. That's the kind of stuff that automatically can often be attacked and a person doesn't have to actually go and look at an image. So we'll talk about kind of the different classes of attack and what it means for forensic software. Evidence hiding's an obvious one. If you can do something to a hard drive to make it so that a normal user with their operating system sees and uses a bunch of data and that is invisible to the examiner, that's kind of a big deal, right? Now, that's not a big deal that you can use to frame somebody else, but it's certainly something that these products don't want to have because if you're, you know, a police officer, you don't want to get tricked like that in some kind of embarrassing, easy way. Now, that's something that can be worked around by using multiple products. To look at every hard drive they look at, there'd be a lot less case load and, you know, forensic examiners would have to be about three times as many, right? So that's kind of a big deal. Code execution. So I'm going to make this clear because this is something that we've been misquoted by journalists in the past. We are not claiming arbitrary code execution. We are claiming that we have found a lot of memory corruption bugs, in some cases, controlling certain things like EIP. Whether or not that is exploitable is a mental exercise for the listener. Because when people claim exploitability and you don't have a working exploit, you know, it gets kind of a big fight in the media and the actual message would get overturned and since we've had a little bit of a contentious relationship with guidance so far, we don't want to get stuck on little stupid things like that. So we didn't write any exploit code. We're not releasing any exploit code. But these bugs, as you'll see, control some very interesting parts of memory. And therefore, if people spend a lot of time, I think our evidence supports the idea that these products probably have a decent number of code execution vulnerabilities in them and people need to prepare for that from a protection standpoint and they need to prepare for it from a legal standpoint. And then denial of service. There's a lot of bugs you can do to make these things just kind of either not be able to look at your hard drive, crash all the time, hang all the time. You know, that happens sometimes with these products on a day-to-day basis anyway. And if you're an attacker, make it happen over and over again, you might be able to get away with something. You might be able to make their life hard. You might just want to be a jerk, right? So, you know, I'm not sure what the actual impact of denial of service would be, although a lot of those denial of service bugs, if you kind of look at them, maybe they become exploitable in the end. So, you know, a couple techniques that you can use for finding this stuff. There's the dumb old way, random fuzzing. It's not sexy. We're not going to say that it's like some kind of super elite attack technique. Unfortunately, it works really, really well against these products. And you can use our tools to do things like generate a file system, put a bunch of PDFs on them, put a bunch of exchange-day-basis on them, and then fuzz both the files without touching the file system. Or you can fuzz the file system and mess up things like file system structures, obviously attacking totally different parts of the code. And then you can do a lot of targeted, manual mingling of things. You know, as a human being, it's sometimes a lot easier to figure out something that would kind of trip up these products. You know, this is something that would be hard for me to code around if I had to build the product. And so we did a lot of that, too. And so Chris is going to talk about some of the individual bugs. Okay, hi, I'm Chris. So there's the slides detail a bunch of different bugs, and we don't have a whole ton of time. So I'm going to be skipping a lot of them and just jumping to the funny, cool ones. Or, you know, glossing them over. But again, visit the paper and all the details are there. So our fuzzer just does some kind of obvious stuff. And again, this shouldn't have produced much in the way of results, but even in 2007, a random number generator can cause tons of trouble, and that's kind of sad. But that's where we are. So, you know, we picked just some of the obvious targets. You know, the most common file system is most common document types. And again, we've only just barely scratched the huge attack surface of these products. So who knows what else lurks? Also, in addition to the random buzzing, we did do some, as Alex was saying, some manual, you know, targeted manipulation things that would seem like, as a developer, you'd think, well, where would I go wrong if I were trying to understand NTFS? You know, so we tried to, like, see if the developers of the products had gone wrong there. And in some cases, they did. The usual stuff, make a super long file, super deeply nested directories, and that happens to be a particularly good one, or a funny one. So first, the Sleuth Kit by Brian Carrier. It's open source, wonderful. That helped us do better what we think is much better testing. The availability of code lets us see exactly what code is going wrong. We were even able to patch over the first round of bugs and then find more deeply hidden bugs. When you're doing this kind of random buzzing, you'll often just hit a bug, and there may be a bug that the first bug is hiding. And so with having code, we were able to dig a little deeper than we were with proprietary product. So Sleuth Kit works in a Unix-y way. There's just a million little programs each do one thing, two or with a file system image, and then it's up to you to script the pieces together and make something useful out of it. So it's nerdy. And we found problems in four of the 23. Nothing new in this slide that you've already seen. But the defects are crashes and strange parsing of data structures. So here's an obvious one. Hopefully everyone can see what's wrong in this code, and I made it easy by making the code red. So easy fix, simple problem, but it just causes a crash, depending on your allocator. And most allocators these days probably wouldn't like that too well. De-referencing memory after it's been freed. Let's see, I'm going to skip to a particularly fun one. Here's one. So again, we see the code has some defense against a possible problem. It checks in that top of that while loop. It makes sure that the FS data run pointer is valid, not null, but it gets changed before the check is rerun. And at the bottom, we may be dereferencing a null pointer or an otherwise bad pointer. This one might be... This one's kind of complicated. There's a side effect happening on that IDXE. But a good point to make here is these functions like getU48, getU16, getU32, they read the file system, which again is attacker-controlled data, 10 gigabytes of potentially malicious stuff. And it reads that user data, turns it into a 16-bit or 48-bit or 32-bit number, and then uses it as an offset or a pointer or some other value that controls how the application is going to do its job without checking for things like, does this pointer point anywhere sane? Do we have... Are we looking for the 10 millionth item in a list of 100 items, that kind of thing? A lot of problems like that where there's a lot of trust in the file system, which of course is misplaced. Let's see, I want to skip ahead since I've only got a few minutes, but these are all along the same lines, lots of crashes, bad pointers that go nowhere, annoying service, infinite loops due to strange integers that go wrong. But let's move on to, in case, a proprietary product for Windows, and it's pretty much the opposite of the SleuthKit, it's Windows-y, right? It has a specific, I'm sorry, a sophisticated user interface, and it integrates all the features that you would want. It can handle different file systems, it can handle different data types, and it can even, you know, you all have seen in case, lots of hands went up, it'll show you the data right in a little view pane, you can get a hex view, or a document view, or all sorts of nice stuff. So it does have some programmability, of course, it's got its own built-in language called in-script, so it's very different than the SleuthKit approach, as well as in its opaqueness. In addition to being proprietary, it's also packed or pseudo-encrypted, and there's some relatively simple anti-debugging mechanisms in there to further annoy us, but we just attached Windabug after it starts, and then it doesn't seem to mind that too well, or it doesn't seem to mind that. So we were still able to do things, you know, use Windabug to analyze in case. And then, of course, there's also a copy protection dongle, which is kind of infuriating. So we didn't get to do the... We only hit the first layer of bugs with our random fuzzing because we couldn't patch the ones we found and then see what else is there. But so who knows what else lurks. So in case you can't handle things like mangled partition tables, it will fail to acquire the drive, for example. Here's an example with a... Partition number 29 is just completely wrong. It's the same size as the others, but it's starting-end offsets or completely crazy, and that makes, in case, not be able to acquire this drive at all. Let's... Oh, yeah, that's actually a good point. Thank you, Alex. In this case, the partition table, this is when we feed the image to, in case, running on a Windows machine running a Linux machine, running a little program called linin, which is an encased tool to... It's kind of like your way you'd think of if you were using a Sleuthkit or just Unix stuff, you would use DD and Netcat to feed the raw device to another server to read. So it's kind of like it's doing basically that, although it's its own thing. And so we found that linin itself behaves differently depending on whether you corrupt this partition table before linin has started and has begun reading or after, and it makes encase hang and be... It's... encase has different failure modes depending on when the corruption happens, but we didn't really look into linin much at all. We just sort of noted that issue and then moved on. But linin is its own thing. So there's going to be a lot of bugs like this where if you mangle an NTFS image encase can't handle it in various ways. NTFS is just a rather... As file systems go, it's among the more insane. It's extremely tricky. And in this case, what we'll see here is that... So in the master file table, which is a NTFS data structure, it has different entries of arbitrary size and number for different attributes of a file. And we just poked one. There's a file record. Normally, it would be zero where it says 61 in red, but our fuzzer happened to put 61 there one time in a file record. And what we'll see... Oh, I'm so sorry. This is so tiny. My laser pointer probably can't even do... Right around here, I think it's EDI. I can't read it either. And my computer has an extremely different tiny view. EDI contains in it the base of an allocated region in which the file record will go. And our number is 6130, is used as an offset into that region, which is completely wrong. What we get is a read access violation because that number is way too big for the region and it points nowhere, and so in case it crashes. But so the point is that attacker-controlled data causes a pointer dereference that is wrong in case dies and we get wind to bug. So a lot of the bugs are along those lines. I'm going to skip ahead to some... This is a good one. Okay, so... NTFS, being the crazy complicated thing that it is, lends itself to problems like this where different interpreters of it interpret the same structure differently. And we found that the Linux NTFS 3G driver handles a directory loop in a way that's different than the way in case handles it. So what we did is we manually created a directory loop. We had a file that said that it was its own parent, which of course is completely silly. So what we did is we just manually did that. That's not the result of random fuzzing. So in this HexDump shows a part of MFT entry for a file called readme.txt. The blue areas refer to, for example, there's the... What's the file reference? What's the size actual and real? And what are the flags that describe this file? And we just manually changed them to those of the parent directory. And the red bits is what we changed. And again, our paper, if you can't read it because it's too small or too strange, the paper covers it in good enough detail. So we feed this file system that contains a directory loop to Linux and in case. And... Oh, I'm skipped ahead, sorry. So what we found is that in case shows the file itself and doesn't show the directory loop but it fails to show other files that were in the same directory as the file that is a loop to its parent. Whereas Linux shows us just a regular directory loop. So this allows a bad guy to potentially use data in Linux that in case will later ignore when the image is analyzed by in case. So... And I don't really have... I can't even speculate as to how our developer on in case how I would even approach that because again, NTFS is very frightening and I'm scared. And here's a good one. This one will show EIP belongs to us but in a sadly unamusing way. It's not particularly exploity but it's definitely suggestive. So what we did is we created again manually just a super deeply nested directory structure you know there's like maybe a thousand children. And what we found is that you don't get this problem if the children have multiple siblings. It has to be a directory contains one directory contains one directory contains one directory for a long time. And we think that the reason that bug happens only when there's only one child per is an optimization to avoid recursion but the result is that EIP becomes controlled by the number or partly controlled I should say by the number of nested things. And as you can see here if you have supervision which I don't but if you have the paper again isekpartners.com slash black hat you'll see that EIP is CA in hexadecimal too low to point to any code at all let alone attackers code. But of course it does cause a crash because there's no reasonable code there at all. But the point is a bad file system image allow the attacker to control the instruction pointer which seems not totally great. Oh and then here's a simple one if you make a disk image with too many partitions and you can see here we made a disk image in Linux that has like I think 51 partitions in case just doesn't like that it will show us up to number 25 and then it stops. So if you want to hide your porn put it on partition 26. But oh and we should mention that the bugs that I've listed so far guidance tells us that they are going to be fixed in the next release which will be released 6.7 so that's good news. These particular bugs although Alex is going to talk about a different kind of bug protocol bug that probably will take longer to fix. How long for time? Yeah okay great I'm going to hand it over to Alex but there exists more entertaining bugs for you to read in the paper. So that was kind of just a bit a snapshot of some of the bugs we talked about in the paper and the paper is a snapshot of the bugs we generated. When you do testing like this the hard part is not generating the flaws it's doing the analysis right. It's really easy to automate the fuzzing it's easy to Chris actually worked up a really cool using a thing called, anybody here use PiWin Auto before? There's a window subsystem called Windows Automation that allows you to automate and click a lot of buttons automatically and Chris worked up like a really cool Python script that would go and have in case do the acquisitions automatically and stuff like that. You don't have to do things like that to generate the bugs. The problem is there's really no good way of automating the analysis and a lot of the times when you do this kind of thing like Chris said we'll have huge stack of windy bug mini dumps that come out of our tools that all point to the same flaw expressed in different ways that may be different EIPs or different memory because things slightly were different on the way there. So anyway that was a little slice of issues in those two products and then the Sleuthkit bugs have been fixed and they were fixed in version 2.0.9. They're actually fixed within like three days or something like that. You can draw your own conclusions of open source versus commercial software. It was like a week. I took them a whole week. Anyway, so we had a lot of people here who used Ncase Enterprise. This is probably the big money maker for guidance. It's the much more expensive version. The version of Ncase Forensic we own cost about $6,000 and we have clients that own Ncase Enterprise and their installs are in the $125,000 to $250,000 range. Now companies are willing to pay that because they find Ncase Enterprise extremely convenient. And it's convenient because it doesn't really add any analysis benefits. It's convenient because it allows you to remotely acquire machines for analysis. To remotely look at the processes that are running on machine to remotely grab the memory and to remotely grab the hard drives of that machine. Store them locally on your workstation then do your analysis at your own time. If you're a big global company and you've got 50 offices around the world and your instant response and fraud and Forensic's team are all in New York you really don't want to be putting them on 747s every time there's an incident anywhere on the planet. It's especially true because it seems that once Enterprise is deployed, Ncase Enterprise they're much more into phishing expeditions that they will not wait for something that is specifically look like somebody's committing fraud against them. If they feel something's going wrong it's so convenient it's not that hard to go out and pull down the whole marketing department's hard drives and look at all of them and see who the one who had the insider trading information. So that's much more convenient for them because you can go investigate people without them knowing. You don't have to go to their cube and pull their hard drive out. You don't have to have some person from a different office very mysteriously walking around or being there at 3am. You can just say if their machine's on at night grab this at 3am give me their hard drive and when I come in the morning I start sitting there for analysis. I'm not saying that's a bad thing. I'm just saying that this is why people are willing to pay $250,000 for this product. So would you think Ncase Enterprise is only used for internal investigations? I'm guessing the significant number of those people that raised their hands were actually law enforcement officers who use Ncase Enterprise which we were surprised about but it does seem that Ncase Enterprise is used sometimes because of the law pushes police officers to use minimally invasive techniques minimally invasive to image somebody's driver remotely over the network than it is to go pull their hard drive out, right? Since the latter means you can't do business anymore. And so I think Enterprise has been used for that situation and certainly guidance puts forth in their public documentation the idea that evidence collected with Ncase Enterprise alone should be good enough for civil or criminal lawsuits. In fact they have an entire legal document written by their chief legal officer that lays out case law and a lot of justifications of why it should be good. And it turns out that courts have accepted Ncase Enterprise evidence in the past, right Chris? So there is some case law backing them up that you can use Ncase Enterprise to gather evidence. It's not just for internal investigations, it can be used for law enforcement. In our case is actually a couple of our clients use it to do their own internal investigation and then they turn that data over to the US Attorney or to the local district attorney. And so the initial analysis is done by their own people and then later analysis is done by police investigators. And here of course is a quote from them, Ncase Enterprise is ideally suited to recover and authenticate data over a local or wide area network. So please remember that phrase. Okay, so should we trust the evidence gathered by Ncase Enterprise? Ncase Enterprise contains a rather complex script or system. It is not extremely well documented and this is kind of a point we want to make that for a product that's very, very important and that has sent probably a lot of people to jail it seems to be the kind of thing that should be at least the crypto system should be open bare for people to have lots of peer review perhaps by guys like Ed Felton and Dave Wagner who love looking at that stuff for free and then writing about it on their blogs. And so when we wanted to learn about Ncase Enterprise we can't afford a $200,000 license but we did observe its use, its legal license use by our customers in their enterprise environments and then some testing during that our lawyer sitting in the front row wave Joe. If anybody threatens you for doing security research I recommend hiring Kecker Van Nest of San Francisco and especially Joe Grant $525 an hour. You're buying lunch bro. So anyway to do this kind of research is actually very difficult and I think there's a lot of enterprise software out there that doesn't get good security research because 13 year olds in the Czech Republic can't download it off BitTorrent and because most legitimate organizations like us can't afford it in this case we were able to use it legally within our customers because they're interested in the outcome themselves. When we wanted to find out how the crypto system worked there were a couple of public documents from guidance neither one of them really lay out the crypto system in what I would call a scientific manner or a manner that corresponds to if you read a paper in a cryptography class in college that would correspond to that. Actually probably the best documentation was when we asked them we did receive a slide deck that they give to us in sales presentations with security teams who ask which was nice of them but actually the best documentation overall was their patent applications. Guidance software has been issued two patents on the ability to remotely acquire network drives as well as a patent on how to do a restart of that acquisition and although the patents do not specifically say this is in case Enterprise Edition 6 it seems that the information the patents corresponds to all the other publicly available information and also corresponds to our own testing and so we are going to use the patent applications for our cryptanalysis and for our discussion today but I just want to kind of lay it out maybe this is the kind of thing that we can get a nice big academic white paper from them that was reviewed in the future people that make products like this so one of the things you do when you want to set out and build a crypto system is you have to lay out what your goals are and a lot of crypto systems are broken because the goals are incorrectly understood maybe you really want integrity protection and use a confidentiality protection or Cypher on data does not give you integrity protection for example but might give you a reasonable amount of confidentiality protection so when we sat down and thought to ourselves what would we want to do if we had to design a system that grabs people's hard drives with a network we thought the things we want to do is authenticate what machine we are going to keep that hard drive secret as it flies across the network keep the hard drive image from being changed as it flies across the network obviously you don't want it changed by people we don't want to authorize the user asking for the target machine we obviously don't want to create a back door in all of our machines that anybody can use to grab their hard drives our analysis has shown that the MKS Enterprise system meets all of these goals except the first one the authentication of the target machine which in our opinion is the most important but I'm sure there can be reasonable discussion of whether or not that's actually the most important goal and they kind of actually almost admit to this in some of the documentation saying what the goal of the MKS Enterprise system is mostly about user authentication the MKS Enterprise, the examiner's workstation which is basically encased forensic with some other stuff wrapped around it this is where a person sits down and says I want bobscomputer.corp.bank.com or an IP address there's a thing called a SAFE which is a server that generally runs full-time on a corporate network the SAFE is kind of the trusted introducer it knows who all the licensed examiners are and it allows it authorizes and authenticates those examiners and then does a trusted introduction between the examiners and the servlet now they use the term servlet which really drives us nuts because we do a lot of Java stuff it has nothing to do with Java it's just a small program, it's like 600k it's a user mode program as well as a device driver that's blown out to people's hard drives so that you can image their hard drive so the examiner workstation has a public-private key pair which comes from guidance software that's then registered with the SAFE the SAFE has a key pair it's part of a big human in the middle authentication process the servlet does not have a key pair and that's what we're about to talk about so I can't really read these, these are screenshots from the patent which our lawyer has told us we're allowed to use this is the initialization of the crypto system when you do the install this looks okay the SAFE generates its own key pair sends it to guidance, there's some kind of human in the loop situation where a human verifies that you're a licensed user and stuff and then the SAFE rules its own servlet so it creates a setup.exe which is a setup program that installs the servlet on all the targeted workstations and that setup.exe has the public key of the SAFE burned into it so this is how you bootstrap trust between all the workstations and that enterprises encase server is that you push out a binary that has the key burnt into it when you want to do an examination it contacts the SAFE and says I want to do an examination and when it does so this actually works out pretty well it's a standard kind of mutual authentication using public private keys, you generate random numbers you send it to each other, yada yada yada the SAFE has a big list of who's allowed to do what this seems to work fine so the part that we are concerned about is this part so I'm going to try to actually show this in the PDF to make it bigger is that at all readable or do I have to make it bigger here we go is that readable to you guys? actually better so our components here are the client machine which is the examiner the vendor who isn't involved in this transaction the server, the SAFE this is the full-time server running on the network the keymaster who is like a super user who's not involved and then the target machine this is Bob so Alice in this example is our examiner Bob is the person who's being investigated then Malice is the person who actually committed the crime and happens to be on the same switched Ethernet network as Bob unfortunately for Bob so if you look at this actually people that have done a crypto review it kind of actually gets obvious what the issue is here the server generates a random number it signs that random number with its private key it sends that package to the target machine so now the target machine can say hey that's a random number and it came from the SAFE and because it has the local public key it can verify that signature so it does so it generates its own random key and then it sends its random key and the original random key encrypted with the SAFE's public key here a couple other things happen this creates a one-time session key for AES symmetric encryption and it encrypts it with this random key here what's missing from this handshake I'm sorry authentication of what of the target machine the target machine has done nothing cryptographically to prove who it's he is all you know as the SAFE in this situation is that the target machine has your public key so unfortunately in the general use case of Ncase Enterprise a lot of people blow out the servlet as part of their standard build or something like an active directory on boot script and so every single desktop and workstation and server in the entire enterprise has exactly the same binary on it and that exact same binary has the exact same public keys and it turns out that as long as this handshake goes to one of those things it always looks the same I mean the random number is different but there's no way for the client to say I am this client later on in the handshake there's actually a little thing where the examiner sends a package that says oh you're supposed to be at this IP address right and the guy comes back and says yep that's the IP address I'm at and the servlet goes and locally looks in the register so all that means is that this machine that it's asking thinks that it's IP address so this hopefully takes care of maybe some mistaken router issues, routing issues stuff like that it will protect you against the most simplest attack you can possibly think of here which is just doing a TCB port forwarding with Netcat but it does open you up to a bunch of other things basically anybody here who's ever plugged their computer into a network and it automatically works like magic fairy protocols like a magic fairy comes along and sprinkles magic fairy dust on your ethernet cable and that magic fairy dust is DHCP DNS and ARP and none of those protocols are secure none of them use any cryptographic verification of what's in them and there's lots of attacks against all of them and so in a corporate network and at any normal corporate network there's lots and lots of different ways of making somebody across the network think that you own the wrong IP address or what if malice just takes over an IP address if I'm malice and I know you're going to image Bob's workstation tonight at 3 a.m. before I leave at 10 p.m. I change my IP address and I take over Bob's IP address and if there's a static mapping the DNS doesn't name right if you're not doing like dynamic DNS updates and Bob's computer pops a little box saying oh you have an IP address conflict but Bob's not working anymore because it's 10 p.m. the image happens at 3 a.m. it goes it does a static lookup it goes and talks to my machine and my machine now has Bob's IP address so I don't even have to do anything to the servlet and it comes and images my machine and the examiner thinks it's Bob's is the most basic way there's a lot more complicated ways ARP spoofing DHCP spoofing I think DNS attacks are interesting if you have a situation where the examiner is using DNS names and some IP addresses attacking the internal DNS infrastructure is real easy I've never seen a corporate network where like their internal dynamic DNS which is tied to DHCP is updated securely basically there's really no way for NKC Enterprise to figure out exactly who's who it is trusting that a machine has the right IP address at the right time and that DNS is working so there's arguments I'm sure guidance will argue this isn't a big deal which they can have reasonable arguments that you know it's admissible to just go across and say somebody had an IP address we think and so we grab some data off of them and so that's admissible evidence we're not going to make any legal arguments for that stuff but to put forth a metaphor if the old way of getting the hard drive is the police officers come to your house and they kick down the door and they put you in handcuffs and then the forensic people come in and they bag up your computer and they take that computer to a lab and that sucker's got a sticker on it and whenever it changes hands they sign the sticker for chain of evidence and they pull that hard drive out of the computer they're pretty darn sure that's your computer you know if somebody lied somewhere in that process there's no way for an outsider to all of a sudden make that you know the hard drive magically change so in a corporate environment that would be like if I want to go look at Bob's hard drive I walk down the stairs go to his cube pull his hard drive out now obviously there's an authentication issue of is this Bob's hard drive is he the only person that had access to the hard drive these things have been dealt with in the courts in the past but in the in case enterprise situation instead of going to Bob's cube and get the hard drive on the floor and I look at the cube farm and I say who here has Bob's hard drive and the first person who comes to me with a hard drive I say thank you and I put a stick at note that says Bob's hard drive on it right you're trusting all the people on the network not to screw around and change with Bob's hard drive and that includes Bob Bob could come and say oh this is my hard drive that you're going to examine right and one of the basic problems here that probably can't be solved is remote attestation you cannot have remote attestation of software running on a computer that is under full control of the attacker this is the whole idea of TPMs interesting computing bases none of them work as you've seen from some interesting things and even if they did work there are no commercial operating systems that actually support integrity protection using a trusted computing base and so there's two issues here one with the basic cryptographic design you can frame people but the other issue is that as an examiner if you think the person you're examining is advanced it's not that hard for them you know it actually the servlet doesn't have a lot of anti-reverse engineering protections would not be that hard to patch it and make it not see physical drive drive one it only sees physical drive zero for example or you know actually probably standard root kits could be pretty easily modified to to wipe out the sectors on disk that in case grabs it uses this interesting iSCSI open up the SCSI open up the local hard drive kind of function that you could patch pretty easily with a root kit in the kernel so anyway we had a couple of suggestions for guidance this is generally used in big windows corporate networks those guys have active directory computers and active directory networks have their own identity in Kerberos it's the name of the computer with a dollar sign you could use that to bootstrap trust it's not perfect but at least an attacker would have to attack AD and have the equivalent power of a domain admin which at that point they can plant evidence on anybody's drive anyway so at least you can raise the security of your active directory network and the other thing is if you don't want if guidance doesn't want to only support AD supported networks you can have servlet registration where the first time the servlet is booted it generates a key pair it has a hardware fingerprint it registers itself and whenever it's IP or DNS name changes it registers that change this is not perfect and is attackable but at least it would create an audit trail that would make it pretty obvious to a human being if somebody all the sudden the last time when you do examine Bob's workstation it's key pair changed right it could be something they'd be able to trigger on and warn people about and give you an audit trail so our suggestions for triple E users the lawyer will talk in a second but our suggestions is if we're using NKS Enterprise I think it's fine to use for initial incident response you don't want to take servers down if you think they've been broken into but you're not sure about it I think it's great for initial investigations for fishing expeditions to look through stuff and especially if you're looking at the hard drive of your non geeks right unlikely your marketing department is going to be patching and start dot sis in the kernel but if you are going to use NKS Enterprise to gather evidence I strongly suggest that you grab the physical drive afterwards and authenticate that the data the evidence is on the physical drive the whole idea of MD5 if NKS Enterprise falls apart because if you image a working machine the hash is going to change just as data accesses change things like the access times so you have to authenticate the individual files right yes this email was on there yes this PDF was on there if you want to do court testimony do it based upon the physical image that you gathered be careful investigating your system administrators or any of your geeks that have the ability maybe to manipulate NKS Enterprise either on a network layer or by patching the kernel and you probably want to keep that physical hard drive forever if you must only use NKS Enterprise you need to authenticate that the drive belongs to that person through other means right look at what its system idea is pull its Kerberos key out of it and compare it to what the domain server has that kind of stuff is critical so that you don't get tricked into grabbing the hard drive that doesn't actually belong to that person so our conclusions and we'll have Chris Ritter speak for a couple minutes in just a second but our conclusions are we don't really think forensic software vendors are paranoid enough they're not paranoid like Microsoft's paranoid or Oracle's paranoid and so I think a lot of work needs to go into secure coding defensive coding and doing things like making the product the fact that NKS uses the Aladdin e-token turns off depth protection does a virtual protect X into the entire memory space and so there's no buffer overflow protection either stack protection or NX bit protection over the entire memory space because of that dongle and that's the kind of thing that needs to be looked at if you buy forensic software you need to use security as an acceptance criteria the government does lots of testing and forensic software none of it's security testing it's all does this thing image correctly right that kind of stuff does it generate md5 some it's just to ask oh well now can something load up into my kernel and we think that those testing those methods need to be public they need to be negative QA not just positive QA like so we're on right now and the acquisition of system images over a corporate network is inherently dangerous it sounds like we're beating up on guidance we're just looking at them because they're an industry leader there are other products that claim to do this and we're sure that they have the same kind of issues it's an inherently dangerous thing to do if you can kick somebody's door down and get the hard drive or knock nicely I don't know but the inherently dangerous to go grab system images that way okay so we'd like to thank these guys and up next when we're doing this research we're kind of thinking what would security flaws mean for forensic software evidence and so we called the EFF and we called Jennifer Granik and they both pointed to the same person and that person is Chris Ritter of Residential Fellow of the Sanford Law School who will talk just real briefly about how courts deal with forensic evidence and might deal with security flaws in it so thank you so I looked at some of the the legal implications of this work and work like it that demonstrates there might be vulnerabilities in the software and the real lever here is how likely is it that some sort of compromise happened to your system is it enough to just be a criminal defendant and say oh yeah my system was tampered with with nothing well probably not but you know I think the likelihood is an important issue but I'm going to review a few different doctrines that are relevant authenticity you need to put evidence in court only if it's authentic something called the best evidence rule and reliability and but yeah the likelihood of malicious conduct occurring is always going to be a lever in those so and there's two sort of things there's data hiding attacks and the possibility of malicious code execution or tampering with the evidence data hiding is less of a problem from an evidentiary perspective first of all if it stays hidden nobody's going to know about it but also incompleteness is not something courts are as concerned about if the evidence is incomplete they have what's in front of them and the fact that it's incomplete may go to the jury and they may weigh that as a consideration but it's probably not going to get kicked out another sort of data hiding thing you might think about is that lawyers in both the civil and criminal context have obligations to find data that might be helpful to their opponents but I think it's unlikely that that obligation would extend to data that's been hidden even from forensic software it usually doesn't even extend to deleted data so if there's possibly evidence that's been tampered with is it authentic and the federal rules of evidence say authentication of a document is satisfied by evidence sufficient to support a finding that the matter in question is what the proponent claims that means if the judge thinks a jury could find it's authentic the judge will send it to the jury so it's not a very high bar but you can also make these arguments to a jury who may factor that into the weight of the evidence so one way authenticity is looked at or determined one factor in authenticity is the chain of custody is what you're presenting in court the same as what you originally collected to the extent you know there's been a compromise your ability to demonstrate that is going to be eroded or eliminated another thing you need is some sort of indication that the evidence is what it purports to be and sometimes you have a person with knowledge this I saw this document and I know it's correct but sometimes you don't for example a log file 10,000 lines log and line 1274 is an issue so there's a rule of evidence for this situation and it says you can authenticate evidence by describing a processor system used to produce a result and showing the processor system produces an accurate result so it's that accuracy and a couple of courts have actually found that evidence that's susceptible to being altered even with no firm evidence that there was any alteration can be excluded there's a great one where someone pulls down evidence of boat ownership from a US Coast Guard database on the web and the court says the internet's inherently untrustworthy and hackers can change it and kicked it out there's one about website postings from Nazi groups and one of the people in the case was a skilled computer user and the judge said well maybe she altered it so he kicked it out but that's definitely an exception usually courts let in printouts from websites and such so then you've got the best evidence rule I'm not going to talk about that too much again that comes down to you can use sort of a duplicate if it accurately reflects the original same as authenticity and reliability there's sort of there's a case called Daubert vs. Marrow Dauft pharmaceuticals where the court lists a bunch of factors and some of them are whether there's been testing peer review and I think as you heard from these guys there could be more another factor is whether the techniques have a known error rate and I think susceptibility to attack counts as an error so the higher the susceptibility the more likely you'll get evidence kicked out whether there are standards governing their application they kind of are but you know they're a little they're variable and whether theories enjoy widespread acceptance and they do right now but I think as you know if more vulnerabilities come out acceptance will drop so in my conclusion was that forensic tools aren't magic they're software and like anything else they're subject to attack and because they play such a critical role in our court system lives and property are at stake you know courts need to be sensitive courts have denied defendants the opportunity to do their own forensic analysis just accepting that the forensic image that the police had was good enough and I think that is definitely the wrong way to go I think for finding hidden evidence or finding evidence of tampering both sides should have an opportunity to look at the data sometimes you may not have a hard drive that was locked in a safe that you can compare to like if the enterprise software was used and in that case courts need to be thoughtful and for more information you can look at my paper it's on my partner's website thanks