Suplantación de identidad alemana con autenticación en línea y financiación de refugiados en Alemania

ID alemana

Wolfgang Ettlinger, especialista en seguridad de SEC Consult Vulnerability Lab, describió una técnica para manipular los datos (incluidos el nombre y la dirección) durante una verificación en línea de las identificaciones estatales alemanas.

Las tarjetas de identificación alemanas se emiten a partir del 1 de noviembre de 2010. Cada tarjeta contiene un chip RFID que almacena información sobre el propietario, incluido el nombre, la fecha de nacimiento y la foto biométrica. Si el propietario lo desea, puede grabar un escaneo de huellas digitales.

Las nuevas tarjetas son legibles por máquina y se pueden usar como documentos de viaje en la mayoría de los países europeos, así como para la autenticación en servicios gubernamentales en línea (impuestos, postales) o para verificar la edad. Se utilizan para autenticar a los usuarios en algunos servicios en línea, incluso en el portal de presentación de impuestos .

La autenticación RFID se realiza utilizando un lector de tarjetas y una aplicación de cliente eID (por ejemplo, AusweisApp 2 ), que interactúa con el chip RFID y el servidor de autenticación (eID-Server o SAML-Processor) para verificar la información de inicio de sesión.



Para evitar la falsificación de identidad, el servidor de autenticación valida la información y luego firma la respuesta que el cliente envía al servidor web para que el servicio web pueda confiar en la legitimidad de los datos recibidos.

Wolfgang Ettlinger encontró una manera de engañar a una aplicación web enviándole datos modificados. La captura de pantalla muestra cómo se autenticó con éxito en la aplicación oficial bajo el nombre de Johann Wolfgang von Goethe, un famoso escritor alemán. El formulario muestra la dirección donde vivió el escritor 50 años, donde se encuentra hoy el Museo Goethe.



La vulnerabilidad se encontraba en Governikus Autent SDK, un componente de software para integrar características de autenticación en aplicaciones web. Incluyendo que implementa la función de verificación de autenticación del cliente eID. La conclusión es que la verificación se lleva a cabo en dos etapas independientes . En la primera etapa, se verifica la firma de autenticación del servidor de autenticación, y en la segunda etapa, los datos en sí, incluida la identidad del propietario. Como resultado, es posible enviar dos respuestas SAML independientes a la aplicación: la primera con una firma válida y la segunda con datos falsos y sin firma.

El exploit explota el hecho de que Governikus Autent SDK verifica la firma usando el método HttpRedirectUtils.checkQueryString , que no considera usar el mismo parámetro varias veces. Por lo tanto, después de verificar el parámetro, otras instancias se analizan como si ya hubieran pasado la prueba.

Así es como se aplica este método en una aplicación real:

 // check the signature of the SAML response. There is no XML signature in this response but the // parameter are signed. if (!HttpRedirectUtils.checkQueryString(request.getQueryString(), SamlExampleHelper.SERVER_SIG_CERT)) { storeError(request, response, "Signaturprüfung der SAML-Response fehlgeschlagen!"); return; } 

El método recibe la cadena de consulta, la analiza, crea una versión canónica de la cadena de consulta y verifica la firma.

Luego se analiza la respuesta SAML:

 // get the parameter value String samlResponseBasee64 = request.getParameter(HttpRedirectUtils.RESPONSE_PARAMNAME); [...] // parse the SAML Response. ParsedResponse parsed = parser.parse(samlResponse); 

Como ya se mencionó, HttpRedirectUtils.checkQueryString no considera usar el parámetro varias veces, siempre usa el último valor del parámetro.

Para aprovechar con éxito la vulnerabilidad, un atacante necesita una cadena de consulta firmada por el servidor de autenticación. Detalles como el momento de la firma o la persona para la que se solicitó no importan. Incluso si la cadena de consulta es válida por un período corto, se realiza una verificación de validez de los datos en la tarjeta de identificación. Según el investigador, obtener una solicitud válida no será difícil si sabe dónde buscar, ya que están disponibles a través de una búsqueda de Google en los registros del cliente eID.

Los investigadores muestran sus resultados en video:


Aplicaciones web vulnerables que ejecutan Governikus Autent SDK 3.8.1 y versiones anteriores que manejan configuraciones HTTP duplicadas. La vulnerabilidad se puede utilizar, por ejemplo, para registrarse en servicios en línea con un nombre falso.

¿Por qué podrías necesitar un nombre tan falso? Puedes dar un ejemplo tan abstracto. Recientemente, el Ministerio del Interior de Alemania lanzó la iniciativa "Retorno voluntario" , en virtud del cual financia a cualquier extranjero que desee ir voluntariamente a casa. Pagar un boleto y alojamiento al gobierno es más barato que deportar por la fuerza a un refugiado ( 700 contra 1.500 euros ), es decir, el financiamiento tiene sentido.


Campaña publicitaria en el metro de Berlín: para los refugiados que han notificado a las autoridades alemanas su salida voluntaria a su tierra natal hasta el 31 de diciembre, se compensa el alquiler anual de viviendas en su país de origen

Teóricamente, cualquier extranjero puede venir a Alemania, solicitar el estatuto de refugiado, recibir un rechazo e inmediatamente ser financiado por este programa. El único problema para el estafador es que solo puedes hacer este truco una vez. Obviamente, los servicios verificarán que el beneficio aún no se haya emitido a su nombre. Pero si se registra en el programa con un nombre diferente, se puede recibir dinero varias veces (en teoría).

Por supuesto, la suplantación de identidad electrónica alemana estatal no ayudará a un estafador con un pasaporte extranjero a llegar a Alemania con un nuevo nombre. Pero este ejemplo muestra que cada sistema de seguridad debe tener vulnerabilidades. La única pregunta es el deseo y los recursos para encontrarlos.

---