ページの先頭です


ページ内移動用のリンクです

  1. ホーム
  2. IIJの技術
  3. セキュリティ・技術レポート
  4. Internet Infrastructure Review(IIR)
  5. Vol.25
  6. 1.インフラストラクチャセキュリティ

Internet Infrastructure Review(IIR)Vol.25
2014年11月25日
RSS

目次

1.4 フォーカスリサーチ

インターネット上で発生するインシデントは、その種類や規模が時々刻々と変化しています。このため、IIJでは、流行したインシデントについて独自の調査や解析を続けることで対策につなげています。ここでは、これまでに実施した調査のうち、Bashの脆弱性Shellshockについて、POODLE attack、リスト型攻撃の発生状況と対策の3つのテーマについて紹介します。

1.4.1 Bashの脆弱性Shellshockについて
Shellshockとは

表-1 Shellshock関連脆弱性一覧

この脆弱性CVE-2014-6271(※44)は、2014年9月24日にBash(※45)の対策バージョンと共に公開されました。脆弱性の影響としてはリモートから任意のコード実行が可能です。Bashは通常ローカルで使用されるシェルプログラムであるため、リモートからの攻撃とは無縁と思われがちですが、その影響が明らかになるにつれて大きな騒ぎになりました。

脆弱性公開と同時に対策バージョンがリリースされましたが、公開後から約1週間で、関連する複数の新しい脆弱性が立て続けに公開されました。表-1が関連する脆弱性の一覧です。CVE-2014-7169(※46)は元々の修正が不十分であったとして新しい脆弱性として登録されました。CVE-2014-7186(※47)、CVE-2014-7187(※48)は修正の過程で発見された脆弱性です。CVE-2014-6277(※49)、CVE-2014-6278(※50)はパッチがアップストリームに取り込まれる過程で作り込まれました。Shellshockによる攻撃を防ぐためには、これらの脆弱性すべてに対応する必要があります。

脆弱性への対応

表-2 CentOS各リリースにおける対策版bashパッケージ

Bashはシェルプログラムという性質上、サーバプログラムやスクリプト言語のインタープリタなどとは異なり、最新版の機能が必要とされる機会はあまりありません。そのため、多くの場合で各ディストリビューションの提供するバイナリパッケージを使用しています。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環境におけるプログラム実行

図-13 UNIX環境における外部プログラム実行

UNIX環境においては、Windows環境とは異なり完全新規のプロセスを作成することができず、親プロセスの複製(fork)を経て、子プロセスを実行対象のプロセスへ変化(exec)させる手順を辿ります。最終的には子プロセスは実行対象のプログラムへと変化して親プロセスとは別物になりますが、複製を経由するため一部のデータが引き継がれます。図-13にこの処理の流れを示します。

表-3 exec系関数の動作

変化する際に呼び出すexec関数には表-3に示すとおり複数の種類があり、今回の脆弱性において鍵となる環境変数の扱いが異なっています。呼び出し時に明示的に環境変数を指定しないexec関数においては、親プロセスから子プロセスに引き継がれた環境変数が、そのまま実行対象のプロセスへ変化した後も使用されます。

CGIの処理の流れ

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

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

図-14 CGIにおける影響

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

まとめ

これまで説明したように、Bashという一見リモートからの攻撃とは無縁に見えるプログラムの脆弱性であったとしても、利用のされ方により、外部からこの脆弱性狙った攻撃にさらされることになります。

このような影響条件は、ソースコードを元にした静的な調査などではすべての実行パスを網羅的に調査することは困難です。一方、Bashのアップデートはサーバプログラムなどとは異なり、多くの場合において再起動を必要としないため、少しでも影響が疑われる箇所であれば速やかに対策版へ更新することをお勧めします。

アプライアンス製品や組み込み機器については、ベンダーによるファームウェア修正が必要になります。対策版ファームウェアのリリースに時間がかかる製品もありますので、その場合は影響が疑われる箇所へのアクセスを制限するなどの暫定的な対策も有効です。

脆弱性への対策としては、回避策の適用、対策版への更新、セキュリティ装置による防御などの様々な手段があります。対象のシステム構成により、最適な対策は異なりますので、その都度判断して適切に対処することが重要です。

