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. ]

Espectrômetro de Massa, cadeia de suprimento, segurança, aplicações

Espectrômetro de Massa

A existência desta tecnologia não é muito difundida, as aplicações porém são de vital importância.

Tomei conhecimento da existência do equipamento há muitos anos atrás ao acompanhar agentes da Polícia Federal inspecionando mercadorias recebidas do exterior – o espectrômetro de massa, à época, era utilizado para detectar narcóticos ou material explosivo entrando ilegalmente pelos aeroportos.

Ainda hoje é utilizado por agentes da Polícia Federal em aeroportos internacionais, no combate a delitos transnacionais, e na interceptação de mercadorias importadas com valor abaixo do declarado em nota.

Procedimentos de segurança, em projetos de alto risco, precisam utilizar tal maquinário para evitar uma possível infiltração malígina da cadeia produtiva, em missões críticas.

Foi atribuído a um ator “desconhecido” a inserção de explosivos dentro de grandes peças de mármore adquiridas pelo Irâ, para serem usadas como base das centrífugas em sua usina de enriquecimento de Urânio.

Caso tivessem empregado o espectrômetro de massa na fiscalização do material recebido, a sabotagem teria sido detectada previamente.

Após determinado tempo em funcionamento, por ondas ou temporizador, os artefatos escondidos no mármore foram acionados, e ocorreu uma enorme explosão dentro da usina, avariando equipamento e possivelmente pessoal. A missão crítica foi atrasada alguns meses.

A Importância do controle de acesso

Instalações críticas precisam ter o acesso restringido a pessoal autorizado, porém esta regra de ouro pode ter algumas “brechas legais ou tecnológicas”, que colocam em risco operações.

Supondo que o artefato dentro do mármore tenha sido ativado com “temporizador iniciado por acionamento via ondas”, e que a instalação de pesquisa/enriquecimento tivesse propriamente protegida contra ondas externas, alguém poderia ainda assim enviar um sinal de ativação via smartphone infectado ou outro aparelho emissor, de dentro da instalação; os portadores poderiam ser visitantes ou inspetores internacionais.

O vetor ideal, porém, seria a infecção de um smartphone de pessoal autorizado a trabalhar na instalação, sem o conhecimento do mesmo, aparelho este sem as últimas atualizações de segurança instaladas – ou totalmente atualizado, dependendo do “budget” da operação.

Tal integração de sistemas é medianamente avançada, e com os especialistas corretos trabalhando juntos, pode ser montada uma prova-de-conceito funcional, não-miniaturizada, em menos de 48 horas – excluindo o exploit necessário para o smartphone completamente atualizado.

Caso a instituição responsável pelo recebimento da matéria-prima comprometida tivesse empregado o espectrômetro de massa na etapa inicial de inspeção de material, a sabotagem teria sido propriamente detectada e neutralizada.

Cadeia de Suprimentos

Muito se fala nos dias de hoje sobre os ataques à cadeia de suprimentos virtuais, especialmente aqueles em que o software é comprometido para chegar a ativos “mais valiosos”, porém os ataques às cadeias de suprimentos físicas também existem, e seus impactos são reais e de grande letalidade.

A difusão tecnológica dos smartphones e outros aparelhos conectados, como IoT, dão margem a integração desses nos ataques à cadeia de suprimento física. Os atores que dominarem tal campo, irão prevalecer nas guerras do futuro – que já estão ocorrendo, então, também, do presente – sejam elas físicas, virtuais ou uma mistura das duas.

Toda instituição que almeja um eficiente controle de qualidade dos equipamentos e matérias-primas adquiridas, precisa possuir tal ativo, o espectrômetro de massa – existem versões de grande ou pequeno porte.

As Oportunidades no Afeganistão pós-guerra

Sem citar a lista de todos os grandes impérios que invadiram o Afeganistão e eventualmente caíram após a retirada:

  • Em 1919, o Império Britânico invadiu o Afeganistão. Algum tempo depois o Império Britânico caiu.
  • Em 1979, a União Soviética invadiu o Afeganistão. Algum tempo depois a União Soviética caiu.

Em outubro de 2001, os norte-americanos investiram seu poderio militar contra o Afeganistão, sob o pretexto de dar uma resposta a al-Qaeda por ter dado cobertura a Osama Bin Laden.

