Saturday, June 30, 2007

Snort and the IT Appliance Fixation

I'm a huge fan of Snort, but I am more than a little dismayed at the lack of acceptance that it has in the community. Now I know that most people who read this blog will think that I have lost my mind, but hear me out.

There is a mindset that I see with IT people that goes something like this:

Manager: "We have a problem. Our enterprise isn't covered by IDS sensors."
IT guy: "I know just what we need. There's a vendor that has an appliance . . ."
Manager: "Get me three bids."

I call this the IT Appliance Fixation. In my experience, the "typical" IT response to a problem is to buy a box that someone can hang on to the network. The purchase is based largely on vendor advertising, sales pitches and the vendor's website. The problem is, when it comes to intrusion detection, there is no better sensor than a good old snort box. I will grant you that building a snort sensor takes time and writing/configuring snort rules takes time too, but what's the cost benefit ratio?

Assume that a Vendor supplied IDS will cost $50,000 just to purchase. Factor in the time spent finding the right product. Now consider that an organization could easily spend that time configuring a Snort sensor baseline image, and roll that out on computers that are past the end of their life cycle - see where I'm going? Now factor in the open source nature of Snort's rule sets, and you could easily save money in implementation, and use the money to hire a decently paid IDS analyst.

The bottom line here is that the best solution is not always the newest one, or one that comes with vendor support. If you are in a position to do something useful on a network, it does not always have to cost money.

Friday, June 29, 2007

Office 2007 Event Logs

A coworker walked into my office today and asked if I'd take a look at a drive to see if I thought the former owner had tried to tamper with the contents. After a little "pokin' 'round" I exported the event logs and opened up my event viewer to look at them when I noticed another log on my box. Not the ones I'd exported, but a new event log that comes with a default installation of Office 2007. So naturally, I discarded the investigation that I was supposed to be doing and began investigating what interested me. My proclivity for doing things like this is the reason that my desk is a shambles, but that's a tale for a different day, on to the new event log!

OSession.evt isn't incredibly interesting, but it might be useful in an examination. Below there are two of the entries that I carved out. . . You'll note that the application (Word) and the times are identified. That might be useful in a case where time was an issue.

I have not yet figured out what the active time entry is. It does not appear to be something that would be associated with actually working in the program; the first entry below was me opening Word, putting in some text and then saving and closing the document - active time 0 seconds. The second entry is from the first time I opened up Excel. I'm not sure what I did there, but it was probably something to do with carving out a file and then opening it with Excel. I have not found anything official that documents the log, so I would be interested in links to reliable documentation.

I did not include everything from the log, but it appears on first blush to have all the same features that the "big 3" event logs have, so you can find times. Times associated with log entries are the times that you exited the program, so an entry at 1345:00 hours that was 901 seconds long would have started at 1329:59 hours.

ID: 0, Application Name: Microsoft Office Word, Application Version: 12.0.4518.1014, Microsoft Office Version: 12.0.4518.1014. This session lasted 20 seconds with 0 seconds of active time. This session ended normally.

ID: 1, Application Name: Microsoft Office Excel, Application Version: 12.0.4518.1014, Microsoft Office Version: 12.0.4518.1014. This session lasted 172 seconds with 120 seconds of active time. This session ended normally.

Sunday, June 17, 2007

Quickly Cracking EFS on Vista (and getting local admin rights too)

Kimmo Rousku has some interesting observations and a walk through on getting Administrator and/or System level rights on Vista through the use of a recovery CD. One area that he mentions is that you can crack EFS encrypted files with this as well.

I have not toyed with or analyzed Vista yet (except to try and help a coworker configure a static IP, which was rather unpleasant), but gaining Admin/System rights might be useful for acquisition if used in conjunction with Bart PE and a write blocker. I'll defer to those that have done more work here to decide.

I'd guess that if you followed the steps for cracking PGP that I outlined previously, you could use this to crack the EFS files without cracking the SAM. I have no idea if this would be faster than cracking the SAM and using traditional forensic tools would be, but it's always nice to have more than one tool in your toolbox.

Saturday, June 16, 2007

RAM and U. S. Courts

I subscribe to quite of few mailing lists. In fact, I'm one of those people who cannot keep up with the volume of email that I receive because I get so much of it.

My usual strategy is to let gmail handle what I'll read by adding a star to those people's emails that I have a personal relationship with, friends, smart people, etcetera; then all I have to do is skim subject lines of unstarred posts before selecting and deleting those (BTW, I star all comments that come in here under the smart people category ;-)). The following almost got cut, but I'm glad it didn't.

An article on Cnet, reports that a Federal Magistrate in the Central District of California has ordered that Torrentspy turn over masked IP addresses in a ongoing civil case that the RIAA brought against it. Why is this interesting? Because the Magistrate ruled that even though the data in RAM is in "electronic storage."

I'm not a lawyer, but let me see if I can put this issue in a nutshell: In criminal and civil cases, there's a pretty well accepted rule; you cannot force someone to create a document that they do not already have, and then force them to produce that document. So, I couldn't send a subpoena to and ask them to produce something worded like this:

"A document containing Customer John Smith's Social security number, mother's maiden name, his last three log ins to the system and his credit card information."

Unless of course, had a document like that already. From the article, "a federal judge in Los Angeles found that a computer server's RAM, or random-access memory, is a tangible document that can be stored and must be turned over in a lawsuit."

What I found most interesting was the discussion of the issue. The Judge's ruling explains some of the history of RAM in Federal court cases, and since there are not a lot of them, I found the analysis enlightening.

You can find the original here, but I have included the discussion below. The case is Columbia Pictures et al. v. Justin Bunneli, et al. CV 06-1093 in the Central District of California

