Ameaas e Vulnerabilidades em Aplicaes para CGU 2012

Andr Molina http://timasters.ning.com/profile/AndreMolina

Quem sou eu?

Formao
Engenharia de Computao ITA Mestre em Telecomunicaes UnB Especialista em Criptografia UFF

Atuao profissional
Aeronutica 2000 a 2007 CGU 2007 a 2009 Senado Federal (PRODASEN)

Referncias
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project Vitali, Maycon Maia. Curso de Extenso Tecnolgica - Segurana em Web. Silva Junior, Armando Gonalves da. Cross-Site Scripting: Uma Anlise Prtica. Universidade Federal de Pernambuco. Alonso, Chema; Bordn, Rodolfo; Guzmn, Antonio; Beltrn, Marta. LDAP Injection & Blind LDAP Injection in Web Applications Amaral, Thiago Melo Stuckert do. Lio sobre injeo de SQL do projeto WebGoat. Universidade de Braslia. http://en.wikipedia.org/wiki/Session_fixation http://www.trtec.com.br/produtos/barracuda/waf_overview.php http://www.trtec.com.br/produtos/fortinet/fortiweb/ http://ha.ckers.org/xss.html http://www.webappsec.org/projects/articles/071105.shtml http://www.md5crack.com/
3

OWASP TOP 10 (2010)

A1 Injection A2 Cross-Site Scripting (XSS) A3 Broken Authentication and Session Management A4 Insecure Direct Object References A5 Cross-Site Request Forgery A6 Security Misconfiguration A7 Insecure Cryptographic Storage A8 Failure to Restrict URL Access A9 Insufficient Transport Layer Protection A10 Unvalidated Redrects and Forwards
Prof. Andr Molina

A1 Injection
Falhas de Injection (SQL, SO, LDAP) ocorrem quando dados no confiveis - que podem ser manipulados - so encaminhados diretamente ao interpretador como parte do comando ou query que ser executado. O propsito do ataque injetar e executar comandos especificados pelo atacante na aplicao vulnervel. A principal vulnerabilidade no tratar os dados antes de envi-los ao interpretador.

Prof. Andr Molina

A1 Injection
Ex SQL: Formulrio de Login em sistema

A busca na base ser feita com os valores colocados nos campos, sem qualquer tratamento

Prof. Andr Molina

A1 Injection
Ex SQL: Formulrio de Login em sistema

' or '1'='1 ' or '1'='1

Prof. Andr Molina

A1 Injection
Ex SQL: Formulrio de Login em sistema

A consulta vlida para todos os registros do banco de dados. Assim, o primeiro registro encontrado (geralmente o Administrador) retornado.

Prof. Andr Molina

A1 Injection
Ex LDAP: Formulrio de Autenticao

A busca na base ser feita com os valores colocados nos campos, sem qualquer tratamento

Prof. Andr Molina

A1 Injection
Ex LDAP: Formulrio de Autenticao

Somente o primeiro filtro (USER) avaliado pelo servidor LDAP. Assim, a consulta (&(USER=slisberger)(&)) retorna sempre verdadeiro.

10

Prof. Andr Molina

A1 Injection
Ex LDAP: Formulrio de Autenticao

Como somente o primeiro filtro foi verificado, e o usurio slisberger existe na base, a autenticao foi vlida.

11

Prof. Andr Molina

A1 Injection
Como verificar: Os interpretadores separam os dados no confiveis na execuo dos comandos e queries?
SQL: Bind variables e stored procedures

Verificar o cdigo em busca da comandos e queries que utilizam dados no confiveis, a fim de garantir que esses dados no podem modificar o significado dos comandos e queries Busca automatizada por meio de ferramentas especializadas
Ex: Backtrack, Nessus, OpenVAS, Acunetix

12

Prof. Andr Molina

A1 Injection
Preveno: Utilizar uma API segura que evite o uso de interpretadores ou que fornea uma interface parametrizada Usar escape syntax para o interpretador na presena de carateres especiais Validao de entrada de dados por whitelist com canonizao (no uma defesa completa j que muitas aplicaes necessitam de carateres especiais quando da entrada de dados) Garantir o menor privilgio possvel quando da execuo Ocultar mensagens de erro Firewalls de aplicao (WAF), IDS e IPS
Prof. Andr Molina

13

A2 Cross-Site Scripting (XSS)

