add plugin cve-2019-15107

[hh-hunter]

Hey,

this PR for the Vuln Detector Plugin for CVE-2019-15017 (see Issue #82)

In order to verify the vulnerability, I used two different docker environments, one for the vulnerable version and the other for the fixed version

Vulnerable image:

docker run -it -d -p 10000:10000 githhhunter/cve-2019-15107:latest

Safe image:

docker run -it -d -p 10001:10000 johanp/webmin:latest

Please let me know what else to do next?

Finally, I have another question. If the target is https, but the certificate is invalid, how can I skip the certificate verification?

[hh-hunter]

@magl0 hi, when will the review start?

[lokiuox]

Hi @hh-hunter, thank you for your contribution! Could you please provide a testbed for this detector?

[RaulDoyensec]

Hi @hh-hunter,

Thanks for your collaboration! Here are a few points to improve the code:

• Please make sure the code passes the google-java-format tool to ensure it follows the proper formatting.
• It would be helpful to add more information about the vulnerability in the README, along with some references to blogs or public exploits for better context.
• Currently, the exploit command is hardcoded in the request. It would be better to generate the command dynamically using tsunamiPayload.getPayload(). This will also allow us to detect the vulnerability using the callback server.
• It would be interesting to implement service detection to verify whether the service is actually vulnerable before launching the exploit.

Thanks again for your efforts!

[hh-hunter]

ok

[hh-hunter]

Hi @hh-hunter,

Thanks for your collaboration! Here are a few points to improve the code:

• Please make sure the code passes the google-java-format tool to ensure it follows the proper formatting.
• It would be helpful to add more information about the vulnerability in the README, along with some references to blogs or public exploits for better context.
• Currently, the exploit command is hardcoded in the request. It would be better to generate the command dynamically using tsunamiPayload.getPayload(). This will also allow us to detect the vulnerability using the callback server.
• It would be interesting to implement service detection to verify whether the service is actually vulnerable before launching the exploit.

Thanks again for your efforts!

@RaulDoyensec I have finished , please review.

[ikkisoft]

Testbed in google/security-testbeds#118

[RaulDoyensec]

Hi @hh-hunter,

Sorry for the delay in the response, here are some notes about your modifications:

• I can't find the detection phase for the service, you could do something similar to the following code to implement it.

    return DetectionReportList.newBuilder()
        .addAllDetectionReports(
            matchedServices.stream()
                .filter(NetworkServiceUtils::isWebService)
                .filter(this::isWebmin) // Create a function to dynamically detect Webmin services (verifying HTML patterns for Webmin)
                .filter(this::isServiceVulnerable)
                .map(networkService -> buildDetectionReport(targetInfo, networkService))
                .collect(toImmutableList()))
        .build();
  }

• The folder name is tsunami-security-scanner-plugins/community/detectors/CVE-2019-15107, it would be better to follow tsunami standars and use tsunami-security-scanner-plugins/community/detectors/webmin_rce_cve_2019_15107.
• I have seen that the following files don't follow the Google Java Format:
  1. CVE201915107VulnDetector.java
  2. CVE201915107DetectorBootstrapModule.java
• The last version of the plugin does not detect the vulnerability with the provided testbed, as curl is not installed in the vulnerable host. You could do a replace in the command from curl to wget to make it works.

Regards.

[hh-hunter]

@RaulDoyensec I've finished modifying it according to your suggestion, please review

[RaulDoyensec]

Hey @hh-hunter,

I tested your recent changes for the plugin, but it looks like the tests aren't passing. Specifically, the test that handles the vulnerable case (detect_whenVulnerable_returnsVulnerability) isn't passing correctly, apparently because the MockWebServer is not configured correctly for that scenario.

Regards.

[tooryx]

Hi @hh-hunter,

This vulnerability is too old and the testbed is difficult to setup again. Closing this issue.
We will prioritize your other contributions.

~tooryx