この記事は 「Movable Type Advent Calendar 2021」 1日目の記事です。
Advent Calendar の初っぱなの記事で脆弱性の話をするのもあれかなと思ったんですが、現時点でもかなり影響が続いていそうなのと、注意喚起にはよい機会ということで書きます。
今月 （11月） の 15 日以降から、この記事を書いている時点までの 2 週間程度の間に、私 （というか、私の会社の方） 宛てに、本脆弱性を悪用したと思われる攻撃によって Web サイトが閲覧できなくなったので助けて欲しいという問い合わせが数件程寄せられました。
弊社でサーバや Movable Type をはじめとする CMS などの保守・管理をご契約頂いている場合は、当たり前ですがこういう脆弱性情報を認知した時点で即座にお客様にお知らせして必要な対策をとるわけですけども、今回お問い合わせいただいたのはそういう関係のない会社さんばかり。
最初にこの件で連絡が来たときは、まぁそんだけ古い Movable Type を放置してればそうなりますよねとか思いつつ、呑気に復旧作業の見積もり作ったりしてたんですけども、その日のうちにさらに 2 件、翌日、翌々日にさらに 1 件ずつみたいな感じで立て続けに同様の問い合わせがきたので、こりゃやばいんじゃね？ とちょっと真顔になる事態に。
で、つい先日まで実際に複数の会社さんの Web サイト復旧や Movable Type のアップデート作業なんかをお手伝いした経緯があるのですが、注意喚起も兼ねて、実際の攻撃はこんな感じでしたよというのを書ける範囲でメモしておこうと思います。
脆弱性の概要
- 本脆弱性は 2021 年 10 月 20 日に公開された （CVSS v3 による深刻度は 「基本値 ： 9.8 （緊急）」）
- Movable Type の XMLRPC API には、OS コマンドインジェクション （CWE-78） の脆弱性が存在した
- Movable Type の XMLRPC API に細工したメッセージを
Postメソッドで送信することで、第三者によって、任意の OS コマンドを実行される可能性があった - 影響を受けるのはすでにサポート終了をしたバージョンを含む、Movable Type 4.0 以降、Movable Type 7 r.5002 以前のすべてのバージョン
- 関連製品として PowerCMS 5.19 / 4.49 / 3.295 を含む以前のバージョンも本脆弱性の影響を受ける
開発元からの本脆弱性に対するアップデート情報
- [重要] Movable Type 7 r.5003 / Movable Type 6.8.3 / Movable Type Premium 1.47 の提供を開始（セキュリティアップデート） - Movable Type
- PowerCMS の XMLRPC API における OS コマンド・インジェクションへの対応 - PowerCMS
2021 年 12 月 16 日に追加修正を行ったバージョンがリリースされています。
関連情報
- 更新：「Movable Type」の XMLRPC API における OS コマンド・インジェクションの脆弱性について（JVN#41119755）- IPA 独立行政法人 情報処理推進機構
- JVNDB-2021-000093 - JVN iPedia - 脆弱性対策情報データベース
まぁなんていいますか、ひと言でいえば 「やべぇ脆弱性」 です。
実際の攻撃に関する共通点
さすがに具体的な攻撃内容は書けないんですけども、サーバのログやサーバ内に不正に設置されたファイルの内容、攻撃が発覚したきっかけみたいなものはほぼすべてのケースで同じでした。
.htaccess ファイルの設置・置き換え
まず、問題が発覚した （要するになんか Web サイトがおかしいぞって気がつくきっかけですね） のは、すべてのケースで 「Web サイトにアクセスすると HTTP 403 や 404 が帰ってきて何も表示されません」 というものでした。原因はサーバのドキュメントルートに攻撃者によって設置、もしくは置き換えられた .htaccess ファイルによるものです。
.htaccess の内容は実はなんてことはない、WordPress がデフォルトで設置する .htaccess と同じものです。
# BEGIN
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . index.php [L]
</IfModule>
# END
ドキュメントルート直下で、ファイル名の指定がないアクセス （要するに example.com/ に対するアクセス） を、すべて index.php にリダイレクトするおなじみのやつですが、この .htaccess のせいで、ルートディレクトリに index.php が存在しなかった場合、HTTP 403 などが帰っていたと。
逆にいえば index.php がサーバに存在する場合 （元々トップページのファイル名が index.php だった場合など）、Web サイト自体は問題なく表示されてしまっていたということで、気がつかないままというケースも考えられそうです。
これ、目的がなんなのか考えてみたんですけども、よくわからんですね。攻撃対象サイトが WordPress を使っている前提で、ベーシック認証用の記述とか、.htaccess に書き足された記述をデフォルトの内容による上書きによって消したかったとか？
Movable Type でスタティックに Web ページを書き出していた場合、拡張子は index.html なことが大半ですから、この .htaccess の書き換えっていう攻撃者の余計なひと手間のおかげで、今回私が対応したケースのようにトップページが表示されなくなってあまり詳しくない人でも即座におかしいと気がつくという、ある意味ラッキーな形で攻撃が早期発覚したともいえます。
mt-xmlrpc.cgi に対するアクセスログ
mt-xmlrpc.cgi に対する Post メソッドによるアクセス試行に関しては、下記のような感じでログが残っていました （一部伏せ字）。
***.***.***.*** - - [dd/mm/yyyy:06:23:30 +0900] "POST /mt/mt-xmlrpc.cgi HTTP/1.1" 301 243 "example.com" "Mozilla/5.0 (Linux; Android 11; RMX2195 Build/RKQ1.201217.002; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/94.0.4606.85 Mobile Safari/537.36" ***.***.***.*** - - [dd/mm/yyyy:06:23:31 +0900] "POST /cgi-bin/mt/mt-xmlrpc.cgi HTTP/1.1" 404 65 "example.com" "Mozilla/5.0 (Linux; Android 11; RMX2195 Build/RKQ1.201217.002; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/94.0.4606.85 Mobile Safari/537.36"
これを見る限り、/mt/ とか /cgi-bin/mt/ みたいな、「ありがちな」 Movable Type インストールディレクトリを手当たり次第当たっていくという攻撃の仕方をしていますね。
実際に攻撃された会社さんの Movable Type もコメント機能や Movable Type 標準の検索機能などは未使用で、外部に公開されている HTML から Movable Type のインストールディレクトリがわかるような状態にはなっていませんでしたが （ちなみにコメントや検索機能を使うと、HTML に mt-comments.cgi や mt-search.cgi へのパスが記述されるのでインストールディレクトリはわかりやすいです）、この総当たりみたいな攻撃でたまたまインストールディレクトリが当てられちゃったという感じです。
サーバに不正に設置されたファイル
今回の脆弱性を悪用されることでサーバのドキュメントルートを中心に、不正な PHP ファイルが設置されることを確認しています。
概ね、バックドアの設置を目的とした PHP ファイルのようですが、例として私が復旧作業に関わったサーバから検体として取得したファイルとしては下記のようなものがありました。
不正なファイルはほぼすべて難読化されていますので、内容を確認するには少し手間がかかりますが、ひとつの例として可能な範囲で解析したソースコードを下記に （リンク先の UnPHP はオンラインで使える PHP デコーダ）。
なお、ドキュメントルートだけでなく、例えば画像が入っているディレクトリの下の階層の方に同様の PHP ファイルが設置されていた例も私が担当した範囲で観測していますので、ドキュメントルートだけを確認して安心するのは危険ですからやめましょう。
また、不正な PHP ファイルの設置だけでなく、既存ファイルへの書き換え （JavaScript の挿入など） についても疑ってかかった方がよいと思われます。サーバに SSH できるなら ls -cl するなどして攻撃があった時間帯に新規設置されたり更新されたファイル、ディレクトリがないか確認したり、しばらくサーバのログなどを監視して、怪しいログが出ていないかの確認が必要でしょう。
一番確実なのは一度ドキュメントルート以下、およびデータベースをまっさらにして攻撃を受ける前のバックアップデータから復旧することですが、保守・管理が適当なサーバでバックアップがきちんと保存されてることなんてほぼないのでまぁあれです。
ちなみに下記が、不正に設置された PHP ファイルを対象にしたと思われるアクセスログ （一部伏せ字）。
***.***.***.*** - - [dd/mm/yyyy:05:44:50 +0900] "GET /82cbg.php?Fox=eqC9j HTTP/1.1" 301 246 "example.com" "Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36" ***.***.***.*** - - [dd/mm/yyyy:05:44:50 +0900] "POST /82cbg.php?Fox=eqC9j HTTP/1.1" 301 246 "example.com" "Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36" ***.***.***.*** - - [dd/mm/yyyy:05:44:50 +0900] "GET /ldjchjvobm.php?getTools HTTP/1.1" 301 250 "example.com" "Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36" ***.***.***.*** - - [dd/mm/yyyy:05:44:50 +0900] "POST /82cbg.php?Fox=eqC9j HTTP/1.1" 301 250 "example.com" "Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36" ***.***.***.*** - - [dd/mm/yyyy:05:44:50 +0900] "GET /ldjchjvobm.php?getTools HTTP/1.1" 301 254 "example.com" "Mozlila/5.0 (Linux; Android 7.0; SM-G892A Bulid/NRD90M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/60.0.3112.107 Moblie Safari/537.36"
脆弱性への基本的な対策
本脆弱性への対応は、「まずはとにかく Movable Type をアップデートしろ」 で、詳しくは開発元であるシックス・アパート社から出ているアドバイザリーを見ていただくのが早いです。
また、前述したとおり、アクセスログなどから攻撃を受けた痕跡の調査、そしてすでに攻撃を受けている場合はサーバ内に不正な PHP ファイルなどが設置されている可能性が高いですので、サーバ内の不正ファイル調査と排除を早急に行う必要があるでしょう。
加えて、シックス・アパート社が公開しているセキュリティ対策などを参考に、現状の運用状況や設定を今一度見直してみることをお薦めします。
ちなみに、上記のセキュリティ対策には書かれていませんが、前述したとおり、この手の攻撃が、「ありがちな」 Movable Type インストールディレクトリを総当たりして脆弱性のあるプログラムを探すという手順を踏むことを考えると、（コメントやトラックバック、あるいは検索機能など HTML ソースコード上に Movable Type インストールディレクトリへのパスが出てしまう場合を除き） Movable Type のインストールディレクトリ自体を推測されにくい文字列にするというのもひとつの追加的対策になるかもしれません。
管理できないなら自前でホストするのをやめよう
経験上、サーバや Movable Type のような CMS の保守・管理って結構軽視されがちなことが多いんですけども、社内にきちんと保守ができる人や部署があるか、あるいは私 （弊社） などもそうですが、外部の専門的な知識を持った会社などに費用を払って保守・管理をアウトソースするか、どちらかができないのであれば安易に自前でサーバ借りて Movable Type や WordPress を稼働させたりするのはやめた方がよいですよ。
例えば、Movable Type の場合、SaaS として提供されている MovableType.net を利用すれば、サーバや Movable Type の保守・管理のことはほぼ何にも気にすることなく、インストール版 Movable Type と同等以上の機能が利用できます。
会社のコーポレートサイトやセールス部門で何かプロモーション用の Web サイトを運用する、といった程度の要件であれば、SaaS 版で問題なく対応できます。
もし、どうしても公開サーバだけは自前で運用しないといけない事情がある場合は、クラウド版 Movable Type を利用すればよいでしょう。
クラウド版 Movable Type には 「サーバー配信機能」 という便利な機能があって、クラウド版 Movable Type で生成したコンテンツを指定の外部サーバへ配信できます。つまり、Movable Type を Web サイト公開用のサーバとは分離した状態で稼働させつつ、運用が可能ということです。
MovableType.net にしても、クラウド版 Movable Type にしても、自前でホストする場合のように自由にプラグインを導入したり、自前でプラグインを開発して機能拡張したりという部分の自由度が下がるのはデメリットでしょう。
しかし、数万ページ単位の大規模 Web サイトから小規模なコーポレートサイトまで Movable Type や PowerCMS での構築をお手伝いしてきた私の経験上でも、そこまで特殊なカスタマイズが必要なケースというのはほぼなかったので、多分、世の中の Movable Type 利用案件の 90% くらい （適当） は MovableType.net で済む話だと思うんですよね。
なので、特にこれから Web サイトを立ち上げたいとか、フルリニューアルしよう、みたいな方々は、安易に 「無料だから WordPress でよくね？」 とか 「Movable Type は一度ライセンス買っちゃえば利用自体はずっとできるからいいんじゃね？」 みたいな考えで保守・管理もできないのに自前でホストするみたいなことはやらず、一度こういうセキュリティリスクなどのことにも考えを巡らせていただければと思います。それか弊社に有償の保守・管理をご依頼くだ（ゲフン...
関連エントリー
- Next.js と Movable Type Data API を使用して Jamstack な Blog を作ってみる
- Movable Type のテンプレートタグで使用可能な演算関数を使って画像の高さを算出する
【広告】
Movable Type や PowerCMS を利用した Web サイトの新規立ち上げやリニューアルをご検討中の企業様で、これら CMS による構築経験が豊富な受託先をお探しでしたら、ぜひバーンワークス株式会社まで一度ご相談ください。
