Date: Tue Apr 11 22:33:25 2006
From: ian.t7 at hotmail.co.uk (Ian stuart Turnbull)
Subject: info on ip spoofing please

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@...d.edu>
>To: Ian stuart Turnbull <ian.t7@...mail.co.uk>
>CC: bmenrigh@...d.edu, full-disclosure@...ts.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@....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@...d.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@...d.edu
>
>
> >
> > >From: Brandon Enright <bmenrigh@...d.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@...d.edu
> > >
> >
>
>

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

Powered by blists - more mailing lists