自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

對(duì)兩個(gè)D-Link路由器身份驗(yàn)證繞過(guò)漏洞的分析

安全 漏洞
今年2月,D-Link發(fā)布了 針對(duì)兩個(gè)身份驗(yàn)證繞過(guò)漏洞CVE-2020-8863 和 CVE-2020-8864的固件 補(bǔ)丁程序,這些漏洞 影響了D-Link DIR-882,DIR-878和DIR-867路由器。這些漏洞存在于HNAP協(xié)議的處理中。

[[345608]]

今年2月,D-Link發(fā)布了 針對(duì)兩個(gè)身份驗(yàn)證繞過(guò)漏洞CVE-2020-8863 和 CVE-2020-8864的固件 補(bǔ)丁程序,這些漏洞 影響了D-Link DIR-882,DIR-878和DIR-867路由器。這些漏洞存在于HNAP協(xié)議的處理中。

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

我們將首先研究CVE-2020-8863,以熟悉HNAP的身份驗(yàn)證方案。在那之后,我們將分析比較奇怪的CVE-2020-8864,它上面寫有“backdoor”一詞。

0x01 HNAP是什么

HNAP或家庭網(wǎng)絡(luò)管理協(xié)議,是Pure Networks,Inc.發(fā)明的一種專有的基于SOAP的協(xié)議,后來(lái)被Cisco收購(gòu)。該協(xié)議可以追溯到2007年,可以被認(rèn)為是UPnP的直接競(jìng)爭(zhēng)對(duì)手。該協(xié)議的主要用戶是Cisco和D-Link。但是,兩者都分別在2012年和2016年停止使用此協(xié)議 。該功能通常在管理面板中隱藏,因此無(wú)法禁用。如果你的路由器仍支持HNAP,則可能意味著你的路由器需要升級(jí)。

作為一種過(guò)時(shí)的專有協(xié)議,Internet上很少有相關(guān)文檔。HNAP提供兩種類型的身份驗(yàn)證方案:基本和基于HMAC。我可以找到的有關(guān)基于HMAC的身份驗(yàn)證方案的最佳文檔是來(lái)自逆向項(xiàng)目的 Github Wiki頁(yè)面。

0x02 HNAP認(rèn)證過(guò)程

對(duì)服務(wù)器(路由器)的身份驗(yàn)證需要兩個(gè)事務(wù)。首先,客戶端發(fā)送一條request消息并從服務(wù)器獲得身份驗(yàn)證質(zhì)詢。

  1. request      admin 

服務(wù)器響應(yīng)與三個(gè)值的請(qǐng)求:Challenge,Cookie和PublicKey

  1. OK      rEmNZG3LUDFUSMJHU55P      uidpiK0+      vq1w3gFhoIAlc38rEVLO      0 

客戶端必須首先將PublicKey和用戶密碼結(jié)合在一起以創(chuàng)建一個(gè)PrivateKey。請(qǐng)注意這一點(diǎn),因?yàn)樗鼘⒃谝院笞兊煤苤匾?。然后,客戶端將使用新生成的PrivateKey和Challenge來(lái)生成新值。客戶端將此值放在消息的LoginPassword字段中,login作為對(duì)服務(wù)器發(fā)出的質(zhì)詢的響應(yīng):

  1. login      admin      ........ 

服務(wù)器可以通過(guò)獨(dú)立計(jì)算PrivateKey并LoginPassword使用記錄的用戶帳戶密碼,計(jì)算對(duì)Challenge的預(yù)期響應(yīng)并將其與LoginPassword客戶端提供的密碼進(jìn)行比較,從而對(duì)客戶端進(jìn)行身份驗(yàn)證。如果值匹配,則客戶端已成功認(rèn)證自己。

0x03 CVE-2020-8864

此身份驗(yàn)證繞過(guò)漏洞是由于不正確地使用strncmp()來(lái)將服務(wù)器計(jì)算出的值LoginPassword與LoginPassword客戶端提供的值進(jìn)行比較而引起的。下面是漏洞函數(shù)的控制流程圖:

查看全圖

圖1-CVE-2020-8864的漏洞函數(shù)的控制流程圖

本質(zhì)上,控制流程圖的上述部分描述了以下常見(jiàn)的易受攻擊的代碼模式:

  1. strncmp(db_password,attacker_provided_password,strlen(attacker_provided_password)); 

