Peer to Peer Study

Overview

The purpose of this study is to identify the associated threats to a peer to peer application that a typical user would experience. It will also identify which peer to peer applications may pose a larger risk to users. One additional benefit that may be perceived out of this study is the type of traffic and attacks a typical broadband Internet user may encounter.

Peer to Peer Study. 1

Overview.. 1

Table of Contents. 1

Subject Areas Studied. 1

Applications studied. 2

Setup. 2

Statistic Gathering. 2

Study #1 Windows XP Workstation. 3

Study #3 Bearshare. 7

Study #4 HotlineSW... 7

Subject Areas Studied

The goal of this study was to understand and answer the following:

Any increase in attacks when using peer-to-peer applications vs. not using them
Increase in attacks between the different peer-to-peer applications
Complexity of attacks associated with each peer-to-peer application
Differences in attacks between the different Peer to Peer realms

Applications studied

Peer to Peer applications were chosen based on popularity and content that can be accessed through each. Kazaa and Bearshare are more focused on music and movies while Hotline is more focused on applications like games and software. The following peer-to-peer applications will be studied:

Kazaa – popular peer-to-peer tool
HotlineSW – proprietary client/server technology
Bearshare – Gnutella client

Other peer-to-peer applications may be added at a later date.

Setup

A windows XP system with SP1 will be setup with full event logging enabled. The XP system will be setup behind a router that will log all traffic bi-directional. Tripwire will be installed on the XP system to monitor any un-authorized file changes. A separate system containing Ethereal (www.ethereal.com) will log all traffic packets bi-directional as well. Snort will be setup on a third system containing the latest rules set at the time of testing. All Snort logs will be stored in a secure MYSQL database.

Each peer-to-peer application will be installed on a freshly installed Windows XP system. Searches will be done, and files will be downloaded to create activity on the network. The goal is to simulate a typical user, so some files will be made for share, and others will not. Service Packs and other security hotfixes will not be installed. However, a stateful inspection firewall will be placed between the XP system and the Internet. This is done to log all traffic to and from the XP system, to monitor how long connection attempts occur after the peer-to-peer application is removed and for safety of denying outbound malicious activity. This creates one small issue though, that packets sent out of state, of packets that are sent without first establishing a SYN connection, are rejected. For example, if an attacker were to send a ACK scan, the firewall will drop those packets. This may be restudied at a later date.

Statistic Gathering

All statistics will be compared to a standard Windows XP workstation on the Internet, not utilizing any peer-to-peer applications. Statistics will also be compared against each other based on the peer-to-peer application.

The Ethereal logs, Router logs and SNORT logs will all be correlated. Each of the logging systems have a set of scripts designed to alert the administrator should an event occur. Specific packet captures will be displayed for further analysis and education. Each study consists of two weeks of monitoring and collecting data. At the end of the two weeks, a report will be generated and a write-up will be added to this paper.

SNORT is used to determine the amount of attacks the Windows XP system encountered. In addition, SNORT logs will act as the standard count of attacks and complexity. Snort 2.0 with the latest rule set available at the start of each study was setup. Snort was configured to log to a MYSQL database that was secured on the backend of the network.

Ethereal was used to examine specific attack packets and as a method to log all attacks the SNORT rule base might miss. Ethereal logs were rotated daily and activity was compared to the SNORT reports generated.

Firewall logs were also used in determining traffic. The logs were also rotated on a daily basis and compared against the SNORT database.

The complexity of attacks will be based upon information gathered from the logs of SNORT, Ethereal and the router logs. This information will be researched in the following information resources:

SNORT
CERT
CVE
Bugtrack

Finally, by using an who-is database, source IP addresses will be researched and written up in the final report to determine if the peer-to-peer applications draw specific geographical attackers.

Study #1 Windows XP Workstation

Overview

This study was designed to gather information and attacks that a typical workstation, left on for 14 days straight, would encounter on a broadband connection. The data collected from this study will serve as the baseline for analyzing the peer to peer traffic seen in the other studies.

Setup

Windows XP with SP1 will be installed and no additional applications will be installed or used. It is meant to simulate a broadband (always on) computer that an average user would have.

Results

The results are pretty straight forward. A large majority of all hostile packets came in the form of the common worms and viruses. More proof that users do need to be aware of software applications they have installed and maintain patching on these applications. As recorded during this study, some IP addresses consistently sent hostile packets, by a worm that infected that system. Thus, posing the question, how do we educate users? It also poses the question, whose problem is it? Are the ISP’s responsible since they own the network of the infected systems? Is the computers owner responsible as they don’t patch their systems appropriately? And how does this apply to international times. The Internet isn’t owned by one individual who can make a new rule saying “anyone with an infection cannot use the Internet”. Obviously that would be nice, but is just not reality.

