When dealing with SMTP servers the communication needs to flow
a known protocol. To ensure the socket is in the correct state
after a send and receive it needs to be read until a line return
a response code followed by a `space` and additional data and `\r\n`
or the response code immediately followed by `\r\n` is returned.
When connecting to an SMTP server after `HELO` and auth
complete there can be additional data sent from the client
that sits in the socket queue. Adding a `get_once` after connection
has settled ensure any pending for extension responses are cleared.
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.
Heyder Andrade