Pages

Wednesday, December 30, 2009

Lions, and tigers, and DECAF...oh, my!

Most of us are aware that DECAF is back, with a new version. Ovie had interviewed Mike and posted the podcast (I'd also posted, and others had commented), and the next day, the original DECAF was taken down. Now it's back, like Die Hard sequels, or a bad MRE...but I kid. See? Smiley face. ;-)

So, how do DECAF and tools like it affect the current state of incident response (IR) and digital forensics (DF) analysis, if at all?

In order to discuss this, let's go back to COFEE. MS released COFEE as an LE-only tool, and IMHO, that's the reason for the hoopla surrounding its release and subsequent "leak"...that it was LE-only. The fact of the matter is that while COFEE was released by MS, and includes the use of several native Windows apps and some from MS/SysInternals, it's really just a glorified batch file with some add-ons to make it's use and deployment easier...which, I think, is the key to understanding the nature of COFEE.

While COFEE was released by MS, it wasn't developed by MS in the way that Windows 7 or MSWord were...instead, it was a small group within MS that led the charge on developing and releasing COFEE to law enforcement.

Now, please understand...I am not disparaging the efforts of this group at all. In fact, I applaud their efforts in stepping forward and taking the first step to do something. I mean, there have been plenty of similar frameworks out there for folks to choose from, and some of them very good...but for some reason, COFEE was very well received. However, I will suggest that perhaps making something too easy to use isn't always the best solution. Sometimes, when it really comes down to it, it may be better...albeit not necessarily easier... to educate the user than it is to make a tool easier to use and deploy.

Given that, my own personal, overall assessment of COFEE is that it's a tool produced by folks who don't do a great deal of IR or "live response" work, for folks who don't do a great deal of IR or "live response" work. Don't make this statement out to be something that it isn't...I'm not disparaging anyone when I say this. All I'm saying is that in the corporate arena, many of us have taken the time and effort to educate ourselves on the issues and nuances of live response, whereas LE may not have had that sort of time...after all, when I'm reading or testing stuff, I'm sure most LE are diligently working to put bad guys in jail.

Then there was DECAF. I remember that there was discussion about "LE-only" this and "vulnerabilities" that. However, listening to the CyberSpeak podcast interview, there's no specific mention of what those "vulnerabilities" are. The "vulnerability" that Mike and friends found in COFEE was never specifically stated during the interview, pretty much leaving that particular issue up to speculation on the part of the community as a whole.

So where does that leave us? I'd suggest that the release of DECAFv2 really doesn't change anything at all. Here's why...

First, I don't necessarily see a vast deployment of this sort of tool. Think about it...how much encryption is being used for nefarious purposes? From what I've seen over the past 10 or so years, as well as from talking to others, the use of steganography outside of the academic or lab environment seems to be another one of those "urban legends" of digital forensics. Even when looking at some pretty sophisticated or large-scale intrusions, I (and others) haven't seen a great deal of what's generally referred to "anti-forensics". I hate to say it, but it really isn't necessary.

Second, I don't see this being deployed on servers to any great extent. I mean, really...think about it. Your company gets compromised and a great deal of money is spent to get a consulting team on-site to assist. Do you want to be the one to explain to the CEO why you installed DECAF on a system, when the efforts of the responders were hampered, or worse, the system BSoD'd?

Third, DECAF is signature-based, and does ship with some default signatures (although I have no idea what "FTK Imager Port" is from the Press Release page...I don't use any tool named that, so I guess I'm safe). Beyond that, how many users are going to go about crafting and distributing custom signatures? I mean...really. Better yet, who's going to write the DECAF signature for DECAF?

Fourth, let's say that you do encounter a system with DECAF installed...it's likely going to be an uber-admin's desktop or laptop...and there are other ways to collect data. Like pull the hard drive out and image it. Sure, you may not be able to get volatile data, but you may not need it for what you're doing, or you may have other data available to you.

Finally, I have no doubt that someone's going to come up with a DECAF detection tool. There are tools available that will detect the presence of whole disk or volume encryption on live systems, and detecting the presence of DECAF running...and doing so using a tool with random signatures (remember RootkitRevealer??) makes use of capabilities that have already been employed. In a way, this reminds me of the whole escalation stuff that happens with combat weapons. Tanks have armor, so someone makes a TOW missile. Then someone puts reactive armor on the tank. Then someone else puts a probe on the end of the TOW missile. And on. And on. DECAF comes out...someone else will ultimately produce a DECAF detection tool.

Circling back around to the beginning of the post, what we, and in particular LE, don't necessarily need is easier to use tools. Sure, there's a certain level of usability in GUI-based tools over CLI-based tools, but what's needed is education, first and foremost. After all, a knowledgeable responder is better prepared. Knowing is half the battle! or something like that...

