ID alemãoO especialista em segurança Wolfgang Ettlinger, do SEC Consult Vulnerability Lab,
descreveu uma técnica para adulterar dados (incluindo nome e endereço) durante uma verificação on-line dos IDs alemães estaduais.
Os cartões de identificação alemães são emitidos a partir de 1º de novembro de 2010. Cada cartão contém um chip RFID que armazena informações sobre o proprietário, incluindo nome, data de nascimento e foto biométrica. Se o proprietário quiser, ele pode gravar uma digitalização de impressões digitais.
Os novos cartões são legíveis por máquina e podem ser usados como documentos de viagem na maioria dos países europeus, bem como para autenticação em serviços governamentais on-line (fiscais, postais) ou para verificar a idade. Eles são usados para autenticar usuários em alguns serviços online, inclusive no
portal de declaração de impostos .
A autenticação RFID é realizada usando um leitor de cartão e um aplicativo cliente eID (por exemplo,
AusweisApp 2 ), que interage com o chip RFID e o servidor de autenticação (eID-Server ou SAML-Processor) para verificar as informações de login.
Para impedir a falsificação de identidade, o servidor de autenticação valida as informações e assina a resposta que é enviada ao servidor da Web do cliente para que o serviço da Web possa confiar na legitimidade dos dados recebidos.
Wolfgang Ettlinger encontrou uma maneira de enganar um aplicativo da Web enviando dados modificados. A captura de tela mostra como ele se autenticou com sucesso no aplicativo oficial sob o nome de Johann Wolfgang von Goethe, um famoso escritor alemão. O formulário mostra o endereço onde o escritor viveu 50 anos, onde o Museu Goethe está localizado hoje.
A vulnerabilidade estava no Governikus Autent SDK, um componente de software para integrar recursos de autenticação em aplicativos da web. A inclusão dela implementa a função de verificação de autenticação do cliente eID. A conclusão é que a
verificação é realizada em dois estágios independentes . No primeiro estágio, a assinatura de autenticação do servidor de autenticação é verificada e, no segundo estágio, os próprios dados, incluindo a identidade do proprietário. Como resultado, torna-se possível enviar duas respostas SAML independentes para o aplicativo: a primeira com uma assinatura válida e a segunda com dados falsos e sem uma assinatura.
A exploração explora o fato de que o SDK do Governikus Autent verifica a assinatura usando o método
HttpRedirectUtils.checkQueryString , que não considera o uso do mesmo parâmetro várias vezes. Assim, após verificar o parâmetro, outras instâncias são analisadas como se já tivessem passado no teste.
Veja como esse método é aplicado em um aplicativo 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; }
O método recebe a string de consulta, analisa-a, cria uma versão canônica da string de consulta e verifica a assinatura.
Em seguida, a resposta SAML é analisada:
// get the parameter value String samlResponseBasee64 = request.getParameter(HttpRedirectUtils.RESPONSE_PARAMNAME); [...] // parse the SAML Response. ParsedResponse parsed = parser.parse(samlResponse);
Como já mencionado,
HttpRedirectUtils.checkQueryString não considera o uso do parâmetro várias vezes, sempre usando o último valor do parâmetro.
Para explorar com êxito a vulnerabilidade, um invasor precisa de uma sequência de consultas assinada pelo servidor de autenticação. Detalhes como o horário da assinatura ou a pessoa para quem foi solicitado não importam. Mesmo que a string de consulta seja válida por um curto período, uma verificação de validade é realizada para os dados no cartão de identificação. Segundo o pesquisador, obter uma solicitação válida não será difícil se você souber onde procurar, pois elas estão disponíveis através de uma pesquisa no Google nos registros do cliente de identificação eletrônica.
Pesquisadores mostram seus resultados em vídeo:
Aplicativos da Web vulneráveis executando o Governikus Autent SDK 3.8.1 e versões anteriores que lidam com configurações HTTP duplicadas. A vulnerabilidade pode ser usada, por exemplo, para registrar-se em serviços online com um nome falso.
Por que você precisa de um nome tão falso? Você pode dar um exemplo tão abstrato. Recentemente, o Ministério da Administração Interna da Alemanha lançou a iniciativa
“Retorno Voluntário” , sob o qual financia qualquer estrangeiro que deseje voluntariamente voltar para casa. Pagar uma passagem e acomodação ao governo é mais barato do que deportar à força um refugiado (
700 contra 1.500 euros ), ou seja, o financiamento faz sentido.
Campanha publicitária no metrô de Berlim: para refugiados que notificaram as autoridades alemãs de sua partida voluntária para sua terra natal até 31 de dezembro, o aluguel anual de moradias no país de origem é compensadoTeoricamente, qualquer estrangeiro pode vir para a Alemanha, solicitar o status de refugiado, receber uma recusa - e ser imediatamente financiado sob esse programa. O único problema para o fraudador é que você só pode fazer esse truque uma vez. Obviamente, os serviços verificarão se o benefício ainda não foi emitido em seu nome. Mas se você se registrar no programa com um nome diferente, o dinheiro poderá ser recebido várias vezes (teoricamente).
É claro que a falsificação de documentos eletrônicos de identidade alemães não ajudará um fraudador com um passaporte estrangeiro a chegar à Alemanha sob um novo nome. Mas este exemplo mostra que todo sistema de segurança deve ter vulnerabilidades. A única questão é o desejo e os recursos para encontrá-los.