Mas o que poucos sabem é que o governo do Afeganistão, à época, se ofereceu a entregar ou infligir restrições disciplinares ao supra-citado Osama Bin Laden, caso os EUA se dispusessem a informar provas de que o mesmo teve participação em atentados, o que não ocorreu.

Tentativas de obtenção de tais provas podem ter sido realizadas por agências policiais e de inteligência estadunidenses, européias e israelenses; além de aliados, companhias privadas e detetives particulares junto a familiares ; mas ao que tudo indica, foram todas exemplarmente frustradas. O presidente dos EUA, à época, explicitamente escolheu não informar tais provas, caso existissem, nem negociar termos, em contradição às normas da ONU.

Apenas exigiu rendição total e incondicional, o que não foi aceito, levando Osama a se aliar a parceiros mais confiáveis em suas palavras e ações.

Os relatórios de agências da Inteligência dos EUA, indicavam que a força nacional previamente treinada e aparelhada pelos estadunidenses, seria capaz de resistir por um período de 3 meses a 1 ano, antes da queda de Cabul, o que não ocorreu. Houve “mais uma” falha da inteligência estadunidense.

Em relação a costumes, temos Arábia Saudita, perfeitamente incluída na geopolítica mundial, com valores e costumes extremamente parecidos com os dos representantes do Afeganistão atual. Já temos países asiáticos em conversas produtivas com os mesmos, com projetos de mineração aguardando retomada. O que temos naquela região, hoje, é um grupo que acumulou grandes espólios de uma guerra que durou 20 anos, de aeronaves, drones a carros de combate, armas leves, material de inteligência e equipamentos biométricos.

No que se refere a um estado, o poderio bélico está intrinsicamente ligado a sua capacidade de dissuasão frente a ameaças externas. Alguém acha utópico termos 100% das fronteiras brasileiras vigiadas, com drones controlados e integrados a um sistema de comando e controle? Não é. E salva vidas de militares destacados nessas regiões.

Os equipamentos militares, incluindo softwares, e as informações relacionadas a inteligência, são sim de grande valia.

Porém, os recursos minerais do Afeganistão, avaliado na casa dos trilhões de dólares, e totalmente de acordo com a nova indústria elétrica mundial, me obrigam a reavaliar nossa interação com os mesmos:

  • Valeria a pena manter uma aliança comercial/estratégico/militar com determinado país, com tantos recursos interessantes e carente de parcerias para transformar, analogamente, “ouro bruto guardado” em “finas jóias”?
  • Ou valeria mais a pena mantermos uma outra parceira estratégica e o “status-quo” que possuímos há algumas décadas com nações antagônicas aos mesmos, nações estas que repetidamente freiam nossas ambições de projeção de poder, bloqueando nosso progresso, num clássico exemplo de neo-colonialismo?

O Paquistão é, sem dúvida, um dos maiores interessados em material de inteligência proveniente daquela região.

Porém, para Rússia, China e Irã, considerando além dos valiosos recursos minerais, creio que a paz regional seja a maior moeda de troca.

Apenas interações reais levam ao progresso.

3 Formas de burlar Marca d’àgua no Áudio/Vídeo, desde que os mesmos canais estejam disponíveis de várias fontes

1) Identificar ponteiros, substituir marcas, adicionar lixo

Para sistemas que usam um cartão compatível com EMV, o cartão é geralmente encaixado na parte de trás do seu equipamento receptor. Seu equipamento, com a ajuda do cartão EMV na traseira do mesmo, decodifica o sinal, geralmente recebido via cabo, para o seu receptor e finalmente para sua tela.

Pesquisadores precisam começar com ao menos 3 receptores diferentes sintonizados no mesmo canal para “ver/analizar” os dados DEPOIS de decriptados, para então iniciar o trabalho de identificar as marcas d’àgua tanto no áudio quanto no vídeo.

Se você for capaz de colocar as mãos no algoritmo de “patch” da marca d’àgua, esta é claro uma forma mais fácil, e tudo estará resolvido, mas duvido muito que estarão tão facilmente disponíveis em qualquer tipo de mercado 🙂

