Virtual Patch

O que é, qual sua importância segundo a OWASP?

Folha de referências do virtual patch

Introdução

O objetivo com esta folha de dicas é apresentar uma estrutura de virtual patch concisa que as organizações podem seguir para maximizar a implementação oportuna de proteções de mitigação.

Definição: Patching Virtual

Uma camada de aplicação da política de segurança que evita e relata a tentativa de exploração de uma vulnerabilidade conhecida.

O virtual patch funciona quando a camada de aplicação de segurança analisa as transações e intercepta os ataques em trânsito, de forma que o tráfego malicioso nunca alcance o aplicativo da web. O impacto resultante da correção virtual é que, embora o código-fonte real do aplicativo em si não tenha sido modificado, a tentativa de exploração não é bem-sucedida.

Por que não apenas consertar o código

De uma perspectiva puramente técnica, a estratégia de remediação número um seria para uma organização corrigir a vulnerabilidade identificada dentro do código-fonte do aplicativo da web. Esse conceito é universalmente aceito por especialistas em segurança de aplicativos da web e proprietários de sistemas. Infelizmente, em situações de negócios do mundo real, surgem muitos cenários em que atualizar o código-fonte de um aplicativo da web não é fácil, como:

  • Falta de recursos – os desenvolvedores já estão alocados para outros projetos.
  • Software de terceiros – O código não pode ser modificado pelo usuário.
  • Desenvolvimento de aplicativos terceirizados – as alterações exigiriam um novo projeto.

O ponto importante é este – as correções no nível do código e o Virtual Patching NÃO são mutuamente exclusivos. Eles são processos executados por equipes diferentes (OWASP Builders/Devs vs. OWASP Defenders/OpSec) e podem ser executados em conjunto.

Valor do virtual patch

Os dois objetivos principais do Virtual Patching são:

  • Minimize o tempo de correção – Consertar o código-fonte do aplicativo leva tempo. O objetivo principal de um virtual patch é implementar uma atenuação para a vulnerabilidade identificada o mais rápido possível. A urgência dessa resposta pode ser diferente: por exemplo, se a vulnerabilidade foi identificada internamente por meio de revisões de código ou teste de penetração versus encontrar uma vulnerabilidade como parte da resposta ao incidente ao vivo.
  • Redução da superfície de ataque – concentre-se em minimizar o vetor de ataque. Em alguns casos, como a ausência de validação de entrada de segurança positiva, é possível atingir 100% de redução da superfície de ataque. Em outros casos, como falta de codificação de saída para falhas de XSS, talvez você só consiga limitar as exposições. Lembre-se – 50% de redução em 10 minutos é melhor do que 100% de redução em 48 horas.

Ferramentas de Virtual Patch

Observe que a definição acima não lista nenhuma ferramenta específica, pois há uma série de opções diferentes que podem ser usadas para esforços de virtual patch, como:

  • Dispositivos intermediários, como um dispositivo WAF ou IPS
  • Plug-in de servidor da Web como ModSecurity
  • Filtro de camada de aplicação como ESAPI WAF

Para fins de exemplo, mostraremos exemplos de patches virtuais usando a ferramenta WAF de código-fonte aberto ModSecurity .

Uma metodologia de virtual patch

Patching virtual, como a maioria dos outros processos de segurança, não é algo que deva ser abordado aleatoriamente. Em vez disso, deve ser seguido um processo consistente e repetível que proporcionará as melhores chances de sucesso. O seguinte fluxo de trabalho de patching virtual imita a prática aceita pela indústria para conduzir a Resposta a Incidentes de TI e consiste nas seguintes fases:

  1. Preparação.
  2. Identificação.
  3. Análise.
  4. Criação de virtual patch.
  5. Implementação/Teste.
  6. Recuperação/Acompanhamento.

Vulnerabilidade pública de exemplo

Vamos tomar a seguinte vulnerabilidade de injeção de SQL como nosso exemplo para o restante deste artigo:

WordPress Shopping Cart Plugin for WordPress

/wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.php

reqID Parameter prone to SQL Injection.

Descrição:

WordPress Shopping Cart Plugin para WordPress contém uma falha que pode permitir que um invasor execute um ataque de injeção de SQL.

O problema é devido ao /wp-content/plugins/levelfourstorefront/scripts/administration/exportsubscribers.phpscript não higienizar adequadamente a entrada fornecida pelo usuário para o reqID parâmetro.

Isso pode permitir que um invasor injete ou manipule consultas SQL no banco de dados back-end, permitindo a manipulação ou divulgação de dados arbitrários.

Fase de Preparação

