Dlink设备中的HNAP分析
漏洞分析
Dlink设备中HNAP数据处理漏洞分析
最近在学习设备中的认证绕过漏洞，发现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相关漏洞和基本资料](https://research.qianxin.com/archives/599) [请求详情](https://github.com/bikerp/dsp-w215-hnap/wiki/Authentication-process) 第一步：发送登录请求，然后等回显。 请求的数据包格式如下： ```c 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。 响应数据 ```c <?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认证。 ```xml 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 <?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明显是添加上去的，普遍性不高吧，（还是感觉这样的洞有点离谱。 此外该设备还存在许多命令注入的漏洞，但不是学习的重点，稍微了解了一下就没有继续分析了。
发表于 2022-08-16 09:28:10
阅读 ( 7652 )
分类：
漏洞分析
4 推荐
收藏
0 条评论
就叫16385吧
11 篇文章
×
温馨提示
您当前没有「奇安信攻防社区」的账号，注册后可获取更多的使用权限。
×
温馨提示
您当前没有「奇安信攻防社区」的账号，注册后可获取更多的使用权限。
×
举报此文章
垃圾广告信息：
广告、推广、测试等内容
违规内容：
色情、暴力、血腥、敏感信息等内容
不友善内容：
人身攻击、挑衅辱骂、恶意行为
其他原因：
请补充说明
举报原因:
×
如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！
