Existe una vulnerabilidad de día cero en Java, considerada crítica, que 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.

Toda clase de implementaciones Java podrían verse comprometidas si esta falla es explotada, incluyendo campos como las comunicaciones cifradas, tokens de autenticación, actualizaciones de código y otros. Oracle corrigió el error, identificado como CVE-2022-21449, en su parche de seguridad trimestral.

Recursos afectados:

• Oracle Java SE: 17.0.2 y 18;
• Oracle GraalVM Enterprise Edition: 21.3.1 y 22.0.0.2.

Descripción:

La vulnerabilidad CVE-2022-21449 es fácilmente explotable, y permite que un atacante no autenticado con acceso a la red a través de múltiples protocolos comprometa Oracle Java SE y Oracle GraalVM Enterprise Edition. Los ataques exitosos de esta vulnerabilidad pueden resultar en la creación, eliminación o modificación no autorizada del acceso a datos críticos o a todos los datos accesibles de Oracle Java SE, Oracle GraalVM Enterprise Edition. Esta vulnerabilidad se aplica a las implementaciones de Java, normalmente en clientes que ejecutan aplicaciones Java Web Start en zona de pruebas o subprogramas de Java en zona de pruebas, que cargan y ejecutan código que no es de confianza (por ejemplo, código que proviene de Internet) y dependen de la zona de pruebas de Java para la seguridad. Esta vulnerabilidad también se puede explotar mediante el uso de API en el Componente especificado, por ejemplo, a través de un servicio web que proporciona datos a las API.

Al respecto, el investigador Thomas Ptacek considera este reporte como el “error criptográfico del año”, dadas sus condiciones de explotación y problemas derivados del ataque. Según reportes, esta vulnerabilidad surgió cuando parte del código de verificación de formas en Java 15 se reescribió de C++ a Java, incluyendo el código de verificación ECDSA.

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.

Las firmas ECDSA se componen de un par de números, denominados r y s. Para verificar una firma, el código realiza algunos cálculos que involucran un hash de los datos, la clave pública de cualquier organización o persona que haya usado su firma digital y los números r y s; un lado de la ecuación usa r, el otro r y s.

Ambos lados de este cálculo deben ser iguales para que la firma sea verificada adecuadamente; eso implica que los datos fueron firmados digitalmente por la clave privada del firmante. Si la verificación de la firma falla, eso probablemente significa que quien firmó los datos no es quien dice ser, por lo que los datos no deberían ser verificados.

En teoría, para que una firma sea válida, el valor de r y s no puede ser 0, 0, ya que en el proceso se multiplican estos números con otros valores. El error surgió porque, si bien el código C++ original verificaba que tanto r como s no fueran cero, el nuevo código Java no verificó esta condición. Como seguramente sabrá, cualquier cantidad multiplicada por cero es igual a cero. Cuando s tiene que dividir un valor entre 0, se desencadena la falla de verificación.

Recomendaciones:

La falla ya ha sido corregida por Oracle, por lo que se recomienda actualizar de inmediato. Ver Oracle Critical Patch Update Advisory - April 2022 (https://www.oracle.com/security-alerts/cpuapr2022.html)

Referencias:

• https://noticiasseguridad.com/hacking-incidentes/vulnerabilidad-critica-en-java-permite-falsificar-certificados-firmas-mensajes-webauthn-y-evadir-mecanismos-de-autenticacion-actualice-de-inmediato/
• https://www.oracle.com/security-alerts/cpuapr2022.html#AppendixJAVA
• https://neilmadden.blog/2022/04/19/psychic-signatures-in-java/