Obtendo um shell root em um terminal de cartão de crédito
(stefan-gloor.ch)- Foi feita uma tentativa de engenharia reversa do terminal de cartão de crédito Worldline Yomani XR para pesquisa de segurança
- Durante a desmontagem interna, foi descoberto que, embora o recurso de detecção de intrusão física estivesse bem implementado, havia um problema de software em que um shell root ficava exposto na porta serial externa
- Por meio de dessoldagem da memória, extração e análise do firmware, foi confirmada a estrutura de um sistema baseado no kernel Linux 3.6 e a presença de componentes muito antigos
- Foi demonstrado que, pela porta de console serial, era possível obter privilégios de root e instalar código malicioso facilmente sem desmontar o dispositivo
- Todo o trabalho crítico relacionado a pagamento e autenticação é realizado em um processador de segurança separado, portanto o risco real de exposição de dados importantes não é alto
Visão geral do projeto
- Este projeto se concentra no processo de engenharia reversa do modelo Worldline Yomani XR com fins de pesquisa de segurança de terminais de pagamento
- Esse modelo, amplamente usado em toda a Suíça, está descontinuado atualmente, mas ainda segue em uso em várias grandes redes varejistas e pequenas lojas
Primeiras observações e desmontagem do hardware
- Após investigações básicas como navegação pela interface e varredura de portas, foi iniciada a desmontagem do hardware
- Foram observados vários PCBs, uma carcaça bem projetada em termos de materiais e um processador Arm dual-core baseado em ASIC customizado, indicando um nível considerável de segurança de hardware
- O principal SoC é um ASIC dedicado com o codinome Samoa II, com flash e RAM externos
Detecção de intrusão e proteção contra violação
- Mesmo sem abrir a carcaça, eventos de intrusão podiam ser detectados apenas por falha na conexão da placa por detecção de pressão (Zebra strip) ou pelo afrouxamento de parafusos
- A detecção era mantida mesmo em situações de corte de energia graças à bateria
- Na PCB principal, trilhas em zigue-zague, assim como a PCB flexível ao redor do leitor de cartões, acionavam detecção de intrusão se fossem danificadas
- Após uma breve desmontagem e remontagem, por causa da detecção de intrusão, o dispositivo passou a exibir apenas a tela vermelha "TAMPER DETECTED" e não respondia a entradas externas
Extração de firmware por chip-off
- O flash onboard foi dessoldado e conectado diretamente para extrair o firmware
- Os dados não estavam criptografados, mas foi identificada uma estrutura de ECC incomum e a disposição de metadados do sistema de arquivos YAFFS2
- Foi implementado um leitor do sistema de arquivos para obter a lista completa de arquivos
- O sistema usa kernel 3.6 baseado em Buildroot de 2010, além de uClibc, busybox e várias bibliotecas antigas
Como o shell root foi encontrado por acaso
- Após a análise do firmware, o flash foi reconectado e os sinais foram capturados com um analisador lógico ao localizar as linhas do console serial
- Junto com os logs de boot, foi exposto um prompt de login
- Ao digitar
root, era possível entrar imediatamente em um shell root sem senha - Na prática, essa porta serial é acessível externamente apenas abrindo a tampa
- Um atacante poderia se conectar rapidamente e injetar malware sem precisar desmontar o terminal
Quão grave é o problema?
- A análise do boot e da configuração do sistema mostrou que o Linux é responsável apenas por rede, atualizações e parte da lógica de negócio
- Pagamento com cartão, entrada de PIN, display e todas as funções relacionadas à segurança são gerenciados por um processador mp1 separado
- O Linux (mp2) sempre inicializa primeiro e, depois disso, uma imagem assinada e criptografada é carregada no núcleo seguro por um bootloader seguro
- Internamente, a proteção do núcleo seguro continua funcionando corretamente, e dados centrais de segurança não vazam por causa da exposição do shell root
Cronograma de divulgação e reporte
- 14 de novembro de 2024: descoberta do shell root
- 15 de novembro de 2024: notificação ao fabricante com previsão de divulgação em 90 dias
- 18 de novembro de 2024: confirmação de recebimento do reporte por parte do fabricante
- 1 de junho de 2025: divulgação do projeto
Conclusão
- A exposição de um shell root por meio da porta serial externa é claramente uma superfície de ataque desnecessária e um erro de engenharia
- Ainda assim, graças ao projeto com separação do processador de segurança, o risco real de exposição de dados de pagamento é baixo
- É possível que a permissão de login root tenha sido aplicada por engano no firmware de produção, ou que isso varie conforme a versão
- Durante a pesquisa, também houve dispositivos em que a função de login root estava totalmente desativada
- É possível que esse problema já tenha sido reconhecido e corrigido internamente
Este projeto deixou vários resultados interessantes e também voltou a mostrar o valor de uma exploração profunda de firmware
1 comentários
Comentários do Hacker News
Um recado para os desenvolvedores mais jovens: é esse o sentido de “hacker” em “Hacker News”; recomendação deste post como um exemplo que disseca de forma acessível, passo a passo, uma jornada hacker típica; se quiser conhecer casos parecidos, vale dar uma olhada no Hack-a-day; o autor parece ser alguém muito curioso e com fundamentos bem sólidos; no fundo, trata-se de pesquisar datasheets de chips, dessoldar sem danificar, religar com fios se for memória, improvisar e aprender por tentativa e erro; como dica, na próxima talvez valha considerar uma câmera pinhole ao fazer furos rasos para evitar marcas de violação; e fica a observação de que teria sido realmente interessante se o autor também tivesse conseguido passar pelas verificações anti-violação e fazer o aparelho funcionar normalmente
Explicação de que o termo hacker não se limita à segurança de computadores, mas tem um significado bem mais amplo e até uma definição filosófica; citação do Jargon File, organizado por Guy Steele e outros, para apresentar definições de hacker como “alguém que gosta de aprender os detalhes de sistemas programáveis e ampliar seus limites”, “alguém que gosta de programar com entusiasmo”, e até “um especialista muito habilidoso em determinado programa”; resumo de que o termo é usado em vários sentidos; suposição de que o fundador do Hacker News, PG, provavelmente escolheu o nome tendo essa definição mais ampla em mente; adendo de que a história do termo também deveria mencionar The UNIX-HATERS Handbook
Concordância total com a primeira frase; comentário de que, se surgir mais um wrapper de LLM hoje em dia, já vai dar nos nervos
Opinião de que, só porque este site surgiu de uma incubadora de startups de VC, não faz sentido presumir que o nome se refira a hacking de segurança; interpretação de que provavelmente está mais próximo do hacking no estilo startup de “move fast and break things”, isto é, despejar código rapidamente e ir rompendo obstáculos
Elogio de alguém que ficou anos só lendo e só recentemente criou conta para comentar, dizendo que posts como este, cheios de informação e capacidade de execução, é que mostram o espírito “hacker” do Hacker News
Confissão de que foi a primeira vez que deu upvote em um post por ele realmente ser sobre hacking; normalmente só dá upvote em comentários, mas este foi uma exceção
Apresentação de que é possível simular transações falsas de cartão de crédito/débito com um leitor de cartão USB de US$ 2; explicação de que todas as especificações e protocolos são vastos, mas públicos, então dá para implementar só lendo a documentação; porém, para que uma transação real seja aprovada, é preciso enviar os dados ao banco pela internet, e isso inevitavelmente faria as autoridades aparecerem rapidamente (por exemplo, o FBI); explicação de que o leitor de cartão em si quase não tem proteção alguma (a maioria usa Linux e senhas fracas), e que a segurança vem dos contratos e regras entre lojistas e bancos
Contestação da afirmação de que leitores de cartão “não têm proteções”; explicação detalhada de que, na prática, eles só executam binários assinados, o sistema de arquivos executável é somente leitura, o sistema de arquivos de dados tem flag
noexec, login root é desativado, o busybox vem com funcionalidades reduzidas, as chaves são carregadas de uma área segura no boot, a inserção da chave mestra só pode ser feita na fábrica, o próprio boot é muito seguro e, se houver detecção de violação, o chip se apaga; relato de experiência de alguém com desenvolvimento EMV dizendo que terminais baratos e não certificados podem quase não ter segurança, mas os terminais reais são praticamente totalmente travadosReconhecimento de que a parte sobre “a única segurança são as regras entre a loja e o banco” está correta; por isso, a opinião de que teorias conspiratórias sobre gente roubando dinheiro de cartões contactless com leitores portáteis são difíceis de colocar em prática; mesmo que alguém consiga criar uma transação, por causa dos passos seguintes e da preparação prévia, tirar o dinheiro com segurança é quase impossível; sobretudo hoje, em que notificações push de transação aumentam a chance de a fraude ser percebida
Opinião de que o cenário mais preocupante é o de um leitor de cartão ser hackeado em campo para ler dados de cartão de crédito em cache ou receber malware do tipo interceptor, e que é por isso que pesquisa nessa área é importante
Explicação de que a afirmação de que uma transação precisa ser enviada ao banco pela internet para ser aprovada não está correta; observação de que bancos não mantêm uma API aberta na internet para processar transações de cartão
Discordância da ideia de que a segurança dos leitores de cartão é fraca; explicação de que terminais de loja de verdade incluem hardware seguro para armazenar com proteção as chaves de bancos e das redes de pagamento; acrescenta que, se essas chaves vazarem, aí sim seria possível forjar transações legítimas
Relato de alguém que comprou e usou 36 leitores Stripe M2 e viu 7 quebrarem: 2 com bateria que não carrega, 1 sem conseguir ler NFC e 4 que morreram com erro de “violado”; comentário de que, à primeira vista, a taxa de falha parece grave, mas é preciso considerar o contexto de dias de uso e idade dos aparelhos; a queixa é de que o mais grave é que, mesmo tendo usado leitores com 1 a 3 anos de idade por apenas 9 dias no total, ainda assim 7 falharam; diz que, no transporte, cada unidade fica em estojo rígido com espuma, então não seria problema de armazenamento; mesmo assim, a realidade é que o Stripe M2 ainda é a opção mais utilizável e por isso continuam usando; também acrescenta que a empresa cuida dos pagamentos de festivais, então usa muita unidade por pouco tempo
Imaginação de que, quando a proteção contra violação física é acionada, um shell root talvez possa ser aberto; isto é, ou o sistema entra em um modo de segurança que ainda tem todas as chaves criptográficas necessárias, ou então abre um shell root para depuração/análise de falhas; pedido de que, nesse caso, ao menos as chaves privadas importantes tenham sido apagadas automaticamente
Recomendação do post original, junto com a citação de que “mesmo se um shell root for aberto, os dados do cartão não ficam em risco”, como material que designers de segurança deveriam ler obrigatoriamente
Opinião de que o Linux (já violado) decide se vai carregar o código de “compromised mode” ou o sistema de segurança mp1; observação de que, por mais seguro que o bootloader seja, tudo depende do ambiente em que ele efetivamente roda; preocupação de que o coprocessador possa fazer o papel de Secure Enclave, mas, se o Linux puder carregar um bootloader separado, isso seria um problema sério de segurança
loadercodeemp1.imgjuntos, independentemente do estado de violação, e que o desvio conforme o estado de violação foi projetado para acontecer dentro doloadercode, protegido por integridadeRecomendação para iniciantes tentarem primeiro os terminais de cartão de crédito mais novos baseados em Android; provocação de que é ainda mais divertido porque o PIN é digitado na tela sensível ao toque
Explicação de que o controlador de toque normalmente fica ligado a um MUX controlado por um processador seguro, e que, durante a entrada de informações sensíveis, o toque vai direto para o processador seguro, sem envolvimento do sistema operacional baseado em Android
Ênfase em que, mesmo quando aparece no touchpad, os dados do PIN são gerenciados por firmware executado em trust zone e permanecem criptografados; os apps no meio do caminho não conseguem ver o PIN
Previsão de que, mesmo hackeando esses terminais Android, se o desenho de segurança for o mesmo, ainda assim não haveria informação útil na prática porque o próprio cartão faz criptografia complexa; opinião de que esse tipo de ataque só funcionaria quando restassem apenas leitores de cartão de crédito, e que, nesse caso, o terminal por si só já seria um sinal de alerta de skimmer para o usuário
Menção breve, considerada interessante, de que terminais Android usados na Índia ainda rodam Android Oreo (suporte encerrado em janeiro de 2021)
Reação de estranheza ao fato de a análise do interior do terminal já começar abrindo-o e disparando o modo de violação; suposição de que talvez o autor nem soubesse que a maioria dos leitores detecta violação; comentário de que testar em modo violado pode reduzir a utilidade dos resultados, e curiosidade se o shell aberto após a violação não serviria justamente para inicialização; por fim, conselho para pensar de novo se realmente faz sentido abrir o aparelho logo de cara
Elogio de que é surpreendente como, apesar de uma proteção anti-violação tão rigorosa, ainda restam muitos caminhos de contorno e vestígios interessantes; avaliação de que a parte de segurança ter sido paralisada de forma segura é exatamente o comportamento esperado do projeto
Ênfase em que o processador reforçado (
mp1) continua inviolado; explicação de que, na prática, apenas strings são passadas ao bináriodisplay_toolpara trocar mensagens com o outro processador; leitor de cartão, teclado e afins não podem ser acessados diretamente pelo Linux; o processadormp1, completamente separado, cuida de todo o tratamento “seguro”, como cartão, entrada de PIN e exibição de tela, enquanto o Linuxmp2trata só de rede, atualizações e lógica de negócioCenário levantado de que o lado Linux pode até detectar e tratar o evento de violação, mas, se as chaves de segurança só puderem ser apagadas depois que a violação for completamente detectada, então pode haver risco de alguém obter root shell antes e depois contornar a violação
Comentário de que esses terminais estão espalhados por toda a Europa; talvez não na Suíça, mas em muitas regiões europeias que a pessoa conhece, cartões de crédito parecem pouco comuns; em compensação, terminais POS leem todo tipo de cartão, então chamá-los de “sistemas POS” seria mais apropriado; ainda assim, o post foi divertido de ler