當(dāng)attacker_provided_password為空字符串時(shí),strlen()返回0。然后,由于strncmp()使用長(zhǎng)度參數(shù)0調(diào)用了它,因此它根本不比較任何字符。而是返回值0,表示相等。在CVE-2020-8864中,如果攻擊者提供一個(gè)空LoginPassword值,strncmp()則將返回0并遵循代碼路徑進(jìn)行成功的身份驗(yàn)證。

0x04 CVE-2020-8863

該漏洞的標(biāo)題為:

D-Link多個(gè)路由器HNAP PrivateLogin身份驗(yàn)證算法的錯(cuò)誤實(shí)現(xiàn)身份驗(yàn)證繞過(guò)漏洞

“ PrivateLogin”一詞比較有意思。讓我們看一下路由器如何處理HNAP登錄請(qǐng)求,以了解如何用幾行代碼實(shí)現(xiàn)此PrivateLogin后門。

通過(guò)HNAP進(jìn)行身份驗(yàn)證時(shí),服務(wù)器通常會(huì)根據(jù)用戶密碼生成PrivateKey。但是,當(dāng)攻擊者

  1. request        Admin                Username 

以下是生成研究人員提供的身份驗(yàn)證質(zhì)詢值的函數(shù)的Ghidra的反編譯器輸出:

  1. undefined4 Request(char **param_1,undefined4 param_2,undefined4 param_3,undefined4 param_4) // offset 0x004206c0 
  2.  
  3.   int iVar1; 
  4.   char *Username; 
  5.   char *Captcha; 
  6.   char *PrivateLogin; 
  7.   size_t size
  8.   undefined4 uVar2; 
  9.   undefined *Uid; 
  10.   char *__nptr; 
  11.   int local_1a8; 
  12.   char Challenge [64]; 
  13.   undefined Uuid [64]; 
  14.   char Publickey [64]; 
  15.   char Password [64]; 
  16.   char PrivateKey [132]; 
  17.    
  18.   memset(Challenge,0,0x40); 
  19.   memset(Uuid,0,0x40); 
  20.   memset(Publickey,0,0x40); 
  21.   memset(Password,0,0x40); 
  22.   uVar2 = 0x80; 
  23.   memset(PrivateKey,0,0x80); 
  24.   iVar1 = FUN_00421a44(param_1); 
  25.   if (iVar1 == 0) { 
  26.     webGetVarString(param_1,"/Login/Action",uVar2,param_4); 
  27.     Username = (char *)webGetVarString(param_1,"/Login/Username",uVar2,param_4); 
  28.     webGetVarString(param_1,"/Login/LoginPassword",uVar2,param_4); 
  29.     Captcha = (char *)webGetVarString(param_1,"/Login/Captcha",uVar2,param_4); 
  30.     PrivateLogin = (char *)webGetVarString(param_1,"/Login/PrivateLogin",uVar2,param_4);  // Get PrivateLogin element 
  31.     __nptr = (char *)nvram_safe_get("CAPTCHA"); 
  32.     iVar1 = atoi(__nptr); 
  33.     if ((iVar1 != 0) || (*Captcha != '')) { 
  34.       local_1a8 = 0; 
  35.       while ((local_1a8 < gCntUid && 
  36.              (iVar1 = strcmp(*(char **)(pgUidCaptMap + local_1a8 * 8),param_1[0x36]), iVar1 != 0))) 
  37.       {    
  38.         local_1a8 = local_1a8 + 1; 
  39.       }    
  40.       size = strlen(Captcha); 
  41.       ToUpper(Captcha,size); 
  42.       __nptr = *(char **)(pgUidCaptMap + local_1a8 * 8 + 4);  
  43.       size = strlen(*(char **)(pgUidCaptMap + local_1a8 * 8 + 4)); 
  44.       ToUpper(__nptr,size); 
  45.       iVar1 = strcmp(*(char **)(pgUidCaptMap + local_1a8 * 8 + 4),Captcha); 
  46.       if (iVar1 != 0) { 
  47.         FUN_0042115c(local_1a8); 
  48.         Login_Response(param_1,4); 
  49.         return 0; 
  50.       }    
  51.       FUN_0042115c(local_1a8); 
  52.     }    
  53.     Randombyte(Challenge,0x14); 
  54.     Randombyte(Uuid,10); 
  55.     Randombyte(Publickey,0x14); 
  56. //  If PrivateLogin != NULL && PrivateLogin  == "Username"  Then Password = Username 
  57.     if ((PrivateLogin == (char *)0x0) || (iVar1 = strncmp(PrivateLogin,"Username",8), iVar1 != 0)) { 
  58.       GetPassword(Password,0x40); 
  59.     }    
  60.     else { 
  61.       strncpy(Password,Username,0x40); 
  62.     }    
  63. //  GenPrivateKey(Challenge, Password = username , PublicKey, PrivateKey, 0x800; 
  64.     GenPrivateKey(Challenge,Password,Publickey,PrivateKey,0x80); 
  65.     __nptr = Challenge; 
  66.     Uid = Uuid; 
  67.     uVar2 = SaveCookie(param_1,PrivateKey,__nptr,Uid,Publickey); 
  68.     AddCookie(param_1,Uuid,__nptr,Uid); 
  69.     Login_Response(param_1,0); 
  70.   } 
  71.   else { 
  72.     Login_Response(param_1,5); 
  73.     uVar2 = 1; 
  74.   } 
  75.   return uVar2; 

