La popular biblioteca de seguridad cloud JWT parchea una vulnerabilidad de ejecución remota de código

JWT es la abreviatura de JSON Web Token, donde JSON es la abreviatura de JavaScript Object Notation.

JSON es una forma  de representar datos estructurados. Su formato se parece un poco al XML y a menudo puede utilizarse en su lugar, pero sin todos los corchetes angulares de apertura y cierre que dificultan la legibilidad.

Por ejemplo, los datos que podrían registrarse así en XML:

<?xml version="1.0" encoding="UTF-8"?>
<data>
   <name>Duck</name>
   <job>
      <employer>Sophos</employer>
      <role>NakSec</role>
   </job>
</data>

En JSON sería:

{"name":"Duck","job":{"employer":"Sophos","role":"NakSec"}}

Si JSON es realmente más fácil de leer que XML es una cuestión abierta, pero la gran idea de JSON es que, como los datos están codificados como código fuente JavaScript legal, aunque sin ningún código directa o indirectamente ejecutable en ellos, puedes analizarlos y procesarlos utilizando tu motor JavaScript existente, así:

La cadena de salida “undefined” anterior refleja simplemente el hecho de que console.log() es un procedimiento, una función que realiza algún trabajo pero no devuelve un valor. La palabra Sophos se imprime como efecto secundario de la llamada a la función, mientras que “undefined” denota lo que la función calculó y devolvió: nada.

La popularidad de JavaScript para la programación tanto en navegador como en servidor, más la familiaridad visual de JSON para los programadores de JavaScript, significa que JSON se utiliza mucho hoy en día, especialmente cuando se intercambian datos estructurados entre clientes y servidores web.

Y un uso popular de JSON es el sistema JWT, que no se lee (oficialmente, en todo caso) en voz alta como juh-witt, como se escribe, sino que se pronuncia peculiarmente jot, una palabra inglesa que a veces se utiliza para referirse al puntito que escribimos encima de una i o una j, y que se refiere a un detalle minúsculo pero potencialmente importante.

Autentícate y obtén un token temporal

En términos generales, un JWT es un bloque de datos codificados que muchos servidores en la nube utilizan como token de acceso a un servicio.

La idea es que empieces por demostrar tu identidad al servicio, por ejemplo, proporcionando un nombre de usuario, una contraseña y un código 2FA, y obtengas de vuelta un JWT.

El JWT que te devuelven es un blob de datos codificados en base64 (en realidad, codificados en URL64) que incluye tres campos:

• Qué algoritmo criptográfico se utilizó para construir el JWT.
• Qué tipo de acceso concede el JWT y durante cuánto tiempo.
• Un hash criptográfico de los dos primeros campos utilizando una clave secreta que solo conoce tu proveedor de servicios.

Una vez que te hayas autenticado, puedes hacer solicitudes posteriores al servicio en línea, por ejemplo para comprobar el precio de un producto o buscar una dirección de correo electrónico en una base de datos, simplemente incluyendo el JWT en cada solicitud, utilizándolo como una especie de tarjeta de acceso temporal.

Evidentemente, si alguien roba tu JWT, puede utilizarlo en el servidor correspondiente, que normalmente le dará acceso en tu lugar. Pero los JWT no necesitan guardarse en disco, suelen tener una vida útil limitada y se envían y reciben a través de conexiones HTTPS, de modo que (al menos en teoría) no pueden ser robados fácilmente.

Cuando los JWT caducan, o si el servidor los cancela por motivos de seguridad, tienes que volver a pasar por todo el proceso de autenticación para restablecer tu derecho a acceder al servicio.

Pero mientras sean válidos, los JWT mejoran el rendimiento porque evitan la necesidad de volver a autenticarte completamente para cada solicitud en línea que quieras hacer, algo parecido a las cookies de sesión que se establecen en tu navegador mientras estás conectado a una red social o a un sitio de noticias.

La validación de seguridad como infiltración

Pues bien, investigadores de Palo Alto han descubierto una vulnerabilidad que han descrito como un “fallo grave” o un “fallo de seguridad crítico” en una popular implementación de JWT.

