Forensics Wiki - User contributions [en]

User:John Crout

2013-04-14T19:16:18Z

John Crout: format

: * Customer Support (Access Control, 3rd party incident support) for an email host
: * Colorado (licensed) Substitute (Estes Park, Thompson, Poudre)

: * 8th Coast Guard District Western Rivers Region (Auxiliary)
: - Division 1 Staff Officer for Communications
: - Vice Commander, Flotilla 6

: * ARC Centennial Chapter, Disaster Team

User:John Crout

2013-04-14T18:16:23Z

John Crout: Updated personal information

Current:
Customer Support (Access Control, 3rd party incident support) for an email host
Colorado (licensed) Substitute (Estes Park, Thompson, Poudre)

Division 1 Staff Officer for Communications
Vice Commander, Flotilla 6
8th Coast Guard District Western Rivers Region

ARC Centennial Chapter, Disaster Team

Inter-agency communication advocate

User:John Crout

2012-07-10T23:59:57Z

John Crout: MPH, BSEE, CISSP. Advocating FEMA training and volunteer relationships with federal agencies. ("Politician" is a paid position that needs oversight).

Management and design experience from avionics and medical devices industries

USCG Auxiliary
Flotilla Vice Commander, 8WR 16 (2012)
Flotilla Staff Officer - Information Services, 8WR 16 (2012)

ISSA Colorado Springs

IGC Denver chapter, member

SoftHome.net (since Oct 2003)
System/Network Administrator

NIST Cloud Security Working Group contributor

American Red Cross

Prev:
Texas Engineering Extension (TEEX), div. of Texas A&M (since June 2011)
Adjunct, DHS/FEMA certified cybersecurity courses

USCG Auxiliary
Direct communication with CIO was authorized Feb 2010
National Staff, Branch Chief Data Security (Dec 2008 - Jan 2010)
Flotilla Staff Officer - Communications Services (Nov 2008 - Dec 2010)

User:John Crout

2012-07-10T23:57:37Z

John Crout: MPH, BSEE, CISSP. Advocating volunteer relationships with federal agencies. ("Politician" is a paid position that needs oversight).

Management and design experience from avionics and medical devices industries

ISSA Colorado Springs

USCG Auxiliary
Vice-Flotilla Commander, 8WR 16 (since Dec 2011)
Authorized for direct communications with CIO (outside of Chain of Leadership) since Feb 2010
National Staff, Branch Chief Data Security (Dec 2008 - Jan 2010)
Flotilla Staff Officer - Communications Services (Nov 2008 - Dec 2010)

IGC Denver chapter, member

SoftHome.net (since Oct 2003)
System/Network Administrator

NIST Cloud Security Working Group contributor

American Red Cross

Prev:
Texas Engineering Extension (TEEX), div. of Texas A&M (since June 2011)
Adjunct, DHS/FEMA certified cybersecurity courses

Talk:Write Blockers

2011-12-29T06:53:50Z

John Crout: Answered my question / hope I didn't waste anyone's time

Talk:Write Blockers

2011-12-29T06:50:20Z

John Crout: /* How are they more valuable than mount -o ro? */

== How are they more valuable than mount -o ro? ==

To add value, wouldn't a write-blocker need to be infallible, then *proven* to be infallible? (That is, proven to be as such, within the margin demonstrated by proving compliance with RTCA/DO-178B using Criticality Level 1). [[User:John Crout|johnc]] 17:49, 28 December 2011 (PST)

The question may not be relevant to hardware solutions. A schematic or data flow diagram would be helpful. Many thanks to the folks who created this page. [[User:John Crout|johnc]] 22:50, 28 December 2011 (PST)

Talk:Write Blockers

2011-12-29T01:49:57Z

John Crout: How are they more valuable than mount -o ro?

Talk:Forensic Live CD issues

2011-12-25T20:26:37Z

John Crout: /* List of Live CD distros that ARE forensically sound? */ Provided opinion

Just putting all discovered stuff together in one article. [[User:.FUF|.FUF]] 21:29, 3 February 2010 (UTC)

