Just reading about “vlan hopping” and was wondering how to check if my TP-Link L2 switches + Mikrotik devices could be vunerable to such attack!
https://cybersecurity.att.com/blogs/security-essentials/vlan-hopping-and-mitigation
Also has anyone used Yersinia
https://tools.kali.org/vulnerability-analysis/yersinia
MikroTik is not Cisco, they do not use proprietary DTP…
I would like to check if double tagging was used, can vlan hopping occur on TP-link switches and Mikrotik devices?
Can’t say anything about TP link gear. MT (most probably) can’t be exploted this way, at least if bridge vlan-filtering is used (some HW offloaded VLAN setup might be vulnerable but it very much depends on how switch chip operates - I’m not going to study that now) … if set up properly.
The thing is that there is no “native VLAN” in MT bridge world. So either frame is tagged on ingress and tag remains (tagged ports or hybrid ports for tagged frames) or is not tagged and port adds tag according to PVID (access ports or hybrid ports for untagged frames). In both cases it is important to aporopriately set property frame-types= and set ingress-filtering=yes … both properties are often forgotten. If both are set correctly, it is almost impossible to get into double-tagging. AFAIK the only possibility for that to happen is if attacker crafts frame tagged with different type of VLAN tags (e.g. 802.1ax - service tags vs. 802.1q - usual VLAN tags) and MT device will then apply 802.1q tag with PVID … but that doesn’t help the attacker as MT device adds tag on ingress (and removes it on egress) whereas attacker wants that frame is passed intact on ingress and be untagged on egress.
To add mkx, does applying ingress filtering and limiting type of packets reduce in general vulnerabilities or put the other way around, improve general security of the vlans???
These settings improve security. E.g. if port doesn’t have ingress-filtering=yes set and tagged frames are allowed on ingress, attacker could inject packets into arbitrary VLAN (also into VLANs which have nothing to do with this particular port). It’s one way again (replies are not delivered), but it’s same kind of vulnerability as discussed by articles linked in OP.