Ataques de XSS so uma espcie de problema de injection, na qual scripts maliciosos so inseridos na requisio feita a um site confivel mas vulnervel. Ocorrem quando um atacante usa uma aplicao web para enviar um cdigo malicioso para um usurio final diferente, geralmente na forma de um script, que ser executado no browser da vtima. O usurio final geralmente no tem como saber que o script no deveria ser confivel, pois est inserido no contexto da aplicao web que ele confia. Como executado no contexto dessa aplicao confivel, o script pode acessar qualquer cookie, token de sesso, ou outras informaes restritas retidas no browser e utilizadas pelo site da aplicao. Os scripts podem, inclusive, rescrever o contedo HTML da pgina exibida.

14

Prof. Andr Molina

A2 Cross-Site Scripting (XSS)

Essa falha ocorre sempre que uma aplicao web utiliza uma entrada de um usurio na sada gerada sem que seja feita a validao ou codificao. H 3 tipos bsicos de ataques de XSS Persistente (Stored) No persistente (Reflected) Document Object Model (DOM) based

15

Prof. Andr Molina

A2 Cross-Site Scripting (XSS)

Persistente
Caracateriza-se quando o cdigo fornecido pelo atacante fica armazenado permanentemente no servidor (banco de dados, frum de mensagens, comentrios) e exibido permanentemente nas pginas retornadas para os usurios durante a navegao, sem que haja escape syntax adequada do HTML. o tipo mais perigoso, pois no depende da ao do usurio e frequentemente acontece em sites no qual o atacante pode postar texto, como, por exemplo, fruns, Orkut, Twitter, Facebook, etc. Em meados de 2007, o Vrus do Orkut, por meio da uma falha de XSS do Orkut, fez com que os usurios atacados ingressassem na comunidade Infectados pelo Virus do Orkut e enviassem o cdigo para todos os amigos.
16 Prof. Andr Molina

A2 Cross-Site Scripting (XSS)

Persistente
Ex: Formulrio de contatos

17

Prof. Andr Molina

A2 Cross-Site Scripting (XSS)

Persistente
Ex: Formulrio de contatos

18

Prof. Andr Molina

A2 Cross-Site Scripting (XSS)

Persistente
Ex: Formulrio de contatos

Dinmica do ataque.

19

Prof. Andr Molina

A2 Cross-Site Scripting (XSS)

No Persistente
Ocorre quando o cdigo injetado refletido no servidor web, tal como numa mensagem de erro, numa busca, ou qualquer outra resposta que inclua parte ou toda entrada enviada para o servidor como parte da requisio feita. necessrio que a vtima receba o ataque por algum meio distinto, como email ou um outro servidor web que contenha a requisio. A vtima, quando por exemplo clica no link, encaminha uma requisio especialmente formulada contendo o cdigo malicioso. Ento o servidor vulnervel reflete o ataque de volta para o browser da vtima, que ento executa o cdigo, visto que ele provm de um servidor confivel. Os no persistentes so os mais comuns, e esto muito ligados a phishings.
Prof. Andr Molina

20

A2 Cross-Site Scripting (XSS)

No Persistente
Ex: Busca em Site de Banco
Link malicioso enviado vtima
http://busca.bb.com.br/buscabb/busca/busca?q=%22%3E%3Cscript%3ECODIGOMALICIOSO%3C%2Fscript%3E&x=12&y=9

O que o site recebe e entende.

21 Prof. Andr Molina

A2 Cross-Site Scripting (XSS)

No Persistente
Ex: Busca em Site de Banco

O que o servidor retorna (reflete) para a vtima.

22

Prof. Andr Molina

A2 Cross-Site Scripting (XSS)

No Persistente
Ex: Busca em Site de Banco

Dinmica do Ataque

23

Prof. Andr Molina

A2 Cross-Site Scripting (XSS)

DOM Based
Diferentemente dos outros dois tipos, que ficam embutidos no contexto da resposta HTML, neste tipo a carga maliciosa executada por meio da modificao do ambiente DOM (Document Object Model) no browser da vtima no script original, de forma que o cdigo executado no cliente se comporta de uma forma inexperada. A pgina em si (resposta HTTP) no se modifica, mas o cdigo para o cliente contido na pgina executado de forma diferente, devido s modificaes que ocorreram no ambiente DOM. O ataque se baseia na explorao da gerao de cdigo dinmico atravs de parmetros passados pelo usurio. Desse modo, tanto pode existir o XSS Persistente DOM Based, como o No persistente DOM Based. Para estar vulnervel, o site deve ter uma pgina HTML que utiliza dados de document.location, document.URL, document.referrerm, etc. de forma insegura.
24 Prof. Andr Molina

