Bug #1109

Syn scanner (likely all raw packet inject) are arping from the wrong source IP

Added by HD Moore almost 2 years ago. Updated 4 months ago.

Status:Closed Start date:03/13/2010
Priority:Normal Due date:
Assignee:Tod Beardsley % Done:

100%
Category:general
Target version:Metasploit 3.4.1
Resolution:fixed Release Note:

Description

Reported to the mailing list:

I'm having problems with scanner/portscan/syn auxiliary module. The problems begins when I set up INTERFACE option to the "eth1" value.

During scan I set up tcpdump on another console and got such output:

arp who-has 192.168.20.2 tell 77.83.x.51
arp who-has 192.168.20.3 tell 77.83.x.51
arp who-has 192.168.20.4 tell 77.83.x.51
arp who-has 192.168.20.5 tell 77.83.x.51
arp who-has 192.168.20.6 tell 77.83.x.51

arp-syn.pcap (490 Bytes) Tod Beardsley, 03/15/2010 08:42 am

Associated revisions

Revision cb640571
Added by Tod Beardsley almost 2 years ago

Fixes #1109 -- ARP is now less picky about ARP replies, but does conform to normal networking standards.

git-svn-id: file:///home/svn/framework3/trunk@8832 4d416f70-5f16-0410-b530-b9f4589650da

History

#1
Updated by Tod Beardsley almost 2 years ago

The "incorrect" sender IP address, 77.83.70.51, is by design. Will confer with the reporter if the responses are getting back to him regardless (they certainly should).

#2
Updated by Tod Beardsley almost 2 years ago

Sent to the reporter:


> arp who-has 192.168.20.2 tell 77.83.70.51
> arp who-has 192.168.20.3 tell 77.83.70.51
> arp who-has 192.168.20.4 tell 77.83.70.51

This is normal. Will explain in a bit.

> I'm scanning 192.168.20.0/24 network and machine with metasploit does not
> have any external ip-address or connection to the internet.
> IP-address 77.83.70.51 does not belongs to my IPS.
> I'm reciving such errors in the msfconsole:
> [-] Error: #<Class:0xb54d7410> execution expired

This is normal but probably not desired; need to track down exactly what's expiring and why it's throwing the ugly error. Generally it should be harmless -- this means that you didn't get an arp reply within the timeout. 

The big question is: are you able to scan anything in 192.168.20.0/24? Is there a host in there you know will respond to ARP? (tcpdump while pinging will confirm, even if you get no ping response).

As for 77.83.70.51 -- This is what Metasploit is setting as the source IP address of the ARP packet, and this is settable as the ARP_SECRET advanced option. The source IP address needn't be correct to actually receive ARP replies, since the MAC address /is/ set correctly. (your tcpdump should confirm this).

I've attached an example pcap showing the expected behavior of the syn portscanner. The network being scanned is 192.168.1.100/30 (4 hosts), which includes a printer at .100, me at .101, and nothing at .102 and .103.

Packet 1,2: ARP request and reply.
Packet 3,4 : SYN to .100 port 81, and a RST.
Packet 5: SYN to .101 -- no ARP because I'm .101, so I already know my MAC address.
Packet 6-7: Unanswered ARP requests to .102 and .103 (normal because they're not there).

Hope this helps, and do let me know if you're running into a problem that's not described here.

#3
Updated by Tod Beardsley almost 2 years ago

  • Subject changed from Syn scanner (likely all raw packet inject) are arping for the wrong target to Syn scanner (likely all raw packet inject) are arping from the wrong source IP

Talked to hdm/jduck, and it turns out the source IP /is/ significant on enough networks that it should be legit in order to catch the replies. Will fix.

#4
Updated by Tod Beardsley almost 2 years ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100

Applied in changeset r8832.

#5
Updated by Tod Beardsley almost 2 years ago

  • Status changed from Resolved to Assigned

Still a bit of a problem. Looks like this comes up only on switched networks that don't actually have a gateway -- in that case, you won't hear the replies to your probes because you have a bad mac address. That's the working theory, anyway; waiting to hear back from the reporter to confirm.

#6
Updated by Tod Beardsley almost 2 years ago

  • Resolution set to fixed

Commits in the interim seems to have solved this problem for the reporter -- he can no longer reproduce the problem on his virtualized network. Closing.

#7
Updated by James Lee over 1 year ago

  • Target version changed from Metasploit 3.4.0 to Metasploit 3.5.0

#8
Updated by Tod Beardsley over 1 year ago

  • Status changed from Assigned to Closed

This was fixed two months ago , just never closed correctly.

#9
Updated by Joshua J. Drake over 1 year ago

  • Target version changed from Metasploit 3.5.0 to Metasploit 3.4.1

Also available in: Atom PDF