Toward Secure, Audited Processing of Digital Evidence: Filesystem Support for Digital Evidence Bags...

Toward Secure, Audited Processing of Digital Evidence: Filesystem Support for

Digital Evidence Bags

Golden G. Richard III, Ph.D.Associate Professor, Dept. of Computer Science, University of New Orleans

Co-Founder, Digital Forensics Solutions, LLC

Vassil Roussev, Ph.D.Assistant Professor, Dept. of Computer Science, University of New Orleans

IFIP 2006 / Orlando 2 © 2006 by Golden G. Richard III

Investigatory Process: Needs

Acceptance– Steps and methods are accepted as valid

Reliability– Methods can be proven to support findings

Repeatability– Process can be reproduced by independent agents

Integrity– Evidence is not altered (if at all possible) and can show that it was

not altered (or measure the degree to which it was altered) Cause and effect

– Can show strong logical connections between individuals, events, and evidence

Documentation– Entire process documented, with each step explainable and

justifiable


Careful Documentation is Crucial


Imaging: Documentation

Tools for imaging:– dd / dcfldd– FTK Imager– Other proprietary imaging solutions

Common problem: documentation, including application used to image, hash of copy, etc. is detached from blob of digital evidence


Imaging: Documentation (2)

For dd, likely some handwritten or typed notes For imaging software like the FTK imager, somewhat

better:

Information for DriveImage_F Source: F: Frag count: 5 Frag size: 671088640 Sector count: 12578824 Sector size: 512 Bytes: 6440357888 MD5: 60D4E476A1554293216479B5D837EEC2-end-

Both detached from disk image


Documenting the Analysis Phase

(Again) Handwritten or typed notes Shell logs (e.g., via script) Application audit logs...

Scalpel version 1.53 audit fileStarted at Sun Jan 29 13:43:24 2006Command line: scalpel -c scalpel.jpg.conf c:\128MB.ddOutput directory: C:\Scalpel\scalpel-outputConfiguration file: C:\Scalpel\scalpel.jpg.confOpening target "c:\128MB.dd"

The following files were carved:File Start Chop Length Extracted From00000021.jpg 1817346 NO 3424 128MB.dd00000020.jpg 1816576 NO 4194 128MB.dd00000019.jpg 1790759 NO 4683 128MB.dd


Documenting Analysis (2)

5/6/2004 2:58:07 PM -- FTK Version 1.43 build 04.04.23 Examiner's Machine: Phys Mem: Total: 2,146,287,616 Available: 1,557,483,520 Used: 588,804,096 Virt Mem: Total: 2,147,352,576 Available: 1,976,782,848 Used: 170,569,728 Page File Available: 1,608,339,456 ----------------------------------------------------5/6/2004 2:58:07 PM -- New case started by investigator Golden using FTK version 1.43 build 04.04.23 Case Name: SANSBinaryAnalysis Case Number: 2 Case Folder: c:\sanspractical\SANSBinaryAnalysis Description: Case Log Options: Log case and evidence events: Yes Log error messages: Yes Log bookmarking events: Yes

…Processes to be performed: File Extraction: Yes

KFF (Known File Filter): Yes Entropy Test: Yes Full Text Index: Yes Prerender Thumbnails: Yes Decrypt EFS Files: Yes

……


Better Documentation

To completely document an investigation, need to manually combine notes and logs from many applications

Better: common format for storage of digital evidence, with “internal” audit log

Each application touching digital evidence documents actions, effect on evidence (e.g., creation of new evidence, reads/writes, …)

Ties output of an analysis tool (e.g., a file carver) to original evidence (e.g., disk image)


Better Documentation (2)

Quickly answer questions like:– Which “dd” options were used to create

this disk image?– When I carved files from the 8GB disk

image from the FoMoCo computer, which config file did I use?

– Did I use “quick” mode in application XXX?

Much easier to collaborate on a case


Traditional Evidence Bags and Tags


Digital Evidence Bags

Digital Evidence Bags (DEBs) – Phil Turner, “Unification of Digital Evidence from Disparate

Sources (Digital Evidence Bags),” DFRWS 2005 Goals:

– Common format for storage of digital evidence– Scalable: floppy TBs– For selective capture, documentation of what was captured– Auditable– Teach novice investigators?

DEB Contents:– Bag table of contents– “Blobs” of digital evidence– Tags that describe digital evidence (name/value pairs)– Audit log


More Powerful than Traditional Bags…

Modification (e.g., introduction of new blobs of evidence) + Access to bag contents…

…can be programmatically audited DEB’s audit log stores info about:

– Application that created the bag– Investigators who “touched” the bag– Which applications accessed DEB contents– How the applications accessed DEB contents

Optionally, some mechanisms for tamper-proof auditing


DEBs: Standardization of Format

Proprietary formats for storage of digital evidence unacceptable

But goal of this work isn’t to standardize format of DEBs See: previous paper! Working group: Common Digital Evidence Storage

Format (CDESF) See: http://www.dfrws.org/CDESF/ See: “Standardizing Digital Evidence Storage,” CACM

2006 Also see: Security Definition and Exchange Formats

(SecDEF) www.secdef.org forensic format not yet underway Instead, create tentative API for accessing DEBs and

investigate support for legacy apps


An API for DEBs

int CreateDEB( char *filename, char *applicationinfo, char *comment, … /* variable number of DEB tags */ );

int AddDEBBlob( char *filename, char *blobname, void *blob, char *applicationinfo, char *comment );

int AddDEBBlobFile( char *filename, char *blobname, char *blobfilename, char *comment );

int OpenDEBBlob( char *filename, char *blobname, int mode, char *applicationinfo, char *comment );

