Aqua CNDR で DreamBus ボットネット攻撃を阻止する #aqua #コンテナ #セキュリティ #dreambus #CNDR #マルウェア #ボットネット攻撃
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
本ブログは「Aqua Security」社の技術ブログで2021年12月22日に公開された「 Stopping a DreamBus Botnet Attack with Aqua’s CNDR 」の日本語翻訳です。
Aqua CNDR で DreamBus ボットネット攻撃を阻止する
最近非常によく確認される攻撃シナリオとして、管理者権限を持つ開発者が、クラウドネイティブアプリケーションを立ち上げたものの、誤って脆弱な認証情報を設定をしていた、ということがあげられます。そのわずか12時間後、その環境は DreamBus ボットネットに攻撃され、セキュリティ防御層を回避して Kinsing マルウェアとクリプトマイニングを実行しはじめました。Aqua CNDR(Cloud Native Detection and Response)は、この攻撃をリアルタイムで警告しました。この投稿では、環境の設定方法、攻撃者のアクセス方法、Aqua CNDR を使用して攻撃を検出、調査、対応した方法について説明します。
環境の構築
まず、開発者は4つの独自コンテナイメージで構成されるシンプルなコンテナ環境を作成しました。
- Web UI - ユーザがアプリケーションにログインして操作できる UI を提供します。
- Gateway - アプリケーションへのゲートウェイとして機能します。
- Microservice - アプリケーションをサポートします。
- Database - PostgreSQLを使用しています。
この攻撃がどのように、そしてなぜ起こったのかをよりよく理解するためには、開発者がコンテナを実行する前に行った手順を再現する必要があります。
コンテナイメージをスキャンする
まず、開発者は Aqua のソリューションでコンテナイメージをスキャンしました。下のスクリーンショットにあるように、コンテナイメージ Microservice や Web UI には、低~中程度の脆弱性がありました。彼は、これらの脆弱性には外部からの悪用がなく、その影響はごくわずかであり、またこれらの脆弱性は開発者の組織のコンプライアンスとポリシーを満たしているため、これらを無視しました。そして、他の2つのコンテナイメージは問題ないように見えました。
次に開発者は、Aqua の DTA(Dynamic Threat Analysis)を使ってコンテナイメージをスキャンしました。DTA は、コンテナイメージを安全な隔離環境(サンドボックス環境)で実行し、実行後のコンテナの挙動をよりよく理解できるように設計されています。静的スキャンはシグネチャとハッシュに基づいて既知の脆弱性や悪意のあるファイルを検出しますが、DTA は実行時にのみ現れる悪意のある動作を検出することができます。
例えば、コンテナイメージのパッケージ等には問題がなくても、コンテナイメージ内で実行されるようにしているコマンドの1つがリモートの C&C サーバからペイロードをダウンロードして実行するように設計されている場合、静的スキャンはこれを検出しません。ファイルレスのマルウェアや、tar 等で固められたファイル、エンコードされたファイルについても同様です。もう1つの利点は、静的スキャンと異なり、DTA は悪意のあるネットワークトラフィックも検出できることです。その結果、DTA は与えられたコンテナイメージに対して、より包括的な脅威のアウトプットを提供します。私たちのケースでは、DTA は何の問題も検出せず、コンテナイメージにマルウェアは見受けられませんでした。
コンテナをデプロイする
開発者は、Aqua のワークロード保護と CNDR を導入しましたが、Drift Prevention(コンテナにインスタンス化した後のイメージの変更を禁止するソリューション)を無効にしていました。また、Database コンテナは、任意の IP アドレス(0.0.0.0:5432)からのアクセスを許可しており、コンテナや Database へのアクセスを制限するマイクロセグメンテーションポリシーは作成していませんでした。さらに、PostgreSQL データベースは、脆弱な認証情報で構成されていました。
CNDRでBotnet攻撃を検知する
初回アラート
Aqua の CNDR は、最近 Aqua Platform に導入されたクラウドネイティブの検知・対応ソリューションで、攻撃を観測して作成した行動指標(IoC)を用いて、未知の攻撃をリアルタイムで検知し、ブロックするものです。
環境構築から12時間以内に、CNDR はコンテナの1つに深刻なセキュリティ問題があることを警告しました。開発者はそのコンテナを停止し、原因究明を開始しました。
CNDR は、コンテナとその下のホストに関連するさまざまな問題で、合計25件のアラートを発報しました。インシデントとレスポンスチームは、CNDR ダッシュボードで各イベントに関連する情報とコンテキスト、その起源(例えば、ホストまたはコンテナ)、その説明と深刻度を簡単に見つけることができ、多くの時間を節約することができました。
「View Full Event Data」をクリックすると、各イベントの詳細が表示されます。このケースでは、攻撃者はコンテナ内で /tmp から Kinsing マルウェアを実行していることがわかりました。
エビデンスの収集
CNDR の UI を通じて、さらにエビデンスを収集できます。CNDR は、リモートソースからファイルをダウンロードするために wget と curl が使用されていることを検出しました。つまり、実行時にコンテナはアプリケーション curl をダウンロードし、攻撃者はリモートソースからさらにファイルをダウンロードできるようになりました。
CNDR の監査ログには約7000件のイベントが記録されており、攻撃の全容を把握できました。その中には、不審な行動や悪意のある行動の検出、ネットワーク通信の遮断などが含まれています。
- wget 及び curl コマンドの検知
- クリプトマイニング実行の検知
- /tmp 配下でバイナリが実行
- セキュリティ機能の無効化
- リモートファイルのコピー
Kinsing マルウェア(MD5 648effa354b3cbaad87b45f48d59c616)と kdevtmpfsi(MD5 8c6681daba966addd295ad89bf5146af)が監査ログから確認できました。これらは、リモートソースから /tmp ライブラリにダウンロードされたものです。以下のスクリーンショットにあるように、それらは両方とも「postgres」グループの「postgres」ユーザによって所有されています。
さらに監査ログを見ると、以下のようなコードの実行が確認されました。
さらに、コンテナ内に複数の不正なファイルが発見されました。
- k(MD5 d79229c6c7fcbc4802934e34f80661a8) - 複数のクリプトマイナーが組み込まれたもの
- c(MD5 080a3bccdddc6979e3f1e74f732603b0) - 複数のクリプトマイナーが組み込まれたもの
- ss(MD5 a0db00b585a994be2cff9bb4a62ca385) - クリプトマイナー(VirusTotalで確認できないもの)
初期アクセスの取得
PostgreSQL のログを分析することで、初期のアクセスを取得するための不正行為が明らかになる可能性もありますが、これらのログは、他のログと一緒に失われていました。システムログの削除は、Kinsing マルウェアの特徴的な手口です。
CNDR のインシデント画面のアラートの1つは、攻撃者がシステムログを削除することによってシステムの整合性を損なったことを示唆しており、これがログファイルの欠落を意味する可能性があります。また、攻撃者がデータベースの内容をダンプし、環境外に流出させたのではないかという疑問が生じます。
PostgresSQL v9.3 以降、「COPY TO/FROM PROGRAM」として知られる機能により、データベーススーパーユーザと「pg_execute_server_program」グループのユーザが任意の OS コマンドを実行できます。この機能は、認証後、あるいは PostgreSQL がバックグラウンドで動作しているアプリケーションの SQL インジェクションを悪用して利用できます。なお、この機能はベンダー情報によれば脆弱性とはみなされていません。
キーポイント:多層防御が重要
この攻撃は、「多層防御」戦略を実践している好例と言えるでしょう。ワークロード保護やセキュリティスキャンなど、環境に導入された初期の保護レイヤーはいずれも、この攻撃の防御、検知ができなかったのです。
CNDR がなければ、攻撃者は攻撃に成功し、気づかれることなくクリプトマイニングを実行し、さらに被害を拡大させた可能性があったでしょう。CNDR はリアルタイムで攻撃を検知し、悪意のあるアクティビティに関するアラートを上げ、さらなる調査のために追加のログを提供します。
このような攻撃は、多重のセキュリティ層を構築し、さまざまな攻撃ベクトルに対応する冗長な防御を展開する「多層防御」の価値を示しています。万が一、あるセキュリティコントロールに障害が発生しても、他のレイヤーで攻撃をブロックできます。
緩和の推奨事項:Aqua ランタイム保護戦略
Aqua のランタイム保護は、ネットワーク、ワークロード、データの機密性、完全性、可用性を保護するために、クラウドネイティブ環境全体に階層化された一連のセキュリティ機構と制御を展開するものです。
Advanced Malware Protection機能とふるまい検知と保護
Aqua の Advanced Malware Protection は、シグネチャとハッシュに基づいて、既知の脅威とマルウェアの環境を継続的にスキャンしています。この攻撃では、Aqua のマルウェア対策は、悪意のあるスクリプト(.systemd-service.sh)、Kinsing マルウェア、Kdevtmpfsi クリプトマイナー、およびその他の悪意のある項目を検出しました。
未知の脅威を検知するために、Aqua のふるまいベースの保護は、ファイルレスマルウェアの実行、多層防御回避技術、疑わしいネットワーク通信、ルートキットの使用など、疑わしい悪意のあるふるまいを探すように設計されています。今回の場合、CNDR はログの削除やバイナリのダウンロードと実行など、疑わしい悪意のある行動を複数検出しました。
また、パスワードが強固で運用に耐えうるものであることを確認するために、ツールを使用することを強くお勧めします。例えば、Avishai Wool 氏と Liron David 氏のプロジェクトでは、パスワードの強度を推定し、パスワードクラッカーが与えられたパスワードを見つけるまで何回試行する必要があるかを予測することによって、ユーザが脆弱なパスワードを選ぶのを避けることができるようにするものです。
今回、Aqua のソリューションである静的スキャンと DTA を使用してコンテナイメージをスキャンしましたが、悪用された脆弱性は分析中であったために、見逃されてしまいました。したがって、本番環境では、CNDR のような実行中に悪意のある動作を明らかにできる検知・対応ソリューションを導入することを強くお勧めします。また、本番環境で起こりうるゼロデイ攻撃の検出と防止にも役立ちます。
Aquaのクラウドワークロード保護プラットフォームの機能
Aqua のクラウドワークロード保護プラットフォームの機能には、VM、コンテナ、サーバーレスワークロードを重層的に保護するための堅牢なランタイムコントロールのセットが含まれています。これらの制御は、ワークロードが実行される前に堅牢化し、本番環境で進行中の攻撃にリアルタイムで対応するための多層防御戦略として機能します。Assurance Policy などの一部の実行時管理は、ワークロードの受け入れゲートとして機能し、実行可能なものと不可能なものを定義します。
マイクロセグメンテーションポリシーは、ノード、クラスター、およびホスト間で許容するトラフィックを決定し、Kubernetes Assurance Policy は、ワークロードの実行を許可するために存在しなければならない(または存在してはならない) Kubernetes 構成を指示するものです。エンドユーザは、ワークロード保護機能を完全に制御でき、環境を保護するため事前に設定できます。
PostgreSQL データベースのようなサービスをインターネットに公開しないことを強くお勧めします。しかし、データベースが外部にアクセス可能である必要がある正当な使用例もあります。このような場合、ネットワークファイアウォールを使用し、データベースへのアクセスを制限することを検討してください。誰に対してもインバウンドトラフィックを許可するのではなく、特定の IP またはコンテナにトラフィックを制限します。
Drift Prevention
実行中のコンテナの不変性を維持するために、Drift Prevention は、コンテナにインスタンス化された後のイメージの変更を禁止します。この機能は、コンテナの不変性を利用して、実行中のコンテナにおける異常な動作を、その原因を知る必要なく特定しブロックできます。