黑客24小时在线接单网站

黑客24小时在线接单网站,黑客网站入口,黑客接单入口,黑客攻击

2022年04月08日 12:02:00

对两个D-Link路由器身份验证绕过漏洞的分析

今年2月，D-Link发布了 针对两个身份验证绕过漏洞CVE-2020-8863 和 CVE-2020-8864的固件 补丁程序，这些漏洞 影响了D-Link DIR-882，DIR-878和DIR-867路由器。这些漏洞存在于HNAP协议的处理中。

https://supportannouncement.us.dlink.com/announcement/publication.aspx?name=SAP10157

我们将首先研究CVE-2020-8863，以熟悉HNAP的身份验证方案。在那之后，我们将分析比较奇怪的CVE-2020-8864，它上面写有“backdoor”一词。

0x01 HNAP是什么

HNAP或家庭网络管理协议，是Pure Networks，Inc.发明的一种专有的基于SOAP的协议，后来被Cisco收购。该协议可以追溯到2007年，可以被认为是UPnP的直接竞争对手。该协议的主要用户是Cisco和D-Link。但是，两者都分别在2012年和2016年停止使用此协议 。该功能通常在管理面板中隐藏，因此无法禁用。如果你的路由器仍支持HNAP，则可能意味着你的路由器需要升级。

作为一种过时的专有协议，Internet上很少有相关文档。HNAP提供两种类型的身份验证方案：基本和基于HMAC。我可以找到的有关基于HMAC的身份验证方案的最佳文档是来自逆向项目的Github Wiki页面。

0x02 HNAP认证过程

