Difference between pages "NSF DUE-0919593" and "Forensic Live CD issues"

From ForensicsWiki
(Difference between pages)
Jump to: navigation, search
 
(Problems)
 
Line 1: Line 1:
This page includes links to digital forensics resources produced under NSF DUE-0919593, "Creating Realistic Forensic Corpora for Undergraduate Education and Research"
+
== The problem ==
  
'''EDUCATIONAL DATA SETS'''
+
[[Live CD|Forensic Live CDs]] 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. Unfortunately, community-developed distributions are no exception here. Finally, it turns out that many Linux-based forensic Live CDs are not tested properly and there are no suitable test cases published.
  
'''1. 2009-M57 "Patents" scenario'''
+
== Another side of the problem ==
  
This scenario involves a small company called M57 which was engaged in prior art searches for patents. The fictional company is contacted by the local police in November 2009 after a person purchases a computer from Craigslist and discovers "kitty porn" on the computer. The police trace the computer back to the M57 company.
+
Another side of the problem of insufficient testing of forensic Live CDs is that many users do not know what happens "under the hood" of the provided operating system and cannot adequately test them.
  
The scenario actually involves three separate criminal activities:
+
=== Example ===
      1 - Exfiltration of proprietary information by an M57 employee.
+
      2 - Stealing of M57's property and selling it on Craigslist.
+
      3 - The possession of "kitty porn" photos by an M57 employee.
+
  
This is an involved scenario which has the following information available to students trying to "solve" the case:
+
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).
      1 - Disk image of the computer that was sold on Craigs List
+
      2 - Disk images of the firm's five computers when the police show up.
+
      3 - Disk images of the four USB drives that were found on-site belonging to M57 employees
+
      4 - The RAM image of each computer just before the disk was imaged.
+
  
There are approximately 2-4 weeks of use on each computer.
+
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.
  
'''2. Nitroba University Harassment Scenario'''
+
== Problems ==
  
This scenario involves a harassment case at the fictional Nitroba University.
+
Each problem is followed by a list of distributions affected (currently this list is not up-to-date).
  
Nitroba's IT department has received an email from Lily Tuckrige, a teacher in the Chemistry Department.  Tuckrige has been receiving harassing emails and she suspects that they are being sent by a student in her class Chemistry 109, which she is teaching this summer.  The email was received at Tuckridge's personal email account, lilytuckrige@yahoo.com. She took a screenshot of the web browser and sent it in.
+
=== Journaling file system updates ===
  
The system administrator who received the complaint wrote back to Tuckridge that Nitroba needed the full headers of the email message. Tuckridge responded by clicking the "Full message headers" button in Yahoo Mail and sent in another screen shot, this one with mail headers.
+
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:
  
The mail header shows that the mail message originated from the IP address 140.247.62.34, which is a Nitroba student dorm room. Three women share the dorm room. Nitroba provides an Ethernet connection in every dorm room but not Wi-Fi access, so one of the women's friends installed a Wi-Fi router in the room. There is no password on the Wi-Fi.
+
{| 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.
 +
|}
  
Because several email messages appear to come from the IP address, Nitroba decides to place a network sniffer on the ethernet port. All of the packets are logged. On Monday 7/21 Tuckridge received another harassing email. But this time instead of receiving it directly, the perpetrator sent it through a web-based service called
+
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).
"willselfdestruct.com." The website briefly shows the message to Tuckridge, and then the website reports that the "Message Has Been Destroyed."
+
  
Students are provided with the screen shots, the packets that were collected from the Ethernet tap, and the Chem 109 roster. Their job is to determine if one of the students in the class was responsible for the harassing email and to provide clear, conclusive evidence to support your conclusion.
+
[[Image:ext3 recovery.png|thumb|right|[[Helix3]]: damaged Ext3 recovery during the boot]]
  
'''3. M57 Jean'''
+
List of distributions that recover Ext3 (and sometimes Ext4) file systems during the boot:
  
The M57-Jean scenario is a single disk image scenario involving the exfiltration of corporate documents from the laptop of a senior executive. The scenario involves a small start-up company, M57.Biz. A few weeks into inception a confidential spreadsheet that contains the names and salaries of the company’s key employees was found posted to the “comments” section of one of the firm’s competitors. The spreadsheet only existed on one of M57′s officers—Jean.
+
{| class="wikitable" border="1"
Jean says that she has no idea how the data left her laptop and that she must have been hacked.
+
|-
 +
!  Distribution
 +
!  Version
 +
|-
 +
|  Helix3
 +
|  2009R1
 +
|-
 +
|  SMART Linux (Ubuntu)
 +
|  2010-01-20
 +
|-
 +
|  FCCU GNU/Linux Forensic Boot CD
 +
|  12.1
 +
|-
 +
|  SPADA
 +
|  4
 +
|-
 +
|  DEFT Linux
 +
|  7
 +
|}
  
Students are given a disk image of Jean’s laptop. Their job is to figure out how the data was stolen—or if Jean isn’t as innocent as she claims.
+
=== Orphan inodes deletion ===
  
