Vulnerability Research
August 6, 2019
By VDOO Research Team

Working with the Community – disclosing significant vulnerabilities in multiple network switches

As part of our ongoing efforts to improve the state of IoT and embedded devices security and in addition to our in-house research efforts, VDOO has been working closely with the information security community to assist in coordinating vulnerability disclosure to vendors. As such, VDOO acts as an intermediary 3rd party to help researchers communicate with the vendors as well as to help the vendors deal with the disclosed vulnerabilities in the most professional and secure way possible in order to minimize risks to deployed devices and end-users.

Today we disclose several vulnerabilities in multiple network switches as part of our collaboration with renowned security researcher, bashis. In recent years, bashis has discovered and published multiple zero-day vulnerabilities in different connected devices, mainly from the video surveillance domain.

Researching multiple network switches, bashis has discovered and disclosed several critical vulnerabilities – multiple stack-overflow vulnerabilities leading to remote-code execution (RCE) with some not requiring authentication as well as unauthenticated access to config/firmware upgrade CGIs, and command injection vulnerabilities requiring authentication. The vulnerabilities, which stem from the Realtek Managed Switch Controller (RTL83xx) SDK, appear to be relevant to multiple network switching models from multiple different vendors that are using code from this SDK.

VDOO approached all possibly affected vendors that were identified by the researcher bashis and responsibly disclosed the vulnerabilities to the vendors that responded. Unfortunately, as of now, since our initial approach in March 2019, we weren’t able to receive any technical response from Realtek regarding these issues.

Below is a list of affected vendors/models:

  • Zyxel Communications Corp., models GS1900-24 v2.40_AAHL.1_20180705 - vulnerabilities confirmed and patched.
  • NETGEAR, models GS750E ProSAFE Plus Switch v1.0.0.22, GS728TPv2, GS728TPPv2, GS752TPv2, GS752TPP v6.0.0.45, GS728TPv2, GS728TPPv2, GS752TPv2, GS752TPP v6.0.0.37 - vulnerabilities confirmed and patched.
  • Cisco Systems, Inc., 220 Series Smart Switches, versions prior to 1.1.4.4 - vulnerabilities confirmed and patched.
  • Realtek, SDK + models RTL8380-24GE-4GEC v3.0.0.43126 - no response was received so far to the initial approach from VDOO.
  • EnGenius Technologies, Inc., models EGS2110P v1.05.20_150810-1754, EWS1200-28TFP v1.07.22_c1.9.21_181018-0228, EWS1200-28TFP v1.06.21_c1.8.77_180906-0716 - no response was received so far to the initial approach from VDOO.
  • PLANET Technology Corp., models GS-4210-8P2S v1.0b17111, GS-4210-24T2S v2.0b160727 - no response was received so far to the initial approach from VDOO.
  • DrayTek Corp., models VigorSwitch P1100 v2.1.4 - vulnerabilities are yet to be confirmed by vendor.
  • CERIO Corp., models CS-2424G-24P v1.00.29 - no response was received so far to the initial approach from VDOO.
  • ALLNET GmbH, models ALL-SG8208M v2.2.1 - vulnerabilities confirmed and are yet to be patched.
  • Xhome, models DownLoop-G24M v3.0.0.43126 - no response was received so far to the initial approach from VDOO.
  • Abaniact (a brand of INABA), models AML2-PS16-17GP L2 v116B00033 - no response was received so far to the initial approach from VDOO.
  • Araknis Networks (SnapAV), models AN-310-SW-16-POE v1.2.00_171225-1618 - vulnerabilities are yet to be confirmed by vendor.
  • EDIMAX Technology Co., models GS-5424PLC v1.1.1.6, GS-5424PLC v1.1.1.5 - no response was received so far to the initial approach from VDOO.
  • Open Mesh, Inc., models OMS24 v01.03.24_180823-1626 - no response was received so far to the initial approach from VDOO.
  • Pakedgedevice & Software Inc, models SX-8P v1.04 - no response was received so far to the initial approach from VDOO.
  • Shenzhen TG-NET Botone Technology Co,. Ltd., models P3026M-24POE (V3) v3.1.1-R1 - no response was received so far to the initial approach from VDOO.

VDOO continues to support this disclosure and work with affected vendors. As such, vendors that are using the SDK and could be vulnerable are encouraged to contact us. In addition, this list will be updated to reflect the current status of affected vendors, patching and disclosure. Additional details will be released on August 20, 2019 in an independent technical publication with Proof-of-Concept (PoC) on these issues by bashis.

Thanks

VDOO would like to thank bashis for his work and conduct in the process.

Additional thanks are due for Mr. Dorian Schneltzer for his help in facilitating communications.

Recommendations for Device Makers

We would like to relate to some bad architectural practices that were found in the network switches analyzed in this research, that make it easier for an attacker to discover and exploit vulnerabilities. We encourage device makers to take the below recommendations into consideration.

  • Input sanitization. When getting input from an external interface, the input should be sanitized from shell special characters that may lead to shell command injection vulnerabilities.
  • Executing external processes to perform tasks (such as configuring the device or its operating system) instead of using existing API for the programming language (library functions), if such exists. Executing external processes, and specifically running shell commands introduces the possibility of command injection vulnerabilities to the program.
  • Usage of unsafe functions. strcpy function is unsafe, and should be replaced by the safe strncpy function, that can limit the amount of characters copied to the destination buffer and avoid potential buffer overflow vulnerabilities. The best practice is to not use any of the unsafe versions of the functions even if at a specific case it is safe, since using them regularly can lead to using them in an unsafe manner by mistake.
  • User-mode ASLR. ASLR is implemented and turned on already in the Linux OS running on the device, and the only change needed to be done is to make the main binary compatible with it by adding the “-pie -fPIE” flag to GCC. With this feature, an attacker cannot guess the address of the functionality he wants to jump to.
  • Stack canaries. This is a very simple and important security feature that can be turned on by adding the “-fstack-protector-all” flag to GCC. With this feature, the executable will crash when it recognizes that the stack was compromised. That would lead to a short denial of service, but at least it won’t allow an attacker to run code of his choice. It is important to note that this feature can lead to performance degradation since a stack canary is checked for every function. If this performance degradation makes it impossible to use, it is possible to control the creation of stack canaries and set them to be put only on functions that have high potential to be vulnerable to stack-based buffer overflows. If using the GCC compiler, that can be done by using the “-fstack-protector” flag together with "--param ssp-buffer-size".
  • Lack of firmware encryption. Firmware encryption will raise the bar and make it harder for adversaries to analyze the firmware for bugs, and specifically use binary diffing methods between the latest and previous firmware in order to find and analyze the patches and in this way – uncover the vulnerabilities that still exist in the previous version. Moreover, the device contained unstripped binaries with symbols like function names. This aided us in understanding how the code works. On the other hand, it is worth noting that the security by obscurity approach for firmware content may contribute to a situation in which issues exists but are not being discovered and remediated since the firmware is encrypted properly. Also, by distributing a non-encrypted firmware available to the community, security researchers can review the security and enhance it with their findings with a responsible disclosure process. Vendors should consider this tradeoff carefully.
  • Lack of firmware digital signing. This allows an attacker to repack a malicious firmware. Vendors should consider signing their firmware, to protect from this threat.

Share this post

You may also like