View Single Post
  #4 (permalink)  
Old October 3rd, 2002
cultiv8r cultiv8r is offline
Connoisseur
 
Join Date: August 9th, 2001
Location: Philadelphia, PA, USA
Posts: 358
cultiv8r is flying high
Exclamation

Gnutella has a number of vulnerabilities. Assuming you know a bit about Gnutella's workings, here are some things:

-- If one responds with a PONG with the port set to 80 and the IP address set to that of, say, CNN.com, a lot of people will start bombarding CNN.com with Gnutella Connect requests. Because of caching implemented, it will also take a while before these fake PONGs are removed from the network.

-- If one responds with a QUERY HIT, also with port set to 80 and an IP address that does not belong to me (like with the PING), I might also be causing people to attempt to download a file from a non-Gnutella client.

-- If one responds with a QUERY HIT, with the port and IP address of a Gnutella client user I don't like, I can cause his/her Upload slots to become full with short-lived requests (the file may or may not exist, hence short-lived because it'll abort with an 'File not found' error).

-- One can monitor QUERY HITs for files that are "blacklisted". If so, one could do the same as described above, and fill the upload slots with long-lived requests until full. If the agressor has access to multiple IP addresses, limiting X requests per IP won't protect against this.

-- One can inject the fake QUERY HITs into the network with ease, causing your result list to loose its quality. That is, any attempt to download a file from this "fake" list will fail (or alternativly, it is actively tracked).

-- One can "reverse" the HOP and TTL count in Gnutella messages. That is, each node is normally supposed to increase the HOP count and decrease the TTL count, so that a message does not live "forever". One could for example, reset the HOP count to zero (0) and the TTL to seven (7) (or a slightly higher value, like Hop of 1 and TTL of 6). This causes the message to live longer - at the end of a chain, it might even "double" the life of such message. Increasing the lifetime of messages on the network also increases the number of messages going though the network, thus causing a banwidth flux.

There are actually more things, but these are fairly easy to do with any existing, open-source Gnutella client. The problem is that each message on Gnutella is coming from a trusted source, even if that source is actually mallicious. These issues are also known to Gnutella developers (at least, those participating on the Gnutella Developers Forum), but only a few have shown interest in protecting end-users and others against these kind of "attacks".
Reply With Quote