They are hoping that Universities will install this toolkit to cut down on the amount of illegal file sharing. However, this tool seems to be introducing some severe vulnerabilities to the privacy of users and direct access (unauthenticated and totally anonymous) to the logs of all network traffic that can be accessed from any remote system on the Internet. It also appears that they are providing false information to exactly what this toolkit does.
I went ahead and downloaded this toolkit and performed some rudimentary tests. Below are the initial findings.
Xubuntu loads up and a terminal opens up. This lets you set your networking information and a 'session password'. You can then enter a name to describe the sensor.
You get a message that peerwatch is running and two URLs to manage the device.
Reports
http://192.168.1.125:8180
NTOP
http://192.168.1.125:3000
During this setup the sensor will check to see if there is a new version of the University Toolkit. In my case I downloaded it straight before I installed it and it found a new version was available. The current version at the time of testing is 1.2-RC5. The toolkit will phone home to the universitytoolkit.com site and check a file called version.txt. The last modified date of the file at this time was 10-12-2007 and the text of the file reads 1.2-RC3. So, maybe they are just absent minded about keeping the versions updated properly.
I setup my home router to route all unsolicited traffic from the Internet to my new MPAA University Toolkit. This means that any traffic coming to my home router (initial traffic) will go to my toolkit. I am testing the toolkit from a remote location that is located about 17 miles from the sensor with no VPN.
My device is now actively monitoring the network. Before we go much further let us take a look at the 2-page summary of the toolkit located at
http://universitytoolkit.com/MPAA%20University%20Toolkit%20Overview.pdf.
The bullet points in the summary with my notes enclosed in []:
- The University Toolkit is a free software application to analyze the traffic on campus local networks
[It didn't cost me a thing to download.]
- Creates a simple graphical report on the extent of file sharing occurring within the campus network
[not just file sharing!]
- The University toolkit does not identify infringements
[This is true]
- No privacy issues - the content of traffic is never examined or displayed
[This is not true. There are a lot of privacy issues with this and I'll show you why later]
- It does not communicate results to the MPA
[This will take some time to verify. The sensor will check in for an update for a newer version. Doesn't that mean the MPAA now has the IP address of the toolkit sensor?! More on this later as well!]
- It is offered for free to all universities on CD and as a download on
UniversityToolkit.com.
[This is true]
- Requires minimal effort from IT staff.
[This isn't entirely true. The work that has to be done for this to be effective (for their purposes) is great.]
- Access to NTop and Snort data for detailed analysis.
[From a web based console that has no authentication and lets you view it from anywhere in the world. Yes, this is true!]
Whitney Houston, we have a problem.....
First I have to admit I haven't done full packet captures or analyzed what data is written to disk. It would be much appreciated if someone out there has the time to do this. But just on the face of this I can tell you there seems to be the makings of a great conspiracy theory. If any Universities have installed this toolkit you better read further.
First let us talk about the 'no privacy issues - the content of traffic is never examined or displayed
Nov xx xx:xx:xx ubuntu kernel: [ 223.078052] device eth0 entered promiscuous mode
The network card went into Promiscuous mode which enables a network card to pass all traffic it receives to the CPU rather than just packets addressed to it. It also lets you inspect the contents of those packets. There is more information later in this blog about this.
Another privacy issue. Even though they ask you for a 'session password' the web application used to 'view reports' and 'view ntop' is not password protected. I was able to successfully view what websites were visited, what email servers were communicated with, what remote desktop connections there were, and on and on and on without supplying any credentials at all. This means that anyone (including the MPAA) could access this system remotely and view the console. View all traffic from any host this sensor can see. (don't forget, this system will check for updates giving up the IP address of the sensor to the MPAA). It also appears that the logging for Apache2 is turned off so you won't have any record of what was accessed in the web application.
Here is a screenshot of what what I could see remotely without supplying any authentication whatsoever.
As we can see it shows traffic to pretty much all hosts with which my home computer is communicating with. In a Student Resnet network this would be on a much larger scale.
They did customize some firewall rules to 'specifically' allow access to the MPAA Toolkit from remote. If they didn't want the to be available from remote I would think that they would have either added a function in the setup that let you choose your own rules or password protect the entire application.
#Allow NTOP and PEERWATCH connections
iptables -A INPUT -p tcp --dport 8180 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 8180 -j ACCEPT
iptables -A INPUT -p tcp --dport 3000 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 3000 -j ACCEPT
Port 8180 is the main MPAA Toolkit home page which lets you see the "Top 10 File Transfers" and the "Top 10 Alerts" that was triggered by the Snort rules. There is also a link to an Advanced page that takes you to the NTOP application.
Port 3000 is the NTOP application and it gathers information about network traffic. NTOP will let you see ALL traffic on the network and not just the P2P related traffic. If someone visits their bank it will show up in this log. It will also show the IP address and MAC address of the host that visited the banking site. Now lets put on our 'conspiracy theory hat'. The MPAA could, in theory, get data about an IP address that is file sharing. In their database of sensors that 'phoned home' they could directly access the sensor and get real-time traffic stats for the host they are investigating. They can get the MAC address of said host. A MAC address is unique to a computer and by default doesn't change. A university will match the IP address and timestamp to a MAC address then search their database to find the user. Just let that sink in a bit. To add to this conspiracy lets think of some examples that this tool can be used for. I'll put on an evil MPAA hat for a minute.
What if I log into my MPAA networked desktop computer and think today I want to go look at the sensor on the University of Tinfoil Hats' network. I go there and load up the main application and get a list of IP addresses that are showing to be on the Kazaa network. I get the MAC address and all information I can get. Then I send that information to the packet henchmen (MediaDefender, etc) and tell them to find this IP address and generate data for a DMCA notice. Well, now the MPAA has way more information than they are supposed to have. Actually information that would normally require a subpoena. They can drill down and find out where that IP address is going. Myspace, PirateBay, Grandma's website, whatever. If a person on the network has a personal website they might even be able to get a name and contact information of that user. And to add more weirdness to this scenario the Apache webserver logging is disabled. So you will not know what IP address accessed the application and what pages were accessed.
So lets get to the "the content of traffic is never examined or displayed":
They are using Snort which is a free intrusion detection system that is able to view the packet headers and contents of packets and compare to a list of predefined signatures to determine if specific things exist in the packet. Normally this is used to detect attacks on the network and is also used to enforce company policies.
The MPAA included the following Snort rules in the distribution and listed them in the Snort configuration file:
include $RULE_PATH/bleeding-p2p.rules
include $RULE_PATH/local-ftp.rules
include $RULE_PATH/local-http.rules
include $RULE_PATH/local-smb.rules
include $RULE_PATH/p2p.rules
So it looks like they weren't telling the whole truth about the viewing of traffic content. This tool is in fact looking at that traffic and inside the packets (content).
Example from local-ftp.rules:
alert tcp any 20 -> any any (msg: "FTP Download - MPEG Movie File - B2"; \
content: "00 00 01 B2"; depth: 6; rawbytes; \
sid: 1000501; rev: 1; \
Example from local-http.rules:
alert tcp any 80 -> any any (msg: "HTTP Download > 100M - MPEG Movie File - B2"; \
flow: established,from_server; \
content: "HTTP"; depth: 5; nocase; \
content: "200"; within: 8; \
content: "Content-Length\: "; within: 300; nocase; \
pcre: "/^[0-9]{9,}\r\n/R"; \
content: "0d 0a 0d 0a"; within: 100; \
content: "00 00 01 B2"; within: 6; \
sid: 1000101; rev: 1; \
)
Example from their local-smb.rules:
alert tcp any 445 -> any any (msg: "SMB-445 Download > 100M - MPEG Movie File - B2"; \
flow: established,from_server; \
content: "SMB2E"; offset: 5; within: 4; nocase; \
content: "00 00 01 B2"; distance: 54; within: 4; \
sid: 1000301; rev: 1; \
)
These above do inspect the contents of the packet.
Example of their p2p.rules:
alert tcp $HOME_NET any -> $EXTERNAL_NET 8888 (msg:"P2P napster login"; flow:to_server,established; content:"00 02 00"; depth:3; offset:1;
classtype:policy-violation; sid:549; rev:8;)
Isn't Napster totally legit now? Why would they include a detected napster login?
There seem to be some false positives so far in initial testing. It showed Kazaa traffic coming from my computer but I don't have Kazaa installed. In actuality it is fairly hard to reliably detect P2P traffic. A lot of P2P applications allow for changing of port numbers used as well as encrypting the traffic. Add the popularity of using proxies such as Tor and it gets even more difficult.
I think Perhaps the MPAA jumped the gun a bit when they began to send the letters out asking folks to install this toolkit. There are a lot of changes that need to be made before a tool like this could be installed in a production environment. And of course anyone that is responsible for running a network should always make sure to look closely at devices and applications before putting them into production.