É um inferno de análise de baixo nível, tipo hexdump/xxd, mas tenho certeza que algum mago do Python pode semi-automatizar a tarefa, mesmo em tempo real. Adicionalmente, após identificar os ponteiros normalmente utilizados (porque esses offsets podem sim mudar com o tempo), vai precisar inserir seu próprio “lixo” para que a fonte original da transmissão não possa ser propriamente identificada. É como realizar o “patch” de uma assinatura de vírus de computador com uma sequência randômica de bytes num editor hexadecimal, para que o “vírus” (nesse caso a marca d’àgua) não possa mais ser detectado. Tudo isso sendo feito sem perder a qualidade do àudio/vídeo.

Para o áudio ser processado quase em tempo real, sabemos que poder de processamento é necessário, então prepare-se para escalar o mesmo, de acordo com a demanda.

2) Multiplexação – A Forma Fácil nº 1

Não seja barato – esta é a regra.
Vamos lá, você tem milhares de consumidores, então vamos fazer uma matemática simples, ok? Compare o número total de verdinhas pagas pelos seus consumidores, ao número total de verdinhas que são cobradas pela operadora, por cartão EMV. Quantas contas com a operadora você pode ter por canal mantendo uma boa margem de lucro? Mais de 5? Ok. Compre até 32 cartões por canal.

Mude constantemente a origem dos canais no seu sistema IPTV no estilo round-robin. Porque? Negação-plausível. O rastreamento do seu serviço pela marca d’àgua não irá levar a um único cartão EMV.

Cancele assinaturas e compre novos cartões, antes mesmo de serem cancelados.

Você irá necessitar de um engenheiro para colocar isso no ar 🙂

3) Filtros – A Forma Fácil nº 2

Essa forma possui um ótimo custo/benefício, então não vou explicar. Deixo pra vocês imaginarem como é feita.

Atenção: Nenhuma responsabilidade será assumida pela implementação das soluções acima mencionadas, que foram explicadas puramente por princípios de pesquisa. Não encorajo nenhum tipo de atividade ilegal. Nem tenho tempo ou disponibilidade para implementá-las, apesar de serem tecnicamente viáveis.

3 Ways to circumvent Watermarking in Audio/Video, upon same streams availability from multiple sources

1) Indentify Offsets, replace marks, add noise

For systems used with an EMV-compatible card, the card is usually available in the back of your receiver equipment. Your equipment with the help of the EMV-card in its back, decodes the streams, usually sent via cable, to your receiver and finally to your screen.

Fellas need to start with at least 3 different receivers tunned on the same stream(channel) to “watch/analyze” the RAW streams AFTER decryption, identifying the watermarks in both audio AND video.

If you manage to get your hands on the watermarking patching algorithm, for sure a much easier way, its all done, but I doubt it is so easily available in any market at all 🙂

It is a hell of low-level analysis, hexdump/xxd-like, I am sure some Python-magician can semi-automate the task, even in realtime. In addition, after identifying the offsets commonly used (because these spots can also change with time), you need to insert your own “noise” so the original streams cannot be properly identified. Its pretty much like “patching” a virus signature with random sequence of bytes in an hex-editor, so the “virus” (in this case the watermark) cannot be detected anymore. All while not breaking the quality of the audio/video stream.

For the audio stream to be processed in near realtime, y’all know GPU/CPU usage spikes will occur – and possibly delay, so prepare for scaling of processing power.

2) Multiplexing – The Easy way nº 1

You shall not be cheap – this is the rule.
Come on, you have thousands of customers, so lets make a simple math, ok? Compare the total number of greens paid by customers, to the total number of greens providers charge per EMV-card. How much EMV-card subscriptions can you buy retaining a good profit margin? More than 5? Ok. Buy up to 32.

Shuffle the source of the cable streams into your IPTV-based stream. Why? Plausible-deniability. They cannot trace a single card to your service.

Keep cancelling subscriptions and buying new cards.

You will need an engineer to set this up 🙂

3) Filters – The Easy way nº 2

This is too much cost-effective, so I will not explain it. I leave to you fellas to figure it out.

Warning: I assume no responsability for the implementation of the solutions above mentioned, which were explained just for research purposes. I haven’t the time nor the will to implement them, but can be done.

Tecnologia Militar – A necessidade e a oportunidade de modernização dos sistemas legados

