Vulnerabilidad de suplantación de EAA de Akamai: análisis en profundidad

En esta publicación, trataremos los detalles técnicos de CVE-2021-28091, la vulnerabilidad que afecta a la plataforma Enterprise Application Access (EAA) de Akamai. Trataremos nuestro proceso de investigación, resolución y divulgación de la vulnerabilidad. Para obtener una descripción general de la vulnerabilidad, el impacto en Akamai, el impacto en los clientes de EAA y las acciones necesarias, consulte nuestro informe complementario.

Descripción general

En esta sección, le guiaremos por la historia y la anatomía de esta vulnerabilidad. Es posible que algunos lectores deseen omitir esta sección por ahora e ir directamente a la sección Acciones necesarias, y utilizar esta descripción general como referencia en cualquier evaluación que necesiten realizar o para revisiones futuras.

Antes de la adquisición de la tecnología EAA por parte de Akamai mediante la adquisición de Soha Systems en 2016, se introdujo una función clave en la plataforma que permitía a los clientes de la plataforma tomar decisiones de control de acceso y autenticación basadas en la información de identidad proporcionada por un proveedor de identidad de terceros. La plataforma EAA ofrece varios métodos de integración de identidades de terceros. El método más destacado para este informe es la compatibilidad con el protocolo de autenticación del lenguaje de marcado de aserción de seguridad (SAML) v2.0.

SAML es un estándar abierto ampliamente utilizado. SAML permite a un proveedor de identidad (IdP) confirmar, mediante la firma criptográfica y la devolución, un proveedor de servicios (SP) a través del cliente mediante la presentación de un objeto de afirmación del IDP al SP en un periodo de tiempo definido. (Consulte la sección Antecedentes a continuación para obtener más información).

Cuando se añadió la compatibilidad con IdP de terceros a EAA, los desarrolladores seleccionaron la biblioteca de código abierto Lasso para implementar la compatibilidad con SAML en la plataforma. Basándonos en la evaluación de Akamai del código en el que Lasso verifica las respuestas de SAML proporcionadas como SP, creemos que en el momento de la integración inicial, los desarrolladores que implementaron la función de IdP de terceros lo hicieron de forma razonable de acuerdo con los casos de prueba proporcionados con la biblioteca. Una investigación posterior reveló que el conjunto de pruebas utilizado para realizar la implementación de Akamai no era lo suficientemente riguroso para identificar esta vulnerabilidad de suplantación o debilidades similares en el proceso de autenticación. Esta deficiencia se ha abordado como parte de nuestra respuesta mediante la ampliación del conjunto de pruebas aplicado a las nuevas versiones del producto a fin de incluir todas las combinaciones de respuestas y/o afirmaciones válidas y firmadas de forma no válida, así como afirmaciones y respuestas sin firmar. Estas nuevas pruebas forman parte del proceso de control de calidad estándar de cara al futuro.

En las siguientes secciones del informe, desglosamos las diversas debilidades y factores que contribuyeron a la vulnerabilidad general. Nuestro objetivo al proporcionar este nivel de transparencia es ayudar a otros a comprender las medidas que ha adoptado Akamai de modo que puedan evitar circunstancias similares en sus propios entornos.

Pruebas y evaluación del sistema

Las pruebas unitarias, las pruebas de integración y las pruebas de regresión son un aspecto clave de cualquier ciclo de vida de desarrollo de software (SDLC). Aunque el subcomponente que se implementó tenía todos estos métodos de prueba asociados, hemos visto con claridad que las pruebas no eran lo suficientemente rigurosas. Además, este incidente ha esclarecido que se produjo un descuido al incorporar algunas bibliotecas de terceros a proyectos bajo la falsa suposición de que el SDLC de la dependencia es en sí mismo riguroso y que se fundamentará en detecciones específicas del dominio, como las vulnerabilidades, en bibliotecas similares.

