Root shell obtido em terminal de cartão de crédito

• Ao desmontar e analisar o firmware do terminal de pagamento Worldline Yomani XR usado na Suíça, foi possível entrar em um root shell digitando apenas root no console serial acessível pela escotilha traseira
• O terminal tinha proteção contra violação capaz de detectar abertura da carcaça, desconexão de contato entre PCBs, corte de trilhas em zigue-zague e danos à flex PCB ao redor do leitor de cartões, mas a exposição da porta de depuração criou uma via de ataque separada
• O firmware extraído da flash onboard incluía um sistema de arquivos não criptografado e rodava sobre Linux 3.6, Buildroot 2010.02, BusyBox, uClibc e o bootloader customizado Booter v1.7
• Funções de segurança como cartão, PIN, tela e teclado parecem ficar a cargo de um processador separado, mp1, e da imagem criptografada e assinada mp1.img, sem evidência de acesso direto a partir do Linux mp2
• A versão exata de firmware vulnerável não foi confirmada, e alguns dispositivos tinham o login root desativado, mas ainda existe uma superfície de ataque desnecessariamente grande em cenários onde alguém pode controlar fisicamente o terminal por um curto período

---

Worldline Yomani XR analisado

• O alvo da análise foi o terminal de pagamento Worldline Yomani XR, amplamente usado na Suíça
• Como a verificação da UI após o boot e a varredura de portas não mostraram nada de muito relevante, a investigação avançou para a desmontagem do hardware
• O interior é composto por várias PCBs
  • uma pequena placa para conectores externos
  • a placa principal
  • uma placa vertical com o slot de cartão instalado
• O SoC principal parece ser um ASIC customizado baseado em Arm dual-core, identificado no firmware pelo codinome “Samoa II”
• Segundo a documentação da Worldline, esse chip não é um rebranding de um chip pronto, mas sim um ASIC customizado
• Ao lado do SoC há uma pequena flash externa e RAM

Estrutura de proteção anti-violação do hardware

• Não foi encontrado um switch convencional de detecção de abertura da carcaça; em vez disso, a própria board-to-board interconnect era usada como mecanismo de detecção
• Entre as placas há uma Zebra strip sensível à pressão, de modo que as placas precisam ser parafusadas firmemente para manter o contato
  • só afrouxar alguns parafusos já pode interromper o contato e disparar um evento de violação
  • como a detecção precisa funcionar mesmo sem alimentação externa, é usada uma coin cell battery
• Áreas vulneráveis da PCB são cobertas por trilhas de detecção de violação em formato de zigue-zague
  • em uma invasão física, o rompimento de apenas uma trilha de cobre pode disparar a detecção de violação
• O slot de cartão fica dentro de uma carcaça interna separada, e a flex PCB ao redor dele atua como proteção anti-violação
• Após a remontagem, o terminal passou a mostrar apenas uma grande tela vermelha com “TAMPER DETECTED”, e nesse modo aparentemente não respondia a entradas externas

Extração da flash e recuperação do sistema de arquivos

• Como a exploração em runtime foi bloqueada, o flash chip onboard foi removido, fios foram conectados e seu conteúdo foi dumpado
• Ao contrário do esperado, o conteúdo dumpado não estava criptografado como um todo
• A flash usava uma disposição de ECC incomum
  • não seguia o padrão de 2048 bytes de payload + 64 bytes de ECC/spare
  • havia 3 chunks de dados de 694 bytes, e cada chunk era seguido por 10 bytes de ECC
  • os últimos 16 bytes da spare area pareciam ser metadados do sistema de arquivos YAFFS2
• Como a área de metadados era menor do que em um YAFFS2 típico, foi preciso modificar o sistema de arquivos para lidar com uma estrutura de metadados menor
• Depois de implementar um reader de sistema de arquivos compatível, o conteúdo foi extraído com sucesso

Sistema antigo baseado em Linux

