ZIP Slip脆弱性：アーカイブ展開の悪用

数千のアプリに影響を与える重大なセキュリティ脆弱性の理解

2018年6月、セキュリティ研究者は現代ソフトウェア開発で最も広範囲にわたる脆弱性の一つ、ZIP Slipを公開しました。この重大なアーカイブ展開の脆弱性は、多くのプログラミングエコシステムにまたがる数千のプロジェクトに影響し、攻撃者がターゲットシステムに任意のファイルを書き込み、リモートコード実行を可能にします。公開から数年経っても、新たな事例が続々と発見されており、2025年には人気のアーカイブライブラリに関する新しいCVEが報告されています。

ZIP Slipとは何か？

ZIP Slipは、アーカイブ展開時のディレクトリトラバーサルを悪用した任意ファイル上書き脆弱性の一種です。攻撃は、../../evil.shのようなパストラバーサルシーケンスを含むファイル名を持つ特別に作成されたアーカイブファイルを利用し、展開時に意図しない場所にファイルを書き込みます。

この脆弱性はZIPファイルだけに限定されません。以下の複数のアーカイブフォーマットに影響します：

ZIP (.zip)
TAR (.tar, .tar.gz)
JAR (Java Archive)
WAR (Web Application Archive)
APK (Android Package)
CPIO (.cpio)
RAR (.rar)
7Z (.7z)

この広範な影響により、ZIP Slipはファイル処理システムの中でも最も危険な脆弱性の一つとなっており、HP、Amazon、Apache、Pivotal、Oracle、LinkedIn、Twitterなどの大手組織を含む多くのアプリケーションに影響しています。

技術的仕組み：ZIP Slipの動作原理

脆弱なコードパターン

基本的に、ZIP Slipはアーカイブ展開コードの単純ながら重大な見落としを悪用します。以下は脆弱なJavaの例です：

Enumeration<ZipEntry> entries = zip.getEntries();
while (entries.hasMoreElements()) {
    ZipEntry entry = entries.nextElement();
    File file = new File(destinationDir, entry.getName());
    FileOutputStream fos = new FileOutputStream(file);
    // ファイル展開処理...
}

問題は2行目のnew File(destinationDir, entry.getName())にあります。このコードは、検証なしにZIPエントリの名前と宛先ディレクトリを単純に結合しています。もしentry.getName()が../../../etc/cron.d/maliciousのようなパスを返すと、ファイルは/etc/cron.d/maliciousに書き込まれ、意図した場所から外れてしまいます。

悪意のあるアーカイブの構造

悪意のあるZIP Slipペイロードの作成には、特別なフォーマットのファイル名を持つアーカイブを作る必要があります。標準の圧縮ユーティリティではこれらのファイルを作成できませんが、攻撃者はカスタムコードや特殊なツールを使って生成します。

典型的な悪意のあるアーカイブの構造例：

exploit.zip
├── good_file.txt
├── ../../../../../../tmp/backdoor.sh
├── ../../../etc/cron.d/persistence
└── ../../../../var/www/html/shell.php

このアーカイブを脆弱なコードで展開すると、ファイルは意図しない場所に書き込まれ、重要なシステムファイルや設定ファイル、実行可能スクリプトを上書きする可能性があります。

実世界の攻撃シナリオ

シナリオ1：Webアプリケーションのシェルアップロード

攻撃者は、プラグインインストール機能を持つWebアプリに悪意のZIPファイルをアップロードします。ZIPには以下が含まれます：

正当なプラグインファイル/...
../../../../var/www/html/shell.php

展開後、攻撃者はhttps://target.com/shell.phpにWebシェルを設置し、リモートコード実行を行います。

シナリオ2：システム設定の改ざん

Linuxシステムを対象とした悪意のアーカイブには次のような内容が含まれる場合があります：

../../.ssh/authorized_keys
../../../etc/cron.d/backdoor

これにより、攻撃者はSSHキーを追加したり、持続的なアクセスのためのスケジュールされたタスクを作成したりできます。

シナリオ3：モバイルアプリの悪用

