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

click to expand
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.

click to expand
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:

  1. Read a chunk of data (default 1k).

  2. Determine if the chunk is text or binary data:

    1. If text, attempt to classify it based on its contents (e.g. html).

    2. If binary, attempt to classify it using the UNIX file command.

  3. If chunk was successfully classified, compare it with the previous chunk:

    1. If they are the same class, assume they are in the same file.

    2. If they are not of the same class, assume they are in different files.

  4. If chunk was not successfully classified, compare it with the previous chunk:

    1. If they are the same type (binary or text), assume they are in the same file.

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

click to expand
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)].

click to expand
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




Digital Evidence and Computer Crime
Digital Evidence and Computer Crime, Second Edition
ISBN: 0121631044
EAN: 2147483647
Year: 2003
Pages: 279

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net