Sobre a vulnerabilidade recente em caixas eletrônicos Diebold Nixdorf

*NT – Notas do Tradutor

Traduzido de: https://habr.com/en/company/pt/blog/589291/ com comentários inseridos por Fábio Martins

v2.6

[ NT: O domínio de certas tecnologias dá ao Brasil garantia de poder frente a outras nações-estado, inclusive em relação a algumas potências chamadas de primeiro mundo, que frequentemente recorrem a “fuga de cérebros” para tentar manter o status-quo. Assim como ocorre com a tecnologia de exploração de petróleo em águas profundas e ultraprofundas, sim, também estamos na crista da onda em outras áreas. A criptografia assimétrica forte, exerce aqui um papel importantíssimo, o de não deixar cair em mãos erradas os ativos de grande valor conquistados e criados, que devem servir apenas ao nosso crescimento, guardados com segurança física, fora da rede e criptografados. Não é futuro, é presente. ]

[ NT: Também faço a engenharia reversa dos ATMs, e produzo código para a exploração dos mesmos, tanto para a parte de hardware quanto a de software, sempre com contrato e NDA assinado pelo cliente, que precisa ter as autorizações necessárias do(s) fabricante(s) ]

Isenção de responsabilidade: Este artigo é publicado apenas para fins informativos e não é, de forma alguma, um guia para ação. As vulnerabilidades descritas no artigo foram descobertas pelo autor como parte do projeto aprovado pelo fabricante do ATM. Neste ponto, eles foram corrigidos pela Diebold Nixdorf, que foi notificada pela Positive Technologies de acordo com os princípios de divulgação responsável. Como um elemento adicional de proteção, o fornecedor foi recomendado para habilitar a autenticação física para o operador durante a instalação do firmware, a fim de garantir que as alterações no ATM sejam feitas por um funcionário e não por um invasor.

Olá! Há algum tempo, a Positive Technologies publicou a notícia de que os ATMs fabricados pela Diebold Nixdorf (anteriormente conhecido como Wincor), ou mais especificamente, os terminais RM3 e os dispensadores de notas tipo CMDv5, continham uma vulnerabilidade que permitia aos atacantes sacar dinheiro e fazer upload de firmware modificado (vulnerável). E como meu ex-colega Alexei Stennikov e eu estávamos diretamente envolvidos na descoberta dessa vulnerabilidade, gostaria de compartilhar alguns detalhes.

Introdução

Em primeiro lugar, acho que devo dizer brevemente o que é um caixa eletrônico, como funciona e o que exatamente são os dispensadores de notas. Em geral, um ATM é um sistema bastante complexo, que consiste em duas partes principais: superior e inferior.

[ NT: O setup era assim antigamente. Nos dias de hoje, depende do país, e varia muito de fornecedor para fornecedor. Em 1 hall de banco com 20 caixas eletrônicos, pode haver 4 diferentes modelos, facilmente. ]


A parte superior era um PC normal, que na maioria das vezes fica na vertical. São muitos os dispositivos USB conectados a ele: câmeras, impressoras, leitores de cartões e, por fim, o dispensador de notas, que fica na parte inferior. O PC na parte superior (que, aliás, é considerado inseguro) costuma ser o alvo principal dos ataques de malware. Mas não se trata de nós – malware é ruim, [ NT: porém interessante ]! Então, vamos ver lá embaixo, do cabo USB até a parte inferior do ATM, onde podemos analisar …

A parte segura (também conhecida como cofre ou dispensador de notas) – uma parte protegida do caixa eletrônico. Ela está trancada com uma chave, que apenas os abastecedores de dinheiro possuem [ NT: Geralmente os vigias do carro-forte, os técnicos de manutenção ]; essa parte não é feita de plástico (ao contrário da parte superior) e geralmente é reforçada com concreto, aço ou montada em uma parede. E há algo no cofre que é a razão pela qual os caixas eletrônicos são hackeados – notas de banco. Eles são organizados por denominação em cassetes, cada um dos quais também é trancado com uma chave. O dinheiro é retirado dos cassetes por meio de um sistema de correia (e os NCRs usam ventosas), segue pela esteira até a porta de saída e é extraído pelo usuário.

