I have been using Aruba's device profiling technology for quite some time. It can be quite useful when you must extend your VLANs all the way to your access switches. For instance, with their Instant AP model, every "user" VLAN must be tagged at the APs. They must be also tagged all the way up to your core switches. You simply enable device profiling and the Aruba switches will identify other HPE/Aruba switches AND APs and tag/untag their ports accordingly. Granted, all of your gear must be HPE/Aruba. I'm now starting to change my tune on this technology. It must be used sparingly alongside strong access controls as you will see below.
Now, the way the device identification takes place is with LLDP (Link-Layer Discovery Protocol). You can find more info on LLDP here. LLDP operates at Layer 2 of the OSI model and is useful for devices to communicate capabilities with one another without having any information beforehand such as an IP, etc. LLDP is often used by VoIP phones to communicate VLAN, PoE, and other requirements. It is also true that LLDP has no authentication mechanisms as part of the specification. Today, we're going to exploit that fact.
We're going to look at how we can "hop" VLANs by exploiting implied trust between two endpoints at the lower levels of the OSI model. Specifically, we'll be using an Aruba AOS-CX 6300 and a standard Windows laptop. Using simply a Python script, I will demonstrate how to trick the switch into thinking I'm a different device and assign me to a different VLAN.
To begin we need to understand how the switch determines what device is on the other end of the link. Below is a snippet of the switch configuration.
port-access lldp-group LLDP-device seq 20 match sysname FakeSwitch01 exit port-access role LLDP-device description SCAPY-TEST vlan trunk native 199 vlan trunk allowed 2,199 exit port-access device-profile custom-switch enable associate role LLDP-device associate lldp-group LLDP-device exit
From the configuration you can see you must first build the lldp-group which determines how you match on the LLDP neighbor. In this example, as long as the sysname matches FakeSwitch01 the port-access role will be assigned. AOS-CX also supports sys-desc and vendor-oui. So, as you can see, if we were to craft an LLDP packet to send to the switch with the sysname TLV set to FakeSwitch01 we would force the switch to reconfigure the port we're connected to.
So, on to the cool stuff as the kids would say. Using scapy's Python library we will construct a legitimate packet to fool the switch into thinking we are also a switch. There will be a link to github gist at the end of the article.
Lets first take a look at a packet capture from a switch.
We can see the source appears to be an Aruba Switch. What we're particularly interested in is the System Name field. We know from our configuration that is what we're keying off of to identify a neighboring switch. So, we need to know how to craft the packet to at least deliver that much. Below I'm going to provide a snippet of the code we're concerned with. I'll explain more later.
This code is constructing a byte array to later add to our payload. line 14 is defining the length of the name in the first 2 bytes, and we're adding the switch name to remaining bytes. (Padding is implied)
Now, if I send the packet along with just this data the switch on the other end should reconfigure our port. Why? Because it thinks we're now a switch. . Lets take a look at the current interface configuration:
Lets send the packet:
Now that our system name is set, the switch should have fired off its device profiling rule.
And there we go. Now we're on VLAN 199, and tagged for VLAN 2.
- This feature is disabled by default.
- Device Profiling is also available on the AOS-S line of switches.
- Profiling can also be used to identify APs and gateways. The script could easily be modified to impersonate one of those devices as well.
- Profiling should be used sparingly, if at all.
- ALWAYS use strong authentication such as 802.1X with a NAC platform in favor of profiling.