建站
咨詢
售后
建站咨詢
新聞中心
今年2月，D-Link發(fā)布了 針對兩個身份驗證繞過漏洞CVE-2020-8863 和 CVE-2020-8864的固件 補丁程序，這些漏洞 影響了D-Link DIR-882，DIR-878和DIR-867路由器。這些漏洞存在于HNAP協(xié)議的處理中。
https://supportannouncement.us.dlink.com/announcement/publication.aspx?name=SAP10157
我們將首先研究CVE-2020-8863，以熟悉HNAP的身份驗證方案。在那之后，我們將分析比較奇怪的CVE-2020-8864，它上面寫有“backdoor”一詞。
0x01 HNAP是什么
HNAP或家庭網(wǎng)絡(luò)管理協(xié)議，是Pure Networks，Inc.發(fā)明的一種專有的基于SOAP的協(xié)議，后來被Cisco收購。該協(xié)議可以追溯到2007年，可以被認(rèn)為是UPnP的直接競爭對手。該協(xié)議的主要用戶是Cisco和D-Link。但是，兩者都分別在2012年和2016年停止使用此協(xié)議 。該功能通常在管理面板中隱藏，因此無法禁用。如果你的路由器仍支持HNAP，則可能意味著你的路由器需要升級。
作為一種過時的專有協(xié)議，Internet上很少有相關(guān)文檔。HNAP提供兩種類型的身份驗證方案：基本和基于HMAC。我可以找到的有關(guān)基于HMAC的身份驗證方案的最佳文檔是來自逆向項目的 Github Wiki頁面。
0x02 HNAP認(rèn)證過程
對服務(wù)器（路由器）的身份驗證需要兩個事務(wù)。首先，客戶端發(fā)送一條request消息并從服務(wù)器獲得身份驗證質(zhì)詢。
- request admin
服務(wù)器響應(yīng)與三個值的請求：Challenge，Cookie和PublicKey
- OK rEmNZG3LUDFUSMJHU55P uidpiK0+ vq1w3gFhoIAlc38rEVLO 0
客戶端必須首先將PublicKey和用戶密碼結(jié)合在一起以創(chuàng)建一個PrivateKey。請注意這一點，因為它將在以后變得很重要。然后，客戶端將使用新生成的PrivateKey和Challenge來生成新值?？蛻舳藢⒋酥捣旁谙⒌腖oginPassword字段中，login作為對服務(wù)器發(fā)出的質(zhì)詢的響應(yīng)：
- login admin ........
服務(wù)器可以通過獨立計算PrivateKey并LoginPassword使用記錄的用戶帳戶密碼，計算對Challenge的預(yù)期響應(yīng)并將其與LoginPassword客戶端提供的密碼進行比較，從而對客戶端進行身份驗證。如果值匹配，則客戶端已成功認(rèn)證自己。
0x03 CVE-2020-8864
此身份驗證繞過漏洞是由于不正確地使用strncmp()來將服務(wù)器計算出的值LoginPassword與LoginPassword客戶端提供的值進行比較而引起的。下面是漏洞函數(shù)的控制流程圖：
查看全圖
圖1-CVE-2020-8864的漏洞函數(shù)的控制流程圖
本質(zhì)上，控制流程圖的上述部分描述了以下常見的易受攻擊的代碼模式：
- strncmp（db_password，attacker_provided_password，strlen（attacker_provided_password））;
當(dāng)attacker_provided_password為空字符串時，strlen()返回0。然后，由于strncmp()使用長度參數(shù)0調(diào)用了它，因此它根本不比較任何字符。而是返回值0，表示相等。在CVE-2020-8864中，如果攻擊者提供一個空LoginPassword值，strncmp()則將返回0并遵循代碼路徑進行成功的身份驗證。
0x04 CVE-2020-8863
該漏洞的標(biāo)題為：
D-Link多個路由器HNAP PrivateLogin身份驗證算法的錯誤實現(xiàn)身份驗證繞過漏洞
“ PrivateLogin”一詞比較有意思。讓我們看一下路由器如何處理HNAP登錄請求，以了解如何用幾行代碼實現(xiàn)此PrivateLogin后門。
通過HNAP進行身份驗證時，服務(wù)器通常會根據(jù)用戶密碼生成PrivateKey。但是，當(dāng)攻擊者
- request Admin Username
以下是生成研究人員提供的身份驗證質(zhì)詢值的函數(shù)的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從登錄請求中提取元素的內(nèi)容（如果存在），并將其存儲在PrivateLogin變量中。該Username元件也提取并存儲在所述Username可變上方的幾行。
PrivateLogin稍后在第58行使用該變量。if如果應(yīng)用De Morgan定律，則可以更輕松地理解該條件。該條件檢查該PrivateLogin元素是否存在，并進一步確保該PrivateLogin元素包含字符串“ Username”。如果兩個條件都滿足，則Username元素的值（即“ Admin”）將使用strncpy()復(fù)制到Password變量中。這與路由器調(diào)用GetPassword()以從NVRAM讀取管理員密碼的普通代碼路徑不同。
在第65行，現(xiàn)在被污染的Password被傳遞到GenPrivateKey()，Challenge，Cookie和PublicKey值的驗證Challenge。結(jié)果，攻擊者現(xiàn)在知道了所有必需的值以重新創(chuàng)建PrivateKey并響應(yīng)身份驗證質(zhì)詢，而無需知道路由器的真實管理員密碼。
0x05 分析總結(jié)
這個后門是如何進入產(chǎn)品的？開發(fā)人員為什么要編寫這些代碼行？它是制造商原始設(shè)計的一部分嗎？還是這些代碼行是由惡意員工編寫的？為什么代碼審計沒有發(fā)現(xiàn)這一點？是否有 任何 代碼審計流程？CVE-2020-8864是否 也有意編碼為維持立足點的替代方法？我們沒有上述任何問題的答案。但是，我們可以肯定地知道固件中存在此類漏洞是較大問題的征兆，并且與單純提供補丁程序相比，對于賣方而言，它需要采取更多的措施。
本文翻譯自：https://www.thezdi.com/blog/2020/9/30/the-anatomy-of-a-bug-door-dissecting-two-d-link-router-authentication-bypasses如若轉(zhuǎn)載，請注明原文地址。
網(wǎng)頁題目：對兩個D-Link路由器身份驗證繞過漏洞的分析
當(dāng)前網(wǎng)址：http://www.dlmjj.cn/article/djigeos.html
