カテゴリー: Security

銀行のキャッシュカードに有効期限をつけたらどうでしょう?

一般の利用者の安全性確保もできますし、不正口座を無くすにもかなり効果的だと思います。クレジットカードだと損害を補償しなければならないがキャッシュカードだと保障しなくても良い場合が当たり前だったので「キャッシュカードに有効期限をつける」と言う発想は金融機関になかったのだと思います。キャッシュカードにも有効期限をつけた方が良いですね。

結構知られている(?)と思いますが1985年までに作られたキャッシュカードには暗証番号が記録されている物もあるそうです。比較的最近のキャッシュカードでも一部を書き換えするだけで利用できてしまうカードもあるようです。今はこういったカードを持っているATMを利用すると自動的にアップグレードされたりするでしょうか?それとも最低限、キャッシュカードを更新する必要がある旨のメッセージが表示されたりするのでしょうか?

ネット取引用にOTP(One Time Password)を採用している銀行もありますが、ネット取引の安全性を担保するには別デバイスでのトランザクションの認証が一番安全だと思います。随分前、ソフトウェアキーボードがセキュアキーボードと呼ばれていた頃にこのブログに実装案(携帯等で取引を確認後に署名する方法)を書きましたが今のところ似たような方法を採用した銀行は知りません。誰も思いつきそうな方法ですが、もしかして特許の問題などがあるのかも知れませんね。

これならどうでしょう?トランザクション番号を携帯などの別端末から入力して認証を取った取引だけ許可するとか? これなら特許問題が発生するような

詐欺かな – 「出会い系サイトを運営しませんか?」メール

「出会い系サイトを運営しませんか?」とメールが来ていたのですが詐欺っぽいですね。こんなメールでも騙される人はいるのでしょう。「出会い系サイトを利用しませんか?」という内容のSPAMは山ほど来ているのですが「出会い系サイトのサイトを運営しませんか?」というSPAMは初めてです。(来ていたのかも知れませんが気が付いたのは初めて)100%の確証は無いのでメール自体は引用しません。地域別にフランチャイズと言う触れ込みですが”普通”はインターネットサイトを地域別に営業活動するものではありません。個別訪問でもして利用者を集める、ということでしょうか? まずは50万からで自宅サーバでもレンタルサーバでもOKだそうです。はっきり言って詐欺でしょう。

# 100%詐欺でも無くてもSPAMメールの送信、検索エンジンSPAM
# に利用され、そして全く利益にならないのが落ちでしょう。

既に他で詐欺であろうことは指摘されていると思いますが、少しでも騙される人が減る事に役立てば良いのですが…

ちなみにこれは日本語のメールです。きちんと日本人が書いたと思われる文章でした。英語のSPAMにはこの手のネットビジネス物の詐欺と思われる物はかなり多いのですが日本語では初めて見ました。

これからのプログラムの作り方 – 文字エンコーディング検証は必須

最近PostgreSQL、MySQL両方にSJISエンコーディングを利用している際のエスケープ方法の問題を修正がリリースされています。この件は単純に「データベースシステムにセキュリティ上の脆弱性があった」と言う問題ではなく「アプリケーションの作り方を変える必要性」を提起した問題です。

参考:セキュアなアプリケーションのアーキテクチャ – sandbox化

もっと読む

trackbackもDNS逆引きなしホストから拒否します

海外からのコメント/トラックバックspam対策としてコメントだけはDNS逆引きなしのホストを拒否(というか登録したように見えても実際には反映しない)していたのですが、最近は一度に数百のトラックバックスパムを送ってくるSEO/SEM業者がいます。

コメントスパムに比べるとトラックバックURLを知った上でスパムを送信する必要があるのでコメントスパムに比べてトラックバックスパムの方が若干手間がかかるのですが、スパム業者もそれくらいの手間は惜しまなくなったようです。

DNS逆引きなしのホストからはトラックバックは受け付けないようにソースを修正しました。普通のまっとうなISPの場合、必ず逆引きは設定されているので普通のユーザは困ることはありません。(少なくとも日本は)逆引きくらいは簡単に設定できるのであまり意味が無いように思えますが、実際にSpamを送信してくるホストに逆引きが設定されていないケースが多いので多少は役に立つはずです。

