Linux for computer forensic investigators: «pitfalls» of mounting file systems

First published October 2009

by Suhanov Maxim
ITDefence.Ru

Introduction

Forensic Linux distribution is a customized Linux distribution that is commonly used to complete different tasks during computer forensics investigations. These distributions are often used to complete the following tasks:

Get The Latest DFIR News!

Top DFIR articles in your inbox every month.


Unsubscribe any time. We respect your privacy - read our privacy policy.

– Quick preview of various data storage devices (for example, to determine installed operating system);
– Creating «bit-to-bit» copies of data storage devices;
– Conducting full analysis of data storage devices.

Some forensic Linux distributions may include network forensics tools and tools for acquiring volatile data from a running system.

Requirements for forensic Linux distributions

Every forensic Linux distribution should satisfy the following requirements:

– Do not allow any writes to evidentiary media without user’s permission;
– Boot on most common hardware configurations;
– Use only up to date software and fix all security problems as soon as possible.

Blocking any writes to evidentiary media can be achieved by following these steps:

1. Boot scripts and programs do not mount any file systems, do not activate the swap space and do not activate software RAID arrays on evidentiary media without user’s permission;
2. Automouting for all file system types on connected removable devices is disabled.

It is also possible to set all block devices to read-only mode during the boot process to protect evidence from incorrect user actions.

«Pitfalls» of mounting file systems in read-only mode

All Linux distributions allow users to mount a file systems in read-only mode (for example, using the following command: «mount -o ro /dev/sda1 /mnt/sda1»). However, mounting file systems in such a way does not guarantee that file system’s data will never be altered by the operating system. For example, mounting a damaged Ext3 file system with only «-o ro» option will result in data modification during the recovery process:

EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
kjournald starting. Commit interval 5 seconds
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.

Some forensic Linux distributions may show user a message saying that some data on evidentiary media has been overwritten

In this case some file system metadata gets updated after recovery:

 

FILE SYSTEM INFORMATION
——————————————–
File System Type: Ext3
Volume Name:
Volume ID: 5962a06aa4c895b5104749a687ccb9e0
Last Written at: Mon Sep 7 17:41:01 2009
Last Checked at: Fri Sep 4 18:39:00 2009
Last Mounted at: Mon Sep 7 17:41:01 2009
Unmounted properly
Last mounted on:
Source OS: Linux
Dynamic Structure
Compat Features: Journal, Ext Attributes, Resize
Inode, Dir Index
InCompat Features: Filetype, Needs Recovery,
Read Only Compat Features: Sparse Super, Has
Large Files,
FILE SYSTEM INFORMATION
——————————————–
File System Type: Ext3
Volume Name:
Volume ID: 5962a06aa4c895b5104749a687ccb9e0
Last Written at: Mon Sep 7 18:02:57 2009
Last Checked at: Fri Sep 4 18:39:00 2009
Last Mounted at: Mon Sep 7 17:41:01 2009
Unmounted properly
Last mounted on:
Source OS: Linux
Dynamic Structure
Compat Features: Journal, Ext Attributes, Resize
Inode, Dir Index
InCompat Features: Filetype,
Read Only Compat Features: Sparse Super, Has
Large Files,

 

Metadata changes after damaged Ext3 file system recoveryMounting other file systems (for example, Ext4, ReiserFS and XFS) with only «-o ro» option may result in data modification too.

Mounting file systems in a forensically sound manner

To mount various file system types in a forensically sound manner the following methods can be used:

1. Loopback devices in read-only mode: can be switched on using «ro,loop» mount options (for example: «mount -o ro,loop /dev/sda1 /mnt/sda1»);
2. Block devices for disks and partitions in read-only mode: you can switch any block device to read-only mode by using blockdev tool (for example: «blockdev –setro /dev/sda1»);
3. You can disable all journal recovery actions for Ext3 and Ext4 file systems by using «ext2» file system type during the mount. Unfortunately, not all file systems support such kind of write protection — for example, there are no working write protection mount options for XFS (however, this was fixed in very recent kernel versions).

It should be noted that mounting damaged Ext3 and Ext4 file systems using these ways is only possible by utilizing alternate superblocks. You can get alternate superblocks locations by using «mke2fs -n» command (for example: «mke2fs -n /dev/sda1»).

«Pitfalls» of automounting file systems

Automounting of file systems in Linux may occur in following situations: during the boot process and after connecting removable device (for example, USB Flash drive) to a running system.