• O sistema de arquivos extraído confirmou que o terminal executa Linux
• O sistema inclui componentes antigos
  • Linux kernel 3.6
  • Buildroot 2010.02
  • build de fevereiro de 2023
  • bootloader customizado Booter v1.7
  • script de init, BusyBox, uClibc
  • libcrypt 0.9.26
• Não foi possível confirmar quão recente era a versão de firmware dumpada, mas ela deve ter sido lançada após fevereiro de 2023

Root shell sem senha

• Depois de religar o flash chip com fios, o terminal voltou a inicializar mesmo exibindo a mensagem de violação
• Para ver o log de boot do Linux, foi usado um logic analyzer ao redor do conector de depuração, e atividade foi encontrada em um pad do conector de depuração não populado
• No console serial apareceu um prompt de login junto com o log de boot do Linux
  • no log de boot aparecia “Reset reason: Tamper”
  • também surgiam logs como dropbear is not present, verificação de atualização de firmware e inicialização do daemon de monitoramento da aplicação
  • ao final aparecia o prompt samoa login:
• Ao digitar root como login, o prompt de shell ~ # apareceu sem exigir senha
• Esse acesso não exigiu exploit chain nem brute-force de senha

Porta de depuração acessível externamente

• O acesso ao root shell não se limitava aos casos em que o interior do terminal era aberto
• A serial port podia ser acessada externamente por uma pequena escotilha na traseira do terminal
• Era possível conectar ao conector de depuração sem abrir o terminal e sem acionar a proteção anti-violação
• A avaliação foi de que, se alguém pudesse ficar com o terminal sozinho por um curto período, seria possível conectar à porta serial, fazer login, instalar malware e ir embora

Separação entre processador de segurança e Linux

• O root shell exposto não significa acesso imediato a dados de cartão ou PIN
• O sistema Linux é apenas uma parte da arquitetura geral, e não foram encontradas evidências de que display, teclado e leitor de cartão possam ser acessados diretamente pelo Linux
• A saída da tela também não parecia ser tratada diretamente por um driver de framebuffer; em vez disso, strings eram passadas ao binário display_tool, que então enviava mensagens entre processadores
• Funções sensíveis como cartão, entrada de PIN e exibição na tela parecem ser tratadas por um processador separado, o mp1
• O Linux executado no segundo processador, mp2, cuida de networking, atualização e lógica de negócio

Fluxo de boot e imagem segura

• O núcleo Linux aparentemente sempre inicializa, independentemente do estado de violação
• Depois disso, o Linux carrega na memória o bootloader seguro loadercode
• O loadercode verifica se a proteção anti-violação foi acionada
  • se uma violação for detectada, ele mostra a tela vermelha
  • se não houver problema, ele inicializa a imagem segura real, mp1.img
• O mp1.img fica dentro do sistema de arquivos Linux, mas aparentemente é criptografado e assinado por duas entidades
• A imagem segura que processa cartão, display e teclado estava devidamente criptografada e assinada

Cronograma de divulgação e incertezas restantes

• O cronograma de divulgação foi registrado assim
  • 14 de novembro de 2024: descoberta do root shell
  • 15 de novembro de 2024: reporte ao fabricante e aviso de divulgação após 90 dias
  • 18 de novembro de 2024: fabricante confirma o recebimento do reporte
  • 1 de junho de 2025: divulgação
• O root shell exposto representa uma superfície de ataque desnecessariamente grande, mas não foram encontradas evidências de que dados sensíveis como informações de cartão pudessem ser comprometidos por esse caminho
• Não foi possível determinar exatamente quais versões de firmware são vulneráveis
• Durante a pesquisa, também foram encontrados dispositivos com login root desativado
• Não foi possível confirmar em que momento o recurso de depuração entrou no firmware de produção, nem se o fabricante já o havia identificado e corrigido internamente

[GN⁺]