1.4.2 POODLE attack

米国時間2014年10月14日に、Googleの研究チームからSSLv3(※55)への新たな攻撃が公開されました(※56)。POODLE attack(Padding Oracle On Downgraded Legacy Encryption attack)と呼ばれる本手法はBEAST攻撃(※57)に類似した中間者攻撃で、ブラウザから大量のリクエストをサーバに送りつけることによるトライ&エラーを繰り返すことでSSLで暗号化された攻撃対象データを1バイトずつ復号する攻撃手法です。現実的な被害としては、Cookieの搾取が挙げられています。なお本手法は一見TLSv1.0(※58)にも適用可能であるかのように見えますが、SSLv3.0とTLSv1.0のパディング手法の違いにより、TLSv1.0では現実的な攻撃にはなりません。一方でSSLv3.0では1バイトを盗み見るために最大255回のクエリをサーバに送りつけるだけで攻撃が可能となります。本節では、POODLE attackの技術的背景と本攻撃の現実性について取り上げます(※59)

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

図-15 CBC暗号モードの概要

POODLE attackはBEAST攻撃と同じく暗号モードとしてCBC(Cipher Block Chaining)モードが利用されたときのみ成功します。RC4をはじめとしたストリーム暗号は、鍵情報をもとに発生させたキーストリームを平文にXOR演算で足しこむことで暗号化を行う方式であり、任意長のデータを暗号化することができます。一方で、DESやAESなどのブロック暗号は定められた入力長(ブロック長:DESは64ビット、AESは128ビット)のデータを暗号化アルゴリズムに入力し、入力長と同じブロック長の暗号文を得る方式です。通常ブロック暗号を利用する際には、ブロック長よりもはるかに長いデータを暗号化しますので、何度も逐次的に暗号化アルゴリズムで暗号処理を行う必要があります。1つ前のブロック暗号処理で得られたデータを次のデータ処理でどのように利用するかを定めた方式のことを暗号モードと呼び、いくつもの方式が提案されています。図-15はその1つであるCBC暗号モード(※60)の概要を示しています。まず初期値としてブロック長のIV(Initial Vector)(※61)を用意します。平文をブロック長ごとに分割したときの最初のパートであるP1にIVをXOR演算で足し合わせたデータに、実際のブロック暗号における暗号化処理を行い、その出力として暗号文C1が得られます。次の平文パートP2を暗号化するには、前のブロック暗号化処理で得られたC1をXOR演算で足し合わせたデータを平文として入力して暗号化し、同様にC2を得ます。このようにCi =ENC(Pi ⊕ Ci-1)という暗号化処理を繰り返すことで、平文全体の暗号化を計算します。逆に復号する際にはPi=DEC(Ci) ⊕ Ci-1という復号処理を逐次的に繰り返すことで、平文を復元することができます。

図-16 ブロック長が8バイトの場合のPKCS#5 paddingの例

この暗号化処理において、ブロック長でちょうど割り切れないデータを扱う場合にはパディング処理が必要となります。これは、平文の最後のパートがブロック長に満たない場合、何がしかのデータでブロック長になるように埋めてブロック暗号化処理が行えるようにする処理です。TLSではPKCS#5 padding方式(※62)が採用されており、図-16はブロック長が8バイト(例えばDES)の場合のパディングの例を表しています。(a)はブロック長に満たすまでに3バイト足りないためパディングデータとして3バイト分を0x03で埋めます。同様に(b)は5バイト足りないため5バイト分を0x05で埋めています。(c)はちょうどブロック長の倍数のデータを暗号化しようとするケースですが、平文のどこまでパディングされていたかの境界を復号時に認識できるようにするために「8バイト分(ちょうどブロック長)足りない」ということにして当該ブロックのすべてを0x08で埋めていきます。

図-17 PKCS#5 paddingとSSLv3 paddingの違い

※ 色付けされたパディングデータにおける*はランダムなデータであることを示している。

