o be strictly accurate the malefactor may not have to spoof the IP address (although if you're protected by a decent firewall then this should police the IP address) but they would have to get the TCP sequence correct (the TCP application on the host doesn't look at the IP Address), however, TCP sequence number prediction isn't easy if you can't sniff the traffic. It is possible to predict the sequence number with some IP stacks...as purportedly demonstrated by Kevin Mitnick... but in this instance he inititated the TCP connection with a spoofed IP Address and then used an unspoofed source IP for the next packet (predicting the initial sequence number from the other end) while at the same time preventing the real host at the spoofed address upsetting matters with a RST (by occupying it with a SYN flood) In the case described the malefactor doesn't know how many packets have been exchanged and, therefore, cannot predict the sequence... er... so we're back to what David just suggested in that they would need to be sniffing the traffic (they could reside at either location, or perhaps be sniffing the traffic en route)...as a matter of interest does anybody know whether MS stacks have incorporated protection against ISN prediction? If your site is protected by a stateful firewall (or even a NAT device or proxy) then it seems likely that any session will timeout in a shorter period (dependant upon the settings in the device) The risk is that you will have: 1. A hole punched through your firewall for the source IP/port + target IP/port (until the firewall times it out) .....maybe a DOS attack on your host will be possible 2. An opportunity for someone who has sniffed the traffic to take over the connection either locally (using the sequence number) or remotely if they can get through the firewall (maybe using the original source IP as suggested...but they would either have to own that address or disable whatever does own it...to prevent a RST) ....could they then potentially masquerade as your messenger friend? (does yahoo encrypt the communication?) If the intention is to masquerade as your friend would it be easier to try to crack his/her password? (I have no idea how difficult that would be) -----Original Message----- From: David Gillett [mailto:gillettdavidat_private] Sent: 13 November 2002 17:35 To: incidentsat_private Subject: RE: Yahoo Messenger Stale Sessions Not so arbitrary. He needs to not only spoof the IP address your friend had, but also get the other port number and the TCP sequence number right. Which might not be much challenge *IF* he was able to sniff your original conversation. (If he's spoofing rather than assuming the address, he'll need to sniff your machine's responses....) That much probably limits it to people within either your, or your friend's, network provider. Then there's the question of what to do with this connection. Is there a vulnerability in Yahoo Messenger that could be exploited from there? (If so, should you be using it at all?) David Gillett > -----Original Message----- > From: Leonard.Ongat_private [mailto:Leonard.Ongat_private] > Sent: Tuesday, November 12, 2002 5:39 PM > To: incidentsat_private > Subject: RE: Yahoo Messenger Stale Sessions > > > Hello All, > > During my observation in daily use of Yahoo Messenger, my > computer has "stale/zombie" sessions. For example, If i have > received/message a friend, yahoo will normally make a direct > connection from my PC to my friend. From Netstat result, you > can see a high port on my computer is having an Established > session with my peer's:5101 port. > > The issue is, after a contact has gone offline (dial-up), the > state established in the netstat will remain until the next > day. I wouls see this as a vulnerabilities, since an > arbitrary user can assume the IP Address was used > (dial-up->dynamic ip assignment), and use this established > session to assume it. > > Any idea ? > > > Regards, > Leonard Ong > Network Security Specialist, APAC > NOKIA > > Email. Leonard.Ongat_private > Mobile. +65 9431 6184 > Phone. +65 6723 1724 > Fax. +65 6723 1596 > > > > -------------------------------------------------------------- > -------------- > This list is provided by the SecurityFocus ARIS analyzer service. > For more information on this free incident handling, management > and tracking system please see: http://aris.securityfocus.com > ------------------------------------------------------------------------ ---- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com ---------------------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Thu Nov 14 2002 - 09:40:28 PST