今日は、Contrast Securityのアプリケーションにおける検知と対応(ADR)のデータについて、特に世界で最も危険な攻撃手法の1つであるEL(式言語)インジェクションに焦点を当てて、詳しく見ていこう。攻撃の種類別の件数については、下記の本文内に記載している。
侵害事件
これは、史上最大規模のデータ侵害の1つであるEquifax侵害事件で、中心的な役割を果たしたことで記憶に新しいかもしれない。この侵害は、1億5,900万人のデータに影響を与えた。Equifaxは、消費者の回復を支援するために最大4億2,500万ドルを支払うことに同意した。この金額は、テクノロジとデータのセキュリティの改善し、訴訟費用やコンピューターフォレンジック費用、その他の直接的な費用など、同社の修復費用として推定される3億3,700万ドルを超える金額だ。
侵害は2017年まで、さかのぼる。そんな日付だと、古いニュースのように聞こえるが、そうではない。毎日のように、攻撃者はEquifaxの侵害と同じ種類のWebアプリケーションの脆弱性を悪用しようとしている。なぜ分かるのかというと、Contrastが、WAF(Webアプリケーションファイアウォール)を含む従来の全ての防御をすり抜けて攻撃を仕掛けてきた者を捕まえているからだ。
Equifaxに関連した脆弱性と同じ種類といえば、今月の攻撃数レポートの焦点であるOGNL(Object-Graph Navigation Language)インジェクションのことだ。このような単純な攻撃がどのように機能し、どのように阻止できるのかについては説明するが、まず、Contrast ADR(アプリケーションにおける検知と対応)の概要を、続けて10月の攻撃数を紹介しよう。
Contrast ADRとは?
システムを銀行に例えると、従来の防御は境界を守る警備員のようなものだ。攻撃者は常に、銀行の正規の顧客になりすまして警備の目をかいくぐろうとしている。残念なことに、警備員は自分達が何を守っているのか、実際の顧客がどのような顔をしているのかを知らない。攻撃者かもしれないと思われるものには過剰に反応する。
この例え話しを続けると、Contrastおよび後述で紹介するデータは、銀行内、金庫内に設置されたカメラに基づき、人々や彼らが銀行内に持ち込むあらゆる物を常に監視している。Contrastは、フェンスと警備員を通り抜けた人々だけを認識する。Contrastは、人々の行動が明らかに本当の攻撃である場合を検知する。例えば、銃を抜いたり、金庫からお金を盗んだりなど。このようにして、Contrastは脆弱性の存在を検知するだけでなく、実際に悪用可能かどうかを確認する。これは、Contrastは実際の脆弱性を悪用しようとする本当の試みだけをフラグを立てて防止することを意味する。
Contrast ADRで検知した2024年10月の攻撃
10月の攻撃のうちの大部分はプローブ(探査検出)と呼ばれるものであった。プローブとは、やみくもにアプリケーションやAPIを標的にし、実際の脆弱性には結びつかない無害な攻撃の試みである。なので、プローブと実際の攻撃を区別することが非常に重要になる。
例えば、実際にEL攻撃が式を評価するコードに全く近づかないと想像してほしい。それが、プローブだ。誰が自分を攻撃しているのかを知りたいという点で興味深い存在だが、明らかに危険ではない。WAFやAPIセキュリティ製品などの境界検知テクノロジでは、プローブを重大な攻撃としてフラグを立て、誤ったアラートを生成し、アプリケーションやAPIの正常な動作を妨げることがよくある。
最初のグラフは、これらのプローブを示している。10月には、平均的なアプリケーション/APIで4,110件のプローブがあった。これは相当な数の攻撃だ。パストラバーサルは明らかに攻撃者のお気に入りで、プローブの82%を占めていることがわかる。コマンドインジェクション(364件/月)とSQLインジェクション(178件/月)が、それに続く。
パストラバーサル(最も厄介な攻撃の1つ)についてもっと読む
ただ、これらの攻撃のほとんどは、対する脆弱性に到達することはなく、無視しても問題ない。
2つ目のグラフはさらに興味深いものになっている。これは、アプリケーション/APIを通過し、実際に対応する脆弱性に到達する攻撃を示している。全体として、これらの実行可能な攻撃は、プローブの件数の約1%だ。例えば、パストラバーサルのプローブが何千もあるにもかかわらず、実際に実行可能でファイルアクセス関数に到達するのは、月にわずか2件しかない。
ご覧の通り、クロスサイトスクリプティング(XSS)とボット攻撃が最も一般的だ。これらの実際の攻撃結果を考慮し、SQLインジェクション、信頼されていないデシリアライゼーション、ELインジェクションなどの攻撃に焦点を当てることが必要だ。なぜなら、実際には最も重大だから。
これらが「実行可能な攻撃」になると非常に危険であり、Contrastが導入されていなければ、対象のアプリケーション/APIは悪用されていただろう。
お分かりのように、平均的なアプリケーション/APIでは、月に約2.5件のプローブと1.4件の実行可能なEL攻撃が発生している。かなり少ないように思えるが、なぜこれが実際には非常に深刻であるのかを見ていこう。
ELインジェクションに注目:「実に上品な攻撃」
EL(式言語)インジェクション攻撃は簡単であり、厄介で悪意に満ちた攻撃だ。ASF(Apacheソフトウェア財団)は、そのような脆弱性(特にApache Struts CVE)が、Equifaxの侵害に関与していると指摘している。
OGNLを理解すること、そして、Contrast SecurityのCTO兼創設者であるJeff Williamsがこのような攻撃を「上品」だと考える理由を理解するには、EL(式言語)を理解する必要がある。この言語は、開発者がユーザインターフェイスにコードを簡単に追加できるようにすることを目的としていた。これは、データ値を取得して、例えばHTMLページに貼り付けるように設計されている。他にもいくつか用途はあるが、これが主な使用例だ。
開発者は、多くのコードを記述する代わりに、シンプルな構文を使うことができるのだ。「例えば、'user'オブジェクトの名前の値を教えてくれ、と言う。それで、ユーザオブジェクトを取得して、そこから名前を取り出したら、それをユーザインターフェイスのHTMLに貼り付ける。」とJeffは説明する。
「ELがなければ、そのデータを取り込むには4〜5行のコードが必要になる。それは、ちょっと面倒だったんだ。」とJeffは言う。しかし、ELであれば、データの断片を取得して単純な処理を行うという特定のタスクに対して、上品で簡潔な構文が可能だ。
何が悪かったのか?
残念なことに、ELエンジンを開発した人達はそれを強力なものにしすぎたのだ、とJeffは言う。式内から関数を呼び出せるようにしてしまったのだ。例えば、データを大文字にする関数を呼び出すことができる。しかし、制限はないので、関数を呼び出してプロセスを開始したり、ファイルを作成したり、データベースに接続したりすることなどができる。というように、これらを全て式内から実行できる。
「そして、開発者はたまに、評価対象の式の中にユーザが作成したデータを誤って入れてしまうことがある」とJeffが説明を続ける。「これによって、攻撃者が、データを盗んだり、ランサムウェアをインストールしたり、他のシステムを攻撃したりといった、危険なことを行う悪意のある式を送り込む機会が作られることになる。」
例えば、銀行のWebサイトでコードを実行できるとしよう。あなたならどうする?ランサムウェアをインストールする?他人のアカウントを乗っ取る?銀行のデータベースを破壊する? それを出発点として利用して、銀行内部のリソースにアクセスするだろうか?「これら全てが選択肢だ」とJeffは言う。
上品で危険、そしてフレームワークに組み込まれている
アプリケーションとAPIフレームワークは、開発者が迅速に製品を作成できるよう、広範なサポートを提供する。そして、これらのフレームワークの多くは、ELのサポートを含んでいたり、ELのサポートに依存している。Javaでは、StrutsとSpringはどちらも広く使用されているフレームワークであるが、どちらも長年にわたり、意図せずELインジェクションの脆弱性を露呈していた歴史がある。
例えば、Apache StrutsのCVEリストで最も重大な脆弱性はELの問題だ。また、StrutsやSpringなど、式に依存するその他のフレームワークの欠陥のあるバージョンをいまだにダウンロードしている組織もある。2023年12月時点で、Apache Struts2のダウンロードの5件中4件は、CVSSの深刻度が10段階中9.8となった、重大な脆弱性であるCVE-2023-50164を含むバージョンであったと報告されている。
これだけ脆弱性が詰め込まれたものがダウンロードされているのだから、今月Contrast ADRで3,345回のEL攻撃が確認されたのも不思議ではない。これらの攻撃は全て、Equifaxの惨事が再現されてしまうものだった。
Contrast ADRでOGNL攻撃をどのようにブロックするか
Contrast ADRは、次の2つの方法でOGNL攻撃をブロックする。
1. ADRは信頼できないデータによる式の変更を防ぐ
Contrast ADRは、信頼できないデータを追跡し、アプリケーションコードでそれが式として評価されないようにする。Contrast ADRにより信頼できないデータの評価が確認された場合、信頼できないデータは決して式として評価されるべきではないことから、それは攻撃として認識される。この攻撃にフラグが立てられ、インシデントとしてセキュリティオペレーションセンター(SOC)に送信される。また、悪意のある式の評価を自動的に停止し、悪用を防ぐこともできる。このアプローチは非常に正確で、確認された攻撃のみが識別される。
2. ADRは危険な関数の周りにサンドボックスを作る
しかしながら、信頼できないデータのソースは必ずしも単純ではない。例えば、多かれ少なかれ信頼しているバックエンドシステムからデータを取得することもある。例えば、データは、他の場所から取得したAPIやデータベースから取得される場合もあれば、テキストファイルから取得される場合もある。つまり、Webアプリケーションユーザ以外のソースから取得される場合がある。これらのデータの全てが式で使われないようにすると、機能が損なわれる可能性がある。そのため、このような場合、式評価エンジンの周囲にサンドボックスが作成され、ネイティブプロセスの開始、ネットワーク接続の作成、ファイルへのアクセスなど、危険な操作が行われないようになる。このような悪意のある動作は、Contrast ADRによって防御され、安全でない式は評価されないようになる。
JNDI攻撃を解明:Contrast ADRでこれらの攻撃を阻止する方法を学ぶには攻撃の仕組みを参照
Contrast ADRにより、全てのアプリケーションの動作をリアルタイムでアクティブに監視・解析し、このような危険な関数を信頼境界で囲み、本番環境の脆弱性と攻撃を特定できる。強力で危険な関数に境界線を設置するようなものだと考えてほしい。そして、この境界線は、異常な動作を防ぐ。
まとめ
Contrast ADRは、あらゆる場所で適切なチェックを行い、実際の脆弱性と実際の攻撃を組織に警告し、 アプリケーション/API、脅威、アーキテクチャ、接続されたシステムに関する完全なコンテキストと洞察を提供する。
ADRテクノロジにより、攻撃者が日々仕掛けてくるWebアプリ/API攻撃からどのように組織を守ることができるのかは、是非Contrast ADRのデモのリクエストを。 その機能をぜひご覧いただきたい。
関連記事/サイト: