2017.02.24

SHA-1の強衝突耐性が破られた

Internet Watchによれば「GoogleとCWI、SHA-1衝突に成功……」とのことである。

Freestart Collisionが見つかってから、1年4ヵ月くらい。MD5の8年に比べるとかなり早い。ただし、元記事によると相当な計算をクラウド上で行っている模様 (単純なブルートフォース攻撃ではない)。

MD5でコリジョンが発見されたケースに比べれば影響は低い (というか、既に予想されていた) と思われる。すでに主要なブラウザではSHA-1の証明書は無効化されているか、無効化される予定になっている。MD5の場合はコリジョンが発見されてから無効化されるまで8年くらいかかっている。しかし、SHA-1も本当に破られましたね (以前のネタ)。

2015.10.13

SHA-1の「Freestart Collision」が見つかる

SHA-1の「Freestart Collision」が発見されたとのことである。

Freestart Collision (フリースタート衝突?) というのは、本来は規定されている初期ベクタ (IV) の値を都合の良い値に変更した上でSHA-1の全手順を実行させた場合に発生する Collision のことである (詳しい解説が、ここにある)。

SHA-1 は規定された80ラウンドから縮小したアルゴリズム (本来のSHA-1とは異なる) では既に Collision が見つかっていたが、80ラウンドを全て備えたアルゴリズム (ただし、IVが異なるため本来のSHA-1とは異なる) では初めてらしい。

これによって、SHA-1を使用した証明書の偽造がすぐにできるようになるとかいう話もでているようだが良く解らない。ちなみに、MD5の場合にはFreestart Collisionが見つかってから、本物のCollisionが見つかるまでに8年かかっているらしい (いずれにしても、既にNISTによりSHA-1は非推奨とされており、早急にSHA-2への移行を進めるべきである)。

2009.01.07

MD5の脆弱性を用いた証明書の偽造

「MD5 の collision attack を使用して、X.509 証明書の偽造に成功したという研究発表」の報告があった。備忘録として知り得た情報を整理しておく。

今回の攻撃は既知のMD5の強衝突耐性への攻撃を用いており、MD5のハッシュ値の衝突を起こすように作られたX.509の証明書の例は過去にも報告されている。今回の新しい点は

  • 正規のCAの署名をつける事に成功した
  • サーバ証明書ではなく、中間証明書が得られた
の2点であろう(つまり、正規のCAの署名付きの中間証明書が得られた事になり、攻撃者は「正統なCA」に成り済ました状態になる)。これで攻撃者はどのような証明書も自由に作れる事になる(実際の方法は「自堕落な技術者の日記」に詳しい)。

もちろん、SHA-1で署名したサーバ証明書の作成も(必要なら新たな中間証明書の作成も)可能なので、証明書が今回の攻撃によって作られていない事を確認するためには(全ての)中間証明書の署名がMD5を用いていない事を確認しなければならない。また、ルート証明書は自己署名なのでどのようなアルゴリズムを用いているかは関係ない。

尚、今回の攻撃ではMD5の強衝突耐性が破られている(既存の攻撃と同じ)、弱衝突耐性が破られた訳ではない(任意の証明書が作れるのはCAの成り済ましに成功したからであってMD5の弱衝突耐性とは関係ない)。従って、既存のMD5を用いて署名された証明書が直接改竄できる訳ではない。もちろん、いまだにMD5を使用しているCAがある事自体が大問題な訳で、今回の発表は最後通牒と言えるだろう。

2007.04.19

APOPにMD5関連の脆弱性

