Vulnerabilidad crítica en BankID sueco expone datos de usuario

El BankID sueco es una forma de identificación digital utilizada por la mayoría, si no por todos, los residentes suecos para autenticarse en múltiples servicios, como proveedores de Internet, servicios bancarios en línea, sitios web de apuestas y, especialmente, sitios web gubernamentales.

Al vivir en Suecia y con la mentalidad de hacker siempre zumbando en mi cerebro, decidí que sería un campo muy interesante para realizar algunas investigaciones sobre seguridad.

En esta publicación presentaré una nueva vulnerabilidad que encontré presente en la mayoría de los proveedores de servicios suecos debido a una implementación insegura del protocolo de autenticación de BankID.

Repasaré brevemente cómo funciona dicho protocolo, cómo se ve una configuración vulnerable, cómo explotarla, cómo remediarla y, al final, qué significan estos tipos de ataques para la implementación general de las eID.

El protocolo de autenticación BankID

BankID es un servicio que se instala en el dispositivo de un usuario y se obtiene solicitándolo a un banco sueco, siempre que se tenga un persunnumer sueco, un código fiscal personal. La aplicación se instala en el dispositivo del usuario y se conecta a su código fiscal, vinculando esencialmente su identidad a dicha aplicación. Así es como funcionan los sistemas de identificación electrónica: un tercero confiable y autorizado por el gobierno entrega un software que está vinculado a un individuo específico y luego los servicios se integran con el proveedor de ese software para permitir a sus usuarios autenticarse en su plataforma, un modelo de confianza compartida que permite que los servicios autentiquen fácilmente a las personas.

BankID no es diferente y proporciona documentación para dichos servicios, que a partir de ahora se denominarán Parte de Confianza (RP), para que puedan integrar fácilmente su flujo de autenticación con BankID. https://www.bankid.com/en/utvecklare/guider/teknisk-integrationsguide/rp-introduktion .

Con BankID se utilizan dos flujos principales para autenticar a un usuario:

• Autenticar en el mismo dispositivo

• Autenticar en otro dispositivo

  
  

Volveremos a revisar estos dos pronto; sin embargo, ambos flujos comienzan cuando el RP envía una solicitud a la API de BankID para iniciar una orden de autenticación. En esta solicitud de publicación, el RP debe especificar el parámetro endUserIp , que contiene la IP del usuario que intenta iniciar sesión, esto será importante más adelante en el informe.

El punto final de la API /auth responderá con algo como esto:

 HTTP/1.1 200 OK Content-Type: application/json { "orderRef":"131daac9-16c6-4618-beb0-365768f37288", "autoStartToken":"7c40b5c9-fa74-49cf-b98c-bfe651f9a7c6", "qrStartToken":"67df3917-fa0d-44e5-b327-edcc928297f8", "qrStartSecret":"d28db9a7-4cde-429e-a983-359be676944c" }

• orderRef es un identificador que el RP puede usar contra el punto final /collect para verificar el estado de autenticación y luego obtener la información de usuario que necesita de esa persona.
• autoStartToken es un token que utiliza el RP para crear un enlace profundo que, al hacer clic, abrirá la aplicación BankID y solicitará al usuario que se autentique ( esto será realmente importante ).

qrStartToken y qrStartSecret se tratarán a continuación, pero no son estrictamente importantes para la investigación de seguridad realizada.

Además de la IP del usuario, un RP puede especificar más parámetros para la orden de autenticación, incluido el texto que se mostrará en la aplicación BankID y los requisitos de autenticación .

Entre los requisitos de autenticación, en los que nos centraremos en esta publicación se encuentran las llamadas políticas de certificados , estas permiten que el RP comunique a BankID cuál de los dos flujos fue elegido por el usuario.

Autenticación en el mismo dispositivo

Cuando un usuario elige autenticarse usando BankID en el mismo dispositivo, el RP usa autoStartToken para crear un vínculo profundo similar a: bankid:///?autostarttoken=7c40b5c9-fa74-49cf-b98c-bfe651f9a7c6&redirect=https://service.com/login . Luego, el sistema operativo del usuario recoge este enlace profundo y lo entrega a la aplicación BankID.

Mientras investigaba este flujo, se encontró una vulnerabilidad de Open Redirect ya que no hay validación del parámetro redirect por parte de BankID. Explicaré por qué este error adicional hace que el ataque de secuestro de sesión sea aún más poderoso más adelante.

Autenticación en otro dispositivo

Cuando un usuario elige autenticarse usando BankID en otro dispositivo, el RP usa qrStartToken y qrStartSecret para generar un código QR dinámico (obteniendo los datos del siguiente cuadro del punto final /collect antes mencionado) que el usuario puede escanear usando su Mobile BankID. solicitud.

Políticas de certificación

El RP DEBE especificarlos al iniciar una orden de autenticación; permiten a BankID rechazar un intento de autenticación si el flujo no coincide para mitigar el phishing. Por ejemplo, si el usuario eligiera "autenticación en el mismo dispositivo", el RP debe comunicarlo a BankID para que, si se intenta la autenticación en un BankID móvil y/o utilizando el código QR, la aplicación pueda rechazarla.

