7月21日の記事7月16日の記事で、『POODLE(Padding Oracle On Downgraded Legacy Encryption)脆弱性』について振り返りました。
『POODLE』は、TSL3.0およびLS 1.0 / TLS 1.1の脆弱性でしたが、今回は昨年4月に重大な脆弱性が発覚した「Heartbleed」をはじめとするOpenSSLの脆弱性についてあらためて振り返ります。

OpenSSLとは

OpenSSLとは、インターネット上で情報を安全にやり取りするために暗号化通信を行なうSSLとTLSの機能を実装した、オープンソースのライブラリ(プログラム部品)のことです。

現在、OpenSSLは多くのWebサーバ、様々なOS、ソフトウェア、ネットワーク機器で使用されています。そのためOpenSSLに重大な脆弱性が発覚すると、影響を受ける範囲は非常に広くなります。
2014年4月に発覚した「Heartbleed」は、SSLサーバ証明書の秘密鍵が漏えいする可能性もあり、場合によっては秘密鍵を作り直して証明書の再発行を行う必要がありました。

OpenSSLにはこのほかにも様々な脆弱性が発覚していますが、そのような中で私たちが気を付けるべき点を確認しましょう。

Heartbleedとは?

OpenSSLには、「heartbeat」という機能が存在し、ネットワーク機器間で通信が行われていない間もTLSセッションの接続を維持し続け、通信相手が存在しているかを確認しています。

heartbeatに由来するバグがOpenSSLに混入したのは2011年12月31日のことであり、バグに気付かれることがないままOpenSSL1.0.1が広く公開されてしまいました。

2014年3月から4月にかけて、Googleのセキュリティーチーム、そしてフィンランドのサイバーセキュリティ会社コデノミコンはOpenSSL 1.0.1シリーズのバグを発見しました。

このバグは「heartbeat」に由来するバグであることから、「Heartbleed(ハートブリード、心臓出血)」と名付けられ、世界の人々に注意を喚起すべくロゴマークも作成されました。

OpenSSLは、「https://」で始まる、SSL/TLSが動作しているサイトの6割以上で使用されていると言われています。Heartbleedは、OpenSSLを利用しているサーバに細工を施したデータを送信するだけで、サーバのメモリー上にあるデータ(可能性は低いもののWebサイトの秘密鍵、ユーザーIDやパスワードをはじめ、暗号化しているはずのコンテンツ)を、第三者が閲覧できる可能性のあるバグでした。

Heartbleedの影響は大きく、この影響を受けたサーバにインストールされているSSLサーバ証明書は、新しい秘密鍵を使って再発行、インストールのやり直しが必要となり、古い証明書の失効手続も必要となりました。
証明書の再発行については、弊社はじめ主要な認証局はすべて無償で対応しました。

2014年6月、7つの脆弱性が発覚

Heartbleedの発覚から2か月後、OpenSSLで新たに7つの脆弱性が発覚しました。

  • SSL/TLS MITM 脆弱性(CVE-2014-0224)
  • DTLS 再帰呼び出しに関する欠陥(CVE-2014-0221)
  • DTLS の不正フラグメントによる脆弱性(CVE-2014-0195)
  • SSL_MODE_RELEASE_BUFFERS の NULL ポインタの参照外し(CVE-2014-0198)
  • SSL_MODE_RELEASE_BUFFERS によるセッションインジェクションまたは DoS攻撃(CVE-2010-5298)
  • 匿名の ECDH DoS攻撃(CVE-2014-3470)
  • "Recovering OpenSSL ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack" (FLUSH+RELOADキャッシュのサイドチャネル攻撃によるECDSA Nonce の復元) で説明されている攻撃に対応する修正(CVE-2014-0076)

その中にはMan-in-the-Middle(MITM)攻撃により、暗号化通信の内容が第三者に読み取られたり、改ざんされたりする可能性がある、深刻な脆弱性も含まれ、「ChangeCipherSpec (CCS) Injection Vulnerability」と呼ばれました。

この脆弱性を発見したのは日本のネットワーク/セキュリティ技術・研究開発企業、レピダムの菊池正史氏で、菊池氏はこの脆弱性がOpenSSLの最初のリリースから存在し、16年も誰にも気づかれなかった点をブログにて指摘しました。

