CVE-2024-21181 Plugin

[leonardo-doyensec]

Hello,
here it is the detector for Weblogic CVE-2024-21181. The issue is detected via a DNS callback, hence the Tsunami Callback Server needs to be set up in order to recieve a DNS query properly.

You can find the tesbed here google/security-testbeds#102

[maoning]

Is the jar still needed with the current implementation?

[lokiuox]

Hi @maoning, yes it is still required for the detection to work. Without it, the plugin will still compile (as to not disrupt the setup process), but it will exit early with a warning during the detection phase asking the user to recompile it with the Oracle library. Note that the warning is only printed AFTER fingerprinting, if a target is actually confirmed to be Weblogic, so it won't appear during scans on unrelated software.

[lokiuox]

Pushed a new version which does not use any Oracle libraries. The protocol was reverse-engineered and the network communications between the detector and the WebLogic server are all handled internally now.

[maoning]

Pushed a new version which does not use any Oracle libraries. The protocol was reverse-engineered and the network communications between the detector and the WebLogic server are all handled internally now.

Thank you, I'm running into a internal compilation error about AutoValue class cannot be extended:

...doyensec/detectors/weblogic_cve_2024_21181/src/main/java/com/google/tsunami/plugins/detectors/cves/cve202421181/weblogic/requests/InitRequest.java:10: error: [ExtendsAutoValue] Do not extend an @AutoValue class in non-generated code.
public class InitRequest extends GiopPacket {
       ^

.../doyensec/detectors/weblogic_cve_2024_21181/src/main/java/com/google/tsunami/plugins/detectors/cves/cve202421181/weblogic/requests/WeblogicIiopRequest.java:8: error: [ExtendsAutoValue] Do not extend an @AutoValue class in non-generated code.
public abstract class WeblogicIiopRequest extends GiopPacket {
                ^

Here are the recommendations:

@AutoValue classes are intended to be closed, with a single implementation with known semantics. Implementing them by hand is extremely dangerous.

Here are some common cases where we have seen code that extends @AutoValue classes and recommendations for what to do instead:

* Overriding the getters to return given values. This should usually be replaced by creating an instance of the @AutoValue class with those values.

* Having the @AutoValue.Builder class extend the @AutoValue class so it inherits the abstract getters. This is wrong since the Builder doesn't satisfy the contract of its superclass and is better implemented either by repeating the methods or by having both the @AutoValue class and the Builder implement a common interface with these getters.

* In other cases of extending the @AutoValue class and implementing its abstract methods, it would be more correct to have the @AutoValue class and the other class have a common supertype.

Could you create a supertype or just remove the usage of AutoValue for this case?

[lokiuox]

Hey @maoning, for some reason I don't get the same issue while compiling. Anyway, I changed the implementation slightly to use the "factory" design pattern, so now those classes no longer inherit from GiopPacket.