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. . .
Tuesday, August 14, 2007
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.
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).
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.
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.
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.
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.
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.
Subscribe to:
Posts (Atom)
Posts
