CVE-2020-15134

{"id": "CVE-2020-15134", "metrics": {"cvssMetricV2": [{"type": "Primary", "source": "nvd@nist.gov", "cvssData": {"version": "2.0", "baseScore": 6.4, "accessVector": "NETWORK", "vectorString": "AV:N/AC:L/Au:N/C:P/I:P/A:N", "authentication": "NONE", "integrityImpact": "PARTIAL", "accessComplexity": "LOW", "availabilityImpact": "NONE", "confidentialityImpact": "PARTIAL"}, "acInsufInfo": true, "impactScore": 4.9, "baseSeverity": "MEDIUM", "obtainAllPrivilege": false, "exploitabilityScore": 10.0, "obtainUserPrivilege": false, "obtainOtherPrivilege": false, "userInteractionRequired": false}], "cvssMetricV31": [{"type": "Secondary", "source": "security-advisories@github.com", "cvssData": {"scope": "CHANGED", "version": "3.1", "baseScore": 8.0, "attackVector": "NETWORK", "baseSeverity": "HIGH", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:N", "integrityImpact": "HIGH", "userInteraction": "REQUIRED", "attackComplexity": "HIGH", "availabilityImpact": "NONE", "privilegesRequired": "NONE", "confidentialityImpact": "HIGH"}, "impactScore": 5.8, "exploitabilityScore": 1.6}, {"type": "Primary", "source": "nvd@nist.gov", "cvssData": {"scope": "CHANGED", "version": "3.1", "baseScore": 8.7, "attackVector": "NETWORK", "baseSeverity": "HIGH", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:N", "integrityImpact": "HIGH", "userInteraction": "NONE", "attackComplexity": "HIGH", "availabilityImpact": "NONE", "privilegesRequired": "NONE", "confidentialityImpact": "HIGH"}, "impactScore": 5.8, "exploitabilityScore": 2.2}]}, "published": "2020-07-31T18:15:14.617", "references": [{"url": "https://blog.jcoglan.com/2020/07/31/missing-tls-verification-in-faye/", "tags": ["Exploit", "Third Party Advisory"], "source": "security-advisories@github.com"}, {"url": "https://github.com/faye/faye/security/advisories/GHSA-3q49-h8f9-9fr9", "tags": ["Exploit", "Third Party Advisory"], "source": "security-advisories@github.com"}, {"url": "https://blog.jcoglan.com/2020/07/31/missing-tls-verification-in-faye/", "tags": ["Exploit", "Third Party Advisory"], "source": "af854a3a-2127-422b-91ae-364da2661108"}, {"url": "https://github.com/faye/faye/security/advisories/GHSA-3q49-h8f9-9fr9", "tags": ["Exploit", "Third Party Advisory"], "source": "af854a3a-2127-422b-91ae-364da2661108"}], "vulnStatus": "Modified", "weaknesses": [{"type": "Secondary", "source": "security-advisories@github.com", "description": [{"lang": "en", "value": "CWE-295"}]}, {"type": "Primary", "source": "nvd@nist.gov", "description": [{"lang": "en", "value": "CWE-295"}]}], "descriptions": [{"lang": "en", "value": "Faye before version 1.4.0, there is a lack of certification validation in TLS handshakes. Faye uses em-http-request and faye-websocket in the Ruby version of its client. Those libraries both use the `EM::Connection#start_tls` method in EventMachine to implement the TLS handshake whenever a `wss:` URL is used for the connection. This method does not implement certificate verification by default, meaning that it does not check that the server presents a valid and trusted TLS certificate for the expected hostname. That means that any `https:` or `wss:` connection made using these libraries is vulnerable to a man-in-the-middle attack, since it does not confirm the identity of the server it is connected to. The first request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket. Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both libraries to support TLS verification before Faye could claim to do the same. Your client would still be insecure if its initial HTTPS request was verified, but later WebSocket connections were not. This is fixed in Faye v1.4.0, which enables verification by default. For further background information on this issue, please see the referenced GitHub Advisory."}, {"lang": "es", "value": "Faye versiones anteriores a 1.4.0, se presenta una falta de comprobaci\u00f3n de certificaci\u00f3n en los protocolos de enlace TLS. Faye usa em-http-request y faye-websocket en la versi\u00f3n de Ruby de su cliente. Ambas bibliotecas usan el m\u00e9todo \"EM::Connection#start_tls\" en EventMachine para implementar el protocolo de enlace TLS cada vez que una URL \"wss:\" es usada para la conexi\u00f3n. Este m\u00e9todo no implementa la verificaci\u00f3n de certificados por defecto, lo que significa que no comprueba que el servidor presenta un certificado TLS v\u00e1lido y confiable para el nombre de host esperado. Eso significa que cualquier conexi\u00f3n \"https:\" o \"wss:\" realizada con estas bibliotecas es vulnerable a un ataque de tipo man-in-the-middle, ya que no confirma la identidad del servidor al que est\u00e1 conectado. La primera petici\u00f3n que hace un cliente de Faye es enviada siempre por medio de HTTP normal, pero los mensajes posteriores pueden ser enviados por medio de WebSocket. Por lo tanto, es vulnerable al mismo problema que estas bibliotecas subyacentes, y necesit\u00e1bamos ambas bibliotecas para admitir la verificaci\u00f3n TLS antes de que Faye pudiera afirmar que hac\u00eda lo mismo. Su cliente todav\u00eda estar\u00eda no seguro si se verificara su petici\u00f3n HTTPS inicial, pero las conexiones WebSocket posteriores no. Esto es corregido en Faye versi\u00f3n v1.4.0, que permite la verificaci\u00f3n por defecto. Para obtener m\u00e1s informaci\u00f3n de fondo sobre este tema, consulte el Aviso de GitHub referenciado"}], "lastModified": "2024-11-21T05:04:54.997", "configurations": [{"nodes": [{"negate": false, "cpeMatch": [{"criteria": "cpe:2.3:a:faye_project:faye:*:*:*:*:*:*:*:*", "vulnerable": true, "matchCriteriaId": "2ABAABF2-4BED-4A50-BC87-A43978ECAF2B", "versionEndExcluding": "1.4.0"}], "operator": "OR"}]}], "sourceIdentifier": "security-advisories@github.com"}