Movable Type における CSRF の可能性と各種対処法

この記事の説明およびもくじ

MT をインストールしたら真っ先に行うべきセキュリティ対策という記事を 2004 年 9 月に書きましたが、当時は Movable Type 2.661 の環境を想定して書いたもので情報としては古く、また多くのトラックバックをいただいたおかげで追加情報を得られたということもあり、新たにまとめ直してみようと思いました。

MT をインストールしたら真っ先に行うべきセキュリティ対策を既に読まれた方は、いくつか重複してしまう点もありますが、こちらを単独で読める新しい一記事とするためにもご理解をお願いします。

なお、つい先日に Movable Type Publishing Platform: 【重要】 第三者による不正アクセスを許す危険性の対策についてとして movabletype.jp 上での発表が行われましたが、この記事で説明することと発表の内容は違うものです。 というか、 movabletype.jp 上での発表は第三者による不正アクセスの危険性を述べていますが、必ずしも第三者によるとは限らず、運営側が以下に述べる脆弱性について認識しているかどうかは判断できかねます。

1. 脆弱性の概要
2. 「第三者による不正アクセスを許す危険性の対策について」との違い
3. Movable Type で想定される問題
4. Movable Type に CSRF 脆弱性による攻撃を行うための情報
5. 攻撃者はいかにして情報を入手し、攻撃をするか - 特定少数のターゲットの場合
6. 攻撃者はいかにして情報を入手し、攻撃をするか - 不特定多数のターゲットの場合
7. 防御法 - Cookie を保持しない (1)
8. 防御法 - Cookie を保持しない (2)
9. 防御法 - Cookie を保持しない (3)
10. 防御法 - mt.cgi に制限をかける
11. 防御法 - 削除の確認画面以外からの削除を不可にする
12. 防御法 - mt.cgi の名前を変更する
13. mt.cgi の名前を変更した際の注意点 (1) - 管理画面のトラックバックのリンクアンカーを絶対にクリックしない
14. mt.cgi の名前を変更した際の注意点 (2) - weblog 内に mt.cgi へのリンクアンカーを作成しない
15. mt.cgi の名前を変更した際の注意点 (3) - スクリーンショットに注意
16. mt.cgi の名前を変更した際の注意点 (4) - mt.cfg 自体の保護
17. 定期的なバックアップを行うべき
18. 簡単なまとめ
19. トラックバック送信先一覧

脆弱性の概要

まず、この脆弱性についての名前を紹介します。 クロスサイトリクエストフォージェリ ( Cross Site Request Forgeries ) という用語で、 CSRF という略語が用いられます。 ( この記事でも、以後 CSRF と記述します。 )

CSRF についての解説は用語「CSRF」@鳩丸ぐろっさり (用語集)に詳しいものがありますので参照してください。

CSRF の脆弱性を用いた攻撃の例としては、昨年夏に話題になった Movable Type やはてなダイアリーにおいて記事の削除や予期しない投稿が行われるといったものや、つい先日に発生した mixi におけるはまちちゃんといったものが挙げられます。 ただし、それはあくまで一例であり、 CSRF は XOOPS や Movable Type などで問題になったため、「勝手にコンテンツを削除されてしまう」問題としてとらえられている節があります。 それは間違いではないのですが、実はもっと危険なことができるケースも...... という可能性があることも覚えておいて下さい。

勘違いされる方もおられるようですが、ウィルスやワーム、クラッキングの類とは性質が異なります。 あくまでコマンドの実行はユーザー自身が行うものである点に注意して下さい。

「第三者による不正アクセスを許す危険性の対策について」との違い

Movable Type(ムーバブル・タイプ)の脆弱性により、第三者による不正なアクセスが可能であることが確認されました。 Movable Typeのセッション管理で使われるCookieの値に、ハッシュ化されたユーザーアカウント情報が含まれており、以下の条件を全て満たした場合に、第三者による不正なアクセスが可能になります。

第三者による不正なアクセスが発生する条件：

1. 第三者が、Cookieの値を取得する。
2. 第三者が、Movable Type管理画面CGIスクリプトのパスを取得する。

また、このCookieの値が、Atom APIによるログイン時のパスワードとしても利用されているため、Cookieが第三者に漏洩した場合にAtom API対応のBlogクライアントソフトなどで、自由に記事の投稿や削除などの操作が可能になります。