A importância de utilizar adequadamente a fase de preparação em relação ao patching virtual não pode ser exagerada. Você precisa fazer uma série de coisas para configurar os processos e a estrutura de virtual patch antes de realmente ter que lidar com uma vulnerabilidade identificada, ou pior ainda, reagir a uma intrusão de aplicativo da web ao vivo. A questão é que durante um compromisso ao vivo não é o momento ideal para propor a instalação de um firewall de aplicativo da web e o conceito de um virtual patch. A tensão é alta durante incidentes reais e o tempo é essencial, portanto, estabeleça a base da correção virtual quando as águas estiverem calmas e coloque tudo no lugar e pronto para funcionar quando ocorrer um incidente.

Aqui estão alguns itens críticos que devem ser abordados durante a fase de preparação:

  • Monitoramento de vulnerabilidade pública/fornecedor – Certifique-se de que você se inscreveu em todas as listas de e-mail de alerta de fornecedor de software comercial que está usando. Isso garantirá que você seja notificado caso o fornecedor libere informações de vulnerabilidade e dados de patch.
  • Pré-autorização de patches virtuais – os patches virtuais precisam ser implementados rapidamente para que os processos normais de governança e as etapas de autorização para patches de software padrão sejam acelerados. Como os patches virtuais não estão realmente modificando o código-fonte, eles não exigem a mesma quantidade de teste de regressão que os patches normais de software. A categorização de patches virtuais no mesmo grupo de atualizações de antivírus ou assinaturas de IDS de rede ajuda a acelerar o processo de autorização e minimizar fases de teste estendidas.
  • Implante a ferramenta virtual de patch com antecedência – como o tempo é crítico durante a resposta a incidentes, seria um momento ruim para obter aprovações para instalar um novo software. Por exemplo, você pode instalar o ModSecurity WAF no modo incorporado em seus servidores Apache ou um servidor proxy reverso Apache. A vantagem dessa implantação é que você pode criar correções para servidores back-end não Apache. Mesmo se você não usar o ModSecurity em circunstâncias normais, é melhor tê-lo “no convés” pronto para ser ativado se necessário.
  • Aumente o registro de auditoria HTTP – O Common Log Format (CLF) padrão utilizado pela maioria dos servidores da web não fornece dados adequados para conduzir uma resposta adequada a incidentes. Você precisa ter acesso aos seguintes dados HTTP:
    • Solicitar URI (incluindo QUERY_STRING)
    • Cabeçalhos de solicitação completos (incluindo cookies)
    • Corpo de solicitação completo (carga útil POST)
    • Cabeçalhos de resposta completa
    • Corpo de resposta completa

Fase de Identificação

A fase de identificação ocorre quando uma organização toma conhecimento de uma vulnerabilidade em seu aplicativo da web. Geralmente, existem dois métodos diferentes de identificação de vulnerabilidades: Proactive e Reactive.

Identificação Proativa

Isso ocorre quando uma organização se encarrega de avaliar sua postura de segurança na web e realiza as seguintes tarefas:

  • Avaliações dinâmicas de aplicativos – os invasores de Whitehat conduzem testes de penetração ou ferramentas automatizadas de avaliação da web são executadas no aplicativo da web ao vivo para identificar falhas.
  • Revisões do código-fonte – os invasores do Whitehat usam meios manuais/automatizados para analisar o código-fonte do aplicativo da web para identificar falhas.

Devido ao fato de que os aplicativos da web codificados personalizados são exclusivos, essas tarefas de identificação proativas são extremamente importantes, pois você não pode contar com notificações de vulnerabilidade de terceiros.

Identificação Reativa

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

  • Contato do fornecedor (por exemplo, pré-aviso) – ocorre quando um fornecedor divulga uma vulnerabilidade para o software de aplicativo comercial da Web que você está usando. Exemplo é o Programa de Proteção Ativa da Microsoft (MAPP)
  • Divulgação pública – Divulgação pública de vulnerabilidade para software aplicativo da Web comercial/de código aberto que você está usando. O nível de ameaça para divulgação pública aumenta à medida que mais pessoas sabem sobre a vulnerabilidade.
  • Incidente de segurança – esta é a situação mais urgente, pois o ataque está ativo. Nessas situações, a correção deve ser imediata.

Fase de Análise

