Importante falla criptográfica en Java permite la falsificación de 'documentos psíquicos'

imágenes falsas

Las organizaciones que utilizan versiones más nuevas del marco Java de Oracle se enfrentaron a un consejo preocupante el miércoles: una vulnerabilidad crítica podría facilitar a los atacantes falsificar certificados y firmas TLS, mensajes de autenticación de dos factores y credenciales de autorización creadas por una serie de códigos abiertos ampliamente utilizados. estándares

La vulnerabilidad, parcheada por Oracle el martes, afecta la implementación de la empresa del algoritmo de firma digital Elliptic Curve en las versiones de Java 15 y posteriores. ECDSA es un algoritmo que utiliza los principios de la criptografía de curva elíptica para autenticar digitalmente los mensajes. Un beneficio clave de ECDSA es el tamaño más pequeño de las claves generadas en comparación con RSA u otros algoritmos criptográficos, lo que lo hace ideal para su uso en estándares como 2FA basado en FIDO, lenguaje de marcado de aserción de seguridad, OpenID y JSON.

Médico que y el papel psíquico

Neil Madden, el investigador de la firma de seguridad ForgeRock que descubrió la vulnerabilidad, la comparó con las tarjetas de identificación en blanco que aparecen regularmente en el programa de ciencia ficción. Médico que. El papel psíquico del que están hechas las cartas hace que la persona que las mira vea lo que el protagonista quiere ver.

«Resultó que algunas versiones recientes de Java eran vulnerables a un truco similar al implementar firmas ECDSA ampliamente utilizadas», escribió Madden. «Si está ejecutando una de las versiones vulnerables, un atacante podría falsificar fácilmente algunos tipos de certificados SSL y protocolos de enlace (permitiendo la intercepción y alteración de las comunicaciones), JWT firmados, afirmaciones SAML o tokens de ID de OIDC, e incluso mensajes de autenticación WebAuthn. Todo con el equivalente digital de una hoja de papel en blanco”.

Él continuó:

“Es difícil sobrestimar la gravedad de este error. Si usa firmas ECDSA para cualquiera de estos mecanismos de seguridad, un atacante podría hacerlo pasarlos por alto de forma trivial y completa si su servidor ejecuta una versión de Java 15, 16, 17 o 18 anterior a la Actualización de parche crítico (CPU) de abril de 2022. Por contexto, casi todos los dispositivos WebAuthn/FIDO en el mundo real (incluidos Yubikeys) usan firmas ECDSA y muchos proveedores de OIDC usan JWT firmados por ECDSA”.

El error rastreado como CVE-2022-21449 tiene una calificación de gravedad de 7.5 de 10 posibles, pero Madden dijo que, según su evaluación, calificaría la gravedad en un «10 perfecto» debido a la amplia gama de impactos y diferentes funcionalidades asociadas. con la gestión de acceso.” En su peor forma, la falla podría ser explotada por alguien fuera de una red vulnerable sin ninguna verificación.

Otros expertos en seguridad también reaccionaron con violencia, con uno para explicarlo «Error criptográfico del año».

Un factor atenuante es que las versiones de Java 15 y superiores no parecen ser tan utilizadas como las versiones anteriores. Los datos recopilados por la firma de seguridad Snyk en febrero y marzo de 2021 mostraron que Java 15, la última versión en ese momento, representó el 12 por ciento de las implementaciones. Si bien Madden dijo que el error específico de implementación de ECDSA solo afectó a Java 15 y versiones posteriores, Oracle también enumeró las versiones 7, 8 y 11 como vulnerables. Madden dijo que la discrepancia puede deberse a errores criptográficos separados corregidos en versiones anteriores.

a/0 = firma válida

Las firmas ECDSA se basan en un número pseudoaleatorio, normalmente anotado como K, que se utiliza para derivar dos números adicionales, R y S. Para verificar que una firma sea válida, una de las partes debe verificar la ecuación usando R y S, la clave pública del firmante. y un hash criptográfico del mensaje. Si ambos lados de la ecuación son iguales, la firma es válida.

En un artículo publicado el miércoles, la empresa de seguridad Sophos explicó con más detalle el proceso:

S1. Elija un número aleatorio criptográficamente sólido K entre 1 y N-1 inclusive.
S2. Calcule R a partir de K mediante la multiplicación de curvas elípticas.
S3. En el improbable caso de que R sea cero, vuelva al paso 1 y comience de nuevo.
S4. Calcula S a partir de K, R, el hash a firmar y la clave privada.
S5. En el improbable caso de que S sea cero, vuelva al paso 1 y comience de nuevo.

Para que el proceso funcione correctamente, ni R ni S deben ser nunca un cero. Eso es porque un lado de la ecuación es R y el otro se multiplica por R y un valor de S. Si ambos valores son 0, la comprobación de verificación devuelve 0 = 0 X (otros valores de clave privada y hash), lo cual es cierto independientemente de los valores adicionales. Esto significa que un atacante solo necesita proporcionar una firma vacía para pasar con éxito la verificación de verificación.

madden escribió:

¿Adivina qué examen olvidó Java?

Es correcto. La implementación de Java de la verificación de firma ECDSA no verificó si R o S son nulos, por lo que podría producir un valor de firma donde ambos son 0 (codificados adecuadamente) y Java lo usaría como una firma válida para cualquier mensaje y para cualquier clave de aceptación pública . El equivalente digital de una tarjeta de identificación en blanco.

A continuación se muestra una sesión JShell interactiva creada por Madden que muestra una implementación vulnerable que acepta una firma vacía como válida al verificar un mensaje y una clave pública:



|  Welcome to JShell -- Version 17.0.1
|  For an introduction type: /help intro
jshell> import java.security.*

jshell> var keys = KeyPairGenerator.getInstance("EC").generateKeyPair()


keys ==> java.security.KeyPair@626b2d4a
jshell> var blankSignature = new byte[64] 



blankSignature ==> byte[64] 
 { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, ... , 0, 0, 0, 0, 0, 0, 0, 0 }
jshell>var sig = Signature.getInstance("SHA256WithECDSAInP1363Format")


sig ==> Signature object: SHA256WithECDSAInP1363Format<not initialized>
jshell> sig.initVerify(keys.getPublic())

jshell> sig.update("Hello, World".getBytes())

jshell> sig.verify(blankSignature)


$8 ==> true
// Oops, that shouldn't have verified...

Las organizaciones que utilizan cualquiera de las versiones de Java afectadas para validar firmas deben priorizar la aplicación de parches. También será importante prestar atención a los clientes potenciales de los fabricantes de aplicaciones y productos para ver si alguno de sus productos se está volviendo vulnerable. Aunque la amenaza CVE-2022-21449 parece estar limitada a las nuevas versiones de Java, su gravedad es lo suficientemente alta como para justificar la vigilancia.



DEJA UNA RESPUESTA

Por favor ingrese su comentario!
Por favor ingrese su nombre aquí

6 + 10 =