Copyright 2014 Symantec Corporation. All rights reserved. Symantec と Symantec ロゴは Symantec Corporation または関連会社の米国およびその他の国における登録商標です その他の会社名 製品名は各社の登録商

Transcription

1 WHITE PAPER: White Paper 脆弱性を作りこまない SSL の実装方法 powered by Symantec

2 Copyright 2014 Symantec Corporation. All rights reserved. Symantec と Symantec ロゴは Symantec Corporation または関連会社の米国およびその他の国における登録商標です その他の会社名 製品名は各社の登録商標または商標です 合同会社シマンテック ウェブサイトセキュリティは 本書の情報の正確さと完全性を保つべく努力を行っています ただし 合同会社シマンテック ウェブサイトセキュリティは本書に含まれる情報に関して ( 明示 黙示 または法律によるものを問わず ) いかなる種類の保証も行いません 合同会社シマンテック ウェブサイトセキュリティは 本書に含まれる誤り 省略 または記述によって引き起こされたいかなる ( 直接または間接の ) 損失または損害についても責任を負わないものとします さらに 合同会社シマンテック ウェブサイトセキュリティは 本書に記述されている製品またはサービスの適用または使用から生じたいかなる責任も負わず 特に本書に記述されている製品またはサービスが既存または将来の知的所有権を侵害しないという保証を否認します 本書は 本書の読者に対し 本書の内容に従って作成された機器または製品の作成 使用 または販売を行うライセンスを与えるものではありません 最後に 本書に記述されているすべての知的所有権に関連するすべての権利と特権は 特許 商標 またはサービス マークの所有者に属するものであり それ以外の者は 特許 商標 またはサービス マークの所有者による明示的な許可 承認 またはライセンスなしにはそのような権利を行使することができません 合同会社シマンテック ウェブサイトセキュリティは 本書に含まれるすべての情報を事前の通知なく変更する権利を持ちます 2

3 Contents サーバへの攻撃の現状とその問題点 4 HTTPS の設定の注意点 5 1. 独自認証局で発行した SSLサーバ証明書を使用しない 5 2. 古いSSL/TLSの規格を使用しない 6 3. HTTPS 利用時のCookieはsecure 属性を有効に 9 4. キャッシュ対象ファイルの設定の注意 9 5. フォーム使用時の注意 ウェブサイトから脆弱性をなくす SSL/TLS プロトコルの新たな脆弱性に注意する SSLサーバ証明書のアルゴリズムを最新に保つ 11 まとめ 12 注意のポイント 12 対策方法について 12 SSL Toolbox 12 脆弱性アセスメント 12 シマンテックセキュリティ診断サービス 12 シマンテッククラウド型 WAF(Web Application Firewall) 12 3

4 サーバへの攻撃の現状とその問題点近年の報道で周知の通り ウェブサイトに対する攻撃は増加の一途をたどっています また 攻撃の内容を見てみると 攻撃手法が分業化して高度化している状況も報告されています 特に最近頻繁にターゲットになっているウェブサイトに対する攻撃は 誰もがアクセスできる公開ウェブサーバに対して行われるため 悪意を持った攻撃者だけを排除することは容易ではありません 従来ウェブサーバに対する攻撃は 管理者や社内の人間だけがアクセスするアプリケーションやポート (FTP や SSH など ) へのアクセスをファイアウォールで対策しておけば 多くを守ることが可能でした しかし 攻撃技術の進歩や攻撃ツールの普及により公開サーバで脆弱性を放置しているところが狙われる構図に変わりつつあります そういった現状を鑑みると ネットワークのセキュリティだけでなくウェブサーバのセキュリティが非常に重要になります さらに ウェブサイトへの攻撃はネットワークの攻撃とは違い 正常なウェブへのアクセスを装って行われるため すべてのアクセスログを詳細に調べないと気付かないという特徴があります そのため 攻撃をされても気付きにくく 利用者やクレジットカード会社からの指摘で気付く例も後を絶ちません またインターネットを閲覧する機器が パソコンや携帯電話などに限られていた時代は通信経路が限られていたので盗聴の問題が現実に起こる確率は低かったのですが スマートフォンやタブレット端末といった接続機器の選択肢が増え かつ公衆無線 LAN などが発達した現状では 隣の端末の通信内容を覗き見ることが簡単にできるケースが増えています そのため暗号通信を行う SSL サーバ証明書利用の重要性が一段と増しており Google や Facebook などでもすべてのサイトの SSL 通信化を進めるなどの動きが起こっています しかし SSL サーバ証明書は購入してサーバへ設定すれば終わりではありません サーバ設定を間違っていると 前述したようなウェブサイトに対する攻撃が成功してしまうことになります そこで本書では ウェブサイト管理者やウェブアプリケーション開発者向けに SSL を実装する際に 脆弱性を作りこまないための注意点を解説すると共に その対策やウェブサーバ設定についてご紹介します 4

