Slide1: Yuji Ukai, Senior Software Engineer Ryan Permeh, Founding Software Engineer Ryoji Kanai, Software Engineer Retina Network Security Scanner Development Core Team


Introduction: Introduction The American Department of Defense announced that they will move their network to IPv6. Because of this, IPv6 is currently in the spotlight in the U.S. All network devices should be updated to support IPv6 Security products must also updated to keep up Network security scanner must have be able to scan an IPv6 network. Most of the core technologies based on IPv4 can still be used, but we are facing some new issues. We will describe some of the issues and some possible solutions to the problem of security risk management in an IPv6 network.


IPv6 networking: IPv6 networking IPv6 is rapidly becoming more popular since the DoD IPv6 announcement. - DoD will switch their network to IPv6 across the board. - This network is responsible for supporting soldiers and signal communications. All new network devices purchased should already support IPv6. The US Department of Commerce is investigating the economic effect of IPv6. The governments and militaries in Germany, France, U.K., China, and Korea and Japan all have plans to push IPv6 forward in their networks. Many vendors, ISPs, and research institutes have accelerated their Randamp;D for IPv6 deployment. Security risk management solutions must consider the implications of supporting IPv6 as well.


Security risk management using network security scanner: Security risk management using network security scanner Scan the network. Collect the assets and their vulnerability information. Analyze the threat, vulnerability, and importance of asset. Know the risk factors on the network and take action to fix them. We must deploy accurate and fast vulnerability scanning to manage the risk on their network appropriately. Supporting IPv6 might have a bad effect on the accuracy and speed of a traditional scanning methodology. - Host discovery and OS detection technique


Slide5: IPv6 Host Discovery


Negative impact caused by supporting IPv6 - Host discovery: Negative impact caused by supporting IPv6 - Host discovery Discover the hosts using ICMP、TCP、and UDP probe. Host discovery is necessary to collect the asset information and list of targets for vulnerability scanning. Huge Address Space Secure Neighbor Discovery and CGA Privacy Enhanced Addresses Host Discovery


Huge Address Space: Huge Address Space The traditional host discovery method takes very long time because the address space is expanded to 128bit - A typical IPv4 subnet may have 8 bits reserved for host addressing 　 1 packet/sec : 5 min - A typical IPv6 subnet may have 64 bits reserved for host addressing 1 packet/sec : 50 billion years http://www.6net.org/publications/standards/draft-chown-v6ops-port-scanning-implications- 00.txt


Secure Neighbor Discovery and CGA: Secure Neighbor Discovery and CGA Joint research project to reduce attacks on Neighbor Discovery (ND) ND is stateless. Vulnerable for hijacking attacks. Cryptographically secure addressing scheme Can be used to prevent and detect collision attacks http://research.microsoft.com/users/tuomaura/Publications/arkko+-wise02.pdf Address can be guessed. We can not reduce search space.


Privacy Enhanced Addresses: Privacy Enhanced Addresses IETF scheme for generating random address bits Instead of using IEEE identifier (i.e., a link-layer MAC address) Privacy protection, etc. Generates short lived addresses with small chance of repeat Generated on boot or periodically at runtime Current Address Seed or History 64 bits 64 bits md5 64 bits 64 bits Set bit 6 to 0 to create global address New Address New History Address can be guessed. We can not reduce search space.


IPv6 Discovery Solutions: IPv6 Discovery Solutions Multicast Neighbor Discovery Ethernet Vendor ID DHCPv6 State Tables Neighbor Cache Target IPv4 Stack instead Local Discovery and Distributed Architecture


IPv6 Layer 3 – Multicast: IPv6 Layer 3 – Multicast Multicast is a core component of IPv6 We can get some live IP addresses using multicast Typically site or link local Certain IPv6 Functions require multicast, so you are likely to have responses Common groups: FF02:0:0:0:0:0:0:1 – All nodes on the local link FF02:0:0:0:0:0:0:2 – All routers on the local link FF02:0:0:0:0:0:1:3 – All DHCP agents on the local link


IPv6 Layer 3 – Neighbor Discovery: IPv6 Layer 3 – Neighbor Discovery Neighbor Discovery is an ICMPv6 specific service Peer Discovery (layer 3 ARP) Sent by a node to determine the link-layer address of a neighbor. Neighbor discovery can act as a link local ping replacement. Some hosts may block multicast pings, but none should block multicast ND solicitations. Router Discovery Host requests routers to generate Router Advertisements Packet immediately.


Ethernet Vendor ID: Ethernet Vendor ID It is typical to have the low 64 bits of the IPv6 Header comrpised of the Interface Identifier Interface is typically EUI-64 representation of the layer 2 Address Part of this can be guessed (Layer 2 Vendor ID), reducing search space EUI-64 : http://standards.ieee.org/regauth/oui/tutorials/EUI64.html Vendor-id : http://standards.ieee.org/regauth/oui/oui.txt 00-01-02 00-05-B5 00-07-E9 00-E0-4C


