Internet Infrastructure Review（IIR）Vol.25
2014年11月25日

Shellshockとは

脆弱性への対応

ディストリビューションの例として、CentOS（※51）の各種リリースにおける各脆弱性の対応状況を表-2に示します。CVE-2014-6271の対策版において、修正が不十分であった点は他と変わりませんが、それ以降の脆弱性においては同時に対応し、アップストリームの修正に起因するCVE-2014-6277、CVE-2014-6278については影響を受けていません。これはCentOSの元となるRed Hat Enterprise Linux（※52）がBashの最新版へのアップデートではなく、ベースとなるパッケージに対して、脆弱性を修正するパッチを当てて対応しているためです。他のディストリビューションにおいても同様に、修正方法により影響有無が分かれています。

脆弱性の影響

ローカルシェルとして使用されるBashにおける脆弱性が、何故リモートから悪用可能な脆弱性へ発展したのでしょうか。今回の脆弱性は、特定の環境変数の値が設定された状態において、Bashプログラムが起動されると影響を受けるというものです。Bashがシェル関連の呼び出しで使われる/bin/shを兼ねている環境もあり、こちらも同様の影響を受けます。

実際にこの脆弱性を用いた攻撃は既に観測されており、最も狙われている箇所はCGI（※53）です。分かりやすい影響例として、Webサーバ上で動作するBashで書かれたCGIプログラムがありますが、実際の環境においてはほぼ利用されていないと考えられます。しかしながら、他の言語で作られたCGIプログラムであったとしても、内部的にシェルに依存しているために影響を受ける場合があります。

また、アプライアンス製品や組み込み機器の制御OSとしてもLinuxが多く採用されています。身近な物としてはロードバランサ、ホームルータ、ファイルサーバなどが挙げられます。これらにもBashが組み込まれていたり、管理画面においてCGIが使われていたりと、普通のUNIXサーバ同様の影響を受けてしまう場合もあります。これらを踏まえて、今回の脆弱性の影響を理解するにあたり、UNIX環境におけるプログラムの実行と、CGIの処理の流れについて説明します。

UNIX環境におけるプログラム実行

CGIの処理の流れ

CGIはWebサーバ経由で動的コンテンツを提供する仕組みです。Webアプリケーションフレームワークの普及に伴い、以前よりは少なくなっていますが依然として使われています。WebサーバはHTTP経由で受け取ったヘッダを、環境変数へ展開してCGIプログラムを起動します。この仕様が今回の脆弱性において、CGIが最も影響を受けやすい箇所となっている理由です。CGIプログラムとして直接Bashが起動されない限り、この時点では影響を受けません。ですが、前述のとおり環境変数は子プロセスに引き継がれていくため、他の言語で書かれていたとしてもシェルを経由して外部プログラムを呼び出してしまうと、影響を受ける可能性があります。直接呼び出したプログラムに限らず、ライブラリやモジュールを経由して、間接的に呼び出されたプログラムであったとしても同様です。図-14にCGI経由のプログラム呼び出しにおける影響の有無を示します。

また、スクリプト言語においてはプログラムの記述方法により、意図せずにシェルが呼び出されてしまうこともあります。スクリプト言語の例としてPerl（※54）における動作を示したものが表-4です。このように、同一の関数による呼び出しであっても、引数次第で暗黙的にシェル経由の呼び出しへ展開されてしまいます。環境変数はすべて引き継がれていますので、シェル経由の呼び出しへ展開される場合は、今回の脆弱性の影響を受けます。

拡大する

図-14 CGIにおける影響

拡大する

表-4 Perlにおける外部プログラム呼び出し

CBCモードの概要とCBCモードが持つ潜在的な脆弱性

