Difference between pages "SIMCon" and "Forensic Live CD issues"

From ForensicsWiki
(Difference between pages)
Jump to: navigation, search
 
(Problems)
 
Line 1: Line 1:
{{Wikify}}
+
== The problem ==
  
==SIMCon==
+
[[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.
  
[http://www.simcon.no SIMCon] is a program that securely images all files on a [[GSM]] [[SIM Card]] with a standard smart card reader. After imaging, the forensic investigator can then analyze the contents of the card. Specific information regarding stored numbers, call history, and text messages are available.
+
== Another side of the problem ==
  
[http://www.simcon.no SIMCon]'s features:
+
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.
  
* Acquire all available files on a [[SIM Card]] and store in an archive file
+
=== Example ===
* Analyze and interpret content of files
+
* Recover deleted text messages stored on the card
+
* Manage PIN and PUK codes
+
* Compatible with [[SIM Cards]] and [[USIM Cards]]
+
* Print reports of evidence
+
* Secure file archive using hashing
+
* Export items to popular spreadsheet programs
+
* Supports international charsets
+
  
 +
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).
  
All [[GSM]] cell phones today have a subscriber identity module (SIM) to identify the phone onto the network. [http://www.simcon.no SIMCon] is an application to acquire all of the information from the [[SIM Card]].
+
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.
  
The [[SIM Card]] provides secure storing of the key identifying a mobile phone service subscriber, subscription information, preferences and text messages.  Network state information, such as the current location area identity (LAI), is also stored on the card.  When a handset is turned off and then back on, it will search for the LAI that it was in, rather than having to search all frequencies that the phone operates in.  This saves time when trying to log on to the network. (Subscriber, 2006, para. 1)
+
== Problems ==
  
By using [http://www.simcon.no SIMCon] and a smart card reader, all of the above information and more can be pulled off of the card without knowing the PIN or the PUK of the card.  The PIN and the PUK are ways to keep the information on the card secure.  They also can be used as a security feature on the phone, not allowing anyone to use a phone to access the [[SIM Card]] without knowing the codes.
+
Each problem is followed by a list of distributions affected (currently this list is not up-to-date).
  
[http://www.simcon.no SIMCon] is an application developed by Inside Out Forensics in Norway.  It is designed for use by the law enforcement community, and it can be obtained free of charge by emailing [http://www.simcon.no SIMCon] and identifying the officers and unit.  However, for anyone outside the law enforcement community, it is not free. 
+
=== Journaling file system updates ===
  
===Review===
+
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:
[http://www.simcon.no SIMCon] makes the acquisition of data very easy, simply inserting the SIM Card to the appropriate Sim card reader, and clicking acquire is all that is needed to start analyzing evidence. After the acquisition of the data is complete SimCon will show the user a screen with two halves. 
+
  
On the left panel is the different data sectors of the [[SIM Card]] that can either be checked on or off depending on what is needed. After choosing what data sectors are needed, the right panel will be populated with the selected data. Some of the most useful pieces of information that are shown are: the International Mobile Subscriber Identity number, every contacts name and number, and all SMS messages sent and received both stored and deleted.   
+
{| 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.
 +
  |}
  
[http://www.simcon.no SIMCon] also comes with two more handy features that are key to an investigation and in a court of law.  The first is [http://www.simcon.no SIMCon]s' feature that allows the printing of a report.  [http://www.simcon.no SIMCon] will format and populate a report with the contents of the users’ choosing.  This can list all the key pieces to an investigation and is an excellent piece of evidence to be used in a court of law.  The second feature is the exportation of the acquired data.  [http://www.simcon.no SIMCon] allows the exportation of all SMS messages and also of all contacts.  When these exported files are opened in a program such as Microsoft Excel the data can be read, sorted, and analyzed in a format of the users design.
+
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).
  
When SMS messages are exported [http://www.simcon.no SIMCon] automatically adds the following information about every message: file, item, status, service center, message type, number, time stamp, and text.  When the contacts are exported [http://www.simcon.no SIMCon] automatically adds the following information about every contact: file, item, identifier, and number.  For reference a report of an acquired [[SIM card]] is enclosed as well as a document that tells what information is added into an exported file at the end of this document.
+
[[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:
  
===Links===
+
{| class="wikitable" border="1"
* [http://www.simcon.no SIMCon]
+
|-
 +
!  Distribution
 +
!  Version
 +
|-
 +
|  Helix3
 +
|  2009R1
 +
|-
 +
|  SMART Linux (Ubuntu)
 +
|  2010-01-20
 +
|-
 +
|  FCCU GNU/Linux Forensic Boot CD
 +
|  12.1
 +
|-
 +
|  SPADA
 +
|  4
 +
|-
 +
|  DEFT Linux
 +
|  7
 +
|}
  
* [http://en.wikipedia.org/wiki/Subscriber_Identity_Module Subscriber Identity Module]
+
=== Orphan inodes deletion ===
  
* [http://www.simcon.no/ InsideOut Forensics]
+
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 option to disable orphan inodes deletion. The only solution here is to use "-o ro,loop" flags.
 +
 
 +
=== Root file system spoofing ===
 +
 
 +
''See also: [[Early userspace | 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.
 +
 
 +
[[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]
 +
 
 +
[[Category:Live CD]]

Revision as of 16:24, 19 May 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 option 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 the block device to read-only mode does not guarantee that no write commands will be passed to the drive.

External links