Aqui estão as etapas recomendadas para iniciar a fase de análise:

  1. Determinar a aplicabilidade do virtual patch – o virtual patch é ideal para falhas do tipo injeção, mas pode não fornecer um nível adequado de redução da superfície de ataque para outros tipos ou categorias de ataque. Uma análise completa da falha subjacente deve ser conduzida para determinar se a ferramenta de patching virtual tem recursos de lógica de detecção adequados.
  2. Utilize o sistema de rastreamento de bugs/tíquetes – insira as informações de vulnerabilidade em um sistema de rastreamento de bugs para fins de rastreamento e métricas. Recomende que você use os sistemas de bilhetagem que você já usa, como o Jira, ou uma ferramenta especializada, como o ThreadFix.
  3. Verifique o nome da vulnerabilidade – isso significa que você precisa ter o identificador de vulnerabilidade público adequado (como nome/número CVE) especificado pelo anúncio de vulnerabilidade, varredura de vulnerabilidade, etc. Se a vulnerabilidade for identificada proativamente em vez de por meio de anúncios públicos, então você deve atribuir seu próprio identificador exclusivo para cada vulnerabilidade.
  4. Designe o nível de impacto – É sempre importante entender o nível de criticidade envolvido com uma vulnerabilidade da web. Vazamentos de informações não podem ser tratados da mesma maneira que um problema de injeção de SQL.
  5. Especifique quais versões de software são afetadas – você precisa identificar quais versões de software estão listadas para que possa determinar se as versões instaladas são afetadas.
  6. Liste qual configuração é necessária para acionar o problema – Algumas vulnerabilidades podem se manifestar apenas sob certas definições de configuração.
  7. Lista de código de exploração de Prova de Conceito (PoC) ou cargas úteis usadas durante ataques/testes – muitos anúncios de vulnerabilidade acompanham código de exploração que mostra como demonstrar a vulnerabilidade. Se esses dados estiverem disponíveis, certifique-se de baixá-los para análise. Isso será útil mais tarde, ao desenvolver e testar o virtual patch.

Fase de Criação de Virtual patch

O processo de criação de um virtual patch preciso é limitado por dois inquilinos principais:

  1. Sem falsos positivos – nunca bloqueie o tráfego legítimo em nenhuma circunstância.
  2. Sem falsos negativos – Nunca perca os ataques, mesmo quando o invasor tenta intencionalmente escapar da detecção.

Deve-se ter cuidado para tentar minimizar qualquer uma dessas duas regras. Pode não ser possível aderir 100% a cada um desses objetivos, mas lembre-se de que o virtual patch é sobre redução de risco. Os proprietários de negócios devem entender que, embora você esteja ganhando a vantagem de encurtar a métrica de Tempo para consertar, pode não estar implementando uma correção completa para a falha.

Criação manual de virtual patch

Segurança positiva (lista de permissões) Patches virtuais ( solução recomendada )

O modelo de segurança positivo (lista de permissões) é um mecanismo de segurança abrangente que fornece um envelope de validação de entrada independente para um aplicativo. O modelo especifica as características da entrada válida (conjunto de caracteres, comprimento, etc …) e nega qualquer coisa que não esteja em conformidade. Ao definir regras para cada parâmetro em cada página do aplicativo, o aplicativo é protegido por um envelope de segurança adicional independente de seu código.

EXEMPLO DE VIRTUAL PATCH DO MODSECURITY DE LISTA DE PERMISSÕES

Para criar um virtual patch de lista de permissões, você deve ser capaz de verificar quais são os valores de entrada normais esperados. Se você implementou o log de auditoria adequado como parte da Fase de Preparação, você deve ser capaz de revisar os logs de auditoria para identificar o formato dos tipos de entrada esperados. Neste caso, o reqID parâmetro deve conter apenas caracteres inteiros para que possamos usar este virtual patch:

##

## Verify we only receive 1 parameter called “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/ “[email protected] 1”

##

## Verify reqID’s payload only contains integers

##

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/ “[email protected] ^[0-9]+$”

Este virtual patch irá inspecionar o reqID valor do parâmetro na página especificada e evitar qualquer caractere diferente de inteiros como entrada.

  • Nota – Você deve se certificar de atribuir IDs de regra corretamente e rastreá-los no sistema de rastreamento de bugs.
  • Cuidado : Existem vários vetores de evasão ao criar patches virtuais. Consulte o documento OWASP Best Practices: Virtual Patching para uma discussão mais completa sobre métodos de combate à evasão.

Patches virtuais de segurança negativa (lista de bloqueio)

Um modelo de segurança negativo (lista de bloqueios) é baseado em um conjunto de regras que detectam ataques conhecidos específicos em vez de permitir apenas tráfego válido.

EXEMPLO DE VIRTUAL PATCH DO MODSECURITY DE LISTA DE BLOCOS

Aqui está o exemplo de código PoC fornecido pelo consultor público:

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

Olhando para a carga útil, podemos ver que o invasor está inserindo um caractere de aspas simples e, em seguida, adicionando lógica de consulta SQL no final. Com base nesses dados, poderíamos proibir o caractere de aspas simples como este:

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 ‘”

