Full Disclosure mailing list archives

Realtek Managed Switch Controller RTL83xx


From: bashis <mcw () noemail eu>
Date: Tue, 20 Aug 2019 21:44:03 +0000

    [SOT]
    
    [Subject]
    
    Realtek Managed Switch Controller (RTL83xx) PoC (2019 bashis)
    https://www.realtek.com/en/products/communications-network-ics/category/managed-switch-controller
    
    [Brief description]
    
    1.  Boa/Hydra suffer of exploitable stack overflow with a 'one byte read-write loop' w/o boundary check. (all FW 
version and vendors affected)
        Note: The vulnerability are _not_ from Boa nor Hydra, coming from Realtek additional coding
    2.  Reuse of code between vendors gives almost indentical exploitation of found vulnerabilities
    3.  Two strcpy() vulnerable fixed buffers next to each others in same function make it easy for jumping in Big 
Endian
    
    [Goals for this PoC]
    
    1.  One Python PoC for all vendors
        Using dictionaries to have one 'template' for each vendor and another dictionary with unique details for each 
target, to be merged on the fly.
        The python code will read and use details from dictionary when verifying/exploiting
    
    2.  Uniquely identify remote target
        ETag - Static and excellent tool for determine remote target, due to non-changing 'last modified' in same 
revision of Firmware
    
        ETag: xxxxx-yyyyy
        xxxxx = file size (up to 5 digits)
        yyyyy = last modified (up to 5 digits)
    
    3.  Reverse shell
        MIPS Big Endian shellcode is the only option, as there are no 'netcat/telnet/stunnel.. etc' availible
    
    4.  add/delete credentials for GUI/CLI
        Quite many of the firmware's has the 'option' to add valid credentials by unauthorized updating of 
'running-config'
        For those who has added protection, we can add/delete credentials with an bit interesting jumping sequence
    
    [Technical brief]
    1.  Stack       - Read/Write/Executable (Using CMD injection in the PoC to turn off ASLR)
    2.  Heap        - Read/Write/Executable (No need to turn off, ASLR not turned on for heap)
    3.  fork        - Boa/Hydra using forking shellcode, as I want try restart Boa/Hydra to avoid DoS after successful 
reverse shell
    
    Two vulnerable buffers with fixed size in same call, we overwrite $RA with four bytes, and overwrite first byte in 
$RA with second buffers NULL termination,
    this allows us to jump within the binary itself, and passing arguments for the function we jumping to by tailing 
these with the original request
    
    [Basically]
    First buffer:         [aaaaaaaa][0x58xxxxxx]        ('a' and 0x58 will be overwritten by second buffer)
    Second buffer: [bbbbb][bbbbbbbb][0x00xxxxxx]        (NULL termination will overwrite 0x58)
    
    [Known targets]
    
    All below is fully exploitable, with following exception:
    [*] ETag: 639-98866   [NETGEAR Inc. GS728TPv2, GS728TPPv2, GS752TPv2, GS752TPP v6.0.0.45]
    [*] ETag: 639-73124   [NETGEAR Inc. GS728TPv2, GS728TPPv2, GS752TPv2, GS752TPP v6.0.0.37]
    
    Not because they are not vulnerable, its because 1) their heap addresses lays at the '0x478000-0x47a000' range,
    and 2) they using obfuscation 'encode' for the password (99 bytes max), we can never reach the 'two buffers' jump 
method.
    [They are still fully exploitable with the Boa/Hydra vulnerability]
    
    Note:
    In this PoC I have only implemented few affected versions, in reality there is many more models and FW version 