5 HTTPS の設定の注意点ウェブサイトが攻撃にさらされているという現実は目の前にあるものの ウェブを介した便利なサービスの広がりもあり 個人情報や重要情報の入力をウェブサイトでやめることは困難です そのため 重要になってくるのはウェブサーバの設定をきちんと行い 攻撃からシステムと情報を守ることです その第一歩は 盗聴されては困る通信を暗号化通信することです 公開サーバでの暗号通信の為に HTTPS をサーバに導入 利用する際は 以下の項目に注意する必要があります 1. 独自認証局で発行した SSL サーバ証明書を使用しない 2. SSL2.0 を使用しない 3. HTTPS 利用時の Cookie は secure 属性を利用する 4. キャッシュ対象ファイルリダイレクト使用時の設定の注意 5. フォーム使用時の注意 6. ウェブサイトから脆弱性をなくす 7. SSL/TLS プロトコルの新たな脆弱性に注意する 8. SSL サーバ証明書のアルゴリズムを最新に保つ 1. 独自認証局で発行した SSL サーバ証明書を使用しない認証局 (CA:Certificate Authority) は誰でも構築することができ その認証局を使って SSL サーバ証明書を発行することができます 例えば OpenSSL を利用して 自己署名証明書を作成することができますが このような SSL サーバ証明書はインターネット上で利用する証明書としては役に立ちません 広く公開されるウェブサーバに設定する SSL サーバ証明書は 信頼できる認証局から購入してウェブサーバに設定してください 独自に発行したサーバ証明書が証明書として役に立たないのは下記の理由からです なりすましを見抜くことができない SSL を使った Man-in-the-Middle 攻撃とブラウザの挙動が同じだから 誰でも独自発行証明書を手に入れることが出来るから 本物であるかどうかを証明できない 自分で 自分は ですと名乗っているだけの状態になる 信頼できる第三者機関が認証するからこそ そのサーバの持ち主を証明できる ブラウザに警告が表示されるため エンドユーザーが怪しむ 信頼できる認証局とはブラウザに標準でルート証明書が組み込まれている認証局ブラウザ開発メーカーの要件である Web Trust for CA の審査基準を満たす認証局です 例えば Symantec GeoTrust Thawte など ( ブラウザや携帯電話端末によって 標準で実装されている証明書は異なります ) が該当します ルート証明書が入っていないと ブラウザは危険なウェブサイトにアクセスしていると認識してユーザに警告をします 5

6 2. 古い SSL/TLS の規格を使用しない HTTPS を使うことができる SSL/TLS の主な規格としては下記のものがあります SSL2.0 SSL3.0 TLS1.0 TLS1.1 TLS1.2 しかしこれらの中で SSL2.0 は脆弱性がある古い規格のため利用しないようにしてください SSL2.0 では 乱数ジェネレータの実装にバグがあり Man-in-the-Middle 攻撃で第三者が通信を傍受されたり なりすまされる可能性があります そのため SSL3.0 以上を使用することが必要です 最近リリースした新しいブラウザや今後登場する予定のブラウザでは SSL2.0 を利用できないようになってきているため SSL2.0 の利用を禁止することに問題はありません また その他 以下のような古い規格を使わないようにすることも合わせて推奨されます 匿名 DH (Anonymous Diffie-Hellman) を使った暗号スイート 共通鍵の 56bit 暗号スイート 共通鍵の 40bit 暗号スイート 低強度 (128bit 以下 ) の共通鍵暗号スイート RC2 や DES の共有鍵暗号スイート ハッシュアルゴリズムに MD5 を使った暗号スイート ウェブサーバ側で SSL2.0 の利用を禁止するためには ウェブサーバの設定を変更する必要があります IIS の場合 1 [ スタート ] ボタンをクリックし [ ファイル名を指定して実行 ] をクリックします regedit と入力し [OK] をクリックします 2 レジストリエディタで次のレジストリキーに移動します HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\ Protocols\SSL 2.0\Server 3 [ 編集 ] メニューの [ 値の追加 ] をクリックします 4 [ データタイプ ] ( または [ データ型 ]) ボックスの一覧の [DWORD] をクリックします 5 [ 値の名前 ] ボックスに Enabled と入力し [OK] をクリックします 注 : この値が既に存在する場合は 値をダブルクリックして その値を編集します 6 バイナリエディタで と入力し 新しいキーの値が 0 になるように設定します 7 [OK] をクリックし コンピュータを再起動します 6

