ブログ

    発行
     
      • Symantec SSL/TLSサーバ証明書の入れ替えに関する情報について

        Mar 29 2018, 8:59 PM

        作成者 : connect 0

        さる2017年8月2日(米国時間)、シマンテックは、エンタープライズ領域で高い拡張性を持つ世界有数の認証・暗号ソリューションプロバイダであるDigiCert社が、シマンテックのウェブサイトセキュリティ事業および関連するPKIソリューションを買収することについて発表いたしました。昨今、ウェブを経由して侵入する高度なサイバーセキュリティの脅威が高まり、こうした攻撃からビジネスを保護することが非常に重要であるタイミングで、この発表は執り行われました。

        この買収によりお客様は技術的に強化された基盤、最高レベルのサポート、そして業界をリードする革新と合わせてお客様に必要な認証と暗号のリーディングソリューションに特化する企業ならではのメリットを享受することができるようになります。お客様のビジネスの継続性を維持することは弊社の最優先事項であり、そのためのカスターマーサービスを提供することを強くお約束します。

        ブラウザーコミュニティによる提案への対応の一環として、弊社のウェブサイトセキュリティ事業部門では、お客様に、Google ChromeおよびMozillaの提案に伴う警告表示などの問題を避けていただき、お客様のウェブサイトの継続性を維持することに全力で取り組みます。この一環として、弊社では警告表示の影響を受けるお客様に対して、積極的にご連絡を差し上げております。


        Google社の提案の背景

        さる2017年7月27日、Google社は、シマンテックが発行したSSL/TLSサーバ証明書について、その時間的な制約を含む実行計画(英語リンク)を掲載しました。お客様のウェブサイト運営に影響を及ぼす可能性のある日にちへの言及がございます。

        • 2017年12月1日より、Google Chromeに信頼されるために全てのSymantec SSL/TLSサーバ証明書は新たなPKI基盤より発行されなければなりません
        • 2018年3月15日(Chrome 66 Beta、日程は前後する可能性があります)にGoogle Chromeは、2016年6月1日より前に発行されたSSL/TLSサーバ証明書が導入されたウェブサイトに対して警告を表示します。 ウェブサイトのセキュリティや暗号通信機能は従来通り機能しますが、Chromeを利用するサイト訪問者に対しては警告が表示されます。
        • 更にGoogle Chrome は、2017年12月1日以降、全てのシマンテックグループの証明書を新たなインフラより発行することを求め、これ以前にシマンテックグループの現インフラより発行されたSSL/TLSサーバ証明書に対して、2018年9月13日(Chrome 70 Beta、日程は前後する可能性があります) 以降に警告を表示する、と宣言しています。ウェブサイトのセキュリティや暗号通信機能は従来通り機能しますが、Chromeを利用するサイト訪問者に対しては警告が表示されます

        また、さる2017年8月1日に、MozillaはGoogle社によって提案された時間軸に追従する意思(英語リンク)を示しました。Google社は2017年9月11日に最新のブログ(英語リンク)でその計画を再確認しています。

        速やかに実施可能な対応

        弊社では、前述の複数の期限を考慮しながら、お客様のビジネスに影響がないよう、そしてブラウザの要求を満たすよう、全てのお客様の証明書を調査しています。そして2017年12月1日までに、弊社の認証局パートナーとなるDigiCert社が、弊社に代わってGoogleならびにMozillaによる要求を満たすための業務を開始します。

        2016年6月1日より前に発行されたシマンテックグループのSSL/TLSサーバ証明書をお持ちのお客様につきましては、2018年3月15日より前に再発行および再インストールを実施いただく必要がございます。弊社は影響を受けるお客様へのご連絡を開始するのと同時に移行がスムーズに完了するように直接お手伝いさせていただきます。

        マネージドPKI for SSLをご利用中のお客様が、どのように再発行をすべき証明書を見つけるかについては以下のKBをご確認ください。

        シマンテックから直接購入されていないお客様は、シマンテックの販売パートナー様と再発行の調整を行なっていただければ幸いです。

        マネージドPKI for SSLやコンプリート・ウェブサイトセキュリティ(CWS)をご利用中のエンタープライズのお客様は、2017年12月1日時点で全ての新規申請や再発行申請を含めたいかなる証明書申請も即時発行が可能な状態を維持するために、近日中にDigiCert社による先行再認証業務を開始いたします。この先行再認証業務についてお客様の追加費用負担は必要ございません。

        2017年12月以降に順次再発行いただくべき証明書

        一部のお客様は、2017年12月1日(Digicert社とのパートナーシップにより統合された認証業務を開始する時期)以降の再発行をすべき証明書をお持ちです。Google社の提案における複雑な時間軸を鑑みると、これ以前に、上記にリストアップしたもの以外の証明書の再発行を行うことは必ずしも推奨されません。弊社は、2017年12月1までに、DigiCert社とのパートナーシップにより統合された認証業務の提供を開始することを宣言しております。このことにより、お客様がChromeの警告表示を避けるために証明書の再発行をいただくための十分な時間を確保いただけるものと考えます。この時点以降の全ての認証業務はDigiCert社によって実施されます。そしてこの再発行作業を実施いただくことによって、お客様はCA/B Forumのガイドラインに規定された有効期間内を十分に利用いただける証明書を入手いただけます。

        弊社は、お客様が証明書を再発行、再取得をいただく際に最も推奨されるタイミングについて、より詳細な情報を順次ご連絡差し上げます。

        サポートについては下記からお問い合わせください。

        https://www.symantec.com/ja/jp/page.jsp?id=contact-authentication-services

        シマンテック ウェブサイトセキュリティ事業部

        • DigiCert SSL TLS Certificates
        • Products
        • Products and Solutions
      • Symantec Backs Its CA

        Oct 20 2017, 8:41 PM

        作成者 : connect 0

        The below has been updated to ensure translation accuracy.

        Symantecは業界をリードする認証局の一つであることを誇りに思っています。私たちはGoogle社がChromeブラウザにおいてSymantec SSL/TLSサーバ証明書をターゲットとして行なうアクションに強く反論します。この行為は想定外のものであり、かつブログに書かれた内容は無責任なものであると考えます。私たちは、この行為がSSL/TLSサーバ証明書に対するインターネットコミュニティの不確かな状況や不信感を生じさせるために行われたものではないことを願います。

        私たちの証明書発行業務ならびに過去の不適切な発行の影響範囲に関するGoogle社のステートメントは誇張されており、誤解を生じさせるものです。例えば私たちが3万枚の証明書を不適切に発行したとするGoogle社の主張は事実ではありません。Google社が言及する事象では、3万枚ではなく、127枚の証明書が不適切に発行されましたが、消費者に被害は及んでいません。私たちはこれらの状況を是正するために広範な救済措置を執り、問題に関わったパートナーのRegistration Authority(RA)としての認定を即時終了し、またSymantecのSSL/TLSサーバ証明書の信頼を強化するためにRAプログラムの終了を発表しています。この管理の強化は非常に重要なものであり、他のパブリック認証局が未だ追従できていないものです。

        あらゆる大手認証局がSSL/TLSサーバ証明書の不適切な発行という事態を経験している中、Google社はブログの中でいくつかの認証局における問題の存在を指摘しつつ、Symantecの認証局のみを提案の対象としています。

        私たちは業界標準に従って認証局を運営しています。私たちはSSL/TLSサーバ証明書の発行業務に対する厳格なコントロールを維持しており、認証局としての業務内容を継続的に強化しています。私たちはこれまでにインターネットのセキュリティに対して多大な投資を行い、今後も同様にコミットしていきます。Symantecは公にかつ積極的にSymantec証明書のCertificate Transparency(CT:証明書の透明性)へのログの登録を推進しており、自らCTサーバーを抱える数少ない認証局の一つです。Symantecは、Certificate Authority Authorization (CAA:認証局の指定)の推進者であり、CA/ブラウザフォーラムにすべての認証局がCAAの遵守をするようルールの変更を働きかけてきました。直近では、私たちが作り出したフリーミアムプログラムであるEncryption Everywhereが、暗号化されたウェブサイトの広範囲な拡大を促進し、認証局のエコシステムに対して貢献しています。

        Symantecのお客様および消費者の皆様には、シマンテックSSL/TLSサーバ証明書が引き続き信頼してお使いいただけますことを確認させて頂きます。Symantecは、Google社のブログ記事の提案によって引き起こされ得る混乱があったとしても、安全で生産的なインターネットの利用を精力的に守ります。

        私たちはGoogle社と共通の顧客とパートナーの利益の為に、この件の解決に向けてGoogle社と話し合いを持つ準備が出来ており、進んで議論を行います。

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

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

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

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

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

        ファイルも 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
      • OSコマンドインジェクション脆弱性(CWE-78)の解説

        Oct 20 2017, 9:16 PM

        作成者 : Masato Hayashi 0

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

        今回は、最近著名CMSの脆弱性として情報漏えいを起こした原因としてニュースをにぎわしており、Webアプリケーションの脆弱性の中でも最も危険度の高いOSコマンドインジェクションについて解説をしています。

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

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

        OSコマンドインジェクション脆弱性(CWE-78)

        ■概要

        Webアプリケーションの中には、機能の実現のために外部コマンドを呼び出すものがあります。また、多くのアプリケーションでは、メール送信の機能をsendmailコマンドの呼び出しで実現し、外部からのファイルダウンロードをwgetやcurl等のコマンド呼び出しにより実現する場合もあります。

        外部コマンドにパラメータを渡して呼び出している場合、パラメータを巧妙に細工することにより、開発者が意図しない別のプログラムを呼び出せる場合があります。これにより悪意のあるコマンド呼び出しを行う攻撃がOSインジェクション攻撃です。また、OSコマンドインジェクション攻撃を許す状況をOSコマンドインジェクション脆弱性と言います。

         OSコマンドインジェクションはソフトウェアの脆弱性として継続して報告されており、サイト改ざんなどの攻撃に悪用されています。

        ■攻撃のイメージと影響

         Webアプリケーションで利用者登録の際にメールアドレスを登録してもらい、そのメールアドレスに対して通知メールを送信している場合を想定します。以下のPerlスクリプトで$mailは、利用者が入力したメールアドレスです。

        system(“/usr/sbin/sendmail $mail < /var/data/message.txt”);

        ここで、$mail = “test@example.jp; cat /etc/passwd” と外部から指定された場合、生成されるコマンドは以下の通りです。

        /usr/sbin/sendmail test@example.jp; cat /etc/passwd < /var/data/message.txt 

         コマンド中のセミコロン「;」は、2つ以上のコマンドを続けて実行する際の区切り文字なので、上記コマンド呼び出しにより/etc/passwdの内容を表示する結果となります。この他、様々なコマンド呼び出しが可能です。

        ■脆弱性による影響

         この脆弱性による影響の例として下記がありますが、これらに限りません。OSコマンドインジェクション攻撃を受けると、サーバが乗っ取られた状態になり、最悪の場合はサーバ内部からの脆弱性攻撃により、root権限を奪取される可能性があります。

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

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

         OSコマンドインジェクション脆弱性の有無の確認は、ソースコードを確認する方法が確実です。system、exec等外部コマンドを呼びだすことのできる関数名やメソッド名を検索して、該当箇所を目視で確認します。

         あるいは、ネットワーク経由の手動診断で脆弱性の有無を検証することもできます。この場合、独立行政法人情報処理推進機構(IPA)が公開している「安全なウェブサイトの作り方」別冊の「ウェブ健康診断仕様」に診断の方法が説明されており、参考になります。

        ■対策

         OSコマンドインジェクション脆弱性はアプリケーションのバグなので、アプリケーション改修による対策が基本です。外部コマンドを使わないで同じ機能を実現できる場合は、外部コマンドを呼ばない実装の方が安全で効率も良くなる場合が多いです。どうしても外部コマンドを使用する必要がある場合は、シェルを経由しないコマンド呼び出しの方法を採用します。詳しくは「安全なウェブサイトの作り方」等の参考資料を御覧ください。

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

        ■参考文献

        安全なウェブサイトの作り方

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

        • Products
        • DigiCert Complete Website Security
        • DigiCert SSL TLS Certificates
        • Products and Solutions
      • コードサイニング証明書を「正しく使う」ために

        Apr 14 2016, 5:14 AM

        作成者 : Quentin Liu 0

        シマンテックの最近の調査レポートにより、中国に拠点を置く高度な脅威グループ、通称 Suckfly がコードサイニング証明書の秘密鍵を奪い、2年前からマルウェアを拡散していたことが明らかになりました。この発見で、サイバー攻撃者が正規のファイルやアプリケーションのように偽装してマルウェア拡散を実行する増加傾向がセキュリティ面で注意すべきポイントとしてひとつ増えたことになります。

        サイバー攻撃者が、コードサイニング証明書の秘密鍵を狙うのはなぜでしょうか。問題は、その目的として相反する二つの面に起因しており、従来からのコードサイニング利用の管理方法にあります。

        コードサイニング証明書の主な目的は、a)内容の完全性を検証し、それが改変されていない事を証明することと、b)ファイルまたはアプリケーション作成者の帰属を明らかにして使用環境による警告を防止することです。コードサイニング証明書があると、ファイルやアプリケーションの内容が改変されていないこと、そして内容と作成者の存在の関連付けが第三者機関によって検証されているため信頼度が上がります。ソフトウェアメーカーや業界グループの多くが、この理由からコードサイニング証明書の使用を義務付けています。

        実際の使われ方を見ると、ユーザーが署名のないアプリケーションをダウンロードしようとした場合に、一部のブラウザは警告を表示することによってユーザーを保護します。また、リスクを低減するために、署名のないファイルやアプリケーションをダウンロードあるいは実行するのを防いで、不明または不正な発行者から送られたコードの実行を最小限に抑えるセキュリティアプリケーションもあります。このように、セキュリティ意識が高く、社内でソフトウェアまたはアプリケーションを多数開発している企業であれば、発行に関する観点からも、リスク低減の観点からもコードサイニング証明書を導入しているのが普通です。

        従来のコードサイニングでは、署名に使われる秘密鍵を安全に保管する全責任は、発行を依頼した組織にあります。その組織の中では一般的に、秘密鍵のセキュリティと管理は開発グループに一任されます。ファイルやアプリケーションを発行するのが、たいていはアプリケーションまたはソフトウェアの開発者だからです。そのグループが基本的なセキュリティ対策(ベストプラクティス)について訓練を受けていない場合、あるいは鍵の紛失や盗難、悪用について説明責任を果たせなかった場合、マルウェアが自分たちの秘密鍵で署名されてしまうというリスクに、企業全体が直面することになります。

        企業が鍵の盗難や悪用を防ぐうえで、以下のような業界の基本的なセキュリティ対策(ベストプラクティス)があります。

        • 秘密鍵の保護
          • HSM または専用のセキュリティ環境で保管する
        • 秘密鍵と署名履歴の追跡
          • 誰が、何に、いつ署名したかをわかりやすくする
        • 発行者の任命と失効の管理
          • 秘密鍵には権限のあるユーザーだけがアクセスできるようにする
        • 監査の準備
          • コードサイニング署名について責任の明確化と証跡の保全を推進する

        基本的なセキュリティ対策(ベストプラクティス)だけでなく、秘密鍵をオンサイトで分散保管させず、確実な鍵管理のガバナンスとセキュリティを備えた一元的な場所に保管することで、セキュリティを強化すべき企業もあるでしょう。全世界のコードサイニング証明書の 65% を提供している*プロバイダとして、シマンテックは、従来のコードサイニング手法に存在するガバナンスの欠如などの問題のギャップに対処できる次世代のサービスを提供し、秘密鍵の盗難というリスクに対応しています。それが Symantec Secure App Service です。クラウドベースの総合的なコードサイニング管理ソリューションであり、鍵の管理とコードサイニング履歴の追跡、さらにユーザーの管理までが一元化されます。

        サイバー犯罪者は今後も、企業のセキュリティを破って重要なデータを盗み出す手法を次々と生み出すでしょう。業界のベストプラクティスを厳重に守り、Symantec Secure App Service などのソリューションを活用すれば、そうした企みを防ぎ、コードサイニング本来の信頼を保証できます。

        *出典: rsEdge による国際的な調査(2014 年)

        【参考訳】

        • Products
        • DigiCert SSL TLS Certificates
        • Products and Solutions
        • Symantec Website Security
      2 ページ