A2 Cross-Site Scripting (XSS)

DOM Based
Ex: Site com escolha de lngua, e opo default na URL
Select your language: <select><script> document.write("<OPTION value=1>"+document.location.href.substring(document.location.href.indexOf("default=")+8)+"</ OPTION>"); document.write("<OPTION value=2>English</OPTION>"); </script></select>

http://www.some.site/page.html?default=French

Forma normal de invocar a pgina

25 Prof. Andr Molina

A2 Cross-Site Scripting (XSS)

DOM Based
Ex: Site com escolha de lngua, e opo default na URL
Select your language: <select><script> document.write("<OPTION value=1>"+document.location.href.substring(document.location.href.indexOf("default=")+8)+"</ OPTION>"); document.write("<OPTION value=2>English</OPTION>"); </script></select>

Cdigo destinado ao lado cliente

Forma normal de invocar a pgina

Forma maliciosa

http://www.some.site/page.html?default=French

http://www.some.site/page.html?default=<script>alert(document.cookie)</script>
26 Prof. Andr Molina

A2 Cross-Site Scripting (XSS)

DOM Based
Ex: Site com escolha de lngua, e opo default na URL

Dinmica do Ataque

27

Prof. Andr Molina

A2 Cross-Site Scripting (XSS)

Como verificar: Testar entradas para checar se existe validao de entrada, e que toda entrada adequadamente submetida escape syntax antes de ser includa na pgina retornada
Persistente
https://www.owasp.org/index.php/Testing_for_Stored_Cross_site_scripting_%28OWASP-DV-002%29

No persistente
https://www.owasp.org/index.php/Testing_for_Reflected_Cross_site_scripting_%28OWASP-DV001%29

DOM Based
https://www.owasp.org/index.php/Testing_for_DOM-based_Cross_site_scripting_%28OWASP-DV003%29

http://ha.ckers.org/xss.html The DOMinator Tool plugin do Firefox

Busca manual/automatizada por meio de ferramentas especializadas, pentest

Ex: Backtrack, Nessus, Acunetix
28 Prof. Andr Molina

A2 Cross-Site Scripting (XSS)

Preveno: Manter dados no confiveis separados do contedo ativo enviado ao browser: Uso adequado de escape syntax de todo dado no confivel do contexto HTML (body, attribute, JavaScript, CSS, ou URL) no qual esse dado ser inserido Validao de entrada por meio de whitelist, embora no seja uma defesa infalvel, visto que muitas aplicaes utilizam caracteres especiais. A validao deve decodificar todo caractere codificado e ento validar o comprimento, os caracteres e o formato antes de aceit-lo como entrada.
Ex: UTF-8 Unicode Encoding: <IMG_SRC=&#106;&#97;&#118;&#97;&#115;&#99;&#114;&#105;&#112;&#116;&# 58;&#97;&#108;&#101;&#114;&#116;&#40;&#39;&#88;&#83;&#83;&#39;&#41;>

29

Prof. Andr Molina

A3 Broken Authentication and Session Management

So vulnerabilidades associadas a falhas nas funes de autenticao ou de gerenciamento de sesso, que possibilitam sequestro de sesso, exposio de contas e senhas, IDs de sesso, etc. Geralmente, essas falhas esto relacionadas ao processo de logout, gerenciamento de senha, timeout, remember me, questo secreta, atualizao de conta, tokens de sesso, etc.

30

Prof. Andr Molina

A3 Broken Authentication and Session Management

Ex. 1: Site de compra de passagens areas, que registra a ID da sesso na prpria URL. http://example.com/sale/saleitems;jsessionid=2P0OC2JDPXM0OQSNDLPSKH CJUN2JV?dest=Hawaii

O controle da sesso est exposto na URL

31

Prof. Andr Molina

A3 Broken Authentication and Session Management

Ex. 2: Site suscetvel a XSS que mantm o controle da sesso unicamente por meio de cookie registrando a ID da sesso.

32

Prof. Andr Molina

O atacante aplica um XSS e consegue obter o cookie que contm o controle da sesso.

