Log4Shell Exploit Threatens Enterprise Data Lakes, AI Poisoning
2022/05/13 DarkReading — 人工知能 (AI) や機械学習 (ML) の導入が進み、企業のデータレイクは大容量化しているが、残念なことに、Java Log4Shell 脆弱性を介して悪用されやすいことが、研究者たちにより明らかにされている。一般的な組織は、プライバシー保護に配慮しながら、AI／ML アルゴリズムの学習用に可能な限り多くのデータポイントを取り込むことに注力しているが、データレイク自体のセキュリティ強化に手を抜いていることが、あまりにも多くなっているという。
Zectonal の調査によると、Log4Shell の悪用は、従来からの WAF やスキャン装置などのセーフガードを回避して、データ・パイプライン経由でターゲットのデータレイクやデータリポジトリに取り込まれると発動するという。
ユビキタス Java Log4j ライブラリを標的としたオリジナルの攻撃と同様に、悪用に必要なのは単一のテキスト文字列のみである。攻撃者たちは、この文字列を悪意のビッグデータ・ファイルのペイロードに埋め込むだけで、データレイク内でシェルを開くことが可能であり、そこからデータ・ポイズニング攻撃を開始することができると、研究者たちは述べている。また、悪意のペイロードを含むビッグデータ・ファイルは、暗号化または圧縮されていることが多いため、検出の難易度は非常に高くなる。
Zectonal の創設者である David Hirko は、「Log4jShell の悪用はシンプルであるため、きわめて悪質なものになり得る。この攻撃ベクターは、データパイプライン／ビッグデータ分散システム／機械学習の学習アルゴリズムなどの、通常の運用に紛れ込んでいるため、脅威として監視／特定することが困難である」と述べている。
データレイクにアクセスするための RCE エクスプロイトの悪用
この攻撃を実現する１つの方法として、データレイクを構築するための最も一般的なツールである、ノーコードのオープンソース抽出／変換／読み込み (ETL：extract-transform-load) ソフトウェアの、脆弱なバージョンを標的とする戦術が存在する。攻撃者は、既知のリモートコード実行 (RCE) エクスプロイトを悪用し、パブリックなインターネットからプライベート・サブネットで実行されている、ETL サービスにアクセスできると、研究者たちは報告書で説明している。
Zectonal チームは、この攻撃ベクターを使用した PoC エクスプロイトを作成し、パブリック・クラウド・プロバイダがホストする、仮想プライベートクラウドの一部であるサブネット IP アドレスに、リモート・アクセスすることに成功した。
昨年に ETL は、RCE 問題に対するパッチを適用したが、対象となるコンポーネントは数百万回もダウンロードされており、セキュリティ・チームによる修正プログラムの適用が遅れているようだ。Zectonal が Dark Readingと共有した報告書によると、「Zectonalチームは２年間を期間として定め、ETL ソフトウェアの複数の未パッチ・リリースに対して、RCE エクスプロイトを誘発させることに成功した」とのことだ。
David Hirko は、「この攻撃経路は、単にテキスト文字列を Web サーバーに送信するというような単純なものではなく、データのサプライチェーンに侵入する必要がある。攻撃者は、上流のどこかでファイルを侵害し、それをターゲットのデータレイクに流し込む必要がある。たとえば、気象データについて考えてみると、深海のセンサーから送られてくるファイルを操作して、問題となっている特定の文字列が含まれるようできるかもしれない」と述べている。
この脆弱性に対してはパッチが用意されているが、この種の Log4Shell 攻撃を実現するための手段は数多く存在すると思われる。Hirko は、「同じようなことを可能にする、これまで知られていなかった、あるいは公表されていなかった脆弱性が、おそらく数多く存在する。それは、私たちが見た、データ・ポイズニングに特化した初めての攻撃ベクターであるが、AI ポイズニングのサブセットとしてのデータポイズニングは、今後の新しい攻撃ベクターの１つになる」と述べている。
現実世界での影響
現時点において、この種の攻撃が Zectonal により確認されているわけではないが、この脅威がセキュリティ・チームのレーダー。スクリーンに映し出されることを、研究者たちは願っている。このような攻撃は稀なことかもしれないが、きわめて大きな影響を及ぼす可能性がある。たとえば、AI とセンサーに依存して、街中を移動する自律走行車の場合を考えてみよう。
Hirko は、「自動車メーカーは AI に信号待ちをさせ、停止／減速／発進のタイミングを、信号機の赤／黄／緑で判断させるよう訓練している。もし、AI を訓練しているデータレイクに汚染されるとしたら、AI ソフトウェアを操作して、予期せぬ振る舞いをさせることが可能になる。もしかしたら、あなたの車は、信号が赤になったら進み、青になったら止まるように、学習させられてしまうかもしれない。つまり、そういう攻撃ベクターが今後は登場してくると思われる」と述べている。
セキュリティ保護が遅れている
David Hirko は Dark Reading の取材に対し、「このリスクは現場の実務家の間でも注目されており、その多くは危険性を理解していながら、どのように取り組めばよいか途方に暮れている。この問題に取り組むには、新しいツールだけでなく、新しいセキュリティの実装方法が必要であることも課題の１つだ」と述べている。
彼は、「私たちは、ごく一般的なデータ・パイプラインを通じて、毒化されたペイロードを送ることができた。現時点において、この種のファイルやデータのパイプラインは、標準的なファイアウォールのフロントドア・セットを通過していない。データがエンタープライズに入ってくる経路や、データがデータレイクに入ってくる経路は、深層防護やゼロトラストといった、古典的なセキュリティ。フレームワークの一部にもなっていない。大手のクラウド・プロバイダーを利用している場合、オブジェクト・ストレージのバケットから入ってきたデータは、必ずしもファイアウォールを通過するわけではない」と指摘している。
また、この種の攻撃が忍び込んでくるファイル形式は比較的に新しいおもであり、やや不明瞭であり、ビッグデータや AI の世界に特化している。そのため、文書やスプレッドシートをスキャンするために作られた、一般的なセキュリティ・ツールでは簡単にスキャンできないとも、彼は付け加えている。
David Hirko は、「したがって、セキュリティ・ベンダー側としては、さらなる可視性を獲得するために、さまざまなタイプの製品の開発に注力する必要がある。その一方で、ユーザー企業側は、データの品質／構成要素／個々のデータポイントに注目しているが、そのデータのセキュリティ上の脆弱性にも目を向けるべきだ。データの観測可能性は、データ・セキュリティだけではなく、品質保証にも組み込まれると思われる。それが、データおよび AI セキュリティの新たな領域である」と指摘している。
現実の脅威が登場しているという話ではありませんが、登場していないことを証明できるわけでもありません。JNDI Lookup とLDAP の組み合わせのような、攻撃な容易な脆弱性は Log4Shell に限ったものではなく、この記事で指摘されるような悪用につながる恐れがあります。また、文中には、「ETL：extract-transform-load) ソフトウェアの、脆弱なバージョンを標的とする戦術が存在する」と記されていますが、それに関しては Zectonal の An Attack Vector for Data Supply Chains and Data Lakes Using Data Payloads as Exploits に詳述されています。このレポートは Web 形式なので、ラウンドー度なしで簡単に参照できます。→ Log4j まとめページ
IoT OT Security News 