最近のApacheの問題の原因となったPath Traversal脆弱性の影響を体験する
10月初旬、ApacheはPath Traversal and Remote Code Executionの脆弱性を修正したバージョン2.4.49と、2.4.49での修正が不完全だったことに対応した2.4.50をリリースしました。Apacheはインターネットの25％を占めていると言われていることから、これらのリスクを回避するために最新バージョンにアップデートすることの重要性について、ソーシャルメディアで話題になっているのを見たことがあるかもしれません。しかし、実際のところはどうなのでしょうか？どの程度のリスクがあるのでしょうか？
自分で試してみませんか？
私たちは、実際の環境でリスクを実証するためのミッションを構築し、誰でも試すことができるように公開しました。このミッションでは、Path Traversal脆弱性がインフラやアプリケーションにどのような影響を与えるかを説明します。このミッションに参加するには、以下をクリックしてください。
パス・トラバーサルの脆弱性について
この脆弱性は、2.4.49 リリースで導入された（URL 正規化関数の変更による）新しいパス正規化関数にあります。残念ながら、URL エンコードされたパスを正しく正規化することができませんでした。このため、以下の設定がない場合、パストラバーサル攻撃が可能となります。
.avif)
また、mod_cgi が有効になっている場合、これを利用してリモートコード実行の脆弱性が発生する可能性があります。しかし、何が問題だったのかを理解するために、まずURLエンコーディングについて掘り下げてみましょう。
URLエンコーディング
最も基本的なことですが、この脆弱性は、URLエンコードされたURLに対する配慮が欠けているために発生します。新たに導入したパスの正規化機能では、ドットがURLエンコードされている場合に完全に対応できていませんでした。
パストラバーサル攻撃を行うためには、../ というシーケンスでトラバースする必要があることを覚えておいてください。しかし、正規化関数は賢いので、それを取り除くことができます。では、どうすればいいのでしょうか？.（ドット）を%2eまでURLエンコードして、.%2e/のようなシーケンスを使うことができます。これは多くの場合、Apache 2.4.40に対して機能します。しかし、もう一歩進んで、二重にエンコードすることもできます。.%2e/ のURLエンコードバージョンは、.%252e/です。これはさらに、Apacheによる正規化の試みを回避することができました。
しかし、それには問題があります。
もし誰かがブラウザで直接この脆弱性を利用しようと思っても、成功しないでしょう。これは、ブラウザがサーバーに送信されるURLを正規化しようとすることが原因です。つまり、二重にエンコードされた配列であっても削除されてしまうのです。また、単純にブラウザを使って実証することはできないということです。
cURLでは、--path-as-is フラグを使用することで、送信前にURLを正規化することを防ぐことができ、これを実証することができます。
.avif)
予防と緩和
この問題を完全に防ぐためには、Apacheの最新のパッチを入手することが重要です。具体的には、最低でも 2.4.51 にアップグレードすることをお勧めします。しかし、最新の状態を保つためには、定期的にアップグレードするのがよいでしょう。
2.4.49を使用している場合、この問題を回避するには、Apacheの設定に以下の項目が含まれていることを確認してください。
.avif)
また、リモートコード実行を防ぐために、mod_cgi を利用していない場合は無効にしてください。
そのインパクトを体感してください。
何が起こったのか、自分で試してみたいと思いませんか？
10月初旬、ApacheはPath Traversal and Remote Code Executionの脆弱性を修正したバージョン2.4.49をリリースし、その後、修正が不完全であったことに対応した2.4.50をリリースしました。私たちは、実際の環境でリスクを実証するために、ミッションを構築しました。今すぐお試しください。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
デモを予約する
10月初旬、ApacheはPath Traversal and Remote Code Executionの脆弱性を修正したバージョン2.4.49と、2.4.49での修正が不完全だったことに対応した2.4.50をリリースしました。Apacheはインターネットの25％を占めていると言われていることから、これらのリスクを回避するために最新バージョンにアップデートすることの重要性について、ソーシャルメディアで話題になっているのを見たことがあるかもしれません。しかし、実際のところはどうなのでしょうか？どの程度のリスクがあるのでしょうか？
自分で試してみませんか？
私たちは、実際の環境でリスクを実証するためのミッションを構築し、誰でも試すことができるように公開しました。このミッションでは、Path Traversal脆弱性がインフラやアプリケーションにどのような影響を与えるかを説明します。このミッションに参加するには、以下をクリックしてください。
パス・トラバーサルの脆弱性について
この脆弱性は、2.4.49 リリースで導入された（URL 正規化関数の変更による）新しいパス正規化関数にあります。残念ながら、URL エンコードされたパスを正しく正規化することができませんでした。このため、以下の設定がない場合、パストラバーサル攻撃が可能となります。
また、mod_cgi が有効になっている場合、これを利用してリモートコード実行の脆弱性が発生する可能性があります。しかし、何が問題だったのかを理解するために、まずURLエンコーディングについて掘り下げてみましょう。
URLエンコーディング
最も基本的なことですが、この脆弱性は、URLエンコードされたURLに対する配慮が欠けているために発生します。新たに導入したパスの正規化機能では、ドットがURLエンコードされている場合に完全に対応できていませんでした。
パストラバーサル攻撃を行うためには、../ というシーケンスでトラバースする必要があることを覚えておいてください。しかし、正規化関数は賢いので、それを取り除くことができます。では、どうすればいいのでしょうか？.（ドット）を%2eまでURLエンコードして、.%2e/のようなシーケンスを使うことができます。これは多くの場合、Apache 2.4.40に対して機能します。しかし、もう一歩進んで、二重にエンコードすることもできます。.%2e/ のURLエンコードバージョンは、.%252e/です。これはさらに、Apacheによる正規化の試みを回避することができました。
しかし、それには問題があります。
もし誰かがブラウザで直接この脆弱性を利用しようと思っても、成功しないでしょう。これは、ブラウザがサーバーに送信されるURLを正規化しようとすることが原因です。つまり、二重にエンコードされた配列であっても削除されてしまうのです。また、単純にブラウザを使って実証することはできないということです。
cURLでは、--path-as-is フラグを使用することで、送信前にURLを正規化することを防ぐことができ、これを実証することができます。
予防と緩和
この問題を完全に防ぐためには、Apacheの最新のパッチを入手することが重要です。具体的には、最低でも 2.4.51 にアップグレードすることをお勧めします。しかし、最新の状態を保つためには、定期的にアップグレードするのがよいでしょう。
2.4.49を使用している場合、この問題を回避するには、Apacheの設定に以下の項目が含まれていることを確認してください。
また、リモートコード実行を防ぐために、mod_cgi を利用していない場合は無効にしてください。
そのインパクトを体感してください。
何が起こったのか、自分で試してみたいと思いませんか？
10月初旬、ApacheはPath Traversal and Remote Code Executionの脆弱性を修正したバージョン2.4.49と、2.4.49での修正が不完全だったことに対応した2.4.50をリリースしました。Apacheはインターネットの25％を占めていると言われていることから、これらのリスクを回避するために最新バージョンにアップデートすることの重要性について、ソーシャルメディアで話題になっているのを見たことがあるかもしれません。しかし、実際のところはどうなのでしょうか？どの程度のリスクがあるのでしょうか？
自分で試してみませんか？
私たちは、実際の環境でリスクを実証するためのミッションを構築し、誰でも試すことができるように公開しました。このミッションでは、Path Traversal脆弱性がインフラやアプリケーションにどのような影響を与えるかを説明します。このミッションに参加するには、以下をクリックしてください。
パス・トラバーサルの脆弱性について
この脆弱性は、2.4.49 リリースで導入された（URL 正規化関数の変更による）新しいパス正規化関数にあります。残念ながら、URL エンコードされたパスを正しく正規化することができませんでした。このため、以下の設定がない場合、パストラバーサル攻撃が可能となります。
また、mod_cgi が有効になっている場合、これを利用してリモートコード実行の脆弱性が発生する可能性があります。しかし、何が問題だったのかを理解するために、まずURLエンコーディングについて掘り下げてみましょう。
URLエンコーディング
最も基本的なことですが、この脆弱性は、URLエンコードされたURLに対する配慮が欠けているために発生します。新たに導入したパスの正規化機能では、ドットがURLエンコードされている場合に完全に対応できていませんでした。
パストラバーサル攻撃を行うためには、../ というシーケンスでトラバースする必要があることを覚えておいてください。しかし、正規化関数は賢いので、それを取り除くことができます。では、どうすればいいのでしょうか？.（ドット）を%2eまでURLエンコードして、.%2e/のようなシーケンスを使うことができます。これは多くの場合、Apache 2.4.40に対して機能します。しかし、もう一歩進んで、二重にエンコードすることもできます。.%2e/ のURLエンコードバージョンは、.%252e/です。これはさらに、Apacheによる正規化の試みを回避することができました。
しかし、それには問題があります。
もし誰かがブラウザで直接この脆弱性を利用しようと思っても、成功しないでしょう。これは、ブラウザがサーバーに送信されるURLを正規化しようとすることが原因です。つまり、二重にエンコードされた配列であっても削除されてしまうのです。また、単純にブラウザを使って実証することはできないということです。
cURLでは、--path-as-is フラグを使用することで、送信前にURLを正規化することを防ぐことができ、これを実証することができます。
予防と緩和
この問題を完全に防ぐためには、Apacheの最新のパッチを入手することが重要です。具体的には、最低でも 2.4.51 にアップグレードすることをお勧めします。しかし、最新の状態を保つためには、定期的にアップグレードするのがよいでしょう。
2.4.49を使用している場合、この問題を回避するには、Apacheの設定に以下の項目が含まれていることを確認してください。
また、リモートコード実行を防ぐために、mod_cgi を利用していない場合は無効にしてください。
そのインパクトを体感してください。
何が起こったのか、自分で試してみたいと思いませんか？
10月初旬、ApacheはPath Traversal and Remote Code Executionの脆弱性を修正したバージョン2.4.49と、2.4.49での修正が不完全だったことに対応した2.4.50をリリースしました。Apacheはインターネットの25％を占めていると言われていることから、これらのリスクを回避するために最新バージョンにアップデートすることの重要性について、ソーシャルメディアで話題になっているのを見たことがあるかもしれません。しかし、実際のところはどうなのでしょうか？どの程度のリスクがあるのでしょうか？
自分で試してみませんか？
私たちは、実際の環境でリスクを実証するためのミッションを構築し、誰でも試すことができるように公開しました。このミッションでは、Path Traversal脆弱性がインフラやアプリケーションにどのような影響を与えるかを説明します。このミッションに参加するには、以下をクリックしてください。
パス・トラバーサルの脆弱性について
この脆弱性は、2.4.49 リリースで導入された（URL 正規化関数の変更による）新しいパス正規化関数にあります。残念ながら、URL エンコードされたパスを正しく正規化することができませんでした。このため、以下の設定がない場合、パストラバーサル攻撃が可能となります。
また、mod_cgi が有効になっている場合、これを利用してリモートコード実行の脆弱性が発生する可能性があります。しかし、何が問題だったのかを理解するために、まずURLエンコーディングについて掘り下げてみましょう。
URLエンコーディング
最も基本的なことですが、この脆弱性は、URLエンコードされたURLに対する配慮が欠けているために発生します。新たに導入したパスの正規化機能では、ドットがURLエンコードされている場合に完全に対応できていませんでした。
パストラバーサル攻撃を行うためには、../ というシーケンスでトラバースする必要があることを覚えておいてください。しかし、正規化関数は賢いので、それを取り除くことができます。では、どうすればいいのでしょうか？.（ドット）を%2eまでURLエンコードして、.%2e/のようなシーケンスを使うことができます。これは多くの場合、Apache 2.4.40に対して機能します。しかし、もう一歩進んで、二重にエンコードすることもできます。.%2e/ のURLエンコードバージョンは、.%252e/です。これはさらに、Apacheによる正規化の試みを回避することができました。
しかし、それには問題があります。
もし誰かがブラウザで直接この脆弱性を利用しようと思っても、成功しないでしょう。これは、ブラウザがサーバーに送信されるURLを正規化しようとすることが原因です。つまり、二重にエンコードされた配列であっても削除されてしまうのです。また、単純にブラウザを使って実証することはできないということです。
cURLでは、--path-as-is フラグを使用することで、送信前にURLを正規化することを防ぐことができ、これを実証することができます。
予防と緩和
この問題を完全に防ぐためには、Apacheの最新のパッチを入手することが重要です。具体的には、最低でも 2.4.51 にアップグレードすることをお勧めします。しかし、最新の状態を保つためには、定期的にアップグレードするのがよいでしょう。
2.4.49を使用している場合、この問題を回避するには、Apacheの設定に以下の項目が含まれていることを確認してください。
また、リモートコード実行を防ぐために、mod_cgi を利用していない場合は無効にしてください。
そのインパクトを体感してください。
何が起こったのか、自分で試してみたいと思いませんか？
始めるためのリソース
セキュア・バイ・デザインベストプラクティスの定義、開発者の能力向上、予防的セキュリティ成果のベンチマーク
このリサーチペーパーでは、Secure Code Warrior 共同設立者であるピーテル・ダニュー（Pieter Danhieux）氏とマティアス・マドゥ（Matias Madou）博士、そして専門家であるクリス・イングリス（Chris Inglis）氏（元米国サイバーディレクター、現パラディン・キャピタル・グループ戦略顧問）、デヴィン・リンチ（Devin Lynch）氏（パラディン・グローバル・インスティテュート・シニアディレクター）が、CISO、アプリケーション・セキュリティ担当副社長、ソフトウェア・セキュリティの専門家など、企業のセキュリティ・リーダー20人以上への詳細なインタビューから得られた主な知見を明らかにします。
セキュリティ スキルのベンチマーク: 企業におけるセキュアな設計の合理化
セキュアバイデザイン（SBD）構想の成功に関する有意義なデータを見つけることは、非常に困難である。CISO は、セキュリティプログラム活動の投資収益率（ROI）とビジネス価値を、従業員レベルと企業レベルの両方で証明しようとすると、しばしば困難に直面します。言うまでもなく、企業にとって、現在の業界標準に対して自社の組織がどのようにベンチマークされているかを把握することは特に困難です。大統領の国家サイバーセキュリティ戦略は、関係者に「デザインによるセキュリティとレジリエンスを受け入れる」ことを求めている。セキュアバイデザインの取り組みを成功させる鍵は、開発者にセキュアなコードを保証するスキルを与えるだけでなく、規制当局にそれらのスキルが整っていることを保証することである。本プレゼンテーションでは、25万人以上の開発者から収集した社内データ、データに基づく顧客の洞察、公的研究など、複数の一次ソースから得られた無数の定性的・定量的データを紹介します。こうしたデータ・ポイントの集積を活用することで、複数の業種におけるセキュア・バイ・デザイン・イニシアチブの現状をお伝えすることを目的としています。本レポートでは、この領域が現在十分に活用されていない理由、スキルアッププログラムの成功がサイバーセキュリティのリスク軽減に与える大きな影響、コードベースから脆弱性のカテゴリーを排除できる可能性について詳述しています。
始めるためのリソース
明らかになった：サイバー業界はセキュア・バイ・デザインをどのように定義しているか
最新のホワイトペーパーでは、当社の共同設立者であるピーテル・ダニュー（Pieter Danhieux）氏とマティアス・マドゥ（Matias Madou）博士が、CISO、AppSecリーダー、セキュリティ専門家を含む20人以上の企業セキュリティリーダーと対談し、このパズルの重要なピースを見つけ出し、Secure by Design運動の背後にある現実を明らかにしました。セキュア・バイ・デザインは、セキュリティ・チーム全体で共有された野心ですが、共有されたプレイブックはありません。
