imágenes falsas
Las organizaciones que utilizan versiones más recientes del marco Java de Oracle se despertaron el miércoles con un aviso inquietante: una vulnerabilidad crítica puede facilitar que los adversarios falsifiquen certificados y firmas TLS, mensajes de autenticación de dos factores y credenciales de autorización generadas por una variedad de códigos abiertos ampliamente utilizados. estándares
La vulnerabilidad, que Oracle parchó el martes, afecta la implementación de la empresa del algoritmo de firma digital de curva elíptica en las versiones de Java 15 y superiores. ECDSA es un algoritmo que utiliza los principios de la criptografía de curva elíptica para autenticar mensajes digitalmente. Una ventaja clave de ECDSA es el tamaño más pequeño de las claves que genera, en comparación con RSA u otros algoritmos criptográficos, lo que lo hace ideal para su uso en estándares que incluyen 2FA basado en FIDO, el 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 identidad 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 que vea.
“Resulta que algunas versiones recientes de Java eran vulnerables a un tipo de truco similar, en la implementación de firmas ECDSA ampliamente utilizadas”, escribió Madden. “Si está ejecutando una de las versiones vulnerables, un atacante puede falsificar fácilmente algunos tipos de certificados SSL y protocolos de enlace (lo que permite la intercepción y modificación de las comunicaciones), JWT firmados, aserciones SAML o tokens de identificación OIDC, e incluso mensajes de autenticación WebAuthn. Todo usando el equivalente digital de una hoja de papel en blanco”.
Él continuó:
“Es difícil exagerar la gravedad de este error. Si utiliza firmas ECDSA para cualquiera de estos mecanismos de seguridad, un atacante puede pasarlos por alto de forma trivial y completa si su servidor está ejecutando cualquier versión de Java 15, 16, 17 o 18 antes de 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 los 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 en funcionalidad diferente en un contexto de gestión de acceso”. En su forma más sombría, el error podría ser explotado por alguien fuera de una red vulnerable sin ninguna verificación.
Otros expertos en seguridad también tuvieron fuertes reacciones, con uno declarándolo “el error criptográfico del año”.
Bien. Es el error criptográfico del año. Márcalo para abril. Java 15-18 ECDSA no verifica que la coordenada x aleatoria y la prueba de firma sean distintas de cero; una firma (0,0) valida cualquier mensaje. Rompe JWT, SAML, etc. https://t.co/t2WgnS0g3A
— Thomas H. Ptacek (@tqbf) 20 de abril de 2022
Un factor atenuante es que las versiones de Java 15 y superiores no parecen ser tan utilizadas como las versiones anteriores. Los datos recopilados en febrero y marzo de 2021 por la firma de seguridad Snyk mostraron que Java 15, la última versión en ese momento, representó el 12 por ciento de las implementaciones. Si bien Madden dijo que la falla específica de implementación de ECDSA afectó solo a Java 15 y superior, 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 usa para derivar dos números adicionales, R y S. Para verificar que una firma sea válida, una parte debe verificar la ecuación que involucra a R y S, la clave pública del firmante, y un hash criptográfico del mensaje. Cuando 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. Seleccione un entero aleatorio criptográficamente sólido K entre 1 y N-1 inclusive.
S2. Calcule R a partir de K usando la multiplicación de curva elíptica.
S3. En el improbable caso de que R sea cero, vuelva al paso 1 y comience de nuevo.
S4. Calcule S a partir de K, R, el hash que se 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 pueden ser cero. Esto se debe a que 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 se traduce en 0 = 0 X (otros valores de la clave privada y el hash), que será cierto independientemente de los valores adicionales. Eso significa que un adversario solo necesita enviar una firma en blanco para pasar la verificación con éxito.
madden escribió:
¿Adivina qué cheque olvidó Java?
Así es. La implementación de Java de la verificación de firma ECDSA no verificó si R o S eran cero, por lo que podría producir un valor de firma en el que ambos son 0 (codificado correctamente) y Java lo aceptaría como una firma válida para cualquier mensaje y para cualquier público llave. El equivalente digital de una tarjeta de identificación en blanco.
A continuación se muestra una sesión interactiva de JShell que Madden creó y que muestra una implementación vulnerable que acepta una firma en blanco 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
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 afectadas de Java para validar las firmas deben otorgar una alta prioridad a la aplicación de parches. También será importante monitorear los avisos de los fabricantes de aplicaciones y productos para ver si alguno de sus productos se vuelve vulnerable. Si bien la amenaza de CVE-2022-21449 parece estar limitada a las nuevas versiones de Java, su gravedad es lo suficientemente alta como para justificar la vigilancia.