O desenvolvimento de produtos no meio militar, em contraste com a norma capitalista da “obsolescência programada”, concebe sistemas feitos para durarem décadas.

O documentário “The Light Bulb Conspiracy” [1] nos dá uma visão capitalista e maquiavélica das empresas que planejam obter lucro programando seus produtos para falharem.

Uma impressora Epson foi descoberta com um contador interno num chip, que instruia a parada da mesma após um número determinado de impressões [2].

Nos meios militares, sistemas concebidos há mais de 50 anos encontram-se em pleno funcionamento, muitas vezes exigem mínima manutenção, independente da letalidade do mesmo.

Algumas obras cinematográficas já realizaram paródias sobre o caso, como no caso do filme “Johnny English Strikes Again” [3] onde não era recomendado utilizar nenhum aparelho celular próximo a um submarino nuclear antigo, o que ocasiona o envio de um míssel balístico inadvertidamente.

Sistemas de lançamento de mísseis nucleares oriundos da guerra fria ainda encontram-se em atividade, alguns com “senha padrão” composta de oito zeros, outros com “flashcards” postados online[9], causando vazamento de informações sensíveis.

Numa época em que as guerras eletrônicas[6] e cibernéticas[5] evoluíram o suficiente para causar preocupação, respostas cinéticas[7], e até mesmo a capitulação de nações com poderio bélico nuclear, a necessidade de modernização segura de muitos desses sistemas é uma ótima janela de oportunidade para realizar novos negócios e aumentar nosso poder de dissuasão nesta área.

Ao invés de um código estático configurado manualmente num lançador de mísseis, a tecnologia de chaves pública/privada e curvas elípticas de hoje, nos permite ter códigos que mudam a cada X horas ou minutos, e as sementes para o cálculo dos códigos podem existir apenas na mala presidencial e/ou no alto comando das forças armadas.

Tendo em vista as recentes evoluções nos chamados ataques a cadeia produtiva [8], nada mais interessante que desenvolvermos um HSM “padrão militar” com tecnologia 100% nacional – alguns chips ainda precisam ser importados.

O prolongado tempo de vida de veículos e armas abre um espaço enorme para a indústria, no que tange a modernização, como a adição ou substituição de sensores, e outros dispositivos analógicos mais propensos a falhas mecânicas. Alguns microchips atuais [4], padrão militar, possuem tempo de vida de mais de 50 anos, contagem feita, claro, a partir de testes que multiplicam, às vezes em fatores de centenas de vezes, suas operações, para estimar o tempo de vida dos mesmos em laboratório.

[1] https://www.imdb.com/title/tt1825163/
[2] https://therestartproject.org/design/triumphing-together-against-planned-obsolescence/
[3] https://en.wikipedia.org/wiki/Johnny_English_Strikes_Again
[4] https://www.microchip.com/wwwproducts/ProductCompare/ATECC608B/ATECC608B-TCSM
[5] https://www.theregister.com/2016/06/22/cyber_warfare_future_stuxnet/
[6] https://www.maritime-executive.com/article/gps-spoofing-patterns-discovered
[7] https://www.bbc.co.uk/news/uk-34078900
[8] https://www.fireeye.com/blog/threat-research/2021/03/sunshuttle-second-stage-backdoor-targeting-us-based-entity.html
[9] https://www.bellingcat.com/news/2021/05/28/us-soldiers-expose-nuclear-weapons-secrets-via-flashcard-apps/

Explorando vulnerabilidades no Cellebrite UFED e Analisador Fisico pela perspectiva de um App

