Verificação de vulnerabilidades e desenvolvimento seguro. Parte 1

Como parte de suas atividades profissionais, desenvolvedores, pentesters e especialistas em segurança precisam lidar com processos como gerenciamento de vulnerabilidades (VM), SDLC (seguro).
Por baixo destas frases encontram-se diferentes conjuntos de práticas e ferramentas utilizadas que estão interligadas, embora os seus utilizadores sejam diferentes.

O progresso técnico ainda não atingiu o ponto em que uma ferramenta possa substituir uma pessoa na análise da segurança da infraestrutura e do software.
É interessante entender por que isso acontece e quais problemas enfrentamos.

Процессы

O processo de gerenciamento de vulnerabilidades foi projetado para monitoramento contínuo da segurança da infraestrutura e gerenciamento de patches.
O processo Secure SDLC (“ciclo de desenvolvimento seguro”) foi projetado para manter a segurança do aplicativo durante o desenvolvimento e operação.

Uma parte semelhante desses processos é o processo de avaliação de vulnerabilidades - avaliação de vulnerabilidades, verificação de vulnerabilidades.
A principal diferença entre a varredura de VM e SDLC é que no primeiro caso o objetivo é detectar vulnerabilidades conhecidas em software ou configuração de terceiros. Por exemplo, uma versão desatualizada do Windows ou a sequência de comunidade padrão para SNMP.
No segundo caso, o objetivo é detectar vulnerabilidades não apenas em componentes de terceiros (dependências), mas principalmente no código do novo produto.

Isso cria diferenças em ferramentas e abordagens. Na minha opinião, a tarefa de encontrar novas vulnerabilidades em uma aplicação é muito mais interessante, pois não se resume a impressão digital de versões, coleta de banners, força bruta de senhas, etc.
Para uma verificação automatizada de vulnerabilidades de aplicativos de alta qualidade, são necessários algoritmos que levem em consideração a semântica do aplicativo, sua finalidade e ameaças específicas.

Muitas vezes, um scanner de infraestrutura pode ser substituído por um temporizador, como eu disse avleonov. A questão é que, puramente estatisticamente, você pode considerar sua infraestrutura vulnerável se não a atualizar, digamos, por um mês.

Ferramentas

A verificação, assim como a análise de segurança, pode ser realizada usando uma caixa preta ou uma caixa branca.

Caixa-preta

Ao escanear a caixa preta, a ferramenta deve ser capaz de trabalhar com o serviço por meio das mesmas interfaces pelas quais os usuários trabalham com ela.

Os scanners de infraestrutura (Tenable Nessus, Qualys, MaxPatrol, Rapid7 Nexpose etc.) procuram portas de rede abertas, coletam “banners”, determinam versões de software instalado e pesquisam em sua base de conhecimento informações sobre vulnerabilidades nessas versões. Eles também tentam detectar erros de configuração, como senhas padrão ou acesso aberto a dados, cifras SSL fracas, etc.

Os scanners de aplicativos da Web (Acunetix WVS, Netsparker, Burp Suite, OWASP ZAP, etc.) também podem identificar componentes conhecidos e suas versões (por exemplo, CMS, frameworks, bibliotecas JS). As principais etapas do scanner são rastreamento e difusão.
Durante o rastreamento, o scanner coleta informações sobre interfaces de aplicativos e parâmetros HTTP existentes. Durante a difusão, dados mutados ou gerados são inseridos em todos os parâmetros detectados para provocar um erro e detectar uma vulnerabilidade.

Esses scanners de aplicativos pertencem às classes DAST e IAST - Dynamic and Interactive Application Security Testing, respectivamente.

white Box

Existem mais diferenças com a digitalização de caixa branca.
Como parte do processo de VM, os scanners (Vulners, Incsecurity Couch, Vuls, Tenable Nessus, etc.) geralmente recebem acesso aos sistemas executando uma verificação autenticada. Assim, o scanner pode baixar versões de pacotes instalados e parâmetros de configuração diretamente do sistema, sem adivinhá-los nos banners de serviço de rede.
A varredura é mais precisa e completa.

Se falamos de varredura de caixa branca (CheckMarx, HP Fortify, Coverity, RIPS, FindSecBugs, etc.) de aplicativos, geralmente estamos falando de análise estática de código e do uso de ferramentas apropriadas da classe SAST - Static Application Security Testing.

