The subtitle of this post should be something like, "The disclosure discussion comes to digital forensics" or "Yes, Virginia...IR software has vulnerabilities, too."
For those of you who may not be aware, it wasn't long ago that MS's COFEE was leaked. Based on some of the comments you can find online, this occurred around the beginning of the second week of November. What's the big deal? Is it that this is "LE only"? Well, now that it's been exposed and you have an idea of what's in it...are you a better person for knowing? Or are you wishing you could forget?
Also, something that a lot of folks may not realize...MS is a HUGE company. At one point, I worked for SAIC, and internally folks described the environment not as one big company, but as 400 small companies that could and did compete against each other. MS is similar...don't expect that the left hand knows what the right hand is doing all the time. Remember WOLF? There've been other efforts within MS to produce tools and documentation, but it's not as if these have been released the way Windows 7 or MS Office are released. Tools like COFEE should be considered more of a grass-roots effort, and not something you're going to see Bill or Steve on stage endorsing.
Comparing COFEE to what's out there now and has already been in use may be a bit like comparing the GI Joe accelerator suit to the real-world MOPP gear, in some ways. You'll have to excuse the analogy...we in the "community" never seem to see eye-to-eye when it comes to this sort of thing. I'm simply trying to illustrate the point that while COFEE was released by MS to LE, that doesn't mean that it's entirely bleeding edge stuff.
Then, along came DECAF, reportedly a counter-intel, anti-forensics tool meant to detect the use of COFEE, and automatically react by doing things on the system, much like an anti-virus or -spyware utility would do.
Ovie then had the opportunity to interview Mike, one of the authors of DECAF. One of the most striking things about the interview is that Mike really didn't seem to have a well thought-out rational behind the creation of DECAF. For good or for bad, MS released something to assist LE, and act as a force multiplier...as a former Marine, I totally understand that. Regardless of what you actually think of the tool itself, the idea was to give LE a capability that they did not have before; specifically, officers that are first on-scene would have a tool that would allow them to collect data (which could be used as evidence) prior to spoilation due to temporal proximity to an event (that means, get it now, before it's gone). Mike apparently had an issue with the tool, and found what he determined to be a shortcoming or "vulnerability", and produced DECAF to "exploit" that shortcoming. Interestingly enough, I've listened to the podcast twice now, and I'm at a loss...Mike never said exactly what the shortcoming or vulnerability was, other than the tool could be "fingerprinted". But isn't that true for...well...just about anything?
However, what was he really doing? He wasn't so much exploiting a software "vulnerability" as he was exploiting the training (or lack thereof) of the first responders who would use COFEE. Ovie had an excellent point...what happens if a really, really bad guy had DECAF installed, and the first responders only had COFEE? There's a possibility that the bad guy could go on hurting children due to the fact that specific evidence could not be collected. If you listen to the podcast, I really think you'll see that regardless of the example used, Ovie made a very valid point, and it really seemed that Mike maybe hadn't thought all of this through.
Mike's primary issue with COFEE throughout the interview seemed to be that it could be fingerprinted...that there were automatic means by which someone could determine that COFEE was being run on a system. Okay...but isn't that true for just about ANY software? I don't know the inner workings of DECAF, but couldn't the same thing be said for other responder tools? According to an article in The Tech Herald, it appears that COFEE's primary purpose is to automate the use of 150 (wait...150?!?) tools, some of which include tools available from the MS/SysInternals site.
How many other responders use these tools?
How many other toolkits could possibly be affected by tools such as DECAF?
Consider this...why COFEE? Why not Helix? Why not WFT? Why target a tool released by MS, and not one, say, endorsed by SANS? I'm not going to speculate on those...those are for tool authors themselves to consider.
I have to say that before I actually listened to the CyberSpeak podcast, I found out that as of Friday morning, the DECAF tool had been taken down, the web site changed, and reportedly, anyone using DECAF on a system with an Internet connection would find that the tool had phoned home and self-destructed. Kind of cool, eh...an anti-forensics tool with the ability to phone home and get updates and instructions, with no user interaction beyond turning the system on...wait, that sounds kinda like a 'bot to me...
Following right along with the CyberSpeak interview, you can watch this YouTube video, as well, that pretty much reiterates what was said on the DECAFME.ORG web page. Speaking of which, here's a quote from the page:
As a security community at large, we need to band together and start relieving some of the burden off our government by giving back.
I agree with this 100%...and I agree that two guys did have an impact. However, from the interview, Mike seems like a really smart guy, so I have to ask myself...if you see something wrong, why not fix it? If you see an issue with a tool or process, why not do something to improve it? If you find an issue with a tool, particularly one aimed at assisting LE or others with their job, why not fix it? If you have a better tool or process and want to get it out there, consider Facebook, Twitter, blogging, and even contacting guys like Ovie and Brett. If the issue is the training received by LE, remember that a lot of LE is really strapped for cash...again, contact Ovie, or your local HTCIA or InfraGuard chapter and see what you can do.
My point is, two smart guys can have an impact, but their motives will dictate the impact that they have. This wasn't an issue like what's seen in the usual "full disclosure" discussions...we're not talking about server software that's been deployed across the globe that has a severe vulnerability. We're talking about a tool that can and should be used by a discriminating, knowledgeable responder...and if you don't think that the tool is sufficient, do something to fix it...other than subverting it. Provide something better.
Thoughts?
6 comments:
DECAF has just been 100% advertisement for its authors and the community is helping them adding to the adverstisement.
Their ethics should be questioned indeed.
They not only used and reversed engineered a LE tool enfringing copyright, but they also by provided a way for bad guys to hide from it.
By the way COFEE had been leaked more than a year before all the fuzz about it on rapidshare and other similar sites.
Anonymous,
Thanks for weighing in.
Just to be clear, though...as expressed, these are your thoughts and comments, and while I share the sentiment, this isn't necessarily how I would have conveyed that sentiment.
What I mean is that I don't want folks who read this to construe what's been said as having been said by me. I wouldn't make a comment like Their ethics should be questioned without having signed my name to the comment.
Just wanted to be clear. I've received a number of emails over the years I've been blogging from folks who've said, "...you said..." and then quoted an Anonymous comment.
Thanks.
@Anonymous,
Bringing up "reverse engineering" is just going to derail the conversation down another, counter productive, path. Security researchers conduct research into the behavior and capabilities of software and operating systems to determine how they function. This in turn assists the developers strengthen their tools and increase the tool's capabilities. They would call this research and not reversing. Six in one hand....yada, yada, yada.
Personally I think it is great that these guys worked on this stuff and exposed some of the functionality and capabilities (although I do not agree with the phone-home capabilities if they exist). Perhaps this research will help the developers understand that there are bad guys out there who are already working on these types of detection mechanisms for their tools. We have seen it other places (vm, malware), so why is this shocking here? Mayhap this will help Microsoft start thinking along the lines of mixing up some of their techniques. For instance, randomizing the names of the tools run, running tools in slightly different order, or providing compilation capabilities to mix up the signatures of the tools to avoid detection.
What this really boils down to is understanding the Order of Volatility. Knowing that if something can change then an analyst should expect it to change. Whether before or "during" information gathering. Heck, if you are writing to a default location then you should also be worried about changes "after" data collection.
Could the crew of DECAF have handled this better? Yes. But in a day and age when speed of release is seemingly more important than functionality and capabilities I can understand why they jumped the gun before the COFEE issue retreated into the background again. Hopefully this activity has attracted the attention of the COFEE developers and they now have some ammunition they can use to justify continued and more in-depth development. I hope that they can push the case for being able to provide in-depth information into the inner workings of the Windows operating system so that it is easier for law enforcement, digital analysts, and incident responders to gather and analyze the activity that has occurred on a system with more detail and accuracy. Also, these efforts have probably taught the DECAF crew a few lessons. Hopefully they will use this knowledge for positive research and tool releases in the future.
Go forth and do good things,
Don C. Weber
Don,
COFEE is nothing more than a glorified batch file...which means that rather than finding an issue or vulnerability and fixing it, the DECAF guys took an approach that could potentially affect all such frameworks. Any tool can be fingerprinted...even memory dumping tools.
Also, keep in mind that there is a pretty big misconception about COFEE...while it has the MS label on it, the last time I had a close look it, COFEE was developed FOR folks who don't really do IR, BY folks who don't really do IR, and the folks who created COFEE (God bless 'em) are not the entirety of MS. Rather, they're a small part of MS.
How many tools from MS are really for IR? Look at the SysInternals tools and how many of them create a Registry entry the first time you use them on a system...is this really something someone looks for in an IR tool?
Hey everyone, I respect everyone's comments whether truthful or lack thereof.
The blog post was very good which is why I decided to take some time and post my two-cents.
DECAF was not well thought through. We knew we needed to get out the door before someone else did. Our intentions were not malicious and the opportunity for DECAF to phone home was nothing more for version checking and for monitoring usage.
We NEVER reverse engineered COFEE and although "Anonymous"'s assumption is incorrect, DECAF did monitor for COFEE's presence through other identification.
Needless to say our WHOLE agenda was to put emphasis on the security seen at large. Whether we did it right or wrong, it worked.
Anyhow, the COFEE leak was major when it should have been minor. DECAF news road that wave, it wasn't anything great. Its over.
:)
- Mike
DECAF Developer
Mike,
Thanks for the comment!
Post a Comment