 So, I'm Charles Edge and I'm doing 10 ways how to not get caught hacking on your Mac. Most of this is a little rudimentary, but hopefully you're doing it, and if not, hopefully you'll start. Who here's got a Mac in their lab right now? Sweet! The first year I came to Defcon with my 540C, I was the only one, so I sucked. Now I suck less, but I still suck. Anyways, I don't actually...never mind. Alright, so a little bit about my company, which nobody cares about, so the talk. First, I'm not condoning doing anything that requires that you need to use any kind of covert channels or anything like that. That by the way is the best covert channel ever. So, wow. Alright, so the more collaborative the better, although we've got like 10 minutes left, so never mind on that. So the first thing that I was going to talk about is timestamps. So obviously any time that anyone goes to do any forensic work on your machine, one of the first things they're going to do is probably plug it into Incase, and Incase is going to catalog everything based on timestamps, right? So clearing out those timestamps helps to make it more difficult for anyone to prove that you did anything based on what time you did it or logs of that type. So this isn't just dates, files created, or files modified, but both of those. So two different variables there to make sure to take into consideration when you're trying to hide your tracks or whatever. Don't touch it! Don't touch it! So... Throw the ball at that guy. I didn't just do that. Yeah, tell me about it. Time stamps! Alright, so my laptop just crashed. Alright, we're going to do this like low budge style. Alright, so when changing the timestamps on every file, make sure to do it on everything. Basically the concept here is you're never going to remember to change the timestamps, so cron it out. If you're running Tiger or above, make sure to launch D it out because cron is deprecated. Having said that it's deprecated, it still works if you invoke it, but you have to reboot after you invoke it for the first time to undeprecate it. Apple is great at deprecating services in that manner in favor of better services like launch D, which is what they replaced cron with. So basically you build a shell script, you add an XML file into launch D, and you tell it to run every night. If you don't feel like learning how to use launch D because you're only using the Mac for certain types of things, then you can actually just use a program called Lingon, which gives you a graphical interface for running launch D. It looks a lot like the MS config screen of a Windows computer. How many people have seen that screen? So nobody? Yes, I've removed spyware in the past. Alright, so if there's no history on your computer of what you've done, then it's going to be very difficult to trace what you've done. So clearing out those history files, not just removing the timestamp, but removing the actual history, specifically your shell history, and that's not just your shell, but your root user shell and any other users that you happen to log into, and also the shell of the remote node that you might happen to be tapping into. Many of the GUI tools that you run, like if you're running ARD and you're sending a shell command out to 100 machines or something of that nature, you're actually running shell commands. And sometimes you can actually go into the root user's shell history and see what's happening, which is a great way to reverse engineer what Apple's doing, because they'll write a cocoa interface, and then they'll write these shell scripts underneath, and they just won't call them .sh. They'll just have a name like discard D or something of that nature. So clearing the history files from your system is a great step. And this, what did I write there? Oh, well, whatever. So keep the trash empty, and when possible, do a secure empty trash. Personally, on my machine, I have it tabbed out so that every night it does an SRM of my machine, which is just the actual command. The SRM is just the, is that better? Yeah. Why didn't you say something sooner? You didn't want to be that guy that says, speak up. Anyways, sorry about that. Dude, it's Intel. Never mind. All right, so just throwing a file away doesn't get rid of it, blah, blah, blah. Emptying the trash is basically in an Apple, you can go and under, well, not under that. But there's this whole security trash. There's actually a command line shell for that, SRM. So SRM has a dash F if you're going to script it out. Make sure to put that in because it forces the emptying. Otherwise, if you have a script that runs at, let's say, 3 AM, or if you're like me, 5 AM because you're still up at 3 AM, then the dash F will force it in case there's a file in use or hidden or something of that nature. So you can also use the dash M flag, which you can use with the dash F flag, which will do seven passes of random data. And hopefully whoever's doing forensics on your machine doesn't have an electron microscope. Because otherwise, I don't think they're going to find it, right? Does anyone disagree with me on that, by the way? No love. Come on, anyways. All right, so while you're looking at your logs in your history, don't forget to trash your firewall logs. Apple has ipfw.log, which will often log outgoing requests as well as incoming requests. It definitely logs everything from a stealth mode perspective. So anytime it kicks stealth mode in, it goes ahead and logs that. So don't forget to delete your log archives, although if you're deleting your logs every night, that won't really factor in. But that's still something to remember. How am I on time? I got 10. Sweet. Halfway through. OK, so who here uses FileVault? Who here has managed to actually decrypt a FileVault? OK, so if you're using an Apple and you're not using FileVault and you're doing anything that you don't want anyone to intercept, what's the logical conclusion of the fact that no one raised their hands that they've been able to decrypt a FileVault? Use FireVault? Yay! All right. So who backs up? OK, so you didn't actually lose more than one a day's worth of work, which totally sucks if you stayed up till 6 AM, but that's aside from the point. Yeah, I've lost my FileVault, too, but not since 10-3. And I still haven't lost any sparse images that aren't automatically created. So another thing is you can actually create a sparse image inside of FileVault. Therefore, you need to separate discrete passwords to actually unlock it. FileVault can be unlocked using one of two different passwords, is that better? Using one of two different passwords, a master password and your regular password. So make sure that both are strong, blah, blah, blah. Your root password will not unlock the FileVault. So I use encrypted disk images for everything, especially hiding prawn from the wife. Bad joke, sorry. I couldn't help it. So like with FileVault, the encrypted disk images store the files in an encrypted manner. It's all pretty much AES. By the way, is there anyone from Apple? I asked that same question at Black Hat, and no one raised their hand. And then after my speech, two guys came up and said, hey, you know. So anyways. But at least you admitted you're a contractor, right? And by the way, Apple's got great security, I think, across the board. I mean, there are some holes, but they're proactively doing things in their own labs to try to approach that. So I think that's pretty strong for someone with, what, four and a half percent of the market share. So FileVault stuff's easy to use. If you don't use encrypted disk images, you can always also, or in addition to using encrypted disk images, you can use secure channels. The metadata and music files, who here has seen Johnny Longtalk? Not nearly enough. His latest talk is pretty, pretty funny. So if you haven't seen him, make sure to hit that. And then steganography, hidden images in iPhoto and things of that nature. And then something that some of us like to do is actually add false positives into your secure channel. So create secure channels that don't actually go anywhere. Nothing will make things take longer in forensic investigations than finding something in a file and just trying to track it down for months on end. Once again, I guess I put clear those logs. Although before I wasn't talking about regular log files, I was talking about histories. Most of the files on an Apple system are in private VAR log. That's one of those funny things about the way that Apple's done the stuff. You don't typically CD into VAR unless you're running OS10 server. You typically CD into private and then VAR and then logs. So if you buy a Mac and you open it up and you double click on the hard drive and you're like, where's my VAR? Where's my Etsy? That's where it's just going to private. From the GUI level, you can actually hit Apple Shift G and type slash library, and it'll pop up with all those folders that you're thinking are missing. So once again, run scripts nightly to remove those logs because you're never going to remember yourself and then always SRM. The next thing is secure virtual memory. If I were to grab a machine and go to do forensics on it, I would probably also look at the RAM and what was on the RAM when the machine was shut down last or before the RAM got wiped. So virtual memory is a place that people often look for that stuff as well. So when you use the secure virtual memory feature in Apple or in OS10, when you shut down, it clears out all that stuff. And by the way, the reason I decided to give this talk is because last year I noticed that about 10% of the people here were running on Macs. So I thought that it would be kind of good to say it's not Linux, it's not BSD. If you edit your rc.local or your rc.com and file, those edits will get overwritten. So use launch D when you're making these scripts. I would steer away from using Cron. So other forms of volatile data can obviously be accessed as well. Raids, this is my favorite thing. I store, from my non-speaking machines, I store my encrypted home folder on a XSAN volume. And basically, the XSAN volume has two USB jump drives, and it splits all the data, half, between the two jump drives. So the fact that I can't imagine that anyone would actually be able to restore that data unless they had both jump drives, even if they knew my password to decrypt it, because all the data is encrypted, and it writes 64K slices to each drive. So reassembling that data would be quite difficult. Without running XSAN, you can plug two jump drives into your computer, and you can just use that as an encrypted disk image or a file vault home folder. But when you use XSAN, you can specifically drill down, and you can determine how many slices go to each LUN or USB drive. And XSAN is written to run on Fiber Channel, but if you label the LUNs as free space, you can actually then take use of them inside of the XSAN software with a couple small hacks that are available on xsanity.com now. And if you're doing that, I can't fathom that anyone is ever going to be able to decrypt your file vault, provided that they don't get a hold of both of your USB jump drives, even portions of files, because they would never be able to actually, anyways. Does that make sense? Sweet. So the last thing is just don't keep stuff. It's hard to get in trouble for having something that you don't have unless someone is able to trace it back directly to you, for sure, no matter what. Physically destroy system disks and RAM. If you have extra system disks and RAM, that is. Don't keep data on your system. Doesn't mean that you don't have to keep data at all. There's lots of different ways to maintain data that aren't on your system. Peer-to-peer networks are funny enough becoming kind of popular for that. Secure channels on untraceable remote systems, which peer-to-peer networks. And then if you don't compromise the system too far, no one's probably going to find what you've put on the system. So if you're running an FTP server on an unsuspecting system, then people probably aren't going to notice. People typically in the Apple community, especially, only notice that their systems have been rooted. If their ISP calls them and says, hey, you're running this website that announces itself as though it were eBay and is asking for people's passwords, I'm not sure what that type of attack is. Never mind. But there's not a lot of security analysis that's done on most Mac networks. So if you find a Mac system and you compromise it and you just don't go too far, then chances are no one will ever notice unless they hire me. But anyways. So and then even in most small businesses, which is Apple's core market, entertainment industry, small business, if someone finds something, chances are it's not enough of a monetary damage for any feds to step into the situation. So they're probably just going to delete it, re-image the system. So it doesn't become quite as big a deal. Anyways, that's it, turbo talk. I kind of did it a little fast because I didn't have that much time. So I think we've got a few minutes for Q&A. It's all AES, you know? I mean, you mean from the, I have an analysis of the implementation. So decrypting and re-encrypting as opposed to the actual act of the encryption on the files. I haven't been able to crack it. And I've been trying for about a year. So, and has anyone else? It's as secure as both your passwords. I mean, in transit, one exception is if you're using network home folders and you're not using a public infrastructure, then there are times when the passwords are submitted over the network, but that becomes more of a networking thing rather than a localized troubleshooting thing. Right. But that's the way Umbutu handles. I mean, has anyone been able to crack encrypted home folders in Umbutu yet? Right. So I mean, it's the exact same algorithm and practically the exact same implementation, to be honest with you. LA County District Attorney. I'm not a great forensics guy. I've gotten called into a few things for entertainment stuff in Hollywood, but outside of Hollywood I haven't gotten. I work in Hollywood too. Oh. The way that it's come up in the past with me is I've found things and then I've gone to the LA District Attorney. I've handed them an IP address. They say, we'll get you a John Doe warrant. And then they come back with the physical address of who it was. I mean, in a lot of my cases, it's high profile and not necessarily high profile like DRM, but high profile like someone famous as Blackberry got hacked into or stupid crap like that. And I don't know exactly what happens on their end, because I'm not a law enforcement person. But I'm a pretty decent Mac person. And when those kind of things come up, LA County sometimes calls me or sometimes I call them. And that's when it's come up. Maybe there's a technical term that they use that they don't tell me. I mean, not that they would be hiding it, but maybe they think, oh, well, he's not a fed, so he wouldn't care. But if there's a better term that I should replace that with, not that I'll ever give this presentation again, then I'd be happy to. I mean, if there's a better way for me to ask for that that makes them think I'm smarter, then that would be rad, too. John Doe warrant, it's a very common term he says. Adaptex sucks on the Mac. I mean, Adaptex is awesome on Windows 2003. But on the Mac, their Mac support has just gone. I mean, if you use SCSI, go Addo, period, on a Mac. Hardware for the RAID host controller, usually Addo's. Oh, wait, you mean on my MacBook? On my MacBook, I'm using software-wise, XAN, and hardware-wise, I'm just using my USB interface. Apple pretty much did go straight to FiberChannel as far as there. And really, in the next serve, you're going to get a promise with a SATI connection. So it's not really necessarily as, you know. But you can totally use USB 2.0 with XAN. Mild on? Sweet. Bye, guys. Oh, do I have one more thing?