これはあくまで第三者が Cookie の値を取得して不正アクセスを行う可能性を示唆するもので、 CSRF とは違います。 私が以前 MT をインストールしたら真っ先に行うべきセキュリティ対策で述べた対策を取ることで、 2 つ目の 第三者が、Movable Type管理画面CGIスクリプトのパスを取得する ことの可能性を低くすることができるように見えるので、MT をインストールしたら真っ先に行うべきセキュリティ対策のトラックバックに、今回の件の参考リソースとして取り上げた旨を通知している方も見受けられますが。 Cookie が漏洩するような事態の場合、 mt.cgi のパスを変更することは実際は危険性の軽減にはなりません。

というか、 Cookie の値を取得されてしまえば危険に晒されるというのは Movable Type に限ったことではありません。 Movable Type の脆弱性の件 : NDO::Weblog の ishinao さんのコメントにもあるように、 Cookie が漏洩してしまう脆弱性ではなく Cookie が漏洩してしまうと起こりうる事態についての発表なのです。 この記事の内容と矛盾するかもしれませんが、今回発表された事態に慌てるよりも、それが容易に起こり得ることなのか、それをしっかりと考えることが重要だと私は考えます。

ちなみに、 CSRF による攻撃の場合、極端な話をすれば必ずしも 第三者が、Cookieの値を取得する ことはありません。 攻撃者が罠を張っておき、罠にかかったユーザの Cookie を見るとは限りませんし、罠を張っただけで「罠にかかる様」すら見届けていないことだって考えられます。

Movable Type で想定される問題

• 意図しない記事の投稿
• 意図しない記事の削除
• weblog 自体の消去
• その他、管理画面から行える操作 ( 未確認 )

実際に実験したわけではないので確認はしていませんが、これらのことが行えるようです。 何故こういったことを行うことができるかの理論は SG::Acme : attacking MT 1 に詳しく書かれていますが、 ターゲットのMTの環境に関する僅かな情報があれば、Cookie認証を済ませたユーザーに任意の操作を行うmt.cgiへのクエリを含んだurlを踏ませることで、確認なくその動作を実行 させる攻撃手段が一例として挙げられます。

なお、これは Movable Type だけに存在する脆弱性ではなく、 Cookie を利用してユーザーログインを行っている weblog ツール・ weblog サービスのほぼ全てに同様の脆弱性が存在すると思った方が良いでしょう。 実際にはてなダイアリーではごく小さな範囲ですが、テストによって実行が可能であることが証明されましたし ( 現時点では対策が行われています。 ) 、 mixiでは不特定多数のユーザがこの攻撃にひっかかりました。

Movable Type に CSRF 脆弱性による攻撃を行うための情報

• Movable Type がインストールされたディレクトリ
• 管理画面のファイル名

実際の攻撃手段に用いられる情報はこの 2 つです。 「第三者による不正アクセスを許す危険性の対策について」との違いでも述べていますが、 Cookie の値は必須ではありません。 必須ではないというか、 Cookie の値は消去等のリクエストを行うユーザー ( = その Movable Type のオーナー ) が既に保持しているパターンであるため、わざわざ取得する必要が無いとでも言いましょうか。

通常、 Movable Type をインストールしたディレクトリと、実際に weblog を公開するディレクトリは必ずしも一致しません。 おそらく、それらのディレクトリは別にしているユーザがほとんどでしょう。 では、別にしているからオーナー以外はインストールディレクトリを知る術は無いのか ? 残念ながらそんなことはありません。

コメント投稿フォームから探す

個別エントリーアーカイブにはコメント投稿フォームが配置されていますので、その form 要素の action 属性を見れば /Install directory/mt-comments.cgi という URI を知ることができます。

トラックバックから探す

個別エントリーアーカイブの head 要素には <$MTEntryTrackbackData$> として /Install directory/mt-tb.cgi という URI が示されています。 更に、このエントリーのトラックバックURL: として堂々と記事内に書かれています。

検索フォームから探す

Movable Type 内の検索フォームの、 form 要素の action 属性を見れば /Install directory/mt-search.cgi という URI を知ることができます。

ぱっと思いつくだけでも、これだけ簡単にインストールディレクトリを知ることができます。 そして、管理画面となるファイル名はデフォルトでは mt.cgi です。 もうお分かりでしょう。 上記の方法で取得したインストールディレクトリ下の mt.cgi にブラウザからアクセスしてみて、管理画面へのログイン画面が出れば 2 つの情報の入手は完了です。

更に、 中には「管理用」などとご丁寧に mt.cgi へのアンカーが記述されているブログもあります という状況なのです。 攻撃用の情報は丸裸だと言っても過言ではないでしょう。

攻撃者はいかにして情報を入手し、攻撃をするか - 特定少数のターゲットの場合