Aunque es necesario un SDLC riguroso para cada componente y cada una de sus dependencias, suele ocurrir que las pruebas incorporadas en el desarrollo del componentes y el plan de control de calidad (QA) no son suficientes. Para complementar esta prueba, se pueden emplear evaluaciones contradictorias, como pruebas de penetración o revisiones de código de terceros. En el caso de EAA, se han llevado a cabo varias evaluaciones externas de seguridad y vulnerabilidad de la plataforma EAA a lo largo de la vida útil del producto, normalmente por parte de los clientes. A pesar de ello, el informe que inició esta respuesta fue la primera vez que se informó de esta vulnerabilidad a Akamai. Akamai ha realizado evaluaciones específicas en otras partes de la plataforma EAA y su aplicación cliente, pero este componente específico no ha sido sometido a ese nivel de escrutinio.

Evitar una divulgación prematura

Al principio de este proceso de respuesta a incidentes, Akamai comenzó a redactar una notificación de alto nivel para guiar a los clientes a iniciar las investigaciones sugeridas en la sección Acciones necesarias de la publicación complementaria. En una revisión previa a la publicación de ese documento, el personal de Akamai que no estaba informado sobre la vulnerabilidad recibió una copia del mensaje dirigido al cliente. En un plazo de una hora desde que se proporcionó el mensaje, nuestros revisores pudieron identificar el protocolo afectado (SAML), el paquete afectado (Lasso) y, con algunas actividades recientes por parte del responsable de mantenimiento del proyecto Lasso, elaborar una conjetura de cuál era la vulnerabilidad. Esta revelación puso en pausa inmediata nuestros planes de notificación parcial para cumplir los principios de divulgación responsable. 

Después de algunas conversaciones con nuestros revisores, el equipo de incidentes pudo conocer el proceso que les permitió realizar estos descubrimientos. Un hallazgo clave notificado por los revisores fue el mensaje de error devuelto por el IdP cuando se producía una condición de error. Hasta que se publicó la corrección de la vulnerabilidad, los fallos de SAML devolvían una página de error que exponía el error de Lasso al usuario final, como se muestra en la siguiente imagen. El reenvío de un error, especialmente de procesos de seguridad críticos como la autenticación, es contrario a las prácticas recomendadas, por lo que el error no será visible para los usuarios finales a partir de esta versión. 

El documento XML anterior se ha simplificado para los fines de este informe, pero la estructura es la misma. El documento «principal» externo es la respuesta de SAML que incluye metadatos sobre la solicitud y un documento de afirmación. La afirmación, también denominada afirmación de SAML, son los datos que se proporcionan desde el IdP al SP para su uso en el proceso de autenticación. Pueden existir varias afirmaciones en una única respuesta de SAML. En el ejemplo anterior, el contenido de las llaves ds:Signature es una firma criptográfica sobre el contenido del objeto principal, que es la afirmación en este caso. El mismo objeto de firma también se puede aplicar a todo el objeto de respuesta. El propósito de la firma es permitir que el SP valide que los datos contenidos en la afirmación o la respuesta son legítimos y que han sido proporcionados por el IdP. En el caso de la afirmación, la firma solo se aplica a todos los datos contenidos en la afirmación, como un nombre de usuario, una dirección de correo electrónico o indicaciones de pertenencia a grupos. Las firmas aplicadas en el nivel de respuesta se aplican al contenido completo de la respuesta y a todas las afirmaciones que incluye.

La verificación de las diversas firmas en la respuesta de SAML se confía al SP y se suele configurar cuando se configura el IdP para comunicarse con la aplicación. En nuestra respuesta a este problema, creemos que las condiciones de verificación predeterminadas de las respuestas de SAML deben ser las siguientes.

• Cuando la respuesta de SAML completa se firma de forma válida, todas las afirmaciones de la respuesta deben estar firmadas correctamente o no tener ninguna firma. Si se encuentran firmas no válidas, la verificación debe fallar. Este método se basa en que el IdP sea autorizado para todo el cuerpo del mensaje, que está firmado.
• Cuando la respuesta de SAML está sin firmar, todas las afirmaciones de la respuesta deben estar firmadas correctamente; de lo contrario, la verificación debe fallar.
• Cuando la respuesta de SAML tiene una firma no válida, la verificación debe fallar.

Las condiciones de procesamiento anteriores son las que ha implementado el parche propuesto por Akamai para Lasso.

