共用サーバにおけるSymlink Attacksによる攻撃とその対策について

先日、大手レンタルサーバ事業者において、ワードプレスを使用したウェブサイトが大量に書き換えられるという事件が発生しました。
これについては、すでに多くのニュースやブログ記事などにおいてご存知の方も多いと思います。
当初はクラックではなく管理画面への不正ログインであるというリリースが出ていたり、グループの会長が「クラックなどではない」と断言されておられたことなどもあり、よくあるブルートフォースアタックであろうと思われていました。
しかし結果としてワードプレスは無実であり、サーバソフトウェアの設定の問題を突いたクラック行為によるものであることが分かりました。
詳細は発表されていませんが、Optionsを設定できなくしたということやFollowSymLinksを無効にしたという発表から、Symlink Attacksと呼ばれる種類のアタックが行われたと断定しても問題ないと思います。
真似する人が出ると困るので、あえて解説は避けていましたが、既に手口などの情報も出始めてしまったので、手口だけでなく対策法まで解説することにしました。この手口によって他ユーザのファイルを閲覧することは犯罪ですので、くれぐれも悪用などされないようにお願いします。

それでは今回のケースを見ていきますが、端的に言うと他ユーザのディレクトリ内にあるwp-config.php（ワードプレスの設定ファイル）へシンボリックリンクを張って、自分のウェブサイトURL経由でその内容を閲覧したというものです。
多くのレンタルサーバ事業者など共有サーバの管理者は、各ユーザのホームディレクトリの権限を 701や705などに設定し、ユーザを全て同一のグループに所属させて、ユーザ間のファイルの読み書きを抑制しています。そのため、ホームディレクトリ配下にある全てのファイルは、FTPやシェル(コマンドライン)経由で、他ユーザに見られたり、書き換えられたりすることはありません。
しかし、Apacheは別です。Apacheのプロセスは、ユーザとは異なるグループ権限で動作しているので、全てのユーザのファイルを見れます。

とはいえ、wp-config.phpにアクセスしても、PHPのコードが実行されるだけで、ファイルの中にあるパスワードなどを見ることはできません。

そのため、攻撃者は自分のディレクトリ内に、wp-config.txtなどPHPと認識されない拡張子のファイル名で、他ユーザのwp-config.phpへのシンボリックリンクを張り、自分のウェブサイト経由でアクセスすれば、テキストファイルとして他ユーザのwp-config.phpの中身をテキストとして閲覧することが可能になります。

対策としては、chrootやjailを使ってパス空間を分離したり、仮想化して完全に別々のインスタンスにしたりというものもありますが、今回の問題に対するもっともスマートな解決法は、他ユーザのファイルへのシンボリックリンクを無効化するというものです。
以下のような設定を行うことにより、シンボリックリンクをたどる際にはリンク元とリンク先のユーザ権限が一致しているかどうかを確認するようになります。

既に指定しているOptionsを生かすのであれば、以下のように設定しても構いません。

なお、ユーザが.htaccessにおいてOptionsを自由に設定できないように、AllowOverrideにおいて制限する必要があります。以下のように、AllではなくOptionsを除いた項目を列挙します。

この設定をしないと、.htaccessのOptionsにおいて +FollowSymLinks -SymLinksIfOwnerMatch という設定を入れられた場合に、異なるユーザ間でのシンボリックリンクが有効化されてしまいます。
さくらのレンタルサーバにおいては上記のような設定をしており、今回のケースにおけるクラック行為は成立しないわけですが、ユーザが.htaccessにおいてOptionsを設定すると 500 Internal Server Errorとなってしまうため、提供にあたってFAQを用意するなど、サポート面での対応策が必要なりました。ですので、変更にあたっては、そのサーバのユーザへの対応が必要なことをご留意ください。

ちなみに、Apache 2.2以降であれば、Optionsでユーザが設定できる項目を指定できるようになり、Indexesなどのよく利用されるOptionsの項目に限定してユーザ側に許可することが可能になりました。これにより、Optionsが指定できないことによる弊害も、かなり抑制できます。

さくらのレンタルサーバではApache 1.x系で上記の設定ができなかったため、Optionsの利用を全て不可にしていたのですが、現在サーバを順次アップグレードをしているところであり、いずれはサービスにおいてOptionsを使用できるようにしたいと思っています。

今回の攻撃手法については昔から知られており、多くのレンタルサーバ事業者においては適切な設定がなされていますが、一部に適切でない事例も見られるようです。
レンタルサーバ事業者など不特定多数にサーバをレンタルする管理者の方々においては、Symlink Attacksについて広く知られることとなった現状を勘案し、適切な設定への修正を行って頂きますよう、強く推奨したいと思います。
ちなみに、Symlink Attacksについては以上のとおりですが、suEXECを使っていない環境において、他ユーザのファイルへアクセスできる脆弱性は残っていますので、phpのモジュールモードなど、Apache権限で不特定多数のユーザに自由にスクリプトを実行できる環境を提供しているサーバ管理者の方々も対応をお願いします。
また今回のケースでは、MySQLデータベースサーバがインターネットから自由にアクセスできたこともあり、wp-config.phpの中にあったユーザ名とパスワードで、データベースを直接書き換えられたというのも被害を大きくした理由だったようですので、インターネットへ公開する共用サーバは必要最小限にするということも重要です。

ところで、この騒ぎの中で「共用サーバは危ない」「AWSやさくらのVPSへ移行しよう」という意見を見受けますが、これは多くのケースにおいては間違った対応です。共用サーバを提供する多くの事業者においては、知られた脆弱性に対して迅速に対応されていますし、逆にセキュリティ対策ができない状況でAWSやVPSのような素のサーバを使うことは非常に危険です。しっかりとサーバ管理の出来るケースに限って、AWSやVPSなどを活用すべきだと思います。

最後に、今回のケースでは直接ワードプレスが悪いというより、よく利用されているCMSだからターゲットにされたということがありました。良く利用されているアプリケーションについては狙われやすいということがあるので、ユーザ名やパスワードを他のサイトと異なるものにしたり、複雑なものにしたりと、さまざまな対策をユーザ側でも行うことが重要です。