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] [thread-next>] [day] [month] [year] [list]
Date: Tue Dec  6 16:26:26 2005
From: ghooti at googlemail.com (Mark Knowles)
Subject: Packet sniffing help needed

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.

> 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)

> 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)

> Of course with SSL/TLS it doesn't matter what the application layer
> does, as the entire conversation is protected from many forms of attack
> (simple snooping, replay, etc.)

I think i am after simple snooping :) - If I have an address say
www.google.com can i snoop every packet that goes to that address,
from other addresses that are not my own, or on my subnet?

> 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 :)

Cheers

M.

> Brian
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