Opiniões no Hacker News

• É possível criar transações falsas de cartão de débito/crédito com um leitor de cartão USB de US$ 2
  As especificações são todas públicas e o protocolo também é documentado. Pelo que me lembro, o PDF tinha algo como 5.000 páginas, então era extremamente doloroso de ler
  Mas, para validar essa transação, é preciso enviá-la ao banco pela internet, e aí órgãos federais/FBI ou afins podem aparecer na sua porta
  O leitor de cartão em si quase não tem proteção real; na maioria dos casos é algo como um Linux pequeno com senhas péssimas. A proteção vem dos contratos e das regulamentações entre a loja e o banco

  • Não é correto dizer que leitores de cartão não têm proteção. Só binários assinados são executados, o sistema de arquivos executável é somente leitura, e o sistema de arquivos de dados fica com noexec configurado
    O login de root é desativado, usam busybox com muitos recursos removidos, e as chaves são carregadas de uma área segura na inicialização. A injeção da chave mestra só é possível durante o carregamento na fábrica, a própria inicialização também é segura até certo ponto, e, se for detectada adulteração, o chip é apagado
    Claro que, se for um terminal Android barato, sem certificação EMV, importado da Ásia, é bem provável que rode um Linux padrão com sistema de arquivos raiz de leitura/escrita, login de root e até sudo habilitado para o usuário que executa os apps. Pode também não haver detecção de adulteração, o espelhamento de tela pode não estar bloqueado, portas podem ser abertas e o busybox pode estar quase completo
    Como alguém que desenvolveu aplicações EMV para adquirência de cartões por alguns anos e ainda faz isso de vez em quando, até o modo de desenvolvimento exige que o fornecedor forneça um ID de desenvolvedor e é bastante bloqueado
  • A parte de que contratos e regulamentações entre a loja e o banco são o núcleo da proteção está correta
    É por isso que também estão erradas aquelas teorias da conspiração sobre alguém sair andando com um leitor de cartão portátil e roubando dinheiro de cartões por aproximação. Até dá para criar esse tipo de transação, mas o problema é o que acontece depois e as configurações necessárias antes disso
    Nem é certo que você conseguiria sacar o dinheiro antes de ser pego e bloqueado. Hoje em dia muita gente ativa notificações push de transações, então acho ainda mais difícil
  • Isso não é verdade. Terminais de estabelecimento têm hardware seguro embutido que armazena chaves do banco e das redes de cartões
    Se essas chaves vazarem, alguém pode se passar por uma transação legítima
  • Eu ficaria mais preocupado com um leitor de cartão em campo ser comprometido e permitir a leitura de dados reais de cartões em cache ou armazenados, ou com a instalação de malware de interceptação
    Neste caso específico parece difícil ou impossível, mas é por isso que pesquisa nessa área faz sentido
  • Você poderia explicar com um pouco mais de detalhe a parte de “é possível criar transações falsas de cartão de débito/crédito com um leitor de cartão USB de US$ 2”? Não quero dizer “me ensine como fazer”

• Não sei exatamente o que procurar, mas já tive a tentação de abrir um leitor Stripe M2 que tenho e ver o interior
  O problema é que, dos 36 leitores comprados, 7 “morreram”. Dois não mantêm carga, um não consegue escanear NFC e quatro exibem “tampered”. À primeira vista a taxa de perda é ruim, mas é preciso considerar a frequência de uso e a idade para ter o quadro completo
  Só que a resposta é ainda pior. Os dispositivos têm de 1 a 3 anos, e o total de dias de uso é de no máximo 9 dias. Ou seja, em um total de 9 dias de uso, 7 de 36 falharam de alguma forma. Mesmo durante transporte, todos ficam em um estojo rígido com inserto de espuma e um slot separado para cada leitor
  Por isso não sou grande fã do leitor M2, mas ele ainda é a melhor opção para mim
  [0] Como contexto adicional, nossa empresa processa pagamentos em festivais. Vamos até o local do evento e processamos pagamentos presenciais com iPad e leitores M2, enquanto a maior parte dos pagamentos acontece na web/no app. É por isso que, ao longo de 3 anos, há tão poucos “dias de uso”

  • Antes de guardar até o próximo evento, é melhor sempre deixá-los carregados. A maioria das baterias não gosta de ficar armazenada por muito tempo com baixo nível de carga
    E é bem provável que a detecção de adulteração também precise de uma bateria funcionando corretamente