El informe proporcionado a Akamai al principio de este problema mostraba que el investigador enviaba dos afirmaciones de SAML en una única respuesta de SAML, la primera estaba firmada de forma válida, pero la segunda no. La configuración predeterminada para Lasso tenía las siguientes condiciones de verificación predeterminadas.

• Si la primera afirmación de SAML de la respuesta estaba firmada de forma válida, se superaba la verificación, independientemente de que la firma de la respuesta de SAML completa fuera válida o no.
• Si la primera afirmación de SAML estaba firmado de forma no válida, fallaba la verificación.
• Si la respuesta de SAML estaba firmada de forma válida y ninguna de las afirmaciones estaba firmada, se superaba la verificación.
• De lo contrario, fallaría la verificación.

 Para complicar las cosas, cuando la biblioteca consideraba que la respuesta era válida, la función para recuperar la afirmación de la respuesta de SAML devolvería la última afirmación en el objeto de respuesta, independientemente de que tuviera una firma válida. A modo de ejemplo, supongamos que un atacante obtiene una respuesta de SAML válida con una única afirmación de un IdP, como la anterior, y que agrega lo siguiente como segunda afirmación:

En el caso en el que el usuario proporcionado sea válido para la organización pero tenga más privilegios, tendría la respuesta de SAML combinada para su envío al SP:

Cuando Lasso intentó validar esta respuesta de SAML, el resultado sería que la respuesta era válida. Cuando la aplicación que llama recuperó la afirmación de la respuesta que se muestra más arriba, se devolvería la afirmación con el identificador de usuario (uid) de superusuario y probablemente se consideraría una afirmación válida. Además del ejemplo mostrado anteriormente, si la respuesta de SAML en sí tenía una firma válida, sería posible este mismo método de suplantación. Este fue el caso del procesamiento que realizó EAA de las respuestas de SAML. 

Condiciones de explotación

Para que la respuesta de SAML se modifique antes de enviarla al SP, debe producirse una de las siguientes condiciones:

• El cliente legítimo, controlado por un usuario autorizado válido y a través del cual se redirige una respuesta de SAML, debe modificar la respuesta de SAML inyectando el documento de afirmación adicional como parte de la respuesta de SAML. Por ejemplo, se podría llevar a cabo a través de una extensión de navegador maliciosa u otro malware en el sistema cliente, lo cual se conoce a veces como un ataque "Man-in-the-Browser".
• Un atacante debe obtener una copia válida de una respuesta de SAML que aún sea válida, ya sea disponiendo de tiempo antes de que caduque la afirmación o, en algunas aplicaciones, que la afirmación aún no se haya presentado al SP. Por ejemplo, una parte intermedia puede interceptar y modificar una respuesta de SAML a través de un proxy, lo cual se suele denominar un ataque "Man-in-the-Middle".
• Un cliente no autorizado conoce o puede adivinar la información de inicio de sesión de un usuario autorizado. La información de inicio de sesión se puede recopilar a través de muchos procesos, como los ataques de phishing, filtración de contraseñas, adivinación o fuerza bruta.

Cada una de las condiciones anteriores podría comprometer la sesión de un usuario y, si la implementación de SAML tiene errores como se ha indicado anteriormente, el SP sería vulnerable a un ataque de suplantación.

Historia de la vulnerabilidad

Se ha informado de esta misma vulnerabilidad, conocida como XML Signature Wrapping (ajuste de firma XML) una y otra y otra vez. 

La revisión de los repositorios de Lasso indica que la debilidad de la biblioteca se ha incorporado al código base desde noviembre de 2005, mucho antes de nuestra incorporación de la biblioteca y también antes de la publicación de las vulnerabilidades anteriores anunciadas en otras plataformas.

También hemos observado durante la investigación que los responsables del mantenimiento de la biblioteca de Lasso se comprometieron con el proyecto poco después de que se enviara la notificación del problema a Akamai. En las conversaciones con el informador, este compromiso no estaba relacionado en absoluto con su informe, sino que fue simplemente una coincidencia.

