Dicas de segurança: Patch virtual

O tópico do nosso artigo hoje é Patch virtual.

O Patch virtual é uma camada de política de segurança projetada para detectar e impedir a exploração de exploração de vulnerabilidades conhecidas.

O patch virtual começa a funcionar após a análise de tráfego e impede que o tráfego malicioso entre no aplicativo vulnerável. Portanto, o patch virtual, se aplicável, impede a exploração da vulnerabilidade sem modificar o código fonte do aplicativo. Geralmente, o patch virtual é implementado em firewalls para aplicativos da Web (WAF).

Então, por que o patch virtual, por que não apenas atualizar o código?

Obviamente, atualizar o código é a primeira solução recomendada, mas nem sempre é possível, seja a falta de recursos na organização (todos os desenvolvedores já estão ocupados e não podem ser transferidos para correções de emergência), o uso do software de outra pessoa (como posso alterar o código aqui) ou apenas precisar reescrever um pouco se não todo o aplicativo para este patch.
Isso não significa que o patch virtual e a atualização de código sejam coisas mutuamente exclusivas! Eles geralmente são executados por comandos diferentes (tendo em vista as especificidades desses processos), para que o patch e a atualização possam ocorrer em paralelo.

Os benefícios do patch virtual são os seguintes:

• Uma solução rápida (relativamente) para fechar a vulnerabilidade até que não haja possibilidade de um patch completo.
• Se o aplicativo da Web for o seu produto, ele não violará os possíveis processos de negócios existentes, ou seja, se o próximo patch para o produto estiver planejado, por exemplo, em um mês, você não precisará interromper o cronograma inteiro.
• A capacidade de fechar vulnerabilidades com membros de outra equipe, se os desenvolvedores não puderem fazer isso no momento.
• Oportunidade - se você usa um software pronto, não se sabe quando o patch do seu produto será lançado e, é claro, você não deseja deixá-lo vulnerável.

Desvantagens do patch virtual:

• Isso ainda não é uma panacéia. Ao usá-lo, nem todos os vetores de ataque podem ser cobertos, pelo que o perigo de operação permanecerá.
• A desvantagem de todas as soluções temporárias é a probabilidade de que o temporário se torne permanente. A empresa decidirá que, uma vez que funcione, não tocaremos mais e deixaremos as coisas como estão.
• Esta é uma solução complementar, a vulnerabilidade em si não desaparece, mas simplesmente se esconde atrás de uma camada adicional de proteção.

A preparação para o patch virtual pode ser dividida nas seguintes etapas:

1. Preparação
2. Identificação de ameaças
3. Análise
4. Crie um patch virtual
5. Implementação e Teste
6. Recuperação / continuação do trabalho

Vulnerabilidade pública

Por exemplo, considere a injeção de SQL e o ModSecurity WAF (desde código aberto).

WordPress Shopping Cart Plugin  WordPress /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php  reqID   SQL Injection. 

O plug-in do carrinho de compras do WordPress para WordPress contém uma falha que pode permitir que um invasor execute uma injeção de SQL. O problema está no script /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php, no qual o parâmetro reqID não é higienizado corretamente.

Isso pode permitir que um invasor incorpore ou manipule consultas SQL no back-end, o que leva à possibilidade de obter acesso ilegal aos dados, com todas as conseqüências resultantes.

Fase de preparação

Como em muitos processos, a preparação para o patch virtual é um componente importante. Antes de lidar com uma vulnerabilidade descoberta (ou pior ainda, com um ataque em tempo real), você precisa fazer algumas coisas. O ponto de preparação não é entender freneticamente durante o ataque como o patch virtual funciona e como integrar o WAF à infraestrutura atual, se não estiver presente, mas executar ações certas e bem pensadas.

Aqui estão alguns pontos críticos que precisam ser abordados na preparação:

