【51CTO.com 獨家譯稿】唉，我多么懷念從前攻擊者們能夠輕易獲取密碼散列的時光。那個時候，防御此類攻擊方式只需三個步驟：第一、保護好自己的密碼散列不被竊取；第二、使用強度較高的密碼散列；第三、保證使用較長的密碼以免遭到破解。

如今，從密碼散列入手已經是過時的招數。當下攻擊者們采用的是清一色的hash注入攻擊。通過這種攻擊方式，那幫混球能夠取得散列--無論是從密碼散列存儲數據庫中還是內存中--并利用它們重新生成一套完整的身份驗證會話。

密碼散列--或任何一種身份驗證模式--是登錄行為成功與否的核心所在。這類信息是通往禁宮的鑰匙，因此幾乎每種安全保障機制都在盡力試圖防止攻擊者拿到身份驗證資料。倘若他或她獲得了超級管理員訪問權限，那么任何操作、任何實施途徑對他們來說都是可行的，而且整個過程絕對會暢通無阻--因為對于防御體系來說，他們是完全合法的。

hash式攻擊能夠成功攻克任何操作系統及任何身份驗證協議，甚至Kerberos協議（由麻省理工學院開發的一套強力安全認證系統）對此也束手無策。此項技術同樣適用于智能卡類的登錄行為（因為在微軟的Windows系統中，網絡終端上的密碼散列的存儲及調用仍然源自局域網管理器上的驗證機制）。

我一直試圖向客戶們灌輸這樣的思路，即真正可怕的并不是hash攻擊本身。我們需要關注、且有能力關注的應該是如何將那些混球制止在實施hash攻擊前所必需的準備工作過程中。在攻擊者已經獲得了超級管理員身份時還執著于如何對抗hash攻擊，就像是在自己的車被小偷盜走后，還在心存僥幸地觀望車上的手剎是否能放緩他的腳步一樣。不過，當hash攻擊反復來襲時，它必然會引起我們--及我們的客戶--的注意。事實上，此類攻擊時下確實有愈演愈烈之勢。

抵御注入

正如我在前面提到的，能夠完全抵御hash攻擊的終極機制并不存在，但這并不意味著我們就應該在此類侵襲面前坐以待斃。安全性畢竟并不是二進制代碼，也不是非黑即白的二選一。安全性的真正含義是在完全安全與完全危險之間取較為適中的某個平衡點。

我曾經看到過通過禁用低強度密碼散列來對抗高級持續威脅的技術，這種辦法即使在攻擊者的工具非常強大、能夠輕松應對高強度密碼的情況下仍然能夠奏效。因為攻擊者事實上根本不知道較弱的密碼散列已經被禁用，因此他們認為沒必要嘗試hash攻擊。

在林林總總的hash攻擊防御方案之中，防止攻擊者獲取超級管理員訪問權限無疑是最重要、最核心的手段。遺憾的是，在多年來的傳統計算機安全防御工作討論中，我已經無數次強調過保持登錄用戶權限最小化、反惡意軟件工具、白名單、防火墻等等的必要性。然而，我的客戶們往往不會主動就hash攻擊跑來求助，直到他們意識到自己的防御體系已經形同虛設。

我們可以設下層層阻礙，令攻擊者無法順利將散列信息從內存中提取出來。在Windows系統中，密碼散列能夠通過下列登錄類型從內存中提取得到：交互、批處理、服務、解鎖、遠程交互以及緩存交互。表面上看這似乎已然包括了我們耳熟能詳的所有登錄類型，但是請注意，網絡登錄并不在其中。因此，單純對共享中的NetBIOS驅動器進行訪問是無法從內存中提取出密碼散列的。

另外，盡管注銷操作常常能幫我們清空內存中的密碼散列，但應用程序及API卻可能對其予以完整保留，因此這種作法并不完全可靠。注銷后再重新啟動計算機的方式最為理想，它能保證內存中不再殘留任何涉及密碼散列的信息。

阻斷上述途徑

