Twitter?

É eu me rendi a mais uma "ferramenta" geek! Eu conheci o twitter há algum tempo atrás e confesso que achei meio bobo, sem sentido. Conversando com alguns amigos eu fui convencido a olhar com mais calma, afinal, poderia ser mais uma ferramenta para troca de idéias, opiniões, sobre o que eu penso e faço no meu dia-a-dia.

Bom, fui lá e dei-um "Forgot password" e resolvi começar a "twittar" (é assim que se fala?).

Quem quiser acompanhar e claro, apreciar com moderação, é só me incluir (é assim? Calma, estou começando.) acessando a URL: http://twitter.com/welias

Pen-test não morre não, fiquem tranquilos!

No início de Dezembro Brian Chess co-fundador da Fortify escreveu um artigo para o portal CSO Online com o seguinte título: Penetration Testing: Dead in 2009.

Como o título foi extremamente sensacionalista e na minha opinião, as declarações de Chess foram bastante parciais em favor do produto/negócio da Fortify, as interpretações não foram as melhores.

Ivan Arce CTO da Core Security escreveu um outro artigo para o mesmo portal com o título: Twelve Reasons Pen Testing Won't Die

Neste artigo Arce "contra-ataca" Chess e faz uma brincadeira criando o acrônimo, SISSP (School of Information Systems Security Prophets) e descreve de forma muito clara inúmeros motivos para se realizar testes de segurança (pen-tests).

No maior estilo Schopenhauer, Chess, escreveu outro post no blog da Fortify: Penetration Testing is Dead, Long Live Penetration Testing

A minha opinião sobre esta novela toda é: Muda-se o nome, muda-se a "roupagem" mas os testes de segurança sempre deverão ser feitos. Afinal, como será garantido que os produtos mesmo após um bom SDL (secure Development Lifecycle) são realmente seguros como deveriam ser? Como diria Michael Howard: "Ou você testa ou alguém ira testar por você".

SDL e falha de XML Parser do Internet Explorer

Um excelente post no blog Security Development Lifecycle, fala sobre a falha de XML Parser que afeta algumas versões do Internet Explorer da Microsoft.

A falha irá causar algumas mudanças na capacitação dos desenvolvedores, segundo o post o conteúdo dos treinamentos voltados ao SDL (Secure Development Lifecycle) não cobre com clareza a falha que ocorreu.

"Code Analysis and Review

Memory-related TOCTOU bugs are hard to find through code review; we teach TOCTOU issues, and we teach memory corruption issues, and issues with using freed memory blocks; but we do not teach memory-related TOCTOU issues. We will update our training to address this.

Our static analysis tools don't find this because the tools would need to understand the re-entrant nature of the code."

Devido a característica bastante peculiar da falha, muito provavelmente a falha foi encontrada por acaso, pois até mesmo as técnicas de fuzzing (considerada bala de prata por alguns) não conseguiriam identificar facilmente.

"Fuzz Testing

In theory, fuzz testing could find this bug, but today there is no fuzz test case for this code. Triggering the bug would require a fuzzing tool that builds data streams with multiple data binding constructs with the same identifier. Random (or dumb) fuzzing payloads of this data type would probably not trigger the bug, however."

Outro ponto é a questão da compatibilidade entre as versões. Devido a compatibilidade com versões anteriores não é usado ASLR e NX, o que poderia ter amenizado o problema.

"ASLR and NX

Even though Windows Vista and Windows Server 2008 have both ASLR and NX enabled by default, Internet Explorer 7 does not opt-in to these defenses owing to compatibility issues with many common applications. Internet Explorer 8 enables these defenses by default, but an attack could be mounted by calling a component that does not use these defenses, and then by using an attack technique known as heap-spraying get the attacker's code into the non-ASLR and non-NX memory. This is why it's so important to build components for Windows that use all the available Windows defenses. Matt Thomlinson and I wrote an article on this subject, and David LeBlanc and I wrote Writing Secure Code for Windows Vista that covers the subject in much more detail."

Treinamentos em Janeiro

A Conviso IT Security oferece no primeiro trimestre de 2009, os cursos "Internet Hacking Techniques" e "Web Hacking Techniques" em várias capitais brasileiras:

Internet Hacking Techniques

Ensina o processo de análise de vulnerabilidades técnicas em redes de dados, incluindo técnicas para teste de intrusão (pen-test), scan de vulnerabilidades, testes de resistência de senhas e análise do controle de acesso a dados.

Belo Horizonte: 12, 13 e 14 de janeiro
Manaus: 19, 20 e 21 de janeiro
Recife: 21, 22 e 23 de janeiro
Curitiba: 26, 27 e 28 de janeiro

