SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

Agent 1433: remote attack on Microsoft SQL Server を読んでみる

leave a comment

Twitter の TL を眺めていたところ、Agent 1433: remote attack on Microsoft SQL Server が話題になっていましたので、どのような内容なのかを軽く確認してみました。

日本語は、マイナビニュースさんの 世界中で攻撃を受けるMicrosoft SQL Server、パスワードの見直しを で情報を公開されていたようです。
今回の攻撃ですが「直近の数日間で発生した攻撃」ではなく、Kaspersky Lab から公開された、「2019年1月~7月」の期間で、SQL Server の SQL Server Agent を利用した攻撃についての情報となるようです。
「この攻撃がどのような期間で猛威を振るっていたの / 現在も振るっているのか?」は、どのように情報を読むかによって変わってくるのではないでしょうか。

攻撃の内容

攻撃ですが、「攻撃者がサブネットワークの脆弱なパスワードを持つサーバーをスキャンし、攻撃は SQL Server がインストールされているかのリモートチェックから開始される」とあります。
「SQL Server の TCP 1433 を持つサーバーが外部に公開しているかどうか?」という記載はありません。
攻撃の踏み台としてバックドアが仕込まれてしまったコンピューターと、SQL Server がネットワークに疎通ができてしまうような構成となっていれば、攻撃の対象とみなされることになるかと。
この辺は一般的なウイルス感染による攻撃と変わらないですね。
接続については「パスワードの総当たり (ブルートフォースアタック)、または、以前に感染したマシンで認証されたユーザーアカウントトークン」を使用することがあると記述されており、コードの例は Windows 統合認証となっていますが、

  • 頻繁に使用されるユーザー名をターゲットとしたパスワードの総当たりによる SQL Server 認証
  • 以前に感染したマシンで認証されたユーザーアカウントトークンを使用したWindows 統合認証

あたりは定番で攻撃に使用されることになるかと。
今の Windows 版の SQL Server は次のようにインストールをすれば、既定で作成されている「sa」は無効化した状態で、SQL Server 認証を使うことができます。

  • インストール時は Windows 統合認証でインストール
  • インストール後に SQL Server 認証に変更

SQL Server on Linux については、初期ログインが sa となりますので、Linux 版の SQL Server については、インストール後に明示的に設定を変更する必要があります。
サンプルとして提示されているコードでは TCP 1433 として記述されていますが、「SQL Server を対象とする」と決めている場合、ポートスキャンで TDS の応答があったポートに対して攻撃を行う気もしますので、1433 から変更することにより、ある程度はブロックできるかもしれませんが、「SQL Server で使用するポート (初期であればTCP 1433)  で接続ができる IP を限定する」ことが、最初に意識しなくてはいけないことかと思いますが。
Web + SQL Server が同居しているような環境であれば、SQL Server の 接続で使用するプロトコル を TCP を用いないように設定して、ローカルホストからしか接続できないようにしておくというような考慮もあるかもしれないですね。
(Express Edition や Developer Edition のインストール直後の構成)
 

ジョブのサンプル

攻撃にはいくつかのパターンがあるようです。
その一つが SQL Server に含まれている「SQL Server Agent」という、ジョブスケジューラーの機能が利用され、マルウェアの実行が行われるパターンです。
このジョブスケジューラーの機能を使用して、次のような行動が行われているようです。

  • SQL Server Agent の「オペレーティングシステム (CmdExec)」を実行するジョブとして次のような処理を実行するジョブをして実行
    (ファイル削除等も記載されているようですが今回は割愛)
    • Internet Connection Sharing (ICS) サービスの停止
    • FTP でバイナリを入手し実行

SQL Server on Linux の SQL Server Agent では「オペレーティングシステムコマンド」を実行するジョブは作成できないはずですので、今回と同一の方法でジョブを仕込むことはできないかと。
FTP 以外のパターンでは、JavaScript によりマルウェアのダウンロードを行うというものもあるようです。
SQL Server には、OLE オートメーションストアドプロシージャ という機能があり、サーバーの構成として「Ole Automation Procedures」が有効 (デフォルトは無効) の場合に利用することができます。
攻撃対象となり、ログインが成功した場合は、この機能が有効化され、SQL Server のストアドプロシージャー経由で JavaScript が実行され HTTP 経由でアクセス可能な場所に対して配置された EXE がダウンロードされ、実行されるという経路での攻撃パターンもあるようです。
上記の OLE オートメーションを利用してバイナリを直接書き込むというパターンもあるようです。
SQL Server から、FTP や インターネット接続を遮断していたとしても、OLE オートメーション経由でバイナリをローカルドライブに書き込まれることで EXE を生成するということもありそうですので、外部へのアクセスを遮断していたとしても、攻撃対象になった場合は、特定のプログラムを実行されるということはありそうですね。
(試してはいないのですが、SQL Server on Linux の場合、OLE オートメーションストアドプロシージャの実行についてもかなり制限されているような気がしますね)
今回の攻撃では、SQL Server のログインの試行というシンプルな攻撃が、攻撃開始の始点となっているため、SQL Server のアカウントに対しての強力なパスワードの付与が推奨されているのではないでしょうか。
そもそもの話として、今回の攻撃にかかわらず、権限の強いログインに簡単なパスワードをつけること自体が推奨されませんが…。
基本的なことですが、外部 (社外ネットワーク) からのアクセス有無にかかわらず、「SQL Server にはどのネットワークからならアクセス可能となっているのか?」ということも意識しておきたいですね。
外部ネットワークにさらしていなくても、「外部ネットワークにアクセス可能な SQL Server にアクセス可能な端末」があれば、内部ネットワークからでも攻撃される可能性があり、今回は、SQL Server が外部のネットワークにアクセスできないようになっていても、バイナリを直接 OLE オートメーション経由で書き込むことで、マルウェアのプログラムを SQL Server に配置するということもありますので。
SQL Server Agent のアカウントは、SQL Server のデータベースに対しては、強力な権限が付与されていますが、OS のコマンド実行については、かなり制限されているものとなります。
ストアドプロシージャの実行についても SQL Server のサービスアカウントの権限で実行されることになりますので、OS に対して実行できることもかなり制限はついているはずですが、「SQL Server のサービスアカウントの権限の中で、OS に対して何が実行できるのか?」という観点の考慮は重要ですね。
 
Kaspersky の製品では、今回のような動作を行う SQL Server Agent ジョブのインストール (作成) が検知されるようになっているようです。
今回の攻撃の場合、SQL Server がマルウェアに感染していなくても、マルウェアが仕込まれた環境がネットワーク内に存在してしまっており、その端末から通常のアクセスパターン  (TDS による通信) が発生していると見えていても、SQL Server 内にウィルススキャンソフトが導入されていれば、ログインが行われても、不適切なジョブの作成 (または、クエリの実行) を検知 / ブロックすることができることになりますので、RDBMS 上のウイルススキャンソフトの導入の効果という観点でも、面白い調査内容なのではないでしょうか。
SQL Server の機能が使用されたマルウェア検知の一貫として、このようなパターンを判断するのでしょうかね。
SQL Server の機能を使用してマルウェアを導入させるために様々な方法を使っているのは興味深いですね。

Share

Written by Masayuki.Ozawa

8月 25th, 2019 at 2:44 pm

Posted in SQL Server

Tagged with

Leave a Reply