世間で姦しいので、WordPress乗っ取りに関して考えてみた。

あくまでも、個人的に考えただけなので、どこかで発生している何かがこんな流れであるということではありません。

• どこか(以下 A社)のサービスとして、共有サーバーを用いたレンタルサーバーサービスを提供している
• このサーバーサービスでは、Blog設置サービスとしてWordPress(以下WP)やMovableType(以下MT)、メール関係のサービス等が提供されている
  • 標準ではDBを利用するのはWPのみ
• このサービスのレンタルサーバーは「共有サーバー」であり、複数の様々な利用者を収容している
• DataBaseを提供するサービスも提供しており、MySQLをユーザー単位で提供している

1. WordPressは、PHPとMySQLを利用して動作するシステムである
2. WordPressで管理される情報は(一部の実体としてのファイル)を除き、全てMySQL内に記録される
   • つまり、DB内には、過去の投稿などの記録だけで無く、管理者アカウント情報等も含まれている
3. WordPressは、(通常) 1サイト毎に 1DB を使用する
4. DBへの接続には、MySQLの認証ロジックを利用しており、Username/Passwordが必要
5. WordPressは上記認証情報を wp-config.php に登録している
   • この情報は、PHPがMySQLdとセッションを張るために必要な情報であり、暗号化などはされていない
6. 一般にWeb ServerはApache等のWeb Server Application(以下httpd)がそのサービスを提供する
7. 通常、httpdはシステムに脆弱性を作らないようにするため、(一般には)制限された権限で動作する
8. この制限された権限でもWordPressが動作するようにWordPressの本体(PHPスクリプトファイル群)は、注意深く権限設定されていなければならない

1. WordPressサイトへの攻撃は、wp-config.phpを入手できればOK
2. WordPressサイトへの攻撃は、WordPressのDataが記録されているDB(MySQL)に対象サイトのUsername/Passwordでlogin出来ればOK
3. もし、WordPressのDataが記録されているDBのrootパスワードを取得できれば、WordPress以外の全データが奪れるので、なおBetter
4. A社のサービスモデルならば、DBサーバーも複数存在する可能性が高く、もし全てのDBサーバーのrootパスワードが一緒なら、一気に美味しい

1. A社のWPサービスを利用している大多数のユーザー(5000以上)のサイトが書換えられた
2. A社でwp-config.phpのpermission等を再度設定しなおしたが、その後も書換えられるという報告が(少なくとも数件)上がっている
3. WordPressのVersionは関係ない(最新版でも古いものでも同じように発生している)

以下、個人的な推測です。こうだったという証拠はありません

1. 被害が多数にわたっていることから、個別にwp-config.phpが漏れたとは考えにくい
   • 根拠
     • このwp-config.phpが漏れるためには、wp-config.phpに何らかの方法でアクセスできる必要がある。
       1. WordPressからwp-config.phpにアクセスする方はないと思われる(あるのかもしれないが私は知りません)。
       2. WordPress以外のWebサービス経由か、(ftpやssh等で)loginした上で持っていくか、サーバー自体を乗っとられるか位しか、取得する方策はなさそう。(あるのかもしれないが、私は知りません)
       3. Browserやwget/curl等で取得する方策は、httpd側でphp処理を実行して結果を返すだけになると考えられるのでダメ。
       4. WordPress本体、もしくはPHPのBUGの可能性は捨て切れないが、非常に低いと思われる。
     • 従って、これだけの数(5000以上)のwp-config.phpを「個別に」取得したと言うのは考えにくい。
     • あり得るとしたらサーバー丸ごと乗っとられて、一気に全部のwp-config.phpを持っていくというシナリオだろう。
   • 注意：
     • 上記シナリオは、そもそもサーバーが正しく護られているという前提にたっている。
     • 以下のシナリオが成立する場合は、前提がひっくり返るので注意
       1. ftp等で/etc/passwd (shadowやmaster.passwdではない)を持っていくことが可能で、利用者のアカウントが全て取得でき、利用者のwp-config.phpが持っていかれる場合
       2. ApacheでDirectory listingが可能であって、その手法でwp-config.phpが持っていかれる場合
       3. その他、User permissionがボロボロで何でも出来てしまう設定だった場合