Androidアプリの場合、攻撃者はAPKアップデートに以下を仕込むことがあります：

../../data/data/com.target.app/shared_prefs/settings.xml
../../../lib/libmalicious.so

これにより、アプリの設定を上書きしたり、悪意のあるネイティブライブラリを注入します。

なぜこの脆弱性はどこにでも存在するのか

エコシステムの問題

ZIP Slipの蔓延は、ソフトウェア開発におけるいくつかの制度的な問題に起因します：

標準ライブラリの不足：多くのプログラミングエコシステム、特にJavaには、アーカイブ処理のための中央集権的で高レベルなライブラリが不足しています。これにより、開発者は独自に展開コードを書くか、オンラインの脆弱なスニペットをコピーする必要があります。
コード再利用文化：開発者は頻繁にStack OverflowやGitHubのリポジトリ、コミュニティのソースからコードをコピーします。脆弱なコードスニペットが広まると、数千のプロジェクトに急速に伝播します。
依存関係の連鎖：アプリケーションは直接含むライブラリだけでなく、それらのライブラリの依存関係も継承します。深くネストされた依存関係の脆弱性が、複数の層にわたるアプリに影響を与えることがあります。
セキュリティ意識の不足：多くの開発者は、アーカイブ展開時のパストラバーサルの脆弱性を認識しておらず、アーカイブ処理をセキュリティ上重要な機能とみなしていません。

影響：攻撃者が達成できること

直接的な結果

リモートコード実行 (RCE)：ZIP Slipの最も深刻な結果です。攻撃者は実行可能ファイルやシェルスクリプト、動的ライブラリを上書きし、その後システムやユーザによって実行される可能性があります。

データ破壊：悪意のあるアーカイブは、重要なデータファイルや設定データベース、バックアップファイルを狙い、データの損失や破損を引き起こすことがあります。

権限昇格：/etc/sudoersやSSHのauthorized_keysなどのシステム重要ファイルを上書きすることで、攻撃者は権限を昇格させることが可能です。

持続性確保：スタートアップスクリプトやcronジョブ、systemdサービスなどを変更し、長期的なアクセスを確保します。

二次的な攻撃経路

ZIP Slipは、より高度な攻撃の足掛かりとしても利用されます：

サプライチェーン攻撃：ビルドシステムや依存リポジトリを侵害し、ZIP Slipを通じて悪意のコードを注入
横展開：侵害されたシステムから他のネットワーク接続システムに悪意のあるアーカイブを展開
ランサムウェア展開：重要ファイルを書き換えた後に暗号化し、バックアップなしでは復旧困難に

ZIP Slipの脆弱性を検出する方法

コード監査のテクニック

1. 脆弱なパターンの検索

検証なしにアーカイブを展開するコードを探します：

// 警告：検証なしの直接結合
File file = new File(baseDir, entry.getName());

// 警告：パスの正規化チェックなし
String filePath = destinationDir + File.separator + entry.getName();

2. アーカイブ処理関数の分析

次のようなコードを調査します： - ZIP、TAR、RARなどのアーカイブファイルを開く - アーカイブエントリを反復処理 - 展開した内容をディスクに書き込み - アップロードされたアーカイブを処理

3. 依存関係のスキャン

自動ツールを使って脆弱な依存関係を特定します。Snykなどのセキュリティプラットフォームは、多エコシステムにわたる影響を持つライブラリのリストを最新に保っています。

実行時の検出戦略

ファイルシステムの監視：予期しないファイル書き込みを監視し、特に/etcや/bin、/libなどの重要パスに注意します。

アーカイブ内容の検査：展開前に、以下のような疑わしいファイル名パターンをスキャンします： - ../や..\のシーケンス - 絶対パス（/やドライブレターで始まる） - 特殊文字やエンコーディングトリック

サンドボックス展開：コンテナや仮想マシン内でアーカイブを展開し、検証済みの内容を本番環境に移す前に安全性を確認します。

防止と緩和策

セキュアコーディングの実践

1. パスの検証と正規化

