ランタイムセキュリティでAPIと古いCOTSを保護するには

APIが脆弱性リスクの上位に入る理由

1. 継続的なテストができない
2. APIのテストに必要なソフトウェアやデータ構造で実際のユーザが使用するルートが可視化されていない
3. 最もリスクの高い脆弱性に優先順位を付け、迅速に対応するための実用的な情報が不足している

Spring4ShellはAPIの保護が、アプリケーションを保護するのとは全く異なることを示す例だ。2022年3月29日、中国のサイバーセキュリティ調査会社がこの脆弱性の詳細をリークした。これは世界中のほとんどのエンタープライズJavaアプリケーションに影響を与える可能性のある脆弱性であると。Spring(Javaアプリケーション開発のインフラサポートを提供するオープンソースのアプリケーションフレームワーク)を開発するVMware社は、その2日後にリモートコード実行(RCE)の脆弱性を発表した。

数日のうちに、Spring4Shellは武器となった。 4月11日までに、悪意のある攻撃者がこの脆弱性を武器として活用して脆弱なサーバ上でボットネットマルウェア「Mirai」を実行していることが、セキュリティ研究者によって確認された。

Spring4Shellは、APIのセキュリティ確保が、アプリケーションのセキュリティ確保といかに異なるかを示す貴重な例である。というのは、この脆弱性は、単純に誰のせいでもないからだ。 Spring側にも、コードを書く開発者にとっても、適切な防御策は講じられていた。問題の深刻さを増大させたのは、コンポーネント間の相互作用だった。具体的には、Java9のClassオブジェクトへの変更によって、作成されるオブジェクトグラフインスタンスの Classである、ProtectionDomainとClassLoaderのどの部分も攻撃者が制御できないようにするためにSpringで実行されていたチェックが不十分になったのだった。 

APIは従来のWebアプリケーションと同じようにハッキングされやすいが、APIのセキュリティがアプリケーションセキュリティ(AppSec)とは同じではないAppSec)ことにみんな驚く。現在のセキュリティツールがAPIに適していると思うかもしれないが、そうではない。静的アプリケーションセキュリティテスト(SAST)や動的アプリケーションセキュリティテスト(DAST)では、スキャンしているものを明確に把握できない。これらは、2000年代初期からWebアプリケーション用に設計されて、それ以来あまり進歩していないのだ。

そして次はもう1つの問題の、パッチ未適用のCOTSだ

パッチが適用されていない古いCOTS：時限爆弾

本番環境に存在する悪用可能な脆弱性は、ただ攻撃が起こるのを待っているようなものだ.…。あるいは、場合によっては、既にハッカーにスキャンされて活発に悪用されている可能性もある。

一例を挙げると、2023年12月5日、米サイバーセキュリティ・インフラセキュリティ庁(CISA)が、Adobe ColdFusionの重大な脆弱性(CVE-2023-26360)がハッカーに盛んに悪用されて、政府のサーバが侵害されたと警告している。

この脆弱性は、Adobeが3月中旬にColdFusion 2018 Update 16と2021 Update 6をリリースして修正する前に、ゼロデイとして悪用された。当時、CISAはこの脆弱性を悪用する脅威の実行者に関する通知を出し、連邦機関や州のサービスに対して、利用可能なセキュリティアップデートを適用するよう早急な対応を求めた。それから数ヶ月が経過した現在、CVE-2023-26360は依然として攻撃に利用されている。例えば、6月には、2つの連邦政府機関システムに影響を与えたインシデントなどがあった。これらのシステムでは、CISAが「さまざまなCVE」と呼んだものに対して脆弱な古いバージョンのソフトウェアを実行していた。

攻撃者は、データを盗み出してスパイ活動を行うだけでなく、アイランドホッピング(企業や団体のデジタルトランスフォーメーションを乗っ取り、それを利用して顧客やパートナーに攻撃を仕掛ける行為を表す用語)を実行するために、悪用可能な脆弱性を常にスキャンしている。

アイランドホッピングでは、攻撃者はアプリケーションの攻撃によって企業環境に侵入し、そのアクセスを使用して、被害を受けた企業の顧客をベースに本来の標的に対して攻撃を仕掛ける。ColdFusionの攻撃以外にも、パッチが適用されていないCOTSの危険性を示す最近の例として、Operation Blacksmithがある。これは、Cisco Talos(サイバーセキュリティ企業)が、Lazarus Groupとして知られる悪名高い北朝鮮関連の脅威グループの活動を追跡するために使用している名前だ。このサイバーセキュリティ企業が12月初めに報じたように、このグループはLog4jのセキュリティ脆弱性を悪用して、これまでに公開されていなかったリモートアクセス型トロイの木馬(RAT)を侵入したホストに展開している。

長年にわたり北朝鮮で最も多くのサイバー犯罪に関与してきたLazarusによる今回のキャンペーンが、特に懸念すべきなのは、多くの企業がソフトウェアスタックにまだLog4jの脆弱性を抱えていると考えられることだ。Log4Shellの脆弱性が明らかになってから2年が経過した現在でも、企業は脆弱なLog4jライブラリを探し出すのに苦戦している。Veracodeによると、アプリケーションの4つに1つは依然として脆弱だという。

これらの脆弱性を探す時間がない

オープンソースであれCOTSであれ、Log4Shellなどの脆弱性に時間をかけて対処できる時代は終わった。攻撃者は、数日のうちに脆弱性を武器にしている。脆弱性を放置しておくと、企業は格好のカモにされてしまう。

