1 / 38

Yuji Ukai, Senior Software Engineer Ryan Permeh, Founding Software Engineer

Yuji Ukai, Senior Software Engineer Ryan Permeh, Founding Software Engineer Ryoji Kanai, Software Engineer. PacSec 2006 Conference The fourth annual PacSec conference November 27-30 2006, at the Aoyama Diamond Hall in Tokyo, Japan. Retina. Development Core Team. Network Security Scanner.

bern
Download Presentation

Yuji Ukai, Senior Software Engineer Ryan Permeh, Founding Software Engineer

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. Yuji Ukai, Senior Software Engineer Ryan Permeh, Founding Software Engineer Ryoji Kanai, Software Engineer PacSec 2006 Conference The fourth annual PacSec conference November 27-30 2006, at the Aoyama Diamond Hall in Tokyo, Japan. Retina Development Core Team Network Security Scanner

  2. 米国防総省がIPv6ネットワークへの移行を宣言米国内でIPv6は大きく注目米国防総省がIPv6ネットワークへの移行を宣言米国内でIPv6は大きく注目 システムのIPv6対応が急務セキュリティ製品もIPv6対応は必須 セキュリティスキャナもIPv6対応 IPv4で培ったテクノロジーの多くを利用可能しかし、新たに直面する課題が存在 IPv6対応により、ネットワーク型のセキュリティスキャン技術をベースとしたセュリティリスク管理が直面する課題とその解決法を提案 はじめに

  3. 国防総省によるIPv6化宣言でIPv6への取り組みが加速 - IPv6 を国防総省関係部局全体で採用- 戦場における兵士の安全や通信を確保新たに購入するネットワーク関連製品は全てIPv6対応 米商務省内でもIPv6利用に関する経済効果を検討 ドイツ、フランス、イギリス、中国、韓国の政府や軍でIPv6対応を推進 各ベンダーやISP、研究機関などはIPv6化を強力に推進 セキュリティリスク管理製品などもIPv6対応が必須課題 ネットワークのIPv6化の動き

  4. ネットワークをスキャンし、資産とその脆弱性を把握ネットワークをスキャンし、資産とその脆弱性を把握 脅威、脆弱性、資産の重要度を分析 ネットワークのリスクを把握、対策を推進する リスクを適切に管理するためには、ネットワークに対して正確かつ迅速なセキュリティスキャンを実施する必要がある→ 高速、高精度 IPv6化に伴い、速度と精度に影響が出る→ ホスト検出技術、リモートOS検出技術 ネットワーク型セキュリティスキャナを用いたセキュリティリスク管理

  5. IPv6Host Discovery

  6. ICMPや、TCP、UDPパケットにて、ネットワーク内で動作するホストを検出ICMPや、TCP、UDPパケットにて、ネットワーク内で動作するホストを検出 ネットワーク内の資産把握、および、脆弱性診断対象の取得に必須 広大なアドレススペース Secure Neighbor Discovery と CGA Privacy Enhanced Addresses IPv6化によるセキュリティスキャナへのインパクト - ホスト検出 ホスト検出

  7. アドレススペースが128bitに拡張されたため、通常のホスト検出手法は長時間を要す- 代表的なIPv4サブネットは、ホストアドレッシングに8bit1 パケット/秒: 5 分- 代表的なIPv6サブネットは、ホストアドレッシングに64bit1 パケット/秒 :50 億年http://www.6net.org/publications/standards/draft-chown-v6ops-port-scanning-implications- 00.txt 広大なアドレススペース

  8. Neighbor Discovery (ND) に対する攻撃に対処するNDはステートレス。Hijacking攻撃に脆弱 暗号技術を利用した安全なアドレッシングスキーム コリジョン攻撃の検出と回避 http://research.microsoft.com/users/tuomaura/Publications/arkko+-wise02.pdf Secure Neighbor Discovery と CGA アドレスが予測不能。検出対象アドレスを絞り込めない。

  9. ランダムなアドレスビットを生成するIETFスキームランダムなアドレスビットを生成するIETFスキーム IEEE identifier (i.e., a link-layer MAC address)の代わりに利用するプライバシー保護など ランダムなアドレスビットを生成し、時間とともに値が変化同じ値が再現する確立は非常に低い ブート時、あるいは、定期的に変化 Privacy Enhanced Addresses 64 bits 64 bits 現在のアドレス Seed、もしくはHistory md5 64 bits 64 bits 新しいアドレス 新しいHistory 新しいグローバルアドレスを生成するため、bit 6を0にする アドレスが予測不能。検出対象アドレスを絞り込めない。

  10. マルチキャスト Neighbor Discovery Ethernet ベンダーID DHCPv6 ステートテーブル Neighbor Cache IPv4の利用 ローカル検出と分散アーキテクチャ IPv6 ホスト検出手法

  11. マルチキャストは、IPv6のコアコンポーネントマルチキャストは、IPv6のコアコンポーネント マルチキャストを利用することで生きているアドレスをいくつか収集できる サイトローカル、あるいはリンクローカル限定 IPv6ノードの必須機能として、マルチキャスト機能が仕様に含まれているこのため、レスポンスを得られる可能性が比較的高い 一般的なグループ： FF02:0:0:0:0:0:0:1 – リンクローカル・スコープ 全ノード FF02:0:0:0:0:0:0:2 – リンクローカル・スコープ 全ルーター FF02:0:0:0:0:0:1:2 – リンクローカル・スコープ DHCPエージェント IPv6 レイヤー 3 – マルチキャスト

  12. Neighbor Discoveryは、ICMPv6独自のサービス ピア探索 (Neighbor Solicitation )IP アドレスを使用してリンク層アドレスを判定する (Layer-3 ARP)Neighbor Discoveryは、ローカルpingと同様、ホスト検出に利用できる。いくつかのホストではマルチキャストpingをブロックしてもNeighbor Solicitationはブロックしていない可能性がある。 ルータ探索ルーターに、Router Advertisementパケットをすぐに送信するよう要求 IPv6 レイヤー 3 – Neighbor Discovery

  13. IPv6アドレスの下位64ビットは、多くの場合、Interface IDとなっている Interface IDは、イレヤー2アドレスのEUI-64表記となっている。 このInterface IDの一部は推測できる(Layer-2 ベンダーID)検索スペースを削減できる EUI-64 : http://standards.ieee.org/regauth/oui/tutorials/EUI64.html ベンダーID : http://standards.ieee.org/regauth/oui/oui.txt Ethernet ベンダーID 00-01-02 00-07-E9 00-05-B5 00-E0-4C

  14. DHCPv6は、IPアドレスの付与状態を保持する必要があるDHCPv6は、IPアドレスの付与状態を保持する必要がある メモリ、あるいはファイルに保持されている付与状態をチェックする事で、生存しているIPアドレスを抽出できる ログ、SQLデータベース、アプリケーションAPI、あるいは、サーバプロセスのフック サーバへのアクセスと権限が必要 DHCPv6 ステートテーブル MSDN: DWORD DHCP_API_FUNCTIONDhcpEnumSubnetClients( DHCP_CONST WCHAR*ServerIpAddress, DHCP_IP_ADDRESSSubnetAddress, DHCP_RESUME_HANDLE*ResumeHandle, DWORDPreferredMaximum, LPDHCP_CLIENT_INFO_ARRAY*ClientInfo, DWORD*ClientsRead, DWORD*ClientsTotal ); DWORD DHCP_API_FUNCTIONDhcpEnumSubnets( DHCP_CONST WCHAR*ServerIpAddress, DHCP_RESUME_HANDLE*ResumeHandle, DWORDPreferredMaximum, LPDHCP_IP_ARRAY*EnumInfo, DWORD*ElementsRead, DWORD*ElementsTotal );

  15. IPv6ルーターとホストは、 Neighbor Cacheを保持している生きているIPアドレスをいくつか得ることができる IPv4のARPキャッシュに相当 生存しているIPアドレスと、対応したレイヤー2アドレスが含まれる SNMPや、OS、アプリケーション独自のAPIでアクセス可能 SNMP OID – .1.3.6.1.2.1.55.1.12 Windows – C:\research>netsh interface ipv6 show neighbors Interface 6: Local Area Connection Internet Address Physical Address Type fe80::210:a4ff:feb6:b972 00-10-a4-b6-b9-72 Stale fe80::211:25ff:fe5a:cd63 00-11-25-5a-cd-63 Permanent Linux – # ip -6 neigh show fe80::201:23ff:fe45:6789 dev eth0 lladdr 00:01:23:45:67:89 router nud reachable Neighbor Cache

  16. 混在モードのネットワークでは、通常、IPv4とIPv6の両方のアドレスが存在する。その場合はIPv4アドレスを利用する混在モードのネットワークでは、通常、IPv4とIPv6の両方のアドレスが存在する。その場合はIPv4アドレスを利用する IPv6移行アドレッシングスキームではIPv4アドレスが組み込まれる事が多く、サーチアドレススペースを減少させることができる(ISATAP , 6to4 Transitional Addresses) IPv4の利用

  17. IPv6は、内部からの見通しは良いが、外部からの見通しは悪いIPv6は、内部からの見通しは良いが、外部からの見通しは悪い 内部ネットワークにおけるホスト検出は比較的容易 外部からはやや困難 複数のスキャナを分散して設置 個々のスキャナを、NDやマルチキャストが利用できる範囲内に設置 負荷を複数のスキャナで分散する ローカル検出と分散アーキテクチャ

  18. IPv6OS Detection

  19. 対象のOSを、リモートからクレデンシャル無しで検出する技術対象のOSを、リモートからクレデンシャル無しで検出する技術 ネットワーク内の資産把握、および、対象の正確な脆弱性診断に必須 TCP/IPの実装の違いや、各サービスのバナーなどを利用し、OSを特定→ IPv4時代のICMP OS 検出技術が利用できなくなる 全てのTCP、UDPポートが閉じている状態だと、OS検出が不可 IPv6化によるセキュリティスキャナへのインパクト - リモートOS検出 リモートOS検出

  20. TCP/IPスタックの実装の違いから対象OSを推測するTCP/IPスタックの実装の違いから対象OSを推測する いくつかのテストパケットを送信し、そのレスポンスを解析 リモートOS検出技術の基礎 TCP OS 検出 (Nmap法) - TCPポートにパケットを送信し、そのレスポンスを解析 - Window SizeやTCPオプションの違いでOSを識別 ICMPv4 OS 検出 (Xprobe法) - 対象から送信されるICMPパケットを解析 - 様々なタイプのICMPパケットに対する応答やIPヘッダ値の違いでOSを識別 - TCP OS 検出と異なり、オープンポートの有無に左右されない ICMPv6 OS検出 - 対象から送信されるICMPv6パケットを解析 - IPv6ではICMPv4をサポートしないので、IPv6独自のOS検出が必要

  21. ICMPv4 OS検出技術 テストパケット • UDP Unreachable Port • ICMP Echo Request • ICMP Timestamp Request • ICMP Information Request • ICMP Netmask Request チェックする項目 • レスポンスの有無 • IP Length • IP Identification • IP TOS • IP Flags • IP Fragment Offset • IP TTL • Checksum X remote ICMP based OS fingerprinting techniques Ofir Arkin and Fyodor Yarochikin http://www.sys-security.com/

  22. ICMPv6 Echo Request ICMPv6 Echo Request (Invalid Code) UDP Unreachable Port ICMPv6 Multicast Listener Discovery ICMPv6 Neighbor Solicitation Windows XP SP2 Windows Vista Beta 2 Build 5384 Solaris 10 Linux Fedora 2.6.15 FreeBSD 6.0 ICMPv6 OS検出技術 - テストパケットと実験対象 テストパケット テスト対象OS

  23. Type = 129 Check sum Code = 0 Identifier Sequence Number Data . . . ICMPv6 Echo request / HopLimit - Probe&Response ・ Probe- ICMPv6 Echo Request Type = 128 Check sum Code = 0 ICMPv6 Echo Request Identifier Sequence Number Data . . . ・ Response - ICMPv6 Echo Reply Version Traffic Class Flow Label IPv6 Payload Length Next Header Hop Limit ICMPv6 Echo Reply

  24. ICMPv6 Echo request / HopLimit - Characteristics ・ Responseパケット HopLimit値の比較 ICMPv6 Echo Reply HopLimit 128 64 255 Windows XP Windows Vista Linux FreeBSD Solaris

  25. ICMPv6 Echo request / Invalid Code - Probe&Response ・ Probe- ICMPv6 Echo Request (不正なCode値) Type = 128 Check sum Code = 1 ICMPv6 Echo Request Identifier Sequence Number Data . . . ICMPv6 Echo Request の Code値は 0 と指定されている(RFC2463) しかし実際には、多くの実装は Code値をチェックしていない

  26. ICMPv6 Echo request / Invalid Code - Characteristics ・ Responseパケットの有無 ICMPv6 Echo Reply HopLimit 128 64 255 Windows XP Windows Vista Solaris ICMPv6 Echo Reply Invalid Code Yes No FreeBSD Linux

  27. UDP Port Unreachable / Probe&Response ・ Probe- クローズしているポートに対してUDPパケット(Over IPv6)を送信 Version Traffic Class Flow Label IPv6 Payload Length Next Header Hop Limit Source Port Destination Port UDP UDP Data Length UDP Check Sum Data . . . Closed Port を指定 ・ Response -通常、ICMPv6 Destination Unreachable Message が帰ってくる。 Port Unreachable Type = 1 Check sum Code = 4 ICMPv6 Destination Unreachable Unused 最小IPv6 MTUを超えない範囲での送信パケット

  28. UDP Port Unreachable / Characteristics RFC2463 "A destination node SHOULD send a Destination Unreachable message with Code 4 in response to a packet for which the transport protocol (e.g., UDP) has no listener, if that transport protocol has no alternative means to inform the sender." → MUSTではない ICMPv6 Echo Reply HopLimit ・ Responseパケットの有無 128 64 255 UDP Port Unreachable Solaris ICMPv6 Echo Reply Invalid Code Yes No Windows XP Windows Vista Yes No FreeBSD Linux

  29. ICMPv6 Multicast Listener Discovery / Probe&Response ルーターが、ローカルのリンクにマルチキャストのメンバーが存在するかを調べるプロトコル ・ Probe- 以下のMulticast Listener Discovery (MLDv1)パケットを対象に送信 Type = 130 Check sum Code = 0 ICMPv6 Multicast Listener Discovery Maximum Response Delay (0x0000) Reserved Multicast Address (全て0x00) ・ Response -通常、Multicast Listener Reportが帰ってくる。 Type = 131 or 143 Check sum Code = 0 ICMPv6 Multicast Listener Discovery Multicast Listener Report (Typeフィールドに依存)

  30. MLDv1 vs MLDv2 ・ MLDv2 - MLDv1に送信者情報(ソースアドレス)指定機能を追加したもの ・ MLDv1 QueryとMLDv2 Queryは同じICMPv6 Type(130)。端末はパケット長により両者を識別。 ・ 一部実装では、 MLDv1 Queryに対して MLDv2 Reportで応答。一部実装では応答を返さない。 Type = 131 Check sum Code = 0 ICMPv6 MLDv1 Multicast Listener Report Maximum Response Delay Reserved Multicast Address Type = 143 Check sum Code = 0 Reserved Multicast Address Recordの数 ICMPv6 MLDv2 Multicast Listener Report Multicast Address Record [1] Multicast Address Record [n]

  31. ICMPv6 Multicast Listener Report / Characteristics ・ Responseパケット ICMPv6 Echo Reply HopLimit 128 64 255 MLD Query Solaris MLD Query v1 None Windows XP Windows Vista v1 v2 FreeBSD Linux

  32. ICMPv6 Multicast Listener Report / IPv6 Hop-By-Hop Option ・ MLD Report パケットには、IPv6 Hop-By-Hop Optionが付随される ・ オプションの並びが実装によって異なる Version Traffic Class Flow Label IPv6 Payload Length Next Header = 0 Hop Limit Next Header = 58 Header Ext Len IPv6 Hop-by-Hop Option ICMPv6 Hop-by-Hop Option Hop-by-Hop Option Type = 131 Check sum Code = 0 ICMPv6 Multicast Listener Discovery Multicast Listener Report (Typeフィールドに依存)

  33. Type Length Data IPv6 Hop-By-Hop Option / Characteristics ・ オプションフォーマット Type 8bit オプションタイプ Length 8bit オプションデータ長 Data オプションタイプに応じたオプションデータ ・ オプションタイプ ・ オプションの並び方

  34. Type = 136 Check sum ICMPv6 Neighbor Advertisement Code = 0 Reserved S O R ルーターフラグ Target Address 要請フラグ 上書きフラグ Option (キャッシュされたアドレス更新) ICMPv6 Neighbor Solicitation / Probe&Response 同一リンク内の他ノードに対し、リンクレイヤアドレスの通知を要求するメッセージ ・ Probe- Neighbor Solicitation(近隣要請)パケットを対象に送信 Type = 135 Check sum Code = 0 ICMPv6 Neighbor Solicitation Reserved Target Address = Source IPv6 Address Option ・ Response - Neighbor Advertisement(近隣通知)が帰ってくる

  35. ICMPv6 Neighbor Solicitation / Characteristics ・ Overrideフラグ

  36. Fingerprint

  37. OS検出精度の測定- まだ多くのOSにアルゴリズムを適用していない- Fingerprintの収集 OS検出精度の向上- OSのバージョン差が認識できないケースが多い- より有用な特徴パラメータの抽出を試みる- Mobile IPやセキュリティ(IPSec)の実装は新しいため要解析 ICMPv6 OS検出 - 今後の課題

  38. Thank you for your attention ! Question ? Contact : Yuji Ukai <yukai@eeye.com>

More Related