CS38, Security and Privacy, Spring 2005

Homework 2

Due May 9

This is a preliminary version of Homework 2. I may add or remove a problem or two, depending on how our virtual environment handles crafted packets.

The items marked with *) are harder, and therefore extra-credit, but I encourage you to try them.

Unless the problem statement is explicitly to the contrary, you can use any tool of your choice to generate required packets: sendip, nemesis command line tools, or the netdude GUI packet building tool, or the underlying libraries libnet or its superset libdnet straight up (see the presentation_on_libnet_programming and libdnet manual).

References: Beej's Guide to Network Programming, class reading links.

1. Poor man's covert channel:

a) A program running on cs38victim is accepting "hidden" messages: it sniffs ICMP echo request packets (such as used by ping(8)) and concatenates the TTL values in them into a string. Unprintable (non-ASCII) TTL values are ignored.

Send it an ASCII string of your choice (in good taste, please). The received strings are periodically appended to the world-readable file /tmp/ttlcovert.eth1 or /tmp/ttlcovert.br0 (depending on whether your packets come from the outside network or the virtual network, respectively) or on cs38victim so that you can check your progress.

2. Knock-knock, a port-knocking daemon

The following scheme of hiding a running server has been proposed (and implemented by various people), in order to limit its exposure only to those in the know. The machine that runs the servers is initially configured to deny access to all outside hosts. A daemon process on the machine is receiving data from a sniffer; it notes access attempts to any port over TCP or UDP, looking for a fixed pattern. When it sees a host accessing certain ports in certain order within a limited time, it allows access from that host only to the service. Thus access is limited to those users who know the right sequence of ports. This scheme is called "port-knocking". See, e.g., http://www.portknocking.org/

a) Cs38victim is running a port-knocking daemon. Activate it by trying to access TCP ports 314 1592 6535 8979 3238 within one minute. Access port to 8080 within 5 min will then return a message that you need to record and submit. You can use telnet ("telnet cs38victim.cs.dartmouth.edu 8080", then press Enter a couple of times) or netcat to collect the message. A web browser pointed at http://cs38victim.cs.dartmouth.edu:8080 should also work. (At least Mozilla works, and you *are* using Mozilla for browsing untrusted websites, even though your bank/credit card/other vendor requires you to use IE despite your vehement objections, right?)

Hint: You don't need any fancy tools to do TCP port knocking -- telnet ("telnet host port") or netcat will do just fine.

b*) The same task with UDP port knocking (same ports). A UDP response will be fired in the direction of your machine, based on the IP that your packets came from (you will have to sniff it).

Note: It is possible that your knocking may interfere with someone else's -- the daemon is a bit stupid in this respect, and does not do full tracking by IP (or maybe it is that way to allow one of the knocks to be spoofed?). So try a few times.

3. Poor man's reverse shell:

a) On your virtual machine set up a "reverse shell" that would allow you to run commands on it from any machine on which you have a legitimate account, other than cs38victim. (E.g., some machine on the CS dept network or your home machine.) Note that the virtual machines are not reachable by their IPs from any machine other than cs38victim, the situation typical for a office desktop machine behind a firewall (firewalls often do Network Address Translation, NAT, to prevent outside machines from initiating any connections to protected hosts). However, your virtual machines can freely access the rest of the world. Use this.

You don't have to report the output of the commands that you run, but it will be a bonus. The execution of your commands can be delayed.

Hint1: you can (but not at all compelled to!) use cron(8) and wget(1). There are no restrictions in protocols or tools.

Hint2: since this is an open-ended problem, please feel free to ask for explanations and/or suggestions.

b*) Make sure that only your commands can be executed that way! Consider the possibility that the attacker can sniff your traffic between the controlling machine and the controlled (virtual) host.

Please postpone the following until I notify you that this setup is ready:

4. Sniffing in a switched environment:

On our virtual network, hosts 192.168.1.110 and 192.168.1.120 are engaged in periodic unencrypted communication, believing that the (emulated) switched network keeps them secure from sniffing. Prove them wrong and capture a fragment of their conversation.

Note: arp-sk and the dsniff suite of tools are already installed on your virtual machine, as are tcpdump and tethereal. You may install any other tools you need for this task.

5. a) Using the hunt(1) tool or the appropriate utility from the dsniff package (tcpkill(8)), cause the teardown of the TCP session between 192.168.1.21:port -> 192.168.1.11:22, where port is calculated as follows: (the last octet of your machine's IP addess + 5000), so for 192.168.1.106 this would be 192.168.1.21:5106 -> 192.168.1.11:22. Please don't interfere with other people's sessions (let them wreak their own TCP destruction).

b*) Perform a Man-in-the-middle attack on TCP with hunt or dsniff. On our virtual network, this will require some extra setup, such as giving you another virtual machine as a target. Talk to me if you want to do this, after reading the appropriate manuals.

.

Back to Dartmouth CS Home Page