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 for Android: free password hash cracker in your pocket

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

Date: Thu, 29 Apr 2010 08:31:43 +0200
From: wlet@....net
To: Przemyslaw Borkowski <xperience@...eria.pl>
Cc: bugtraq@...urityfocus.com
Subject: Re: STP mitm attack idea

> Disadvantages of method.
> - stops whole traffic beetween switches, and needs delicate timing
> - when link beetween switch 1 and 2 is working we can't see frames that
> flying across wire

The whole Attack is theoretically possible. But only theoretically, because of the point that a flapping link between the two switches will be recognized by other hosts on the switches. That mean either you MitM the whole "interconnection" traffic of the switches or you get caught.
The next point is: By periodically rebuilding the STP tree your're very noisy - the chance that this stays undetected in a monitored environment is very low.

You also need a very good synchronization of the two attacker controlled hosts (start sending when the original interconnection link is back on, stop right before you cut again).

And: The whole attack could be prevented with portfast and BPDU guard enabled.

As a conclusion: Maybe possible, but it would make more sense to ARP-Spoof directly on each switch (I mean you already control a host in the same segment, why making it more complicated) - much easier, pretty straight forward and a lot more quite.

wlet