• Monitorando vulnerabilidades do fornecedor ou de fontes públicas - se você usar software de terceiros, verifique se está inscrito em todas as correspondências de emergência dos fornecedores. Isso ajudará você a se manter atualizado sobre novas vulnerabilidades ao seu software e patches relacionados.
• Prepare todo o trabalho necessário com antecedência para permitir a aplicação de patches virtuais - os patches virtuais devem ser integrados rapidamente, para que o processo de verificação usual dos patches não funcione aqui. Como os patches virtuais não alteram o código-fonte, eles não exigem a mesma quantidade de testes que os patches de software comuns. Vale a pena atribuir patches virtuais à mesma categoria que atualizações para antivírus ou atualizações de assinatura para o IDS. Isso irá acelerar significativamente o processo de lançá-los em produção.
• Insira os utilitários do patch virtual com antecedência - como o principal critério do patch virtual é a velocidade, instalar um novo software se você precisar de um patch de emergência, para dizer o mínimo, é uma má idéia.
• Aumente o log para seus sistemas - o padrão de log usado pela maioria dos servidores por padrão (CLF) não fornece dados suficientes para responder corretamente a incidentes. Você deve ter acesso aos seguintes dados:
  
  ◦ Solicitar URI (incluindo QUERY_STRING)
  ◦ Todos os cabeçalhos de solicitação (incluindo cookies)
  Body Corpo completo da solicitação (incluindo carga do POST)
  ◦ Cabeçalhos de resposta completa
  Body Corpo de resposta completo

Estágio de detecção de ameaças

Esse estágio começa quando a organização descobre que há uma vulnerabilidade em seu aplicativo da web. Em geral, existem duas abordagens diferentes para identificar vulnerabilidades - pró-ativas e reativas.

Abordagem proativa

O caso em que a organização realiza trabalho de segurança e executa as seguintes tarefas:

• Avaliação dinâmica do aplicativo - pentests e / ou testes de avaliação automática são executados em um aplicativo Web em execução para identificar deficiências.
• Revisão do código fonte - é realizada uma avaliação manual e / ou automática do código fonte de um aplicativo da web para detectar deficiências.

Abordagem reativa

Existem três métodos reativos principais para identificar vulnerabilidades:

• Uma mensagem do fornecedor - quando o fornecedor do software publica informações sobre uma vulnerabilidade descoberta.
• Publicação pública é a publicação de uma vulnerabilidade descoberta para o software usado em fontes públicas. Nesse caso, sua resposta à vulnerabilidade deve ser mais rápida do que nos relatórios do fornecedor, pois mais pessoas sabem sobre a vulnerabilidade.
• Incidente de segurança - isso significa que o ataque já está em andamento. É necessária ação imediata para concretizar e fechar a vulnerabilidade.

Fase de análise

Etapas recomendadas para a fase de análise:

• Determine como o patch virtual é adequado para o seu caso - é ótimo para fechar as falhas associadas à entrada (ou seja, injeção), mas pode não fornecer um nível adequado de proteção para ataques de outros tipos ou categorias. Uma análise detalhada e completa do problema subjacente deve ser realizada para determinar se o software de patch virtual fornecerá um nível adequado de detecção e cobertura.
• Envolva seus sistemas para rastrear bugs / tarefas - insira informações de vulnerabilidade em seu rastreador para rastreamento e investigação adicionais.
• Verifique a vulnerabilidade - encontre o nome oficial da vulnerabilidade, se existir. Se ele foi detectado por métodos proativos, você deve fornecer seu próprio número / nome exclusivo.
• Determinar o nível de risco - é sempre importante entender o quão crítico pode ser o impacto da exploração dessa vulnerabilidade para você. Por exemplo, se será um vazamento de informações ou acesso ao banco de dados.
• Determine quais versões de software estão em risco - é importante entender se você está em risco ou não.
• Determine sob quais configurações do software um problema pode surgir - algumas vulnerabilidades podem aparecer apenas em determinadas configurações do seu software.
• Faça uma lista das explorações ou cargas úteis da Prova de Conceito usadas durante o ataque / teste - muitas publicações de vulnerabilidade são acompanhadas de código PoC que demonstra a vulnerabilidade. Se esses dados estiverem disponíveis, analise-os. Isso será útil no desenvolvimento e teste de um patch virtual.

Estágio de criação de um patch virtual

O processo de criação de um bom patch virtual está vinculado a dois aspectos:

• Sem falsos positivos - nunca bloqueie o tráfego normal, apesar das circunstâncias
• Sem falsos positivos - nunca perca um ataque, mesmo quando o atacante tenta deliberadamente evitar a detecção.

Esforços devem ser feitos para minimizar o impacto de ambas as regras. Pode não ser possível (o que acontece com mais frequência) seguir as duas regras, mas é importante lembrar que o patch virtual é para reduzir riscos.

Criação manual de um patch virtual
Abordagem positiva (lista de permissões, lista de permissões) no patch virtual

Essa abordagem é criar uma validação de entrada independente para o aplicativo da web. A abordagem determina as características dos dados válidos (conjunto de caracteres, comprimento, etc.) e proíbe qualquer coisa que não se encaixe nessas condições. Ao definir as regras para cada parâmetro em cada página do aplicativo Web, envolvemos o aplicativo em uma camada adicional de proteção, independente do seu código-fonte.

