Rafael Soares Ferreira Sócio Diretor Técnico rafael@clavis.com.br

Principais Vulnerabilidades em Aplicações Web

Apresentação

•  Grupo Clavis

•  Sócio Diretor Técnico

•  Testes de invasão em redes, sistemas e aplicações

Contatos

rafaelsoaresferreira@gmail.com rafaelsoaresferreira @rafaelsferreira www.facebook.com/rafaelsoaresferreira

•  Compras

•  Redes Sociais

•  Internet Banking

•  Webmail

•  Outras...

Utilização

•  Protocolo leve e simples

•  E “stateless”!

•  Anytime, Anywhere

•  Independe de plataforma

•  Atualizações centralizadas

Benefícios

•  O protocolo HTTP HTTP 1.0 - RFC-1945 HTTP 1.1 – RFC-2616 RFC 1945: ...is an application-level protocol with the lightness and speed

necessary for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods (commands)...

Protocolos e Tecnologias

•  “Lightness” •  Protocolo em texto puro •  Simples de implementar um cliente

•  “Stateless” •  Servidor responde a requisição e •  Encerra a conexão

Protocolos e Tecnologias

•  Não confiar em dados externos •  Tudo pode ser forjado/modificado

•  Validar todos os dados

•  Prever e Tratar erros

•  Testar segurança, revisar

Segurança Básica

Mudança de Paradigma •  What is a secure site?

“a site that uses the HTTPS protocol...”

•  Segurança da comunicação é apenas 1 dos problemas

Segurança Básica

Erros Comuns •  Falta de Canonicalização

•  Verificações Client-Side

•  Segurança por Obscuridade

Segurança Básica

Canonicalização •  Decisões baseadas em nomes

•  Representação de forma única

•  Muitas representações para caracteres

•  ASCII, hexadecimal, UTF-8, unicode ...

Segurança Básica

Canonicalização – Exemplo •  SecureIIS do eEye http://www.exemplo.com/ver.asp?arquivo=../../../winnt/repair/sam

•  Evasão http://www.exemplo.com/ver.asp?arquivo=%2e%2e/%2e%2e/%2e

%2e/winnt/repair/sam

Segurança Básica

Verificações Client-Side •  Facilmente contornadas

•  Desabilitar javascript

•  Usar um proxy

•  Plugins de browser

Segurança Básica

Verificações Client-Side •  Tamper data

Segurança Básica

Segurança por Obscuridade •  Esconder o problema não resolve

•  Pode ser usada como camada adicional

•  Nunca como SOLUÇÃO de segurança

Segurança Básica

Segurança por Obscuridade •  Trocando a string do Apache

ServerSignature Off

SecServerSignature “Meu Servidor“

Segurança Básica

Principais Ameaças

Injeções

Descrição

•  Envio de dados não tratados para algum serviço interno.

•  Pode ser feita via SQL, LDAP, Xpath, comandos de sistema operacional, argumentos de programas, etc.

•  Descoberta por varreduras e/ou fuzzers

SQL Injection

Exemplo

SQLi:

•  Aplicação: OcoMon

•  Versão: 2.0-RC6

•  Bypass de autenticação via SQLi

•  Validação de entradas feita client-side

Exemplo

•  Página inicial filtrando caracteres especiais através de javascript.

Exemplo

•  É possível editar a função de validação, ou impedi-la de ser executada no navegador.

Exemplo

•  Sem a função de validação é possível submeter a string admin ‘ or ‘ -- que possibilita acesso ao sistema.

Impactos

•  Dependendo do tipo de injeção os danos causados podem ser:

ü  Perda ou corrupção de dados

ü  Negação de Serviço

ü  Falhas de autenticação

ü  Execução arbitrária de código e até comprometimento total do sistema.

Como se Prevenir

•  Não utilizar dados não confiáveis em comandos e/ou queries.

•  Rotinas de validação ou “escape” de caracteres.

•  É aconselhável o uso de validação positiva nas entradas.

•  Utilizar canonicalização de dados.

Quebra de Autenticação / Sessão

Principais Ameaças

•  Restrição de conteúdos / recursos

•  Autenticação HTTP: Basic -> credenciais concatenadas separadas por “:” e codificadas em base64 Digest -> hash MD5

Definição

