暗証番号入力の拒否が面倒、と言う場合三井住友VISAカードなら、miniカードを利用するのも良いかも知れません。限度額が10万円なのでPCを買う場合などに利用できないですが申し込みました。
miniカードのカード番号は別の番号になるようです。写真からはICチップは付いていない様なので暗証番号入力を求められる事も無いはずです。
# 三井住友VISAの規約にはICチップ付きカードの場合、
# 暗証番号をサインの代わりに入力することもある、と
# 書いてあります。つまりICチップが無ければ、サイン
# でのみ利用可能と言うことですね。
しかしこの小さいカードを使うと店の人が使えるかどうか不安になったりするかも知れませんね ;)
これのつづきです。
世の中は防犯カメラが100%設置されている銀行のATMでさえ暗証番号入力は危ないので生体認証を採り入れようか、という時にも関わらず加盟店のレジでクレジットカードの暗証番号を入力させるという時代錯誤の加盟店が急増中に思えます。
レジで清算する際には真後ろや真横に他人が待っていて暗証番号を見るのは非常に簡単です。レジには防犯カメラが付いている事も多いと思いますが、その映像の管理は銀行等のATMに比べて十分安全に管理されているか?には大きな疑問符が付くと思います。
# 通上、利用規約上は暗証番号の入力を伴う取り引きの全て責任は
# 利用者にある、と書かれているはずです。ただし、判例などでは
# 明らかに不正利用と思われるケースでは暗証番号の入力があって
# も被害が保証される場合もあるようです。
そこで三井住友VISAカード、セゾンMASTERカード、ニコス郵貯VISAカードで暗証番号を拒否しサインで利用することは可能か聞いてみました。3社ともカードの暗証番号入力を拒否してサインで利用できます、と回答がありました。
セゾンにはより詳しく調べて頂き、判っている限りではJRのみどりの窓口以外は暗証番号を入力せずに利用できる、と詳しい回答を頂きました。答えて頂いた方の説明によるとJRのシステムが暗証番号無しで取り引きが出来ないように作られてしまった事が原因のようです。
# これは許される間違い(?)なのかな…
クレジットカード利用時に無意味かつ不必要な電話番号の記入を強要する加盟店でも電話番号を書いたことはほとんどないのですが、こんどは暗証番号入力を拒否する手間が増えるとは…
多分他のカード会社も同じ様に取り引き時の暗証番号入力は拒否できると思われます。クレジットカードの暗証番号記入に不安を覚える方はどんどん暗証番号入力を拒否しましょう。
クレジットカード利用時に不必要な電話番号の記入を強要するカード加盟店は昨年の記入された電話番号を悪用した事例のおかげでやっと無くなりました。カード規約には書名でサービスを利用できると明記されているので私はいつも電話番号記入は拒否していました。電話番号の記入を求める加盟店はまずカードの署名と伝票の署名が一致しているか確認していませでした。海外では署名を確認しない、ということはあり得ないのですが日本では確認しない加盟店の方が今でも多いくらいです。署名を確認されないと私は非常に不満なのですが、署名を確認されると不満に感じる利用者も多い(?)ということかも知れません。
BINDのバグの多さに辟易して2000年にdjbdnsに乗り換えてからBINDを使っていないのですがDNSキャッシュ汚染問題はまだまだ続いているようです。
DNS ‘pharming’ attacks target .com domain で広範囲なDNSキャッシュ汚染攻撃があったとニュースになっています。
SANSのブログによると
1,304 domains poisoned (pulled from the referer entries in the HTTPD logs)
と、1,300以上のDNSキャッシュ汚染(DNS cache poisoning)エントリが見つかったと書いています。
セキュリティに詳しい方には古い問題ですがなかなか改善されていません。私自身も昨年、日本のあるISPにDNS設定の問題を連絡したのですが、知合いのシステム管理者からISPから変更の連絡あったと聞いていないのできっとまだ改善されていないと思います。ISPでさえもこのレベルなので日曜DNS管理者(私もDNS管理を専門としていないので日曜DNS管理者ですが)が設定したDNSサーバに問題があっても当然かもしれません。
これから書く事を理解するためにはDNSサーバとDNSキャッシュを明確に区別する必要があります。example.comドメインを例に説明します。example.comのDNSサーバはexample.comドメインに権限を持ち、www.example.com, ftp,example.com等、example.comのサブドメインにホストを登録できます。一方、DNSキャッシュはDNS問い合わせをクライアントに代わって行うサーバです。DNSキャッシュサーバはトップレベルドメインから目的のホストのIPアドレスを取得するまで再帰的にDNS問い合わせを行い、結果をキャッシュします。ISP等が”DNSサーバ”と呼んでいるのは通上はDNSキャッシュサーバです。BINDでは再帰問い合わせに答えるサーバがDNSキャッシュサーバになります。
DNSサーバを構築する場合、DNSサーバとDNSキャッシュは別サーバとしなければならない、のですがBINDの悪いデザインのためDNSサーバとDNSキャッシュが同じサーバに設定できるようになっています。しかも、古いBINDではデフォルトで全てのクライアントから再帰問い合わせを受け付けるように設定されていました。このため、間違ったDNSサーバ設定方法ドキュメントが大量に再生産／再利用され現在でも間違った設定のDNSサーバが大量に存在します。
example.comドメインでDNSサーバとDNSキャッシュが同じDNSプログラム(BINDなど)で実行されていると、DNSキャッシュが汚染されるとexample.com以下のwww.example.com,ftp.example.comヘのアクセスを別のIPアドレスのサーバに誘導する事が可能です。SSLのサイト証明を使用していないと http://www.example.com/ へアクセスしたユーザは意図しているサイトにアクセスしているか、偽サイトにアクセスしているか全く区別がつきません。
# HTTP Response Splitting Attackでも同じ効果をHTTPキャッシュを汚染し
# 偽サイトを表示させることも出来ますが、DNSキャッシュ汚染に比べると
# DNSキャッシュ汚染の方が強力な攻撃方法です。
DNSが安全でないことはqmailとdjbdnsの作者として有名なDan J. Bernstein氏が詳しく説明しています。
DNSを安全に利用する為には
などの対策が必要です。これらの対策を行ってもDNSサーバとDNSキャッシュを同じサーバプログラムで実行しているサイトでDNSキャッシュ汚染があると偽ホストにアクセスしていても普通は気が付かないでしょう。
The importance of separating DNS caches from DNS serversの中で指摘されているようにBINDのマニュアルでもDNSサーバとDNSキャッシュを必ず別するよう書いてあます。DNSキャッシュとDNSサーバを同じサーバに設定しても構わない場合は、分離されているネットワークシステムの実験環境などでDNSを使えるするようにする、など非常に限定された状況しかありません。本来、DNSサーバプログラムはDNSサーバとDNSキャッシュは別プログラムとして提供されるべき物です。djbdnsではDNSサーバ(tinydns)とDNSキャッシュ(dnscache)プログラムは別プログラムになっており、DNSサーバとDNSキャッシュは別サーバとして動作します。当然ですが最近作られたDNSサーバプログラムはDNSキャッシュとDNSサーバは別サーバととして動作します。
個人的にはsendmailの様に捨てられるサーバプログラムになっても構わないのですが、ISCはいつになったら壊れたBINDのデザインを修正するつもりなのでしょうね?
追記：念のために書いておきますがDNSキャッシュ汚染はdnscacheを使っていても可能です。dnscacheの場合汚染がより難しいだけです。DNSキャッシュ汚染は仕組の問題であるためプログラムでは修正できません。通常、ISP以外の組織がDNSキャッシュを公開する必要はなく、また公開DNSキャッシュを運用するべきではありません。
個人的にはACCSの訴えに合理性を全く感じられなかったのですが、日本のコンピュータセキュリティ上非常に影響が大きい判決が出てしまった様です。
個人的には関連性を見出してしまう発言が政治家からありました。片山元総務大臣はインターネットも放送と同じく公共性を持たせ規制するべき、と言う旨の発言があったようです。
自民党の片山虎之助参院幹事長はフジテレビの番組で、「放送とインターネットは（役割が）似てきた。法的な環境の整備も含めて考える必要がある」と述べ、【インターネットにも放送法のような公共性を求める法規制を整備する必要があるとの認識を示した】（日経）
http://www.janjan.jp/media/0503/0503285040/1.php
一見全く関係ないようですが、ACCS裁判の裁判官と片山幹事長は同じ間違い、国境さえもない完全にボーダーレスなインターネットの世界に無理矢理現在の都合のよい(?)世界観を適用させようとする間違い、をしていると思います。
考え方を変えないと録画サーバサービスの例もあるように色々な問題が発生し、その度に騒ぎになると思います。
野放しがよいとは思いませんが、なんらかの規制を行う場合はその必要性と実効性をよく検討し、既得権益を持つ者の道具にならないような形で規制してもらいたいものです。
最近カーネルrootkitがまた話題になっています。カーネルrootkitへの対処策ソリューションを提供し始めたからの様です。
First Winternals/Sysinternals did their RootkitRevealer
Then Microsoft started fear-mongering
Now F-Secure jumped on the bandwagon with their Blacklight Beta
rootkitとはバックグラウンドで動作してシステムの利用状況を記録したり、バックドアを開けてリモートから管理者権限でシステムを使用できるようにするプログラムの総称です。
全てのrootkitが良くないか、と言うとそうでは無い場合もあります。システム管理者がネットワーク上のコンピュータを管理する為に開発されたrootkitもあり、これらのツールはネットワークシステム管理者にとって非常に便利です。
問題なのはadware、malwareと呼ばれるプログラムにユーザが意図しないrootkitが含まれていたり、ウィルスに含まれていたりする事です。これらのrootkitはSPAMメールの送信に利用されたり、ユーザがどのようなWebページをブラウズしているか記録する為に利用される事がほとんどです。しかし、その気になれば銀行のWebアカウントへログインする為のユーザ名とパスワードを盗む事も簡単です。
通上のrootkitの検出はプロセスの一覧を見ることで簡単に検出できます。ファイルシステム上を検索する事により不審なファイルを捜す事によっても検出できます。しかし、カーネルレベルrootkitの検出は簡単ではありません。カーネルレベルrootkitは文字どおりカーネルレベルで動作しプロセスの一覧、ファイルの一覧などを取得するシステムコールを横取りし、rootkitのプロセス、ファイルの存在を隠してしまいます。この隠蔽はカーネルレベルで行われているため、一旦インストールされてしまうとユーザレベルで実行されるアンチウィルス対策は全く役に立ちません。
snort等のIDS(Intrusion Detection System)を使えばネットワークトラフィックから検出できると思われるかも知れませんが、例えばHacker Defenderの場合、135番ポートで通信し他のWindowsアプリも正常に動作するため通常の状態ではsnortで検出できません。
Microsoft Resarchの場合、カーネルrootkitもCross View Diffと呼ばれるテクニックで検出するようにしたようです。詳しい、説明はリンク先を見て頂くとして、より低いレベルでのスキャンとAPI出力の差分からrootkitを検出するという手法です。現在確認されているrootkitは検出可能ですがどのような方法を取ったとしてもイタチごっこの様な気もします。
ちなみにこの手のカーネルrootkitはWindows用ばかりではありません。当然ですがLinux用のカーネルrootkitも多数存在します。
今すぐrootkitが入っていないか確認したい！と言う場合、検査するシステムのHDDを取り外し、信頼できるシステムにマウントしてrootkitファイルが無いか確認すると良いでしょう。
CERTも放っておくわけには… 2004/12/2 US-CERTのメールから。
TA04-315A describes a buffer overflow vulnerability in Microsoft Internet Explorer HTML elements that could allow a remote attacker to execute arbitrary code. Note that any program that hosts the WebBrowser ActiveX control could be affected. Microsoft Security Bulletin MS04-040 contains an update to fix this vulnerability.
The vulnerability is described in further detail in VU#842160.
URL： http://www.us-cert.gov/cas/techalerts/TA04-336A.html
PHP 4.3.7/5.0.0RC3以前に脆弱性がある事は広く知られている(?)と思いますが、攻撃用コードがネットに公開されています。
http://www.felinemenace.org/~gyan/phpnolimit.c
もし脆弱性があるPHPを利用している場合は直ぐにアップグレードする等、必要な対策をおこなうべきです。
要は個人でサーバを立てるな、と言う話。巷には「簡単サーバ構築」本が溢れていますがサーバ構築と運用は「簡単」ではない、と言うことが完結にまとまっています。すばらしい。
私も以前から悶々と考えていた事が丁寧に記載されています。
# Webセキュリティー関係の基礎をwikiにまとめてアップしたいですね。
# 題して「Webプログラミング」に対する誤った認識、かな。(進歩は真似からはじまる by yohgaki
まさかsmbfsをインターネット等に公開している方はいないと思いますが、DOS攻撃は簡単そうです。
Inetnet Watchによると
米セキュリティベンダーのFinjan Softwareは10日、Windows XP SP2に深刻な脆弱性が10件発見されたと発表した。同社ではすでにMicrosoftに連絡しているという。
だそうです。
先日私のPukiwikiのページが荒しにあいました。初めての荒しでしたが、ついに来たかと、さっさとバックアップを使ってページを回復し気にせず放っておいたのですが、どうも他のサイトも荒しあったようです。
ググってみるとPukiwikiの開発日記にこの荒しと関連していると思われる記載がありました。これによると荒しにも関わらず不正侵入で書き換えたようなメッセージが表示されていましたがご丁寧にもzone-hにまで登録したらしい… 恥じを知らないクラッカーですね。
ここの日記にも書いたHTTP Response Splitting Attackの対策がPHPでも取られるようです。
header(“bad-header: This is bad header\r\n but having CR/LF in a haeder is allowed by the standard in some case.”);
上記のヘッダが送られた際に\r\nを自動削除可能な設定が追加されます。ただし、\r\nがヘッダ中に現れる事は標準で認められいいますが、パッチを適用したPHPの場合は拒否&警告エラー(php.ini設定のデフォルト値になる)が発生します。もちろん「不正なユーザ入力対策は万全」というサイト向けではそのままCR/LFを送ることも可能です。次のPHPリリース時には取り込まれていると思いますが、仕様が変わっているかも知れないのでChangeLogなどで確認する必要があります。
未対策のアプリがあるサーバはエラーハンドラ(必ず作ってますよね。PHPプログラマの方!)で処理するだけです。普通にエラー処理しているPHPアプリケーションならPHP本体にパッチを当てるだけで完了です。
SANS Top 20が10/8日に発表されていますね。UNIXはBINDが1位になっています。インストールしたままアップグレードしない、古いパッケージをそのまま使う管理者も多いと言うことなのでしょう。
ちなみに私は出来るかぎりdjbdnsを使ってます。このリンク先にDan J. Bernstein氏が随分前から指摘していたDNS キャッシュを DNS サーバから分離することの重要性を知らないユーザも多いと言うこともあるでしょう。こちらも随分前になりますがCERTもこの件に関してアドバイザリを出しています。
しかし、今でもDNSキャッシュとDNSサーバに同じIPアドレスを指定させているISPがあります。CERTアドバイザリのURL等を添付して改善を依頼するメールを送った所、「検討します」という内容のメールが来ました。しかし、それから早くも半年近くも経ちます。DNSキャッシュの汚染によるサイトの乗っ取りなどの被害が発生した場合、このISPは損害賠償を請求されても仕方が無いですね。
世界中にはこの様なISPが沢山あるのかも!?
HTTP Reponse Splitting AttackはOWASPの新しい脅威のカテゴリになるそうですね。
簡単言うと言語やブラウザ等のHTTP Reuqestヘッダによって別のページに振り分ける(リダイレクト)させるWebサイトのヘッダに問題があると脆弱性が発生し攻撃が可能になります。
可能になる攻撃にはクッキーの漏洩からキャッシュシステムが組み込まれたWebサイトでは意図しないページの表示(複数のユーザ向けへのページの改竄)まで、と色々な影響があります。対処方法は正しいヘッダを返す。つまりCR,LFを含んだ入力をリダイレクトに使わない。
詳しくは
http://lists.virus.org/webappsec-0403/msg00004.html
クリックしてwhitepaper_httpresponse.pdfにアクセス
PDFは非常に丁寧にHTTP Response Splitting Attackを解説しています。