I’m spending the night learning about the tool ettercap. May as well write down what I learn for future reference.
Ettercap is a Man-In-The-Middle network attack tool for your LAN. It features a bunch of pre-written exploits
for you to run, such as ARP and DHCP poisoning. I’ve previously done some work for school using ARP spoofing where we
used it to automatically take over traffic headed for a server on the same LAN as a failover. You can find the prototype
for that code here: <https://github.com/Tethik/arp-failover>__. This will be a pretty informal post, I’ll update it as I go.
The Setup
Anyhow, back to business. I’m using 3 machines for this experiment. My normal computer (Debian) as the adversary, my old computer (Windows 8) as the victim host and my raspberry pi as the server since I’m already running services on it. I realise this could be done using VMs on a single machine, but I think having a real setup makes it more interesting.
1. Listening in on traffic.
ettercap -T -M arp /192.168.137.164/ /192.168.137.200/80This attack will set up so that traffic destined from the victim to the raspberry pi on port 80 will run through the adversary computer. This gave me the following output:
Thu Jan 22 00:14:58 2015
TCP 192.168.137.200:80 --> 192.168.137.164:49896 | AP
HTTP/1.1 200 OK
Date: Wed, 21 Jan 2015 23:14:59 GMT
Server: Apache/2.2.22 (Debian)
Last-Modified: Wed, 21 Jan 2015 22:45:30 GMT
ETag: "159e-86-50d314fffafa2"
Accept-Ranges: bytes
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 128
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: text/html
QtwpU(HML6%%9v!
E9
EeE6aB}JJ;b=RTT=&bfuVWat? Then I see the Content-Encoding: gzip header. This needs to be fixed. Doing some basic google-work I find that I’m not the first to run into this issue. One fix is to apply a filter which removes the gzip from the content encoding header, making the server reply in plaintext. Preferably I’d just ungzip the content instead. Being too lazy to do that for now I’ll continue with the next attack.
2. Taking over traffic.
For this attack I want the adversary to take over traffic completely. The attacker wants to respond using his own server for e.g. phishing purposes. For this ettercap was the wrong tool it seems, instead I went for arpspoof. The following commands were executed in different terminals. I had to trick both the router and the victim host. Alternatively I could have made it a global broadcast.
arpspoof -i wlan0 -c own -t 192.168.137.164 192.168.137.200
arpspoof -i wlan0 -c own -t 192.168.137.1 192.168.137.200Checking the arp table in Windows 8 (cmd: arp -a) I see that the MAC is successfully injected, but the browser still goes to the raspberry pi. I figure this is because my adversary and victim computer are on a wireless network while the raspberry is on wired. Changing to my ethernet interface on the adversary machin was enough to trick the router to forwarding to my computer. Then I also set the client ip using ifconfig to the same as the raspberry pi on that interface.
arpspoof -i eth1 -c own -t 192.168.137.164 192.168.137.200
arpspoof -i eth1 -c own -t 192.168.137.1 192.168.137.200
ifconfig eth1 192.168.137.200And it works. I don’t know why I have to specifically tell the adversary interface to configure on the server’s ip. I would have though promiscuous mode (ifconfig eth1 promisc) would have enabled that, but no luck.
3. DNS Spoofing
One feat of interest would be to do phishing popular/outside domains. E.g. Facebook or maybe a corporate controlled domain. For this we need to somehow spoof the DNS address to our own local ip instead of the remote. There is apparently an ettercap module dns_spoof which does this for us.
ettercap -T -M arp /192.168.137.164/ /192.168.137.1/53 -P dns_spoofBut… it didn’t work. After some trial and error, I instead managed it with just arpspoof and dnsspoof. I think this is very reliant on the router’s behaviour, since it’s the one being spoofed in this case.
arpspoof -i wlan0 -c own -t 192.168.137.164 192.168.137.1
dnsspoofdnsspoof on it’s own seems to default by answering all queries with the local ip in question. I did notice that I was getting request timeouts when running the nslookup command in windows, and my own company website only worked to spoof once, after that it wouldn’t work. I’m not sure why.
I think I’m done for tonight. I learned enough. Further work I want to do would be to look at SSL-connections and try to manipulate those with self-signed certificates, I’d also like to look at how my “Smart” TV communicates with the cloud that powers its apps, and I might look at how to prevent these types of attacks on my own network.