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

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.

• 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