nginxの脆弱性、写真のアップロードで100万台のサーバーに侵入可能 nginx+php注意

nginxの脆弱性、画像アップロードで100万サーバーに侵入可能 nginx+php注意
国内トップクラスのセキュリティチーム80secは、5月20日午後6時にnginxに関する脆弱性の存在を通知し、nginx+phpで構築されたWebサイトは、画像のアップロードが可能な限りハッキングされる可能性があると発表した。 5 月 21 日、nginx はまだ脆弱性を修正するパッチをリリースしていませんでした。

Netcraft の統計によると、2010 年 4 月まで、世界中で 1,300 万台のサーバーが nginx プログラムを実行していました。非常に控えめに見積もっても、そのうち少なくとも 600 万台が nginx を実行しており、PHP サポートが有効になっています。控えめに見積もっても、そのうちの 1/6、つまり 100 万台のサーバーでユーザーが画像をアップロードできます

nginx の脆弱性のため、これらの 100 万台のサーバーは、ハッカーによって画像をアップロードすることで簡単にトロイの木馬を埋め込まれる可能性があります。トロイの木馬を埋め込むプロセスも非常に簡単で、写真をアップロードするようにトロイの木馬を変更するだけです。被害は非常に深刻なので、詳細については説明しません。ご興味がございましたら、http://www.80sec.com/nginx-securit.html をご覧ください

ここまで述べましたが、トップ セキュリティ チームである Su Baozi が行う 80sec については、皆さんもっと興味があると思います。簡単な紹介をします。

80sec チームは、若く、精力的で、体力があり、情熱的でクリエイティブな未婚の dota 男性のグループで構成されており、彼らは全員、大手インターネット企業で情報セキュリティの仕事に従事しています。蘇宝子もこの観点に強く同意します。「物事に精通していれば、その欠点を客観的に発見することができ、同時にその物の長所も発見することができます。」

80sec は「ポート 80 のセキュリティ」、つまり「Web セキュリティ」を意味すると同時に、チームメンバーは全員 80 年代生まれの若者であるため、「80 番ポートのセキュリティ」とも理解できます。 「the 80s」; さらに、sec の発音はセ・ケであるため、「80 年代以降のセックス ゲスト」、「80 年代以降の写真家」、または「80 年代以降の S ゲスト」とも理解できます。80 秒についての私たちの理解は次のとおりです。私たちの想像力によってのみ制限されます。

彼らは、IIS、IE、FireFox、Maxthon、Window of the World、PHHPWind、DeDeCMS、QQ mail、QuarkMail、EXTMail およびその他のソフトウェアの脆弱性を発見し、達成したことを示しています。素晴らしい結果。

80sec を紹介したので、もう 1 つのトップ セキュリティ チームである 80vul を紹介する必要があります。このチームは WEB セキュリティに重点を置いています。このチームも 80 年代生まれの少年で構成されています (90 年代以降の世代が多く含まれています)。 IE、Gmail、wordpress、PHPWind、DISCUZ、MYBB などの WEB APP にも多数のセキュリティ脆弱性が発見されています。

これを見て、誰もが心の中で悔しい思いをしているはずで、だからこそ1980年代生まれの女性ハッカーはいないのです（私は女装者を差別しているわけではありませんが、女装者ではないと言わざるを得ません）。私も同じ後悔をしています。

最後に、ハッカーがすでに活動していると言われています。セキュリティ担当者とシステム管理者は、危険を冒して脆弱性を修復する必要があります。そうしないと、次の攻撃を受ける可能性があります。それはあなたのウェブサイトです。 80sec のセキュリティ情報の説明によると、一時的な修正方法は次の 3 つから選択できます。

1. php.ini の cgi.fix_pathinfo を 0 に設定し、php を再起動します。最も便利ですが、設定を変更した場合の影響は自分で評価する必要があります。

2. nginx の vhost 設定に次の内容を追加し、nginx を再起動します。 vhost が少ない場合にも便利です。

if ( $fastcgi_script_name ~ ..*/.*php ) {

return 403;

}

3. をアップロードすることは禁止されています。 PHPプログラムを説明するディレクトリ。仮想ホストとサーバーが多数ある場合は、Web サーバーを移動する必要はありません。仮想ホストとサーバーが少ないときに使用することをお勧めします。

著者: Hily 元のリンク: http://hily.me/blog/2010/05/nginx-php-configure-security-problem/
著作権表示: 再版できますが、使用する必要があります。転載する場合はスーパー リンクフォームには記事の出典元、著者情報、著作権表示が記載されています



脆弱性のリスクレベル: 壊滅的。
厳密に言えば、この脆弱性は Nginx や PHP 自体の脆弱性によって引き起こされるのではなく、設定によって引き起こされます。この脆弱性は、私が以前に書いた多くの構成で蔓延しています。

簡単な検出方法:
Nginx + PHP サーバー上の任意の画像を開きます。たとえば、

画像のリンクの後に /xxx.php の文字列を追加すると (xxx は任意の値)

イメージにまだアクセスできる場合は、構成に抜け穴があることを意味します。

脆弱性分析:
以下では、非常に一般的な Nginx 構成を分析することによって脆弱性の原因を説明します:
server {
listen 80;
server_name test.local;

access_log /work/www/logs/test.access.log main;
error_log /work/www/logs/test.error.log;

location / {
root /work /www/test;
インデックス Index.html Index.htm Index.php;
}

location ~ .php$ {
root /work/www/test;
fastcgi_indexindex.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
fastcgi_pass unix:/tmp/php-fpm.sock;
}
}

