カテゴリー: Security

不要なドメインは使わない

このブログの「新しいドメインの仕組や新ドメインは必要か?」等で時々新しいドメインは不必要と書いていますがDomainKeysの例が解かりやすいと思います。

Yahoo! AuctionがDomainKeysに対応したそうです。

ただしこのときユーザは、そのドメインが自分の登録しているサービスや金融機関等がもつドメインなのかどうか、を自分自身で知っている必要がある。

当り前ですがユーザがこのドメインは信頼できる、と知っていなければDomainKeysは役に立たないのです。

組織によってはやたらとブランドやサービス毎に新しいドメイン名を持ちたがる所があります。例えば

  • brand-a.jp, brand-b.jp 等商品ブランド毎にドメインを持つ
  • service-a.jp, service-b.jp 等サービスタイプ毎にドメインを持つ

等です。そして最悪なのが「組織ドメイン名+サービス・ブランド名」を使っている場合です。

  • brand-a-company.jp
  • service-a-company.jp

この様なドメインと使うと「私のサイト利用者をどうぞフィッシングしてください」と言っているようなものです。

googleやsony等の大企業が特定のサービスやブランド、gmailやplaystation等、を本気でプロモーションする等のケース以外は全て自社ドメインのサブドメインとするべきです。例え大企業でも出来る限り自社ドメインのサブドメインを使ったサイトを構築した方がユーザにとって親切です。

brand-a.jp や brand-a-company.jpではなく

  • brand-a.company.jp

とした方がユーザにとってドメインが信用できるかどうか判り易いのは明らかです。

しっかりとプロモーション、SEO対策を行えば自社ドメインのサブドメインとしてサービス、製品サイトを作っても何の問題もありません。中途半端にしかプロモーションしないのであれば新規の組織レベルドメインは有害でさえあります。不要/無用/有害なドメインが多すぎると感じるのは私だけでは無いと思います。

# ここではDomainKeysに対応したというニュースに対して
# コメントしていますが、httpsでも全く同じ問題が発生
# します。無用なドメインは排除するべきでしょう。
# 特に国際化ドメインは信頼できるサイトとしては乱用
# を防ぐために保持する事は避けられませんが、使用する
# べきでは無いと考えています。

Nessusがクローズドソースにライセンスを変更

このニュースは随分前(10月はじめ)のアナウンスですが先週末知りました。

Nessusはセキュリティ脆弱性スキャナーとして最も人気が高いオープンソース製品(GPL2)です。現在はVersion2系が最新リリース版ですが、多くの機能、性能が向上しているとされているVersion3系のソースコードは公開されないようです。

Nessus 3 is major enhancement of the key components of the Nessus engine – the NASL3 intepreter has been rewritten from scratch, the process management has changed to reduce the overhead of executing a plugin (instead of creating NxM processes, nessusd now only creates N processes), the way plugins are stored has been improved to reduce disk usage, etc…

Nessus 3 also contains a lot of built-in features and checks to debug crashes and mis-behaving plugins more easily, and to catch inconsistencies early.

As a result, Nessus 3 is much faster than Nessus 2 and less resource intensive. Your mileage may vary, but when scanning a local network, Nessus 3 is on average twice as fast as Nessus 2, with spikes going
as high as 5 times faster when scanning desktop windows systems.

Nessusはセキュリティ確保の為のスキャナーとして利用されますが、個々の脆弱性を検査するプラグインには度々不備が見つかっています。中にはコマンド実行を可能とする物も少なくありません。Nessus3のエンジン部分は1から書き直され、Nessus3ではスキャン性能が向上し動作がおかしいプラグインをより容易く検知できるようになっているようです。

Nessus 3 will be available free of charge, including on the Windows platform, but will not be released under the GPL.

Nessus 3 will be available for many platforms, but do understand that we won’t be able to support every distribution / operating system available. I also understand that some free software advocates won’t want to use a binary-only Nessus 3. This is why Nessus 2 will continue to be maintained and will stay under the GPL.

