Security Training
Security Certification
Cyber Security Graduate School
Internet Storm Center
Security Awareness Training
Computer Forensics
Penetration Testing
IT Audit
Software SecurityIntrusion Detection FAQ: How can passive techniques be used to audit and discover network vulnerability?
Hee SoAbstractThis paper examines methods to identify vulnerabilities within a network by only passively listening to network traffic. Since these techniques do not write any packets to the network, they could also be used in network forensics analysis. First, a history of operating system identification implementations using active TCP/IP stack fingerprinting is summarized. Second, current operating system identification implementations using passive techniques are discussed. Third, information cannot be trusted if it is crafted, but crafted packets also leave signatures. Therefore there is a discussion identifying the level of packet crafting. Fourth, vulnerabilities cannot be determined from OS alone, and passive banner grabbing technique is discussed. Finally, passive techniques for discovering the network topology and data flow are discussed. IntroductionHaving a strong perimeter defense is less effective if the attacks can come from inside the network as well as from the Internet connection. In campus or corporate environments, machines may be compromised from within or through alternate entry points into the network e.g. wireless using WEP/802.11b protocol, laptops that have been infected while attached to other networks, or through email. The defense in depth concept for internal networks can be enumerated into the different layers of the device protocol stack -- physical layer, data-link link layer, TCP/IP layer, and application layer – as well as the network topology. How do you know if the ATM machine you are entering your pin into is a legitimate ATM? How do you know the van, driving next to you, is not acting as a cell site and your cell phone conversation is not being relayed through it? These questions can be answered with more confidence by identifying the level of packet craft. A back door router or an unsolicited host attached to the network, however, can be detected by passively detecting the network topology and its changes, and bandwidth utilization and direction from connection initiator to responder. Ideally, a network analysis tool should not inject packets into the network by actively scanning machines. Not only will IDS be set off, possibly causing a feedback loop, there could be undesirable results from machines auto responding to port scans like those from Psionic’s PortSentry tool. Passive network sniffers put the network card into promiscuous mode, which can be detected as demonstrated by AntiSniff tool by L0PHT. Some sniffers like tcpdump and ethereal by default resolve IP addresses which inject DNS requests into the network. The existence of these sniffers can be detected by the presence of additional DNS requests due to the gethostbyaddr() from the sniffer on the same subnet. Thus, the first form of protection is to protect at the physical layer by using a one-way cable that only receives and does not transmit packets. Some name resolution can be achieved without injecting packets into the network by caching the netbios-ns, and the DNS replies. Monitoring inside the LAN in addition to the DMZ and WAN connection point has the added advantage of using additional passive techniques to identify source spoofing at the Data Link layer. For example, the minimum Ethernet length is 60 bytes while the minimum TCP/IP packet is 40 byes. The frame header is 14 bytes so the remaining 6 bytes are filled in by the sending host. Solaris8 fills this in with 0x55 while many systems fill in using 0x00. A Netgear firewall uses a unique six(6) byte signature. Seeing a Windows signature coming from a Solaris box is suspicious. Once the packet is forwarded through a device like a router or firewall, these padded bytes could change thus making the detection of spoofing more difficult. OS, applications and services visible from the network can be identified through passive OS fingerprinting and passive banner grabbing. If an internal host is exploited or a new exploit is announced, a comparison against existing hosts can be made to identify if other machines need to be hardened or patched. Finally, network topology mapping with direction of traffic flow can reveal where the perimeter defenses are necessary or if any have been violated. OS Fingerprinting ImplementationsAn operating system can be identified by comparing slight differences in the implementations of the network protocol stack. When specifications are written, it is often unclear what to do under certain error conditions so implementations can vary. As specifications improve, not all implementations get updated thus leaving distinguishable differences between vendors. Initially abnormal combinations of TCP flags and options were used to see how a system responded and that difference could identify an operating system. These OS fingerprinting techniques eventually matured and injecting abnormal stimuli into the network was no longer necessary and fingerprinting could be achieved by reading one normal packet. A generalization is made that since OS fingerprinting using TCP has matured from an active technique to a passive one, that the current active fingerprinting using ICMP packets will eventually mature to passive techniques. History of Active OS Fingerprinting ImplementationsThe first implementation of operating system fingerprinting was seen with SIRC by Johan, which used abnormal TCP flag tests to categorize hosts into four(4) categories ~VLinux, 4.4BSD, Win95, and Unknown. The logic was hard coded into the program. checkos by Shok used much of the same code as SIRC and also had telnet banner grabbing. By the time ss-3.11 by Su1d came out, twelve(12) operating systems could be identified. queso (Sep 1998) by Savage added additional checks and was the first to move the OS fingerprinting outside of the code into a text data file. cheops by Mark Spencer used the same OS fingerprinting file and added a graphical interface to queso as well as network topology mapping using traceroute. While queso used port 80(http) as a default, Cheops uses ports 80(http),139(netbios-ssn),and 23(telnet) -- probably because if a system didn~Rt have web running on it, it would be a Windows box using netbios-ssn or a Unix box with telnet. Below is an examination of the Cheops traffic. 0.00s (46) cheops > target: icmp echo request(id=9933,seq=3) (DF) (ttl 64, id 0) Notice the initial ICMP request and six packets with TCP flags set to SYN, SYN+ACK, FIN, FIN+ACK, SYN+FIN, and SYN with reserved bits set. For all the TCP packets, a random sequence number was the same, acknowledgement number=0, window size=4660, TTL=255, and the IP identification increased for every packet. Notice also that the timing is 20ms between packets and the last packet was 40ms apart. The queso/cheops algorithm for determining the OS was based on whether a response was received, TCP sequence number, acknowledgement number, TCP window size, and TCP flags. Since snort, a common network intrusion detection software, does not look at a sequence of packets for its signatures. Without a snort plugin, the easiest way to detect this sequence is to look for a unique packet. The last packet could be considered unique to the queso/cheops scans. A simple snort rule to detect this activity: Unfortunately there is no window size in a snort rules, i.e. win: 4660 would have been better since a router with CWR/ECN congestion support could set the two reserved bits thus any TCP connection request would trigger a false positive.alert tcp any -> $HOME_NET any (msg:”queso scan”; flags:21S; ack: 0) nmap by Fydorwas the first active fingerprinting tool to bring the OS determination logic outside of the source code into a text based database which could allowed the number of detectible operating systems to scale very rapidly. When an OS signature is not known, the unknown signature is displayed and information on how to submit it to the nmap database is given thus utilizing the whole community to build the database. The tests looked at TCP flags and options that included measuring the TCP initial sequence numbers of the target host, several TCP packets that don’t contain normal information, and a UDP packet to a closed port. Again, the first packet is an ICMP echo request.From the nmap OS fingerprint file describes the active fingerprint tests Tseq, T1 through T7, and PU.The T1 through T7 tests look at responses to packet and examines the DF bit, window size, TCP ack, TCP flags, and TCP options. Tseq classifies the ISNs into TR, C, 64K, and I800 classes. If nmap can’t classify the ISN as TD class, then they are lumped into the RI class. According to SecuriTeam, beginning with Windows NT4.0 w/SP4 the Microsoft “one per millisecond” algorithm has changed, but is still predictable. The measurements used Tseq i.e. the ISN class in addition to the greatest common denominator, T5 tests, and PU tests is useful for passive fingerprinting and can provide additional OS resolution.# TEST DESCRIPTION:nmap classification of the TCP sequenceability or differences between TCP Initial Sequence Numbers (ISN) icmpid-1.0by Simple NomadIn May 2001, icmpid was released as a proof of concept code, based on Ofir Arkin's ICMP research, to identify OS using the existence of stimulus/response pairs to ICMP Request packets and the responses to ICMP Echo Request packets that don’t contain normal information. The logic of OS identification was hard coded into the code. For passive OS fingerprinting, the unusual ICMP packets are not readily available on the network. If a Timestamp Reply was received or an Information Reply, then there would be a finite list of known boxes that could have responded. Values useful for passive compare of ICMP packets are a combination of IP identification, ToS, DF bit, IP reserved flag, TTL, existence of Timestamp Reply, existence of Address Mask Reply, existence of Info Reply.ICMP Echo Request(type=8) -> ICMP Echo Reply(0) xprobeby Ofir Arkin and Fyodor Yarochkinxprobe-0.0.2 was released in Oct 2001. It sends on UDP packet to a default port 32132 and based on the response, sends additional ICMP packets to identify systems based on hard coded logic to determine OS. Currently there are 29 signatures. ICMP Echo Reply and ICMP Destination Unreachable messages include a partial copy of the original IP packet received. Hosts return Destination Unreachable messages code=1 through 5 while routers return codes 6-12. Examination of this field as well as the length of the partially copied packet can distinguish different OS implementations. Typically most systems return the required IP header plus eight(8) additional bytes, but Linux and Solaris boxes return more.0.00s (46) xprobe.63667 > target.32132: udp 70 (DF) Ofir Arkin’s research is relatively new as are the tools using the research. Just as p0f and ettercap have achieved a one line passive signature, and looking at the history of active fingerprinting using TCP flags and options, it is very likely to see one line passive fingerprints based on UDP/ICMP in the near future. Below are the packet fields being compared by p0f.
ettercapby Alberto Ornaghi (ALoR) and Marco Valleri (NaGA)This project began Nov 2000. This tool can actively scan the network but also has a passive OS fingerprinting feature with one line OS signatures similar to p0f. Ettercap not only compares the initial client SYN packet, but also the initial server SYN+ACK response packet, thus allowing both server and client to get fingerprinted when a TCP connection is established. The fields compared are very similar to those of p0f except that ettercap does not use the IP packet length, and does compare the existence of the Timestamp TCP option. By default ettercap-0.6.2 comes with about 85 SYN signatures and about 420 SYN+ACK signatures, but many of the signatures are very similar with one bit turned on and the other bit turned off. There are about 300 unique OS signatures. Notice that the ettercap algorithm can ignore the MSS and WSCALE TCP options which is slightly different than the p0f implementation. It is not clear which implementation is more effective. v Ettercap looks at MAC addresses and ARP messages for mapping on the same broadcast domain. The routers are identified by identifying the MAC address of the packets destined to external IP addresses. Also the ICMP TTL-exceeded or redirect messages come from the hosts acting like a router. Identifying a non-local IP address requires the netmask. In forensics analysis, this might not be known, thus identifying which MAC address has multiple IP addresses can identify routers. One slight improvement over the p0f implementation is that the TTL values are compared to the next power of two thus allowing for packets from over 30 hops away or packets through congested routers to get fingerprinted correctly. Below are the nine(9) packet fields used by ettercap to passively OS fingerprint:
Passive OS Fingerprinting on RSTWhen a TCP connection is requested by a client, the server will respond with a SYN+ACK to establish a connection or on most systems a RST+ACK if the server port is closed. Since OS fingerprinting is available on the SYN+ACK packet, by fingerprinting on the RST, both sides of the communication can be fingerprinted not only when a connection is established, but also if a connection is merely attempted. Below is an examination of the return RST+ACK packet of a telnet to a closed port. It shows that a certain level of OS distinction can be made.
Note: The TCP sequence and/or acknowledgement numbers can change to a non-zero value when passed through a firewall. From the data above plus evaluating the reply similar to T5 test from nmap, the OS can be identified on RST+ACK to a much better degree of accuracy by also looking at the following header information.
Classification of Packet CraftingEvidence of packet crafting is evidence of potential source spoofing. Identifying if a stimulus or response was crafted gives better insight to the method of attack and lethality of the attacker. Being able to classify what tools were used to craft packets makes it more predictable what the attacker can do. p0f was first to provide packet craft signatures e.g. queso and nmap in their database. Depending on what layer in the protocol stack was crafted, a tool would give the same signature for all platforms it was run from. If a system gave the signature that it was a Linux box and from time to time gave a different signature, then that could indicate signs of a crafted packet vs. authentic packet from the OS. Writing a TCP/IP protocol stack and using sockets() is possible but with new standard libraries like RawIP and Route’s libnet, it has become too easy to craft packets that could be run from a variety of systems. Below is a classification of levels of packet. Signs of a higher level of packet crafting is can indicate a higher potential for source spoofing. Some of the higher level of packet crafting could be used to fingerprint legitimate systems. Later, an example detecting packets crafted from one of these libraries is shown. Authentic – either the packets are from real host or are too indistinguishable from a real machine e.g. a virtual machine. Normal passive OS fingerprinting techniques could be used to identify these systems.With libraries like Route’s libnet, it is very easy to craft packets. Attacks can be achieved with only implementing a simple TCP table and no error or congestion handling. Omitting these leave signatures that distinguish one program from another. Both Stateful and Timer based crafting would require examination of multiple packets and are considered advanced techniques. Sample fingerprinting of crafted packet using librariesThere are many libraries to craft IP level packets such as the very popular Route’s libnet. Not everyone’s choice language is C. Some might want to use the Net/RawIP libraries for Python or Perl. Below is an example of a network layer packet craft using Perl’s Net/RawIP libraries.
Passive Banner GrabbingBanner grabbing is commonly available in many scanning tools. However, analyst tools that examine packet headers such as tcpdump or snort capture a fixed length of the packet header and save it in a libpcap file format. The larger the snapshot length, or snaplen, the more the payload can be examined, but more disk space is required to save the dumps; while a shorter snaplen has the advantage of saving more disk space, however, there is more likelihood of truncation of the packet header information. By default, tcpdump uses a snaplen=144 Bytes while the maximum is 1500 Bytes for Ethernet. While packet header analysis is very helpful, the header information of a TCP stream could easily get truncated. Using a “dynamic snapshot length” solves this problem. To illustrate this concept, if the TCP snaplen was set to 2KB, then after the TCP connection state is change to ESTABLISHED, the 2KB of server and 2KB of the client TCP payload would get recorded into the libpcap dump file. This is analogous to the phone company recording the first few seconds of the phone conversation (TCP stream) for identification of callers as well as the phone numbers dialed from and to (TCP+IP headers). For passive banner grabbing, only the 2KB of the server TCP stream needs to be saved. For libpcap implementations, “dynamic snaplen” could be used when saving the dump file by setting pcap_file_header.snaplen=1500 and pcap_pkthdr.caplen=size_of_headers. Once a TCP connection is ESTABLISHED, then the capture length should be set to capture the TCP payload, pcap_pkthdr.caplen=size_of_headers+TCP payload, until the 2KB was reached, then would continue to just store the headers. There is an excellent article “Passive System Fingerprinting using Network Client Applications” by Jose Nazario. He shows that from looking at a three letter abbreviation in a pine Message-ID, the OS flavor can be determined. The article shows other examples of OS information being leaked in other headers like HTTP headers as seen below. Example of application, application version, and operating system:But this is still useful for auditing your network for potential vulnerabilities. If it is known that a specific version of software has a known vulnerability, e.g. CVE-1999-0971 Exim 1.62 local root exploit, then this system running Exim should be tagged as a possible vulnerable system, but that some details are unknown.Example of application and application version:root@dell103 init.d]# telnet attackme.com 80 The problem with the passive banner grabbing method is that the banner is only available when someone connects to the server. Banners are being removed as a security measure, but sometimes this cannot be turned off as it is part of the protocol for both sides to identify the versions that each side supports for example in the case of SSH. [watts@myhost ~watts]$ telnet some.ssh.server.out.there 22 Passive Network MappingNetwork managing and mapping can be done using the Simple Network Management Protocol (SNMP) however not all devices support SNMP nor is access to those devices always granted. Plus, SNMP is not necessarily secure. SNMP doesn’t identify when an unauthorized host has been attached to the network, doesn’t identify when the switched network traffic path has been altered through ARP cache poisoning or if additional backdoors into the network exist with additional routers or hosts acting as routers with IP_FORWARD enabled. In combination with the other passive techniques described in this paper, the list of devices, services running, and topology can be detected and compared against a database of known vulnerabilities. Mapping is broken down to each network layer – Data-Link layer, Network/Transport layer, and Application Layer; as well as the network topology and direction of traffic flow.
ConclusionLooking at the trends of active OS fingerprinting and current passive techniques available, there is no doubt that passive OS fingerprinting can be done on TCP connection establishment, acknowledgement, and rejection. In the near future ICMP packets will be passively fingerprinted from a single line in a text file. In addition to identifying the potential lethality of the attackers, identifying packet crafting signatures can help distinguish authentic vs. spoofed data to properly audit the network state. Combining passive OS fingerprinting, passive banner grabbing, and passive network topology, the traffic flow and a good idea of the state of the internal network can be acquired. Having catalogued the network devices, their operating systems, and services provided, a quicker response time can be achieved in prioritizing and patching up vulnerable systems within the network. REFERENCESStevens, W. Richard. TCP/IP Illustrated, Volume 1. Reading: Addison Wesley Longman, Inc, 1994. Ptacek, Thomas H. et al. “Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection.” Jan 1988. URL: http://www.aciri.org/vern/Ptacek-Newsham-Evasion-98.ps (20 Jan 2002) Fydor, “Remote OS detection via TCP/IP Stack FingerPrinting.” 10 Apr 1999. URL:http://www.insecure.org/nmap/nmap-fingerprinting-article.html (20 Jan 2002) Securiteam.com. “AntiSniff - find sniffers on your local network.” 31 Jul 1999. URL:http://www.securiteam.com/tools/AntiSniff_-_find_sniffers_on_your_local_network.html (20 Jan 2002) SecuriTeam.com. “NT Predictable initial TCP sequence vulnerability revisited.” 28 Aug 1999. URL:http://www.securiteam.com/windowsntfocus/ NT_Predictable_initial_TCP_sequence_vulnerability_revisited.html (20 Jan 2002). Al-Herbish, Thamer. “Raw IP Networking FAQ” 1.3. 11 Nov 1999 URL:http://www.whitefang.com/rin/rawfaq.html (20 Jan 2002) Schiffman, Michael D. “Libnet 101, Part1: The Primer.” 19 Jun 2000 URL:http://www.guardent.com/docs/libnet_wp.PDF (20 Jan 2002) Nazario, Jose. “Passive System Fingerprinting using Network Client Applications.” 19 Jan 2001. URL:http://www.crimelabs.net/docs/passive.pdf (20 Jan 2002) Chmielarski, Tom. “Reconnaissance Technique using Spoofed IP Addresses.” 4 Apr 2001. URL:http://www.sans.org/resources/idfaq/spoofed_ip.php (20 Jan 2002) Arkin, Ofir. “ICMP Usage in Scanning – The Complete Know How.” 3.0. Jun 2001. URL:http://www.sys-security.com/archive/papers/ICMP_Scanning_v3.0.pdf (20 Jan 2002). Honey net Project. “Passive Fingerprinting: Idling remote hosts, without them knowing.” 3 Sep 2001. URL:http://project.honeynet.org/papers/finger/ (20 Jan 2002). |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Check Them Out!
SANS provides the best up to date training relating to security issues. The sessions are relevant and well presented with well written manuals.
-Ravindranath Goswami, The Power Generation Company of Trinidad and Tobago Ltd.
