There is hardly a week passing by, that is not dominated by some more or less serious IT security incident. Though a considerable number of these incidents is caused by the exploitation of specific vulnerabilities, be it zerodays or not, their impact is frequently dependent on the prevalent infrastructure of the systems in question. The spreading of WannaCry, for example, could have been – and in many cases probably was* – condemned by the proper employment and configuration of firewalls to separate networks or at least filter potentially illegitimate traffic.

Though the state of IT security is frequently described as being broken beyond all repair, the proper employment of basic technologies can make a huge difference. Apart from firewalling, the logical separation of networks based on VLANs is one such basic technology. Without being able to assert that VLANs are always set up in an effective way, one can say that, in the corporate context, their utilization is common practice nowadays. But also in the SME and even consumer segments, the number of managed switches and access points is on the rise as they regularly increase resource efficiency and administrative convenience while potentially adding to the overall security by simplifying network segregation.

However, as we found out ourselves, even these basic technologies – that we so heavily rely on – sometimes malfunction or exhibit fundamental errors that affect operation such that firewalls do not filter traffic according to installed rules or that networks are not separated as specified in the VLAN configuration.

But why is this noteworthy?

Because the point is that we are not talking about some random Smart Home IoT device that we can tell from experience is not always inherently secure, but about basic technologies.
Utilization of VLANs is not a modern trend that is supported by a hand full of IT professionals only. It is common practice and only on rare occasions (i.e. some safety-critical systems) dropped for actual physical separation. This is why the proper implementation and utilization of such technology is of utmost importance. Depending on the scenario not only privacy, sensitive data or even production facilities might be at risk, but also safety. Unlike Antivirus software or Spam filters, that operate in a best-effort fashion, firewalls and VLANs have to enforce communication rules without exception at any given point in time.

An example of such basic technology failing its essential purpose, that we made first-hand experience with, is the TP-Link AP500 Access Point (AP) that is being advertised as VLAN-capable. The device’s Multi-SSID feature allows for the configuration of multiple SSIDs and assign these to different VLANs by having the traffic tagged accordingly in the fashion of IEEE 802.11q.
Unfortunately, the device does not behave as intended, though presumably configured correctly. In a set-up where we connected the AP to a VLAN-capable switch that supports 802.11q-compliant tagging on the uplink to the AP, the ports of the switch that have been configured to employ port-based VLAN will receive traffic from other VLANs as well. This was the case, when the respective untagged port belonged to a VLAN that was also handled by the AP’s Multi-SSID feature. Ports that employed VLANs unknown to the AP would not receive any of the misrouted traffic. To make sure this is neither related to some weird bug in the switches VLAN implementation nor this one specific AP, we replicated the setup utilizing three different VLAN switches (Netgear GS108Ev2, Netgear GS108Ev3 and TP-LINK TL-SG108E) as well as another one of the AP500 Access Points (the exact same model) – always with the same result. The fact that the misrouted traffic monitored on one of the ports did not even originate at the AP but at another port of the switch that belonged to another VLAN implicates that the AP500 bridged traffic across the VLANs it handled. This became obvious when clients attached to a port of VLAN 1 got IP-Adresses from a DHCP Server attached to a port of VLAN 2.
Attaching both APs at the same time to ports that employed VLAN-tagging corroborated that impression since it rendered the network completely inoperable, implying that a loop was introduced.

Having gained some insights into the details of this misbehavior allowed for a specific Internet search that revealed two things. First, the problem is, of course, not new, and second, it has not been fixed in 18 months time though TP-Link has been informed about this issue. Instead, the TP-Link support provided individual users with different firmware images of questionable quality and compatibility thus externalizing their QA and testing while still advertising and marketing a faulty product.

Irrespective of the fact, that the AP500 is a low-price device which obviously targets the consumer market, one should expect it to implement advertised features in a compliant way.

*Media coverage on IT networks that were not compromised because of proper employment of counter measures is usually not extensive.