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

如何在HASH注入攻擊前先行制止

原創(chuàng)
安全 數(shù)據(jù)安全
下列技巧能夠幫助大家避免攻擊者獲取到我們的密碼散列——因為一旦他們得手,一切就徹底玩完了。

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

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

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

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

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

抵御注入

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

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

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

我們可以設(shè)下層層阻礙,令攻擊者無法順利將散列信息從內(nèi)存中提取出來。在Windows系統(tǒng)中,密碼散列能夠通過下列登錄類型從內(nèi)存中提取得到:交互、批處理、服務(wù)、解鎖、遠程交互以及緩存交互。表面上看這似乎已然包括了我們耳熟能詳?shù)乃械卿涱愋停钦堊⒁?,網(wǎng)絡(luò)登錄并不在其中。因此,單純對共享中的NetBIOS驅(qū)動器進行訪問是無法從內(nèi)存中提取出密碼散列的。

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

阻斷上述途徑

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

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

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

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

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

"彈"窗很重要

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

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

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

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

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

【51CTO.com獨家譯稿,非經(jīng)授權(quán)謝絕轉(zhuǎn)載!合作媒體轉(zhuǎn)載請注明原文出處及出處!】

責任編輯:佟健 來源: 51CTO.com
相關(guān)推薦

2011-08-09 15:27:17

2016-01-13 10:23:51

2015-12-30 10:49:31

2014-11-05 09:52:50

2020-08-07 08:13:08

SQL攻擊模式

2019-02-22 09:00:00

2010-09-14 16:28:52

2010-09-30 12:53:10

2010-09-14 19:40:42

2014-05-12 10:37:41

2010-09-13 16:58:13

2013-12-13 10:45:26

2011-05-24 11:25:17

2010-09-20 11:22:08

2024-10-12 10:57:21

2011-10-19 10:47:56

2017-05-08 14:33:51

2012-12-19 10:36:06

2013-11-07 09:31:22

2014-07-09 15:41:51

點贊
收藏

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