Full Disclosure mailing list archives
Re: Packet sniffing help needed
From: Brian Dessent <brian () dessent net>
Date: Tue, 06 Dec 2005 05:33:34 -0800
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 _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- Packet sniffing help needed Mark Knowles (Dec 06)
- Re: Packet sniffing help needed Brian Dessent (Dec 06)
- Re: Packet sniffing help needed Mark Knowles (Dec 06)
- Re: Packet sniffing help needed Joachim Schipper (Dec 06)
- Re: Packet sniffing help needed Mark Knowles (Dec 06)
- Re: Packet sniffing help needed Joachim Schipper (Dec 06)
- Re: Packet sniffing help needed Mark Knowles (Dec 06)
- Re: Packet sniffing help needed Brian Dessent (Dec 06)
- <Possible follow-ups>
- RE: Packet sniffing help needed Mark Senior (Dec 06)