# 三浦さんのspamパッチを試さないと…

ところでspamメールでは結構おなじみのドメイン名を使ったSpam効果測定を行っていると思われるspamが連続して送信されていました。例えば以下のドメインです。

4109.mejsef.info

(サーバはオーストリア、ドメイン所有者はポーランド、ネットワークアドレスが26ビットなので大口の一般ユーザ(?)のように思えますが逆引きはISPが設定した(?)ままの状態のようです)

4109がなんらかのIDと思われます。サイト識別IDにしては4109は短すぎるのでキャンペーン番号のようなID番号なのでしょう。いちいちDNSに登録するのが面倒では?と思われるかも知れませんが、ずっと前のspamメールのエントリにも書いたようにドメインをIDとして利用するのは、ワイルドカードをサポートしたDNSなら非常に簡単です。ほとんど手間もかかりません。DJBDNS、Apache 仮想ホスト、サーバサイドスクリプト少々、なんらかのデータベースシステム等があれば簡単に汎用的な仕組みが出来てしまいます。

RFC原理主義者ではないですが… 迷惑な迷惑メール対策に反対!

RFCの位置づけも、絶対的に崇め奉る技術者がいたり、そもそも読んでない(あることを知らない)なんて技術者がいたりとまちまちだが、相互接続に影響する部分は準拠しておいてほしいと思う。携帯各社のメールアドレス仕様でユーザより「PCのメールからメール送受信ができない!」とクレームを受けたことのあるタレコミ人としては、ユーザに対しきっちり警告も行わないままで、相互接続に問題がある形式を採用するのは迷惑なだけ、と思うのだが、みなさんはいかが?そもそも、メールの相互接続は保障していない!って?”

DoCoMoもAUも何を考えているのだろう?
想像力が不足しているように思えます。不正なメールアドレスを使って他のドメイン/サーバからの迷惑メールを防ぎたいなら、自分のドメインからのみ受信できる状態をデフォルトにすれば良いだけでは?

このような迷惑な仕様によって発生するサポートコストは「DoCoMoとAUに請求したいくらいだ」と思っている人も多いと思います。

時間があるAUユーザは是非自分のメールアドレスを非RFC対応メールアドレスに変更してAUサポートに電話をお薦めしたいくらいです。

ユーザ:「PCからのメールが届きません!」
サポート:「メールアドレスに一部に一般的に使えない文字が含まれているからです」
ユーザ:「使ってよいとしたのはそちらなので使えるようにして下さい。機械の事はよくわからないので受信できるようにしてもらいたいのです」
サポート:「連続した.(ドット)や@直前に.は使わないでください」
ユーザ:「もうこのアドレスにしたよ、って友人送っちゃいました。アドレス変えて送り直すってことですか?」
… 以下延々と …

と言ったサポートコールが山のようにあれば改めるかな?一端広げた仕様を狭めるのは非常に難しいので出来るだけ早く修正されることを期待したいです。

文字コードといい、いい加減なのは技術者でなくて、技術をよくわかっていない上司の鶴の一声だったりするのかも知れません….

それともユーザから「どうしてこの文字はアドレスに使えないのか?」といった問い合わせが多いのかな? 「DoCoMoでは使えるよ!」とか?

ところでこの投稿のリンク先に書いてあったAU, DoCoMoの迷惑メール対策も「いかがなものか」と思います。

半角英数字と「- (ハイフン)」「. (ピリオド/ドット)」「_ (アンダーバー)」などの記号を組み合わせた長いアドレスが、迷惑メールの防止に効果的です。

http://www.au.kddi.com/notice/meiwaku/email/mail_address/

メールアドレスの文字数別に迷惑メール受信率を調査したところ、文字数が多いほど迷惑メールを受信してしまう率が低いという結果が出ています

http://www.nttdocomo.co.jp/info/spam_mail/measure/change_add/

