如何运用D-Link高端路由器构建僵尸网络 (d-link配置)

整理分享如何运用D-Link高端路由器构建僵尸网络 (d-link配置)，希望有所帮助，仅作参考，欢迎阅读内容。

内容相关其他词:d-link配置,d link设置,d link设置,d—link怎么进入,d—link的管理app,d-link连接,d-link配置,d link设置,内容如对您有帮助，希望把内容链接给更多的朋友！

　　在本文中，我会向大家介绍D-Link高端路由器中存在的一些漏洞，受影响的路由器型号包括：　　DIRL　　DIRL　　DIRL　　其他DIR8xx型号的D-Link路由器　　这些设备运用了相同的代码，这就给攻击者提供了绝佳的机会，可以将这些设备一起纳入僵尸网络中。此外，我们稍微修改了Mirai的编译脚本，成功将Mirai移植到这些设备上。　　本文也会顺便说一下我们与开发者的交流过程（然而没有取得任何进展，这些漏洞依然没被修复）。这3个漏洞中，有2个漏洞与cgibin有关（cgibin是负责生成路由管理页面的主CGI文件），另一个漏洞与*恢复有关。　　二、窃取登录名及密码　　一句话概括：只需一个HTTP请求，攻击者就能获得登录名及密码。　　我们发现的第一个漏洞位于phpcgi中。Phpcgi是cgibin的符号链接，负责处理对.php、.asp以及.txt页面的请求。Phpcgi可以解析通过URL、HTTP头或者POST请求正文（body）发送的那些数据。Phpcgi会创建一个长字符串，该字符串随后会分解为若干组键值对（key-value），包括$GET、$POST、$SERVER字典以及其他php脚本变量都包含在这些键值对中。完成请求分析过程后，该符号链会检查用户的授权状态。如果用户未经授权，符号链会往字符串中添加值为-1的一个AUTHORIZED_GROUP变量。

　　从安全角度来看，这种解析过程存在一些问题。每个键值对（key-value）的编码形式为：TYPEKEY=VALUE，其中TYPE指代的是GET、POST、SERVER或其他值。编码完成后，键值对后会跟上换行符'\n'。

　　通过POST请求，我们可以运用SomeValue%3dAUTHORIZED_GROUP=1这个字符串实现添加值的目的。这个字符串会被设备解析为_GET_SomeKey=SomeValue\nAUTHORIZED_GROUP=1，通过这种方式，我们可以运用已授权用户身份运行脚本（尽管可运行脚本的数量有限）。向1http:/..0.1/getcfg.php*发送请求并添加SERVICES=DEVICE.ACOUNT键值对后，我们可以调用1/htdocs/webinc/getcfg/DEVICE.ACCOUNT.xml.php脚本，迫使路由器返回登录名及密码信息。

　　从设备代码中我们可以看出，攻击者可以运行位于/htdocs/webinc/getcfg目录中的脚本。这个目录中还包含一个DEVICE.ACCOUNT.xml.php脚本，可以为攻击者提供大量敏感信息，如设备的登录名及密码等信息。

　　换句话说，如果攻击者往　　1　　http:/..0.1/getcfg.php　　发送请求，同时添加SERVICES=DEVICE.ACOUNT键值对，那么设备在响应页面中就会包含相应的登录名及密码信息。　　对攻击者而言，获得这些信息已经足够，比如，攻击者可以运用登录凭证将自制的恶意固件刷到设备中。　　读者可以访问此链接了解完整的PoC代码。　　三、获得设备的超级用户权限（从RCE到Root）　　一句话概括：只需一个HTTP请求，攻击者就能获得设备的rootshell。　　第二个漏洞是个栈溢出漏洞，与HNAP（HomeNetworkAdministrationProtocol，家庭网络管理协议）的执行错误有关。　　如果想要运用该协议来发送消息，攻击者需要向　　1　　http:/..0.1/HNAP1/　　页面发送请求，并在SOAPACTION头部中指定请求的类型。设备对授权请求的处理过程存在漏洞。设备会运用　　1　　http:/purenetworks*/HNAP1/Login　　值来调用授权函数。攻击者可以在请求正文（body）中指定其他键值对（key-value），如Action、Username、LoginPassword以及Captcha（请求正文中事先已经包含一组预定义的值）。随后设备会运用html标签对这些值进行编码，编码结果如：value。

