[unisog] Do Windows file access, file mod, file create timestamps lie?

[Wyman Miles]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



- --On Wednesday, September 19, 2007 1:23 PM -0400 Brian Smith-Sweeney 
<bsmithsweeney at nyu.edu> wrote:

>
>> And this isn't just a Windows issue.  Most OS will cache atime updates
>> for as long as is felt safe.  The effect isn't as dramatic as NTFS, but
>> it's still there.  And if you want a real shocker, mount an OSX volume
>> read-only, root around in it, and check the timestamps.  Then
>> umount/mount it again and breathe easy.
>>
> Yeah this gave us a bit of a jump the other day.  I ended up posting
> about it to the Sleuthkit list and only got a response from one guy
> there.  After looking around for some relevant documentation (and
> finding none) we submitted a bug report to Apple who says they've got an
> engineer working on it.

Yup.  Saw that post.  I ran into it on an analysis once a while back and 
scared myself silly.  I just figured Apple was being irritatingly quirky 
for its own sake.  Bug?  Do they have those?

You can sort of imagine file metadata being cached by the OS but a 
lower-level process is handling the fact that the volume is read-only.

>
> This has some pretty horrific implications for forensics.  Imagine you
> do your analysis, look at some files, and at some point fire off your
> script or Autopsy to generate a file activity timeline for you.  Then
> later you notice modified atimes on files that *should've* been on a
> read-only volume.  Might call into question how well you followed your
> incident response procedure.  I've thankfully never had to testify
> regarding my forensic work, but this seems like the kind of thing that
> would mess with your credibility.

I'd be concerned about forensics tools that were doing that much 
interaction with the operating system of the analysis workstation.  They 
really ought to be reading the underlying filesystem structures right out 
of the image and working from there.  Even more so in the face of something 
like NTFS where you've got two sets of timestamps, resident data, streams, 
and whatnot.  And most filesystem drivers are going to overlook, ignore, or 
behave unpredictably in the face of tampering or damage.  Again, I'd expect 
a forensics tool to raise some objection, show an inconsistency, or note if 
I was using resident data in unused MFT entries to conceal a couple dozen 
megs of data, for example.

We do our analyses under Linux, but I don't trust any Linux NTFS 
implementation to present an accurate picture of the partition being 
analyzed.  Sleuthkit, sure.

>
> Read-only volumes should be read-only.  Representing them otherwise,
> even if you're not actually modifying them, is a Bad Thing.

Write-blockers are your friend.  Cheap insurance that things are as you 
expect.

>
> Cheers,
> Brian
>



Wyman Miles
Senior Security Engineer
Cornell University, Ithaca, NY
(607) 255-8421
-----BEGIN PGP SIGNATURE-----
Version: Mulberry PGP Plugin v3.0
Comment: processed by Mulberry PGP Plugin

iQA/AwUBRvFf+cRE6QfTb3V0EQKQEwCgw1BVxquZ3VuBhKD++cPkKMmT0IUAn2kn
uGZ4IBxelz/e49V7pzom+NZY
=cj+i
-----END PGP SIGNATURE-----