From: [i shot the sheriff] Edição 41

Ainda há muito o que se discutir, mas em breve a comissão organizadora estará liberando mais novidades sobre o evento e garanto que ele será excepcional.

E o código seguro? Sim, uma das palestras será sobre código seguro, aguardem!

[1] Detectando buffer over/underflow em C e C++ com ferramentas OpenSource

[2] Mudflap

[3] Valgrind

[4] Using valgrind to detect and prevent application memory problems

- Sobre a possibilidade de exisitir uma boa implementação do Python para o Android é um a especulação minha, porém é prematuro avaliar algo sobre uma plataforma que pouco sabemos, considerando a utilização de qualquer tipo de aplicativo, mas com os poucos fundamentos que temos até o momento a primeira coisa a saber é qual será a política de instalação de aplicativos;

1) Totalmente Regulado, onde apenas aplicativos autorizados por assinaturas da OHA poderiam ser instalados.

2) Altamente Controlado, onde só aplicativos assinados teriam acesso a todos os recursos do OS e não assinados teriam acesso restrito, similar a licença do Symbian.

3) Pouco Regulado, similar a segunda opção, porém com certificados para o desenvolvedor e não para a aplicação.

4) Totalmente Livre, deixando a segurança sob total responsabilidade do usuário.

Meu palpite aponta para a segunda possibilidade, pois foi o que senti com o vídeo [4] do Nick Sears, Alex Rubin, Steve Horowritz, Dan Morril, Pelsun Wu, Erick Tseng, Illyan Malchev e de outros membros da equipe de desenvolvimento do Android, mas ele também foi um pouco vago.

Riscos sempre existem, afinal quem não se lembra do A Silent SMS Denial of Service (DoS) Attack [5], dos vírus do Symbian, bluejacking e do bluesnarfing? E vulnerabilidades existem em qualquer plataforma, a questão é se o ataque é de difícil ou fácil exploração entre outros fatores que só poderemos avaliar quando tivermos algo de mais concreto para analisar.

[1] Python & Android

[2] Android do OHA

[3] Mikko da F-Secure

[4] Vídeo de introdução ao Android

[5] A Silent SMS Denial of Service (DoS) Attack

[6] Serious flaws in bluetooth security lead to disclosure of personal data

Agora estou curioso para saber quem irá lançar os posts ou artigos “Coisas que (Quase) Ninguém sabe sobre os *NIX” e principalmente um “Coisas que (Quase) Ninguém sabe sobre Segurança nos *NIX“, ficará mais interessante quando começar a surgir os benchmarks entre eles!
[1] Coisas que quase ninguém sabe sobre a Microsoft

[2] Coisas que (Quase) Ninguém Sabe Sobre Segurança na Microsoft

Como expressa o Sutter, “francamente, você já deveria estar utilizando snprintf mesmo antes dele ter tornado-se padrão” em “os formatadores de strings da Granja do Solar” capítulo do livro Exceptional C++ Style (que traduzido para o pt-br virou Programação avançada em C++) do Herb Sutter, onde de uma forma divertida ele cita George Orwell:

“Todos os animais são iguais, mas alguns são mais iguais do que outros”

Com bom humor e com qualidade, tópicos tratados nestes capítulos também podem ser encontrados nos livros Secure Code in C and C++ do Robert Seacord (CERT – SEI Series), no Escrevendo Código Seguro do LeBlank e do Michael Howard, também no Secure Programming for C and C++ do Matt Messier e do John Viega e são alguns dos 19 pecados mortais do 19 deadly sins of software security também do Michael Howard, David LeBlanc e do John Viega.

Porquê estou comentando isto? e não é só isto, afinal em vários artigos estas recomendações básicas são encontradas. Historicamente, até bugs non sense e incompreendidos são resolvidos quando a boa prática é empregada.

Como há sempre muito mais do mesmo, pra quem realmente programa em C++ e não leu os livros do Sutter [1] recomendo-os, pois além de dicas de codificação segura há dicas para melhorar a perfomance, diminuir armadilhas entre outras, depois o livro do Seacord [2] que apesar do repeteco, é específico e trata de alguns detalhes ausentes na obra do Sutter.

Para todos, recomendo o 19 Deadly Sins of Software Security [3] e para quem está mais interessado numa leitura bem densa entrem de cabeça no “The Art of Software Security Assesment” [4] do Mark Dowd, Johan Mcdonald e do Justin Schuh.

No site http://www.codigoseguro.com.br há seção de livros [5] que vários livros que eu poderia recomendar, mais alguns livros que desconheço, além de vários artigos interessantes para doses homeopáticas.

Para quem quiser uma palhinha, leiam: Top 10 Secure Coding Practices [6] de onde eu tirei esta imagem que eventualmente me vem na cabeça quando encontro certas construções peculiares.

Porém este nome me parecia familiar e eu ainda não estava conseguindo fazer o devido join, foi quando percebi que um dos livros que estava guardado na minha estante aguardando leitura, o criptografia – segredos embalados para viagem é justamente da mesma autora do site, desta forma resolvi ler o livro e constatei que a obra é realmente muito boa.

No fundo a “dream log management tools” sugerida pelo Grossman é algo muito similar ao que eu imagino já a alguns anos, mas o Chuvakin tem razão e seu pensamento vai de encontro com o meu e é muito óbvio; para implementar tal “dream log management tools” a quantidade de recursos computacionais necessários inviabilizam qualquer proposta, mesmo utilizando compressões de dados e outras artimanhas; porém é possível chegarmos a um meio termo, um pouco melhor do que existe hoje e não exatamente como o Grossman propõe.