2. Webサーバーが乗っとられたのか？というと微妙
   • 根拠
     • もしサーバーが乗っとられたのであれば、WordPress以外のサービスでも書換えなどの攻撃を喰らったのではないかと考えられる。
       1. Blog系は、WPかMTが供給されており、それなりに利用者がいると考えられる。
       2. その他、Mail等も提供されていることを考えれば、WPだけというのは考えにくい
     • また、一般にこの種のサービスは、利用者にDisk容量を供給するが、一人当たり10Gとか20GとかのDiskを供給することが多い。
     • その場合、1台のサーバーに5000以上のユーザーを収容するか？というとそういう可能性は低い。
       • 通常は多くても500〜1000ユーザー程度しか収容しないと思われる。(それでも多い気はしますが)
     • 以上から、被害は恐らくサーバー５台分以上に相当する。
       • それ以上のサーバーがあると考えられるので、その内のWPユーザーがいるものだけを乗っ取ったと言うのは考えにくい。
       • あり得るシナリオは、1台乗っ取ったか、全部乗っ取っただと思うが、被害範囲から後者。
       • やはりWPだけが被害を受けていると言うのは考えにくい。
   • 注意
     1. そもそも攻撃者の意図がA社のWPをいじめることにあるなら、WP以外に目をくれない可能性はある
     2. WPを提供しているサーバーとそうでないサーバーが分離している可能性は否定できない
        • 但し、これはサービス毎に収容サーバーを変えることになるため、やはり考えにくい
          • 契約後サーバー立ち上げまでに利用する全サービスが決り、途中追加はないを仮定せざるを得ない
3. DBが乗っとられたという可能性が高い
   • 上記から、書換え自体はDBに直接行われた可能性が一番疑われる
   • 根拠
     1. 書換えを行った全てのページに対し、管理コンソールから書換えを指示する手法では時間がかかること
     2. 上記手法をscript化出来るなら、DBに対して発行する命令を分析してSQL文にすることは容易であること
     3. 書き換えた場所にもよるが、多くの場合でサイトのタイトルやキャッチフレーズなど、WPに標準で設定する部分が書き換えられていると思われること
   • 注意
     • WebサーバーからmysqlコマンドでDBへのSQL命令を発行する手法が取れる場合、そのWebサーバーにlogin出来ていることを(ほぼ)意味する
       • その場合は実質2のサーバーを乗っとられてるシナリオとかなり近い状況になる。
         • そもそもこの種のサービスでユーザーへのloginを許可する設定になっている可能性は低いと考えられる。
       • 何らかの踏台等を経由して、DBに直接アクセスできる状況を作り、そこからMySQLのroot権限を乗っ取り、一気にDBを書き換えたという可能性が高い
   • 問題点
     • そもそもDBにアクセスできる踏台があるのか？

1. 内部犯
   • 今回の場合、被害がWPに限定されていることを考えると、内部犯は考えにくい。が多少の可能性は残っている
   • 内部犯であるなら、技術問題は恐らく関係ないので、シナリオを割愛する
2. 外部犯
   • そうはいってもWeb Serverから攻撃した場合
     1. A社のWPサービスを買う
     2. DBのアドレスなどを取得する
     3. wp-config.phpを収集する
     4. mysqldに対して認証情報などを使って直接SQL文を突っ込む
   • 何らかのDBへの踏台を見つけた場合
     1. 踏台からMySQLdに対してPassword Crackをかける
     2. MySQLdのroot権限を奪取
     3. 個別の認証情報など使わずに、一気に全員書き換える
   • MySQLがInternetからDirectにアクセスできてしまっている場合
     1. どこからかMySQLdに対してPassword Crackをかける
     2. MySQLdのroot権限を奪取
     3. 個別の認証情報など使わずに、一気に全員書き換える
     • このシナリオの場合には、wp-config.phpで集めた認証情報を使う手も利用できるので、かなりカオスです。

以上の考察が正しいとするなら、このような問題が発生した場合、恐らくWordPressの脆弱性とかを疑うよりもサービス及び運用を疑う方が正しいと考えられます。

これは、今回の事案例が「多数の利用者」が「一気に」コンテンツを書換えられたという事例だからで、通常は運用しているWordPressの脆弱性や外部からの攻撃であることが多いでしょう。

ちなみに、世の中にDBが直接公開されている事例と言うのは こんなの がやはりあるんですね。怖いですね。

あと、某所の事例では、こんな原因の推測もある模様です。

更に追記。こんな情報を見つけました。事実なら、こんな難しい事しなくても行けたということで、衝撃です。つか、さすがにこれが原因なら酷すぎる。元の設定が…