To make things simple :

  - Nessus 2 : GPL, will have regular releases containing bug fixes
  - Nessus 3 : free of charge, contains major improvements

問題のNessus3がクローズドソース製品になってしまう、という部分です。要旨は次の通りです。

  • Nessus3はWindow版も含め無料で利用できる
  • Nessus3のライセンスはGPLではない
  • Nessus2とNessus3はほとんどのプラグインを共有する
  • Nessus2はGPL版としてメンテナンスされる

Nessus2のメンテナンスも継続されるようですが新しい機能を利用するにはNessus3が必要になるようです。

何故クローズドソースにライセンスを変更するか?という部分ですが作者(セキュリティ系の製品・サービスを提供しているらしい)競争相手との競争に負けないようにするためだそうです。ソースを公開すると競争相手に取り込まれてしまい…. と言った状況になっている(なる?)らしいです。

Nessus2とNessus3はオープンソースの新しいビジネスモデルとしても興味深い点が多くあります。これからどうなっていくか注目ですね。

保護士認定試験

保護士といっても保護観察の保護司ではなく、個人情報保護士認定試験の保護士です。サンプルの問題が公開されています。12月8日に二回目の認定試験があるようです。

http://www.joho-gakushu.or.jp/piip/exam/piip-exam1-1.html
http://www.joho-gakushu.or.jp/piip/exam/piip-exam2.html

サンプルといっても第一回に出題された問題らしく2つ合わせて100問もあります。

http://www.joho-gakushu.or.jp/info/security.html

にも情報セキュリティ認定試験のサンプル問題のPDFへのリンクがありますね。

時間のある方は試してみてはいかがでしょう。

UHFのRFIDに意外な弱点

電磁波について勉強したことはあっても専門家ではないので「UHFは人体に吸収されやすい」事に起因する問題に気が付きませんでした。電波が人体に吸収されるためUHF RFIDを利用した万引き防止装置は有効に機能しない可能性があるそうです。山のように物を詰め込んでRFIDが読み取れなくても当たり前と思っていましたが、電子レンジで物が温まるのと同じ理由で人体に近いと読み取り精度が落ちるとは(少なくとも私には)盲点でした。

しかし、再書き込み可能なRFIDを利用すると非常に危険(30万のノートPCを300円で自動清算されると困る…)、色々な条件で読み取り精度が落ちる(沢山詰め込むと… 電波が水に吸収される…)、など専門家には解りそうな気がするのですが….

「専門家の言うことは信じるな」と言われますが、本当にそうだったりする事も多いですね。自分もそう言われないよう少なくとも自分の専門分野は取り組まなければ。

Detailed Firefox and IE vulnerability report

FirefoxとIEの脆弱性比較です。英語サイトですが表を見れば筆者の言いたいことは解ると思います。確かに最近はFirefoxの方が多くの脆弱性が見つかっています。リリース時期から考えてもFirefoxの方が安定性が低くても当然と思います。

http://secunia.com/advisories/16942/
でModerateなのでHRS攻撃に脆弱な程度ではあまり重大な脆弱性では無いという事になります。ブラウザ以外の環境に依存する攻撃であるため低いレベルの脆弱性と分類している事は理解できます。これをどう考えるか?は人によるでしょう。

ところで今でも私のお勧めはIEよりFirefoxです。
どのブラウザを使っていてもこまめにアップデートしないと常に危険、といえるのは間違い無いです。

速いSSH

SSHでのファイル転送は遅くて困る事があります。RabbitベースのCryptiCoreを採用したため、OpenSSHより2倍から8倍速いという事らしいです。

日本円でも買えるようですがエンタープライズ用という事で結構高いです。

クライアント – ¥17,756
サーバ – ¥92,234
http://www.ssh.com/company/sales/store/

音でキーロガー