Discusson of Websites in general.

Operation of defendants' website.

Discussion of server log data.

RAM is Electronically Stored Information according to the Federal Rules of Evidence:

MAI Systems Corporation v. Peak Computer, Inc., 991 F.2d. 511, 518-19(9th Cir. 1993) citation:

Perfect 10, Inc. v., Inc., 2007 WL 1428632 (9th Cir. May 16, 2007:

Three more cases discussing RAM:

If you read the decision, you see that there are several cases where courts have ruled that data in RAM is both tangible and recoverable. What does all this have to do with forensics? Well, what if you had a case where a kid had been kidnapped after chatting with the bad guy in an Instant Messaging session and there was not any logging of chats?

Assume that you could collect the contents of RAM and find the smoking gun there (say, the offender's IM name) and this led you to the bad guy, and you later discovered that he killed the kid. If you had those kinds of data from RAM, that could be incredibly important to your case. If your evidence came up for a supression hearing, you could point your prosecutor to some other cases where other courts had examined the contents of RAM as evidence, and that might be useful to help put our bad guy where he belongs by helping get the chats you recovered allowed into evidence at trial.

Monday, June 11, 2007

"Defeating" Whole Disk Encryption, Part 3

In Part One, we reviewed obtaining the last 16 characters of the PGP password from a computer that was live. In Part Two, we reviewed how to set up your VMware box so you can boot the image. In this post we will review the options for imaging the computer, be forewarned, neither is a perfect solution.

Tools you may need:

1. The PGP recovery .iso. You will need the correct .iso for the version of PGP installed on the computer. You can find the files linked from this page.

2. You may also need the original media used to install the OS on the computer, or a version that is very close. In other words, if the computer is running XP Home, you will need an XP Home CD. It's usually better to have the one that was used to install the OS on your suspect's box, but I've had success without having it.

Now it's time for the choice we discussed in post two; do you need unallocated space? If you don't, you can jump down to the decryption option, but really, now would be a good time to back up your VMware files - you'll need them so you can go back to a good image, and to document your work. Let's call this back-up 1.


Boot your drive, enter the PGP password and get through the windows boot sequence. If you have boot failures, use the OS CD to get the necessary files and continue to reboot until you can boot the computer. Once you have the drive booted, you can use a variety of tools to acquire the drive back to the share on your computer.

You may need to add another drive share if you do not have sufficient drive space - follow the steps you followed to add a shared folder if you do.

The advantage of this method is that you will be able to access unallocated space and file slack on the drive. The disadvantages include having to make multiple changes to the drive which includes adding files. The good news is that another examiner will have to follow the same steps (when using your computer). The files that you add won't be evidentiary in nature, but you are changing the evidence; however, there is no other option of which I'm aware so I think it's defensible.


Edit your VMware session and change your CD ROM device from the physical device to the .iso image that you downloaded from PGP.

Save your settings and boot the VM ensuring that you are booting to the CD first.

The CD will ask for the PGP password and run through a decryption dialogue. I'm writing this from memory, so I won't try and outline the steps, but it's self explanatory. After you begin decryption, take the day off because you are going to have long wait. I've found that it takes 16-24 hours.

Once the drive is decrypted, take a snapshot with VMware and then save those files as backup 2.

Now you can boot the computer, or pull the decrypted VM into Encase for analysis. You won't see anything in unallocated space. Apparently, VMware only decrypts allocated files, but you should have all the active files available for analysis. Again, not perfect, but better than nothing right?

A couple of other thoughts:

I suspect that putting a new drive in the suspect's computer and installing a new OS with VMware etc. on your drive, then booting the suspect's drive as a VM would get past the compatability problems - if anyone has time to test this, I'd be really interested in knowing your results.

If you don't have the PGP password, AccessData's Password Recovery Toolkit and Distributed Network Attack can be used to brute force the partition. I haven't tried it, but they claim that this is possible.

Sunday, June 10, 2007

What's in your (electronic) wallet?

I was looking at RSnake's Mr. T the other day. For those who don't know, Rsnake developed a pretty simple proof of concept showing the information that your browser will disclose to someone with a website. You can see a demo here. Notice that your browser gives up your web-based email address?

This got me thinking; why waste your time phishing for passwords? It's a given that everyone reuses passwords. A bit of googling turned up turned up a small academic study showing that the average was just over 3 per person.

So what does all this mean? Where does almost every website send your password? Right to your email account in most cases. So if I can read your email, I can own any account I want that is associated with that email. I can get a password reminder, or a password reset sent there and if I'm smart, the user would never know until it is too late.

So why phish for passwords? I could create a site that grabbed all the user's data (and probably a bit more) than Mr. T grabs, and get the user to give me a password. I could give the user something that they want (think Free Porn). Since I have a one in three chance that the password, (or even one in ten for that matter) I could go take over a lot of users lives. Bank accounts, your resume, your mother's maiden name, passwords to your favorite sites? I read user's email all the time - that's all there for the taking.

Now the second question is; What to do about it? This is a acknowledged problem, but short of carrying around an encrypted USB drive (user's don't want that), or using some form of two-factor authentication, I don't see any answers on the horizon.

The scary thing is, if I'm thinking about this, someone's already doing it.

Wednesday, June 6, 2007

New updates are coming, or I don't like group papers

I am in the process of finishing up my MS this month, so things are on hold here until I finish up finals, term papers and a short teaching gig this week.

The worst part of grad school is working on group papers. It is hard enough to do your own work, but when you have to share the load with 3-5 other people, it makes things even more complicated, and if you are the guy who has to edit and produce the final product, your life just sucks.

Now where did I leave my APA guide. . .?