7 ( 参考 )IIS で PCT 1.0 SSL 2.0 SSL 3.0 または TLS 1.0 を無効にする方法 Apache の場合 ssl.conf 内のディレクティブを以下のように設定 SSLProtocol all -SSLv2 SSLCipherSuite ALL:!ADH:!EXPORT56:!EXPORT40:!MD5:!DES:!RC2:RC4+RSA:+HIGH:+MEDIUM:-LOW:!SSLv2:+EXP 上記の例では SSLCipherSuite で Annonymous Diffie-Hellman 鍵交換方式の暗号スイート 40bit と 56bit の共通鍵暗号スイート RC2 や DES の共通鍵スイート ハッシュアルゴリズム MD5 を使った暗号スイート 低強度の共通鍵暗号スイート SSL2.0 を無効可しています 7

8 確認方法 SSL2.0 サービスが提供されているかどうかの確認は Linux などで提供されている OpenSSL コマンドを使用することで確認することができます SSL2.0 が提供されている場合の実行例 $ openssl s_client -connect -ssl2 CONNECTED( ) ( 略 ) --- Ciphers common between both SSL endpoints: RC4-MD5 EXP-RC4-MD5 RC2-CBC-MD5 EXP-RC2-CBC-MD5 DES-CBC-MD5 DES-CBC3-MD5 --- SSL handshake has read xxxx bytes and written xxx bytes --- New, SSLv2, Cipher is DES-CBC3-MD5 Server public key is 2048 bit Compression: xxxx Expansion: XXXX SSL-Session: Protocol : SSLv2 Cipher : DES-CBC3-MD5 Session-ID: XXXXXXXXXXXXXXXXXXXXXXXXXXXX Session-ID-ctx: Master-Key: xxxxxxxxxxxxxxxxxxxxxxxxxxxx Key-Arg : XXXXXXXXXXXXXXX Krb5 Principal: xxxxxx Start Time: xxxxxxxx Timeout : xxxxx (sec) Verify return code: 21 (unable to verify the first certificate) --- SSL2.0 が提供されていない場合の実行例 $ openssl s_client -connect -ssl2 CONNECTED( ) 11147:error:1407F0E5:SSL routines:ssl2_write:ssl handshake failure:s2_pkt.c:428: 8

9 3. HTTPS 利用時の Cookie は secure 属性を有効に Cookie を発行する際には 以下のように属性を付けることができます Set-Cookie : 名前 = 値 ; expires= 日付 ; path= パス ; domain= ドメイン名 ; secure この属性の中で secure と指定することで HTTPS 通信時のみ送信を許可する Cookie を発行することができます この secure 属性が指定された Cookie は HTTP での通信時には送信されないようになります つまり HTTPS だけで流通する Cookie を使うことができるのです HTTPS 利用時の Cookie に secure 属性を使わないと HTTPS で保護された通信の内容 ( にアクセスをする Cookie の中身 ) を HTTP に流してしまうことになります たとえば 攻撃者が盗聴した Cookie で HTTPS に入れてしまうということになると HTTPS で保護している意味がありません もし HTTP と HTTPS にまたがってセッション管理をする必要がある場合には HTTP 用と HTTPS 用に 2 つ Cookie を使う事になります なお サイトを常時 SSL( 自社の持つ複数のドメイン /FQDN をすべて HTTPS 通信にする手法 ) にするとセッション管理をシンプルにしセキュリティを強化することができます 4. キャッシュ対象ファイルの設定の注意サーバ側のキャッシュ設定もセキュリティとサーバの負荷低減の観点から注意を要するポイントです キャッシュを多く許容することによりサーバの負荷を減らして安定したサービスを提供したいというのはサーバ管理者にとって理想ですが キャッシュを許容しすぎると セキュリティのリスクが増す事に成ります 具体的な問題点としては もし攻撃者がマスターシークレットを窃取できた場合に 有効期限が切れるまでセッションの当事者になりすませる可能性があり中間者攻撃が成功する可能性がでるためです それでは どのような設定が推奨されるかというのを以下に列記します HTTPS 通信ではキャッシュ機能をオフにすることが最も安全ですが ウェブサイトの表示スピードの問題が顕在化するので最小限のキャッシュに留めるように設定します 許容するキャッシュは 画像ファイルなどの静的ファイルだけに限定する事を推奨します SSL のキャッシュは一例として以下の表記を Apache の設定ファイル < httpd.conf> 追記することで可能になります [Header onsuccess append Cache-Control public] ExpiresActive On ExpiresDefault "access plus 300 seconds" 9 <Directory "/home/website/public_html"> Options FollowSymLinks MultiViews AllowOverride All Order allow,deny Allow from all ExpiresByType text/html "access plus 1 day" ExpiresByType text/css "access plus 1 day" ExpiresByType text/javascript "access plus 1 day" ExpiresByType image/gif "access plus 1 day" ExpiresByType image/jpg "access plus 1 day" ExpiresByType image/png "access plus 1 day" ExpiresByType application/x-shockwave-flash "access plus 1 day" </Directory>

