11.4 Data Recovery
11.4 Data Recovery
Unlike Windows and Macintosh file systems, UNIX does not have file slack space. When UNIX creates a new file, it writes the remainder of the block with zeros and sets them as unallocated. Therefore, it is not possible to recover deleted data from slack space on UNIX systems. Some tools, such as testdisk[7] and gpart[8] are available for recovering deleted partitions on UNIX and Windows systems. There are only a few tools, such as tarfix, fixcpio, tarx, and tar_aids for repairing damages files on Unix.
11.4.1 Unix-Based Tools
One approach to recovering deleted files on UNIX systems is to search for inodes and recover the associated data. For instance, a list of all deleted inodes obtained from a Linux system using ils is shown here:
examiner1% ils -f linux-ext2 /e1/case2/ext2-bitstream.dd | more class|host|device|start_time ils|ease|exta-bitstream.dd|1054082181 st_ino|st_alloc|st_uid|st_gid|st_mtime|st_atime|st_ctime|st_dtime|st_mode|st_nli nk|st_size|st_block0lst_block1 1|a|0|0|973385730|973385730|973385730|0|0|0|0|0|0 24|f|500|500|973695537|973695537|973695537|973695537|40700|0|0|308|0 25|f|500|500|954365|44|973695521|973695537|973695537|100600|0|28587|309|310 26|f|500|500|954365144|973695521|973695537|973695537|100600|0|340|338|0 2049|f|500|500|973695537|973695537|973695537|973695537|40700|0|0|8489|0 2050|f|500|500|953943572|973695536|973695537|973695537|100600|0|4178|8490|8491 2051|f|500|500|960098764|973695521|973695537|973695537|100600|0|52345|8495|8496 2052|f|500|500|953943572|973695537|973695537|973695537|100600|0|4860|8548|8549 2053|f|500|500|959130680|973695521|973695537|973695537|100600|0|28961|8553|8554 2054|f|500|500|959130680|973695521|973695537|973695537|100600|0|87647|8583|8584 2055|f|500|500|961959437|973695521|973695537|973695537|100600|0|30799|8670|8671 2056|f|500|500|959130680|973695521|973695537|973695537|100600|0|50176|8702|8703 2057|f|500|500|953943572|973695537|973695537|973695537|100600|0|21700|8752|8753 2058|f|500|500|959130680|973695521|973695537|973695537|100600|0|22865|8775|8776 2059|f|500|500|959130680|973695521|973695537|973695537|100600|0|14584|8799|8800 2060|f|500|500|953943572|973695521|973695537|973695537|100600|0|12276|8815|8816 2061|f|500|500|959130680|973695521|973695537|973695537|100600|0|10840|8827|8828 2062|f|500|500|959130680|973695521|973695537|973695537|100600|0|26027|8838|8839
Once the inode number of a deleted file is known, the contents of the file can be accessed using icat provided the data still exist as shown here for inode 2054 in the previous list (in bold):
examiner1% icat -f linux-ext2 ext2-bitstream.dd 2054 /* dcc.c — handles: activity on a dcc socket disconnect on a dcc socket …and that's it! (but it's a LOT) dprintf'ized, 27oct95 */ /* This file is part of the eggdrop source code copyright (c) 1997 Robey Pointer and is distributed according to the GNU general public license. For full details, read the top of 'main.c' or the file called COPYING that was distributed with this code. */ #if HAVE_CONFIG_H #include <config.h> The Linux Disk Editor,[9] Recover,[10] and debugfs (Widdowson and Ferlito 2001; Buckeye and Liston 2002) use this approach to recover deleted files on ext2 file systems. The SMART tool also uses this approach to recover deleted files (Figure 11.7).
Figure 11.7: SMART file recovery process saves deleted files onto the examination system for further analysis using other tools.
However, recall that many UNIX file systems remove references from inodes to the sectors that contain the data, breaking the connection between the inode and the data on disk. This fact is evident in the following list of deleted inodes from a Solaris system - all of the starting blocks (the first sector that contained data for each file) are set to zero:
examiner1% ils -r -f solaris /e1/case2/ufs-bitstream.dd class|host|device|start_time ilsllegolasl/e1/morgue/ufs-bitstream.dd|103910l486 st_ino|st_alloc|st_uid|st_gid|st_mtime|st_atime|st_ctime|st_mode|st_nlink|st_size| st_block0lst_block1 213|f|0|1|1038427233|1038427233|1038427243|0|0|0|0|0 3946|f|0|0|987886669|987886669|987886690|0|0|0|0|0 7698|f|0|60001|987893332|987893332|987893332|0|0|0|0|0 11509|f|0|60001|987893332|987893332|987893332|0|0|0|0|0 15105|f|0|60001|987893332|987893332|987893332|0|0|0|0|0 15260|f|0|0|987886816|987886816|987886830|0|0|0|0|0 15261|f|0|0|987886821|987886821|987886830|0|0|0|0|0 15264|f|0|0|987886449|987886449|987886457|0|0|0|0|0 15265|f|0|0|987886449|987886449|987886457|0|0|0|0|0 22816|f|0|0|1038421634|1038421621|1038421634|0|0|0|0|0 22817|f|0|0|987893848|987887279|987893848|0|0|0|0|0 34164|f|0|60001|987893333|987893332|987893354|0|0|0|0|0 45493|f|0|0|1038421571|1038421571|1038421634|0|0|0|0|0 45494|f|0|0|1038421571|1038421571|1038421634|0|0|0|0|0 53039|f|0|60001|987893333|987887277|987893354|0|0|0|0|0 56784|f|0|0|987886929|987886922|987886935|0|0|0|0|0 56787|f|0|0|987886930|987886929|987886935|0|0|0|0|0 56788|f|0|0|987886903|987886903|987886917|0|0|0|0|00 60579|f|0|0|987886609|987886609|987886620|0|0|0|0|0 60580|f|0|0|987886601|987886601|987886620|0|0|0|0|0 64394|f|0|1|1038425953|1038425939|1038425983|0|0|0|0|0 64395|f|0|1|1038421500|1038421498|1038421506|0|0|0|0|0
Another approach to recovering deleted files is to look in directories for deleted entries, provided they exist.[11] For instance, The Sleuth Kit uses this method to generate a list of deleted files and directories on an ext2 file system using fls as shown here:
examiner1% fls -d -r -f linux-ext2 /dev/hdd2 -/- * 0: boot/ -/- * 4(realloc): boot/ -/- * 0: boot/P -/- * 0: boot/ -/- * 0: boot/ b/- * 0: dev/ataraid/d9p9;3d905a83 b/- * 0: dev/cciss/c7d9p9;3d905a83 c/- * 0: dev/compaq/cpqrid;3d905a83 c/- * 0: dev/dri/card3;3d905a83 b/- * 0: dev/i2o/hdz9;3d905a83 b/- * 0: dev/ida/c7d9p9;3d905a83 c/- * 0: dev/inet/udp;3d905a83 d/d * 933895(realloc): dev/input c/c * 66319(realloc): dev/ip2ip|0 l/l * 66318(realloc): dev/ip c/c * 66323(realloc): dev/ip2stat0 c/c * 66320(realloc): dev/ip2ip|1 c/c * 66321(realloc): dev/ip2ipl2 c/c * 66322(realloc): dev/ip2ipl3 d/d * 983047(realloc): dev/logicalco -/- * 3355443: dev/ <cut for brevity>
The Autopsy Forensic Browser combines these two approaches to list all deleted directory entries that were referencing a given inode (labeled "Pointed to by file") as shown here for inode 3817585 on an ext2 file system:
node: 3817585 Pointed to by file: /tmp/makewhatis3JoBa0 (deleted) /root/.netscape/cache/1A/cache3DDC0D5A01A20AD (deleted) /root/.netscape/cache/1A/cache3DD5997A1200A22 (deleted) File Type: empty Details: Not Allocated Group: 233 uid/gid: 0/0 mode: drwx------ size: 0 num of links: 0 Inode Times: Accessed: Mon Nov 25 19:08:29 2002 File Modified: Mon Nov 25 19:08:29 2002 Inode Modified: Mon Nov 25 19:08:29 2002 Deleted: Mon Nov 25 19:08:29 2002 Direct Blocks:
It is worth reiterating that these tools are not limited to examining UNIX file systems - they can be used to recover files from FAT and NTFS systems.
11.4.2 Windows-Based Tools
Although EnCase recovers some deleted files on ext2 file systems, placing them all in a "Lost Files" area, it does not reference data using inode numbers and does not currently recover deleted directory entries as described earlier in this next section. However, some Windows-based tools do facilitate certain forms of examination that are not readily available in Linux-based tools. As an example, Forensic Toolkit recovers deleted files and folders from ext2 file systems into an area called "[orphan]," organizing and displaying the recovered data in a way that facilitates examination. For instance, as shown in Figure 11.8, FTK uses inode numbers to reference recovered items and provides convenient representations of recovered files such as the deleted TAR file.
Figure 11.8: FTK used to view ext2 file system in the file "honeynet.hda8.dd," available from http://www.honeynet.org/challenge/.
11.4.3 File Carving with UNIX
Deleted data can also be recovered using class characteristics. For instance, foremost[12] can be used to carve files from any digital object such as an evidence file, unallocated space, or a swap file. The following output shows foremost recovering files from a bitstream copy of a floppy disk:
examiner1% foremost -o carved-foremost -v floppycopy.dd foremost version 0.62 Written by Kris Kendall and Jesse Kornblum. Using output directory: /e1/carved-foremost Verbose mode on Using configuration file: foremost.conf Opening /e1/case2/floppycopy.dd. Total file size is 1474560 bytes /e1/case2/floppycopy.dd: 100.0% done (1.4 MB read) A doc was found at: 17408 Wrote file /e1/case2/carved-foremost/00000000.doc ---- Success A doc was found at: 37888 Wrote file /e1/case2/carved-foremost/00000001.doc -- Success A jpg was found at: 76800 Wrote file /e1/case2/carved-foremost/00000002.jpg --Success A jpg was found at: 77230 Wrote file /e1/case2/carved-foremost/00000003.jpg --Success A jpg was found at: 543232 Wrote file /e1/case2/carved-foremost/00000004.jpg -- Success A gif was found at: 990208 Wrote file /e1/case2/carved-foremost/00000005.gif --Success A jpg was found at: 1308160 Wrote file /e1/case2/carved-foremost/00000006.jpg -- Success Foremost is done.
This tool can be instructed to search for any type of file by adding the appropriate header and footer information to its configuration file "foremost.conf." If a file is fragmented, this and other carving methods will only find the first portion of the file since other fragments will not contain the signature header.
Another approach to recovering data is implemented in Lazarus from TCT. Lazarus automatically classifies digital data in the following way:
-
Read a chunk of data (default 1k).
-
Determine if the chunk is text or binary data:
-
If text, attempt to classify it based on its contents (e.g. html).
-
If binary, attempt to classify it using the UNIX file command.
-
-
If chunk was successfully classified, compare it with the previous chunk:
-
If they are the same class, assume they are in the same file.
-
If they are not of the same class, assume they are in different files.
-
-
If chunk was not successfully classified, compare it with the previous chunk:
-
If they are the same type (binary or text), assume they are in the same file.
-
If they are different types (binary or text), assume they are in different files.
-
As with other file carving tools, one of the operative assumptions in this approach is that computers make an effort to save files in contiguous sectors. In this way, Lazarus provides some structure to data on a disk and attempts to reconstruct files fragments in contiguous chunks as shown in Figure 11.9.
Figure 11.9: Lazarus from the Coroner's Toolkit used to classify data on a disk and recover deleted data such as the partial image shown here.
Note that this simple but clever method uses the concepts of comparison and classification described in Chapter 9.
Although certain aspects of UNIX file systems make data recovery more difficult, the use of block groups in UNIX file systems can facilitate data recovery because it causes clustering of data on the disk. For instance, all log files in the directory "/var/log" (but not necessarily its subdirectories like "/var/log/argus") will be stored in the same block group. So, rather than searching all unallocated space on the disk for deleted log entries, digital evidence examiners can focus on unallocated space of that block group. For instance, on one Linux system, the "/var/log" directory has inode number 502952 [Figure 11.10(a)] in block group 31 [Figure 11.10(b)].
Figure 11.10: The Sleuth Kit showing (a) /var/log directory with inode number 502952 (b) information relating to inode number 502952, including the associated block group 31, which can also be obtained using the istat command.
The "Image Details" screen in the Autopsy Forensic Browser gives the following information about block group 31:
Group: 31: Inode Range: 502945 - 519168 Block Range: 1015808 - 1048575 Data bitmap: 1015808 - 1015808 Inode bitmap: 1015809 - 1015809 Inode Table: 1015812 - 1016318 Data Blocks: 1015810 - 1015811, 1016319 - 1048575
The unallocated sectors for just this portion of the disk can be extracted using dls in the Sleuth Kit and then searched for information of interest as shown here:
examiner1% dls -f linux-ext2 /dev/hda2 1016319-1048575 > /e1/block31- unallocated examiner1% strings block31-unalloc | grep "Apr 3" Apr 3 09:54:45 case sshd[792]: Server listening on 0.0.0.0 port 22. Apr 3 09:55:14 case xinetd[806]: START: sgi_fam pid = 1118 from = <no address> Apr 3 10:20:20 case sshd[165]: Could not reverse map address 192.168.0.3. Apr 3 10:20:25 case sshd[165]: Failed password for jay from 192.168.0.3 port 1176 ssh2 Apr 3 10:20:29 case sshd[165]: Accepted password for jay from 192.168.0.3 port 1176 ssh2 Apr 3 10:45:05 case sshd[282]: Could not reverse map address 192.168.0.3. Apr 3 10:45:09 case sshd[282]: Accepted password for jay from 192.168.0.3 port 1177 ssh2 Apr 3 13:23:37 case sshd[765]: Server listening on 0.0.0.0 port 22. Apr 3 13:24:07 case xinetd[779]: START: sgi_fam pid = 1013 from = <no address> Apr 3 13:47:16 case sshd[117]: Could not reverse map address 192.168.0.5. Apr 3 13:47:21 case sshd[117]: Failed password for moe from 192.168.0.5 port 1553 ssh2 Apr 3 13:47:26 case sshd[117]: Failed password for moe from 192.168.0.5 port 1553 ssh2 Apr 3 13:47:30 case sshd[117]: Accepted password for moe from 192.168.0.5 port 1553 ssh2 Apr 3 13:47:32 case sshd[119]: subsystem request for sftp
However, when searching for log files or other digital evidence, keep in mind that swap space may also contain useful data.
11.4.4 Dealing with Password Protection and Encryption
Although a collection of UNIX systems, called a "Beowulf cluster", can be used to attempt to break weak encryption, this approach is rarely effective against strong encryption like PGP. When strong encryption is involved, it is usually necessary to take advantages of weaknesses in the implementation of the encryption program. For instance, files on UNIX machines can be encrypted using the crypt utility as shown here.
% crypt -key 'guessme' < plaintext> ciphertext
However, if the plaintext file is simply deleted rather than wiped, it may be possible to recover this copy from the hard disk. Furthermore, if the plaintext file was stored in memory, swapped to disk, or backed up to external media, it may be possible to retrieve some or all of these data. Another obvious weakness of the crypt command is the secret key. If an easy to remember key such as "guessme" is used, it may be possible for someone to guess it and gain access to the encrypted data. If a difficult to remember key is used, it may be necessary for the user to write it down in a location that can be referenced the next time the data are decrypted, potentially exposing it to others.
When performing a functional reconstruction using a restored clone of a UNIX system, it may be possible to bypass the logon password by booting into single user mode and manually altering the password file. In situations where the actual password is needed, tools like Crack and Jack the Ripper are available that attempt to guess password entries in UNIX password files.
[7]http://www.cgsecurity.orgltestdisk.html
[8]http://www.stud.unihannover.de/user/76201/gpart/
[9]http://lde.sourceforge.net/Ide_use.html
[10]http://recover.sourceforge.net/linux/recover/
[11]Recall that Solaris and ext3 dears the inode number in deleted directory entries and HP-UX deletes the entire entry, eliminating this method as a possibility.
[12]http://foremostsourceforge.net
EAN: 2147483647
Pages: 279