Portanto, todo esse sistema complexo de sensores (usados para avaliar a espessura, número e amassamento das notas), esteiras, portas de saída e cassetes é controlado pela placa de controle do dispensador de notas (ou mais simplesmente, o dispensador). A placa possui um processador, memória e outros elementos de um dispositivo independente; além disso, há um código que controla tudo. E é aí que acabamos de ver o cabo USB.

Por que os criminosos invadem o dispensador em vez do PC, e o que os ataques de caixa preta têm a ver com isso?


Uma boa pergunta essa. Se olharmos da perspectiva de um invasor (o que é melhor não), a desconexão de um dispositivo USB (o distribuidor) do computador ATM será exibida apenas como uma linha nos registros do computador, e os registros do dispensador de notas não conterão nenhuma informação significativa (se comparado com os comandos executados no console do invasor).

[ NT: Muito cuidado nessa hora ! Alguns sistemas atuais enviam relatório de desconexões “incomuns” de alguns dispositivos ligados ao ATM – um “alarme” vai diretamente para a central de segurança, por isso, em um determinado pentest, houve a necessidade de injeção de código em memória, um patch em memória nas instruções assembly do processo que fazia essa notificação, para desabilitar essa capacidade do software do Banco. ]

Algum tempo atrás, os dispensadores de notas eram frequentemente explorados via ataques de caixa preta. Durante esse tipo de ataque, o criminoso, tendo uma vez capturado o tráfego de retirada de dinheiro USB / COM em um dispositivo, poderia usá-lo em outro, hackea-lo e obter o dinheiro. Hoje em dia, provavelmente ninguém será capaz de fazer isso, porque as técnicas anti-caixa negra são usadas em todos os lugares: por exemplo, chaves de rolagem de sessão para criptografar o tráfego USB e o uso de criptografia em quase todos os estágios. Agora, apenas um computador ATM pode trabalhar com essa criptografia, então, na maioria das vezes, um invasor não pode mais entrar no tráfego

[ NT: Ainda existe uma variação deste tipo de ataque, que não foi consertada em alguns modelos. ]

Mas então este artigo não existiria, nem as notícias que mencionei. Havia uma pequena vulnerabilidade em nosso projeto (felizmente, ela já foi corrigida). Leia sobre isso abaixo.

O que o tornou vulnerável?


Antes de começar, explicarei resumidamente do que se trata a vulnerabilidade e, em seguida, passarei aos detalhes.

Em primeiro lugar, deve-se dizer que o firmware é criptografado com chaves que são conhecidas apenas pelo fornecedor. Um invasor pode explorar as vulnerabilidades descritas pela Positive Technologies (uma em cada dispositivo) para fazer upload do firmware para o dispensador de notas sem saber as chaves de criptografia (elas serão mencionadas abaixo como KEY0 e KEY1). Ou seja, tendo um código limpo, um invasor pode modificá-lo como quiser, criptografá-lo novamente, fazer upload para o caixa eletrônico e, em seguida, retirar dinheiro, ignorando os algoritmos de criptografia de tráfego USB existentes. Bem, agora vamos passar aos detalhes …

Final de 2017, o projeto começa


[ NT: O Brasil está tão mais avançado nas tecnologias de proteção ao ATM (provavelmente devido às tentativas de explorá-los), que as técnicas utilizadas no Brasil há 10 anos atrás, ainda funcionam em vários modelos dos EUA e Europa. Caixas-Eletrônicos não são trocados como um desktop normal. Permanecem no mesmo lugar por anos, devido a custos. ]


