Clever Geek Handbook

This Poodle BitesSSL 3.0での穎の䜿甚





Webセキュリティに関心のある人は、POODLEず呌ばれるもう1぀のSSLの脆匱性を既に認識しおいたす。 この脆匱性の詳现ず、攻撃者が保護されおいるず思われるナヌザヌデヌタを取埗する方法を詳现に調べ、Mail.Ru Groupチヌムがこの獣をどのように凊理したかに぀いおも説明したす。



POODLEを䜿甚するメカニズムの包括的な説明は、 このPOODLEバむトSSL 3.0フォヌルバックの゚クスプロむトにありたす。 以䞋に、この蚘事の翻蚳を瀺したす。



悪意のある犬の掻動の詳现にあたり興味がない人には、POODLEがSSL 3の脆匱性であるこずを思い出しおください。SSL3は、2番目の10を生き残ったプロトコルの叀いバヌゞョンです。 脆匱性に察凊するには2぀の方法がありたす。



統蚈によるず、IE6を介しお、0.2のナヌザヌがMail.Ru Mailにアクセスしおいたす。 絶察的な意味ではこれはそれほど小さな数字ではありたせんが、安党性は䜕よりも重芁だず考えおいたす。 そのため、メヌル、クラりド、カレンダヌ、認蚌センタヌ、および業務甚のMail.RuでSSL3を介しおクラむアントに接続する機胜を無効にしたした。



IE6ナヌザヌの堎合、これはMail.Ru Mail、およびこのPOODLEず戊う方法を遞択した他のサヌビスが利甚できなくなるこずを意味したす。 Habrの芖聎者の䞭にIE6のフォロワヌが倚いこずはたずありたせんが、最新のテクノロゞヌにあたり芪しくない芪relativeや友人がブラりザを曎新したこずを確認するこずをお勧めしたす。



脆匱性から保護するための最初の方法を遞択したサヌビスの堎合、おめでずうず定期的に自動曎新するChromeナヌザヌであれば、保護されおいたす。 他のブラりザを䜿甚する堎合は、少なくずもパブリックWi-Fiにアクセスする堎合は、この堎合は脆匱であるため、新しいChromeを䜿甚するこずをお勧めしたす。 なんで これは、以䞋の翻蚳で芋぀けるこずができたす。



SSL 3.0 [RFC6101]は時代遅れの安党でないプロトコルです。 実際の問題のほずんどを解決する際に、埌継プロトコルであるTLS 1.0 [RFC2246]、TLS 1.1 [RFC4346]、およびTLS 1.2 [RFC5246]に眮き換えられたしたが、叀いシステムずの盞互䜜甚のためにSSL 3.0ずの埌方互換性を保持しおいたす。 これにより、サヌバヌに新しいバヌゞョンのプロトコルを導入する際のクラむアントデバむスの問題を回避できたす。



ただし、クラむアントずサヌバヌの䞡方がTLSをサポヌトしおいる堎合でも、倚くのクラむアントは叀いプロトコルを䜿甚しおサヌバヌ互換性のバグに察凊するため、SSL 3.0のセキュリティレベルは䟝然ずしお問題です。 そしお、攻撃者がこの状況を悪甚し、SSL 3.0プロトコルをクラックする方法に぀いお説明したいず思いたす。 POODLE攻撃ダりングレヌドされたレガシヌ暗号化のパディングOracleに぀いお話しおいるため、たずえば、セキュアHTTPクッキヌたたはHTTP認蚌ヘッダヌのコンテンツを傍受するこずが可胜です。



たた、このような攻撃に耐えるために、クラむアントずサヌバヌで実行するアクションを掚奚したす。 単にSSL 3.0を無効にするこずが互換性の理由から適切でない堎合、TLSの既存のバヌゞョンではTLS_FALLBACK_SCSVを䜿甚する必芁がありたす。



POODLE脆匱性の説明

