FHR: novidades

Algumas novidades rápidas sobre o FHR (leia mais sobre o projeto no último post):

1. o FHR agora é OWASP FHR, o projeto foi aprovado pelo OWASP. A partir de agora, as novidades serão postadas na página do projeto: https://www.owasp.org/index.php/OWASP_File_Hash_Repository
2. O servidor DNS do FHR está integrado ao DNS mundial. Ainda restam algumas arestas a aparar com relação à disponibilidade, mas já está funcionando.

Agora, para fazer consultas, basta usar:

dig 84C0C5914FF0B825141BA2C6A9E3D6F4.hash.sapao.net

ou, caso queira o registro completo:

dig TXT 84C0C5914FF0B825141BA2C6A9E3D6F4.hash.sapao.net 

outros comandos que gerem consultas DNS também podem ser usados, como:

ping 84C0C5914FF0B825141BA2C6A9E3D6F4.hash.sapao.net 

Como detalhe técnico, registro que o servidor do FHR está rodando na núvem da Amazon (AWS EC2).

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.

Lei de crimes digitais - 2

Embora eu não concorde com a gritaria geral contra o projeto de crimes digitais, tem um ponto onde eu acho que o projeto poderia ser melhorado: a questão dos códigos maliciosos.

O texto diz o seguinte:

IV – código malicioso: o conjunto de instruções e tabelas de informações ou qualquer
outro sistema desenvolvido para executar ações danosas ou obter dados ou informações de
forma indevida;

Inserção ou difusão de código malicioso
Art. 163-A. Inserir ou difundir código malicioso em dispositivo de
comunicação, rede de computadores, ou sistema informatizado:
Pena – reclusão, de 1 (um) a 3 (três) anos, e multa.

 Nesse ponto, podemos ter a criminalização da atividade de desenvolvimento de softwares de segurança, o que seria prejudicial às atividades dos profissionais de segurança da informação.

Muitas vezes usamos programas capazes de realizar ataques para testar o estado da segurança de alguma rede ou sistema. Esses programas claramente executam "ações danosas", mas os profissionais os utilizam de forma responsável para que os danos, caso existam, seja limitados. Embora a posse e a construção dessas ferramentas não esteja tipificada, esses programas só são úteis se forem distribuídos, o que poderia ser considerado "difusão".

Ou seja, ferramentas de pentest estariam disponíveis apenas aos criminosos, dando um vantagem indesejada com relação aos verdadeiros profissionais de segurança. Esse artigo e a definição de código malicioso merecem um reescrita cuidadosa. Nesse caso, acho que a intenção é o cerne da questão. A difusão para fins de causar dano deve ser criminalizada, mas a difusão como forma de compartilhamento de conhecimento deve ser permitida.

Edit:  uma nova proposta corrige esta distorção: http://edemocracia.camara.gov.br/en/web/seguranca-da-internet/wikiLegis

Lei de crimes digitais

A proposta de lei é polêmica e tem seus pontos falhos, mas me irrita a quantidade de críticas que o projeto recebe de gente que força a barra só pra poder falar mal. A última que eu li foi que "o projeto vai criminalizar a cultura e pesquisa hacker".

Isso porque o projeto define como crime:

Art. 285-A. Acessar rede de computadores, dispositivo de comunicação ou sistema informatizado, sem autorização do legítimo titular, quando exigida:

Pena – reclusão, de 1 (um) a 3 (três) anos, e multa.

Parágrafo único. Se o agente se vale de nome falso ou da utilização de identidade de terceiros para a prática do crime, a pena é aumentada de sexta parte.

Se alguém defende a "cultura hacker", deveria ao menos se dar ao trabalho de ler um pouco a respeito. Mesmo a wikipedia admite que, dentro da "ética hacker", a invasão de sistemas não é unanimamente aceita como um comportamento éticamente aceitável. Ou seja, colocar a invasão de sistemas como algo natural na "cultura hacker" é generalizar um pensamento de alguns, em detrimento do demais.

Além disso, chamar as pessoas que invadem sistemas de pesquisadores é um desrespeito com os pesquisadores de verdade. Nenhum pesquisador que seja digno do nome sai por aí invadindo sistemas. E os profissionais de verdade não invadem sistemas de graça, até porque são muito bem pagos para invadirem os sistemas de seus clientes.

Confundir os script kiddies que ficam por aí "testando" sites com profissionais de verdade só demonstra falta de conhecimento ou má fé.

Um paralelo com o mundo físico é possível nesse caso: no jardim em frente à minha casa, tenho um coqueiro. Embora não haja grade ou muro entre a rua e o jardim, há uma pequena cerca viva que deixa claro que o jardim faz parte da minha propriedade. Algumas vezes já aconteceu de eu pegar gente subindo no coqueiro para apanhar cocos. Embora qualquer prejuízo que isso possa me causar seja insignificante, não deixa de ser uma invasão à minha propriedade para pegar algo que me pertence.