IPAによれば「APOP 方式に、MD5 ハッシュ衝突に基づく攻撃手法が発見され」たとの事(JVN#19445002 APOP におけるパスワード漏えいの脆弱性)。

MD5は以前からハッシュ衝突の危険性が指摘されていた訳であるが、実際に衝突を起こして署名を捏造したりパスワードを解読したりする事に成功した事例は報告されていなかったように思う。今回は APOP 自体のプロトコル上の脆弱性と MD5 のハッシュ衝突の問題を組み合わせてパスワードの取得を行ったらしい。公開された情報から攻撃方法は「中間者攻撃」である。したがって正当にやりとりされるネットワーク上の通信を傍受してパスワードを取り出したという訳ではない。

とりあえず、詳しい情報へのリンク

乱暴に要約すると、今回の攻撃はMD5の脆弱性を突かれている事に加えハッシュをチャレンジ・レスポンスにしか使っていない事が対象になっているように思える。同じMD5を使用したチャレンジ・レスポンス型のHTTPのダイジェスト認証では、サーバ上に平文パスワードのハッシュ値が格納され、さらにハッシュ値に対するチャレンジ・レスポンスでハッシュ値を求める(つまり、ハッシュを2回使う)形になっているのでAPOPよりは平文パスワードを取り出す事の障壁は高い。もちろん、IPAの報告通り(中間者攻撃そのものを防ぐ事ができ、メール本文も保護する)SSLを使用するのが正しい対処である。

2005.04.21

Cross-Site Request Forgeries

Mixi で問題になっていたのだが、Cross-Site Request Forgeries (CSRF) と呼ばれる Web サイトに対する攻撃方法*1があるらしい(原典?)。要するに、悪意のある者(偽装者)が特定のサイト(攻撃対象)のフォームをコピーし、まったく違う目的のフォーム(またはリンクや単なるIMG要素など)に紛らわせてアクセスさせるものである。偽装する方法は単に偽装者が自身のサイトを用いて行ってもかまわないし、クロスサイトスクリプティング(XSS) を用いても良い。ちなみに、CSRF は XSS と似ているが、XSS とは異なり、必ずしも攻撃対象のサイトそのものにスクリプトを埋め込む必要は無い。したがって、対策も XSS とは異なるものが要求される。単純に思いつく対策を挙げてみる。


クッキー

リクエスト元ではなくリクエスト先のクッキーをブラウザが自動的に付与するため、先に攻撃対象のサイトに誘導して認証を済ませていれば防護にならない。

Basic認証

リクエスト先に応じてブラウザが自動的に認証情報を送るため、クッキーと同じ問題を持つ。

POSTメソッドの判定(GETメソッドの禁止)

IMG要素を利用した簡単なものなら検出できる可能性がある。ただし、フォームを利用したりJavaScript を併用した高度な攻撃には対応できない。

SSL

ブラウザはSSLの場合、他のサイトに対するアクセスは警告を発する場合が多いので防護できる可能性がある。

Referer

フォームなりリンク元のサイトなりが正しい事を確認する最も直接的な方法がRefererである。ただし、Refererは必ずつくわけではない。詐称も可能である。*2

これらの方法はまったく効果がないものからある程度の効果が期待できるものまで含まれているが、完全に防げるものではない。完全に防ぐための方法は以下のようなものが考えられる。


フォームの要素によるセッションの確認

偽装者が予測不能な要素をフォームの要素なりリンクなりに含める。単純にセッション保持用のクッキーの値と同じものでも良い。ブラウザはクッキーを自動的に付けるが、フォーム要素は明示的に指定しない限り付け加えない。セッションのキーが偽装者に予測不能(これは当然の要件)であれば充分である*3

ユーザ介入の要求

「削除して良いですか?」のようにユーザに対して確認を求める画面を出力する。ただし、単純に Yes と答えるように固定の応答を要求する場合は CSRF をもう一度繰り返して破られる恐れがある*4。再度ユーザ認証を求める(単純に同じパスワードをもう一度入力させる方法でも効果がある)か使い捨てトークンを併用するなど固定の応答にならないようにすれば機械的にまねる事はできない。

フォームの要素によるセッション管理は JavaScript でアクセスすれば破られるのではないかという指摘もある。しかし、偽装者が他サイトに仕組んだ JavaScript で攻撃対象の情報を取得できたとすればブラウザのセキュリティホールである。また、攻撃対象サイトに JavaScript が送り込まれたとすれば、サイトに XSS 脆弱性があったと言うことができる。

--------
*1: CSRFという名前は使用していないが kjm's home page にも同様の議論がある。
*2: 偽装者によって詐称することはできないのではないかという指摘が「高木浩光@自宅の日記」になされていたので修正した。
*3: 同じく、「高木浩光@自宅の日記」での指摘を受けて修正した。
*4: 言うまでもないが、サイト内部でのセッション管理がなく、単純に type=hidden の要素などで情報を引き継いでいる場合には直接確認画面に対して1度のCSRFを行えば攻撃できる。

2005.02.16

SHA-1が破られた?

セキュリティホール memoによれば
full SHA-1に対しブルートフォースした場合の2の80乗オペレーションよりも少ない2の69乗オペレーションによるコリジョンの検出がなされたとの事。これが「完全版 SHA-1 が破られた」事になるらしいですが私には解っていません。詳細はリンク先を参照してください(と言っても現時点ではあまり情報はありませんが)。

(2005/6/13加筆)
どうやら SHA-1 が破られたというのは言いすぎ(実際にコリジョンの検出はなされていない模様)らしい。ただし、SHA-1 が当初考えられたより 1/1000 くらいの強度であるという事になっているらしく、計算機の速さを元にアルゴリズムの寿命を想定していた場合、寿命が短くなる(=危殆化が進む)という事になる(例えば、5年で10倍の速度向上を想定していた場合、1/1000 では15年寿命が短くなる)。

2005.02.04

新しいspamメール送信方法

CNET Japan によれば「スパムの新しい送信方法が開発されたことからその数が急増しそう」とのこと。

従来のスパム対策は、信頼できないと思われる SMTP サーバからのメールを受け取らない事が中心であったが、新しい送信方法では、「スパムデータをISPに送信するよう(中略)命令」するとの事である。この結果、「主要ISPからのスパムが急増している。現在、すべてのISPのメールサーバから大量のスパムが送信されている」らしい。

原理的にユーザから送られる正規のメールと、悪意を持った(者の書いた)スパム用ソフトウェアから送られるメールを区別するのは難しいかもしれない。そのため対策が困難になる可能性がある(今のところ、送信できるメールの数を制限しようとしているらしい)。

#そういえば、携帯電話のメールでは既にメール数の制限はやっていたような…

今のところあまり詳しい事は解らない。詳細が解れば続報したい。

2005.01.24

Wi-Fi の新たな攻撃手段

CNET-Japan によれば、Wi-Fi ホットスポットに対する新たな(?)攻撃手段の警告が発表されたとの事。

「Evil Twin(悪の双子)」と呼ばれる偽物のアクセスポイントを設置する事によって通信内容を全て傍受する事ができるという趣旨で、これによってユーザ ID やパスワードを入手できるとのことである。実際にそのような脅威があるのか、対応策はあるのかを調べてみた。

通信傍受の防止と言えば、まず暗号化を思いつく。クローズドなネットワークであれば、WEP で暗号化することにより防ぐ事はできそうである。たとえ偽物のアクセスポイントを設置したとしても、WEP の暗号の鍵を入手できない限り通信内容は解らない。

しかし、公衆無線 LAN のアクセスポイントの場合は WEP のキーを含めて公開する必要があるため有効な防護策にはならない。偽物のアクセスポイントを設置した者が容易に暗号の鍵を得る事ができるからである。鍵に関する問題は共通鍵暗号自体の使い方の問題と言えるため、WEPを使っている限り解決しないと考えられる。

WEP の脆弱性は早くから指摘されており、対応策も既に策定されている。標準化されたものでは WPA (Wi-Fi Protected Access) は不正なアクセスポイントへの接続の防止も対象に入っており、IEEE802.1x に基づく相互認証を行う事が可能になっている。ただし、公衆無線 LAN のサービスプロバイダ自体が利用しなければ意味が無い。OCN のホットスポットなどは IEEE802.1x 対応を謳っており EAP-TTLS による認証を行う事ができるらしい。詳細は不明だが正しく運用されていれば EAP-TTLS のサーバ証明書によって偽アクセスポイントが検出できるはずである。

2005.01.05

IEの脆弱性

Internet Watch によれば、IE (Internet Explorer) にまた脆弱性が見つかったとの事である(Windows XP SP2では問題ないらしい)。

情報元によれば、

The vulnerability is caused due to an input validation error in the handling of FTP file transfers. This can be exploited by a malicious FTP server to create files in arbitrary locations via directory traversal attacks by tricking a user into downloading malicious files

となっていて詳細は解らないのだが、どうやら "directory traversal attack" (Path Traversal 脆弱性を付く攻撃)の一種らしい。疑問なのは、Path Traversal 脆弱性というのは通常はWebサーバ側の問題である事である。想像するに、URLの一部に /../ か \..\ などを含む特殊なファイル名を入れて置くのではないかと思うが、通常クライアント側では(サーバ側の位置を示している) path 部分のほとんどは無視してファイル名の部分だけを使用するのであまり問題になるとは思えない。強いて問題になりそうな部分と言えば Unicode Web Traversal という UTF-8 の解釈の方法に起因する問題くらいか。

いずれにしても、FTP の場合だけで起こる問題というのは解せない。URL の解釈の問題であれば HTTP 等でも同じ問題が起こるはずだからである。FTP の場合にはサーバからファイル名が送られるという事もあまり考えられないのだが。

2004.09.02

二重解放の脆弱性

セキュリティホールの中に、「二重解放の脆弱性(double-free vulnerability)」と呼ばれるものがある。

二重解放というのは、同じメモリ領域を二重に解放(使い終わったメモリ領域をシステムに返却)することであるが、通常はアプリケーションがクラッシュしたり単にエラー終了したり(何も起こらなかったり)するバグである。実際、単純なテストを行っただけでは何も起こらないことが多いため、発見する事が難しいありがちなバグである。二重解放がなぜセキュリティ上の脆弱性になるのか良く解らなかったので調べてみた。

Web上で調べた結果、二重解放では悪意のある攻撃者によって

  • サービス運用妨害(DoS)
  • 第三者への情報漏えい
  • 任意のコードの実行

が引き起こされるという(実際の攻撃法は見つかっていないケースしか発見できなかった)。

サービス運用妨害(DoS)は良く解る。アプリケーションが終了したりクラッシュすればサービスの運用は妨害される。問題は情報漏えいや任意のコードの実行である。これらはどのように起こるのであろうか。Webで調べたところでは詳しい説明はなかったので考えてみた。

マルチスレッドのプログラムによってサービスが提供されていたとして、あるスレッド(A)がメモリ領域を使い終わって解放したとする。ここで別のスレッド(B)がたまたま今解放したばかりのメモリ領域を取得してユーザ情報を書き込み、直後に元のスレッド A が二重解放のバグによって B が取得したばかりのメモリ領域を解放してしまうことがありえる。この場合、別のスレッド(C)によって問題の領域が再び取得され、別のユーザ情報を書き込んでしまうかもしれない。スレッド B はそんな事(二重解放)は知らないので今自分で書き込んだ情報と信じてユーザ情報を表示する(実は他人の情報)という事が起こるだろう。

もう一つのケースは、スレッド B が取得したメモリ領域にプログラムを読み込んで実行していた場合で、やはり二重解放のバグによってメモリ領域が解放され、別のスレッド C によって再びメモリ領域が取得されてネットワークから取得したデータを読み込んだ場合に起こる。この場合、スレッド B はメモリ領域が解放された事を知らないのでネットワークから取得されたデータ上をそのまま走行しつづけてしまう可能性がある。

これでめでたく情報漏えいと任意のコードの実行が可能になった。確かにあり得ることである。が、実際に攻撃するためには非常に微妙なタイミングでバグを発動させる必要がある。攻撃法が見つかっていないケースが多いのもうなずける。

最近のトラックバック

無料ブログはココログ

Googleアナリティクス

  • Googleアナリティクス