最近在学习设备中的认证绕过漏洞，发现HNAP这个协议，思科太难搞了，刚好Dlink设备存在几个相关的漏洞，顺便就学习了。

D-Link DIR-882、DIR-878 和 DIR-867路由器

固件下载地址：https://tsd.dlink.com.tw
下载了DIR-878 v1.10设备的固件，这里有些版本的DLink固件要加密，但是我下载的时候并没有说这个是加密的，所以就不演示固件界面了，实际上，DIR设备的解密也非常简单，可看以下连接。
https://yjy123123.github.io/2021/05/28/D-Link-%E8%B7%AF%E7%94%B1%E5%99%A8%E5%9B%BA%E4%BB%B6%E8%A7%A3%E5%AF%86/
思路就是利用有解密模块的未加密固件进行解密。

0x01 CVE-2020-8864漏洞分析

系统在处理HNAP登录请求时，处理password存在固定缺席导致的未授权登录，攻击者可以利用此漏洞进行RCE。

1.1 HNAP协议

该协议过时，不用过多的理解，稍微了解就行了。
HNAP相关漏洞和基本资料
请求详情

第一步：发送登录请求，然后等回显。
请求的数据包格式如下：

Headers:
"Content-Type": "text/xml; charset=utf-8"
"SOAPAction": "http://purenetworks.com/HNAP1/Login"
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
<Login xmlns="http://purenetworks.com/HNAP1/">
  <Action>request</Action>
  <Username>admin</Username>
  <LoginPassword/>
  <Captcha/>
</Login>
  </soap:Body>
</soap:Envelope>

有SOAPAction头部，xml中有username。
响应数据

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
<LoginResponse xmlns="http://purenetworks.com/HNAP1/">
  <LoginResult>OK</LoginResult>
  <Challenge>........</Challenge>
  <Cookie>........</Cookie>
  <PublicKey>........</PublicKey>
</LoginResponse>
  </soap:Body>
</soap:Envelope>

返回challenge，cookie和public。其中cookie被用来作为http请求的cookie头，其他两个被用来加密password，作为http头中的HNAP_AUTH认证。

Headers:
"Content-Type": "text/xml; charset=utf-8"
"SOAPAction": "http://purenetworks.com/HNAP1/Login"
"HNAP_AUTH": "........"
"Cookie": "uid=........"
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
<Login xmlns="http://purenetworks.com/HNAP1/">
  <Action>login</Action>
  <Username>admin</Username>
  <LoginPassword>........</LoginPassword>
  <Captcha/>
</Login>
  </soap:Body>
</soap:Envelope>

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
<LoginResponse xmlns="http://purenetworks.com/HNAP1/">
  <LoginResult>success</LoginResult>
</LoginResponse>
  </soap:Body>
</soap:Envelope>

1.2 漏洞分析

可以通过grep定位关键字符串，找到漏洞程序为/bin/prog.cgi，在其中的sub_42141C，为关键的登录逻辑判断。

从未知的角度来看，我需要分析HNAP处理流程，自然还是从字符串下手，可以搜索LoginPassword之类的字符串。注意搜索的一定是response包里面的内容。
也可以搜到 bin/prog.cgi 和 bin/prog-cgi，逆向程序的时候，交叉应用，也很方便的找到了处理函数。
sub_424090函数中，明显是response包生成的过程

返回上一级函数可能就是处理的流程。最终找到websSecurityHandler函数，该函数是整个HNAP认证的开始，其调用的sub_423DF4函数是主要的认证函数。

sub_42141C函数中是漏洞出现的位置，进入login的逻辑之后，在其中发现一处关键比较点，如下：

使用nvram获取了登录状态，使用strncmp比较了密码，这里有个重要的漏洞pattern，
strncmp(x, y, strlen(y))，strlen遇到00截断，而其中的y代表输入的passwd，如果输入的是\x00，那么比较的就是前0位，即一位也不比较，这将strncmp返回0，所以这里就存在了非预期的登录成功。

CGI调试的时候，可以使用sh脚本，首先设置好环境变量，然后再去qemu开启调试比较合适。

0x02 CVE-2020-8863 漏洞分析

和8864是同样的设备，发生在request中，

进入之后，逻辑比较清晰，和上面那个漏洞一样。

一个关键的比较是，privatelogin这个节点里面，前八个字节如果是Username，那么就把传入的username当作是passwd，而else分支中，则是nvram函数从http_passwd中取出passwd。
继续看，似乎passwd被用来加密，最终结果传递到了a4。

继续跟踪这个变量。

在pub_key未初始化的时候，初始化v24，然后传给pub_key，且预言家说，要看一下a4这个参数，函数的第四个参数 第四个参数最终传入sub_41EA9C(a1, (int)v23);函数，函数中，把这个参数也就是v23，指针赋给了a1+212。最后在sub_424090(a1, 0);函数中，注意到生成的challenge之类的。

来自于上面几个变量，进去看，发现大都一致。

只是strcmp比较不同，这里专门看了public_key的，如果i[8]一样，那么返回i[9]。
综上，总结出，最后的challenge，cookie，public_key分别是 sub_41F430函数的第345个参数。

所以说，正常来看，public_key由http_psswd生成，但是控制这个private_login则可以自己生成，那么用户完全可以自己构造响应数据包，响应认证，即可完成登录。

感觉这个漏洞像个预留的后门，不像是代码上的失误。以上几个漏洞呢，也是了解到了strncmp函数存在的某些bug，测试了strcmp，不可以输入\x00字符，所以应该是不存在类似bug的。
疑惑的还是第二个漏洞，private-login明显是添加上去的，普遍性不高吧，（还是感觉这样的洞有点离谱。

此外该设备还存在许多命令注入的漏洞，但不是学习的重点，稍微了解了一下就没有继续分析了。