Además de esto, una vez que se completa la autenticación, el RP puede recuperar la ipAddress que se utilizó para abrir la aplicación BankID desde el punto final API /collect . Esto DEBE luego compararse con la dirección IP del usuario en el RP en caso de que haya elegido "autenticación en el mismo dispositivo".

Las políticas de certificado, junto con la ipAddress DEBEN usarse para garantizar que el flujo de autenticación no pueda ser alterado.

Sin embargo, si bien estas medidas de seguridad están implementadas, BankID no resalta su importancia y no las implementa correctamente ni siquiera en el ejemplo de implementación proporcionado. https://github.com/BankID/SampleCode

El error de fijación de sesión

Entonces, ¿qué sucede cuando este protocolo no se implementa de forma segura?

Cuando vi por primera vez el enlace profundo bankid:/// estaba navegando por los formularios de solicitud de mi universidad, a los que se puede acceder iniciando sesión con BankID. Al principio pensé: ¿qué pasa si le envío este enlace profundo a alguien? Así que se lo envié a un amigo mío, quien hizo clic en él y, para mi sorpresa, después de abrir BankID, ¡tenía frente a mí todas sus solicitudes universitarias!

Fue entonces cuando comencé a investigar la API de BankID, implementé mi propio RP y aprendí todo lo que acabo de describir.

Después de algunas semanas de investigación, desarrollé un script que automatizaba la captura de enlaces profundos de bankid:/// para más de 30 RP. El script iniciaba un servidor web y creaba una ruta para cada servicio, cuando un usuario visitaba el enlace para En un servicio específico, el script buscaría un enlace nuevo y redirigiría al usuario a él. Esto haría que el dispositivo del usuario abriera la aplicación BankID y, tras la autenticación, yo sería autenticado en lugar de ellos.

Pude hacer esto porque:

• Los RP no enviaron las políticas de certificado a BankID, lo que me permitió obtener un enlace profundo y transmitirlo a una aplicación de Mobile BankID.

• Los RP no compararon la dirección IP que solicitaba el enlace con la dirección IP que había completado la autenticación.

• Los RP proporcionaron el enlace incluso cuando se eligió la opción "autenticar en otro dispositivo"

  
  

Lo que llevó a la vulnerabilidad de fijación de sesión.

El ataque

Imaginemos un servicio vulnerable llamado AmazingSevice AB, han implementado el flujo BankID siguiendo el código de muestra proporcionado y alojan dicha implementación en https://amazingservice.se/login/bankid .

Un atacante está interesado en los datos de usuario almacenados en AmazingSevice AB y tiene a su víctima a la vista. Simplemente tendría que automatizar la captura del enlace bankid:/// , alojarlo en su servidor y luego enviar el enlace a su servidor malicioso a sus víctimas. Después de elegir la entrega de phishing que le gusta (SMS, correo electrónico, etc.), insertará el enlace en el mensaje haciéndose pasar por AmazingSevice AB y solicitará a la víctima que inicie sesión.

Tal apropiación de cuentas implica muy poca ingeniería social porque una vez que la víctima hace clic en el enlace, se le solicita inmediatamente que abra BankID, dejando el “territorio desconocido” del sitio del atacante por una interfaz mucho más familiar, BankID. Además, AmazingSevice AB solicita la solicitud de autenticación que la víctima vería en la aplicación BankID, lo que hace imposible detectar comportamientos fraudulentos.

Una vez que la víctima se autentica, la sesión del atacante se autentica en la cuenta de la víctima; la víctima puede ser engañada aún más explotando la vulnerabilidad Open Redirect presente en BankID, lo que permite al atacante especificar el parámetro redirect como https://amazingservice.se/login/bankid . Esto llevaría a la víctima a ser redirigida al sitio web legítimo del servicio, dejándole simplemente pensando que la autenticación no fue exitosa.

Manifestación

No pude utilizar una de las empresas a las que informé, por razones obvias, por lo que la demostración muestra que el servicio de demostración de BankID es vulnerable a esto.

En la esquina derecha está la vista de la víctima que recibe el enlace; aquí se simula una visita al sitio web del atacante. Una vez que la víctima visita el enlace, el servidor del atacante abre el navegador sin cabeza y extrae el enlace bankid:/// que luego se transmite al teléfono de la víctima. En la aplicación de BankID, puede ver "Test av BankID", que es el origen legítimo del sitio de demostración de BankID. Además, al comienzo del vídeo, se activa una VPN para comprobar que no se realizan comprobaciones de dirección IP durante la autenticación. Al final, se puede ver que en el portátil del atacante está conectado como víctima (Johan Johansson).

El impacto

