カテゴリー: Security

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

    アメリカではスパイウェア(キーロガー)によると思われる被害が急増しています。日本でもスパイウェアにより情報を収集し、銀行口座から不正の送金される被害が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

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

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

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

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

  • DOM Based Cross Site Scripting

    メモ。DOMベースのXSSを解説したページが新しく公開されています。

    要旨はDOMを使う場合、

    – document.location
    – document.URL
    – document.referer

    に注意、ということ。

  • .mobiドメイン承認

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

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

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

  • 悪魔の双子

    「悪魔の双子」という攻撃はセキュリティに詳しい方ならご存知と思いますが、あまり一般的に認知されていないような気がしてきたので簡単に書いておきます。日本語版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のアクセスポイント偽装をあらわす用語として使われていたように思えます。どうだったかな?)

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

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

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

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

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

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

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

  • HTTP Request Smuggling Attack

    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を参照してください。

  • D.J.Bernstein氏のセキュリティホールコースのfinal exam.

    qmail, djbdnsで有名なD.J.Bernstein氏の昨年末のセキュリティホールコースのfinal exam.がPDFで公開されています。

    UNIX/Cプログラマ向けの試験です。結構難しいです。
    UNIX/Cプログラマの方は一度試してみる価値があるテストです。

    さらにこのコースの説明(最初のPDF)を見てみると成績の60%は新しいセキュリティホールを10個見付けることによって決まる、と書いてあります。さすがDJB :)

  • 分散リファラスパム

    来ているところには前からアクセスがあったのだと思いますが、Botnetを利用したと思われるリファラスパム攻撃が急増しています。データベースに載せられたのかもしれませんね。

    ソースIPが広範囲に分散しています。IPアドレスがばらばらなのでBotnetを利用していると思われるます。自分のネットワーク帯域ではないのでリファラスパムが有効かどうかも確認していないようです。

    スパムメールの半分はBotnetから送られていると言われていますが、Webの帯域の半分はリファラ/コメントスパムのトラフィック、なんて事にならなければ良いのですが…

    本当に面倒な世の中になりましたね…

  • XMLRPC for PHPにセキュリティーホール

    Secuniaから”Highly Critical”レベルとされるアドバイザリが出ていたのでxmlrpc-epiモジュールのことかと思いましたが、このモジュール利用したPHPスクリプトライブラリの脆弱性でした。

    http://sourceforge.net/projects/phpxmlrpc/

    利用されている方は出来るだけ早くアップデートした方がよいようです。

  • allow_url_fopen

    追記:
    現在のPHPではリモートファイル読み込みを制御するphp.ini設定としてallow_url_fopen(URL等のファイルとして読み込むフラグ)とallow_url_include(URLなどをPHPスクリプトとして読み込むフラグ)があります。php://input(標準入力用のURL。Webアプリの場合、POSTリクエストなどが読み込める)もallow_url_include=Offでは利用できません。このためallow_url_include=Offの場合、リモートスクリプトからの読み込みを防止できます。

    基本的には

    • allow_url_includeは常に無効(JSONなどでなくPHPスクリプトとしてリモートデータを読む、などの場合は局所的に有効化)
    • allow_url_fopenは全く必要ないなら無効

    とすると良いでしょう。

    PHPを使っている方はHTTP/FTP/SSH等のプロトコルでリモートサーバ上のファイルをローカルファイルの様に読み書きできる事をご存知と思います。この機能はphp.ini設定のallow_url_fopenディレクティブで有効/無効を設定できるようになっています。PHP 4.3.4より前のPHPではこの機能のスクリプト中からも無効/有効に設定を変更する事ができました。(INI_ALLの設定項目であった)

    驚いたことにPHP 4.3.4からphp.iniからしかこの設定を変更できなくなってしまいました。(INI_SYSTEMの設定項目になった)誰かがセキュリティ強化を目的として変更したのだとは思いますが、セキュリティも強化できず、有用なリモートファイルアクセス機能も使えなくする非常に拙い変更です。

    例えば、phpBB(BBSアプリケーション)ではinclude/require文に不適切に処理されたユーザ入力が利用されている為、リモートスクリプトを読み込み実行できてしまう非常に深刻なセキュリティ上の問題がまた最近見つかりました。phpBBはallow_url_fopen機能が無効であっても動作するので

    allow_url_fopen = Off

    と設定するか必ず読み込まれる設定ファイルで

    ini_set(‘allow_url_fopen’, 0);

    とすると、phpBBのようなアプリケーションでも比較的安全に運用することができました。

    しかし、allow_url_fopenがINI_SYSTEMの設定項目になった為、前者の方法を取ると他のアプリケーションで、場合によっては非常に有用な、allow_url_fopen機能を使えなくなってしまいました。後者の方法は、特定のアプリケーションのみの設定を変更するのに有効ですが、INI_SYSTEM設定項目であるため実際には無効に設定できなくなってしまいました。

    セキュリティ上の意味は容易に理解できるであろうと、internals@list.php.net にallow_url_fopenの設定を

    デフォルトOFF
    INI_ALLへ変更

    するように提案して見たところ議論が結構荒れています…
    この設定が安全かつ不必要な機能制限が無く、最も良い設定と思うのですが…

    # allow_url_fopen_includeのようにinclude/require文用の設定
    # を追加するのも良いですが、デフォルトOFF、INI_ALLであるべき
    # と思います。

  • 不正なJavaScriptによるダイアログの表示サンプル

    先日IEの仕様ですに書いた問題とはどういう物か、百聞は一見にしかず、実際に見るのが良いと思います。

    Secunia(ここからのアドバイザリは多いですね)がレポートした問題で、この不具合の動作をテストするページも用意されています。どういう訳かニュースサイトなどではこのURLが紹介されていない場合が多いようなので紹介する事にします。

    http://secunia.com/multiple_browsers_dialog_origin_vulnerability_test/

    このページの

    Start the test:
    Test Now – Left Click On This Link

    「Left Click On This Link」を未対策のブラウザでクリックするとパスワード入力を要求するダイアログが開きます。

    ポイントは「Left Click On This Link」は http://www.google.com/ にリンクされていること、クリックした後のダイアログ表示動作がいかにも http://www.google.com/ からのダイアログの様に表示されてしまうことです。どんなにセキュリティに精通したWeb開発者がWebサイトを開発してもこの攻撃に対処できません。ブラウザ側の問題だからです。
    # 「このサイトはポップアップを利用していません」と注意を促すことは
    # できますが、対策とは言えないでしょう。

    これにユーザが騙されるか? というリスクへの対策が今問われています…
    送信元が不明なダイアログやWindowの利用は注意してください、と言うだけでは不十分であること明らかではないでしょうか?

    しかも、この問題を悪用するのは簡単です。
    ほんの少しJavaScriptを知っていれば誰でも悪用できます。

  • IEの仕様です

    最近話題になっている、信頼できるサイトからのダイアログの様に見せかける事ができるためフィッシングに利用される可能性がある問題、に対するマイクロソフトの対応です。

    仕様として見て見ない振りしても問題は消えません。また一つIEを使わない理由が増えましたね。


    成人の6割以上が銀行預金残高を主にインターネットで確認–米調査
    という状況を考えると「仕様です」と言って切り捨てる訳には行かないと思います。

    ブラウザのメンテナンスが大変であればいっそ「IEはもう新しいバージョンはリリースしません」と宣言してしまえばよいのではないかと思います。

  • Javaのセキュリティホール

    このセキュリティーホールは1週間ほど前に報告されている問題で、ちょっと古いですがメモとして残しておきたいので書いておきます。

    The flaws are “highly critical,” security monitoring company Secunia said in an advisory posted Tuesday.

    自動更新を有効にしている場合、アップデートが自動的に行われます。私のPCも先週「アップグレードしてください」と表示されました。

    http://sunsolve.sun.com/search/document.do?assetkey=1-26-101749-1
    http://sunsolve.sun.com/search/document.do?assetkey=1-26-101748-1

    適当なニュース記事を探そうと、CNet Japanを見ても記載されていないので本家を見て見ると載っていました。日本語版でも載っていたほうが良い様な気がします。

  • 3つの脅威

    米国の政府機関では、スパム、フィッシング、スパイウェアというインターネット上の3つの脅威に対処する体制が整っていない、と米政府の監査官らは結論づけた。

    最近まで外部からの攻撃で身近なセキュリティ上の脅威といえばウィルスやワームでしたが、今はスパム、フィッシング、スパイウェアが身近で最も大きな脅威であると思います。(ウィルス対策に力を入れなくて良いという事ではありません。念のため)

    これら3つの脅威への対応は、ウィルス対策に比べると、ユーザ教育が非常に重要になってきます。システム的に対処を行いづらいため対策コストが多く必要になる割には高い効果も期待できません。

    企業では、ウィルスを同様に、スパイウェアがPCに紛れ込まないシステム管理を行う事も十分可能です。しかし、システムとして対応できない部分、例えば非常事態が発生した場合の対応のマニュアル化などはやらなければならない事は山積みです。

    最近、ファミリーレストランの店長を、クレームなど、何らかの理由で外部に呼び出し、店長が留守のすきにアルバイト店員を騙して売上金を奪う詐欺が目立ってきているようです。

    クレームを装って店長を呼び出し、残った店員から現金を受け取るという手口はソーシャルエンジニアリングを利用した犯罪の典型例です。スパム、フィッシング、スパイウェアを利用する攻撃もソーシャルエンジニアリング攻撃といえます。最大の問題はソーシャルエンジニアリングに対してウィルス対策ソフトウェアのような特効薬がないことです。困ったものです…