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]
Message-ID: <20100429063143.13150@gmx.net>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