full-disclosure - Packet sniffing help needed

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]

Message-ID: <4395932E.C1855E10@dessent.net>
Date: Tue Dec  6 13:33:43 2005
From: brian at dessent.net (Brian Dessent)
Subject: Packet sniffing help needed

Mark Knowles wrote:

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

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.

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.

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

Brian