Figure 1:Protocol Profiles for default workstation

Type	Number of Attempts	Further Information
Scan Squid Proxy Attempt	1	Snort
Scan Proxy (8080) attempt	4	Snort

Figure 1:TCP

Type	Number of Attempts	Further Information
MS-SQL Worm Propagation attempt	241	Bugtrack

Figure 2:UDP

Type	Number of Attempts	Further Information
ICMP Superscan echo	3	Snort
ICMP Ping Nmap	92	Snort

Figure 3:ICMP

Theory

Study #2 Kazaa

Overview

This study lasted two weeks and a complete attack alert log from SNORT can be found in Figure 1. The attacks caused by Kazaa were minimal, and not very sophisticated. The system was never compromised and most scans were non-evasive.

Setup

The application was set to share five files at a time, and specific files were set to download. Searches were done on a daily basis to increase traffic to hosts. The host was a Windows XP with SP1 installed. It had a default password set to “scooby”, the name of my dog. The purpose was to utilize the application as any user would, and monitor traffic increases based on usage. Kazaa was installed as it was downloaded from www.kazaa.com, with no alterations except the number of simultaneous uploads, which was changed to five.

Results

Kazaa is client to client software that allows anyone to download what they see. Therefore, an attacker could view files and download them if they wanted to that were shared in your Kazaa share folder. The idea was to download certain files that would perhaps entice an attacker to look beyond that shared folder.

Statistics

The 2 week span produced the following:

285 alerts in Snort

18 of them were unique

121 different source IP addresses

154 different source ports

93 TCP 62 UDP

6 different destination ports

Figure 1:Traffic profiles

Type	Number of Attempts	Further Information
Scan Squid Proxy Attempt	1	Snort
Scan Proxy (8080) attempt	7	Snort
Incomplete RPC Segment	12	Snort
Web IIS cmd.exe access	41	Snort
WEB-IIS ISAPI .ida	16	CVE
WEB-IIS Unicode directory traversal attempt	23	CVE
WEB-IIS CodeRed v2 root.exe access	14	Snort

Figure 1:TCP Scans

Type	Number of Attempts	Further Information
MS-SQL Worm Propagation attempt	67	Bugtrack

Figure 2:UDP Scans

Type	Number of Attempts	Further Information
ICMP Superscan echo	6	Snort
ICMP Ping Nmap	66	Snort
ICMP Webtrends scanner	1	Snort
ICMP Destination Unreachable	25	Snort
ICMP large ICMP packet	3	Snort

Figure 3:ICMP Scans

Using the areas of focus outlined earlier in this document, the following are responses to those items.

Any increase in attacks when using a peer-to-peer application

Yes, the system become more visible and an increase in scans and probes did occur.

Complexity of attacks associated with using a peer-to-peer application

The type of scans, probes and attacks did not increase in complexity.

Differences in attacks between the different Peer to Peer realms

It is clear that Worms and ICMP probes were most common when using Kazaa.

Theory

As seen in the results, attacks were limited in both, the volume and complexity. Using Kazaa for 2 weeks straight did not automatically make the system a bigger target than it was before using Kazaa.

It may be completely possible to assume that being targeted a victim of a hacker may be like being in a car accident or winning the lottery. It could be associated with the old phrase “being in the wrong place at the wrong time” theory. For example, let’s look at the number of people who were on Kazaa the last day of this study. 1,000,000 people are using it to share files, and you are just one of them. That makes your odds 1 in 1,000,000, which winning the lottery may be better. An attack at this point would be truly random and would require someone to do a little more than just a simple port scan. It would require someone to actually pick you, perform some reconnaissance, and then actually carry out an attack. What would they get in the end? That depends on what is on your system. The Honeynet Organization has already proven that day to day hackers are after one of two things, either hard drive space or bandwidth. So if you’re on a dial up, you chances become even better against being hacked. Should you be concerned about using Kazza? It certainly adds to the risk factor by offering another service for an attacker to exploit, but the odds are significant. The risk can be calculated by the following formula:

Risk = time spent on Kazaa X attractive files system has X

Please keep in mind that two weeks should not be considered a comprehensive study. Remember, the longer one is online using Kazaa, the larger that window of risk grows.