展開されたファイルパスを常に意図した宛先ディレクトリと比較して検証します：

public static boolean isSafePath(File destination, ZipEntry entry) throws IOException {
    File destinationFile = new File(destination, entry.getName());
    String canonicalDestination = destination.getCanonicalPath();
    String canonicalTarget = destinationFile.getCanonicalPath();
    
    return canonicalTarget.startsWith(canonicalDestination + File.separator);
}

2. セキュアなライブラリの利用

以下のような、ZIP Slip保護機能を備えたライブラリを優先します：

Java：Apache Commons Compress（最新版推奨）
Python：zipfileを適切に検証して使用
.NET：System.IO.Compressionとパスチェック
Node.js：extract-zipなどのセキュリティパッチ適用済みライブラリ

3. 深層防御の実装

import os
import zipfile

def safe_extract(zip_path, extract_to):
    with zipfile.ZipFile(zip_path, 'r') as zip_ref:
        for member in zip_ref.namelist():
            # パスの正規化と検証
            member_path = os.path.normpath(os.path.join(extract_to, member))
            
            # 展開先内に収まるか確認
            if not member_path.startswith(os.path.abspath(extract_to)):
                raise Exception(f"パストラバーサルの試み: {member}")
            
            # 追加の検証
            if os.path.isabs(member):
                raise Exception(f"絶対パスは禁止: {member}")
            
            # 安全に展開
            zip_ref.extract(member, extract_to)

アプリケーションレベルの保護

1. ファイルアップロード制限

必要なアーカイブ形式のみに制限
ファイルサイズ制限を設け、zip bomb攻撃を防止
アップロード機能には認証・認可を実装
展開操作の詳細なメタデータをログに記録

2. 最小権限の原則

展開処理は最小権限で実行： - 制限されたファイルシステムアクセス権を持つ専用アカウントを使用 - 必須のアクセス制御（MAC）ポリシーを適用 - 信頼できないコンテンツにはコンテナやサンドボックスを利用

3. 入力検証

アーカイブ処理前に： - マルウェアや疑わしいパターンをスキャン - アーカイブの構造と整合性を検証 - 不合理な圧縮比（zip bombの可能性）をチェック - 疑わしいエントリ名を拒否

インフラの考慮点

コンテナ分離：Dockerコンテナなどの隔離技術内で展開し、パストラバーサルによるホストシステムへの影響を防止

ファイルシステムの権限設定：システムディレクトリに対して厳格な権限を設定し、不正な書き込みを防止

ネットワーク分離：ユーザアップロードされたアーカイブを処理するシステムと重要インフラを分離し、被害範囲を限定

ZIP Slipの検出方法

テストケースの作成

セキュリティチームは、ZIP Slipのテストを評価ルーチンに組み込みます：

テストケース1：基本的なトラバーサル

アーカイブ内容： ../../../etc/test.txt
期待される結果：展開に失敗、またはファイルが宛先内に収まる

テストケース2：エンコードされたトラバーサル

アーカイブ内容： ..%2F..%2F..%2Fetc%2Ftest.txt
期待される結果：デコード後に展開失敗

テストケース3：Windowsパスのトラバーサル

アーカイブ内容： ..\..\..\Windows\System32\test.dll
期待される結果：Windowsシステムで展開失敗

テストケース4：絶対パス

アーカイブ内容： /tmp/malicious.sh
期待される結果：絶対パスは拒否

自動化ツールによる検査

以下のツールはZIP Slipの脆弱性検出に役立ちます：

Snyk：依存関係のスキャンとZIP Slip検出
OWASP Dependency-Check：脆弱なコンポーネントの特定
SonarQube：静的解析とパストラバーサルのセキュリティルール
カスタムスクリプト：アーカイブ処理コードを対象とした特定のテスト

ファイルアップロード機能における検証の重要性

ファイルアップロード機能は現代アプリの中核です：

