RE: How to track down a wireless hacker

["ep" <captgoodnight () hotmail com>]

> > CG,
> > Pen Testing is not forensics and incident response as much as you would
like this. Forensics and Incident response are the other side of the
argument. As for what I know on forensics, 
> > lets see. I am one of the 14 people with a GIAC GSE level accreditation,
co-author of a forensic book and about 20 peer reviewed published papers.
Oh, also post grad law and 15+ years 
> > experience in digital forensics (21 security).
> > As for Honeynets - I have run several.


I will simply state that I work as a security engineer (yeah one of those).
I help run a large multi-continent honeynet, conduct pentests and
stress/break corporate IT/DR policies for a living. I have been doing so for
sometime now. I too have some high end rare certifications and educations of
which due to general conduct I would feel embarrassed to gratuitously list
them in a signature or mention them in a paragraph. I guess it's a
nature/nurture thing. 

> From the experiences of pentesting and auditing IT/DR policies I have
realized corporate digital forensics and incident response are indeed
closely interwoven with pentesting.
The very security applications and policy practices that we're trying to
defeat or dodge or for that matter using to do so are examples of companies
efforts in digital forensics and incident response. Be it policy, the custom
security code of the NSO/admin or the latest bells and whistles sec product.
To continue defeating and furthering those technologies and practices as
they evolve we have to enlist in digital forensics (just another word for
obsession really) and incident response. I'm sorry but digital forensics in
the field I work in isn't defined by the textbook definition nor by law
procedures. It's also not surprising that the creators of one of the most
powerful exploiting/pentesting frameworks/tools also contributes to
antiforensics http://www.metasploit.com/projects/antiforensics/. Pssst,
here's a not so secret, coders know a little about digital forensics, just
look at today's malware and botnets. I agree to disagree with you, I'm happy
with that. Lets drop this tangent as it will go nowhere, seeing as we don't
share an environment.

 
> > You state:
> > "Once an ATTACKER steps past the authentication/authorization border
he/she loses all rights of expected privacy on that network. As well,
entrapment (4th amendment) applies to law 
> > enforcement ect..., which I'm not."
> > I find your lack of understanding of legal issues problematic. There is no
relation to the 4th amendment and these actions. Neither did I mention
entrapment. An attacker does not lose 
> > any rights. There is no legal recourse to attack back or retaliate. As
much as you may not like it - this is how it works. Further, the attack may
originate from an innocent 3rd party. >>The law does not work on the
principle of an eye for an eye.


Entrapment is one of the usual ill conceived issues with running a honeynet.
This is the card defendants can play when faced with digital evidence taken
from a compromised honeypot. You should have made that connection. From what
I understand entrapment in the US is strictly reserved to government. And if
I remember right, entrapment has oh just a little todo with the 4th
amendment. Please correct me if I'm wrong, I'm certainly not a lawyer; we
rent those. I mentioned entrapment because that's the only thing I could
possibly imagine being a issue in using a honeycookie for the OT, since the
suggestion is basically just another honeynet, isn't it? 

I got on the legal topic because well, you jumped on my back over this
attacking back, retaliating and eye for an eye nonsense. It's just not part
of the equation, it's strictly about legally collecting information in a
controlled environment. There's NO intention in placing a piece of data on
another's machine that they themselves didn't place there knowingly. By the
way, that's the second time I have said that. Please let it sit.


> > How do you propose to find these leads? You seem to be stating that
placing data somewhere will lead to a capture. Please explain how.
> > I see this as a simple request. I ask you to explain how this will occur.
Let us forget web cookies. You have stated a field in a database, username
and password for instance. Please 
> > explain how this will lead back to the mystery attacker?


Yes, please let YOURSELF get over the idea of a web cookie. Honestly though
I'm confused that you have never heard of the term honeycookie before and
thus twisted it with a web cookie. Or for that matter the legalities of
honeynets as your so akeen to law. Or the general philosophy through
practice of honeynets like the monitoring and controlling involved; thus
feedback. I'm sorry, but come on! You have misunderstood and asked such
questions that I now must question your integrity. Please continue that off
list if you so desire...


