I’ve made a few mentions about VLANs in the recent past as it’s something that I find quite useful along with virtual APs with managing an ever-increasingly-complex home network. But as some more “basic” edge equipment may not be able to tag/untag packets to participate in VLANs, while others can’t really be trusted to maintain a fixed VLAN tag setting and avoid VLAN hopping , it actually makes sense to enforce the VLAN tagging as a function of the network infrastructure instead of configuring it at the edge.
Traditionally, this would be quite an expensive proposition, as smart-switches were traditionally the realm of business networking with choices mostly from big-name vendors costing several hundred dollars at the least. One could always jury-rig their own from a Linux box with a few NICs or an old router supported by DD-WRT/OpenWRT/etc or invest in some rather cost-efficient Mikrotik gear but this is still somewhat overkill.
Luckily, this under-served market segment has seen several vendors enter – providing “smart” switches which aren’t much more expensive than traditional “dumb” switches while offering some of the capabilities that much more expensive models do.
In this article, I will look at the TP-Link TL-SG105E 5-Port Gigabit “Easy Smart” Switch which I managed to obtain on discount for AU$39.20 including postage. While on the outside, it shares a visual similarity with the metal-cased TL-SG105 “regular” switch, this one also offers a number of additional capabilities of which VLAN operation is one of them.
Unlike the cheaper plastic switches which I reviewed earlier, the Easy Smart switch seems to have an air of “premium” about it with a foiled-colour outer cardboard wrap, proclaiming a 3-year warranty which is pretty standard.
The front of the box shows the product clearly along with some of its features in icon form. Interestingly, the top right corner has a logo indicating “Business Solution”, which also suggests that this is a more “sophisticated” product.
The rear provides a blurb about the capabilities of the unit – again, with switches, it’s almost like reading the back of a shampoo bottle.
The underside has the system requirements, which seems to suggest the configuration utility only runs under Windows, but the switch can be administered through the web interface which should work on almost anything. The particular unit I have is a “Ver 3.0” unit with part number 1731500017.
The sides give more information about features, and makes it clear that the box includes the switch, a power adapter, installation guide and resource CD.
Under the cardboard outer wrap, is a plain inner flip-open cardboard box. Under the flap is the mini-CD of resources, installation guide and switch in a protective plastic bag.
For Australia, it seems a separate warranty statement is also included. The switch also has a bag of self-adhesive rubber feet included, so “some assembly is necessary”.
The included switchmode power supply is rated 9V 0.6A, as is common with most of TP-Link’s products. Unlike some of their older products, the rear of the casing does not have the brand moulded into it.
The design of the switch is so that all the Ethernet cables cone in fron the front, with link speed and activity lights integrated into each jack. A power LED is provided on the right side as well.
The rear of the unit has the barrel jack for power supply, a slot for a Kensington lock and a reset button.
The other sides are not used, except for some ventilation holes.
The underside has a label with some product information and the unique serial number/MAC of the unit. Note the outlines for the self-adhesive rubber feet which have not yet been fitted. Slots for wall-mounting screws are also provided.
The unit has two screws holding the top lid in place. Getting in is as simple as unscrewing these and sliding the cover off.
A look at the shell shows that there are some ID numbers internally, along with protection around the wall-mounting slots to prevent screws from shorting out the PCB internally.
The main PCB looks as follows – dated Week 50 of 2017, the design features very few components. A console header (J2) can be seen near the switch chip which is a square leaded-type under a heatsink. A 25Mhz clock crystal feeds this IC, along with a 25Q16CSIG (16Mbit/2MiB) flash memory. The port magnetics are Group-Tek HST-2027DAR units dated Week 1 of 2018. The firmware was dumped, but because of the presence of unique MAC addresses, will not be made available. The majority of the data is identical to the firmware update blobs issued by TP-Link, however, the data alignment is different.
The underside has no components, only solder points for through-hole components with silkscreen over solder-mask to reduce risks of solder bridges.
Judging from the input, the only electrolytic capacitor is a “bulk” capacitor for compensating for power supply cable lengths and ensuring a local reserve of power for step changes in operational mode. As a result, it’s not likely that this capacitor will fail as it will be relatively un-stressed. It is a Samxon 470uF 25V capacitor, which feeds into a downstream switching converter that has MLCC capacitors, providing the supply for the switch chip.
Configuration and Firmware
Rather interestingly, the unit comes pre-configured with a static IP address rather than DHCP – this is quite likely to conflict with some home routers (192.168.0.1). As a result, it probably helps to run a separate direct connection to the switch at first for configuration, with a static IPv4 address.
The main screen is the System screen. This shows the basic information about the switch – you can set a name for your switch on this screen as well. The left hand panel forms the navigation between the various features available. Of note is the Save Config button on the left – while any changes on the pages can be applied and the switch will respect them, the configuration is only in RAM and is lost on a reboot until you also click on the Save Config button in the sidebar. I only realised this after getting frustrated that power-cycling a configured switch caused all the configuration to be lost – I didn’t click that button after finishing my config!
The system menu also allows you to configure the IP settings.
User Accounts allows you to change the password and username for the administrator.
The system tools sub-section allows the possibility of backing up and restoring the configuration …
… rebooting or resetting the whole system.
The first feature under Switching is Port Setting, which allows you to manually configure speed, duplex and flow control. Surprisingly, while the chip supports Flow Control, it is disabled by default.
The next feature is IGMP Snooping which allows for multicast traffic to be filtered and sent only to ports that request membership, avoiding needless “flooding” of data. This can be disabled if necessary.
The final feature in this section is LAG – no, that’s not a latency thing. It is short for “Link Aggregation Group”, basically a statically configured link teaming system. Unfortunately, on a five-port switch, there’s no real reason to use LAG, as you can only have two link-aggregated pairs and an odd-port-out.
Under the Monitoring category, the first page is port statistics which shows the status of the ports. Rather interestingly, it is noted in the manual that jumbo frames are counted as both bad and good packets – so don’t be alarmed if you see bad packets, it could just be a jumbo frame or a “fully laden” VLAN tagged frame.
Port mirroring allows you to “copy” the traffic to and from one port onto another for network diagnosis or capture. This can be rather useful in case of wanting to monitor a network without needing to run a “bridge” on a computer which can affect the performance of a network more adversely.
Cable testing allows you to detect faults and distances to faults – many modern NICs have this capability but being able to run testing remotely is a plus.
The switch seems to have its own loop prevention system – this seems to be distinct from STP, which can be enabled if desired. I tend to keep it disabled, as I’m careful with the way my network is wired up and would rather not risk potential traffic drops under heavy loads.
The main star is the VLAN capabilities, which are somewhat confusingly labelled. The first type is MTU VLAN – and that’s got nothing to do with Maximum Transmission Unit. I believe MTU in this case is “Multi Tenant Unit”, in any case, this seems to “isolate” traffic from each port from directly talking to each other. All traffic is funneled up the uplink port for an upstream router to decide which traffic should pass between these downstream ports (if any).
Port-based VLAN is more like creating several “virtual” switches on one switch – say grouping ports 1 and 2 together and 3-4-5 into another group where both groups are isolated but still plugged into the same physical unit. This is more useful if you have more ports (i.e. a larger switch) as this applies only to the one switch rather than doing a “tagged” VLAN which can define networking topologies that extend beyond a single switch.
If you’re into VLANs, then 802.11q VLAN is the type you’re after – you can define VLAN IDs and whether ports are members of these VLAN IDs in a tagged or untagged way. However, just beware that only 32 unique VLAN IDs are supported simultaneously.
This is to be used in conjunction with the 802.1Q PVID Setting Page (which looks similar, I didn’t take a screenshot of) which sets which tags are applied by the switch to packets incoming from the ports.
The QoS menu allows for basic port-based QoS which probably affects the queueing behaviour of the switch. This can be done based on the port priority or by packet priority tags.
A more powerful option is the ability to limit by bandwidth. This can act as a safety valve to prevent a single malfunctioning device from saturating the network bandwidth.
Storm control options are also provided which limit rate but only for certain types of broadcast/multicast frames.
While the screenshots were made on the older firmware, I updated to the latest firmware as soon as I started to seriously use the unit. To do this, we need to access the firmware update menu which actually causes the unit to reboot into a firmware upgrade mode.
Once rebooted, then it is possible to select the upgrade file to be loaded.
Once the upgrade is started, then the file is sent to the switch.
From there, the image is written to the onboard flash.
The device is then rebooted.
The page attempts to refresh, but fails to as the restart process may take just a bit longer than the page expects. However, that is not a cause for concern – just give it a little longer and it will be back.
Simple Smart Utility
For those who don’t want to use the web interface or can’t find the switch on the network, it is possible to use the Simple Smart Utility (or its older brother, the Unmanaged Pro Utility) to discover and configure the switch through UDP network broadcast packets.
The IP Setting dialogue allows you to configure the connectivity and username/password.
Once logged in, the configuration appears slightly different but offers much the same functionality as that available via the web interface.
Security? Um … Hold My Beer.
Unfortunately, the security of this unit seems to be problematic. After setting up the unit, the first thing I noticed was that login credentials were sent in plain-text over unsecured HTTP over the network with no attempt to obfuscate the data or hash it:
Logins seem to be done based on IP-address (rather than sessions, cookies, etc) – anyone who has the same IP address from the switch’s point of view will be logged in as soon as one person is logged in. This was made apparent to me as I logged in from one browser on the PC and became magically logged in on another browser in my VM which is NAT-ed behind the same IP.
Then, I discovered that while passwords have a length limit enforced by the HTML, if you craft an equivalent request using cURL, it is possible to cause a “denial of service” by issuing an over-length login request regardless of the data which cause the switch to reboot – as long as username and logon fields exist.
curl -d "username=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxx&logon=Login" -X POST http://192.168.0.1/logon.cgi
The minimal requirement I found was the above which would cause it to reboot consistently.
The crash can be confirmed when the switch replies with the <script> portion of the HTML followed by a hang. The switch becomes unavailable for almost 30 seconds as it reboots and reconfigures. If you only configured the switch but did not click “Save Configuration”, doing this will reset your switch to factory defaults. I made this mistake initially, incorrectly believing this would reset to factory defaults allowing VLAN escape – this is not the case, it merely loses any “volatile” configuration that was not saved through using the Save Configuration option in the sidebar.
Things do get worse from here – now that we know how a switch can be DoS’ed, the next part is finding the switch itself. Because of the existence of “Simple Smart Utility” which features a routine to detect the presence of switches on the network, it was found that the switch will reveal its existence even if the broadcast is for a different VLAN or subnet and reveal its own IP address.
This may not directly allow access to the switch, but knowing that the SSU issues requests on port 29808/29809 (tq/tp) to 255.255.255.255 gives a good hint as to passively detect the presence of switches being administered. If we combine this with the knowledge that the administration is happening through broadcasts with static key encryption – it is possible that the login may be captured and reused later to take over a switch as broadcast traffic is disseminated throughout the whole broadcast layer 2 domain.
This is rather regrettable, as the “standard” workarounds (e.g. setting an isolated VLAN, setting a static IP in a different subnet) won’t stop the switch from being discovered and attacked.
I tried contacting TP-Link through their security disclosure system but received absolutely no reply after two-and-a-half months, with no new firmware released. However, it seems an unlikely mitigation was found through my experimentation.
By exploiting the login overflow bug, I found that making the login a little longer stopped the switch from rebooting but instead would hard-crash the 8051, causing the unit to stop responding to web interface requests or broadcast discovery requests. The switch continues to pass data retaining the configuration it had prior to the crash.
curl -d "username=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxx&logon=Login" -X POST http://192.168.0.1/log on.cgi
By crashing the remote administration abilities, it becomes impossible to remotely reconfigure the unit without power cycling, however, it protects the unit against such attacks. Not an ideal result, but better than leaving a few glaring holes open on the network. Lets face it – how often are you going to need to reconfigure the VLANs on the switch, given that doing so requires it to reboot and breaks connectivity for a short period?
Note that increasing the length of the request beyond a certain level actually is handled correctly by the switch and does not result in crashing its internal CPU – so hence it’s a “range” of lengths causing reboots, a “range” of lengths causing crashes and a “range” of lengths handled correctly with no side effects.
In truth, it seems that the switch chips employed even in basic “dumb” switches are relatively capable of performing some of the features normally reserved for smart-switches. It is through exploiting these features, which are normally “fixed” in configuration by the inbuilt EEPROM, that low-cost semi-smart switches are realised.
The TP-Link TL-SG105E uses the onboard 8051 of the Realtek RTL8367 switch chip to allow configuration of these features through a web-interface and a broadcast-based tool, allowing users to access features such as VLANs, rate limiting, QoS, IGMP Snooping and port mirroring at “budget” price not much more than that of a regular “dumb” switch. The best part is that the functionality generally works as expected, although the documentation is poor and the interface does present some confusing information at times.
However, it seems that the limitation of this approach lie in the limited onboard processing and storage capabilities of the switch chip, which results in a clunky firmware that has very strange security issues in its design including the use of fixed-key encryption as determined by another security researcher, broadcast-based messaging that allows anyone on the network or any VLAN to detect the presence of the switch, plain-text passwords over the network when logging in, the ability for crafted requests to cause it to spontaneously reboot denying service temporarily to downstream users or even lock up the remote management access permanently.
While I have contacted them about this, they have not responded nor issued any new firmware within the two-and-a-half month period since I notified them through their website’s security disclosure contact form. This is an unfortunate situation, but not unexpected given their response to the disclosure made by another security researcher.
Because of the peculiarities of the switch and its behaviour, I’d have to say that it is hard to give a clean recommendation – the unit can perform the tasks it claims to do, but it can also be the target of denial of service which would interrupt users connected downstream of the switch on a semi-continuous basis. However, I found that by crashing the remote management also meant the switch became immune from network-side attack but loses the ability to be remotely administered until power cycled. So it can be used safely and the attack window can be reduced provided the remote administration ability is “crashed” as soon as practical after the switch comes online, but this loses the ability for convenient re-configuration of the network without power cycling of the switch. As a result, I don’t think I’ll be buying any more of these myself.