712 lines
36 KiB
Plaintext
712 lines
36 KiB
Plaintext
==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 ]=---------------------------------------------------------------=|
|
|
|