日本でもスパイウェアによる被害が940万

Security

日本でもスパイウェアによる被害が940万

7月 20, 2005 投稿者 yohgaki

アメリカではスパイウェア（キーロガー）によると思われる被害が急増しています。日本でもスパイウェアにより情報を収集し、銀行口座から不正の送金される被害が940万円あったと発表がありました。（今はアクセスできませんが、TBSのヘッドラインニュースで940万円の被害と報道していました。アクセスできないので間違い?) ジャパンネットバンク他、合計3行で被害が確認されたようです。スパイウェアを使った攻撃の危険性はこのブログでも書いたと思いますが、遂に潜在的な脅威から現実の脅威になったようです。

スパイウェアはブラウザやシステムの脆弱性を攻撃してインストールされる場合もありますが、ネットカフェなどの共有のPCにインストールされる場合も多いです。カーネルレベルのルートキット（スパイウェアの一種）の場合、検出が非常に難しいか不可能な場合もあります。システムコールより更に低レベルの実行結果とシステムコール実行後の結果を比較してカーネルレベルルートキットを検出するなどの手法も考案されていますがいたちごっこでしょう。

Windowsにカーネルレベルのルートキットをインストールされないようにするためには、Windowsは通常ユーザで使用すれば概ね大丈夫です。Windowsマシンで開発しているため管理者権限が必要な場合、開発用のマシンとメールやブラウジングなどの通常作業は別のPCかバーチャルマシンで行う様にした方がよいと思います。

Windowsはコマンドラインでの操作性は最悪ですが、runasコマンドを使うと現在ログインしているユーザ以外の権限でプログラムを実行する事ができます。この機能を使うと多少は通常ユーザでWindowsを実行した場合の問題を回避できます。

参考
http://www.ipa.go.jp/security/topics/170720_spyware.html
http://internet.watch.impress.co.jp/cda/news/2005/03/09/6783.html

Computer, Development

PHPのE_STRICTエラー

7月 15, 2005 投稿者 yohgaki

PHPのエラーレポートレベルはphp.ini設定のerror_reportingで設定されています。

PHP5から追加されたE_STRICTで「あれ」と思われるかもしれない状況があるので書いておきます。

PHP5でE_ALLをerror_reportingに設定してもE_STRICTレベルのエラーは報告されません。デフォルト設定ファイルではE_STRICTは無視されるようになっています。

error_reporting = E_ALL | E_STRICT

と設定しないとより厳しいエラーチェックが行われません。

開発時には言語が用意しているエラーチェックを出来る限り多く使用するべきです。しかし、E_STRICTレベルのエラーレポートを行う設定を行った場合に問題が発生する場合があります。次のコードがどのように処理されるか考えると分かります。

<?php
error_reporting(E_ALL); // E_STRICTは不必要

class foo {
  var $bar;
}
?>

E_STRICTで報告されるエラーには”var”宣言されたプロパティにpublic/private/protectedを使用するよう推奨するエラーがあります。このエラーはコンパイル時に発生するため、スクリプト中でerror_reporting関数を使ってエラー報告レベルと変更してもE_STRICTエラーを無視できません。E_STRICTエラーが有効な環境で、error_reporting関数で確実にE_STRICTエラーが発生しないようにするには、E_STRICTエラー出力を抑制するには最初に読み込まれるファイルのコード中にE_STRICTエラーが発生しないしerror_reporting関数を使用してエラー報告レベルを変更しなければなりません。

# E_STRICTは開発時だけ使う、という方針がお勧めです。
# PHP4用に作ったアプリの修正は手間な場合は、INSTALL
# ファイルなどにE_STRICTは無効にするよう書くだけでも
# 良いかもしれません。

備考：
E_NOTICEレベルのエラーは全て実行時に発生するエラーであるため、E_STRICTの様な問題は発生しません。念のため。

追記：
今時のPHPアプリケーションならE_STRICTエラーも発生しないようにプログラムを作成すべきす。

 

Other

NEC LaVie G タイプRX

7月 14, 2005 投稿者 yohgaki

LaVie G タイプRXをPentinumM 1.7GHz, 1GBメモリ, 80GB HDD, DL対応 DVD, WindowsXP Proを1台約19万で2台購入。2Kgほどの重さで、持ち運ぶ時にも問題ないです。今はNECダイレクトで14%OFFクーポン（今日まで）が使えるのでカスタマイズしたい方はNECダイレクトがよいかも。このPCはSXGA+（1400×1050）なのでソースコードを眺めるには良いPCと思います。今使っているVAIOもSXGA+ですがやはりこれくらいは欲しいところです。このスペックで19万は安いかと思います。
# 損した気分になるかもしれないので価格比較は行ってません

