NTLM中繼攻擊結合MSSQL呼叫xp_dirtree拿下MSSQL最高許可權
不久前，我們在為客戶進行應用程式安全測試時，發現了一個NTLM憑證轉發攻擊，挺有意思的，這裡給大家分享一下。
該應用程式乍一看非常不起眼。一個非常典型的Windows胖客戶端，一個應用程式伺服器和一個後端MSSQL資料庫伺服器。檢視胖客戶端目錄中的一些XML配置檔案，我們在一些明文的主機名和埠號旁邊找到了名為“DBUsername”和“DBPassword”的一串base64編碼值。解碼之後，存在一些無法識別的二進位制亂碼，顯然是經過加密的。應用程式開發人員可能認為攻擊者會就此放棄，但我們偏不放棄，誰讓我們固執呢。我們認為如果客戶端軟體能夠解密這些憑據，那我們有了客戶端的副本，我們肯定也能進行解密。
剛開始，我們進行了枯燥的逆向工作，但很快就發現相關的二進位制檔案都是.NET管理，這意味著我們能夠簡單的將它們反編譯成非常清晰的原始碼。在原始碼中搜索“crypt”字串，很快就定位到了負責加密和解密儲存資料庫憑證的函式，以及硬編碼金鑰和IV，這兩者都是基於軟體供應商的名字。
使用Python搗鼓了一段時間後，我們重新實現了應用程式中的解密函式，值得自豪的是，我們獲取了一些資料庫憑證，使用它登入到MS SQL Server例項後，我們發現即使這個資料庫與應用程式主資料庫使用的伺服器相同，我們的憑據也只能訪問伺服器上非常有限的資料庫，而且沒什麼有用的東西。客戶端使用更傳統的方法獲取最敏感的資料，即通過帶有資料庫後端連線的應用層伺服器。
'xp_cmdshell'這個元件是攻擊者最喜歡用的，不過這裡，我們的使用者無法使用。如果我們想找到一種方法來拿下資料庫伺服器，我們需要有一些騷思路。
接下來，我們嘗試了另一個經典的技巧，就是使用'xp_dirtree'這個擴充套件儲存過程。xp_dirtree這個儲存過程實際上是讓SQL服務例項對提供的檔案路徑進行目錄遍歷。通過UNC路徑，將伺服器指重定向到攻擊者控制的主機上，我們通常可以使用Responder或ntlmrelayx等工具來捕獲SQL Server服務帳戶密碼的NetNTLMv2雜湊值，或者轉發服務帳戶的憑據並使用它們通過SMB對輔助主機進行身份驗證。雖然我們能夠獲取雜湊值，但密碼設定的非常複雜，我們在有效時間內很難破解。此外，我們無法通過SMB將憑證轉發到任何範圍內的主機，因為都已經配置了SMB簽名，設定為 “REQUIRED”，這就非常頭疼了，使得我們的轉發憑證毫無價值。
挫敗ing……
不過，先稍等一下！好像可以轉發NTLM身份驗證來對其他協議進行身份驗證，包括HTTP和MSSQL！也許不允許將NTLM身份驗證返回到源主機的這種常規的規則不適用於這樣的跨協議場景？no no no，其實他們仍然適用。
再次挫敗！！！
到了這一步，我們變得有點沮喪並且回到了剛開始的基礎知識部分，深入挖掘我們之前收集到的偵察資料，包括使用Shell/">PowerShell模組 SPI/PowerUpSQL/" target="_blank" rel="nofollow,noindex">PowerUpSQL 收集到的資訊。PowerUpSQL將列舉一個數據庫伺服器與另一個數據庫伺服器之間的連結。當你有主執行的資料庫伺服器和充當“資料倉庫”的輔助伺服器的情況下，這些連結尤為常見，其中資料定期從一個數據庫進行整理並歸檔到另一個伺服器中，我們案例中的情況正是它所定義的場景。
通過第一個資料庫將查詢傳送到資料倉庫並沒有立即產生任何特別有用的結果。我們在資料倉庫中許可權也非常低，這剛開始看起來似乎是一條死衚衕，不過，我們突然意識到我們已經擁有了拿下伺服器所需要的一切資訊。
首先，我們設定ntlmrelayx以捕獲針對我們攻擊者控制的主機的SMB身份驗證嘗試，並將它們轉發到與之前相同的MSSQL伺服器埠上，只不過這次不是在第一臺伺服器上執行xp_dirtree，而是使用資料庫連結將相同的xp_dirtree查詢傳送到第二個伺服器執行。它會嘗試連線我們的主機，協商NTLM身份驗證，然後將身份驗證嘗試轉發回第一臺伺服器的MS SQL Server埠上，這就完成了一個完整的流程，如圖：
我們回到剛開始的地方，但現在我們通過了身份驗證，成為了SQL Server服務帳戶，該帳戶在兩個SQL伺服器上都具有本地管理員許可權，因此它們也被授予了全部的“sa”許可權。有了管理員訪問許可權，我們就能夠啟用“xp_cmdshell”擴充套件儲存過程，並使用它以管理員使用者在作業系統中執行shell命令。我們這裡不會詳細介紹，但在這次突破之後，只需要幾分鐘的時間，我們就能夠完全控制整個AD / Windows環境。
那麼，這一切的主要經驗教訓是什麼？
·不要將憑據和加密金鑰硬編碼到應用程式配置檔案或二進位制檔案中。如果你的安全是基於此來設計的，那麼你的設計是錯誤的。
· 不要讓使用者直接登入到資料庫伺服器 –讓他們通過應用層伺服器進行訪問。
· 禁用不需要的SQL Server擴充套件過程，包括xp_cmdshell，xp_dirtree和xp_filexist。
· 出站防火牆規則與入站規則一樣重要。如果你的後端伺服器不需要與客戶端進行SMB通訊，那就禁止SMB通訊！
· 雖然SMB簽名是一種極其有效的安全控制，但遇到堅持不懈的對手，任何單一的安全控制都不會完全有效。