Jump to content


Photo
- - - - -

Backtrack 3 VMware Ettercap suddenly not working.


  • Please log in to reply
5 replies to this topic

#1 L3g10n

L3g10n

    Will I break 10 posts?

  • Members
  • 5 posts

Posted 16 June 2009 - 06:40 PM

Hello all, :P

Just to give you some information on what kind of setup i have going. Im running Windows Vista Ult. as my main operating system. I have VMware server running ( VMware-server-2.0.1-156745) where i have backtrack 3 running with persistent changes so its not a live boot, and i have Windows XP SP3 running. Both virtual machines are using a bridged connection with the main machine. Each machine gets an IP from the DHCP, and I have no problems accessing the internet, pinging or any kind of communication between the OS's. I'm a netsec student, and use this virtual environment to test exploiting different vulnerabilities, and make videos of doing so. I have had no problems whatsoever with ettercap up until a few days ago. For some reason the program isn't able to successfully poison. When i chk_poison, there is no poisoning between my targeted machine.
The ettercap command im using.
ettercap -T -q -M arp:remote -P dns_spoof /<target_ip>/ // (obviously replacing the <target_ip> with the appropriate address)

I have used wireshark to analyze the packets to compare a successful poison vs a unsuccessful one in wireshark. I have found the problem and ettercap is simply not rewriting the DST mac with the spoofed one. If i get any replies i can upload the wireshark log...

Some steps Ive taken to try and fix the problem.

I made sure the etter.dns file have the correct ip. **** In backtrack
Restart all the machines, restart the router and cable modem.
ipconfig /flushdns and clear the cache in IE7 ***** on the target machine
echo "1" > /proc/sys/net/ipv4/ip_forward *** In backtrack
Im not sure if your iptable rule sets reset once your reboot, but i have checked my iptables -L in backtrack and all is good. I can upload a copy if anyone wants to see.

I thought there might be some kind of issue with Vista and communicating between the machines, so i reset the tcp/ip stack with netsh int ip reset reset.log still nothing........ :angry:

If anyone could help me out id appreciate it. If you need any more information about my system or anything let me know.
Thanks
L3g10n

Edited by L3g10n, 16 June 2009 - 06:41 PM.


#2 lattera

lattera

    Underground Shizzleness

  • Members
  • 511 posts
  • Gender:Male

Posted 16 June 2009 - 08:19 PM

VMWare prohibits network interfaces from entering promiscuous mode.

#3 L3g10n

L3g10n

    Will I break 10 posts?

  • Members
  • 5 posts

Posted 16 June 2009 - 09:20 PM

Really.... the only part that doesn't make sense about that, is ive done about 10 videos already using ettercap in VMware..... and it worked perfectly each time, it just suddenly stopped.... with no explanation...

I also found this...

Using Virtual Network Adapters in Promiscuous Mode on a Linux Host

VMware Server does not allow the virtual network adapter to go into promiscuous mode unless the user running VMware Server has permission to make that setting. This follows the standard Linux practice that only root can put a network interface into promiscuous mode.

When you install and configure VMware Server, you must run the installation as root. VMware Server creates the VMnet devices with root ownership and root group ownership, which means that only root has read and write permissions to the devices.

To set the virtual machine’s network adapter to promiscuous mode, you must launch VMware Server as root because you must have read and write access to the VMnet device. For example, if you are using bridged networking, you must have access to /dev/vmnet0.

To grant selected other users read and write access to the VMnet device, you can create a new group, add the appropriate users to the group and grant that group read and write access to the appropriate device. You must make these changes on the host operating system as root (su -). For example, you can enter the following commands:

chgrp <newgroup> /dev/vmnet0
chmod g+rw /dev/vmnet0

<newgroup> is the group that should have the ability to set vmnet0 to promiscuous mode.

If you want all users to be able to set the virtual network Adapter (/dev/vmnet0 in our example) to promiscuous mode, you can simply run the following command on the host operating system as root:

chmod a+rw /dev/vmnet0


but im still trying to track down the location of /dev/vmnet0 or some other name of a vmnet adapte..... but still really weird

Edited by L3g10n, 16 June 2009 - 09:50 PM.


#4 lattera

lattera

    Underground Shizzleness

  • Members
  • 511 posts
  • Gender:Male

Posted 16 June 2009 - 10:56 PM

Ah, my bad. I wouldn't know the cause of the problem, then.

#5 G-Brain

G-Brain

    mad 1337

  • Members
  • 127 posts
  • Country:
  • Gender:Male

Posted 17 June 2009 - 05:28 AM

This isn't a solution to your VMWare problems, but you could try using VirtualBox instead.

Here's some information regarding VirtualBox and promiscuous mode.

Edited by G-Brain, 17 June 2009 - 05:31 AM.


#6 L3g10n

L3g10n

    Will I break 10 posts?

  • Members
  • 5 posts

Posted 17 June 2009 - 05:48 AM

Nice thanks ill take a look at that. My little solution that i posted earlier " Using Virtual Network Adapters in Promiscuous Mode on a Linux Host " is something i just came across real quick. This is for a Linux host running VMware. Unfortunately for me, im using Vista Ult 64 bit as my host OS, and i cant seem to find much info about this on google.
On the other side of things... still cant figure out the problem with ettercap in BT3 in vmware. Like i said before it was working perfectly than just suddenly stopped. I am getting an interesting error though... so on my main machine im running Vista Ult 64 bit. when i try and run ettercap -T -q -M arp:remote -P dns_spoof /<target_ip/ // obviously replacing <target_ip> with the targets (in backtrack3), i get an ip conflict error(on the vista machine). The thing is, is the error has to do with the MAC address because i believe that is how ettercap is spoofing the network. When this happens, my main Vista machine gets a 169.*.*.* generic, but my virtual machines are still up and running and can connect to the internet and everything. Obviously with the generic, i cannot connect to the internet on the main machine. (duh) Well im wondering why Vista is resetting to a generic, even when its not a target, merely a gateway to the other virtual machine. Ive search a ton for the past 3 days and haven't been able to find a solution. If any of the seasoned boys could maybe give a word of advice.... ive tried alot of stuff.
Thanks in advance
L3g10n

Edited by L3g10n, 17 June 2009 - 05:53 AM.





BinRev is hosted by the great people at Lunarpages!