図-18はCBCモードを利用した復号時において、暗号文が改ざんされた場合の波及範囲を示しています。この図において暗号文C₁の一部を改ざんすることで平文P₁はブロック全体が変更されてしまいますが、平文P₂は攻撃者の意図する箇所を自由に変換することができます。図-19はこの特徴を用いたPadding Oracle Attack（※63）の原理を示しています。平文の長さが分かっているという前提でP_nまでのデータが暗号化されている場合、最後のブロックC_nを中間者が「攻撃対象」、つまり復号したいデータであるC_iに差し替えます。このとき平文の長さが既知のため、パディングされたデータ長が格納されているP_nの最終バイトは既知となります。SSL/TLSサーバは手順どおりパディングチェックを行い、もし仕様で定められたパディング方式に則っていない場合にはエラーを返却します。このエラー返却機能（Padding Oracle）を使うと、サーバが暗号化データをアクセプトした場合、パディング部分には正しいデータが格納されていることを意味します。SSLv3においてはP_iの最終バイトとP_nの最終バイトが一致するときにアクセプトされますので、P_i ⊕ C_i-1の最終バイトとP_n ⊕ C_n-1の最終バイトが一致することからP_iの最終バイトを（暗号化鍵を知らなくても）復元することができます。実際には、MACによるチェックが入るためパディングデータよりも前の平文部分が改ざんされたことが検知できますので、うまくいかないことがほとんどです。しかし、今回POODLE attackで指摘されたように、うまくそのブロックがパディングデータのみで埋め尽くされる状態（図-16の（c）のような状態）にすることでMACの影響範囲を最終ブロックから外すことができます。このとき最終の1バイトが合致しているか試行すると256回に1度だけ必ずアクセプトされます。一方でTLSにおいては、図-16（c）のように、ブロックすべてのバイトが同じデータで埋め尽くされる必要があります。この例ではブロック長が8バイトですから、2⁶⁴回の試行で1度だけ成功します。またAESではブロック長が16バイトですから2¹²⁸回の試行が必要なことからも、TLSにおいてこの攻撃は現実的ではない潜在的な問題点としてみなされてきました。しかし、今回指摘されたPOODLE Attackでは、1バイトを復元するために2⁸程度の計算で済むため、現実的な攻撃として認識されました。

POODLE attackの現実性

SSHにおいては、CBCモード以外にも利用可能な暗号モードの1つであるCTRモードが利用可能であったため、CBCモードの利用を取りやめることでPadding Oracle Attackを防ぐことができました。しかし、SSL/TLSにおいてはCTRモードの利用は仕様上定められていません。またSSLv3においては、仕様で規定されているCipherSuites（暗号アルゴリズム）において、輸出規制のためにかつて利用されていた40ビット鍵の強度しか持たないアルゴリズムやNULL（暗号化なし）以外のものでCBCモードを利用しないときにはRC4を使わざるを得ません。しかしRC4には昨年新たな攻撃手法が立て続けに公開されており（※64）（※65）、もはやRC4も脆弱なアルゴリズムであると認識されています。

POODLE attackと同様にPadding Oracle Attackに分類されているBEAST攻撃は、SSLv3及びTLSv1.0にて成功可能であり、TLSv1.1にて仕様としてこの脆弱性を回避する設計がなされています。具体的には前セッションの暗号化データを次セッションのIVとして利用する際の潜在的問題を回避し、新たにIVを作り直す工程が入りました。またBEAST攻撃が存在しながらもSSLv3及びTLSv1.0が現在も利用されてきたのは、1/n-1分割法と呼ばれる対策方法が有効であることが知られているためです（※66）。この手法は主要ブラウザにおいて既に対策されていますが、POODLE attackに適用することはできません。今後、1/n-1分割法と同様にSSLv3の延命技術が考案される可能性はありますが、現時点ではSSLv3を安全に利用する方法が皆無となりました。

今回の攻撃に対する根本的な対策として、1）SSLv3を無効にする（クライアント、サーバのいずれか）、2）TLS_FALLBACK_SCSVの導入（クライアント、サーバ共に対策が必要）、の2つが挙げられています。1）に関しては、主要ブラウザは今後SSLv3を無効にするとアナウンスされました（※67）（※68）（※69）。また、ブラウザに自ら設定してSSLv3を無効化する方法も案内されています（※70）（※71）。サーバサイドにおいてもSSLv3を無効にする方法が共有されつつあります（※72）。一方でレガシーな製品、特にフィーチャーフォンやゲーム機器などにおいては対策が難しいと考えられます。そのためSSL/TLSサーバがSSLv3非対応になることで、これらの機器からサイトが閲覧できなくなるケースが考えられます。