== List of Live CD distros that '''''ARE''''' forensically sound? ==

This is an incredibly useful article. However, with a quick glance through the listed offenders, one might walk away with the impression that '''all''' of the 'major' forensics Live CD distros might corrupt the target drive. Or worse, someone may falsely believe that if their favorite flavor was not mentioned in the article, then it must be safe.

Further still, the sentence, "Each problem is followed by an up to date list of distributions affected" is a pretty bold statement, especially in light of the fact that this article hasn't been updated in 15 months...

I'm just wondering if anyone has re-tested any '''newer''' versions of the listed offenders since this article was written? Or perhaps whether the specific developer teams might have self-declared that these issues are "fixed" as of a particular release? Or if anyone is aware of '''other''' forensic Live CD distros that have been verified as 'safe' from these problems? Hoping to avoid reinventing the wheel here... either way, if I learn of anything in my travels, I'll post an update...

--[[User:Grolltech|Grolltech]] 21:19, 11 September 2011 (PDT)

: Runtime options to mount can be changed at will by UID=0 no matter which options are chosen as defaults. This really begs the question of "Who is responsible" during an investigation. To me it seems the answer is "the investigator", not "the distro". I'm still learning the process of investigation but they I understand it, its processes and chain of custody demand that an investigator is skilled with the distro, not merely acquainted. (And the scope needs to include the entire OS/distro not merely the Linux kernel). [[User:John Crout|John Crout]] 12:26, 25 December 2011 (PST)

Forensic Live CD issues

2011-12-25T19:44:20Z

John Crout: /* Problems */ Removed first sentence (was re-statement explaining what a Live CD is and can be used for).

== The problem ==

[[Tools#Forensics_Live_CDs | Forensic Linux Live CD distributions]] are widely used during computer forensic investigations. Currently, many vendors of such Live CD distributions spread false claims that their distributions "do not touch anything", "write protect everything" and so on. Community-developed distributions are no exception here, unfortunately. Finally, it turns out that many forensic Linux Live CD distributions are not tested properly and there are no suitable test cases developed.

== Another side of the problem ==

Another side of the problem of insufficient testing of forensic Live CD distributions is that many users do not know what happens "under the hood" of such distributions and cannot adequately test them.

=== Example ===

For example, [http://forensiccop.blogspot.com/2009/10/forensic-cop-journal-13-2009.html ''Forensic Cop Journal'' (Volume 1(3), Oct 2009)] describes a test case when an Ext3 file system was mounted using "-o ro" mount flag as a way to write protect the data. The article says that all tests were successful (i.e. no data modification was found after unmounting the file system), but it is known that damaged (i.e not properly unmounted) Ext3 file systems cannot be write protected using only "-o ro" mount flags (write access will be enabled during file system recovery).

And the question is: will many users test damaged Ext3 file system (together with testing the clean one) when validating their favourite forensic Live CD distribution? My answer is "no", because many users are unaware of such traits.

== Problems ==

Each problem is followed by an up to date list of distributions affected.

=== Journaling file system updates ===

When mounting (and unmounting) several journaling file systems with only "-o ro" mount flag a different number of data writes may occur. Here is a list of such file systems:

{| class="wikitable" border="1"
|-
! File system
! When data writes happen
! Notes
|-
| Ext3
| File system requires journal recovery
| To disable recovery: use "noload" flag, or use "ro,loop" flags, or use "ext2" file system type
|-
| Ext4
| File system requires journal recovery
| To disable recovery: use "noload" flag, or use "ro,loop" flags, or use "ext2" file system type
|-
| ReiserFS
| File system has unfinished transactions
| "nolog" flag does not work (see ''man mount''). To disable journal updates: use "ro,loop" flags
|-
| XFS
| Always (when unmounting)
| "norecovery" flag does not help (fixed in recent 2.6 kernels). To disable data writes: use "ro,loop" flags.
|}

Incorrect mount flags can be used to mount file systems on evidentiary media during the boot process or during the file system preview process. As described above, this may result in data writes to evidentiary media. For example, several Ubuntu-based forensic Live CD distributions mount and recover damaged Ext3/4 file systems on fixed media (e.g. hard drives) during execution of [http://en.wikipedia.org/wiki/Initrd ''initrd''] scripts (these scripts mount every supported file system type on every supported media type using only "-o ro" flag in order to find a root file system image).

[[Image:ext3 recovery.png|thumb|right|[[Helix3]]: damaged Ext3 recovery during the boot]]

List of distributions that recover Ext3 (and sometimes Ext4) file systems during the boot:

{| class="wikitable" border="1"
|-
! Distribution
! Version
|-
| Helix3
| 2009R1
|-
| SMART Linux (Ubuntu)
| 2010-01-20
|-
| FCCU GNU/Linux Forensic Boot CD
| 12.1
|-
| SPADA
| 4
|}

=== Root file system spoofing ===

Most Ubuntu-based forensic Live CD distributions use Casper (a set of scripts used to complete initialization process during early stage of boot). Casper is responsible for searching for a root file system (typically, an image of live environment) on all supported devices (because a bootloader does not pass any information about device used for booting to the kernel), mounting it and executing ''/sbin/init'' program on a mounted root file system that will continue the boot process. Unfortunately, Casper was not designed to meet computer forensics requirements and is responsible for damaged Ext3/4 file systems recovery during the boot (see above) and root file system spoofing.

[[Image:Grml.png|thumb|right|[[grml]] mounted root file system from the [[hard drive]]]]

Currently, Casper may select fake root file system image on evidentiary media (e.g. [[Hard Drive|HDD]]), because there are no authenticity checks performed (except optional UUID check for a possible live file system), and this fake root file system image may be used to execute malicious code during the boot with root privileges. Knoppix-based forensic Live CD distributions are vulnerable to the same attack.

List of Ubuntu-based distributions that allow root file system spoofing:

{| class="wikitable" border="1"
|-
! Distribution
! Version
|-
| Helix3
| 2009R1
|-
| Helix3 Pro
| 2009R3
|-
| CAINE
| 1.5
|-
| DEFT Linux
| 5
|-
| Raptor
| 2.0
|-
| BackTrack
| 4
|-
| SMART Linux (Ubuntu)
| 2010-01-20
|-
| FCCU GNU/Linux Forensic Boot CD
| 12.1
|}

Vulnerable Knoppix-based distributions include: SPADA, LinEn Boot CD, BitFlare.

[http://anti-forensics.ru/ Anti-Forensics.Ru project] [http://digitalcorpora.org/corp/images/aor/ released several ISO 9660 images] used to test various Linux Live CD distributions for root file system spoofing (description for all images is [http://anti-forensics.ru/casper/ here]).

=== Swap space activation ===

''Feel free to add information about swap space activation during the boot in some distributions''

=== Incorrect mount policy ===

==== rebuildfstab and scanpartitions scripts ====

Several forensic Linux Live CD distributions (Helix3 2009R1, Helix3 Pro 2009R3, old versions of CAINE, old versions of grml) use rebuildfstab and scanpartition scripts to create entries for attached devices in ''/etc/fstab''. Some versions of these scripts use wrong wildcards while searching for available block devices (''/dev/?d?'' instead of ''/dev/?d*''), this results in missing several "exotic" devices (like /dev/sdad, /dev/sdad1, etc) and in data writes when mounting them (because fstab lacks of read-only mount options for these devices).

=== Incorrect write-blocking approach ===

Some forensic Linux Live CD distributions rely on [[hdparm]] and [[blockdev]] programs to mount file systems in read-only mode (by setting the underlying block device to read-only mode). Unfortunately, setting the block device to read-only mode does not guarantee that [http://archives.free.net.ph/message/20090721.105120.99250e3f.en.html no write commands will be passed to the drive].

== External links ==

* [http://www.computer-forensics-lab.org/pdf/Linux_for_computer_forensic_investigators_2.pdf Linux for computer forensic investigators: problems of booting trusted operating system]
* [http://www.computer-forensics-lab.org/pdf/Linux_for_computer_forensic_investigators.pdf Linux for computer forensic investigators: «pitfalls» of mounting file systems]