Evaluating Commercial Counter-Forensic Tools
Message # 1
Date: Sat, 12 Nov 2005
To: practicalsecurity at hbarel.com
From: Hagai Bar-El
Subject: [PracticalSecurity] Evaluating Commercial Counter-Forensic Tools
I have just enjoyed reading "Evaluating Commercial Counter-Forensic Tools" by Matthew Geiger from Carnegie Mellon University. The paper presents failures in commercially-available applications that offer covering the user's tracks. These applications perform removal of (presumably) all footprints left by browsing and file management activities, and so forth. To make a long story short: seven out of seven such applications failed, to this or that level, in fulfilling their claims.
I did not take the results by a complete surprise because I am for a long time aware of the difficulty in properly removing all tracks of any action on Microsoft Windows. The system is so complex that anything you do instantly affects several areas of the system in a way that it is hard to predict, let alone revert discrete changes.
Whenever I read claims made by such "erasers" I kept saying to myself: "Wow, how do they do that?", and, lacking a complete answer, I used to assume that they know what they're doing, as I would probably do if I were making such products myself. Apparently, they don't.
The next thing I was wondering about is how come these products sell so well, given that they do not provide what they state they do, in a way that is sometimes so evident. It must be pointed out: the failures were not such that require sophisticated hardware to exploit - the paper discusses surface-level failures that can be exploited instantly without much knowledge beyond knowing the failure exists.
The only answer I can think of is that the customers of such applications are ordinary people who admire privacy and don't like to see their browsing history on the left pane, but yet are people who do not commit crimes that require being able to evade detection by the FBI. The latter guys probably don't use such tools.
So, what would I personally use if I ever needed to cover my tracks?
Well, if it was important enough, I would simply store an image of the OS & applications drive before performing the acts-to-be-hidden, and then wipe the drive once or twice before restoring the drive using the recorded image. Complex? certainly, but as it does, and always did, seem to me - that's the only way that has a chance of working.
This text: http://www.hbarel.com/Blog/entry0007.html Paper by Matthew Geiger:
http://www.dfrws.org/2005/proceedings/geiger_couterforensics.pdf
Message # 2
Date: Sat, 12 Nov 2005
From: lists
To: Hagai Bar-El
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] Evaluating Commercial Counter-Forensic Tools
On 12 Nov 2005 22:28:04 +0200, Hagai Bar-El wrote:
I have just enjoyed reading "Evaluating Commercial Counter-ForensicThis comes as no surprise. Anyone that has performed data forensics on Windows systems with media such as hard drives knows that data tends to lurk everywhere, which can help with basic recovery efforts, and trying to wipe a data footprint, from say web browsing in IE, on a modern Windows system currently running its Windows is an undertaking that, if even possible, I'd leave to the people at the likes of Sysinternals. In other words, good luck trying to clean up such a mess to any decent degree without a total wipe of the media using military or Gutmann grade techniques. Prevention of the footprint may be possible, though.
Tools" by Matthew Geiger from Carnegie Mellon University. The paper
presents failures in commercially-available applications that offer
covering the user's tracks. These applications perform removal of
(presumably) all footprints left by browsing and file management
activities, and so forth. To make a long story short: seven out of
seven such applications failed, to this or that level, in fulfilling
their claims.
So, what would I personally use if I ever needed to cover my tracks?Wiping a system prior (re)installation or at decommission is a good practice because you never know what may be lying around. The boot and nuke tool may be useful here.
Well, if it was important enough, I would simply store an image of
the OS & applications drive before performing the acts-to-be-hidden,
and then wipe the drive once or twice before restoring the drive
using the recorded image. Complex? certainly, but as it does, and
always did, seem to me - that's the only way that has a chance of
working.
For the purposes of "covering my tracks," I'd prefer using flavors of BSD Unix or striped down GNU/Linux as I feel I know a bit better what is going on in those systems than in Windows and so one can make sleek, custom distro's easily. This could result in booting off of trusted, read-only media, such as a CD, and having no ability to write to any storage media (this could be nicely portable), or, if data storage is desired, booting off of trusted, read-only media and then mounting encrypted partitions on writable storage media.
(I use encrypted partitions quite a bit, but not to cover my tracks. I care about customer data being stolen, such as theft of a work laptop, so I encrypt a subset of partitions that I deem important.)
-Andrew
Message # 3
From: pgut001 at cs.auckland.ac.nz (Peter Gutmann)
To: info at hbarel.com, lists at kriptik.org
Date: Mon, 14 Nov 2005
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] Evaluating Commercial Counter-Forensic Tools
lists
For the purposes of "covering my tracks," I'd prefer using flavors of BSDThis topic came up in a discussion recently... Windows has dozens (hundreds?) of utilities that clean up junk left all over the place by the OS and apps.
Unix or striped down GNU/Linux as I feel I know a bit better what is going on
in those systems than in Windows
However, no-one was able to name any equivalent piece of software for Unix systems, even though they write equivalently large amounts of junk all over the place. Does anyone know of such a program (or programs) for Unix systems?
Peter.
Message # 4
Date: Sun, 13 Nov 2005
To: lists
From: Hagai Bar-El
Subject: Re: [PracticalSecurity] Evaluating Commercial Counter-Forensic Tools
Cc: practicalsecurity at hbarel.com
Hi Andrew,
At 12/11/05 23:46, lists wrote:
For the purposes of "covering my tracks," I'd prefer using flavors ofI am not sure I would prefer using Unix on my solution of storing an image of the volume and reverting to it after the "crime". I amended the last paragraph of my post in
BSD Unix or striped down GNU/Linux as I feel I know a bit better what is
going on in those systems than in Windows and so one can make sleek,
custom distro's easily. This could result in booting off of trusted,
read-only media, such as a CD, and having no ability to write to any
storage media (this could be nicely portable), or, if data storage is
desired, booting off of trusted, read-only media and then mounting
(snip)
http://www.hbarel.com/Blog/entry0007.html after thinking of a few other advantages for this method. One is that it avoids the cat-and-mouse game that I usually don't like playing in security. The tools in Unix may be better (?), but they still apply for certain track generating applications only, and only for their current versions. Taking the image restoration approach gives you a blanket insurance regardless of flaws or version assumptions. It also mitigates the issue of leaving tracks of the "eraser" utility.
The approach of using a R/O media is neat! This can be applied, but not always because some of the activities do require non-volatile memory, such as most banking and web-mail sessions that utilize cookies for session management.
(I use encrypted partitions quite a bit, but not to cover my tracks. II could not agree more with the need to encrypt partitions (BTW, TC 4.0 is out, in case someone hasn't noticed!) Yet, I don't consider this as mitigation, even if the OS partition is encrypted, because the ones who form the threat are guys with legal warrants to whom you may be forced to surrender the keys anyway...
care about customer data being stolen, such as theft of a work laptop,
so I encrypt a subset of partitions that I deem important.)
Best,
Hagai.
Message # 5
Date: Sun, 13 Nov 2005
From: Ian G
To: Hagai Bar-El
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] Evaluating Commercial Counter-Forensic Tools
Hagai Bar-El wrote:
The next thing I was wondering about is how come these products sellA partial answer to why these things sell so well might be found in the debate about security as viewed as a market in insufficient information.
so well, given that they do not provide what they state they do, in a
way that is sometimes so evident. It must be pointed out: the
failures were not such that require sophisticated hardware to exploit
- the paper discusses surface-level failures that can be exploited
instantly without much knowledge beyond knowing the failure exists.
The only answer I can think of is that the customers of such
(snip)
It has been suggested that security is a market for lemons (one where the customer does not know the good from the bad) but I disagree and refer to security as a market for silver bullets (one where neither the customer nor the supplier know good from bad).
Either way, in such insufficient markets, the way sales arise is often quite counter intiutive. In a draft paper, I make the claim that sales in the market for security have nothing to do with security, but are driven by other factors.
Ref: http://iang.org/papers/drafts.html 3rd one down, and you might prefer the PS if on a windows machine (apparently there are bugs in IE that trip up on the HTML).
So, once we appreciate that disconnect in the market, it's quite easy to prediuct that vapourware sells better than real product, because the real product has higher costs which means less marketing. All other things being equal of course.
Another partial answer is that the bad guys that do need to evade the FBI (and competitors) will know the score. They also know something that shows them to be generally astute: they generally mistrust privacy-oriented technology as being fraudulent in claims because it can't be easily checked up on. So sales of products will tend to go to people who believe claims.
So, what would I personally use if I ever needed to cover my tracks?Right, or something like copying the data off to another machine, doing the work on the other machine, then disposing of it altogether.
Well, if it was important enough, I would simply store an image of
the OS & applications drive before performing the acts-to-be-hidden,
and then wipe the drive once or twice before restoring the drive
using the recorded image. Complex? certainly, but as it does, and
always did, seem to me - that's the only way that has a chance of working.
But, much of people's work is done sequentially, and here you are assuming one act.
Virtualisation may helps somewhat here - if one were to create a virtual OS every time one logged in, then just wipe it on logging out. (Mind you, I don't know enough about virtualisation to know if it works that way.)
This text: http://www.hbarel.com/Blog/entry0007.htmliang
Paper by Matthew Geiger:
http://www.dfrws.org/2005/proceedings/geiger_couterforensics.pdf
Message # 6
Date: Sun, 13 Nov 2005
From: lists
To: Hagai Bar-El
Cc: practicalsecurity at hbarel.com
Subject: Re: [PracticalSecurity] Evaluating Commercial Counter-Forensic Tools
Hey Hagai,
On 13 Nov 2005 16:36:08 +0200, Hagai Bar-El wrote:
At 12/11/05 23:46, lists wrote:(I may have been misinterpreted, and I do not want to start operating system debates. I use and support a variety of operating systems, including flavors of Windows and Unix.)
For the purposes of "covering my tracks," I'd prefer using flavors ofI am not sure I would prefer using Unix on my solution of storing an
BSD Unix or striped down GNU/Linux as I feel I know a bit better what is
going on in those systems than in Windows and so one can make sleek,
custom distro's easily. This could result in booting off of trusted,
read-only media, such as a CD, and having no ability to write to any
storage media (this could be nicely portable), or, if data storage is
desired, booting off of trusted, read-only media and then mounting
encrypted partitions on writable storage media.
image of the volume and reverting to it after the "crime". I amended the
last paragraph of my post in http://www.hbarel.com/Blog/entry0007.html
after thinking of a few other advantages for this method. One is that it
avoids the cat-and-mouse game that I usually don't like playing in
security. The tools in Unix may be better (?), but they still apply for
certain track generating applications only, and only for their current
versions.
My point was that it is better to never have the data written to storage media than to wipe the media after the fact, and I think variations of this are easier to accomplish in Unix and GNU/Linux (at least for me).
If you desire to store some data after booting off of your trusted read-only media, then I think you should be careful to only mount encrypted partitions on the writable storage media (Yes, this would still need wiping to "cover your tracks," but, I dunno, I'd feel better about never having plaintext data hit the storage media).
The approach of using a R/O media is neat! This can be applied, but notI can think of things like RAM disks that might work well here.
always because some of the activities do require non-volatile memory,
such as most banking and web-mail sessions that utilize cookies for
session management.
I could not agree more with the need to encrypt partitions (BTW, TCI do agree with you, if the media has data fingerprints written to it, wipe the whole thing. I wipe at every (re)install and decommission to clean any residual data to a reasonable degree for my purposes. I'd take the same approach if trying to wipe fingerprints, except I'd maybe physically destroy the media as well.
4.0 is out, in case someone hasn't noticed!) Yet, I don't consider
this as mitigation, even if the OS partition is encrypted, because the
ones who form the threat are guys with legal warrants to whom you may
be forced to surrender the keys anyway...
-Andrew
Message # 7
Date: Sun, 13 Nov 2005
From: "Roy M. Silvernail"
To: practicalsecurity at hbarel.com
Subject: [PracticalSecurity] CRM: Re: Evaluating Commercial Counter-Forensic
[oops... forgot to send this to the group. Thanks, Andrew, for catching that]
On 13 Nov 2005 02:53:41 -0500, Roy M. Silvernail wrote:
lists wrote:--
For the purposes of "covering my tracks," I'd prefer using flavors ofThe live-CD distros are particularly suited to this task. There are
BSD Unix or striped down GNU/Linux as I feel I know a bit better what is
going on in those systems than in Windows and so one can make sleek,
custom distro's easily. This could result in booting off of trusted,
read-only media, such as a CD, and having no ability to write to any
storage media (this could be nicely portable), or, if data storage is
desired, booting off of trusted, read-only media and then mounting
encrypted partitions on writable storage media.
several that are security/forensics or hacker oriented. Persistent
storage can easily be a USB drive, leaving no trace at all on the host
system. All you're doing is borrowing the CPU and I/O.
Off the top of my head:
Auditor (soon to be combined with WHAX)
ELE (Everything Leaves Encrypted)
PLAC (Portable Linux Auditing CD)
DSL (Damn Small Linux)
And the old standby Knoppix, though you'll want to take care to umount
(snip)
Roy M. Silvernail is roy at rant-central.com, and you're not "It's just this little chromium switch, here." - TFT CRM114->procmail->/dev/null->bliss
http://www.rant-central.com
Message # 8
Date: Mon, 14 Nov 2005
To: lists
From: Hagai Bar-El
Subject: Re: [PracticalSecurity] Evaluating Commercial Counter-Forensic Tools
Cc: practicalsecurity at hbarel.com
Hey Andrew,
At 13/11/05 21:19, lists wrote:
My point was that it is better to never have the data written to storageActually, I see your point. Even if you are hit by a search warrant, you're better off storing the data to be wiped on encrypted volumes.
media than to wipe the media after the fact, and I think variations of
this are easier to accomplish in Unix and GNU/Linux (at least for me).
If you desire to store some data after booting off of your trusted
read-only media, then I think you should be careful to only mount
encrypted partitions on the writable storage media (Yes, this would
still need wiping to "cover your tracks," but, I dunno, I'd feel better
(snip)
Most tools that encrypt volumes generate container files / partitions that do not disclose the fact that they are container files. So, in the typical case of using a container file, the large random-looking file will raise suspicion. Even if one cannot prove you were hiding anything, it will surely not get you closer to the end of the examination, just farther... On the other hand, you are much better off when wiping stuff that was on an encrypted volume, because the deleted encrypted volume will not yell for attention and will not be detected by string searches on the volume contents. So, no plain data has ever hit the drive, and the encrypted data is less likely to be noticed by forensic tools after it was deleted.
Right... You'll even get better performance as a by product :)The approach of using a R/O media is neat! This can be applied, but notI can think of things like RAM disks that might work well here.
always because some of the activities do require non-volatile memory,
such as most banking and web-mail sessions that utilize cookies for
session management.
Hagai.