Akamai EAA におけるなりすましの脆弱性 - 詳細

この記事では、Akamai の Enterprise Application Access（EAA）プラットフォームに影響を与える脆弱性 CVE-2021-28091の技術的な詳細について説明します。Akamai で実施したこの脆弱性の調査、修正、開示のプロセスについて説明します。脆弱性の概要、Akamai への影響、EAA をご利用のお客様への影響、必要な対策については、付属レポートをご覧ください。

概要

このセクションでは、この脆弱性の歴史と仕組みについて説明します。お急ぎの場合は、このセクションをスキップし、「必要な対策」のセクションまで直接進んでもかまいません。この「概要」のセクションは、評価を実施する必要がある場合、または今後レビューを実施する場合のリファレンスとしてお使いください。

Akamai は 2016 年に Soha Systems を買収し、EAA テクノロジーを手に入れましたが、このプラットフォームにはそれ以前にプラットフォームのユーザーがサードパーティーのアイデンティティプロバイダーから提供されたアイデンティティ情報に基づきアクセス制御および認証の判断を行えるという重要な機能が導入されていました。この EAA プラットフォームには、サードパーティーのアイデンティティ統合のための複数の手段が用意されています。そのうちこのレポートで注目するのは、Security Assertion Markup Language（SAML）v2.0 認証プロトコルのサポートです。

SAML は、広く利用されているオープンな標準規格です。SAML は、暗号化された署名と情報のやり取りを通して、クライアントが一定時間内にアイデンティティプロバイダー（IdP）から取得したアサーションオブジェクトをサービスプロバイダー（SP）に提示することで、IdP から SP への認証を可能とする仕組みです（詳細については、下記「背景」のセクションをご覧ください）。

EAA にサードパーティー IdP のサポートが追加されたとき、開発者はプラットフォーム内で SAML のサポートを実装するためのライブラリとして、オープンソースの Lasso を選びました。提供された SAML レスポンスを Lasso が SP として検証するコードを Akamai で評価したところ、最初の統合時に開発者がサードパーティー IdP 機能を実装した際は、ライブラリが提供するテストケースに基づき適切に作業が行われたと考えています。しかしさらに詳しく調査を行ったところ、Akamai での実装を行う際に使用されたテストスイートが十分厳格なものではなかったため、認証プロセスにおけるなりすましの脆弱性または類似の弱点を見極めることができなかったことが明らかとなりました。Akamai ではこの問題への対策として、有効および無効な署名済みレスポンスおよび／またはアサーション、ならびに無署名のレスポンスとアサーションのあらゆる組み合わせが含まれるように、本製品の新規リリースに適用されるテストスイートを拡充しました。これらの新しいテストは、今後の標準的な QA プロセスの一部として組み込まれます。

本レポートの以降のセクションでは、さまざまな弱点について詳細に検討するとともに、全体的な視点から脆弱性をもたらしている要因について解説します。Akamai では、当社がどのような手順で対策を行っているかをお知らせし、皆様自身の環境で似たような状況を引き起こさないためのお手伝いをしたいと考えています。そのため、このように詳細に踏み込んで内情を公開することにしました。

システムのテストと評価

ソフトウェア開発ライフサイクル（SDLC）において、ユニットテスト、統合テスト、回帰テストは非常に重要な要素です。今回脆弱性が見つかったサブコンポーネントには、これに関連するあらゆるテスト用のメソッドが実装されてはいましたが、テスト自体が十分厳格なものではなかったことが判明しました。また、依存関係のあるライブラリ自体の SDLC が厳格で、類似のライブラリの脆弱性など、それぞれのドメイン固有の知見が確実に反映されているという誤った思い込みに基づき、一部のサードパーティーライブラリがプロジェクトに統合されていました。このインシデントにより、このような見落としが明らかとなったのです。