1. ターゲットが特定少数の場合、まずターゲットの情報を前項の方法で取得します。
2. 任意の操作を行うmt.cgiへのクエリを含んだurlを作成します。
3. そして、それをターゲットのコメント欄に書き込むか、トラックバック欄に残します。
4. Movable Type のオーナーがログイン状態でそのリンクアンカーを辿ることで攻撃が成立します。

CSRF は、ログイン済みの正規のユーザに「削除」のリクエストを行わせる攻撃です。 たとえば、攻撃者はサイト上に「削除」コマンドのリクエストとなるようなリンクを用意しておきます。 一般のユーザがこのリンクをたどっても何も起きません。 しかし、管理画面にログインしている状態のユーザがリンクをたどると、削除が実行されてしまうことになります。

このように、オーナー以外のユーザーが攻撃者によるリンクアンカーを辿っても実害はありませんし、オーナーであってもリンクアンカーを辿らなければ実害はありません。 しかし、コメント欄やトラックバック欄に残されたリンクアンカーは、オーナーであれば辿ってしまう確率は非常に高いと思います。

攻撃者はいかにして情報を入手し、攻撃をするか - 不特定多数のターゲットの場合

前項の方法だけであれば、攻撃手段としてはあまり効率が良くないのでは ? と思われるかもしれません。 しかし、不特定多数に自動的に攻撃を行う手段も考えられています。

たとえばMTを攻撃の的としたいなら

1. http://ping.bloggers.jp/ などのping鯖で公開されているrdfをごそっと取得
2. そのなかからMTで生成されたものを選別
3. 悪意のあるスクリプトがあるURLを、上で選別されたMTサイトに自動でトラックバックする
4. 管理者が管理画面からそのURLを踏む or (管理画面じゃなくってサイトから)普通にクリック
5. refererのURLからmt.cgiの場所を推測
6. javascriptやmeta refreshなどで自動でPOSTやGETを送信させる
7. 記事が全削除される
8. (゜д゜)クマー

上記の方法をスクリプトなどで実行することにより、数十人はひっかかって全記事削除されると思います。

防御法 - Cookie を保持しない (1)

この防御法で危険性を低くできる攻撃

• Movable Type における CSRF 攻撃
• 第三者による不正アクセス

Movable Type において、一般のユーザーとオーナーの区別は管理画面へのログインを行えるか否かという点で、それは Cookie によって判断されます。 ということは、ログアウトをしていればオーナーであっても Movable Type における CSRF 攻撃は成立しないのです。

よって、管理画面へのログイン中は他のサイトを見ないようにする、作業終了後は必ずログアウトするようにすることで危険性を軽減できます。

防御法 - Cookie を保持しない (2)

この防御法で危険性を低くできる攻撃

• Movable Type における CSRF 攻撃
• 第三者による不正アクセス

ブラウザのクッキー機能をオフにする

一番確実なのはこれかもしれない。 試しにやってみた。 IEなら、「ツール」→「インターネットオプション...」→「プライバシー」と進み、スライダーを最高（全てのCookieをブロック）にすればいい。

しかしこれでは、MTの管理画面で何かする度にIDとパスワードの入力が発生する。 確実だが、かなりうっとうしい。

これは前項と考え方は似ています。 毎回ログアウトするというのはその都度 Cookie を破棄するということですが、こうすることにより最初から Cookie を拒否しておくことができます。

ちなみに Firefox の場合は

1. ツール
2. オプション
3. プライバシー
4. Cookie データの保存
5. 「 Cookie を有効にする」のチェックを外す

という手順になります。

防御法 - Cookie を保持しない (3)

この防御法で危険性を低くできる攻撃

• Movable Type における CSRF 攻撃
• 第三者による不正アクセス

普段ブラウジングに使っているブラウザと、更新管理とかに使うブラウザを別にするという方法。 普段IE系ブラウザを使っている場合は、更新管理はFirefoxを使うようにすれば、管理ツールの認証情報はFirefoxでのみ維持されるんで、IE上で攻撃URLを踏んでも自動認証されたりはしなくなる。

これは以前も紹介しましたが、シンプルかつ便利な方法だと思います。 これだと毎回ログアウトする必要もありません。 ( これは mixi などでも有効な方法でしょう。 )

防御法 - mt.cgi に制限をかける

この防御法で危険性を低くできる攻撃

• Movable Type における CSRF 攻撃
• 第三者による不正アクセス

デフォルトでは mt.cgi のガードは user/pass による認証だけです。 そのために Cookie が漏洩すれば不正アクセスが可能になりますし、 CSRF 攻撃も可能となっています。