2）はダウングレード攻撃（※73）を根本的に防ぐために提案されている方式です（※74）。この方式ではTLS_FALLBACK_SCSVというCipherSuiteとエラーコードinappropriate_fallbackが新たに追加されており、クライアントとサーバの両者共にこのSCSV（Signaling Cipher Suite Value）（※75）に対応している場合にのみ、ダウングレード攻撃を防ぐことができます。挙動は非常にシンプルでクライアントは自身が対応可能な最高バージョン以外でサーバに繋ぐときにはClientHelloメッセージのCipherSuitesに本SCSVを含むようにします。一方、本SCSVを含むCipherSuitesを受け取ったサーバは、クライアントが指定したプロトコルバージョンがサーバで対応している最も高いバージョンより低い場合にはエラーを返します。これらの挙動により潜在的なダウングレード攻撃を回避することができます。現在はTLS WGでLast callというステータスのドラフトですが、今年2月よりGoogleサーバとChrome（バージョン33以降）にて本SCSVが実装されています。また10月15日に公開されたOpenSSLでもこのSCSVが実装されました。更にFirefoxも対応することが予定されており（※76）、今後サーバ・クライアント双方で利用が広がる見込みです。しかしこの対策はサーバ・クライアントの双方で対応しない限りPOODLE attackを防ぐことはできません。フィーチャーフォンなどのレガシーな環境において、この対策が浸透するとは考えられず、今後の潜在的な攻撃に備えて実装されている、と捉えることもできるでしょう。

POODLE attackの前提条件としてブラウザから大量にリクエストを発生させ、かつそのリクエストを経路上で一部書き換える（攻撃対象の暗号化データに差し替える）必要があることから、BEAST攻撃と同様に一般的な利用環境では容易に攻撃可能とは一概には言えません。しかし、今回はプロトコル仕様自体の問題であり、回避が難しいことからSSLv3はSSLv2と同様に脆弱なバージョンとして捉え、今後利用すべきではないと考えられます。実際TwitterなどのいくつかのサービスにおいてSSLv3無効化を行ったとのアナウンスが即座になされました（※77）（※78）。

TLS仕様はTLSv1.0だけでなくBEAST攻撃に対処したTLSv1.1、より安全なハッシュ関数のSHA-256、SHA-384やCBC以外の暗号モードGCM、CCMに対応したTLSv1.2が規格化され、広く実装されています。更にTLSv1.3（※79）も現在TLS WGにおいて検討されています。暗号モードとしてCBCを除外するなどの検討がなされており、最新のプロトコルバージョンを利用することで安全に利用できる仕組みが整いつつあります。かつては安全と認識され広く利用されていたDESやMD5などの暗号アルゴリズムが危殆化（※80）し利用停止されたように、暗号プロトコルについても過去のバージョンを捨て速やかに新しいバージョンに移行していく必要があります。その際には、後方互換性（バージョンアップすることで繋がらなくなるSSLクライアントの比率）と安全性（対策の緊急度）のバランスを見ながら対応していくことが必要になります。

リスト型攻撃とは

昨年から様々なオンラインサービス（以下、サービス）において、リスト型攻撃またはリスト型アカウントハッキングと呼ばれる攻撃手法を用いた不正アクセスが頻発しています。リスト型攻撃とは、攻撃者がログインIDとパスワードを組み合わせたリストを用いて、サービスのログインを連続的に試行する攻撃です。攻撃に利用されるリストは、攻撃対象とは異なるサービスから流出した情報から作成されています。複数のサービスでログインIDとパスワードを使い回すユーザが多い（※81）ことから、攻撃者はリストを利用して攻撃しているのです。

攻撃者がログインに成功しても、サービス提供者からは一見して、正規ユーザであるか否かを判別することは難しく、攻撃者は対策が行われる前に目的を達成することができます。ユーザがログインIDとパスワードの使い回しをしているサービスが多い程、ユーザの被害が大きくなってしまいます。

他のログイン試行攻撃との違い

ログイン試行の攻撃手法としては、特定のログインIDに対して、様々なパスワードを試してみるブルートフォース攻撃や、パスワードとしてよく使われる単語やフレーズを試してみる辞書攻撃がよく知られています。リスト型攻撃では、試されるログインIDとパスワードの組み合わせが、あらかじめ決まっているという点がこれらの攻撃とは異なります。

2014年のリスト型攻撃の発生状況

表-5は2014年1月1日から9月30日の間にリスト型攻撃として公表されたインシデントをまとめたものです。ほぼ毎月どこかのサービスがリスト型攻撃を受け、不正にログインされていることが分かります。金銭的被害も9件発生しており、クレジットカードで大量のチケットを購入し、換金する事例や、友人の名を騙ってメッセージを送り、ポイントカードを購入させる事例、他にもサービス独自のポイントをギフト券などへ不正に交換する事例などが発生しています。リスト型攻撃の発見の契機については、サービス提供者による発見数13件、ユーザによる発見数9件となっています。サービス提供者自身もリスト型攻撃に気がついていない状況が多くあることが窺えます。

