同社は、問題となったVeloCloud Orchestratorの機能について「本来は社内利用のみを想定していた」と説明していますが、アナリストたちは、意図だけでは不十分だと指摘しています。
Aristaは、実際に悪用が確認されているVeloCloud Orchestrator（VCO）のセキュリティ上の欠陥を修正しました。同社によれば、この脆弱性は「リモートの攻撃者がVCOホストの内部特権機能にアクセスし、影響を及ぼす可能性がある」ものです。
Aristaのセキュリティアドバイザリでは、この欠陥が「オーケストレーターおよびオーケストレーターが管理するデータの機密性、完全性、可用性を損なう可能性がある」とも付け加えられています。
さらに、「この露出を防止できる設定は存在しない」とも述べています。
同社は、影響を受けるソフトウェアであるVeloCloud Orchestrator On-Prem（旧称Broadcom製VeloCloud Orchestrator）を利用している顧客に対し、できるだけ早く修正版へアップグレードするよう推奨しています。対象バージョンは、5.2系ではVCO 5.2.3.14以降、6.1系ではVCO 6.1.3.4以降、6.4系ではVCO 6.4.2.4以降です。
また、VCOプラットフォームが侵害されると攻撃者がVeloCloud Edgeデバイスにアクセスできるようになる可能性があるため、組織は認証情報のローテーション、管理者アクティビティの確認、管理対象デバイスの状態検証、そして信頼できるソースからの影響を受けたインスタンスの復元・置き換えといった、その他のインシデント対応活動も検討すべきだとしています。
これ以上ないほど深刻な事態
IDCでセキュリティ部門のグループ副社長を務めるFrank Dickson氏は、この脆弱性を「CISOの一日を台無しにするもの」と表現しています。
「これはまさに、誰も見たくない類の“パーフェクト10”です。すでに実際の攻撃で悪用されている、未認証のコマンドインジェクションの欠陥。これこそCISOが悪夢にうなされる原因です」とDickson氏は述べています。「さらに悪いことに、VCOのウェブインターフェースはデフォルトで外部に露出しているため、設定による回避策も存在しません」
コンサルタントでFormerGovのエグゼクティブディレクターを務めるBrian Levine氏も、この見解に同意しています。
「ネットワークオーケストレーターにおけるCVSS10、未認証のコマンドインジェクションの欠陥は、これ以上ないほど深刻な事態と言えます。攻撃者が管理プレーンを掌握すれば、事実上そこに接続されているすべてのエッジデバイスを掌握することになります」と同氏は述べています。「企業にとっての意味合いは明確です。SD-WANやオーケストレーションプラットフォームをTier-0（最重要）資産として扱い、外部への露出を制限し、アイデンティティ基盤に対するのと同じ緊急性でパッチを適用すべきです」
同氏はさらに、「これは、侵害されたネットワーク機器の上に築かれた『セグメンテーション』が幻想に過ぎないことを改めて示す事例です。制御プレーンがインターネットに露出している時点で、最初の戦いにはすでに敗れているのです」と指摘しています。
Digital 520のプリンシパルコンサルタントを務めるNoah Kenney氏は、「権限を持たない第三者がコマンドを実行できてしまう管理プレーンというのは、最悪に近いシナリオです」と付け加えています。
懸念すべき疑問
MalwarebytesのプリンシパルセキュリティリサーチャーであるGiuseppe Trotta氏も、公開された技術的詳細が懸念すべき疑問を投げかけていると指摘しています。
「Aristaは、オンプレミス展開よりも先にクラウドホスト型インフラのセキュリティ対策を講じていたと伝えられています。これは、コンプライアンスや主権、統制の観点からオンプレミスを選択する組織が、実際の悪用が進行している最中に重要なセキュリティ修正への対応が遅れがちになるという厳しい現実を浮き彫りにしています」と同氏は述べています。また、多くの企業がベンダーやインテグレーターの利用のためにVCOの管理インターフェースを意図せずインターネットからアクセス可能な状態にしていることから、この単一の脆弱性が企業全体を巻き込む侵害へと発展しかねないと指摘しています。
同氏はさらに、今回のケースではパッチ管理が厄介な問題になり得るとも付け加えています。「AnsibleやTerraformといったツールを通じてSD-WANの自動化に依存している成熟した組織にとって、このパッチの適用は運用上難しい課題となる可能性があります。バックエンドのコマンド実行に対するどんな変更も、既存のワークフローを妨げるおそれがあります」
お決まりの失敗パターン
コンサルタントやアナリストたちはまた、今回侵害された機能について「本来は社内利用のみを想定しており、リモートからアクセス可能であることは意図していなかった」というAristaの説明にも注目しています。
「『リモートからのアクセスを意図していない』ということと、『実際にリモートからアクセスできない』ということは、まったく別の話です」とIDCのDickson氏は述べています。「これは、内部向けとされていた機能が、外部に露出したインターフェースから実際には十分に隔離されていなかったという典型的なケースです。だからこそ、たった一つの未認証リクエストでその機能に到達できてしまったのです」
Kenney氏は、この「内部専用」という考え方は現時点でも危険であるだけでなく、攻撃者がこの弱点をすでに発見してしまった今、その危険性はますます増していくだろうと付け加えています。
「ここで起きたことは、よくある失敗のパターンです」と同氏は述べています。「誰かが内部向けの機能を書き、それを呼び出すのはシステム内の別の信頼された部分だけだろうと想定します。呼び出し元は自分自身のはずだと考えるため、公開エンドポイントに対してのように入力をサニタイズしません」。しかし、その後、どこかの時点での変更によってそのエンドポイントが外部から到達可能になり、呼び出し元を信頼する前提で書かれた関数に、見知らぬ第三者が入力を送り込めるようになってしまう、と同氏は説明しています。「コード自体は何も変わっていません。変わったのは、その露出範囲です」
今回の事態は、二つの判断が重なり合った結果だとKenney氏は述べています。「『これは内部向けだから、堅牢化は不要だ』という判断は、下された時点では妥当でした。そして『製品として機能させるには外部から到達可能である必要がある』という判断も、それ自体は妥当でした。しかし、後者の変更が行われた後に、前者の前提がまだ成り立っているかどうかを誰も確認しなかったのです」
Aristaはさらなる情報提供の依頼に対し、「公開済みのCVEに記載されている以上のコメントはありません」とメールで回答し、コメントを控えました。
M&Aがもたらした憂鬱
この状況に影響を与えた可能性のあるもう一つの要因は、VeloCloudがAristaのポートフォリオに比較的最近加わった事業であり、同社の傘下に入ってからまだ1年余りしか経っていないという点です。M&Aのデューデリジェンスでは、新たに生じ得るセキュリティリスクが十分な深さまで検討されないことがよくあります。
「多くの場合、買収によって受け継がれるオーケストレーション層は、比較的新しく、その下流にあるすべてに対して最大の特権を持っています」とKenney氏は指摘しています。「攻撃者は、堅牢化されたデータプレーンに正面から挑むのをやめ、それを制御するコンソールを狙うようになったのです」
さらに厄介なことに、VeloCloudはAristaに移る前にVMwareとBroadcomを経由しています。コードがこれだけ何度も持ち主を変えると、どの機能が暗黙のうちに信頼された呼び出し元を前提としていたかを知る人物は、おそらくもう残っていません。
「テストでは機能が引き続き動作することは確認できますが、古い『内部専用』という前提が移行後も生き残っているかどうかまでは、めったに再検証されません」と同氏は述べています。
