René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"[Java] CWE-295 - Incorrect Hostname Verification - MitM","articleBody":"## CVE ID(s)\r\n\r\n*List the CVE ID(s) associated with this vulnerability. GitHub will automatically link CVE IDs to the [GitHub Advisory Database](https://github.com/advisories).*\r\n\r\n- CVEs pending\r\n- No CVE for this one:\r\nhttps://github.com/laurent-clouet/sheepit-client/pull/240/files\r\nThis instance would not have been found by this query.\r\nThat is not a fault of the query, but `sheepit-client` uses [Lombok](https://projectlombok.org/) which seems to not work well with LGTM.\r\n[This \"hack\"](http://anthonywhitford.com/lombok.maven/lombok-maven-plugin/faq.html#alt-src-setup) should fix it.\r\n`sheepit-client` is the client for a distributed Blender render farm, based on people giving their computer power for free.\r\nThe MitM vulnerability would have allowed an attacker to **execute code** by changing the Blender file to contain dangerous python code.\r\nNormally python code is disabled from running, but this value is sent by the server and so the attacker could override this as well.\r\nThis means that **an attacker could execute arbitrary code**.\r\n- [CVE-2020-13955](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-13955)\r\n  \u003e 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. \r\n- CVE-2020-26234\r\n  \u003e 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.\r\n- CVE-2020-17514\r\n  \u003e 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. \r\n\r\n  The vulnerable class is used for example [here](https://lgtm.com/projects/g/apache/fineract/snapshot/a28948c8c98837a5fc580fbbc489322aafdc3d2b/files/fineract-provider/src/main/java/org/apache/fineract/infrastructure/hooks/processor/TwilioHookProcessor.java?sort=name\u0026dir=ASC\u0026mode=heatmap#L79) which seems to be used for sending SMS.\r\nI'm not 100 % sure (found this issue more than half a year ago...), but I think the SMS was used to send [OTP tokens](https://github.com/apache/fineract/blob/cf7d38adbcf0bc197fec2a43cd32a69ade81e44f/fineract-provider/src/main/java/org/apache/fineract/infrastructure/security/service/TwoFactorServiceImpl.java#L104), although I did not really verify the OTP token part.\r\n- CVE-2021-21385 (https://github.com/openMF/mifos-mobile/security/advisories/GHSA-9657-33wf-rmvx)\r\n  \u003e [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.\r\n\r\n  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.\r\n\r\n\r\n## Report\r\n\r\nHostname verification is an essential part of Transport Layer Security (TLS) and HTTPS.\r\n\r\nWhen a TLS connection is established there are two important steps:\r\nFirst, the chain of trust is verified that means it is checked whether the certificate has been issued by a trusted certificate authority.\r\nSecond, the hostname (that is being connected to) needs to be verified against the certificate.\r\nThat means it is checked whether the certificate is actually for the hostname.\r\n\r\nIf 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.\r\n**This allows  a man-in-the-middle attack!**\r\n\r\nMany posts tell developers that have problems with hostname verification to accept any certificate as valid in the case of a mismatch.\r\nThese problems usually are configuration problems that should be fixed instead.\r\n\r\nJava verifies HTTPS hostnames by default.\r\nBut when a protocol uses TLS (SSLEngine) the hostname is not verified by default.\r\nThat's where the second part of my query (IncorrectHostnameVerifier.ql) comes into play.\r\n\r\n[This PR and PR description is WIP]\r\n\r\n87 of 642 projects tested have *overridden* the `Hostname.verify` method. \r\nQuery: https://github.com/github/codeql/pull/3581\r\n27 of 642 projects are detected by my currently running query.\r\n\r\n- [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*\r\n","author":{"url":"https://github.com/intrigus-lgtm","@type":"Person","name":"intrigus-lgtm"},"datePublished":"2020-05-27T21:15:51.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":23},"url":"https://github.com/108/securitylab/issues/108"}