普通キーロガーと言えばソフトウェア、キーボードの信号を直接ハードウェアで読み取る方法のどちらかですが、簡単な仕組みでキーボードをタイプしている音から入力をかなりの確率で推測できると論文が発表されたそうです。

私の好きな映画の一つ「ミッドナイトラン」でロバート・デニーロが電話を盗聴してダイアル音から通話先の電話番号を割り出すのと基本的には同じ手口です。

今後は防音室でキーボードを使いましょう(笑

#防音室じゃなくて本当に必要なのはユーザ名と
#パスワードだけに頼らない認証方法ですが

Firefoxに未パッチの脆弱性

ドメインに0xADが含まれているとヒープオーバーフローが発生するそうです。
個人的にはIDNは不必要と考えていますが、IDN関係のコードかな? IDN以外でこんなバグがあるとは思えない。

IDNはレジストラだけが儲かる仕組だと思います。一般ユーザやサイト運営に関わる人には全く利益無し、とまでは言いませんが不利益の方が利益を遥かに上回ると思います。IDNサポートは駆逐されて欲しい機能の一つですね。

追記:
http://security-protocols.com/modules.php?name=News&file=article&sid=2910

Technical Details:
The problem seems to be when a hostname which has all dashes causes the NormalizeIDN
call in nsStandardURL::BuildNormalizedSpec to return true, but is sets encHost to an
empty string. Meaning, Firefox appends 0 to approxLen and then appends the long
string of dashes to the buffer instead. The following HTML code below will reproduce
this issue:

A HREF=https:———————————————

Simple, huh? ;-]

パッチはここから
https://bugzilla.mozilla.org/show_bug.cgi?id=307259
というかこれに書いたときにはパッチは有りましたね。広くリリースされてはいませんが。IDNは手動で無効に設定しておいても良いかも。

network.enableIDN=false

回避策として公開されていますね。
https://addons.mozilla.org/messages/307259.html

XPIでインストールしなくても about:config をアドレスバーに入力して network.enableIDN=false に設定すればOKです。

オンライン取引を安全に実行する方法

先日のPHP関西セミナーで、管理者権限で動作しているスパイウェアなどがインストールされたPC上で、Web上のログインやフォーム送信の安全性を保障する方法は(説明した方法では)無いと言いましたがこれは変わりがありません。時間があまり無かったので補足しておいた方が良いと思える点を補足します。

まずパスワードですが、パスワードが盗まれても大丈夫な仕組みは昔からあります。ワンタイムパスワードと呼ばれる方法です。ログインするコンピュータでパスワード生成プログラムを実行するとパスワードの安全性が損なわれる為、通常液晶が埋め込まれたカード型のパスワード生成機等のデバイスを使います。ワンタイムパスワードを利用している場合パスワードが盗まれる事はありません。他のコンピュータからログインされてアカウントを不正に利用される危険性はほとんど無くなります。

ワンタイムパスワードを使えば安全か考えるとまだ安全とは言えません。正規のユーザがコンピュータを利用中にスパイウェア等がデータを書き換えてしまう危険性が排除されている事をWebサイト側では保障できません。現実的な脅威かは別として、例えば銀行のフォーム送信等でデジタル署名などを行っても安全性を保障する事はできません。管理者権限で動作しているスパイウェアがインストールされているコンピュータだけでトランザクションを行うと、スパイウェアが任意の時点でデータのすり替えを行い、本来送信しようとしている送信先とは別の送信先にお金を送信する、等の危険性はなくなりません。そもそも署名に必要な秘密鍵がコンピュータにインストールされている場合、スパイウェアは秘密鍵を盗む事が可能です。USBデバイス等で秘密鍵が絶対に読み取られないようなデバイスの場合、秘密鍵が盗まれる事はないかもしれませんが、液晶などの表示機能が無いと署名した取引情報が意図しているものかユーザは判別できません。