Para mim, um invasor de sistemas, mesmo que não altere nada, tem uma atitude parecida com a pessoa que pega os meus cocos: está desrespeitando os direitos do legítimo proprietário do bem, seja ele um coco ou um sistema. Não importa o tamanho do prejuízo ou das defesas instaladas para evitar a invasão: se há uma clara delimitação de onde termina o território público, não há motivo que justifique o desrespeito à propriedade privada.

Continuando o paralelo, se o cara que pegou os cocos tivesse batido na porta e perguntado se podia pegar um coco, eu certamente teria deixado e, mais ainda, teria negociado para que ele pegasse todos os que estivessem bons e lhe daria alguns como "pagamento" pelo trabalho. Por que a atitude correta no mundo virtual seria outra? Eu conheço muitas organizações que gastam bastante dinheiro para testar a segurança de sues sistemas. Um pesquisador de verdade poderia facilmente negociar para fazer esses testes em troca dos conhecimentos adquiridos ou da possibilidade de divulgação dos problemas encontrados (anonimamente, claro).

Enfim, a ética dos grupos com os quais convivo, muitos dos quais poderiam ser claramente definidos como "hackers", é: "nunca entre sem pedir licença". Em outras palavras, testes de segurança só devem ser feitos com a devida autorização e, se alguma vulnerabilidade for descoberta, nunca deve ser usada para acessar sistemas indevidamente. E esse comportamento não será afetado pela lei.

Outra crítica que vejo muito é de que a lei tem definições muito vagas. Isso acontece com outros tipo penais e não vejo tanta reclamação, Por exemplo a definição de dano:

Dano

Art. 163 - Destruir, inutilizar ou deteriorar coisa alheia:

Pena - detenção, de 1 (um) a 6 (seis) meses, ou multa.

Pra mim, essa definição permitiria criminalizar muitas condutas que normalmente não vemos como crime. Ou alguém já foi preso por pisar na grama do vizinho? Ou por derramar vinho na toalha da mesa do restaurante?

A aplicação das leis não se dá ao pé da letra e exige bom senso e a observância de diversos princípios que o Direito desenvolveu ao longo dos anos. Se não levarmos isso em conta, vamos acabar pedindo a revisão de toda a nossa legislação penal. Por outro lado, se as definições de crimes mais corriqueiros pode ser feita sem tanta precisão, por que os "crimes de informática" precisam ser tipificados nos mínimos detalhes?

Segurança na Web - Uma janela de oportunidades

Já tem algum tempo que eu estou meio sumido, mas tenho um bom motivo para isso: eu estava trabalhando na elaboração de um manifesto com sugestões da comunidade brasileira do OWASP para o governo brasileiro.

A ideia do manifesto é apresentar de forma resumida e didática algumas ideias que são constantemente discutidas dentro do OWASP e fora dele também. Muitas das ideias vem do keynote do Dinis Cruz no IBWAS 2010. Vários dos temas tratados no manifesto refletem o discurso de importante figuras do cenário mundial da segurança de informações, como o Bruce Schneier e o Divid Rice.

O manifesto do OWASP inclui sugestões de ações e políticas que o governo e os gestores de órgãos públicos podem tomar para melhorar as condições de segurança na internet brasileira. São sugestões de possíveis marcos legais e também de ações concretas que poderiam ser adotadas por qualquer órgão público.

O documento está disponível no site do OWASP e, como todos os documentos do OWASP, pode ser livremente distribuídos a todos os possíveis interessados.

Novos livros

Caramba! Tem tento tempo que não apareço aqui no blog que nem tinha notado que fiquei uns 6 meses sem postar. Foi a trabalheira do AppSec Brasil 2010 e depois fim de ano, férias, etc.

Mas estou de volta... Esta semana, meu amigo Kenji anunciou que havia publicado um livro para o Kindle. Fui verificar, comprei o livro, mas não antes de perceber que o Kenji publicou o livro usando o pseudo-pseudônimo de "Leonardo K. Shikida". Pois é: se procurar por Kenji na Amazon, ninguém acha o livro do Kenji. Mas enfim.

Depois de comprar o livro do Kenji, fiquei com inveja. Afinal já tive filhos, plantei árvores, mas nunca havia publicado um livro. Então resolvi publicar um livro sobre desenvolvimento seguro em Java (só pra variar). E o livro já está disponível aqui.

Acabei empolgando e fiz a versão digital do "De Que Cor São Suas Asas?", supostamente meu primeiro livro de ficção, mas que nunca havia sido publicado de verdade. Esse também está disponível na Amazon.