La corrección propuesta el 24 de febrero de 2021 resolvió parcialmente el impacto de la explotación, pero tras una revisión posterior, determinamos que no era una corrección completa, motivo por el cual se propuso nuestro parche en última instancia a los responsables de mantenimiento.

Análisis de la respuesta a incidentes de Akamai

Akamai sigue un proceso formal de respuesta a incidentes. Las incidencias suelen resolverse gracias a la labor de cooperación del personal de desarrollo de sistemas o ingeniería, operaciones de red y atención al cliente. En general, cuanto más grave sea el incidente, más personas participarán en él y más se priorizará sobre las operaciones y el trabajo planificados. En todos los incidentes, el objetivo de Akamai es: 

• Limitar el impacto del problema. 
• Garantizar el funcionamiento seguro y continuado de nuestros sistemas.
• Garantizar la seguridad y el cuidado continuos de los responsables de respuesta a incidentes.
• Mantener a los clientes satisfechos y sus datos seguros
• Cumplir las diversas leyes y normativas.
• Asegurarnos de que somos capaces de aprender y mejorar de cualquier peligro que haya causado que se produzca el incidente.

Como se ha descrito anteriormente, iniciamos nuestro proceso de respuesta a incidentes tras la notificación de esta vulnerabilidad. Dicho proceso permitió a Akamai alinear los recursos técnicos, comunicarse con las partes interesadas internas y la dirección, comunicarse con las partes interesadas externas y coordinar todas las actividades relacionadas con el incidente de forma oportuna y eficaz.

Proceso de aplicación de parches e implementación

El proceso de desarrollo de una corrección para esta vulnerabilidad y de implementación del parche en la red EAA fue muy similar al proceso normal seguido para las actualizaciones planificadas, pero con un cambio mucho menor y un plazo mucho más corto.

En las primeras horas de respuesta al incidente, preparamos un borrador de la cronología de la corrección teniendo en cuenta algunas decisiones clave. Esa cronología consistía en que, una vez que la corrección estuviera lista, se esperaba que el proceso de control de calidad tuviera una duración de 3 días después del proceso de control de calidad estándar, y que la fase de implementación fuera de 48 horas. Tras la fase de implementación, planificamos la comunicación del problema en forma de entrada de blog y notificaciones al cliente. Estos plazos podrían haberse acelerado, pero teniendo en cuenta que no había pruebas de explotación activa, dimos prioridad a la estabilidad de nuestra red y nos aseguramos de que nuestros clientes permanecieran estables durante todo el proceso.

Después de la clasificación inicial del problema, el equipo de ingeniería abordó la corrección a través de dos rutas, cada una de las cuales utilizaría diferentes recursos de ingeniería y de control de calidad. 

Un equipo investigó y desarrolló una corrección parcial para el problema, cerrando el problema notificado y restringiendo los requisitos del procesamiento de respuestas de SAML a lo que creemos que es la presentación normal de una respuesta de SAML con una afirmación. Este método puede haber ocasionado que se hayan denegado algunas respuestas de algunos IdP aunque fueran válidas y seguras. Este enfoque también tenía la opción de desactivar una comprobación más estricta por cliente a fin de proteger el resto de la base de clientes en caso de una interacción inesperada con un pequeño número de IdP.

El otro equipo adoptó un enfoque similar al del primer equipo, pero en lugar de una corrección parcial configurable, trabajó en lo que creemos que es una corrección completa. Su enfoque se analizó para garantizar que se aceptaran todas las respuestas SAML bien formadas y correctamente firmadas, lo que reduce la complejidad necesaria para que se puedan degradar los clientes.

Adoptamos este enfoque simultáneo porque permitiría bloquear una ruta o toparse con desafíos de control de calidad a la vez que hacía posible implementar una corrección. A última hora del día del 24h de febrero, hora del este de EE. UU., esperábamos que la corrección parcial estuviera lista para el control de calidad tres días después de que comenzara el incidente, mientras que se esperaba que la corrección completa tardara una semana más en desarrollarse. El trabajo continuó durante la noche hasta el día 25, cuando el informe de progreso del equipo de ingeniería mostró que la opción de corrección completa estaba progresando bien y que, en última instancia, se esperaba que su desarrollo fuera más rápido y las pruebas menos complejas.

