Por que se preocupar e gastar dinheiro e recursos em segurança? Por que se preocupar em organizar um SDL (Ciclo de vida de desenvolvimento de segurança)? Por que integrar a difusão no processo de desenvolvimento? Por que se preocupar com o conhecimento sobre vários difusores como AFL, libfuzz etc.? Afinal, você pode “simplesmente” transformar a busca por vulnerabilidades em seus produtos em tortura contínua e criar uma vida “doce” para pesquisadores e atacantes. Quer saber como fazer isso? Então seja bem-vindo ao kat!
Disclaimer: Este artigo deve ser tomado com uma certa quantidade de humor e ironia!Recentemente, mais e mais trabalhos foram dedicados ao tópico AntiFuzzing. O AntiFuzzing é uma ação que reduz a eficácia e o uso do fuzzing para procurar vulnerabilidades nas soluções de um desenvolvedor.
Este artigo se concentrará nos aplicativos binários confusos escritos em C \ C ++ que podem ser implantados localmente e tentarão encontrar vulnerabilidades relacionadas à corrupção de memória neles.
Hoje, um grande número de ações é direcionado ao fuzzer AFL, como o representante mais impressionante, conhecido e de renome da abordagem de fuzzing baseada em feedback.
Tendo estudado o problema, identificamos possíveis técnicas de AntiFuzzing:
- Organizar os resultados do trabalho do fuzzer é a técnica mais excêntrica que alguns desenvolvedores estão adotando sem perceber) consiste em adicionar mais bugs para tornar o programa mais seguro ... Sim, infelizmente, não podemos responder a questão é quantos de nossos bugs já estão no programa e quão perigosos são, mas podemos diluí-los com vários erros que são inúteis para o atacante!
- A detecção de um processo de difusão é do escopo jailbreak_detect, root_detect. O aplicativo determina de forma independente (e o desenvolvedor faz uma série de verificações) que ele não funciona apenas, mas é faseado e, como resultado, se recusa a funcionar. O setor de segurança da informação já passou por isso um milhão de vezes. Esse código é pesquisado e excluído do aplicativo com bastante facilidade, e a técnica leva o título de "o mais inútil e pouco sofisticado".
- Abrandando o processo de difusão - em nossa empresa, chamamos essas coisas de "ocultar bugs nas despesas gerais". Mesmo agora, alguns softwares funcionam mal, não apenas sob difusão, portanto, procurar vulnerabilidades torna-se uma tarefa psicologicamente difícil para os pesquisadores)
- A criação de zonas de ponto cego é a direção mais interessante que, em nossa opinião, impulsionará a evolução dos difusores. Portanto, no trabalho apresentado no BlackHat 2018, o problema de colisões no shared_mem é levantado pela AFL, que o utiliza para determinar seções de código cobertas. Ou seja, são criadas áreas em que o difusor não cai durante sua operação.
Assim, o AntiFuzzing tem vantagens e desvantagens óbvias:
- "-" Talvez a turvação da mente dos desenvolvedores de software pouco versados em alguns aspectos da segurança da informação e do processo de difusão.
- "+" A evolução dos fuzzers, que no futuro começarão a superar os mecanismos AntiFuzzing implementados e fornecerão maior cobertura em primeiro lugar, se houver mecanismos AntiFuzzing implementados; segundo, quando houver elementos no software que simulem as funções do AntiFuzzing.
Por que usar essa abordagem para garantir a segurança estúpida e prejudicial? O desenvolvimento de uma abordagem AntiFuzzing de alta qualidade e sua aplicação em software real são comparáveis em complexidade ao desenvolvimento do próprio algoritmo para aumentar a cobertura do código com difusão baseada em feedback. A dificuldade é que, além de inserir estruturas inibidoras de fases nos lugares certos, é necessário garantir que elas não possuam um padrão claro que possa ser distinguido e simplesmente excluído. O AntiFuzzing não aumenta a segurança do aplicativo em si ... É bom que, embora a pesquisa do AntiFuzzing seja realizada apenas em um ambiente acadêmico. Ao mesmo tempo, existem empresas que, pelo contrário, estão focadas em simplificar a busca por bugs. Por exemplo, a Mozilla fornece uma compilação especial de seu navegador para este
blog.mozilla.org/security/2018/07/19/introducing-the-asan-nightly-project !
O aumento do interesse no AntiFuzzing foi causado principalmente pelo DARPA Cyber Grand Challenge 2016. Esta é uma competição em que computadores sem ajuda humana pesquisam vulnerabilidades, as exploram e as corrigem. A maioria dos sistemas de busca, como você deve ter adivinhado, era baseada no fuzzer AFL, e todos os alvos na competição eram aplicativos binários. Tudo isso pode ter como objetivo neutralizar sistemas automáticos, e não pessoas.
Este artigo é baseado em trabalhos que você pode estudar sozinho:
- “Escapando do Fuzz Avaliando as técnicas do Fuzzing e enganando-as com o AntiFuzzing” , tese de mestrado em sistemas e redes de computadores
2016 - Chaff Bugs: Deterring Attackers Tornando o Software Buggier , 2018
- “O ponto cego da AFL e como resistir à difusão da AFL para binários arbitrários de ELF” , BlackHat USA 2018
- Também recomendamos que você leia o artigo dos caras do Grupo NCC “Introdução ao Anti-Fuzzing: Uma Defesa em Profundidade” de 2014 (o primeiro lançamento da AFL apareceu e ainda não conquistou o grande amor da comunidade, e mais dois anos antes da final do DARPA CGC).
PS: Trabalhamos frequentemente com o AFL (+ libfuzz) e suas modificações ao pesquisar software e implementar SDL para nossos clientes. Portanto, em um dos artigos a seguir, falaremos mais sobre difusão usando AFL e por que mais e mais pessoas o usam em programas de teste e como isso aumenta o nível de segurança do desenvolvimento.