詳解 Active Directory & Windowsインフラ・ペネトレーションテスト という書籍が今週発売されました。この書籍の内容には「9章 Microsoft SQL Serverの侵害」として SQL Server を対象とした内容も含まれています。
O’Reilly Online Learning ではまだ公開されていないのですが、原書となる Pentesting Active Directory and Windows-based Infrastructure については既に公開されていますので、原書で SQL Server の章を読んで読んで考えたことについてまとめておきたいと思います。
原書は 2023 年に発刊されたものとなり、今回の日本語版の書籍でアップデートがあるかもしれませんので、日本語版の書籍が O’Reilly Online Learning で公開されたら本投稿の内容にも反映したいと思います。
SQL Server に対しての侵害については、2008 年の書籍にはなりますが、SQL Server Forensic Analysis にも参考となる情報がありますので、こちらも参照するとよいのではないでしょうか。
SQL Server の発見と接続の制御
SQL Server のデータベースエンジンでは、通常次のポートが使用されます。
- TCP 1433: 既定のインスタンスのデフォルトポート
- TCP 1434: 専用管理者接続 (DAC)
- UDP 1434: SQL Server Browser サービスのポート
どのようなインスタンスが動作しているかを隠蔽する必要がある場合は UDCP 1434 (SQL Server Browser) へのアクセスも考慮する必要がありますが、TCP 1433 / 1434 へのアクセス許可については必須で考慮をしておく必要があるのではないでしょうか。
「SQL Server を発見する」という観点ではというような方法が使用される可能性があります。
- Active Directory から SQL SErver のインスタンスについての SPN をスキャンする
- IP 範囲でポートスキャン
上記のような手法でSQL Server が動作していると発見された環境に対して、TCP 1433 / 1434 には必要となるアクセス元からのみアクセスが行われる環境となっているかを確認するのが重要となるのではないでしょうか。
システム管理者権限の把握
SQL Server のログインとして最も強い権限がシステム管理者 (sysadmin) 権限となります。
SQL Server に対して不正な接続が行われ、バックドアとして利用されるシステム管理者権限を持つユーザーが作成されていないかについては把握しておく必要があるのではないでしょうか。
システム管理者権限を持つユーザーを取得する例としては次のようなクエリを使用できます。
SELECT 'Login Check' AS CheckType, name, principal_id, type_desc, create_date, modify_date, IS_SRVROLEMEMBER ('sysadmin', name) AS is_admin_role
FROM sys.server_principals
WHERE IS_SRVROLEMEMBER ('sysadmin', name) = 1
ORDER BY modify_date DESC
Microsoft Entra 認証でログインしている場合等は IS_SVROLEMEMBER が不正確になるケースがあるため、上記のクエリは簡易的なものとなりますが、このようなクエリを使用することで「直近で作成されたシステム管理者権限を持つログイン」を把握することができます。
次のような内容が確認のポイントとなるのではないでしょうか。
- 直近で変更されたログインが存在しないか
- 想定しないログインに対してシステム管理者権限が付与されていないか
また、OS の Administraotrs グループのユーザーがシステム管理者の権限を保持しないように設定しておくことも検討が必要かもしれませんね。ドメイン華僑の場合、Domain Admins が Administrators グループに含まれることで、ドメインの管理者が SQL Server に接続できるような構成が正しいのかは検討する必要があるのではないでしょうか。
信頼できるデータベースの設定
SQL Server のデータベースでは TRUSTWORTHY というデータベースプロパティがあります。
データベース所有者のクロスデータベースの所有権チェーンとして使用されるプロパティとなり、デフォルトでは msdb 以外のデータベースでは無効となっており、ユーザーデータベースもデフォルトは無効となっています。
データベースの侵害によりこの設定が意図せず有効化された場合、信頼関係により他のデータベースへのアクセスが可能となり、バックドアとして利用される可能性があります。
信頼できるデータベースの設定は次のクエリで確認ができます。
SELECT name, is_trustworthy_on FROM sys.databases
msdb はデフォルトで有効になっていますが、それ以外のデータベースで有効化されてバックドアとして利用される可能性があるかを把握することは重要ではないでしょうか。
DAC の使用状況の確認
SQL Server に対しての侵害があり接続が行われた場合、専用管理者接続 (DAC) を使用されると、通常参照できない SQL Server の様々な情報を確認することができてしまう可能性があります。
書籍では、DAC を使用してリンクサーバーのパスワードを複合化し、他の SQL Server に対して接続を行うというような侵害が記載されています。
SQL Server で DAC による接続が行われたかどうかについては、拡張イベントのログイン関連のイベントで「is_dac=true」で取得することができます。
DAC による接続が実施されたかどうかについては、このイベントを取得することで把握することができるのではないでしょうか。
DAC による接続が確認できた場合、通常では取得できない情報が取得された可能性が出てきます。
OS コマンドの実行
SQL Server ではデフォルトでは無効となっていますが、OS コマンドの実行に関連する次のような設定があります。
これらの設定はデフォルトでは無効になっており、侵害によってバックドアを仕掛けるため有効化される可能性があります。
設定状況は次のクエリで確認ができますので、侵害が発生した際にはこれらの設定が変更されていないかを確認する必要があります。
SELECT * FROM sys.configurations
WHERE name in ('xp_cmdshell', 'clr enabled', 'Ole Automation Procedures')
ERRORLOG がロールオーバーされていなければ、サーバー構成の変更はログに記載されるため、sp_readerrorlog で確認できる可能性があります。
EXEC sp_readerrorlog 0, 1, 'Configuration option'
また、他の方法として SQL Server エージェントジョブ経由でバックドアが仕込まれる可能性もあります。
不正な SQL Server エージェントジョブで作成されていないかを確認するために、次のようなクエリが活用できます。
SELECT name, date_created, date_modified FROM msdb.dbo.sysjobs ORDER BY date_modified DESC
直近で見覚えのないジョブが作成されているかどうかを確認するのも重要ではないでしょうか。
SQL Server オブジェクトの確認
侵害があった場合、見覚えのないSQL Server オブジェクトの作成が行われていないかの確認も必要となります。
- 直近で作成されたオブジェクトが存在していない
- スタートアップスクリプトが登録されていないか
- ログオントリガーが登録されていないか
このような確認が必要となるのではないでしょうか。
次のようなクエリを実行することで上記の内容を確認することができます。
USE [master] GO EXEC sp_MSforeachdb 'USE [?];SELECT ''[?]'' AS db_name, * FROM sys.objects WHERE modify_date > DATEADD(DAY, -7, GETDATE()) AND object_id > 0' SELECT * FROM sys.configurations WHERE name = 'scan for startup procs' SELECT * FROM sys.procedures WHERE is_auto_executed = 1 SELECT * FROM sys.server_trigger_events
機密性の高いデータへのアクセスの確認
SQL Server では、データの検出と分類の機能 があり、SQL Server の監査の SENSITIVE_BATCH_COMPLETED_GROUP と組み合わせることができます。
機密性の高いデータを含むテーブルへのアクセスについては、データベースレベルの監査で特定のテーブルを対象として監査を設定するという方法もあります。
監査対象が増える可能性を考慮すると、SQL Server 2022 以降での利用となりますが、検出と分類の機能と連携をさせたほうが良いのではないでしょうか。
Microsoft Defender fo SQL の活用
攻撃の検知としては Microsoft Defender fo SQL を活用するということも検討できるのではないでしょうか。
SQL 高度な脅威保護 により侵害に関係しそうなアクセスを検知できる可能性がありますので、入られる兆候の把握として活用できる可能性があります。
不変バックアップの確保
SQL Server 2025 からの機能になりますが、SQL Server 2025 からま Azure の Immutable BLOB Storage に対してのバックアップがサポートされています。
データの改ざんが行われていない不変的なバックアップの取得についても考慮をしておく必要があるのではないでしょうか。
SQL Server の更新プログラムの適用
SQL Server の更新プログラムの提供状況は次の情報から確認できます。
SQL Server の累積修正プログラムは、SQL Server のサービス モデル のサイクルで更新プログラムが提供されます。
定期的な更新プログラムの提供はメインストリームサポートのリリース後の最初の 5 年間で実施されます。
- 最初の 1 年間: 毎月
- その後の 4 年間: 2 か月ごと
その後はセキュリティの問題が発生したタイミングで拡張サポート期間の中で更新プログラムが提供されることになります。
これ以外に GDR という例外的な更新プログラムの適用サイクルがあります。
以前は GDR が提供されるのはまれでしたが、昨今はこの GDR と呼ばれる例外的な更新プログラムのリリース頻度が上がってきています。
2024 年以降、GDR のリリース頻度が上がっています。
リリース頻度が高くなった GDR の提供に対して、更新プログラムの適用タイミングをどのようにするかを改めて検討が必要となっているのではないでしょうか。