研究者たちの助言:Google API Tool の脆弱性から見えてくる可視化の重要性とは?

Researchers Debut Fresh RCE Vector for Common Google API Tool

2022/08/10 DarkReading — Google SLO Generator の脆弱なバージョンを悪用し、リモートコードの実行 (RCE) を容易にするという、新たな攻撃ベクターが発見された。この脆弱性の悪用に成功した攻撃者は、システムにアクセスし、あたかもネットワーク内の信頼できるソースから来たかのように、悪意のコードを展開できるという。

Google SLO Generator は、Web API のパフォーマンスを追跡したいエンジニアに、広く利用されている Python ライブラリである。このツールは数千の Google サービスで使用されているが、2021年9月のパッチ適用以前は、安全ではなく悪用が可能な関数が格納されており、ユーザーの入力データが暴露される可能性があった。


Vicarius の CEO である Michael Assraf は、この悪用の方法は未知のものであったが、単純な情報公開よりも悪い結果をもたらす、古いバージョンを悪用する方法を生み出すことになったと説明している。

攻撃経路の詳細を記したレポートを発表した Vicarius によると、このライブラリを使用している 167,000以上のアプリケーションのうち、どれだけが脆弱なバージョンを実行しているかは不明だという。コードをアップデートしたユーザーが、この攻撃にさらされることはないが、パッチ未適用の脆弱性は、企業への攻撃が成功する、最も一般的な道筋である。

また Assraf は、脆弱なソフトウェア・インスタンスを悪用する新しい攻撃ベクターを、セキュリティ研究者が発見したときに生じる、回避策という問題についても持論を展開している。つまり、既知の脆弱性攻撃から保護するために、体系的なアップデートやパッチを適用するのではなく、回避策を講じる開発者が数多くいることの問題である。彼は、「このような開発者は、この新しいエクスプロイトの影響を受けやすくなるが、そのレベルはパッチを適用していない開発者とおなじである」と述べている。

数百万台のパッチ未適用デバイスの問題が残る

外部からアクセス可能な脆弱性は、サイバー犯罪者にとって、お気に入りの攻撃経路であり続けると予想される。今週に Rezilion が発表したレポートによると、ソフトウェアやインターネット接続機器において、10年も昔からの脆弱性が、未パッチの状態で残っていることが判明している。

この調査で確認されたことは、2010年〜2020年に発見された脆弱性の、影響を受ける可能性のあるインターネット接続機器が450万台以上も存在することだ。また、これらの脆弱性の大半において、活発なスキャンや搾取の試みが繰り返されていることも確認された。

Rezilion の脆弱性リサーチ担当ディレクターである Yotam Perkal は、パッチが適用されていない脆弱性が、これほど多く存在する理由は複数あると述べている。

彼は、「第一に、セキュリティ・プログラムが成熟していない組織では、自社環境に存在する脆弱性を可視化することすらできていない。適切なツールや脆弱性管理プロセスを導入していなければ、基本的にリスクが見えるはずがなく、知らないものにパッチを当てることはできないとなる。第二に、成熟した脆弱性管理プロセスを持つ組織であっても、パッチ適用には時間と相当な労力が必要であり、しばしば予期せぬパッチ互換性の問題を、引き起こす可能性があることだ。毎年発見される新しい脆弱性の数は、増加の一途をたどっており、その遅れを取り戻すのに、すべての組織が苦労している」と説明している。

パッチ未適用の脆弱性はセキュリティの最重要課題

Assraf は、パッチが適用されていない脆弱性は、あらゆるセキュリティ問題の中で、最も重要かつ一般的であり、しかも修正可能な問題の1つであると述べている。彼は、「この問題は、業種や企業の規模を問わないが、大企業はシステムやユーザーの数が多いため、一般的に影響を受けやすくなっている」と述べている。

また、毎日のように新たな脆弱性が発生しており、脆弱性ゼロを実現することは夢物語であるとも指摘している。さらに、大規模なアップデートは、時として物事を壊し、予期せぬ結果や互換性の問題を引き起こすことがあるため、「壊れていないなら、直さない」というスタンスを取る人も少なくない。

