Forensic Imaging and Artifacts analysis of Linux & Mac (EXT & HFS+)

Transcription

1 Copyright: The development of this document is funded by Higher Education of Academy. Permission is granted to copy, distribute and /or modify this document under a license compliant with the Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. To view a copy of this license, visit Forensic Imaging and Artifacts analysis of Linux & Mac (EXT & HFS+) BLOSSOM Manchester Metropolitan University (Funded by Higher Education Academy) l.han@mmu.ac.uk

2 1. Learning Objectives This lab aims to learn how to perform forensic imaging and forensic analysis of Linux /Mac OS using open source tools. 2. Preparation 1) Under Linux environment 2) Some documents that you may need to refer to: 3. Tasks 'Virtual-MachineGuide.pdf' Linux-Guide.pdf BLOSSOM-UserGuide.pdf Setup & Installation: Start a single virtual machine as you have done with previous exercises (see Virtual Machine Guide): # kvm -cdrom /var/tmp/blossomfiles/blossom-0.98.iso -m 512 -net nic,macaddr=52:54:00:12:34:57 -net vde -name node-one

3 Task 1 Creating Linux File System & Imaging Using dcfldd 1.1 Creating forensically sound images of devices is an extremely important part of forensic computing, since that will be what you will be analysing for evidence so that the original piece of evidence would not be changed and remain as admissible evidence. Due to the nature of this lab being on a virtual machine, we must first create a file system that can then be imaged. # dd if=/dev/zero of=disk-image count=10240 # mkfs t ext3 q disk-image This will create an empty 5MB large file system of type EXT3. We must also mount it to a device in order to allow for live imaging: # mkdir fs # mount o loop disk-image fs This will create a directory called fs, and mount the disk-image to the directory as the first loop device available, which should be /dev/loop Now with the file system in place, we can use dcfldd to create a forensically sound image of the file system. dcfldd is very similar to dd with certain exceptions relating to the forensically sound acquisition of disk images, allowing for hash creation and validation for example. The command to image the mounted device would be as follows: # dcfldd if=/dev/loop1 of=dcfldd.img hashwindow=5m hash=md5,sha1 hashlog=dcfldd.hashlog This will take /dev/loop1 as the input device and output the image as dcfldd.img. hashwindow, hash and hashlog are all commands that relate to the forensic verification of the image, hashwindow states at which point the hash verification should occur, for which 5MB has been chosen due to the file system size, hash states the choice of hash functions to be used for verification, for which MD5 and SHA1 have been selected, and hashlog stores the output of the hash functions into a hash log. 1.3 Before delving in to analysing file systems, a key point to understand is the reason for using hash functions to verify the image file. Whenever the disk image is changed, even in the slightest manner, the result of each hash function will be drastically different. This can be seen by viewing the hashlog previously created, and then copying a file in to the file system and creating the disk image again, and you will be able to see the extreme differences between the hash function results.

4 Task 2 Using Sleuthkit to analyse Linux Artifacts 2.1 Sleuthkit is an Open Source piece of software that contains tools with the potential to provide a forensic analysis on disk images. We will look in to multiple different commands, why the command helps in a forensic investigation, and will also delve in to certain artifacts of forensic importance contained within a linux file system. The first command we will look at is fsstat: # fsstat dcfldd.img This will display information about the file system that we created in the previous task, showing such important information as the type of file system, and times relating to the time which it was last written to, checked and mounted. Metadata information is also displayed, providing the inode number of the root directory, and the content / block information provides information that is needed to extract raw data from the file system, such as telling us the amount of block groups, how many inodes and blocks are in a group. This information could potentially help in recovering deleted data. 2.2 The next command we will look at is stat, which simply allows us to discover metadata about files in the file system. We will also look in to the function known as hard linking files in EXT file systems. For this we will create some test files within the mounted file system: # cd fs # touch file1 # echo I am file1 > file1 This will create a file called file1 with the text I am file1 inside. Perform the stat function now: # stat file1 This will display information about file1, such as the last time accessed, modified and changed, as well as device, block and inode information and levels of access control. We will now hard link file1 to another file, file2 using the ln command, and then view its metadata: # ln file1 file2 # stat file2 We will now be shown information about the newly created hard link to file1. When viewed, both file1 and file2 will show the exact same content, being I am file1, and will also display the same inode and block information. Compare both file1 and file2 in stat and it will

5 become apparent that both of these files are simply just referencing the same inode. Another type of linking can also occur in an EXT file system, which is known as soft linking. Soft links have a path to another file in place of the block pointers in its inode, therefore serving as an indirect reference to the file: # ln s file1 file3 Now view the metadata of both files through the stat command. The file, file1 will remain unchanged completely, not even realising that it is also file3 ; however, file3 will show that is has no data allocated to it, the size of the file will be the number of bytes in the target files name, and it will also be its own inode. The forensic value of metadata becomes quite apparent over the previous few exercises, such as being able to find the ownership information about a suspect file in order to reduce the number of people involved in an investigation based on access privileges to a machine. In preparation for the next task, delete the file file1 from the file system we created using the following command: # rm file1 NOTE: After this task, recreate the dcfldd.img file so it includes the files created during the previous task. 2.3 Another set of useful commands in sluethkit is fls and icat. The files and directories named in the image can be recovered using fls, which will also display the inode location of files, and if file1 is displayed as inode 12, we can recover the file using icat : # fls dcfldd.img fls reveals that the file at inode 12 (file1) has been deleted, but as it is shown by this command, we can then recover it using the following command: # icat -r dcfldd.img 12 > file1 The -r tag states that we wish to recover the file at the inode location specified in the image, and the > signifies where the file will be saved and what is will be called, and for simplicities sake it has been named file1. Next we can use the stat command used previously to verify that the file has in fact been recovered (Check the size, blocks etc).

6 Task 3 Creating MAC File System & Imaging Using dcfldd 3.1 As with the first task, we are going to have to create a file system within the virtual machine to image, but this time we will be using the HFS+ file system, which is the file system primarily used in MAC computers. First, we must create the initial file system file in the same way as before, but we add the file system type in a slightly different manner: #dd if=/dev/zero of=mac-image count=10240 #mkfs.hfsplus v Untitled mac-image This creates the file mac-image as a 5MB file of type HFS+. Next, we must mount it, again in a similar fashion to before: #mkdir mfs #mount t hfsplus o loop mac-image mfs This will create the directory mfs and mount the file mac-image to the directory as the next loop device available, which should be /dev/loop2. Question: With the basic HFS+ file system up and running, what would the command be to create an image of it? Use the command and name the output file dcflddmac.img

7 Task 4 Using Sleuthkit / MAC Artifacts 4.1 As with the EXT3 image created earlier, the HFS+ image can be analysed using Sleuthkit in a similar manner: # fsstat dcflddmac.img This will show information pertaining to the file system, which should show that the file system type is HFS+, and also information about metadata, block allocation and mount information. 4.2 The next command we will look in to is fls, which provides a list of the files and directory names in the image: # fls dcflddmac.img This should display 6 HFS+ special files, which are the backbone of the HFS+ file system. These are denoted by the $ symbol before each file name. Question: What are the HFS+ special files and what is the purpose of each file? What are these similar files similar to? Research these via the Internet.