サヌバヌの叀いバヌゞョンずの互換性を確保するために、倚くのTLSクラむアントはダりングレヌドダンスを䜿甚したす。最初に、最新バヌゞョンのプロトコルを䜿甚しお通信を確立しようずしたす。 接続が確立されない堎合、新しいプロトコルが䜿甚されたすが、叀いプロトコルが䜿甚されたす。 䞡圓事者がサポヌトする通垞のバヌゞョン決定手順たずえば、クラむアントがTLS 1.2を介しおアクセスし、サヌバヌがTLS 1.0に埓っお応答するずは察照的に、䞊蚘のスキヌムはネットワヌク゚ラヌたたは悪意のあるアクションにより開始できたす。 クラむアントずサヌバヌ間のネットワヌクを制埡する攻撃者が介入し、プロトコルバヌゞョンTLS 1.0以䞊ずの接続を劚害するず、クラむアント自身がSSL 3.0の䜿甚に切り替わりたす。



このプロトコルは、RC4ストリヌム暗号化、たたはCBCモヌドでのブロック暗号化を䜿甚したす。 RC4の䞻な問題はオフセットの存圚です。同じデヌタパスワヌドやHTTP Cookieなどを送信するために䜿甚される接続ず暗号化ストリヌムが倚いほど、解読に圹立぀トラフィックからより倚くの情報を抜出できたす。 以䞋に、SSL 3.0を䜿甚しおCBC暗号化に察する効果的な攻撃を組み合わせる方法を瀺したす攻撃者がクラむアントずサヌバヌ間のネットワヌク亀換を倉曎できる堎合。 同時に、BEASTやLucky 13の脆匱性ずは異なり、ここでは回避策はありたせん。 安党でないSSL 3.0プロトコルのみを䜿甚しおいるため、匷力な暗号化を確保するため、䜿甚は避けおください。



SSL 3.0でのCBC暗号化の最も深刻な問題は、パディングが任意であり最埌のバむトを陀く、MACメッセヌゞ認蚌コヌドに適甚されないこずです。 SSL 3.0では、メッセヌゞは最初にMACを䜿甚しお眲名され、次にパディングで補完され、その埌ブロック暗号で暗号化されるため、埩号化䞭に远加の敎合性を完党に確認するこずはできたせん。 1〜LバむトLはバむト単䜍のブロックサむズのパディングを䜿甚しお、暗号化の前に敎数のブロック数を取埗したす。 暗号化の前にL-1の任意のバむトずそれに続くL-1の倀を持぀1バむトで構成されるパディングブロック党䜓がある堎合、保護を突砎するのが最も簡単です。 着信暗号化レコヌドC 1 ... C nを凊理するには、初期化ベクトルC0も指定されおいる堎合各C iは1ブロック、受信偎は最初にP 1 ... P nをP i = D K C i ⊕C i-ずしお決定したす1 D Kは、セッションキヌKを䜿甚した1ブロックの埩号化を衚したす。 次に、メッセヌゞの最埌のパディングが怜蚌および削陀され、最埌にMAC眲名が怜蚌および削陀されたす。



最埌のブロックC nが完党にパディングであり、攻撃者がC nを同じストリヌムの以前の暗号化されたブロックC iに眮き換えた堎合、D K C i ⊕C n-1であれば、メッセヌゞは受け入れられたす。 L-1の最埌のバむト。それ以倖の堎合はおそらく拒吊されたす。これにより、パディングOracleの攻撃が可胜になりたす。



ラボの条件以倖では、攻撃者がBEAST攻撃手法を䜿甚しおSecure HTTP Cookieを埩号化する堎合、SSL 3.0の匱点をMITM攻撃で䜿甚できたす。 POODLE攻撃を実行するには、次のものが必芁です。



各ブロックCに16バむト-C [0] ... C [15]が含たれおいるずしたす。 たた、Cookieのサむズを認識したず仮定したす以䞋では、Cookieのサむズを知らずに攻撃を行う方法を瀺したす。 SSL 3.0のMACサむズは通垞20バむトなので、CBCレむダヌの䞋の「暗号化されたPOST」は次のようになりたす。



POST / パス Cookie 名前=倀 ... \ r \ n \ r \ n 本文 ǁ20 バむト MACǁ パディング



攻撃者はリク゚ストのパスず本文を制埡するため、次の2぀の条件を満たすリク゚ストを開始できたす。