次の内容を持つ新しいファイル test.png を /work/www/test/ ディレクトリに作成します:
次に、 にアクセスすると、出力はテキスト コンテンツです:
しかし、 /xxx.php が最後に追加されるとき、つまり http://test.local/test.png/xxx.php では、何か恐ろしいことが起こります:
Array
(
[HOSTNAME] ] =>
[PATH] => /usr/local/bin:/usr/bin:/bin
[TMP] => /tmp
[TMPDIR] => /tmp
[ TEMP] => /tmp
[OSTYPE] =>
[MACHTYPE] => 2
[USER] => [ホーム] ] = > /home/www
[FCGI_ROLE] => レスポンダー
[SCRIPT_FILENAME] => /work/www/test/test.png
[QUERY_STRING] =>
REQUEST_METHOD] => GET
[CONTENT_TYPE] => [CONTENT_LENGTH] =>
[SCRIPT_NAME] => /test.png/xxx.php
[REQUEST_URI] => /test .png/xxx.php
[DOCUMENT_URI] => /test.png/xxx.php
[DOCUMENT_ROOT] => /work/www/test
[SERVER_PROTOCOL] => /1.1
[ゲートウェイ_インターフェイス] => CGI/1.1
[サーバー_ソフトウェア] => nginx/0.7.62
[リモート_ポート] => 192.168.1.163
🎜 > [SERVER_ADDR] => 192.168.1.12
[SERVER_PORT] => 80
[SERVER_NAME] => test.local
[HTTP_ACCEPT] => ; 画像/gif、画像/x-xbitmap、画像/jpeg、画像/pjpeg、アプリケーション/x-shockwave-flash、アプリケーション/QVOD、アプリケーション/QVOD、アプリケーション/x-ms-アプリケーション、アプリケーション/x-ms -xbap 、application/vnd.ms-xpsdocument、application/xaml+xml、application/vnd.ms-excel、application/vnd.ms-powerpoint、application/msword、*/*
[HTTP_ACCEPT_LANGUAGE] => -cn
[HTTP_ACCEPT_ENCODING] => gzip、deflate
[HTTP_USER_AGENT] => Mozilla/4.0 (互換性; MSIE 6.0; Windows NT 5.1; SV1; QQPinyin 689; QQDownload 627; Mozilla/4.0 (互換性; MSIE 6.0; Windows NT SV1) ; .NET CLR 3.0.4506.2152; 🎜> [HTTP_CONNECTION] => キープアライブ
[ORIG_SCRIPT_FILENAME] => /work/www/test/test.png/xxx.php
[PATH_TRANSLATED] => 🎜> [PHP_SELF] => /test.png/xxx.php
[REQUEST_TIME] => 1274125615
)
環境変数では、SCRIPT_FILENAME が Nginx から渡されます:
fastcgi_param SCRIPT_FILENAME $ document_root$ fastcgi_script_name;
$fastcgi_script_name 変数の説明については、次を参照してください:
http://wiki.nginx.org/NginxHttpFcgiModule

Nginx から PHP に渡される値は /work/www/ ですtest/test.png/ xxx.php、これは $_SERVER の ORIG_SCRIPT_FILENAME の値ですが、$_SERVER の SCRIPT_FILENAME は /work/www/test/test.png です。
その理由は、/work/www/test/test.png/xxx.php が存在しないためです。これらの存在しないパスの場合、PHP はパス内に存在するファイルをチェックし、冗長な部分を PATH_INFO として扱います。
ここで、/work/www/test/test.png は PHP によって SCRIPT_FILENAME として解析され、/xxx.php は PHP によって PATH_INFO として解析されて破棄されるため、$_SERVER には表示されません。

解決策:
この脆弱性に対する解決策は明らかです。上記の解析をオフにするだけです。
この解析は PHP 構成ファイルで設定でき、デフォルトで有効になっています。ここではそれをオフにする必要があります:
; cgi.fix_pathinfo は、CGI の *本当の * PATH_INFO/PATH_TRANSLATED サポートを提供します。
; 以前の動作では、PATH_INFO を grok しませんでした。これを 1 に設定すると、PHP CGI が仕様に準拠するようにパスを修正します。
; を 0 に設定すると、デフォルトは 1 になります。スクリプトを修正する必要があります。 >; PATH_TRANSLATED ではなく SCRIPT_FILENAME を使用します。
; http://php.net/cgi.fix-pathinfo
;cgi.fix_pathinfo=1
cgi.fix_pathinfo=0
ここで、cgi.fix_pathinfo =0 は新しい設定行で、PHP の自動 PATH_INFO 検出をオフにすることを意味します。閉じると、構成の脆弱性を排除できます。

より良い解決策はありますか?
上記の解決策は最も完璧ではありません。以前に cgi.fix_pathinfo 機能を使用したことがある場合、その機能が閉じられた後、私のブログ (Wordpress) 記事の URL ディレクトリ形式に大きな影響が生じます。リライトを使用して実装されます。
拡張子が .php のファイルのみを解析するように PHP を設定できれば、この問題はより合理的に解決されます。
しかし、関連する設定項目は見つかりませんでした。もしかしたら、将来的には php-fpm 設定ファイルに表示されるはずです。

概要:
この種の問題は基本的に予測できませんが、アーキテクチャが適切に設計されていれば、この問題が存在してもセキュリティには影響しません。アーキテクチャ上のセキュリティに関する提案は次のとおりです:
* 動的コンテンツと静的コンテンツをできるだけ分離します。PHP は静的コンテンツ サーバー上に存在するため、静的ファイルは解析されません。