攻撃者の目から見れば、政府機関と取引する企業・団体であれば、付加価値が高いと価値が高いとマークされ、標的にされることになる。悪用が成功した場合には、自分達のビジネスが政府機関そのものへのアイランドホップに利用されることになる。

COTSを更新できない場合にAPIやアプリを保護するには

企業・団体でよくあるのは、脆弱性管理プロセスや機能を採用する(できれば自動化する)ことで、自分達のソフトウェアを何重ものレイヤーの背後に埋め込むことだ。自分達のアプリケーションをマイクロセグメンテーションで分離する。つまり、ネットワークをセグメントに分割し、セグメントの要件に基づいて各セグメントにセキュリティ制御を適用するということだ。重要なのは、攻撃者の悪用経路を遅らせるために、システムを複数のパラメータの背後に置くことで、危険にさらされる環境の数を制限することだ。

また企業や団体では、システムが悪用される可能性のあるネットワークやエンドポイントの動作異常を探すために、侵入検知システム(IDS)などのセキュリティツールにも投資しているだろう。また、これらのシステムが実際に悪用可能かどうかを判断するための侵入テストも実施することであろう。そして、関連する攻撃経路を使用して、システムへのアクセスを強化するのだ。

これらの要素はすべて多層防御に関して価値あるものだが、それだけでは十分ではない。企業がすべきことは、ランタイムセキュリティを採用することだ。その理由は、ネットワーク攻撃が達成された場合、パッチが適用されていないCOTSを使用しているエンドポイントを悪用して成功するため、攻撃者の足跡がすでにネットワーク上に残っているからだ。その時点で、ほとんどの攻撃者は防御側自体に対して防御側自身の認証、認可、暗号化を使用するので、ほとんど手遅れになるのだが。

自分のセキュリティによって現実が見えなくなっている

暗号化は、鋼鉄のトンネルのようなものだ。暗号化されたトラフィックを解凍することはできない。攻撃者に独自の暗号化を使用された場合、それを解除して何が起こっているかを確認することはできない。これはパンドラの箱となる。鋼鉄製のトンネル内で何が起こっているのかを知ることはできず、攻撃者は基本的にはIDSなどを迂回するために、アプリケーションと自由にやり取りをするだろう。

これが、AppSecが現在よりもさらに進化する必要がある理由だ。だからこそ、ランタイム保護が必須なのだ。

ランタイムセキュリティで鋼鉄製のトンネルの壁を乗り越える

 根本的な問題は、一般的なソフトウェアスタックには、使用上危険でありながらまったく保護されていない関数が何千も存在するということだ。開発者が、開発で使用するすべての関数に関連する危険性やリスクをすべて把握することは不可能だ。この問題を実際に解決することなく覆い隠すために、頭文字プロセスとサイロ化されたツールセットの市場全体が作成された。

ランタイムセキュリティは、インストルメンテーションの力により、ソフトウェアスタック全体に埋め込まれた信頼境界でこれらの危険な関数を保護できる。これらの信頼境界は、関数が安全に使用されていない場合に開発者に警告を発する。また、ライブラリが脆弱で悪用可能かどうかを判断し、関数の使用を観察することでセキュリティの青写真を明らかにし、攻撃を検出して悪用の試みを防ぐ。

ランタイムセキュリティは実証済みであり、大変革をもたらものである。例えば、ランタイムプロテクション(RASP)によって、リモートコード実行(RCE)の脆弱性の存在が皆に知られる前からLog4Shellに対して保護してきた実績がある。これは、EDR(エンドポイントにおける検知と対応)やNDR(ネットワークにおける検知と対応)に似ている。SAST、DAST、WAFといった従来の方法とは異なり、ランタイムセキュリティはアプリケーションの動作をリアルタイムで検査し、異常な動きを自動的に特定して阻止することに重点を置いている。このプロアクティブなアプローチは、特定の脅威に関する知識に依存せず、標準的な動きから逸脱したものを防ぐことに重点を置く。

ランタイムセキュリティを義務化するという目標に向けて、CISAがGroup Lazarusに関する最近の勧告を強化して、ランタイムセキュリティの必要性を盛り込むことがが大きな第一歩となるだろう。

これは、信頼境界でアプリケーションスタックを強化し、企業や団体のセキュリティ体制を根本的に改善し、パッチが適用されていない脆弱性と新たなゼロデイ脆弱性の両方の脅威からアプリケーションを保護するための最良の方法だ。

Contrast SecurityのCTOで共同創業者のJeff Williamsよるビデオで、Contratのランタイムセキュリティプラットフォームに触れ、アプリケーションの脆弱性がどのように観察され、コンテキスト化され、開発ライフサイクル全体でどのように修正されるかを確認してほしい。 

関連記事：

• アプリケーションの攻撃経路マッピング  | Contrastブログ 
• 過検知+検知漏れ=実際のコスト  | Contrastブログ 
• 統計についての話：AppSecが誤った計算に基づいて行われている理由  | Contrastブログ 
• 無駄なAppSecにお金をつぎ込んではいけない | Contrastブログ
• 使えないAppSecツールを実際に機能する「ランタイムセキュリティ」に入れ替えよう  | Contrastブログ

この記事は、最初にSecurityInfoWatch.comに掲載されたものです。