[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Full-disclosure] info on ip spoofing please



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???


From: Brandon Enright <bmenrigh@xxxxxxxx>
To: Ian stuart Turnbull <ian.t7@xxxxxxxxxxxxx>
CC: bmenrigh@xxxxxxxx, full-disclosure@xxxxxxxxxxxxxxxxx
Subject: Re: [Full-disclosure] info on ip spoofing please
Date: Tue, 11 Apr 2006 20:42:21 +0000
MIME-Version: 1.0
Received: from mailbox4.ucsd.edu ([132.239.1.56]) by bay0-pamc1-f1.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 13:42:37 -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 k3BKgWM2066017(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);Tue, 11 Apr 2006 13:42:33 -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 k3BKgLci061774;Tue, 11 Apr 2006 13:42:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1])by moray.bmenrigh.dyndns.org (Postfix) with ESMTP id 982551EE4DB;Tue, 11 Apr 2006 20:42:21 +0000 (UTC)
X-Message-Info: JGTYoYF78jEHjJx36Oi8+Z3TmmkSEdPtfpLB7P/ybN8=
References: <BAY112-F8AAC63A6AF32C102B39D099CD0@xxxxxxx>
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 13:42:34 -0700 (PDT)
X-MailScanner: PASSED (v1.2.8 38349 k3BKgWM2066017 mailbox4.ucsd.edu)
Return-Path: bmenrigh@xxxxxxxx
X-OriginalArrivalTime: 11 Apr 2006 20:42:37.0761 (UTC) FILETIME=[781BBB10:01C65DA8]

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@xxxxxxxx


_________________________________________________________________
Be the first to hear what's new at MSN - sign up to our free newsletters! http://www.msn.co.uk/newsletters

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