(Traduzido de https://signal.org/blog/cellebrite-vulnerabilities/ por Fábio Martins)

moxie0 em 21 de abril de 2021

A Cellebrite desenvolve software para automatizar a extração e indexação física de dados de dispositivos móveis. Eles existem dentro do “label cinza” – onde a marca corporativa se junta com o ladrão para ser chamado de “inteligência digital”. Sua lista de clientes inclui regimes autoritários na Bielo-Rússia, Israel, Estados Unidos da América do Norte (EUA), e Venezuela; policiais em Mianmar. Alguns meses atrás, eles anunciaram que adicionaram suporte ao Signal em seu software.

Seus produtos costumam ser vinculados à perseguição de jornalistas e ativistas presos em todo o mundo, mas menos se escreveu sobre o que seu software realmente faz ou como funciona. Vamos olhar mais de perto. Em particular, seu software é frequentemente associado a contornar a segurança, então vamos examinar a segurança de seu próprio software.

Olhando por trás

Em primeiro lugar, qualquer coisa que envolva o Cellebrite começa com outra pessoa fisicamente segurando seu dispositivo nas mãos. A Cellebrite não faz nenhum tipo de interceptação de dados ou vigilância remota. Eles produzem dois softwares principais (ambos para Windows): UFED e Physical Analyzer (ou Analisador Fisico).

O UFED cria um backup do seu dispositivo na máquina Windows que esta rodando o UFED (é essencialmente um front-end para backup via adb no Android e backup do iTunes no iPhone, com algumas análises adicionais). Depois de criar um backup, o Physical Analyzer analisa os arquivos do backup para exibir os dados em formato navegável.

Quando a Cellebrite anunciou que adicionou o suporte Signal ao seu software, tudo o que realmente significava foi que eles adicionaram suporte ao Physical Analyzer para os formatos de arquivo usados ​​pelo Signal. Isso permite que o Physical Analyzer exiba os dados do Signal que foram extraídos de um dispositivo desbloqueado, que se encontra na posse física de um usuário do Cellebrite.

Uma maneira de pensar sobre os produtos da Cellebrite é que se alguém estiver segurando fisicamente seu dispositivo desbloqueado nas mãos, eles podem abrir os aplicativos que quiserem e tirar capturas de tela de tudo que há neles para salvar e revisar mais tarde. O Cellebrite basicamente automatiza esse processo para alguém que está segurando seu dispositivo nas mãos.

No lugar certo, a Celleb … ridade certa

Por uma coincidência verdadeiramente inacreditável, recentemente estava passeando quando vi um pequeno pacote cair de um caminhão à minha frente. Conforme me aproximei, o tipo de letra empresarial enfadonho lentamente entrou em foco: Cellebrite. Lá dentro, encontramos as versões mais recentes do software Cellebrite, um dongle de hardware projetado para evitar a pirataria (diz algo sobre seus clientes, eu acho!) E um número bizarramente grande de cabos dapatadores de celular.

Pacote da Cellebrite na beira da estrada.

O software

Qualquer pessoa familiarizada com segurança de software reconhecerá imediatamente que a principal tarefa do software da Cellebrite é analisar dados “não confiáveis” de uma ampla variedade de formatos usados ​​por muitos aplicativos diferentes. Ou seja, os dados que o software da Cellebrite precisa para extrair e exibir são, em última análise, gerados e controlados pelos aplicativos no dispositivo, não por uma fonte “confiável”, então a Cellebrite não pode fazer nenhuma suposição sobre a “exatidão” dos dados formatados que está recebendo. Este é o espaço em que virtualmente todas as vulnerabilidades de segurança se originam.

Uma vez que quase todo o código da Cellebrite existe para analisar entradas não confiáveis ​​que podem ser formatadas de uma forma inesperada para explorar a corrupção de memória ou outras vulnerabilidades no software de análise, pode-se esperar que a Cellebrite tenha sido extremamente cautelosa. Olhando para o UFED e o Physical Analyzer, no entanto, ficamos surpresos ao descobrir que muito pouco cuidado parece ter sido dado à segurança de software da própria Cellebrite. Faltam defesas de mitigação de exploits padrão da indústria e muitas oportunidades de exploração estão presentes.

Como apenas um exemplo (não relacionado ao que segue), seu software agrupa DLLs FFmpeg que foram construídas em 2012 e não foram atualizadas desde então. Houve mais de uma centena de atualizações de segurança nesse período, nenhuma das quais foi aplicada.

Vulnerabilidades FFmpeg por ano

Os exploits


Dado o número de oportunidades presentes, descobrimos que é possível executar código arbitrário em uma máquina Cellebrite simplesmente incluindo um arquivo formatado especialmente, mas inócuo em qualquer aplicativo em um dispositivo que é posteriormente conectado ao Cellebrite e escaneado. Praticamente não há limites para o código que pode ser executado.

Por exemplo, ao incluir um arquivo especialmente formatado, mas inócuo em um aplicativo em um dispositivo que é verificado pela Cellebrite, é possível executar um código que modifica não apenas o relatório Cellebrite sendo criado nessa verificação, mas também todos os anteriores e futuros. Os relatórios da Cellebrite de todos os dispositivos escaneados anteriormente e de todos os dispositivos escaneados no futuro, de qualquer forma (inserir ou remover texto, e-mail, fotos, contatos, arquivos ou quaisquer outros dados), sem alterações de carimbo de data / hora detectáveis ​​ou falhas de checksum. Isso pode até ser feito aleatoriamente e colocaria seriamente em questão a integridade dos dados dos relatórios da Cellebrite.

Qualquer aplicativo pode conter esse arquivo e, até que o Cellebrite seja capaz de reparar com precisão todas as vulnerabilidades em seu software com extrema confiança, o único remédio que um usuário do Cellebrite tem é não fazer a varredura dos dispositivos. A Cellebrite poderia reduzir o risco para seus usuários atualizando seu software para interromper a varredura de aplicativos que considera alto risco para esses tipos de problemas de integridade de dados, mas mesmo isso não é garantia.

Obviamente, estamos dispostos a divulgar de forma responsável as vulnerabilidades específicas que conhecemos para a Cellebrite se eles fizerem o mesmo para todas as vulnerabilidades que usam em sua extração física e outros serviços para seus respectivos fornecedores, agora e no futuro.

Abaixo está um vídeo de amostra de um exploit para UFED (exploits semelhantes existem para o Physical Analyzer). No vídeo, o UFED atinge um arquivo que executa código arbitrário na máquina Cellebrite. Essa carga útil de exploração usa a API do Windows MessageBox para exibir uma caixa de diálogo com uma mensagem. Isso é para fins de demonstração; é possível executar qualquer código, e uma carga útil de exploração real provavelmente tentaria alterar relatórios anteriores de forma indetectável, comprometer a integridade de relatórios futuros (talvez aleatoriamente!) ou exfiltrar dados da máquina Cellebrite.

O copyright


Também é interessante que o instalador do Physical Analyzer contém dois pacotes de instalador MSI chamados AppleApplicationsSupport64.msi e AppleMobileDeviceSupport6464.msi. Esses dois pacotes MSI são assinados digitalmente pela Apple e parecem ter sido extraídos do instalador do Windows para o iTunes versão 12.9.0.167.

Pacotes MSI

O programa de instalação do Physical Analyzer instala esses pacotes MSI em C:\Program Files\Common Files\Apple. Eles contêm DLLs que implementam a funcionalidade que o iTunes usa para interagir com dispositivos iOS.

DLLs instaladas no sistema de arquivos

A ferramenta Cellebrite iOS Advanced Logical carrega essas DLLs da Apple e usa sua funcionalidade para extrair dados de dispositivos móveis iOS. A captura de tela abaixo mostra que as DLLs da Apple são carregadas no processo UFED iPhone Logical.exe, que é o nome do processo da ferramenta iOS Advanced Logical.

DLLs carregadas em processo

Parece improvável para nós que a Apple tenha concedido à Cellebrite uma licença para redistribuir e incorporar DLLs da Apple em seu próprio produto, então isso pode representar um risco legal para a Cellebrite e seus usuários.

Completamente não relacionado

Uma notícia completamente não relacionada, mas as próximas versões do Signal irão baixar arquivos periodicamente para colocar no armazenamento do aplicativo. Esses arquivos nunca são usados ​​para nada dentro do Signal e nunca interagem com o software ou dados do Signal, mas têm uma boa aparência e a estética é importante no software. Os arquivos serão devolvidos apenas para contas que já tiveram instalações ativas por algum tempo, e apenas probabilisticamente em baixas porcentagens com base no número de telefone. Temos algumas versões diferentes de arquivos que consideramos esteticamente agradáveis ​​e faremos uma iteração por eles lentamente ao longo do tempo. Não há outro significado para esses arquivos.

Nota do Tradutor

A caixa de pandora foi aberta.

Não confie em empresas que oferecem “simulação de adversário” com adversários capazes e reais. Contrate tal pessoal com assinatura de NDA (Non-Disclosure Agreement), ou você pode acabar perdendo a sua empresa e/ou, seu produto e potencialmente seus clientes no mundo real, não no simulado.

Qualquer um que tenha tido o celular auditado / analisado pelo equipamento da Cellebrite em um processo judicial, já pode requerer a auditoria / análise do programa UFED pelos seus próprios peritos (inclusive este que vos fala, especialista nas tecnologias e ferramentas em questão, capaz de realizar as demonstrações necessárias fora ou em corte), alegando que as vulnerabilidades existentes (algumas públicas, outras não) do mesmo podem ferir a integridade das informações obtidas, e caso o pedido seja negado, pedir que as provas sejam removidas do processo judicial.

É importante ressaltar que tal medida vale não apenas para processos futuros, mas também passados – já que existe a possibilidade de que arquivos com nome ou conteúdo mal-formado, inválido ou corrompido, fato comum de acontecer em memórias tipo SDcard ou flash presentes no hardware dos dispositivos móveis, possam ter ferido a integridade das provas obtidas.

Exemplo de nome de arquivo corrompido num SDcard de smartphone, fato ocorrido sem interação humana proposital, mas que mesmo assim pode afetar a integridade de relatórios periciais:

SDcard de smartphone naturalmente corrompido

Sentenças podem ser anuladas, processos e julgamentos que tiveram base neste tipo de prova, recomeçarem do zero.

Também existe a possibilidade de que quantias bilionárias sequestradas pela justiça, precisem ser devolvidas.

O impacto dessa revelação pode afetar centenas, senão milhares, de processos judiciais em todo o mundo – já que não se pode mais confiar na integridade dos dados extraídos de um smartphone através dessa ferramenta, sem mencionar que as suas ações (CLBT) a serem listadas ( num suposto “merge” bilionário, de aproximadamente 12 bilhões de reais – realmente ocorrerá? ) em breve na NASDAQ, não atrairão muitos investidores, devido ao futuro incerto da companhia Israelense.

Quanto vale um relatório forense que não pode ser usado em corte?

Ou que se usado, pode ser facilmente retirado da lista de supostas provas, pelo advogado de defesa e seus peritos?

Entre o assassino e o corrupto (Bota na conta)

Me mostre apenas 1 chefe de estado, com exceção de Vossa Santidade O Papa, que nunca precisou tomar decisões difíceis – na minha opinião, não existe.

Em todo o rumo da história, seja em tempos de paz ou guerra, todos os chefes de estado foram levados a tomar decisões extremas para garantir a evolução e a independência de seus povos.

Quanto mais longe formos pesquisar, mais sangue veremos. Nos dias atuais menos sangue, mais hipocrisia e mídia.

Nossa sociedade evoluiu o suficiente para chefes de estado não precisarem mais tomar tais decisões, correto? Shangri-la foi encontrada e todos vivemos alegres e felizes nela, com maná caindo do céu, certo?

Opa, me esqueci que também o Papa quis visitar uma das zonas mais perigosas da cidade do Rio de Janeiro, logo, assumiu o risco das decisões difíceis a serem tomadas, transferindo a responsabilidade para os agentes de segurança que necessitaram realizar as ações necessárias.

Favor retirar Vossa Santidade O Papa da lista.

Precisamos de uma fábrica de waffles!

O Brasil precisa sim urgentemente de uma fabrica de chips.

Longe de querer chegar em poucos anos, aos 10 ou 7 nanômetros na tecnologia de produção dos mesmos, mas a necessidade de se começar existe.

As pesquisas mais avançadas no setor são lideradas por EUA e China, sendo EUA o primeiro lugar absoluto com Intel / AMD.

Porem isso não impediu que China tentasse alcançar a sua independência tecnológica, aliando polo industrial, PPP e universidades – nasce Loongson / Godson. Quanto tempo vai demorar para chegar ao patamar de Intel / AMD? Ninguem sabe – mas talvez chegue um dia.

Como fomentar a área? Não sei, mas podemos iniciar nos perguntando:

  • Quais as universidades federais mais avançadas na área?
  • Quais os Institutos de engenharia militares mais avançados nessa pesquisa?
  • E empresas privadas querendo produzir tecnologia indígena de baixo custo para equipar consumidores de baixa / media renda que não necessitam de computadores acima dos 10 mil reais para estudo e trabalho?