Re: [Full-disclosure] 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

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

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

Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia -

Relevant Pages

  • system fails to boot after /usr/lib/ file is overwritten
    ... Bus ErrorConnection to tru-sd-comhub closed. ... Connection closed by remote host ... WARNING: forceload of misc/md_trans failed ... WARNING - fatal error from fsck - error 137 ...
  • Re: Merging from Access database on server
    ... What type of connection are you using? ... Are they seeing the SQL warning dialog? ... The database and merge documents are located on a server that ...
  • Re: wireless help
    ... With some Mac and ip list restrict to your user only, ... if the attacker as an ip and a mac but cant use any services ... the victim, the victim, is out, and the attacker can get is connection. ... be encryption like VPN or IPSec, I suspect. ...
  • Re: [Full-disclosure] Packet sniffing help needed
    ... > accessed a standard POP3 or FTP server over an insecure connection (i.e. ... This is what i wanted to know - how can an attacker capture this plain ... > inserting his own certificate in place of the one that the remote server ... But if the user dismisses this warning without ...
  • Netbeans 6und SuSE 10.3
    ... libxcb: WARNING! ... Program tries to unlock a connection without having ... There will be no further warnings about this issue. ...