quarta-feira, 25 de junho de 2008

Microsoft Source Code Analyzer for SQL Injection

Acaba de ser lançada pelo time de segurança do Microsoft SQL Server uma ferramenta de análise de código fonte especializada em encontrar falhas de injeção SQL em código ASP. Mais detalhes no SQL Server Security blog.

quarta-feira, 28 de maio de 2008

Utilidade Pública - Furo no Flash Player

Várias organizações de segurança de TI (aqui, aqui, aqui) têm divulgado advertências sobre a grave ameaça provocada pelo furo de segurança (estouro de buffer) encontrado no Flash em abril passado. Já existe registro de sites que usam essa vulnerabilidade para instalar software de captura de senhas nas máquinas com navegadores que usam a versão com o furo (aqui).

Antes de duvidar, proteja-se! É simples. Verifique a versão do Flash Player (aqui) e caso seja diferente de 9.0.124.0, faça a atualização (aqui).

segunda-feira, 12 de maio de 2008

WebGoat 5.1 em Português


No último final de semana consegui finalmente terminar a tradução do WebGoat 5.1 (Versão em Inglês). Foram 4 meses aproveitando o tempo de saguão de aeroporto, o próprio vôo, além daquelas situações onde a cabeça só aceita uma atividade mecânica. Foram cerca de 14o arquivos (vide imagem) distribuídos dentre plano da lição, dicas e soluções.

Para quem não conhece, o WebGoat é um site que coleciona um conjunto de páginas com vulnerabilidades divididas por algumas categorias, cujo intuito é de ensinar na prática qual o risco de desenvolver aplicações sem o compromisso com a segurança. Cada página possui um objetivo de ataque específico, descrito pelo plano da lição. Outros elementos, como por exemplo, as dicas permitem que o público adquira gradativamente os conhecimentos necessários para a efetivação de ataque a aplicações web.

Essa iniciativa vem a somar ao trabalho empenhado pela OWASP no sentido de divulgar informações sobre o desenvolvimento de aplicações com segurança. No que tange ao capítulo Brasil, soma-se as ações de tradução dos documentos para o português brasileiro. Tenho observado por onde passo, que ainda é muito grande a ignorância sobre a questão da segurança no desenvolvimento, e essa iniciativa procura diminuir uma das barreiras, o idioma.

Faça o download da versão de instalação aqui. Em breve tudo estará consolidado na página do WebGoat mantida pelo coordenador desse projeto, Bruce Mayhew.

sexta-feira, 9 de maio de 2008

O Impacto do PCI no Mercado

Para quem não conhece o PCI (Payment Card Industry) Standard, como o nome sugere é um padrão que a indústria que processa informações de cartões de crédito é obrigada a seguir. O padrão está organizado em 12 seções em um documento de 16 páginas (aqui). Para efeito da segurança de software, os itens seguintes são os mais relevantes:

