Cartão ou rosto: diferenças fundamentais
O algoritmo de trabalho de um sistema de controle de acesso clássico se parece com este:
- a pessoa traz o cartão ao leitor;
- o leitor recebe o número do cartão e o envia ao servidor;
- o servidor verifica as permissões para esta chave e, se o acesso for permitido, retorna o status "OK";
- .
Se aplicarmos este algoritmo, substituindo o número do cartão por uma imagem de rosto, um apocalipse local acontecerá, porque a imagem é muito maior que o número do cartão. Isso significa que sua transferência para o servidor levará mais tempo e a correspondência de imagens no banco de dados do servidor é muito mais do que encontrar o número da chave. Se houver muitos funcionários no escritório em constante movimento, existe uma probabilidade diferente de zero de que você terá que sorrir para a fechadura enquanto espera a porta se abrir por vários minutos.
Para evitar isso, em vez de uma simples câmera IP, eles usam um dispositivo inteligente que é poderoso o suficiente para reconhecimento de rosto, e o banco de dados de rostos é armazenado no dispositivo. Normalmente, esse dispositivo é um poderoso gadget Android ou um PC compacto com Windows ou Linux.
Neste caso, o servidor central é usado para sincronizar as bases de dados dos visitantes, atualizar o software do leitor e administrar todo o sistema.
Mover a carga de processamento do servidor para a borda externa elimina a necessidade de enviar dados confidenciais, como imagens, para processamento. Os tempos de resposta são aceitáveis e os requisitos de largura de banda são reduzidos.
No entanto, junto com o poder de processamento, outras tarefas passam para os nós de borda. Essa mudança adiciona dois problemas notáveis:
- em nós de fronteira, além das operações primitivas de ler um cartão e abrir uma porta, uma lógica de negócios completa é adicionada, que é uma fonte de vulnerabilidade potencial;
- , .
Queremos também estar no futuro o mais rápido possível, onde comprar um bilhete basta sorrir na catraca, mas consideramos necessário excluir a situação em que alguém sorria e o dinheiro foi debitado de você.
Como mostra nosso estudo Identified and Authorized: Sneaking Past Edge-Based Access Control Devices , os sistemas de controle de acesso baseado em rosto têm muitas vulnerabilidades desagradáveis: eles podem ser hackeados, enganados, apresentados com uma foto de uma pessoa na tela do iPhone em vez do rosto de uma pessoa e até mesmo se tornar um administrador e excluídos. todos os chefes da lista de admitidos nas instalações.
Considere um dos dispositivos mais vulneráveis em nosso estudo - ZKTeco FaceDepot 7B
Sistema de controle de acesso ZKTeco FaceDepot. Fonte: Trend Micro
O dispositivo vem em uma caixa de metal resistente com uma tela e uma câmera frontal voltada para o visitante. O reconhecimento de rosto ocorre dentro do dispositivo. As fotos tiradas durante a autenticação não são enviadas para o servidor central - a potência do processador do tablet é suficiente para realizar o reconhecimento por conta própria.
Uma implantação típica do ZKTeco FaceDepot ACS inclui vários desses dispositivos e um servidor central através do qual a base de usuários é sincronizada entre os dispositivos.
Porta USB insegura
A caixa de metal protege o ACS de interferências físicas, mas a porta USB aberta na parte inferior do dispositivo estraga tudo. Ele foi projetado para fazer a manutenção do dispositivo.
Vulnerabilidade # 1 - porta USB aberta. Fonte: Trend Micro
Versão desatualizada do Android
Outra vulnerabilidade global do ZKTeco é o firmware do dispositivo, que é baseado no Android Lollipop 5.1.1, lançado em abril de 2016. Hoje, a versão atual do Android é a décima. Ao longo dos anos, o sistema operacional recebeu muitas melhorias relacionadas à segurança. Obviamente, na quinta versão nada disso é fornecido.
Tela com versão Android no ZKTeco FaceDepot SKD. Fonte: Trend Micro
A capacidade de instalar pacotes APK
Como este é o Android, o usuário pode ir para a tela inicial e iniciar o aplicativo. Por exemplo, ele pode iniciar o ApkInstaller e instalar qualquer pacote APK Android a partir de uma mídia conectada a uma porta USB.
Instalador do APK em execução no ACS. Fonte: Trend Micro
O fabricante do dispositivo limitou a capacidade de acessar menus e aplicativos apenas para usuários com direitos de administrador, mas uma investigação mais aprofundada do dispositivo mostrou que isso não é um problema, porque o dispositivo ainda se comunica com o servidor e o faz via HTTP.
Troca não criptografada com o servidor
O dispositivo se comunica com o servidor via HTTP. Todas as informações são transmitidas em texto claro e podem ser facilmente interceptadas. Pior de tudo, os comandos administrativos são transmitidos em texto não criptografado - registro do usuário, atribuição de uma função de administrador a um usuário, exclusão de um usuário e sincronização.
Um atacante que obtenha acesso à rede à qual o tablet está conectado poderá escutar o tráfego de rede entre o ACS e o servidor e obter as informações necessárias para realizar os ataques.
Infelizmente, os desenvolvedores do dispositivo conseguiram fortalecer ainda mais a vulnerabilidade associada à falta de criptografia de dados: eles fizeram um procedimento de autenticação de dispositivo com vazamento completo.
Autenticação de dispositivo vulnerável
O único sinal da legitimidade de um dispositivo no servidor é o token que é passado no cookie. O token é definido quando o dispositivo é registrado pela primeira vez no servidor e, de acordo com nossos dados, nunca muda.
O valor do token é armazenado como um cookie. Fonte: Trend Micro
Dado que o token "secreto" é transmitido em texto não criptografado, qualquer cliente HTTP pode representar um ACS legítimo. Em nossos experimentos, usamos curl, um utilitário simples de linha de comando.
Por exemplo, é assim que cadastramos um novo usuário no sistema e colocamos uma imagem para ele:
O primeiro comando registra um usuário com o nome Bogus no servidor, o segundo define uma foto para ele. Fonte: Trend Micro
O arquivo userdata.post contém os dados que enviamos ao servidor via POST. No nosso caso, o arquivo contém os seguintes dados: Conteúdo do arquivo de imagem
a ser enviado ao servidor. Fonte: Trend Micro
Registrando um administrador com curl
Um administrador existente pode promover um novo usuário a administrador usando o console do dispositivo. O administrador atual deve primeiro fazer o login no dispositivo por meio de reconhecimento facial e, em seguida, acessar o console do sistema para iniciar o processo de promoção. Assim que o usuário é promovido ao nível de administrador, o dispositivo envia um relatório ao servidor, notificando-o da mudança de status.
Mas como qualquer usuário que possui o token pode simular o tráfego de rede legítimo entre o dispositivo e o servidor, nada o impede de executar o seguinte comando e tornar qualquer usuário um administrador:
Definir privilégio = 14 torna o usuário um administrador. Fonte: Trend Micro
Após a próxima sincronização do servidor e todos os dispositivos ACS registrados nele, o novo administrador será reconhecido em toda a rede do escritório.
Carregar todas as fotos do usuário
Os URLs das fotos armazenadas no servidor são previsíveis, portanto, listar todos os URLs e enviar as fotos é muito fácil. Nenhuma autenticação é necessária para acessar esses URLs.
Por exemplo, no seguinte URL, o servidor enviará uma foto de um usuário com o ID “11111”:
Para coletar imagens, você pode fazer um script simples que irá iterar através de IDs de usuário de “00000” a qualquer número e baixar todas as fotos disponíveis no sistema
Injeção de servidor falsa
Como toda a comunicação entre o dispositivo e o servidor é feita por HTTP, é relativamente fácil redirecionar todos os dispositivos AC para um servidor falso usando envenenamento ARP (Protocolo de Resolução de Endereço).
Depois que conseguimos que o dispositivo de destino se comunicasse com nosso servidor falso, pudemos enviar ao dispositivo as atualizações de que precisávamos durante uma de suas sessões de sincronização regulares. Essa técnica pode ser usada para uma variedade de ataques. Por exemplo, você pode deslizar dispositivos finais com a foto de um usuário para o qual deseja organizar o acesso ilegal às instalações de uma empresa.
Acesso pela foto de um visitante legal
Dado o número de opções de ataque possíveis, testar esse método já era um tanto exagero. Mas dada a simplicidade e disponibilidade de tal ataque mesmo para uma pessoa que está longe da tecnologia, ainda assim verificamos se seria possível enganar o ACS usando a fotografia de uma pessoa cadastrada no sistema com acesso ao escritório. E ficaram muito surpresos quando, depois de passar por várias opções, o ataque funcionou: a câmera ZKTeco FaceDepot acabou por apoiar as fotos mostradas no iPhone X e iPhone XS, mas se recusou a pular a mesma foto na tela dos smartphones iPhone 6, Samsung A10, Samsung S8, Samsung S9 , Samsung S10, Samsung S10 + e Samsung Note 10.
Recomendações para fabricantes
O dispositivo de controle de acesso ZKTeco FaceDepot não é o único testado em nosso estudo. Infelizmente, outros dispositivos também continham vulnerabilidades sérias, que lançavam sérias dúvidas se eles poderiam ser usados para criar um perímetro de acesso físico verdadeiramente seguro às instalações da empresa.
Todas as vulnerabilidades encontradas em dispositivos estão incluídas no Top 10 Web Application Security Risks , compilado pelo projeto OWASP:
- sem criptografia padrão e desabilitando a criptografia do lado do servidor;
- autenticação vulnerável e sistema de gerenciamento de sessão;
- versões desatualizadas do sistema operacional.
Para tornar os dispositivos de controle de acesso mais seguros, os fabricantes devem seguir estas diretrizes:
- — , ;
- ;
- — USB- ;
- , .