Exploiting Aruba Device Profiles

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.

Aruba AOS-CX LLDP Capture

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.

Sysname bytearray

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:

Interface Configuration before packet. (VLAN 1)

Lets send the packet:

Injected LLDP Packet. NOTE: System Name

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.

Interface Configuration after packet. (VLAN 199, 2)

NOTES

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.

NOTES

RESOURCES