MongoDBハッキングとセキュアなデフォルト設定の重要性

MongoDBをインストールしている場合は、今すぐ安全に設定されているか確認してください。クリスマスの少し前から、公開状態にあるMongoDBのインストール環境が28,000件以上ハッキングされています。攻撃者は盗んだデータを人質に取り、データを取り戻すためにビットコインでの支払いを企業に要求しています。これまでに少なくとも20社が要求に応じ、身代金を支払ったようです。この記事では、ハッキングの手口、自分を守る方法、そしてこの事件から学べることを解説します。

ハッキングの手口

今回のハッキングは、驚くほど単純な手口です。バージョン2.6.0以降では、MongoDBにデフォルトの設定ファイルが含まれており、MongoDBは標準で127.0.0.1にバインドされます。そのため、データベースはローカルからの接続のみを受け付けます。

バージョン2.6.0より前はそうではありませんでした。MongoDBは標準でリモート接続を許可していました。また、標準では認証も不要だったため、バージョン2.6.0より前のMongoDBをそのままインストールすると、認証されていないリモート接続を問題なく受け入れてしまいます。

インストールの設定に時間をかければ、ユーザーはアクセスをローカル接続のみに制限できました。しかし、そのためにはmongodb.confファイルに1行を手動で追加する必要がありました。標準設定ではなかったため、この重要な手順を行っていない既存のインストール環境が数多くありました。

さらに、攻撃対象となりうるMongoDBを見つけるのは簡単です。MongoDBのデフォルトポートは27017です。ZoomEyeなどの検索エンジンを使えば、MongoDBのインストール環境を検索し、公開されているポートを確認できます。これにより、脆弱な環境を約100,000件見つけられます。

この脆弱性自体は目新しいものではありません。この問題は2012年に初めて提起され、2015年ごろに公表されました。また2015年初頭には、John Matherlyが安全でないMongoDBのインストール環境を約30,000件発見したと報告し、話題になりました。つまり、誰もが以前から知っていてもおかしくない問題なのです。

安全でないデフォルト設定の問題

安全でないデフォルト設定は、決して軽視できる問題ではありません。調査を重ねても重ねても、ほとんどの人はシステムが提示するデフォルト設定をそのまま使うことが明らかになっています。デフォルト設定は重要です。

こうした安全でないデフォルト設定は、使いやすさとセキュリティのバランスを取るためのもので、妥当な前提に基づいていると主張する人もいるかもしれません。たとえば、ほとんどの場合、データベースはファイアウォールの内側にインストールされると安全に想定できるなら、データベースをローカル接続にバインドしないことが妥当なデフォルト設定だと判断するかもしれません。

しかし、こうした前提は危険です。誰かがその前提を崩す行動を取ることは、起こるときの問題であって、起こるかどうかの問題ではありません。その結果、攻撃に対して脆弱になり、本人も気づかない可能性があります。こうしたデフォルト設定がもたらす潜在的なセキュリティリスクは、一般に広く知られているとは言えません。あらゆる判断を検証するセキュリティ専門家が社内にいない限り（それが望ましいのは確かですが、必ずいるとは限りません）、安全でないデフォルト設定は見過ごされたままになることが多々あります。

安全でないデフォルト設定を追跡する

安全でないデフォルト設定の問題は、さらに深刻です。

責任ある組織として、Snykのようなツールを使い、ツールや依存関係に脆弱性がないかスキャンしているとしましょう。通常、安全でないデフォルト設定は脆弱性と見なされないため、こうしたツールはこの問題を報告しません。ここで問題となっているのは、コード自体のバグや脆弱性ではなく、設定上の問題だからです。

ある程度は納得できますが、公式な識別子やデータベースを設けて、安全でないデフォルト設定を管理すべきかという疑問は残ります。

一方、安全でないデフォルト設定を報告するサービスを作れば、間違いなくノイズも発生するでしょう。安全でないデフォルト設定は数多くあり、すでに対処済みの組織もあるはずです。そうした組織は、自分たちにもまだ当てはまる問題なのかを判断する必要がありますが、それは必ずしも簡単ではありません。該当しないのであれば、安心して無視し、先に進めます。

しかし、こうした問題をまだ認識していないユーザーにとっては、安全でないデフォルト設定の報告が非常に役立つ可能性があります。報告によって、気づかれず対処されないままになっていたセキュリティリスクに気づけるかもしれません。MongoDBの問題のように、何年も放置されていたリスクもあります。

オープンソースのデータベースで既知の安全でないデフォルト設定にフラグを付ければ（既知の脆弱性にフラグを付けるのと同じように）、今回の攻撃は防げなかったとしても、影響を受けるデータベースを少なくとも一部減らせたかもしれません。

次に何をすべきでしょうか？

まずはMongoDBのインストール環境を安全に設定してください。お待ちしています。

お戻りですね。今回のハッキングが示しているのは、セキュアなデフォルト設定が非常に重要だということです。セキュリティはあまりに重要なので、運任せにしてはいけません。サイトをデフォルトでHTTPS経由にするという考え方が業界で広まりつつあるように、パッケージの作者も、パッケージがデフォルトで安全になるよう最善を尽くすべきです。安全でないデフォルト設定は、既知の脆弱性と同じくらい大きな被害をもたらす可能性があります。開発者が、できるだけ手間をかけずにインストールできる設定をデフォルトにしたいと考えるのは理解できます。しかし、その設定が安全でなければ、MongoDBをめぐって現在起きているような事態につながりかねません。

今回の攻撃が提起するもう一つの問題は、オープンソースのデータベースで安全でないデフォルト設定を追跡すべきかどうかです。Snykでは、こうした欠陥に脆弱性のマークを付けるべきかどうかを繰り返し議論しており、今後も長く議論が続くでしょう。どちらの立場であれ、強い意見があれば、メールまたはTwitterでぜひお聞かせください。それまでの間に、依存関係に予期せぬセキュリティ上の問題がないか確認したい場合は、Snykを使ってリポジトリをすばやくテストしてみてください。