Web Hacking Techniques

Ao entender as principais vulnerabilidades em aplicações web e como evitar que elas sejam criadas, os alunos deste curso aprendem a revisar a segurança das aplicações web, além de serem capacitados em práticas de programação segura e no uso de ferramentas Open Source para testes de segurança e criação de medidas de proteção neste modelo de aplicação.

Belo Horizonte: 15 e 16 de janeiro
Manaus: 23 e 24 de janeiro

Calendário dos Cursos: http://convisosec.com/yahoo_site_admin1/assets/docs/CSTR_Calendario_2009_V2.35175159.pdf

Browser Security Handbook

O Google lançou um book em versão wiki que, descreve várias características de segurança de diversos browsers. A wiki é atualizada constantemente e é um material interessantíssimo para quem deseja conhecer um pouco mais dos "internals" dos browsers.

As informações são valiosas para quem deseja ir além do debug.print/echo POST/GET no desenvolvimento web. Recomendo fortemente a parte 3 - Experimental and legacy security mechanisms.

O conteúdo se mostrou bastante imparcial e não é voltado apenas para o Chrome do Google.

php, Estefan Esser, e a saga

No último dia 04/12/2008 Stefan Esser, divulgou um advisory que anunciava uma falha no método ZipArchive::extractTo() do php 5.2.6. A falha é um Path Traversal e extremamente simples de explorar. Para explorar a falha é necessário que o sistema utilize o método ZipArchive::extractTo() para upload e fazer a descompressão automática (Muitos CMS utilizam isso). Para quem necessita deste recurso o único meio de tratamento é upgrade para versão 2.5.7. Mais detalhes sobre o advisory estão publicadas neste link.

No Domingo 07/12/2008 o mesmo Stefan Esser, fez alguns comentários sobre os backports relacionados a segurança e disse para tomar cuidado com o upgrade, pois o upgrade para a versão 5.2.7 irá quebrar a diretiva de magic_quotes. Qual o problema disto? Acreditem, muitas aplicações dependem única e exclusivamente disto para tratar problemas de SQL Injection e afins.

Já hoje dia 09/12/2008 novamente ele, anunciou um projeto bem interessante que ele vinha trabalhando e disponibilizou a primeira versão para download. O projeto chama ext/usim e permite que você teste o upgrade para versões mais recentes, assim você pode testar se a sua aplicação irá se comportar perfeitamente nesta versão.

Será que até o final da semana ele vai soltar mais uma?

Coisas que me irritam e espero que mudem

Entre um dia corrido e outro, vou anotando algumas coisas. Quem me conhece sabe, minha área de trabalho é cheia de arquivos texto onde escrevo de tudo, uns comandos que estou começando a usar, um script, algumas referências para ler com mais calma e também coisas do dia-a-dia.

Entre as coisas que venho observando há anos e sempre faço uma anotação ou outra é sobre o mercado de segurança da informação. Está certo que eu sou um pouco mais rabugento que a média, mas muita coisa é de irritar, as anotações servem como válvula de escape. As vezes leio algo ou passo por uma situação e a primeira coisa que vem a cabeça é: vou escrever um post e soltar o verbo, mas acabo anotando e observando um pouco mais. É verdade, as vezes escapa e acabo falando demais. Hoje eu decidi falar sobre uma coisa que me incomoda profundamente.

Profissionais que adoram falar sobre código de ética, classificação da informação, política de segurança e plano de continuidade de negócios

Mas Wagner, você sempre defendeu estes pontos? Sim, eu sempre defendi e acho super importante estes pontos, mas, (a quem diga que após um mas sempre vem uma crítica. :) ) eu estou cansado de encontrar "Grandes" profissionais do mercado de segurança da informação que, nunca implementaram nada, não sabem do que falam e se colocam em posição de sênior e superior a todos que não falam as palavras da moda e não lêem revistas de negócio. Vou dar umas dicas para quem deseja ser este profissional altamente desejado e merecedor de bons cargos e salários.

• Gaste boa parte do seu sálario com um bom terno, camisas, abotoaduras e sapatos bem lustrados;


• Leia todos os livros de auto-ajuda e os nacionais de segurança da informação;


• Faça lobby, muito lobby. Vale convidar para fumar charutos (mesmo que você odeie qualquer tipo de coisa parecida com cigarros), degustar vinhos caros (mesmo que você goste mesmo é de uma cerveja bem gelada);


• Fale muito daquela viagem que você fez para Miami e Buenos Aires, isso é chique, (não é tão chique assim, mas é o que você consegue pagar, pois os ternos são caríssimos) os executivos gostam disto;


