武田圭史

今のところどちらも初歩的なDoS合戦にすぎないが、周辺に飛び火しないとも限らないので身の回りの安全は確認しておいた方がよいだろう。

asahi.comによる首相官邸と内閣官房に対する攻撃に関する記事の中で、

同センターは、被害に遭っているサーバーを即座に割り出すシステムを利用して常時監視を続けている。

とあるが、被害にあっているサーバより攻撃の発信元を即座に割り出してくれた方がありがたい。

【参考情報】
■ハッカー：尖閣防衛団体サイトに攻撃、利用不能に(毎日新聞)
http://www.mainichi-msn.co.jp/kokusai/america/news/20050224k0000m030054000c.html

■首相官邸と内閣官房ＨＰにサイバー攻撃　一時接続不良に(asahi.com)
http://www.asahi.com/national/update/0223/043.html

■首相官邸ＨＰなどにサイバー攻撃・大量のデータ送信(NIKKEI NET)
http://www.nikkei.co.jp/news/main/20050223AT1G2303J23022005.html

ブログのユーザが自分のブログ上に新たな機能を提供するつもりで追加したJavaScriptの部品が読者のPCにスパイウェアをインストールさせてしまうことがBlogger.com周辺で問題になっている。

下記の記事ではgoogleのBlogger.comのことばかり書いているが、MoovableTypeなど既存のブログツール上で「テンプレート（部品）」としてJavaScriptのコードをどこからかダウンロードして利用した場合には同じ問題が発生する。

使用するJavaScriptコードの内容をよく検証し、出所のあやしいコードは利用しない方が良い。

ブログという新しいツールには、まだまだ様々な問題が発生してきそうだ。

【参考情報】
■ブログがやばい–スパイウェアの配布に悪用される脆弱性あり(Stefanie Olsen@CNET News.com@CNET-Japan)
http://japan.cnet.com/news/sec/story/0,2000050480,20080895,00.htm

■How Google’s Blogspot Helps Spread Unwanted Software(Benjamin Edelman)
http://www.benedelman.org/news/022205-1.html

「スパムの配信方法が全く異なる。中国のスパムは人海戦術で一斉配信される。人手によるため、同じ内容のスパムは1～2日の短期間しか配信されない。欧米との大きな違いだ」と指摘する。

「中国のスパムは他国とはひと味違う」と英サーフコントロール幹部（日経コンピュータ）

スパムに限らず、ある程度知識を持った攻撃者がネットワーク越しに人海戦術で攻めてきた場合の対処というのは現在想定されている様々な対策を無効化する可能性がある。

例えば個々のターゲットのネットワークでしか動作しないワントゥワンなウィルスやトロイなどは、現在のアンチウィルスやIDSのスキームからは外れてしまうだろう。差し迫ったところで言えば、コメントスパムやトラックバックスパムなどもこれでやられると対応が面倒だ。

人件費の安さはこういった分野でも力を発揮するのだろうか。

■参考情報
「中国のスパムは他国とはひと味違う」と英サーフコントロール幹部（日経コンピュータ@日経IT Pro）
http://itpro.nikkeibp.co.jp/free/NC/NEWS/20050222/156510/

以前カリフォルニア州のサッター小学校で児童・生徒にRFIDタグの着用を義務付けて行う予定だった実験について一部の保護者達が反対をして問題となっていた件について、学校側がこの実験の中止を決定した。
　

校長のEarnie Grahamは、同プログラムが無くなったのは残念だと語った。「非常に大きな損失だ」と校長は言う。「最先端に立つチャンスだった」（校長）

CNET-Japan

この一言に今回の騒動の原因を垣間見ることができる。RFIDタグを用いた生徒・児童の出欠管理自体については、すでにニューヨーク州バッファローのチャータースクールでも導入が行われており、うまく「プライバシー保護のための工夫」をすれば全く受け入れられないものではなかったはずだ。

今回の実験に関する初期の発表や製品の開発元であるInCom CorporationのWebページから読み取るに、開発者や導入に関わった職員がプライバシーの侵害の可能性を考慮しておらず、このような反発をまったく想定していなかったかのように思える。

このような問題を考える際にまず認識しなければならないことは、「プライバシーの問題の感じ方には個人差がある。」ということである。この手のサービスが問題となる多くの場合、開発者がプライバシーの問題を全く意識していないか、気づいていてもメリットがあるのだからいいだろうという安直な考えを持っている場合が多い。今回のケースでは、これに加え、保護者や児童・生徒に十分な説明もなく着用を義務付けようとした点や、学校関係者や開発元がこの学校を実験台として儲けを企んでいたことがみえみえだったことも、保護者達の反感を大きくしたようだ。