信頼できないデバイス、スパイウェアがインストールされたPC等、だけを使用して信頼できるオンライン取引を行う事は技術的には不可能なはずです、安全に使えない、と言うのでは困るのでより安全に取引を行う方法を考えて見ます。安全に取引を行うにはトランザクションを行うデバイス、通信が信用できる必要があります。今の環境であれば、携帯電話に取引情報を送信して、携帯電話上で取引情報を表示・確認してから直接送信するか、署名してからPCで送信する方法が考えられます。携帯電話は信頼できる、と言う前提が必要です。別に携帯電話でなくても信頼できるデバイスで取引情報を確認し、取引情報改ざんを防ぐ署名ができる仕組みであれば何でも良いです。USBで接続された表示機能付き署名デバイス等でもOKです。ワンタイムパスワードの仕組みを知っている方なら思い浮かぶアイデアと思います。

スパイウェアがオンライン取引の最中に取引データを改ざんし、表示された取引情報とは別の取引を行うリスクには対処できませんが、別のPCからの不正な取引を十分なほど防ぐには暗号表を使うのが良いと思います。セミナーでは暗号表は繰り返し暗号表を利用した取引を見ることによって解読できるので安全ではないと言いました。確かに暗号表の解読は、暗号表が固定的であれば、難しくありません。「固定的であれば」と条件が付くので「動的であれば」安全になります。ここでも信頼できるデバイスが必要になりますが、携帯電話メールが信頼できるとすると取引の度に新しい暗号表を携帯電話にメールで送信すればかなり安全といえます。頻繁に携帯電話に暗号表を送信する方法は現実的かつ実用的と思います。既に何処かで利用されているかな?

グラフィックテキストも安全ではない

昨日に引き続き「絶対安全」と誤解されているかもしれないセキュリティ対策の話です。

CSRF(クロスサイトリクエストフォージェリ)対策、アカウント作成ボット対策としてグラフィック上に書かれたテキストを読み取らせるサイトが多くあります。普通のOCRで読み取れるような簡単なグラフィックテキストでもコメントスパムなどのボット対策としては(今のところ)十分有効ですが、認証用のグラフィックテキストを生成するプログラムにはCAPTCHAが有名です。

単純なグラフィックテキストだとOCRで機械的に読み取られてしまう事は明白です。昨日、IRCで話をしていてOCR技術はかなり向上してきており単純な物は100%認識できてしまうようなってしまっている事を知りました。この分野はあまり気にかけていなかったので昨日PWNTHAと言うCAPTCHAなどで作成されたグラフィックテキストを読み取るツールを知りました。リンク先を見ると分かりますが、今では結構OCRで読み取りが難しいと思われるようなグラフィックでもかなりの高確率で読み取れるようです。

仕掛けは多少大掛かりになりますが、グラフィックテキスト情報を人間に読ませる攻撃方法も考案されています。例えば、こんな感じです。

前準備:音楽、映画、アダルトコンテンツなど多くのネットユーザが参照したくなるWebサイト(以下、「解読サイト」)を用意する。

1. プログラムで攻撃対象のWebサイトのグラフィックテキスト付きページを開きページを保存する。
2. グラフィックテキストを解読サイトのコンテンツダウンロードの認証キーとしてユーザに解読させる。
3. ユーザが解読してくれたテキストを攻撃対象のWebサイトの認証キーとして利用する。

このような手法を用いられた場合、グラフィック上に記述されたテキストや写真情報を使った防御策も完全とは言えません。

セキュアキーボードは安全ではない

SSLが流行しはじめた頃、「このサイトはSSLを使っているので安全です」とうたっていたサイト多く見かけました。これが大嘘であった事は周知の事実となっていると思います。

最近セキュリティ対策として「セキュアキーボード」と呼ばれている「ソフトウェアキーボード」が流行しつつあります。特に金融機関を中心に急速に浸透してきています。ソフトウェアキーボードとはWeb画面上に口座番号・暗証番号などを入力するボタンを表示してID情報を入力する仕組みです。残念ながら「セキュアキーボードを使っているので安全です」とうたっているサイトも大嘘をついている事になります。