CMSプラットフォーム：WordPressやDrupalなどのプラグイン・テーマアップロード
クラウドストレージ：DropboxやGoogle Drive、OneDriveが数十億のアーカイブを処理
開発ツール：パッケージマネージャやCI/CD、IDEプラグインによるアーカイブの継続的処理
モバイルアプリ：アプリストアやアップデート、コンテンツ配信システム
エンタープライズソフトウェア：ドキュメント管理やバックアップ、コラボレーションツール

これらはすべて攻撃の潜在的な入り口です。未検証のアーカイブ展開はシステム全体を危険にさらすため、検証は絶対に必要です。

アップロードから実行までの流れ

一般的な流れ：

ユーザがアーカイブをアップロード
サーバが一時的にファイルを保存
展開処理が始まる（脆弱なポイント）
アプリケーションが展開内容を処理
コンテンツがユーザやシステムに利用可能になる

展開ステップがZIP Slipの攻撃ポイントです。アプリが異常に気付く頃には（気付くことは稀ですが）、悪意のあるファイルはすでに重要な場所に書き込まれている可能性があります。

業界の対応と現状

セキュリティコミュニティはZIP Slipへの対策に大きく取り組んでいます：

ライブラリのパッチ適用：ほとんどの主要アーカイブライブラリは修正済みです。Snykは、エコシステム全体の影響を追跡するGitHubリポジトリを管理しています。

開発者教育：セキュリティ研修にはZIP Slipが標準的なトピックとして組み込まれています。

自動スキャン：最新のセキュリティツールはZIP Slip検出を脆弱性データベースに含め、依存関係の特定を支援します。

標準化の進展：一部のエコシステムでは、セキュアなアーカイブ処理ライブラリの開発が進められ、カスタム実装の必要性を低減しています。

しかし、課題も残っています：

レガシーシステム：古いアプリは更新されないケースも多い
依存関係の複雑さ：脆弱なトランジティブ依存を更新するとアプリが壊れる可能性
ゼロデイの変種：2025年のCVEのように新たなバリエーションが出現し続ける
開発者の認識不足：多くの開発者がこの問題を理解していない

ベストプラクティスのまとめ

開発者向け

アーカイブエントリのパスは絶対に信用しない - 常に展開先と照合して検証
セキュアなライブラリを利用 - 保護機能付きの信頼性の高いライブラリを選択
許可リストを設定 - 許容されるファイルの場所を定義し、それ以外を拒否
セキュリティテストを追加 - ZIP Slipのテストをテストスイートに含める
最小権限の原則を守る - 展開は最小権限で実行

セキュリティチーム向け

定期的な監査を実施 - コードや依存関係の脆弱パターンをスキャン
監視を導入 - 不審なファイル書き込みをリアルタイムで検知
開発者教育を徹底 - パストラバーサルリスクの理解促進
アップロード機能のテスト - 脆弱性を狙ったペネトレーションテストを実施
インシデント対応計画を整備 - ZIP Slipの悪用に備える

組織向け

依存関係を最新に保つ - セキュリティパッチ適用済みのライブラリを使用
DevSecOpsを採用 - セキュリティスキャンをCI/CDに組み込む
コードレビューを徹底 - アーカイブ処理コードのセキュリティレビュー
多層防御を実施 - 検証、サンドボックス、権限管理など複数の層を重ねる
インシデント対応計画を策定 - 侵害時のリカバリ手順を準備

アーカイブセキュリティの未来

アプリがソフトウェア配布やデータバックアップなどでアーカイブファイルに依存し続ける限り、安全なアーカイブ処理の重要性は高まる一方です。

新たな脅威：ZIP Slipの新バリエーションは引き続き出現しています。例： - シンボリックリンクを利用したトラバーサル（CVE-2025-3445） - フィルタを回避するエンコーディングトリック - 展開時のTOCTOU攻撃

クラウドネイティブの懸念：サーバーレスやコンテナ化されたアプリは、新たな攻撃経路を生み出し、IAMポリシーやLambda、コンテナオーケストレーションを危険にさらす可能性があります。

AIと自動化：AIを活用した開発ツールがコード生成を行う中、脆弱なパターンを再現させないことが重要です。

結論

