ランサムウェアによるデータベースへの攻撃と復旧作業

はじめに

近年、ランサムウェア攻撃は、金銭の獲得が容易であること、ツールの入手が容易であること、攻撃対象が拡大していることなどから、急激に増大しています。

ランサムウェアは、攻撃したデバイスのデータを暗号化し、その復号化のために金銭を要求する攻撃の一種です。通常はファイルやファイルシステムに関連することが多いですが、データベースサーバーを標的にすることもあります。データベース向けのランサムウェアは、復旧が困難であり、データベースの専門知識が必要です。

Imperva Threat Researchの調査結果を交えて、この記事では、データベースを狙うランサムウェアの脅威について、以下に解説します。

• 攻撃の検出方法
• 復旧のためのガイドライン
• MySQLデータベースを復旧するための具体的な方法

データベースに対するランサムウェア攻撃について

一般的なランサムウェア攻撃とは異なり、データベース向けのランサムウェア攻撃は、ファイルではなく、データベースに影響を与えます。

データベースに侵入するランサムウェア攻撃は、暗号化タイプとデータ漏洩タイプに分類できます。

それぞれのタイプについて詳しく確認します。

暗号化タイプ

ランサムウェアについて語るとき、ファイル暗号化という方法が最初に思い浮かぶことが多いでしょう。ファイルやファイルシステムによく使われますが、データベースでも同様に用いられます。

このタイプの攻撃は、データベースのサービスに備わっているデータ暗号化の機能を用いることが多いです。

• データベースに保存されるデータの暗号化（透過的データベース暗号化：「TDE」方式など）：データを書き込む前に暗号化し、暗号化された内容をディスクに書き込みます。メモリー上のデータは暗号化されません。
• vデータベースの標準機能を用いた暗号化： データベースのソフトウェアには、AES、DES、RSAのような一般的なアルゴリズムを使用した暗号化用の機能が提供されています。この機能は、テーブルやカラムにデータを先に挿入し、これらのデータを対象に適用されます。また、復号化用の機能が適用されるまでデータは暗号化されたままです。通常は暗号・復号化に用いる秘密鍵の管理機能も備わっています。

データベース向けのランサムウェア攻撃を行う攻撃者には２種類のタイプがいます。

1. 「hit and run」方式を用いた攻撃者の場合、攻撃の痕跡を残すことや検知されるリスクを気にせずに、データを暗号化していき、その暗号化鍵を削除することだけを狙います。まず、固有のキーと暗号鍵によって暗号化されたセカンダリ・キーを使って、データを暗号化します。ここでは、上記のデータベースの標準的な機能を用いて暗号化することもできます。その後に暗号化鍵を削除することで、データベースはデータを復号化できなくなります。
2. 「slow and low」方式を用いた攻撃者の場合、セキュリティソフトに検知されないよう、慎重に全てのデータを読み取ります。次に、データを暗号化しますが、アプリケーションに問題が生じないように、暗号化鍵を取り換えます。この準備が完了すると、攻撃者は暗号化鍵を削除し、データにアクセスできないようにします。

通常、これらの攻撃者は被害者と接触し、復号鍵と引き換えに身代金を要求します。

データ漏洩タイプ

このタイプのランサムウェアを使う攻撃者は、暗号化ではなく、データを盗むことを主な目的とします。

攻撃者は、以下のような方法でデータを漏洩させます：

• データベースのダンプを取得
• 通常の「select」クエリによる取得（場合によっては、限定したレコードのみ）
• DNSプロトコルなどを悪用して、セキュリティ対策を回避するテクニックを使用することで侵入

上記の2種類の攻撃者が、データ漏洩タイプのランサムウェア攻撃をどのように利用するか、ここで紹介します。

• hit and run」方式を用いた攻撃者の場合、攻撃の痕跡を残すことや検知されるリスクを気にせずに、ダンプツールや通常のクエリでデータをすべて抜き取ります。
• 「 slow and low 」方式を用いた攻撃者の場合、セキュリティソフトに検知されないように慎重に全てのデータを読み取り、セキュリティの回避テクニックを使いながらデータを流出させていきます。データの流出が完了すると、攻撃者はデータベースの中身を削除し、被害者に身代金のメッセージだけを残します。