• Pode ser que, quando o lacre de adulteração seja acionado, um shell de root seja aberto
  Ou seja, o sistema pode estar em um modo seguro, com as chaves criptográficas necessárias para operar, ou em um modo não seguro, com um shell de root aberto para depuração e análise de falhas, mas no processo de transição as chaves privadas importantes são apagadas

  • Eu também imaginei isso. Talvez seja até possível gravar novas chaves na flash para tornar o dispositivo utilizável novamente
    Fiquei curioso para saber se dá para conseguir um terminal de verdade. Se eles estão sendo substituídos e desaparecendo, talvez não seja tão difícil achar um usado

• Para quem se empolga fácil, vale acrescentar que há o trecho: “o shell de root exposto não parece ser um risco tão grande quanto se temia inicialmente. Não encontramos evidências de que dados sensíveis, como informações de cartão, possam ser comprometidos dessa forma”
  Ainda assim, é uma boa leitura para arquitetos de segurança

  • Se você tem acesso físico ao terminal e chega até root, mas ainda assim não consegue ler o número do cartão de crédito, isso é muito suspeito
    Em segurança, acesso físico — e, em menor grau, acesso root — é praticamente equivalente a um hack bem-sucedido

• Se o Linux comprometido for quem decide entre carregar o código do “modo comprometido” e o sistema de segurança mp1, isso parece uma rota que vale investigar
  Dizem que o bootloader em si é seguro, mas, dependendo de onde ele é realmente executado, se for carregado dentro de um ambiente comprometido, isso pode não significar muita coisa
  Talvez dê para ver o coprocessador como uma espécie de Secure Enclave, mas o fato de o Linux poder carregar e executar um bootloader separado é preocupante

  • Não é possível carregar um bootloader separado. Tentei adulterar o bootloader “seguro” chamado loadercode, mas ele não inicializou
    Por isso suspeito que um terceiro componente, provavelmente a boot ROM, faça essa verificação
    Além disso, o Linux parece sempre carregar loadercode e mp1.img, independentemente do estado de adulteração. O caminho de código diferente conforme o estado de adulteração parece ser escolhido dentro do loadercode, que é protegido por integridade

• Se você quiser um modo mais fácil, basta olhar para os terminais de cartão baseados em Android que estão saindo hoje em dia
  Especialmente porque o PIN é digitado diretamente na tela, há uma chance bem maior de ser gratificante

  • O controlador de toque normalmente fica conectado a um multiplexador controlado pelo processador de segurança
    Ao inserir dados sensíveis como PIN ou PAN, a saída do controlador de toque contorna o sistema operacional da família Android responsável pela GUI e é roteada diretamente para o processador de segurança
  • Mesmo que os dados do PIN sejam exibidos no touchpad, eles continuam criptografados e usam uma interface de usuário controlada por firmware executado em uma zona confiável
    Por isso, as aplicações intermediárias acessíveis nesse tipo de ataque não conseguem ver o PIN
  • Fazendo isso, provavelmente daria para obter o PIN com bastante facilidade, mas, se as partes importantes forem projetadas da mesma forma para passar ao coprocessador de segurança, ainda não há muito que se possa fazer com o cartão
    Cartões modernos executam muitas operações criptográficas dentro do próprio cartão para impedir esse tipo de ataque
    Esse ataque só funcionaria em terminais em que, entre as opções de pagamento, apenas o leitor de tarja magnética ainda estivesse ativo; e, em um terminal desses, o alerta de skimmer já deveria acender antes mesmo de aparecer o prompt de PIN
  • Não sei quais terminais Android são usados em cada região, mas, na Índia, parecem rodar Android Oreo. O suporte acabou em janeiro de 2021

