攻撃用フレームワーク「RAVEN」は、侵害されたElasticsearchおよびKibana環境を、持続的なデータ窃取・永続化オペレーションの拠点に変えてしまいます。
RAVEN(Reconnaissance & Attack on Vulnerable Elasticsearch Nodesの略)は、偵察、悪用、データ流出、永続化、痕跡消去といった一連の作業を通じてElasticsearchとKibanaのセキュリティ体制を評価するために構築されたオープンソースのモジュール型フレームワークです。
最新の解説では、Elasticsearch 7.17.22のラボ環境(認証なしの構成とX-Packによるセキュリティ有効化構成の両方)を対象とした侵害後の攻撃活動に焦点が当てられています。
このフレームワークが備えるexfilモジュールは、インデックス全体を改行区切りのJSONファイルへ丸ごと抽出できます。
Elasticsearch 7.10以降を対象とする場合はPoint-in-Timeページネーションを利用し、古いバージョンを対象とする場合はScroll APIによる対応も維持しています。攻撃者は、顧客情報を含むusersリポジトリのような単一インデックスを狙うことも、全非システムインデックスをコピーする一括モードを使うことも可能です。
結果として、検索・解析、あるいは攻撃者が管理するElasticsearchインスタンスへのインポートが可能な、ローカルに保存された持ち運び可能なデータセットが作られます。
大規模な環境向けに、RAVENは再開可能な収集処理をサポートしており、中断されたダウンロードを直前の地点から再開できます。
これは運用上重要な意味を持ちます。数百万件のドキュメントを窃取しようとしている最中にプロセスがクラッシュしたりネットワーク障害が発生したりしても、最初からやり直す必要がないからです。
このツールは、抽出したコンテンツを別のElasticsearchサーバーへ直接リインデックスすることも可能で、インデックスのマッピングや設定を保持したまま、被害者環境の攻撃者管理下ミラーを作成できます。
これにより、大量データの移動処理そのものがElasticsearchプロセス内で完結する形になり、大量の外向きAPI取得に伴う明白な兆候を減らせる可能性があります。
データ管理
LevelBlueの分析では、この手法は検知されにくい選択肢として位置付けられていますが、リポジトリの作成やスナップショット関連の活動は、防御側が監視すべき重要な監査イベントであることに変わりはないとしています。
`users`インデックス内のすべてのドキュメントは、今や`./loot/users.ndjson`に格納されています。1行につき1ドキュメントという形式で、解析、検索、あるいは攻撃者自身のElasticsearchインスタンスへのインポートに即座に利用できる状態です。
LevelBlueの研究者らによると、RAVENはさらに、スナップショットを利用した窃取手法も別の選択肢として用意しているとのことです。ドキュメントのページネーションによって長時間にわたるクエリ活動を発生させる代わりに、攻撃者はリポジトリを登録し、Elasticsearchにサーバー側でスナップショットを作成させることができます。
Elasticsearchデータベースの窃取
より懸念すべきなのは、永続化に関するデモンストレーションの部分です。RAVENは、Elasticsearch APIキー、不正なユーザーアカウント、スケジュール化されたWatcherジョブを作成できます。
APIキーは独立した認証情報であり、パスワードをローテーションしただけでは無効化されません。
Elasticの公式ドキュメントによれば、APIキーは有効期限が切れるか明示的に無効化されない限り有効なままであり、無効化にはmanage_security、manage_api_key、manage_own_api_keyといった適切な権限が必要です。
このフレームワークのWatcherベースの仕組みは、削除された永続化アーティファクトを復元するように設計されています。仕込まれたユーザーアカウントやAPIキーが存在するかどうかを定期的にチェックし、防御側がそれらを削除しても該当コンポーネントを再作成してしまいます。
Elasticによると、Watcherの管理にはmanage_watcher権限が必要であり、新しいバージョンのウォッチはそれを作成または更新したユーザーの権限の下で実行されます。そのため、インシデント対応時には権限の見直しとウォッチの棚卸しが不可欠です。
防御側にとって重要なメッセージは、Elasticsearchが侵害された後、パスワードのローテーションだけでは封じ込めが完了しないということです。
`raven-es –quiet -t localhost apikey –list –confirm-writes -u elastic -P changeme`を実行すると、以前に作成されたキーに加えて新しいキーが存在することが確認できます。
対応チームは、未把握のAPIキーを棚卸しして無効化し、ネイティブユーザーとロール割り当てを確認し、Watcherの定義とスケジュール化された自動処理を洗い出し、スナップショットリポジトリと直近のスナップショット活動を調査したうえで、これらの結果をKibanaおよびElasticsearchの監査ログと突き合わせる必要があります。
RAVENには、正規のテスト用に活動ログとクリーンアップ機能も備わっており、状態を変更する操作を記録し、元に戻すための手順も提供しています。
しかし、それが示している可視性のギャップは現実のものです。組織は、攻撃者が作成した認証情報、スケジュール、リポジトリが表面的な修復作業を経ても残存し得ることを前提に対処する必要があります。
[ライブウェビナー] ElasticとUnderDefenseが共催するウェビナーに参加し、小規模なセキュリティチームがAIの可視性とエージェント型対応を一つの運用モデルへ統合する方法を学びましょう。-> 今すぐ登録
翻訳元: https://gbhackers.com/elasticsearch-databases-theft/
