Add RPORT to the list of DCERPC ports to check

[todb-r7]

Validation steps

• Start a DCERPC service on a port other than 135 or 593. WDS is delightful for this purpose, see Windows Deployment Services Scanner #1420 for instructions from @Meatballs1
• Set the RPORT on auxiliary/scanner/dcerpc/endpoint_mapper to 5040 (assuming you go with WDS)
• Start wireshark or tcpdump with a BPF filter of "port 5040"

Without patch:

• See no traffic on port 5040.

With patch:

• See traffic on port 5040.

[todb-r7]

Also tested with the auxiliary/scanner/dcerpc/hidden module, which doesn't take an RPORTS option, and it works as expected there as well.

[Meatballs1]

I think maybe deregister RPORT would be more correct?

[todb]

You could, but that means you couldn't query alternate ports at all.

[Meatballs1]

Its extremely unlikely that endpoint mapper runs on anything other than 135?

The 593 port is specifically used to hold the Web service endpoint mapper - but tbh I've never seen that? Not sure if this module would actually work with 593 if its expecting HTTP...

"593 provides "endpoint mapper" services for RPC-over-HTTP (when IIS acts as a proxy for RPC). See port 135 for more info. Sometimes enabled automatically by Exchange."

[Meatballs1]

I guess having the RPORT option allows for NAT/tunnelling scenarios. The problem with this solution is if you set the RPORT to 7867 for your local meterpreter portfwd or ssh tunnel, you could scan yourself on 135 without knowing about it! I'm not a big fan of 593 being hidden from the user either...

[todb]

So @Meatballs1 are you saying this is a pointless exercise? It seemed to me that port 5040 acted as a fine endpoint mapper for at least to WDS servers; I can double check that to make sure I wasn't really pulling in data from port 135.

If it's dumb to ask other ports for endpoint mapping services, then I'm with you, the module should just deregister RPORT so users (like me) aren't confused about availability.

[Meatballs1]

I imagine you set the RPORT, but the results you got back were actually from port 135 anyway. I think it is useful for port forwarding situations however it should just be datastore['RPORT'] (Default to 135) and not [datastore['RPORT'], 135, 593,].uniq.each in that case.

[todb]

Got it . Will fix. Thanks!
On Nov 19, 2013 12:00 PM, "Meatballs1" notifications@github.com wrote:

I imagine you set the RPORT, but the results you got back were actually
from port 135 anyway. I think it is useful for port forwarding situations
however it should just be RPORT (Default to 135) and not [datastore['RPORT'],
135, 593,].uniq.each in that case.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/2507#issuecomment-28815591
.

[todb-r7]

Done. To see the changes not counting whitespace (due to the unindenting of the now removed iterator block) see this change without whitespace changes:

https://github.com/rapid7/metasploit-framework/pull/2507/files?w=1