it-swarm-pt.tech

Custo de encontrar vulnerabilidades vs desenvolver exploits

Da perspectiva de alguém que deseja desenvolver uma exploração de dia zero contra algum aplicativo ou destino de software, em geral, existem duas tarefas que o invasor deve fazer: (1) encontrar uma nova vulnerabilidade explorável no software; (2) desenvolver uma exploração confiável e armada para essa vulnerabilidade.

Por exemplo, fuzzing, reversão e análise estática podem ajudar a encontrar a vulnerabilidade; mas é preciso análise e trabalho separados para construir um exploit confiável.

Qual dessas duas tarefas tende a custar mais, em média? Estou me perguntando como é a economia disso e para ter uma noção da proporção dos custos para essas duas tarefas. Eu sei que se você olhar para uma única vulnerabilidade, os custos dependerão da vulnerabilidade, mas estou perguntando sobre o caso médio. Por exemplo, se olharmos para uma empresa que desenvolve exploits, em conjunto, esperaríamos que mais de seu orçamento fosse para 1 ou 2?

Suponha que estejamos atacando um aplicativo de software de usuário final relativamente maduro e amplamente utilizado.

6
D.W.

Os custos relativos dependem muito de qual é a vulnerabilidade. Para demonstrar isso, vou me referir a duas vulnerabilidades semirrecentes: o bug Bash "Shellshock" e o bug glibc "Ghost" gethostbyname().

Trauma pós guerra

O bug Shellshock foi causado por uma falha intrincada na análise da função do Bash que poderia ser usada para fazer o Bash executar código diretamente a partir de variáveis ​​de ambiente. O bug existiu por aproximadamente 22 anos antes de ser descoberto publicamente.

Uma verificação para saber se o bug existe é assim:

$ env X="() { :;} ; echo vulnerable" /bin/sh -c ":"

Agora, encontrar esse bug exige um exame cuidadoso do código-fonte ou uma boa sessão com um fuzzer de código. Mas assim que é reduzido a um caso de teste como esse, os exploits vêm facilmente. Por exemplo, se você souber que um servidor de destino está executando um shellscript CGI:

$ nc vulnerable.example.com 80 <<__END
GET /path/to/cgi.sh HTTP/1.1
Host: localhost
User-Agent: () { x; }; printf "%s\n\n" "Content-type: text/plain"; /usr/bin/id
Accept: */*

__END

Portanto, Shellshock era difícil de encontrar, mas uma vez encontrado, era trivial de explorar.

Fantasma

A vulnerabilidade glibc gethostbyname(), por outro lado, é uma vulnerabilidade de estouro de buffer que só pode acontecer sob certas condições muito específicas. Um invasor pode sobrescrever no máximo 8 bytes de memória em máquinas de 64 bits ou 4 em máquinas de 32 bits. O invasor precisa configurar uma entrada DNS especialmente criada e, em seguida, induzir o alvo a solicitá-la.

Este bug não foi corrigido por cerca de 13 anos e, quando foi corrigido, não foi reconhecido como uma vulnerabilidade de segurança. Os pesquisadores de segurança da Qualys que relataram isso como uma vulnerabilidade gastaram uma grande quantidade de tempo testando programas individuais para explorabilidade. A grande maioria não era, devido à limitação de 8 bytes e às particularidades de como gethostbyname() é normalmente usado. Observe também que simplesmente acionar o bug geralmente fará com que o programa trave: mais uma negação de serviço do que uma exploração.

Seu golpe de misericórdia, um exploit remoto completo do servidor de correio Exim, é uma cadeia Rube Goldberg meticulosamente projetada que conseguiu contornar as limitações usando propriedades específicas de como o Exim organiza sua memória em situações específicas. Ele está totalmente descrito no aviso de segurança da Qualys , e é muito complicado para entrar aqui.

Comparação

Admito que não tenho certeza de qual bug foi mais difícil de encontrar. Ambos permaneceram latentes no código por um longo tempo. Qualys encontrou o bug do Ghost "durante uma auditoria de código"; Stéphane Chazelas encontrou o bug Shellshock extrapolando coisas que ele já sabia sobre o comportamento do Bash , e uma série inteira de bugs relacionados foram encontrados rapidamente quando as pessoas souberam onde procurar, alguns com a ajuda de ferramentas de difusão.

No entanto, a questão de qual era mais difícil de explorar é muito mais fácil de responder. Acho que está claro que um nível muito alto de engenharia foi necessário para encontrar uma maneira de transformar o bug do Ghost em um exploit Exim funcional. Foi necessário muito mais trabalho do que o exploit Shellshock acima, que levou cerca de 10 minutos para ser escrito e testado.

3
Jander