本文作者：奇安信代碼安全實驗室
漏洞簡介
CVE-2020-1472是一個windows域控中嚴重的遠程權限提升漏洞。由於微軟在Netlogon協議中沒有正確使用加密算法而導致的漏洞，微軟在進行AES加密運算過程中，使用了AES-CFB8模式並且錯誤的將IV設置為全零，這使得攻擊者在明文(client challenge)、IV等要素可控的情況下，存在較高概率使得產生的密文為全零。下面就整個攻擊過程做一個簡要分析。
漏洞原理
Netlogon協議是微軟提供的一套域訪問認證協議，不同於大部分rpc服務，該協議使用的並不是典型的微軟認證方式如NTLM\Kerberos，該協議的通信流程如下：
圖1-1
圖1-1中攻擊者可控的因素有client challenge,攻擊者將它設置為全0，server challenge在每一輪認證過程中都會變化，secret對應於用戶密碼的hash，Encrypt的過程採用的是AES-CFB8，其運算過程如下：
圖1-2
在圖1-2中，黃色部分內容即為IV,微軟錯誤的將其設置為全0，而實際上為了保證AES算法的可靠性該部分內容應該隨機生成，黃色部分後緊接著的藍色部分為明文，對應於client challenge,該部分內容攻擊者可控，設置為全0，AES使用的key是將secret、challenge進行運算後得到的值，也就是說，key會隨著每一輪server challenge的變化發生變化，那麼如果IV和client challenge為全0的話，那麼整個AES運算過程變成圖1-3所示：
圖1-3
如圖1-3所示，在第一輪AES運算過程中，密文(黑色部分)第一個字節為0的概率是1/256，這是因為一個字節有8位，全為0的概率是1/256，那麼由這運算得到的密文第一個字節0x0和IV以及後面全0的client challenge計算後得到的新一輪”明文”依舊為全0，同樣進行AES運算，由於第二輪運算時明文 密鑰和第一輪都一致，那麼這一輪所產生的密文第一個字節也同樣是0，接下來幾輪計算原理以此類推，所以每一次連接都是由1/256的概率產生一個全0的密文，最理想的情況即是256次就一定能完成碰撞。因此Client challenge設置全0後，客戶端憑據(8字節)通過驗證的概率就從1/2^64提高到了1/256。
通過上述碰撞方法，攻擊者便完成了域身份認證，在接下來的攻擊過程用類似的方法也bypass了對call的校驗，最後通過相關調用完成對域控密碼的修改。值得注意的是由於整個碰撞過程中session key一直是未知的，攻擊者可以通過NetrServerAuthenticate3設置合適的flag使得剩下的通信過程不使用session key進行加密。
一言以蔽之，Netlogon協議身份認證採用了挑戰-響應機制，其中加密算法是AES-CFB8，並且IV默認全零，導致了該漏洞產生。又因為認證次數沒做限制，簽名功能客戶端默認可選，使得漏洞順利被利用。
漏洞驗證
1．無法獲取域內用戶憑據信息
2．執行PoC測試
3. 可以看到DC01的密碼置空，然後獲取域內憑據信息
<code>參考鏈接： https://www.secura.com/blog/zero-logon https://github.com/dirkjanm/CVE-2020-1472/<code>