A3 Broken Authentication and Session Management

Ex. 3: Site suscetvel a Fixao de Sesso (Session Fixatation).

O atacante inicia a sesso e repassa para a vtima autenticar, quando ento toma controle novamente da sesso.

33

Prof. Andr Molina

A3 Broken Authentication and Session Management

Como verificar: As credenciais sempre so protegidas quando armazenadas utilizando hashing ou criptografia? Veja A7 As credenciais podem ser adivinhadas ou sobrepostas atravs de funes inadequadas no gerenciamento da conta (ex.: criao da conta, mudana de senha, recuperao de senha, identificadores de sesso de sesso fracos)? Os IDs de sesso so expostos na URL? (ex.: reescrita de URL) Os IDs de sesso so vulnerveis ataques de fixao de sesso? Os IDs de sesso expiram aps um determinado perodo de inatividade e os usurios tem uma opo para efetuar o logout? Os IDs de sesso so rotacionados aps a autenticao bem sucedida? Senhas, IDs de sesso, e outras credenciais so enviadas em conexes TLS (A9)?
34 Prof. Andr Molina

A3 Broken Authentication and Session Management

Preveno: Disponibilizar aos desenvolvedores um conjunto forte de controles de autenticao e gerenciamento de sesso
Implementaes seguras de timeouts, IDs de sesso seguros e modificveis a cada requisio, etc.

Evitar falhas de XSS, as quais podem ser utilizadas para obter IDs de sesso. Utilizar identificadores de sesso provenientes do SSL/TLS

35

Prof. Andr Molina

A4 Insecure Direct Object References

Uma referncia direta a um objeto ocorre quando um programador expe uma referncia implementao direta de um objeto, como um arquivo, diretrio ou chave de base de dados. Se no houver uma verificao de controles de acessos ou outra proteo, os atacantes podem manipular estas referncias para acessar e comprometer dados sensveis e protegidos.

36

Prof. Andr Molina

A4 Insecure Direct Object References

Ex 1: Acesso a arquivos do sistema operacional.

37

Prof. Andr Molina

A4 Insecure Direct Object References

Ex 2: O site do banco utiliza o nmero da conta como chave primria, e faz uso desse valor na interface web, sem qualquer verificao se o usurio autenticado o proprietrio da conta.

A varivel acct chave primria no banco.

38

Prof. Andr Molina

Uma referncia direta na URL permite que sejam utilizadas outras contas.

A4 Insecure Direct Object References

Como verificar: Observar se todas as referncias a objetos tem protees adequadas, considerando:
Para referncias diretas a recursos restritos, a aplicao deve verificar se o usurio est autorizado para acessar o recurso requisitado; Se a referncia indireta, o mapeamento deve ser limitado a valores autorizados para o usurio em questo.

A anlise de cdigo da aplicao permite uma verificao rpida Testes manuais tambm auxiliam a identificar referncias diretas a objetos e se as mesmas so seguras. Obs: Ferramentas automatizadas geralmente no procuram essas falhas, pois no diferenciam o que precisa ser protegido do que no precisa.
Prof. Andr Molina

39

A4 Insecure Direct Object References

Preveno: Prevenir referncias diretas inseguras a objetos requer selecionar uma abordagem para proteger cada objeto acessvel pelo usurio: Utilizar referncia indireta por usurio ou por sesso Verificar o acesso. Cada uso de referncia direta a objeto proveniente de uma fonte no confivel deve incluir uma verificao de controle de acesso para assegurar que o usurio autorizado para o objeto requisitado.

40

Prof. Andr Molina

A5 Cross-Site Request Forgery

Um ataque CSRF fora a vtima que tenha uma sesso ativa em um navegador a enviar um pedido (request) HTTP forjado, incluindo o cookie da sesso bem como outras informaes da sesso, a uma aplicao WEB vulnervel. Esta falha permite ao atacante forar o navegador da vtima a criar pedidos que a aplicao vulnervel aceite como pedidos legtimos oriundos da vtima. O cdigo malicioso geralmente no est no site vulnervel, por essa razo recebendo o nome Cross Site. O CSRF faz proveito de aplicaes WEB que permitem prever todos os detalhes de uma transao. Uma vez que os navegadores enviam credenciais como cookies de sesso automaticamente, atacantes podem gerar pginas contendo requisies maliciosas que so indistinguveis das legtimas.
41 Prof. Andr Molina

