I fear there is a problem with BT5R1's (or kernel 2.6.39.4) handling spoof responses

[cynicaljim]

To make a very, very long story short: I was having trouble geting Metasploit's fakedns+arp_poison
working. After extensive troubleshooting with Metasploit and removing every variable I could
think of- including moving off VMware to two different machines connected via wifi-
here are the final results:

Platforms: Host: MacBook Pro running OSX 10.6.6 and VMWare Fusion 3.3.1
VM1: BT5R1, unmodified, all updates as of 11/4/11.
VM2: Win XP Pro no SPs, unmodified install
VMs sharing a host-only network. Network connectivity working fine for normal meatbag stuff.

I was trying to, of course, arpspoof with arp_poison and spoof DNS with fakedns.
I have had this working in previous versions of BT with ettercap and arp/dnsspoof.
In desperation, I shut off Metasploit, put a static (spoofed) arp entry on the XP vm,
and set up a netcat listener on udp/53 and sniffed the whole thing in NON-PROMISCUOUS
mode on the BT vm.

When I perform an nslookup on the XP VM, Wireshark shows the resolution request entering the BT5
VM, but it never gets to Netcat. Nothing happens. Eventually, XP gives up and goes away.

Here's the interesting thing: if I turn on IP forwarding in the kernel, the packet is forwarded
properly. So there's no firewall blocking it. (Unless forwarding turns something off, but I've
never heard of that, and ipchains or anything else that looks like a firewall isn't running).
Of course, netcat still doesn't see it. There's nothing strange in the logs, and even in
promiscuous mode things don't work properly.

The only conclusion I've been able to reach is that the kernel (or stack, or NIC driver) is
refusing to forward packets for non-native IP addresses to processes on the BT vm. As to why
Wireshark can see it, I suppose its tap in the NIC driver is at a low enough level that it
avoids this problem. Also, netcat, as well as arp_poison+fakedns works properly when
the XP nslookup is set to use DNS at the real IP of the BT vm- so I'm pretty sure I
have everything configured properly.

I've seen several other threads about this problem, but none that have pursued an answer
to this level of detail. And, unfortunately, no solutions. Help! And feel free to call me a
dumbass if I'm missing something obvious... I've looked all over this site and Google.

cynicaljim

[cynicaljim]

Ok: after thinking about it over the weekend, I was able to develop a workaround which well, works, and supports my theory that the kernel is dropping traffic for non-native IP addresses:

ifconfig eth0:0 <address you're spoofing>/netmask

Which configures a secondary IP address on eth0 so the kernel treats it properly. I also tried assigning it as lo:0, but that doesn't work because (duh) the MAC address is different.

On one hand I'm glad to have found a way to make it work, but on the other hand that means that basically every module intended to do spoofing stuff will have to be modified. Yikes! Or some brave soul will have to mod the kernel to behave like it used to. I'd take a stab at it, but kernel hacking isn't part of my skillset.

I also noticed that you need to configure fakedns to listen on the IP address you've created above. Apparently the convention of 0.0.0.0 listening on all interfaces is buggy or broken by the same thing that is dropping traffic for non-native IPs.

Cynicaljim