各コンポーネント、および依存関係のある各ライブラリに対して厳格な SDLC が必要になりますが、コンポーネント開発や品質保証（QA）に組み込まれたテストが十分ではないこともしばしばあります。このようにテストで不足している部分を補うため、侵入テストや第三者によるコードレビューなどの敵対的評価を行うことができます。EAA の場合は、製品のリリース以来、一貫して EAA プラットフォームに対する複数の外部セキュリティおよび脆弱性評価が（多くの場合お客様によって）実施されてきました。それにもかかわらず、この対応を開始するきっかけとなったレポートが公表されるまで、この脆弱性は Akamai に報告されませんでした。Akamai では、EAA プラットフォームのこのコンポーネント以外の部分、およびクライアントアプリケーションに対しては、厳格な評価を行っていましたが、この特定のコンポーネントについてはそれらと同等の厳格な評価／調査が行われていませんでした。

拙速な開示の回避

Akamai では、本インシデントへの対応プロセスの初期段階において、お客様に対して付属レポートの「必要な対策」のセクションに提案されているとおりに調査を開始するよう促すため、概要について記述したお知らせをお客様向けに作成することにしました。このドキュメントの公開前に、この脆弱性について知らされていない Akamai スタッフに、お客様向けお知らせメッセージのコピーを提供し、レビューしてもらいました。レビューを依頼されたスタッフは、メッセージ提供後 1 時間も経たないうちに、影響のあるプロトコル（SAML）とパッケージ（Lasso）を特定し、Lasso プロジェクトのメンテナンス担当者が最近行った活動をもとに、どのような脆弱性かを推測するに至りました。このような思いがけない情報が得られたことから、対策が不十分な状態でお客様にお知らせすることはただちに中止し、責任ある開示の原則に従ってまずは十分な対策をとることにしました。

インシデントチームは、レビュー担当スタッフに詳しく話を聞き、どのようにしてそれらの情報を得るに至ったか、そのプロセスを知ることができました。レビュー担当スタッフの話によると、エラー状態が発生したときに IdP が返すエラーメッセージが重要な鍵を握っていたことがわかりました。脆弱性の修正がリリースされるまで、SAML でエラー状態が発生した場合に表示されるエラーページに以下の画像のような Lasso エラーが表示されており、エンドユーザーに筒抜けになっていました。特に認証などの重要なセキュリティプロセスにおいてエラーをそのまま表示する行為はベストプラクティスに反しています。そのため、このリリースからは、エンドユーザーにエラーを表示しないよう対策を行いました。

上記の XML ドキュメントはこのレポートの読者にわかりやすいようにシンプル化されていますが、構造は保たれています。外側に位置する「親」ドキュメントは、リクエストおよびアサーションドキュメントについてのメタデータを含む SAML レスポンスです。アサーション（SAML アサーションとも呼ばれます）は、IdP から SP に提示されるデータで、認証プロセスで使用されます。単一の SAML レスポンスに複数のアサーションが存在していることもあります。上記の例では、ds:Signature のくくりの中に、親オブジェクトのコンテンツ（この場合はアサーション）に対する暗号化署名が含まれています。同じ署名オブジェクトを、レスポンスオブジェクト全体に適用することもできます。SP は、署名により、アサーションまたはレスポンスに含まれているデータが IdP から提供された正規のデータであることを確認することができます。アサーションの場合、署名はユーザー名、メールアドレス、所属グループを示す情報など、アサーションに含まれるあらゆるデータにのみ適用されます。レスポンスレベルで適用される署名は、レスポンスのコンテンツ全体、およびレスポンス内のすべてのアサーションに適用されます。

SAML レスポンス内のさまざまな署名の検証は SP に委ねられており、多くの場合 IdP とアプリケーション間での通信を設定するときに検証の方法が設定されます。この問題への対応を行うにあたり、SAML レスポンスはデフォルトで以下の条件に基づき検証される必要があります。

• SAML レスポンス全体が有効に署名されている場合、レスポンス内のすべてのアサーションには正しく署名が行われているか、または無署名であることが必要です。無効な署名が見つかった場合、検証に失敗します。この場合、IdP がメッセージ本文全体に署名することにより、レスポンスが信頼できるものであることが保証されます。
• SAML レスポンスが無署名の場合、レスポンス内のすべてのアサーションが正しく署名されている必要があります。それ以外の場合、検証に失敗します。
• SAML レスポンスの署名が無効な場合、検証に失敗します。