• Excelente. Gosto de pensar em maneiras de contornar e explorar restrições de hardware, como esse tipo amplo de proteção contra adulteração, mas eu achava que, uma vez acionada, era fim de jogo
  Mas não é necessariamente assim, e ainda havia muitas partes interessantes para investigar. Dito isso, é claro que a parte de segurança ser desativada corretamente faz sentido. Se não fosse assim, eu perderia toda a confiança nos projetistas

  • Para o processador reforçado, isso ainda pode ser verdade. O texto original também diz que não foi essa parte que foi comprometida aqui
    Apenas strings de texto são passadas para um binário chamado display_tool, e esse binário parece enviar mensagens entre processadores. O mesmo vale para o teclado e o leitor de cartões. Não encontrei evidências de que esses periféricos sejam diretamente acessíveis pelo Linux
    Em vez disso, parece que um processador totalmente separado chamado mp1 cuida das tarefas “seguras”, como processamento do cartão, entrada do PIN e exibição de informações na tela. O Linux “não seguro”, que roda em um segundo processador, mp2, lida apenas com rede, atualizações e lógica de negócio
  • Pela descrição, parecia que o lado Linux poderia ter algum papel no tratamento de eventos de adulteração
    Ainda assim, espero que a arquitetura apenas permita ver que houve adulteração. Caso contrário, seria possível primeiro obter um shell root e depois ter a chance de impedir que o evento de adulteração fizesse a exclusão das chaves de segurança

• Ao ler sobre todos os mecanismos de detecção de adulteração do dispositivo, fiquei curioso sobre qual seria a maneira mais fácil de acionar o modo de adulteração
  Afinal, se fosse possível fazer isso com apenas alguns desses dispositivos, poderia ser um ataque eficiente de negação de serviço contra uma loja em que a maior parte, ou a totalidade, dos pagamentos passa por esses terminais

  • Deixar cair no chão ou jogar água

• É interessante investigar esse tipo de dispositivo, mas não entendo por que abriram logo de cara e acionaram o estado de adulteração. Será que não sabiam que a maioria dos leitores tem esse mecanismo?
  Testes reais feitos no estado de adulteração podem não ter significado. Pode ser que, para fins de inicialização, entrar no estado de adulteração abra um shell
  Pelo que parece, abrir o dispositivo deveria ser algo a tentar por último

  • Senti que primeiro precisava ter uma noção do que eu estava lidando: o hardware, qual SoC era, interfaces, flash e coisas do tipo
    Caso contrário, era tudo muito às cegas. Claro que, olhando em retrospecto, eu poderia simplesmente ter conectado no conector de debug e pronto
    E também consegui um shell em um segundo dispositivo que não tinha sido adulterado

• Esse tipo de dispositivo está em toda parte na Europa. Não sei quanto à Suíça, mas, em boa parte da Europa que conheço, as pessoas não possuem ou não usam muito cartões de crédito
  Eu chamaria isso de POS, ou seja, sistema de ponto de venda. Esses dispositivos conseguem ler todos os tipos de cartão. De qualquer forma, ótimo texto

  • Na verdade, usam bastante. Não gosto de carregar aquela pilha de cartões na carteira. Já tenho tantos cartões que nem são de pagamento, por vários motivos, que não sobra espaço para algo como um cartão de débito
    Também não vejo o atrativo de colocar ainda mais coisas no celular ou no smartwatch. Prefiro relógio mecânico, e perder o celular já é um desastre grande o suficiente do ponto de vista da privacidade. Claro, esse é o meu caso