I will get this tested. My first instinct is to say that there be dragons here as we have tried this before and if memory serves things went south. That said, will review and do all I can to help it land, this has been much needed for a long time (PSH wmi for one already does this sort of madness).
Ping @kernelsmith and @egypt.

I've had a positive reactions from a few pen testers who are already using this. I've also been looking closely at how 'check' does this and will be following this up with some refactors so they both work in a similar way.

Very handy! Reading RHOSTS from a file does not work yet, right?

I'm not fundamentally opposed to the idea of this, but as @sempervictus mentioned there are dragons. I've discussed this with @hdm, @busterb, @wvu, and many others over the years. The biggest difficulty is the difference in victims as regards to payload compatibility. Theoretically, different Targets can have different size constraints but in practice there are zero exploits that actually do.

Exploits targeting multiple operating systems and multiple architectures are a bigger concern. In practice, it's less of an issue because when you find a group of vulnerable boxes, they're quite often all the same, but we still need to be careful about e.g. sending x64 shellcode to an x86 process.

So, about them dragons - this breaks Aux scanners pretty badly. If you pry into http/version scanner and run_host(ip) you're ok, but hitting cmd_run doesnt seem to get there. Think i'mma need to revert this till i can devote some time to digging around in the subtleties of how Aux and Exp execute their runners.

Yes, aux scanner modules use the same trick as this PR. To complete this, we need to move the differentiated logic from the different module types and have only one cook in the kitchen slinging the RHOSTS values one by one into the module datastores.

The above push fixes scanners (to my knowledge). It turns out that we 'fixed' problems we had with RHOST earlier by simply deleting it in the setup function for aux/scanner. This worked great, but to avoid confusion and support legacy stuff, this PR aliased RHOST and RHOSTS. Unfortunately while that was an awesome idea for exploits, it meant that when you launched a scanner module, the first step in the setup process was deleting all your targets. 😢 I removed the setup/cleanup functions and some other stuff related to RHOST as an independent concept, and it seems to work (at least with SMBv1 scanner.

Are there any more dragons on this PR? Should we look to merge this now?

Definitely gremlins in here, for example: obj = self.clone replacing obj = obj.class.new is NOT the same thing and will have disastrous downstream effects on all auxiliary scanners (although subtle). Clone only clones the top-level object, it copies references below it IIRC. This seems like a dangerous PR to merge without extensive testing.

I am pretty sure replicant is used in other contexts where this can go wrong (maybe MSPro?).

My vote is "do not merge, will eat your pets." In testing it breaks aux all over the place.

@sempervictus did you test 0d51ba8 or was that prior?

We are not concerned about preserving MSPro compatibility with this change, by the way. I haven't stumbled into a way to break an aux module yet, but will keep trying. In the mean time, I'll look into cleaning up some aux code so it's actually shared here.

Prior, I had to back it out a while ago. Will re-merge on the next window.

Jenkins test this please.

Do we have any status if this code is up to par ?

Do we have any status if this code is up to par ?

Up to par with what? If you're asking whether or not it works without breaking everything in sight, it seems to, on my end anyway (though merge conflicting a decent chunk of my altered command_dispatcher/exploit, which i imagine wont be a problem for everyone else given Jenkins' approval).

@busterb: it looks like its working so far, aux scanners and exploits both execute, threading appears to work. Will keep using it during sniffer & dns testing.

Alright; I'm going to restart testing this and land this. If there are any last concerns, voice them.

Well, this is a bit of an irritant, because as it is, with most of our exploits, this stops after the first successful exploit. I wish it were a simple matter to enable something like ExitOnSession, though that's a lower-level exploit option. I think that the ability to automatically background should be available on the payload/handler side, and I explored that and got a little close before metasploit threading monsters started launching about 40 handlers for every exploit. Honestly, while irritating, there's no reason not to land this, even if it not as usable as I'd like. I'd welcome other ideas for making this more useful to automate large IP ranges, but that's not something that I think should limit its landing.
Some possible solutions while I'm thinking on this
Optimal: allow the payloads and handlers to become a bit more independent. The multi/handler can now do a lot of negotiating itself because of UUIDs, and supporting the exploitation component somewhat asynchronously would be hella' useful for hackers. Start a handler, then just fire off some exploits. See what comes back. I tried to do this using browser autopwn2 as a guide. I'm not sold that it is impossible, but it took longer than 2 days so I moved to something else. If nothing comes, I'll likely return to it.
Alternative: Enable auto-back-grounding of sessions immediately, possibly leveraging on_connect or something similar.

Regardless, this is still useful, and it is increasingly falling behind master, so I'm just going to merge it and wait for the sound of shattering glass. We can address increasing usefulness of the feature later.

Each one of those handler threads has a database connection (thanks, ActiveRecord!), so that might lead to some problems with resource starvation if you can't control how many spin up. May not impact if we want to land it, but we should be aware.

I had not planned on adding the changes to the handlers until I can make them not explode, and I might as well do that in another PR, anyway.

@bwatters-r7 isn't there a callback when a session is created. Could that be leveraged? The callback could be modified to send the uuid (if it doesn't already). I'm not sure that is enough, along with the session information, to make useful determinations in this situation, but thought I would throw it out there. Admittedly, I don't %100 grok the full situation here.

On a related note, I've always dreamed of the ability to have a callback from multi/handler that could identify the exploit used to get the session. I realize that's unrealistic as you'd somehow have to relay uniquely identifiable info, but man it'd be sweet for tracking.

@kernelsmith I do not entirely grok it myself, so absolutely happy to take advice!
If I understand it, many (maybe all?) of the UUID payloads already send that UUID in the first stage (if staged) so that the multi/handler can tell what stage needs to be sent to complete the session. Not all payloads support that, which was the catch for trying to add an option to use the multi/handler as a universal handler. It was a nice tie-in here, as the multi/handler already supported the 'ExitOnSession' setting, so it would have added features and solved a problem simultaneously.

I'm not sure that leveraging the callback would work, though I've been embarrassingly wrong before on this stuff, so I' not going to say no. Honestly, in the darkest night, I even thought about making a silly, kludgey script that just ran 'background' as the autorun script. Likely, that would work, though I really like the idea of supporting a universal handler, as I can see some benefits as the payloads get smarter, but at least my attempts over the last 2 days suggested it is non-trivial (for me, at least).

Release Notes

This PR allows the user to specify an IP range when using remote exploits.