Problemas

Existem muitos problemas com a digitalização! Tenho que lidar com a maioria deles pessoalmente no âmbito da prestação de serviços de construção de processos de digitalização e desenvolvimento seguro, bem como na execução de trabalhos de análise de segurança.

Destacarei três grupos principais de problemas, que são confirmados por conversas com engenheiros e chefes de serviços de segurança da informação em diversas empresas.

Problemas de verificação de aplicativos da Web

1. Dificuldade de implementação. Os scanners precisam ser implantados, configurados, personalizados para cada aplicação, alocados em um ambiente de teste para varreduras e implementados no processo de CI/CD para que isso seja eficaz. Caso contrário, será um procedimento formal inútil que só produzirá falsos positivos
2. Duração da verificação. Mesmo em 2019, os scanners fazem um péssimo trabalho de desduplicação de interfaces e podem passar dias digitalizando mil páginas com 10 parâmetros em cada uma, considerando-as diferentes, embora o mesmo código seja responsável por elas. Ao mesmo tempo, a decisão sobre a implantação na produção dentro do ciclo de desenvolvimento deve ser tomada rapidamente
3. Recomendações ruins. Os scanners fornecem recomendações bastante gerais, e o desenvolvedor nem sempre consegue entender rapidamente como reduzir o nível de risco e, o mais importante, se isso precisa ser feito agora ou ainda não é assustador
4. Impacto destrutivo no aplicativo. Os scanners podem muito bem realizar um ataque DoS em um aplicativo e também podem criar um grande número de entidades ou alterar as existentes (por exemplo, criar dezenas de milhares de comentários em um blog), portanto, você não deve iniciar uma varredura impensadamente na produção
5. Baixa qualidade de detecção de vulnerabilidades. Os scanners geralmente usam uma matriz fixa de cargas úteis e podem facilmente ignorar uma vulnerabilidade que não se enquadra no cenário de comportamento conhecido do aplicativo.
6. O scanner não compreende as funções do aplicativo. Os próprios scanners não sabem o que são “Internet banking”, “pagamento”, “comentário”. Para eles, existem apenas links e parâmetros, portanto, uma enorme camada de possíveis vulnerabilidades da lógica de negócios permanece completamente descoberta; eles não pensarão em fazer uma dupla baixa, espionar os dados de outra pessoa por ID ou aumentar o saldo através de arredondamentos
7. O scanner não entende a semântica das páginas. Os scanners não conseguem ler perguntas frequentes, não conseguem reconhecer captchas e, por conta própria, não descobrem como se registrar e fazer login novamente, que você não pode clicar em “sair” e como assinar solicitações ao alterar o parâmetro valores. Como resultado, a maior parte do aplicativo pode nem ser verificada.

Problemas ao digitalizar o código-fonte

1. Falso-positivo. A análise estática é uma tarefa complexa que envolve muitas compensações. A precisão muitas vezes tem que ser sacrificada, e mesmo scanners empresariais caros produzem um grande número de falsos positivos
2. Dificuldade de implementação. Para aumentar a precisão e a integridade da análise estática, é necessário refinar as regras de varredura, e escrever essas regras pode ser muito trabalhoso. Às vezes é mais fácil encontrar todos os locais no código com algum tipo de bug e corrigi-los do que escrever uma regra para detectar tais casos
3. Falta de suporte de dependência. Grandes projetos dependem de um grande número de bibliotecas e estruturas que ampliam os recursos da linguagem de programação. Se a base de conhecimento do scanner não tiver informações sobre os "sumidouros" nesses frameworks, isso se tornará um ponto cego e o scanner simplesmente não entenderá o código
4. Duração da verificação. Encontrar vulnerabilidades no código é uma tarefa complexa em termos de algoritmos. Portanto, o processo pode levar muito tempo e exigir recursos computacionais significativos.
5. Baixa cobertura. Apesar do consumo de recursos e do tempo de varredura, os desenvolvedores da ferramenta SAST ainda precisam fazer concessões e analisar nem todos os estados em que o programa pode estar.
6. Reprodutibilidade dos resultados. Apontar para a linha específica e a pilha de chamadas que levam a uma vulnerabilidade é ótimo, mas, na realidade, muitas vezes o scanner não fornece informações suficientes para verificar a presença de uma vulnerabilidade externa. Afinal, a falha também pode estar no código morto, inacessível para um invasor

