MyBait：攻撃者をおびき寄せて当社のクラウドMySQLを暗号化させた理由

マネージドMySQLデータベースは、業務を容易にするためのものであるはずです。パッチ適用、バックアップ、インフラストラクチャはクラウドプロバイダーが管理し、認証とアクセス制御は顧客が管理します。その責任分担は、双方がそれぞれの役割を果たす場合にうまく機能します。そうでない場合、導入から侵害までの時間は数分単位で測定できるほど短くなることがあります。

Varonis Threat Labsは、そのウィンドウをテストすることにしました。Google Cloud PlatformのCloudSQLにおける設定ミスを調査していた際に、パブリックIPアドレスを持つMySQLインスタンスを作成しました。数分以内に、ブルートフォース攻撃が始まりました。そこで私たちは、「攻撃者に完璧なシナリオを与えたらどうなるだろうか」考えました。。つまり、脆弱なルートパスワードとパブリックアクセス権限を持つMySQLハニーポットを異なるクラウドプロバイダーに設置し、そこで何が起こるかを記録したらどうなるだろうかということです。

8分以内にブルートフォース攻撃が始まりました。数時間以内に、2つの別々の攻撃者がGCPインスタンスに侵入し、デコイテーブルを盗み出し、ビットコインを要求するランサムノートを残しました。AWS RDSとAzure MySQL Flexible Serverで同じ実験を展開しましたが、どちらも侵害されませんでした。

クラウドプロバイダー全体にわたるマネージドMySQLサービス

主要な3つのマネージドMySQLサービスに焦点を当てました。

1. GCP CloudSQL for MySQL
2. Azure MySQL Flexible Server
3. Amazon RDS for MySQL

これら3つはすべて、ポイントインタイムリカバリを備えた自動バックアップ、スケーラブルなコンピューティングとストレージ、各ダッシュボード（Google Cloud Monitoring、Azure Monitor、Amazon CloudWatch）を通じた組み込みの監視機能を提供します。セキュリティパッチとネットワークのセグメント化はプラットフォームによって処理されます。これらの違いは、デフォルトのセキュリティ構成とログ構成にあります。

GCPでは、管理アクティビティログが自動的に有効化され、すべての管理操作が記録されます。これらのログをオフにすることはできません。システムログは、バックアップやメンテナンスなどの自動化された操作をキャプチャします。ただし、データアクセスログは明示的に有効化する必要があり、データベースレベルの監査ログ記録には、特定のデータベースフラグ（general_log、cloudsql_mysql_audit）の設定が必要です。

Azureでは、アクティビティログがデフォルトで有効になっており、インスタンスの作成や削除などのAPIアクションが記録されます。データベースレベルの監査ログを有効にするには、サーバーパラメータでaudit_log_enabledをONに設定し、ログを保持するように診断設定を構成する必要があります。管理者はNSGフローログを使用して、ネットワークセキュリティグループを通過するIPトラフィックパターンを監視できます。

AWSでは、CloudTrailがデフォルトですべての管理APIアクティビティをログに記録します。これには、MySQLインスタンスに対する管理操作や、S3へのデータベースエクスポートが含まれます。データベースレベルの監査を行うには、管理者がMARIADB_AUDIT_PLUGINを含むオプショングループを作成し、SERVER_AUDIT_EVENTSおよびSERVER_AUDIT_LOGGINGをONに設定する必要があります。

セキュリティ態勢のデフォルトも異なります。 

GCP Cloud SQL for MySQLでは、rootユーザーをパスワードなしで作成できます。IAMデータベース認証もサポートされており、許可されたIPアドレスにアクセスを制限したうえで、パブリックIPアクセスを有効にできます。プライベート接続は、Private IPまたはPrivate Service Connect（PSC）を介して実現できます。Azureでは、予約済みの管理者ユーザー名（root、admin、administrator、guest、public、azure_superuser）は使用できず、Microsoft Entra認証をサポートしています。ネットワークアクセスは、ファイアウォールルールとVNet統合によって制御され、完全にプライベートな接続のためにオプションのPrivate Endpointを使用できます。AWSは、パスワード、IAM、Kerberos認証をサポートしており、管理者がIPアドレスとポートごとにインバウンドおよびアウトバウンドのトラフィックルールを定義できるVPCセキュリティグループによって、ネットワークアクセスが制限されます。

ハニーポットの実例

このGCPインスタンスは意図的に脆弱なセキュリティ設定でデプロイされました。具体的には、ルートパスワードが「password」に設定され、あらゆるIPアドレス（0.0.0.0/0）からのパブリックアクセスが許可されていました。データアクセスログと一般的なMySQLログの両方を有効にして、すべてのクエリをキャプチャするようにしました。2つのデコイデータベースが作成され、攻撃者が盗む価値のあるものとして偽の顧客データが格納されました。

攻撃者が行ったこと

展開から数時間後、複数のIPアドレスからブルートフォース攻撃および個別のログイン試行が複数検出されました。これらはすべて、複数のIPレピュテーションサービスによって悪意のあるものとしてフラグが立てられていました。主要な攻撃者は、持続的なブルートフォース攻撃によって攻撃を強化しました。約576回の試行失敗の後、攻撃者はデータベースへのアクセスに成功しました。その直後、サードパーティのVPNに関連付けられたIPアドレスを使用して再接続しました。

