淺談 ( Pass the Hash ) PtH 與 PtT ( Pass the Ticket ) 攻擊對企業的衝擊（上）

發行項
03/29/2016

前言　
　　多數的企業為了集中化管理，而導入了企業身份識別系統 Active Directory，使內部的使用者可以透過集中式的帳號密碼認證機制，達成單一簽入的目標，大大的提升了便利性，但集中管理與分散管理，一直以來，都是管理者們在衡量便利與安全之間最大的難題。早在 NT 4.0 時，推出了網域服務，這個服務即開始深植入企業資訊管理者的心裡，讓每一個人都能擁有自已的識別帳號 ( Identification ) ，輸入自已的帳號密碼送交驗證 ( Authentication ) ，系統認證通過後，依照每一個使用者的帳號資訊給予正確存取的授權 ( Authorization ) ，最後即可於系統或服務上查詢到該使用者的存取稽核資訊 ( Accountability ) ，這是一個資訊安全系統上必要的存取控制措施，自有安全需求的系統起，無論帳號密碼稽核條件如何演變，不管需要多複雜、多長的密碼組合，每一個關卡都可以簡單抑或複雜。
　　而故事則是由這裡開始的，當我們將帳號密碼透過具有 3A 架構的系統存取控制機制來集中管理時，一來可以透過管理原則將帳號、密碼有效的提升其強度，二來可以提供一個通用的帳戶來存取各種不同的資源。但便利與安全永遠是置放於天枰的兩端，當開始追求安全時，便利性則會比起原本的機制來得麻煩，為了某人要開放更便利的使用系統時，則具備機密及敏感等級的使用者，就有可能變得不安全。
　　因此，無論在 AD 或是其它的驗證基礎、協定上，均提出了各種不同即可便利，又可安全的存取控制，而自 Domain Service 問世以來，提供了一個結合方便及安全的系統存取控制的架構，其中 Pass the Hash 及 Pass the Ticket 攻擊，則是依附著驗證系統化繁為簡而生，在電腦的驗證系統中，不外乎是輸入帳號密碼，輸完帳號密碼後，給予一個安全且簡單的再次確認機制，在古代就有所謂的漢符、令牌、通關卡…等等的代表該人已被驗證過的證據，讓這些已驗證者可以快速的通過查核。
本文大綱如下：

問題說明

而在電腦世界中，這一類的驗證系統，當然也有著各自的快速驗證機制，各位試著思考一下，我們要如何騙過以人為基礎的驗證系統？古代舉試如何查驗雙胞胎當槍手?如何確認漢符、令牌發放之後沒有被盜用?近日有一則新聞，有一位乘客在機場跑錯航空公司櫃台，而該櫃台人員亦只查核英文姓氏，連性別都沒有查驗就讓一位女性頂替一位未到場的男性辦理了登記作業，而通關過程亦無人查覺有異，一直到了飛抵目的，確認通關時才被航空公司查覺到，該名未到場的男性要求重新劃位，那麼在飛機上的那個人是誰，才讓該航空間司未仔細驗證的事情曝了光。

　　該航空公司未查證該女並非公司客戶，而直接發放了登機票證，如同 Kerberos 驗證機制中的 Pass the Ticket Attack ，錯的人拿著已驗證完成的票證向主機要求存取服務。

　　難道系統存取控制機制沒有再次確認的機制嗎?怎麼會讓人偽冒身份來存取服務呢?因此針對 NTLM Hash 驗證機制而生的 Pass the Hash attack 、針對 Kerberos ticket 驗證機制而生的 Pass the Ticket attack ，就此成為企業內部最大的問題，從一開始 SMB 協定在網路上以明文方式傳送 Token ，而後來因為這個驗證是明文傳送，過於危險，則出現了 LAN Manager Challenge / Response 驗證機制，又因為過於簡單，僅僅是為了讓用戶端向伺服器證明自已的身份，而用戶端與伺服器又共享有一個 Secret ，透過這個Secret來證明自已的身份，所以發起者是用戶端只要發起驗證，伺服器即丟遞一個隨機值 ( Challenge ) ，用戶端則用這個 Challenge 作為金鑰加密的 Secret ，而伺服器再將 Challenge 解開得到 Secret ，即可驗證該用戶端是否合法。問題就出在必須確保 Challenge 夠隨機，不以被猜測到，因此若從發起者用戶端身上去偷得 Secret ，也取得伺服器上的 Challenge ，那麼這個機制即可被偽冒。