'''RESEARCH DATA SETS'''
+
When mounting Ext3/4 file systems all orphan inodes are removed, even if "-o ro" mount flag was specified. Currently, there is no specific mount flag to disable orphan inodes deletion. The only solution here is to use "-o ro,loop" flags.
  
We are also making available an enlarged "research data set" which contains a wealth of information that can be used by students interested in RAM, Network, or Disk Forensics.
+
=== Root file system spoofing ===
  
The research data set was created at the same time as the 2009-M57 Patents dataset but contains substantially more information:
+
''See also: [[Early userspace | early userspace]]''
  * All of the IP packets in and out of the M57 test network.
+
  * Daily disk images and RAM captures of each computer on the network.
+
  
This data is not needed to "solve" the scenario, but it might be interesting for students that are:
+
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.
  
  * Interested in learning about RAM analysis and needs a source of RAM images.
+
[[Image:Grml.png|thumb|right|[[grml]] mounted root file system from the [[hard drive]]]]
  * Interested in network forensics and wants packets.
+
  * Interested in writing software that does "disk differencing" or can detect the installation of malware.
+
  * Wants examples of how a Windows registry is modified over time with use.
+
  
'''OBTAINING THE DATA'''
+
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.
  
You can obtain our data at the following addresses:
+
List of Ubuntu-based distributions that allow root file system spoofing:
  
  The M57 Corpus:
+
{| class="wikitable" border="1"
  * http://torrent.ibiblio.org/doc/187/torrents (bit torrent form)
+
  |-
  * http://domex.nps.edu/corp/scenarios/2009-m57(individual files)
+
!  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
 +
|}
  
Please download from the iBiblio bittorrent server if possible. There are a number of torrents available for your convenience. If you examine the manifests, you will notice that the files overlap (some disk images appearing in more than one torrent).
+
Vulnerable Knoppix-based distributions include: SPADA, LinEn Boot CD, BitFlare.
  
Each torrent will place files into:
+
[http://anti-forensics.ru/ Anti-Forensics.Ru project] [http://digitalcorpora.org/corp/aor/drives/ 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]).
  
          [YOUR_LOCAL_DIRECTORY]/torrent_name/corp/scenarios/2009_m57/
+
=== Swap space activation ===
  
Please seed if possible! The "police materials" torrent references only those materials that would be captured in a raid (e.g. the final day of the scenario).
+
''Feel free to add information about swap space activation during the boot in some distributions''
  
 +
=== Incorrect mount policy ===
  
The 2008-Nitroba corpus:
+
==== rebuildfstab and scanpartitions scripts ====
  * http://domex.nps.edu/corp/scenarios/2008-nitroba/
+
 
 +
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 a block device to read-only mode does not guarantee that [http://oss.sgi.com/archives/xfs/2009-07/msg00213.html no write commands will be passed to the drive]. There were several other bugs related to writing on a read-only device in the past (like [https://lkml.org/lkml/2007/2/6/1 Ext3/4 orphan inodes deletion]). At present, kernel code still disregards read-only mode set on block devices in many places (it should be noted that setting a block device to read-only mode will efficiently write-protect the drive from programs running in userspace, while kernel and its modules still can write anything to the block device, regardless of the read-only mode).
 +
 
 +
=== TRIM aka discard command ===
 +
 
 +
== 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]
 +
 
 +
[[Category:Live CD]]

Revision as of 17:59, 15 June 2014

The problem

Forensic Live CDs 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. Unfortunately, community-developed distributions are no exception here. Finally, it turns out that many Linux-based forensic Live CDs are not tested properly and there are no suitable test cases published.

Another side of the problem

Another side of the problem of insufficient testing of forensic Live CDs is that many users do not know what happens "under the hood" of the provided operating system and cannot adequately test them.

Example

For example, 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 a list of distributions affected (currently this list is not up-to-date).

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:

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 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).

Helix3: damaged Ext3 recovery during the boot

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

Distribution Version
Helix3 2009R1
SMART Linux (Ubuntu) 2010-01-20
FCCU GNU/Linux Forensic Boot CD 12.1
SPADA 4
DEFT Linux 7

Orphan inodes deletion

When mounting Ext3/4 file systems all orphan inodes are removed, even if "-o ro" mount flag was specified. Currently, there is no specific mount flag to disable orphan inodes deletion. The only solution here is to use "-o ro,loop" flags.

Root file system spoofing

See also: early userspace

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.

grml mounted root file system from the hard drive

Currently, Casper may select fake root file system image on evidentiary media (e.g. 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:

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.

Anti-Forensics.Ru project released several ISO 9660 images used to test various Linux Live CD distributions for root file system spoofing (description for all images is 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 a block device to read-only mode does not guarantee that no write commands will be passed to the drive. There were several other bugs related to writing on a read-only device in the past (like Ext3/4 orphan inodes deletion). At present, kernel code still disregards read-only mode set on block devices in many places (it should be noted that setting a block device to read-only mode will efficiently write-protect the drive from programs running in userspace, while kernel and its modules still can write anything to the block device, regardless of the read-only mode).

TRIM aka discard command

External links