記事本文
この記事は obsolete です。 Movable Type における CSRF の可能性と各種対処法を参照していただくようお願いします。
何故こんな記事を書くのか
通常、私は自分の力量の範囲で調査・考察し、自分で「理解できた」と判断したもののみを記事として書くというスタンスでサイトを運営しています。
それは
真琴が興味のあることを調査、ないし考察したことについての記録を行うサイトです
と書いている通りで、知ったかぶりをしないように自戒するための意味を持っています。
しかし、今回の記事は緊急を要するものであり、
検索してみた所、記事の少なさから、この問題に対する意識の低さを感じました
と元記事にあることを受け、多くのユーザーが記事を書くことで元記事への関心を示し、問題に対する意識を持っていると表明することに繋がると判断したために、拙いながらも自分の分かる範囲からちょっと背伸びして記事を書くことにしました。
この記事を目にした方で Movable Type ユーザーである方は、貴方なりにこの問題に対する記事を書いてくれませんか ?
この記事を目にした方で Movable Type ユーザーではないけど何がしかのウェブサイトを持っている方は、 SG::Acme : attacking MT 1 および SG::Acme : attacking MT 2 を一読して、良ろしければ貴方のサイトにてこの 2 つの記事を紹介してもらえませんか ?
何故緊急を要するのか
実際の問題の詳細は SG::Acme : attacking MT 1 に書かれているため、ここでは割愛します。 要点のみをまとめると、
MT3のコードも目を通してみたのですが、対策が為されていないようです。
MTに限らずCookieでのセッション管理を行う多くのWeb Applicationにありうる。(MT自体の脆弱性と言うには語弊があることに注意)
urlをクリックした瞬間、何の前触れもなくblogの消去やentryの投稿など、任意の動作が実行されてしまう
-
記事を書いているうちに、対応がなされていたようです。 ただし、まだ油断はできないので、友人のスーパーハカー ( 笑うところ ) たちのテストの結果次第ではまた追記します。 ( はてなダイアリー - はてなダイアリー日記 - はてなダイアリーの不正な自動操作についての脆弱性について )はてなダイアリーにも同じ脆弱性がある
この脆弱性は知人が8月上旬頃(15日?)にはてなへ通報済みですが未だ対応されてません。
更新だけではなく削除や設定変更なども可能
- この脆弱性を突いた攻撃の例 : はてなダイアリー - あんちぽっぷくぷー - はてな脆弱性のテスト ( なお、脆弱性を突いたはてなダイアリーユーザーと、脆弱性を突かれたはてなダイアリーユーザーは知人同士であり、攻撃の例は悪意をもって行われたものではありません )
- 表面化していないだけで、 Cookie を利用してユーザーログインを行っている weblog ツール・ weblog サービスのほぼ全てに同様の脆弱性が存在すると思います。
利便性をあまり損なわず、ある程度確実性も保たれる対策
mt.cgiの名前を変更する
ことです。
以下にその理由を説明します。
Movable Type の管理画面は、 /Install directory/mt.cgi からアクセスする形になります。 そして、当たり前ですが管理画面からは変更できません。 ( この脆弱性がなければ変更する意味もほとんどありませんし。 )
通常では weblog を公開するディレクトリと Movable Type のシステムファイルを置いておくディレクトリ ( Install directory ) は別のものを設定していると思います。 だからといって Install directory は閲覧者には知る術がないのかというと、そんなことはありません。 全くテンプレートをカスタマイズしていない Movable Type 2.661 を例にとってみても、以下のような手段が考えられます。
- コメント投稿フォームから探す
-
Main Index や Monthly Archive の、各記事のコメントというアンカーに、 /Install directory/mt-comments.cgi?entry_id=id という URI が示されています。
また、 Indiviaual Entry Archive にはコメント投稿フォームが配置されていますので、その form 要素の action 属性を見れば /Install directory/mt-comments.cgi という URI を知ることができます。
- トラックバックから探す
-
各記事のトラックバックというアンカーに、 /Install directory/mt-tb.cgi?entry_id=id という URI が示されています。
また、 Indiviaual Entry Archive の head 要素には <$MTEntryTrackbackData$> として /Install directory/mt-tb.cgi という URI が示されています。
- 検索フォームから探す
-
Movable Type 内の検索フォームの、 form 要素の action 属性を見れば /Install directory/mt-search.cgi という URI を知ることができます。
このように、簡単に Install directory を知ることができますので、 Install directory/mt.cgi にアクセスすれば、そのサイトの Movable Type の管理画面が表示されるはずです。
もちろんこれだけでは、 ID/PASS を入力しない限りは実際の編集は行えないはずです。
しかし、 SG::Acme : attacking MT 1 で説明されている通り、
ターゲットのMTの環境に関する僅かな情報があれば、Cookie認証を済ませたユーザーに任意の操作を行うmt.cgiへのクエリを含んだurlを踏ませることで、確認なく
記事の投稿や weblog 自体の消去を行わせることができます。
ここで述べられている
ターゲットのMTの環境に関する僅かな情報
というのは、 Install directory のパスと、編集画面の CGI のファイル名が mt.cgi であるか否かという 2 点だけです。
Install directory のパスは前述の通り容易に知ることができます。
そして、 mt.cgi であるか否かは、実際に /Install directory/mt.cgi にアクセスしてみれば判断できます。
この 2 点さえ分かってしまえば、あとは Movable Type のユーザーにトラップを仕掛けた URI をクリックさせてしまえば攻撃はほぼ成功するということです。
この書き方だと、攻撃は特定のターゲットに対して行われるのかと捉えられるかもしれませんが、そんなことはありません。
たとえばMTを攻撃の的としたいなら
- http://ping.bloggers.jp/ などのping鯖で公開されているrdfをごそっと取得
- そのなかからMTで生成されたものを選別
- 悪意のあるスクリプトがあるURLを、上で選別されたMTサイトに自動でトラックバックする
- 管理者が管理画面からそのURLを踏む or (管理画面じゃなくってサイトから)普通にクリック
- refererのURLからmt.cgiの場所を推測
- javascriptやmeta refreshなどで自動でPOSTやGETを送信させる
- 記事が全削除される
- (゜д゜)クマー
上記の方法をスクリプトなどで実行することにより、数十人はひっかかって全記事削除されると思います。
こういった、多数のターゲットに対する攻撃方法の予測もなされています。
しかし、 mt.cgi のファイル名を本人にしか分からないように変更してしまえば、攻撃者は目標を失います。 mt.cgi のファイル名を変更しても、影響を受ける部分はほとんどありませんので、定期的にファイル名の変更を行えば、ファイル名を推測されて攻撃される危険性も激減します。 mt.cgi のファイル名変更対策で見落としやすい穴に気を付けておけば、確実性を高く保ったまま運用を続けることができます。
利便性を度外視するが、確実性の高い対策
Cookie を有効にしないこと、あるいは編集作業を始めたら他のウェブサイトを見ずにそれのみに集中し、編集作業を終えたら直ちにログアウトすることです。
この対策を行えば、編集を行う度に ID/PASS の入力が必要となりますが、そのために悪意ある URI をクリックしたとしてもその攻撃は成功しません。 利便性さえ考えなければ確実な対策と言えますし、 Movable Type のシステム自体には何ら変更を加える必要がないので、素早く対策を取ることができます。 ( ただし、一度でもログアウトを忘れるとその確実性はたちまちゼロになりますが。 )
なお、前述の mt.cgi のファイル名変更対策と組み合わせると、より強固なセキュリティを得ることができます。
普段ブラウジングに使っているブラウザと、更新管理とかに使うブラウザを別にするという方法
を取るのも良いでしょう。
通常のブラウジングに使っているブラウザで編集画面のログインを行わないようにして、編集画面のへのログインはそれ専用のブラウザを使用すれば、毎回ログアウトを行うよりは利便性も保たれます。
mt.cgi のファイル名変更対策で見落としやすい穴
mt.cgi のファイル名変更対策には、落とし穴があります。 ファイル名を変更していたとしても、それを Movable Type のユーザー以外でも知る術が残っていればたちまち確実性はゼロになります。 よって、以下に示すセキュリティホールとなり得る要因の対策も同時に行う必要があります。
- 管理画面のトラックバックを絶対にクリックしない
-
Movable Type の場合、トラックバックを受信すると、管理画面にそのアンカーが表示されます。
「トラックバックが来た !! 」なんて喜んで、不用意にそのアンカーをクリックすると、トラックバック送信者に向けてファイル名変更後の .cgi のファイル名を Referer として教えてしまうことになります。
また、管理画面にトラックバックのアンカーが表示されるということは、すなわち Cookie が有効な状態である場所にアンカーが表示されるということです。 SG::Acme : attacking MT 1 にある通り、
一見無害なurlで
攻撃を仕掛けることができるため、よりユーザーのクリックを誘発しやすくなります。 - /Install directory/search_templates/default.tmpl の修正
-
/Install directory/search_templates/default.tmpl というのは、検索結果を出力する際に使われるテンプレートです。 これは Movable Type の管理画面からは変更できないため、テンプレートをカスタマイズしている人でも見落としがちなテンプレートですが、デフォルトのままだとこの脆弱性に対する大きなセキュリティホールを抱えています。
<MTSearchResults> <MTBlogResultHeader> <h2 class="date">Search Results from <$MTBlogName$></h2> </MTBlogResultHeader> <div class="blogbody"> <h3 class="title"><a href="<$MTEntryPermalink$>"><$MTEntryTitle$></a></h3> <$MTEntryExcerpt$> <$MTEntryEditLink$><br /> <div class="posted">Posted in <$MTBlogName$> on <$MTEntryDate$></div> </div> </MTSearchResults><$MTEntryEditLink$> というのは検索テンプレート専用のテンプレートタグで、その他のテンプレートでは使えません。 よって検索テンプレート同様このテンプレートタグの存在自体を知らない人も多いかもしれません。 これは検索結果ごとにその記事を直接編集できるアンカーを作るもので、 Movable Type ユーザーにとってはなかなか便利なものです。
mt.cgi のファイル名変更対策で mt.cgi のファイル名を変更していた場合、 /Install directory/lib/MT/App/Search.pm を書き換えないと <$MTEntryEditLink$> は正しく機能しません。
sub _hdlr_entry_edit_link { my($ctx, $args) = @_; my $user = $ctx->stash('user') or return ''; my $entry = $ctx->stash('entry') or return $ctx->error(MT->translate( 'You used an [_1] tag outside of the proper context.', '<$MTEntryEditLink$>' )); my $blog_id = $entry->blog_id; my $cfg = MT::ConfigMgr->instance; my $url = $cfg->AdminCGIPath || $cfg->CGIPath; $url .= '/' unless $url =~ m!/$!; require MT::Permission; my $perms = MT::Permission->load({ author_id => $user->id, blog_id => $blog_id }); return '' unless $perms && $perms->can_edit_entry($entry, $user); sprintf q([<a href="%s%s?__mode=view&_type=entry&id=%d&blog_id=%d">Edit</a>]), $url, $ENV{MOD_PERL} ? 'app' : 'mt.cgi', $entry->id, $blog_id; }この mt.cgi の部分も合わせて変更しておかないと、 <$MTEntryEditLink$> で生成されるアンカーは mt.cgi のままです。
しかし、合わせて変更しておくということは、攻撃者が Movable Type 内を検索して、 <$MTEntryEditLink$> で生成されたアンカーを発見してしまう可能性を生じさせるということなのです。 mt.cgi のファイル名変更対策を行う場合は、 /Install directory/search_templates/default.tmpl 内の <$MTEntryEditLink$> の記述自体を削除するようにしてください。
<MTSearchResults> 内に表示されるアンカーは、
ブラウザ側のCookie を読み取り、ログイン済みならば表示させる、という処理
が行われているようですので、 <$MTEntryEditLink$> の記述自体を削除する必要はないかもしれません。なお、 EntryEditLink plugin というプラグインを使えば、検索テンプレート以外でも <$MTEntryEditLink$> を使えるようになりますが、攻撃者に対して mt.cgi の新しいファイル名を自ら教えていることになりますので、この脆弱性に対する対策を取るならば使用しないようにしてください。
どうしても <$MTEntryEditLink$> の機能を使用したい場合は、 brain-dump.com - Frontend Editing for MovableType で配布されている AdminLinks Plugin を使用するようにしてください。
- Edit アンカーの撤去
-
実は、ちょっと発想を変えれば前述の <$MTEntryEditLink$> はプラグインなど使わずとも実現できます。 実際に私は以前のサイトで同じようなことを書いていましたが、ARTIFACT ―人工事実― | MovableTypeの記事修正を楽にするなどで紹介されている方法がこれにあたります。
<a href="<$MTCGIPath$>mt.cgi?__mode=view&_type=entry&id=<$MTEntryID$>&blog_id=<$MTBlogID$>">Edit</a>とテンプレート内に記述することで、プラグインを使わずに <$MTEntryEditLink$> を実現できるのですが、これも攻撃者に対して mt.cgi の新しいファイル名を自ら教えていることになります。前項と同様に、どうしても <$MTEntryEditLink$> の機能を使用したい場合は、 brain-dump.com - Frontend Editing for MovableType で配布されている AdminLinks Plugin を使用するようにしてください。
- スクリーンショットにも注意を
-
Movable Type の手順解説などを書く場合、自分の Movable Type をサンプルとしてスクリーンショットを掲載しているケースはよく見られます。 ( MT hxxks もその一部です。 ) このときに、アドレスバーの URI を隠しておかないと、攻撃者に対して mt.cgi の新しいファイル名を自ら教えていることに繋がってしまいます。
Latest Entry Redirect Template の記事において、スクリーンショットのアドレスバーを処理していたことに気付いた方はおられたでしょうか ? このように、システム外のところにも気をつけておかないと、自らセキュリティホールを作り出してしまいます。
簡単なまとめ
Movable Type をベースに説明してきましたが、これは Movable Type に限った話ではありません。 それぞれがツールの特性を知った上で、自衛する必要があります。
この脆弱性の怖いところは、ユーザーに悟られることなく罠を仕掛けることができ、かつ罠自身は攻撃を仕掛けない、というところです。 サーバをクラックするわけでもなく、ウィルスやバックドアなどを仕込むわけでもありません。 ユーザー自身のブラウザによって改竄が行われるのです。 Phishing 詐欺ならぬ Phishing アタックとでも言えるかもしれません。 クリックしたら最後、 weblog が綺麗さっぱり消去されてしまったということもあるかもしれません。
あまり危機感のみを煽るのもよくありませんが、かと言って根拠なく安心しているわけにもいきません。 多くの人がこの問題に関心を持ち、それぞれ自衛するなりツールやサービスのシステム自身の改善を要望するなりしてくれることを望みます。