Removing all entries for file systems on evidentiary media from «/etc/fstab» does not guarantee that they will never be mounted during the boot — file systems can be mounted (and modified) during execution of initrd scripts or during execution of hardware detection scripts.

Automounting of file systems on removable data storage devices is controlled by special software programs that are properly configured (or disabled) on most forensic Linux distributions.
Testing popular forensic Linux Live CD distributions

I have tested several major forensic Linux Live CD distributions for various mounting issues.

 

Information about tested forensic Linux Live CD distributions

Test results:

– All tested distributions do not mount file systems on connected USB Flash devices;
– Some distributions automatically mount (and sometimes modify) file systems on evidentiary media during the boot process: SPADA mounts file systems during execution of hardware detection scripts, other automounting distributions alter the data on evidentiary media during execution of initrd scripts.

 

Test results

Testing automatic swap space activation

The following distributions were tested for automatic swap space activation during the boot: Helix3 (old version), SMART Linux (Slackware), grml, LinEn Boot CD and RIPLinux.

None of these distributions activate the swap space on evidentiary media during the boot process.

Conclusions

I have found that some forensic Linux Live CD distributions do mount and recover several file system types during the boot process. However, I didn’t test Linux RAID and LVM activation issues, so it is recommended to use distributions that do not activate software RAID arrays and LVM without users’ permission (e.g. grml).

Leave a Comment

Latest Videos

Quantifying Data Volatility for IoT Forensics With Examples From Contiki OS

Forensic Focus 22nd June 2022 5:00 am

File timestamps are used by forensics practitioners as a fundamental artifact. For example, the creation of user files can show traces of user activity, while system files, like configuration and log files, typically reveal when a program was run. 

Despite timestamps being ubiquitous, the understanding of their exact meaning is mostly overlooked in favor of fully-automated, correlation-based approaches. Existing work for practitioners aims at understanding Windows and is not directly applicable to Unix-like systems. 

In this paper, we review how each layer of the software stack (kernel, file system, libraries, application) influences MACB timestamps on Unix systems such as Linux, OpenBSD, FreeBSD and macOS.

We examine how POSIX specifies the timestamp behavior and propose a framework for automatically profiling OS kernels, user mode libraries and applications, including compliance checks against POSIX.

Our implementation covers four different operating systems, the GIO and Qt library, as well as several user mode applications and is released as open-source.

Based on 187 compliance tests and automated profiling covering common file operations, we found multiple unexpected and non-compliant behaviors, both on common operations and in edge cases.

Furthermore, we provide tables summarizing timestamp behavior aimed to be used by practitioners as a quick-reference.

Learn more: https://dfrws.org/presentation/a-systematic-approach-to-understanding-macb-timestamps-on-unixlike-systems/

File timestamps are used by forensics practitioners as a fundamental artifact. For example, the creation of user files can show traces of user activity, while system files, like configuration and log files, typically reveal when a program was run.

Despite timestamps being ubiquitous, the understanding of their exact meaning is mostly overlooked in favor of fully-automated, correlation-based approaches. Existing work for practitioners aims at understanding Windows and is not directly applicable to Unix-like systems.

In this paper, we review how each layer of the software stack (kernel, file system, libraries, application) influences MACB timestamps on Unix systems such as Linux, OpenBSD, FreeBSD and macOS.

We examine how POSIX specifies the timestamp behavior and propose a framework for automatically profiling OS kernels, user mode libraries and applications, including compliance checks against POSIX.

Our implementation covers four different operating systems, the GIO and Qt library, as well as several user mode applications and is released as open-source.

Based on 187 compliance tests and automated profiling covering common file operations, we found multiple unexpected and non-compliant behaviors, both on common operations and in edge cases.

Furthermore, we provide tables summarizing timestamp behavior aimed to be used by practitioners as a quick-reference.

Learn more: https://dfrws.org/presentation/a-systematic-approach-to-understanding-macb-timestamps-on-unixlike-systems/

YouTube Video UCQajlJPesqmyWJDN52AZI4Q_i0zd7HtluzY

A Systematic Approach to Understanding MACB Timestamps on Unixlike Systems

Forensic Focus 21st June 2022 5:00 am

This error message is only visible to WordPress admins

Important: No API Key Entered.

Many features are not available without adding an API Key. Please go to the YouTube Feed settings page to add an API key after following these instructions.

Latest Articles

Share to...