Problemas de verificação de infraestrutura

1. Inventário insuficiente. Em grandes infraestruturas, especialmente aquelas separadas geograficamente, muitas vezes é mais difícil saber quais hosts verificar. Em outras palavras, a tarefa de digitalização está intimamente relacionada à tarefa de gerenciamento de ativos
2. Priorização deficiente. Os scanners de rede produzem frequentemente muitos resultados com falhas que não podem ser exploradas na prática, mas formalmente o seu nível de risco é elevado. O consumidor recebe um relatório de difícil interpretação e não está claro o que precisa ser corrigido primeiro.
3. Recomendações ruins. A base de conhecimento do scanner geralmente contém apenas informações muito gerais sobre a vulnerabilidade e como corrigi-la, então os administradores terão que se munir do Google. A situação é um pouco melhor com os scanners de caixa branca, que podem emitir um comando específico para corrigir
4. Feito à mão. As infraestruturas podem ter muitos nós, o que significa potencialmente muitas falhas, cujos relatórios devem ser analisados ​​e analisados ​​manualmente a cada iteração
5. Cobertura deficiente. A qualidade da verificação da infraestrutura depende diretamente do tamanho da base de conhecimento sobre vulnerabilidades e versões de software. Em que, Acontece, mesmo os líderes de mercado não possuem uma base de conhecimento abrangente, e os bancos de dados de soluções gratuitas contêm muitas informações que os líderes não possuem
6. Problemas com patch. Na maioria das vezes, corrigir vulnerabilidades de infraestrutura envolve atualizar um pacote ou alterar um arquivo de configuração. O grande problema aqui é que um sistema, especialmente um legado, pode se comportar de maneira imprevisível como resultado de uma atualização. Essencialmente, você terá que realizar testes de integração na infraestrutura ativa em produção.

Aproximações

Como pode ser isso?
Contarei mais sobre exemplos e como lidar com muitos dos problemas listados nas partes a seguir, mas por enquanto indicarei as principais direções nas quais você pode trabalhar:

1. Agregação de várias ferramentas de digitalização. Com o uso correto de diversos scanners, é possível obter um aumento significativo na base de conhecimento e na qualidade da detecção. Você pode encontrar ainda mais vulnerabilidades do que o total de todos os scanners lançados separadamente, ao mesmo tempo que pode avaliar com mais precisão o nível de risco e fazer mais recomendações
2. Integração de SAST e DAST. É possível aumentar a cobertura do DAST e a precisão do SAST através da troca de informações entre eles. Nas fontes você pode obter informações sobre rotas existentes e, usando o DAST, você pode verificar se a vulnerabilidade é visível de fora
3. Aprendizado de Máquina™. Em 2015 eu contado (e mais) sobre o uso de estatísticas para dar aos scanners uma intuição de hacker e acelerá-los. Definitivamente, isso é motivo para o desenvolvimento de análises automatizadas de segurança no futuro.
4. Integração do IAST com autotestes e OpenAPI. Dentro do pipeline CI/CD, é possível criar um processo de varredura baseado em ferramentas que funcionam como proxy HTTP e testes funcionais que funcionam sobre HTTP. Os testes e contratos OpenAPI/Swagger fornecerão ao scanner as informações que faltam sobre os fluxos de dados e possibilitarão a varredura do aplicativo em vários estados
5. Configuração correta. Para cada aplicação e infraestrutura, é necessário criar um perfil de varredura adequado, levando em consideração o número e a natureza das interfaces e as tecnologias utilizadas
6. Personalização do scanner. Freqüentemente, um aplicativo não pode ser verificado sem modificar o scanner. Um exemplo é um gateway de pagamento, no qual cada solicitação deve ser assinada. Sem escrever um conector no protocolo de gateway, os scanners bombardearão inconscientemente solicitações com a assinatura errada. Também é necessário escrever scanners especializados para um tipo específico de defeito, como Referência Insegura de Objeto Direto
7. Gerenciamento de riscos. A utilização de vários scanners e a integração com sistemas externos como Gestão de Ativos e Gestão de Ameaças permitirá a utilização de vários parâmetros para avaliar o nível de risco, para que a gestão possa obter uma imagem adequada do estado atual de segurança do desenvolvimento ou infraestrutura

Fique ligado e vamos atrapalhar a verificação de vulnerabilidades!

Fonte: habr.com