これらの脆弱性は、OpenSSL 0.9.8y以前の全てと1.0.0~1.0.0l、1.0.1~1.0.1gに存在します。クライアント、サーバ側の双方が脆弱性のあるOpenSSLを使用しており、サーバ側が1.0.1以降を使用している場合に、MITM攻撃を受ける可能性があります。

皮肉なことに、先述のHeartbleedへの対策としてOpenSSLの更新を行った結果、サーバのOpenSSLのバージョンが1.0.1以降に更新され、結果としてChangeCipherSpecのリスクにさらされるケースが増えた可能性もあると指摘されています。

脆弱性の発覚を受けてOpenSSLプロジェクトは6つの問題を修正したバージョン0.9.8za、1.0.0m、1.0.1hへアップグレードすることを呼びかけました。

2015年3月、危険度「高」の2つの脆弱性

2015年3月19日、OpenSSLの新バージョンが公開され、脆弱性の修正が行われた14項目が発表されました。この中で、危険度「高」とされたのは「CVE-2015-0291」「CVE-2015-0204」の2つです。

CVE-2015-0291は、OpenSSL 1.0.2のみが対象であり、Dos攻撃(Denial of Service attack、サーバなどに攻撃を行い、サービス提供を不能な状態にする攻撃)を仕掛けられる可能性がありました。

CVE-2015-0204は、既に2015年2月に公表されていた「FREAK」の危険度が「低」から「高」に変更されました。研究が進み、当初の想定より広い範囲に影響が及ぶことが判明したのです。弊社でも、FREAKについての記事(2015年3月9日2015年4月6日)を公開し、注意を呼びかけました。

このとき発覚した脆弱性は、OpenSSL1.0.1、1.0.0、 0.9.8に影響があるため、それぞれ1.0.1k、1.0.0p、0.9.8zdへのアップグレードが呼び掛けられました。

2015年7月、新たな脆弱性が発覚

2015年7月9日にOpenSSLの最新版が公開され、脆弱性「CVE-2015-1793」が修正されました。これは「Alternative Chains Certificate Forgery Vulnerability(代替チェーンによる証明書偽造の脆弱性)」と呼ばれます。SSLサーバ証明書のセキュリティチェックが回避されてしまう可能性があります。

この脆弱性は1.0.2c、1.0.2b、1.0.1n、1.0.1oに影響し、v1.0.2dおよびv1.0.1pへのアップグレードが推奨されています。

なお、この脆弱性によって秘密鍵が漏えいすることはなく、SSLサーバ証明書の再発行も必要ありません。

私たちは今後どうすればいいか?

以上のように、OpenSSLには初めから存在して16年間発見されなかった脆弱性や、途中で混入し気付かれずに数年が経過した脆弱性などが潜んでおり、今後もいつ脆弱性が発覚するか分かりません。
常に最新の情報に注意を払い、OpenSSLのアップグレードや、場合によってはSSLサーバ証明書の再発行など対処を行う必要があります。

そのための情報源としては、下記サイトをご参照ください。

OpenSSL公式サイト
IPAの脆弱性対策情報

また、SSL認証局のサイトでも、SSLサーバ証明書の再発行が必要かどうかを含めて、情報が公開される可能性がありますので、最新情報をチェックしましょう。

OpenSSLのバージョンの確認方法

OpenSSLがインストールされたサーバ環境で以下のコマンドを実行してください。

# openssl version

脆弱性診断

グローバルサインでは、HeartbleedやFREAK、先日当ブログでも取り上げたPOODLEなど、SSLに関する脆弱性を診断する無償ウェブサービス「SSL Server Test」を提供しております。このツールは、SSLの研究を行ってる「Qualys SSL Labs社」が開発した評価システムを利用し、SSLサーバ証明書の設定状況の確認や安全性診断などを行なうことができます。

ill_poodle02_01.jpg

heartBleed脆弱性が存在すると「This server is vulnerable to the Heartbleed attack. 」と表示され、「F」評価されます。

ill_openssl_01.png

トピック関連記事

#

2021年04月06日

不正アクセス事例から学ぶ、VPN接続のセキュリティ強化

#

2015年03月09日

SSL/TLS通信の脆弱性「FREAK」について

#

2019年04月01日

電子証明書シリアル番号のランダム性欠如による脆弱性

この記事を書きました

グローバルサインブログ編集部

グローバルサインカレッジ編集部
所属:GMOグローバルサイン マーケティング部
当サイトの運営・管理を担当。