> > Or is it that you are proposing that you will sniff traffic and find them
post the event. That you propose making environmental changes that are going
to be noticed?
> > What if the attacker sniffed the network and did not insert anything? What
if they played an inactive role in the attack gathering information and
monitoring traffic flows as occurs in >>most of these cases? What then?  You
have made it sound simple, please elaborate.


Come on! You said you have worked with honeynets before! See ---> "As for
Honeynets - I have run several" Craig, I don't believe you.

Wireless honeynet example.
If the attacker whacks my wpa or wep then he understands cowpatty, aircrack
ect. That's a testament to his skillset. I then can safely assume he will
use kismet, cain, ettercap or something of the like to capture packets, i.e.
usernames and passwords - honeycookie (your own words "What if they played
an inactive role in the attack gathering information and monitoring traffic
flows as occurs in most of these cases? What then?"). I'm banking on the
attacker to later use those credentials from a illegal/legal gateway or
system to a different honeypot I own that's facing the internet. I want that
attacker to make that other honeypot his safe and secure home - to a limit.
This way I can track him and learn more about his habits and locations. Once
he has set up shop in my home I will then give him all kinds of enticing
things to keep him around, say a supersecrets.txt file with other
credentials to other honeynets I control or a mysql dump full of trackable
false credit card numbers or maybe he'll set up a emech session so I can
track his/crew botnet habits, or yet again another variation of the webmin
exploit lol. Really it's endless in such a controlled environment. From the
wire to the mind I want to know as much as I can about that attacker and
what makes him unique. I want a omnipotent relationship with that attacker.
That's how to track down a wireless hacker. That's just common honeynet play
man. If you propose that's fantasy, I suggest you actually run a large scale
honeynet project for a living and see what kinda things you can net. As for
when to contact the authorities; you'll know.

It absolutely blows my mind how intuitive skepticism plays into most of
these replies, actually go out and study/research/perform this stuff will
ya. Do yourself a favor and answer your own pointed, dare I say ignorant
questions.

http://www.wardriving.com/
http://www.honeynet.org 


I'm done, really. 

cg








----------------------------------------------------------------------------
----
From: ep [mailto:captgoodnight () hotmail com]
Sent: Fri 9/11/2007 9:24 PM
To: Craig Wright
Cc: pen-test () securityfocus com
Subject: RE: How to track down a wireless hacker


> > > "Ah, if only all pentesters were also honeynet admins, /sigh"
> > First, pen-testing is function of testing, not forensic analysis and
incident response.

Pen-testing has all the flavors of forensic analysis and incident response.
It's just the other side of the coin that's usually amiss in practice.

> > How do you propose to track the cookie? Are you making the assumption 
> > that
all attacks will be to a web server? Adding a cookie to a web session is a
valid response, if it is not a web >>session (and I saw nothing to suggest
that this attack on an  internal network was) then it may not be.

It's NOT a web cookie, though in another example it could be and in fact
it's the same functional idea. More specifically it's a username and
password that belongs to (for the sake of the argument) OUR NETWORK, be it
the network the attacker sniffed them from after breaking into or the one
he/she would log into later on. That action would be a lead, from there we
could add other ingredients to create more leads... But NEVER would any
piece of data be placed on the attacker's machine that he/she didn't
knowingly place there themselves. May I say dear Craig, that simple fact
pretty much negates your remaining 'reply'. But let's continue.

Once an ATTACKER steps past the authentication/authorization border he/she
loses all rights of expected privacy on that network. As well, entrapment
(4th amendment) applies to law enforcement ect..., which I'm not.

If you are curious to the legalities of honeynets in the US then may I
suggest you visit this site http://www.honeynet.org. Also, please kindly
trim your replies.



------------------------------------------------------------------------
This list is sponsored by: Cenzic

Need to secure your web apps NOW?
Cenzic finds more, "real" vulnerabilities fast.
Click to try it, buy it or download a solution FREE today!

http://www.cenzic.com/downloads
------------------------------------------------------------------------