UDPScanner library does not detect broadcast packets

[bcoles]

Current behavior

The UDPScanner library does not detect broadcast packets.

There are services which will send a reply to a broadcast address, not the source IP address, regardless of whether the initial packet was broadcast or was sent to the host directly.

The scanner_process method is not executed when broadcast traffic appears on the network interface. As such, the @results variable is never populated with the replies, and no replies are available in scanner_postscan.

The current approach taken by various auxiliary modules (scanner and discovery) is to use the Msf::Exploit::Capture library and bespoke spaghetti code that's not reusable.

Additionally, this approach requires custom timeouts for the capture. Attempting to combine this approach with the UDPScanner library, so as to take advantage of the request batching, will cause the module to block on the UDPScanner's ScannerRecvWindow timeout duration which is executed for each batch of hosts.

Expected behavior

The UDPScanner library should be able to detect broadcast packets.

Given that several UDPScanner modules already operate on the assumption that only network traffic directed at the metasploit host should be parsed, and given the noisy nature of modern networks thanks to zero-conf, any changes which allow broadcast traffic to be parsed by the UDPScanner library should probably be added as an optional configuration option (off by default).

[bcoles]

@busterb tagging you as this issue is somewhat related to #8828

[busterb]

sounds useful. Is this different enough to have a different mixin? UDPBroadcastScanner?

[busterb]

I don't see any precedent for Socket::SO_BROADCAST being used in framework, but rather always raw sockets. Why is that?

[bcoles]

[bcoles]

This has since caused an issue on two separate occasions.

Once, on a device I promptly irrecoverably bricked because I'm awesome. Similar to the ASUS Infosvr service, the device replies to 255.255.255.255, rather than directly to the broadcast host.

Secondly, on a HID VertX door controller, as per #10126.

[bcoles]

I'm undecided on UDPBroadcastScanner.

The modules for the protocols mentioned above are dual use - they can be used to gather information from an IP directly, or all IPs that respond to a 255.255.255.255 broadcast packet. In the event that the target IP address is already known, targeting the host directly is stealthier than broadcasting. Splitting a module into two (broadcast/discovery style and scanner/gather style) is overkill.

There's also the issue of whether broadcast modules should be moved to modules/auxiliary/scanner/discovery/; again complicated by dual use. Other such modules include the mDNS Query and WSDD Query modules.

I have no intention of resolving this issue, but will leave the PRs open should someone wish to resolve the issue in the future.

[bcoles]

This issue also affects the scanner/jenkins/jenkins_udp_broadcast_enum module, which could identify all Jenkins servers with a single broadcast packet to 255.255.255.255 in the event that the module is rewritten to use UDPScanner, and the UDPScanner library was rewritten to support broadcast packets.

[github-actions]

Hi!

This issue has been left open with no activity for a while now.

We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 30 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!

As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request.