Slashdot Mirror
Linux and Forensic Discovery
Max Pyziur writes "Found this on cryptome.org where Linux is cited in a DOJ document against Moussaoui (sometimes referred to as the "20th man"). FBI: Moussaoui E-mail Not Recoverable - January 1, 2003." An interesting read which gives some insight into how computer evidence is handled in court.
Of the fact that lawyers will argue over anything.
Heh, this seems to be a discussion about whether they used "approved methods" of retrieving a deleted email. According to one person, the LinuxGNU was the only one approved by NIST (national institute of standards and technologies). This of course, is wrong...NIST doesn't "approve" software, they just test it and declare whether or not it works.
To anyone who is concerned about having their deleted files recovered, take a look at Wipe - in its strongest mode it will make 37 passes over the data in order to be sure that electron microscopes cannot reconstruct the bit patterns.
The test reults are abailable here:
http://www.ojp.usdoj.gov/nij/sciencetech/cftt.htm
To be honest, 'dd' is not a Linux utility. Various *nixes used it before Linux was even started.
Michael Loves Me!
Actually, if you read on in the article, they state that Linux dd COULD have been used, that NIST had tested it and found it acceptable, but if you read the procedures used to the four HDDs, they actually used the other methods listed exclusively.
dd is a common Unix program. The SGIs at work have it, my various BSDs at home and work have it and Linux has it.
Trolling is a art,
You do realize that in the event of a search warrant or subpoena that privacy policy no longer applies, right? Of course, they can't turn over anything they no longer have, but if they have it the government will too. On a side note, the libraries in my city (seattle) have a very explicit privacy policy that states that they do not ever save information about books a patron has read and returned. The only things on the books are currently checked-out items, for exactly this reason.
-
The Eagan, Minnesota Kinkos Computers
This would be rather thorough, it seems.19. The Initial September 2001 Inquiry at the Eagan, MN Kinkos: On October 17, 2002, I spoke with Minneapolis FBI Special Agent David Rapp. At that time, SA Rapp told me that, to the best of SA Rapps unrefreshed recollection, on or about September 19, 2001, SA Rapp went to the Kinkos store in Eagan, Minnesota, to inquire about a receipt found on the person of Zacarias Moussaoui at the time of his arrest. At that time, SA Rapp met with a person who represented himself as a Kinkos employee responsible for managing and maintaining customer computer workstations. At that time, the Kinkos employee informed SA Rapp, in substance, as follows:
(A) The Kinkos receipt did indicate that a computer workstation had been utilized;
(B) It could not be determined from the copy of the Moussaoui receipt alone which computer workstation was used;
(C) In response to SA Rapps inquiry about the possibility of acquiring any information from the computer workstations regarding the use of the computers by Moussaoui, the Kinkos employee stated that, since the date of the receipt, all computers had been wiped clean/formatted and started with a fresh install; and,
(D) The computer workstations were generally wiped weekly or bi-weekly approximately, even though Kinkos policy called for weekly wipings. At a minimum, the Eagan Kinkos store wiped the computers at least once per month.
[....]
21. Eagan Follow-up: On October 11, 2002, I requested that the Minneapolis FBI Field Office contact Kinkos personnel at the Eagan store and determine if, as alleged by the defense, the Kinkos computer could still maintain evidence of defendant Zacarias Moussaouis use from August 2001. On or about October 15, 2002, Special Agents Brendan Hansen and Christopher Lester visited the Eagan Kinkos and interviewed Brian Fay, who, as of August 11, 2001, was one of two Kinkos employees who knew how to restore an image onto the six computers with internet access designated for customer use. Mr. Fay stated that the six computers presently at the store are the same computers (with the same hard drives) that were present in August of 2001. These six computers are leased and scheduled to be replaced at the end of this year.
The computers are maintained by formatting the computers hard drives and reloading an image using Norton Ghost whenever business is slow and time allows. There are no logs recording the dates or frequency of loading images on to the computers and Fay could not estimate how frequently they were imaged. Although Fay was not personally familiar with the exact details of the formatting and imaging process he administers to the computers, Fay had been advised by Kinkos that the formatting and restoration process destroyed all files associated with previous users.
ouch
"It is a greater offense to steal men's labor, than their clothes"
From http://www.itl.nist.gov/fipspubs/fip180-1.htm:
So yes, two different files can have the same hash, but it's infeasible to do this. That's why hashing methods like SHA are used in cryptography; SHA-1 is used in DSA signatures.the shred utility will only work on non-log structured and non-journaling filesystems, i.e. ext2, but not ext3, jfs, reiserfs, etc. see: "man 1 shred" for more info.
Now, the document says the examiner determined that there was only one partition, and that he used a "a Linux Boot CD" - this implies (it's not terribly clear what that actually is) that he used linux's fdisk command (or diskdruid or something) to determine that there was indeed only one partition - by examining the current contents of the drive's partition table.
Doing this doesn't capture any space not currently assigned to a partition - in particular, if another partition were present but was then deleted, or if the extant FAT32 partition were resized (say with partition magic).
Infact it's rather unusual for a windows laptop to only have one FAT32 partition - many (most?) vendor-created laptops ship with a sleep-to-disk partition on the disk as well (Dell seems to always to this on windows systems).
In a non-forensic setting, these gripes would be beyond pedantic, but given the seriousness of the crime concerned, and the alleged technical skill of the terrorist groups implicated, these omissions are not immaterial. I do hope that they're omissions only in this document and that the examiners actual procedure did properly image, checksum and examine _all_ of the disk's contents.
## W.Finlay McWalter ## http://www.mcwalter.org ##
Are they saying that two different files can't have the same hash value? That's a load of crap! It's not hard at all to modify data to create any hash value that you want, especially when you're including "deleted space" in the CRC calculations... It's good at telling you if there were any random modifications caused by errors during copying, but not that the files are identical.
There are no known examples of two files that have the same MD5 (or SHA-1) hash values, so I think you should reevaluate your statement. While it certainly is true that such files do exist (2^128 MD5 values, > 2^128 possible files, pigeon-hole principle, etc...), that does not mean that finding them is computationally easy or even possible.
A brute force search of files would require ~2^128 files to be search to find a match. If 2^32 computers each processed 2^16 files a second on average per year (60*60*24*365 20^30 seconds), then it would take greater than 2^50 years to find a match. Equivalently, the odds that any of the files that have ever been produced by humans have the same MD5 are pretty bad.
It might be possbile that a cryptographic flaw in MD5 exists that could be exploited to reduce the number of files that needed to be searched. I believe no such flaw is known. If one does exist, I'm quite sure it doesn't provide dramatic benefits.
At the current state of the art, your best bet is to buy a new disk, and make sure that you never put any unencrypted bits on it: use a cryptographic filesystem such as CFS, and make sure your swap is encrypted also. As Gutmann notes, you may also want to take measures to make sure that sensitive data doesn't sit in RAM too long (!).
Once data is in clear on disk, there's really no way to be sure it's gone except to physically destroy the platter.
someone already made that for you.
e raser. html
The dude is in our local lug, http://www.sslug.dk/ and his name is Ole "perl" Tange.
You can get the program here
http://www.linux-kurser.dk/secure_harddisk_
Call this off-topic if you must, but I've seen gazillions of posts in this and many other threads about forensics and data recovery that are terribly misinformed about the realities of the field. Here's the two cents of a real, live forensic examiner:
/dev/hdX in vi, and starts paging through 5 GB or hex? Oh, god, no--that would take years. Making the bitstream image is the easy part, and your choices are virtually unlimited. For the actual analysis (what does it MEAN), you need something that can examine an allocation table, interpret the results, and display the contents in an easy-to-understand format. You need software that can quickly search across a drive for a particular keyword, regular expression, or file signature. You need something that can analyze data for randomness in order to re-assemble images that have been chunked out across virtual memory. Linux does NOT have basic utilities for all of this, and neither does Windows.
First, it is NOT realistically possible to recover data that has been overwritten ONE time. Yes, yes--I've read all the white papers on magnetic force microscopy (MFM) and I understand that a theory exists about recovery of overwritten data. In practice, nobody actually does it. Maybe one time, six years ago, some dude at NASA or MIT actually made this work conditions on an older disk with a lower bit density, but anyone telling you that old patterns can be read in the real world is full of shit. And yes, it's been tried. Millions have been spent on this, and nobody can do it. Anybody selling you software that claims under laboratory to be "more secure" because it overwrites more than once is being silly. It's not even paranoia, just lacking a clue.
That's why forensic examiners don't need to have the original media. In fact, one of the big tenets of the job is to never, ever, ever perform analysis on the originals. You make a bitstream copy of the perp's (excuse me, "client's") disk, and you work with that.
Oh, and electron microscopes have nothing to do with this theorized recovery process. MFM is a related but very different technology.
Second, Linux versus Windows versus LogicCube versus ImageMasster (another brand) is utterly beside the point. Forensic shops use what they find to be cost effective, fast, and convenient. The dd command is great, and all, and many examiners use it on Linux platforms for their disk imaging needs, but it's not an analytical tool.
Let me put it this way: do you actually think that a forensic examiner sits down, opens
Last, a good forensic examiner is less constrained by his/her knowledge of computers than by his/her investigative skills. I know more about operating systems, file allocation, and troubleshooting than any of the 30-50 year old former cops/feds/spooks that I work with, but they're capable of far more effective work than I am. Why? Because once you have a few basic computer operations taken care of, the work has as much to do with computers as Computer Science does.
The folks that put the child pornographers, embezzlers, script kiddies, and the rest of the computer criminals in jail generally know much, much less than you about computers, Slashdotters. They also don't give a rat's ass about Linux, Windows, Bill Gates, RMS, or any of it.
Ask your self: How the hell did they know to image his laptop on September 11th? This means they already knew he was part of the attack, and they were already on to him. Funny how we, the people, were never warned.
Have you been living in a Cave for the past year?
You've never heard of Moussaoui?
I read the NIST document and noticed they mentioned a limitation of dd.
When copying, dd only copies entire blocks. If there is an incomplete block of information remaining at the end of the disk, for example, dd will not copy that last block at all.
Since dd defaults to a block size of 1024 bytes, and PC hard drives use a sector size of 512 bytes, this could happen. In this case, dd will not copy the final sector of the hard disk, as it is an incomplete block.
Because of a stupid decision made decades ago, traditional PC hard disk addressing uses 63 sectors per track, not 64. Therefore, odd total numbers of sectors are common. Modern addressing does away with CHS and just numbers all sectors from 0 to the end of the disk (many millions, in most cases). Still, because of the legacy of having 63 sectors per track, many disks have an odd total number of sectors.
It would be nice if dd had an option to correctly copy a partial block at the end of the source. If there is an incomplete block, it should simply copy one byte at a time until there are no more bytes to copy.
This would be easy to add to dd. Has it been done already? If so, it should be documented. Making it the default behaviour might break existing applications, so have it as an option that is highly recommended.
Dr. Demento On The 'Net!
did I read in all the legal bullshit that all the FBI uses for verification is a CRC sum?
It's easy to defeat CRC - just add empty space to the end of each file until you get the result you want. SHA-1 or MD-5 is safe(ish), but a straight CRC is too easy to forge.
I wouddn't trust these disk copies with a bargegepole.
oh brave new world, that has such people in it!