Como parte do projeto em um banco, Alexei e eu recebemos dois arquivos: um tinha a extensão .BTR (bootloader) e o segundo tinha a extensão .FRM (firmware). Os arquivos tinham cabeçalhos claros, mas ao mesmo tempo o conteúdo era completamente incompreensível. Tentamos todos os tipos de formas de descriptografar o conteúdo (ficou óbvio que estava criptografado), mas sem sucesso. O projeto poderia ter terminado ali, e os arquivos permaneceram no disco rígido por vários meses até que o espertinho Alexei decidiu procurar uma placa de controle do dispenser no eBay. Como você deve ter adivinhado, Alexei encontrou a placa lá e, depois de um tempo, ela estava sobre a mesa.

Ter uma placa controladora do hardware a ser analisado é uma bênção, não ter um é uma maldição


[ NT: A experiência com os serviços prestados a diversos clientes ao longo dos anos, dá a capacidade de ter a lista completa de fabricantes, marca, modelo e versão de diferentes partes dos caixas eletrônicos, de algumas instituições. Alguns ATMs são verdadeiros “franksteins”. Se em foguetes europeus, vemos falhas de software causarem centenas de milhões de euros em estragos, com suporte de times que possuem uma grande quantidade de engenheiros com PHD, acreditar que sistemas bancários custando apenas algumas dezenas de milhares de dólares são imunes é, no mínimo, inocência. ]

Após tocar os pinos da placa, encontramos o conector JTAG, que estava localizado bem ao lado do processador principal. Além do principal, havia mais dois processadores na placa, cuja finalidade não era muito clara para nós: CollectorBooter e DispenseBooter. No entanto, a memória de todos os três processadores foi despejada para análise posterior.

Bem, não é grande coisa. Mas o que viria a seguir? Decidimos tentar fazer algo a respeito do firmware – tínhamos seus arquivos criptografados, lembra? E embora tivéssemos problemas, foi muito mais agradável trabalhar com o firmware em sua forma pura.

Software do fornecedor

Muitas vezes, seja para fins de diagnóstico ou para trabalhar com um caixa eletrônico, os fabricantes escrevem programas especializados que podem ser usados para realizar tarefas padrão e algumas tarefas não documentadas que raramente são usadas. Por exemplo, atualizando o firmware do dispensador.

[ NT: No início do hacking de ATMs, apenas esses softwares de teste/diagnóstico faziam funcionar os ataques caixa-preta ]

Esse software também estava em nosso projeto. E não foi escrito em algum tipo de BASIC ou C ++, mas na boa e velha linguagem Java (e respeitada por qualquer engenharia reversa). Com ele, você pode descompilar ou remontar as coisas, se necessário.

Depois de pesquisar em arquivos JAR, descobrimos uma função que carregava arquivos de firmware para o controlador. Infelizmente, ele não descriptografou os arquivos, mas nos deu uma boa oportunidade de depurar esse processo. Conectando o depurador ao JTAG e executando o upload do firmware, de alguma forma conseguimos encontrar o local responsável pela descriptografia. Vamos conversar a respeito disso.

Criptografia de arquivos de firmware

O algoritmo de criptografia era um XTEA normal, mas com um delta bastante incomum: 0xF27716BA. Não sabemos como foi gerado ou se era seguro ou não. Mas uma coisa era certa: não dá para pesquisar no Google.

Os seguintes dados de entrada foram usados como a chave de criptografia XTEA:

● As primeiras cinco dwords imediatamente após o nome do firmware especificado no cabeçalho (nós as chamamos de Header-Dwords)

● Chave externa KEY0, 8 bytes de comprimento (ainda não está claro de onde veio)

● Chave externa KEY1, 16 bytes de comprimento (também não sabíamos onde encontrá-la)

Depois de um tempo, encontramos um trecho de código que extraiu KEY0 e KEY1. Descobriu-se que eles estavam localizados em uma área especial no ponteiro 0x64000000, que não muda de local. A seguir, fizemos um dump desta área e extraímos ambas as chaves de lá. Ao usar essas chaves em um descriptografador furreca, obtivemos … Não, não o firmware.

Arquivos AP32

Foi aPLib. Aqueles cujo trabalho diário é reverter malware certamente reconhecerão esse nome, uma vez que esse algoritmo de compactação é (foi) muito usado por desenvolvedores de malware.