Akamai は、上記の条件に基づく処理をパッチとして実装するよう Lasso に提案しました。

この問題について当初 Akamai に提供されたレポートによると、調査担当者は単一の SAML レスポンスに 2 つの SAML アサーションを含めて送信しました。それらのアサーションのうち、1 つ目は有効に署名されていましたが、2 つ目は無署名でした。Lasso は、デフォルトで以下の条件に基づき検証されるように設定されていました。

• レスポンス内の 1 つ目の SAML アサーションが有効に署名されている場合、SAML レスポンス全体の署名が有効かどうかにかかわらず検証に成功します。
• 1 つ目の SAML アサーションの署名が無効な場合、検証に失敗します。
• SAML レスポンスが有効に署名されており、アサーションがいずれも署名されていない場合、検証に成功します。
• それ以外の場合は、検証に失敗します。

さらに複雑なことに、ライブラリでレスポンスが有効であるとみなされると、SAML レスポンスからアサーションを取得する関数は、有効な署名があるかどうかにかかわらずレスポンスオブジェクト内の最後のアサーションを返していました。たとえば攻撃者が、上記のような、IdP からの単一のアサーションを含む有効な SAML レスポンスを窃取し、2 つ目のアサーションとして以下を追加する場合を考えます。

提示されたユーザーが組織の有効なユーザーであるが、より多くの権限が含まれる場合、それらの権限に対応する複数のアサーションを組み合わせた SAML レスポンスが SP に提出されます。

Lasso がこの SAML レスポンスの検証を試みると、レスポンスが有効であるという結果となっていました。呼び出し元のアプリケーションが上記のレスポンスからアサーションを取得すると、ユーザー ID（uid）が superuser のアサーションが返され、有効なアサーションとみなされていました。上記の例以外にも、SAML レスポンス自体に有効な署名があれば、これと同じなりすましを行うことができました。EAA の SAML レスポンス処理ではこの方法が悪用されていました。

脆弱性悪用の条件

SAML レスポンスが SP への提出前に改変されるためには、以下のいずれかの状態が発生する必要があります。

• 正当な権限を持つユーザーにより管理され、SAML レスポンスのリダイレクトを仲介する正規のクライアントが、SAML レスポンスの一部として追加のアサーションドキュメントを挿入することにより、SAML レスポンスを改変する必要があります。たとえば、クライアントシステム上の悪性のブラウザー拡張機能やその他のマルウェアによりこのような改変が実行されます。この攻撃は「マン・イン・ザ・ブラウザー攻撃」と呼ばれることがあります。
• 攻撃者が、有効な SAML レスポンスのコピーを窃取する必要があります。ただしこのレスポンスは、アサーションの有効期限が切れる前であるか、またはアプリケーションによってはアサーションがまだ SP に提出される前であり、有効性を維持していることが必要です。たとえば、中間にいる第三者により、プロキシを通して SAML レスポンスが傍受され、改変されます。この攻撃はしばしば「中間者攻撃」と呼ばれます。
• 正当な権限を持たないクライアントが、権限を持つユーザーのログイン情報を把握しているか、または推測できる必要があります。ログイン情報は、フィッシング攻撃、パスワード漏えい、推測、総当たり攻撃などを通して収集されます。

上記のいずれかの状態が発生すると、ユーザーのセッションが侵害され、SAML の実装にすでに説明したような脆弱性が存在すると、SP がなりすまし攻撃を受ける危険性があります。

この脆弱性の歴史

この脆弱性は XML 署名ラッピングと呼ばれ、CVE 脆弱性として登録されているほか、レポートを通して、または問題としてたびたび報告されています。

Lasso ライブラリのリポジトリを確認すると、この弱点は早ければ 2005 年 11 月からコードベースに組み込まれていたことがわかります。つまり、Akamai がライブラリを統合するはるか以前から、そして他のプラットフォームについて先行して発表された脆弱性がリリースされたときよりも前から存在していた弱点であるということです。

また、調査を行ったところ、この問題が Akamai に通知された直後に、Lasso ライブラリのメンテナンス担当者がプロジェクトにコミットを行っていることも判明しました。レポート発行者との話では、このコミットは単なる偶然で、レポートとは無関係とのことでした。

