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.