full-disclosure - How we caught an Identity Thief

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <200602201816.k1KIG4Ln011824@turing-police.cc.vt.edu>
Date: Mon Feb 20 18:16:18 2006
From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks@...edu)
Subject: How we caught an Identity Thief 

On Mon, 20 Feb 2006 12:22:35 EST, Babak Pasdar said:

> I would just like to ask you and others not to make presumptions about
> our preparedness, the intelligence of our consultancy, our script
> writing capabilities or the depth of our team, since I did not emphasize
> or define those things in the story.

You may not have "emphasized", and you may not have thought you "defined", but
between the story and your reply, you left enough info lying around for people
to figure things out....

The nasty thing about information leakage is that you usually don't even know
it's happening.  For instance, *YOU* said: "I had to get back to our office
from the client site over an hour away" as a partial explanation of why something
took hours. Now, this has 3 possibilities: (1) It's a lie to cover up an even
more lame reason for it taking hours, or (2) the company was stretched too thin
and didn't *have* anybody else qualified to do basic incident response and recon,
or (3) your company in fact had others available, but didn't give a shit and didn't
bother dispatching anybody else until you got to the office.

This sort of stuff is why back in 1977, the designation of information as
"sensitive but unclassified" was devised - to cover the case of data that seems
innocuous, but can be combined with other data to infer secret data (for
instance, figuring out how many big IRIX systems SGI sold to the NSA and DoD
by looking at their total sales, the systems listed on the Top500 list, and
looking for discrepancies...)

Obligatory security tie-in:  Kevin Mitnick's greatest strength was using this
sort of leaked info and leveraging it into a complete exploit.

>                                       I would certainly like to ask you
> not to minimize the time and effort it takes to build a good forensics
> case.

There *is* a certain amount of rigor required in building the case.  However,
it certainly shouldn't take *hours* to do basic recon.  And in fact, if you
take *too* long, this can actually *ruin* your case.  The opposing attorney
can make the implication that during the intervening hours, somebody else had
altered the data - leaving *you* to prove that such a thing didn't happen.

And although it may have been safe to take hours back in 2001, it's certainly
not in 2006 - see Gadi's recent posting on fast-flux attacks for an indication
of what time frame you need to respond in.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20060220/6e696e57/attachment.bin