sexta-feira, 14 de outubro de 2011

Novo projeto: File hash repository

Estive quieto nos últimos tempos, mas estou de volta. :-)

Fora ajudar na organização do AppSec Latam 2011, eu estive também recluso trabalhando em um novo projeto, o File Hash Repository (FHR), que, se tudo der certo, será em breve um novo projeto do OWASP.

Mas o que é o FHR?
Simplificando: o FHR é um repositório de hashes de arquivos. Só que a ideia é ir além de somente guardar uma lista de hashes: pretendo que o repositório possa indicar quando os arquivo em questão for (parte de) um malware ou quando for um arquivo reconhecidamente benigno. Assim, qualquer um poderia consultar o hash de um arquivo para saber se corresponde a um malware ou a um arquivo já conhecido.

Já não existem outras fontes com essa informação?
Sim, e uma das ideias do projeto é agregar informações de diversas fontes. Por exemplo, o NIST tem o NSRL, que provê hashes de arquivo reconhecidamente benignos. O problema é que o NIST fornece essa informação em um arquivo texto cujo download tem mais de 1GB de tamanho. Outras fontes conhecidas são o MHR do Team Cymru, o repositório de hashes do SANS e o Virus Total.
Além de agregar as informações, um dos objetivos do FHR é permitir livre acesso à sua base de dados.

O livre acesso a uma base de dados que contém malware não é perigoso?
Sim, é perigoso, mas o repositório do projeto não vai conter malwares. O repositório só vai ter os hashes dos malwares, o que não apresenta nenhum perigo.

Detectar malwares usando hashes não é boa estratégia.
Certamente, e o projeto não tem o objetivo de substituir os antivírus atuais. No entanto, a criação de hashes é mais eficiente e fácil do que a criação de vacinas genéricas e é uma estratégia que vem sendo usada como complemento para os antivírus tradicionais. Vários produtos comerciais incluem o uso de cloud computing como parte de suas estratégias. Infelizmente, os produtores dessas tecnologias não permitem que façamos consultas a suas bases de dados de hashes. Com o FHR, o objetivo é criar uma base de livre consulta e que possa ser usada por todo mundo.

O FHR vai ser integrado em sistemas de antivírus?
Eu pretendo desenvolver alguns sistemas clientes para o FHR que possam fazer varreduras em estações de trabalho e consultar a base se dados do FHR para tentar identificar malwares. Esses clientes serão criados para uso próprio e como prova de conceito e terão seus códigos abertos. Seria ótimo se tivermos apoio de algum fabricante de antivírus, mas só o tempo dirá.

Tecnicamente, como funciona o FHR?
Como não poderia deixar de ser, o núcleo do sistema é a sua base de dados de hashes. Hoje essa base roda em MySQL (pretendo depois fazer um post sobre a novela da escolha da base de dados).
Em volta dessa base, podemos desenvolver várias interfaces de consulta. Algumas ideias de protocolos para consultas são:

  1. DNS
  2. Web
  3. WebServices
  4. JSON
No momento, já tenho funcionando a interface para consultas via DNS, que só não está integrada ao DNS global porque meu provedor bloqueia acessos à porta 53 UDP. A medida que o projeto amadurecer, devemos conseguir migrar o servidor para um provedor de hosting a então teremos um DNS 100% funcional.

Quais informações já estão disponíveis?
No momento a base de dados já tem os 20 milhões de registros do FHR. Em breve teremos funcionalidades de consulta a outras bases devidamente implementadas.
Para cada arquivo cadastrado, temos as seguintes informações:
  1. SHA-1
  2. MD5
  3. fonte
  4. data de quando o sistema viu o hash/arquivo pela primeira vez (não disponível para os arquivos do NIST)
  5. status (GOOD, MALWARE, UNKNOWN, SUSPICIOUS)
  6. tamanho
  7. certeza (percentagem que indica o grau de certeza com relação ao status do arquivo).
É possível testar o sistema?
Claro! A interface DNS está disponível para testes. Mas, como está rodando em casa, nem sempre está no ar. Para ver como funciona, é necessário fazer uma consulta DNS ao servidor do FHR (ns.hash.sapao.net) na porta 1053. O hash deve ser acrescido ao sufixo .hash.sapao.net. A consulta do registro tipo A retorna um endereço da rede 127.0.0.0/8 cujo último octeto indica o status do arquivo. Consultas do tipo TXT retornam uma string com todas as informações disponíveis. 
Eu recomendo o uso do dig para fazer as consultas manualmente. Um exemplo de linha de comando seria:
dig @ns.hash.sapao.net -p1053 TXT 84C0C5914FF0B825141BA2C6A9E3D6F4.hash.sapao.net
É possível contribuir com o projeto?
Claro! Entre em contato comigo ou deixe um comentário.

5 comentários:

Wagner Elias disse...

Lucas,

muito bacana a idéia e parabéns pelo trabalho.

Sei que comentou a novela para escolher uma base de dados, mas me parece um bom caso de uso de NoSQL.

Abs.

Lucas disse...

Oi Wagner,

eu pensei em NoSQL, mas acabou não funcionando tão bem. No final o melhor desempenho veio mesmo do bom e velho MySQL.

Vou tentar publicar a "novela" em breve.

Inté,

Lucas

Sandro Süffert disse...

Grande Lucas, parabéns pela iniciativa!

Além dos serviços já citados (Cymru, Sans, VirusTotal), existe também o FileAdvisor da Bit9:

http://www.bit9.com/products/bit9-fileadvisor.php

[ ]s,

Tony Rodrigues disse...

Lucas, show de bola.

Se puder, acrescente Fuzzy Hash à base. Isso é muito útil para comparação de variantes e de malware extraído direto da memória.

Abração,

Tony

Lucas disse...

Oi Sandro,

o problema do Bit9 é que ele exige um registro e login antes de permitir acesso aos dados. Terei de trabalhar nisso depois e ver o que vai ser possível fazer.

Tony,

o problema é conseguir um fonte de dados que tenha fuzzy hashes. Se souber de alguma, posso verificar como fazer para integrá-la.

Inté,

Lucas