prog.cgi on D-Link DIR-3060 devices before 1.11b04 HF2 allows remote authenticated users to inject arbitrary commands in an admin or root context because SetVirtualServerSettings calls CheckArpTables, which calls popen unsafely.
{"zdt": [{"lastseen": "2021-09-22T22:28:33", "description": "", "cvss3": {"exploitabilityScore": 2.8, "cvssV3": {"baseSeverity": "HIGH", "confidentialityImpact": "HIGH", "attackComplexity": "LOW", "scope": "UNCHANGED", "attackVector": "NETWORK", "availabilityImpact": "HIGH", "integrityImpact": "HIGH", "baseScore": 8.8, "privilegesRequired": "LOW", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H", "userInteraction": "NONE", "version": "3.1"}, "impactScore": 5.9}, "published": "2021-03-13T00:00:00", "type": "zdt", "title": "D-Link DIR-3060 1.11b04 Command Injection Vulnerability", "bulletinFamily": "exploit", "cvss2": {"severity": "HIGH", "exploitabilityScore": 8.0, "obtainAllPrivilege": false, "userInteractionRequired": false, "obtainOtherPrivilege": false, "cvssV2": {"accessComplexity": "LOW", "confidentialityImpact": "COMPLETE", "availabilityImpact": "COMPLETE", "integrityImpact": "COMPLETE", "baseScore": 9.0, "vectorString": "AV:N/AC:L/Au:S/C:C/I:C/A:C", "version": "2.0", "accessVector": "NETWORK", "authentication": "SINGLE"}, "acInsufInfo": false, "impactScore": 10.0, "obtainUserPrivilege": false}, "cvelist": ["CVE-2021-28144"], "modified": "2021-03-13T00:00:00", "id": "1337DAY-ID-35942", "href": "https://0day.today/exploit/description/35942", "sourceData": "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\r\n title: Authenticated Command Injection in D-Link DIR-3060 Web \r\n Interface \r\n vendor/product: D-Link DIR-3060 (https://www.dlink.com/)\r\n vulnerable version: v1.11b04 & Below\r\n fixed version: v1.11b04 Hotfix 2\r\n CVE number: CVE-2021-28144\r\n impact: 8.8 (high) CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\r\n\r\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\r\n\r\nVendor description:\r\n-------------------\r\nD-Link Corporation is a Taiwanese multinational networking equipment \r\nmanufacturing corporation. The DIR-3060 (also known as the EXO AC3000 Smart \r\nMesh Wi-Fi Router) is one of their higher-end home/small business routers. \r\n\r\n\r\nVulnerability overview/description:\r\n-----------------------------------\r\nThe D-Link DIR-3060 is affected by a post-authentication command injection\r\nvulnerability. Any person who is able to gain authenticated access to a \r\nDIR-3060 would be able to run arbitrary system commands on the device as the \r\nsystem \"admin\" user, with root privileges. \r\n\r\n\r\nProof of concept:\r\n-----------------\r\nWhen a SOAP request is made to the SetVirtualServerSettings SOAP endpoint, the\r\nfunction at 00461918 in prog.cgi is invoked. This function traverses the SOAP\r\nXML request body, stores expected SOAP field values, and takes different paths\r\ndepending on the values. \r\n\r\nIf a request with a non-null LocalIPAddress, Enabled set to \u201ctrue\u201d, an \r\nInternalPort of \u201c9\u201d and a ProtocolType of \u201cUDP\u201d is sent, the function \r\nCheckArpTables (named by me, based at 0046163c) is invoked.\r\n\r\n// ...snip \r\n iVar5 = strcmp(Enabled,\"true\"); \r\n if ((((iVar5 == 0) && (LocalIPAddress != (char *)0x0)) && \r\n (iVar5 = strcmp(InternalPort,\"9\"), iVar5 == 0)) && \r\n (iVar5 = strcmp(ProtocolType,\"UDP\"), iVar5 == 0)) { \r\n local_4154 = local_4154 + 1; \r\n iVar5 = CheckArpTables(LocalIPAddress, InternalPort, ProtocolType, 0xdc, local_4154); \r\n if (iVar5 == -1) { \r\n local_4160 = 0xb; \r\n goto LAB_00462504; \r\n } \r\n } \r\n// ...snip\r\n\r\nInterestingly, UDP/9 correlates to the canonical Discard Protocol, which is the\r\nTCP/UDP/IP equivalent of /dev/null. \r\n\r\nThe CheckArpTables() function attempts to check the device ARP records, by \r\ncalling the arp system command and grep\u2019ing the output. However, the user-\r\ncontrolled value passed as the LocalIPAddress is written directly into the \r\ncommand line format string with snprint(). This string is then passed directly\r\nto a function called FCGI_popen(), which is a library function imported from \r\nlibfcgi.so.\r\n\r\nundefined CheckArpTables(char *LocalIPAddress, char *InternalPort, char *ProtocolType, undefined param_4, int param_5) {\r\n // ...snip...\r\n memset(buffer, 0, 0x40);\r\n // ...snip...\r\n snprintf(buffer, 0x40, \"arp | grep %s | awk \\'{printf $4}\\'\", LocalIPAddress);\r\n iVar1 = FCGI_popen(buffer, \"r\");\r\n // ...snip... \r\n}\r\n\r\nWe can see in libfcgi.so that FCGI_popen() is essentially only a thin wrapper \r\naround the stdio popen() library function. Arguments passed to FCGI_popen() \r\nget passed directly to popen().\r\n\r\n\r\nint FCGI_popen(char *param_1, char *param_2) \r\n{\r\n FILE *__stream; \r\n int iVar1; \r\n __stream = popen(param_1,param_2); \r\n iVar1 = FCGI_OpenFromFILE(__stream); \r\n if ((__stream != (FILE *)0x0) && (iVar1 == 0)) { \r\n pclose(__stream); \r\n } \r\n return iVar1; \r\n}\r\n\r\nSince the LocalIPAddress value is not sanitized or checked in any way, a \r\ncrafted command injection string can be passed as the LocalIPAddress, which \r\nwill then be written to the arp command format string, and passed (almost) \r\ndirectly to popen(). \r\n\r\n\r\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\r\n\r\nVulnerable / tested versions:\r\n-----------------------------\r\nDIR-3060 v1.11b04\r\n\r\n\r\nSolution:\r\n---------\r\nApply D-Link-supplied patch, v1.11b04 Hotfix 2.\r\n\r\n\r\nAdvisory URL:\r\n-------------\r\nhttps://www.iot-inspector.com/blog/advisory-d-link-dir-3060/\n\n# 0day.today [2021-09-23] #", "sourceHref": "https://0day.today/exploit/35942", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}}], "packetstorm": [{"lastseen": "2021-03-12T16:17:19", "description": "", "cvss3": {}, "published": "2021-03-12T00:00:00", "type": "packetstorm", "title": "D-Link DIR-3060 1.11b04 Command Injection", "bulletinFamily": "exploit", "cvss2": {}, "cvelist": ["CVE-2021-28144"], "modified": "2021-03-12T00:00:00", "id": "PACKETSTORM:161757", "href": "https://packetstormsecurity.com/files/161757/D-Link-DIR-3060-1.11b04-Command-Injection.html", "sourceData": "`IoT Inspector Research Lab Security Advisory IOT-20210311-0 \n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \ntitle: Authenticated Command Injection in D-Link DIR-3060 Web \nInterface \nvendor/product: D-Link DIR-3060 (https://www.dlink.com/) \nvulnerable version: v1.11b04 & Below \nfixed version: v1.11b04 Hotfix 2 \nCVE number: CVE-2021-28144 \nimpact: 8.8 (high) CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H \nreported: 2020-11-27 \npublication: 2021-03-11 \nby: T Shiomitsu, IoT Inspector Research Lab \nhttps://www.iot-inspector.com/ \n \n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \n \nVendor description: \n------------------- \nD-Link Corporation is a Taiwanese multinational networking equipment \nmanufacturing corporation. The DIR-3060 (also known as the EXO AC3000 Smart \nMesh Wi-Fi Router) is one of their higher-end home/small business routers. \n \n \nVulnerability overview/description: \n----------------------------------- \nThe D-Link DIR-3060 is affected by a post-authentication command injection \nvulnerability. Any person who is able to gain authenticated access to a \nDIR-3060 would be able to run arbitrary system commands on the device as the \nsystem \"admin\" user, with root privileges. \n \n \nProof of concept: \n----------------- \nWhen a SOAP request is made to the SetVirtualServerSettings SOAP endpoint, the \nfunction at 00461918 in prog.cgi is invoked. This function traverses the SOAP \nXML request body, stores expected SOAP field values, and takes different paths \ndepending on the values. \n \nIf a request with a non-null LocalIPAddress, Enabled set to \u0093true\u0094, an \nInternalPort of \u00939\u0094 and a ProtocolType of \u0093UDP\u0094 is sent, the function \nCheckArpTables (named by me, based at 0046163c) is invoked. \n \n// ...snip \niVar5 = strcmp(Enabled,\"true\"); \nif ((((iVar5 == 0) && (LocalIPAddress != (char *)0x0)) && \n(iVar5 = strcmp(InternalPort,\"9\"), iVar5 == 0)) && \n(iVar5 = strcmp(ProtocolType,\"UDP\"), iVar5 == 0)) { \nlocal_4154 = local_4154 + 1; \niVar5 = CheckArpTables(LocalIPAddress, InternalPort, ProtocolType, 0xdc, local_4154); \nif (iVar5 == -1) { \nlocal_4160 = 0xb; \ngoto LAB_00462504; \n} \n} \n// ...snip \n \nInterestingly, UDP/9 correlates to the canonical Discard Protocol, which is the \nTCP/UDP/IP equivalent of /dev/null. \n \nThe CheckArpTables() function attempts to check the device ARP records, by \ncalling the arp system command and grep\u0092ing the output. However, the user- \ncontrolled value passed as the LocalIPAddress is written directly into the \ncommand line format string with snprint(). This string is then passed directly \nto a function called FCGI_popen(), which is a library function imported from \nlibfcgi.so. \n \nundefined CheckArpTables(char *LocalIPAddress, char *InternalPort, char *ProtocolType, undefined param_4, int param_5) { \n// ...snip... \nmemset(buffer, 0, 0x40); \n// ...snip... \nsnprintf(buffer, 0x40, \"arp | grep %s | awk \\'{printf $4}\\'\", LocalIPAddress); \niVar1 = FCGI_popen(buffer, \"r\"); \n// ...snip... \n} \n \nWe can see in libfcgi.so that FCGI_popen() is essentially only a thin wrapper \naround the stdio popen() library function. Arguments passed to FCGI_popen() \nget passed directly to popen(). \n \n \nint FCGI_popen(char *param_1, char *param_2) \n{ \nFILE *__stream; \nint iVar1; \n__stream = popen(param_1,param_2); \niVar1 = FCGI_OpenFromFILE(__stream); \nif ((__stream != (FILE *)0x0) && (iVar1 == 0)) { \npclose(__stream); \n} \nreturn iVar1; \n} \n \nSince the LocalIPAddress value is not sanitized or checked in any way, a \ncrafted command injection string can be passed as the LocalIPAddress, which \nwill then be written to the arp command format string, and passed (almost) \ndirectly to popen(). \n \n \n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \n \nVulnerable / tested versions: \n----------------------------- \nDIR-3060 v1.11b04 \n \n \nSolution: \n--------- \nApply D-Link-supplied patch, v1.11b04 Hotfix 2. \n \n \nAdvisory URL: \n------------- \nhttps://www.iot-inspector.com/blog/advisory-d-link-dir-3060/ \n \n \nVendor contact timeline: \n------------------------ \n2020-11-16: Initial contact made to ipsecure@dlinkcorp.com to request keys for \nencryption. \n2020-11-20: No reply received, so follow-up e-mail sent. \n2020-11-27: No reply received, so advisory sent by e-mail without encryption. \n2021-02-03: No reply received, so follow-up e-mail sent. \n2021-02-12: No reply received, so inquiry sent using the forms at \nsupport.dlink.com and eu.dlink.com/uk/en/contact-d-link. \n2021-02-17: Response from the US D-Link support team, pointing us towards the \nUS-specific D-Link security page. \n2021-02-17: Sent e-mail to this new US-specific D-Link security e-mail address. \n2021-02-19: Response from a member of the D-Link USA SIRT. \n2021-02-19: We request a public key from D-Link USA for transmission of the \nadvisory. \n2021-02-19: PGP public key is provided by D-Link USA. \n2021-02-19: Advisory is sent to D-Link USA with encryption. \n2021-02-19: Receipt of advisory is confirmed by D-Link USA SIRT. \n2021-02-19: We reply and ask for D-Link USA to keep us updated. \n2021-02-20: D-Link \u0093ipsecure\u0094 finally answers our e-mail, saying that \nsecurity@dlink.com should be the official e-mail, and the \nipsecure@dlinkcorp.com e-mail (the only one listed on the main \nD-Link security disclosure page) is only a backup address. \n2021-02-22: D-Link USA responds, confirming that the e-mail address listed \non the main D-Link security page has been changed. \n2021-03-02: We e-mail D-Link USA to ask for a status update. \n2021-03-02: D-Link USA responds with status update. \n2021-03-08: D-Link USA provides patched firmware for testing. \n2021-03-08: We respond asking for assigned CVE number. \n2021-03-08: D-Link USA notes that they do not apply for, or manage CVE numbers \nrelated to their own products. \n2021-03-08: We apply for a CVE number for this issue. \n2021-03-08: D-Link USA publishes public advisory. \n2021-03-11: CVE is assigned & IoT Inspector Research Lab publishes advisory. \n \n \n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \n \nThe IoT Inspector Research Lab is an integrated part of IoT Inspector. \n \nIoT Inspector is a platform for automated security analysis and compliance \nchecks of IoT firmware. Our mission is to secure the Internet of Things. In \norder to discover vulnerabilities and vulnerability patterns within IoT devices \nand to further enhance automated identification that allows for scalable \ndetection within IoT Inspector, we conduct excessive security research in the \narea of IoT. \n \nWhenever the IoT Inspector Research Lab discovers vulnerabilities in IoT \nfirmware, we aim to responsibly disclose relevant information to the vendor \nof the affected IoT device as well as the general public in a way that \nminimizes potential harm and encourages further security analyses of IoT \nsystems. \n \nYou can find our responsible disclosure policy here: \nhttps://www.iot-inspector.com/responsible-disclosure-policy/ \n \n \n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ \n \nInterested in using IoT Inspector for your research or product? \n \nMail: research at iot-inspector dot com \nWeb: https://www.iot-inspector.com \nBlog: https://www.iot-inspector.com/blog/ \nTwitter: https://twitter.com/iotinspector \n \nEOF T Shiomitsu / @2021 \n \n \n`\n", "sourceHref": "https://packetstormsecurity.com/files/download/161757/IOT-20210311-0.txt", "cvss": {"score": 0.0, "vector": "NONE"}}], "seebug": [{"lastseen": "2021-07-24T16:12:31", "description": "# Advisory: D-Link DIR-3060 Authenticated RCE (CVE-2021-28144)\n\nMARCH 11, 2021\n\n# **Overview** \n\nThe [D-Link DIR-3060](https://www.dlink.com/en/products/dir-3060-exo-ac3000-smart-mesh-wi-fi-router) (running firmware versions below v1.11b04) is affected by a post-authentication command injection vulnerability. Anybody with authenticated access to a DIR-3060 would be able to run arbitrary system commands on the device as the system \u201cadmin\u201d user, with root privileges. D-Link has released a patched firmware version [v1.11b04 Hotfix 2](https://supportannouncement.us.dlink.com/announcement/publication.aspx?name=SAP10208) to address this issue. Affected users are advised to apply the patch.\n\n| Affected vendor & product | D-Link DIR-3060 ([www.dlink.com](https://www.dlink.com/)) |\n| ------------------------- | ------------------------------------------------------------ |\n| Vulnerable version | v1.11b04 & below |\n| Fixed version | [v1.11b04 Hotfix 2](https://supportannouncement.us.dlink.com/announcement/publication.aspx?name=SAP10208) |\n| CVE Number | CVE-2021-28144 |\n| Impact | 8.8 (high) [CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator?vector=AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H&version=3.1) |\n| Credit | T. Shiomitsu, IoT Inspector Research Lab |\n\n# **Vulnerable Component** \n\nWeb management functionality on the DIR-3060 is mainly handled by the `prog.cgi` binary. The `lighttpd` `fastcgi` server configuration is such that requests made to `/HNAP1/` or files with the `.fcgi` extension are handled by `/etc_ro/lighttpd/www/web/HNAP1/prog.fcgi`, which is a symlink to `/bin/prog.cgi`.\n\n \n\n```\n// ... \n\nfastcgi.server = ( \n\n\u200b \"/HNAP1/\" => \n\n\u200b (( \n\n\u200b \"socket\" => \"/var/prog.fcgi.socket-0\", \n\n\u200b \"check-local\" => \"enable\", \n\n\u200b \"bin-path\" => \"/etc_ro/lighttpd/www/web/HNAP1/prog.fcgi\", \n\n\u200b \"idle-timeout\" => 10, \n\n\u200b \"min-procs\" => 1, \n\n\u200b \"max-procs\" => 2 \n\n\u200b )), \n\n\u200b \".fcgi\" => \n\n\u200b (( \n\n\u200b \"socket\" => \"/var/prog.fcgi.socket-0\", \n\n\u200b \"check-local\" => \"enable\", \n\n\u200b \"bin-path\" => \"/etc_ro/lighttpd/www/web/HNAP1/prog.fcgi\", \n\n\u200b \"idle-timeout\" => 10, \n\n\u200b \"min-procs\" => 1, \n\n\u200b \"max-procs\" => 2 \n\n\u200b )), \n\n\u200b \"/common/\" => \n\n\u200b (( \n\n\u200b \"socket\" => \"/var/myinfo.fcgi.socket-0\", \n\n\u200b \"check-local\" => \"disable\", \n\n\u200b \"bin-path\" => \"/sbin/myinfo.cgi\", \n\n\u200b \"idle-timeout\" => 10, \n\n\u200b \"min-procs\" => 1, \n\n\u200b \"max-procs\" => 1 \n\n\u200b )) \n\n) \n\n// ...\n```\n\n\n\nBy default, configuration changes are made by issuing SOAP requests to the web management interface at `http://[ROUTER]/HNAP1/` \u2013 these are then all then handled by `prog.cgi`. \n\n# **The** **Vulnerability** \n\nWhen a SOAP request is made to the `SetVirtualServerSettings` SOAP endpoint, the function at `00461918` in `prog.cgi` is invoked. This function traverses the SOAP XML request body, stores expected SOAP field values, and takes different paths depending on the values. \n\nIf a request with a non-null `LocalIPAddress`, `Enabled` set to \u201ctrue\u201d, an `InternalPort` of \u201c9\u201d and a `ProtocolType` of \u201cUDP\u201d is sent, the function `CheckArpTables` (named by me, based at `0046163c`) is invoked.\n\n \n\n```\n// ...snip \n\n\u200b iVar5 = strcmp(Enabled,\"true\"); \n\n\u200b **if** ((((iVar5 == 0) && (LocalIPAddress != (**char** *)*0x0*)) && \n\n\u200b (iVar5 = strcmp(InternalPort,\"9\"), iVar5 == 0)) && \n\n\u200b (iVar5 = strcmp(ProtocolType,\"UDP\"), iVar5 == 0)) { \n\n\u200b local_4154 = local_4154 + 1; \n\n\u200b iVar5 = CheckArpTables(LocalIPAddress, InternalPort, ProtocolType, *0xdc*, local_4154); \n\n\u200b **if** (iVar5 == -1) { \n\n\u200b local_4160 = *0xb*; \n\n\u200b **goto** LAB_00462504; \n\n\u200b } \n\n\u200b } \n\n// ...snip\n```\n\n\n\nInterestingly, UDP/9 correlates to the canonical [Discard Protocol](https://en.wikipedia.org/wiki/Discard_Protocol), which is the TCP/UDP/IP equivalent of `/dev/null`. \n\nThe `CheckArpTables()` function attempts to check the device ARP records, by calling the `arp` system command and `grep`\u2019ing the output. However, the user-controlled value passed as the `LocalIPAddress` is written directly into the command line format string with `snprint()`. This string is then passed directly to a function called `FCGI_popen()`, which is a library function imported from `libfcgi.so`.\n\n \n\n```\nundefined CheckArpTables(**char** *LocalIPAddress, **char** *InternalPort, **char** *ProtocolType, undefined param_4, **int** param_5) {\n\n\u200b // ...snip...\n\n\u200b memset(buffer, 0, *0x40*);\n\n\u200b // ...snip...\n\n\u200b snprintf(buffer, *0x40*, \"arp | grep %s | awk \\'{printf $4}\\'\", LocalIPAddress);\n\n\u200b iVar1 = FCGI_popen(buffer, \"r\");\n\n\u200b // ...snip... \n\n}\n```\n\n\n\nWe can see in `libfcgi.so` that `FCGI_popen()` is essentially only a thin wrapper around the stdio `popen()` library function. Arguments passed to `FCGI_popen()` get passed directly to `popen()`.\n\n \n\n```\n**int** FCGI_popen(**char** *param_1, **char** *param_2) \n\n{\n\n FILE *__stream; \n\n **int** iVar1; \n\n __stream = popen(param_1,param_2); \n\n iVar1 = FCGI_OpenFromFILE(__stream); \n\n **if** ((__stream != (FILE *)*0x0*) && (iVar1 == 0)) { \n\n\u200b pclose(__stream); \n\n } \n\n **return** iVar1; \n\n}\n```\n\n\n\nSince the `LocalIPAddress` value is not sanitized or checked in any way, a crafted command injection string can be passed as the `LocalIPAddress`, which will then be written to the `arp` command format string, and passed (almost) directly to `popen()`. \n\n# **Key Takeaways** \n\nAbstraction of common library functions with potential security implications is common in embedded device development. Many embedded developers attempt to do this in order to easily \u201cdrop-in\u201d common library functions with more secure analogues. \n\nHowever, D-Link, in this case, did not do this. They had abstracted (and used) the `FCGI_popen()` function as a drop-in replacement for `popen()` \u2013 presumably in order to ensure that the implementation could be standardized for code cleanliness (and perhaps security) purposes. However, there was no extra checking or sanitization in place in the actual `FCGI_popen()` function. Therefore, there was no particular security benefit to this abstraction. \n\nFrom our perspective (we\u2019re in the business of automating security analysis of embedded device firmware, in case you didn\u2019t know) this is an interesting case. Vendors often use such drop-in replacement functions, imported from external libraries. When running our automated security analyses of ELF executables, we have to take into account which imported functions are used within an ELF, as well as how exposed potentially dangerous library functions are within these functions. This can help us drill down more intentionally into these executables to flag potential security issues. This kind of automation can considerably speed up recognition of potential security issues. \n\n# **Disclosure Timeline** \n\n*2020-11-16*: Initial contact made to ipsecure@dlinkcorp.com to request keys for encryption.\n*2020-11-20*: No reply received, so follow-up e-mail sent.\n*2020-11-27*: No reply received, so advisory sent by e-mail without encryption.\n*2021-02-03*: No reply received, so follow-up e-mail sent.\n*2021-02-12*: No reply received, so inquiry sent using the forms at support.dlink.com and eu.dlink.com/uk/en/contact-d-link.\n*2021-02-17*: Response from the US D-Link support team, pointing us towards the US-specific D-Link security page.\n*2021-02-17*: Sent e-mail to this new US-specific D-Link security e-mail address.\n*2021-02-19*: Response from a member of the D-Link USA SIRT.\n*2021-02-19*: We request a public key from D-Link USA for transmission of the advisory.\n*2021-02-19*: PGP public key is provided by D-Link USA.\n*2021-02-19*: Advisory is sent to D-Link USA with encryption.\n*2021-02-19*: Receipt of advisory is confirmed by D-Link USA SIRT.\n*2021-02-19*: We reply and ask for D-Link USA to keep us updated.\n*2021-02-20*: D-Link \u201cipsecure\u201d finally answers our e-mail, saying that security@dlink.com should be the official e-mail, and the ipsecure@dlinkcorp.com e-mail (the only one listed on the main D-Link security disclosure page) is only a backup address.\n*2021-02-22*: D-Link USA responds, confirming that the e-mail address listed on the main D-Link security page has been changed.\n*2021-03-02*: We e-mail D-Link USA to ask for a status update.\n*2021-03-02*: D-Link USA responds with status update.\n*2021-03-08*: D-Link USA provides patched firmware for testing.\n*2021-03-08*: We respond asking for assigned CVE number.\n*2021-03-08*: D-Link USA notes that they do not apply for, or manage CVE numbers related to their own products.\n*2021-03-08*: We apply for a [CVE number](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-28144) for this issue.\n*2021-03-08*: [D-Link USA publishes public advisory](https://supportannouncement.us.dlink.com/announcement/publication.aspx?name=SAP10208).\n*2021-03-11*: CVE is assigned & IoT Inspector Research Lab publishes advisory.", "published": "2021-03-12T00:00:00", "type": "seebug", "title": "D-Link DIR-3060 \u6388\u6743RCE\u6f0f\u6d1e\uff08CVE-2021-28144\uff09", "bulletinFamily": "exploit", "cvelist": ["CVE-2021-28144"], "modified": "2021-03-12T00:00:00", "id": "SSV:99158", "href": "https://www.seebug.org/vuldb/ssvid-99158", "sourceData": "", "cvss": {"score": 9.0, "vector": "AV:N/AC:L/Au:S/C:C/I:C/A:C"}, "sourceHref": ""}]}
CVE-2021-28144
