1) O documento discute testes de segurança de software, abordagens como white-box e black-box, e a importância da modelagem de ameaças para planejar testes. 2) É explicado que testes de segurança buscam garantir não repúdio, controle de acesso e privacidade de dados. 3) A modelagem de ameaças mapeia riscos e ajuda a definir requisitos de segurança.

2. Como fazer revisão e testes de código para identificar problemas (bugs) de segurança. Wagner Elias Research & Development Manager Conviso IT Security http://wagnerelias.com SEG303:

3. Agenda Introdução Os principais problemas de segurança de software Por que testes de segurança de software? O papel do testador de segurança de software Abordagens de testes de segurança de software Criando planos de testes com base na Modelagem de Ameaças Padrões de Ataques

4. Introdução Os testes de segurança de software são essenciais para garantir a Confidencialidade, integridade e disponibilidade das informações que serão tratadas pelo software Testes de segurança de software garantem que requisitos de segurança de software foram garantidos mesmo quando estes requisitos não fazem parte das especificações funcionais

5. Os principais problemas de segurança de Software Buffer Overflow SQL Injection XSS (Cross Site Scripting)

6. Buffer Overflow buffer overflow ou buffer overrun acontece quando o tamanho de um buffer ultrapassa sua capacidade máxima de armazenamento

