ファイルアップロードを容易にするウェブアプリケーションは、顧客、パートナー、従業員が様々なタイプの文書やファイルを共有するためのポータルとして機能し、多くの組織にとって不可欠なものとなっている。例えば、人事会社では履歴書をアップロードできるようにしたり、ある企業ではパートナーが専用のウェブプラットフォームを介してファイルを共有しやすくしたりすることができる。
セキュリティ対策が強化され、検証プロセスが厳しくなっても、攻撃者は巧妙な手法で脆弱性を悪用し続けています。画像のような一見無害に見えるファイルでも、ウェブ・サーバーのセキュリティを侵害するために操作されることがあります。
ポリグロットファイルとは、同時に複数のタイプとして有効なファイルのことで、攻撃者はファイルタイプに基づくセキュリティ対策をバイパスすることができます。例えば、GIFとRARファイルの両方として機能するGIFAR、JavaScriptとJPEGの両方として解釈されるJavaScript/JPEGポリグロット、PharアーカイブとJPEG画像の両方として認識されるPhar-JPEGファイルなどがあります。このようなポリグロットファイルは、欺瞞的な拡張子や空の拡張子によって検出されないことがあり、システムを「騙して」（画像やPDFのような）良性のファイルタイプであると思わせながら、検出されない悪意のあるコードを含んでいます。
ファイル・アップロードの検証
適切な、あるいは包括的な検証なしに、ユーザからのファイルアップロードを許可することは、ウェブアプリケーショ ンに重大な脅威をもたらします。攻撃者がウェブシェルのような悪意のあるファイルのアップロードに成功した場合、攻撃者は潜在的にサーバを制 御し、システムと機密データの両方を危険にさらす可能性があります。このようなリスクを軽減するために、開発者が効果的な検証対策を適用するためのベストプラクティスが確立されています。これらのベストプラクティスは、ファイルアップロードの安全な処理を保証し、悪用のリスクを最小化するのに役立ちます。
ファイル・アップロードの安全性を確保するための主な重点項目は以下の通りである：
- 拡張子の検証：ファイル拡張子のブロックリストまたは許可リストを実装し、許可されたファイルタイプのみが受け入れられるようにする。
- ファイル名のサニタイズ：アップロード時にファイル名にランダムな文字列を生成します。
- Content-Typeの検証：アップロードされたファイルのMIME-Typeを検証し、期待される形式と一致していることを確認します。
- 画像ヘッダーの検証：画像のアップロードでは、PHPのgetimagesize()のような関数を使用して、ヘッダーをチェックすることでファイルの有効性を確認することができます。
ファイル・アップロード・フィルター・バイパス
このような保護手段が実装されているにもかかわらず、攻撃者は検証メカニズムを迂回する手口を絶えず改良している。ヌル文字注入、二重拡張子、空の拡張子などのテクニックは、拡張子検証を弱体化させることができます。ファイルは、検出を回避するために「file.php.jpg」、「file.php%00.jpg」、「file.PhP」、「file.php/」のような名前で表示されるかもしれません。MIMEタイプの検証は、GIFファイルに関連するヘッダであるGIF89aに変更するなど、ファイルの最初のマジックバイトを変更することで回避することができます。さらに、悪意のある.htaccessファイルをアップロードしてサーバーの設定を操作することで、不正な拡張子のファイルを実行させることも可能です。
ポリグロットファイル攻撃
ファイルアップロードフィルタのバイパス技術を防ぐために、複数のセキュリティ対策を組み合わせた厳格な検証プロセスを実装しても、ポリグロットファイル（ポリグロット画像）を標的とする高度な攻撃は、依然として重大なセキュリティ上の脅威となっています。この手法により、攻撃者は、画像ファイルとして期待されるバイナリ構造に準拠しながら、異なるコンテキストで解釈されたときに同時に悪意のあるコードを実行できる画像などのファイルを作成することができます。これらのファイルの二重の性質は、従来の検証メカニズムを回避し、特定のシナリオにおける脆弱性を悪用することを可能にします。
ExifToolによるシンプルなポリグロットファイル
ポリグロット画像を生成する簡単なテクニックは、ExifToolを利用することです。この強力なアプリケーションは、EXIF、XMP、JFIF、Photoshop IRBなど、さまざまなメタデータ形式の読み取り、書き込み、変更を行うように設計されています。しかし、悪意のある人物は ExifTool を利用し、悪意あるポリグラフ画像の作成など、有害な行為を実行する可能性があります。ExifToolを使用して画像のEXIFメタデータ、特にUserCommentやImageDescriptionなどのフィールドに悪意のあるコードを埋め込むことで、攻撃者はポリグロット画像を生成し、悪用に成功する可能性を高めることができます。
以下に、画像に関連する包括的な情報を提供する、画像の EXIF メタデータを示します。
ExifToolを利用することで、脅威者は画像のEXIFメタデータ内に悪意のあるコードを埋め込むことができ、それによって検証メカニズムを回避する可能性のあるポリグロットファイルを作成することができる。
MIMEタイプの検証は基本的なウェブシェルファイルのアップロードを制限することができるが、このポリグロットイメージはこれらの制限を回避することができるため、攻撃者はポリグロットウェブシェルをアップロードすることができる。
攻撃者はその後、ポリグロット・ウェブ・シェルを悪用してウェブ・サーバーを制御することができる。
Javascript/JPEGポリグロットファイル
JavaScript/JPEGポリグロットファイルは、JPEG画像としてもJavaScriptスクリプトとしても有効な構造になっています。これを実現するためには、悪意のある行為者はJPEGファイルの内部構造を包括的に理解していなければなりません。この知識により、画像内に悪意のあるバイナリデータを正確に埋め込むことができ、JPEG画像としての有効性を損なうことなくJavaScriptエンジンで処理することができます。
JPEG画像は次のような構造をしている：
| バイト | 名称 |
| 0xFF, 0xD8 | 画像開始 |
| 0xFF, 0xE0, 0x00, 0x10, ... | デフォルトのヘッダー |
| 0XFF, 0XFE, ... | 画像コメント |
| 0xFF, 0xDB, ... | 量子化テーブル |
| 0xFF, 0xC0, ... | フレーム開始 |
| 0xFF, 0xC4, ... | ハフマン表 |
| 0xFF, 0xDA, ... | スキャン開始 |
| 0xFF, 0xD9 | 画像の終わり |
JPEG画像構造では、ヘッダーの後に長さ情報が続く。前の例で示したように、ヘッダーは0xFF 0xE0 0x00 0x10 というシーケンスで始まり、0x00 0x10は特にセグメントの長さを表し、16 バイトを示します。マーカー0xFF 0xD9は画像の終わりを示す。
JavaScript/JPEGポリグロットファイルを作成するには、JavaScriptエンジンがそれらを認識して処理できるように、画像の16進数値を変更する必要があります。
まず、JavaScriptでは、0xFF 0xD8 0xFF 0xE0というシーケンスは非ASCII値として解釈できますが、0x00 0x10は 無効なので変更する必要があります。これらの16進数値の適切な置き換えは0x2F 0x2Aで、これは/*の16進数表現であり、JavaScriptでコメントを開くために使用される構文です。この置換により、残りのバイナリデータはコメントの一部として無視される。
しかし、0x00 0x10はもともとJPEGヘッダーの長さを表しているため、これを10進数で12074に相当する0x2F 0x2Aに変更するには、その有効性を維持するためにJPEGヘッダーを再定義する必要があります。そのためには、ヌルバイトを追加する必要があり、JavaScriptのペイロードは、JPEG構造内の画像コメントを示す0xFF 0xFEマーカーの後に配置する必要があります。
例えば、ペイロードが*/=alert(document.domain);/*で、28バイト長の場合、必要なヌルバイトは 以下のように計算される：12074 (新しい長さ) - 16 (元のヘッダー長) - 2 (0xFF 0xFEマーカー) - 28 (ペイロード長) = 12,028ヌルバイト。
その結果、JPEG画像内のJavaScriptコードは以下のようになる：
最後に、シーケンス0x2A 0x2F 0x2F 0x2F（*///に対応）をJPEGエンドマーカー0xFF 0xD9の直前に配置する必要があります。このステップでJavaScriptのコメントを閉じ、JPEGファイルの構造を崩すことなくペイロードが正しく実行されるようにします。
この修正後も、画像は有効な画像として解釈され、同時に実行可能なJavaScriptコードを含むことができます。
HTMLファイルがこの画像をJavaScriptのソースコードとして読み込んでも、有効なままであり、埋め込まれたJavaScriptコードを実行することができます：
ポリグロット画像ファイルは、クライアントサイドでの悪用だけでなく、特定の状況下ではサーバサイドでの攻撃にもリスクをもたらします。この例として、Phar/JPEGポリグロットファイルが挙げられます。Phar/JPEGポリグロットファイルは、PHPアーカイブ(Phar)としてもJPEG画像としても解釈することができます。Phar ファイル構造は、メタデータにシリアライズされたデータを埋め込むことができ、 特に特定の PHP バージョンにおいて、デシリアライズ脆弱性の潜在的なリスクをもたらします。その結果、Phar/JPEGポリグロットファイルは、ファイルアップロードの検証を回避し、脆弱なサーバーを悪用するために利用される可能性があります。
Phar ファイル形式は、stub/manifest/contents/signature のようにレイアウトされ、Phar アーカイブに何が含まれているかという重要な情報をマニフェストに格納します：
- スタブ：スタブは、ファイルが実行可能なコンテキストでアクセスされたときに 実行される PHP コードの塊です。スタブの内容には特に制限はありませんが、最後に __HALT_COMPILER(); を書く必要があります。
- マニフェスト：このセクションにはアーカイブとその内容に関するメタデータが含まれ、serialize() フォーマットで保存されたシリアライズされた Phar メタデータが含まれることがあります。
- ファイルの内容：アーカイブに含まれるオリジナルファイル。
- 署名（オプション）：完全性検証のための署名情報を含む。
スタブは __HALT_COMPILER() の規定以上の内容制限を課さないので、脅威者はスタブに画像の 16 進値を注入することができる。これらの値をPHARファイルの先頭に置くことで、有効な画像として識別できる。その結果、以下の例で示すように、JPEG画像の16進数バイトを先頭に付加することで、PHAR/JPEGポリグ ロットを簡単に構築できる：
この方法により、生成されたポリグロットファイルは、有効な画像と正規のPHARファイルの両方として機能するため、特定のファイルアップロード検証メカニズムを回避するために使用することができる。
このポリグロットファイルはファイルアップロードフィルタをバイパスすることができますが、現在のところウェブサーバを悪用することはできません。PHARファイルやPHARポリグロットファイルを使ってウェブサーバを攻撃し、侵害するためには、ファイルのマニフェストに悪意のあるシリアライズされたメタデータを注入することが不可欠です。
ファイル操作(file()、file_exists()、file_get_contents()、fopen()、rename()、 unlink()など)に関連する特定のPHP関数(PHP ≤7.x)において、 PHARラッパー(phar://)を通してPHARファイルにアクセスすると、シリアライズされたメタデータに対して unserialize()関数がトリガーされます。結局のところ、PHP ガジェットチェーンを構築するために広く使われているツールである PHPGGC を利用することで、脅威者は PHAR ポリグロッ トファイルを通してデシリアライズの脆弱性を悪用し、ウェブアプリケーションサーバを危険にさらすことができます。
PHAR/JPEGポリグロットファイルとデシリアライズの脆弱性の組み合わせは、ファイルアップロードフィルタが実装されていても、攻撃者がウェブアプリケーションサーバに侵入することを可能にします。注目すべきことに、この侵害は画像ファイルの処理中でさえも起こり得ます。
ファイルアップロードフィルタを迂回し、PHAR ラッパー (phar://) をファイルの場所に付加するためにポリグロットのファイルを利用することで、攻撃者はウェブサーバがファイルを PHAR アーカイブとして扱うように操作できる。この操作により、デシリアライズの脆弱性が引き起こされ、ファイル操作関数を通してリモートでコードが実行される可能性がある。
アプリケーションにおけるポリグロットファイルに関連するリスクを伝えるため、アプリケーションに厳格なファイルアップロー ドフィルタを採用し、悪意のあるファイルや Web シェルのアップロードを防止している環境をシミュレートしました。このような安全策にもかかわらず、ポリグロット画像は検証プロセスを迂回し、特定の文脈ではリモートコード実行につながり、 最終的に脆弱なウェブアプリケーションサーバを危険にさらす可能性があります。
この例は、クライアント、パートナー、組織間でファイル共有を可能にする従来のウェブ・アプリケーションを示している：
MetaDefender Core MetaDefender ICAP これらの脅威からWebアプリケーションを保護し、ネットワークとインフラのセキュリティを強化します。Server
MetaDefender ICAP Server とMetaDefender Core が連携して、悪意のある PHAR/JPEG ポリグロッ トファイルを含む高度な攻撃からウェブサーバを保護します：
PHAR/JPEGポリグロットファイルがウェブアプリケーションにアップロードされると、まずMetaDefender Core MetaDefender ICAP Server に転送され、当社のDeep CDR ™ テクノロジーを使用して包括的なサニタイズ処理が行われます。単純なファイルタイプチェッカーとは異なり、Deep CDR はアップロードされたファイルの構造を徹底的に分析し、スクリプト、マクロ、ポリシー外のコンテンツを削除し、必要なデータのみを含むように JPEG ファイルを再構築します。
この処理は、JPEG エンドマーカ(0xFF 0xD9) の後に付加された有害な PHAR コンテンツを削除し、サニタイズされたファイルが厳密に JPEG であることを保証します。その結果、ウェブアプリケーションはPHAR/JPEGポリグロット攻撃から保護されます。たとえ攻撃者がファイル処理スキームを変更してPHARラッパーを注入できたとしても、ウェブサーバを悪用することはできません。
WAF（ウェブ・アプリケーション・ファイアウォール）、プロキシ、イングレス・コントローラーのいずれを使用しているかにかかわらず、確立されたネットワーク・セキュリティ・インフラを持つ組織は、MetaDefender ICAP Server によって防御メカニズムを強化することができる。このソリューションは、既存のウェブ・サーバーとMetaDefender Core の間にインターフェイスを作成し、すべての受信ファイルに対して透過的なセキュリティ・チェックポイントを確立する。ICAP インタフェースを経由してルーティングされたコンテンツは、ウェブサーバーに到達する前にスキャンおよび処理され、安全かつ正当なコンテンツのみがネットワークに入り、エンドユーザーに届くようになります。
このアプローチは、組織が既存のセキュリティ投資を活用しながら、さらに強力な保護レイヤーを追加できることを意味します。NGINXイングレス・コントローラーを使用している組織は、プロキシ設定によってMetaDefender ICAP Server を既存のインフラと統合できます。
OPSWATのアプローチは、従来の脅威検出を超えるものです。MetaDefender Core 不審なファイルに単にフラグを立てるのではなく、潜在的な脅威を積極的に無効化し、危険なファイルを安全で使用可能なコンテンツに変換します。ウェブサーバーと統合すると、MetaDefender ICAP Server ゼロデイ脅威やポリグロット攻撃に対する包括的な保護を提供します。
ファイルを信じない。Trust no device.の理念のもと、OPSWAT は、ネットワーク、データ、デバイスを保護し、既知および未知の脅威、ゼロデイ攻撃、マルウェアを防止する、インフラストラクチャのあらゆるレベルで特許取得済みのテクノロジーにより、世界中のお客様の課題を解決します。