En teoría, al menos, este fallo podría ser aprovechado por los ciberdelincuentes para ataques que van desde implantar archivos no autorizados en un servidor JWT, modificando así maliciosamente su configuración o modificando el código que podría utilizar posteriormente, hasta la ejecución directa e inmediata de código dentro de la red de una víctima.

En pocas palabras, el acto de presentar un JWT a un servidor back-end para su validación, algo que suele ocurrir en cada llamada a la API (jerga para hacer una solicitud de servicio), podría conducir a la implantación de malware.

Pero aquí está la buena noticia:

• El fallo no es intrínseco al protocolo JWT. Se aplica a una implementación específica de JWT llamada jsonwebtoken de un grupo llamado Auth0.
• El fallo fue parcheado hace tres semanas. Si has actualizado tu versión de jsonwebtoken de la 8.5.1 o anterior a la versión 9.0.0, que salió el 2022-12-21, ya estás protegido contra esta vulnerabilidad concreta.
• Los ciberdelincuentes no pueden explotar directamente el fallo simplemente iniciando sesión y realizando llamadas a la API. Por lo que podemos ver, aunque un atacante podría desencadenar posteriormente la vulnerabilidad haciendo peticiones remotas a la API, primero hay que “cebar” el fallo escribiendo deliberadamente una clave secreta trampa en el almacén de claves de tu servidor de autenticación.

Según los investigadores, el fallo existía en la parte del código de Auth0 que validaba los JWT entrantes con la clave secreta almacenada centralmente para ese usuario.

Como ya se ha dicho, el JWT consta de dos campos de datos que indican tus privilegios de acceso, y un tercer campo formado por los dos primeros campos con una clave secreta que solo conoce el servicio al que llamas.

Para validar el token, el servidor necesita volver a calcular el hash con clave de esos dos primeros campos JWT, y confirmar que el hash que has presentado coincide con el hash que acaba de calcular.

Dado que no conoces la clave secreta, pero puedes presentar un hash que se calculó recientemente utilizando esa clave, el servidor puede deducir que debes haber obtenido el hash del servidor de autenticación en primer lugar, demostrando tu identidad por adelantado.

Confusión de tipos de datos

Resulta que el código de validación del hash en jsonwebtoken asume (o, hasta hace poco, asumía) que la clave secreta de tu cuenta en el almacén de claves de autenticación del propio servidor era realmente una clave secreta criptográfica, codificada en un formato estándar basado en texto como PEM (abreviatura de privacy enhanced mail, pero que actualmente se utiliza principalmente para fines distintos del correo electrónico).

Si pudieras corromper de algún modo la clave secreta de un usuario sustituyéndola por datos que no estuvieran en formato PEM, sino que fueran, de hecho, algún otro tipo de objeto de datos JavaScript más complejo, entonces podrías poner una trampa al cálculo de validación hash basado en la clave secreta, engañando al servidor de autenticación para que ejecute algún código JavaScript de tu elección a partir de esa “clave falsa” infiltrada.

En pocas palabras, el servidor intentaría descodificar una clave secreta que supusiera que estaba en un formato que podía manejar con seguridad, aunque la clave no estuviera en un formato seguro y el servidor no pudiera manejarla con seguridad.

Ten en cuenta, sin embargo, que sería prácticamente necesario piratear primero la base de datos del almacén de claves secretas, antes de que fuera posible cualquier tipo de ejecución de código realmente remoto.

Y si los atacantes ya son capaces de merodear por tu red hasta el punto de que no solo pueden meter las narices en tu base de datos de claves secretas JWT, sino también modificarla, probablemente tengas problemas mayores que el CVE-2022-23539, como se ha designado a este fallo.

¿Qué hacer?

Si utilizas una versión afectada de jsonwebtoken, actualiza a la versión 9.0.0 para solucionar este fallo.

Sin embargo, si ya has parcheado pero crees que los cibercriminales podrían haber sido capaces de llevar a cabo este tipo de ataque JWT en tu red, no basta con parchear.

En otras palabras, si crees que podrías haber estado en peligro, no te limites a parchear y seguir adelante.

Utiliza técnicas de detección y respuesta a amenazas para buscar agujeros por los que los ciberdelincuentes podrían llegar lo suficientemente lejos como para atacar tu red de forma más general y asegúrate de no tener delincuentes en tu red, incluso después de aplicar el parche.