We locate the dyld_shared_cache in memory to find and resolve the
functions we need in libdyld.dylib. We retain the original dyld location
method on osx versions before Sierra.
Explicitly set length for osx x64 initial stage
The rdx register, used for passing the payload length, is being
clobbered by a system call in the new MacOS version. Instead of relying
on the register being untouched, we set it equal to the payload length.
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.
Add in a minor additional note about needing to potentially create one of the directories in case people run into errors as I encountered this during some recent testing.
Grant Willcox