1 / 48

Cisco の脆弱性 過去 - 現在 – 今後

Cisco の脆弱性 過去 - 現在 – 今後. 背景にあるもの http://www.cisco.com/warp/public/707/advisory.html. 本日のセッション. 過去 既知の脆弱性 デマ情報 影響 現在 ヒープ オーバーフロー スタック オーバーフロー Shell コード 今後. 序章. アクセス リスト TCP „established“ キーワード バグ 1995 年 6 月 2 日、最初の警告は常に Cisco が発表

jermaine-aguilar
Download Presentation

Cisco の脆弱性 過去 - 現在 – 今後

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Ciscoの脆弱性過去 - 現在 – 今後 背景にあるもの http://www.cisco.com/warp/public/707/advisory.html

  2. 本日のセッション • 過去 • 既知の脆弱性 • デマ情報 • 影響 • 現在 • ヒープ オーバーフロー • スタック オーバーフロー • Shell コード • 今後

  3. 序章 • アクセス リスト TCP „established“ キーワード バグ • 1995 年 6 月 2 日、最初の警告は常に Cisco が発表 • „established“コネクションの一部として内部に ACK または RST、あるいはその両方が設定された TCP パケットに適合するとされていた拡張アクセス リスト • バグによって TCP SYN パケットがこのルールに適合 • 全詳細が公表されること決してなかった (PSIRT であろうとも?) • どうやら、この問題が原因で MCI、SCI および cバス インターフェイスにルート キャッシング。キャッシングによりACL ルールの再検討が阻まれた。 Ref: http://www.netsys.com/firewalls/firewalls-9211/0001.html

  4. 序章 [2] • アクセス リスト „tacacs-ds“キーワード バグ • 1995 年 7 月 31 日 • キーワードが „tacacs-ds“から „tacacs“に変更された • コマンドライン パーサーに下位互換性がない • „tacacs-ds“を備えた拡張アクセス リストのエントリが、　ことごとく無視される • 特にキーワードを使用している „deny“ルールには悪い • Config キーワードのリネームの問題は IOS では一般的だが、これによってセキュリティ問題が世に送り出された Ref: http://www.cisco.com/warp/public/707/1.html

  5. さらなる IOS バグ • 1997 年 10 月 1 日、Cisco PPP CHAP のバイパス • PPP 認証の完全なバイパス • 詳細は公表されず、ベンダー固有の PPP 拡張機能に疑いを持たれる • 1997 年 10 月 10 日、„Land“アタック • 発信元および送信先のアドレスとポートが同じ TCP SYN パケット • IOS は最新バージョンまでもが脆弱だった • „新しい“CatOS にも影響があった Ref: http://www.cisco.com/warp/public/770/land-pub.shtml

  6. さらなる IOS バグ [2] • 1998 年 1 月 21日、Cisco AAA バグ • AAA を使用した処理が RADIUS/TACACS サーバからの応答情報を一切受信しない • 応答に制約があっても制約が適用されない • 1998 年 8 月 12 日、VTY ログイン バグ • 突発的に発生するルータのクラッシュに関するカスタマ レポートによりバグを特定 • 詳細は公表されなかった

  7. さらなる IOS バグ [3] • 1998 年 10 月 14 日、„履歴のバグ“ • ログイン プロンプトでの „奇妙な“ 文字の並びにより、以前のユーザのコマンドライン履歴が明らかになる • Cisco Advisory „ラボ テスト“ でバグ検索する „信頼おけるカスタマ“ について述べる • 1998 年 11 月 5 日、再びアクセス リスト • 7k シリーズ ルータ分散型ファスト スイッチングが出力アクセス リストの適用をし忘れる • 1995 年の „established“バグ のようではない?

  8. さらなる IOS バグ [4] • 1999 年 4 月 13 日、„NAT リーク“ バグ • NAT config でパケットのリーク • 再びカスタマのテストで見つかったと言われる • 新しい 12.0 メインラインにも影響 • 1999 年 6 月10 日、GSR で ACL „established“ • 4 年後、ついに 12000 シリーズ バックボーン ルータでも見つかる • 再び顧客により発見

  9. さらなる IOS バグ [5] • 2000 年 5 月 14 日、最初の HTTP バグ -%% • %% を含む GET リクエストの受信時にデバイスがフリーズする • 個別にも起きる • そして次のバグ: 2000 年 10 月 25日、HTTP クエリ • http://device_ip/whatever?/ への GET リクエストの受信時にデバイスがフリーズする • enable パスワードが必要

  10. さらなる IOS バグ [6] • あらゆる所に SNMP • 2001 年 2 月27 日、ILMI コミュニティ • 2001 年 2 月28 日、複数の脆弱性 • „ケーブルdocsis“ • RO ウォーク経由で RW コミュニティ可視化 • SNMP トラップ コミュニティ RO/RW に有効 • 2001 年 7 月 12 日、PPTP バグ • 変形パケット DoS • 初めて Cisco が信頼する (Candi Carrera)

  11. さらなる IOS バグ [7] • 2001 年 6 月 27 日、HTTP の重大事 • „exec レベル“ と認識されていたバグ • http://<device_addres>/level/16/exec/ • Advisory は今も „この脆弱性の悪用は知られていない“ と述べている • 2002 年 2 月 12 日、変形 SNMP • PROTOS がすべてを引き出す– これ以上のコメントは必要ない

  12. デマ情報 • IOS バックドア • やりにくいわけではない • Phix が、たった 1 日で Router Checksum fixup スクリプトを明らかにしてくれた ! [もうデマはなし] • BGP ハック ツール • ADMbgp が存在し、非常に効きそうである • Man-in-the-Middle アタックは効果抜群 • NSAバックドア • 現時点で兆候なし

  13. 過去における影響 • 簡単なサービス条件の否定頻繁に悪利用される • Land.c • VTY クラッシュ バグ • „Death on arrival“ バグ • コア ネットワーク フィルタのために利用が制限される • 脆弱なルータは、しばらく存在する • HTTP „exec レベル“ バグ • 広く悪利用された no matter what they say • ルータのスコアを所持して再構成 • Guess what, nobody noticed! (ちょっと、誰も気づかない!)

  14. 現在 改善されたのか?

  15. 最新の IOS バグ • 2002 年 5 月 15 日、Response Time Reporter (あるいは SAA) • シングル パケット DoS • 詳細は公表されることはなかった • UDP ポート 1967 • Data: \x00\x00\x00\x34 + ‚A‘ x 48 • 2003 年 7 月 16日、 „Death on arrival“ バグ • 再び設計の失敗、加えてひどい解析バグ • 悪利用が広まるのを防ぐため、慎重をきして Cisco から情報が公表された

  16. „現状の“ セキュリティ情報 • CDP ルータ DoS • EIGRPルータ がネットワーク全域の DoS を助長 • TFTP ロング ファイル名バッファ オーバーフロー 　　(悪用された) • OSPFバッファ オーバーフロー 　　　　　　　　　　　　　　(悪用された) • UDP echo サービス メモリのリーク • HTTP 2GB リクエスト バッファオーバーフロー　　　　 (悪用された)

  17. ホストブロック 前のブロック 次2 次1 前2 前1 次のブロック 次3 前3 ヒープ オーバーフロー • 2 種類のメモリ エリア: メインおよび IO メモリ • メモリ ブロックのポインタ リストに二重にリンク • IO では同じサイズ • メインではサイズが違う • おそらくツリー構造に基づいている • 1 つのブロックは複数のリンクしているリストの一部

  18. IO メモリおよびバッファ • IOS は、パケット転送と操作に関連するその他のトラフィックのための、固定サイズのバッファの調整されたリストを動的に使用します。 • パブリック バッファ プール(small、middle、big、very big、hug) • プライベート インターフェイス プール(サイズは MTU に依存) • 割り当て/割り当て解除はスレッショルドに依存 (perm、min、max、free)

  19. ブロックのレイアウト MAGIC 0xAB1234CD PID 割り当てチェック領域 RAMアドレス コードアドレス ‚show mem alloc‘ の文字列 ptr コード アドレス malloc() を呼び出したPC 次の ptr 前の ptr サイズ + 使用量 参照カウント ほとんどが 0x01 0xFD0110DF REDZONE

  20. ホスト ブロック ヘッダ Data データ Next block 偽ヘッダ Header オーバーフローの理論 • „ホスト ブロック“ が一杯になる • 次のブロック ヘッダが上書きされる – これにより „偽ブロック“ が作成される • IOS メモリ管理が偽ブロックの情報を使用するように • 期待した結果:任意のメモリ位置に書込む 利用バッファ

  21. ホスト ブロック 前のブロック 次2 次1 前2 前1 次のブロック 次3 前3 IOS における free() • 注意:メモリ ブロックの二重にリンクしたポインタ リスト • free() により、リストの要素が 1 つ削除される • ポインタ交換操作は Linux または Windows の操作と非常に似ている Host->prev=next2; (Host->next2)+prevofs=prev2; delete(Host_block);

  22. 任意のメモリ書込み MAGIC • FREE NEXT (FREE マークの次) と FREE PREV (FREE マークの前) はチェックされない • ポインタ交換が実行される • サイズ フィールドで 0x7FFFFFFF を使用することで、偽ブロックに „free“ とマークすることができる • どちらのポインタも書込み可能なメモリを指している必要がある サイズ + 使用量 ほとんどが 0x01 パディング MAGIC2 (FREE) パディング パディング コード アドレス FREE NEXT *free_prev=*free_next; *(free_next+20)=*free_prev; FREE PREV

  23. 悪用 – 過去における問題 • ヒープ オーバーフローには、アドレス次第でイメージや構成が必要になる • メモリ ブロックにおける PREV ポインタ • IO メモリの利用におけるサイズ値 • スタック位置 • 自身のコード位置 • 要件によって、信頼できるリモートでの利用が困難 / 不可能になる

  24. 小さなバグ ... • Cisco IOS 11.x、およびそれ以下のバージョン • UDP Echo サービス メモリのリーク • デバイスが UDP 長さフィールド が受けたデータと同量のデータを送信側に送り返す • IO メモリ ブロックをリークさせる • IO メモリには実際のパケット データが含まれている – しかし、正しいデータではない • ここでは、19 キロバイトのことを指している • IOS 12.x Cisco Express Forwarding (CEF) コードで明らかになっているバグに匹敵

  25. IOS フィンガープリンティング • リークした IO メモリには、メモリ ブロック ヘッダが含まれている • ブロック ヘッダにはブロックを割り当てた側のアドレスが含まれている • 割り当て関数のアドレスはイメージ単位に変更する • アドレスの範囲はプラットフォーム単位に変更する • 結果: 信頼できるリモート IOS フィンガープリント

  26. IOS フィンガープリンティング[2] MAGIC 詳細: PID 割り当てチェック Echo データ0x00 … 割り当て名 割り当て PC 次の ptr イメージ固有 前の ptr 受信 バッファ サイズ + 使用量 ほとんどが 0x01 プラットフォーム固有、位置を表す リング バッファ 情報 Ethernet ヘッダ IP パケット 受信 バッファ Hmm… いけるのか…? REDZONE

  27. リモート IOS スニフィング • リークした IO メモリには、受信バッファ内のパケットが含まれている (RX リング ds 要素) • Phenoelit IOSniff • 度重なるメモリ リークの回復 • メモリ ブロック識別 • パケット オフセット識別 • パケットの復号化 • キャッシュ処理と複製を防止

  28. IOS HTTP バグ • 組み込まれた HTTP 実装のほとんどが脆弱 – Cisco も例外ではない • この問題に関連する整数または集計 • IOS 11.x – 12.2.x • 2 GB サイズに調整された URL をデバイスに送信する必要がある • スタック ベースのバッファ オーバーフロー

  29. 現状 • UDP Echo メモリ リーク • アタッカーがバイナリ データを設置 (配信された Echo コンテンツ) • 生存している IOS メモリ アドレス(リークした IO メモリ ブロック ヘッダ) • 複数のメモリ エリアに、こちら側のバイナリ データを詰め込む能力 (リング バッファ) • HTTP オーバーフロー • ダイレクト フレーム ポインタと戻りアドレスの上書き

  30. 現在可能な手段 • 完全なバイナリ shell コードを送信する • IO メモリ ブロック ヘッダの情報を使用するコードのアドレスを計算する • ほとんど修正されていない shell コードを選択する • 提供した shell コードで直接転送を実行する • ボックスを所有する

  31. 合成 • IOS が許可している最大の URL 長を送信する • 正しいサイズに調整されたチャンクで 2 GB の追加 URL を送信する • リクエスト パケットにおいて、shell コードで UDP メモリ リークを数回実行する • どのアドレスを使用するか賢明な選択をする • オーバーフローを終わらせて制御を掌握する

  32. HTTP 接続 + 正当なサイズの URL 2 GB の /AAAAAA/AAA..../ 満足するまで 繰り返す UDP Echo への Shell コード リークしたメモリ ブロック HTTP オーバーフローを終わらせる Again, in color 所有

  33. HTTP 経由のバイナリ • Cisco の HTTP はすべての文字を受け入れるわけではない • スラッシュ、0x0a、0x0d、および 0x00 は、明らかに HTTP には悪い • 他にも悪いものはいくつかある • HTTP エンコード処理 (%XY) をサポート • デコード処理がまったく同じバッファで行われているように見うけられる • 戻りアドレス HTTP はエンコードされる

  34. リターンアドレスの選択肢 • 複数のアドレス選択戦略がテストされています。 • 最後に取得したアドレス (約 50% 成功) • ランダムに選んだアドレス(約 50% ~ 60% 成功) • 最も高いメモリ位置 (約 0% ~ 10% 成功) • 最も低いメモリ位置(約 90% 成功) • 最も頻繁に現れるアドレス(約 30% ~ 40% 成功)

  35. バイナリ IOS のリサーチ • Cisco ではシリアル gdb をサポート • ROM モニタ (rommon) で限定したデバッグが行える • ブレークポイント • ウォッチポイント • 分解 • コード識別が簡単 • 関連するデバッグ文字列がコードに存在する • データおよびテキスト セグメントが互いに混ざりあっている • 関連する関数の前に文字列が格納される

  36. 次世代のコード • 実行時 IOS パッチ • パッチを当てた (無効な) 要素: • IOS テキスト セグメント checksum 関数 • VTY コネクションの認証要件 • “enable mode” 関数からの Verification 戻りコード • 将来は: ACL または BGP 近隣チェック? • IOS を稼動させ続ける … しかし、どうやって?

  37. Clean の戻り • オーバーフローは、HTTP エンコーディングのために多量のスタックを破壊する • 24 バイトのエンコード結果: %fe%fe%ba%be%f0%0d%ca%fe • 8 バイトのデコード結果 • Motorola 呼び出し構造体は、A6 のフレーム ポインタとスタックに保存されているスタック ポインタを使用する • 関数の保存されている SP の前にスタック ポインタを移動させると、SP と A6 をリストアする • スタックの “上の方” へ希望の関数の戻りアドレスを検索する SP = <current> - 4 unlk a6 rts

  38. Clean の戻りコード IOS 11.3(11b) HTTP オーバーフロー find の戻りコード move.l a7,a2 findret: addq.l #0x01,a7 cmp.l #0x0219fcc0,(a7) bne findret move.l a7,(a2) sub.l #0x00000004,(a2) move.l (a2),a6 clr.l d0 movem.l -4(a6),a2 unlk a6 rts

  39. 実行時 IOS パッチ • メリット • ルータがオンラインのままである • 構成が保存される • IOS 実行時コードでのバックドア • デメリット • イメージに依存する • 大型のターゲット リストが必要(イメージ単位のコード アドレス) • コンソールの “checksum のエラー” メッセージがいらだたしい 

  40. CISCO CASUM EST • 信頼できるリモート IOS の利用 • アドレス計算および UDP Echo 情報のリークによる shell コードの配置 • 2 番目に小さいアドレスを使用したアドレス選択 • 1 番小さいものは HTTP 転送に使用される • 実行時 IOS パッチは VTY を無効にしてモード パスワードの検証を有効にする

  41. 別のアプローチ • イメージ依存 shell コードを anyone (誰でも OK) で? • IOS コードの修正は、イメージに依存する • IOS 構成の修正は、イメージに依存しない • 実行時 config 変更コードはオリジナルの config を保存して、ほんのわずかの „要素“ を変更する • Shell コードには次のものが必要 • Strstr() • Memcpy() • Checksum() • “うむ、これならできる”

  42. Config 変更コード • NVRAM で構成の出だしを検索する • 次のものを検索する“\n password ““\nenable “ • 検索結果を、自分の “データ” で置き換える • ここで次の認証情報を置き換える • コンソール パスワード • VTY ライン パスワード • Enableパスワード (パスワードを暗号化しない) • Enable secrets (パスワードを暗号化する) • Recalculate checksum (再計算 checksum ) • Reboot (リブート)

  43. Config 変更コード • メリット • イメージに依存する • 構成が保存される • 選択の幅が広い • デメリット • プラットフォームに依存する • いったんルータをリブートしなければならない

  44. その結果は? • コミュニティの IOS バグの悪利用に関する経験が高くなる • 今も IOS には内部の防御がない • 今も古いコード ツリーに機能が追加されている • 今も IOS はバッファに収まりきらないほどのデータをバッファにコピーしている • 注意: その他にも IOS の悪利用もあるが、public でのみ行われる

  45. 今後 希望?

  46. “相手はまだ解析できていない!” • ここで取り上げたバグのほとんどは解析されている • リサーチは、IOS での各サービス処理がサービス自体の IP パケット解析を行っていることを示している • ご自身でご確認ください: • HTTP リクエスト:GET / 0x7FFFFFFF.0xFFFFFFFF • デバッグ出力の結果:HTTP: クライアント バージョン 2147483647.-1

  47. アウトルック (Microsoft 社のソフトではなく「見解」) • „Death on arrival“ バグは設計に関連するものである • 将来、さらに増える可能性がある • まだ、すべてのオーバーフローが検出されているわけではない • 完全な書き換えは進行中である (再度) • それが出れば安全になあるのか? • ロード可能なモジュールをサポートするのか? • サードパーティのモジュールはどうか? • 22.000 以上のイメージが製造されているが、そのすべてを誰が更新するのか?

  48. now. THIS IS THE POWER IN THE NETWORK. • Dragos for the invitation to PacSec.jp • The Phenoelit Members • The Members of c0d3andb33r • all@ph-neutral • Phix for being real cool • Halvar, Johnny Cyberpunk, Gera and others for ideas and support • Riley and the Eeye ppl • Kaminsky and the Avaya crew

More Related