Keylogers

[Mike Acker]

On 14:59, Robert J. Hansen wrote:
> On Wed, 27 Apr 2011 12:56:19 -0400, Mike Acker <Mike_Acker at charter.net>
> wrote:
>
>> > This is why we need the Software Audit Tool I've discussed at times on
>> > various boards.  The Software Audit Tool will need to be on a separate,
>> > read-only, bootable media such as a DVD.  On boot-up it would mount the
>> > C: drive of the target system and then pull a software inventory. When
>> > complete this inventory would be audited, checking the data-time stamp
>> > and CRC of every executable software in the inventory.  This would be
>> > checked against OEM specifications and system owner's noted.  System
>> > Owners Notes should specify: what packages are supposed to be on this
>> > system.
> Already exists: a copy of md5deep and the forensics signature database
> will do it for you.
>
> Unfortunately, as people have learned, this technique doesn't actually
> work -- at least, not reliably.  False positives abound all over the place.
> The problem is the signature db: it simply cannot work the way people
> think it should.  Some system patches use data from the host system as part
> of the patch.  (As an example, your processor ID might be used as a unique
> identifier somewhere within the code.)  This means the updated executables
> will not have a reproducible hash: each machine will report a slightly
> different one.
>
> You can get around this somewhat with fuzzy hashing, but in the main this
> is an unresolved problem in computer forensics.  You can easily tell when a
> file is known-good, but just because a file isn't on the known-good list
> doesn't mean it's bad -- and telling the bad apart from the good is a
> Herculean task.
>
> My next door neighbor (okay, so he lives a block away) is pretty big in
> the digital forensics community: if you like, I'd be happy to ask him about
> the latest research in this the next time we go out for beers (probably
> Monday, to celebrate his Sunday marathon).
>
>
>
I had worked with Wolfgang Stiller's program on DOS systems earlier.  
and yes:  it did create false positives. and it is easy to see how some
practices in software  distribution and maintenance will tend to create
these false positives.

in view of the need however it is and has been my feeling that this is a
topic that needs to be pursued although I do not see is successful
solution as probable without direct vendor support.  particularly in the
software inventory listings.

we shoud recognize that this inventory process is most critical for the
operating software itself: the software that is allowed to run in RING0.

In a properly secured O/S an application program can't do any damage to
its host O/S.  with this in view we can take a limited approach to the
project at the start and expand it to cover application software where
vendors agree to sign on.

at all times it will be important to keep the objective in mind: we want
to certify the operating software on a selected computer system so that
we can be assured that our Encryption Software -- PGP, HTTPS, S/FTP &c
-- will be successful.

With that in mind, one element that will be needed it the System Owners
Notes. e.g. VERIFY SYSTEM C:\  as Windows7, x64, Home Premium, SP1.

Given cooperation from the OEM has provided a list of what we ought to
find, and where, we should be able to certify the system.

I would like to see MSFT convert their MSRT to perform this function. 

The OEM Inventory could be obtained safely from a download using an
S/FTP connection.

So this is what I see -- as the start.

Notes
(1) modifying a load module after compilation is considered extremely
bad practice. if anyomne gets caught doing this during an install
process they need to go to the shed.



-- 
/MIKE

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20110428/28775c6e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 292 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20110428/28775c6e/attachment.pgp>