攻撃者はシステムの設計ミスや設定不備など、さまざまな穴を突いてシステムへ侵入しようとしてきます。その種類や手法はさまざまで、世の中で話題に上るような有名な脆弱性についてはご存じの方も多いのではないでしょうか？
しかし、話題に上ることが少ないマイナーな脆弱性の中にも、実際に攻撃が成功すると大変危険なものが存在します。今回はそのような“有名ではないけれどインパクトが大きい脆弱性”を三つご紹介します。
Apache HTTP ServerのOSコマンド実行脆弱性
マイナーな脆弱性の中でも比較的有名な脆弱性が、2021年に見つかったパストラバーサルの脆弱性である「Apache HTTP ServerのOSコマンド実行脆弱性（CVE-2021-41773）」です。発表された当時は騒がれていましたが、後に発表された「Log4Shell」という大きな脆弱性に話題が奪われた印象があります。
パストラバーサルとは、サーバ内で本来アクセスが想定されている範囲を超えて、より上位のディレクトリ・ファイルにアクセスできてしまう脆弱性です。攻撃者は../といったパスの遡上を表す記号列をパラメータに挿入することで、上位のディレクトリ・ファイルに対して不正アクセスすることが可能になります。
パストラバーサルについての詳細は、別記事で解説予定です。
Apacheの場合、本来はドキュメントルート（/var/www/html、/usr/local/apache2/htdocs等）より上位のパスにはアクセスできないよう、適切に../が除去されています。
しかし、本脆弱性が存在するApache 2.4.49においては../を判定して除去する処理に不備があり、パーセントエンコーディングを完全にデコードする前に../の判定を行っていました。
そのため.(ドット)をパーセントエンコーディングした%2e%2e/という記号列を利用することで、../の判定処理を回避して上位のパスにアクセスできてしまっていました。
さらにこの脆弱性の怖い点は、Apacheの設定によっては、URLで指定されたファイルを読み込むだけではなく OSコマンドが実行できてしまうため、サーバ上にあるデータの窃取や改ざんなど、さまざまな攻撃につながる可能性があるところです。
対策は、Apache HTTP Serverのバージョンを2.4.51以上にアップデートすることです。
（※2.4.50で一度修正されましたが、修正内容に不備があり回避可能でした。）
X-Forwarded-Forヘッダを利用したアクセス制御回避
二つ目の刺さると怖いマイナーな脆弱性は、「X-Forwarded-Forヘッダを利用したアクセス制御回避」です。
X-Forwarded-Forヘッダとは、ロードバランサなどの機器を経由してWebサーバに接続する際にクライアントのIPアドレスをサーバ側に伝える役割を持つヘッダです。途中にロードバランサが複数あるケースでは、カンマ区切りでIPアドレスが追加されていくのが一般的です。
そのため一見すると、WebサーバはX-Forwarded-Forヘッダの値の一番左側のIPアドレスをクライアントのIPアドレスと判断できるように思えます。
しかし、HTTPリクエストの内容はユーザが自由に改ざんすることができるため、攻撃者によってあらかじめX-Forwarded-Forヘッダに任意のIPアドレスが追加されていた場合はどうなるでしょうか？
下図の例では、ローカルからのアクセスであると認識されるIPアドレス（127.0.0.1）を追加しています。
このとき、WebサーバがX-Forwarded-Forヘッダの値の一番左を見てクライアントを識別してしまうと、攻撃者による外部からのアクセスも結果としてローカルからのアクセスだと誤認識してしまい、アクセス制御を回避できてしまいます。
これにより社内からのアクセスに限定しているはずのシステムやDBの管理コンソールに外部からアクセスできてしまい、結果として情報漏洩やデータの窃取・改ざん等につながる可能性があります。
対策は、まず「経由する可能性のあるロードバランサの一覧」をあらかじめ定義しておきます。アクセスされた際、WebサーバはX-Forwarded-Forヘッダの右側から順にその一覧と照合し、一覧にないIPアドレスが出現した段階でそのIPアドレスがクライアントの本来のIPアドレスであると判断し、それをもとにアクセス制御を行うようにします。
Apacheの場合は、RemoteIPTrustedProxyやRemoteIPInternalProxyにロードバランサの一覧を定義することができます。
Matrix URIの解釈違いによるパストラバーサル
三つ目の刺さると怖いマイナーな脆弱性は、「Matrix URIの解釈違いによるパストラバーサル」です。
Matrix URIとは、パス中にセミコロンで区切って付与されるパラメータを含むURIのことです。
下記の例では、/foo/barにアクセスする際、付加情報としてnameやageが扱われています。
|
例）/foo;name=john;age=24/bar |
ただし、Matrix URIはURIの仕様として明確に定められているものではないため、サーバにより解釈がバラバラになってしまうという問題があります。
例えば、/foo;name=john/barというURIでアクセスした際、各サーバがどの様にパスを解釈するのかを次の表に示します。
| サーバ | パス解釈 |
| Apache（HTTP Server） | /foo;name=john/bar |
| Nginx | /foo;name=john/bar |
| IIS | /foo;name=john/bar |
| Tomcat | /foo/bar |
| Jetty | /foo/bar |
| WildFly | /foo |
| WebLogic | /foo |
Apacheはセミコロンで区切られた部分をパラメータとして認識しないため、foo;name=johnディレクトリの中にあるbarファイルにアクセスしようとしますが、Tomcatはセミコロンで区切られた部分をパラメータとして認識するため、fooディレクトリ内のbarファイルにアクセスする、といった具合です。
Apacheをリバースプロキシとして、その後ろでTomcatが動いているようなケースを例に説明します。
ここでは/portal配下で公開アプリケーションが、/manager/html配下でTomcatの管理画面がそれぞれ動いており、なおかつApacheで/manger配下に対してアクセス制限（IP制限等）を行っているとします。
このとき、/portal/..;/manager/htmlに対してアクセスするとどうなるでしょうか？
Apacheは..;/をパスの遡上とは解釈せず、/portal/..;/manager/htmlへのアクセスとして処理するためアクセスが許可されTomcatにリクエストが転送されますが、一方でTomcatは；（セミコロン）以下を除いた/portal/../manager/htmlへのアクセスとして理解するため、パスを遡上し /manager/htmlへのアクセスとして処理されます。
これにより、本来は外部からアクセスできないTomcatの管理画面にアクセスすることができ、その結果、管理画面からアプリケーションの停止や、攻撃者が用意した悪意のあるアプリケーションへのすり替えができてしまいます。
この問題に対する最も良い対策は、外部からアクセスさせたくない管理機能を別サーバに分離することですが、どうしても分離できない場合は、；（セミコロン）が含まれているパスへのアクセス前に（上図の例であればApache側で）拒否する方法もリスク低減策として有効です。
クローズ
今回紹介した三つの脆弱性のように、大きな話題にはなっていなくても、万が一、刺さってしまうとインパクトが大きい脆弱性は日々発表されています。そのため、Vex等の脆弱性検査ツールや脆弱性診断サービスを活用し定期的にセキュリティ診断を行いながら、安全なWebアプリケーションを維持していきましょう。
ユービーセキュアではセキュリティコンサルタントによる無料相談会を定期的に実施しております。
少しでも気になることがございましたら、お気軽にご相談ください。
