[Java] CWE-295 - Incorrect Hostname Verification - MitM

intrigus-lgtm commented 4 years ago

CVE ID(s)

List the CVE ID(s) associated with this vulnerability. GitHub will automatically link CVE IDs to the GitHub Advisory Database.

CVEs pending
No CVE for this one: https://github.com/laurent-clouet/sheepit-client/pull/240/files This instance would not have been found by this query. That is not a fault of the query, but sheepit-client uses Lombok which seems to not work well with LGTM. This "hack" should fix it. sheepit-client is the client for a distributed Blender render farm, based on people giving their computer power for free. The MitM vulnerability would have allowed an attacker to execute code by changing the Blender file to contain dangerous python code. Normally python code is disabled from running, but this value is sent by the server and so the attacker could override this as well. This means that an attacker could execute arbitrary code.
CVE-2020-13955

HttpUtils#getURLConnection method disables explicitly hostname verification for HTTPS connections making clients vulnerable to man-in-the-middle attacks. Calcite uses internally this method to connect with Druid and Splunk so information leakage may happen when using the respective Calcite adapters. The method itself is in a utility class so people may use it to create vulnerable HTTPS connections for other applications. From Apache Calcite 1.26 onwards, the hostname verification will be performed using the default JVM truststore.
CVE-2020-26234

Opencast before version 8.9 and 7.9 disables HTTPS hostname verification of its HTTP client used for a large portion of Opencast's HTTP requests.
CVE-2020-17514

Fineract provides a reliable, robust, and affordable solution for entrepreneurs, financial institutions, and service providers to offer financial services to the world’s 2 billion underbanked and unbanked. Fineract is aimed at innovative mobile and cloud-based solutions, and enables digital transaction accounts for all.