7 comments:

  1. Jimmy_Weg10:28 PM

    The COFEE/DECAF issue has, IMHO, grown way out of proportion to reality. First, I have declined to support COFEE as a first responder tool in my state. That decision has nothing to do with the utility’s validity or worth as a means to gather data on site. However, I don't believe that it is an instrument that is suited to first responders, regardless of whether they partake in COFEE training. There are too many variables, such as the best way to configure COFEE for a particular case. I don't like the idea of folks using tools that they can't explain, beyond saying that they "pushed a button.".

    Our first responders are superb at what they do. Even if we were to train them in COFEE's use, the responders would use it so rarely as to make it difficult to remain adept in its use. Aside from that, COFEE's use in the 9th Circuit is questionable, at best.

    I listened to Ovie's interview of Mike. I think that Ovie was well meaning, but went beyond what was necessary in imploring Mike to take down DECAF. At that point, the train had left the station. I think that some folks are making too much of a good-guy vs. bad-guy scenario out of this. I'll be amazed if anyone comes across a system on which DECAF successfully foils an attempt to recover evidence. Wanna bet a beer?

    ReplyDelete
  2. Quick review of the DECAFv2 to address your signature-based section in the article: http://bit.ly/7zVNcG

    ReplyDelete
  3. Randy,

    Thanks...very interesting perspective on DECAF.

    ReplyDelete
  4. Well written article. The only thing I would caution you on is to be careful about equating the use of encryption and stegonagraphy as urban legends. I have been involved in computer forensics since 1999 and I have seen both in use in the field and, in every instance, it involved a particularly serious crime.

    Their use may not be statistically significant, but that is no excuse for letting your guard down. The risk is just too high.

    I check for these technologies before I seize any live computer. I also check for their existence in every exam I do. That's probably why, when I talk to people, I seem to come across this problem more than most. I live in a area where most users are "low-tech". We don't have a Best Buy or any other major technology retailer nearby. Nor do we have any high-tech industry. Yet I have a case involving TrueCrypt and another involving Steganos right now. And, I just finished one involving Folder Lock.

    To me, checking for these technologies is like wearing a seat belt. The only time I need to wear a seat belt is when I am going to be in a car wreck. Unfortunately, by the time I find out I am going to be in a wreck (I have been in two) it is too late to put my seat belt on. So, I always wear my seat belt when I drive. Same goes for wearing body armor. You only need to put the armor on when you are going to get shot by a badguy. But I think you get the point.

    Encryption and steganography technology can mean the end of your forensic examination before it ever starts. If you don't take them seriously, you could get burned.

    ReplyDelete
  5. data,

    Your points are well-taken, but please take the entire post in context. Again, as I stated, in over 10 yrs of doing this, I have not once seen the use of either encryption or steganography. Speaking to others, I receive similar responses. Yes, I have encountered WDE drives, but in every instance, it's been for an engagement where I've been asked to simply image corporate systems, and the use of WDE was policy.

    Also, I never said that this isn't something that's used. All I said was that I've never seen either used "in the wild", in large part due to the fact that it really isn't necessary.

    Thanks for commenting.

    ReplyDelete
  6. Keydet89,

    I appreciate what you are saying, and I believe that I am taking your entire post in context. I only cautioned you to be careful about using the phrase "urban legends" to describe the use of encryption and/or steganography. To me, I think you could unintentionally give the impression that these technologies are not something to really worry about. From a statistical point of view that impression is correct, but from a perspective that focuses on the impact of evidence recovery the impression is incorrect. I'm not saying that your intention was to give the impression to not worry about the technologies, just that your statement *could* give that impression.

    However, one thing I am unclear on is exactly what you mean by "it really isn't necessary".

    What isn't? Encryption or looking for it.

    Also, my intention and point in the use of the seat belt and body armor analogy was mainly to say that it really doesn't matter if, for example, you have done 10,000 exams and never run into encryption or steganography. It matters when you do, even if you only run into it once in your entire career. A lot of officers go their entire career without being shot, yet look at how many agencies, even small towns, provide body armor for their officers. It's a matter of cost/benefit risk assessment.

    To me, the same goes with these technologies. What's the cost of my checking for encryption before seizing a running system? Pretty minimal. Can I justify doing so in court? Yes.

    What's the cost if I don't, and it was in use and unlocked at the time, yet I pull the plug? Potentially very high.

    The risk for approaching a live system assuming encryption/steganography is not in use is just too high. Again, not in terms of the likelihood of it being there, but in terms of the impact it will have on the evidence if it is and currently in an unlocked status. I'm there to collect evidence, not lock myself out of it.

    I am jealous that you have never had to deal with these technologies "in the wild" as you say as it can be a real pain. And I think your experience is shared with more people than not (thankfully). But I have noticed an increase in the number of people who are encountering this in the wild.

    Again, I'm not saying these technologies are being implemented in a significant number of cases. In fact, I think it is the exception. However, when they are encountered it can be the end to a succesful exam. In other words, it's not a game of numbers, it's about the potential impact on the forensic exam that justifies the cautionary approach.

    Sorry if I misunderstood your post, but I think you may have misunderstood mine as well.

    ReplyDelete
  7. > However, one thing I am unclear on
    > is exactly what you mean by "it
    > really isn't necessary".
    >
    > What isn't? Encryption or looking for it.

    Again, its about the context. The entire phrase I used was "All I said was that I've never seen either used "in the wild", in large part due to the fact that it really isn't necessary."

    This in no way implies that it isn't necessary to look for encryption or steganography...not at all. What I am saying is that in the incidents I've responded to in the past 10+ years, it simply hasn't been necessary to use either one, because most of the incidents haven't been discovered by the "victim". Rather, the "victim" in most cases has been alerted to the issue weeks or months after the fact.

    I haven't said that either of these two technologies should not be considered or looked for...in fact, I completely agree with you in that regard...if the situation warrants it. As a corporate investigator, I could easily respond to an incident, collect several dozen systems and analyze them...I've done that. However, I'm billing a customer...if I include in the report that I analyzed the systems for the use of encryption or steganography, the customer will respond with, "well, we didn't ask you to look for those, so we need you to resubmit your billed hours, with the time for that analysis removed. And oh, yeah...we won't be calling you again."

    I completely agree that both should be considered, IF it makes sense to do so.

    Thanks for your comments.

    ReplyDelete