実録・4大データベースへの直接攻撃：川口洋のセキュリティ・プライベート・アイズ（25）

» 2010年05月18日 10時00分公開

情報の入れ物、データベースは大丈夫ですか

　皆さんこんにちは、川口です。そろそろGumblarの話に飽きてきたところでしょうか。今回は以下の4種類のデータベースで、管理用ポートをインターネットにオープンしているとどうなるかについて調べた結果を取り上げます。いずれも管理用ユーザーのパスワードは「脆弱なもの」に設定されています。

Oracle（1521/tcp）
SQL Server（1433/tcp）
MySQL（3306/tcp）
PostgreSQL（5432/tcp）

　右側に書いてある番号が管理用ポート番号です。データベースを管理する場合、これらのポートをインターネットに対してオープンにする必要はないはずです。しかし、これらのポートに対して外部から“直接”接続するインシデントが年に数回は発生しています。

　このようなインシデントは、大学のネットワークに接続したサーバがほとんどですが、ホスティングサービスのサーバでもこれらインシデントが発生しています。データベースサーバに対するアクセス制御が不十分なことが原因です。

　データベースが攻撃を受けた頻度を表したものが下のグラフです。

図1　データベース種類別の被攻撃回数（2009年10月～2010年4月・ラック調べ）

　SQL Serverが最も多く攻撃を受けています。攻撃者にとっても最も“おいしい”環境なのでしょう。次いでMySQL、Oracleとなっています。

　PostgreSQLは管理用ポートへの接続すらありませんでした。データベースとしてはそこそこ利用されているはずですが、攻撃者にとっては魅力がない環境なのでしょう。アクセス制御をせずにデータベースを運用する方にはPostgreSQLが最もお勧めですね、というのはもちろん冗談です（笑）。

SQL Serverへの攻撃

　SQL Serverが攻撃を受けた際に実行されたコマンドは以下のようなものです。攻撃者は脆弱なパスワードを突破したあと、これらコマンドを短時間で実行していますので、おそらく機械的に攻撃しているのでしょう。

図3　SQL Serverへの攻撃コマンド例（クリックで全体を表示）

　1行目と2行目で関数を定義して、3行目でコマンドを一気に実行しています。3行目から18行目は見やすさを考えて改行を入れていますが、実際には1行のSQLコマンドです。4行目から17行目が“&”で連結されたOSのコマンドです。5行目から11行目まででsetuply.sysというファイルにFTPコマンドを追加してコマンドファイルを作成しています。12行目でFTPコマンドファイルを引数に指定して、FTP接続を実行します。

　FTPサーバからはnb.exeと730.exeの2つのファイルを取得しています。それぞれファイル名をnb.exeからsetuply.exeへ、730.exeからtcpser10.exeに変更し、保存しています。そのあとsetuply.exeとtcpser10.exeを実行し、実行したファイルを消去しています。

　実行されたプログラムはボットとして動作しており、攻撃者はこのボットを経由してデータベースサーバを自由に操作します。そのあと、このデータベースサーバは別のIPアドレスから次々とログインされ、ボットを埋め込まれてしまいました。

MySQLへの攻撃

　次にMySQLへの攻撃を説明します。MySQLもSQL Serverと同様に脆弱なパスワードを用いて突破し、さまざまなコマンドを実行していきました。実行されたコマンドは以下のようなものです。

図3　MySQLへの攻撃コマンド例

　ここから、以下のような手順で攻撃が行われているのが分かります。

ログイン後、変数などの設定を行い、特定テーブルの初期化を行う
concatを使い、不正なプログラムをテキスト形式で送り込む
送り込んだテキストファイルを実行ファイルに変換
VBスクリプトを作成し、外部のサーバのk.exeを取得し、実行
後始末

　SQL Serverへの攻撃と同様に、SQLコマンドとOSコマンドを組み合わせながら、外部のサーバに置かれている実行ファイルを取得しています。外部のファイルを取得する方法として、SQL Serverへの攻撃の際にはFTPを利用していましたが、今回はVBスクリプトからHTTP経由で取得しています。これは攻撃者の好みの問題だと思いますが、データベースサーバから不審な通信が発生していることには違いありません。

　MySQLへの攻撃で特徴的なことは、Windowsのバイナリファイル（k.exe）を取得していることです。実はこのデータベースサーバはLinux上でMySQLが稼働しており、Windowsのバイナリファイル（k.exe）を実行することができません。攻撃者はデータベースが稼働しているOSを確認することなく、バイナリファイルを実行しました。このファイルの実行が失敗に終わると攻撃者はそのまま接続を切っていました。

　Windows上でMySQLが稼働しているサーバはWindowsのバイナリファイル（k.exe）を実行されて、ボットとして動作してしまいました。そのあとも何度もMySQLには侵入されたのですが、侵入先のOSによらず、毎回Windowsのバイナリファイルの実行を試みています。

Oracle、PostgreSQLへの攻撃

　Oracleへの攻撃はSQL ServerやMySQLに比較すると非常に少なく、データベースへ接続が行われたのですが、パスワード認証を突破するまでには至りませんでした。攻撃者の辞書ファイルが未熟なのでしょうか。ここでは面白いデータを得ることはできませんでした。

　なお、Oracleへ攻撃するツールを確認していますが、攻撃数が少ないのはOracleが攻撃者にとっておいしい市場ではないのかもしれません。

　また、PostgreSQLはデータベースへの接続すらなく、攻撃の対象外と認識されているようです。PostgreSQLが使われている確率が低いのか、PostgreSQLユーザーの意識が高いと思われているのかは不明ですが、PostgreSQL用の攻撃ツールを誰も作っていないというのが本命ではないかと思っています。

　今回はデータベースの管理用ポートに対する攻撃を取り上げました。このような攻撃はデータベースへ接続できるIPアドレスが制限されてさえいれば、まったく心配する必要はありません。しかし「普通ありえないよね」という攻撃がJSOCで観測されていることも事実ですので、念のためデータベースのアクセス制御について確認ください。

　普通と違うといえば、先日「普通とは違う」ことを目指した友人の結婚式に参加しました。「席次表とメニューはテーブルのデジタルフォトフレームで」「新郎のプレゼンテーションから開始」「最後に参加者全員がメインテーブルで記念撮影」という、いままで見たことも聞いたこともない結婚式でした。それが新郎新婦の狙いだったようで、とても新鮮で楽しい結婚式でした。

　私の誕生日でもある情報セキュリティの日（2月2日）に入籍した新郎新婦を祝うために、今日も飲みに行くのでした。