サービスの企画・設計時点から、本当に児童・生徒の安全を考え、両親の意見なども取り入れながら「プライバシー保護のための工夫」をしていけばこのような結果にはならなかっただろう。この事例をとりあげ、ヒステリックにRFIDの利用全てを悪者扱いすることは避けたい。ただし、今後、RFID利用の普及を考えた場合には、プライバシーの保護に関する配慮と工夫について、早い段階での利用者への説明・意見交換と仕様への反映が不可欠だろう。

【参考情報】
■米小学校、RFIDを使った児童監視システムを廃止–保護者などの反対を受け(CNET Japan)
http://japan.cnet.com/news/ent/story/0,2000047623,20080789,00.htm

■InClass(InCom Corporation)
http://www.incomcorporation.com/

■米国のRFID児童・生徒使用実験こちらは死体と同じ扱いに（武田圭史）
http://motivate.jp/archives/2005/02/rfid.html

Schneier氏のブログにSHA-1 brokenに関するエントリーが追加された。

特に目新しい情報が追加されたわけではないが、ポイントは以下のとおり。

・Full SHA-1がブルートフォースよりも効率の良い方法でコリジョンが発見されることは予想されていた。しかしこれほど早くその方法が明らかになるとは思っていなかった。

・今回の発表は、暗号の研究者や技術者にとってインパクトがあるが、一般のユーザに直ちに影響を与えるものではない。

・すでにSHA-1以上の強度を持つハッシュ関数（SHA-224, SHA-256, SHA-384, and SHA-512.）が存在しているので今後これらに移行するなどSHA-1の代替を検討していく必要がある。（NISTに対しては新たなハッシュ関数に関するコンペティションを提案している。）

【参考情報】

■Cryptanalysis of SHA-1(Bruce Schneier@Schneier on Security)
http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html

これのようです。

■Collision Search Attacks on SHA1(Xiaoyun Wang, Yiqun Lisa Yin, Hongbo Yu)
http://theory.csail.mit.edu/~yiqun/shanote.pdf

full SHA-1については理論値で、コリジョンの実証はされてないようです。

しばてんさんにコメントで教えていただいたページから辿れました。

１９ページのバージョンがあるとかないとか。本当かなぁ。

サンフランシスコで開催中のRSAカンファレンスにおいて、セキュリティに関する法規制と企業責任に関するディスカッションが行われたようだ。

一般的な企業の現場ではセキュリティ投資に対する経済的インセンティブはまだまだ低いのが実情だ。いくら政府の委員会で「情報セキュリティが重要だ、産官学で協力して強固な体制を作ろう！」と叫んだところで、先立つものがなければ単なる掛け声で終わってしまい、盛り上がっているのはセキュリティ関連企業だけということになりかねない。様々な省庁が主催する委員会から立派な報告書がPDF配布されているが、肝心の企業側にセキュリティ対策のメリットがなければそこに自ら投資を行う動機は生まれてこない。

社会全体として情報セキュリティの水準を高めるためには、セキュリティに関する損害を、情報を扱う各企業等の全面的な責任と位置づけ、セキュリティ対策への経済的インセンティブを設けるのが理にかなっている。社会全体のセキュリティ投資が促進されセキュリティ業界にとってはありがたい話だが、今まで以上にリスクを負わされる一般企業はいい迷惑かもしれない。セキュリティにある程度目をつぶっても、革新的な新製品や新サービスを提供できた方が社会全体としてのメリットが大きい場合もあるだろうし、がちがちのセキュリティを要求することで新たなビジネスの芽をつぶす危険性もある。

これまでのような「セキュリティは重要」といった掛け声や、奇抜なセキュリティ技術の研究開発への投資だけでなく、こういった制度面からの情報セキュリティ強化に対するアプローチについても国内の議論を深めていく必要があるだろう。

【参考情報】
■The Fight Over Cyber Oversight(Kim Zetter@WIRED NEWS)
http://www.wired.com/news/privacy/0,1848,66632,00.html?tw=wn_story_page_prev2

■不正キャッシュカードのコストは誰が負担すべきか(崎山伸夫のBlog)
http://blog.sakichan.org/ja/index.php/2005/02/12/p112

■「情報システム等の脆弱性情報の取扱いに関する研究会 報告書」の限界(崎山伸夫のBlog)
http://blog.sakichan.org/ja/index.php/2004/04/12/p77

■Why Information Security is Hard An Economic Perspective(Ross Anderson)
http://www.ftp.cl.cam.ac.uk/ftp/users/rja14/econ.pdf

■Why Cryptosystems Fail(Ross Anderson)
http://www.cl.cam.ac.uk/users/rja14/wcf.html