Finalmente, la opción de corrección completa se entregó al equipo de control de calidad aproximadamente un día antes que la corrección parcial. Una vez que se entregó la primera opción al equipo de control de calidad, se publicó una notificación de parches para todos los clientes de EAA en la que se indicaba el plazo de implementación previsto.

Este estado se mantuvo igual durante todo el proceso de control de calidad. Poco antes del periodo de mantenimiento, la corrección completa recibió la aprobación del equipo de control de calidad, lo que despejó el camino para la implementación.

El proceso de implementación comenzó con un punto de presencia (POP) con una carga ligera en el que  ejecutamos un conjunto de regresión ampliado supervisando el tráfico cuidadosamente para detectar posibles interrupciones para los clientes. Se actualizó otro POP de carga ligera con un proceso de prueba reducido y un periodo de supervisión. En las primeras horas del día 2 de marzo, los POP que sirven a la implementación interna de EAA de Akamai se actualizaron para poder realizar más pruebas de carga con nuestros casi 8000 usuarios finales. Al no detectarse ningún problema con ninguna de las implementaciones hasta ese momento, el resto de los POP se actualizaron durante las 36 horas restantes del periodo de mantenimiento y, finalmente, se completó el proceso de implementación antes del cierre del periodo de mantenimiento. 

Durante el proceso de actualización, es probable que la mayoría de los usuarios que interactuaban con sus aplicaciones de EAA experimentaran una o más interacciones de reautenticación.  Normalmente consisten en una interrupción temporal de la sesión y el redireccionamiento a su IDP para que introduzcan sus credenciales y puedan volver a su trabajo normal. Es posible que los usuarios del cliente EAA también hayan observado este comportamiento. Los clientes de EAA agruparon los intentos de reautenticación durante la implementación. Después de la actualización de código en cada POP, se borró la caché de sesión que mantiene EAA, la cual activaría una nueva autenticación para todas las solicitudes en un intervalo de 5 minutos. Una vez reautenticadas, no observamos ningún impacto adicional en los usuarios finales.

Gestión del equipo de incidentes

Un aspecto clave a la hora desarrollar, verificar e implementar de forma segura la corrección en nuestra red para problemas importantes como este es la atención minuciosa que se presta al equipo que trabaja en un problema. El proceso de gestión de incidentes de Akamai y su formación complementaria incluyen orientación sobre cómo limitar el desgaste de los equipos técnicos y de gestión que responden a un incidente. Esta guía incluye la verificación de que los miembros del equipo encargado del incidente:

• Comen (de forma regular)
• Duermen (preferiblemente, una noche completa de sueño)
• Atienden sus obligaciones personales
• Se mantienen saludables (vacunas contra la COVID-19, ejercicio)

Si bien la resolución del incidente en cuestión es fundamental, nos hemos dado cuenta de que mantener la atención al equipo durante todo el proceso contribuye a llegar al destino de forma más segura para el producto o el sistema afectado, a la vez que reduce el número de errores evitables y los eventos que pueden afectar al cliente, a menudo asociados con una respuesta a incidentes con un alto nivel de estrés.

Otro aspecto clave del proceso de gestión de incidentes de Akamai es el principio de que todos estamos en el mismo barco y de que ni ahora ni en el futuro se culpará a nadie. El equipo de incidentes trabaja en equipo para resolver el problema, sea el que sea, de la mejor manera posible, centrándose primero en reducir el impacto y, a continuación, en averiguar cómo evitar que vuelva a producirse. Akamai se centra en hallar las suposiciones que causaron un incidente, aprender de esas suposiciones incompletas y realizar las modificaciones adecuadas para reducir las posibilidades de que este o eventos similares vuelvan a producirse.

Acciones necesarias

Los propietarios de sistemas que confían en Lasso para su autenticación SAML deben aplicar el parche lo antes posible. Es posible que se requieran acciones adicionales para investigar el impacto en los sistemas autenticados. Puede encontrar más información sobre las acciones que pueden ser necesarias en la sección Acciones necesarias de la publicación complementaria a este informe.

Cronología