In this article:
This post is part of a series about practical network layer 2 exploitation.
Now is the time to change your network administrator hat for the attacker one. Your own, known network now becomes an unfamiliar target.
Before rushing and banging against the nearest devices, it may wiser to just stand back and listen.
On switched networks, users are somewhat isolated from each other thanks to the separation of collision domains. All that remain is some kind white noise… but this white noise in itself can bring invaluable information to an attacker!
In particular we will see how, simply by passively listening to this white noise, an attacker will be able to detect several weaknesses affecting the network and plan his next steps.
In this lab no interaction will occur with either the Admins or the Servers VLANs, the User_1 workstation will be required only for the DHCP Discover messages part:
STP messages
| Lab | Compatible |
|---|---|
| Dynamips | Yes |
| IOU | Yes |
| Real gear | Yes |
Now is the time to open a session on the Attacker host and fire-up
Wireshark.
As with most tool we will use in this post series, it requires a raw access to
the network devices and must therefore be run as root: this is not a problem
on some distributions like Kali where the whole desktop session is running as
root, on other you may need to start Wireshark through sudo wireshark.
Once Wireshark is up and listening on your main network interface in promiscuous mode, you should already start to see mostly light-grey packets regularly accumulating as the “white noise” mentioned earlier.
Most of these messages are STP messages, sent every few seconds by the nearby switch:
These messages are sent in case we add another switch on our end (in sane networks they should not be sent on access ports). They are used to detect topology loops and build the most efficient forwarding path between connected switches.
The presence of these messages means that we can start discussing with the switch using the STP protocol, potentially inducing changes to the whole spanning tree.
By themselves, this ability won’t allow us to do any really profitable attack against the network. However, in some cases it can provide us a valuable support to make other attacks more effective:
-
The attacker can become root of the STP tree, making the propagation of malicious packets throughout the switched network more efficient.
-
The attacker can cause a temporary but renewable DoS disrupting communication over the whole switched network or a VLAN depending on the network communication. This can be used as:
-
A part of a social engineering attack. For instance a fake IT support guy calling an employee, notifying about current network outages “which have been detected” and collecting sensitive information “for troubleshooting purposes”.
-
A brutal way to paralyze a VLAN or a network, for instance to disrupts network and system management services while the actual attack is going on.
-
DHCP Discover messages
| Lab | Compatible |
|---|---|
| Dynamips | Yes |
| IOU | Yes |
| Real gear | Yes |
Start or restart the User_1 host. You should eventually see, among other things, a DHCP Discover message popping up in your Wireshark:
This is a good thing (from an attacker perspective) as this means that DHCP snooping has not been enabled in the switches you are facing. This give the attacker the ability to build a rogue DHCP server, distributing malicious DHCP replies and opening the way to various MITM attacks.
You can also take this occasion to note-down the MAC address of the User_1 machine which appears as the message’s source (Ethernet II, Src field) address.
DTP messages
| Lab | Compatible |
|---|---|
| Dynamips | No |
| IOU | Yes |
| Real gear | Yes |
About every minute, you may encounter a DTP message:
This is your lucky day.
This protocol allows plug-and-play auto-configuration of Cisco switches.
At the low-end, from a purely passive perspective we can see that DTP packets disclose a lot of information regarding the switch configuration, including the VTP domain name, the native VLAN number and the switch port status.
But above all, this opens the most devastating attack we will see in this series as actively engaging in the DTP communication opens the way to VLAN hopping.
Note
The DTP packets, as the CDP ones we will see below, leak the native VLAN information which happens to be the same as the Users VLAN in our lab where the attacker is located.
This is usually documented as a security weakness also allowing VLAN hopping through double-tagging, however Cisco switches do not seem vulnerable to this attack as they correctly drop 802.1Q packets coming on non-trunk ports.
Moreover, even on vulnerable devices the range of this paticualr attack is somewhat limited as it allows only one-way communication (still useful for things like malicious UDP notifications though). As we will see, DTP-based VLAN hopping doesn’t have this limitation.
CDP messages
| Lab | Compatible |
|---|---|
| Dynamips | Yes |
| IOU | Yes |
| Real gear | Yes |
At last, about every minute you may also encounter a CDP message:
These messages allow a Cisco device to share some technical details with other directly connected devices. This protocol is used by several Cisco proprietary features, such as:
-
Cisco Neighbor Discovery: each device stores a table fetchable through SNMP containing their neighbors information.
-
Lowering power delivered through PoE ports: a Cisco device (like an IP phone) can use this to inform the PoE switch it is connected to that it requires only 9 W instead of the default 15.4 W, thus lowering the switch’s global energy consumption. More information.
-
On-Demand routing (ODR): this is a Cisco proprietary intermediary solution between static and dynamic routing. It can be used in hub and spoke topologies, the spoke routers using CDP to notify the hub router of their ports IP address prefixes, thus allowing a hub router with ODR enabled to update its routing table accordingly. More information.
Note
In ODR, the “routing” communication occurs only between the spoke and hub routers. Unless you do lousy things such as connecting end-users directly to the infrastructure switches, it is out of attackers direct reach.
CDP packets are usually not directly exploitable with a notable exception.
Unlike normal network traffic which is not parsed but immediately forwarded through ASICs (see here for more information), CDP messages content needs to be parsed by the device’s general purpose CPU. Would a a bug be present in the parsing software an attacker may be able to send specially crafted packets and execute arbitrary code on a near-by device.
This particular attack is out-of-scope of this series. We will just notice that CDP messages are extremely verbose when it comes to devices details, providing:
-
Detailed information on the platform and firmware version being run (here a Cisco 3725 box running the C3725-ADVENTERPRISEK9-M firmware, version 12.4(15)T10, compiled Mon 14-Sep-09 15:33 by prod-rel_team). Such information can be matched against vulnerability databases to reveal exploitable software bugs such as the example mentioned above.
-
Details regarding the device configuration, including interface addresses, VTP domain name, the native VLAN number and the device name. Such information may potentially be reused in other attacks or aggregated in order to gain knowledge on the network general design and implementation.
Next: Spanning Tree Protocol exploitation
How an attacker can take advantage of STP, and how to prevent this.
