ブログ

    発行
     
      • 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
      • 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
      • コードサイニング証明書を「正しく使う」ために

        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
      • 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