(2/18:追記)
CNETにも同じトピックを扱った記事が掲載されていた。Wiredが企業責任を中心に書いているのに対し、CNETは政府による規制を中心に書いているが、内容が端折られすぎていてポイントがわかりにくくなっている。

■Time to regulate the software industry?
http://news.com.com/2100-7348_3-5579963.html

■ソフトウェア産業を規制すべきか–米でパネルディスカッション
http://japan.cnet.com/news/sec/story/0,2000050480,20080762,00.htm

フィッシング詐欺の新たな手口として、ユーザが正しいドメイン名にアクセスしているつもりでも、IPアドレスへの変換のしくみ（lmhostsやDNSサーバ）に細工をし、任意のIPアドレスのサーバに誘導し、クレジットカードや個人情報などを搾取する、通称ファーミング(Pharming)が注目されている。

ユーザを任意のIPアドレスにユーザを誘導するため一手段としてDNSポイゾニングという手法が用いられる可能性があり、ここではその手口や対策について簡単に紹介する。

【DNSポイゾニングの手口】
攻撃者は、攻撃対象となるユーザが利用するDNSサーバのキャッシュに誤った情報を記憶させ、ユーザが特定のドメイン名、たとえばwww.example.comというEコマースサイトにアクセスしようとした際に、任意のIPアドレスを持つサーバ（例えばクレジットカード番号収集用のサーバ）に通信を行うよう誘導する。これは以下のような手順で行われる。

１　攻撃対象のユーザが利用するDNSサーバに、ユーザが利用するであろうサイトのドメイン名(www.example.com)についてIPアドレスの問い合わせを行う。

２　DNSサーバは問い合わせ対象の情報が自ドメインの管理下にないため当該ドメインのDNSサーバに要求を転送する。

３　攻撃者は２の要求転送先であるDNSサーバになりすまし、誘導したいIPアドレスを回答として送信する。

DNSは通常UDPプロトコルを使用して通信を行うため、IPパケットの送信元を書き換えるだけで容易に詐称することができる。サーバー側の対策として返答の送信元の詐称を困難にするため要求を送信する際ランダムなシーケンスナンバーを指定するが、攻撃者が総当り的に異なるシーケンスナンバーを持つパケットを大量に送信することでDNSサーバをだますことができてしまう。

特に古いバージョンのDNSサーバ（BIND4,8等）では、一つの問い合わせについて複数の要求パケットを送信するために、シーケンスナンバーが偶然一致する確率が高くなる。また、サーバで生成する擬似乱数の偏りを利用して、シーケンスナンバーが一致する確率を高める方法も考えられている。

【対策】
このようなDNSポイゾニングの対策としては、サービス提供側(www.example.com)としては、SSLのサーバ認証を利用し、ユーザに都度証明書を確認するよう促すぐらいしかない。SSLを使用していることをユーザによく認識してもらいSSLを介さずに接続された場合は偽物のサイトであることを理解してもらう。また、仮にSSLで接続された場合でも攻撃者のドメイン名に対する証明書だったり、オレオレ証明書が用いられる場合もあり、当該サイト(www.example.com)に対する正しいドメインの証明書であることを確認してもらう必要がある。

自分が管理するDNSサーバに対してDNSポイゾニングが行われないようにするための対策としては、外部からの自ドメインに関する問い合わせについて回答するDNSサーバと、内部ユーザからの問い合わせを処理する（キャッシュ）サーバをそれぞれ異なるIPアドレス持つよう分離し、外部から内部ユーザが利用するDNSサーバを攻撃対象とされないようにすることが考えられる。また内部用のDNSサーバには外部から直接問い合わせができないようアクセス制限を行う。またファイアウォールやIDSを用いて不正なパケットを制限・監視する方法などが考えられる。

【まとめ】
DNSというサービスのプロトコル上の制約から、今回紹介したようなDNSポイゾニングについて完全な対策を行うのは容易ではない。DNSSECなどセキュアなプロトコルとサービスに関する研究が進められているが、そういった新たな技術が十分に普及するまではDNSポイゾニングの危険性は存在し続けるものと思われる。

【参考情報】
DNS Cache Poisoning – The Next Generation(Joe Stewart,GCIH@SecurityFocus )
http://www.securityfocus.com/guest/17905

（2/18：表現等一部更新）

Schneier氏のブログSchneier on Securityに各種暗号（署名）システム等に広く利用されているハッシュ関数SHA-1がXiaoyun Wang, Yiqun Lisa Yin, Hongbo Yu という中国Shandong University を中心とする研究グループによって破られたとの論文が出回っているという投稿が行われた。