Então, nós obtivemos muitos arquivos, e todos eles iam um após o outro. Se você juntar os blocos de dados descompactados, obterá o firmware completo. Parece que há motivo para comemorar? Não tão rápido. Ao tentar alterar algo no firmware (por exemplo, uma string), após empacotá-lo e criptografá-lo, o dispositivo se recusou a aceitar nosso firmware. Então, houve uma verificação de integridade em algum lugar.

Autoassinatura

O nome desta seção fala por si. Sim, encontramos o código que verificou a assinatura do firmware e, curiosamente, o próprio firmware tinha tudo o que era necessário para verificar sua integridade, ou seja, a chave pública e os próprios dados assinados.

Como algoritmo de verificação de assinatura, o RSA foi usado com um expoente igual a 7, e a contagem de bits da chave foi determinada pelo tamanho da parte pública N. Descobriu-se que se você ajustasse os deslocamentos em que a assinatura e a chave pública foram escritos, você pode definir quase qualquer comprimento.

Isso foi o que fizemos. Em vez dos 2048 bits originais (acredito que sim), inserimos com sucesso uma chave de 512 bits.

Carregando o firmware modificado

Sim, podemos fazer isso agora. Aqui, acho que devo contar com mais detalhes o que é o upload do firmware. Para começar, vamos abrir o gerenciador de dispositivos e ver o que é exibido lá durante a operação normal do controlador:

E é assim que a lista fica quando o dispositivo está sendo atualizado:

Este último dispositivo aceita os arquivos. E usa o protocolo Device Firmware Update (DFU), que poderíamos ter entendido mesmo sem ter a placa de controle. Acontece que no final de cada arquivo de firmware existe uma determinada estrutura que contém a tag UFD.

Primeiramente é enviado ao dispositivo o comando de protocolo DFU_DETACH, em seguida é executado o comando USB UsbCyclePort, que habilita a interface que aceita o firmware. Quem já trabalhou com este protocolo dirá que também possui o comando DFU_UPLOAD (no caso, “download”), mas não foi implementado em nosso projeto.

Executando o firmware

Depois de fazer o upload do firmware para o dispensador, ele é descriptografado, descompactado, sua assinatura é verificada e, em seguida, o firmware é gravado na memória flash.

Retirada de dinheiro?


[ NT: Apesar da “boca” de onde sai o dinheiro ter a capacidade de “cuspir” umas 40 notas, em testes de laboratório, observei entupimento. Tente “cuspir” apenas 20 notas de cada vez para ter mais sucesso nas operações e não inutilizar o ATM. ]

Não, ainda não. Antes de receber o dinheiro, tivemos que descobrir como enviar comandos para o dispensador de notas. Depois de nos aprofundarmos no código Java, conseguimos encontrar arquivos JAR especiais responsáveis ​​pelo autoteste, ou seja, por testar os componentes do dispensador. A partir deste código, conseguimos descobrir o seguinte:

Um smartcard estava envolvido na interação do computador ATM e o dispensador (há muito tempo estava visível no quadro).

Um módulo de plataforma confiável (TPM) foi usado.

O armazenador do TPM foi usado para armazenar contadores de sessão (leia mais abaixo), certificados e a chave base.

Havia quatro direções, cada uma das quais usava sua própria chave de sessão e contador: PC → Firmware IN / OUT, Firmware → PC IN / OUT

Smartcard

O smartcard acabou se tornando um interessante objeto de pesquisa. Eu nunca tinha lidado com o APDU (o protocolo usado na comunicação com smartcards), então tive que investigar. Depois disso, encontrei uma classe responsável por trabalhar com um smartcard no software Java, de onde consegui extrair a maioria dos comandos APDU. Eles também podem ser encontrados no código do firmware e, em seguida, alguns outros comandos podem ser encontrados por referência.

[ NT: Para dar celeridade aos projetos envolvendo smartcard, baixe o software cardpeek e estude os scripts contidos no mesmo. Estão disponíveis vários protocolos e exemplos de APDU. Você vai precisar de um leitor de smartcard. ]