6.5 Desenvolva todos os aplicativos de web baseados em diretrizes de codificação seguras tais como as diretrizes do Open Web Application Security Project. Revise o código dos aplicativos customizados para identificar as vulnerabilidades do código. Verifique a prevenção das vulnerabilidades mais comuns no processo de desenvolvimento dos códigos dos softwares para
incluir o seguinte:
6.5.1 Input não validado
6.5.2 Quebra do controle de acesso (por exemplo, uso desonesto dos IDs dos usuários)
6.5.3 Quebra da administração de autenticação/sessão (uso das credenciais da conta e
cookies da sessão)
6.5.4 Ataques ao cross-site scripting (XSS)
6.5.5 Overflow do buffer
6.5.6 Defeitos de injection (por exemplo, structured query language injection (SQL)
6.5.7 Administração incorreta dos erros
6.5.8 Armazenagem insegura
6.5.9 Recusa de serviço
6.5.10 Administração de configuração insegura.

6.6 Assegurar-se de que todos os aplicativos que funcionam por meio da web estejam protegidos
contra ataques conhecidos através dos seguintes métodos:
• Ter todos os códigos de aplicativos customizados revisados para vulnerabilidades comuns através de uma organização que se especialize em segurança de aplicativo
• Instalar uma camada de aplicativos (application layer) de firewall na frente dos aplicativos voltados para a web
Nota: Este método é considerado uma melhor prática até 30 de junho de 2008, e depois dessa data se tornará uma exigência.

Apesar da gama de preocupações abordada pelo modelo, o ponto de maior impacto neste momento vem na nota de duas linhas no final da seção 6.6. Pois a partir de junho próximo, toda entidade que ofereça software que trabalhe com informação de cartões será obrigada a utilizar as ferramentas especificadas por essa seção. Até agora o resultado mais evidente é a luta dos fornecedores para colocar seu produto no mercado (A Cicso é a última), ou se aliar com diferentes fornecedores para tentar oferecer a melhor solução (aqui). É provável que o resultado que mais nos interessa (software seguro) seja uma consequência natural disso e que outros negócios sejam influenciados pelos resultados dessa obrigação imposta pelo PCI. Veremos!

terça-feira, 6 de maio de 2008

Terceirização de Software Seguro

É comum encontrar o cenário onde o contratante e o contratado em uma relação de terceirização nunca ouviram falar em software seguro e isso reflete diretamente nos aspectos legais entre as partes. Porém, algumas organizações já se encontram preocupadas sobre como estabelecer parâmetros legais que façam com que o negócio considere oficialmente a segurança no desenvolvimento, e permita às partes se comprometerem de fato.
Navegando pelo site da OWASP encontrei uma sugestão de minuta de contrato (aqui) que pode ser fonte de inspiração para as empresas que desejarem incorporar em seus contratos esse tipo de obrigação.

sexta-feira, 2 de maio de 2008

(In)Secure Magazine - Abril - 2008

A revista eletrônica, (In)Secure magazine de Abril traz um artigo que muito interessante sobre o desenvolvimento seguro "Producing Secure Software With Software Security Enhanced Processes" elaborado por Marco Morana. O artigo, além de discorrer sobre a abordagem mais defendida hoje para tratar do desenvolvimento de software seguro (segurança desde o princípio, faz ainda uma comparação muito rica sobre as propostas de segurança em processo mais difundidas hoje: MS-SDL, CLASP, Pontos de controle da Cigital.
Vale observar que a revista possui vários outros artigos relacionados a segurança. Vale a pena conferir.

sexta-feira, 28 de março de 2008

O Que Esperar Fortify Souce Code Analyzer?


No final de março, tive a oportunidade de fazer o curso de auditor de código fonte com o Fortify Source Code Analyzer oferecido pela própria Fortify. O curso foi realizado em Denver no Colorado. A cidade, além de ser muito charmosa, fica bem próximo de Aspen. Foi uma pena não ter tido mais tempo para aproveitar esse outro lado.

Voltando ao curso em si, a turma era formada por oito pessoas. Todos inexperientes com a ferramenta. A maioria com experiência em desenvolvimento e em segurança no geral. Vale ressaltar que a Systest foi a empresa com mais participantes, quatro pessoas. O curso foi ministrado por Su Gaustad, cujo conhecimento acerca de desenvolvimento seguro e do uso do Fortify SCA impressiona, sua habilidade para lidar com o público também.

O Fortify SCA é um analisador estático de código fonte, cuja inteligência se resume nas regras desenvolvidas pela Fortify para encontrar furos de codificação, distribuídas dentre as seguintes abordagens de análise:
  • Estrutural - Detecta uso de funções e APIs potencialmente perigosas.
  • Semântica - Detecta furos potencialmente danosos na estrutura ou definição do programa. Por exemplo, uma atribuição de variáveis em Servlets, uso de loggers que não são declarados como static final.
  • Fluxo de Controle - Detecta sequência de operações potencialmente perigosas. Isso remete à visualização análise de sequência de execução das operações, para verificar se alguma delas a aplicação é exposta a vulnerabilidades. Ex. Abrir uma conexão com banco de dados e não fechá-la, pode expor a aplicação à uma sobrecarga por não alocação de recursos.
  • Fluxo de Dados - Detecta potenciais vulnerabilidades relacionadas a dados de entrada em processamento no software. Isso pressupõe uma análise inter-procedural, o que significa que suas regras são capazes reconhecem falhas de um dado recebido por um método, que é passado para outro método e lá sim, que ele oferece risco de se tornar uma vulnerabilidade explorável. Ex. Parâmetro de nome de arquivo recebido por um método é passado como parâmetro para outro método, que faz uso de strcopy para copiar o conteúdo de tal parâmetro para um buffer.
  • Configuração - Localiza erros, pontos frágeis e violação de políticas nos arquivos de implantação da aplicação. Por exemplo, a connectionstring com parâmetros de usuário e senha no Web.Config em aplicações ASP.NET.
  • Agrega a análise do FindBugs.
Seu processo de análise é organizado em três fases complementares:
  • Tradução - onde o código fonte é recolhido segundo uma série de comandos e traduzido em um formato intermediário, que é associado à um BuildID (identificador do projeto em análise).
  • Análise - compreende a busca por vulnerabilidades e análise de acordo com as regras descritas anteriormente.
  • Verificação - garantia de que a análise foi realizada de acordo com as regras e seu resultado informa erros significativos.
Suporta as linguagens comercialmente mais utilizadas (Java, .NET, PHP, ColdFusion, JavaScript, PL-SQL), integra-se com as principais IDEs (Eclipse, Visual Studio 2003/05), como foi desenvolvido em Java, funciona em toda plataforma que suporte a JVM. É facilmente integrada com o ANT também.

Suas regras de análise (rulepack) são propriedade intelectual da Fortify e estão debaixo de forte critptografia. Seu acesso é dependente da manutenção da assinatura anual pelo seu uso. O que significa que, além da licença, é necessária a assinatura para usar o rulepack. Apesar de altamente não recomendado, a ferramenta permite ainda que sejam elaboradas regras próprias para as análises. Prepare-se pois a tarefa é de alta complexidade. Daí a razão da Fortify se disponibilizar a customizá-las, tão logo a necessidade seja indentificada pelos seus clientes, e devolver no rulepack.

Pela consistência dos resultados apresentados pelas análises (falso positivo/negativo) usando o SCA ao longo do curso, pela forma didática como ela os apresenta, bem como as facilidades proporcionadas para o auditor, percebo que essa ferramenta tem espaço garantido quando se tratar de ciclo de desenvolvimento seguro. Infelizmente, não conheço os detalhes do principal concorrente Ounce 5, para poder compará-las e desconheço também qualquer detalhe sobre os custos associados à sua arquisição/manuteção (pergunte à LeadComm), mas tenho a impressão que seu mercado é bem restrito.