最初の攻撃者は、データベースへの侵入後、構造化された手順に従いました・

1. すべてのデータベースを列挙し（SHOW DATABASES）、テーブルを一覧表示し（SHOW TABLES）、テーブル構造を調査しました（SHOW FIELDS FROM `Records`）。
2. INFORMATION_SCHEMA.TABLESを使用してテーブルの存在を確認し、SELECT /*!40001 SQL_NO_CACHE */ `RecordID`, `CustomerID`, `Balance` FROM `Records` WHERE 1 LIMIT 10を使用してデータを抽出しました。このプロセスは、すべてのデータベース内のすべてのテーブルに対して繰り返されました。
3. 外部キー（ALTER TABLE `Records` DROP FOREIGN KEY `Records_ibfk_1`）を削除し、テーブル（DROP TABLE `Records`）を削除したうえで、ランサムノートを含む新しいRECOVER_YOUR_DATAテーブルを作成しました。

身代金要求のメモには次のように記されていました：「すべてのデータはバックアップされています。48時間以内に0.0094 BTCをbc1qd9r8c0t7x0dw748f8ft5wng2wjf9puh29ay5kuに支払わなければ、データは公開され、削除されます。」

このメモには、被害者が支払い後に自身のデータを特定するための連絡先メールアドレス（rambler+24hse@onionmail[.]org）とデータベースコード（24HSE）が含まれていました。

私たちはインスタンスを元の状態に復元しました。わずか6時間後、2人目の攻撃者が同じブルートフォース攻撃の手法を使ってこれを侵害しました。この攻撃者は最初のランサムノートを見つけ、RECOVER_YOUR_DATAテーブルをロックし、その構造と内容を確認した後、自身のランサムノートを含むRECOVER_YOUR_DATA_infoという新しいテーブルを作成して、元のテーブルを削除しました。同じ日に2つの異なるランサムウェア攻撃者が同じ公開データベースを標的にしたことになります。

侵害の兆候

実験中に以下のIPアドレスが観測されました。

当社の脅威インテリジェンス調査により、2回目の攻撃フローにおける初期攻撃者が、Huntersの非管理型Postgresハニーポット、ThreatIntelligenceLabが文書化したMongoDBランサムウェア事例、およびBorder0が文書化した侵害されたPostgresDBにも出現していたことが明らかになりました。この重複は、同一の攻撃者が複数のデータベースタイプにわたって自動化されたランサムウェア攻撃キャンペーンを実行していることを裏付けています。

公開されたデータベースの数

問題の規模を把握するために、Censysを使用して、3つのプロバイダーすべてにおいてパブリックIPアドレス経由でアクセス可能なMySQLインスタンスを特定しました。

これらのインスタンスはすべて、パブリックインターネットからアクセス可能です。それぞれが、今回観測したのと同様の自動化されたブルートフォース攻撃やランサムウェア攻撃の標的となる可能性があります。

検出

観測された攻撃は予測可能なシーケンスに従っており、各段階で検出可能なシグナルが生成されました。

1. 単一のIPアドレスからの繰り返されるログイン失敗。実験において、攻撃者は、成功するまでに576回の試行を行いました。どのようなアラートシステムであっても、そのしきい値に達するより十分に早い段階で、ブルートフォース攻撃やクレデンシャルスタッフィング攻撃のパターンを検知できるはずです。
2. ログインに成功した後、環境内でこれまで確認されていないVPNプロバイダーから再接続が行われました。初期アクセス後にIPを切り替えることは、ブルートフォーストラフィックを通常の活動から切り分けるための標準的な手法です。
3. 短期間にユーザーが大量の操作を繰り返す時間ベースの異常。これには、通常のアプリケーション活動ではまれで、攻撃者による収集を示唆する可能性のある大規模なSELECT * SQL_NO_CACHEクエリ、スキーマ偵察を示す頻繁なSHOW FIELDSクエリ、複数のDROP TABLE操作、過剰なSHOW TRIGGERSクエリが含まれます。
4. 偵察クエリのパターン：SHOW DATABASESに続いて、SHOW TABLES、SHOW FIELDS、そして一括のSELECT *ステートメントが実行されます。これは通常のアプリケーションの振る舞いとは全く異なります。これは、攻撃者がデータを持ち出す前にデータベース構造をマッピングしている状態です。
5. 同じテーブルに対する大量のSELECT *アクセスの直後に、DROP TABLE操作が実行されています。これはデータベースランサムウェアの特徴です。

MySQLインスタンスを保護する方法

今回の実験で侵害につながった設定ミスは、すべて修正可能です。GCPインスタンスは、脆弱なrootパスワードと無制限の一般公開アクセスが原因で侵害されました。開いたのはその2つの扉で、どちらか一方を閉めていれば、両方の襲撃者を阻止できたはずです。

マネージドデータベースでは、インフラストラクチャの責任はクラウドプロバイダーに移管されますが、認証、アクセス制御、監視は依然として顧客側の問題です。私たちの実験により、攻撃者はまさにこれらの脆弱性を狙っていることが証明されました。

 注：このブログはAI翻訳され、当社日本チームによってレビューされました