RageLtMan
074120a2d3
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