•  Identificadores de Sessão (“SESSION ID") expostos

•  Lembretes de Senha ou “logout” vulneráveis

Definição

Exemplo

Cookie: [...] Authorization: Basic dGVzdGU6ZHVtbXlwYXNzd29yZA== [...] Decodificando: $ echo "dGVzdGU6ZHVtbXlwYXNzd29yZA==" | base64 –d teste:dummypassword

Exemplo

•  Tunelamento por SSL

•  Políticas de segurança

•  CAPTCHA

•  Proteger Cookie

Como se Prevenir

Principais Ameaças

XSS – Cross Site Scripting

Descrição

•  Ocorre quando uma aplicação inclui dados não tratados em um objeto enviado ao navegador.

•  Existem 3 principais tipos: ü  Stored ü  Reflected ü  DOM based XSS

Impactos

•  Roubo de informações de sessão •  Pichação de Sites •  Redirecionamento de usuários e etc. •  Exposição de informações dos usuários

Descrição

Stored:

•  Código injetado é armazenado permanentemente na aplicação vulnerável (comentários, posts, logs, etc)

•  A vítima recebe o código malicioso junto com alguma requisição feita.

Stored XSS

Exemplo

Stored: •  Aplicação: dotProject

•  Versão: 2.1.5

•  Múltiplas Vulnerabilidades de XSS e SQLi

Exemplo

•  Na submissão de arquivos é possível inserir um código malicioso no campo descrição.

Exemplo

<script>alert('xss')</script>

Exemplo

•  O código então será submetido a todos que visualizarem a descrição de tal arquivo.

Descrição

Reflected: •  O código é “refletido” para o usuário através de

respostas que contenham dados não tratados recebidos pela aplicação (resultado de buscas, mensagens de erro, etc).

•  Geralmente disseminado através de links maliciosos.

Reflected XSS

Exemplo

Reflected: •  Acunetix test site: http://testasp.vulnweb.com/search.asp

•  Aplicação com exemplos de vulnerabilidades

Exemplo

Reflected: •  O código submetido na busca é retornado ao

usuário na página de resultado sem nenhum tratamento.

Exemplo

Reflected: •  No caso de submissão de um código html por

exemplo, o mesmo será exibido para o usuário como se pertencesse a página em questão.

Exemplo

Reflected: •  A submissão pode ser feita pels busca: <br><br>Entre aqui com suas credenciais:<form action="destination.asp"><table><tr><td>Nome:</td><td><input type=text length=20 name=nome></td></tr><tr><td>Senha:</td><td><input type=text length=20 name=senha></td></tr></table><input type=submit value=Acessar></form>!

•  Ou pela URL: http://testasp.vulnweb.com/search.asp?tfSearch=%3Cbr%3E%3Cbr%3EEntre+aqui+com+suas+credenciais%3A%3Cform+action%3D%22destination.asp%22%3E%3Ctable%3E%3Ctr%3E%3Ctd%3ENome%3A%3C%2Ftd%3E%3Ctd%3E%3Cinput+type%3Dtext+length%3D20+name%3Dnome%3E%3C%2Ftd%3E%3C%2Ftr%3E%3Ctr%3E%3Ctd%3ESenha%3A%3C%2Ftd%3E%3Ctd%3E%3Cinput+type%3Dtext+length%3D20+name%3Dsenha%3E%3C%2Ftd%3E%3C%2Ftr%3E%3C%2Ftable%3E%3Cinput+type%3Dsubmit+value%3DAcessar%3E%3C%2Fform%3E+!

Descrição

DOM based XSS: •  Ocasionado por uma modificação no ambiente

DOM do navegador da vítima.

•  O código executado é legítimo, porém devido a essa alteração no ambiente sua execução é feita de maneira anômala.

Exemplo

DOM based XSS: •  O seguinte código é executado no navegador

(client-side)

Exemplo

DOM based XSS: •  A variável “name” pode ser manipulada

conforme o exemplo a seguir:

Como se Prevenir

•  “Escapar” caracteres vindo de fontes não confiáveis e que serão utilizados no contexto do navegador (body, atributos, JavaScript, CSS, URL).

•  A validação positiva é sempre interessante mas

é preciso atentar para peculiaridades da aplicação em questão pois caracteres especiais e codificações diversas podem fazer parte da rotina da aplicação.

Referência Direta a Objetos

Principais Ameaças

•  Apenas proteção na camada de apresentação não funciona

•  Atacante simplesmente altera parâmetros e consegue acessar o conteúdo

Definição

Exemplo

Como prevenir

•  Trocar referências diretas por um valor de mapeamento aleatório temporário

•  Verificar se o parâmetro está dentro do padrão

•  Verificar se o usuário tem permissão de acesso

•  Verificar se o usuário pode executar a ação que deseja em um determinado objeto

Falhas de Configuração

Principais Ameaças

•  Aplicações rodam em cima de serviços que rodam em cima de SOs

•  Todos podem ser vetores de ataque

•  Exploits (e patchs!) se aplicam à qualquer tipo de software

Definição

•  “Hardening” de servidores

•  Patchs e atualizações

•  Homologação de mudanças

•  Vulnerability Management

Como se Prevenir

Exposição de dados sensíveis

Principais Ameaças

Descrição

•  Falha mais comum e grave: simplesmente não criptografar dados sensíveis

•  Falhas quando a criptografia é empregada: -  Geração e armazenamento inseguros de chaves -  Não implantar políticas de rotação de chaves -  Utilizar algoritmos de criptografia fracos -  Utilizar métodos de criptografia em uma só via (hash)

fracos ou sem salto para proteger senhas.

Descrição

•  Falha em proteger o tráfego de rede onde passam os dados da aplicação

•  Utilização de criptografia somente na autenticação (expondo dados e IDs de seção)

•  Utilização de certificados expirados ou mal configurados

•  Falhas básicas de fácil detecção, bastando observar o tráfego de rede do site.

•  Frequentemente comprometem todos os dados protegidos por criptografia

•  Tipicamente, estes dados incluem, mas não estão limitados à: -  Credenciais de acesso -  Dados pessoais -  Registros de saúde -  Cartões de crédito, etc.

Impacto

•  Algoritmos de criptografia e chaves utilizados devem ser apropriadamente fortes.

•  Senhas devem armazenadas em hash com um algoritmo de criptografia em uma só via, forte e com um salto apropriado.

•  Proteger o transporte de dados adequadamente pode afetar o projeto do site. Em geral, é mais simples forçar o uso de criptografia em todo o site.

Como se Prevenir

Falha no controle de acesso

Principais Ameaças

Falha no controle de acesso

•  Usuário autorizado modifica um parâmetro ou URL e acessa uma função privilegiada

•  Usuário anônimo acessa funções desprotegidas

•  Impacto •  Acesso a contas e dados de outros

usuários

•  Realizar ações de privilégio maior do que devido

Falha no controle de acesso a nível de função

Como prevenir

•  Restringir acesso a usuários autenticados

•  Mostrar somente o que for designado ao usuário ou ao grupo

•  Negar qualquer requisição a páginas não autorizadas

•  Não utilizar abordagens de análise automatizada

•  Deve-se negar todo o conteúdo (DENY ALL)

Cross Site Request Forgery

Principais Ameaças

•  Browsers enviam alguns tipos de credenciais automaticamente

-  Cookies -  Cabeçalhos -  Endereço IP -  Certificados SSL

Definição

•  A vítima acessa um site malicioso enquanto está logada no sistema vulnerável

•  O atacante força a vítima a fazer tal requisição

Impacto

Cross Site Request Forgery(CSRF)

•  Autenticações forçadas em requisições sensíveis

•  Controle exposição de dados utilizados como credenciais

•  Adicionar um token secreto, não automático, para todas requisições importantes

Como se Prevenir

Utilização de componentes vulneráveis

Principais Ameaças

Utilização de componentes vulneráveis

•  Componentes bibliotecas e frameworks

•  Demora na divulgação da vulnerabilidade

•  Muitos produtores não lançam uma correção (hot fix)

•  Monitorar versões de todos os componentes, incluindo todas dependências

•  Manter componentes sempre atualizados

•  Organizar uma política de segurança

•  Buscar uma alternativa enquanto uma correção não aparece

Como se Prevenir

Redirecionamentos e repasses não validados

Principais Ameaças

Descrição

•  Falha em validar o destino de redirecionamentos ou repasses utilizados

•  Problemas mais comuns: -  Ausência de validação do destino de um

redirecionamento ou repasse -  Similaridade entre redirecionamento para destinos

internos (da própria aplicação) e externos

l  Redirecionamentos podem induzir usuários a instalar malware ou revelar informações sensíveis.

l  Repasses inseguros podem permitir contornar controles de acesso.

Impacto

l  Evitar estas falhas é extremamente importante, pois elas são os alvos favoritos de phishers tentando ganhar a confiança de um usuário.

l  Recomendações básicas para utilizar redirecionamentos e repasses: -  Não envolver parâmetros de usuário para calcular o

destino -  Se não puder ser evitar, validar o parâmetro e verificar

autorização do usuário

Como se Prevenir

Dúvidas?

Perguntas? Críticas?

Sugestões?

Siga a Clavis

Rafael Soares Ferreira Sócio Diretor Técnico

Muito Obrigado!

rafael@clavis.com.br

@rafaelsferreira