Re: Changing file times, was -> Re: Trojan of somesort - Update

From: Gadi Evron (ge_at_linuxbox.org)
Date: 05/28/04

  • Next message: Daniel Hanson: "Administrivia: Trojan of somesort - Hack definition branch == dead" 
    Date: Fri, 28 May 2004 20:23:12 +0200
To: Harlan Carvey <keydet89@yahoo.com>

    > Just b/c something *can* happen, doesn't mean that it
    > *does* happen.

    Absolutely. That is how the world of security is built.

    We need to make three distinctions:
    1. If it *can* happen, we need to be prepared for it.
    2. Do we have an adversary smart enough, determined enough and
        resourceful enough to be innovative?
    3. Cost vs. benefit. Would it be worth it or even needed to invent new
        tools or even use them on a target, depending on the target? (on both
        ends, the attacking and defending/forensic).

    What I am saying is, that unlike usual security cost vs. benefit/risk
    vs. gain situations with targets, resources, and how much you are
    willing to invest to defend/attack, as a person doing forensic work you
    need to take any possibility into account.

    You'd look for what you know might be there, but your analysis should be
    complete, looking for anything and everything - once again, under your
    cost vs. benefit guidelines.

    Changing file dates happened in the past, especially with viruses. I
    can't come up with any example at the moment though so.. don't take my
    word for it.

    >>It's easier on some systems than others, and
    >>practically ridiculous on FAT file systems.
    >
    >
    > To be honest, I'm not aware that there's any real
    > distinction with regards to file system. On both NTFS
    > and FAT, as long as you have write access to the file
    > in question, the file times can be changed. I've
    > demonstrated this time and again, in presentations as
    > well as in my book.
    >
    > If I'm missing something with regards to the
    > distinction with regards to how easy it is to change
    > MAC times on FAT vs NTFS, please let me know.

    The reason I mentioned FAT as an example is because you can find tools
    which will do it for you for many years now. PC Tools, diskedit, etc.
    You don't need to study or check into anything yourself.

    Obviously, once access to a local machine is secured *anything* can be
    done. Regardless, I am not too familiar with NTFS as I didn't get to do
    any forensic work on it and can't comment on it without further study.

    It might be just as easy and I do stand corrected, as it is pointless
    how easy it is once access is gained to a machine, especially locally.
    However, FAT systems have been around for a while.. and come on - it
    doesn't get any easier than that.

    One other thing I always look for is inconsistencies and erroneous file
    information. People make mistakes. Finding a windows DLL dated to 1990
    or a file without a date raises suspicion.

    Which is why I'd like to repeat what you said:
    "When performing incident response and forensics, one should never rely
    on one piece of information/evidence exclusively."

            Gadi Evron. 

    -- 
Email: ge@linuxbox.org.  Work: gadie@cbs.gov.il. Backup: ge@warp.mx.dk.
Phone: +972-50-428610 (Cell).
PGP key for attachments: http://vapid.reprehensible.net/~ge/Gadi_Evron.asc
ID: 0xD9216A06 FP: 5BB0 D3E2 D3C1 19B7 2104  C0D0 A7B3 1CF7 D921 6A06
GPG key for encrypted email: 
http://vapid.reprehensible.net/~ge/Gadi_Evron_Emails.asc
ID: 0x06C7D450 FP: 3B88 845A DF1F 4062 E5BA  569A A87E 8DB7 06C7 D450
  • Next message: Daniel Hanson: "Administrivia: Trojan of somesort - Hack definition branch == dead"