Monday, December 24, 2007

Blog, not dead

I have had some personal issues that have been intruding on my blogtime. Namely, I'm moving across the country. A couple of years ago, an agency that I don't work for started recruiting me, their recruiting ploy; going back home and doing the same job. Devious.

Long story short, I got an offer from said agency, told my present employer about the job and my agency offered to transfer me. I accepted.

The end result is I've been spending a lot of time arranging for the move. . .

Now a few random thoughts:

1. I was really saddened that Harlan Carvey decided to do away with the WindowsForensicAnalysis group on Yahoo!. I've thought about re-starting the group, but then I'm not sure that I have the time to do the moderation.

2. I do a lot of work with drives that have been encrypted with Pointsec. I've played around with the idea of breaking the encryption, and have done some initial research into the matter. Is there anyone out there who has looked into this, or is interested in collaboration? If you have/are, email me at bill (random gunk here @ .. wsxcvhuio) r i n g 3 . n e t.

3. The US. Gov's idea of of having 50 points that connect to the internet is a good concept, but I'm close to reaching the conclusion that the defense of USG's national assets is best left to the Department of Defense (they're the only ones who seem to do an even half-assed job of protecting their infrastructure). Further, do we really want 50 points that are FOIA'able for all to know about? Do Americans really want everyone to know that the FBI/NSA/CIA is crawling their site? There are some who argue that this is not necessarily going to be the effect of this memo, but remember, bureaucrats will strictly "the letter of the law." The upside is, of course, that if this is properly implemented, the Gov's security will be better. I'm skeptical that this will be the case, however.

4. A holiday spent away from your family is not a good holiday.

Friday, November 16, 2007

Comment spam =+ moderation

It has been a busy couple of months... more to come soon.

Wednesday, October 31, 2007

In keeping with the Internet security theme

This was originally posted at http://getahead.org/blog/joe/. It's a really good graphic presentation on Web-application problems.

Via gnucitizen.org:

Sunday, October 28, 2007

The final solution

Internet Security:




With apologies to xkcd.com

A couple of toughts and things to come

1. If you have not seen the Tactical Exploitation presentation by HD Moore and Valsmith did at Defcon this year, you need to see it.

There's good stuff there for forensic folks too. Things like http://whois.domaintools.com that some people don't know about. . . just good stuff.



2. When you do forensics on compromised systems, there is an inverse relationship between time and evidence; that is, the greater the time between compromise and examination, the evidence decreases.

A couple of files that I've found to be useful in exams - memory.dmp and drwatson.log (it might be drwtsn.log. . .). I'm going to do a do a longer post on this later on, but in short, attacker's tools often cause applications to crash. This is an easy way to find out how the attack was accomplished. WinDbg is your friend here. More later.

3. I'll be posting a couple of scripts in the near future. One will extract event logs from a remote computer, and the other gets services from a remote computer (similar to sc \\remote query), but it also extracts the PID and the path to the executable and command line.

I've been *really* busy in the last couple of months, between work and home life, but I'll continue to post when I've got something that I think is useful.

Saturday, October 6, 2007

Things that pain me

<\begin rant>It's been a really busy couple of months, so I haven't had much time to myself, but a couple of quick thoughts:

1. 5 Minutes a week isn't asking that much, is it?


I have a server that I manage - I've been putting in extra hours at work, but still somehow I manage to have 5 minutes a week to look at my logs. I wrote a shell script that looks for things like failed logins, brute force attacks, successful logins, etcetera; why can't IT "Professionals" spend a little time doing the same thing?

I'd challenge everyone to stop right here and take a look at the logs on the box that you are viewing this post from, or even better, a server that you manage - you'll learn more from five minutes of reading your own logs than you will from the rest of this blog.

2. Information security/assurance/warfare/technology/badgers are stupid

Until artificial intelligence (AI) gets significantly better (read, not during the course of your career), there will be no substitute for people doing work to analyze the products that computers create. There is, and there will be no appliance, no snort box, no grep expression, no program, no pretty graphic user interface that will be able to analyze data collected and conclude with a reasonable degree of certainty that something is amiss. People on the other hand can infer and from those infrences determine the likely answer to questions. Attackers are people, and as such are remarkably fluid and resilient in the face of adversity; that is, they can modify their behavior when confronted with new information or situations.

Computers by contrast, are rule based - if text == Attack! then drop packet - but if text == 0x41ttack, well. . .