価格・スペック比以外にもNECは近所にサービスセンターがあって前に使っていたノートPCが壊れた時の対応が非常によかったのでこれに決めました。

Computer, Security

PHPのメモリ・リソースリークの修正

7月 14, 2005 , 投稿者 yohgaki

気が付いていてもやってないことが多いので、せめて近日中に処理しようと思っていることくらいは公開して自分にプレッシャーをかけてみる事にしました。

PHPにはError HandlerやException Hanlderを使った場合、メモリやリソースが開放されない場合があります。多少のリークは問題とならない場合がほとんどですが中にはサーバがフリーズしてしまうケースもあります。原因と修正すべきコード、対処方法なども分かっています。取り掛かろうとしてinternalsに軽くメールしたのち放置中…

# この問題と原因は随分前から知っていて放置してました :(

Other

ハンズフリーでも運転中の電話は危険

7月 14, 2005 投稿者 yohgaki

CNNニュース（テレビでみたのでURLなし）によると、米国の調査では自動車の運転中にイアフォンなどを利用したハンズフリー通話と携帯電話を手にした通話では危険度はあまり変わらない、と放送していました。合わせて通話している場合と通話していない場合では事故の確率が4倍になるとしていました。アメリカでも市などの条例で運転中の通話にイアフォンを使うよう推奨しているそうですがこの調査によるとイアフォンを使用した通話は全く意味が無いとしています。

ダイアル中、受話中、通話中など状態によって危険度は変わるとおもいますが、どのような状態で危険度測定したかなどの詳細な情報が無かったので判断しかねる部分もありますが、少なくとも話し始めたら手に持っていてもイアフォンを使っていても同じ危険度らしいです。

日本の場合、運転中にメールを読んだりする人もいるので運転中に端末を持ってはいけない、とするのは合理的とは思います。法律ができてから電話で通話中のためおかしな運転になっている車を見かけることも無くなりました。しかし、香川県のチャイルドシート利用率は年々下がり半分程度になっているそうです。同じような結果になりそうな気がします。

追記：後で関連URIを見つけました
http://hotwired.goo.ne.jp/news/technology/story/20050715305.html

Computer, Development

関数の戻り値と定数値（リテラル）への参照

7月 13, 2005 投稿者 yohgaki

追記：このエントリへのアクセスが多いので加筆修正しました。

Fatal error: Only variables can be passed by reference

直訳すると「致命的エラー：変数のみ参照渡しが可能です」となります。エラーメッセージの通りvariable（以外）の値は参照として渡せないのでエラーになっています。エラーメッセージが適切かどうかは微妙ですが、意訳すると「致命的エラー：ソースコード中に記述した定数値（リテラル）へのアクセスはできません」あたりが妥当と思います。当然ですがdefineで定義した定数値を返す事は可能です。PHP内部では定数は変更できない「変数」の様に実装されているからです。このエントリの「定数値」を正確に書くと「ソースコード中に記述された定数値」となります。

もっと読む

Security
Computer, Security

.mobiドメイン承認

7月 13, 2005 投稿者 yohgaki

何度か「もう新しいドメインは必要ない」とこのブログに書いていますが、ICANNはモバイル用に.mobiを承認したようです。

EU用の.euドメインは、EUが最終的には統一国家のような体制を目指しているので必要かとおもいますが、アダルトサイト用.xxxやモバイル用.mobiはドメイン名のレジストラとごく一部の利用者（ドメインを必要とするもの）を除いて不必要なドメインです。管理上、地域別にドメイン名を付けるのは理解できます。しかし、サイトの種類に応じてドメイン名を付ける、と言うアイデアは破綻している事が証明されてから久しいです。トップレベルのドメイン名がどんどん増えていますが、レジストラのみ儲ける仕組みですね。
# 会社名.xxx等をアダルトサイト運営者に取得されないように
# するためだけに企業が.xxxドメインを取得するのは目に見え
# ています。.xxxドメインの半数以上は普通の企業のドメイン
# となると思います。（アダルトビジネスを甘く見すぎ?）