修正は 2021 年 2 月 24 日に提案され、この脆弱性を悪用した攻撃の影響を部分的に解決するものでしたが、さらにレビューを行ったところ完全な修正とはなっていないことがわかりました。そのため、最終的には Akamai からメンテナンス担当者にパッチが提案されることになりました。

Akamai のインシデント対応の概要

Akamai は、正式なインシデント対応プロセスに従い対応を行っています。エンジニアリング／システム開発、ネットワーク運用、カスタマーサポートの各担当者が協力して、規則どおりにインシデントへの対応が行われます。通常は、インシデントの重大性が高いほど、対応に携わる担当者の数が多くなり、計画されている運用や作業よりも優先度が高くなります。Akamai では、以下を目標としてあらゆるインシデント対応を行っています。

• 問題の影響範囲を限定すること
• システムの継続的かつ安全な運用を確保すること
• インシデント対応者の継続的な安全確保とケアを実施すること
• お客様の満足度を維持し、お客様のデータを保護すること
• さまざまな法律や規則に準拠すること
• インシデントを発生させた危険性から学び、学んだ内容をもとに改善を実施すること

すでに説明したように、Akamai では、この脆弱性の通知を受けて、インシデント対応プロセスに基づく対応を開始しました。このプロセスを通して、Akamai は技術的なリソースの調整、社内および社外の利害関係者や経営陣とのコミュニケーション、インシデントに関連するあらゆる活動の調整を、タイムリーかつ効果的に実施することができました。

パッチの適用と展開のプロセス

この脆弱性に対する修正の開発および EAA ネットワークに対するパッチの展開は、計画的なアップグレードで使用される通常のプロセスと非常に似たプロセスを通して実施されました。ただし、はるかに小規模な変更内容かつ短期間で実施されました。

インシデント対応の最初の数時間で、いくつかの重要な決定事項を考慮しつつ、修正のためのドラフトスケジュールを作成しました。そのスケジュールとは、修正を準備した後、標準的な QA プロセスに従った QA のプロセスを 3 日間にわたり実施し、展開のフェーズでは 48 時間かけるというものでした。展開のフェーズに続き、問題をブログ記事およびお客様へのお知らせという形で公表する計画を策定しました。このスケジュールは、さらに期間を短縮することもできましたが、この脆弱性を狙った攻撃が現在進行形で行われている証拠はなかったため、対応プロセス全体を通してお客様に安定したネットワークを提供することを最優先としました。

最初に問題のトリアージを行った後、エンジニアリングチームでは、異なるエンジニアリングおよび QA リソースを用いて 2 つの道筋から問題の修正にアプローチしました。

一方のチームは問題に対する部分的な修正について調査と開発を行いました。これにより、報告された問題をクローズし、SAML レスポンスの処理要件に制約を課して、1 件のアサーションを含む正常な SAML レスポンスと考えられるもののみを受け付けるようにしました。この方法により、一部の IdP から送られるレスポンスは、有効かつ安全なものであっても拒否されることが考えられました。このアプローチでは、少数の IdP との間で予期しないやり取りが発生した場合に備え、お客様ごとに厳格なチェックを無効にできるオプションも用意しました。無効にしていないお客様には厳格なチェックが適用されたままとなります。

他方のチームのアプローチも 1 つ目のチームと似ていますが、お客様ごとの設定を許す部分的な修正ではなく、完全な修正に向けて作業を行いました。このアプローチでは、適切な形式で正しく署名されたあらゆる SAML レスポンスが受け付けられるように厳密な調査が実施されました。これにより、複雑性が低減し、お客様がダウングレードしても問題が生じなくなります。

このような同時並行型のアプローチを採用したのは、一方のアプローチで作業が阻まれたり、QA で課題が発生したりしても、修正を展開することが可能なためです。米国東部標準時の 2 月 24 日遅くの段階で、部分的な修正はインシデント発生後 3 日で QA に進めると予想されていました。一方、完全な修正は、開発にさらに 1 週間長くかかると予想されていました。25 日にかけて夜を徹して作業が行われ、その時点でエンジニアリングチームから報告された進捗では、完全な修正は順調に作業が進んでおり、最終的には予想よりも短い時間で開発が終わり、テストも想定よりも複雑にはならないことがわかりました。

