This was no booking session, but a question and answer session instead. Among the topics came the discussion of YouTube and the fingerprinting technology to be used to catch uploaded material that violates copyrights:

Schmidt: On fingerprinting, we have a problem in the world that people are taking unauthorized copies of content and uploading them. In looking at solutions, the only one that looks to work is where we have copy of correct product; when illegal copy comes over, we throw it out. My feeling is that this is a permanent requirement going forward. We did fingerprinting thing because it was the right thing to do.

That solution works well for Google, but content providers, like the big Hollywood studios, may need some convincing. As with traditional fingerprints, Google would need a copy of every potential work that could be infringed, including ones that have not been released yet to catch people uploading pre-release content.

There would be a fun job for the budding Tarantinos out there, joining Google’s content fingerprinting division and having an early look at all of Hollywood’s output, including the big budget summer releases, before anyone else.

New Fingerprinting To Detect Copyrighted Videos

Dailymotion has not yet implemented the system but says it will be introduced on six localized sites in 13 languages. Silicon Alley Insider says the filtering system will not be installed in the U.S.

The filtering technology that Dailymotion will use if from Ina, a digitalized image bank which will provide its "Signature" technology.

If Google’s YouTube could implement a full-proof method for detecting infringing video it would be huge. Google has said it would implement such technology by the end of the year. In April, Eric Schmidt said the company was very close to getting the system launched.

As to why Google has not yet implemented such technology some believe the company underestimated the technical challenges surrounding video fingerprinting. Peter Kafka theorizes that there is another reason why Google has been slow in developing a filtering system.

"Google doesn’t want to turn the filtering system on while it’s deep in its lawsuit with Viacom. If Google shows that it has the ability to detect pirated videos from legit ones, the argument goes, it will undermine its legal case, which basically boils down to ‘hey, we don’t have any control over what users slap up on the site."

(via Barry Schwartz at SEL)

Next, a WMW thread mentions that Google AdSense has started testing a feature for you to choose which sites are allowed to publish ads using your AdSense code, specifically to be able to report “unauthorized sites that have displayed ads using your AdSense publisher ID within the last week.”

(via Barry Schwartz at SERoundtable.)

Finally, at the SMX session on personalized search, Matt Cutts stated that if you want to turn off personalized search, append &pws=0 to the end of your search URL. I believe he also suggested that someone could make a Firefox extension to include the parameter (and get a lot of links!).

Some one took him up on his advice. Joost de Valk created an Open Search plugin compatible with Firefox and IE that automatically adds the string to your query URL.

There’s your link, Joost!

(via Barry Schwartz at SEL)

Comments

Tag:

One area that I spend a bit of time on is the Summary Statistics window provided by EtherPeek – it’s hot! Using the information provided in the summary statistics window, I can identify a network that is experiencing the following traffic behavior:

• ARP scans are looking for active systems on a subnet
• Ping scans are looking for active systems on the entire network
• Port scans are looking for active services over TCP or UDP
• Routing configurations are causing packet redirection or advertising new default gateway settings
• OS fingerprinting is attempting to identify operating system types and versions
• Services are not configured properly or services are not functioning properly
• Traceroute is attempting to discover network paths

In this article, I’ll walk you through two categories that I focus on most often during onsite analysis visits:

ICMP Analysis
IP Analysis

To open the Summary Statistics window in EtherPeek, click on the Summary Statistics icon on the main toolbar.

ICMP Analysis Summary Information
This is one of my first stops during the laying on of hands’ (my process for baselining network performance and identifying the personality’ of the network).

ICMP is one of the most informative protocols available in the TCP/IP protocol suite. This protocol is used for good and bad. On one hand, some ICMP packets help us isolate network configuration and performance problems. On the other hand, ICMP is the protocol of choice for folks who perform reconnaissance on your network, your operating systems and your network services for the eventual purpose of hacking in.

Figure 1 shows the ICMP Analysis details within EtherPeek’s Summary Statistics window.

Figure 1: The ICMP Analysis section can help identify configuration problems as well as OS fingerprinting and UDP-based port scans.

Ping Packet Statistics (ICMP Echo Packets)
There are three items in the Summary Statistics window that deal with ping operations:

• Pings Unanswered
• Ping Requests
• Ping Responses

The “pings unanswered” value is equal to the ping requests minus the ping responses.

If I see a high number of ping requests (and even a counter that increments as I watch) and a low number of pings unanswered, I know that one device is pinging another device successfully. A high number of pings is not normal on a network – typically ping is used for a short-term connectivity test. I high number of pings may indicate a user is playing with ping command. The next step in this case may be to identify the devices who are sending continuous pings and get them to CLAM UP!