AU, DoCoMoは「長いメールアドレスが迷惑メール防止に効果的だ」としていますが、長いメールアドレスが迷惑メール防止に役立つとは思えません。単純に迷惑メールに辟易したユーザが長い別の新しいメールアドレスを取得しただけだと思います。

当り前ですが迷惑メール業者はメールアドレスをデータベース化し、そのデータを元に送信しているはずです。データベースに登録されるか?されないか?はメールアドレスの長さや使っている文字に関係しません。(迷惑メールを送る業者がわざわざメールアドレスがRFC準拠かチェックしているとは思えない)長いメールアドレスが迷惑メール防止に役に立つ、と言う技術的根拠を示してほしいものです。(統計的に役に立っている、という議論は無意味)

私は携帯、PHSメールアドレスを送信にはほとんど使わない&Webサイトに登録しないので迷惑メールは全くきません。@前のユーザ名部分もいつも使っている”yohgaki”です。しかもこのアドレスはずっと以前から使っています。さらに私が他のメールサービスなどでメールアドレスを設定する場合、yohgakiがユーザ名に使用できれば必ずyohgakiを使っています。yohgakiをユーザ名にすることにより迷惑メールを送信されるリスクは高くなると思われます。にも関わらず迷惑メールは受信していません。メールアドレスのユーザ名部分が分かりづらいから迷惑メールがこないのでは無く、メールアドレスがデータベースに登録されていないから迷惑メールがこないのです。
# ちなみに公開メールアドレスのyohgaki@ohgaki.netに
# は毎日数百通のSPAMメールが世界中から送信されてき
# ます。

統計的に長いメールアドレスを持つユーザが迷惑メールを受信していないのは

SPAMメールに辟易

新しいアドレスの取得を試みる

分かり易いアドレスはほぼ全て使用済み

仕方が無いので分かりづらい長いアドレスを設定する

結果として新しいメールアドレスになる ←ここだけが迷惑メールを防ぐポイント

当然新メールアドレスはSPAM業者のデータベースに登録されていない

当然、SPAM業者からSPAMメールが来ない

と考えるのが妥当と思います。メールアドレスが分かりやすいか、長いかはSPAMメール対策に何の効果ももたらしません。

更に短いメールアドレスを持つユーザは「長い期間」そのメールアドレスを使用していると考えられます。その結果として複数のSPAM業者のデータベースに登録されてしまい、多くのSPAMメールを受信していると思われます。「短いメールアドレスを持つ」事と「SPAMを受け取りやすくなる」事には全く因果関係はありません。実際、@ohgaki.netの1文字メールアドレスには1通もSPAMメールが来たことがありません。

長いメールアドレスが迷惑メール対策に有効と宣伝するのは「嘘をついている」言われても仕方ないと思います。

本当かどうか知らないのですが「マウスでぐるぐるポインタを回しているとPCが速く動作する」と言うバカバカしいと思われる知識(追記:WORDでは処理タイミングの問題で印刷スプール処理が速くなる場合があるそうです。私が聞いたのはEXCELファイルの読み込み中にマウスをぐるぐる回している速く読み込める、と言うものでしたがもしかしてこれも本当だってりします?マウスイベントでスプール処理が速くなるのはWindowsとOfficeの歴史からも納得できるのですがEXCELのファイル読み込みでも同じ現象が確認できるでしょうか?ご存知の方、是非教えてください。)を本気で信じている初心者の方も多いらしいです。「長いメールアドレスが迷惑メール対策に有効」と宣伝するのはこれと変わりありません。
# 一部のアプリケーションでスクロール中にマウスを動かすと
# 速くスクロールするのですが、この仕様が誤解の原因??

とにかく、技術的根拠が全くない迷惑な迷惑メール対策には強く反対です。RFCに違反していると知りつつ大手ネットワークサービスプロバイダがRFC違反するのにも強く反対です。RFCが気に入らないなら、RFCを変えてから変更するか、本気になってRFCの変更を提案する姿勢を見せてほしいものです。

“Path Insecurity” – クッキー/HTTP認証のパスは信頼できるか?

