Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
1 task done
intrigus-lgtm opened this issue May 27, 2020 · 23 comments
Closed
1 task done

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

intrigus-lgtm opened this issue May 27, 2020 · 23 comments
Labels
The Bug Slayer Submissions to The Bug Slayer bounty

Comments

@intrigus-lgtm
Copy link
Contributor

intrigus-lgtm commented May 27, 2020 •
edited
Loading

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 (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: github/codeql#3581
27 of 642 projects are detected by my currently running query.

  • 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
@intrigus-lgtm intrigus-lgtm added the The Bug Slayer Submissions to The Bug Slayer bounty label May 27, 2020
@nicowaisman
Copy link

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
Copy link
Contributor

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
Copy link
Contributor Author

Still waiting for some confirmations.
Might take some time.

@intrigus-lgtm
Copy link
Contributor Author

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

@intrigus-lgtm
Copy link
Contributor Author

intrigus-lgtm commented Sep 27, 2020 •
edited
Loading

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
Copy link
Contributor Author

CVE-2020-26234 has just been assigned 🎉
I think the advisory will be published soon-ish.
GHSA-44cw-p2hm-gpf6

@kevinbackhouse
Copy link
Contributor

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.

@kevinbackhouse kevinbackhouse removed the The Bug Slayer Submissions to The Bug Slayer bounty label Jan 14, 2021
@ghsecuritylab
Copy link
Collaborator

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
Copy link
Contributor Author

intrigus-lgtm commented Jan 14, 2021 •
edited
Loading

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

@kevinbackhouse
Copy link
Contributor

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

@intrigus-lgtm
Copy link
Contributor Author

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
Copy link
Contributor

kevinbackhouse commented Jan 15, 2021 •
edited
Loading

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.

This was referenced Mar 1, 2021
Closed
Closed
@JarLob
Copy link
Contributor

JarLob commented Mar 2, 2021

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

@JarLob JarLob closed this as completed Mar 2, 2021
@JarLob JarLob added the The Bug Slayer Submissions to The Bug Slayer bounty label Mar 2, 2021
@intrigus-lgtm
Copy link
Contributor Author

[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
[PROBLEMTYPE]: Critical
[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:apache/fineract@e054a6f#diff-1d795f6e046aa3b856186409a7330109723169f9eade25374ba76efe23acdec9

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

@JarLob
Copy link
Contributor

JarLob commented May 27, 2021

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
Copy link
Contributor Author

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

@JarLob JarLob reopened this May 27, 2021
@ghsecuritylab
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Collaborator

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
Copy link
Contributor Author

Thank you!

@xcorail
Copy link
Contributor

xcorail commented Jun 7, 2021

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

@xcorail xcorail closed this as completed Jun 7, 2021
@ghsecuritylab
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
The Bug Slayer Submissions to The Bug Slayer bounty
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@kevinbackhouse @xcorail @anticomputer @nicowaisman @JarLob @intrigus-lgtm @ghsecuritylab