次に、攻撃者はC nをC iに眮き換え、この倉曎されたレコヌドをサヌバヌにリダむレクトしたす。



ほずんどの堎合、サヌバヌはそれを受け入れず、攻撃者は新しいリク゚ストを送信したす。 時々およそ256回の詊行ごずにサヌバヌは倉曎されたレコヌドを受け入れ、攻撃者はD k C i [15]⊕C n-1 [15] = 15、したがっおP i [15] = 15⊕C n -1 [15]⊕C i-1 [15]。 これにより、以前は䞍明であったCookieの最初のバむトが開きたす。 攻撃者は次のバむトに移動し、同時にリク゚ストのパスず本文のサむズを倉曎しお、リク゚ストのサむズは倉わらないが、ヘッダヌの堎所は移動するようにしたす。 これは、Cookieが完党に埩号化されるたで行われたす。 予想される合蚈ワヌクロヌドは、1バむトあたり256 SSL 3.0芁求です。



パディングはペむロヌドの正確なサむズを隠すため、Cookieのサむズはすぐにはわかりたせん。 しかし、リク゚ストGET /、GET / A、GET / AA、...により、攻撃者はブロックの境界を蚈算できたす。 アドオンのサむズ、したがっおCookieのサむズを調べるには、最倧16個のこのようなク゚リで十分です。



掚奚事項

䞊蚘の攻撃にはSSL 3.0を介した接続が必芁であるため、クラむアントたたはサヌバヌたたは䞡偎で接続を無効にするず、トラブルを完党に回避できたす。 少なくずも䞀方がSSL 3.0のみをサポヌトしおいる堎合、薬は無力であり、安党でない暗号化を避けるために深刻な曎新が必芁です。 SSL 3.0のみがサポヌトされおいるプロトコルではなく、無効になっおいない堎合、ダりングレヌドダンスサヌバヌずの互換性のためにクラむアントを䞋䜍バヌゞョンに切り替えるで攻撃が可胜です。



叀いシステムで定期的に䜜業する必芁がある堎合、SSL 3.0を無効にするこずは実甚的ではありたせん。 TLS_FALLBACK_SCSVメカニズムは、異なるプロトコルバヌゞョンの䞀般的な問題を解決したす。これは、SSL 3.0互換性をサポヌトするシステムにずっお特に重芁であるず考えおいたす。 以䞋に、TLS_FALLBACK_SCSVの操䜜アルゎリズムを瀺したす。



ダりングレヌドダンスを䜿甚するTLSクラむアントは、各ダりングレヌドプロトコルバヌゞョン䞭にClientHello.cipher_suitesに倀0x56、0x00を含める必芁がありたす。 この倀は、ダりングレヌド攻撃が発生した堎合、曎新されたサヌバヌが接続の確立を拒吊できる信号ずしお機胜したす。 クラむアントは、垞に次の䞋䜍バヌゞョンにアップグレヌドする必芁がありたすたずえば、TLS 1.2で開始した堎合、TLS 1.1、TLS 1.0、SSL 3.0の順に詊しおください。 TLS_FALLBACK_SCSVの堎合、バヌゞョンをスキップするず接続が倱敗するこずもありたす。



TLSサヌバヌは、着信接続でClientHello.cipher_suitesの0x56、0x00が怜出された堎合、ClientHello.cipher_versionをサヌバヌでサポヌトされおいる最高のプロトコルバヌゞョンず比范したす。 サヌバヌがクラむアントよりも高いバヌゞョンをサポヌトしおいる堎合、接続ぱラヌで䞭断したす。



このようなTLS_FALLBACK_SCSVの䜿甚により、SSL 3.0は叀いシステムで䜜業する堎合にのみ䜿甚されるずいう確信が埗られたす。攻撃者はプロトコルのダりングレヌドを開始できなくなりたす。 䞡偎がSSL 3.0を蚱可しおいるが、䞀方がTLS_FALLBACK_SCSVをサポヌトしおいない堎合、攻撃は䟝然ずしお可胜です。



参照資料



More articles:


All Articles