最終的に、完全な修正は、部分的な修正よりも約 1 日早く QA チームに引き渡されることになりました。部分的な修正が QA チームに引き渡された後、EAA をご利用のすべてのお客様にパッチのお知らせを通して予想展開スケジュールが通知されました。

QA プロセスを通してこのステータスが維持されました。メンテナンス期間を若干前倒しして、完全な修正が QA チームの承認を受け、展開可能な状態になりました。

展開プロセスは、まず非常に負荷の低い Point of Presence（POP）から開始されました。その POP で一連の回帰テストを徹底的に実施し、お客様の体験を損なうふるまいが生じないかトラフィックを慎重に監視しました。その後同様に負荷の低い別の POP をアップグレードし、簡略化したテストを実施して、一定時間監視しました。3 月 2 日の早い時間に、Akamai の社内向け EAA を提供する POP がアップグレードされ、8,000 人近くのエンドユーザーを通してさらなる負荷テストが実施されました。その時点までの展開で問題が発生しなかったため、メンテナンス期間の残りの 36 時間を使ってそれ以外のすべての POP がアップグレードされました。最終的に、展開プロセスはメンテナンス期間中に完了しました。

アップグレードプロセス中、EAA アプリケーションを使っていたほとんどのユーザーが 1 回以上の再認証操作を求められたと考えられます。通常は、一時的にセッションが中断され、IdP へとリダイレクトされて、そこで認証情報を入力すると、引き続き通常の業務に戻ることができます。EAA クライアントのユーザーは、次のようなふるまいも目にしていると考えられます。展開中には、EAA をご利用のお客様による再認証試行が殺到しました。各 POP のコードのアップグレード後、EAA が保持しているセッションキャッシュがクリアされたため、5 分間にわたってすべてのリクエストの再認証がトリガーされました。再認証が終わった後は、エンドユーザーに対する影響は見られていません。

インシデントチームの管理

この脆弱性のような重大な問題について修正を開発し、検証して、安全にネットワークに展開する際には、問題解決に取り組むチームを慎重にケアすることが重要となります。Akamai のインシデント管理プロセスおよび付属のトレーニングには、インシデントに対応する技術チームおよび管理チームの燃え尽きを防ぐ方法についてのガイダンスが含まれています。このガイダンスでは、インシデントチームについて以下を確認するよう求められています。

• 決められた時間に食事をとっていること
• 1 日に必要な睡眠時間が確保されていること（理想的には夜間）
• 業務以外でするべきことがあればできること
• 健康を維持すること（新型コロナウイルスのワクチン接種、運動）

目先のインシデントの修正ももちろん重要ですが、インシデント対応プロセス全体を通してチームのケアを怠らないことで、インシデントの影響を受ける製品やシステムをより安全な方向へと導くことができるほか、避けられるはずのエラーを減らし、インシデント対応で抱える多くのストレスによってお客様に何らかの影響を与えてしまうことがなくなります。

Akamai のインシデント管理プロセスでもう 1 つ重要なのは、インシデントには全員が一丸となって対応し、現在または将来において誰一人個人的に責任を負わされることがないという原則です。インシデント対応チームは、まずはインシデントの影響を軽減し、その後、再発を防止する方法を見つけようと、最善を尽くし、一丸となって問題の解決にあたります。Akamai は、インシデントの原因について仮説を導き出し、不完全な部分の存在するこれらの仮説をもとに事態の把握を試み、同じイベントまたは類似のイベントが再発する可能性を低減するための適切な変更を行う作業に集中して取り組みます。

必要な対策

SAML 認証に Lasso を利用しているシステムオーナーは、可能な限り早期にパッチを適用する必要があります。認証されるシステムへの影響を調査するため、追加の対策が必要となる場合があります。必要な対策の詳細については、この記事の付属レポートの「必要な対策」のセクションをご覧ください。

タイムライン