[[345608]]

今年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消息并從服務器獲得身份驗證質詢。

request      admin 

服務器響應與三個值的請求：Challenge，Cookie和PublicKey

OK      rEmNZG3LUDFUSMJHU55P      uidpiK0+      vq1w3gFhoIAlc38rEVLO      0 

客戶端必須首先將PublicKey和用戶密碼結合在一起以創建一個PrivateKey。請注意這一點，因為它將在以后變得很重要。然后，客戶端將使用新生成的PrivateKey和Challenge來生成新值。客戶端將此值放在消息的LoginPassword字段中，login作為對服務器發出的質詢的響應：

login      admin      ........ 

服務器可以通過獨立計算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。但是，當攻擊者

request        Admin                Username 

以下是生成研究人員提供的身份驗證質詢值的函數的Ghidra的反編譯器輸出：

undefined4 Request(char **param_1,undefined4 param_2,undefined4 param_3,undefined4 param_4) // offset 0x004206c0 
 
{ 
  int iVar1; 
  char *Username; 
  char *Captcha; 
  char *PrivateLogin; 
  size_t size; 
  undefined4 uVar2; 
  undefined *Uid; 
  char *__nptr; 
  int local_1a8; 
  char Challenge [64]; 
  undefined Uuid [64]; 
  char Publickey [64]; 
  char Password [64]; 
  char PrivateKey [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);  // Get PrivateLogin element 
    __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); 
        return 0; 
      }    
      FUN_0042115c(local_1a8); 
    }    
    Randombyte(Challenge,0x14); 
    Randombyte(Uuid,10); 
    Randombyte(Publickey,0x14); 
//  If PrivateLogin != NULL && PrivateLogin  == "Username"  Then Password = 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; 
  } 
  return uVar2; 
} 

在第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如若轉載，請注明原文地址。