Tarefa 1
Encontre vulnerabilidade de software em um console.
A primeira coisa que um hacker faria é descobrir qual software é executado no console. Desde que você mencionou, vamos escolher o PS4. Então pegue um pouco de googling.
O PS4 é executado em um processador AMD x86-64 personalizado com 8 núcleos. Esta arquitetura de CPU é muito bem documentada com trabalhos de pesquisa disponíveis na internet. Embora este possa diferir um pouco, as operações fundamentais devem ser as mesmas.
Lá. Nós temos a CPU. Então agora para o sistema operacional. Este console executa o Orbis OS. Este sistema operacional é baseado no Freebase 9.0. Como esta informação é útil? Duas palavras. Código aberto. O sistema operacional também vem com outro software de código aberto.
Particularmente interessante é o WebKit. O WebKit é um mecanismo de layout de código aberto que é usado no PS4 para renderizar páginas da Web no navegador. O WebKit possui algumas vulnerabilidades documentadas que podem ser exploradas. Por exemplo, o CVE-2012-3748 é um estouro de buffer baseado em heap no método JSArray :: sort (…). Essa vulnerabilidade pode ser explorada para nos fornecer acesso de leitura e gravação a tudo o que o processo do WebKit pode ler e gravar.
Isso pode ser usado para sobrescrever endereços de retorno na pilha e assumir o controle do registrador de ponteiros de instrução (rip) . Vulnerabilidade encontrada. Agora tudo o que precisamos fazer é encontrar uma maneira de copiar uma carga na memória e usar o rasgo para executá-la. Então, como fazer isso?
Tarefa 2
Encontre uma maneira de explorar a vulnerabilidade encontrada.
Em outras leituras, descobri que o PS4 tem um kernel que controla as propriedades de diferentes partes da memória. O kernel tem Prevenção de Execução de Dados (DEP) em que as páginas de memória marcadas como “executáveis” não podem ser sobrescritas e páginas de memória marcadas como “graváveis” não podem ser executadas. Portanto, não podemos simplesmente copiar uma carga na memória e executá-la. Podemos, no entanto, executar código que já está carregado na memória e marcado como "executável". Mas isso não é muito útil. Precisamos ser capazes de escrever nosso próprio código e marcá-lo como "executável".
Então nos voltamos para o empilhamento de peças. Particularmente ROP (Return-Oriented Programming) onde podemos sobrescrever uma cadeia de endereços de memória onde o rip irá saltar em sequência. Essas cadeias são chamadas de gadgets. Um gadget é uma única instrução desejada, seguida por um ret.
No assembly x86_64, quando uma instrução ret é atingida, um valor de 64 bits é retirado da pilha e o rip é saltado para ela. E agora que podemos controlar a pilha, podemos fazer com que todas as instruções de retorno saltem para o gadget que desejamos. Por exemplo, de 0x80000 contém instruções,
- mov rax , 0
- ret
então a partir de 0x90000 contém instruções,
- mov rbx , 0
- ret
Se sobrescrevermos um endereço de retorno na pilha para conter 0x80000 seguido por 0x90000, então, assim que a primeira instrução ret for atingida, a execução saltará para mov rax, 0 e imediatamente depois, a próxima instrução ret irá remover 0x90000 da pilha e pular para mov rbx, 0.
Então agora temos uma maneira de explorar a vulnerabilidade, mas como fazer isso?
Tarefa 3.
Explore a vulnerabilidade.
O PS4 possui ASLR (Address Space Layout Randomisation) implementado. Essa é uma técnica de segurança que faz com que os endereços de base dos módulos sejam diferentes toda vez que o PS4 é iniciado. Então, isso significa que não teremos a menor ideia sobre os endereços dos nossos gadgets. Portanto, não saberemos o que escrever na pilha.
Então, temos que ficar longe das cadeias de ROP estáticas. Felizmente, quando todos os módulos são carregados, seus endereços base são preenchidos na tabela de módulos. Se conseguirmos ler a tabela de módulos, podemos calcular os endereços dos nossos gadgets de ROP antes de acionarmos a execução. E nós podemos fazer isso usando JavaScript. Mas como estamos usando o ROP dinâmico, por que não dar um passo adiante? Também podemos cruzar os endereços dos nossos gadgets antes da execução para aumentar a confiabilidade .
Então, como interagir com o kernel? A única maneira é através de chamadas do sistema. Então, vamos dar uma olhada nas chamadas de sistema do FreeBSD 9.0 para encontrar uma maneira de entrar. O FreeBSD usa a convenção do UNIX de chamar chamadas do sistema com argumentos armazenados na pilha. Mas no PS4, a convenção LINUX é usada onde os argumentos são armazenados em registradores. Assim, com muito mais pesquisas, podemos obter uma lista de chamadas do sistema para mexer com.
Podemos verificar o PID de processos para iniciantes. Se nós verificarmos o PID do navegador, reinicie o navegador e verifique novamente, obtemos um valor de retorno 2 maior que o valor anterior. Isso significa que o navegador consiste em dois processos separados. O núcleo do WebKit que analisa HTML e CSS, executa JavaScript e decodifica imagens, e outro para manipular a entrada do usuário, exibindo gráficos, histórico, marcadores e tudo mais. Nós podemos assumir o núcleo.
Em seguida, tentamos analisar as chamadas do sistema por meio de despejos de módulo de engenharia reversa. Algumas chamadas do sistema não são referenciadas nos dumps do módulo, portanto, precisamos analisá-las usando força bruta.
Se nós adivinhamos que uma determinada chamada de sistema pode ter um conjunto particular de argumentos, podemos forçar brute todas as chamadas de sistema que retornam um certo valor (0 para sucesso) com os argumentos que escolhemos e ignorar todos os quais retornaram um erro.
Nós também podemos passar 0s para todos os argumentos, e força bruta todas as chamadas de sistema que retornam erros úteis como 0xe, "Endereço inválido", o que indicaria que eles pegam pelo menos um ponteiro.
Estamos tentando encontrar uma chamada de sistema com uma vulnerabilidade, por exemplo, podemos examinar os dados manipulados no disco antes e depois da chamada do sistema. Se os dados não forem alterados, pode ser um prompt de entrada. Portanto, podemos tentar alimentar uma cadeia longa como um argumento para procurar um estouro de buffer. Ou simplesmente veja se há um tipo de incompatibilidade. Ou um truncador NULL para limitar o comprimento e evitar um estouro. Este é um processo muito longo. Mas é necessário identificar as chamadas do sistema que podem nos levar ao kernel.
Em seguida, analisamos o sistema de arquivos. Depois que terminamos, como podemos ler e escrever arquivos? Infelizmente, devido ao sandboxing, não temos acesso a todo o sistema de arquivos. Então vamos ter que usar o que podemos acessar. Estes incluem dados de salvamento criptografados e informações da conta.
Como um acréscimo, descobrimos que nossas explorações irão realmente rodar o navegador como root. Então, onde estamos tão longe? Sabemos que o PS4 compartilha a maioria das vulnerabilidades com o FreeBSD 9.0. Também sabemos que a maioria das explorações não pode ser acionada usando o ponto de entrada do WebKit devido ao sandboxing. O melhor caminho a seguir seria a engenharia reversa de todos os módulos que podem ser descartados. Nós não temos um que nos forneça acesso ao kernel ainda. Mas nós podemos despejar a RAM assim, missão cumprida?
Espere, qual foi o objetivo de tudo isso? Apenas para despejar a RAM? Mesmo se pudéssemos escrever um gadget e executá-lo, qual seria o seu propósito?
Isso tem sido uma simplificação extrema do que realmente ocorre em um processo de hacking. Mas acho que serve para responder à sua pergunta sobre como as vulnerabilidades são encontradas e exploradas. Para um exame mais abrangente do que acabei de descrever, consulte