MAX_TTL)
return false;
[....]
return true;
}
SCENARIO 3: RENAMING A CONTRABAND FILE TO MATCH INCOMING SEARCH REQUESTS
This scenario is included only for the sake of completeness.
An attacker can rename a contraband file stored on their hard disk to match search requests performed by other GP2P users. For example, if an innocent GP2P user performs a search on the string church choir hymns, an attacker could return a search result stating that they have a file called church_choir_hymns_highest_quality.mp3, rename the contraband file to this name, and hope that the innocent GP2P user downloads the misnamed contraband file thereby turning them into an apparent offender. GP2P applications typically automatically share the contents of their download directory for other GP2P users (including an authority) to download, so the introduction of the contraband file and sharing the file may occur without the apparent offender's knowledge. The apparent offender may listen to the song at a later stage and determine that it
is actually a contraband file, however the damage has already been done and the apparent offender may be subject to the authorities' wrath.
There are several drawbacks to this attack scenario. The attacker loses their anonymity since file transfers are performed via a direct TCP connection, so the apparent offender knows the attacker's IP address. Also, the attacker has to host the contraband file on their computer, leaving them open to prosecution by the authorities. Finally, it is not a scalable attack since the attacker's bandwidth is consumed by the attack.
SCENARIO 4: IMPERSONATING ANOTHER GP2P USER
Each user on the GP2P network has a self-assigned randomly generated unique identifier known as a GUID. Failing to also use more appropriate identification such as IP addresses allows an attacker to impersonate another GP2P user on the network.
For example, an innocent GP2P user might perform a search, receive a search result from a second innocent GP2P user, and attempt to connect to the GP2P user with the desired file in order to download the file. The download attempt will fail if the user with the file is behind a firewall. In this case, the user who wants the file sends a push request through the GP2P
network asking the user with the file to establish a connection to them and push (transfer) the file.
When an attacker receives a push request, instead of propagating it, they can impersonate the user who the push request was intended for and transfer a contraband file (potentially even with a contraband-sounding filename....) to the originator of the push request thereby turning them into an apparent offender. GP2P applications typically automatically share the contents of their download directory for other GP2P users (including an authority) to download, so the introduction of the contraband file and sharing the file may occur without the apparent offender's knowledge.
Instead of merely relying on a self-assigned "unique" ID value for identifying users on the GP2P network, GP2P applications could perhaps also verify that the IP address of the GP2P user pushing them a file is the same IP address of the GP2P user who originally claimed to have the desired file (i.e. who the push request was actually intended for). Identification using IP address is more accurate than using a self-assigned value, though problems may arise when users are behind a firewall performing network address translation. The following extract of relevant code from the current version of Gnucleus illustrates that the self-assigned "unique" GUID value is used to determine if the GP2P user who is pushing the file is the same GP2P user who originally claimed to have the desired file.
From the Gnucleus source code file GnuSock.cpp (CVS) version 1.18 dated 10 June 2003:
void CGnuSock:
nReceive(int nErrorCode)
{
[....]
// Server Requesting to Push a file to us
[....]
// Get Server ID of client giving us the file
int Front = m_Handshake.Find(":") + 1;
int End = m_Handshake.Find("/");
7
CString PushGuid = m_Handshake.Mid(Front, End - Front);
PushGuid.MakeUpper();
[....]
// Find the download that requested the push
for(int i = 0; i GetFileName(m_Index);
[....]
}
It can be seen that ParseRequest retrieves the file name (stored as m_Name) and the file index (stored as m_Index) from the user's request, and then proceeds to overwrite m_Name with the name of the file stored at index m_Index. A suggested fix for this example implementation flaw in Gnucleus (and other similarly affected GP2P applications) is to check that the file index and file name in file transfer requests actually refer to the same file.
This type of implementation flaw is one of the more interesting flaws which the author of this article has identified across a range of GP2P applications, since the flaw is in the server component of the GP2P applications. A GP2P user is vulnerable to this attack not because their software has a flaw, but because another user on the network is using flawed software.
The author of this article has informed the programmer of the GP2P application used in examples throughout this article, and anticipates a fix to be released by the time this article is publicly released. However, GP2P users using any GP2P application will still be vulnerable to the attack described here as long as there is at least one user on the GP2P network still running an unpatched version of Gnucleus or one of the other similarly flawed GP2P applications.
A GP2P user (using any GP2P application) who does not want to become a victim to this attack vector could stop using the GP2P network until every GP2P user with flawed software has upgraded to a patched version. Alternatively, perhaps a possible solution would be to incorporate code into every GP2P application so that when a file is about to be downloaded, the version of the GP2P application with the file is checked (via the HTTP Server field) and the file transfer aborted if it is found to be a flawed version of one of the affected GP2P applications.
While reviewing this article, the developer of Gnucleus kindly contributed the observation that instead of using the index/filename combination to identify a file, a cryptographic hash (typically using the SHA1 algorithm) may be used, and searches and download requests can be performed using a hash value as the identifying criteria. Furthermore, an attacker can
incriminate an innocent GP2P user by providing them with a search result that references a contraband file on an authority's computer. The search result would contain the hash value of the file, but a non-contraband sounding filename in order to entice the innocent GP2P user into downloading the file. When the innocent GP2P user downloads (and subsequently shares) the file from the authority, the download request is based on the hash value, and the (mismatching) file names are ignored. Even if the innocent GP2P user downloaded the contraband file from a GP2P user who was not an authority, they will still become an apparent offender if authorities search the GP2P network for hash values of known contraband files, since the contraband file on the innocent GP2P user's computer will match regardless of its filename.
CONCLUSION
Authorities are increasingly claiming that P2P users are infringing copyright laws. The authorities are handling the alleged infringements by threatening the apparent offender's Internet Service Provider (ISP) with a subpoena forcing the ISP to provide the apparent ffender's details to the authority [5], and threatening the apparent offender with a lawsuit [6] [7] [8].
New legislation is being drafted to allow for fines of up to $250000 and even to send apparent offenders to prison for up to five years [9]. Furthermore, authorities have clearly indicated a desire to attack [10] and destroy [11] computers belonging to apparent offenders. However, this article has indicated that in order for the authority's claim to have merit and for their retaliatory action to be justified, they would need to prove that the apparent offender was an actual offender. This would require the authority proving that there were no malicious users on the P2P network at the time, that the apparent offender's P2P application had no implementation flaws, and (as shown in Scenario 5) that none of the numerous other P2P applications that could have been connected to the network at the time had implementation flaws.
The author of this article is not a lawyer, though it appears that implementation flaws in P2P applications (such as the small sample of flaws detailed in this article, along with other flaws not in the public domain), coupled with the inherent trust placed in a network which is untrustworthy (if not downright hostile when users such as the author of this article are involved), make it nearly impossible for authorities to prove that a P2P user knowingly committed an offence, or even committed an offence at all. Obviously however, if the apparent offender's computer is seized and inspected by an authority and there are contraband files with contraband-sounding filenames in the directory c:\pirated_mp3s, there is an indication of a guilty mind and/or intent and it may be time for the (not-so-apparent) offender to consider a plea bargain.
Authorities recently filed a lawsuit against a 66 year old woman accusing her of illegally sharing hundreds of songs including rap music via the KaZaA P2P network, and threatened fines of up to $150000 for each song [12]. Instead of succumbing to the scare tactics of the authorities and settling out of court, she disputed the claim and questioned the evidence of her alleged misbehaviour. The authorities subsequently dropped the lawsuit.
A GP2P user who the authorities claim is an apparent offender should also consider disputing the authority's "evidence". If the user allegedly searched for or returned matches for a contraband file, they could claim that an attacker generated or manipulated network communication data in order to incriminate them. If they allegedly downloaded a contraband file (e.g. from an authority), they could claim plausible deniability - an attacker must have tricked them into doing it in order to incriminate them. Furthermore, their GP2P application automatically shared the contraband files which they didn't even know they had, for other users (including an authority) to download.
In a nutshell, alleged offenders could show this article to the authorities and claim that they were victimised by an anonymous user on the network - and they probably were.
REFERENCES
[1] FastTrack P2P Technology Message Service Identity Spoofing Vulnerability, 17 Feb 2002,
http://www.securityfocus.com/bid/4121/discussion/
[2] FastTrack P2P Technology Message Service Denial Of Service Vulnerability, 17 Feb 2002,
http://www.securityfocus.com/bid/4122/discussion/
[3] FastTrack P2P Supernode Packet Handler Buffer Overflow Vulnerability, 26 May 2003,
http://www.symantec.com/avcenter/security/Content/7680.html
[4] Napster, universities sued by Metallica, 13 Apr 2000,
http://news.com.com/2100-1023-239263.html?legacy=cnet
[5] RIAA wins battle to ID Kazaa user, 21 Jan 2003,
http://news.com.com/2100-1023-981449.html?tag=nl
[6] Campus file swappers to pay RIAA, 1 May 2003,
http://news.com.com/2100-1027-999332.html
[7] Line'em up! RIAA to sue thousands, 25 Jun 2003,
http://www.theregister.co.uk/content/6/31434.html
[8] Some Defendants Stunned After RIAA Files Lawsuits, 8 Sep 2003,
http://www.local6.com/technology/2463549/detail.html
[9] House proposal targets file swappers, 17 Jul 2003,
http://news.com.com/2100-1028-1026715.html
[10] Hollywood hacking bill hits House, 25 Jul 2002,
http://news.com.com/2100-1023_3-946316.html
[11] Senator endorses destroying computers of illegal downloaders, 17 Jun 2003,
http://www.securityfocus.com/printable/news/5865
[12] File-sharing suit against 66-year-old sculptor dropped, 24 Sep 2003,
http://www.cnn.com/2003/LAW/09/24/tech.lawsuit.ap/index.html
BOYCOTT/EDUCATE/VOTE!
