The ResolveNames endpoint used to gather emails addresses for targeting
only returns 100 at a time. This updates the module to check if the
search result contains all entries and when it does, it recurses into
itself with a refined search prefix. All results are returned to match
the original functionality instead of enumerating and halting once one
that's suitable for exploitation has been found.
Clean up the Java code for PayloadFactory - the `main()` function
is actually not required, the error seen on initial attempts to
compile was some sort of PEBKAC or weird things in classpaths.
Update the module to start the HTTP server before issuing the HTTP
request starting the call chain which eventually executes the Java
PayloadFactory - that chain is quick and races with the service's
startup time to get the JAR containing the Payload and its factory.
Minor misc cleanup.
Give credit where due: we stand on the shoulders of giants.
Testing:
LDAP request is serviced with response containing our JAR URL and
trigger parameters for the factory to instantiate Payload.class and
call its `main()` function.
HTTP request is serviced to deliver the JAR.
Payload handler on MSF-side is tripped with incoming connection.
Per the discussion with @schierlm on GitHub (mihi), the most direct
way to deliver and instantiate our Java payload in the target is
via remote code loading of the JAR using HTTP. This requires a
bootstrap class, a Factory, which instantiates our Payload.class
by calling its main() function on-load from the HTTP endpoint
serving the remote-code-loaded JAR.
Implement a basic PayloadFactory class and include and its sources
in the Metasploit tree.
Using @schierlm's own code from ~10y ago, implement injection of
the PayloadFactory class into our JAR-encoded payloads. Then,
using more of his code from the same module (2011-3544), implement
a secondary service within the exploit module (Rex::ServiceManager
services don't stack well in Msf namespace as they all get assigned
to self.service - faux pas on our end) to serve HTTP requests with
the injected JAR. Finally, generate an appropriate URL target for
the remote code loaded JAR for injection into the LDAP response and
leveraging a final piece of @schierlm's hackery, generate a valid
URI path (updating the datastore is ill advised @ runtime, but its
needed here for the correct service cleanup routines to fire).
Note: during development, i figured out a way to use Rjb for native
Java object serialization to buffers which we can use in Ruby, so i
stashed that away in the Exploit::Java mixin for posterity and left
a reference to it in the module for future endeavors.
Testing:
Verified that the generated jar is served at the generated URL
Verified that the generated JAR can be executed at the CLI for
both metasploit.Payload and metasploit.PayloadFactory
Currently not triggering the remote code load (per wireshark and
our own HTTP service) when delivering the LDAP response, so tuning
that is the next leg of this effort.
Christophe De La Fuente