full SHA-1に対しブルートフォースによるした場合の2の80乗オペレーションよりも少ない2の69乗オペレーションによるコリジョンの検出

（内容について誤解を招くおそれがあったため記述を修正 2/16）

SHA-0に対する2の39乗オペレーションでのコリジョンの検出

58-round SHA-1に対する2の33乗オペレーションでのコリジョンの検出

がなされたそうだ。詳細については現段階においては確認はとれていないが論文そのものは入手されている模様。MD5はすでにコリジョンが検出され危険性が指摘されているし、SHA-1はNISTが2010年までには段階的にフェードアウトさせる予定だったために、今回の発表の内容次第では現行の暗号(署名)を用いた各種システムの入れ替えを前倒ししなくてはならなくなる可能性もある。

詳細は追って公表するとのこと。

【参考情報】
SHA-1 Broken(Schneier on Security)
http://www.schneier.com/blog/archives/2005/02/sha1_broken.html

【書籍紹介：Google Hacking for Penetration Testers】

　強力なサーチエンジンGoogleはセキュリティ監査を行ったり漏洩した情報やフィッシングサイトを探す場合においても有効なツールとして利用することができる。googleの検索画面に、ちょっと工夫をしたクエリーを入力するだけで、危険なバージョンのWebアプリケーション、不用意に公開されているパスワード情報、漏洩した個人情報などを発見することができる。

　これまでもこのような検索テクニックは様々なサイトで断片的に公開されていたが、本書は情報セキュリティの観点からgoogleを活用するためのテクニックや考え方を網羅的に整理し解説している。

　検索で利用できるオペレータと文法に始まり、脆弱なアプリケーションや、名簿、メールアドレス、パスワードなどの効果的な検索要領、サイト側でgoogleによる検索を制限する方法、googleAPIを用いたプログラムなどが紹介されている。本書で紹介されているようなクエリの例を以下に示す。その他の検索例についてはこちらを参照されたい。

・C言語によるexploitコードの検索：「　”#include <stdio.h>” “Usage” exploit　」

・Unixにおけるpasswdファイルの検索：「　intitle:”index of..etc” passwd　」

・MS Frontpageのパスワードファイルの検索：「　”# -FrontPage-” inurl:service.pwd　」

　セキュリティ監査等の情報収集の段階においてgoogleが利用されることは少なくないと思うが、本書を通して読むことでサーチエンジンにより検証可能な項目を俯瞰することができる。また、様々なクエリを実際に試して体験してみることでその背景にある考え方を理解し、様々な場面でgoogleを有効利用するセンスを磨くことができると思われる。

　著者らは現在、Google Hackに対する対抗手段としてサーチエンジンを用いたハッキングに対するハニーポットであるGoogle Hack Honeypot v1.0を、オープンソースプロジェクトとして開発を行っている。

　このエントリを書くにあたり”google hacking penetration”をキーワードとして日本語のページを検索したところ、××××（サイトコンテンツが削除されたので人名を削除2/16）という人物が××庁（削除2/16）に対して行ったと思われる「サイバー犯罪捜査官養成研修」（リンク削除2/16）という資料が公開されているのを発見した。今回紹介した書籍とほぼ同様の内容がまとめられたものなのだが、もし仮に××庁（削除2/16）の許可を得ずに公開されているとすると、このようなクライアントに関わる情報を公開するのはどうかと思う。当然業務に関する秘密ではないとしても、どのような研修を受けているかなどは見方により重要な意味を持つ。
（結果的に、このような検索もまたgoogleを用いた情報セキュリティ検証の例だったりする。）

(追記 2/16)
セキュリティホール memoの小島さんが、「紹介されている サイバー犯罪捜査官養成研修はもしかすると消えちゃうかもと思ったのでいそいで get しておいた。」と書いたら本当に消えてしまったので、関係の記述を削除。

・・・でもgoogleの検索画面までは消せませんから。残念～っ！

【参考情報】
■Google Hacking Database (Johnny Long)
http://johnny.ihackstuff.com/index.php?module=prodreviews
本書で紹介されているのと同様の様々なクエリが登録されている。

■Google Hack Honeypot(GHH Team)
http://ghh.sourceforge.net/

■サイバー犯罪捜査官養成研修（××××）(人名およびリンク削除2/16)
http://www.×××××.net/presentations/JapEng_xxx_google_E&J.pdf

■Google Hacking For Penetration Testers（Syngress Media Inc）
JOHNNY LONG (著), Ed Skoudis (著)
価格： ￥3,508 （税込:’05/2/16現在）

注）画像へはAmazonアソシエイトプログラムのリンクを設定しています。