拡大する

表-5 2014年に発生したリスト型攻撃による事件

オンラインサービスにおけるリスト型攻撃対策

最後にサービス提供者側とユーザ側、それぞれのリスト型攻撃への対策を以下に説明します（※82）。ただし、サービスを提供／利用する上での対策ですので、社内向けシステムなどには当てはまらない箇所もあります。

サービス提供者側のリスト型攻撃対策

サービス提供者側の主な対策は、（1）認証機能設計・実装の改善、（2）システム監視・運用の改善、（3）ユーザアクティビティ監視・通知機能の提供の3つです。なお、対策にあたって、ユーザに過度の負担を強いないような実装を考えなければなりません。

（1）の対策はログインID及びパスワード設定の改善やパスワード以外の認証機能の提供を行います。ログインIDとパスワードの使い回し防止のため、システムにポリシーに基づいたログインIDとパスワードを自動生成させることを検討してください。これにより、他サービスからのログインIDとパスワードの使い回しを防ぐことができます（※83）。ユーザに自由なパスワード設定を許容する場合、「弱いパスワード（※84）を受け付けない」「ログインIDとパスワードの使い回しをしないよう明示する」といった対策が必要となります。

その上で、使い回しをするユーザが必ずいることを想定し、多段階認証や多要素認証（ハードウェアトークンやICカード）で補強することを検討しなければなりません。この実装にはシステム改修が必要な場合があります。また、自社のシステムの脆弱性などにより情報が漏えいする可能性もないとは言い切れません。自社からログインIDやパスワードが漏えいした場合に備え、攻撃者が認証情報を手に入れても、リスト型攻撃に利用することが困難になるような対策が必要になります。パスワードを保存する際は、平文保存や単純なハッシュ化ではなく、ソルトを追加したパスワードにストレッチングを施したハッシュ化を行うことで、パスワードを現実的な時間で解析できなくなります。自社で実装することが困難な場合、外部の組織が提供する認証機能を利用することもできます。しかし、外部が提供する認証システムに対して攻撃が行われるといったリスクも考慮しなければなりません。

（2）は攻撃の事前・事後に備えた対策です。リスト型攻撃が行われた際、平常時と比べて、「システムの負荷が高い」「ログイン失敗の回数が多い」「存在しないログインIDに対するログイン試行が多数行われている」「特定のIPアドレスからのログイン試行が異常に多く、ログインIDが毎回異なる」「平常時とは異なるIPアドレスブロックからアクセスが行われている」といった兆候が見られる場合があります。

このような兆候を検知して、管理者への通知や攻撃元IPアドレス自動遮断、アカウントロックするようなシステムを検討してください（※85）。また、長期間利用がないアカウントを削除することでリスト型攻撃による被害を未然に防ぐことができます。不正ログインが発覚した場合、被害の拡大防止と調査のため、サービスの停止を検討してください。不正ログインされたアカウントのパスワードは、再び不正ログインされないように、パスワードリセットなどで変更しなければなりません。また、念のため、今回、不正ログインの対象となっていないアカウントのパスワードを変更することも検討してください。

（3）は重要な処理の際にユーザにアラートを通知する機能です。ログイン成功・失敗時や個人情報の閲覧・変更時、購入決済処理などの完了時にメールなどでユーザに通知することで、ユーザ自身が不正アクセスに気付くことができます。また、ログイン履歴や購入履歴を確認できる機能を提供することで、いつ頃から不正アクセスが起きているのか把握することができます。

ユーザ側のリスト型攻撃対策

ユーザが自分でパスワードを設定する場合、パスワード管理ソフトウェアを使用して、サービスごとに異なるパスワードを生成・管理するのが最も効果的です。Webベースのサービスの場合、Webブラウザにパスワード生成ツールで作成したパスワードを記憶させる方法もあります（※86）が、Webブラウザに起因するリスクに対応するため、マスターパスワードは必ず設定し（※87）、常に最新バージョンのWebブラウザを使用してください。

サービスが2段階認証を提供している場合は必ず使用するようにします。また、サービスの通知機能を有効にし、身に覚えのない利用通知がサービスから届いた場合は早急にパスワードを変更して、金銭的被害が発生していないか確認し、サービスの運営に連絡しましょう。また、使用する予定がなくなったサービスのアカウントは削除するようにしましょう。