在第31行,PrivateLogin從登錄請(qǐng)求中提取元素的內(nèi)容(如果存在),并將其存儲(chǔ)在PrivateLogin變量中。該Username元件也提取并存儲(chǔ)在所述Username可變上方的幾行。

PrivateLogin稍后在第58行使用該變量。if如果應(yīng)用De Morgan定律,則可以更輕松地理解該條件。該條件檢查該P(yáng)rivateLogin元素是否存在,并進(jìn)一步確保該P(yáng)rivateLogin元素包含字符串“ Username”。如果兩個(gè)條件都滿足,則Username元素的值(即“ Admin”)將使用strncpy()復(fù)制到Password變量中。這與路由器調(diào)用GetPassword()以從NVRAM讀取管理員密碼的普通代碼路徑不同。

在第65行,現(xiàn)在被污染的Password被傳遞到GenPrivateKey(),Challenge,Cookie和PublicKey值的驗(yàn)證Challenge。結(jié)果,攻擊者現(xiàn)在知道了所有必需的值以重新創(chuàng)建PrivateKey并響應(yīng)身份驗(yàn)證質(zhì)詢,而無(wú)需知道路由器的真實(shí)管理員密碼。

0x05 分析總結(jié)

這個(gè)后門是如何進(jìn)入產(chǎn)品的?開(kāi)發(fā)人員為什么要編寫這些代碼行?它是制造商原始設(shè)計(jì)的一部分嗎?還是這些代碼行是由惡意員工編寫的?為什么代碼審計(jì)沒(méi)有發(fā)現(xiàn)這一點(diǎn)?是否有 任何 代碼審計(jì)流程?CVE-2020-8864是否 也有意編碼為維持立足點(diǎn)的替代方法?我們沒(méi)有上述任何問(wèn)題的答案。但是,我們可以肯定地知道固件中存在此類漏洞是較大問(wèn)題的征兆,并且與單純提供補(bǔ)丁程序相比,對(duì)于賣方而言,它需要采取更多的措施。

本文翻譯自:https://www.thezdi.com/blog/2020/9/30/the-anatomy-of-a-bug-door-dissecting-two-d-link-router-authentication-bypasses如若轉(zhuǎn)載,請(qǐng)注明原文地址。

 

責(zé)任編輯:姜華 來(lái)源: 嘶吼網(wǎng)
相關(guān)推薦

2021-07-19 10:10:15

身份驗(yàn)證漏洞Windows Hel

2009-11-27 15:06:15

2015-04-15 19:32:49

360

2015-03-04 11:06:13

2012-11-05 14:35:03

路由器BGP網(wǎng)絡(luò)協(xié)議

2009-12-04 14:04:44

2009-12-10 16:37:02

D-link路由器VP

2009-12-10 16:08:10

2015-04-30 19:02:11

2009-12-08 17:49:17

2009-08-18 14:16:36

2009-12-02 18:10:24

2009-12-10 17:12:58

2013-10-17 13:16:47

2022-09-07 11:51:04

惡意軟件漏洞網(wǎng)絡(luò)攻擊

2009-12-02 17:46:00

d-link無(wú)線路由器

2024-12-31 16:20:45

2009-02-28 14:07:00

D-Link DI-7多口路由器

2009-11-24 17:26:46

2009-11-24 10:59:06

D-link路由器配置
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)