10 5. フォーム使用時の注意 ログインフォームなどのページで HTTPS を用いていても そのデータの送り先サーバが HTTP の場合 データの送信経路は暗 号化されていないことになります そのため 送り先も HTTPS にしないと HTTPS の効果がなくなってしまいます ログインフォームのページが HTTPS でも 送り先が HTTP なら暗号化されない Form の送り先を絶対パスで指定する場合 HTTPS にする ユーザー ID パスワード https <form action=" /login.cgi" method="post"> ユーザー ID <input type="text" name="name"> パスワード <input type="password" name="pwd"> <input type="submit" value=" ログイン "> </form> form.htm HTTPS フォームが本物であることとコンテンツが通信経路上で んされていない事の証明と保護 login.cgi HTTPS データの送り先が本物であることとコンテンツが通信経路上で んされていない事の証明と保護 6. ウェブサイトから脆弱性をなくす HTTPS の設定がきちんとおこなわれても脆弱性を含んだ OS ウェブサーバ アプリケーションが放置されていては情報漏えいをしてしまう危険性があります ベンダー配布のパッチを適用し OS やアプリケーションのバージョンを最新に保ってください ウェブアプリケーションとウェブのネットワークに対する脆弱性の検査を定期的に行い 問題がないことを確認してください 迅速なセキュリティパッチの更新が難しい場合 WAF などのソリューションを利用してください 10

11 7. SSL/TLS プロトコルの新たな脆弱性に注意するここまでは SSL/TLS のサーバ実装に関する注意点を説明しました しかし それ以外にも注意すべき SSL/TLS 利用の注意点があります SSL/TLS は 暗号化通信の確立されている手法で 導入が容易で安価なことから広く普及していますが 新たな脆弱性が SSL/TLS 自身もしくは SSL/TLS を実装するソフトウェアで発見されることがあります 2011 年に発表された BEAST(Browser Exploit Against SSL/TLS) は SSL/TLS の脆弱性を利用して通信の盗聴を行うことでアカウントを乗っ取る攻撃方法のことです この攻撃は既知の SSL/TLS の脆弱性を利用した攻撃で その実現性の高さから非常に注目を集めました プロトコルで CBC(cipher block chaining) モードを利用している場合に 一定の条件が揃うと暗号の解読が成功してしまうというものです また 2014 年 4 月に発表された OpenSSL の脆弱性である Heartbleed は 攻撃ツールが公開されたこと それから OpenSSL を実装しているサーバアプリが非常に多く普及していることから実際の情報漏えいが起こりました その後の 2014 年 6 月には OpenSSL のセキュリティチームは 7 つの新しい脆弱性に関して セキュリティアドバイザリと修正パッチをリリースしました この中の 1 つは Critical な脆弱性であり 攻撃者にクライアントとサーバ間のトラフィックの暗号を解読され マン イン ザ ミドル攻撃 (MITM) を行われる恐れがあります これらの脆弱性に対処するためには OpenSSL1.0.1 から 1.0.1g のバージョンを利用している場合には OpenSSL を OpenSSL 1.0.1h 以降へアップグレードする必要があります 1 他にも SSL/TLS の脆弱性を利用する同様な攻撃手法として TIME CRIME Lucky Thirteen といった攻撃が発見されていますが これらの攻撃が成功しないようにするためにサーバ OS やサーバアプリではパッチを公表しています これらのパッチをきちんと適用して セキュリティを保つことが攻撃を防ぐ最善の策です 8. SSL サーバ証明書のアルゴリズムを最新に保つ SSL サーバ証明書は コンピュータ技術の進歩に伴って進化してきました そのため新しい暗号化技術はまず解読されることはありませんが 古い技術の一部は コンピュータの性能向上によって解読される可能性があると言われています 米国標準技術研究所 (NIST) が 現在使われている暗号方式の一部について 2010 年の終わりまでに より安全性の高いものに切り替える必要がある と公表したことから注目されるようになりました これが暗号の 2010 年問題です この 2010 年問題 で注目を集めていたのは 公開鍵暗号である RSA 暗号方式の鍵長を 1024bit から 2048bit に変更して 暗号強度を上げることでした ただ SSL 証明書で使われている技術には 公開鍵 暗号だけではなく 共通鍵暗号 や ハッシュアルゴリズム もあり それらを最新に保つ必要があります ただ この暗号の移行の難しいところは 暗号強度の強化と暗号の普及のバランスが重要だからです シマンテックでは常にサーバやブラウザ 携帯電話 スマートフォンでの対応状況を調査しながら 市場で最適なセキュリティが担保されるように情報発信を行っています 1: 詳細な対応方法は以下のサイトを参照ください 11