DHCPv6 State Tables : DHCPv6 State Tables DHCPv6 must keep internal state tables to track IP’s that were granted Examining in memory or on disk representation of this will turn up live IP’s May be logs, SQL database, an application API, or even hooking the server process Requires access to the server and rights to do this DWORD DHCP_API_FUNCTION DhcpEnumSubnetClients( DHCP_CONST WCHAR* ServerIpAddress, DHCP_IP_ADDRESS SubnetAddress, DHCP_RESUME_HANDLE* ResumeHandle, DWORD PreferredMaximum, LPDHCP_CLIENT_INFO_ARRAY* ClientInfo, DWORD* ClientsRead, DWORD* ClientsTotal ); DWORD DHCP_API_FUNCTION DhcpEnumSubnets( DHCP_CONST WCHAR* ServerIpAddress, DHCP_RESUME_HANDLE* ResumeHandle, DWORD PreferredMaximum, LPDHCP_IP_ARRAY* EnumInfo, DWORD* ElementsRead, DWORD* ElementsTotal ); MSDN:


Neighbor Cache: Neighbor Cache Every IPv6 router and host must keep a neighbor cache We can get some live IP addresses. Similar to an ARP cache in IPv4 Contains Live Addresses and their associated layer 2 addresses Can be accessed via SNMP or OS/Application specific APIs SNMP OID – .1.3.6.1.2.1.55.1.12 Windows – C:\researchandgt;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


Target IPv4: Target IPv4 Mixed mode networks often have both IPv4 and IPV6 addresses, use the ipv4 instead! IPv6 transition addressing schemes often embed ipv4 addresses in their scheme, potentially reducing the address search space (ISATAP , 6to4 Transitional Addresses)


Local Discovery and Distributed Architecture: Local Discovery and Distributed Architecture IPv6 designed to make internal visibility good, buyt external visibility poor Internal network discovery becomes somewhat easier External still a challenge Many distributed scanners Closer to the source, able to use ND and multicast Distributes workload across many platforms


Slide18: IPv6 OS Detection


Negative impact caused by supporting IPv6 - OS detection: Negative impact caused by supporting IPv6 - OS detection Detect OS type remotely without credentials. OS detection is necessary to manage the asset information and accurate vulnerability scanning. We can detect the remote OS type by examining the differences in TCP/IP implementation, network service banners, and other factors. We can use most of the OS detection methods designed for an IPv4 network, However, the IPv4 ICMP OS detection method can not be used as is. Currently, If a target closes all TCP and UDP ports, we can not detect the remote OS. Remote OS detection


Basics of remote OS detection: Basics of remote OS detection We detect the remote OS type by using the differences in TCP/IP implementations Send some packets and analyze the responses. TCP OS detection (Nmap method) - Send some specially crafted TCP packets and analyze the responses - OS is identified by some parameters (Window Size,TCP options, etc) ICMPv4 OS detection (Xprobe method) - Send some specially crafted ICMP packets and analyze the responses - OS is identified by ICMP types and some IP parameters. - It does not depend on open ports. ICMPv6 OS detection - Send some specially crafted ICMPv6 packets and analyze the responses - IPv6 doesn't support ICMPv4, so we need a new method for IPv6.


ICMPv4 OS detection: ICMPv4 OS detection Test packet Parameters to use OS detection Respond or No respond IP Length IP Identification IP TOS IP Flags IP Fragment Offset IP TTL Checksum UDP Unreachable Port ICMP Echo Request ICMP Timestamp Request ICMP Information Request ICMP Netmask Request X remote ICMP based OS fingerprinting techniques Ofir Arkin and Fyodor Yarochikin http://www.sys-security.com/


ICMPv6 OS detection - Test packets and targets: ICMPv6 OS detection - Test packets and targets 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 Test packets Targets


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


ICMPv6 Echo request / HopLimit - Characteristics: ICMPv6 Echo request / HopLimit - Characteristics Response packet - HopLimit ICMPv6 Echo Reply HopLimit 128 64 255 Solaris Windows XP Windows Vista Linux FreeBSD


ICMPv6 Echo request / Invalid Code - Probe&Response: ICMPv6 Echo request / Invalid Code - Probeandamp;Response Probe - ICMPv6 Echo Request with invalid code Type = 128 Code = 1 Check sum Identifier Sequence Number Data . . . ICMPv6 Echo Request 'Code' parameter in ICMPv6 Echo Request should be 0 (RFC2463) However, most implementations don’t check the code parameter.


ICMPv6 Echo request / Invalid Code - Characteristics: ICMPv6 Echo request / Invalid Code - Characteristics Response ICMPv6 Echo Reply HopLimit 128 64 255 Solaris Windows XP Windows Vista ICMPv6 Echo Reply Invalid Code Yes No Linux FreeBSD