そこで、 *mt3::MRU: 【緊急】【その他の対策】 第三者による不正アクセスを許す危険性の対策について (c)yukkie を参考に、 mt.cgi の認証に加えて mt.cgi 自体への認証を施すという防御法があります。 当然ながら、 .htpasswd のパスワードは mt.cgi のパスワードとは別にする必要があります。

防御法 - 削除の確認画面以外からの削除を不可にする

この防御法で危険性を低くできる攻撃

• Movable Type における CSRF 攻撃

ゑBLOG: MTへの修正にて紹介されている方法は、 CSRF によって意図しない削除を防ぐのに有効な方法です。

削除前の確認画面を表示する際に乱数で生成した適当な値をクッキーとPOSTのパラメータの両方に積んでおき、 実際の削除の時には両方が一致したときだけ削除を実行するようにします。 こうすることで削除前の確認画面以外からの削除ができなくなります。

これは、高木浩光＠自宅の日記 - クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法にて 簡潔な対策方法 として紹介されている方法で、 mt.cgi のファイル名変更よりも有効だと思います。

ただし、これは CSRF 攻撃に対して有効な手段ではありますが、 Cookie が漏洩して mt.cgi に不正アクセスされた場合は削除の確認画面にも到達されるため、有効ではありません。

防御法 - mt.cgi の名前を変更する

この防御法で危険性を低くできる攻撃

• Movable Type における CSRF 攻撃

根本的な解決にはなりませんが、 mt.cgi のファイル名を変更することにより、 mt.cgi に対して向けられた攻撃を高い確率で回避できます。 手順としては、

1. mt.cgi のファイル名を変更し、サーバに put します。
2. mt.cgi を削除します。
3. mt.cfg の # AdminScript mt.pl と書いている行のコメントを消して ( 先頭の # と半角スペースを削除 ) 、mt.pl の部分を mt.cgi から変更した後の名前に変更し、サーバに put します。
4. tmpl/cms/header.tmpl を spanstyle::monolog: MovableTypeに脆弱性が発見されましたの記述を元に変更し、サーバに put します。

ただし、この方法は抜け道が多く存在するため、次項以降で述べる対策を同時にとっておかないと、たちまちこの対策は意味をなさなくなります。 ファイル名の変更は手軽に行える対処法ではありますが、完璧なものではないことに注意してください。 なお、 Movable Type 3.11-ja 頃のバージョン以前のものを使用している場合、 lib/MT/App.pm にも修正箇所がある点に注意。

mt.cgi の名前を変更した際の注意点 (1) - 管理画面のトラックバックのリンクアンカーを絶対にクリックしない

mt.cgi のファイル名を変更すれば、少なくとも mt.cgi という名前のファイルに対する攻撃を回避することができますが、変更後のファイル名が漏れてしまっては意味がありません。 漏れる可能性が高いのが、この管理画面に表示されるトラックバックではないでしょうか。

ログイン直後に weblog を選択したら 最新5件のトラックバック が表示されており、送られてきたトラックバックのリンクアンカーが羅列されています。 また、トラックバックの一覧画面にもリンクアンカーが羅列されています。 これを不用意にクリックしてしまうと、悪意あるトラックバックが含まれていた場合に、 mt.cgi から変更した後のファイル名をリファラから知られてしまいます。

また、トラックバックの URI 自体にリダイレクトなどが仕込まれ、 CSRF による攻撃を受けてしまうことも考えられます。 この場合、既に管理画面にログインしている状態ですので、危険度はかなり高くなります。

mt.cgi の名前を変更した際の注意点 (2) - weblog 内に mt.cgi へのリンクアンカーを作成しない

Movable Type に CSRF 脆弱性による攻撃を行うための情報でも引用しましたが、 中には「管理用」などとご丁寧に mt.cgi へのアンカーが記述されているブログもあります というのが現状です。 せっかく mt.cgi のファイル名を変更していても、それを堂々と表に出していては意味がありません。

ARTIFACT ―人工事実― | MovableTypeの記事修正を楽にするで直接記事編集が行えるような手法が紹介されていますが、セキュリティの観点からすると推奨できません。

どうしてもこの手法を取りたいならば、合わせて自分にしか見えない [編集] リンクを作る | alectropeという手法を取り入れるか、または BASIC 認証を施したディレクトリに、編集リンクを表示するような archives.html を配置するようにした方が良いでしょう。

mt.cgi の名前を変更した際の注意点 (3) - スクリーンショットに注意