El error de fijación de sesión provoca una apropiación de cuenta con 1 clic en cualquier aplicación que utilice Swedish BankID como proveedor de autenticación y haya implementado incorrectamente (o no haya implementado ninguna) políticas de certificados y comprobaciones ipAddress . Esto es bastante grave porque muchas veces los servicios que utilizan BankID para autenticar a sus usuarios tienen acceso a datos y acciones bastante confidenciales. Se encontró que más de 30 aplicaciones eran vulnerables a este ataque y se contactó con la mayor cantidad posible, lo que generó 11 informes de recompensas por errores aceptados en las principales plataformas.

Uno de los servicios a los que informé sobre esta vulnerabilidad pudo ponerme en contacto con el CSIRT nacional de Suecia, debido a lo extendido y grave que es el problema. Las conversaciones acaban de comenzar, así que si quieres estar actualizado, sígueme en Twitter (X) @m4st3rspl1nt3r.

Remediación

Si está buscando un ejemplo de cómo se ve una implementación segura de la API de BankID RP, he creado una que puede usar como una biblioteca de Golang o personalizarla e implementarla como un microservicio. Eso lo puedes encontrar aquí .

Respuesta de BankID

La mayoría de los servicios afectados, especialmente los que tienen BBP y VDP, fueron bastante receptivos y rápidos en responder a mi informe. Sin embargo, la respuesta de BankID fue un poco diferente. En el correo electrónico que recibí después de contactarlos varias veces a través de varios canales, explicaron que estaban al tanto del problema pero que sentían que no se podía hacer mucho al respecto para mantener la “facilidad de integración” para los RP. La mitigación planificada, que lamentablemente todavía requiere que se realicen cambios en el lado de los RP, me fue comunicada (pero por alguna razón no se encuentra en ninguna parte de su documentación) como:

Un requisito adicional que el RP podrá establecer es el Riesgo. Esto establecerá el nivel de riesgo aceptable para la transacción. Si el riesgo de la transacción es superior al límite requerido, la transacción se bloqueará. “BAJO”: solo acepta órdenes de bajo riesgo “MODERADO”: acepta órdenes de riesgo bajo y moderado Si está configurado. Entre otras cosas, realizaremos la verificación de IP por nuestra parte si la proporciona RP. Otros parámetros de riesgo que se supervisarán si se proporcionan son el dominio de referencia, el agente de usuario y el identificador de dispositivo.

Además, también existe un plan para corregir la vulnerabilidad Open Redirect.

Mi opinión personal al respecto es que si desarrolla y opera un proveedor de autenticación tan crítico y altamente adoptado, que a menudo se usa para proteger información muy confidencial del usuario, debe documentar adecuadamente sus mecanismos de seguridad para que los RP puedan integrarlo de manera segura. Las características de seguridad opcionales son completamente inútiles, si un desarrollador puede ahorrar tiempo al no implementar ciertas características/parámetros, eso es lo que sucederá y no podemos culpar al lado de RP. BankID debe hacer todo lo posible para trasladar tantas características de seguridad y antifraude a su lado para mantener la “facilidad de integración”, pero también asegurarse de documentar adecuadamente cualquier característica de seguridad adicional que el RP deba implementar; nota sobre obligatorio , no opcional.

Empresa privada en peligro público

Para mí, esta vulnerabilidad es un ejemplo que muestra los peligros de permitir que una empresa privada tenga el control total de un sistema que es fundamental para la población de un país. La razón por la que creo que esto es más grave que simplemente otra vulnerabilidad en una empresa de software es que BankID es algo que utilizan más de 8,5 millones de residentes suecos, se utiliza para iniciar sesión en su banco, proveedor de seguros, proveedor de electricidad y otras plataformas sensibles que tener consecuencias en el mundo real.

Si alguien encuentra una apropiación de cuenta en Facebook, es posible que pierda algunas fotografías; si alguien encuentra una vulnerabilidad en el proveedor de identificación electrónica de su país (a menudo privado), las repercusiones en la vida de alguien pueden ser inimaginables.

Cada vez más países europeos están adoptando identificaciones electrónicas y la UE planea implementar una identificación electrónica propia en los próximos años (puede leer más sobre esto aquí ).

Mi esperanza es que los reguladores presionen para que los proveedores de identificación electrónica sean completamente desarrollados y controlados por instituciones públicas, posiblemente con el requisito de que dichos sistemas sean de código abierto y auditados periódicamente para detectar fallas de seguridad.

¿Cómo podemos aceptar con seguridad piezas de software tan críticas en nuestra sociedad si son desarrolladas por una empresa privada?

Más investigación

Si bien el tema principal de esta publicación de blog fue el ataque de fijación de sesión en BankID, descubrí que muchos otros proveedores de autenticación/identificación han sido diseñados con el mismo defecto. Se puede encontrar una nueva clase de vulnerabilidad en los proveedores que requieren el uso de otro dispositivo (a menudo un teléfono móvil) para completar el flujo de autenticación.

La investigación está en curso y pronto espero publicar más de mis hallazgos y una herramienta en la que he estado trabajando que pueda usarse para automatizar y explotar dichas vulnerabilidades. Estén atentos a mi próximo tema Fijación de sesiones por diseño: pesadillas de autenticación entre dispositivos

Hasta entonces, ¡hackea el planeta!