affected.
    
    
    $ ./Realtek-RTL83xx-PoC.py --etag help
    
    [*] Realtek Managed Switch Controller RTL83xx PoC (2019 bashis)
    [*] RHOST: 192.168.57.20
    [*] RPORT: 80
    [*] LHOST: 192.168.57.1
    [*] LPORT: 1337
    [+] Target: List of known targets
    
    [*] ETag: 225-51973   [Cisco Systems, Inc. Sx220 v1.1.3.1]
    [*] ETag: 225-60080   [Cisco Systems, Inc. Sx220 v1.1.4.1]
    [*] ETag: 752-76347   [ALLNET GmbH Computersysteme ALL-SG8208M v2.2.1]
    [*] ETag: 225-21785   [Pakedgedevice & Software Inc SX-8P v1.04]
    [*] ETag: 222-71560   [Zyxel Communications Corp. GS1900-24 v2.40_AAHL.1_20180705]
    [*] ETag: 14044-509   [EnGenius Technologies, Inc. EGS2110P v1.05.20_150810-1754]
    [*] ETag: 13984-12788 [Open Mesh, Inc. OMS24 v01.03.24_180823-1626]
    [*] ETag: 218-22429   [PLANET Technology Corp. GS-4210-8P2S v1.0b171116]
    [*] ETag: 218-7473    [PLANET Technology Corp. GS-4210-24T2S v2.0b160727]
    [*] ETag: 752-95168   [DrayTek Corp. VigorSwitch P1100 v2.1.4]
    [*] ETag: 225-96283   [EDIMAX Technology Co., Ltd. GS-5424PLC v1.1.1.6]
    [*] ETag: 225-63242   [EDIMAX Technology Co., Ltd. GS-5424PLC v1.1.1.5]
    [*] ETag: 224-5061    [CERIO Corp. CS-2424G-24P v1.00.29]
    [*] ETag: 222-50100   [ALLNET GmbH Computersysteme ALL-SG8310PM v3.1.1-R3-B1]
    [*] ETag: 222-81176   [Shenzhen TG-NET Botone Technology Co,. Ltd. P3026M-24POE (V3) v3.1.1-R1]
    [*] ETag: 8028-89928  [Araknis Networks AN-310-SW-16-POE v1.2.00_171225-1618]
    [*] ETag: 222-64895   [Xhome DownLoop-G24M v3.0.0.43126]
    [*] ETag: 222-40570   [Realtek RTL8380-24GE-4GEC v3.0.0.43126]
    [*] ETag: 222-45866   [Abaniact AML2-PS16-17GP L2 v116B00033]
    [*] ETag: 14044-44104 [EnGenius Technologies, Inc. EWS1200-28TFP v1.07.22_c1.9.21_181018-0228]
    [*] ETag: 14044-32589 [EnGenius Technologies, Inc. EWS1200-28TFP v1.06.21_c1.8.77_180906-0716]
    [*] ETag: 609-31457   [NETGEAR Inc. GS750E ProSAFE Plus Switch v1.0.0.22]
    [*] ETag: 639-98866   [NETGEAR Inc. GS728TPv2, GS728TPPv2, GS752TPv2, GS752TPP v6.0.0.45]
    [*] ETag: 639-73124   [NETGEAR Inc. GS728TPv2, GS728TPPv2, GS752TPv2, GS752TPP v6.0.0.37]
    
    
    [*] All done...
    
    [Other vendors]
    These names have been found within some Firmware images, but not implemented as I have not found any Firmware 
images.
    (However, I suspect they use exact same Firmware due to the traces are 'logo[1-10].jpg/login[1-10].jpg')
    
    [*] 3One Data Communication, Saitian, Sangfor, Sundray, Gigamedia, GetCK, Hanming Technology, Wanbroad, Plexonics, 
Mach Power
    
    [Known bugs]
    1.  Non-JSON:
        '/mntlog/flash.log' and '/var/log/flash.log' not always removed when using 'stack_cgi_log()'
        (Must change value for 'flash.log' that needs to be 0x02, 'flash.log' has value 0x00)
    
    [Responsible Disclosure]
    Working with VDOO since early February 2019 to disclosure found vulnerabilities to vendors
    https://www.vdoo.com/blog/disclosing-significant-vulnerabilities-network-switches
    
    PoC:
    https://github.com/mcw0/PoC/blob/master/Realtek-RTL83xx-PoC.py
    
    Have a nice day
    /bashis
    
    [EOT]
    
    
    


_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/


Current thread: