Date: 01 June 2002
Click here for printable version
Written by have2Banonymous
1st June 2002
Table of Contents
2.0 Terminology and Formatting Conventions
3.0 Analysis of Peer Discovery Techniques
4.0 Software Required to Exploit the Gnutella Network
5.0 Analysis of Gnutella Network Capture
5.1 Traffic Generated by Pong
5.2 Apparent Exploitation of Pong
5.3 Apparent Exploitation of Queryhit
6.0 Suggested Enhancements to Servents and the Gnutella Protocol
8.0 Protocol References
9.0 Author's Public Key
The Gnutella network is a distributed network which allows users to semi-anonymously locate and communicate with other peers on the network in order to search for, upload and download pictures, songs, videos and other file types. The use of peer to peer file sharing on the Gnutella network is rapidly increasing. Numerous vendors make freely available peer to peer applications, with support provided for the Windows, Linux and Macintosh platforms.
However, the benefits of a distributed and semi-anonymous network are offset by the fact that every peer on the network is implicitly trusted and relied on to maintain the health and accuracy of the network.
A Gnutella user could violate their obligation to help maintain the health of the network. If the user only had a low bandwidth connection, they could make the most of their bandwidth by modifying their Gnutella program to not route other people's searches and search results.
A Gnutella user could violate the trust placed in them to maintain the accuracy of the network by generating false information, which would be subsequently propagated through the Gnutella network. This report discusses the consequences in great detail, which include allowing a malicious person to coordinate an attack and cause other users on the Gnutella network to attack an arbitrary computer which is not even part of the Gnutella network. The attack coordinator and peers on the network who are unknowingly attacking the target do not each require significant bandwidth, since their resources are combined when attacking the target. Furthermore, due to the decentralised and distributed nature of the Gnutella network, the attack coordinator can remain anonymous to both the attackers and the target so that there is no audit trail linking the coordinator with the target computer.
Evidence is presented which indicates that the type of attacks theorised in this report are already occurring on the Gnutella network, and that several Gnutella users including the author of this report may have unknowingly contributed to such an attack.
Finally, this report suggests functionality which could be incorporated into peer to peer programs and the Gnutella protocol in order to help prevent attacks as well as detect an attack and identify the malicious user who coordinated the attack.
The following definitions should be applied when reading this report:
- Servent - A program used to participate on the Gnutella network. Known as a servent because it functions as both a client and a server. Popular servents include BearShare, LimeWire, Morpheus and Gnucleus.
- Coordinator - a malicious user responsible for anonymously causing other users on the Gnutella network to voluntarily attack a target computer.
- Target - the computer which is subjected to a distributed denial of service (DDoS) attack. This computer does not have to be connected to the Gnutella network. For example, the target computer could be a popular e-commerce web server, or an email server, or a home Internet user whose computer is not running any publicly accessible services.
- Attacker - a peer user on the Gnutella network who unknowingly attacks a target computer.
Packets on the Gnutella network fall into one of the following categories:
- Ping, which a servent sends to request information about peer users on the Gnutella network.
- Pong, which a servent sends in response to receiving a ping. A pong packet announces the servent's IP address, port number they are listening on, and the number of files and total size of files they are sharing.
- Query, which a servent sends to look for files matching a specified keyword.
- Queryhit, which a servent sends if it has a file matching the keyword from a received query packet.
- Push request, which a servent sends to download a file from a servent which is behind a firewall. A push request packet causes the servent with the file to connect out to the servent that wants the file.
Pong and queryhit packets contain the IP address (and port number) of the servent which generated the packet. It appears common practice for servents to extract the IP address (and port number) from these packets as servents route them, in order for the servent to subsequently connect to the apparent peer on the network to expand the searchable file base available to the user. Some protocol specification documents actually suggest this as a useful method to locate other peers on the Gnutella network. The following quote is from an article titled The GnutellaNet Protocol at MROB, located at http://www.gnutelliums.com/linux_unix/gnut/doc/gnutella-prot.html
A cursory analysis of GnutellaNet traffic shows that PING comprises roughly 50% of the network traffic. Clearly, this needs to be optimized. One of the problems with clients today is that they seem to PING the network periodically. That is indeed necessary, but the frequency of these "update" PINGs can be drastically reduced. Simply watching the PONG messages that your client routes is enough to capture lots of server addresses.
Unfortunately, a malicious user on the Gnutella network could coordinate an attack by embedding any IP address and port number in pong and queryhit packets which they generate. This would make the embedded target IP address appear to be a peer on the Gnutella network, resulting in the embedded IP address receiving numerous frequent connection attempts on the specified port number. The attack coordinator could increase the severity of the attack by modifying all pong and queryhit packets routed through them to contain the target's IP address and port number. This is a magnification attack, since the coordinator only needs to send one packet in order for the target to receive many connection packets. As a result, a coordinator with pitiful bandwidth could disrupt a target which has significantly more bandwidth. Note that the push request packet also contains a servent's IP address, but this type of packet is exploitable to a much lesser extent and will not be discussed in detail in this report.
More of the target's bandwidth would be wasted if the connection attempts were successful. The coordinator could embed a port number which the target is running a service on. If the target is a web server listening on port 80, the target would waste even more bandwidth by sending back a HTTP error message. If the target is an email server listening on port 25, the target's connection resources would be wasted since interactive services such as SMTP will hold the connection open until it times out.
The coordinator can retain anonymity since they do not have to directly communicate with the attackers or the target. The coordinator is not sending anything to the attackers or the target. Rather, they are just sending packets with the target's IP address embedded in them to one servent which then propagates it through the Gnutella network.
All Gnutella packets contain a hop count value which indicates how many servents the packet has passed through, and a time-to-live value which indicates how many more servents the packet should pass through before being discarded. A coordinator could increase their anonymity by artificially increasing the hop count value slightly, and slightly decreasing the time-to-live value of packets which they generate. This results in the servent directly connected to the coordinator having no idea who generated the packet, and thinking that the coordinator is merely routing the packet on another peer's (apparently the target's) behalf.
To help maintain the coordinator's anonymity, the coordinator should not reply to an incoming ping/query with a pong/queryhit containing the target's IP address if the incoming ping/query has a hop count of 0. Also, the coordinator should not modify a pong/queryhit packet being routed through them to embed the target's IP address if the pong/queryhit has a TTL value of 1 (after the coordinator has decremented it). This indicates that a servent directly connected to the coordinator originated the ping/query, and a coordinator would prefer not to turn a servent directly connected to them into an attacker.
As detailed in this report, the fundamental requirement to exploit the Gnutella network is the ability for a malicious person to embed someone else's IP address (and port number) into outgoing pong, queryhit and push request packets. Unfortunately, the popular open source Gnutella servent Gnucleus provides a GUI to help the user do exactly this. There may be a legitimate use for this functionality, although the author of this report does not know what a legitimate use could be. Nevertheless, by abusing this functionality, a malicious person with limited skill could easily and anonymously coordinate an attack against any computer on the Internet using nothing more than the Gnucleus servent. A slightly more skilled malicious user could modify the source code shipped with the Gnucleus servent to maximise their anonymity by tweaking the hop count, and increase the severity of attacks by appropriately modifying the embedded IP address and port number of packets routed through them.
This screen shot shows that the Gnucleus servent provides the user with the ability to embed an arbitrary IP address and port number in pong, queryhit and push request packets.
This screen shot shows that when the author of this report set his IP address to 127.1.2.3 in the Gnucleus configuration menu, his outgoing pong packets contained this IP address.
The author of this report ran a packet capture utility and connected to the Gnutella network for a short period of time. Only a small capture of less than 4MB in size was performed. A second sample capture was also taken. The captures were then analysed with disturbing results. The author found that pong packets sent by the author's servent resulted in numerous connection attempts to the author's servent. If the author had specified an alternative IP address to use in outgoing pong packets, then that IP address would have received the connection attempts instead. The author also found evidence that the type of attacks theorised in this report were already occurring, and that the author may have unknowingly contributed to such an attack.
This screen shot shows that merely 9 seconds after the author connected to the Gnutella network and had his IP address propagated through the network, incoming connection attempts were received at the rate of about one every four seconds.
This screen shot shows that after being on the network for 592 seconds, the rate of incoming connection attempts had increased to several per second. The actual rate was probably much higher, however the author's 28.8k bandwidth was saturated, resulting in some incoming connection attempts being dropped upstream at the author's Internet service provider.
This screen shot shows that a Gnutella peer was using a pong packet to advertise its IP address as being 22.214.171.124, and instead of listening for incoming Gnutella connections on the default port 6346, was listening on port 80.
A small chance existed that this was actually a legitimate Gnutella peer who had to use port 80 because their computer was behind a packet filtering firewall which allowed port 80 traffic but not traffic on port 6346. However, this peer advertisement was a little unusual because they were sharing no files. The IP address resolved to onlineforeducation.com which appeared to belong to a commercial organisation. Further investigation using the whois utility revealed that the IP address belonged to a company called Interland, which is "the #1 provider of Web Hosting services for small and medium-size businesses" according to their web site at http://www.interland.com.
The netcat utility was used to connect to port 80 to determine if the IP address was actually a legitimate Gnutella peer, or a web site which was suffering a distributed denial of service attack due to attack-coordinating packets like the one in the above screen shot being sent on the Gnutella network. The following output from netcat shows that the IP address was actually a web site which the system administrator apparently was forced to disable on 29th January 2002 while they tried to figure out why they were receiving an overwhelming number of strange hits to their web site.
C:\WINDOWS>nc 126.96.36.199 80
GET / HTTP/1.0
HTTP/1.1 200 OK
Date: Sat, 01 Jun 2002 18:24:48 GMT
Server: Apache/1.3.19 (Unix) FrontPage/188.8.131.520 mod_ssl/2.8.3 OpenSSL/0.9.6b
Last-Modified: Tue, 29 Jan 2002 20:48:13 GMT
<html><title>Site Temporarily Unavailable</title>
<body bgcolor=#ffffff><font face=arial size=5><center>
<h1>Sorry, this site is temporarily unavailable.<br><br>Please check back later.
This screen shot is a more graphical version of the evidence to support the theory that the Gnutella network was already being used to attack arbitrary computers on the Internet.
It is possible that the author's Gnutella servent connected to this web server, thinking that it was another servent on the Gnutella network. The author of this report may have unknowingly contributed to the distributed denial of service attack against this web site. A search on the Internet resulted in publicly accessible snort intrusion detection logs which showed that other people on the Internet had also been sending Gnutella traffic to this web site.
This screen shot was taken from Google's cache of snort logs from the usrbin.org domain. It appears that between 24th March 2002 and 6th May 2002 computers in the usrbin.org domain contributed to the distributed denial of service attack against the web site at IP address 184.108.40.206. The URL of the web site in the above screen shot is http://220.127.116.11/search?q=cache:EPo8Svz6SH4C:www.usrbin.org/snort/ 216/247/191/dest18.104.22.168.html+%2222.214.171.124%22&hl=en
This screen shot shows the IP address 126.96.36.199 (and port number 80) being advertised as a peer on the Gnutella network.
This screen shot shows that port 80 of the IP address 188.8.131.52 is actually a commercial web site.
This screen shot shows that a Gnutella peer was using a queryhit packet to advertise its IP address as being 184.108.40.206 and instead of listening for incoming Gnutella connections on the default port 6346, was listening on port 80.
There was a small chance that this was actually a legitimate Gnutella peer who had to use port 80 because their computer was behind a packet filtering firewall which allowed port 80 traffic but not traffic on port 6346.
As can be seen by the output of the resolve command, the IP address did not resolve to a domain name, but did resolve to the NetBIOS name RACK47, indicating that it was a computer belonging to an enterprise.
220.127.116.11 = RACK47
The whois utility revealed that the computer belonged to an organisation called Global Internet Communication Inc.
The netcat utility was used to connect to port 80 to determine if the IP address was actually a legitimate Gnutella peer, or a web site which was suffering a distributed denial of service attack due to attack-coordinating packets like the one in the above screen shot being sent on the Gnutella network. The following output from netcat shows that the IP address was actually a web site which apparently had its home page removed on 10th May 2002.
C:\WINDOWS>nc 18.104.22.168 80
GET / HTTP/1.0
HTTP/1.1 200 OK
Date: Sat, 01 Jun 2002 18:21:21 GMT
Last-Modified: Fri, 10 May 2002 18:13:30 GMT
This screen shot shows the bogus IP address 22.214.171.124 claiming to have another file. The Servent ID field should theoretically be the same in both queryhits since it is the same servent offering both files. Changing the servent ID may be an attempt for a coordinator to remain anonymous when they later advertise files from a different target IP address. This is because a coordinator would not want the two target IP addresses to be linked by a common servent ID field.
The type of attacks discussed in this report can be mitigated to a large extent by minor changes to Gnutella servents. Going one step further, malicious users who coordinate attacks could be identified via a modification to Gnutella servents. Going yet another step further, advanced detection of malicious users who coordinate attacks could be achieved by an addition to the Gnutella protocol and a modification to Gnutella servents to support the new protocol functionality.
Immediate threat mitigation would be achieved by modifying Gnutella servents to not connect to advertised IP addresses if the corresponding port number is typically used by another service such as HTTP, FTP or SMTP. Instead of specifying these services individually, a blanket fix would be to change Gnutella servents to not connect to advertised IP addresses if the corresponding port number is less than 1024.
Implementing this change might disadvantage Gnutella users who are in a corporate environment and are behind a low quality packet filtering firewall which only allows port 80 traffic through, since peers on the Gnutella network would no longer be able to connect in to them. However, the number of users disadvantaged by this change should be insignificant, since a decent quality stateful inspection packet filtering firewall or application/proxy firewall would have prevented Gnutella peers connecting to them anyway. The impact to Gnutella users behind a low quality corporate firewall should be minimal since they can still connect out to participate in the Gnutella network, and can still search for and download files.
Gnutella servents should also be modified to wait only a short period of time for the GNUTELLA OK reply string during connection negotiation. This minimises the abuse of connection resources if the targeted port runs an interactive service such as SMTP.
The Gnucleus Gnutella servent should be reviewed to determine if users actually require the ability to insert an arbitrary IP address in outgoing pong, queryhit and push request packets. Removing the GUI screen which allows an arbitrary IP address to be entered would prevent unskilled "script-kiddies" from coordinating an attack. However, a reasonably knowledge script kiddie only requires a C compiler in order to insert an arbitrary IP address since the Gnucleus servent is supplied with full source code.
These suggested enhancements to Gnutella servents should immediately mitigate the type of attacks discussed in this report. However, encouraging users to upgrade to a fixed version of their favourite Gnutella servent could be difficult since they are just an accessory to attacks, and are not attacked themselves. The following suggestions are provided in order to identify malicious users who coordinate attacks.
Gnutella servents could be modified to determine if a directly connected Gnutella peer is attempting to coordinate an attack by advertising an IP address which is not their real IP address. A Gnutella servent could check incoming pong, queryhit and push request packets. If the hop count value is 0, it means that the packet was generated by a directly connected servent. The IP address inside the packet could be compared to the actual IP address of the directly connected servent. If they are different, then the directly connected servent is attempting to advertise an IP address which is not their real IP address. An example of this is provided in the following screen shot. Note that a clever attack coordinator could defeat this detection method by inserting a hop count value of 1 into the packet to make it appear as though they are routing the packet instead of generating it themselves.
This screen shot shows the directly connected servent with IP address 126.96.36.199 (resolves to bunyip.weebeastie.net) apparently advertising itself (since hop count = 0) as having the IP address 188.8.131.52. Section 5.3 of this report showed that this advertised IP address was actually a web server apparently suffering a distributed denial of service attack due to attack-coordinating packets like the one in the above screen shot being sent on the Gnutella network.
The Gnutella protocol could be enhanced to provide advanced detection of malicious users coordinating an attack. A Gnutella servent should assume that it is being turned into an attacker if it sees an IP address in a pong, queryhit or push request and when the servent tries to connect, download, or upload a file to the IP address, finds out that the IP address is bogus because it connects but does not successfully negotiate a Gnutella connection (i.e. the IP address and corresponding port number turns out to be a different type of service such as SMTP, HTTP or FTP).
The servent which has become an attacker could determine the IP address of the Gnutella peer who told it to connect to the bogus IP address. This could be accomplished by adding "traceroute request" and "traceroute reply" functions to the Gnutella protocol. These functions would allow an attacker to determine the IP address of each peer between themselves and the attack coordinator. Each peer notifies the attacker of the next IP address in the path between the attacker and the coordinator. This would not require the cooperation of the coordinator, since the servent directly connected to the coordinator is the one who notifies the attacker of the coordinator's IP address.
A clever coordinator could try to blame another peer on the network by sending back someone else's IP address. Nevertheless, the coordinator's IP address has already been returned to the attacker. Incorporating traceroute request and traceroute reply functions into the Gnutella protocol reduces the anonymity of Gnutella users and allows an attacker to determine the IP address of the coordinator with significant accuracy.
This report has discussed a theoretical flaw with the Gnutella network which could allow a malicious user to anonymously coordinate an attack, resulting in other users on the Gnutella network performing a distributed denial of service attack against any computer on the Internet.
All Gnutella servents which extract IP addresses of potential peers from packets on the network are affected by this issue. Users of these servents are vulnerable to being used as attackers, and since they each only send a small amount of data, they would not even know of their participation in an attack. Furthermore, the coordinator does not have to compromise (in the traditional sense of the word) the security of other Gnutella users in order for them to voluntarily participate in the attack.
This report has illustrated that it would be trivial for a malicious user to coordinate such an attack. No special skills or tools are needed, rather, only a free and publicly available Gnutella servent is required.
Evidence has been provided which indicates that the Gnutella network is already being used to launch the type of attacks described in this report.
Finally, modifications to servents and the Gnutella protocol have been suggested which would prevent attacks, as well as help to detect an attack and identify the malicious user coordinating the attack.
The Gnutella Protocol, http://www.gnutelladev.com/protocol/gnutella-protocol.html
Gnutella Protocol Specifications, http://capnbry.net/gnutella/protocol.php
The GnutellaNet Protocol at MROB, http://www.gnutelliums.com/linux_unix/gnut/doc/gnutella-prot.html
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.6-2 (MingW32)
Comment: For info see http://www.gnupg.org
-----END PGP PUBLIC KEY BLOCK-----