==Phrack Inc.== Volume 0x0b, Issue 0x3d, Phile #0x0c of 0x0f |=---------------=[ Fun with the Spanning Tree Protocol ]=---------------=| |=-----------------------------------------------------------------------=| |=-----------=[ Oleg K. Artemjev, Vladislav V. Myasnyankin ]=------------=| Introduction. *=*=*=*=*=*=* Developed in the 1st part of 80th by International Standards Organization (ISO) seven-layer model of Open System Interconnection (OSI) presents a hierarchical structure, where each level has strictly assigned job & interface to upper & lower levels. Due to business needs modern equipment currently supports on the 2nd OSI layer not only traditional frame forwarding & hardware address resolution, but also provides redundancy, multiplexing, load balancing & separation of information flows. Unfortunately, security issues at this layer are often left without attention. Here we'll show weakness in implementation and algorithm of one of the second OSI layer (``channel'' (MAC+LLC)) protocols - Spanning Tree Protocol (STP). This work uses our materials published in Russian: [2], [4]. Since we're publishing an information about security vulnerabilities before a fix is ready on the market & since these information may be used by a malicious person we'll write our article in such a way, so newbies (also known as ``script kiddies'' or ``black hats'' - see [1]) would be unable to use this paper as a step-by-step ``howto''. We understand that different people have different opinion to this issue, but feel that this is almost single possible way to stimulate vendors to fix bugs much faster. Of course we already notified some vendors (Cisco, Avaya) about these vulnerabilities, but an answer was alike: ``unless this gives money we won't make investments''. Well, since we're interested in high level of security in switches & routers we use, we have to publish our investigations - thus we 'll make some pressure on hardware vendors to implement real security in their devices. Also we note, that vendors should be already informed via bugtraq & some - Cisco & Avaya - directly. Our first publication in Russian concerning STP vulnerabilities was made about one year ago. The volume of our materials written while analyzing STP protocol is too big to be published in one magazine article. Full information is available in the Internet at the project's web page ([3]) and with the same restrictions which apply also to this publication (see license below). License. *=*=*=*= As a complain against trends to inhibit publications of security vulnerabilities in software (these tendencies are widely known to the public as a DMCA law in U$ [Digital Millennium Copyright Act]), these materials are a subject to the following license: -------------------------------------------------------------------------------- License agreement. This paper is an intellectual property of it's authors: Oleg Artemjev and Vladislav Myasnyankin (hereinafter - writers). This paper may be freely used for the links, but its content or its part cannot be translated into foreign languages or included into any paper, book, magazine, and other electronic or paper issues without prior WRITTEN permissions of both writers. Moreover, in case of using materials of this research or refer to it, according given license you must provide complete information: full title, authorship and this license. You can freely distribute this paper electronically, if, and only if, all of the following conditions are met: 1. This license agreement and article are not modified, including its PGP digital signature. Any reformatting of the text is prohibited. 2. The distribution does not contradict the given license. Distribution of this paper in the countries with the legislation containing limitations similar to American DMCA contradicts the given license. At the moment of publication this includes United States of America (including embassies,naval vessels, military bases and other areas of US jurisdiction. Moreover, reading this paper by citizens of such a country violates this license agreement and may also violate their law. Nevertheless, distribution of any links to this document is not a violation of the given license. This paper is provided by the authors ``as is'' and any express or implied warranties, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose are disclaimed. In no event shall the writers be liable for any direct,indirect, incidental, special, exemplary, or consequential damages (including, but not limited to, procurement of substitute goods or services; loss of use, data, or profits; or business interruption). Writers claim this article for educational purposes only. You should not read this paper, if you disagree not to use it any other way. The given license agreement is subject to change without warning in the consent of both writers. -------------------------------------------------------------------------------- What is STP? *=*=*=*=*=*= Main task of STP protocol is automated management of network topology with redundant channels. In general, almost all type of networks are unable to accept loops(rings) in their structure. Really, if network equipment is connected with superfluous lines, then without additional measures frames would be delivered to recipient as a several one - this would result in a fault. But business require redundancy, thus there is an STP - it takes care that all physical loops are logically disabled unless one of lines gives a fault - in this case STP enables line that is currently in reserve. STP should guarantee that at each point of time only one of several duplicate links is enabled & should automatically switch between them on demand (fault or physical topology change). How STP works? *=*=*=*=*=*=*= STP begin its work from building a tree-alike graph, which begins at ``root''. One of STP-capable devices becomes a root after winning elections. Each STP-capable device (it could be a switch, router or other equipment, hereby & later for simplicity called ``bridge'') starts from power-up claiming that it's root one by sending special data named Bridge Protocol Data Unit (BPDU - see [9]) through all ports. The receiver's address in a BPDU packets is a group (multicast) address - this allows BPDUs pass through non-intellectual (dumb) equipment like hubs and non STP-aware switches. Here as we say ``address'', we mean MAC-address, since STP is working at the level of Media Access Control (MAC). Thereby all issues about STP & its vulnerabilities apply equal to the different transmission methods, i.e. Ethernet, Token Ring & others. After receiving BPDU from other device the bridge compares received parameters with its own & depending to result decide to stop or keep insisting on its root status. At the end of elections the device with the lowest value of the bride identifier becomes a root one. The bridge identifier is a combination of bridge MAC address & defined bridge priority. Obviously in a network with single STP compatible device it 'll be a root one. Designated root (or ``Designated Root Bridge'', as named by standard) doesn't have any additional responsibilities - it only used as a beginning point to start building topology graph. For all other bridges in a network STP defines the ``Root Port'' - the nearest to the root bridge port. From other ports connected to the bridge it differs by its identifier - combination of its MAC address & defined for the port priority. The Root Path Cost is also a value meaningful for STP elections - it is being build as a sum of path costs: to the root port of given bridge & all path costs to root ports of all other bridges on the route to Root one. In addition to the ``main'' Root Bridge STP defines a logical entity called ``Designated Bridge'' - owner of this status becomes main bridge in serving of given LAN segment. This is also a subject of elections. Similarly STP defines for each network segment the Designated Port (which serving given network segment) & corresponding to it ``Designated Cost''. After all the elections are finished, network goes into stable phase. This state is characterized by the following conditions: - There is only one device in a network claiming itself as a Root one, all others are periodically announcing it. - The Root Bridge periodically sends BPDU through all its ports. The sending interval is named ``Hello Time''. - In each LAN segment there is a single Designated Root Port and all traffic to the Root Bridge is going through it. Compared to other bridges, it has lowest value of path cost to the Root Bridge, if these values are identical - the port with a lowest port identifier (MAC plus priority) is assigned. - BPDUs are being received & sent by STP-compatible unit on each port, even those that are disabled by STP protocol. Exceptionally, BPDUs are not operationing on ports that are disabled by administrator. - Each bridge forwards frames only between Root Port & Designated Ports for corresponding segments. All other ports are blocked. As follows from the last item, STP manages topology by changing port states within following list: Blocking: The port is blocked (discards user frames), but accepts STP BPDUs. Listening: 1st stage before forwarding. STP frames (BPDUs) are OK, but user frames are not processed. No learning of addresses yet, since it may give wrong data in switching table at this time; Learning: 2nd stage of preparation for forwarding state. BPDUs are processed in full, user frames are only used to build switching table and not forwarded; Forwarding: Working state of ports from user view - all frames are processed - STP & user ones. At time of network topology reconfiguration all bridge ports are in one of three states - Blocking, Listening or Learning, user frames are not delivered & network is working only for itself, not for user. In stable state all bridges are awaiting periodical Hello BPDUs from Root Bridge. If in the time period defined by Max Age Time there was no Hello BPDU, then bridge decides that either Root Bridge is Off, either the link to is broken. In this case it initiates network topology reconfiguration. By defining corresponding parameters it is possible to regulate how fast bridges will find topology changes & enable backup links. Lets look closer. *=*=*=*=*=*=*=*=* Here is a structure of STP Configuration BPDU according to 802.1d standard: ---------------------------------------------- |Offset |Name |Size | ---------------------------------------------- ---------------------------------------------- |1 |Protocol Identifier |2 bytes| ---------------------------------------------- | |Protocol Version Identifier|1 byte | ---------------------------------------------- | |BPDU type |1 byte | ---------------------------------------------- | |Flags |1 byte | ---------------------------------------------- | |Root Identifier |8 bytes| ---------------------------------------------- | |Root Path Cost |4 bytes| ---------------------------------------------- | |Bridge Identifier |8 bytes| ---------------------------------------------- | |Port Identifier |2 bytes| ---------------------------------------------- | |Message Age |2 bytes| ---------------------------------------------- | |Max Age |2 bytes| ---------------------------------------------- | |Hello Time |2 bytes| ---------------------------------------------- |35 |Forward Delay |2 bytes| ---------------------------------------------- In a C language: typedef struct { Bpdu_type type; Identifier root_id; Cost root_path_cost; Identifier bridge_id; Port_id port_id; Time message_age; Time max_age; Time hello_time; Time forward_delay; Flag topology_change_acknowledgement; Flag topology_change; } Config_bpdu; Here is how it look like in a tcpdump: ---------------------screendump---------------------------- [root@ws002 root]# tcpdump -c 3 -t -i eth0 stp tcpdump: listening on eth0 802.1d config 8000.00:50:e2:bd:58:40.8002 root 8000.00:50:e2:bd:58:40 pathcost 0 age 0 max 20 hello 2 fdelay 15 802.1d config 8000.00:50:e2:bd:58:40.8002 root 8000.00:50:e2:bd:58:40 pathcost 0 age 0 max 20 hello 2 fdelay 15 802.1d config 8000.00:50:e2:bd:58:40.8002 root 8000.00:50:e2:bd:58:40 pathcost 0 age 0 max 20 hello 2 fdelay 15 3 packets received by filter 0 packets dropped by kernel [root@ws002 root]# ---------------------screendump---------------------------- And with extra info: ---------------------screendump---------------------------- [root@ws002 root]# tcpdump -vvv -e -l -xX -ttt -c 3 -i eth0 stp tcpdump: listening on eth0 000000 0:50:e2:bd:58:42 1:80:c2:0:0:0 0026 64: 802.1d config \ 8000.00:50:e2:bd:58:40.8002 root 8000.00:50:e2:bd:58:40 pathcost 0 \ age 0 max 20 hello 2 fdelay 15 0x0000 4242 0300 0000 0000 8000 0050 e2bd 5840 BB.........P..X@ 0x0010 0000 0000 8000 0050 e2bd 5840 8002 0000 .......P..X@.... 0x0020 1400 0200 0f00 0000 0000 0000 0000 7800 ..............x. 0x0030 0c00 .. 2. 002912 0:50:e2:bd:58:42 1:80:c2:0:0:0 0026 64: 802.1d config \ 8000.00:50:e2:bd:58:40.8002 root 8000.00:50:e2:bd:58:40 pathcost 0 \ age 0 max 20 hello 2 fdelay 15 0x0000 4242 0300 0000 0000 8000 0050 e2bd 5840 BB.........P..X@ 0x0010 0000 0000 8000 0050 e2bd 5840 8002 0000 .......P..X@.... 0x0020 1400 0200 0f00 0000 0000 0000 0000 7800 ..............x. 0x0030 0c00 .. 2. 046164 0:50:e2:bd:58:42 1:80:c2:0:0:0 0026 64: 802.1d config \ 8000.00:50:e2:bd:58:40.8002 root 8000.00:50:e2:bd:58:40 pathcost 0 \ age 0 max 20 hello 2 fdelay 15 0x0000 4242 0300 0000 0000 8000 0050 e2bd 5840 BB.........P..X@ 0x0010 0000 0000 8000 0050 e2bd 5840 8002 0000 .......P..X@.... 0x0020 1400 0200 0f00 0000 0000 0000 0000 7800 ..............x. 0x0030 0c00 .. 3 packets received by filter 0 packets dropped by kernel [root@ws002 root]# ---------------------screendump---------------------------- Generally the same is achieved by multicast alias of tcpdump syntax (if you 've no other multicast traffic in the target network: ---------------------screendump---------------------------- [root@ws002 root]# tcpdump -vvv -e -l -xX -ttt -c 3 -i eth0 multicast tcpdump: listening on eth0 000000 0:50:e2:bd:58:42 1:80:c2:0:0:0 0026 64: 802.1d config \ 8000.00:50:e2:bd:58:40.8002 root 8000.00:50:e2:bd:58:40 pathcost 0 \ age 0 max 20 hello 2 fdelay 15 0x0000 4242 0300 0000 0000 8000 0050 e2bd 5840 BB.........P..X@ 0x0010 0000 0000 8000 0050 e2bd 5840 8002 0000 .......P..X@.... 0x0020 1400 0200 0f00 0000 0000 0000 0000 7800 ..............x. 0x0030 0c00 .. 2. 004863 0:50:e2:bd:58:42 1:80:c2:0:0:0 0026 64: 802.1d config \ 8000.00:50:e2:bd:58:40.8002 root 8000.00:50:e2:bd:58:40 pathcost 0 \ age 0 max 20 hello 2 fdelay 15 0x0000 4242 0300 0000 0000 8000 0050 e2bd 5840 BB.........P..X@ 0x0010 0000 0000 8000 0050 e2bd 5840 8002 0000 .......P..X@.... 0x0020 1400 0200 0f00 0000 0000 0000 0000 7800 ..............x. 0x0030 0c00 .. 2. 006193 0:50:e2:bd:58:42 1:80:c2:0:0:0 0026 64: 802.1d config \ 8000.00:50:e2:bd:58:40.8002 root 8000.00:50:e2:bd:58:40 pathcost 0 \ age 0 max 20 hello 2 fdelay 15 0x0000 4242 0300 0000 0000 8000 0050 e2bd 5840 BB.........P..X@ 0x0010 0000 0000 8000 0050 e2bd 5840 8002 0000 .......P..X@.... 0x0020 1400 0200 0f00 0000 0000 0000 0000 7800 ..............x. 0x0030 0c00 .. 3 packets received by filter 0 packets dropped by kernel [root@ws002 root]# ---------------------screendump---------------------------- As you see here, normally STP frames are arriving approximately within Hello Time (here is 2 seconds). STP & VLANs. *=*=*=*=*=*= We 'd like to say some words about STP functioning specific to networks with virtual LANs (VLANs). Enabling this mode on a switch is logically equivalent to replacing it with a few (by number of VLANs) switches, even when physically there's no separation between VLANs media. It 'd be obvious to find there different STP trees, but this option is supported by only some equipment(i.e. Intel 460T supports only one STP tree for all VLANs; with Avaya's Cajun switches family you'll find separate Spanning Tree only in high models). These facts are destroying a hope to localize possible STP attacks in one VLAN. But there are threats existing even with separate spanning trees per VLAN. Some vendors realize in their devices extended STP-related futures, enhancing their abilities, like Spanning Tree Portfast in Cisco (see [11]) & STP Fast Start in some 3Com switches (see [12]). We'll show essence of them below. Also, some companies support their own implementation of STP, i.e. Dual Layer STP from Avaya. Plus, STP modifications functioning for other network types (i.e. DECnet). Here we'd like to point on their principle similarity and differ only in details and extended abilities (so, in Avaya Dual Layer STP trees could be terminated at the 802.1q-capable ports). All these implementation suffer from the same defects as their prototypes. Unpublished proprietary protocols give one more problem - only developers could solve their problems, since full reverse engineering (needed to provide good bug-fixing solutions) is much harder then small one required to realize attacks & by publishing results some would make an evidence of reverse engineering, which may be illegal. Possible attack schemes *=*=*=*=*=*=*=*=*=*=*=* An idea of 1st group of attacks lies practically ``on the surface''. Essentially the principle of STP allows easily organize Denial of Service (DoS) attack. Really, as defined by standard, on Spanning Tree reconfiguration all ports of involved devices does not transfer user frames. Thus, to drop a network (or at least one of its segments) into unusable state it's enough to master STP-capable device(s) to do infinite reconfiguration. It could be realized by initiating elections of, for example, root bridge, designated bridge or root port - practically any of electional object. ``Fortunately'' STP has no any authentication allowing malicious users easily reach this by sending fake BPDU. A program building BPDU could be written in any high level language having raw-socket interface (look at C sample and managing shell script at our project home page - [5], [6]). Another way - one may use standard utilities for managing Spanning Tree, i.e. from Linux Bridge project([13]), but in this case its not possible to manipulate STP parameters with values that doesn't fit into standard specification. Below we will examine base schemes of potentially possible attacks. Eternal elections. *=*=*=*=*=*=*=*=*= Attacker monitors network with a sniffer (network analyzer) & awaits for one of periodical configuration BPDUs from the root bridge (containing its identifier). After that he sends into a network a BPDU with identifier that is lower then received one (id=id-1) - thus it has pretensions to be a root bridge itself & initiates elections. Then it decrement identifier by 1 and repeat procedure. Each step initiates new elections wave. When identifier reach its lowest value attacker return to the value calculated at beginning of the attack. As a result network will be forever in elections of the root bridge and ports of STP-capable devices will never reach forwarding state while attack is in progress. Disappearance of root. *=*=*=*=*=*=*=*=*=*=*= With this attack there is no need to get current root bridge identifier - the lowest possible value is a starting one. This, as we remember, means maximum priority. At the end of elections attacker stops sending BPDUs, thus after a timeout of Max Age Time gives new elections. At new elections attacker also acts as before (and wins). By assigning minimum possible Max Age Time it is possible to get situation when all the network will spend all time reconfigurating, as it could be in previous algorithm. This attack may occur less effective, but it has simpler realization. Also, depending to network scale and other factors (i.e. Forward Delay value, that vary speed of switching into a forwarding state) the ports of STP-capable devices may never start forwarding the user frames - so we cannot consider this attack as less dangerous. Merging-splitting of the trees. *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= In a network with VLAN support it may be possible to lunch a modification of discussed above attack by connecting segments with different vlans & STP trees. This may be realized without software, by hands, by linking ports together with a cross-over cable. This may become a pain for NOC, since it's hard to detect. Local Denial of Service. *=*=*=*=*=*=*=*=*=*=*=*=* Attacker may make Denial of Service not for the entire network, but just on a part of it. There could be many motivations, i.e. it may isolate victim client from real server to make ``fake server'' attack. Lets look for realization of this type of attack on example. ---------------------------------------------------------------- .------------------------. .------------------. | Switch w/ STP #1 |-----------------| Switch w/ STP #2 | .________________________. '__________________' | | | | | | .___. | | | | | |..... | ._ | | ==| .------,~ | || | | ==| |Client|' | || \_ | -| | PC || \ |.... | | \------ / '=====| | | ======/ Attackers ------- Notebook Server --------------------------Picture 1----------------------------- On the picture 1 server is connected to one switch & victim is connected to another one (connectivity to the bridge may include hubs). Attacker needs to fool nearest switch & make it think that he(she) has better way to the bridge that serves server computer. In terms of STP, attacker must initiate & win elections of designated bridge for server segment. As a result of winning such elections the channel between bridges would be disabled by setting corresponding ports to the blocked state. By destroying connectivity between segments attacker may either try to fool client claiming itself as a real server (compare with well known Mitnick attack) or just feel satisfied if mischief is a subject. BPDU filter. *=*=*=*=*=*= Obvious way to attack is to set a loop that is undetectable by STP by organizing physical ring with filtering there of all BPDU frames. Man In the Middle. *=*=*=*=*=*=*=*=*= Next two attacks have principal difference from already discussed - the goal of them not to achieve denial of service, but data penetrating, that impossible in the normal network operation mode. In short, this attack uses STP to change logical structure of network to direct sensitive traffic via attacker's station. Let's look at the 2nd picture. ---------------------------------------------------------------- Clients segment Server segment .------------------------. .------------------. | Switch w/ STP #1 |------X X--------| Switch w/ STP #2 | .________________________. '__________________' | | | | | | | | .___. | | | | | | |..... | .------. | | | ==| .------,~ | | | | | | ==| |Client|' | |Attacking ; \_,| -| | PC || \ | PC | / | | \------ / \_========_, / | | ======/ |_________|--------' ------- Server --------------------------Picture 1----------------------------- As against mentioned above partial denial of service attack, suppose that attackers station is equipped with two NICs, one Network Interface Card is connected to the ``client's'' segment, and another - to the ``server's'' segment. By sending appropriate BPDU attacker initiates elections of the designated bridge for both segments and wins them. As a result, existing link between switches (marked as "-X X-" ) will shut down (will switch to the blocking state) and all inter-segment traffic will be directed via attacker's station. If intruder's plans does not include denial of service, he(she) MUST provide frame forwarding between NICs. It's a very simple task if attacker doesn't needed to change traffic in some manner. This may be done by either creating simple program module or using built-in STP functions of the operating system, for example with Linux Bridge Project (see [13]), which contribute complete bridge solution. Of course, an intruder must take in account ``bottle neck'' problem - inter-segment link may work at 100Mb (1Gb) speed while client's ports may provide only 10Mb (100Mb) speed, which lead to the network productivity degradation and partial data loss (but software realization of back pressure shouldn't be a big deal). Of course, if attacker wants to ``edit'' traffic on the fly on a heavy loaded link, he(she) may need more powerful computer (both CPU and RAM). Fortunately, this attack is impossible in networks with single switch - try to realize it in these conditions and you will get partial DoS. Also note, that realization is trivial only when attacker is connected to neighbored switches. If connections are made to the switches without direct link, there is additional task - guessing at least one Bridge ID, because STP-capable devices never forward BPDU, sending on the base of received information its own, instead. Provocated Sniffing. *=*=*=*=*=*=*=*=*=*= In general, sniffing is data penetrating by switching network interface into promiscuous mode. In this mode NIC receives all the frames, not only broadcasts and directed to it. There're well known attack on networks based on switches, these are either poison targets MAC address table by fake ARP replies, either over-full bridge switching table and thus making it behave like a hub, but with splitting collision domains. Almost the same results may be achieved using STP. According specification after tree reconfiguration (for example, after designated bridge elections) STP-capable device MUST remove from the switching table all the records (except those statically set by administrator), included before switch gone into listening and learning state. As a result switch will go into hub mode for some time while it refill switching table. Of course, you already noted weakness of this theory: switch learns too fast. After receiving first frame from victim it writes its MAC address into switching table and stops to broadcast them to all ports. However, we must not ignore this attack. This is because manufacturers include in their products some ``extensions'' to core STP. Just after elections network is unreachable. To reduce down time some manufacturers (Cisco, Avaya, 3Com, HP, etc) include an ability to discard listening and learning states on the ``user'' ports (ports with servers and workstations connected to). In other words, port is switching from ``blocked'' state directly to ``forwarding'' state. This ability has different names: Spanning Tree Portfast (Cisco - [11]), STP Fast Start (3Com - [12]) etc. If this ability turned on, eternal elections would lead not to DoS, but to periodical resets of the switching table, that means hub-mode. Note, that this function should not be turned ON on the trunk ports, because STP convergence (finalization of elections to a stable state) not guaranteed in this case. Fortunately, to achieve its goal an intruder must clear switching table at least two times fast than interesting packets are received, that is practically impossible. Anyway it allows collecting of some sensitive data. Also note, that this attack allows to catch all frames, because it works on the channel level of OSI and redirects all protocols (including IPX, NETBEUI etc), not only IP (as ARP-poisoning). Other possible attacks. *=*=*=*=*=*=*=*=*=*=*=* These attacks are unchecked, but we suppose, that them are possible. STP attack on the neighbor VLAN. *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= According 802.1q a bridge with VLAN support can receive on the given channel either all the frames, or the frames with appropriate tags. In VLAN-divided networks frames containing STP packets will be transmitted via trunk link with appropriate tags. So, there is an ability to attack VLAN by sending STP packets in tagged frames to the port, which doesn't support tags. Fortunately, according 802.1q a bridge may filter out those frames. For example, Cisco devices drop down tagged frames on the tag-incompatible ports (at least, users), that makes this attack impossible. But note, that bridge MAY, not MUST drop these frames. STP on WAN links. *=*=*=*=*=*=*=*=* We also must understand, that WAN links are vulnerable to STP attacks too. This because BCP specification declare STP over PPP support. Surprising consequence of this fact is an ability to attack ISP network via dial-up connection. According RFC2878 (BCP description, see [RFC2878]) STP turned on on the PPP link if both sides requesting it, that never takes place in practice. Nevertheless, STP supported by default on the majority Cisco routers, at least models, capable to combine virtual interfaces into bridge group. This applies to GARP. *=*=*=*=*=*=*=*=*=*=*= As you may read in the Generic Attribute Registration Protocol (GARP) specification by 802.1d the STP is a subset of GARP. Some of discussed above attack work against GARP and, in particular, Generic VLAN Registration Protocol (GVRP). Therefore VLANs cannot be used as single security measure in network. 802.1q standard originated from 802.1d and inherits all its defects. We may continue our research of non-standard using STP. All new materials will be available on the project web-page (see [3]). Brief resume. *=*=*=*=*=*=* So, we shown that unfortunately all networks supporting 802.1d and, with some restrictions, those that support 802.1q are all vulnerable. While some devices support STP only if administrator turned on appropriate option during configuration process, others support STP by default, ``from the box'' (most of current vendors enable STP by default). Ask your admin: does our network need STP support? Is STP support turned off on our hardware? Detection and protection. *=*=*=*=*=*=*=*=*=*=*=*=* What is the main difficulty with STP-based attacks detection? The problem is that for this attack used standard C-BPDU packets, so presence STP packets on the network is not strong characteristic of attack. Other difficulty is that Intrusion Detection System (IDS) must have in its disposal information about network scheme, at least, list of network devices (with bridges IDs) to distinguish usual STP traffic from intruder's packets. Moreover, as a main goal of attack is network availability, IDS must have its own alarm channel. But note that in this case there possible false negatives - attack will not detected if malicious BPDUs affect network hardware before IDS disclose them. Each real network normal state can be described in STP terms. For example, in a network which normally doesn't use STP appearance of STP packets most likely signify an STP attack attempt. Series of Root Bridge elections with sequential lowering Root Bridge ID may signify ``eternal election'' attack. In a network with fixed list of device IDs appearance of BPDUs with new ID in most cases may signify an attack (except, of course some ridiculous cases like installation of new device by ones of poor-coordinated administration team). We suppose, that most effective solution is adaptive self-learning IDS using neural networks technology, because the can dynamically compare actual network state with ``normal'' state. One of most significant measure is STP fraction in total traffic amount. Quick fix? *=*=*=*=*=* What can network administrators do while problem exists? - If STP is not barest necessity for your network, it must be disabled. As we noted above, in most devices STP is enabled by default. - In many cases backup links can be controlled using other mechanisms like Link Aggregation. This feature supported by many devices, including Intel, Avaya etc. - If hardware supports individual STP settings on each port then STP must be switched off on all ports except tagged port connected to other network hardware, but not user workstations. Especially this must be taken in account by ISP, because malicious users may attempt to make DoS against either ISP network either other client's networks. - If possible administrators must to segment STP realm, i.e. create several independent spanning trees. Particularly, if two network segment (offices) connected via WAN link, STP on this link must be switched off. Conclusion *=*=*=*=*= Each complicated system inevitably has some errors and communications is not an exclusion. But this fact is not a reason to stop evolution of information technologies - we can totally escape mistakes only if we do nothing. Meanwhile increasing complexity of technologies demand new approach to development, an approach, which takes in account all conditions and factors, including information security. We suppose that developers must use new methods, like mathematical simulation of produced system, which takes in account not only specified controlling and disturbing impacts on the system, but also predicts system behavior when input values are outside of specified range. It is no wonder that developers in first place take in account primary goal of system creation and other questions gives little consideration. But if we don't include appropriate security measures while system development, it is practically impossible to ``make secure'' this system when it is already created. At least, this process is very expensive, because core design lacks are hard to detect and too hard (some times - impossible) to repair in contrast to implementation and configuration errors. References *=*=*=*=*= [2] Our article in Russian in LAN-magazine: http://www.osp.ru/lan/2002/01/088.htm , also there, in paper: Russia, Moscow, LAN, #01/2002, published by ``Open Systems'' publishers. [3] Other materials of this research are published in full at http://olli.digger.org.ru/STP [4] Formatted report of our research http://olli.digger.org.ru/STP/STP.pdf [5] C-code source of BPDU generation program http://olli.digger.org.ru/STP/stp.c [6] Shell script to manipulate STP parameters http://olli.digger.org.ru/STP/test.sh [7] ANSI/IEEE 802.1d (Media Access Control, MAC) and ANSI/IEEE 802.1q (Virtual Bridged Local Area Networks) can be downloaded from http://standards.ieee.org/getieee [8] RFC2878 (PPP Bridging Control Protocol) http://www.ietf.org/rfc/rfc2878.txt [9] Description of BPDU http://www.protocols.com/pbook/bridge.htm#BPDU [10] Assigned Numbers (RFC1700) http://www.iana.org/numbers.html [11] Cisco STP Portfast feature http://www.cisco.com/warppublic/473/65.html [12] Description of STP support on 3Com SuperStack Switch 1000 http://support.3com.com/infodeli/tools/switches/s_stack2/3c16902/man ual.a02/chap51.htm [13] Linux Bridge Project http://bridge.sourceforge.net/ [14] Thomas Habets. Playing with ARP http://www.habets.pp.se/synscan/docs/play_arp-draft1.pdf |=[ EOF ]=---------------------------------------------------------------=|