• Critique a postura alienada dos técnicos que salvam sua pele, garantem o seu salário e lhe passam as informações para montar aquela maravilhosa apresentação "vendendo" sua área. Afinal, o que seria destes técnicos sem todo seu poder de relacionamento inter-pessoal e astúcia com o power point?

E a regra de ouro é: nunca participe de listas de discussões, não tenha um blog, não tenha opiniões fortes. Isso é exposição demais para um "Grande" profissional como você. Vai que alguém descobre que você é um charlatão, que tudo que você aprendeu nos livros é meia dúzia de palavras e conceitos.

Sobre os temas mais citados em gestão de segurança da informação, IMHO é bem simples:

Código de ética: ou você tem ou não tem. Se você precisa a todo momento ficar falando sobre ética é porque você almeja muito e não tem. Vejo muitos profissionais falando o tempo todo, citando, escrevendo, enormes códigos de ética e na primeira oportunidade o "Gersão" surge dentro deles e a ética só vale para os outros;

Classificação da Informação: super importante e um tema muito interessante, mas quem consegue aplicar da forma como os "Grandes" falam? Escrever políticas e colocar rótulos em algumas informações não irá mitigar nenhum risco;

Plano de Continuidade de Negócios: um dos temas que mais me fascina, me dedico bastante a aprender e estudar o tema, porém, na maioria das vezes só tenho contato com BCP (Bullshit Compliance Plan). Tudo não passa de discurso, um monte de papel sem sentido e algum mané dizendo que vai salvar o mundo com este monte de papel.

Eu acredito muito em segurança da informação, já vi muitos casos de sucesso e conheço grandes profissionais, senão fosse isto eu já havia desistido. Ainda sou Brasileiro e não desisto nunca, acredito na "queda das mascaras" e na maturidade do mercado de segurança da informação e no surgimento de mais Profissionais capacitados e capazes de lidar com todos os riscos que nos assolam todos os dias.

[Update] Resolvi deixar uma coisa bem clara, afinal acho que as interpretações foram diversas. Eu não acredito que todas as pessoas que tomam vinho, se vestem impecavelmente e fumam charutos são charlatonas, a mensagem é bem direta: quem é charlatão que se identifique. Como disse ao Lincoln nos comentários, as pessoas podem ser opostas a estas características e serem charlatonas. Muitos gerentes, executivos em geral gostam de tudo que falei e são responsáveis pelo sucesso de muitas áreas e organizações, estão longe de ser charlatões, se preocupam em ser e não em ter. Apreciem o texto com moderação. :)

SQL Injection e as funções de escape no php

Acredito que todos que acompanham este blog e até mesmo quem tenha qualquer contato com desenvolvimento WEB saiba o que é um SQL Injection e o que se deve evitar para combatê-lo, porém, todos os dias eu me deparo com técnicas ineficazes para tratamento de ataques de SQL Injection baseados na dupla php e MySQL.

A maioria destas técnicas para tratamento de SQL Injection fazem referência a funções de escape ou o popular magic_quotes do php, porém poucos devem saber que estas técnicas são ineficazes para evitar este tipo de ataque. A simples adição de uma barra invertida (" \ ") em uma string que contenha um apóstrofo (" ' ") não irá eliminar a possibilidade de exploração de ataques baseados em SQL Injection.

As funções de escape mais conhecidas são addslashes() e mysql_real_escape_string(). Estas funções irão fazer a seguinte transformação em uma string.

String normal = 'admin'
String com escape = \'admin\'

Agora o que poucos sabem é que o MySQL possibilita que você faça consultas de caracteres baseados na tabela ascii. Execute no MySQL a query: select ascii('a'); e você terá a o código da letra a que é 97. Agora faça o oposto, execute a query: select char(97); e você terá o caracter a. Isso quer dizer que podemos representar strings SQL usando os códigos ascii. Se usarmos a função concat() podemos montar uma query inteira usando os códigos ascii.

Execute a seguinte query no MySQL:

select concat(char(39), char(104), char(116), char(116), char(112), char(58), char(47), char(47), char(119), char(97), char(103), char(110), char(101), char(114), char(101), char(108), char(105), char(97), char(115), char(46), char(99), char(111), char(109), char(39))

O resultado será:

'http://wagnerelias.com'

Reparem que na string criada usando a função concat não é representado o apóstrofo (" ' "), com isso as funções de escape não teriam efeito algum. Portanto, cuidado com as funções de escape, muitas vezes elas não irão lhe salvar de um ataque de SQL Injection. Sempre que possível use Bind Variables implementando as Prepared Statements do MySQL.