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.
Due to how this stack is being broken up into LDAP core, scanner
update, and exploit work, changes requested in #15972 actually
apply in this branch and get rebased to the remaining ones.
Address requests to clean up the textual messages, LDIF file read,
sourcing of LDAP methods from net-ldap, and YARD-related placement
of attr_* annotations.
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
Ruby 3 removed the `URI.escape` methods however access to
the a parse for the same RFC is stil available at `URI::DEFAULT_PARSER.escape`.
Per the Ruby forum [comment](https://bugs.ruby-lang.org/issues/17309#note-1) this should equal.
Switch to setting Powershell::prepend_protections_bypass to be
automatically determined by the module. If the generated command is too
large, disable the setting and regenerate the command.
It's unnecessary to encode the final Powershell command in this context
because the modified YSoSerial payload will properly treat the entire
string as the OS command to run.
bwatters