NGINX による HTTPoxy 脆弱性の軽減

2016 年 7 月 18 日、「HTTPoxy」という脆弱性が発表されました。これは、一部の FastCGI 構成など、CGI または CGI のような環境で実行される一部のサーバー側 Web アプリケーションに影響を及ぼします。 これまでに影響を受けることがわかっている言語には、PHP、Python、Go などがあります。

特定の言語と CGI 実装をカバーする多数の CVE が割り当てられています。

• Apache HTTP サーバー(CVE-2016-5387)
• Apache Tomcat (CVE-2016-5388)
• 囲碁(CVE-2016-5386)
• PHP (CVE-2016-5385)

脆弱性を説明する新しい Web サイト、 CERT の脆弱性に関するメモ、および脆弱性の発見に関する説明があります。 Vend のオープンソース Web 開発者であるDominic Scheirlinckの個人 Web サイトに、追加情報が掲載されています。

この投稿では、脆弱性について説明し、NGINX または NGINX Plus を使用してサーバー上で脆弱性を悪用する試みを阻止する方法について説明します。

この脆弱性は名前空間の衝突によって発生します。 CGI または FastCGI のようなインターフェースは、HTTP 要求パラメータに基づいて環境変数を設定し、これによりアプリケーションの構成に使用される内部変数を上書きできます。

現在、この脆弱性の唯一の既知の悪用は、特定の HTTP クライアント ライブラリを使用して他のサービスに HTTP 要求を行う、CGI および CGI のような環境で実行されている Web アプリケーションに対するものです。 この場合、攻撃者はアプリケーションによって生成された内部リクエストを任意のサーバーにリダイレクトし、リクエストに含まれる秘密データを取得する可能性があります (以下を参照)。

NGINX または NGINX Plus を使用すると、この脆弱性を悪用する試みを識別して阻止できます。 そうすることで、攻撃を効果的に防ぐことができ、影響を受けるコードを監査して更新する時間ができます。

HTTPoxy脆弱性の悪用方法

この脆弱性がどのように機能するか、そしてサイトをこの脆弱性から保護する方法を理解するには、CGI および CGI のようなインターフェースが環境変数を設定する方法と、一部のアプリケーション ライブラリが環境変数によってどのように構成されるかを理解する必要があります。

1 – CGI および CGI のようなインターフェースは、HTTP_* という名前の環境変数を定義します。

多くの Web アプリケーション プラットフォームでは、CGI または CGI のようなインターフェイスを使用して、アプリケーションを Web サーバーに接続します。 これらのインターフェースは、HTTP リクエストのヘッダーをHTTP_で始まる環境変数に変換します。 アプリケーションは、環境を検査することで、リクエスト ヘッダー ( User-Agentなど) の値を検索できます。

クライアントは、適切なヘッダーを含むリクエストを送信することで、アプリケーションの環境に任意の環境変数 ( HTTP_で始まる) を作成できます。 たとえば、リクエスト ヘッダーFoo: bar は環境変数HTTP_FOO=barになります。

一部のプラットフォームでは、PHP の$_SERVERグローバル変数などの環境変数を隠す抽象化レイヤーが提供されています。 ただし、これらの抽象化は、環境変数を設定する標準的な CGI および FastCGI の手法に基づいて構築されています。

たとえば、FastCGI モードで実行している場合、PHP アプリケーションは次のようにしてリクエストのUser-Agentヘッダーを判別できます。

// どちらの方法も同じ結果を返します$useragent = getenv( 'HTTP_USER_AGENT' );
$useragent = $_SERVER['HTTP_USER_AGENT'];

2 – 一部のアプリケーションライブラリは環境変数から設定されます