我常常提醒客戶，務必盡量減少前文提到過的各類特權賬戶登錄類型。在大多數運行環境中，我一般會利用遠程桌面協議或其它類型的交互式遠程軟件來進行管理、故障排除并訪問服務器及工作站。這種方式簡單高效，但副作用也同樣明顯--高權限信息往往會殘留在運行環境當中，而此種狀況如果發生在存在木馬或是不受信任的機器上，后果無疑非常嚴重。

相反，我鼓勵客戶通過非交互式的方法來管理計算機。使用控制臺工具代替遠程桌面協議，我們同樣能夠以遠程方式連接到目標計算機。大多數微軟管理控制臺工具能夠重新定向到新的遠程目標計算機。還有，用PowerShell腳本代替手動輸入密碼的過程。

我有許多優秀的同事，他們與我抱有同樣的觀點，即盡可能取消所有具備超級管理員權限的賬號--或者最多保留一個。在微軟Active Directory體系中（我本人正是一位全職微軟員工），我們可以利用"授權"功能為指定用戶提供管理員權限，但又不像超級管理員那樣能夠掌控一切，這種方案類似于設置域管理員或是企業業務管理員。就我所知，沒有哪位域管理員或業務管理員在完全工作時真正需要超級管理員那么高級別的執行能力。相反，只賦予工作人員必需的權限既不會影響他們的正常操作，在散列被竊取后，攻擊者也無法獲得超級管理員賬戶。

我的客戶群體中有一些將希望寄托于頻繁頻繁再頻繁地修改密碼或者使用一次性密碼。的確，如果攻擊者獲得的是此類散列，他們能夠實施操作的時間會變得相對比較短。有多種供應商工具能夠協助我們達成上述目標。同時，最大限度避免密碼重復使用也能在保障密碼散列丟失時防止其它安全區塊發生危險。

最好嘗試使用最新的操作系統。它們總是具備一些早期版本所沒有的防御體系。舉例來說，在Vista、Windows 7以及Windows Server 2008（及之后的版本）中，傳統的NT散列被基于Kerberos協議的AES散列所取代。雖然hash攻擊的發起者可能最終還是能夠侵入AES，但至少目前來說他們對此還沒有太好的辦法，因為眼下還沒有哪款hash攻擊工具是針對AES制作的。盡管這種安全狀態只是暫時的，不過還是要牢記安全的概念是模糊的。任何能夠有效降低hash攻擊危險的方案都是很有價值的。

"彈"窗很重要

另一項重要建議是：管理員們應該在執行管理任務時抱有最大的安全性考量，且只使用受信任的計算機。大家不應該推諉管理職責，而是將其貫徹到日常的網頁瀏覽、電子郵件接收以及訪問社交網站的全部流程當中。此外，在處理管理方面的任務時盡可能創建"彈"窗。這些彈窗較難（希望如此）受到影響，也就從另一個側面保護了超級管理員的散列信息。當彈窗處于最前時，管理員應該使用非交互式遠程工具來實現對其它對話框體的管理。這樣一來，散列內容實際上存儲在另一臺計算機的內存當中。如果管理員以交互式方式登錄到其它某臺不受信任的計算機上時，請確保先注銷、再重啟這一安全操作流程。

有些企業甚至將"彈出"域設置為管理員專用。他們采取單向的、有選擇性的信任方式，借以避免某類身份驗證信息會鉆了可信任及不可信任兩種標準之間的空子。

還可以考慮利用IPsec或者AuthIP對特定計算機之間的互相登錄進行限制，以防止攻擊者在所有計算機上使用竊取來的散列信息。最后，請一定記住保持可以檢測出hash攻擊工具的反惡意軟件始終處于運行狀態。一旦發現潛伏于我們網絡周圍蠢蠢欲動的危險因素，忙碌的一天也將隨之開始。

我希望自己在這篇文章中分享的一些新方法能夠切實幫助大家減少hash攻擊帶來的種種風險。如果各位在這方面有獨到的見解或技巧，也請不吝指教。

原文鏈接：http://www.infoworld.com/d/security/stop-pass-the-hash-attacks-they-begin-167997?page=0,0

【51CTO.com獨家譯稿，非經授權謝絕轉載！合作媒體轉載請注明原文出處及出處！】