3月1日に”Path Insecurity” と題するテクニカルノートが投稿されていますが、さっき試しに“Path Insecurity”をキーワードにググってみても日本語のページが一つも無いので要旨だけ書いておきます。

「クッキー、HTTP認証のPathは信頼できない」

setTimeoutを使って他のページ開くとPath設定されたクッキー(セッションID)で制御していても効果が無いです。(他のページがXSSに脆弱であればその影響を受けてしまう)URLエンコードを使った単純な攻撃でHTTP認証のPathをごまかせる。

MLではHttpOnly Cookieの攻略など最近これに関連した話題で盛り上がっていました。こちらも面白いので興味のある方はMLのアーカイブを検索してみてはいかがでしょうか。(特に共有サーバを利用されている方)

“Path Insecurity”を投稿した方が書いた別のメールには次のような文面も… IE7では直る?

Note that my %2e%2e “finding” for IE 6.0 of early 2006 was
assigned a CVE number CAN-2003-0513 on July 2003.
I suppose Microsoft didn’t find time to fix this in over 2.5
years.
So, to clarify: while I did think of the %2e%2e all by
myself, it was apparently known to the public (courtesy of
Martin O’Neal from Corsaire) for over 2 years.
And that’s what matters

.

解答:まちがった自動ログイン処理

問題:まちがった自動ログイン処理の解答です。このブログエントリは最近作られたアプリケーションでは「問題」にしたような実装は行われていないはず、と期待していたのですがあっさり期待を破られたのでブログに書きました。このブログの方が詳しく書いていますけが「Webアプリセキュリティ対策入門」にも正しい自動ログイン処理を書いています。

参考:自動ログイン以外に2要素認証も重要です。「今すぐできる、Webサイトへの2要素認証導入」こちらもどうぞ。HMACを利用した安全なAPIキーの送受信も参考にどうぞ。

もっと読む

PHP 5.1.2の脆弱性

A cross-site scripting (XSS) vulnerability in phpinfo (info.c) in PHP
<= 5.1.2 allows remote attackers to inject arbitrary web script or HTML
via long array variables, including (1) a large number of dimensions
or (2) long values, which prevents HTML tags from being removed.
(CVE-2006-0996)

Directory traversal vulnerability in file.c in PHP <= 5.1.2 allows
local users to bypass open_basedir restrictions and allows remote
attackers to create files in arbitrary directories via the tempnam
function. (CVE-2006-1494)

The copy function in file.c in PHP <= 5.1.2 allows local users to
bypass safe mode and read arbitrary files via a source argument
containing a compress.zlib:// URI. (CVE-2006-1608)

Mandriva Linux Security Advisoryによると現行リリースのPHP 5.1.2,4.4.2にも含まれる脆弱性を修正したPHPパッケージをリリースしましたね。重要な修正ではないので「適切」にシステムを構築・管理しているPHPユーザは気にする必要はありません。

phpinfo関数を一般に公開するのは絶対に止めた方が良いです。基本的にphpinfo関数の出力はデバッグ用の情報です。セキュアなシステムではデバッグ情報を一般に公開する事はありません。開発時以外はシステムや言語のエラー情報を出力しないのと同じです。

open_basedirは「フェイルセーフ機能」であるため、これに頼った設計を行うべきではありません。Perlなどでtaintモードを信頼するのと変わりません。

# 言い古されてはいますが、セキュリティ対策は繰り返し言い続ける事が重要ですから。

遂にWinnyの脆弱性もOSVDBに載るようになりました

A remote overflow exists in Winny. Winny fails to perform proper bounds checking of unspecified file transfer port commands resulting in a heap-based buffer overflow. With a specially crafted request, an attacker can cause arbitrary code execution in the context of the user who executed the Winny, resulting in a loss of integrity.

EEyeのアドバイザリが英語なので載ってもおかしくないですがSPAMMERに知られると即刻悪用されそうな気がします。

0DAY Firefox Remote Code Execution and Denial of Service Vulnerability

Firefox 1.5.0.2以下のiframe.contentWindow.focus()に問題がありバッファがオーバーフローするようです。これ件フォローが無いので真偽は??です。

NoScript拡張を使って不用意にJavaScriptが実行されないように注意した方が良いかも知れません。