複雑な Web アプリケーションは、外部ライブラリから機能を取得します。 たとえば、アプリケーションが他のサービスに HTTP リクエストを (マイクロサービスのような方法で) 送信する必要がある場合、一般的なサードパーティ ライブラリのいずれかを使用して送信することがあります。 これらのライブラリは、多くの場合、HTTP リクエストを中継するために使用される中間サーバーであるHTTP プロキシと呼ばれる機能をサポートしています。

このようなライブラリを構成する簡単な方法の 1 つは、環境変数を通じて構成を定義することです。 広く使用されているPHP Guzzleライブラリは、プロキシ サーバーのアドレスに設定されるHTTP_PROXYという環境変数によって部分的に構成されます。 HTTP_PROXYがこのように設定されている場合、ライブラリは生成するすべての HTTP 要求をプロキシ サーバーのアドレスに中継します。 Go のnet/httpパッケージと Python の Requests モジュールも同様にHTTP_PROXY環境変数を信頼し、解釈します。

3 – 脆弱性の性質

項目 2 で説明したライブラリは、CGI または CGI のようなインターフェイスを考慮して設計されておらず、信頼するHTTP_PROXY環境変数は、項目 1 で説明したように、CGI および FastCGI インターフェイスで使用されるHTTP_名前空間と重複しています。

HTTP_PROXY環境変数の値を独自に選択したアドレスに設定することにより、攻撃者はアプリケーションによって生成された内部 HTTP 要求をリダイレクトしてキャプチャできます。 これらのリクエストには、認証キーや個人データなどの機密情報が含まれている可能性があり、悪用される可能性のある追加の API やエンドポイントに関する情報が公開される可能性があります。

攻撃者は、プロキシヘッダーを含むリクエストを送信することでこれを実行でき、CGI または FastCGI インターフェイスは、アプリケーションの呼び出し用にHTTP_PROXYという名前の環境変数を自動的に作成します。 偽のProxyヘッダーを含むリクエストのみが直接影響を受けることに注意してください。

NGINX と NGINX Plus を使用した攻撃の阻止

HTTPoxy の脆弱性は NGINX に直接影響しませんが、NGINX と NGINX Plus を使用して、この脆弱性に基づく攻撃を阻止することができます。

アップストリーム FastCGI アプリケーションとの通信

NGINX を使用して、 HTTP_PROXY FastCGI パラメータを空の文字列に設定することにより、アプリケーションへの入力を「サニタイズ」できます。 これにより、FastCGI リクエストからパラメータが完全に削除されます。

fastcgi_param HTTP_PROXY "";

HTTP トラフィックの負荷分散とプロキシ

HTTP リクエストをアップストリーム アプリケーションにプロキシする場合、アップストリーム アプリケーションが脆弱なプラットフォーム上で実行されている場合に備えて、プロキシヘッダーを空の文字列に設定するのが賢明です。

proxy_set_header プロキシ "";

脆弱性を悪用する試みの検出

プロキシは標準の HTTP ヘッダーではないため、このヘッダーを含むリクエストはすべて疑わしいものと見なされる可能性があります。 NGINX または NGINX Plus を使用して、これらの疑わしいリクエストをbadactor.logという名前の専用アクセス ログに記録できます。

# http{} コンテキストで 'proxylog' 形式を定義します:log_format proxylog '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'"$http_proxy"';

# 'proxylog' 形式を使用して、プロキシ ヘッダーを含むリクエストをログに記録します
access_log /var/log/nginx/badactor.log proxylog if=$http_proxy;

注記： このaccess_logディレクティブを配置する構成コンテキストでは、NGINX 構成の上位レベルで定義されているアクセス ログが上書きされます。

安全にお過ごしください

NGINX と NGINX Plus は、HTTPoxy 攻撃を監視して阻止する効果的な方法を提供します。 上記の手法を使用して、脆弱性を排除するためにコードを監査、更新、テストしながらアプリケーションを保護します。

ご質問がある場合は、この投稿にコメントしてください。また、NGINX Plus の加入者の場合は、お気軽にサポート チームにお問い合わせください。