Qual método é melhor para virtual patch – segurança positiva ou negativa

Um virtual patch pode empregar um modelo de segurança positivo ou negativo. Qual você decidir usar depende da situação e de algumas considerações diferentes. Por exemplo, regras de segurança negativas geralmente podem ser implementadas mais rapidamente, no entanto, as possíveis evasões são mais prováveis.

As regras de segurança positivas, por outro lado, fornecem melhor proteção, no entanto, geralmente é um processo manual e, portanto, não é escalonável e difícil de manter para sites grandes/dinâmicos. Embora as regras de segurança positiva manuais para um site inteiro possam não ser viáveis, um modelo de segurança positiva pode ser empregado seletivamente quando um alerta de vulnerabilidade identifica um local específico com um problema.

Cuidado com patches virtuais específicos de exploração

Você deseja resistir à tentação de seguir o caminho mais fácil e criar rapidamente um virtual patch específico para exploits.

Por exemplo, se um teste de penetração autorizado identificou uma vulnerabilidade XSS em uma página e usou a seguinte carga de ataque no relatório:

<script>

alert(‘XSS Test’)

</script>

Não seria sensato implementar um virtual patch que simplesmente bloqueie a carga útil exata. Embora possa fornecer alguma proteção imediata, seu valor de longo prazo é reduzido significativamente.

Criação de virtual patch automatizada

A criação manual de patch pode se tornar inviável conforme o número de vulnerabilidades aumenta e meios automatizados podem se tornar necessários. Se as vulnerabilidades foram identificadas usando ferramentas automatizadas e um relatório XML está disponível, é possível aproveitar os processos automatizados para converter automaticamente esses dados de vulnerabilidade em patches virtuais para sistemas de proteção.

Três exemplos incluem:

  • Scripts OWASP ModSecurity Core Rule Set (CRS) – O OWASP CRS inclui scripts para converter automaticamente a saída XML de ferramentas como [OWASP ZAP em ModSecurity Virtual Patches]. Referência aqui .
  • ThreadFix Virtual Patching – ThreadFix também inclui processos automatizados de conversão de dados XML de vulnerabilidade importados em patches virtuais para ferramentas de segurança como ModSecurity. Referência aqui .
  • Importação direta para dispositivo WAF – Muitos produtos WAF comerciais têm a capacidade de importar dados de relatório XML da ferramenta DAST e ajustar automaticamente seus perfis de proteção.

Fase de Implementação/Teste

Para testar com precisão os patches virtuais recém-criados, pode ser necessário usar um aplicativo diferente de um navegador da web. Algumas ferramentas úteis são:

  • Navegador da web.
  • Clientes da Web de linha de comando, como Curl e Wget.
  • Servidores proxy locais, como OWASP ZAP .
  • ModSecurity AuditViewer – que permite carregar um arquivo de log de auditoria do ModSecurity, manipulá-lo e reinjetar os dados em qualquer servidor web.

Etapas de teste

  • Implemente patches virtuais inicialmente em uma configuração “Somente registro” para garantir que você não bloqueie nenhum tráfego de usuário normal (falsos positivos).
  • Se a vulnerabilidade foi identificada por uma ferramenta ou equipe de avaliação específica – solicite um novo teste.
  • Se o novo teste falhar devido a evasões, você deve voltar para a fase de Análise para identificar a melhor forma de corrigir o problema.

Fase de Recuperação/Acompanhamento

  • Atualizar dados no sistema de tíquetes – embora seja necessário acelerar a implementação de patches virtuais, você ainda deve rastreá-los em seus processos normais de gerenciamento de patches. Isso significa que você deve criar tickets de solicitação de mudança adequados, etc … para que sua existência e funcionalidade sejam documentadas. Atualizar o sistema de tíquetes também ajuda a identificar métricas de “tempo para consertar” para diferentes tipos de vulnerabilidade. Certifique-se de registrar corretamente os valores de ID da regra de virtual patch.
  • Reavaliações periódicas – você também deve fazer reavaliações periódicas para verificar se/quando pode remover patches virtuais anteriores se o código do aplicativo da web foi atualizado com a correção do código-fonte real. Eu descobri que muitas pessoas optam por manter os patches virtuais no lugar devido a uma melhor identificação/registro em comparação com aplicativos ou recursos de banco de dados.
  • Executando relatórios de alerta de virtual patch – execute relatórios para identificar se/quando algum de seus patches virtuais foi acionado. Isso mostrará o valor do patching virtual em relação às janelas de exposição para o tempo de correção do código-fonte.

Referências

Traduzido e adaptado de: https://cheatsheetseries.owasp.org/cheatsheets/Virtual_Patching_Cheat_Sheet.html, acessado em 26/08/2021.