Message-ID: <94568D36597F074DBAF976CA2C6CCDCA0120705E@EDM-GOA-EXCC-1A.goa.ds.gov.ab.ca>
Date: Tue Dec  6 23:59:28 2005
From: Mark.Senior at gov.ab.ca (Mark Senior)
Subject: Packet sniffing help needed

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@...ts.grok.org.uk 
> [mailto:full-disclosure-bounces@...ts.grok.org.uk] On Behalf 
> Of Mark Knowles
> Sent: December 6, 2005 09:26
> To: full-disclosure@...ts.grok.org.uk
> Subject: Re: [Full-disclosure] Packet sniffing help needed
> 
> 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.
> 
> > 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)
> 
> > 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)
> 
> > 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 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 :)
> 
> 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.

Powered by blists - more mailing lists