http://www.noscript.net/whats

IEもObjectタグで騒ぎになっていますね。セミナーでは「WebクライアントとWebサーバアプリは最も危険なアプリです」と言っていますが最近は色々ありすぎですね…

PHPの問題? BugTrackのレポート – Multiple PHP4/PHP5 vulnerabilities

このアドバイザリのメールの日付は何故か「2005/11/13」となっているのですが4/24のメールの様です。結論から言うとこのアドバイザリは通常は「無視してOK」です。

メールではメモリ消費のPoCとして以下のコードを例示しています。

i. wordwrap()
——
<?
$a = str_repeat (“A”,438013);
$b = str_repeat (“B”,951140);
wordwrap ($a,0,$b,0);
?>
——

ii. array_fill()
——
<array_fill (1,123456789,”Infigo-IS”);?>
——

iii. substr_compare()
——
&lt?substr_compare (“A”,”A”,12345678);?%gt;
——

まず1つ目ですが日本語環境でwordwrapを使っているケースは無いでしょう。更にプログラマが長大な分割文字(ラップした時の区切り文字)を指定する事はあり得ません。攻撃される事はまず無いでしょう。とは言っても典型的な整数オーバーフロー問題がある事は確かです。しかし、リスクがMediumとされていますがLowが適切でしょう。

【追記】古いwordwrapには整数オーバーフローがあったため修正されていました。まだ整数オーバーフローがあるのはおかしい、と思いPHP 5.1.2のソースを確認しました。少なくともPHP 5.1.2ではオーバーフローは発生せず整数オーバーフローが発生した場合、エラーが発生するコードになっています。と思っていたら、間違ってCVSのパッチ適用済みPHP5.1.2版のソースを見ていたようです。PHP5.1.2にも整数オーバーフローがあります。PHP 4.4.2も整数オーバーフローの影響を受けます。しかし、既に書いたとおり脆弱性自体の危険性は非常に低いです。同じようなバグが過去にレポートされていて直されていたと思うのですがまだ残っていたようです。

【追記2】substr_compare(“A”,”A”,12345678) ですがメモリ参照の問題でSegfaultします。バグですがこの手の問題は普通DoSとは言いませんね… PHP 5.1.3では修正されます。 “The start position cannot exceed initial string length.”とエラーになります。このエラーメッセージからも分かるように確保しているメモリよりも先のアドレスを参照している為、Segfaultしてしまったバグです。プログラム中に間違えて踏みそうなバグですが、この時点までこんなバグが残っていたのは色々な意味で「どうかな…」と思います。このバグ「クラッシュするよ」とレポートがあれば、PHPソース中で不具合を発生させる箇所が不明でも、バックトレース一発で原因まで特定できる単純なバグです。substr_compareはPHP5からの関数ですがzval(PHP変数のデータ構造体)には文字列(データ)の長さが保存されているのですが、これを使っていなかったのも「どうかな…」と思わされます…

2、3つ目ですがDoSが可能となるとしていますがこれに書いてあるコードでメモリを沢山消費しても仕方ないコードです。(ちょっと乱暴な例えかもしれませんが)C言語で「メモリをGB単位で確保して、確保したメモリにmemsetするとsegfaultする」と言っているような物です。言語とアプリケーションは違います。言語でメモリを大量に消費すると問題になるケースもありますが、これらは問題として取り扱うような動作ではありません。memory_limitの引っかかってしまっても当たり前でしょう。レポートした方はどうすべき、と考えているか聞いてみたいくらいです。

今までにもこの手のレポートはいくつかあったのですが、PHPをプログラミング言語として捉えていない人が多いのは驚かされます… たしか、最近もまた

function foo($arg) {
   foo($arg);
}

で「PHPがクラッシュするからおかしい」とメールがあったと思います。メモリは有限リソースなんですけどね… しかも同じ内容のメールは私が気が付いただけでも複数回見ています… 初心者向けに再帰呼び出し回数に制限を設けてもよいかも知れませんが、再帰呼び出し制限なんて必要なんでしょうか?