If I see a high number of ping requests and a high number of pings unanswered, however, I will look for someone performing a ping scan on the network. A ping scan is used to identify all the active systems on a network. Is there any reason a system should perform such an operation? Watch out for your network management tools – they may use a ping scan to build one of those lovely network maps. Whatever the reason, you need to check out who is ping scanning and why. We certainly don’t want ping scans coming in from the Internet – consider blocking all inbound ICMP Echo requests to thwart these probes.

OS Fingerprinting Packets

OS Fingerprinting is a technology used to identify the operating system and version running on a computer. There are several tools that are used for OS fingerprinting: Xprobe (http://www.sys-security.com/html/projects/X.html), nmap (http://www.insecure.org/nmap/nmap-fingerprinting-article.html), and LANguard Network Scanner (www.gfi.com).

In the early days of OS fingerprinting, tools used TCP connections and banner pages to determine what OS was running on a system. Banners are initial connection details that are displayed when you reach an open service such as FTP or telnet. Many times, the operating system identifies itself when the initial connection is established.

In recent years, however, many FTP servers do not disclose their operating system by default anymore. This makes OS fingerprinting with TCP difficult or impossible – this is where ICMP comes into play.

ICMP-based OS fingerprinting uses a technique documented by Ofir Arkin in “ICMP Usage in Scanning” (http://www.sys-security.com/html/projects/icmp.html). ICMP-based OS fingerprinting tools send an assortment of ICMP packets that are well-formed or malformed and watch the replies. Operating systems respond in a variety of ways – enabling the attacker to classify those operating systems and decide the next step based on operating system vulnerabilities.

The following ICMP packets are commonly used during OS fingerprinting:

• Echo requests (ICMP Type and replies (ICMP Type 0)
• Host Parameter Problem (ICMP Type 12)
• Time stamp requests (ICMP Type 13) and replies (ICMP Type 14)
• Information request (ICMP Type 15) and replies (ICMP Type 16)
• Address mask request (ICMP Type 17) and replies (ICMP Type 18)
• Router Solicitation (ICMP Type 10) and replies (ICMP Type 9)

OS fingerprinting tools may not use all these packet types, but they do typically use several of them during their fingerprinting operation. In reviewing the EtherPeek Summary Statistics window shown in Figure 1, we can see ICMP Router Solicitations, Timestamp Requests/Responses and Address Mask Requests/Replies have been seen. Since these types of ICMP messages are rarely used for legitimate purposes, we must look closely to see if someone is running OS fingerprinting on the network. Perhaps we would place a protocol analyzer on the network and define special filters simply looking for these suspect packet types.

Network/Host Redirection

When a host sends a packet to a router that knows it is not the best router to get to the destination, that receiving router sends an ICMP Redirect for Network/Host packet back to the source. This redirection packet contains the IP address of the preferred router that the host should use.

When a host receives an ICMP network/host redirection message, it will update its routing tables with a dynamic entry for the destination network/host. By typing route print’ in the command box, you can see the new entry.

If a network shows a high number of these redirection packets, either the default gateway setting is not appropriate for the network hosts or someone may be trying to redirect packets for a malicious purpose.

To know which case is true, we’d need to capture the traffic for a while and watch the redirections packets. By examining who is sending the redirection packets and the preferred router information within the packets, we can tell if the redirection is because the router did not offer the best path or the redirection pointed to a system that should not be offering routes. In the latter case, we may have a hacker in our midst. By redirecting the packets through his/her system, the hacker can read the traffic to identify user names, passwords, unencrypted data, etc.

Destination Unreachables and UDP Port Scans
The EtherPeek Summary Statistics window contains a list of ICMP Destination Unreachable packet types:

• Network unreachable
• Host unreachable
• Protocol unreachable
• Port unreachable

I pay particular attention to the port unreachable statistics. If there are a high number of port unreachable packets, either we have a host misconfiguration or a UDP port scan may be underway.

In the case of a misconfigured host, the device sends a message to a desired destination (such as a DNS server). If the destination doesn’t support the services, it responds with an ICMP Destination Unreachable message – specifically a port unreachable’ message. The ICMP communication needs to be examined to watch the systems sending the ICMP port unreachable messages. Since these are basically service refusals, we need to their cause and the solution to eradicate these messages from the network.

During a UDP port scan, a hacker sends a series of UDP packets to a range of ports (most often paying attention to the ports that offer vulnerable or interesting services over UDP, such as DHCP, DNS and SNMP). If the service is not available on a target, the target sends back an ICMP port unreachable message. When a network has a rapidly increasing number of ICMP port unreachable messages, it’s important to look at the traffic to determine if a system is sending a series of packets to a range of destination port numbers. Such behavior is not normal or acceptable on the network.

IP Analysis Summary Information
Another section that I look at is the IP Analysis section. In this area, EtherPeek lists out the number of ARP requests, ARP responses, TCP SYNs (synchronize sequence number requests), FINs (notifications that a task is completed) RST (resetting or refusing a connection), and RARP (Reverse ARP) operations. (See Figure 2.)

These statistics also can indicate if a network configuration problem exists or if someone is scanning your network.

Figure 2: The IP Analysis section can be used to identify misconfigurations, ARP scans and TCP scans.

Excessive Unanswered ARPs
A high number of unanswered ARPs indicates that a system is looking up the hardware address of a local device that is not responding. This lack of response may be due to a network mask misconfiguration (the sending host thinks the target is on the same network when it is not) or a target system that is not functioning (hence the lack of response).

A high number of unanswered ARPs may also indicate that an ARP scan is underway. ARP scanning is used to find out all the hardware addresses of the systems running on the local network. Although some management systems may use this technique to build those beautiful maps, we need to capture the traffic to determine if that is actually case.

TCP-based Port Scanning
Earlier we discussed UDP-based port scanning – the process that looks for systems supporting UDP-based services such as DNS, DHCP, and SNMP. TCP-based scanning looks for services running over TCP. Since most of the really interesting services run over TCP (such as FTP, telnet, HTTP, etc.), we need to watch out for these TCP scans on the network.

TCP scans generate an unusually high number of Reset (RST) packets. During a TCP scan, a host sends a series of packets to the desired port (such as the FTP port 21) on a target system. If the system does support the service, it sends a TCP SYN ACK (synchronize with acknowledgment) response. If that system does not support the service, it sends a TCP Reset in response.

Although many people believe resets are sent at the end of every TCP communication to close the connection, in actuality, Finish (FIN) packets are typically used. For example, when you close a web browser, Finish packets are sent between the web client and the web server to indicate that the client is done with the tasks it was performing.

When you see a high number of RSTs (greater than 30% of the number of SYN packets), check out the traffic to see if you have a TCP port scan underway on your network.

WildPackets did a great job of putting together key information in one location. When you launch EtherPeek, immediately open the Summary Statistics window and check the ICMP Analysis and IP Analysis sections regularly to look for any unusual traffic patterns. From client misconfigurations to hackers performing reconnaissance on your network, you can identify possible problems without even capturing a single packet!

Notes:
Download the ICMP protocol poster from the Library Section at Protocol Analysis Institute – www.packet-level.com.

Laura Chappell is the Sr. Protocol Analyst for the Protocol Analysis
Institute. Laura focuses on researching, writing and lecturing on
network analysis and security. In 2003, over 60 of Laura’s courses
become available via internet/CD and a series of “White Hat Toolbox:
Security Tools, Tricks and Traces” are releasing at
http://www.packet-level.com. Laura can be reached at
lchappell@packet-level.com.

Internet Control Message Protocol (ICMP) is a protocol used to send error messages across a TCPIP network. Many people recognize ICMP as the protocol used by the ping utility. ICMP is also used with the standard trace route utility.

Besides offering wonderful connectivity tests functionality, ICMP can also be used as part of a reconnaissance scan on a network. In particular, ICMP can be used to perform an active OS fingerprint scan. In this article we will examine the typical ICMP packets that cross the cable when an OS fingerprint operation is performed on your network.

Note: Ofir Arkin, founder of the SYS-Security Group, began research on using ICMP for OS fingerprinting in the winter of 2000. His document “ICMP Usage in Scanning” (http://www.sys-security.com/html/projects/icmp.html) offers a detailed analysis of ICMP’s capability as an OS fingerprinting tool and the various responses received from different operating systems.

If you place an analyzer outside your network firewall chances are good that you will experience numerous ICMP packets hitting that firewall. People are probably trying to discover and learn about your network on a daily basis with ping and/or trace route. You will most likely also see ICMP messages that indicate OS fingerprinting scans are underway.

Figure 1 shows an ICMP fingerprint operation as seen on Sniffer Pro.

The trace file shown in Figure 1 is available online at www.packet-level.com in the Library/Trace File area (languard_scan – available in .cap/.dmp/.pkt formats). Download the file and open it up in your analyzer to see inside each packet.

Packets number 7 through 17 are the OS fingerprinting operation in action. We will examine the entire set of ICMP packets (including packet 6) to see how the OS fingerprinting operation works.

SNMP Query – ICMP Response
In Figure 1, packets 6 through 14 are ICMP packets. Packet 6 is simply an ICMP Destination Unreachable/Port Unreachable response to Packet 5. In Packet 5, the fingerprinter (192.168.1.101) has sent an SNMP Get sysObject ID request. Since the target device (192.168.1.103) does not support SNMP services, it sends back an ICMP Destination Unreachable/Port Unreachable message. This ICMP response by itself does not tell us anything about the target operating system. It does tell us, however, that the target does not support SNMP services.

ICMP Echo
Packet 7 is the actual start of the OS fingerprinting operation. This packet is an ICMP Echo request packet, but it is not properly formed. ICMP Echo requests are used by the ping utility to establish whether a device is up and running on a network. In Packet 7, however, the fingerprinter has sent an ICMP Echo request packet with an invalid code. This is a malformed packet. If we look inside Packet 7, we would see the ICMP header contains type 8 (echo) and code 19. In a typical ICMP Echo request, the type number should be 8, but the code should be 0.

By examining the response to an invalid ICMP echo request, the fingerprinter can determine if the target system examines the ICMP Echo request’s code field at all. Some operating systems will look at the type field and the code field Others may look only at the type field and ignore an invalid code field.

In Packet 8, we see the target respond back with a standard ICMP Echo reply packet. This indicates that the target did not process the invalid code field. This gives the fingerprinter one clue about the OS running on the target system.

ICMP Get Address Mask
The next ICMP packet sent from the fingerprinter is an ICMP Get Address Mask request (ICMP Type 17). The ICMP Get Address Mask request was originally defined as a packet sent by diskless workstations to obtain a subnet mask at boot time. This address mask packet can also be used when one host wants to know the address mask of another host on the network. It is not a common packet to see on a network. This packet is being used for the purpose of OS fingerprinting since many operating systems do not support or respond to the Get Address Mask request. In our trace, we can see that the target machine does not respond to this request. Now we know a little more about the target OS.

ICMP Get Timestamp
In Packet 10, the OS fingerprinter sends a Get Timestamp request (ICMP Type 13) to the target. The ICMP Get Timestamp request allows one host to query another host for the current time. Initially, this was defined as a way for a sender to determine the latency time across a network. In this case, however, it is not being used to determine the latency time; it is being used to perform an OS fingerprint operation. In our trace we can see that the target does respond to a Get Timestamp request. Again, we have learned a bit about the type of operating system we might be targeting.

ICMP Get Information
In Packet 12, the OS fingerprinter has now sent an ICMP information request (Type 15) packet to the target. The ICMP information request process was defined to support diskless work stations during boot time. Using the information request packet, the diskless work station could discover there network address. On most networks today however, BOOTP and DHCP provide a better mechanism for IP address discovery. It is considered unusual to see a get information request cross a typical network. In our trace we can see that the target does not respond to this packet. Again, this is a hint as to the type of operating system that is running on the target.

Just for Good MeasureTo finish the ICMP OS fingerprinting operation, the fingerprinter sends another ICMP Echo request using an invalid code (Code 19) to the target. The OS fingerprinter receives a reply back again from the target.

Packets 7-17 depict an unusual sequence of ICMP packets on a network. Typically, on your network you may see ICMP Echo requests (with valid codes) and possibly some ICMP Redirect packets. When you see this sequence (or a similar sequence) of ICMP packets on your network, you are being OS fingerprinted.

Notes:
In this example, LANguard Network Scanner (www.gfi.com) was used to perform an OS fingerprint operation as part of its standard vulnerability scan process.

RFC LIST (www.ietf.org):
RFC 792: &nbsp &nbsp&nbsp Internet Control Message Protocol
RFC 1122: &nbsp &nbspRequirements for Internet Hosts – Communication Layers
RFC 1256: &nbsp &nbspRequirements for Internet Hosts – Application and Support
RFC 1349: &nbsp &nbspType of Service in the Internet Protocol Suite
RFC 1812: &nbsp &nbspRequirements for IPv4 Routers

Laura Chappell is the Sr. Protocol Analyst for the Protocol Analysis
Institute. Laura focuses on researching, writing and lecturing on
network analysis and security. In 2003, over 60 of Laura’s courses
become available via internet/CD and a series of “White Hat Toolbox:
Security Tools, Tricks and Traces” are releasing at
http://www.packet-level.com. Laura can be reached at
lchappell@packet-level.com.