Home 0P3N Blog Problem With Man-In-The-Middle (dnsspoof And Ettercap) Attack On This Course
Ready to Start Your Career?
Create Free Account
authors profile image
January 1, 2016

Problem With Man-In-The-Middle (dnsspoof And Ettercap) Attack On This Course

January 1, 2016
authors profile image
January 1, 2016
Hi guys, Its an amazing course thanks to @Georgia. However I having trouble with dnsspoof and ettercap tools. I do everything as Georgia shows but my targets are still able to get to www.gmail.com for example, even though they suppose to see "my site" on apache server on my Kali. I have ip forwarding set to 1(/proc/sys/bla bla bla). I have the correct host.txt file(127.0.0.1 www.gmail.com). I have apache service running. ...and I see all the traffic when target communicates with Default Gateway (Promiscuous mode is disabled). But the targets aren't redirected to "my website" on kali. Literally everything is working except they can still be resolved to legit site, in this case https://www.gmail.com. I was wondering do I have to set up some rules in IPTABLES to block something before these MITM attacks? What am I missing guys? Hi guys, Its an amazing course thanks to @Georgia. However I having trouble with dnsspoof and ettercap tools. I do everything as Georgia shows but my targets are still able to get to www.gmail.com for example, even though they suppose to see "my site" on apache server on my Kali. I have ip forwarding set to 1(/proc/sys/bla bla bla). I have the correct host.txt file(127.0.0.1 www.gmail.com). I have apache service running. ...and I see all the traffic when target communicates with Default Gateway (Promiscuous mode is disabled). But the targets aren't redirected to "my website" on kali. Literally everything is working except they can still be resolved to legit site, in this case https://www.gmail.com. I was wondering do I have to set up some rules in IPTABLES to block something before these MITM attacks? What am I missing guys? Have you checked the DNS on the target to see if they are now pointing to your server when they query for the site ip ? @Vodkanaut target's (Ubuntu 14.05) DNS was 127.0.1.1. If the poisoning had worked DNS on target machine should be my servers IP? Thanks Impact Nice @Karvina posting anything for free CYBYTES :D Nice!! I have the same problem. ARP spoofing has succeeded in the victim OS. Using the arp -a command in my windows XP machine shows that MAC address of the gateway is changed to the MAC address of the attacking client(Kali). Every DNS lookup that I try is forwarded to the gateway and the DNS response is forwarded to the victim machine without being altered. Everything works fine apart from the modification of the responses (confirmed by looking into wireshark traffic). 192.168.3.140 Kali 192.168.3.1 gateway 192.168.3.141 XP commands used # echo 1 > /proc/sys/net/ipv4/ip\_forward # arpspoof -i eth0 -t 192.168.3.141 192.168.3.2 # arpspoof -i eth0 -t 192.168.3.2 192.168.3.141 # dnsspoof -i eth0 -f /root/hosts.txt source 192.168.141 and udp port 53 hosts.txt: 192.168.3.140 www.gmail.com does the hosts file need to have a specific seperator (space or tab)? Did anyone find a solution or can help me troubleshoot this issue? this: hosts.txt: 192.168.3.140 https://www.gmail.com should look like this: 192.168.3.140 www.gmail.com gmail.com Well actually my hosts.txt was: 192.168.3.140 www.gmail.com I am pretty sure that the prefix "http://" should not be included. Protocols (and therefore ports) are not included in DNS requests. The change that @ngv proposed didn't make any change. I searched about the format of the hosts file and the appended gmail.com is just an alias. As a last resort, I used the sample hosts file that the dnsspoof provides (/usr/share/dsniff/dnsspoof.hosts) and tried to nslookup one of its entries. It didn't seem to work either. I noticed that if I stop forwarding packets, dnsspoof finally sends the spoofed response, but after the dns request timeouts. I suspect that we forward the "legitimate" DNS response faster than we send the spoofed one. Thus the Gateway beets us in the race for response and our spoofed response is dropped. After digging around in the web, I came to the conclusion that dnsspoof does not operate well in kali 2.0 version. As user **uraimund** states in [](https://bugs.kali.org/view.php?id=2631) > This is because dnsspoof in Kali 2.x has response times of up to 500ms. So it is impossible to win the race against the real DNS server. I tried linking dnsspoof against an older libpcap.so.1.3.0 - and the response times became extremly fast again ( For more info take a look at the foresaid link. I will try the fix that they provide and post again. I confirm that the example works fine with Kali 1.1.0. If you want to avoid setting up a new vm, you can download the appropriate vm and test it from [http://www.osboxes.org/kali-linux/](http://www.osboxes.org/kali-linux/) > > The fix suggested in [https://bugs.kali.org/view.php?id=2631](https://bugs.kali.org/view.php?id=2631) worked fine for me. Steps: 1. download libpcap 1.7.4-2kali1 from [here](http://repo.kali.org/kali/pool/main/libp/libpcap/libpcap0.8_1.7.4-2kali1_amd64.deb)2. install with dpkg -i libpcap0.8\_1.7.4-2kali1\_amd64.deb And... voilà! dnsspoof now works like a charm in Kali 2.0 and the dns spoofing example is completed! > > Alongside with the commands and procedures you've followed afterwards you should start unified sniffing with "MITM" selected in ettercap GUI so that your machine could set in the middle and intercept traffic for you > > That is an alternative way of carrying the MITM attack. Ettercap can do the ARP spoofing and effectively render the attacker a Man In The Middle(the same thing that arpspoof does). My problem was that while being in the middle (and able to intercept all traffic with a sniffer), DNS response packets were forwarded to the victim host before the spoofed DNS responses were sent (dnsspoof was too slow). This appears to be a (reported) bug in dnsspoof included in Kali 2.0 and can be resolved by installing libcap 1.7.4. > > @G.Kousoulis nice research! I will try to use your steps when a get a chance to overcome the issue. Thanks > > thanks a lot it's better ! > > Although libpcap0.8\_1.7.4- does speedup the delivery of spoofed DNS packets, this issue still persists in Kali rolling. Has anyone fixed it Kali rolling?
Schedule Demo

Build your Cybersecurity or IT Career

Accelerate in your role, earn new certifications, and develop cutting-edge skills using the fastest growing catalog in the industry