Full Disclosure mailing list archives
Re: Packet sniffing help needed
From: Joachim Schipper <j.schipper () math uu nl>
Date: Tue, 6 Dec 2005 18:09:45 +0100
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 _______________________________________________ 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)