ところでアフリカ連合が統一国家的な体制になった場合、ドメイン名をどうするか問題になりますね。.auは既に使用済みです。この心配が現実になるとしても少なくとも50年以上先の話とは思いますが。

Security

悪魔の双子

7月 13, 2005 投稿者 yohgaki

「悪魔の双子」という攻撃はセキュリティに詳しい方ならご存知と思いますが、あまり一般的に認知されていないような気がしてきたので簡単に書いておきます。日本語版Wikipedia、はてなにも「悪魔の双子」は登録されていないようです。さすがに英語版Wikipediaには載っていました。

日本語のニュースでは、少なくとも、WIRED NEWSに米国イベント会場で「悪魔の双子」のアクセスポイントは頻繁に発見される、と言う趣旨のニュースは出ていたような気がします。（記憶が曖昧。自信なし）

英語版Wikipediaの定義によると、悪魔の双子（Evil Twin）とは

An evil twin is the concept in fiction (especially science fiction and fantasy) of someone equal to a character in all respects, except for a radically inverted morality.

とされています。日本語に訳すと次のような感じになります。

悪魔の双子とは架空の物語（特にSFやファンタジー）の登場人物で、正反対の道徳性を持つこと意外は全く同じ特徴をもつ登場人物のことです。

「悪魔の双子」による攻撃とは、イベント会場などで利用者の利便性の為に無料で提供される無線LANのアクセスポイントを装い、「悪魔の双子」のアクセスポイントを経由したパケットからユーザ名やパスワード等の情報を盗み取る攻撃の事です。アクセスポイントはイベント会場だけでなく、会社や学校、公衆無線LAN、誤った設定のアクセスポイントなどに偽装している場合もあります。「悪魔の双子」による攻撃は無線LANのアクセスポイント以外でも応用可能ですが、無線LANのアクセスポイントを偽装した攻撃を「悪魔の双子」と呼ぶ事が普通のようです。

ネットワークのパケットを盗み見ても価値のある情報はそう簡単に盗み取れない、と思うのは間違いです。今でも暗号化が全くないPOPやIMAPアクセスは普通に利用されています。多くのユーザがメールのアカウントのアカウント名とパスワードは他のアカウントのIDとして利用しています。

登録済みのアクセスポイントに自動接続する仕組みは非常に便利ですが、メールクライアントを立ち上げたまま「悪魔の双子」のアクセスポイントに接続してしまうとメールアカウントのユーザ名とパスワードが盗まれる可能性があります。

アメリカのイベント会場では「悪魔の双子」が見つかっても珍しくない状態になっているようです。日本の状況をレポートした資料は見た事がないですが、用心するにこした事はありません。

イベント会場など他の場所では無線LANを使わないから大丈夫、ともいえません。例えば、社員が職場に「悪魔の双子」を設置した場合はどうでしょう? 大丈夫でしょうか?

蛇足：
時々、無線LANへのアクセスをMACアドレスベースで制限しているので大丈夫、と勘違いされている方を見かけます。WEPで暗号化していても（当たり前ですが）MACアドレスは暗号化できません。最近のNICはMACアドレスを自由に変更できます。したがってMACアドレスでアクセス制限をしてもセキュリティ対策として意味がありません。

ところで「悪魔の双子」による攻撃は無線LANがはやる前から懸念されていた攻撃方法です。「悪魔の双子」という注目を集めやすい名前から急速に認知されるかもしれませんね。（何年も前からEvil Twinは無線LANのアクセスポイント偽装をあらわす用語として使われていたように思えます。どうだったかな?）

Security

画像のみのフィッシングメール

7月 12, 2005 投稿者 yohgaki

受け取っている人はすでに同じようなメールを受け取っていると思いますが、画像のみのフィッシングメールがアンテナ用メールアドレスにまた来ました。
# Citiバンクのフィッシングメールは有名なので受け取っている方
# も多いと思います。

一見、普通のテキストメールのように見えるのがポイントです。うっかりテキスト部分だと思ってクリックするとサイトに接続してしまいます。

Phshing
（これをクリックしてもフィッシングサイトには接続されません）

画像を添付したSPAMメールの増加は非常に気になります。画像を添付したメールは全てSPAM扱いにする方が良いですね。

