SFS Presentation: Anti-Forensics, December 6, 2004

advertisement
Anti-Forensics
A presentation for SFS
By
Robert Erbes
1
6 December 2004
Overview
•
•
•
•
2
Forensics defined
*nix file systems
Anti-forensics
Anti-anti-forensics
6 December 2004
Forensics
The basics
3
6 December 2004
Forensics Defined
• Forensics is the process of acquiring or
analyzing information to help explain past
events.
– Legal
• For prosecution
– Non-legal (not illegal)
• For information or self-protection
4
6 December 2004
Types of forensics
• Media based
– HDDs, CDs, DVDs, Flash Memory devices, et
cetera
– Live or post-mortem
• Network based
– Network captures, traffic logs, et cetera
– Also live or post-mortem
5
6 December 2004
Media Based Digital Forensics
• The Process
– Capture file system
– Gather data from file
system
– Parse and sort
information into
evidence
– Examine evidence…
6
To Find:
–
–
–
–
Who was involved
What happened
When did it happen
How did it happen
6 December 2004
*nix File System
An overview for those not familiar
7
6 December 2004
Generic *nix filesystem
• Data on disk broken up into two types:
– Meta-data
– Data
• Files are stored on data blocks
– Consist of a group of sectors
– Smallest unit available to OS
– Data blocks stored on disk as an array, and referenced
by their offset within the array
– Bitmap of allocated and free blocks stored in “block
bitmap”
8
6 December 2004
Generic *nix filesystem
• Data blocks are organized into files by
inodes
– Generally one inode for each unique file
• Each inode has:
– An array of block pointers
• Which may point to other arrays of block pointers
– Other information
• GID, UID, MAC times, D time, permissions, file
size, et cetera
9
6 December 2004
Generic *nix filesystem
• Inodes also stored in an array called the
inode table
– Refered to by their 0-based index within the
table
• State of inode (allocated or free) stored in
“inode bitmap”
10
6 December 2004
Generic *nix filesystem
• Filenames associated with inodes by directory
entries stored in directory files
• Basic structure of directory entry:
Struct dirent {
int
inode;
short rec_size;
short name_len;
char file_name[name_len];
};
11
6 December 2004
Generic *nix filesystem
• When a file is deleted:
– Inode within dirent is set to 0
– Rec_size of previous directory entry is grown to
encompass deleted dirent
– Filename of deleted file still remains
• Directory entries are organized in a tree, up to the
root directory, “/”, which is always associated with
the 2nd inode, so that the kernel can locate and
mount the file system.
12
6 December 2004
Generic *nix filesystem
• Every time a filename is linked with an
inode, a counter within the inode is
incremented.
• Every time a link is removed, the counter is
decremented
• When the counter reaches 0, the file has
been deleted, and resources can be freed by
marking appropriate bitmaps
13
6 December 2004
Generic *nix filesystem
• Information on how many inodes and
blocks exist, the locations of the inode and
block bitmaps, and a lot of other data are
kept in the super-block, which is stored in a
known location.
• When the kernel mounts a drive, it looks at
this super-block to help determine how to
work with the drive.
14
6 December 2004
Specific Forensic Gathering
• Forensic analysts look at “deleted” files by
looking at blocks pointed to by unallocated
inodes that have their internal link counter
set to 0.
• Analysts can also look within the directory
entry structures to find names of deleted
files.
15
6 December 2004
Anti-Forensics
“The attempt to mitigate the quantity
and quality of information that an
investigator can examine.”
16
6 December 2004
Methods
•
•
•
•
17
Prevention of access to media
Prevention of data gathering
Prevention of data parsing
Prevention of examination
6 December 2004
Access to Media
• Physical access … is total access
– Many programs exist to automatically eradicate
drives at the push of a button (or diskette)
– Physical destruction of media
• Sometimes not enough, but it’ll make an
investigator think twice about spending the money
18
6 December 2004
Remote access
• Little can be done to prevent investigator
gaining file system access
• So focus on the other aspects of forensic
investigation:
– Data gathering (destruction of data)
– Data parsing (proprietary file formats/systems)
– Evidence examination (encryption)
19
6 December 2004
Data gathering
• Destruction of data
– Most effective against legal forensics
– Usually cannot destroy or erase file system
itself remotely
• Hiding of data
– Cryptography, et cetera
• Putting it where forensic tools don’t shine
20
6 December 2004
Necrofile
• Securely deletes all content on data blocks
pointed to by “dirty” inodes
• “dirty” inodes then re-written as clean
inodes to inode table
• Can work based upon specific time criteria
21
6 December 2004
Necrofile at work
#> ./ils /dev/hda6
class|host|device|start_time ils|XXX|/dev/hda6|1026771982
st_ino|st_alloc|st_uid|st_gid|st_mtime|st_atime|st_ctime|st_dtime|st_mode|\
st_nlink|st_size|st_block0|st_block1
12|f|0|0|1026771841|1026771796|1026771958|1026771958|100644|0|86|545|0
13|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|546|0
14|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|547|0
15|f|0|0|1026771842|1026771796|1026771958|1026771958|100644|0|86|548|0
#> ./necrofile -v /dev/hda6
Scrubbing device: /dev/hda6
12 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
13 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
14 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
15 = m: 0x3d334d4d a: 0x3d334d4d c: 0x3d334d4f d: 0x3d334d4f
#> ./ils /dev/hda6
class|host|device|start_time ils|XXX|/dev/hda6|1026772140
st_ino|st_alloc|st_uid|st_gid|st_mtime|st_atime|st_ctime|st_dtime|st_mode|\
st_nlink|st_size|st_block0|st_block1
#>
22
6 December 2004
Klismafile
• Overwrites deleted directory entries
Work.txt
Evil_code.exe
Evil_code.exe deleted
Work.txt
Evil_code.exe
Klismafile
Work.txt
23
6 December 2004
Klimsafile at work
#> ./fls -d /dev/hda6 2
? * 0: a
? * 0: b
? * 0: c
#> ./klismafile -v /mnt
Scrubbing device: /dev/hda6
cleansing /
-> a
-> b
-> c
Total files found:
6
Directories checked: 1
Dirents removed :
3
#> ./fls -d /dev/hda6 2
#>
24
6 December 2004
Data Hiding
• More of an analysis mitigation than
gathering
• Cryptography, steganography, et cetera
• And actual hiding…
25
6 December 2004
RuneFS
• Runefs stores files on blocks it assigns to
the bad blocks inode (inode 1 in ext2)
• Some forensic programs specifically do not
look at the bad blocks inode
• It’s a small oversight, but a significant one
• Later versions of runefs also encrypt
26
6 December 2004
Data Parsing
• Custom file systems
• Custom file formats
• Burneye
– Alters executable to encrypt true purpose
– Used in break-in of Debian project servers Nov
2003
27
6 December 2004
Evidence Analysis
• Encryption
• Modification/deletion of logs
• Modification/deletion of MAC times
28
6 December 2004
Anti-Anti-Forensics
• Information the whole battle
• If they can’t touch it, they can’t do anything
– Possibly keep a write-only inode log off-line,
along with other system logs
• Burndump, blindeye
• More work for next semester
29
6 December 2004
Some Sources
• Phrack Inc., “Defeating forensic analysis on
Unix” an intro to The Defilers Toolkit
• Debian News, “Debian investigation report
after server comprimises”
30
6 December 2004
Questions
?
31
6 December 2004
Download