No último GTS o André Proto e o Jorge Luiz Corrêa da ACME da Unesp de Rio Preto, apresentou seu projeto chamado Banco de dados de fluxos para análises de segurança que vai justamente de encontro com uma dos pilares de viabilização desta ferramenta, porém sem armazenar os payloads; que é o custoso neste processo. Porém eles se baseiam no netflow, desenvolvi um projeto similar, inicialmente utilizando o pcapy e óbvio com Python, depois migrando para C++ utilizei direto o libcap e acho que ele teve um desempenho razoável. De qualquer forma, hoje “penso” em desenvolver um projeto semelhante, integrado ao Snort e ao guardian com um daemon extra de syslog dos servidores monitorados, onde na camada de persistência seria dividida entre servidor de filas e o banco de dados, onde os últimos 10 minutos sempre fiquem armazenados em fila. Quando um alerta for gerado, não só o payload de todos os pacotes do fluxo relativo seria armazenado em database mas todo o channel disponível em fila, isto tudo com a flexibilidade de tunning de sensores que vai de encontro também com a sugestão que o Augusto havia comentado no YSTS, e com um pouco mais de flexibilidade do que alguns IDS oferecem. Mas esta é só uma das features ideais da tal “dream log management tools”!

[1] Ideal Log Management Tool

[2] The Best Web Application Vulnerability Scanner in the World

[3] Jeremiah Grossman

[4] GTS

[5] Banco de dados de fluxos para análises de segurança

O evento YSTS v1.0 superou as expectativas dos participantes e posso afirmar sem nenhuma injustiça que ele foi um marco para eventos do gênero. Tenho participado de vários eventos nos últimos anos, conferências, convenções, workshops e garanto que meus comentários abaixo não são parciais de um geek entusiasta, mas sim uma sóbria perspectiva do que foi realmente o evento.

Segundo o seu anúncio, sua proposta era “trazer para o mesmo palco representantes de diversas camadas do mundo de infosec, oferecendo uma visão abrangente, tornando mais claras as semelhanças de cada uma das partes e reduzindo as barreiras que as separam, em um diálogo sem preconceitos” e felizmente eles alcançaram seus objetivos com grande sucesso, produzindo um evento de grande expressão.

Produzido pelo do pessoal do podcast I sh0t Sherif – Luiz Eduardo, Willian Caprino e Nelson Murilo – o evento contou com speakers de expressão e alto skill aos temas de suas apresentações, reunindo CSOs, analistas de segurança, security engineers, pesquisadores, professores acadêmicos, desenvolvedores e figuras antológicas do cenário da segurança da informação brasileira e mundial, num grande mosaico, com um ambiente intimista, o evento parecia um grande encontro de amigos com muita informação,  diversão e frozen beer.

Detecção de intrusão, a anatomia de um insider, carreira profissional, segurança em VoIP, segurança em computação móvel, a postura da política americana sobre a liberdade de expressão, as atividades da ACME! Computer Security Research e a preparação de seus acadêmicos para o mercado de infosec foram alguns dos temas abordados pelos speakers, incentivando muita conversa interessante que transcendeu estes temas nos bastidores e no Speaker Party que foi outro grande momento do dia.

Certamente, acredito que nenhum dos participantes irá esquecer do leilão da Hacker Foundation e muito menos da presença do Eric Gordon Corley, uops… Emmanuel Goldstein da 2600; que deu um toque especial ao evento. Na realidade, nunca fui em nenhum dos eventos organizados por ele, mas pelo que eu já li e ouvi a respeito, o YSTS foi um evento a lá Goldstein; o que espero conferir no “The Last HOPE” que ocorrerá em 2008.

Muita gente ficou frustrada por não ter conseguido participar e eu os compreendo! Felizmente eu pude verificar que a fórmula faz sucesso, a experiência foi feliz e agora estou na expectativa para versão 2.0; que com alguns ajustes pontuais poderá tornar-se um evento mais sensacional.

[1] YSTS

[2] I sh0t Sherif

[3] Emmanuel Goldstein

[4] YSTS pelo FX

[5] YSTS na Mídia – Matéria sobre carreiras na área de segurança

[6] YSTS por Derneval Cunha

[7] Menção do YSTS pelo Augusto Paes de Barros

E para aqueles que utilizam o Hex-Rays [3] em suas análises estáticas de malwares o Ilfak Guilfanov anunciou um SDK para o Hex-Rays [4] que aparentemente parece ser bem interessante.

O Pedro Augusto, do Security Hub, postou a segunda parte de sua introdução ao spoofing [5] onde ele menciona o HPing [6] e o Scapy [7] que eu também aprecio muito – talvez por ser que o Python é a linguagem que eu mais utilizo – mas dependendo da tarefa prefiro mais o pcapy [8] (que é um projeto da Core) ao Scapy.

Ron Gula lançou mais um de seus posts sobre os plugins do Nessus, este chamado Nessus 3.2 beta – Automated Nessus Program Updates [9] – versão que está disponível desde fevereiro – onde ele comenta sobre o plugin de atualização automática de novas vulnerabilidades, além de outros recursos como o suporte ao IPv6 scanning [10], a library para escrever consultas WMI customizadas [11] mas principalmente que ele está mais rápido tanto no processo de login quanto no processo de varredura. Acho que vale lembrar, que o Nessus tem uma família de plugins para verificação de protocolos SCADA [12]

E o Augusto, mais uma vez mandou um post sobre insider threat [13], que é um de seus assuntos preferidos, vide sua excelente apresentação no YSTS v1.0.

[1] Treinameto hands-on de Snort

[4] SDK para o Hex-Rays

[5] Introdução ao spoofing

[6] HPing

[7] Scapy

[8] pcapy

[9] Nessus 3.2 beta – Automated Nessus Program Updates

[10] Nessus Pv6 scanning

[12] Nessus – Plugins SCADA Family

[14] The Insider Threat Will Eat Your Babies