Message-ID: <20051206170944.GA12293@melpomene.jschipper.dynalias.net>
Date: Tue Dec  6 17:09:56 2005
From: j.schipper at math.uu.nl (Joachim Schipper)
Subject: Packet sniffing help needed

On Tue, Dec 06, 2005 at 04:26:19PM +0000, Mark Knowles wrote:
> Hello, please see inline answers :) sorry for the poor 'netiquette

> > > Comp1(victim1) = Windows xp box, Connected via dial up to a free ISP
> > > Comp2(attacker) = windows/*nix, connected via broadband to different
> > > ISP than comp1
> > > Comp3(webserver/victim2)
> > >
> > > C1< ----- > C3
> > >
> > > C2---?
> >
> > Are you asking what's possible or what's easiest?  I think that many
> > readers of this list could come up with dozens of various plans, ranging
> > from relatively straightforward (compromise the target's computer
> > through a browser vulnerability then install tcpdump/dns
> > redirection/keylogger/etc) to the absurd (gain 'enable' access to C1's
> > ISP's core routers through vulnerabilities or social engineering).
> > Without more specifics or information it's kind of an open-ended
> > question.
> >
> 
> Neither i think.  I understand that if my machine,  the server,  or
> any intermediate gateway
> has been compromised so that it does things other than the intended
> set up of the admin (as in has been rooted - if that a word?) then any
> information i send will go to a third party.

'Rooted' is commonly used as a verb, so let's go with the flow.

> > As far as warnings go..
> >
> > That also depends on the details of the application.  For example if you
> > accessed a standard POP3 or FTP server over an insecure connection (i.e.
> > any connection) then your username and password are flying out in plain
> > sight in cleartext.  The attacker doesn't really have to do anything
> > special to obtain them once he has the packets.
> >
> 
> This is what i wanted to know - how can an attacker capture this plain
> text? all the articles i have read about arp poisoning indicate that
> you need to be on the same network.  At the moment with my standard
> unencrypted packets how easy is it for an attacker to see the results
> - i.e. how could someone see that I googled "fish for tea" without
> server compromise. I know there iwill be a lot of data to be sifted
> through, but that's what machines are for, right? (security obscurity
> n all that jazz)

Sniffing requires the attacker to have some access; it is not possible
to directly sniff your traffic from, say, my computer. However, the
traffic will be routed over a lot of lines, some of which may not be as
you expect. Do a traceroute ('tracert' on Windows is the closest
equivalent) to see the routers in between - you entrust your data
security to all of them (and possibly a couple more, in the case of
multipath routing, routers failing - which will cause a new route to,
say, www.google.com to be established - and the like).

Additionally, people on your LAN are likely able to get to the data with
some monkeying.

> > On the other hand if a (non-https) web page has a login that uses
> > password hashing with proper salting, implemented on the client-side
> > (i.e. using javascript in the browser) then even if the attacker
> > captured the entire conversation it would not give him enough
> > information to be able to steal the credentials.  I think that yahoo
> > does this sort of this for its logins, but most sites do not go this
> > far, and just send username and password completely in the clear as form
> > fields.
> >
> 
> Just as a side note - with JavaScript i disagree with this. If i can
> recover the JavaScript that encrypts and salts then i have a very good
> chance of brute forcing idiots accounts. - even some smart people - it
> all depends on the server side implementation(although this is not
> what im asking nor what i am trying to do)

A proper server-side implementation will not allow the client to choose
the salt, which makes such an attack decidedly nontrivial.

> > But here again the world is not
> > perfect, because an attacker can still proxy the entire conversation,
> > inserting his own certificate in place of the one that the remote server
> > presents.  This certificate will not be valid since it won't have a
> > trusted CA signature (or if it did it would not match the domain of the
> > site) and any browser will pop up a warning about this certificate
> > before continuing.  But if the user dismisses this warning without
> > reading it then the attacker essentially has everything, and the session
> > is no more secure than the non-encrypted http session.  In this example
> > the warning was critical, and ignoring it breaks the entire security
> > model.

> Yep I agree - I am just interested in how I could sniff traffic from
> my dial up account talking to google, without being on the same
> network :)

This would require compromising some router, the host you are talking
to, or just manipulating the routing tables in a smart way.

All that is possible. But it is very likely easier to compromise the
Windows XP machine, if someone is after you specifically or has built a
tool to sniff, say, credit card numbers.

		Joachim

Powered by blists - more mailing lists