2016年6月14日
私はいかにして巨大なセキュリティホールを講義中にたまたま見つけたか
本記事は、原著者の許諾のもとに翻訳・掲載しております。
数週間ほど前にオランダのウィンデスハイム実務専門大学校で客員の講師として講義を行いました。私自身、同学校の卒業生で、恩師たちと連絡を取り続けています。最近、恩師の1人から、多くの学生がITのセキュリティとハッキングについて深く学びたがっているという話があり、客員として講義しないかと招待がありました。喜んで！ 講義を面白くするためにハッキングのデモも行うことにしました。
ハッキングのデモを始めたときに、学生に企業の名前を聞き、続いて私がその企業のセキュリティを検査したら面白そうだと考えました。次の段階で全く驚きの発見をしてしまい、その企業のセキュリティを保護するため、デモの方向性を変えざるを得ませんでした。
ユニリーバをハッキング？
ある学生がオランダでも有名な企業であるユニリーバの名を挙げ、私はこの企業を調べるのが良さそうだと思いました。もちろん法律の範囲内で、です。ユニリーバのサイトのHTTPヘッダを分析し、最後に Shodan を動かしました。
Shodanでユニリーバをサーチ
Shodanはハッカーにとって強力なサーチエンジンです。インターネット内を広くスキャンし、インターネットに接続している全てのデバイスとサービスのデジタルマップを作ります。「uniliver（ユニリーバ）」と入力すると、いくつかの結果が出ました。サーチで出た最初の結果にすぐ注意を引かれました。
見たところ、保護されていないデータベースが莫大なデータを伴ってインターネットにつながっています（13.2GBです！）。その上、全データ中に「Uniriver」という言葉がひょこひょこ出てきているのです。何てことだ！ ハッキングのデモが現実にどこかにつながってしまいました！ 私はこんな情報が出てくるとは予想だにしていませんでした。このデータベースからShodanはいったいどのコンテンツにインデックスを見つけたのでしょうか？
私は details （詳細）ボタンをクリックし、Shodanからさらに情報を得ました。
このMongoDBのデータベースサーバには少なくとも2つ、 unilever と uniliver_test という名前のデータベースが含まれているようでした。これは、本当に危険なことになるかもしれないと思い、ユニリーバをハッキングするデモの中断を決めました。学生に教え過ぎてはなりません。(^_-)
その後： セキュリティホールを伝えるべきか？
あれから2週間経っていますが、あのデータベースをインターネットにつながったまま無防備に放置しておくのは、どうにも適切なこととは思えません。おそらくユニリーバには、全データベースサーバにパスワードが設定されていないという自覚すらないでしょう。私は実際に同社がこのセキュリティホールをふさぐ手助けをすべきです。そこで状況を正確に把握するために詳しい調査を始めました。
データベースへ接続
くだんのデータベースサーバはMongoDBの上で動いており、Shodanで得た発見を実証するにはMongoDBのサーバへ接続できるソフトウェアを手に入れる必要があります。私は今までMongoDBのクライアントをインストールしたことがないので、 'MongoDB client' で検索しました。4番目に出た検索結果から MongoVueという名のクライアントソフト へたどりつき、インストールして開きました。 connect （接続）ボタンを押します。
Shodanで手に入れたIPアドレスを入力します。
それから、 save （保存）ボタンを押します。次の画面では connect （接続）ボタンを押すだけで何が起きるかが見られます。
このサーバの中にある37個のデータベースに無制限に接続できるようです！
まさか！
このセキュリティホールが影響を及ぼしているのはユニリーバ1社だけではないようでした。問題ははるかに大きい！ 問題を解決するにはまさに誰が接続しているかを探し出さなくてはなりません。そこでデータベーステーブルのあたりをクリックしてさらに情報を探しました。データベースにはユーザネームや保護用のパスワードがありませんでした。パブリックなデータベースではないかと推定できます。(^_-)
データベース内に、名前やメールアドレス、さらに個人的なチャットのログを見つけました。どのくらいのデータが漏洩しているか正確には調べませんでした。しかし、この情報は保護せずに放置すべきものでもなく、ネット上にさらしておくべきものでもありません！ データベースサーバには複数のカンファレンスのプレゼンテーションと関係があることが明らかでした。あいにく、最初に見たときにはデータベースの持ち主の手がかりが見つかりませんでした。
注： 上記のスクリーンショットはインストールしたMongoDBバージョン2.6.7のものです。古いバージョンで、 中程度のDOS攻撃を受けるリスク があります。
再びShodanへ
ユニリーバはこの問題で被害を受けたことがほとんどなく、報告を出していません。そこで、Shodanへ戻って、同社の脆弱性のあるサーバについてもっと情報がないか調べました。
MySQLのサーバを概観する
もうひとつのデータベースサーバ（MySQL）がインターネットから誰でもアクセスできるようでした。パスワードが設定されているかどうかはよくわかりません。それでもなお、これはセキュリティ上の悪い見本です。そこにあるのはインターネットを通じて直接アクセスできるデータベースサーバなのです。
MySQLバージョン5.6.21で詳しく見ると、セキュリティ上の数々の脆弱性があることに目が行きました。
ある脆弱性はCVSSの評価で7.5でした！ これが意味するところはセキュリティへのリスクが高く、早急にパッチを当てるべきだということです。MySQLのサーバへの調査を先に進めることはしませんでした。というのも、サーバの持ち主を探していたからです。
付随したサーバのWebサイトへ
問題のデータベースサーバを離れ、（TCPのポート80で外部へ接続した）付随するWebサイトへ行きました。
明らかに、一般の人が（プロキシ）サーバのステータスに関する高度に技術的なデータを手に入れらるようになっています。セキュリティの観点から言えば、こういった機密情報は決して公開されてはなりません。
ドメイン名取得者の情報を検索
ドメイン名の [削除].is-savvy.nl を上記結果の中に見つけ、ドメイン名の取得者の情報を（ whois 経由で）見つけるにはちょうど良い出発点になるだろうと考えました。
上記情報はこれ以上は分かりません。 .nl で終わるドメイン名のさらに詳しい情報はSIDNのサイトへ行ってリクエストしなければ見られないのです。SIDNはドメイン名 .nl の管理を行っています。下記がそこで得た is-savvy.nl の情報です。
たどり着きました！ 取得者はSavvy Congressです。
Savvy Congress Webサイトにアクセスする
そこで Savvy CongressのWebサイトにアクセスしてみました。開発されたソフトウェアは講演会で使うものとわかりました。以下が聴衆とチャットする例です。
なるほど合理的です。チャットログと講演会へのポインタがあったので、使用されているデータベースサーバがMongoDBであるとかなりの確信を持ちました。
より脆弱なデータベースのShodanを調べてみる
Savvy Congressがより脆弱なMongoDBを使用しているかどうか興味があったので、 Shodanで savvy を調べてみました。その結果から、以下の情報を取り出してみました。
| IPアドレス | データ量 | データベース |
| x.x.238.161 | 13.1 GB | 36 |
| x.x.238.162 | 11.1 GB | 33 |
| x.x.238.163 | 23.1 GB | 35 |
| x.x.238.164 | 13.1 GB | 36 |
| x.x.238.165 | 13.2 GB | 37 |
| x.x.238.166 | 13.2 GB | 37 |
| x.x.238.167 | 13.1 GB | 36 |
| x.x.238.168 | 13.1 GB | 36 |
| x.x.238.169 | 13.1 GB | 36 |
| x.x.238.170 | 13.1 GB | 36 |
| x.x.238.171 | 11.1 GB | 33 |
| x.x.148.216 | 9.8 MB | 2 |
| x.x.43.136 | 6.6 GB | 10 |
13個のデータベース（トータルで156.6GB）の全てにパスワードが設定されておらず、自由にアクセスすることができました。そのうち11個のデータベースのIPアドレス範囲は同じIPレンジ（ x.x.238.* )で、 隣り合って連なったIPアドレスでした。
Nmapを始動させる
Shodanがインターネット上のインデックスサービスにおいて拡張性があるかが分からなかったため、 Nmap経由で簡単なポートスキャンを行いました。11個の脆弱なデータベースサーバを含んだIPレンジ内で、さらにMongoDBサーバを見つけられるか調べるためです。
幸いにもそれ以上のサーバは見当たらなかったので、SHodanはインデックスサービスとしては、いい仕事をしているのかもしれません(^_^)
Savvy Congressにコンタクトしてみる
どのデータベースサーバが守られていないのかと、セキュリティにどんな影響があるかが分かりました。集めた情報を伝えるために取得者にコンタクトすべきときです。2016年4月15日、 Savvy Congressへ2回電話をしてみましたが、どちらも受け付けで“はじかれて”しまいました。そこで調べた結果をメールしてみました。次の日、とても感じのいい返事をもらえました。そこには使用しているサーバは実は公開されていて、古い開発クラスタの一部であるとのことでした。それから私の信頼にたる調査結果に対する彼らの感謝の意を示した洒落の利いたTシャツを送ってくれたのです。
注釈：SAVVYをハックしたけれど、成果はこのTシャツだけ
脆弱なサーバが本当に開発機だということなら、私が見た本物のデータはおそらく開発用データベースにコピーされたものでしょう。こういう環境間の移行に手抜かりがあると、大抵の場合、本番環境の安全性が低くなります。
最後になりますが、MongoDBをホストとするラスト2つのIPアドレス( x.x.148.216 と x.x.43.136 )は、 Savvy Congressに属していませんでした。
他の取得者を探す
Droisysに属する x.x.43.136 で6.6GBのデータベースを発見しました。 LinkedInによると 彼らは246人から500人の従業員がいて金融部門を取り仕切っていました。件のデータベースはおそらく業務処理や会計処理に使用していたのでしょう。本当のところは定かではありませんが。 データベースにDroisysの連絡先をいくつか見つけたので、このメールアドレスを利用して、彼らのデータベースがネット上でさらされていることを知らせてみました。残念なことに、まだ彼らから何の返答ももらえていません。エラーメールは返ってきていないので、送信先のメールアドレスはまだ生きているはずです。 Droisysが私のメールを無視したのでしょうか？
最後に
安全面の脆弱性について自身のインターネット基盤をスキャンしていない企業は、どれだけそれらが脆いものかを認識していません。私は自分の仕事で嫌というほど発見したというのに。願わくは、サイバー犯罪が起きる前に、親切なハッカーが、こういった企業のセキュリティ状況に時間と労力をつぎ込んで、その企業のインターネット基盤がいかに脆弱か気づかせてくれますように。
また、もしMongoDBデータベースを使うのであれば、強力なパスワードを用いて、ファイアーウォールの内部で使うのを忘れずに(^_-) ご一読ありがとうございました！
主な出来事の時系列
2016年3月30日 ウィンデスハイムで講義を行う
2016年4月15日 Savvy Congressに脆弱性を通報（連絡）した
2016年4月16日 Savvy Congressが私の調査結果を認める
2016年4月25日 Savvy CongressがMongoDBサーバを使用しているのを確認して、 Droisysにデータベースの脆弱性を知らせる
2016年5月13日 この記事をアップする
この記事に関連するサイト
1. NOS.nl