void CloseDEBBlob( int handle, char *comment ); unsigned long long ReadDEBBlobBlock( int handle,

void *data, unsigned long long len, char *comment ); unsigned long long WriteDEBBlobBlock( int handle,

void *data, unsigned long long len, char *comment );


API (2)

char *GetDEBTagValue( char *filename, char *tagname, char *applicationinfo, char *comment );

int PutDEBTagValue( char *filename, char *tagname, char *applicationinfo, char *comment );

int OpenDEBAuditLog( char *filename, char *applicationinfo, char *comment );

void CloseDEBAuditLog( int handle, char *applicationinfo, char *comment );

int AppendDEBAuditLog( char *filename, char *auditentry, char *applicationinfo, char *comment );


Legacy Application Support for DEBs

Import: Copy DEB into a DEB-enabled filesystem

Currently: DEB “exploded” into a special directory, containing digital evidence blobs + audit logs

Export: Rebuild DEB file from directory Idea: instrument filesystem to automatically

audit actions of DEB-unaware applications Unmodified legacy application accesses

digital evidence as usual, audit logs are updated by filesystem


FUSE

FUSE: Filesystem in USerspacEKernel module…Library…User-level Application…See http://fuse.sourceforge.net for full

details


FUSE (2)

user-definedfunctions for filesystem callbacks

fuse kernel module

user space

kernel space


static struct fuse_operations user_oper={ .getattr = user_getattr, .access = user_access, .readlink = user_readlink, .readdir = user_readdir, .mknod = user_mknod, .mkdir = user_mkdir, .symlink = user_symlink, .unlink = user_unlink, .rmdir = user_rmdir, .rename = user_rename, .link = user_link, .chmod = user_chmod, .chown = user_chown, .truncate = user_truncate, .utime = user_utime, .open = user_open, .read = user_read, .write = user_write, .statfs = user_statfs, .release = user_release, .fsync = user_fsync,};


FUSE (4)

fuse_get_context()->{uid, gid, pid} to obtain info about calling process:struct fuse_context { /** Pointer to the fuse object */ struct fuse *fuse;

/** User ID of the calling process */ uid_t uid;

/** Group ID of the calling process */ gid_t gid;

/** Thread ID of the calling process */ pid_t pid;

/** Private filesystem data */ void *private_data;};

used to peekinto /proc


FUSE (5)

Passed to user-defined open(), read(), write(), etc:struct fuse_file_info {

int flags;

…

…

uint64_t fh;

};

Modify in open() toestablish a uniqueidentifier for streamof operations againsta particular blob ofevidence


Legacy Support: Prototype

Prototype DEB-enabled FS:– Audits modification of structure of DEB

• e.g., introduction or deletion of blobs of evidence

– Adds records to audit log on open/close of individual blobs

• Machine info• Date/time• Command line of opening application• [Hash of opening application]

– Audits read/write operations against individual blobs of evidence: offset, size


Legacy Support: Prototype Overhead

A few simple tests:

Scalpel v1.52 on ext3 FS, no legacy DEB support 3m12s

Scalpel v1.52 on ext3 FS, legacy DEB-enabled FS 3m29s

Table 1. Scalpel JPG file carve on 1GB disk image, 1.6GHz Pentium M T40p Thinkpad with 2GB RAM.

FTK v1.60 Add Evidence on Samba share, no legacy DEB support

47m56s

FTK v1.60 Add Evidence on Samba share, legacy DEB-enabled FS

59m4s

Table 2. FTK Add Evidence processing for 8GB disk image. FTK running on 3GHz Pentium 4 desktop with 15K SCSI disks, 2GB RAM. 8GB disk image served over 100Mb Ethernet by 1.7GHz Pentium 4 A31p Thinkpad with / 512MB RAM.

~9%

~25%


Samba Meets XP

XP issuing two parallel streams of read requests:start = 0, stop = 10723328start = 20971520, stop = 21233664start = 10723328, stop = 10768384start = 21233664, stop = 21282816start = 10768384, stop = 10772480start = 21282816, stop = 21299200start = 10772480, stop = 10833920start = 21299200, stop = 21348352start = 10833920, stop = 10838016start = 21348352, stop = 21364736start = 10838016, stop = 10899456start = 21364736, stop = 21413888...

Breaks sequential access to file, gives misleading view of application behavior


Unimplemented…

(But mentioned in the paper)Secure auditing strategies

– Trickle audit log to trusted, secure server– Use electronic notary service to certify DEB

audit log entries

Goal isn’t to prevent tampering with audit log, but to detect tampering


Legacy DEB Access: Limitations

Audit log is not as tidy as if it were controlled by a compliant application

For Samba mounts, can’t log application name—only know access is via smbd (Samba daemon)

Still, useful as legacy applications are modified to use common DEB formats

Strange: Samba access under WinXP is issuing parallel, non-overlapping streams of reads, even for strict sequential file access

Buffered I/O


Conclusion

Open standard for storage of digital evidence is a good thing

Proprietary/undocumented formats unacceptable! Tightly binding the audit log with the blobs of digital

evidence:– Helps investigator document investigation– Assists with maintenance of chain of custody info– Potentially useful for training new investigators

Possible to support legacy applications, FUSE-based prototype illustrates this

Use of a high-level API for accessing DEBs is better


Future

Working with group developing DEB format standard

Graduate student already enslaved to do full implementation

More work on secure auditing?– Is this worth the trouble?

Better performance study once code is less crusty

Presentation available @

http://www.digitalforensicssolutions.com/IFIP2006.ppt

[email protected]

[email protected]

?

Toward Secure, Audited Processing of Digital Evidence: Filesystem Support for Digital Evidence Bags...

Documents

Transcript of Toward Secure, Audited Processing of Digital Evidence: Filesystem Support for Digital Evidence Bags...