MT をインストールしたら真っ先に行うべきセキュリティ対策

http://hxxk.jp/2004/09/13/2105

記事データ

投稿者

望月真琴

投稿日時

2004-09-13T21:05+09:00

タグ
概要

この記事は obsolete です。 Movable Type における CSRF の可能性と各種対処法 ( http://hxxk.jp/2005/05/13/2105 ) を参照していただくようお願いします。

リプライ

20 件のリプライがあります。

記事本文

この記事は 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を攻撃の的としたいなら

  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. (゜д゜)クマー

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

こういった、多数のターゲットに対する攻撃方法の予測もなされています。

しかし、 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 が綺麗さっぱり消去されてしまったということもあるかもしれません。

あまり危機感のみを煽るのもよくありませんが、かと言って根拠なく安心しているわけにもいきません。 多くの人がこの問題に関心を持ち、それぞれ自衛するなりツールやサービスのシステム自身の改善を要望するなりしてくれることを望みます。

リプライ

20 件のリプライが送られています。

2004-10-25T00:07+09:00 - 自分メモ:mt.cgiのファイル名変更とapp.pmの編集 < Studio-HYG

MTのアップグレードついでに,MT hxxksのMT をインストールしたら真っ先...

2004-10-25T16:44+09:00 - MTのセキュリティ対策

MTをインストールしたら真っ先に行うべきセキュリティ対策に怖いことが書いてあったのでちょっと対策してみました。

2004-10-27T11:43+09:00 - MT をインストールしたら真っ先に行うべきセキュリティ対策 < 日々更新中

MT をインストールしたら真っ先に行うべきセキュリティ対策なる頁発見。ふーん、なるほどなるほど。 うちの頁の場合、index頁に%lt;a href="./mt/mt.cgi" $gt;Login$lt;/a$gt;なんて書いてあってバレバレでした。 そんでmt.cgiを適当にわかりにくい名前に変更。そしてLogi...

2004-10-28T01:23+09:00 - MTのセキュリティ対策 < のまのしわざ

MT3.1 mod_perlでググッたらこんなサイトを見つけました。丁度セキュリティ対策をどうしたらいいのか考えていたところなので、凄く勉強になりました。近いうちになんらかの対策をしなきゃ・・・ MT hxxks - MT をインストールしたら真っ先に行うべきセキュリティ対策MT を...

2004-11-01T23:00+09:00 - MT で CSRF

ちょいと Movable Type の話をしていて yuuさん (w3j.org) に教えていただいたのですが、Movable Type には CSRF攻撃の問題があるみたいですね。「MT をインストールしたら真っ先に行うべきセキュリティ対策 (hxxk.jp) 」 しかし、ちゃんと CSRF という名前があるのに�...

2004-11-02T00:26+09:00 - MT の脆弱性? < ogaoga's blog

MT hxxks - MT をインストールしたら真っ先に行うべきセキュリティ対策 これを見てびっくり。とりあえず、Basic 認証をかけてみたけど、それて対策になるのかなぁ......

2004-11-06T03:47+09:00 - MovableType利用者が真っ先に行うべきセキュリティ対策 < IGALOGる

この内容はもうちょっと広く知られておくべき記事です。MT hxxks - MT ...

2004-11-11T00:03+09:00 - MTのセキュリティ < ●●●ForAmusement●●●

全く別の問題の解決策を探していて見つけたのですが どうやら対策しておくに越したこ...

2004-11-14T01:07+09:00 - ウェブログを削除するリンク < nlog(n)

自分のウェブログを削除するリンクが作れる。そのリンクは、個別記事に置いておくと便利な「編集リンク」と同じような形をしていて、どこにでも置くことができる。「トラックバックをたどって行ってみると、知らないうちに自分で自分のウェブログを削除していた」、そんな...

2004-12-29T16:11+09:00 - CSRF - クロスサイトリクエストフォージェリ < Preview

CSRFの概略  CSRFはCross Site Request Forgeriesの略です。  恥ずかしながら私は最近こういったこういった攻撃方法があることを知りました。日頃のアンテナの低さがバレますね。  CSRFはサイトに対する正規のユ...

2005-01-20T22:47+09:00 - MT/MTでもセキュリティ対策が必要!? < kankichi@blog:SAKURA edition

MTのカスタマイズをしていくうちに、MT hxxks:"MTをインスト...

2005-02-03T15:21+09:00 - MovableTypeセキュリティ問題 < SAKSAK RECORDS WEB SITE

MT hxxks - MT をインストールしたら真っ先に行うべきセキュリティ対策...

2005-02-18T21:19+09:00 - MTへの修正 < ゑBLOG

MT-3.151が出たようなのでアップグレードしようと思ったんですが、その前に現状のMTに入れた修正点をメモしておきます。

2005-02-23T13:44+09:00 - MTをインストールしたら… < S-log : 慎悟のマイナス思考ログ

すごく今更ながらですが、取り急ぎメモ。 MT hxxks - MT をインストールしたら真っ先に行うべきセキュリティ対策 水無月ばけらのえび日記さんの過去日記より。...

2005-04-19T01:11+09:00 - takato

Version 3.151-ja を使っています。 <$MTEntryEditLink$>を使うために /Install directory/lib/MT/App/Search.pmを書き換えようと思っていますが、 該当の文字列が見当たりません。 526行目から同名のサブルーチンがありますが、 バージョンアップにともないSearch.pmが変更に なったようです。 どのように変更したらよいのかご教授いただけると幸いです。

2005-05-02T00:35+09:00 - 真琴

すみません、お返事が遅れました。ご質問のあたりも含めてこの記事は全面改訂しようと思いつつ、ちょうど多忙な時期と重なってしまいました。 さて、ご質問の件ですが、 MT 2.x の Search.pm で mt.cgi と指定している部分は MT 3.x では $cfg->AdminScript となっています。 これは設定ファイル ( mt.cfg ) の AdminScript の値を参照しているので、 mt.cfg の # AdminScript mt.pl と書いている行のコメントを消して ( 先頭の # と半角スペースを削除 ) 、mt.pl の部分を mt.cgi から変更した後の名前に変えれば良いと思います。 ( 私は &#60;$MTEntryEditLink$&#62; を使わないので、実際に試してはいませんが。 )

2005-05-12T20:59+09:00 - セキュリティ情報(Movable Type) < Kyan's BLOG II

Movable Type Publishing Platform: 【重要】 第三者による不正アクセスを許す危険性の対策について ユーザ各位は対応をどうぞ。 当方では Movable Type Technotes: 盗聴によるパスワードやCookieの漏洩...

2005-05-13T01:17+09:00 - Movable Typeの脆弱性 発覚! < 新妻blog(もう新妻じゃないけど)

とうとう出ちゃいましたよ:14: 【重要】 第三者による不正アクセスを許す危険性...

2005-05-13T07:16+09:00 - 【緊急】【その他の対策】 第三者による不正アクセスを許す危険性の対策について < *mt3::MRU

 だいたいのMovableTypeユーザの方ならご存知かと思いますが、致命的なセキュリティホールがあることが確認されました。  パッチが早々に公開されるとは思いますが、それまでの応急処置が公式で発表されています。なお、拙ブログでは公式とはまた違ったアプローチでの応...

2005-05-13T10:37+09:00 - MT3.X日本語版全てに不正アクセスの脆弱性! < fromshun.

MTの管理画面の右はじにこんなアナウンスが。 【重要】 第三者による不正アクセ...

この記事に対するご意見やご質問、ご感想などありましたらこのフォームに簡潔に記入して下さい。 簡潔に記入できない場合や、関連記事にてご意見をお寄せいただく場合は、ご自身の weblog にて記事を書かれた上で あてにトラックバックとして送信してください。

記入フォーム

補足情報

著作、講演、制作実績など