一方でSSLv3.0では異なるパディング方式が採用されており、この違いが今回のPOODLE attackを生み出すきっかけの1つとなってしまいました。図-17はPKCS#5 paddingとSSLv3 paddingの違いを示しています。SSLv3で採用されているパディング方式では、パディングする最終バイトをPKCS#5 padding方式と同様に「パディングするバイト長」とし、それ以外のパディングデータはランダムデータを埋めていくと定められています。不運なことに、SSLv3でもTLSでもこのパディングされるエリアは、通信路でデータが改ざんされていないことを示すデータであるMAC(Message Authentication Code)の対象範囲には入っていません。そのため、パディングデータを改ざんされたとしてもMACの検証では、改ざんを検知することができません。一方で、TLSにおいては上記説明したパディングデータの制約条件を用いて、パディング部分の改ざんを検知できる可能性はありますが、SSLv3では最終バイト以外のパディングデータを改ざんされたとしてもそれを検知することができません。POODLE attackはこのちょっとした隙間を狙った攻撃とも言えます。

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

図-18 CBCモードにおける暗号文が改ざんされた場合の波及範囲

※ 暗号文の1バイトを改ざんして復号処理した場合には、当該ブロックの平文はブロック全体に渡って影響が及ぶが、次ブロックにおける平文において意図した箇所を改ざんすることが可能である。

図-19 Padding Oracle Attackの原理

※ サーバのPaddingチェック機能においてPaddingが正しい場合にはアクセプトされるが誤っている場合にはエラーが返却される。

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クライアントの比率)と安全性(対策の緊急度)のバランスを見ながら対応していくことが必要になります。

1.4.3 リスト型攻撃の発生状況と対策
リスト型攻撃とは