ハニーポットを用いたランサムウェアの監視

Imperva Threat Researchでは、データベースに扮したハニーポットを複数設置することで、データベース攻撃のトレンドを常に監視しています。これらのハニーポットは常にランサムウェア攻撃に晒されており、攻撃者の新しい戦術、技術、手順（TTP）をモニタリングし、検出方法を開発するために利用されます。

これらのハニーポットでは、実際には暗号化タイプのランサムウェア攻撃は観測されませんでしたが、実験的にこの攻撃手法を再現することができました。また、流出タイプのランサムウェア攻撃を検知することに成功しました。

ここでは、ランサムウェア攻撃の調査で得られた結果をご紹介します：

• ランサムウェア攻撃の中には、攻撃者がデータを手に入れたというメッセージを残していましたが、ログを解析すると、読み取られたのはデータのごく一部で、被害者を脅迫するためのサンプルとして提供したと思われます。攻撃者のメッセージを信じる必要はないので、実際にどのデータが盗まれたのかをログから確認することが重要です。
• 多くの場合、攻撃者は身代金としてビットコインを要求します。
• ビットコインの口座アドレスを見ると、頻繁な取引が確認できました。ただし、これらの取引が必ずしも身代金とは限らないことに注意が必要です。
• 以下の文言のように、身代金要求のメッセージにEUのデータ保護規則（GDPR）の罰金という文言が含まれていることもありました。

図1：ハニーポットで検出された流出タイプのランサムウェアの例

データベース向けのランサムウェア攻撃の検知

ここでは、データベース向けランサムウェア攻撃の検知に関する一般的なガイドラインを紹介します。

• データベースの以下ログを確認する：
  
  • MySQLの暗号・復号化に関する関数の利用：
    • MSSQL’s ENCRYPTBYPASSPHRASE
    • MySQL’s AES_DECRYPT
  • データベースの鍵管理操作の利用：
    • MSSQLの場合：ALTER MASTER KEY
    • Oracleの場合：ADMINISTER KEY MANAGEMENT

ランサムウェア攻撃者のメッセージには、以下のようなキーワードが含まれています。

• データベースの監査用の機能を使用し、過去のデータベースの操作履歴を保存できます。
  • MySQLの場合：enterprise audit plugin
  • PostgreSQLの場合：PGAudit extension
• 以下のようなログを確認することで、不正操作を把握することが可能です。
  • 大量のレコードの読み取り： 平常時の読み取り行数と比較
  • 新しいクエリーパターン： アプリケーションは決まったパターンのクエリをリクエストします。新しいクエリが観測された場合、攻撃によってリクエストされた可能性があります。
  • 新しいエラーメッセージが表示される： アプリケーションはデータベースの読み取りエラーを発生させることはほとんどありません。ただし、データベースにアクセスしてエラーを発生させる一般ユーザーもいます。このようなエラーの種類を定期的に監視することで、侵入の兆候となる新しいエラーの種類を特定できます。例えば、攻撃者はSQLインジェクションなどのテクニックを使う際に、構文エラーを発生させる可能性があります。

どのようにデータベース向けランサムウェア攻撃からデータを復旧させるか

これまでは、データベースに侵入するランサムウェア攻撃の種類を説明しましたので、ここからは攻撃からの復旧について説明します。ランサムウェア攻撃によるデータが流出していないことを確認することは難しく、システムの可用性の問題に悩まされるかもしれません。その一方で、バックアップからデータベースを復旧することで、システムを運用可能な状態に戻すことができます。

事前準備

もしデータベースをバックアップしていなければ、身代金を支払わない限り、データは失われるでしょう。そこで最初に紹介するのが、データベースを定期的に複数の場所にバックアップしておくという考え方です。攻撃者は通常、プライマリ・セカンダリのバックアップの場所にアクセスできません。これらのバックアップへのアクセス権をチェックして、バックアップファイルの完全性を確認するために定期的にテストを実施しましょう。

ランサムウェア攻撃によるデータ損失を防ぐためには、データベースのログは非常に貴重です。

次に必要な作業は、トランザクションログを有効にし、データベースを運用することです。

また、攻撃者がログを改ざんする可能性もあるため、ログのバックアップも取得するようにしましょう。