UDP Port Unreachable / Probe&Response: UDP Port Unreachable / Probeandamp;Response Probe - Send a UDP packet over IPv6 to closed port Type = 1 Code = 4 Check sum Unused ICMPv6 Destination Unreachable As much of invoking packet as will fit without the ICMPv6 packet exceeding the minimum IPv6 MTU Flow Label Payload Length Destination Port UDP Data Length UDP Check Sum Data . . . Version Traffic Class Next Header Hop Limit IPv6 UDP Source Port Response - ICMPv6 Destination Unreachable Message is sent back from the target Port Unreachable Closed Port


UDP Port Unreachable / Characteristics: UDP Port Unreachable / Characteristics Response ICMPv6 Echo Reply HopLimit 128 64 255 Solaris ICMPv6 Echo Reply Invalid Code Yes No Linux FreeBSD '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.' RFC2463 → Not 'MUST' UDP Port Unreachable Yes No Windows Vista Windows XP


ICMPv6 Multicast Listener Discovery / Probe&Response: ICMPv6 Multicast Listener Discovery / Probeandamp;Response Probe - Send Multicast Listener Discovery (MLDv1) packet to the target Response - Multicast Listener Report is sent back from target The purpose MLD is to enable router to discover the presence of multicast listeners Type = 130 Code = 0 Check sum Maximum Response Delay (0x0000) Reserved Multicast Address ( All 0x00) ICMPv6 Multicast Listener Discovery Type = 131 or 143 Code = 0 Check sum ICMPv6 Multicast Listener Discovery Multicast Listener Report (Depend of Type field)


MLDv1 vs MLDv2: MLDv1 vs MLDv2 - MLDv2 = Added sender information (source address) on MLDv1 - MLDv1 Query and MLDv2 Query have same ICMPv6 Type(130). IPv6 node recognize the MLD version by checking the length of packet. - Some implementations make response by MLDv2 even if the query is MLDv1. Some implementations don't make any response. Type = 131 Code = 0 Check sum Maximum Response Delay Reserved Multicast Address ICMPv6 MLDv1 Multicast Listener Report Type = 143 Code = 0 Check sum Reserved Multicast Address Recordの数 Multicast Address Record [n] ICMPv6 MLDv2 Multicast Listener Report Multicast Address Record [1]


ICMPv6 Multicast Listener Report / Characteristics: ICMPv6 Multicast Listener Report / Characteristics Response ICMPv6 Echo Reply HopLimit 128 64 255 Solaris v1 v2 Linux FreeBSD MLD Query v1 None Windows Vista Windows XP MLD Query


ICMPv6 Multicast Listener Report / IPv6 Hop-By-Hop Option: ICMPv6 Multicast Listener Report / IPv6 Hop-By-Hop Option IPv6 Hop-By-Hop Option is included in MLD Report response packet The sequence of options is depend on implementation Flow Label Payload Length Version Traffic Class Next Header = 0 Hop Limit IPv6 IPv6 Hop-by-Hop Option Type = 131 Code = 0 Check sum ICMPv6 Multicast Listener Discovery Multicast Listener Report (Depend on Type Field) Next Header = 58 Header Ext Len Hop-by-Hop Option Hop-by-Hop Option ICMPv6


IPv6 Hop-By-Hop Option / Characteristics: IPv6 Hop-By-Hop Option / Characteristics Option sequence Option format Type 8bit option type Length 8bit option length Data Option data depend of option type Option type


ICMPv6 Neighbor Solicitation / Probe&Response: ICMPv6 Neighbor Solicitation / Probeandamp;Response Sent by a node to determine the link-layer address of a neighbor, or to verify that a neighbor is still reachable via a cached link-layer address. Probe - Send Neighbor Solicitation to the target Response - Neighbor Advertisement is sent back from target Type = 135 Code = 0 Check sum Reserved Target Address = Source IPv6 Address ICMPv6 Neighbor Solicitation Option Type = 136 Code = 0 Check sum Reserved Target Address ICMPv6 Neighbor Advertisement Option R S O Router flag Solicited flag Override flag


ICMPv6 Neighbor Solicitation / Characteristics: ICMPv6 Neighbor Solicitation / Characteristics ・ Override flag


Fingerprint: Fingerprint


ICMPv6 OS Detection - Future work: ICMPv6 OS Detection - Future work Determine the OS detection accuracy - Deploy this algorithm to more OSes - Collect more fingerprints Improve accuracy - Identify OS version - Find better parameters to be more accurate - Check the parameters related on Mobile IP and security (IPSec)


Thank you for attending !: Thank you for attending ! Questions ? Contact : Yuji Ukai andlt;yukai@eeye.comandgt;