web-dev-qa-db-ja.com

これらのユーザーエージェントはどのような悪用を試みていますか？

私のサイトのユーザーエージェント追跡ページ（ Yandex にアーカイブ）を見たところ、これらのユーザーエージェントに気付きました。私のサーバー（PHPを使用したNginx）を悪用しようとする試みだと思います。その前の1は、ユーザーエージェントがNginxログに表示された回数です。これらも短縮されたユーザーエージェントであり、Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.86 Safari/537.36のような長いものではありません。 1月または2月のどこかで発生したと考えられるため、ログにアクセスできなくなりました（最も古いログは3月で、1月にサイトを作成しました）。

1 Mozilla/5.9}print(238947899389478923-34567343546345);{
1 Mozilla/5.9{${print(238947899389478923-34567343546345)}}
1 Mozilla/5.9\x22{${print(238947899389478923-34567343546345)}}\x22
1 Mozilla/5.9\x22];print(238947899389478923-34567343546345);//
1 Mozilla/5.9\x22

どのようなエクスプロイトが試行されましたか？これらのエクスプロイトが使用できないことを確認するためにどのようにテストできますか？

exploitwebserverwebnginx
50
Alexis Evelyn

なんらかのコマンドインジェクションを悪用しようとしているようです。 DarkMatterが彼の回答で述べたように、これはおそらく、具体的にターゲットにするのではなく、脆弱なサーバーを見つけるための広範な試みでした。ペイロード自体は、サーバーがコマンドインジェクションに対して脆弱かどうかを確認するためにテストしているように見えます。追加の目的はないようです。

これらの特定のペイロードの影響を受けるかどうかをテストするには、最も簡単な方法は、それらを独自のサーバーに送信して、それらがどのように応答するかを確認することです。ペイロード自体は無害であるため、私はこれだけを言っていることに注意してください。すべてのペイロードでこれを行うことはお勧めしません。

私の賭けはあなたのサーバーは脆弱ではないということです。私は実際にあなたのサーバーを悪用するためのフォローアップ要求を見ることを期待していたからです。

60
Dan Landberg

それはおそらく何もありません。それはそうではないときにその減算を評価して返すウェブサイトをウェブ全体で探しているスキャナーの広範なスパムのようです。かなり一般的なものです。

22
DarkMatter

実際の関数名（例print）の使用は、何らかの方法でevalを使用しているWebサイトを探していることを示唆しています（これはPHPのeval(string $code)、JavaScriptである可能性があることに注意してください） eval(string)、および他のスクリプト言語の同等物）。

実行可能コードは、Mozilla/の後の最初のversionパラメータの直後にあることに注意してください。つまり、この攻撃の作成者は、実際には十分なWebサイトがevalを2つのコンポーネント（major.minor）のバージョン番号を解析する（恐ろしい）方法として使用していると考えています。

だから私は脆弱なWebサイトが次のようにsomethingを実行していると想像します（疑似コード）：

var userAgent = request.headers["User-Agent"];

var indexOfVersion = userAgent.indexof( '/' );
var indexOfVersionEnd = userAgent.indexof( indexOfVersion , ' ' );

var versionText = userAgent.substring( indexOfVersion + 1, indexOfVersionEnd );
var versionNumber = eval( versionText ); // <------- this is the vulnerability!
22
The D

PHPコードをログファイルに挿入しようとしているようです。システム管理者がPHPアプリを使用してログを解析している場合、ログファイルを信頼できるものとして表示し（結局のところ、ユーザーは通常、ログファイルを直接変更することはできない）、そのため、サニタイゼーションプロセスを無視する可能性があります。

ログファイルをデスクトップまたはCLIテキストエディターで表示している場合、この攻撃に対して脆弱になることはありません。 PHPアプリを使用する場合は、ログを信頼できないものとして扱い、通常のユーザー入力フィールドと同じようにサニタイズしてください。

2
520

これは簡単です。彼らはしようとしているPHPコマンドインジェクション。プロセスは、ヘッダー（この場合はユーザーエージェントフィールド）を数式で置き換え、次にコードが実行されているかどうかを判断することです。値。コードが実行されると、戻り値は元の式ではなく、式の結果になります。解釈された言語をだますためによく使用される、開き括弧、閉じ括弧、セミコロン、およびその他の文字のわずかにスパム的な使用法に気づくでしょうデータを実行可能コードとして解釈する心配する必要はありません。このような自動化された脆弱性スキャンは、今日のコースに並ぶものです。

1
Steve Gazzo