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.

Comments

Oh Please!

[Snowbeam]

How is this news? They are using "dd" a Linux utility. Seeing "Linux" in an article does not warrant a story about it. This demeans Linux by using every little scrap of news to attempt to show that it is in use. Instead we should be demostrating it's uses, rather that reporting that it is in use.

electron microscopes

[Alien54]

I am confused.(yes, we all know this)

The document states that image files were generated fo the contents of the hard drives. I do not have confidence that an image would also display latent data.

I know myself that when I do a data recovery on a system, I can get many more megs of recovered data from file fragments, deleted folders, etc than can fit on the drive. Most of this extra stuff ias junk data, but you get the idea.

There is no substitue for the original.

Recovery can require a minimum of specialized software or be as complicated as looking at the platters under an electron microscope. I see nothing here that indicates use of such specialized technology, and yet this is supposed to be a national security matter.

Re:electron microscopes

[g4dget]

The document states that image files were generated fo the contents of the hard drives. I do not have confidence that an image would also display latent data.

It's pretty clear what "dd" images: the entire content of the hard disk drive as it is readable by its disk controller. It won't image residual data that has been erased.

I know myself that when I do a data recovery on a system, I can get many more megs of recovered data from file fragments, deleted folders, etc than can fit on the drive. Most of this extra stuff ias junk data, but you get the idea.

Unless your recovery efforts involve custom hardware, the disk image obtained with "dd", together with bad block information and drive geometry, contains every bit of information you are ever going to get out of that drive. Any software-based recovery working on that image is going to be equivalent to recovery working on the original drive.

Trying to recover data that has been physically overwritten, using analog methods or imaging, is so expensive and time consuming that it is feasible only in special cases.

CRC/SHA-1/MD5

[MeanMF]

If the hash value of the original prior to duplication matches identically the hash value after the duplication, one may conclude that the duplicate file accurately reflects the data on the original file. The fact that the hash values match is typically more important than the hash values themselves.

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.

Re:CRC/SHA-1/MD5

[MeanMF]

There are no known examples of two files that have the same MD5 (or SHA-1) hash values

Sorry, my original message was kind of weak :)
The programs that the government uses to do the copy use CRC32, which is very easy to get around. The CRC32 values are listed in section 13 of the expert's affadavit. The government says that this is enough to authenticate the data.

SafeBack and the Logicube SFK-000A incorporate reliable internal CRC verification techniques, CART procedures do not require examiners to generate separate MD5 or SH-1 hashes for computers imaged using SafeBack or Logicube SFK-000A disk duplicator....All hard drives in this case were imaged by one of the three programs used by the FBI, all of which are recognized by the scientific community as reliable imaging programs. Thus, there should be no question about the authenticity of any of the hard drives.

In terms of autenticating evidence for use in court, shouldn't the government be using something stronger than CRC? If I were on the defense's side, I would tear this apart - the MD5 hash that they eventually received was taken well after the original image was created, leaving plenty of time to alter any data. There was ample opportunity for somebody (whether as part of a "government conspiracy" or as an overzealous investigator/prosecutor) to alter both the image and the original hard drive before taking the MD5 hash, and before the image was delivered to the defense as part of discovery. There's no use in having an MD5 hash if all it is doing is verifying that you have an exact copy of data that has been tampered with. The government should, as standard practice, take the MD5 hash before they even make the first image, and preserve that record along with other evidence. This would make it much more difficult for the defense to claim that the data presented in discovery or at trial is not authentic.

FBI HQ originally denied e-mail search request

[michaelmalak]

See my Aug. 29, 2002 blog article FBI didn't get Moussaoui's e-mail despite having his laptop, which notes the irony that "the U.S. government is interested in the e-mail of all those in the U.S. except for alleged terrorists" and which links to an Aug. 29, 2002 Washington Post article.

(Recall that Massaoui was already in jail before Sep. 11. These pre-Sep. 11 e-mail search requests were rebuffed, according to FBI whistleblower Colleen Rowley.)

Privacy irony & national security

[MacAndrew]

Note that the FBI, charged by so many with violating people's privacy in every way imaginable, here dropped the ball by bring too cautious about someone's privacy.

You can't win -- bungling cuts both ways.