This is not to say that computers do not do some things better than people. Data can be sorted and noise eliminated more quickly with them but people have to analyze the data. It's a waste of time to have IDS analysts unless you have an IDS, and it is a waste of time to have a IDS without an analyst.

3. Network engineers should consider layer 8 during design, and plan their security accordingly.

People are distracted, stupid, ignorant or indifferent to policy. Policy can prohibit me from visiting http://example.com, but someone won't get the word, or won't care if they do. Policy without enforcement is a waste of time.

The only way to secure a network is to build in security as the primary consideration. Some people have come to view their ability to access the Internet as some inalienable right on par with the 4th Amendment to the Constitution* - and IT workers seem to have become both the customer service representatives for said access. It's a sad state of affairs. If your network policy is not governed by a deny all, permit by exception principle, you are owned. Maybe not today, but you will be owned. If you have a DAPBE rule set in place for your network environment, you'll still get owned, but it will be easier to clean up.

People don't need to have access to webmail, CNN, ESPN, Homestarrunner or XKCD from work. They want it, sure, and maybe some do need CNN, but who can tell me of a blacklist that will prevent users from going to all of say, the malware sites that are hosted by blogger? I'm guessing that there isn't one.

3. When you say, "We need to educate the users." I want you to stop breathing my air.

User education is valuable, but only when it's actually education. Education is not the bi-annual, "click here to click through" our security training. You are wasting your money (ok, granted, this was probably some bureaucrat's idea of what security training should entail) and it's a waste of energy. Spend your budget on things that work - and if you've got extra time and money at the end of the year, then you can worry about user education. This also means that I'll be less likely to garrote you in a server room.<\rant>

*The Fourth Amendment to the Constitution of United States guarantees the right of persons to be secure from unreasonable searches/seizures by the Government.

Sunday, September 2, 2007

Order on contents of RAM upheld

I previously wrote about a California Magistrate's decision that the contents of RAM are discoverable. It seems that the order withstood appeal to the District Court. The full decision is here.

Interesting.

Tuesday, August 14, 2007

I am the CEO of Fantasy Land

There's been a dearth of posts of late due to the latest addition to the household - the 9 pound, 10 ounce kind that is. . .