Assraf は、「問題は、それが壊れていることであり、侵入されるまで、その隙間に気づかないだけだ。このほかにも、可視化/シャドー IT/所有権の複雑化につながる、分散されたチームといった問題も散見する」と述べている。

Assraf は、脆弱性とパッチを管理するための第一歩は、見える化であると指摘している。彼は、「環境内の、すべてのソフトウェア資産とデバイスの資産目録を持ち、正確で継続的な更新を行うことが、重要な第一歩だ」と説明している。次に行うべきは、これらのシステムや資産に適用される、アップデートの優先順位を決めることだ。しかし、その量が多すぎると、単なるノイズと化してしまう。ここが、企業が陥りがちなところだ。

Yotam Perkal は、パッチが適用されていない脆弱性がもたらすリスクに対して、より積極的な姿勢をとるためのキーポイントは意識だと考えている。

彼は、「リスクを認識したら、効果的に対策を講じるための適切なプロセスとツールを導入してほしい。結局のところ、野放しで悪用されていることが分かっている、既知の脆弱性に対して既存のパッチを適用することは、適切なセキュリティ衛生上の簡単な側面であるはずだ」と述べている。

Palo Alto Networks Unit 42 が、7月に発表したレポートにおいても、攻撃者がターゲットにするソフトウェアの脆弱性検討する際には、彼らが好むソフトウェアが用いられると示唆されている。

ビジネス・コンテクストでパッチの問題を解決する

Assraf によると、既知の脆弱性の深刻度を評価する CVSS のような、主要フレームワークの重要度に基づいて、優先順位を決めるのが一般的だ。いくつかのセキュリティ・ベンダーも、独自のブラックボックス・スコアリング・システム用いている。しかし、重要なのは、この種のステップが失敗し、ベンダーのスコアリング・システムが失敗する点である。つまり、ビジネスの状況を考慮に入れていないことに問題があるのだ。

したがって、ビジネス・コンテキストを持たない、第三者機関が付けた評価を用いるのではなく、自社のデジタル環境に最大の影響を与える、潜在的な脅威に注目することが重要となる。

Assraf は、「最も成熟した企業は、このような状況に基づいてパッチ適用プロセスを自動化し、最も重要なシステムを更新する。それと同時に、戦略的な導入スケジュールにより、ダウンタイムと影響を最小限に抑えている」と述べている。

Perkal は、組織で実行されているコードの大半が、オープンソース/プロプライエタリを問わずに、さまざまなサード・パーティーから提供されていると指摘する。

彼は、「そのため、企業はコア・ビジネス・ロジックに集中し、コードを迅速にリリースすることができる、それと同時に、ソフトウェアの脆弱性というセキュリティ・リスクも発生する。すべてにパッチを適用することは、実現可能なことではない」と指摘している。

この種のリスクに効果的に対処するためには、最も重要な脆弱性にインテリジェントに優先順位を付け、緩和と修復の一部を自動化することが可能な、攻撃対象領域管理プラットフォームが有効であると述べている。

彼は、「この調査から得られた最も懸念すべき点は、悪用可能な既知の古い脆弱性が、いまだに蔓延していることだ。私たちが行ったのと同じ分析が、攻撃者からも行われている可能性があり、この巨大な攻撃表面を脆弱な状態におくことで、彼らからの攻撃を容易にしている。ここが、重要なポイントだ」と指摘している。

Google SLO Generator という API Tool の脆弱性に関する記事を見つけて、訳し始めたらタイトルと内容が、ずいぶん違うものとなっていました。とは言え、このような記事は、多くの人に読んでもらいたい、とても有益なものだと思います。文中にある、「ビジネス・コンテキストを持たない、第三者機関が付けた評価を用いるのではなく、自社のデジタル環境に最大の影響を与える、潜在的な脅威に注目することが重要となる」という部分は、繰り返しになりますが、とても重要です。ただし、原題はナゾのままです。

%d bloggers like this: