Search Slyck  
MUTE Security Vulnerability Discovered
February 23, 2006
Thomas Mennecke
Font Bigger Font Smaller
Anonymous file-sharing became the latest P2P buzz word following the RIAA’s initial enforcement actions in June of 2003. Led by such projects as Ants and MUTE, anonymous P2P networks began drawing in those concerned about their online anonymity. Over time, their success remains questionable, as intelligent file-sharing has replaced the need for anonymous file-sharing.

Yet this niche P2P market represents a fascinating research aspect. The primary goal of projects such as MUTE is to provide anonymity and avoid copyright enforcement, which has largely become the responsibility of the RIAA and MPAA.

Here’s a simplified version on how anonymous file-sharing, such as in MUTE, takes place. On a typical P2P community, such as FastTrack for example, a supernode indexes files available on the network. Let’s say there’s one supernode with 10 clients connected to the network. Client "A" searches the supernode’s index, and finds the file he or she wants. This file is located on client “B”. The supernode will then tell client “A” the IP address of client “B”, which then allows the file transfer to initiate directly.

With MUTE, the network is designed in a similar fashion; however there is no direct connection between peers during file transfer. In addition, individual peers are assigned virtual addresses rather than IP addresses. When an individual searches for a file, instead of client “A” connecting directly with client “B”, the file is bounced off several other clients before ultimately ending at its intended destination. In theory, if the RIAA has penetrated the network, it would only receive the virtual address rather than the IP address and would have no idea where the unauthorized file originated.

Here’s where the today’s reported security vulnerability comes into play. Like most other P2P communities, MUTE requires an IP address to connect to the network. MUTE obtains 10 random IP addresses from a webcache, which then allows it to join the community. If a malicious attacker wished to compromise the anonymity of the MUTE client, he or she could manipulate the webcache to only reflect the attacker’s IP address. When an individual connects to the network, he or she would in actuality be connecting to the attacker’s IP addresses, thereby exposing the client’s anonymity.

The circumstances of this event are rare, considering the nominal population of the MUTE network and the circumstances needed to manipulate the webcache. The individual who first exposed this weakness, Gary Whetstone, posted his concerns on Mute’s discussion thread and were addressed by developer Jason Rohrer. Jason also talked about the vulnerability with

"This issue, though not terribly serious, is well known. The problem will be fixed in the next release by changing MUTE to ensure that it has a pool of possible hosts from a number of web caches before it randomly picks from that pool.

"This vulnerability could only be exploited if the attacker was running one of the MWebCaches that you connect to. The attacker would not be able to "flood" a legitimate web cache with attacker nodes. Why? Because the MWebCache software itself prevents nodes from posting themselves repeatedly. Thus, an attacker's nodes could be listed on a legitimate web cache, but other non-attacker nodes would also be listed on that cache. If an attacker runs her own "fake" MWebCache, however, then she could fill it however she chooses.

"The reason that this is not a serious vulnerability is that there are social safeguards in place in terms of how MUTE users learn about new MWebCaches. The primary way that they learn about these caches is through the MUTE website itself, where the latest MWebCaches are posted.

"Yes, it would be easy for an attacker to set up a fake MWebCache, but it would be somewhat harder for that attacker to get that cache accepted by the MUTE user community. "Somewhat harder" is certainly not bullet-proof, of course, and that's why the issue will be dealt with in the next release."

The MUTE homepage also addresses this concern to an extent, stating the RIAA would need to “hijack” every surrounding node in order to “corner” an individual. Although largely dismissed, the possibility of a copyright enforcement entity flooding the MUTE network with peers, perhaps in an effort to vastly outnumber legitimate peers, could indeed compromise the security commonly associated with anonymous P2P networks. Considering the near limitless financial resources of the entertainment industry, such a possibility is not out of the question – especially if MUTE receives widespread adaptation.

This story is filed in these Slyck News categories
P2P Clients :: Other Clients
Technology News :: Security

You can read the security report from Securina here.

You can discuss this article here - 29 replies

© 2001-2019