Between Kid V.2.0 and l337 h4x04s, I haven't had much time to post, but rynhere breezed by with a few comments. I've edited them for brevity's sake, but since he keeps coming back for the answer, I figured I'd turn this into a post (being the CEO of Fantasy Land does have it's privileges).

rynhere: "why would anyone. . . [grab a password from memory] from a running and logged in computer?"

Bill: Well, I thought it was kind of obvious, but I've found it useful to have passwords ;-).

rynhere: Um, I'm sorry but [PGP ensures] that lost laptops (which are presumably turned off) do not pose a threat as the data is encrypted.

Bill: I agree that PGP does mitigate the risk of data loss, but that was not the point.

rynhere: Is this "defeat" intended to describe how you would take a turned off laptop and defeat the password?

Bill: No.

rynhere: I didn't see any mention of it beyond the obvious of brute force...good luck on that.

Bill: Actually, there are several products out there that will do just that Accessdata's PRTK and DNA come to mind.

rynhere: However, if you have a running computer that has been logged in and is in the windows interface, then let me give you the 1 step method of getting a copy of the data to run forensics against all day long. It's called hooking up a USB drive and downloading the meaningful contents of the native drive.

Bill: Leet!

rynhere: If your trying to obtain forensic information from the box however, as this article seems to illustrate; I'd like to understand how it is that you ask, (in your kindest, big-brother-is-watching sort of way) for this person to log into WDE and the network for you so that you can take their computer for the next 30 minutes to reverse engineer this password. Riiiight. Tell you what, if you can get someone to give you a logged in and running computer, then one of two things is the case,

1. Your the CEO of fantasy land.
2. Your in the wrong profession because you can clearly sell water to a drowning man. Go find your calling in life as a salesperson instead of geeking out on reverse engineering passwords to a running, unencrypted (once you've authenticated to WDE, the drive "appears" as unencrypted) box.


Ok, now to the point. If you are going to image memory over the network, there's a number of ways get the memory. If you have administrative rights on the box, you can use psexec to get a command prompt on the target's computer, then "net use" back to the drive under your control to execute the tools working as the administrator on your target's box. There is no "pretty" way to do a live acquisition, you are going to make some changes no matter what method you choose, but it's nice to have more than one tool in your toolbox.

Oh, and I have asked for and received a number of passwords to computers and I didn't even need to give the users chocolate to get them. You just never know until you ask. . .

That's all your CEO has time for right now. . .

Thursday, July 19, 2007

You just got 0wned. Now what?

Imagine that you are arriving at your office and you look through the window. Inside the building you can see someone burglarizing the building. What would you do?

You have a few options, you could (1) call the police; (2) you could ignore the burglary and go get a cafe' latte double mocha espresso and hope that the burglar leaves before anyone sees him; (3) or you could open the door to the office, and shout, "Hey! Get out!", wait for the burglar to leave.

In the real world, people routinely choose the first option. They do not run the burglar out of the house and then lock the door to preserve the scene before the police arrive, but for some reason, when it comes to cyber-crime, almost everyone chooses the third option. The burglar is long gone by the time the investigation starts. Evidence has been walked over, looked over, deleted and operating systems re-installed.

The "information assurance" community does a lousy job of ensuring that intrusions are handled appropriately. In my experience there is a community wide knee jerk reaction to intrusions that starts with looking at logs (rather than preserving them), moves into damage control (patching and re-instllation) and then, as an afterthought, calling in people who are qualified to respond to the incident. Harlan Carvey wrote recently that he had only conducted two live acquisitions for clients, and both of those were after operating systems were reinstalled, so I assume that my experience is not unique.

This is usually a response based on emotion, not logic. I know that I'm largely preaching to the choir here, but hopefully someone will wander in during this sermon - so here's what you need to do if you have been hacked:

1. Don't panic

2. Call someone qualified to investigate the incident.

3. Let the investigators investigate, image, analyze what's happen(ing/ed).

4. Develop a plan that will allow you to mitigate damage, determine the extent of the intrusion, catch the bad guy with your incident responders/law enforcement.

5. Implement the plan.

Friday, July 6, 2007

Vista event IDs

An interesting note on Vista event logs in Eric Fitzgerald's blog.

He notes that event log IDs in Vista are "old" event id + 4096. There is also an explanation as to the reasoning behind using 4096 (as opposed to say, adding 1000 and keeping things simple).

Thursday, July 5, 2007

Moxie, Best practice and the Greek cell-hack

IEEE's Spectrum has a very good article in this month's edition that is worth taking the time to read. The article discusses the 2004-2005 hacking of Vodaphone. During the intrusion, the attackers were able to intercept the cellular phone calls of a number of people in Greece. People like the Greek Prime Minister (how do you say "ouch" in Greek?) and senior government officials .

From the article (emphasis mine):

[W]e can only speculate about various approaches that the intruders may have followed to carry out their attack. That's because key material has been lost or was never collected. For instance, in July 2005, while the investigation was taking place, Vodafone upgraded two of the three servers used for accessing the exchange management system. This upgrade wiped out the access logs and, contrary to company policy, no backups were retained. Some time later a six‑month retention period for visitor sign-in books lapsed, and Vodafone destroyed the books corresponding to the period where the rogue software was modified. . .

[D]ue to a paucity of storage space in the exchange's management systems, the logs were retained for only five days, because Vodafone considers billing data, which competes for the same space, a lot more important. Most crucially, Vodafone's deactivation of the rogue software on 7 March 2005 almost certainly alerted the conspirators, giving them a chance to switch off the shadow phones. As a result investigators missed the opportunity of triangulating the location of the shadow phones and catching the perpetrators in the act.


The all to frequent reaction of system administrators and managers to pull the plug on intruders.

Now I'll grant you that I am drastically oversimplifying the matter - I'm sure that having your government's head of state, Naval general staff and others played a significant role in the decision, but this response is not containment - it's often a knee jerk reaction to perceived liability. If a hacker has been in your system for a month, a week, or a year, is watching him for a day or two so you can determine the extentent of the penetration a bad idea? If you were investigating this incident, would you rather have a couple of days where the hackers were inside your system where you could track (and possibly identify them) or would you rather just close the door before you had figured out how they got in in the first place?

It is like being asked to choose between gathering volatile data while a system is still running and yanking the cord out of the wall - I'd choose the former every time. In an intrusion case, I'd argue that not gathering volatile data is tantamount to malpractice; and if presented with the opportunity to determine the full extent of an intrusion, you ought to take the opportunity, or you risk the same argument being applied to your actions.

Best practice in intrusions is to contain the intrusion so that the attacker is isolated, but allowed to continue to access the systems that he's accessing. If there are data that you can not allow out (classified or personally identifying information come to mind), part of the containment strategy should be to come up with either bogus data or a reason why the data can no longer be reached (i.e. "The server crashed, but we're working on it."). There are going to be cases where this will not be realistic, but it should be the starting point for any intrusion investigation. You will learn a lot more, a lot faster this way. This more moxie than just cutting the attacker off, but in the long run it is better for the investigation and ultimately for the victim to know all that there is to know about the intrusion by observing a "live patient" than would ever be discovered through an autopsy of a dead one.

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 example.com 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, example.com 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. Amazon.com, 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.

"LIVE" ACQUISITION OPTION:

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.

DECRYPTION OPTION:


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. . .?

Thursday, May 24, 2007

"Defeating" Whole Disk Encryption - Part 2 "Ok, I've got the password, now what"

In my last post I discussed some techniques for obtaining a PGP encrypted password from a DD image of the physical memory. Let's quickly take a look at how to tackle a dead box before we start to tie all this together.

Dead box:

I'm going to quickly go over this, as I haven't tested what I'm going to write about here.

Accessdata's Password Recovery Toolkit and Distributed Network Attack can be used to bruteforce a dead box. I have not done this, but I'm a big fan of all of Accessdata's tools.

So now we have broken the password/passphrase what are your choices?

Let us assume that you have the password, but you couldn't make a live image of the box. How to get in? Before I start, I'm going to put a big shout out to Dave Shaver over at the US Army's Computer Crime Investigative Unit - a lot of what follows is based on his research and work. . . There are a few other ways that might work here, but this is the one that I've tested.

The Attack:

You are going to need Vmware workstation and Encase. You will also need to download the PGP decryption .iso for the PGP encryption version that your box is running. You can download those here.

Step 1:

In VMware workstation create a VM that you can install Encase (XP, 2000 etc).

Step 2:

Boot your drive, install vmware tools - shutdown the VM.

Step 3.

Edit your shared folders , , and add the folder/drive to add the encrypted image files to something that the VM can access. You might also want to add the folder where you have the Encase installer executable and the Hasp Driver installation file (or you could download those from guidancesoftware.com - your call, but they need to be on the VM or in a folder the VM can access).

Step 4:

Add a second hard drive to your virtual machine. The second hard drive should be slightly larger than the original drive on the encrypted machine. So if the original drive was 188.6 GB, you will want to make your machine 188.7 in VMware. (Note: If you have problems, keep incrementally increasing the size of the drive)

Step 5:

Reboot the VM, install the hasp driver and Encase. With VMware in the foreground, plug in your Encase dongle and start Encase.


Step 6:

Encase should be running in forensic mode. Add the image into Encase. Go through the restoration procedures as if you were restoring the image to a drive, but here, you are going to restore the image to the second drive that we created in step 4. There's a how-to in the Encase manual if you are not sure of the procedures.

Step 7:

Power off your VM, take a copy of the file related to the step 4 drive and copy them to the drive where you have the original image files - copies are your friend here. It's good forensic practice and even if you don't think you need to do this, you'll see why you want to as you read on.

Step 8:

Edit the settings on your virtual drive. Remove the drive that you used to boot (the one we created in step 1). The only drive that should remain active for your VM is the drive from Step 4 - the restored image of the PGP encrypted computer.

Now it is decision time. What are you looking for? Will you be satisfied with only the files that are not deleted, or do you want to make a few changes to the drive and have the chance to get into unallocated space? The good news is that you can have it both ways.

We will tackle that in the next post.

Tuesday, May 22, 2007

"Defeating" Whole Disk Encryption - Part 1

An issue that we are going to continue to encounter is computers with whole disk encryption (WDE). I'm going to post a couple of techniques that have worked for me, and hopefully they'll be of use to someone else out there. In this post, we will look at PGP's WDE, although the techniques outlined here should be easily applied to other encryption schemes.

The background:

PGP WDE uses 256 bit, symmetric AES encryption. For those of you that don't know what this means, suffice it to say that the algorithm is sufficiently strong to prevent the average person/company/government agency from breaking it.

In many cases we do not have the cooperation of the system owner, so how do we handle this?

Scenario 1 - the computer is running:

If there ever was a reason to argue the Live vs. Dead acquisition arguement, disk encryption has to be one in favor of the live side. My personal preference is to acquire the volatile memory (at a minimum) before shutting down the system. Let's assume that you cannot image the whole system live - grabbing the memory with a tool like George Garner's forensic DD. No, it won't work on Vista or Server 2003 with a service pack installed, but the price is right. If you have the money though, George has solved that problem too.

So now you have a dd image of the physical memory, and a dead computer. You image the same computer and you start looking at the drive and realize that you are seeing nothing but garbage - there's no usable data on the drive.

Fortunately, Adam Bolieau help solved that problem. Adam and Tmasky did some really interesting work on acquiring memory via firewire, but he also wrote some really useful code that will read BIOS passwords from memory. Fortunately for us, PGP stores its passwords in the same memory location. So all we have to do is point bioskbsnarf.py[1] at the DD image that we made of the memory and viola - there's the password.
or at least the last 16 bytes in the keyboard interrupt buffer in the BIOS Data Area before you enter protected mode - so you may not see the "whole" password, but would you rather try to brute force but wouldn't it be easier to brute force the password "I am Computer Geek" if you could see: " a Computer Geek"? I think so. . .

Coming up:

Ok, I've got the password. Now what?

[1]. biobksnarf needs a Python interpreter to run. Python can be downloaded from Python.org, though I have not used the windows binaries with biokbsnarf. If you run into problems, try cygwin's python interpreter on a windows system.

From the command line: "python biobksnarf.py " should do the trick.

Tuesday, May 15, 2007

IE7 Internet.evt continued

Andreas Schuster has some follow-up regarding the internet.evt file. Andreas points out that with XP SP2 (German Locale) the file is "Windows .evt" Take a minute to check out his blog.

Further testing on my system reveals that this file has remained its default size 65,536 and clearing the log file seems to have no effect - same file size, same lack of content.

Has anyone seen anything different?

And just to clarify:

In my last post, I wrote that "Using psloglist against the file appears to dump the contents of the file." However, further testing shows that the file is not readable - when Windows cannot find the event file specified, it opens AppEvent.evt.

To illustrate, here is a screenshot of psloglist being run against "cybermonkey." Since there is no cybermonkey.evt on my computer, I get the data from AppEvent.evt.

Sunday, May 6, 2007

First off, Harlan Carvey mentions that his new book has information about this on page 205; I still haven't made it out to buy the book yet, but the day isn't over. Harlan also mentions that the file is created when IE7 is installed.

Wow, there's been quite a response to the first post. . . A couple of things that Andreas Schuster requested. This is the contents of the HKLM\System\CurrentControlSet\Services\EventLog\Internet Explorer


and this is the HKLM\System\CurrentControlSet\Services\EventLog\Internet Explorer:



This is Internet.evt opened in a hex editor:



the remainder of the file appears to be empty. Using psloglist against the file appears to dump the contents of the file.

Friday, May 4, 2007

Internet.evt

While coding an event log dumper for Windows systems. I stumbled upon a something that was, I thought, of interest to forensic examiners. I found a new (and apparently undocumented) event log - %windir%\system32\config\Internet.evt.

According to this post, and this one as well, the file shows up when Internet Explorer 7 is installed. This coorelates with the computers that I have available (that is computers with IE7 have the file, and those with IE6 do not), though I have not yet tested this to determine that this is in fact the case.

I haven't spent a lot of time looking at the structure of .evt files generally, but in my experience, they are generally readable with a hexeditor, but this is not so with the internet.evt. The windows event viewer, when opened shows this file as Internet Explorer, but it appears empty. When I turned the log viewer I was coding towards the file, however; it had some interesting artifacts.

Most notably, software installations were logged. Including (I think) software installations that were performed using Firefox. This could be very relevant when investigating intrusions where a web browser is used to download and install tools, but obviously some more testing needs to be done.

I'll post what I find in a follow-up, but to summarize:

I know Internet.evt:
  1. exists on XP with IE7 installed.
  2. does not appear to exist with pervious versions of IE.
  3. resides in the %windir%\system32\config
  4. is not visable to the windows event viewer in XP home (tested on 1 box).
I suspect the file:
  1. is created when IE7 is installed.
  2. has a file structure that differs from standard event logs.
  3. also logs internet related software installations from other browsers.
To do:
  1. test suspicions
  2. figure out what types of data are stored in the file.
  3. determine what registry entries (if any) are associated with the file.
If anyone knows anything more about this, I'd be interested in hearing from you. I couldn't find any reference on Microsoft's Technet but, we all know the schitzophrenic nature of Technet, so there might be some reference somewhere. . .