Home page logo
/

fulldisclosure logo Full Disclosure mailing list archives

Re: info on ip spoofing please
From: "Ian stuart Turnbull" <ian.t7 () hotmail co uk>
Date: Tue, 11 Apr 2006 22:33:15 +0100

Thanks again for an excellent response. All this info is just what I'm after. However, in that TCP sequence attack my original point is still not clear to me. As I understand it he found 2 machines talking to one another, kept one of them busy while spoofing the other one pretending to be the one he was keeping busy. I still don't understand HOW he found these 2 machines conversing in the first place. Surely he wasn;t on the same network? OR maybe that is exactly the answer and he was? Though this is not clear from the text it appears this was an attack from a totally remote city?
It is this that has piqued my interest.

Ian t


From: Brandon Enright <bmenrigh () ucsd edu>
To: Ian stuart Turnbull <ian.t7 () hotmail co uk>
CC: bmenrigh () ucsd edu, full-disclosure () lists grok org uk
Subject: Re: [Full-disclosure] info on ip spoofing please
Date: Tue, 11 Apr 2006 21:23:47 +0000
MIME-Version: 1.0
Received: from mailbox4.ucsd.edu ([132.239.1.56]) by bay0-pamc1-f10.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 14:24:04 -0700 Received: from smtp.ucsd.edu (smtp.ucsd.edu [132.239.1.49])by mailbox4.ucsd.edu (8.13.6/8.13.5) with ESMTP id k3BLNxD5084813(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);Tue, 11 Apr 2006 14:23:59 -0700 (PDT) Received: from moray.bmenrigh.dyndns.org (cpe-72-130-186-31.san.res.rr.com [72.130.186.31])by smtp.ucsd.edu (8.13.6/8.13.4) with ESMTP id k3BLNlhp071406;Tue, 11 Apr 2006 14:23:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1])by moray.bmenrigh.dyndns.org (Postfix) with ESMTP id C6EFC1EE89E;Tue, 11 Apr 2006 21:23:47 +0000 (UTC)
X-Message-Info: JGTYoYF78jEHjJx36Oi8+Z3TmmkSEdPtfpLB7P/ybN8=
References: <BAY112-F317806DFA70F524FB8414599CD0 () phx gbl>
X-Mailer: Evolution 2.4.2.1 X-Greylisting: NO DELAY (Trusted relay host);processed by UCSD_GL-v2.1 on mailbox4.ucsd.edu;Tue, 11 April 2006 14:24:00 -0700 (PDT)
X-MailScanner: PASSED (v1.2.8 73305 k3BLNxD5084813 mailbox4.ucsd.edu)
Return-Path: bmenrigh () ucsd edu
X-OriginalArrivalTime: 11 Apr 2006 21:24:04.0982 (UTC) FILETIME=[429B8960:01C65DAE]

On Tue, 2006-04-11 at 21:54 +0100, Ian stuart Turnbull wrote:
> Excellent response Brendon. Thanks heaps.
> I was reading the infamous Markoff / Tsutomu Shimomura attack at
> http://www.totse.com/en/hack/hack_attack/hacker03.html
>
> and I guess I assumed that as they did not know each other personally then
> Markoff must have found a way to locate 2 computers conversing with each
> other randomly? Perhaps this assumption was not correct?
> Though from the test it appears Markoff DID find a way of doing this - ie, > finding 2 computers talking to each other NOT on his own LAN / network???
>

The attack you are referring to is known as an TCP sequence prediction
attack.  This sort of attack is not realistic with modern operating
system and TCP/IP stacks because they are careful to prevent predictable
TCP sequence numbers.

If you are curious how easy or hard a sequence attack against a machine
is, using Nmap with -O and -v you can have Nmap check the sequence
numbers and categorize them to some extent.

The output of a Windows XP machine (with either MS05-019 or SP2) looks
something like:

TCP Sequence Prediction: Class=truly random
                         Difficulty=9999999 (Good luck!)
IPID Sequence Generation: Incremental

Conversely, the Windows 98 stack has a difficulty of 1 (by Nmap
standards) which would make a sequence attack very possible.

Reasonable ingress and egress filtering coupled with modern TCP/IP
stacks makes sequence prediction attacks totally infeasible.

Brandon

--
Brandon Enright
Network Security Analyst
UCSD ACS/Network Operations
bmenrigh () ucsd edu


>
> >From: Brandon Enright <bmenrigh () ucsd edu>
> >
> >On Tue, 2006-04-11 at 20:37 +0100, Ian stuart Turnbull wrote:
> > > Hello all,
> > > At
> > >
> >http://www.iss.net/security_center/advice/Underground/Hacking/Methods/Technical/Spoofing/default.htm
> > >
> > > was this comment :-
> > >
> > > QUOTE "
> > > Examples of spoofing:
> > >
> > > man-in-the-middle
> > > packet sniffs on link between the two end points, and can therefore
> >pretend
> > > to be one end of the connection "
> > >
> > > My question is How can you sniff packets on a link that your machine is
> >NOT
> > > on ie NOT on the same subnet??
> > >
> > > Why am I at a loss to understand this. Is there a command/software that
> > > allows one to
> > > say: sniff packets on port x of IP xxx.xxx.xxx.xxx ?
> > >
> > > Please put me out of my agony on this.
> > > Thanks for any info you can give.
> > >
> > > Ian t
> > >
> >
> >In general you can not arbitrarily monitor the traffic of any random
> >host.  If the host you are trying to attack is not relatively local
> >there is little to no chance you'll be able to sniff the traffic.
> >
> >For more local hosts though, if you can directly influence the network
> >devices separating you from your victim there is a chance you will be
> >able to redirect traffic for an attack.
> >
> >The two more common methods for performing MITM attacks are ARP spoofing
> >and Spanning Tree spoofing.  Several tools can perform ARP poisoning
> >(ettercap comes to mind).  There is an excellent overview of attacks
> >with Spanning Tree in Cisco's _Network Security Architectures_ (ISBN:
> >1-58705-115-X).
> >
> >If you goal isn't to modify the stream for a MITM attack but just watch
> >the traffic, CAM table flooding can reduce the switch/vLAN to the
> >behavior of a hub.
> >
> >For a discussion of all of these attacks see
> >http://www.rootsecure.net/content/downloads/pdf/layer2sniffing.pdf
> >
> >All that being said, it still may not be possible to manipulate the
> >network in any useful way. Cisco and other vendors have mechanisms that
> >can be turned on for most of their devices that detect and prevent many
> >or all of the above attacks.
> >
> >For those with Cisco devices looking to protect against said attacks,
> >limiting the number of MACs per port and turning on BPDU Guard
> >(http://www.cisco.com/warp/public/473/65.html) is typically all that
> >needs to be done.
> >
> >Regards,
> >
> >Brandon
> >
> >--
> >Brandon Enright
> >Network Security Analyst
> >UCSD ACS/Network Operations
> >bmenrigh () ucsd edu
> >
>



_________________________________________________________________
The new MSN Search Toolbar now includes Desktop search! http://join.msn.com/toolbar/overview

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]