SYMANTEC ADVANCED THREAT RESEARCH 1 Windows Vista Network Attack Surface Analysis: A Broad Overview
Tim Newsham1 and Jim Hoagland, Principal Security Researcher, Symantec Corporation
variant. The amount of new code present in Windows Vista provides many opportunities for new defects. Each new protocol comes with its own collection of security implications that will need to be understood and considered. Note that we have made an effort to discover public sources that may document or otherwise describe the new technologies in Windows Vista. In some cases, however, we may have overlooked these sources or new sources may have been published since this paper was written. It is not our intent to mislead the reader or to provide incomplete information. Symantec evaluated the security of the network stack of public pre-release versions of Microsoft's Windows Vista operating system. Our investigation was broad and shallow, aiming to provide timely intelligence on the new system by covering as many aspects of the network stack as was practical in a small amount of time. Because of the limited amount of time given to the project, our analysis did not penetrate very deeply into any one aspect of the network stack and was forced to omit some key components. When omissions were made, we attempted to cover the most common configurations and components that were most likely to come under attack. We performed our analysis on the public beta builds 5231, 5270, and 5384 of Windows Vista. Since Windows Vista is still a work in progress, we expect many of our results to be invalidated by changes made prior to its public release. The remainder of this paper will detail our analysis of the Windows Vista network stack. The discussion is ordered according to network layer. In section II we discuss link layer protocols. Section III covers network layer protocols and section IV covers transport layer protocols. Section V covers the Windows Firewall, a component whose design cuts across many protocol layers. Section VI covers the servers and clients that operate at the application layer. Finally, sections VIII and IX present our conclusions and suggestions for future work. II. LINK LAYER PROTOCOLS Windows Vista supports protocols at the Link Layer for transporting IP and IPv4 packets, for performing address resolution and auto configuration tasks, and for providing topology information for network diagnostics. For Abstract--A pre-release version of Microsoft Windows Vista was examined to determine the external security exposure and to identify how the networking components have changed from previous versions of Microsoft Windows. Changes in the networking stack, network services, and core protocols are enumerated and their effect on the external security of the system is analyzed. Index Terms--Computer network security, Computer security, Operating systems. W I. INTRODUCTION
INDOWS Vista is Microsoft's much anticipated new client operating system. When released, it is due to replace Windows XP as Microsoft's premier desktop operating system. Windows Vista represents a significant departure from previous Windows systems both in terms of its emphasis on security and its many new features. As security has grown in importance, Microsoft has paid increasingly more attention to it, evidenced by the significant resource investment that has been made. Windows Vista provides Microsoft with its first opportunity to introduce security into the design process of the core operating system itself. Microsoft has also chosen Windows Vista as the platform on which to introduce many newly developed technologies. The Windows Vista network stack is particularly interesting because many of its components are new. The TCP/IP network stack itself has been rewritten and is one of Vista's largest departures from previous versions of Windows. The new stack was written to allow easier maintenance, important new performance enhancements, and improved stability [30]. It integrates support for IPv6 and IPv4 into a single network stack and provides IPv6 support in the default configuration for the first time in the history of Windows. Many other new protocols are implemented and supported in Vista, either as part of the network stack or as separate components of the Windows operating system. These new protocols support features such as topology discovery, server-less name resolution, and NAT traversal. Even SMB, one of Microsoft's oldest technologies, received a revision with the introduction of the SMB2 1 Tim Newsham conducted this research under contract with Symantec. SYMANTEC ADVANCED THREAT RESEARCH transporting IPv4 and IPv6 packets, Windows Vista uses protocols such as Ethernet, PPP, and PPPoE. In support of the IPv4 and IPv6 protocols, Vista supports ancillary protocols such as the Address Resolution Protocol (ARP) and Neighbor Discovery (ND), which are necessary to support the transmission of IPv4 and IPv6 packets. Windows Vista also introduces support for the new Link Layer Topology Discovery (LLTD) protocol which is used to provide network maps to assist in diagnosing networking problems. We analyzed the ancillary support protocols ARP and ND to determine how they responded to redirection attacks. We also performed a cursory analysis of the undocumented LLTD protocol. As with all link layer protocols, attacks against these protocols are limited to the local network. In the interest of time, we did not perform an analysis of Ethernet due to its simplicity nor of PPP or PPPoE since those protocols are typically used on private links to which an attacker will be unlikely to have access. Analysis of PPP and PPPoE may be warranted in the future. A. Address Resolution The ARP[27] and ND[24] protocols provide Ethernet address resolution for IPv4 and IPv6, respectively. ARP operates at the link layer and provides mechanisms for querying the link layer address of an IPv4 node and for propagating address changes to other hosts on the link. ND is implemented using ICMPv6[5] packets above the IPv6 layer but provides necessary services to transmit packets at the link layer: querying for the link layer address of an IPv6 node, propagating address changes, and autoconfiguring addresses and routes. ND makes use of welldefined IPv6 multicast addresses[14] with fixed link-layer addresses[6] to avoid bootstrapping problems. Both protocols are integral to the operation of the IP network stack and are enabled during installation. ARP is susceptible to a redirection attack when an attacker sends a "gratuitous-ARP" packet (normally used to propagate address changes) to a target host [Appendix II]. After receiving such a packet, the target will forward future packets to the attacker's node rather than the intended target. We observed that the Windows Vista stack will accept the information in a gratuitous ARP packet sent to the broadcast link address or to the host's link address and create a new entry in the host's ARP table or overwrite an existing entry. When an existing ARP table entry is overwritten, no warnings are displayed to the user or logged in the system event log. When processing an ARP packet that contains the same IP address as the host, the Windows Vista stack will log the address conflict in the system event log but will not otherwise notify the user of the conflict. After logging the conflict, the Windows Vista networking stack marks its network interface as having a conflict and stops initiating packets from that interface, effectively rendering the interface useless. Oddly enough, pre-existing connections 2 on the host are not affected. The interface remains in this state until it is reset by reacquiring a DHCP lease. The Neighbor Discovery implementation is much more robust to redirection attacks than the ARP implementation. We observed that the Windows Vista ignored all unsolicited ND responses [Appendix III]. However, it did update the neighbor table when receiving ND responses during the Probe phase of neighbor discovery. Two factors contribute to increase the practicality of redirection attacks: ND table entries timeout fairly quickly and the ND module keeps an address in the Probe phase for a significant amount of time. Taken together these factors make it easy to perform a redirection attack against ND by sending out spoofed ND replies periodically or in response to a legitimate request2. ARP packets are sent in Ethernet frames, but ND communicates using ICMPv6. However, ND is prima facie not vulnerable to remote attack since link-local addresses are used and the network stack verifies that an ND packet has a hop count of 255 before processing its contents. The hop count is decremented each time a packet is forwarded and discarded when its count reaches zero. Since 255 is its maximum value, ND packets cannot be received from a remote network with a hop count of 255 3. B. LLTD The Link Layer Topology Discovery protocol is a newly developed protocol designed by Microsoft for discovering hosts on the local network. LLTD is a core component in Microsoft's network diagnostic strategy. By providing high-quality topology information to end users, Microsoft hopes to make it easier for users to manage their home networks. LLTD is implemented in Windows Vista as two components: · a client program, which initiates and directs topology discovery · a server ("responder"), implemented as a kernel driver, which responds to requests. The client program is invoked when a user requests that a network map be generated from the networking control panel. The responder is configured during installation and is always running unless explicitly disabled. We are unaware of any public documentation of the LLTD protocol. We performed a cursory analysis of the protocol and were able to decode many of the protocol fields [Appendix IV]. Figure 1 shows data from a typical LLTD packet decoded according to our best efforts. LLTD packets are transmitted using Ethernet type 0x88d9. The first 14 bytes of the figure represent the Ethernet header. Immediately following the Ethernet header are four bytes containing a version number, a flag field, and a message
2 The IETF has defined SEND[1] as a way to provide secured Neighbor Discovery. 3 Tunneling protocols may provide a way around this restriction. We have not investigated any ND attacks used in conjunction with tunneling. SYMANTEC ADVANCED THREAT RESEARCH type. We observed types varying from 0 to 9. The header contains several MAC address fields and a few unknown field types. The majority of the packet is made up of typelength-value encoded fields. TLV encoding allows easy decoding even without a full understanding of the packet format. Appendix IV contains a more detailed analysis of the protocol.
ff ff ff ff ff ff 00 c0 9f d2 0c f8 88 d9 01 ff 00 00 00 00 01 00 02 03 0c 0a 00 0b 0f 65 69 61 14 00 01 ff c0 00 0c c0 06 00 04 04 04 08 36 04 12 00 00 00 04 00 ff 9f 00 9f 9f 01 ff d2 0c d2 d2 ff ff 0c f8 0c f8 0c f8 dst (broadcast) src type (LLTD) version 1, ??, msg type 1 mac (dst) mac (src) mac mac Type 1, Value 0 Type Type Type Type 2, Value: 3, Value: 12, Value 10, Value 0 6 0x0f4240 0x369e99 3 where previous implementations offered a separate IPv6 stack as an optional component. Both stacks share many implementation characteristics as a result of this tight integration. The inclusion of IPv6 support in Windows Vista is a major departure for Microsoft. IPv6 provides a lot of functionality, backed by a lot of code that has not been tried by extensive use in a hostile environment. To make matters worse, many of the defenses relied on to protect today's IPv4 networks either do not yet support IPv6 or are similarly immature. As IPv6 sees wider deployment, we expect that attackers will heavily scrutinize this protocol. A. IP Behavior We measured implementation characteristics of the IPv4 protocol layer and compared them to previous implementations. The characteristics we measured were IP ID generation and IP fragment reassembly behavior. We observed that the Windows Vista stack generates IP packet identifiers (used in fragment reassembly) sequentially [Appendix V]. This behavior is identical to that of the Windows XP stack. Sequential IDs can be used to measure the network activity of a host. When two packets are received from a host, the amount of traffic that was sent in the intervening time is the difference between the IDs in each packet. Sequential IDs are also useful in counting hosts behind a NAT firewall[4]. The Windows Vista networking stack behaved differently than the previous XP stack and other popular networking stacks when reassembling IPv4 fragments [Appendix VI]. Vista strictly discards all packets containing fragments with partial overlaps. In cases of total overlap, newer fragments are discarded in favor of previously received fragments. The Windows XP stack would allow partial overlaps and had a more complicated reassembly behavior. As a result of these differences, identical traffic sent to XP and Vista targets may be interpreted differently. Ambiguities in the interpretation of traffic provide opportunities for confusing network intrusion detection devices unless handled appropriately[25]. B. IP Protocols Unlike the Windows XP stack, the Windows Vista stack responds to received packets containing an unhandled protocol type with an ICMP error message. We were able to make use of this behavior to enumerate the IP protocols that are configured during installation of Windows Vista [Appendix VII]. In build 5270, there was a response for both IPv4 and IPv6. However, in build 5384, we find that the ICMP error messages are no longer sent for IPv4. As such, it was necessary to turn off the firewall to update that protocol list. The following IPv4 protocols are configured on a Windows Vista host: ICMP, IGMP, IPv4, TCP, UDP, IP6, GRE, ESP, AH, 43, 44, 249, and 251 (GRE and 249 are new with 5384). The following IPv6 protocols are configured: IPv4, 00 00 00 00 00 00 00 00 9e 00 61 72 73 00 00 0f 00 99 02 00 00 00 00 00 42 00 62 63 76 74 00 06 40 00 5a 00 00 00 Type 1, Value 0x026251 Type 15, "acervista" 80 00 00 00 Type 20, value 0x80000000 Type 0, End of TLVs. Figure 0 Figure 1: Encoding of a typical LLTD packet. We were able to construct an LLTD request that elicited a response from all LLTD responders. The response received back from each LLTD responder contains important information such as the name, Ethernet, IPv4 and IPv6 address of the host. We were not able to cause LLTD responders to generate other traffic on our behalf, although we know LLTD has this functionality[9]. The ability to cause other hosts to generate traffic on an attacker's behalf is often a useful tool in a denial-of-service attack. While some smarter switches may prevent it, in many cases an attacker can already saturate a link and forge source addresses without this mechanism. III. NETWORK LAYER Microsoft chose to rewrite the Windows Vista IP stack rather than derive it from the previous Windows XP stack. This new stack integrates support for IPv4 and IPv6 into a single network stack and, according to Microsoft, is easier to maintain, boasts increased performance, and is more stable than their previous network stack[30]. Windows Vista is the first Windows operating system to enable IPv4[28] and IPv6[7] during installation. The Vista stack integrates IPv4 and IPv6 into a single network stack SYMANTEC ADVANCED THREAT RESEARCH TCP, UDP, IPv6, ICMPv6, ESP, AH and 251 (IPv4 is new with 5384). IPv6 handles header options as protocol payloads and the IPv6 stack supports the Hop-By-Hop, Route, Fragment, and Destination options. These protocols represent core (IGMP, ICMP, TCP, UDP and ICMPv6), tunneling (IPv4, IP6), and security (ESP and AH) protocols. Four protocols configured in Windows Vista are not commonly used: protocols 43, 44, and 249 in IPv4, and protocol 251 in IPv4 and IPv6. Protocols 43 and 44 coincide with the values used to represent IPv6 Route and Fragment options; we believe that their presence in the IPv4 stack is likely an oversight caused by the integration of the IPv4 and IPv6 stacks. In build 5270, we observed that sending random data to the host over protocol 43 causes the host to become unresponsive for a long period of time and that sending random data over protocol 44 causes Vista to crash with a blue screen. This is consistent with an implementation that does not expect to receive these protocol types over IPv4. This behavior has since been resolved in build 5384. The remaining protocols, 249 and 251, are within the unassigned range[16]. Thus far we have not been able to elicit any responses when sending data to a Vista host using these protocol numbers, identify the service or driver making use of this protocol, or find any reference to this protocol online. Analysis of all three exceptional protocols was light; further investigation will likely be rewarding. We also found it surprising that the network stack appears to support tunneling of IPv4 in IPv4 packets and IPv6 in IPv6, but we did not have time to verify that these features were functional or to explore their security implications. C. Defects We tested the stability of the Windows Vista TCP/IP stack using a suite of historic attacks and using random fault injection. Our testing uncovered several defects in earlier builds that leave the system vulnerable to denial-of-service attacks and possibly worse. These defects appear to be fixed by build 5384. We observed that Windows Vista is vulnerable to several historical packet-level attacks against the TCP/IP stack [Appendix VIII]. These well-known vulnerabilities have since been remedied in all popular network stacks. Two of the vulnerabilities observed in Windows Vista build 5231 have been addressed in build 5270; the other was addressed in 5384. The first attack, called "Blat," sends a TCP SYN packet to the target with an urgent pointer that points beyond the end of the packet. The effect this has on a Vista target is to cause the IPv4 stack to become unresponsive for a few seconds (the IPv6 stack continues to run independently). This vulnerability has been addressed by build 5270. The second attack, called "Land," sends a TCP SYN packet to the target's address using the same source and 4 destination address and ports. This can cause a target to reply to itself. The effect this attack has on a Vista target is to cause the IPv4 stack to become unresponsive for a few seconds. This vulnerability has been addressed by build 5270. The third attack, called "Opentear," sends a flood of improperly formatted UDP fragment packets to the target from a large number of forged source addresses. The effect this has on a Vista target is to cause the entire machine to be unresponsive until the flood of packets subsides4. This vulnerability was present in the 5231 and 5270 builds, but has been addressed as of build 5384. In our testing we also discovered a number of new instabilities in the Windows Vista network stack that were present in earlier builds. To test for new vulnerabilities, we flooded the target host with randomly generated malformed traffic. We isolated and analyzed any packets that caused undesirable behavior on the target [Appendix IX]. This analysis uncovered three vulnerabilities in the network stack. When a Vista target received an IP packet for protocol 43, the host crashed with a blue screen. Sending the target a protocol 44 packet caused the system to become unresponsive for a large amount of time. The presence of these protocols was also uncovered in our protocol enumeration testing. The last vulnerability involved the processing of IP options. When an option was received with an option length of zero, the machine locked up completely until reset. The Windows Vista stack likely enters an infinite loop while processing the option when it attempts to advance ahead by zero bytes and repeatedly processes the same IP option. All three of these defects were fixed in build 5384. The presence, however, of these vulnerabilities is consistent with a rewrite of the network stack and suggests that Microsoft has repeated some of the mistakes others have made in the past and introduced some new vulnerabilities of their own. We believe that other defects are likely present in the stack and that further research in this area should be fruitful. D. Tunneling Protocols Windows Vista employs IPv6 transition technologies that allow IPv6 to be used in an IPv4 environment that has limited or no IPv6 infrastructure[19]. These protocols are configured when Windows Vista is installed and are available on all Vista hosts unless explicitly disabled. We investigated the new Teredo protocol, deferring analysis of the ISATAP protocol due to time constraints. Teredo[20][15] is an IPv4-IPv6 transition technology that allows IPv6 traffic to be tunneled in IPv4 UDP packets in
The Opentear attack was performed across a 100Mb/s Ethernet. The effect may be less pronounced if bandwidth is limited.
4 SYMANTEC ADVANCED THREAT RESEARCH unmanaged networks. Windows Vista will enable Teredo tunneling as a last resort if there are no neighboring IPv6 routers or ISATAP servers. We expect this to be the most common environment among Windows Vista users until IPv6 sees wider deployment. Teredo works by carrying IPv6 packets inside of UDP packets sent over IPv4 networks. What makes Teredo unique is its NAT traversal features. Teredo hosts establish and maintain a connection to one of a set of public Teredo servers. The IPv6 address assigned to a Teredo host encodes the public Teredo server that assigned it, as well as the public address and port assigned to the host (i.e. its address as seen outside of the NAT). A NAT-protected host can establish a direct connection to another such host with the assistance of the peer's Teredo server. The host can notify its peer that it wants to establish a connection by sending the packet to the peer's Teredo server, which is forwarded on to the peer host. The two peers may then send packets to each other, opening up mutual holes in their NAT gateways for return traffic to flow through. The two peers can maintain these NAT mappings indefinitely by periodically exchanging traffic. Teredo restores global addressability and routing to hosts using private IPv4 addresses. This is a huge benefit to functionality but also has some serious security implications. Many individuals and companies use private addresses as a key part of their defense strategy and may find their Vista hosts externally reachable to an unexpected degree, unless strict egress filtering is in place. In addition to Teredo, Vista supports ISATAP, 6to4, and 6over4. Surprisingly, Windows Vista seems to support the encapsulation of IPv4 packets in IPv4 packets (protocol 4) and IPv6 in IPv6 packets (protocol 41). We did not get the opportunity to investigate these tunneling technologies further, but expect them to provide leverage in performing network attacks. Further investigation will likely be fruitful. IV. TRANSPORT Windows Vista supports the TCP and UDP transport protocols over IPv4 and IPv6. We investigated the implementation characteristics of these protocols. A. UDP We tested the stability of the UDP transport protocol using random fault injection and did not observe any defects. We did notice that the Vista networking stack replied to UDP packets sent to unbound UDP ports with an ICMP unreachable error. The earlier Windows XP networking stack did not exhibit this behavior when Windows Firewall was active (the default configuration). This behavior allows the host to be "pinged" for aliveness and for the enumeration of UDP services even when Windows Firewall is active. We notice that the Vista stack seems to rate-limit both ICMPv4 and ICMPv6 error messages, which limits the 5 rate at which UDP testing can be done. It might be interesting to evaluate the rate-limiting algorithm. B. TCP We tested the stability of the TCP transport using random fault injection and did not observe any defects. We also measured Windows Vista's TCP ISN generation, "fingerprint" and segment reassembly behaviors and observed several behavioral differences from the earlier Windows XP stack. The choice of the Initial Sequence Number used when establishing a TCP connection has a profound impact on the security of a TCP connection[3][23][26]. We measured Windows Vista's ISN generation and observed that generation is done by random increment but appears random in practice [Appendix X]. When connections are made using the same connection identifiers (source and destination addresses and ports), each successive connection has an ISN that is only slightly larger than the previous connection. However, if connections having different identifiers are made, the sequence numbers appear uncorrelated. This is consistent with the generation algorithm recommended by RFC 1948[1], which generates ISN values by adding a system-wide counter to a secret hash of the connection identifier. This generation scheme offers strong protection against TCP attacks relying on poor ISN generation. There are many network stack fingerprinting methods that identify an operating system through its network stack implementation details[12]. We looked at the TCP behavior measured by the nmap[11] utility. We observed that the Windows Vista networking stack behaves distinctly differently than the previous Windows XP version and other popular network stacks. We also observed differences between different Windows Vista builds, suggesting that the TCP stack is being actively developed. The details of these differences are noted in Appendix XI. Because all incoming TCP traffic is filtered by the Windows Firewall, these differences are observable only if a firewall exception is configured. We measured the TCP reassembly behavior of Windows Vista. When reassembling a TCP stream, Windows Vista resolved any conflicts in overlapping TCP segments by preferring data received in earlier segments over data received in later segments [Appendix XII]. This behavior differs from the behavior observed in the earlier Windows XP networking stack. As a result of these differences, identical traffic sent to XP and Vista targets may be interpreted differently. Ambiguities in the interpretation of traffic provide opportunities for confusing network intrusion detection devices unless handled appropriately[25]. SYMANTEC ADVANCED THREAT RESEARCH V. FIREWALL Windows Firewall provides protection against attacks by filtering out protocol requests before they are processed. Windows Vista configures Windows Firewall during installation; unless explicitly disabled, Windows Firewall is running on all Windows Vista machines. We measured the firewall configuration of a Windows Vista machine after installation and after several common configuration changes. We also note methods that could be used to detect the presence of a Windows Vista host even when protected by Windows Firewall. A. Configuration In its default configuration, Windows Vista 5384 has two firewall exceptions. One was for "Remote Assistance" (the msra.exe program) [Appendix XIII]. This exception is active only when msra.exe is running (used when requesting remote assistance). However, msra.exe is not usually running. The other default exception was for "Network Discovery." Freshly installed Vista hosts will respond to LLTD requests, making it apparently the only service available by default. Despite the protection of Windows Firewall, Windows Vista 5384 still processes TCP packets to inactive TCP ports, returning RST packets. It also processes IPv6-based UDP requests to inactive UDP ports, returning ICMPv6 unreachable errors. This error reporting allows for enumeration of the services in question and for remote aliveness testing as previously noted. Interestingly though, the 5270 build had eliminated the TCP RST responses that were seen in the 5231 build. The earlier Windows Vista 5231 build had several firewall deficiencies that were addressed in the 5270 build. In addition to the RSTs sent for inactive ports, Vista 5231 allowed access to some TCP ports running RPC services (135 and some ports in the ephemeral port range) even though no exceptions were approved by the user or reported in the control panel. Several common Windows configuration changes introduce filtering exceptions into the Windows Firewall configuration. Examples are turning on File and Print sharing (CIFS), opting into People Near Me, using Windows Collaboration, or enabling Windows Media Sharing. The user must authorize these changes by using the Windows Vista consent mechanism. The Teredo service also adds and removes exceptions from the firewall configuration while running, although without the user's consent. The details of these firewall configuration changes can be found in Appendix XIII. We observed that the Windows Firewall APIs[21] and the Windows Firewall control panel did not always reflect the exceptions that were allowed through the firewall and did not report data consistent with each other. When exceptions were added to the firewall configuration, they were not 6 always listed as active in data returned from the firewall API. When an exception was added for File and Printer Sharing, ICMP echoes were accepted by the firewall, but this change was not reflected in the control panel. The Windows Firewall does not appear to distinguish between IPv4 and IPv6 exceptions. An attacker may be able to use an existing exception intended for an IPv4 port to allow traffic in to an IPv6 port, or vice-versa. Due to a lack of time, we did not explore this possibility. B. Discovery Windows Vista hosts protected by Windows Firewall can be discovered in several ways even though ICMP echoes (pings) are filtered. Hosts on the same network can effectively "ping" a host by querying for the host's hardware address using the ARP or ND protocols or by requesting all neighbors to respond to an LLTD request. Detection using LLTD is particularly attractive because it returns the host's Ethernet, IPv4 and IPv6 addresses, and host name. Hosts that are not on the same local network can elicit responses from a Windows Vista host remotely using routable IPv4 and IPv6 packets. As previously mentioned, Windows Vista responds to TCP packets sent to inactive TCP ports and to IPv6-based UDP packets sent to inactive UDP ports even when the firewall is enabled. It also responds to packets received using an unhandled protocol or with certain malformed fields[13] with ICMP errors. Windows Vista may be running Teredo, unbeknownst to its user, with firewall exceptions that allow a remote user to interact with it and elicit responses. C. Tunneling The tunneling protocols supported by Windows Vista have implications to firewalls protecting Vista hosts. If not blocked, tunnels may provide an attacker with an avenue to bypass all firewall restrictions. The tunneling protocols may also provide avenues for bypassing the Windows Firewall. Due to time constraints we did not explore tunnel-based attacks. VI. NETWORK SERVERS A. Active UDP Ports We applied standard techniques to enumerate the network services using the UDP and TCP transports over IPv4 and IPv6 in Windows Vista [Appendix XIV]. We observed that Windows Firewall blocked access to all TCP services unless otherwise configured by the user 5. However, in build 5384 (but not the earlier 5270) TCP services over both IPv4 and IPv6 could be mapped since RSTs were generated for ports with no service: · MS-RPC (135) · NBT (139) (IPv4 only) · SMB (445)
In the 5270 and 5384 builds. The earlier 5231 build allowed port scanning even when Windows Firewall was enabled.
5 SYMANTEC ADVANCED THREAT RESEARCH · Six ephemeral ports (49152-49157) 7 Access to the UDP services were also blocked, but because Windows Vista replied to IPv6-based UDP packets sent to unused ports with ICMPv6 errors, the UDP services for IPv6 could still be enumerated. The UDP ports that were found to be active over IPv6 were: · NTP (123) · ISAKMP (500) · UPnP (1900) · Web Services Discovery (3702) · Link Local Multicast Name Resolution (5355) · Two ephemeral ports (49767, 62133) Because of the nature of UDP active port enumeration it is not possible to distinguish which of these active ports were being used as clients and which were being used as servers. It is likely that at least NTP is being used a client. More details on active ports in the three Vista builds evaluated can be found in Appendix XIV. B. RPC Services Unlike the 5270 build, the earlier Vista 5231 build allowed remote enumeration of TCP services, and we document the results of such enumeration in Appendix XIV. The previous version also allowed unfiltered access to a few RPC services. We were able to enumerate the RPC interfaces supported on these TCP ports using a brute-force enumeration technique. Windows Vista allows several services to share a single process. Due to a limitation of the RPC library, all RPC services in the same process are accessible via the same RPC endpoints. There are techniques to avoid providing unexpected network access to RPC services that were intended for local use, but these remedies rely on programmer diligence ([18] and section 4.11 of [17]). We observed that the available TCP ports answered to several RPC interfaces that should not have been reachable. We also observed that some of the interfaces were callable without any authentication. One such call, ServerAlive2 in the OXIDResolver interface, provided the host's name on demand. Windows Vista 5271 does not expose any of these services, but should an exception be added to the firewall configuration to allow access to any RPC services, we expect these issues to resurface. C. File Sharing Computer users with several machines commonly turn on File and Printer Sharing and we expect many Windows Vista users will do this. Windows Vista supports the SMB protocol and introduces the new SMB2[9] variant. SMB2 is a new implementation of the SMB protocol that provides a clean slate for Microsoft. It eliminates many of the legacy SMB calls that were no longer used. It supports high-performance marshalling with fixed header sizes and better alignment rules. Finally, it provides larger field widths for many of the protocol fields to ensure support for larger disks and faster computers in the future. SMB2 is the preferred protocol when supported by both client and server (two Windows Vista hosts, for example), but support is included for legacy interoperability. We performed some random fault injection of the SMB2 protocol to the stability of the new implementation. We also enumerated the named pipes that are accessible without authentication over the file-sharing protocol since these act as another transport mechanism. We performed random fault injection on an SMB2 connection between two Windows Vista hosts by corrupting the data stream with a proxy. No resulting defects were discovered through this testing. We suspect that the protocol exchange is being protected by signatures, which would provide some immunity to network-based random fault injection by rejecting altered messages after minimal processing. Protocol-aware directed testing may prove more effective. There was some instability in the SMB implementation in the earlier Windows Vista 5321 build. We observed that sending a single string to port 445 was sufficient to cause the machine to crash with a blue screen. This defect had been addressed as of the 5270 build. File sharing allows remote access to named pipes. These pipes are often used as a transport mechanism for application protocols. We enumerated the named pipes that were accessible over an anonymous connection to the "IPC$" share and found that we were able to open the netlogon, lsarpc, and samr pipes without any authentication [Appendix XV]. When using SMB2 we were also able to open the protected_storage pipe, which wasn't accessible via the legacy SMB protocol, suggesting that the two protocols are handled by different implementations. All of these pipes are aliases and refer to the pipe named "lsass." This pipe is used as a transport for several RPC-based interfaces, which we enumerated. We found that we were able to call several of the interfaces without any further authentication. The details of these RPC interfaces are given in Appendix XV. VII. UNSOLICITED TRAFFIC Windows Firewall offers protection against attacks aimed at servers by limiting the number of hosts that can interact with a server and the number of servers that can be accessed. However, it does nothing to protect against replies to traffic initiated from a Windows host. Similarly, many enumeration techniques will provide a list of services, but will not indicate which clients may be active. To enumerate clients and measure the exposure of a Windows Vista 5270 host to client attacks, we observed the unsolicited traffic initiated by a Windows Host during system startup, login, stasis and shutdown [Appendix XVI]. SYMANTEC ADVANCED THREAT RESEARCH These unsolicited requests provide opportunities for wellplaced adversaries to interact with the system despite the protections afforded by the Windows Firewall. Most of the requests originating from a Windows Vista are standard such as address auto-configuration (DHCP) and support protocols (ARP, ND, DNS and NBNS). Some of the more noteworthy protocols in use are the newer protocols Web Service Discovery, Link Local Multicast Name Resolution, IPv6, and Teredo. All of the traffic we observed was unauthenticated, providing little resistance to malicious attack. Although most of the requests we observed were intended for the local network, a few requests were sent off-site to the public Internet, most notably DNS lookups and communication to a Teredo server. These protocols are most likely to be attacked. When using the earlier Windows Vista 5231 build we observed that the host posted information back to a public Microsoft server during shutdown! This behavior had been removed as of the Windows 5270 build. The complete list of protocols we observed can be found in XVI. VIII. CONCLUSION The network stack in Windows Vista was rewritten from the ground up. In deciding to rewrite the stack, Microsoft has removed a large body of tried and tested code and replaced it with freshly written code, complete with new corner cases and defects. This may provide for a more stable networking stack in the long term, but stability will suffer in the short term. Despite the claims of Microsoft developers[30], the Windows Vista network stack as it exists today is less stable than the earlier Windows XP stack. We have identified several implementation flaws in the 5270 Windows Vista build and even more in earlier builds, though these have been fixed in 5384. While it is reassuring that Microsoft is finding and fixing these defects, we expect that vulnerabilities will continue to be discovered for some time. A networking stack is a complex piece of software that takes many years to mature. Microsoft also chose Vista as a platform to introduce new protocols and new implementations of old protocols. IPv6 is enabled during installation for the first time in Windows Vista. The IPv6 protocol is not new, but it has yet to see widespread deployment. To support the process of transitioning from IPv4 networks to IPv6 networks and to increase the usefulness of peer-to-peer technologies, Microsoft has also enabled IPv6 tunneling support in Windows Vista. These tunneling protocols restore global addressability to hosts behind NAT firewalls, increasing the exposure of many users. In support of peer-to-peer communications, Microsoft Vista supports new server-less name-resolution protocols such as PNM and PNRP. Taken together, these technologies provide mechanisms to discover and deliver payloads between peers. These features are critical to the success of Microsoft's peer-topeer initiative but are also the same features that attackers 8 need to deliver malicious content to their victims. As these technologies see wider deployment, we expect IPv6 and the new peer-to-peer protocols to play an increasing role in the delivery of malicious payloads. The SMB2 protocol introduces more new code into the Windows Vista environment. SMB2 is based heavily on the mature SMB protocols, but the new code provides new opportunities for defects as evidenced by the defect we found. This protocol is not available without manual configuration, but the service it provides is useful enough to be configured often. The exposure of this protocol is partially mitigated by the firewall since, when enabled, access is typically restricted to the local network. Due to this restriction, we don't expect this protocol to be widely used in remote attacks against home users. Firewalls and IDSs will have to consider the presence of new Vista machines on their networks. If left unhandled and unchecked, IPv6 and its accompanying transition technologies allow an attacker access to hosts on private internal networks outside of the prevue of the administrator. Unwanted access can be prevented by analysis of IPv6 protocols in the firewall or IDS or by completely blocking all IPv6 protocols. Implementation-specific behavior of the new Vista stack allows an attacker to create ambiguous traffic that may be improperly interpreted by a passive intrusion detection device. IDSs will have to faithfully replicate Vista's behavior when analyzing data destined for Vista hosts. IDSs will also have to analyze new protocols and new versions of existing protocols or face being blind to their traffic. IX. FUTURE WORK We performed a fairly broad and shallow analysis of the networking technologies available in Windows Vista. Some significant omissions in our analysis should be investigated. Our work highlights many interesting implementation features, but does not penetrate very deeply into the subject matter. This provides a wealth of opportunities for future work at all layers of the network stack. At the link layer, we did not investigate the Ethernet, PPP, or PPPoE protocols or any of the link-layer tunneling protocols, nor did we investigate all of the features of the ND protocol. While we did look into the LLTD protocol, we barely scratched the surface. There are fields of the protocol we did not fully decode and we were unable to exercise all of the protocol's features. The stability of the protocol should also be tested further to look for any implementation flaws. At the network layer, we did not look into the fragmentation behavior of the IPv6 protocol, the ICMP and ICMP6 protocols, or into the ISATAP or 6to4 tunneling protocols. Tunneling protocols often invalidate some of the design decisions of other protocols. An analysis of attacks that could be performed in conjunction with tunneling SYMANTEC ADVANCED THREAT RESEARCH protocols is likely to be fruitful. All the tunneling protocols should also be tested more thoroughly for implementation flaws. Although we performed some fault injection against the IPv6 protocol, we believe the tools we used were subpar and encourage further fault-injection testing of IPv6. The defects we observed in IPv4 while performing fault injection were isolated but not fully analyzed. A deeper analysis could determine whether any of these defects could be used for more interesting attacks than denial of service. At the higher levels of the protocol stack, we left the LLMNR and PNRP protocols completely untouched. These protocols need to be analyzed, and their security implications should be understood and tested for implementation flaws. The SMB2 protocol was covered lightly, but could also benefit from a deeper analysis and better fault-injection testing. The firewall could also use more testing. Of particular interest is determining how the firewall behaves when the same port is reused in IPv4 and IPv6 by different programs. It may prove possible to bypass the firewall restriction intended for an IPv4-based transport by using the same port number over an IPv6-based transport, or vice versa. 9 REFERENCES
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] J. Arkko, J. Kempf, B. Zill, P. Nikander, "SEcure Neighbor Discovery (SEND)," RFC 3971, March 2005. http://www.ietf.org/rfc/rfc3971.txt S. Bellovin, "Defending Against Sequence Number Attacks," RFC 1948, May 1996. http://www.ietf.org/rfc/rfc1948.txt S. Bellovin, "Security Problems in the TCP/IP Protocol Suite," Computer Communications Review 2:19, pp 32-48, April 1989. http://www.cs.columbia.edu/~smb/papers/ipext.pdf S. Bellovin, "A Technique for Counting NATted Hosts," Proceedings of the Second Internet Measurement Workshop, November 2002. http://www.cs.columbia.edu/~smb/papers/fnat.pdf A. Conta, S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification," RFC 2463, December 1998. http://www.ietf.org/rfc/rfc2463.txt M. Crawford, "Transmission of IPv6 Packets over Ethernet Networks," RFC 2464, December 1998. http://www.ietf.org/rfc/rfc2464.txt S. Deering, R. Hinden, "Internet Protocol Version 6 (IPv6) Specification," RFC 2460, December 1998. http://www.ietf.org/rfc/rfc2460.txt The Ethereal Project, "Ethereal: A Network Protocol Analyzer." http://www.ethereal.com/ The Ethereal Project, "SMB2." http://wiki.ethereal.com/SMB2 M. Frantzen, S. Xiao, "ISIC ­ IP Stack Integrity Checker 0.06." http://www.packetfactory.net/Projects/ISIC/ Fyodor, "Nmap (`Network Mapper')." http://www.insecure.org/nmap/ Fyodor, "Remote OS detection via TCP/IP Stack FingerPrinting," October 1998. http://www.insecure.org/nmap/nmap-fingerprintingarticle.html V. Hauser, "Attacking the IPv6 Protocol Suite," CORE'05, November 2005. http://www.pacsec.jp/resources.html?LANG=ENGLISH [14] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture," RFC 2373, July 1998. http://www.ietf.org/rfc/rfc2373.txt [15] C. Huitema, "Teredo: Tunneling IPv6 over UDP through NATs," Draft RFC, April 2005. http://www.ietf.org/internet-drafts/drafthuitema-v6ops-teredo-05.txt [16] IANA, "Protocol Numbers." http://www.iana.org/assignments/protocol-numbers [17] J. Marchand, Windows Network Service Internals, October 2003. http://www.hsc.fr/ressources/articles/win_net_srv/index.html [18] Microsoft, "Be Wary of Other RPC Endpoints Running in the Same Process," Platform SDK. http://msdn.microsoft.com/library/default.asp?url=/library/enus/rpc/rpc/be_wary_of_other_rpc_endpoints_running_in_the_same_ process.asp [19] Microsoft, "IPv6 Transition Technologies," November 2002. http://www.microsoft.com/windowsserver2003/techinfo/overview/ip v6coexist.mspx [20] Microsoft, "Teredo Overview," Jan 2003. http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/te redo.mspx [21] Microsoft, "Windows Firewall Interfaces," Platform SDK, http://msdn.microsoft.com/library/default.asp?url=/library/enus/ics/ics/inetfwprofile_authorizedapplications.asp [22] D. Morgan, "Network Topology: Connectivity Visualized," WinHEC'05, April 2005. http://www.microsoft.com/whdc/winhec/Pres05.mspx [23] R. Morris, "A Weakness in the 4.2 BSD Unix TCP/IP Software," Bell Labs Computer Science Technical Report 117, February 1985. http://pdos.csail.mit.edu/~rtm/papers/117.pdf [24] T. Narten, E. Nordmark, W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)," RFC 2461, December 1998. http://www.ietf.org/rfc/rfc2461.txt [25] T. Newsham, T. Ptacek, "Insertion, Evasion and Denial of Service: Eluding Network Intrusion Detection," Secure Networks, Inc. Technical Report, January 1998. http://citeseer.ist.psu.edu/ptacek98insertion.html [26] T. Newsham, "The Problem with Random Increments," Guardent Technical Report, February 2001. http://www.lava.net/~newsham/random-increments.pdf [27] D. Plummer, "An Ethernet Address Resolution Protocol," STD 37, RFC 826, November 1982. http://www.ietf.org/rfc/rfc0826.txt [28] J. Postel, "Internet Protocol," STD 5, RFC 791. http://www.ietf.org/rfc/rfc791.txt [29] K. Renard, "Security Issues in IPv6," March 2005. http://www.wareonearth.com/resources_whitepapers.html [30] Scobleizer, "Abolade Gbadegesin and team ­ Networking in Windows Vista," Channel 9 interview. http://channel9.msdn.com/Showpost.aspx?postid=116349 [31] H. Seki, "Fingerprinting through RPC," BlackHat '04, July 2004. http://www.blackhat.com/presentations/win-usa-04/bh-win-04-sekiup2.pdf [32] D. Song, DSniff 2.3, December 2000. http://naughty.monkey.org/~dugsong/dsniff/ [33] M. Zalewski, "Strange Attractors and TCP/IP Sequence Number Analysis," BindView Technical Report, April 2001. http://www.bindview.com/Services/Razor/Papers/2001/tcpseq.cfm SYMANTEC ADVANCED THREAT RESEARCH 10 APPENDIX I ­ TESTED V ERSIONS All tests were performed against Windows Vista CTP Beta releases. The following versions were tested: · · · · · · Windows Vista CTP Build 5231 x86 (Beta 2, September 2005) Windows Vista CTP Build 5231 x64 Windows Vista CTP Build 5270 x86 (Beta 2, December 2005) Windows Vista CTP Build 5270