Full Disclosure mailing list archives
RE: Packet sniffing help needed
From: "Mark Senior" <Mark.Senior () gov ab ca>
Date: Tue, 6 Dec 2005 16:59:13 -0700
If you're asking about how to MITM a conversation without a full compromise of the client, the server, or any intermediate network equipment, it's a bit tricky, but you still have some options. I'd pinpoint DNS as one of the biggest points of vulnerability. - One possibility is DNS cache poisoning of C1's ISP's DNS server, or any server downstream of it on the way to resolving C3's domain name. Protecting yourself against this is supposed to be old, old news, but some estimates I've seen suggest about 20% of the publicly reachable DNS servers out there are vulnerable to cache poisoning. - There' a rather interesting targetted technique that exploits Windows' simplistic DNS client implementation (a nice phrack article at http://www.phrack.org/show.php?p=62&a=3 outlines how it works). The fun part of that one is that you don't even need to know that C1 wants to visit google.com - you just send C1 phony DNS responses for any old hostname, supplying C2's IP address. - There's always the classic domain stealing trick - social engineering C3's domain registrar. You'd think it should be hard, but people keep doing it... Of course, that's likely to get noticed, if anyone reads the web server logs from C3 - all of a sudden every single connection will be coming from C2.
-----Original Message----- From: full-disclosure-bounces () lists grok org uk [mailto:full-disclosure-bounces () lists grok org uk] On Behalf Of Mark Knowles Sent: December 6, 2005 09:26 To: full-disclosure () lists grok org uk Subject: Re: [Full-disclosure] Packet sniffing help needed Hello, please see inline answers :) sorry for the poor 'netiquetteComp1(victim1) = Windows xp box, Connected via dial up toa free ISPComp2(attacker) = windows/*nix, connected via broadbandto differentISP than comp1 Comp3(webserver/victim2) C1< ----- > C3 C2---|Are you asking what's possible or what's easiest? I thinkthat manyreaders 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'sISP'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. Forexample ifyou accessed a standard POP3 or FTP server over an insecureconnection (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 theclient-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 thinkthat yahoodoes this sort of this for its logins, but most sites donot go thisfar, 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 entireconversation,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/_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. _______________________________________________ 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)