12 まとめ本書では HTTPS の実装や SSL サーバ証明書を利用するに当たって注意すべき点を解説してきました 最後に対策方法を簡単にまとめると共に 正しい運用を行うための Tips をご紹介します 注意のポイント本書で説明をしてきた注意ポイントをまとめると以下のようになります 自己証明書や暗号強度が弱い証明書の利用をしない SSL2.0 などの弱い暗号を利用しない HTTPS の設定時にクッキーの属性やキャッシュの設定に注意する 対策方法について今回挙げた注意点に関して 確認する手段や対策をシマンテックでも提供していますので 以下にご紹介します これら以外にも有償 無償のサービスが色々提供されていますが 自社の求めるチェック頻度 レポート形態 コストなどを考慮して選択して頂ければ幸いです SSL Toolbox SSL の設定については シマンテックが提供する SSL Toolbox( checker/) でも確認が出来ます 証明書が利用しているアルゴリズムなどが 分かりやすく表示されるので簡単に確認できます また中間証明書の設定間違いなども 図示して表示されます このサービスは 誰でも無償で利用できるサービスです 脆弱性アセスメント脆弱性アセスメントは グローバルサーバ ID EV SSL 証明書に無償で提供されている機能で 当該 SSL サーバ証明書を利用しているサーバをシマンテックが週に一度診断し 脆弱性の有無を調べてお客様にその結果をお知らせするサービスです 上記のような注意点を 検知してご連絡いたします シマンテックセキュリティ診断サービス上記の 脆弱性アセスメント が ツールによる自動診断であるのに対し 自動ツールでは見つけることが困難なクロスサイトリクエストフォージェリなどの問題点も経験豊富な技術者により発見する診断サービスを有償で提供しております この診断により本書で指摘した問題点をもれなく調査することが可能です シマンテッククラウド型 WAF(Web Application Firewall) WAF は 公開ウェブサーバの前面に置いてサーバに対する攻撃を防ぎます ウェブサイトの脆弱性を突いてくる攻撃に対して有効で クロスサイトスクリプティングや Drive by download ( ドライブ バイ ダウンロード ) SQL インジェクションなどの代表的な手口に加え Apache Struts の脆弱性やパスワードリスト攻撃などの新たな攻撃の手法へも素早く対応します シマンテックが提供するクラウド型の WAF (Web Application Firewall) は クラウドを利用して提供されるため初期費用を抑えることができ セキュリティ専業会社によるチューニング 運用 保守があわせて提供されるので脆弱性対策の知識を持っていなくても対策することができます 12 Copyright 2014 Symantec Corporation. All rights reserved. シマンテック (Symantec) ノートン (Norton) およびチェックマークロゴ (the Checkmark Logo) は米国シマンテック コーポレーション (Symantec Corporation) またはその関連会社の米国またはその他の国における登録商標 または 商標です その他の名称もそれぞれの所有者による商標である可能性があります 製品の仕様と価格は 都合により予告なしに変更することがあります 本カタログの記載内容は 2014 年 4 月現在のものです 合同会社シマンテック ウェブサイトセキュリティ 東京都港区赤坂 赤坂インターシティ Tel : websales_jp@symantec.com