Movable Type の手順解説などを書く場合、自分の Movable Type をサンプルとしてスクリーンショットを掲載しているケースはよく見られます。 ( hxxk.jp もその一部です。 ) このときに、アドレスバーの URI を隠しておかないと、せっかくの mt.cgi のファイル名変更も意味がありません。

mt.cgi の名前を変更した際の注意点 (4) - mt.cfg の保護

防御法 - mt.cgi の名前を変更するで述べた通り、 mt.cgi のファイル名を変更したら、その名前を mt.cfg に書き込みます。 よって、少なくともブラウザから簡単に読み込めるような状態にしておくよりは、ある程度の保護下に置いた方が良いでしょう。

例えば、パーミッションの値を 400 や 600 などに設定する、 .htaccess でアクセス制限をするなどの方法が考えられます。 .htaccess による制限の場合、 Movable Typeのインストール - mt.cfgの保護にて説明がなされていますが、少々説明不足な面があります。 合わせて Movable Type のマニュアルの記述だと mt.cfg は保護できないをご覧ください。

定期的なバックアップを行うべき

やれ危険性だ防御法だと長々と述べてきましたが、データベースのバックアップを定期的に取る方がよほど効果的かもしれません。

何の対策もしていないのが実際のところ。 今後も対策する予定はない。 理由はいろいろあるが、別にブログが消えたっていいから、というのが大きい。 データベースや生成した記事は、定期的にバックアップしている。

レンタル型の weblog サービスではそうも行かないでしょうが、 Movable Type はサーバにインストールして使う weblog ツールで、データベースを用いることが基本になっています。 例えば MySQL を用いて運用しているのなら、定期的に mysql.dump をバックアップしておくことで、仮に第三者の不正アクセスや CSRF による攻撃を受けても被害を最小限に留めることができます。

仮に記事はおろかテンプレートやコメント、トラックバックも含め全部消されたとしても、 dump から復元するとあっさりと元通りになります。そしてその後でログインパスワードを変更してしまえば、涼しい顔で運営を続けられるはずです。

簡単なまとめ

• Movable Type Publishing Platform: 【重要】 第三者による不正アクセスを許す危険性の対策についてで述べられていることは、 Cookie が漏洩してしまう脆弱性ではなく Cookie が漏洩してしまうと起こりうる事態なのです。
• mt.cgi のファイル名変更に最も行数を割いて述べていますが、完璧な方法ではありません。割とイージーミスで穴はできますし、穴が無かったとしても根本的な対処法ではありません。
• ログアウトをきちんとするとか閲覧環境と更新環境を別にするとかいった方法は Movable Type に限ったことではなく、ユーザーが web アプリケーションを使用する際の心構えだと思います。
• Movable Type の脆弱性を紹介したいわけではありません。 CSRF という言葉の存在を知ってもらいたいのです。
• というか、受け売りだらけで構成している記事なので、間違った認識をしている面が少なからずあると思います。

トラックバック送信一覧

ねこまんだら:MTに脆弱性

Movable Type日本語版の全てのバージョンが対象です と書いていますが、 英語版にも同様の問題が発生します 。

あるまむーん王国：そこら中で不正アクセス

Movable Typeならまだいーと思うのよ、オープンソースだし。 確かに大変な事だが、責任を押し付けちゃイカンと思うのねん。 オープンソースだと責任を取らなくて良いということもありません。 というかそもそも Movable Type はオープンソースじゃありません。

drry+@->Weblog - Movable Type の CSRF による脆弱性が公表

今回シックスアパートが発表したのは、同じような対処法が考えられますが CSRF による脆弱性じゃないと思います。

日々刻々: MTの脆弱性が報告されていました。

MTに関する脆弱性を、それに何の対処も施していないMT上で報告してるって状況はかなり笑えますな。ガード下がりまくり。 movabletype.jp のものは対処が行われているように見受けられます。 トラックバックを受け付けていない weblog でした。

COZY-LiFE - Movable Type、第三者による不正アクセスを許す危険性

blog自体削除されちゃったらもうおしまいだし... DB の dump を定期的に取っていれば、 weblog 自体を削除されてもそこまで大きな問題にはなりません。 もちろん復元の手間は否めませんが。

Movable Typeで第三者の不正アクセスを許可してしまう脆弱性：やじlog本舗

バージョンアップってめんどくさいじゃないですか バージョンアップせずに、シックスアパートが発表した対処を行えば良いのではないでしょうか。

E=Mac^2 Blog: .htaccessによるアクセス制限

<Limit GET> によるメソッドの制限は推奨されません。 http://hxxk.jp/mt/2005/01/21/2250 を参照してください。