　　这里最主要的问题出现在提取键值对的那个函数上，设备在栈上运用了一个大小为0x字节的缓冲区用于提取键值对，然而，攻击者可以运用strncpy函数发送高达0x字节的数据，这样一来就会导致巨大的栈溢出问题。精心构造后，strncpy不仅会溢出当前的栈，也会溢出调用函数栈，因为“dest”变量最多能储存0x个字节的数据，而攻击者输入的值可达0x个字节。

　　此外，当函数退出时，R0寄存器中存在一个指向该字符串的指针。因此，攻击者可以指定一组sh命令，将返回*修改为“system”函数。经过这些步骤，设备已处于攻击者的掌控之下，任攻击者宰割。　　读者可以访问此链接了解完整的PoC代码。　　四、在恢复（Recovery）模式中更新固件　　一句话概括：只需一次重新启动，你就拥有root权限。　　第三个漏洞在于，当路由器启动时，会启动一个用于恢复模式的web服务器，连续几秒钟。如果未授权的攻击者通过以太网线连接到设备上，他们就可以抓住这个机会，利用该服务器更新设备固件。　　为了利用这个漏洞，攻击者唯一要做的就是重新启动目标设备，重新启动设备的方式有很多，攻击者可以运用上面提到的漏洞完成重新启动，也可以往jcpd服务发送“EXECREBOOTSYSTEM”命令完成重新启动。jcpd服务通过端口向本地网络提供服务，攻击者无需经过认证即可访问该服务，并且设备没有提供关闭该服务的任何选项，是非常完美的*作目标。为了完全控制目标设备，攻击者需要将自制的固件上传到设备中。　　读者可以访问此链接了解完整的PoC代码。　　五、时间线　　这里我想提一下我们跟D-Link安全团队的沟通过程，时间线如下：　　//：我们将hnap协议漏洞通知开发者。　　//：D-Link员工回复说他们已经在beta版的固件中修复了这个漏洞，我们可以从support.dlink*下载相应固件。（注：D-Link首页上没有固件下载这一栏）　　//–//：我们分析了D-Link在回复中提到的那个固件版本，发现我们通知开发者的某个漏洞依旧没有被修复。　　//–//：我们发现了固件中的另一个漏洞，通知D-Link并询问前一个漏洞的修复情况。他们回复称漏洞的检测、修复以及评估需要一段时间。　　//：我们将漏洞信息通知CERT，收到的回复如下：　　1　　2　　“向您问候并诚挚感谢您提交的漏洞报告。经过审查后，我们决定不处理该漏洞报告。我们建议您继续跟厂商沟通，再公开这些漏洞信息。”　　//：D-Link沉默了将近一个月，因此我们决定采取一些行动。我们警告D-Link，如果他们对这些漏洞放任不管，我们会向公众披露这些漏洞。　　//：D-Link在回复中提到了他们的漏洞响应过程，发送了一个beta版固件，在固件中修复了phpcgi漏洞。然而之前提交给D-Link的另一个漏洞依旧被开发者忽视了（可能D-Link安全团队依旧坚信他们已经在beta版固件中修复了这个漏洞）。　　我们再一次就未修复的漏洞联系D-Link。果不其然，我们没有得到任何回复。我们从开发者那边得到的最后一条回复如下：　　“首先向您问候，我们的研究团队正在研究您的漏洞报告。在理清漏洞来源、提供搞定方案及确定问题范围（我们需要确定漏洞影响的具体型号）之前，我们通常不会讨论具体的进展情况。　　本周初我们应该会发布一些更新包。　　关于您的研究工作我无法提供任何进展信息。一旦我们修复漏洞后，我们会在support.dlink*上公布经过第三方认证的具体信息。　　正如您看到的那样，通常情况下，漏洞的修复周期为好几个星期。经过验证后，我们会以beta版形式向公众提供固件，在公布RC版之前，我们还需要经过较长的质检周期。完整的发布周期通常需要天。　　如果您选择早点公布漏洞报告，请向我们提供具体的URL*。因为如果你希望该漏洞得到一个CVE编号，我们需要具体的报告作为参考。”　　8月中旬，我们访问support.dlink*，发现开发者上传了同一个beta版固件，该固件中仍有2个未修复。　　因此，我们的结论为：　　D-Link只在DIRL路由器中修复了一个漏洞，其他设备依旧处于不安全状态。开发者完全忽视了其他两个漏洞。我只能说，干得漂亮，D-Link！