　　由於上面單純一次 Challenge / Response 太過於薄弱，那麼透過這個為基礎發展出 Ansi Passwordf(LM_Hash, Challenge)，Unicode Password f(NT_Hash, challenge) 含有 SMB NTLMv1 Challenge / Response 驗證協定，產生的是 1 對 1 的關聯，大幅度的提升了難度，因為其中包含了網域名稱、伺服器、帳號、兩組密碼。但相對的，只要這些資訊完整的被擷取下來，還是會順利的解開其內容，成為被利用的認證架構

　　為了讓 Challenge/Response 驗證協定可以更安全，因而 NTLMv2 則加上了時間戳記，讓 SMB_Session_Setup_ANDX_Reuest 階段加上時戳，並增加 8byte的Server Challenge/nonce 及 Client Challenge ，讓伺服器檢驗 LMv2 及/或 NTv2 的結果是否正確，進而決定要同意或拒絕存取。

工具說明

Mimikatz 來自於法國知名駭客 Benjamin Delpy 之手它可以達成的內部身份竊取攻擊包含有：

- 由 LSASS ( Local Security Authority Subsystem Service ) 傾印認證資訊

( Windows Local Security Account database ) [ sekurlsa 模組 ]

MSV1.0: hashes & keys (dpapi)

Kerberos password, ekeys, tickets, & PIN

TsPkg ( 密碼 )

WDigest ( 密碼明文 )

LiveSSP ( 密碼明文 )

SSP ( 密碼明文 )

- 產生 Kerberos Golden Tickets ( Kerberos TGT logon token ticket attack )
- 產生 Kerberos Silver Tickets ( Kerberos TGS service ticket attack )
- 匯出憑證及金鑰 ( 即時那些不是正常的匯出點 ).
- 傾印快取憑證
- 停用事件監視
- 略過 Microsoft AppLocker / 軟體限制條件
- 修補終端伺服器
- 略過基礎 GPO

在 POC 的過程中，我們可以模擬出的情境包含下列常見的狀況：

- 網域內使用者是本機主機的 Administrators 成員
- UAC ( User access controls 使用者存取控制 ) 是被關閉的
- 所有的驗證機制僅仰賴著帳號及密碼

執行 mimikatz必須以管理者身份執行，執行完成必須再透過權限提升指令 Privilege::dbug

　　　若出現下列訊息，則代表正常啟動

　　　若出現下列訊息，則該帳號權限或身份不足

　　　當使用者曾經在該機器上登入過，即可以透過 sekurlsa::logonpasswords 列出機器上所有使用者的 Hash 值

　　接下來透過 sekurlsa::pth /user:Jason /domain:blackjason /ntlm:7ecffff0c3548187607a14bad0f88bb1 /run:SMB 為基礎的指令，即可偽冒該使用者來存取其使用者權限所及的資訊或服務。

然而在目前 PtH 的威脅下，只能停用 NTLM 嗎？會不會過得了這關，就依據 Microsoft TechCenter 的建議做法告訴我們：

限制及保護高權限的網域帳號

- 將管理者使用的帳戶分隔出管理及個人使用者的帳號：多數的管理者會習慣的將自已的帳號加入網域管理員中，但即使只有在個人電腦中操作 word，也是以管理者的權限在執行，應當落實管理者也是員工，應該也有屬於資訊管理部門的使用者帳戶，當需要執行管理工作時，再切換至管理帳號。
- 為管理員配置專用的工作站主機：由於管理事務需要特別的權限運作，但當主機混用時，易造成較高管理權限的使用者帳戶因為登入到未知主機上，造成被該主機擷取到管理者帳號的相關機密資料。
- 限制伺服器及工作站的登入存取：限制管理者帳戶不可登入本機，例如 Domain admins, Enterprise Admins。
- 禁止特權帳號的權限委派

2. 限制及保護高權限的網域帳號

- 增強本地帳號於遠端存取的限制
- 拒絕來自於網路登入到所有的本地帳號
- 建立為特權帳號建立唯一的密碼

3. 以 GPO 設定 windows 防火牆限制輸入流量

　　當然要更安全的作法就必須導入第二種驗證方式，例如加上 One time pasword 、生物認證，由於較舊的版本 ( windows 7 以前 ) 在驗證模式中，即是使用 NTLMv1 ，但由於新版本作業系統上雖然可以強制指定 NTLMv2 ，但一旦有作業系統上的版本落差，則會出現 NTLMv1 及 NTLMv2 不相容的問題產生，即使你的密碼正確，因 NTLMv2 有加上時戳，因此根本無法與 NTLMv1 配對，當然即無法正常運作通過驗證。

有更多的資訊你可以參考下面的延伸閱讀。