The vulnerable class is used for example here which seems to be used for sending SMS. I'm not 100 % sure (found this issue more than half a year ago...), but I think the SMS was used to send OTP tokens, although I did not really verify the OTP token part.
CVE-2021-21385 (https://github.com/openMF/mifos-mobile/security/advisories/GHSA-9657-33wf-rmvx)

[mifos-mobile is an] (...) Android Application built on top of the MifosX Self-Service platform for end-user customers to view/transact on the accounts and loans they hold.

Note that the fixed code is written in Kotlin; the app has recently been converted to a Kotlin app and the issue has been found in the semantically equivalent Java version.

Report

Hostname verification is an essential part of Transport Layer Security (TLS) and HTTPS.

When a TLS connection is established there are two important steps: First, the chain of trust is verified that means it is checked whether the certificate has been issued by a trusted certificate authority. Second, the hostname (that is being connected to) needs to be verified against the certificate. That means it is checked whether the certificate is actually for the hostname.

If the hostname is not verified an attacker could present any certificate with a valid chain of trust, but that is not issued for the hostname at all. This allows a man-in-the-middle attack!

Many posts tell developers that have problems with hostname verification to accept any certificate as valid in the case of a mismatch. These problems usually are configuration problems that should be fixed instead.

Java verifies HTTPS hostnames by default. But when a protocol uses TLS (SSLEngine) the hostname is not verified by default. That's where the second part of my query (IncorrectHostnameVerifier.ql) comes into play.

[This PR and PR description is WIP]

87 of 642 projects tested have overridden the Hostname.verify method. Query: https://github.com/github/codeql/pull/3581 27 of 642 projects are detected by my currently running query.

[x] Are you planning to discuss this vulnerability submission publicly? (Blog Post, social networks, etc). We would love to have you spread the word about the good work you are doing

nicowaisman commented 4 years ago

Hey @intrigus-lgtm In order for this bounty to be valid, we need at least 3 submission to open source projected properly fixed and with a CVE assigned to it. The vulnerabilities found also required to be associated with a query, as in someone that run the query could have found the vulnerabilities with it.

anticomputer commented 4 years ago

Hi @intrigus-lgtm ... as Nico mentioned above, for this submission to be accepted under the Bug Slayer category it requires multiple CVE (it's actually 4, not 3) to be triaged as a direct result of your query findings as per https://securitylab.github.com/bounties ... for reference, this submission received award under the "All For One" category already.

Do you expect to update this issue with your CVE findings still? If so we'll leave the issue open until we receive your CVE listings.

intrigus-lgtm commented 4 years ago

Still waiting for some confirmations. Might take some time.

intrigus-lgtm commented 4 years ago

Just a heads up that I'm still waiting...

intrigus-lgtm commented 4 years ago

Found another one: [Edit] CVE-2020-13955 has been published.

1 CVE, 1 issue which currently lacks a CVE, so two are missing for the bounty :)

intrigus-lgtm commented 3 years ago

CVE-2020-26234 has just been assigned :tada: I think the advisory will be published soon-ish. https://github.com/opencast/opencast/security/advisories/GHSA-44cw-p2hm-gpf6

kevinbackhouse commented 3 years ago

Hi @intrigus-lgtm. I hope you don't mind, I am going to take this out of our bounty pipeline for now. Please go ahead and resubmit it when you get the extra CVEs.

ghsecuritylab commented 3 years ago

Your submission is now in status Closed.

For information, the evaluation workflow is the following: CodeQL initial assessment > SecLab review > CodeQL review > SecLab finalize > Pay > Closed

intrigus-lgtm commented 3 years ago

CVE-2020-17514 has been assigned, although it still is reserved i.e. not public.

kevinbackhouse commented 3 years ago

Ok, great. Do you have a 4th CVE in the pipeline too, or is it 3 total for the time being?

intrigus-lgtm commented 3 years ago

I have 1 open github security advisory and created 2 issues asking maintainers to open an advisory so I can privately disclose the issues to them. Or do you know a better way for contacting a maintainer?

kevinbackhouse commented 3 years ago

If they don't have contact info in security.md or a README file, then I sometimes try to guess the maintainer's email address by cloning the repo and looking at the email addresses in git log. The git log messages are public information, so I figure they're ok to use for a situation like this, but I always explain where I got their email address from when I contact them.

JarLob commented 3 years ago

I'm going to close the issue as Kevin said. Feel free to re-open it when ready.

intrigus-lgtm commented 3 years ago

[PRODUCT]: Apache Fineract [VERSION]: 0.4.0-incubating, 0.5.0-incubating, 0.6.0-incubating, 1.0.0, 1.1.0, 1.2.0, 1.3.0, 1.4.0

[REFERENCES]:
https://issues.apache.org/jira/browse/FINERACT-1211 [DESCRIPTION]: Apache Fineract disables HTTPS hostname verification in ProcessorHelper in the configureClient method. Under typical deployments, a man in the middle attack could be successful.

Fix-link:https://github.com/apache/fineract/commit/e054a6f0a24ccff367ea6229d03aa90a7b3e4bcc#diff-1d795f6e046aa3b856186409a7330109723169f9eade25374ba76efe23acdec9

@JarLob please reopen :) (I can't reopen this myself)

JarLob commented 3 years ago

Is it the correct reference? The description is "ProcessorHelper error handling can lead to NullPointerException". Was the CVE-2020-17514 requested by Apache or you? Did they change their minds?

intrigus-lgtm commented 3 years ago

The reference is correct. They intentionally used a vague description. Apache requested the CVE and I think the CVE should soon appear on Mitre. Have a look at this: https://cwiki.apache.org/confluence/plugins/servlet/mobile?contentId=74690460#content/view/74690460

ghsecuritylab commented 3 years ago

Your submission is now in status FP Check.

For information, the evaluation workflow is the following: SecLab review > FP Check > CodeQL review > SecLab finalize > Pay > Closed

ghsecuritylab commented 3 years ago

Your submission is now in status CodeQL review.

For information, the evaluation workflow is the following: SecLab review > FP Check > CodeQL review > SecLab finalize > Pay > Closed

ghsecuritylab commented 3 years ago

Your submission is now in status SecLab finalize.

For information, the evaluation workflow is the following: SecLab review > FP Check > CodeQL review > SecLab finalize > Pay > Closed

ghsecuritylab commented 3 years ago

Your submission is now in status Pay.

For information, the evaluation workflow is the following: SecLab review > FP Check > CodeQL review > SecLab finalize > Pay > Closed

intrigus-lgtm commented 3 years ago

Thank you!

xcorail commented 3 years ago

Created Hackerone report 1219493 for bounty 309996 : [108] [Java] CWE-295 - Incorrect Hostname Verification - MitM

ghsecuritylab commented 3 years ago

Your submission is now in status Closed.

For information, the evaluation workflow is the following: SecLab review > FP Check > CodeQL review > SecLab finalize > Pay > Closed

github / securitylab

[Java] CWE-295 - Incorrect Hostname Verification - MitM #108

CVE ID(s)

Report