私が知らないだけかも知れませんが手続き型のライトウェイト言語(Ruby、Python、Perl、Tclなど)で「関数のコールスタックは1000まで」と言った感じでチェックしている(できる)言語がある??!

【追記】
気になりついでにPHP,Ruby,Python,Perlの動作も調べたので、気になる方はコメントをどうぞ。制限するか? しないか? ポリシーの問題のようですね。Perl,PHPは制限しない。Ruby,Pythonは制限する。で、最も中途半端なのはPHP ;) 詳しくはコメントをどうぞ。

セキュリティの脅威を知る レベル 100 シリーズ

まだ全部見ていませんが

【セキュリティの脅威を知る レベル 100 シリーズ】
皆様からご要望の多かった開発者が考慮すべきセキュリティの問題点を1つ1つを解説した
全10回シリーズのオンラインセミナーの基礎コースで、毎週公開予定です。
開発を行う上でセキュリティの脅威やその対処について基本から学びたい技術者の方々を対象に
セキュリティの脅威の原因と被害また、その対応方法を簡潔にご紹介いたします。
本オンラインセミナーの資料(解説付き)もダウンロードいただけます。

第1回: 開発者のセキュリティ
開発者のセキュリティ対策として、発生したときの問題点や、
セキュリティ確保のプロセスなど基本的な要素を解説いたします。
>> >> http://go.microsoft.com/?linkid=4815647

とメールが来ていました。

開発者のセキュリティ
SQLインジェクション
クロスサイトスクリプティング

の順番でセキュリティ対策を解説していくそうです。

参照にはIE必須、メディアプレイヤーが必用なようです。

Firefox, Thunderbird, SeaMonkyは直ぐにアップグレードが必要

Thunderbirdのアップグレードが出たのでUS-CERTからアドバイザリが出てました。

Firefox: 1.5.0.2
Thunderbird: 1.5.0.2
SeaMonkey: 1.0.1

以外はリモートコード実行の脆弱性があります。重要なのは前にここにも書きましたがMozilla SuiteユーザはSeaMonkeyに移行しなければならないことです。

ついでにFirefoxしか普段使っていない方でIEにFlashをインストールしている方、IEのFlashを削除するかIEのFlashも最新にしなければなりません。
(Mozillaのどこかに書いてあるはず。先月のことだったかな?)

【追記】
Flash Player の更新に関する注意喚起
http://www.mozilla-japan.org/kb/solution/2092

「プロフィールが未設定となっております。」 Yahoo!を語るフィッシング?

備考:かなり古いブログですが公開し忘れしていた分です。

次のようなメールが来ました。一瞬、Yahoo!のメールかと思いました。

From: (profile_page_mail)@yahoo.com <profile_page_mail@yahoo.com>
To: (yohgaki)@ohgaki.net <yohgaki@ohgaki.net>
Subject: プロフィールが未設定となっております。

プロフィールが未設定となっておりますので、プロフィールを作成下さいませ。
すべてが無料となっておりますので、ご自由にご利用出来ます。

↓のURLからプロフィール作成が簡単に行えます。
(http)://www.profile-page.com/?member&mail=yohgaki@ohgaki.net

From:はyhoo.comドメインに偽装しています。
「120% SPAMメールだな」と思いましたがリンク先を確認してみる為にクリック。
やはり出会い系サイトのプロフィールを入力するページが表示されました。一目見てYahooとは関係ないと分かるサイトです。ページには

会員の方々のプライバシーの保護、および個人情報のセキュリティには万全を期しています。
あなたが当会の会員であることをはじめ、あなたの個人情報が外部に漏れることはありませんので、ご安心ください。

と書いてありますが、Phishingメールに載っているようなサイトが信頼できるはずがありません。

このメールはFromアドレスを偽造しているのでSPAMというよりPhishingと言った方が適切と思います。送信元を偽ったメールを送っても罪にはならないかな?

Phishingの危険性はサービス開始当事にあまり認識されていなかったとは言え、Yahoo!メールはgmail.comやhotmail.comの様に一目でフリーメールだと分かるドメイン名の方が良かったですよね。