bugtraq - Re: STP mitm attack idea

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <1272565323.22156.11.camel@thinkpad.phocean>
Date: Thu, 29 Apr 2010 20:22:03 +0200
From: Jean-Christophe Baptiste <jc@...cean.net>
To: Joel Maslak <jmaslak@...elope.net>
Cc: Jann Horn <jannhorn@...glemail.com>,
	"bugtraq@...urityfocus.com" <bugtraq@...urityfocus.com>
Subject: Re: STP mitm attack idea

> Portfast modifies STP, it does not disable it. 
Well, right, the interface configured with it goes straight from
blocking to forwarding. You got the idea.

> 
> This does make a good argument for pvst and similar technologies running at the vlan level for enterprise networking. 
I don't see the point. Having one instance of STP per vlan or one for
all, there is no point with the security issue here.

> 
> But it is probably best to assume someone with access to a segment can see everything on that segment, pretend to be anyone else on that subnet, and inject anything onto that subnet. In other words, it is nearly impossible to protect reliability and somewhat privacy on a shared link. 
Of course. It is like an attacker having physical access to a machine.
But it does not mean we shouldn't activate some security features to
make the job harder (and increase the noise in case of an attack).

> 
> On Apr 29, 2010, at 12:19 AM, news <news@...cean.net> wrote:
> 
> > Le mercredi 28 avril 2010 à 18:20 +0200, Jann Horn a écrit :
> >> Am Dienstag, den 27.04.2010, 19:55 +0200 schrieb Przemyslaw Borkowski:
> >>> Second scenario:
> >>> 1. Station C and station D starts to send frames to break link beetween switch 1 and switch 2, and announce non existing connection and switch from C port on switch 1 to D port on switch 2
> >>> 
> >>> A ---- switch 1 --X-- switch 2 ----- B
> >>>          |              |
> >>>          |              |
> >>>          C  --no conn-- D
> >>> 2. Station A sends frame to B
> >>> 3. Frame is forwarded to C station
> >>> 4. Station C stores frame in memory
> >>> 5. After equal timing station C and station D repair link beetween switch 1 and 2
> >>> 6. station C resends stored packet to station D (ie in tunnel or encapsulated in ip packet)
> >>> 7. stations C and D break link beetween switches 1 and 2
> >>> 8. station D sends transmitted packet to station B
> >> 
> >> If you had a WLAN-link, you could simplify that a lot - as far as I
> >> understand, you are able to make the switches redirect the traffic to
> >> your machines.
> >> Anyway, this attack sounds like something a good switch can easily
> >> prevent by having a list of "STP trusted ports" or something like that.
> >> Doesn't that exist?
> > 
> > I think I have heard about this attack before.
> > 
> > Yes, a good admin should set all the port used by machine as portfast
> > (no STP), keeping only the STP on the port attached to network devices.
> > Then the attack would be really too noisy to be successful.
> > 
> > It is also highly recommended to lock down the ports at L2 (port
> > security). Well I hope every one here is doing it, as it can make such
> > attacks really hard.
> > 

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)