この記事では、PHP7 OPcache エンジンのセキュリティ問題について説明し、新しい脆弱性悪用テクノロジについても紹介します。この攻撃方法により、Web ディレクトリでのファイルの読み書きの禁止やその他のセキュリティ対策など、特定のセキュリティ強化テクノロジを回避できます。さらに、攻撃者はこの攻撃手法を使用して、ターゲット ホストで悪意のあるコードを実行することもできます。
OPcahce
OPcache は、PHP 7.0 に組み込まれた新しいキャッシュ エンジンです。 PHP スクリプト コードをコンパイルし、コンパイル結果をバイトコードの形式でメモリに保存できます。
OPcache は、PHP スクリプトのプリコンパイルされたバイトコードを共有メモリに保存することにより、PHP のパフォーマンスを向上させます。プリコンパイルされたバイトコードを保存する利点は、毎回の PHP スクリプトの読み込みと解析のオーバーヘッドを節約できることです。
さらに、ファイル システム キャッシュ機能も提供できますが、PHP.ini 設定ファイルでキャッシュ情報のターゲット フォルダー パスを定義する必要があります:
opcache.file_cache=/tmp/opcache
上記のフォルダーにある場合、OPcache はコンパイルされた PHP スクリプトを、対応する PHP スクリプトと同じディレクトリ構造に保存します。たとえば、コンパイルが必要なコードは /var/www/index.php に保存され、コンパイルされたコードは /tmp/opcache/[system_id]/var/www/index.php.bin に保存されます。
上記のファイルパスのsystem_idは、現在のPHPバージョン情報、Zendフレームワークの拡張ID、各種データ型情報を含むMD5ハッシュ値です。 Ubuntu オペレーティング システムの最新リリース (16.04) では、system_id は現在の Zend フレームワークと PHP のバージョン番号 (81d80d78c6ef96b89afaadc7ffc5d7ea) で構成されます。 OPcache がこれらのファイルを初めてキャッシュするとき、対応するディレクトリがファイル システムに作成されます。
次の章で説明するように、各 OPcache ファイルはファイルのヘッダー フィールドに system_id のコピーも保存します。
この時点で、OPcache フォルダーについて言及する必要があります。非常に興味深い点の 1 つは、ユーザーがこのサービスを有効にすると、OPcache によって生成されたすべてのフォルダーまたはファイルがユーザーに与えられることです (すべてのファイルとフォルダーは、 /tmp/opcache/ ディレクトリ) 書き込み権限。
OPcache フォルダー内の権限情報は次のとおりです:
$ ls /tmp/opcache/
drwx------ 4 www-data www-data 4096 Apr 26 09:16 81d80d78c6ef96b89afaadc7ffc5d7ea
ご覧のとおりご覧のとおり、www-data グループに属するユーザーは、OPcache によって生成されたフォルダーへの書き込み権限を持っています。 OPcache ディレクトリへの書き込み権限がある場合は、ディレクトリ内のキャッシュ ファイルを上書きし、Web シェルを使用して任意のコードを実行できます。
攻撃シナリオ
まず、キャッシュフォルダーの保存パス (/tmp/opcache/[system_id]) とターゲットの PHP ファイルの保存パス (/var/www/...) を取得する必要があります。
誰でも理解しやすいように、Web サイトのディレクトリに phpinfo() ファイルがあると仮定します。キャッシュ フォルダーの保存場所とファイルのソース コードは、このファイルから取得するときに必要になります。 system_id を計算する これらのデータを使用します。私たちは、Web サイト phpinfo() から情報を抽出し、system_id を計算するツールを開発しました。このツールは GitHub リポジトリで入手できます。
ここで、ターゲット Web サイトにはアップロードされるファイルに制限があってはいけないことに注意する必要があります。
ここで、デフォルトの設定情報に加えて、次の設定データも php.ini に追加されると仮定します。デフォルトは 0 です
opcache.file_cache = /tmp/opcache
次に、攻撃の実行プロセスについて説明します:
Web サイトに脆弱性が見つかりました。つまり、Web サイトは私たちにアップロードされません。制限なしでファイルを作成できます。私たちの目標は、ファイル /tmp/opcache/[system_id]/var/www/index.php.bin をバックドアを含む悪意のあるコードに置き換えることです。
上の画像は、脆弱性を含む Web サイトのインターフェイスを示しています。
1. Webshell を含む悪意のある PHP ファイルをローカルに作成し、「index.php」という名前を付けます:
system($_GET['cmd']);
?>
2. opcache.file_cache の関連設定を PHP.ini ファイルに追加します。3. php -S 127.0.0.1:8080 コマンドを使用して Web サーバーを起動し、サーバーから Index.php ファイルをリクエストして、キャッシュ エンジンをトリガーします。このステップでは、コマンド wget 127.0.0.1:8080 を使用するだけで目的を達成できます。
4. 最初のステップで設定したキャッシュ フォルダーを見つけると、index.php.bin という名前のファイルが見つかります。このファイルはコンパイルされた Web シェルです。
上の図は、OPcache によって生成されたindex.php.bin を示しています。
5. ローカルの system_id はターゲット ホストの system_id と異なる可能性があるため、index.php.bin ファイルを開いて、system_id をターゲット ホストの system_id に変更する必要があります。前に述べたように、system_id は、たとえば総当たりによって推測されたり、phpinfo() ファイル内のサーバー情報に基づいて計算されたりする可能性があります。以下の図に示すように、ファイル署名データの後に system_id を変更できます。
上の図は、system_id のデータ保存場所を示しています。
6. ターゲット Web サイトにはアップロードされるファイルに制限がないため、ファイルをサーバー ディレクトリにアップロードします:
/tmp/opcache/[system_id]/var/www/index.php.bin
7. Web サイトのindex.php を更新すると、Web サイトは Web シェルを自動的に実行します。
メモリ キャッシュをバイパスします (file_cache_only = 0)
メモリ キャッシュの優先順位がファイル キャッシュよりも高い場合、OPcache ファイルを書き換えても Web シェルは実行されません。サーバーがホストする Web サイトにファイルのアップロード制限の脆弱性がある場合、サーバーの再起動後にこの制限を回避できます。メモリ キャッシュはクリアできるため、OPcache はファイル キャッシュを使用してメモリ キャッシュを埋め、Webシェルを実行するという目的を達成します。
これは、サーバーを再起動せずに Web シェルを実行する方法がまだあることを意味します。
WordPress などの Web サイトフレームワークには、registration-functions.php など、公的にアクセスできる古いファイルがまだいくつかあります。
これらのファイルは古いため、システムはこれらのファイルをロードしなくなります。つまり、これらのファイルはメモリやファイル システム キャッシュに存在できません。悪意のあるコード (registration-functions.php.bin) をアップロードし、関連する Web ページ (/wp-includes/registration-functions.php) にアクセスすると、OPcache は自動的に Web シェルを実行します。
タイムスタンプ認証をバイパスする (validate_timestamps = 1)
タイムスタンプは通常、特定の瞬間を一意に識別する一連の文字です。一般に、タイムスタンプを生成するプロセスは次のとおりです。ユーザーはまず、タイムスタンプを付ける必要があるファイルをハッシュ エンコーディングで暗号化して要約を作成し、次にその要約を DTS に送信し、受信したファイルの要約の日付と時刻の情報を追加します。ファイルは暗号化され (デジタル署名され)、ユーザーに返送されます。
サーバーがタイムスタンプ認証機能を有効にしている場合、OPcache は要求された PHP ソース ファイルのタイムスタンプを検証し、ファイルがキャッシュ ファイル ヘッダー フィールドのタイムスタンプと一致する場合、サーバーはアクセスを許可します。タイムスタンプが一致しない場合、キャッシュ ファイルは破棄され、新しいキャッシュ ファイルが作成されます。この制限を回避するには、攻撃者はターゲット ソース ファイルのタイムスタンプを知っている必要があります。
これは、WordPress などの Web サイト フレームワークでは、開発者が圧縮パッケージからコード ファイルを抽出するときにタイムスタンプ情報が変更されないため、ソース ファイルのタイムスタンプを取得できることも意味します。
上の画像は、WordPress/wp-includes フォルダー内の情報を示しています。
興味深いことに、これらのファイルの一部は 2012 年以来変更されていません (次の 2 つのファイルにご注意ください:registration-functions.php とRegistration.php)。したがって、これらの同じファイルのタイムスタンプは、WordPress のバージョンが異なっていても同じになります。ファイルのタイムスタンプ情報を取得した後、攻撃者は悪意のあるコードを変更し、サーバーのキャッシュ データを上書きする可能性があります。タイムスタンプ情報は、ファイルの先頭の 34 番目のバイト位置にあります:
デモ ビデオ
ここでは、短いデモ ビデオを提供し、ビデオで攻撃手順を説明します:
ビデオ アドレス: https ://youtu.be/x42l-PQHhbA
前に述べたように、必要なツールは GitHub コード リポジトリで入手できます。
概要
つまり、これは PHP の一般的な脆弱性ではないため、この新しい攻撃方法は PHP を使用して開発されたアプリケーションには影響しません。現在、多くの Linux ディストリビューション オペレーティング システム (Ubuntu 16.04 など) はデフォルトで PHP 7 をインストールするため、この攻撃手法について学んだ後は、開発プロセス中にコードをより慎重にレビューし、ファイルのアップロード制限があるかどうかを確認する必要があります。この脆弱性はサーバーのセキュリティに影響を与えるため、Web サイトに脆弱性が存在します。
この記事は360セキュリティ放送から翻訳されたものです。転載する場合は「360セキュリティ放送から転載」と明記の上、リンクを貼ってください。
元のリンク: http://blog.gosecure.ca/2016/04/27/binary-webshell-through-opcache-in-php-7/
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