7. Exemplo de Buffer Overflow void CopyStuff(string data) { char buffer[128]; strcpy(buffer,data); // do other stuff } Se este dado é maior do que o buffer Então esta função irá estourar o buffer

8. SQL Injection SQL injection é um tipo de ataque muito simples, baseia-se na execução de comandos SQL. Comandos de manipulação de dados - DML (select, insert, update, delete) ou comandos de definição de dados - DDL (create, drop, alter). Os comandos são injetados em campos de formulários que são disponibilizados para o usuário inserir/tratar informações

9. Exemplo de SQL Injection string Status = "No"; string sqlstring =""; try { SqlConnection sql= new SqlConnection( @"data source=localhost;" + "user id=sa;password=password;"); sql.Open(); sqlstring="SELECT HasShipped" + " FROM detail WHERE ID='" + Id + "'"; SqlCommand cmd = new SqlCommand(sqlstring,sql); if ((int)cmd.ExecuteScalar() != 0) Status = "Yes"; } catch (SqlException se) { Status = sqlstring + " failed\n\r"; foreach (SqlError e in se.Errors) { Status += e.Message + "\n\r"; } } catch (Exception e) { Status = e.ToString(); }

10. XSS (Cross Site Scripting) Uma falha no servidor que leva a um comprometimento do cliente. A falha é simplesmente ecoar input do usuário sem uma validação adequada.

11. Exemplo de XSS (Cross Site Scripting) Welcome.asp Hello, <%= request.querystring(‘name’)%> Mantém o badsite.com

12. Por que testes de segurança? Os testes “tradicionais” buscam avaliar as funcionalidades do software. Testes de segurança buscam garantir: Não repudio Controle de acesso adequado Que informações não sejam “vazadas”

13. O papel do testador de segurança? Participar de todo o processo de desenvolvimento de software Ter capacidade técnica e conhecimento de segurança para testar software Acompanhar o desenho e implementação dos controles para garantir a segurança do software Atestar que o software está pronto para ser distribuído

14. Abordagens para teste de segurança? White-Box Black Box Fuzzing

15. White-Box Teste onde o testador tem amplo conhecimento do software e acesso a código fonte Vantagens Permite um teste completo de todas as características do software Desvantagens O teste pode ficar inviável com um número grande de linhas de código

16. Black Box Teste onde o testador tem o mesmo conhecimento e privilégios de acesso de um usuário comum. Vantagens Pode ser executado sem acesso a “solution” (código fonte compilavel) É possível testar controles em “run-tyme” Desvantagens O testador necessita de conhecimentos avançados em segurança de software Pode ser necessário realiazar um engenharia reversa do software

17. Fuzzing Técnica para injeção de falhas Escalável – funciona com qualquer linguagem Versátil – Host ou Rede

18. Verbo == 4 (valid) && Conteúdo > 110 bytes (Cl:Ll) Verbo Conteúdo Exemplo de Teste Fuzzing Testando a interface da porta 1433 do SQL Server Valores Válidos: 1-9 Valores Válidos: Nome da Instância (string) Tamanho (Cl) Longo (Ll) Curto (Ls) Zero (Lz) Randômico (Cr) NULL (Cn) Zero (Cz) Tipo Errado (Cw) Sinal Errado (Cs) Fora dos Limites (Co) Estouro de Buffer

19. Criando planos de testes com base na Modelagem de Ameaças Para um teste eficaz é necessário utilizar as características que foram identificadas e documentadas na modelagem de ameaças que é realizada na fase de design do desenvolvimento de software

20. Modelagem de Ameaças Abordagem estruturada usada para identificar e mensurar riscos aos recursos gerenciados pelo software Permite que o design enderece os riscos de segurança Define os requisitos e recursos de segurança Ajuda a revisar os testes e revisões de código

21. Processo de Modelagem de Ameaças (1 de 3)

22. Processo de Modelagem de Ameaças (2 de 3) 1.Identificar os bens . Identifique os bens valiosos que seus sistemas devem proteger. 2.Criar uma visão geral da arquitetura . Utilize diagramas e tabelas simples para documentar a arquitetura de seu aplicativo, inclusive subsistemas, limites de confiança e fluxo de dados. 3.Decompor o aplicativo . Decomponha a arquitetura do aplicativo, inclusive a rede subjacente e o projeto de infra–estrutura do host para criar um perfil de segurança para o aplicativo. O objetivo do perfil de segurança é revelar vulnerabilidades do projeto, implementação ou configuração de implantação do aplicativo.

23. Processo de Modelagem de Ameaças (3 de 3) 4.Identificar as ameaças . Conhecendo os objetivos de um invasor, a arquitetura e as possíveis vulnerabilidades de seu aplicativo, identifique as ameaças que poderiam afetar o aplicativo. 5.Documentar as ameaças . Documente cada ameaça utilizando um modelo comum de ameaça que defina um conjunto central de atributos a capturar para cada ameaça. 6.Classificar as ameaças . Classifique as ameaças de modo a priorizar e tratar as ameaças mais significativas primeiro. Essas ameaças apresentam riscos maiores. O processo de classificação considera a probabilidade dos danos que ela poderia causar no caso de um ataque. Pode acontecer de determinadas ameaças não justificarem nenhuma ação quando você compara o risco causado pela ameaça com os custos resultantes da atenuação.

24. Modelagem de Ameaças Wagner Elias Research & Development Manager Conviso IT Security http://wagnerelias.com demo

25. Padrões de Ataques Uma série de passos repetitivos que podem ser aplicados de uma forma consistente e confiável para simular um ataque contra um sistema de software. “ Attack Patterns – http://www.attackpatterns.org ” Projeto que, tem como objetivo identificar e documentar padrões de ataques que possam ser utilizados para testes de segurança de software

26. Padrões de Ataques Comuns “ By-Pass” de client Modificação de arquivos de configuração Alterar caminhos de busca para acessar executáveis Manipular variáveis de ambiente para alterar execução de programas ou caminho de busca Embutir um script dentro de outro script Fuga de diretórios e pastas permitidas em site web SQL ou Script Injections Injetar código executável em conteúdo de banco de dados ou de arquivos Manipulação de HTTP Query Strings Buscar URL que aponta para arquivo local Utilizar codificação alternativa de caracteres Análise e envenenamento de Cookies HTTP Alteração de parâmetros

27. Testando SQL Injection com Scrawlr Wagner Elias Research & Development Manager Conviso IT Security http://wagnerelias.com demo

28. Testando XSS com XSSDetect Wagner Elias Research & Development Manager Conviso IT Security demo

29. Testando .net com Fxcop Wagner Elias Research & Development Manager Conviso IT Security demo

30. O que fazer com o resultado dos testes? Identifique suas deficiências e capacite os recursos envolvidos no desenvolvimento de software Identifique e desenvolva políticas com padrões que garantam o desenvolvimento de um software mais seguro Trabalhe e busque a viabilização da inclusão de requisitos de segurança no processo de desenvolvimento de software

31. Conclusões Testes de segurança irão garantir que o software desenvolvido terá sua garantia de funcionalidade e não trará riscos aos seus beneficiados Que o processo de resposta a incidentes após a entrega do software não será traumático devido a falhas que não foram identificadas durante o processo de desenvolvimento Que todas as informações e expectativas de seguranças do cliente serão garantidas

32. Wagner Elias Research & Development Manager Conviso IT Security http://wagnerelias.com

33. Recursos www.microsoft.com/teched Tech·Talks Tech·Ed Bloggers Live Simulcasts Virtual Labs http://www.microsoft.com/brasil/technet Avaliação de produtos finais e betas, conteúdo técnico em português e MUITO MAIS! http://www.microsoft.com/brasil/msdn Developer’s Kit, conteúdo técnico em português, e MUITO MAIS!

34. Sessões Relacionadas SEG201 - Windows Server 2008 - Por que é Realmente Seguro (Análise Técnica) SEG307 - Defesa em Profundidade ? O NAP (Network Access Protection) Pode Ajudar ! SVR307 - Virtualização e Segurança: Como Conciliar os dois Mundos ? SEG308 - Estamos no Século 21: É Hora de Jogar Fora seus Gateways Medievais !

35. Outros Recursos Relacionados Recurso 1 Recurso 2 Recurso 3 Livro: Modelagem de Ameaças (Frank Swiderski e Window Snyder) Livro: Escrevendo Código Seguro (Michael Howard e David LeBlanc) Livro: Como Quebrar Códigos (Greg Hoglund e Gary McGraw)

36. Por favor preencha a avaliação

37. © 2008 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.