Armado com um leitor de smartcard, fiz força bruta em vários comandos e seus parâmetros. Infelizmente, não descobri grandes segredos. No entanto, encontrei comandos que permitiam definir nossos próprios valores de contador de sessão (exceto para os valores que já haviam sido usados ​​antes).

Chaves de sessão (não, obrigado)

Na verdade, todo esse esquema com chaves de sessão, quatro direções de comunicação, o TPM e o armazenamento de chaves não causou nada além de respeito. O esquema foi desenhado com muita habilidade. Um invasor não pode simplesmente entrar no tráfego, repetir uma sessão capturada ou fazer algo do tipo.

[ NT: Há exceções ainda nos dias de hoje, que podem ser classificadas como 0-days, pois nunca houve publicação. ]

Portanto, como engenheiro reverso, eu realmente não queria me ferrar.

Como parte do projeto, mudamos o firmware para que parasse de acessar o smartcard para obter as chaves de sessão, usando, ao invés da chave, um array fictício de zeros.

Agora tínhamos que fazer o mesmo no software Java, para não nos incomodar em escrever código do zero. A propósito, ficou claro para nós pelo código que o algoritmo de criptografia Aes-EAX foi usado.

Saque!

[ NT: Apesar da “boca” de onde sai o dinheiro ter a capacidade de expelir umas 40 notas, em testes de laboratório, observei entupimento. É prudente expelir apenas 20 notas de cada vez para ter mais sucesso nos testes e não inutilizar o ATM. ]

Aqui, gostaria de fazer uma observação importante: todos os testes foram realizados na placa controladora do dispensador de notas que estava sobre a minha mesa. E isso significava que não havia dispositivos periféricos e, portanto, não havia de onde obter notas. Portanto, quando Alexei e eu tínhamos plena confiança de que conseguiríamos sacar dinheiro, fomos ao laboratório do fornecedor para realizar os testes finais.

Durante esses testes, descobriu-se que, para retirar o dinheiro, precisávamos especificar quanto dinheiro tínhamos e em quais cassetes e pular a configuração de dispositivos que não estavam conectados ao laptop (bem, haviam muitas portas USB no computador e apenas duas no laptop).

Só depois disso, um comando com os números das cassetes e a quantidade de notas que desejávamos sacar poderia ser enviado ao dispensador. O caixa eletrônico começou a zumbir alegremente, preparando-se para dividir o dinheiro com outros pesquisadores, mas … nunca vimos o dinheiro. Só não sabíamos, esquecemos que precisávamos abrir a porta das notas. Uma segunda tentativa – e estávamos segurando um monte de notas novas (não verdadeiras, é claro, mas notas de fornecedores especiais) em nossas mãos. Viva!

Conclusões

O projeto foi muito interessante! Ao fazer isso, conseguimos trabalhar com novas tecnologias, acionar o alto-falante instalado na placa e, claro, sacar dinheiro. No momento em que este artigo foi escrito, as vulnerabilidades (uma em cada dispositivo) já foram corrigidas pelo fabricante de ATMs Diebold Nixdorf. Eles têm os seguintes identificadores (os identificadores no Mitre também estão a caminho):

· BDU: 2021-04967

· BDU: 2021-04968

Isso é tudo, eu acho. Gostaria de fazer uma menção especial ao trabalho de Alexei na parte de hardware do projeto, bem como na placa dispensadora que ele comprou, que ainda está na minha mesa.

[ NT: Clientes privados já conhecem essa classe de vulnerabilidade há mais de 6 anos em testes de penetração, algumas das quais ainda não foram informadas ao fabricante.

Chamamos de downgrade de firmware. Não precisa mudar a chave RSA dentro do firmware, nem zerar chaves de sessão, mas saca dinheiro da mesma forma, nos testes de prova-de-conceito, feitos todos, claro, com notas de teste ao invés das reais.

Em tempo: Nunca encontrei um sistema similar que não pudesse produzir uma vulnerabilidade explorável, via engenharia reversa. O menor tempo foi em 2 dias. ]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s