PHP OPcache の隠されたバックドア

0x00 前書き

このブログからの翻訳

この記事では、OPcache ファイルに隠されたマルウェアを検出および分析する戦略を模索します。バイナリ Web シェルでの PHP7 OPcache ファイルの非表示に関する前回の記事をまだ読んでいない場合は、続行する前に読むことをお勧めします。

0x01 OPcache

OPcache は、PHP7.0 の新しい組み込みキャッシュ エンジンです。 PHP スクリプトをコンパイルし、結果のバイトコードをメモリに保存するように設定します。

キャッシュ ターゲット フォルダーは php.ini で指定することもできます。

opcache.file_cache=/tmp/opcache

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) では、現在の zend バージョンと php (7.0.4-7) で生成される system_id は 81d80d78c6ef96b89afaadc7ffc5d7ea です。このハッシュは、インストール中にバイナリ互換性を確保するために使用される可能性が高くなります。このディレクトリは、OPcache が最初のファイルをキャッシュするときに作成されます。

後で説明するように、各 OPcache ファイルのヘッダー フィールドに system_id が保存されます。

興味深いのは、OPcache によって生成されたすべてのフォルダー/ファイル (/tmp/opcache の下にあるすべて) には、このユーザーが実行するサービスとして書き込み権限があることです。

opchache フォルダーの権限は次のとおりです。

#!shell$ ls /tmp/opcache/drwx------ 4 www-data www-data 4096 Apr 26 09:16 81d80d78c6ef96b89afaadc7ffc5d7ea

上記のとおり、OPcache 経由で生成されたフォルダーは www-data ユーザーによって書き込み可能であり、書き込み権限を持っています。 OPcache ディレクトリへの書き込みアクセス権がある場合は、コンパイルされた Web シェルでキャッシュされたファイルを書き換えることで、任意のコードを実行できます。

0x02 攻撃ケース

まず、キャッシュ フォルダーの場所 (/tmp/opcache/[SYSTEM_ID]) とターゲットの PHP ファイルの場所 (/var/ WWW/) を取得する必要があります。 ...)

話を簡単にするために、Web サイトに phpinfo() ファイルが残されていると仮定します。このファイルから、キャッシュ フォルダーの場所、ファイルのソース コードの場所、および必要なすべてのフィールドを取得できます。 SYSTEM_IDを計算します。 (Web サイトの phpinfo からシステム ID() を計算するツールを作成しました。このツールは GitHub リポジトリにあります)。

ターゲット Web サイトもファイルを簡単にアップロードできる必要があることに注意してください。

デフォルトの php.ini 設定が使用されていると仮定します:

opcache.validate_timestamp = 0    ; PHP 7's default is 1opcache.file_cache_only = 1       ; PHP 7's default is 0opcache.file_cache = /tmp/opcache

攻撃の仕組みは次のとおりです: 任意のファイルを /var/www にアップロードできる Web サイトを発見しました。私たちの目標は、/tmp/opcache/[system_id]/var/www/index.php.bin をバックドアを含む独自のファイルに置き換えることです。

1.index.php という名前のローカル WebShell 悪意のある PHP ファイルを作成します。

#!php<?php    system($_GET['cmd']); ?>

2. php.ini ファイルの設定 opcache.file_cache を次のように設定します。あなたの選んだ場所。

3. Web サービスを実行し、PHP -S 127.0.0.1:8080 を使用して、index.php ファイルのリクエストを送信してキャッシュ エンジンをトリガーします。単純な wge t127.0.0.1:8080 で十分です。

4. 手順 1 で指定したキャッシュ フォルダーに移動すると、index.php.bin という名前のファイルが見つかります。これは、Web シェルのコンパイルされたバージョンです。

5. ローカルの SYSTEM_ID がターゲットとは異なる場合があるため、index.php.bin を開いて system_id を変更する必要があります。前に述べたように、system_id は総当たり攻撃または phpinfo() 関数を使用したサーバー情報によって計算できます。ファイル署名の system_id が配置されている右側を置き換えるには、次のようにします。

6. ファイル アップロードの脆弱性を使用して、ファイル /tmp/opcache/[system_id]/var/www をアップロードします。 /index.php。

7. Web サイトのindex.php ファイルを更新すると、Web シェルが実行されます。

0x03 さらに詳しく

php.ini で少なくとも 2 つの構成を設定すると、別の動作が作成されます。

Disabling file_cache_onlyEnabling validate_timestamp

メモリ キャッシュのバイパス (file_cache_only = 0)

メモリ キャッシュ ファイル キャッシュがファイル キャッシュより優先される場合、OPcache ファイルの上書きは実行されません

私たちのウェブシェル。 Web サイトサーバーを再起動すると、この制限を回避できます。メモリ キャッシュがクリアされるため、OPcache はファイル キャッシュを使用してメモリ キャッシュを埋め、Webシェルを実行します。

この動作から、再起動しなくても WebShell を実行できるようです。

WordPress などのフレームワークには、まだ公開されている古いファイルがいくつかあります (例: function.php )。

これらのファイルは非推奨であるため、メモリにロードされないか、ファイル システムにキャッシュされたバージョンがありません。悪意のあるペイロード (functions.php.bin) をアップロードし、関連する Web ページ (/wp-includes/registration-functions.php) をリクエストすると、OPcache はバイナリ Web シェルを実行します。

タイムスタンプ検証のバイパス (validate_timestamps = 1)

タイムスタンプ検証が有効な場合、OPcache はリクエストされた PHP ソース ファイルのタイムスタンプをチェックし、キャッシュされたファイルのタイムスタンプ ヘッダー フィールドと比較します。一致しない場合、キャッシュ ファイルは破棄され、新しいキャッシュ ファイルが作成されます。この制限を回避するには、攻撃者はターゲット ソース ファイルのタイムスタンプを知っている必要があります。

そうは言っても、WordPress などのフレームワークでは、ソース ファイルのタイムスタンプは、zip または tar に抽出されたときのものです。

これで興味深いのは、一部のファイルが 2012 年以来変更されていないことです (functions.php およびRegistration.php ファイル)。したがって、これらの WordPress タイムスタンプは複数のバージョンにわたって同じになります。タイムスタンプを知っている攻撃者は、それに応じてペイロードを変更し、validate_timestamps を設定してキャッシュを上書きすることができます。タイムスタンプはファイルの先頭から 34 バイトにあります:

0x04 結論

要約すると、この新しい攻撃ベクトルは、特定の強化された環境向けの追加のマイニング手法です。これは、PHP アプリケーションに影響を与える一般的な脆弱性ではありません。 Ubuntu 16.04 などの PHP 7.0 リリースの登場により、この攻撃では、ファイル アップロードの脆弱性を回避するためにコードのレビューを強化し、潜在的に危険なサーバー構成に警戒する必要があります。