[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[FD] Realtek Managed Switch Controller RTL83xx

    [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/