Anyone wonder why the heck the Minnesota FBI office went to Washington for a piddly search warrant, instead of their friendly local court? Because this was not an ordinary warrant, but a national security warrant designed to investigate suspected terrorists who might not have committed any crime to provide probable cause for a regular warrant. (You know, like Minority Report. OK, it's not that bad. :)

It will be interesting to see who gets blamed once all of the finger-pointing is over.

From NYT by James Risen*:

According to Ms. Rowley's letter and other bureau officials, the Minneapolis field office believed that the French report on Mr. Moussaoui provided enough troubling information about his ties to Islamic extremism to go to court to obtain a search warrant under the federal law that allows the government to carry out searches and surveillance in espionage and terrorism cases. Under the statute, investigators do not have to show that a subject committed a crime, only that they have reason to believe the suspect is engaged in terrorist activity or espionage on behalf of a foreign power or a terrorist organization.

* Another little note -- James Risen with Jeff Gerth were the NYT reporters blamed with stoking the fire over Wen Ho Lee debacle. Of course, lots of people were blamed -- sound familiar?

How is wipe overkill?

[Anonymous Coward]

3 passes of an encrypted system may be enough for the lowgrade programs you listed, but for realworld, aka non-encrypted systems which 99% of us use, 3 wipes is not enough.

You need something like eraser combined with a dos boot disk or the target drive set as a slave to do anything useful.

I'll post the link if I can find it soon, but I've seen cases of deleted data being recovered after 24 passes of "wiping" programs.

Bottom line like you mentioned is for serious software deletion you need to start with encryption on a virgin disk, and then do multipass guttmann wipes. Even then who knows? Destruction is still the only real method.

That seems pretty low tech

[defile]

Given the weight of the issue and the evidence that could be contained on the disks therein, and given that the US government has an unlimited budget whenever anyone says "terrorism", why they went with dd (or the equivalent ) to copy a disk is beyond me.

I've seen doughnut shops have their hard disks worked on with more advanced technology.

Shouldn't they have taken the hard disk to a clean room, removed the platters from the disk and painstaking recorded every nanometer of them? I wouldn't trust a suspect's hard disk to make a copy of itself.

And in completely unrelated news...

[Kjella]

...encrypting stuff in the first place using Bestcrypt / PGPdisk / whatever would make the entire wiping/recovery discussion (-1, Redundant) when it comes to collecting evidence.

Kjella

Re:Secure File Deletion

[Alsee]

byte pattern 0xff, then 0x00

A little knowledge is a dangerous thing :)
0xff is the value for a string of all 1's and 0x00 is the value for a string of all 0's, but harddrives actually record entirely different bit sequences. And different harddrives use different encodings. Without knowing the specific encoding the current drive uses your best bet is probably to write random values.

-

Uh, September 11?

[netik]

Aside from the fact that 1) the slashdot editor is stupid, and 2) Just because it says linux doesn't warrant a story, this bit caught my eye:

The Examination of Moussaoui's Laptop

Standby counsel's fourth request questions whether the defendant's laptop was imaged before it lost power. The defendant's laptop was imaged on September 11, 2001, before the laptop lost power. Sewell Affidavit at 11. The BIOS settings for the laptop requested by standby counsel are set forth in SSA Sewell's affidavit. Sewell Affidavit at 11. Therefore, this request is now moot.

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.

Re:Secure File Deletion

[sigwinch]

0xff is the value for a string of all 1's and 0x00 is the value for a string of all 0's, but harddrives actually record entirely different bit sequences.

Possibly even variable-length sequences, if a run-length-limited code is used. In which case writing random data a few dozen times could easily leave a big chunk of slack space untouched. Erase/write simply isn't good enough.

The only way to be sure is to nuke the hard drive from orbit. ;-)

Re:Block size limitation in dd noted

[delta407]

(-1, Wrong)

dd does copy incomplete blocks. Try this:

$ dd if=/dev/random of=test bs=1 count=1023
1023+0 records in
1023+0 records out

$ dd if=test of=test2 bs=512
1+1 records in
1+1 records out

$ ls -l test2
-rw-r--r-- 1 delta407 delta407 1023 Jan 1 22:50 test2

See that? We created a 1023-byte file (test), and then dd'ed it to test2 with a block size of 512. Guess what? dd copied the file in its entirety, even though it didn't line up on a block boundary.

Re:Secure File Deletion

[Julian Morrison]

Does anyone know of a "wipe" style utility that can also wipe ununsed disk space (deleted inodes etc) on linux?

Well said!

[disc-chord]

Anyone whose even stepped foot into a "Computer Crimes" department (or whatever your local police call their Info Warriors) knows they have been using *nix since day 1 in forensics.

This is not news, and the idea we should be getting all excited over this suggests that *nix is such a desperatly useless pos as to warrant mass praise whenever anyone actually finds a use. Is that really the message /. wants to convey?