Pull in the ysoserial mixin and create target configurations to
permit ysoserial payload generation. Setup datastore options and
execution flow to manage the remote code loading workflow vs the
deserialization approach.
The buffer produced by ysoserial still needs to be marshalled into
a valid Java String or Stream of some sort, and verified functional
against the PoC target container using public ysoserial libraries.
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.
After evaluating a Rex::Java::Serialization::Model::Stream.decode
of a StringIO containing a natively-produced byteArray serialized
Java class, it looks to be quite time consuming to produce a native
construct from the JARs we currently generate - this requires some
lower-level intervention in the payload generation process and a
considerable amount of data & reference organization.
Since time is limited, and such a construct is devilishly difficult
to proof when bulding out-of-band (in a different language), this
commit takes a different direction: attempting to leverage the Ruby
Java Bridge gem to implore Java itself to construct the serialized
data structure and marshal it back into Ruby for our disposition.
Split the :serialized_payload method to build the actual byteArray
payload in :byte_array_payload which encapsulates the Rjb interface
and produces a valid output to the LDAP packet crafting routine in
:serialized_payload (as read on the wire and by the JVM on the
target container).
Unfortunately, another problem exists here - the metasploit.Payload
class raises: #<NotSerializableException: metasploit.Payload>.
This will likely need to be addressed in the payloads repository.
Once the metasploit.Payload can be successfully serialized by Rjb,
the wire format should accept it verbatim for delivery on-target.
Using Java:
1. Build a test class which prints to the console on init
and ctor
2. Build a serializer for the test class which writes the byteArray
representation of the serialized class to a file
3. Build, run, produce the serialized output and b64 encode it
4. Embed the serialized data into our exploit during development to
avoid construction problems for the Rex encoder of those structures
and my lack of experience using them.
5. TODO: use the embedded Java-produced serialized data to tweak
native structure composition from the raw Java class output.
This is still not working, as just natively writing out the Java
byte array produces an ASN.1 decoding error on the exploitation
target whereas the curent implementation producing EOF errors from
the target system. Wireshark is complaining, so its likely to be
an LDAP structuring issue: the protocol should be using tag 4 which
represents an octet string but the wire data has tag 2 since i was
encoding each byte to BER. Adding octal encoding to the byte array
and encoding each char of that to BER makes the LDAP packet legal
but still results in a `javax.naming.NamingException [Root
exception is java.io.EOFException]`
Leaving this here for folks to hack on while i execute work tasks.
Delivery of the raw payload class bytes and ber-encoded payload do
not produce actionable results. Java-based PoCs appear to pass a
byteArray to their LDAP crafting scheme, although the subsequent
BER encoding appears to be opaque or not exist.
Rex::Java::Serialization appears to provide a mechanism by which to
build a Java byteArray in native Rex.
Implement naive NewArray construction, and encode the bytes of that
array per LDAP protocol specification as otherwise the server will
throw an ASN.1 decoding error.
This is still not producing a session, but may be closer to the
solution. So far not even the simple class built as suggested by
@schierlm is executing correctly in the target Docker container,
meaning that the decoded LDAP response packet is not being loaded
or not referencing something correctly.
Per @shierlm's suggestion, implement the LDAP JNDI hooks required
for an LDAP response to trigger code load.
Payload serialization is wrong however, and my `rex-java` is not
great. It looks like there is a serializer in there containing a
`new_class` method - looks promising, but quick greps through Msf
modules aren't giving me a clear path to encode a generated payload
class this way.
Testing: wireshark says the packet is legal
Using the infrastructure developped for use in the log4shell HTTP
scanner, implement a basic HTTP exploit module which performs the
same action as the scanner does per-host on a specific target; but
instead of logging the vulnerability, return a crafted LDAP search
response containing the payload encoded within the search response.
The crux of this effort lies in payload generation, specifically in
crafting the legal LDAP response packet out of the request data and
generated JAR-format payload. The payload selection is based on an
offline discussion with @Mihi during which he indicated JNDI's
ability to load JARs in the same way as raw Java classes. This
assumption/interpretation on my part may be incorrect.
At present, the delivered LDAP search response appears to be valid
in WireShark, and the vulnerable test docker is showing internal
values in its console output a la:
```
Received a request for API version com.sun.jndi.ldap.LdapCtx@3575a
```
which shows that it is processing the response on its end, just
not in the way we would prefer, yet.
This may be a result of how the MSF payload is being shuffled and
mutated by the packet construction method, or a mistake in the way
i pass in the queried base DN or execute the LDAP search response
transaction.
Testing: fails currently for aforementioned reason
TODO:
figure out how to encode the payload/LDAP response correctly
continue testing until verified and upstreamed
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.
Spencer McIntyre