ちなみにこのフィッシングサイト、これを書いている時点では稼動中でした。:(

追記：たまたま@ITにCitiBankのフィッシングメールのイメージを載せているページを見つけたので、URLを貼り付けておきます。
http://www.atmarkit.co.jp/fsecurity/rensai/mailauth01/mailauth01.html

Other

禁煙1周年

7月 12, 2005 投稿者 yohgaki

ふと気が付くと禁煙1周年を超えていました。確か去年の6月半ばから禁煙しています。日付を覚えていないのは「禁煙しよう」と思って止めたのではないからです。自己暗示をかけているうちに吸わなくなってしまいました。「禁煙しなければ！」と言う意識が無かったためか、吸いたくなる事もあまりありませんでした。そんな簡単に禁煙できるはずが無い、と思われる方もいらっしゃるかもしれません。しかし、以前勤めていた会社の同僚で同じようになんとなく禁煙して成功した方がいます。その時は私も「ほんとに?」と思いましたが、自分も同じように禁煙に成功しました。タイミング、心理状態が要なのかも知れません。

ところで喫煙している方に面白い製品があります。ビタクールはニコチンを分子構造が似ているビタミンB3に変えてしまうそうです。眉唾製品っぽく聞こえますが、日本、中国、韓国、米国で特許を取得しているそうです。

私はもう吸っていないので喫煙者の方、いかがでしょう?

Other

Googleの広告位置を変えてみる

7月 11, 2005 投稿者 yohgaki

今まで右側のサイドバー下にGoogleの広告を入れていましたが、場所を変えてみました。

最初から非効果的な場所とは分かっていたのですが、本当に非効果的でした（笑

# 2ヶ月で700円くらいになりました :)
#
# adsenseで儲けよう、というのではなくadsenseを
# 使ってみてコンテンツの内容と表示される広告を
# 見る事が目的だったので十分と言えます。

ごく一部の方はアフィリエイトで儲けているようですが、クリック単価からするとトラフィックがあり、クリックしやすい場所に広告を載せると言われている程度の広告収入は期待できるかもしれません。その為にはコンテンツが重要ですが、このコンテンツつくりが難しいと思います。私を含め、普通の人には難しいでしょうね。

ところで場所をかえたおかげで本来の目的のコンテンツに対応して表示される広告が見やすくなって個人的には便利になりました。

Other

入門書の書き方

7月 10, 2005 投稿者 yohgaki

ほとんどの文章、セミナーでは対象とする読み手、聞き手を設定してから書き始めると思います。

極論すると、コンピュータを全く触った事がない人には今出版されているプログラミング入門書全ては難しすぎる入門書、になるでしょう。どのあたりに読み手を設定するべきか、コンピュータは知っているがプログラミングは初めて、からC/Java/etcのエキスパートでプログラミング言語はよく知っていて新しく言語を習得する方までいろいろあると思います。

私の書き方はあまり一般的ではない(笑)ため賛否両論になってしまうようですが、最も基本的な方針は「自分が買って読みたく、聞きたくなるなる本やセミナー」を目標としています。自分が読みたいとか聞きたいと思えない物を作ることに大きな抵抗感を持ってしまうからです。この方針のため癖のある文章やセミナーになってしまうと思います。もちろんこれだけでは自分以外には役立たない物になってしまうので、対象とする読み手や聞き手への配慮を入れるようにしています。

ちょうどWebサイトセキュリティの本を書いているところなのですが、この本も自分が読みたくなる本、となるように書いています。概念編と実践編の2部構成で、概念編は開発者以外の読者も読める内容、実践編は開発者向けの内容になります。書店で普通に販売されているコンピュータ関連の技術書の9割は入門書ですが、このWebサイトセキュリティの本も入門書です。

アマゾンのコメントはサンプル数が少なすぎで参考にするのは難しいですが、入門書は

・筆者自身の購買意欲をそそる細かな情報は無くても良いから、その分野の知識が無い人を対象にするべき（つまり、細かいことは置いておき、読みやすさを重視し詳細は省く）
・「PHPポケットリファレンス」も「はじめてのPHP言語プログラミング」もそれなりに売れているので、自分流で書いてしまうべき

のどちらにするかで迷っています。
一般受けして売れるのは前者なのでしょうね。
これはPHPポケットリファレンスを書いている時にも思った事ですが…

文章を書くのが上手な人はきっと簡単に両立できるのだと思いますが、私には難しい… (苦笑　

HTTP Response Splitting攻撃はこう行われる、IDSを潜り抜けるSQLインジェクション攻撃とか、具体的なことを書いても「難しすぎる」「説明が詳細すぎで初心者向けでない」「詳細が多すぎで対策の記述が不十分」と言うコメントが予想されます。硬派な技術系の方には「概念編は具体的な事がかいてないので無駄」「抽象的なことを説明するくらいなら、実践編にページを使った方がよい」などの感想になると予想できます。

要するに、このままではこれまで書いた本と同様、ツッコミどころの多い本になるという事です。
「○○入門」というタイトルになって★一つでも困りますしね…

さぁ、どうしましょう。今なら方針転換がぎりぎり間に合います。

Computer

不必要なIT化?!

7月 9, 2005 投稿者 yohgaki

裁判で電子投票の無効が確定したそうです。

前から思っていたのですがタッチパネルだけで投票する事がそんなに便利なのでしょうか?自宅にいながらインターネット経由で投票できるならまだしも、投票所に行かなければならないのにタッチパネルで投票する事の意義は無いと考えています。物理的に投票者が投票所に行くのですからもっとセキュアな仕組み（検証可能であることも含む）にするべきだと思います。
# 私が知っている電子投票システムはタッチパネルの物ですが
# 岐阜県可児市議選のシステムも同じかどうかは知りません。

私がシステムを設計するのであれば、マークシートとシートリーダを用意して投票と同時にマークシートを読み取らせる様にします。集計結果は投票時間が終了するまで誰も見れない仕組みにすればよいでしょう。万が一、集計データがなくなったり、今回の裁判の様に機器が使えなくなってもも後でマークシートを読めばよいだけです。選挙結果に異議がある場合もマークシートを読み直せばよいだけです。最悪の場合、アメリカの大統領選の様に人間がマークシートを一枚一枚確認する事態になるかも知れませんが、それでもタッチパネルだけの投票より遥かに容易に結果を再検証可能です。完全な電子投票では結果の検証手段が無いという致命的な欠陥があります。

利便性向上も目的の一つですが、電子投票にしたために投票をやり直すようでは経費もそうですが、利便性は低下するばかりです。

将来はネットワーク経由で投票を行えるようにするための実験として紙などを利用しない投票形式にしているのかも知れませんが、個人的には10年後でもネットワーク経由での電子投票には反対すると思います。安全性への疑問が拭いきれないからです。投票所に行かずに投票を行うことは不可能である事を前提とすると、今の電子投票システムは無用の長物としか思えません。電子投票システムの実験をしたいなら別途行って欲しい物です。

経費節減が電子投票推進の理由の一つになっていますが、投票用紙をマークシートにするだけも十分費用削減効果があるのではないでしょうか?そしてマークシート式投票用紙を使用した方が安全性など含め優れた点が多いのではないでしょうか?

さらに各自治体がいろいろな電子投票システムを作っていると思いますが、この状況は改善したのでしょうか?ばらばらに作っていたのでは税金の無駄遣いです。かと言ってシステムを統一すると不正が発生するリスクが大きくなってしまいます。

今の電子投票システムは不必要なIT化の代表例でしょう。

# 子供の安全性確保のためにRFIDを持たせる、というアイデア
# と同じくらい不必要かつ無駄なことだと思います。

Security

HTTP Request Smuggling Attack

7月 9, 2005 投稿者 yohgaki

HTTP Request Smuggling攻撃はクライアントからのリクエストをこっそり持ち出す攻撃です。HTTP Response Splitting攻撃の様にWebアプリケーションの脆弱性はHTTP Request Smuggling攻撃に必要ありません。キャッシュシステムの脆弱性が攻撃に利用されます。

攻撃例として

1. Webキャッシュ汚染
2．Webファイアーウォール回避
3．後方・前方のリクエスト持ち出し
4．リクエストの乗っ取り
5．クレデンシャルの乗っ取り（HTTP認証の強奪）

があげられています。

メジャーなWebキャッシュ製品が脆弱である事が検証されているようです。
各製品のアップデートがリリースされています。バージョンアップが必要な方はお早めに。

キャッシュシステムのバージョンアップ以外にも

1．SSLを使用する（キャッシュを利用できないようにしても同じ効果）
2．Webアプリケーションファイアーウォールを使用する（脆弱な製品もあるのでベンダーに確認要）
3．Apacheを使う

が対策として解説されています。
詳しくはリンク先PDFを参照してください。