ランサムウェア攻撃後のデータ復元方法

ステップ1：暗号化または削除されたテーブルを特定する
ステップ2：特定したテーブルの最新のバックアップを見つける
ステップ3: バックアップを使用して、各テーブルをリストアする
ステップ4: テーブルがバックアップ時点にリストアされる

ただし、バックアップ取得時以降にデータの更新がある場合は、トランザクションのログを検索し、更新情報を復元する必要があります。

ランサムウェア攻撃による操作も行われた場合では、ログの中から正当な操作だけを抽出して、コマンドに変換する作業が必要になります。こうすることで、リカバリ用のコマンドをデータベースに対して実行できるようになります。

注意点：データベースベンダーは、バックアップとリカバリについて、各社独自の条件とオプションを持っています。また、バックアップにはさまざまなタイプ（ホット/コールド/ウォームスタンバイ、オンライン/オフライン状態など）があり、リカバリにもさまざまなタイプがあります。この記事では、一般的な考え方について説明します。

リカバリプロセスの詳細な例については、MySQLデータベースのリカバリの例をご覧ください。

データベース向けのランサムウェア攻撃の影響を軽減する方法

データベース向けのランサムウェアについての説明の次は、データベースに侵入するランサムウェア攻撃からデータベースを守るための方法をいくつか紹介します：

• データベースはファイアウォールの後ろに配置し、許可されたサービスとユーザーのみにアクセスを許可する。
• データベースのセキュリティ構成や特権化されたエンティティを定期的に確認する（DISAやCISなどのガイドラインの確認が必要な箇所の特定に役立ちます）。
• 「最小特権の原則」を適用する – ユーザーには、業務遂行に必要な最小限の権限のみを与える。
• データベースは常に複数の場所にバックアップし、リカバリできることを定期的に確認する。
• データベースはシステム内部に存在するため、セキュリティ対策も不十分なことが多い。攻撃者はこのような脆弱性を利用する可能性が高いため、誤った認識を改める必要がある。
• データベース専用の監視およびリスク分析ツールを使用して、データベースのアクセスやステータスを視覚的に確認することでセキュリティを強化する。

MySQLを使用したリカバリの例（Linux版）

設定：ここでは、テスト用のMySQLインスタンスがあり、「lab」というデータベースがあるとします。このデータベースには、「test」というテーブルがあり、偽のクレジットカード番号とその所有者名が格納されています。このテーブルには、毎日新しいレコードが追加されます。

このデータベースは毎日バックアップしており、バイナリログの設定も有効になっています。

攻撃者はクレジットカード番号のレコードを読み取り、deleteクエリを使ってレコードを削除しました。一方で、レコード削除後にもテーブルには新しいレコードが挿入されるため、復旧作業はより複雑になります。 delete の処理が終わると、攻撃者からの身代金のメッセージが書かれた空のテーブルが作成されます。

ここでは、テーブルを復旧する方法を説明します：

まず、攻撃者がテーブルからレコードを削除し始めた時刻を特定する必要があります。これは、mysqlbinlogツールを使って、疑わしい時間帯を指定して以下のように行うことができます。

出力の一部抜粋：

ログ位置310761361（”# at 310761361″）でデータが削除されたことがわかります。前のログ位置（310761173）を”-stop-position “とします。

ここから、最後に成功した完全バックアップにデータベースをリカバリします。データベースをバックアップする方法はいくつかあります。ここでは、「mysqldump」ツールで「–master-data=2」オプションをつけて作成したバックアップを使用します。この時点で、リカバリ処理が完了するまでの間、データの欠損を避けるためにアプリケーションをシャットダウンしておくことが好ましいです。

バックアップからリカバリが完了したら、バックアップ以降から削除プロセスが開始されるまでに書き込まれたレコードもリカバリする必要があります。この場合、前のステップで設定した”-stop-position”が開始位置になります。また、バックアップファイルに書かれている開始位置も必要です。（”MASTER_LOG_POS=310760919″）：

「mysqlbinlog」ツールを使って復旧させます。

削除後にデータベースに新しい行の挿入または値の変更があった場合、適切なログ範囲を特定し、上記のパラメータを更新してログからのリカバリを再度実行できます。