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.
In order to detect scan callbacks, serve payloads, and otherwise
interact with the LDAP protocol handler in JNDI, Metasploit needs
a native LDAP service properly exposed to various parts of the
Framework and users/consumers.
Implement Rex::Protocol::LDAP::Server with TCP and UDP socket
handlers abstracted to a common access pattern between L4 stacks.
Extend the socket clients to hold a state attibute for LDAP bind
authentication, and use the UDP client abstraction to implement
consistent callback semantics for data receipt from a client and
handling response on the other side. The server utilizes Rex'
native sockets, permitting full pivot and proxy support over the
Switchboard.
Implement the Msf::Exploit::Remote::LDAP::Server mixin to manage
service abstraction and shared methods exposed to Metasploit
modules.
Note: during implementation of this functionality, it was
discovered that the Scanner mixin's :replicant method resulted in
:dup calls to the Rex::ServiceManager service created by this new
mixin (and any others leveraging ServiceManager). As a result,
double-bind attempts created failures in service instantiation from
the duplicated MetasploitModules which also dropped the @service
instance variable reference to the actual running service; leaving
the socket inexorably bound until Framework was halted and Ruby
released the FDs. See https://github.com/rapid7/rex-core/pull/19
and the Issues/Pull Requests sections of R7's MSF GitHub.
Expose the new LDAP infrastructure to users by way of a basic LDAP
server MetasploitModule which consumes a tiny sample LDIF (provided)
and performs queries against it. This is intended to be a template
for future work such as LDAP authentication capture, protocol proxy
for MITM and intercept, and other more specific implementations for
exploits and auxiliary modules.
For feature completeness, provide a Rex::Socket override for
Net::LDAP::Connection until we have a proper, native to Rex, LDAP
client class implemented.
Testing:
Basic functionality only, this is an early effort which will be
extended for feature-completeness over time
RageLtMan