セキュリティ関連MLではどのようにセキュアキーボード(ソフトウェアキーボード)を破るか話題になっていました。この対策は簡単に敗れる事が知られています。スクリーンラッパーという名称になる(?)ようですが、クリックした瞬間の画面イメージを攻撃者に送信する、という単純な手口でセキュアキーボードは破られてしまいます。すこし考えれば直ぐに破り方くらい分かると思うのですが何故か「セキュアキーボード」(安全なキーボード)と言う名称が付いているサイトが多くあります。

スクリーンラッパー付きのスパイウェアがいつ頃出回り始めるかな、と思っていたらもう出回っているようです。セキュアキーボードは”古い”キーロガーだけを使うスパイウェアには有効ですが、新しいスパイウェアには無力です。「セキュア」キーボードという名称は利用者に「安全である」と錯覚させる呼び名と思います。直ぐにセキュアキーボードや安全と思わせるような名称は使わないようにした方が良いと思います。

やはり基本に忠実にスパイウェアをインストールされないようにするしか本当に有効な方法は無いです。しかし、クライアントにスパイウェアをインストールされていない事をWebサイト側から確認することは不可能です。サービスを提供しているサイトは非常に悩ましいですね。

追記:ちなみにスパイウェアを植えつけるWebサイトと認知されているサイトは900ちょっとだそうです。私が見た統計情報にはjpドメインのサーバはありませんでしたが、用心は必要でしょう。

DNSサーバを使ったユーザトラッキング

前からちょくちょく見かけていたのですが最近はDNSサーバを使用しユーザトラキングを行っているSPAMメールがどんどん増えているように思えます。

SPAMMERとしてもどのどのメールアドレスからは反応(クリック)があったのか知りたいので最も安直な手口として

http://example.com/?u=user@example.com

の様なメールがありました。さすがにこれではトラッキングしていることがばればれなので

http://example.com/?id=1234

とか

http://example.com/?prod_id=1234

等とトラッキングしている事を判りづらくする試みは行われていました。ちょっとコンピュータ(Web)を知っている方ならトラキングを行っている(行える)事は明らかなので、最近はドメイン名も使うSPAMMERも増えてきたようです。

http://tracking_id.example.com/
tracking_idはユーザを特定できるIDとなる任意文字列

の様な形式URLが使われています。こんな事をしても全部のサーバ名を作るのが大変では?と思うかも知れませんがDNSサーバによってはワイルドカードが使用できます。

*.example.com 10.10.10.10

の様な定義ができるのです。ユーザがアクセスしてきたらアクセスしてきたHOST情報からユーザを特定し記録した後、別のサイトにリダイレクトする、等の方法を使っているはずです。
# リダイレクトはしてもしなくてもどちらでも良いです。念のため。

DJBDNSユーザなら誰でも思いつく方法と思いますが、広まるまでに時間が必要でしたね :p

Oracleはセキュリティホールを放置している?

CNET Japanの記事によるとドイツの開発者がOracleは2年以上セキュリティーホールを放置していると主張しているとしています。

先日、OracleはE-Business Suiteに複数の脆弱性に対するパッチを公開しましたが

http://www.securityfocus.com/bid/10871

によるとこれも1年近く対策に時間を要したようです。
この状況からすると2年以上セキュリティホールを放置している、とする主張の信憑性も高いと思います。真実はどうなのか気になるところです。

もう少し調べて見ると上記のBugTraq IDはさらに別の脆弱性もこのIDに含まれているようにも見えます。いろいろ出てきそうな雰囲気ですね。

ちなみに今回リリースされたパッチ郡にはリモートからの任意コード実行、SQL Injectionを防ぐパッチが含まれているそうです。