Primeiramente o H2CSO, um evento para colocar de frente em um debate Hackers e executivos de Seguranca da Informacao teve um sucesso impressionante.

Contanto com o apoio da Decision Report, reunimos impressionantes 750 pessoas, sendo 600 do Brasil e 150 do exterior. Locamente tivemos a presenca ilustre dos Senhores Nicolas Waisman (Immunity Manager), Andrew Cushman (Microsoft Security Unit Senior Director), Edgar Barbosa (Senior Reverse Engineer, Coseinc), Sebastian Porst (Binnavi Lead Developer, Zynamics), Ricupero (CIO Grupo Abril) e representantes de diversas outras organizacoes nacionais e internacionais tais como Porto Seguro, Deutsch Bank, Sumitomo Bank e ISC2.

Diversos temas polemicos foram discutidos, rondando principalmente nos objetivos de se contratar hackers e investir em pesquisas mesmo para empresas que nao tem este foco como negocio e como faze-lo, propiciando ambiente fertil para desenvolvimento de novas ideias.

Referente ao H2HC tambem fico meio sem palavras! Particularmente acho que nos superamos totalmente este ano, e tenho ate medo de pensar como conseguiremos um evento de tamanha qualidade novamente no ano que vem! Tivemos 11 palestrantes internacionais, outros tantos nacionais, todos de excepcional qualidade, com diversas novas tecnicas e vulnerabilidades sendo divulgadas pela primeira vez aqui, no Brasil!

Os videos e materiais do evento serao disponibilizados em ate 6 meses apos o mesmo. Espero receber feedbacks a respeito!

Obrigado a todos os patrocinadores, em especial Immunity, Microsoft, Coseinc e Check Point, sem os quais nao teriamos conseguido!

P.S.: O hotel novotel do morumbi foi um local espetacular para organizar o evento, excelente escolha Balestra!

Kurt, como o DNSSEC pode ajudar a proteger o serviço de DNS?

Em teoria, o DNSSEC permite que o cliente verifique se os dados recebidos em resposta a uma consulta DNS estão corretos e não foram alterados no meio do caminho.

O problema do DNSSEC, no entanto, tem dois lados: (1) todos os servidores, incluindo os servidores raiz, precisam suportá-lo, o que não é uma tarefa trivial, principalmente quando se considera o número de pessoas com DNSs contratados cujos provedores ainda não suportam DNSSEC; e (2) para oferecer benefícios reais (idealmente), todos os clientes precisam suportar o DNSSEC, ou, se possível, exigi-lo.

A boa notícia é que a maioria dos fornecedores de Linux estão se encaminhando para isso, e a má notícia é que a Microsoft só oferece clientes com suporte a DNSSEC no Windows 2008 e Windows 7, então todos os usuários do Vista e do XP estão sem sorte.

Neste caso, é improvável que o DNSSEC ajude de alguma forma, ou seja, faltam alguns anos para que o DNSSEC funcione.

Será um debate entre Hackers e gerentes de segurança da informação sobre as ameaças mais críticas, como os ataques funcionam e por que é tão importante investir em pesquisas na área de segurança.

Nesta palestra demonstrei uma técnica nova que desenvolvi para coleta de informações sobre o alvo, provendo as mesmas para o fuzzer de forma que este possa melhorar a geração dos casos de testes. Tal técnica combina o feedback-based fuzzing com mutação do alvo, permitindo assim clusterização.

A mesma pode ser obtida no site do evento e contém em seu final um exemplo da aplicação do mesmo para descobrir detalhes de duas vulnerabilidades que afetam o solaris.

O mesmo trata sobre o Ltrace, excelente ferramenta para depuração de programas em Linux, que embora não seja tão famosa quanto seu par strace é muito mais completa.

Fica aqui o link para o artigo e a recomendação para os leitores de usarem ele!

Peço que participem, enviando idéias de itens a serem discutidos e comentando as entradas!

O H2HC (http://www.h2hc.com.br) acontecerá nos dias 28 e 29 de novembro e conta este ano com 11 palestrantes internacionais e tradução simultânea.

Com patrocínio de empresas de renome tais quais Microsoft, Check Point, Immunity, Coseinc e Compugraf o mesmo é o maior evento da América Latina na área de pesquisas em segurança da informação, sendo também o mais antigo na região.
Fica aqui o convite para que participem!

O servidor DNS faz o melhor que pode para fornecer dados “corretos”. Mas é possível alguém influenciar (envenenar, ou poison) os dados servidos. Basicamente, quando você pede informações a um servidor DNS (tais como “onde fica exemplo.org?”), um agressor também consegue incluir outras informações, como “www.seubanco.com.br”.

Essa informação fica em cache, e se o agressor conseguir controlar o que vai para o cache, ele pode “envenená-lo” e forçar a inclusão de informações maliciosas. No final das contas, isso permite que o agressor redirecione tráfego de um site legítimo para o dos bandidos.

Como evitar isso? Certifique-se de que os seus servidores DNS estejam usando a versão mais recente do Bind e de que estejam configurados adequadamente (haha) ou use o seu próprio resolvedor raiz (normalmente, no pacote “caching-nameserver”, ou algo semelhante).

Este ano a conferência conta com diversas novidades e parcerias, sendo realizada em um hotel da cidade de SP. Maiores novidades não deixe de conferir no website: http://www.h2hc.com.br

A conferência é nova, sendo este seu primeiro ano e contou com a ilustre presença de Richard Stallman.

Os vídeos das palestras serão disponibilizados via internet, e o site da conferência é: http://www.frhack.org.

Abraços,

Rodrigo (BSDaemon).

Um amigo meu vive criticando o PAM por “não fazer sentido e ser coberto de vulnerabilidades”. O PAM realmente é uma ameaça à segurança do sistema? Por quê?

Hmm, não sei bem como responder esta. O PAM é o Pluggable Authentication Module, que permite autenticar usuários quando eles tiverem credenciais (nome de usuário e senha) válidos, ou já estejam logados fisicamente (isto é, ele permite o acesso ao desligamento do sistema sem permitir qualquer outro privilégio).

Com relação a vulnerabilidades de segurança, a maioria delas consiste em revelação de informações, negação de serviço etc. Poucas realmente permitem que o agressor ganhe acesso ou aumente seus privilégios.

A alternativa é basicamente voltar à idade média, quando cada pacote que precisava de autenticação usava seu próprio código para isso.

Não, obrigado, é muito melhor centralizar essas operações no PAM, que permite também definir políticas etc