CVE-2024-54150

{"id": "CVE-2024-54150", "cveTags": [], "metrics": {"cvssMetricV31": [{"type": "Secondary", "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "cvssData": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 9.1, "attackVector": "NETWORK", "baseSeverity": "CRITICAL", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N", "integrityImpact": "HIGH", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "NONE", "privilegesRequired": "NONE", "confidentialityImpact": "HIGH"}, "impactScore": 5.2, "exploitabilityScore": 3.9}], "cvssMetricV40": [{"type": "Secondary", "source": "security-advisories@github.com", "cvssData": {"safety": "NOT_DEFINED", "version": "4.0", "recovery": "NOT_DEFINED", "baseScore": 8.7, "automatable": "NOT_DEFINED", "attackVector": "NETWORK", "baseSeverity": "HIGH", "valueDensity": "NOT_DEFINED", "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X", "exploitMaturity": "NOT_DEFINED", "providerUrgency": "NOT_DEFINED", "userInteraction": "NONE", "attackComplexity": "LOW", "attackRequirements": "NONE", "privilegesRequired": "NONE", "modifiedAttackVector": "NOT_DEFINED", "integrityRequirements": "NOT_DEFINED", "modifiedUserInteraction": "NOT_DEFINED", "availabilityRequirements": "NOT_DEFINED", "modifiedAttackComplexity": "NOT_DEFINED", "subsequentSystemIntegrity": "NONE", "vulnerableSystemIntegrity": "HIGH", "modifiedAttackRequirements": "NOT_DEFINED", "modifiedPrivilegesRequired": "NOT_DEFINED", "confidentialityRequirements": "NOT_DEFINED", "vulnerabilityResponseEffort": "NOT_DEFINED", "subsequentSystemAvailability": "NONE", "vulnerableSystemAvailability": "NONE", "subsequentSystemConfidentiality": "NONE", "vulnerableSystemConfidentiality": "NONE", "modifiedSubsequentSystemIntegrity": "NOT_DEFINED", "modifiedVulnerableSystemIntegrity": "NOT_DEFINED", "modifiedSubsequentSystemAvailability": "NOT_DEFINED", "modifiedVulnerableSystemAvailability": "NOT_DEFINED", "modifiedSubsequentSystemConfidentiality": "NOT_DEFINED", "modifiedVulnerableSystemConfidentiality": "NOT_DEFINED"}}]}, "published": "2024-12-19T19:15:07.747", "references": [{"url": "https://github.com/xmidt-org/cjwt/commit/096ab3e37f73c914b716e7259589179f363265fd", "source": "security-advisories@github.com"}, {"url": "https://github.com/xmidt-org/cjwt/security/advisories/GHSA-9h24-7qp5-gp82", "source": "security-advisories@github.com"}], "vulnStatus": "Received", "weaknesses": [{"type": "Secondary", "source": "security-advisories@github.com", "description": [{"lang": "en", "value": "CWE-347"}]}], "descriptions": [{"lang": "en", "value": "cjwt is a C JSON Web Token (JWT) Implementation. Algorithm confusion occurs when a system improperly verifies the type of signature used, allowing attackers to exploit the lack of distinction between signing methods. If the system doesn't differentiate between an HMAC signed token and an RS/EC/PS signed token during verification, it becomes vulnerable to this kind of attack. For instance, an attacker could craft a token with the alg field set to \"HS256\" while the server expects an asymmetric algorithm like \"RS256\". The server might mistakenly use the wrong verification method, such as using a public key as the HMAC secret, leading to unauthorised access. For RSA, the key can be computed from a few signatures. For Elliptic Curve (EC), two potential keys can be recovered from one signature. This can be used to bypass the signature mechanism if an application relies on asymmetrically signed tokens. This issue has been addressed in version 2.3.0 and all users are advised to upgrade. There are no known workarounds for this vulnerability."}, {"lang": "es", "value": "cjwt es una implementaci\u00f3n de token web JSON (JWT) en C. La confusi\u00f3n de algoritmos ocurre cuando un sistema verifica incorrectamente el tipo de firma utilizada, lo que permite a los atacantes explotar la falta de distinci\u00f3n entre los m\u00e9todos de firma. Si el sistema no diferencia entre un token firmado HMAC y un token firmado RS/EC/PS durante la verificaci\u00f3n, se vuelve vulnerable a este tipo de ataque. Por ejemplo, un atacante podr\u00eda crear un token con el campo alg establecido en \"HS256\" mientras que el servidor espera un algoritmo asim\u00e9trico como \"RS256\". El servidor podr\u00eda usar por error el m\u00e9todo de verificaci\u00f3n incorrecto, como usar una clave p\u00fablica como secreto HMAC, lo que lleva a un acceso no autorizado. Para RSA, la clave se puede calcular a partir de algunas firmas. Para Elliptic Curve (EC), se pueden recuperar dos claves potenciales de una firma. Esto se puede utilizar para eludir el mecanismo de firma si una aplicaci\u00f3n depende de tokens firmados asim\u00e9tricamente. Este problema se ha solucionado en la versi\u00f3n 2.3.0 y se recomienda a todos los usuarios que actualicen. No se conocen workarounds para esta vulnerabilidad."}], "lastModified": "2024-12-20T18:15:29.847", "sourceIdentifier": "security-advisories@github.com"}