Um exemplo de criação de um patch virtual baseado na lista de permissões no ModSecurity
Para criar um patch virtual na lista de permissões, precisamos poder verificar os valores normais esperados. Se o log correto tiver sido pré-configurado como parte da fase de preparação, na revisão do log, você poderá entender o formato dos valores de entrada esperados.

Um exemplo

Nesse caso, o parâmetro reqID deve conter apenas números inteiros para que possamos aplicar esse patch virtual:

 # # ,     1    "reqID" # SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:1,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter - Duplicate Parameters Names Seen.',logdata:'%{matched_var}'" SecRule &ARGS:/reqID/ "!@eq 1" # # ,   reqID     # SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:2,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter.',logdata:'%{args.reqid}'" SecRule ARGS:/reqID/ "!@rx ^[0-9]+$" 

Este patch virtual analisará o parâmetro reqID e permitirá apenas números inteiros na entrada. No entanto, vale lembrar que o vetor de ataque quase nunca é único e o atacante pode tentar a sorte de outra maneira.

Abordagem negativa (lista negra, lista negra) no patch virtual

Essa abordagem é baseada em uma lista de regras que definem certos ataques conhecidos, em vez de permitir apenas tráfego válido.

Um exemplo de criação de um patch virtual baseado em lista negra no ModSecurity

Por exemplo, código PoC de uma fonte pública:

 http://localhost/wordpress/wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php?reqID=1' or 1='1 

Após analisar a carga, podemos ver que o invasor insere uma única citação e adiciona a lógica SQL ao final. Com base nesses dados, podemos proibir aspas simples:

 SecRule REQUEST_URI "@contains /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php" "chain,id:1,phase:2,t:none,t:Utf8toUnicode,t:urlDecodeUni,t:normalizePathWin,t:lowercase,block,msg:'Input Validation Error for \'reqID\' parameter.',logdata:'%{args.reqid}'" SecRule ARGS:/reqID/ "@pm '" 

Cuidado ao criar patches virtuais para explorações específicas

Obviamente, isso parece atraente e economiza tempo. Por exemplo, se o pentest encontrou o XSS na sua página e usou a seguinte carga:

 <script> alert('XSS Test') </script> 

Não seria razoável criar um patch virtual que bloqueie especificamente essa carga, por mais atraente que seja em termos de esforço e velocidade. Um patch virtual precisa ser criado para fechar o problema como um todo, e não seu caso específico.

Criar patches virtuais automaticamente

A criação manual de patches pode se tornar insuportável devido ao crescente número de vulnerabilidades e a automação se torna uma etapa necessária. Se as vulnerabilidades foram descobertas usando ferramentas automatizadas (por exemplo, verificadores de vulnerabilidades), talvez seja possível converter relatórios dessas ferramentas em patches. As ferramentas de automação de patches mais populares são a importação direta para o WAF (naturalmente, se a sua solução suportar isso), os scripts OWASP ModSecurity Core Rule Set (CRS) e o ThreadFix Virtual Patching.

Estágio de implementação e teste

Para testar corretamente nosso novo patch virtual, podemos precisar das seguintes ferramentas:

• navegador da web
• utilitários da web para terminais (por exemplo, curl e wget)
• proxy local
• ModSecurity AuditViewer

Passos:

• Implemente patches virtuais primeiro no modo "somente logs", para garantir que o tráfego normal do usuário não seja bloqueado (opção falso positivo).
• Se a vulnerabilidade foi descoberta usando ferramentas ou comandos específicos, solicite uma nova verificação.
• Se o reteste falhar porque o patch virtual pode ser ignorado, você precisará voltar à etapa de análise para determinar a melhor forma de fechar o problema.

Estágio de Recuperação / Continuação

• Atualize os dados no seu sistema de tíquetes - embora os prazos para a instalação de patches virtuais estejam em vigor, é melhor rastrear e atualizar as alterações no seu sistema de rastreamento. Isso permitirá lidar de maneira mais adequada e completa com o problema original, com uma chance menor de que alguns detalhes sejam perdidos. Também permite avaliar com mais precisão o tempo gasto em cada estágio da solução do problema.
• Reavaliar periodicamente - isso ajuda a entender quais patches virtuais podem ser removidos já / em breve, pois, por exemplo, um patch de código fonte completo foi / será aplicado.
• Configure relatórios de seus patches virtuais - isso ajudará a entender quando e quantas vezes eles estarão envolvidos. Isso, por sua vez, fornecerá estatísticas sobre os locais com maior probabilidade de risco.