ZIP Slipは、攻撃のしやすさと検知の難しさ、エコシステム全体への広がり、壊滅的な結果をもたらす可能性を持つ、セキュリティ脆弱性の完璧な嵐です。2025年に新たな事例が発見されていることからも、認識だけでは不十分であることが証明されています。

アプリケーションがアーカイブを処理する際、特にユーザアップロードを受け付ける場合は、適切な検証とセキュリティ対策を実施しなければなりません。安全性を過信せず、「アーカイブの信頼性はない」「すべてのパスを検証せよ」「展開を安全に行え」の精神で臨むことが重要です。

ZIP Slipの技術的詳細を理解し、堅牢な検証と安全なライブラリの利用、テストと監視を徹底することで、システムをこの広範な脅威から守ることができます。脆弱性はどこにでもありますが、適切な予防策を講じれば、その悪用を防ぐことは可能です。

覚えておいてください：アーカイブを信用するな。すべてのパスを検証せよ。展開を安全に。 これがシステムの安全を守る鍵です。

追加リソース

Snyk ZIP Slip調査: https://security.snyk.io/research/zip-slip-vulnerability
GitHubリポジトリ: https://github.com/snyk/zip-slip-vulnerability
OWASP パストラバーサル: https://owasp.org/www-community/attacks/Path_Traversal
CISAアドバイザリ：ZIP Slipに関する最新情報
CVEデータベース：”ZIP Slip”や”パストラバーサル”で検索して最新情報を確認

記事の長さ：約2,000語
最終更新：2025年11月
SEOキーワード：ZIP Slip脆弱性、アーカイブ展開のセキュリティ、パストラバーサル攻撃、ファイルアップロードの安全性、ディレクトリトラバーサル、ZIPファイルのエクスプロイト、安全なアーカイブ処理、CVE-2025-3445、悪意のアーカイブ、リモートコード実行

ZIP Slip: どこでも起きるアーカイブ展開の脆弱性 📦

数千のアプリに影響を与える重大なセキュリティ脆弱性の理解

ZIP Slipとは何か？

技術的仕組み：ZIP Slipの動作原理

脆弱なコードパターン

悪意のあるアーカイブの構造

実世界の攻撃シナリオ

なぜこの脆弱性はどこにでも存在するのか

エコシステムの問題

最近の新たな事例

影響：攻撃者が達成できること

直接的な結果

二次的な攻撃経路

ZIP Slipの脆弱性を検出する方法

コード監査のテクニック

実行時の検出戦略

防止と緩和策

セキュアコーディングの実践

アプリケーションレベルの保護

インフラの考慮点

ZIP Slipの検出方法

テストケースの作成

自動化ツールによる検査

ファイルアップロード機能における検証の重要性

アップロードから実行までの流れ

業界の対応と現状

ベストプラクティスのまとめ

開発者向け

セキュリティチーム向け

組織向け

アーカイブセキュリティの未来

結論

追加リソース

Related Topics

Keep building with InstaTunnel

Share this article

More InstaTunnel Insights

数千のアプリに影響を与える重大なセキュリティ脆弱性の理解

ZIP Slipとは何か？

技術的仕組み：ZIP Slipの動作原理

脆弱なコードパターン

悪意のあるアーカイブの構造

実世界の攻撃シナリオ

なぜこの脆弱性はどこにでも存在するのか

エコシステムの問題

最近の新たな事例

影響：攻撃者が達成できること

直接的な結果

二次的な攻撃経路

ZIP Slipの脆弱性を検出する方法

コード監査のテクニック

実行時の検出戦略

防止と緩和策

セキュアコーディングの実践

アプリケーションレベルの保護

インフラの考慮点

ZIP Slipの検出方法

テストケースの作成

自動化ツールによる検査

ファイルアップロード機能における検証の重要性

アップロードから実行までの流れ

業界の対応と現状

ベストプラクティスのまとめ

開発者向け

セキュリティチーム向け

組織向け

アーカイブセキュリティの未来

結論

追加リソース

Related InstaTunnel pages

Related Topics

Keep building with InstaTunnel

Share this article

More InstaTunnel Insights