对服务器（路由器）的身份验证需要两个事务。首先，客户端发送一条request消息并从服务器获得身份验证质询。

  • requestadmin

    • 服务器响应与三个值的请求：Challenge，Cookie和PublicKey

  • OKrEmNZG3LUDFUSMJHU55PuidpiK0+vq1w3gFhoIAlc38rEVLO0

    • 客户端必须首先将PublicKey和用户密码结合在一起以创建一个PrivateKey。请注意这一点，因为它将在以后变得很重要。然后，客户端将使用新生成的PrivateKey和Challenge来生成新值。客户端将此值放在消息的LoginPassword字段中，login作为对服务器发出的质询的响应：

  • loginadmin........

    • 服务器可以通过独立计算PrivateKey并LoginPassword使用记录的用户帐户密码，计算对Challenge的预期响应并将其与LoginPassword客户端提供的密码进行比较，从而对客户端进行身份验证。如果值匹配，则客户端已成功认证自己。

    0x03 CVE-2020-8864

    此身份验证绕过漏洞是由于不正确地使用strncmp()来将服务器计算出的值LoginPassword与LoginPassword客户端提供的值进行比较而引起的。下面是漏洞函数的控制流程图：

    查看全图

    图1-CVE-2020-8864的漏洞函数的控制流程图

    本质上，控制流程图的上述部分描述了以下常见的易受攻击的代码模式：

  • strncmp（db_password，attacker_provided_password，strlen（attacker_provided_password））;

    • 当attacker_provided_password为空字符串时，strlen()返回0。然后，由于strncmp()使用长度参数0调用了它，因此它根本不比较任何字符。而是返回值0，表示相等。在CVE-2020-8864中，如果攻击者提供一个空LoginPassword值，strncmp()则将返回0并遵循代码路径进行成功的身份验证。

    0x04 CVE-2020-8863

    该漏洞的标题为：

    D-Link多个路由器HNAP PrivateLogin身份验证算法的错误实现身份验证绕过漏洞

    “ PrivateLogin”一词比较有意思。让我们看一下路由器如何处理HNAP登录请求，以了解如何用几行代码实现此PrivateLogin后门。

    通过HNAP进行身份验证时，服务器通常会根据用户密码生成PrivateKey。但是，当攻击者

  • requestAdminUsername

    • 以下是生成研究人员提供的身份验证质询值的函数的Ghidra的反编译器输出：

  • undefined4Request(char**param_1,undefined4param_2,undefined4param_3,undefined4param_4)//offset0x004206c0
  • {
  • intiVar1;
  • char*Username;
  • char*Captcha;
  • char*PrivateLogin;
  • size_tsize;
  • undefined4uVar2;
  • undefined*Uid;
  • char*__nptr;
  • intlocal_1a8;
  • charChallenge[64];
  • undefinedUuid[64];
  • charPublickey[64];
  • charPassword[64];
  • charPrivateKey[132];
  • memset(Challenge,0,0x40);
  • memset(Uuid,0,0x40);
  • memset(Publickey,0,0x40);
  • memset(Password,0,0x40);
  • uVar2=0x80;
  • memset(PrivateKey,0,0x80);
  • iVar1=FUN_00421a44(param_1);
  • if(iVar1==0){
  • webGetVarString(param_1,"/Login/Action",uVar2,param_4);
  • Username=(char*)webGetVarString(param_1,"/Login/Username",uVar2,param_4);
  • webGetVarString(param_1,"/Login/LoginPassword",uVar2,param_4);
  • Captcha=(char*)webGetVarString(param_1,"/Login/Captcha",uVar2,param_4);
  • PrivateLogin=(char*)webGetVarString(param_1,"/Login/PrivateLogin",uVar2,param_4);//GetPrivateLoginelement
  • __nptr=(char*)nvram_safe_get("CAPTCHA");
  • iVar1=atoi(__nptr);
  • if((iVar1!=0)||(*Captcha!='')){
  • local_1a8=0;
  • while((local_1a8<gCntUid&&
  • (iVar1=strcmp(*(char**)(pgUidCaptMap+local_1a8*8),param_1[0x36]),iVar1!=0)))
  • {
  • local_1a8=local_1a8+1;
  • }
  • size=strlen(Captcha);
  • ToUpper(Captcha,size);
  • __nptr=*(char**)(pgUidCaptMap+local_1a8*8+4);
  • size=strlen(*(char**)(pgUidCaptMap+local_1a8*8+4));
  • ToUpper(__nptr,size);
  • iVar1=strcmp(*(char**)(pgUidCaptMap+local_1a8*8+4),Captcha);
  • if(iVar1!=0){
  • FUN_0042115c(local_1a8);
  • Login_Response(param_1,4);
  • return0;
  • }
  • FUN_0042115c(local_1a8);
  • }
  • Randombyte(Challenge,0x14);
  • Randombyte(Uuid,10);
  • Randombyte(Publickey,0x14);
  • //IfPrivateLogin!=NULL&&PrivateLogin=="Username"ThenPassword=Username
  • if((PrivateLogin==(char*)0x0)||(iVar1=strncmp(PrivateLogin,"Username",8),iVar1!=0)){
  • GetPassword(Password,0x40);
  • }
  • else{
  • strncpy(Password,Username,0x40);
  • }
  • //GenPrivateKey(Challenge,Password=username,PublicKey,PrivateKey,0x800;
  • GenPrivateKey(Challenge,Password,Publickey,PrivateKey,0x80);
  • __nptr=Challenge;
  • Uid=Uuid;
  • uVar2=SaveCookie(param_1,PrivateKey,__nptr,Uid,Publickey);
  • AddCookie(param_1,Uuid,__nptr,Uid);
  • Login_Response(param_1,0);
  • }
  • else{
  • Login_Response(param_1,5);
  • uVar2=1;
  • }
  • returnuVar2;
  • }

    • 在第31行，PrivateLogin从登录请求中提取元素的内容（如果存在），并将其存储在PrivateLogin变量中。该Username元件也提取并存储在所述Username可变上方的几行。

    PrivateLogin稍后在第58行使用该变量。if如果应用De Morgan定律，则可以更轻松地理解该条件。该条件检查该PrivateLogin元素是否存在，并进一步确保该PrivateLogin元素包含字符串“ Username”。如果两个条件都满足，则Username元素的值（即“ Admin”）将使用strncpy()复制到Password变量中。这与路由器调用GetPassword()以从NVRAM读取管理员密码的普通代码路径不同。

    在第65行，现在被污染的Password被传递到GenPrivateKey()，Challenge，Cookie和PublicKey值的验证Challenge。结果，攻击者现在知道了所有必需的值以重新创建PrivateKey并响应身份验证质询，而无需知道路由器的真实管理员密码。

    0x05 分析总结

    这个后门是如何进入产品的？开发人员为什么要编写这些代码行？它是制造商原始设计的一部分吗？还是这些代码行是由恶意员工编写的？为什么代码审计没有发现这一点？是否有 任何 代码审计流程？CVE-2020-8864是否 也有意编码为维持立足点的替代方法？我们没有上述任何问题的答案。但是，我们可以肯定地知道固件中存在此类漏洞是较大问题的征兆，并且与单纯提供补丁程序相比，对于卖方而言，它需要采取更多的措施。

    本文翻译自：https://www.thezdi.com/blog/2020/9/30/the-anatomy-of-a-bug-door-dissecting-two-d-link-router-authentication-bypasses如若转载，请注明原文地址。

    标签：漏洞 

    作者:访客 , 分类:在线接单的网站 , 浏览:998 , 评论:3

    • 评论列表:
    •  绿邪寻倌
       发布于 2022-05-29 16:43:50  回复该评论
    • allenge，Cookie和PublicKeyOKrEmNZG3LUDFUSMJHU55PuidpiK0+vq1w3gFhoIAlc38rEVLO0客户端必须首先将PublicKey和用户密码结合在一起以创建一个PrivateKey。请注意这一点，因为它将在以后变得很重要。然后
    •  鹿岛萌懂
       发布于 2022-05-29 20:17:48  回复该评论
    • param_4);PrivateLogin=(char*)webGetVarString(param_1,"/Login/PrivateLogin",uVar2,param_4);//GetPrivateLoginelement__nptr=(char*)nvram_safe
    •  世味胭话
       发布于 2022-05-29 09:58:25  回复该评论
    • )以从NVRAM读取管理员密码的普通代码路径不同。在第65行，现在被污染的Password被传递到GenPrivateKey()，Challenge，Cooki

    发表评论:

    Powered By

    Copyright Your WebSite.Some Rights Reserved.