No último dia 18, ocorreu mais uma parada do maior evento de hacking, segurança e tecnologia da América Latina, Roadsec, desta vez, em São Paulo. Os encontros, que são itinerantes e já percorreram 17 localidades apenas neste ano, contam com palestras, oficinas e muitos profissionais de segurança da informação do Brasil e do exterior.
Os destaques da edição foram os key notes de Marc "CJ" Rogers, hacker responsável técnico da série Mr. Robot; Jeff Moss, fundador da DEF CON e Black Hat; e Rodrigo Rubira Branco, organizador da Hackers to Hackers Conference (H2HC) e também autor da palestra "Blinded Random Block Corruption Attacks", tema deste post review.
A palestra apresentou uma pesquisa desenvolvida no Intel Labs, por Rodrigo Rubira Branco em parceria com Shay Gueron. No entanto, o conteúdo da palestra não ficou restrito apenas aos resultados da pesquisa, mas também apresentou seu desenvolvimento, destacando o processo evolutivo, desde sua proposição inicial, os erros cometidos, até a obtenção dos resultados.
A pesquisa em si demonstra que atacantes com a capacidade de modificar bits da memória RAM (i.e. atacantes ativos), podem comprometer a confidencialidade de dados, mesmo se a memória estiver encriptada. Por isso, o ataque é descrito como Blinded Random Block Corruption (Corrupção Cega de Bloco Aleatório, em tradução livre), entenda:
- Corrupção de Bloco Aleatório: o atacante tem a capacidade de modificar bits na memória. No entanto, caso essa memória esteja encriptada com cifra de bloco, a modificação de um bit ocasionará a corrupção de um bloco inteiro do texto claro (quando a decriptação for realizada).
- Cega: o atacante não conhece o texto claro em memória, pois encontra-se encriptada.
Ataque por corrupção cega de bloco aleatório
A fim de exemplificar como o ataque pode se suceder na prática, foi citado o processo de login do Linux. Analisando o código responsável pelo login, vê-se que o processo de autenticação pode ser transposto caso o valor da variável (unsigned int) cxt.noauth seja diferente de zero (ou seja, represente o valor lógido de TRUE).
Trecho de código referente a pré-autenticação.
Como observado no próprio código, o processo de autenticação pode ser pulado, caso a conta utilizada já tenha sido autenticada anteriormente e haja uma relação de confiança entre a máquina que está executando o processo de autenticação e o host onde a autenticação tenha sido realizada anteriormente.
Estrutura de dados login_context que contém a variável noauth.
Portanto, caso o adversário seja capaz de corromper um bloco de memória onde está localizada a variável cxt.noauth, por mais que o valor obtido após a decriptação dessa posição de memória não possa ser pré-determinado pelo atacante, a probabilidade que esse valor seja exatamente zero é desprezível e isso permite que o adversário se autentique com qualquer usuário (e.g. root) sem ter que conhecer sua credencial.
O ataque é possível pois, apesar da memória estar encriptada, garantindo assim a confidencialidade dos dados, não há nenhum mecanismo para garantir a integridade desses dados. Ou seja, apenas encriptar a memória não garante segurança em profundidade contra adversários capazes de corromper a memória.
O motivo de não se adotar verificação de integridade da memória deve-se ao fato de prover acesso rápido aos dados e ser otimizada em relação a espaço ocupado, portanto, dessa forma, para incluir mecanismos de integridade dos blocos encriptados da memória, é necessário tanto armazenar informações redundantes (e.g. MAC) quanto despender um maior processamento fazendo a verificação da integridade toda vez que a memória é acessada.
Modelo A-B-C de atacante
A fim de avaliar a aplicabilidade do ataque em cenários, é proposto o modelo A-B-C de atacante:
- Access Seeking Attacker (atacante pretendente de acesso): o atacante tem acesso a uma plataforma bloqueada e pretende logar-se no sistema.
- Breaching Attacker (atacante violador): o atacante é um usuário legítimo da plataforma e pretende contornar restrições de seu usuário, ou seja, elevar privilégio.
- Conspirator Attacker (atacante conspirador): o atacante tem acesso a uma plataforma compartilhada e deseja coletar dados de outros usuários (aos quais não tem acesso de maneira legítima).
O modelo pode descrever um adversário que:
A. Tem acesso a um dispositivo em execução que possui criptografia de disco
B. É funcionário de uma organização qualquer
C. É um administrador do hipervisor de algum fornecedor de soluções de computação em nuvem
Demonstração do ataque
A demonstração (em vídeo) levou em consideração um adversário do tipo A, que busca acessar uma plataforma que encontra-se bloqueada. Através de um debugger (gdb), o adversário pode colocar breakpoints e alterar (e corromper) bits da memória.
Demonstração: ataque de corrupção cega de memória com um adversário do tipo A.
Quando o sistema está bloquado e requisitando senha, a própria implementação do login se encarrega de interromper o processo em um estado favorável (nesse ataque) ao adversário – ou seja, quando o usuário e a senha são requisitados. Nesse momento, o adversário pode corromper a flag de pré-autenticação para poder, em uma próxima checagem, se autenticar no sistema sem necessitar conhecer qualquer senha.
A seu favor, acrescenta-se o fato de que seção .bss, onde fica alocada a estrutura de dados responsável pelo contexto de login (login_context), está a uma distância fixa de onde inicia-se a função de login e dentro da seção .bss, a posição da flag de pré-autenticação (login_context.noauth) também é fixa.
Layout de memória do processo de login.
Portanto, basta corromper o valor da flag e digitar qualquer senha, para que na próxima tentativa de autenticar-se no sistema, nenhuma senha seja requisitada: quadros (C) e (F) da figura acima.
Apesar do ataque descrito, como observado pelo próprio Rodrigo Rubira Branco, não ser exatamente realislístico – um atacante sem acesso a um sistema bloqueado ser capaz de controlar um debugger, ele ilustra a possibilidade de se corromper bits da memória e transpor o processo de autenticação. No entanto, os atacantes do tipo B e C, são certamente factíveis.
Conclusões: pesquisa, palestra e evento
Este post dedicou-se a fazer um review da pesquisa “Blinded Random Block Corruption” apresentada em uma das palestras, sendo que tanto a pesquisa quanto a maneira como ela foi apresentada foram muito interessantes.
A pesquisa foi bem estruturada, definindo com rigor as premissas e modelos de ataque, e, de maneira engenhosa, explorou de forma prática as propriedades de segurança que (não) são entregues por um criptossistema – neste caso, explorou-se o fato da encriptação de memória não garantir integridade dos dados (apenas confidencialidade).
Para aqueles que desenvolvem pesquisas, foi bastante proveitoso observar como essa foi desenvolvida, desde sua proposição, passando por tentativas e erros, até chegar ao resultado final. Certamente, alguns aprendizados podem ser aplicados em outras, além de ressaltar quão trabalhosa pode ser, o que pode demandar bastante tempo – muitas vezes, isso não fica evidente quando apenas nos deparamos com os resultados finais de uma pesquisa.
Quanto ao Roadsec São Paulo 2016, foi um excelente evento. A palestra-tema desse review, foi apenas uma das mais de 20 palestras que ocorrem nas três trilhas do evento (segurança, hacking e tecnologia), das diversas oficinas e atividades que foram organizadas, como os shows: de MC Hckudão a Paralamas do Sucesso, além da presença de muitos profissionais e entusiastas de segurança da informação.