昨年から様々なオンラインサービス(以下、サービス)において、リスト型攻撃またはリスト型アカウントハッキングと呼ばれる攻撃手法を用いた不正アクセスが頻発しています。リスト型攻撃とは、攻撃者がログイン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段階認証を提供している場合は必ず使用するようにします。また、サービスの通知機能を有効にし、身に覚えのない利用通知がサービスから届いた場合は早急にパスワードを変更して、金銭的被害が発生していないか確認し、サービスの運営に連絡しましょう。また、使用する予定がなくなったサービスのアカウントは削除するようにしましょう。

  1. (※44)CVE-2014-6271 bash:specially-crafted environment variables can be used to inject shell commands(https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-6271blank)。
  2. (※45)GNU Bash:The GNU Bourne-Again SHell(http://www.gnu.org/software/bash/blank)。
  3. (※46)CVE-2014-7169 bash:code execution via specially-crafted environment Incomplete fix for CVE-2014-6271(https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-7169blank)。
  4. (※47)CVE-2014-7186 bash:parser can allow out-of-bounds memory access while handling redir_stack(https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-7186blank)。
  5. (※48)CVE-2014-7187 bash:off-by-one error in deeply nested flow control constructs(https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-7187blank)。
  6. (※49)CVE-2014-6277 bash:uninitialized here document closing delimiter pointer use(https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-6277blank)。
  7. (※50)CVE-2014-6278 bash:incorrect parsing of function definitions with nested command substitutions(https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-6278blank)。
  8. (※51)CentOS Project(http://www.centos.org/blank)。
  9. (※52)Red Hat Enterprise Linux(http://www.redhat.com/en/technologies/linux-platforms/enterprise-linuxblank)。
  10. (※53)RFC3875 The Common Gateway Interface Version 1.1(http://www.ietf.org/rfc/rfc3875.txtblank)。
  11. (※54)The Perl Programming Language(https://www.perl.org/blank)。
  12. (※55)IETF、"The SSL Protocol Version 3.0"(http://tools.ietf.org/html/rfc6101blank)。
  13. (※56)Bodo Möller, Thai Duong, Krzysztof Kotowicz, "This POODLE Bites: Exploiting The SSL 3.0 Fallback"(https://www.openssl.org/~bodo/ssl-poodle.pdfPDF)。
  14. (※57)Thai Duong, Juliano Rizzo, "BEAST - Here Come The XOR Ninjas", 2011。
  15. (※58)IETF、"The TLS Protocol Version 1.0"(http://tools.ietf.org/html/rfc2246blank)。
  16. (※59)本節は技術的な解説に重きをおいている。POODLE attackの概要については、以下に示す暗号プロトコル評価技術コンソーシアムによる速報を参照のこと。SSLv3仕様そのものに対するPOODLE attackについて(https://www.cellos-consortium.org/jp/index.php?PoodleAttack_20141015_Jblank)。
  17. (※60)NIST、"NIST Special Publication 800-38A Recommendation for Block Cipher Modes of Operation: Methods and Techniques"(http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdfPDF)。
  18. (※61)IV(Initial Vector)は秘密にする必要はない。ただし復号時には鍵と同様にIVが必要となる。
  19. (※62)IETF、"PKCS #5:Password-Based Cryptography Specification Version 2.0"(http://tools.ietf.org/html/rfc2898blank)。
  20. (※63)SSL/TLSだけでなくSSHやIPsecにおいても同様の攻撃が公開されてきた。いずれも仕様で定められた「データ形式の制約」に則っているかどうかを、サーバからのエラー情報を基に判定して暗号化データを復号する攻撃手法である。M.R. Albrecht, K.G. Paterson, G.J. Watson, Plaintext Recovery Attacks Against SSH, 30th IEEE Symposium on Security and Privacy, 2009.(http://www.isg.rhul.ac.uk/~kp/SandPfinal.pdfPDF)。J.P. Degabriele and K.G. Paterson, On the(In)security of IPsec in MAC-then-Encrypt Configurations, Proceedings of the 17th ACM Conference on Computer and Communications Security, 2010.(http://portal.acm.org/citation.cfm?id=1866363blank)。
  21. (※64)Takanori ISOBE, Toshihiro OHIGASHI, Yuhei WATANABE, and Masakatu MORII, "Full Plaintext Recovery Attack on Broadcast RC4,", Proc. the 20th International Workshop on Fast Software Encryption(FSE 2013), 2013.(Revised Selected Papers, LNCS 8424, pp.179-202, Springer-Verlag, 2014)。
  22. (※65)N.AlFardan, D.J.Bernstein, K.G.Paterson, B.Poettering, J.C.Schuldt, On the Security of RC4 in TLS, USENIX Security 2013.(http://dl.acm.org/citation.cfm?id=2534793blank)。
  23. (※66)ImperialViolet、"POODLE attacks on SSLv3(14 Oct 2014)"(https://www.imperialviolet.org/2014/10/14/poodle.htmlblank)。
  24. (※67)Mozilla Security Blog、"The POODLE Attack and the End of SSL 3.0"(https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/blank)。
  25. (※68)Google Online Security Blog、"This POODLE bites: exploiting the SSL 3.0 fallback"(http://googleonlinesecurity.blogspot.jp/2014/10/this-poodle-bites-exploiting-ssl-30.htmlblank)。
  26. (※69)「マイクロソフト セキュリティ アドバイザリ 3009008, SSL 3.0の脆弱性により、情報漏えいが起こる」(https://technet.microsoft.com/ja-jp/library/security/3009008blank)。
  27. (※70)SANS ISC InfoSec Handlers Diary Blog、"OpenSSL:SSLv3 POODLE Vulnerability Official Release"(https://isc.sans.edu/diary/OpenSSL%3A+SSLv3+POODLE+Vulnerability+Official+Release/18827blank)。
  28. (※71)mozillaZine、"Security.tls.version.*"(http://kb.mozillazine.org/Security.tls.version.*blank)。
  29. (※72)F5 Networks、"CVE-2014-3566:Removing SSLv3 from BIG-IP"(https://devcentral.f5.com/articles/cve-2014-3566-removing-sslv3-from-big-ipblank)。
  30. (※73)意図的に古いプロトコルバージョンで接続させる中間者攻撃。ClientHelloにてクライアントが対応しているバージョンを明示する箇所があり、この部分をSSLv2であると指定することにより、意図せず弱い暗号アルゴリズムを利用させることができる。SSLv2ではこのメッセージはMACなどで守られていないためダウングレード攻撃の根本的な解決方法はなくSSLv2は脆弱なバージョンと認識されている。
  31. (※74)IETF、"TLS Fallback Signaling Cipher Suite Value(SCSV)for Preventing Protocol Downgrade Attacks"(https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsvblank)。当初personalな提案だったドラフト(https://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsvblank)が現在TLS WG預かりに昇格していることが分かる。
  32. (※75)本来CipherSuiteはSSL/TLSで用いられる暗号アルゴリズムの組を示す2バイトデータであるが、2009年に発覚したRenegotiation機能の問題に対処するためにRFC5746(http://tools.ietf.org/html/rfc5746blank)で導入されたTLS_EMPTY_RENEGOTIATION_INFO_SCSVと同様、本来とは異なる用途で別の意味を持たせる拡張が行われている。
  33. (※76)http://www.ietf.org/mail-archive/web/tls/current/msg13905.htmlblank
  34. (※77)https://twitter.com/twittersecurity/status/522190947782643712blank
  35. (※78)CloudFlare blog、"SSLv3 Support Disabled By Default Due to POODLE Vulnerability"(https://blog.cloudflare.com/sslv3-support-disabled-by-default-due-to-vulnerability/blank)。
  36. (※79)The Transport Layer Security(TLS)Protocol Version 1.3(https://tools.ietf.org/html/draft-ietf-tls-tls13blank)。ディスカッションはhttps://github.com/tlswg/tls13-specblankを参照のこと。
  37. (※80)暗号危殆化の事例は本レポートのVol.8(http://www.iij.ad.jp/dev/report/iir/pdf/iir_vol08.pdfPDF)の「1.4.1 暗号アルゴリズムの2010年問題」にて紹介している。
  38. (※81)IPAとJPCERT/CCから公表された「STOP!!パスワード使い回し!!パスワードリスト攻撃による不正ログイン防止に向けた呼びかけ」(https://www.jpcert.or.jp/pr/2014/pr140004.htmlblank)の中で、金銭に関連したサービスサイトと同一のパスワードを使い回している人の割合が約4分の1(25.4%)であることが指摘されている。
  39. (※82)サービス提供者向けとして、総務省からも「リスト型アカウントハッキングによる不正ログインへの対応方策について」(http://www.soumu.go.jp/menu_news/s-news/01ryutsu03_02000063.htmlblank)が公表されている。
  40. (※83)サービス提供者が生成したログインIDとパスワードを、ユーザが他のサービスに利用することを技術的に防ぐことは困難であるため、ユーザに対し他のサービスに利用しないように提示する必要がある。
  41. (※84)「password」や「123456」、「ユーザの名前や住所、生年月日」など推測しやすいものや、それらの組み合わせは弱いパスワードとして設定できないようにしなければならない。
  42. (※85)このような兆候は現在の攻撃傾向を反映した結果であるため、今後は傾向が変わる可能性がある。最新の攻撃傾向を情報収集し、それに合わせた観点で監視を行う必要がある。
    また、兆候の把握やそれを基にした自動遮断など、通信の秘密に対する適法性については、「電気通信事業におけるサイバー攻撃への適正な対処の在り方に関する研究会 第一次とりまとめ(http://www.soumu.go.jp/main_content/000283608.pdfPDF)」の「第4節 SMTP認証の情報を悪用したスパムメールへの対処」や「電気通信事業者における大量通信等への対処と通信の秘密に関するガイドライン(http://www.jaipa.or.jp/other/mtcs/guideline_v3.pdfPDF)」の「(4)SMTP認証の情報を悪用した迷惑メールへの対処」などを参照のこと。
  43. (※86)Webブラウザで管理する場合、マルウェアに感染したときにパスワードが窃取される可能性があるが、多数の複雑なパスワードを身近なツールで管理できるという点において、現実的な手段の1つとして考えることができる。
  44. (※87)Firefoxはマスターパスワードを設定することができる。その他の主要なWebブラウザ(Internet Explorer、Google Chrome、Safari)では、OSなどのセキュリティ機構を使用してパスワードが自動的に暗号化されて保存される。
1.インフラストラクチャセキュリティ

ページの終わりです

ページの先頭へ戻る