ブログ

    発行
     
      • ハッカーたちは、企業のネットワークに侵入しようと、飽くことのない創意を発揮し続けています。実際、最近のマルウェア攻撃のなかには、企業の活動を停止に追い込み、関係者から金銭を奪ったり、大勢の消費者の信用を損ねたりして、ニュースの見出しを賑わせたものもあります。こうした攻撃があるたびに明らかになるのが、サイバー犯罪者も進化を続けており、多くの企業のセキュリティ防御をすり抜ける脅威を生み出しているということです。高度なマルウェアともなれば、セキュリティ防御を感知して無力化するという、生物としてのウイルスなみの性質まで備えている場合があります。

        クラウドアプリケーションの導入が広がり、従業員が使うモバイルデバイスも急増するなかで、ハッカーがこれほど執拗な活動を続けている以上、企業は増え続ける高度なマルウェア攻撃から身を守る手段を、新しく見いださねばなりません。これはかなり厄介な問題です。デバイスやアプリケーション、ユーザーによって異なる脅威にどこからでも対処できるソリューションは、どこにあるのでしょう。その答えは、空を見上げていて見つかるものではありません。しかし、視線を雲に、クラウドに転じれば、企業向けの革新的なセキュリティソリューションをどこで探せばいいのか、手がかりがそこにあります。

        問題: 進化し続ける脅威の性質

        ネットワークセキュリティが進化するように、マルウェアも進化します。今まで以上に認識能力と適応性が高くなり、新しい拡散経路を探りながら、動作検出を回避するように変質しているのです。具体的な進化の例をあげてみましょう。

        仮想マシンの認識 ― 仮想のサンドボックス環境で動作していることを感知でき、自身を偽装できるマルウェアを作成する攻撃者が増えています。

        ファイルも URL も多形態に ― マルウェアファイルは、感染性ウイルスのように形態変化や変異をとげ、シグネチャベースの検出をすり抜けるようになってきました。自動化したシステムを利用して、攻撃者は絶えずファイルの見かけを変え、そのファイルをユーザーの防衛線に向けて大量に送りつけます。どれかが防衛線を突破し、動き始めることを期待しているわけです。ドメイン生成アルゴリズム(DGA)を利用して数学的に新しいドメインを計算すれば、URL でも同じような操作ができ、ブラックリストのような技術では対処できなくなります。

        多段階、多経路の攻撃 ― 巧妙なサイバー犯罪者になると、多段階の攻撃を用意して企業の防衛網を突破します。攻撃者は Web ベース、メール、ファイルベースの侵入を選んで自由に組み合わせ、狙った結果を達成しています。

        通信の暗号化 ― ネットワークセキュリティシステムの大部分は、暗号化されたデータをスキャンしてマルウェアを検出する機能を備えていません。そこに目をつけた攻撃者は、組み込んだマルウェアと、リモートのコマンド & コントロール(C&C)サーバーとの間で通信トンネルを確立する際に SSL を使うようになりました。

        紛らわしいファイル形式 ― マルウェアは、無害なファイルに偽装することがあります。たとえば、JPEG に偽装し、実際には内部に実行可能ファイル(.exe)が仕込まれたマルウェアファイルが知られています。あるいは、後から実行可能ファイルに変化し、ネットワークにマルウェアをまき散らすマルウェアファイルもあります。

        ユーザー操作による起動 ― 正規のソフトウェアになりすましたマルウェアは、わかりやすく親切そうなダイアログボックスを表示して、ソフトウェアのインストールを求めます。ユーザーがインストールを許可してしまうと、すかさず動作し始めるという仕組みです。  

        標的を限定した独自のマルウェア ― 標的を限定した「スピア型フィッシング」攻撃に組み込まれるマルウェアもあります。あるユーザーに狙いを定めると、その標的だけに特有の情報を利用してファイルを開かせようとします。ファイルが開かれると、攻撃者は特定の情報を探し始めます。

        クラウド(クラウド型セキュリティ)、登場

        こうして脅威が高度に発達してくると、それに対処するために、脅威に対する防衛策の見直しが必要になってきます。しかもその防衛策は、企業が Web や企業向けアプリケーションをどのように利用しているのかという現実に即したものでなければなりません。従業員が広範囲に広がると、ラップトップやモバイルデバイスを使って直接インターネットに接続し、SaaS アプリケーションを利用するようになります。そうなれば、クラウド型のセキュリティと脅威防止を視野に入れることが必要になってきます。クラウド型セキュリティは、プロビジョニングも簡単で、あらゆる Web トラフィックについてセキュリティと脅威防止に取り組むことができます。サブスクリプションベースのサービスなので、需要の増減に合わせてスケールアップとスケールダウンが容易だというメリットもあります。配備が簡単とは言え、必要な範囲で最高レベルの脅威防止を提供できるよう配慮が必要です。シマンテックによるクラウド型セキュリティサービスを詳しくご覧になれば、シマンテックのソリューションが真にエンタープライズクラスと評価されている理由をご理解いただけるでしょう。

        解決策: シマンテックのクラウド型セキュリティ、マルウェア解析サービス

        シマンテックの研究開発部門は、進化し続ける新しい攻撃技術に対処するために、シマンテックを強化することに全力を注いでいます。高度な解析手法から、検出技術をすり抜けようとするマルウェアの特定と無効化まで、多層のシステムをシマンテックは開発しました。こうした多層技術で、既知の脅威を遮断し、新しい未知の脅威も解析して、進化した攻撃に備えます。システム全体が、エンタープライズクラスの保護を提供しつつ、誤認率を最小限に抑えるという前提で設計されています(セキュリティやインシデント対応の担当者が、誤報への対処で貴重な時間を無駄にしないために)。

        SymantecCloud_JA_0.png

        Symantec Global Intelligence Network を活用する Web セキュリティサービス

        シマンテックがクラウドで提供する Web セキュリティサービス(WSS)には、GIN(Global Intelligence Network)からデータが供給されています。GIN は、民間として世界最高峰のサイバー防衛用脅威インテリジェンスサービスです。GIN のデータをもとに、企業は細分化されたカテゴリに URL を分類し、所定のリスクスコアを確認することができます。ネットワークには、これまでに確認も分類もされていない Web サイトが 10 億単位で存在し、消費者が送受信するメールは 1 日あたり 20 億通を超えています。シマンテックは、15,000 社の企業と 1 億 7,500 万の消費者およびエンタープライズエンドポイントから集められた脅威情報と遠隔測定データを利用して、それを分類し解析します。シマンテック独自の専門技術と解析手法でそうした情報を利用して、「既知の不良」ファイルや、企業が避けるべきサイトが定義されていきます。Web とファイルアクセスに関する制御ポリシーを Symantec WSS で設定すれば、「既知の不良」は入り口でとどめられ、社内に害が及ぶことはありません。Symantec WSS では、コンテンツ解析機能も利用します。二重のマルウェアエンジンを使い、ブラックリスト/ホワイトリストのファイルも比較して、危険性のあるファイルについてさらに詳しい解析が実行されます。

        シマンテックのマルウェア解析サービス

        マルウェアの作成者が仮想環境とエミュレーション環境をどちらもすり抜けることはきわめて困難なので、シマンテックのマルウェア解析サービスは、Symantec WSS と連携して動作解析とサンドボックス処理機能を備え、高度な脅威の検出と防止に対応しています。ここで使われるのが、エミュレーションと仮想化を組み合わせて悪質なコードを識別する強力な機能です。仮想化が実行される仮想マシンはフルライセンス版の Windows なので、ユーザーはどんなアプリケーションでもインストールできます(Office、Adobe、Quicken、さらにはカスタムアプリケーションも)。この仮想マシンを、シマンテックは Intelligent VM(iVM)と呼んでいます。エミュレーションによるサンドボックス環境は Windows ソフトウェアではなく、Windows ライクな API に基づいて完全に再設計されたコンピューティング環境です。完全制御されたこの人口環境であれば、マルウェアにも本当のコンピュータに侵入したと思い込ませることができます。

        クラウドなら簡単。ぜひお試しください

        急速な進化をとげながら連日ネットワークを攻撃してくる高度な脅威に対処する―そのときに必要な保護機能を提供するというのが、Symantec WSS と、そこに統合される Symantec Malware Analysis Service の設計思想です。企業の資産を保護するサブスクリプションサービスについて詳しくは、ぜひお問い合わせください。「既知の良品」を通過させ、「既知の不良品」を遮断するとともに「未知のもの」は正確に解析する信頼性。シマンテックにお任せください。

        詳しくはこちらをご覧ください。

        【参考訳】

        • Products
        • Products and Solutions
        • DigiCert Code Signing
      • GHOST脆弱性(CVE-2015-0235)の解説

        May 25 2016, 10:04 AM

        作成者 : Masato Hayashi 0

        このブログではウェブサイトやその上で動作しているウェブアプリケーションの脆弱性について紹介すると共に注意喚起をする目的でまとめられています。

        今回は、Linux等で使用されているC言語向けライブラリglibcの脆弱性であるGHOST(CVE-2015-0235)について解説をしています。

        ※なお、内容に関しましてはHASHコンサルティング株式会社の徳丸 浩様に監修いただいています。

        +++++++++++++++++++++++++++++++++++++++++++++++

        GHOST脆弱性(CVE-2015-0235)

        ■概要

        Linux OSの内部で使用されているライブラリglibc(GNU C ライブラリ)にgethostbynameという関数があり、ホスト名からIPアドレスを求める目的で利用されています。このgethostbyname関数には、処理に必要なメモリのバイト数計算に誤りがあり、バッファオーバーフロー攻撃が可能となることが2015年1月に発見されました。この脆弱性はGHOSTと呼ばれます。

        gethostbyname関数を利用しているソフトウェアのうち、メール配信サーバーEximでは実際に任意コード実行が可能であることが実証され、その他のソフトウェアでも影響があるものが報告されています。

        ■攻撃のイメージと影響

         以下のPHPスクリプトをコンソールにて実行します。

        <?php

            gethostbyname(str_repeat('0', 1027));

            gethostbyname(str_repeat('0', 1028));

        str_repeat関数は、文字列を指定の数字だけ繰り返す関数です。このためgethostbyname関数の引数は、それぞれ 0 を1027個並べたものと、0を1028個並べたものになります。このスクリプトの実行結果は以下のとおりです。

        $ php gethostbyename-vul.php

        *** glibc detected *** php: realloc(): invalid next size: 0x08b0b118 ***

        ======= Backtrace: =========

        /lib/libc.so.6[0x92de31]

        /lib/libc.so.6[0x9330d1]

        /lib/libc.so.6(realloc+0xdc)[0x93326c]

        【後略】

         不正なメモリ操作が検知され、PHPが異常終了していることがわかります。

        以上はPHPでの脆弱性の例ですが、メール配信サーバーEximを使っている場合、インターネット経由の攻撃により、任意のコードが実行できることが確認されています。

        ■脆弱性による影響

         Eximを使っている場合、外部から任意コードが実行され、結果として以下の影響を受ける可能性があります。

        • サーバー内のファイルの閲覧、書き換え、削除
        • 不正なシステム操作(ユーザアカウントの追加、変更、その他)
        • 不正なプログラムのダウンロード、実行
        • 他のサーバーへの攻撃(踏み台)

         Exim以外では任意コード実行が検証されてはいませんが、前述のPHPの例のようにソフトウェアがクラッシュ(異常終了)したり、最悪ケースでは任意コードが実行されてしまう可能性があります。

        ■脆弱性の有無の確認方法

         この脆弱性の発見者であるQualys社が脆弱性判定用のプログラム(C言語ソース)を公表しています。

        https://www.qualys.com/research/security-advisories/GHOST-CVE-2015-0235.txt

        $ gcc GHOST.c         コンパイル

        $ ./a.out                    実行

        Vulnerable               Vulnerableと表示されたら脆弱

        $

        ■対策

         各Linuxディストリビューションから対策パッチが提供されていますので、該当するパッチを適用してください。

        ■参考文献

        Qualys社のアドバイザリ(英文)

        https://www.qualys.com/research/security-advisories/GHOST-CVE-2015-0235.txt

        独立行政法人情報処理推進機構(IPA)の注意喚起

        https://www.ipa.go.jp/security/announce/20150129-glibc.html

        • Products
        • DigiCert Code Signing
        • Vulnerability Assessment
        • Products and Solutions
        • Symantec Website Security
      • ShellShock(CVE-2014-6271)の解説

        May 25 2016, 9:32 AM

        作成者 : Masato Hayashi 0

        このブログではウェブサイトやその上で動作しているウェブアプリケーションの脆弱性について紹介すると共に注意喚起をする目的でまとめられています。

        今回は2014年9月に公表されたGNU Bashの脆弱性について解説しています。この脆弱性はShellShockと呼ばれます。

        ※なお、内容に関しましてはHASHコンサルティング株式会社の徳丸 浩様に監修いただいています。

        +++++++++++++++++++++++++++++++++++++++++++++++

        ShellShock(CVE-2014-6271)

        ■概要

        UnixやLinux等のOSでは、ユーザーからのコマンドを解釈実行するプログラムとしてシェルが用いられます。シェルの中でもLinuxやMac OS X等に標準で採用され、もっとも広く用いられているものにBashがあります。

        他のシェル同様Bashにはプログラミングの機能があり、関数を環境変数により外部から指定することができます。この機能に脆弱性があり、環境変数経由で、外部から指定された任意のプログラムを実行できてしまいます。

         Bashに対して外部から環境変数を指定する方法の典型例はCGIプログラムによるものですが、これ以外にメール受信など複数の方法が指摘されており、9月以降現在まで、攻撃が活発に継続されています。

        ■攻撃のイメージと影響

         Perl言語により記述されたCGIプログラムがあり、以下の部分によりメール送信をしているとします。以下のプログラムは外部からのパラメータ指定などはなく、一見すると攻撃の余地はありません。

        system('/usr/sbin/sendmail admin@example.jp < mail.txt'); 

         しかし、このCGIプログラムを起動する際に、ブラウザのUser-Agentを以下のように指定することで攻撃ができてしまいます。

        () { :;}; /bin/cat /etc/passwd

         CGIプログラムに対しては、User-AgentなどHTTPヘッダは環境変数経由で渡されます。そして、CGIプログラムからsendmailコマンドを起動する際に、system関数の実装上シェルが起動されます。このため、デフォルトシェルとしてbashが指定されている環境では、上記のアクセスの結果 /etc/passwdの内容が表示されます。

        root:x:0:0:root:/root:/bin/bash

        daemon:x:1:1:daemon:/usr/sbin:/bin/sh

        bin:x:2:2:bin:/bin:/bin/sh

        【以下略】

        ■脆弱性による影響

         この脆弱性による影響の例として下記がありますが、これらに限定されるわけではありません。

        • 秘密情報の漏洩
        • データの改ざん
        • 他サイトへの攻撃の踏み台

        ■脆弱性の有無の確認方法

         Bashのプロンプトから以下を実行してください。

        $ env x='() { :;}; echo this bash is vulnerable' bash -c :

         下記が表示された場合、ShellShock脆弱性があることになります。

        this bash is vulnerable

        ■対策

         Bashの最新版を導入するか、Bashの最新のパッチを適用することで対処できます。ShellShock対応の初期のパッチは対策が不十分という指摘があるため、必ず最新のパッチを全て適用するようにしてください。

        なお、「シマンテック クラウド型WAF」では、ShellShock攻撃からウェブサイトが攻撃を受けるのを防ぐことができます。

        ■参考文献

        JVNVU#97219505

        GNU Bash に OS コマンドインジェクションの脆弱性

        http://jvn.jp/vu/JVNVU97219505/index.html

        • Products
        • DigiCert Code Signing
        • Vulnerability Assessment
        • Products and Solutions
        • Symantec Website Security
      • POODLE (Padding Oracle On Downgraded Legacy Encryption; CVE-2014-3566)の解説

        May 26 2016, 2:46 AM

        作成者 : Masato Hayashi 0

        このブログではウェブサイトやその上で動作しているウェブアプリケーションの脆弱性について紹介すると共に注意喚起をする目的でまとめられています。

        今回はSSL3.0の脆弱性POODLE (Padding Oracle On Downgraded Legacy Encryption; CVE-2014-3566)について解説をしています。

        ※なお、内容に関しましてはHASHコンサルティング株式会社の徳丸 浩様に監修いただいています。

        +++++++++++++++++++++++++++++++++++++++++++++++

        POODLE (Padding Oracle On Downgraded Legacy Encryption; CVE-2014-3566)

        ■概要

        インターネット上の通信暗号のプロトコルとして、従来からSSL(Secure Sockets Layer)が広く使われています。このSSLの一番新しいバージョン3.0を効率的に解読する方法が今年の10月に米Google社のセキュリティチームにより公表され、POODLE(Padding Oracle On Downgraded Legacy Encryption)と命名されました。POODLEを用いるとSSL3.0上のHTTPS通信の一部が解読される可能性があります。

        ■攻撃のイメージと影響

        SSL3.0による暗号化では、CBC方式のブロック暗号を選択することができ、その場合には一定の長さのブロックという単位で暗号化が行われます。対象のデータサイズはブロック長の倍数とは限らないため、ブロックの余白の部分にはパディングというダミーのデータを配置します。SSL3.0のパディングについては厳密なチェックが仕様として要求されていないため、パディングを巧妙に操作することにより、1回の通信で1/256の確率で1バイトのデータが復号できます。これを繰り返すことにより、数十バイトのデータを得ることができます。クッキーやBASIC認証のパスワードが攻撃の対象になります。

         POODLE攻撃を行う前提として、利用者の端末からの通信を外部から操作できることが必要となります。そのような性質を持つプロトコルとしてHTTPがあります。一方、HTTP以外のメールやデータベースのプロトコルではPOODLEの影響は受けません。

        ■脆弱性による影響

         この脆弱性による影響として、通信の一部が第三者に漏えいする可能性があります。典型的な影響の例としては、クッキーの漏洩によるなりすましや、BASIC認証のIDとパスワードが漏洩して不正ログインなどが考えられます。

         攻撃の性質上、HTTP以外のメール等の暗号を解読することはできません。また、クッキーやHTTP認証(BASIC認証やDIGEST認証)を使用していないサイトは影響を受けにくいと考えられます。

        ■脆弱性の有無の確認方法

         WebサーバーのPOODLE脆弱性を検証する方法として、SSL3.0が有効になっているかどうかで判定することができます。例えば、Windowsのインターネットオプションの「詳細設定」タブで「SSL3.0を使用する」を有効に、その他のSSLおよびTLSを有効にしない設定にして、対象サイトをInternet Explorer(IE)でHTTPSアクセスします。正常にアクセスできた場合は、SSL3.0が有効ですので、POODLE脆弱性があることになります。

        チェックの後は必ずインターネットオプションを元に戻しておいてください。

        ■対策

         POODLE脆弱性はプログラムのバグではなくプロトコル自体の脆弱性であるため、パッチ適用等では根本的に修正することはできません。POODLEの影響を受けるウェブサイトの場合、SSL3.0を無効にしTLSのみを有効にすることで、POODLE脆弱性を受けなくなります。

        なお、「シマンテック クラウド型WAF」では、POODLE脆弱性によりウェブサイトが攻撃を受けるのを防ぐことができます。

        ■参考文献

        更新:SSL 3.0 の脆弱性対策について(CVE-2014-3566)

        JVNDB-2014-004670 OpenSSL およびその他の製品で使用される SSL プロトコルにおける平文データを取得される脆弱性

        http://jvndb.jvn.jp/ja/contents/2014/JVNDB-2014-004670.html

        JVNVU#98283300 SSLv3 プロトコルに暗号化データを解読される脆弱性(POODLE 攻撃)

        https://jvn.jp/vu/JVNVU98283300/index.html

        • Products
        • DigiCert Code Signing
        • Vulnerability Assessment
        • Products and Solutions
        • Symantec Website Security
      • ミドルウェアの不具合に起因するサービス妨害攻撃の説明

        May 26 2016, 1:57 AM

        作成者 : Masato Hayashi 0

        このブログではウェブサイトやその上で動作しているウェブアプリケーションの脆弱性について紹介すると共に注意喚起をする目的でまとめられています。

        今回は、ミドルウェアのバグに基づくサービス妨害攻撃(Denial of Service; DOS)を受けやすい脆弱性について解説をしています。

        ※なお、内容に関しましてはHASHコンサルティング株式会社の徳丸 浩様に監修いただいています。

        +++++++++++++++++++++++++++++++++++++++++++++++

        ミドルウェアの不具合に起因するサービス妨害攻撃

        ■概要

        サービス妨害(DoS)攻撃という手法があります。細工を施したリクエストや大量のリクエストをサーバに送信することにより、サーバの動作を遅くしたり、場合によってはサーバーを停止させる攻撃のことです。DoS攻撃では情報の漏洩やデータの改ざんは通常起こりませんが、サーバ停止の状況によっては、ファイルの一部が破損する場合はあり得ます。

        DoS攻撃としてよく用いられる手法にはネットワークの問題を悪用したものが多いのですが、それ以外にミドルウェアやアプリケーションの不具合を悪用する方法もあります。その一例として、Apacheの不具合を悪用したApache Killer(CVE-2011-3192)やPHPやJava等の言語システムの不具合を悪用したhashdos(CVE-2011-4885等)があります。

        ■攻撃のイメージと影響

         以下はApache Killerの送信するHTTPリクエストです。一部を割愛しています。Rangeヘッダに攻撃の特徴があります。

        GET / HTTP/1.1

        Host: example.jp

        Range: bytes=0-,5-0,5-1,5-2,5-3,5-4,5-5,5-6,5-7,5-8,5-9,5-10,5-11,5-12,5-13,5-14,5-15,5-16,5-17,5-18,5-19,5-20,5-21,5-22,5-23,5-24,5-25,5-26,5-27,5-28,5-29,5-30,5-31,5-32, 【中略】 5-1281,5-1282,5-1283,5-1284,5-1285,5-1286,5-1287,5-1288,5-1289,5-1290,5-1291,5-1292,5-1293,5-1294,5-1295,5-1296,5-1297,5-1298,5-1299

        上記リクエストを脆弱性のあるApacheが受け取ると、CPU使用量、メモリ使用量の両方が肥大化し、メモリ不足とCPU能力の枯渇がおきます。特に、メモリ不足により、Linux OSにおいてはOOM Killerという仕組みが動き、メモリ使用量の多いプロセスを停止していきます。OOM Killerはプロセスの重要度を考慮しないので、データベースサーバ等サービス提供に不可欠なプロセスまで停止させられ、ウェブサーバーは機能停止に陥ってしまいます。

        以下はPHPに対するhashdos攻撃のリクエスト例です。

        POST /phpinfo.php HTTP/1.1

        Host: example.jp

        Content-Type: application/x-www-form-urlencoded

        Content-Length: 1441792

        EzEzEzEzEzEzEzEz=&EzEzEzEzEzEzEzFY=&EzEzEzEzEzEzEzG8=&EzEzEzEzEzEzEzH%17=&EzEzEzEzEzEzFYEz=&EzEzEzEzEzEzFYFY=&EzEzEzEzEzEzFYG8=&EzEzEzEzEzEzFYH%17=&EzEzEzEzEzEzG8Ez=&EzEzEzEzEzEzG8FY=&EzEzEzEzEzEzG8G8=&EzEzEzEzEzEzG8H%17=&EzEzEzEzEzEzH%17Ez=& 【後略】

         このリクエストをPHPが受け付けると、パラメータを内部の連想配列(ハッシュと呼ばれます)に格納する処理に異常に時間がかかり、その間新規リクエストを受けつられなくなります。ただし、Apache Killerと異なりメモリが枯渇するわけではないので、攻撃が終了すると直ちにサーバは回復します。

        ■脆弱性による影響

         DoS攻撃による影響の例としては以下があります。

        • サーバー速度の遅延
        • 新規リクエスト受付の停止
        • サーバーの異常終了

        ■脆弱性の有無の確認方法

        シマンテックのSSLサーバ証明書に無償で提供される「脆弱性アセスメント」には、Apache Killerおよびhashdos脆弱性検出の機能が提供されています。

         上記のような脆弱性スキャナ、脆弱性診断サービスが利用できない場合は、ApacheやPHP等のバージョンが対策済みかを確認して下さい。

        Apache Killer の影響を受けるバージョン 2.2.0 ~ 2.2.20

        Hashdosの影響を受けるもの

        ASP.NET  MS11-100 未適用のもの

        Tomcat   5.5.34およびそれ以前、6.0.34およびそれ以前、7.0.22およびそれ以前

        Ruby     1.8.7-p352およびそれ以前

        PHP    5.3.8およびそれ以前

        ■対策

         対象ソフトウェアの対策バージョンへのバージョンアップあるいはパッチ適用を行います。

         Apache Killerおよびhashdosには、それぞれ緩和策があります。なんらかの理由でパッチ適用等ができない場合、緩和策を実施することで、攻撃を受けた場合の被害を軽減できます詳しくは参考文献を参照ください。

        なお、「シマンテック クラウド型WAF」では、Apache Killerやhashdos等の脆弱性からウェブサイトが攻撃を受けるのを防ぐことができます。

        ■参考文献

        独立行政法人情報処理推進機構(IPA)の注意喚起

        https://www.ipa.go.jp/security/ciadr/vul/20110831-apache.html

        https://www.ipa.go.jp/security/ciadr/vul/20120106-web.html

        Apache公式サイトのアドバイザリ(英語)

        http://httpd.apache.org/security/CVE-2011-3192.txt

        • Products
        • DigiCert Code Signing
        • Vulnerability Assessment
        • Products and Solutions
        • Symantec Website Security
      • 意図しないファイル公開とディレクトリインデックシング(CWE-425、CWE-548)の解説

        May 26 2016, 1:31 AM

        作成者 : Masato Hayashi 0

        このブログではウェブサイトやその上で動作しているウェブアプリケーションの脆弱性について紹介すると共に注意喚起をする目的でまとめられています。

        今回は、古くから現在まで発生し続けている「ディレクトリインデックシング」に起因する情報漏洩について解説をしています。

        ※なお、内容に関しましてはHASHコンサルティング株式会社の徳丸 浩様に監修いただいています。

        +++++++++++++++++++++++++++++++++++++++++++++++

        意図しないファイル公開とディレクトリインデックシング(CWE-425、CWE-548)

        ■概要

         ディレクトリインデックシング(ディレクトリリスティング)はWebサーバーの標準的な機能の一つであり、URLのパスとしてディレクトリを指定した場合に、そのディレクトリに含まれるファイル名を表示する機能です。例えば、ソフトウェアのダウンロードを目的とするサイトでは、ファイル一覧をHTMLとして作成しなくても、ディレクトリインデックシングを使用すると、自動的にファイル名の一覧が表示され、ダウンロードもできるため便利です。

         しかし、うっかりWebサーバーの公開領域に秘密情報を含むファイルが置かれている場合、ディレクトリインデックシングにより、そのファイル名が外部から判明することにより、秘密情報が漏洩する原因になります。

        ■攻撃のイメージと影響

         http://example.jp/bbs.php というURLで掲示板ソフトを提供しているサイトがあり、このサイトにはディレクトリインデックシングが有効であるとします。この場合、http://example.jp/ を閲覧すると、以下のような表示となります。

        Index of /

        • bbs.db
        • bbs.php
        • data/
        • dbconnect.php

        【後略】

        ここで、bbs.dbというファイルが表示されていますが、これは掲示板のデータベースファイル(SQLite形式)です。bbs.dbのリンクをクリックするだけでデータベースファイルをダウンロードでき、データベース内の個人情報など秘密情報が簡単に外部に漏洩してしまいます。

        ■脆弱性による影響

         ディレクトリインデックシング自体は脆弱性ではなく、公開を意図していないファイルを公開領域に配置してしまったことが脆弱性といえます。ディレクトリインデックシングの設定がない場合でも、秘密情報が公開領域にある場合、ファイル名が辞書攻撃などによりわかってしまう場合があります。

        また、とある国家資格のウェブサイトにおいて、解答のPDFファイルを試験前にダウンロードされてしまった事件も過去に起こっています。原因は、解答のPDFファイルをあらかじめWebサーバー上に配置しておき、公開のタイミングでファイルへのリンクを表示する運用をしていたところ、毎年同じルールでファイル名をつけていたために、そのファイル名の規則性を見破られてしまったことが原因でした。そもそも非公開とすべきファイルをWebサイト上に配置してしまったことが根本原因と言えます。

        上記脆弱性の影響には以下があります。

        • 重要情報の漏洩

        ■脆弱性の有無の確認方法

         脆弱性の確認には以下を実施する必要があります。

        • ウェブ公開領域に秘密情報のファイルがないこと
        • ディレクトリインデックシングが無効になっていること(意図的な場合を除く)

        また、外部からディレクトリインデックシングの有無を診断する方法が、「安全なウェブサイトの作り方」別冊の「ウェブ健康診断仕様」に記載されています。

        ■対策

         対策としては以下を実施します。

        • ウェブ公開領域に秘密情報のファイルが配置しないこと
        • ディレクトリインデックシングを無効にする

        Apacheでディレクトリインデックシングを無効にするには、httpd.conf等に以下(-Indexes)を設定します。

        <Directory "/var/www/html">

            Options -Indexes

        </Directory>

        ■参考文献

        ウェブ健康診断仕様(安全なウェブサイトの作り方別冊)

        https://www.ipa.go.jp/security/vuln/websecurity.html

        • Products
        • DigiCert Code Signing
        • Vulnerability Assessment
        • Products and Solutions
        • Symantec Website Security
      • Certificate Transparency とプライバシーのバランス

        May 26 2016, 7:59 AM

        作成者 : Michael Klieman 0

        筆者の前回のブログでは、シマンテックの製品が、お客様へ提供するサービスのすべてについて、今後数週間で Certificate Transparency(証明書の透明性、以下 CT)のサポートを拡大していくとお伝えしました。

        CT を利用すると、組織が所有しているドメインにおいてどのような SSL/TLS サーバ証明書が有効かを監視できます。大多数のお客様の用途では、現在の CT 実装でも問題はありません。ところが、イントラネットの用途で証明書を利用する場合には、証明書の情報(特にサブドメイン情報)を秘密にしておきたいという要望もあります。たとえば、support.mycompany.com については証明書情報を公開してもかまわないが、top-secret-project.mycompany.com のログを記録することには難色を示すというお客様がいても当然でしょう。現在の CT 仕様 RFC 6962 は、こういったプライバシーを伴う配慮や用途は考慮されていません。

        このような現実的な使い方に対応するために、シマンテックの現在の CT 実装では、デフォルトで証明書すべてのログを記録しますが、お客様が証明書の記録を「オプトアウト」するオプションも用意されています。確かに、これは最適なアプローチとは言えません。証明書のログをすべて記録するかすべて記録しないかのどちらかしか選択できないからです。しかし、現在の CT 仕様の限界を考えれば、お客様のプライバシーに対処するには今のところ最も効果的な方法と言えます。

        現在、IETF(Internet Engineering Task Force)が CT 仕様の次期バージョン(RFC 6962-bis)の策定に当たっているところです。この新バージョンでは、CT のログを編集してサブドメインの情報を除外できるようになります。上の例で言えば、top-secret-project.mycompany.com の証明書を「?.mycompany.com」として記録しようということです。この方式であれば、企業は証明書すべてのログを記録して監視したうえで、プライバシー問題にも対処できるようになります。

        シマンテックが名前部分の削除をサポートしているのは、透明性とプライバシーを両立する最適な方法と判断しているためで、最終的に承認され次第、新しい仕様を実装する予定です。

        シマンテックの CT サポートについて詳しくは、こちらをご覧ください。

        【参考訳】

        • Products
        • DigiCert Code Signing
        • Thought Leadership
        • Certificate Transparency
        • Symantec Website Security
      • Certificate Transparency(証明書の透明性)サポートの拡大

        May 26 2016, 7:57 AM

        作成者 : Michael Klieman 0

        本日シマンテックは、Certificate Transparency(証明書の透明性)のサポートを SSL/TLS サーバ証明書のすべてのブランドと顧客チャネルに拡大すると発表しました。Certificate Transparency は、全世界のお客様に強力な証明書管理機能を提供するための重要な要素です。

        Certificate Transparency(以下、CT)は、組織が所有しているドメインにおいてどのような SSL サーバ証明書が有効かを包括的に把握するためのオープンフレームワークです。簡潔なポリシーを実施し、中間者攻撃のような脅威にも迅速に対応するには、証明書について明確かつ完全に把握しておくことが欠かせません。

        すでに発表されているように、シマンテックはまず 2014 年 12 月に、Symantec、Thawte、GeoTrust の Extended Validation SSL/TLS サーバ証明書(以下、EV SSL 証明書)のすべてについて CT サポートを追加しました。次のステップが、これまでに各ブランドの 企業認証製品にサポートを拡大しており、2016 年 2 月にはすべてのドメイン認証製品のサポートを追加する予定です。CT サポートの完了を発表できるのは 3 月中旬の見込みで、このときには日本独自のプラットフォームに対してもサポートが行われます。

        CT が真に効果を発揮するには、公的に信頼されている証明書すべてについて、すべての認証局(CA)が証明書のログを記録する必要があります。シマンテックは、CT のサポートを CA/Browser Forum の Baseline Requirement として定めるべく、SSL/TLS のエコシステムにおける主要な人物との対話を始めています。さらに、CT の採用を促し、他の CA が CT をサポートしやすくなるように、シマンテックの CT サーバは、サードパーティの CA も SSL/TLS サーバ証明書のログを記録できるようにしています。

        シマンテックは、お客様に向けて、また SSL/TLS サーバ証明書エコシステムの中で、証明書の管理と統制の強化を引き続き推進していきます。CT の拡大については、こちらをご覧ください。

        【参考訳】

        • Products
        • DigiCert Code Signing
        • Certificate Transparency
        • Products and Solutions
        • Symantec Website Security
      • PCA3-G1ルート証明書 の削除について

        Jan 13 2016, 7:18 AM

        作成者 : Unknown 0

        すべての大手パブリック認証局(CA)と同じようにシマンテックでも、特定のパブリックルート証明書を定期的に評価し、利用を続けるか、ブラウザ以外の用途に転用するかを判定しています。後者の場合には、Web サイトを保護するために、主要なブラウザプロバイダや OS レベルのトラストストアプロバイダに、削除するか、少なくともルートを「信頼の停止(Untrust)」するよう正式に依頼しています。

        PCA3-G1 ルート証明書が有効期限の終わりに近づいていることを受け、シマンテックは過去数年をかけて、お客様との間で準備を進めてきました。去る 11 月には、いくつかのブラウザがまだこのルート証明書を使っている現状を確認し、PCA3-G1 ルート証明書を削除するか「信頼の停止(Untrust)」するよう、改めて呼びかけました。このルート証明書を削除または信頼の停止をしても、インターネット環境、特にブラウザユーザーに対しては何の害も、また不当なリスクもないよう、シマンテックは万全を期しています。

        代表的なブラウザについては、PCA3-G1 ルート証明書は無用になりますが、企業顧客のなかには、まだこれを利用しているお客様も少なくありません。企業ネットワークの内部で使われているレガシーソフトウェアや機器のために、証明書を要求してきたためです。そうしたニーズに応えるために、シマンテックは「プライベート SSL/TLS」ソリューションの一部として利用できるように、このルート証明書を転用します。シマンテックの記録と公開サイトのスキャンの結果、公開サイトでの利用についてはお客様すべてが移行済みであることが確認されており、PCA3-G1 ルート証明書を削除しても、ブラウザユーザーに対しては何のリスクもないと判断できるテスト結果が出ています。

        パブリック認証局の間では最近、ルート証明書の信頼の停止をめぐって混乱がありました。そのことから、もっと話し合いが必要であるとシマンテックは痛感しています。今後は、この件について定期的に投稿する予定です。これを機に、業界で広く議論が交わされ、Web サイトのセキュリティに関心をもつ関係者すべての利益となるようなアイデアを、全体で共有できるよう願っています。

        • browser
        • Products
        • website security solutions
        • DigiCert Code Signing
        • Root
        • Symantec Website Security