A5 Cross-Site Request Forgery

Toda aplicao vulnervel a XSS est vulnervel a CSRF, mas nem toda aplicao vulnervel a CSRF est vulnervel a XSS. Ex 1: Banco cujas transferncias so realizadas somente com base na requisio, sem que nada seja secreto.

O atacante constri essa requisio e a insere em requisies de imagens em sites sob seu controle, aguardado a visita de alguma vtima autenticada no banco.
42 Prof. Andr Molina

A5 Cross-Site Request Forgery

Ex 2: Site de troca de carros.

Requisio feita para troca de proprietrio.

acao.php?op=troca_dono&carro=[id do carro]&novo_dono=[id do novo dono] 43 Prof. Andr Molina

A5 Cross-Site Request Forgery

Ex 2: Site de troca de carros.

Valor colocado no campo da imagem.

http://localhost/AtaquesWeb/owasp4/acao.php?op=troca_dono&carro=4&novo_dono=2] 44 Prof. Andr Molina

A5 Cross-Site Request Forgery

Ex 2: Site de troca de carros.

45

Prof. Andr Molina

A5 Cross-Site Request Forgery

Ex 2: Site de troca de carros.

Quando o proprietrio do carro visualiza a imagem, automaticamente feita a troca do carro.

46

Prof. Andr Molina

A5 Cross-Site Request Forgery

Como verificar: Verificar se cada link contm tokens imprevisveis para cada usurio, focando nos links que invocam funes de modificao de estado (tais como transferncias, compras, etc). Sem esses tokens os atacantes podem forjar requisies maliciosas. Verificar o cabealho HTTP Referer e/ou ocabealho HTTP Origin Verificar transaes de vrios etapas, pois possvel forjar sries de requisies usando vrias tags ou com javascript (introduzindo delay entre os cliques). Utilizar a ferramenta para desenvolvedores CSRF Tester (OWASP).

47

Prof. Andr Molina

A5 Cross-Site Request Forgery

Preveno:

A preveno requer a incluso de tokens imprevisveis no corpo ou URL de cada requisio HTTP. Tais tokens devem ser no mnimo nicos por sesso do usurio, mas tambm podem ser nicos por requisio.
prefervel incluir o token em um campo oculto, sendo enviado no corpo da requisio HTTP, evitando a incluso na URL, o que pode expor o valor

48

Prof. Andr Molina

A7 Insecure Cryptographic Storage

Geralmente a falha mais comum no implementar controles criptogrficos adequados nos dados sensveis, tais como nmeros de cartes de crdito, credenciais de autenticao, as prprias chaves de criptografia, etc. Outro problema tambm o uso incorreto dos controles criptogrficos disponveis, seja utilizando cifras inapropriadas ou fazendo uso de cifras fortes de forma errada. H ainda casos de utilizao de algoritmos criptogrficos desenvolvidos internamente que podem conter vulnerabilidades simples de serem exploradas.

49

Prof. Andr Molina

A7 Insecure Cryptographic Storage

Ex: Uma base de dados contendo senhas armazenadas na forma de hashes MD5, sem salt. A aplicao suscetvel a SQL Injection, permitindo ao atacando obter os hashes. Em algumas semanas o atacante pode obter a maior parte das senhas. Obs: Se fosse utilizado salt nos hashes, seriam necessrios milnios.

50

Prof. Andr Molina

A7 Insecure Cryptographic Storage

Como verificar: Verificar se para os dados sensveis existem controles criptogrficos adequados, em todo o fluxo desses dados (banco de dados, requisies, backup, etc.) S os usurios autorizados podem acessar os dados em claro? utilizado um algoritmo forte padronizado? Uma chave forte gerada, protegida de acesso no autorizado, e h previso de troca dessa chave?

51

Prof. Andr Molina

A7 Insecure Cryptographic Storage

Preveno: De acordo com as ameaas, certificar que os dados sensveis esto protegidos por controles criptogrficos adequados Certificar que os backups offsite so cifrados, e que as chaves utilizadas so guardadas em separado Utilizar algoritmos fortes e padronizado, e fazer gerenciamento de chave Assegurar que senhas armazenadas com algoritmos de hash adequados com uso de salt Certificar que todas as senhas e chaves so protegidas de acessos no autorizados

52

Prof. Andr Molina

FIM

53