Todos os posts tagados xss

HackersList.com com falha XSS

hackerslist_xss

Chama-se HackersList.com e nos últimos dias tem estado presente em imensos sites da comunicação social.
Basicamente é um serviço de aluguer de hackers profissionais para qualquer tipo de serviço.

Um utilizador intitulado de watt, encontrou e publicou uma falha XSS no site e divulgou-a no xssposed.org.
Uma falta de filtragem da variável de pesquisa, leva à possibilidade de injetar código no URL e executá-lo no browser da vítima.

Dado que à data do artigo, o site ainda estava vulnerável, enviei um email para a equipa do site.

Parece-me correto, escrever o famoso ditado popular – Casa de ferreiro, espeto de pau.

Dailymail vulnerável a ataques XSS

dailymail00

Um utilizador intitulado de SecBit publicou no arquivo de ataques XSSxssposed.org – 9 ataques XSS ao site dailymail.co.uk. A grande maioria ainda não está corrigida e poderá ser um risco de segurança para este jornal britânico.
Para quem não sabe o que é XSS [Cross-Site Scripting], consiste numa vulnerabilidade causada pela falta de validação em parâmetros de entrada do utilizador e a resposta do servidor numa aplicação web. Esta tipo de vulnerabilidade permite que seja inserido duma forma arbitrária, código HTML no browser de um utilizador.

As vulnerabilidades XSS estão localizadas alegadamente em duas aplicações web. O NewsDebate e o Chat do DailyMail. Uma má filtragem em parâmetros destas aplicações tornam o site dailymail.co.uk um alvo para utilizadores maliciosos.

dailymail01

Estes ataques XSS no Dailymail podem conduzir a ataques phishing, propagação de malware, ataques DoS, entre outros.
Relembro que ataques XSS, principalmente em sites populares, podem simplesmente serem conduzidos a ataques de negação de serviço utilizando a ferramenta disponibilizada por Robert ‘RSnake’ Hansen, FlashFlood.

É importante referir que as empresas e respetivas equipas de desenvolvimento devem preocupar-se com este tipo de falha.

Embora desconhecendo se o Dailymail foi contatado sobre estas falhas, e dado que ainda estão vulneráveis, tomei a liberdade de enviar uma notificação por email para resolução desta situação. Entretanto ainda não recebi resposta.

Referências:
https://www.xssposed.org/incidents/53092/
https://www.xssposed.org/incidents/53093/
https://www.xssposed.org/incidents/53094/
https://www.xssposed.org/incidents/53095/
https://www.xssposed.org/incidents/53096/
https://www.xssposed.org/incidents/53097/
https://www.xssposed.org/incidents/53098/
https://www.xssposed.org/incidents/53099/
https://www.xssposed.org/incidents/53100/

DOM XSS – Parte 1

dom_xss

Nesta primeira parte, num total de três, vou explicar o funcionamento do DOM XSS e demonstrar como encontrar falhas nesta variante do XSS – um tipo de ataque muito utilizado/comum hoje em dia para roubo de sessões, phishing e propagação de malware utilizando o XSS Persistente [mais perigoso que o XSS Refletido, pois o XSS Persistente fica armazenado na aplicação web].

Vou também fornecer referências e vídeos que ajudam a complementar este artigo.

Tive conhecimento do DOM XSS[1] há alguns anos, altura em que li o livro XSS Attacks: Cross Site Scripting Exploits and Defense de Seth Fogie[2], com a participação do Robert ‘RSnake’ Hansen[3]. Foi exatamente no site – ha.ckers.org – do RSnake que despertei o interesse pelo XSS.

O DOM XSS tem sido bastante popular na segurança informática, muito devido às recompensas nos programas de divulgação responsável de vulnerabilidades de diversas empresas [Google, Yahoo!, PayPal, etc]. Quem sabe se, com esta leitura, poderá ser uma oportunidade para o leitor ganhar uns trocados :-)
Essa popularidade também é originada pelo aumento da utilização de JavaScript [e por sua vez, AJAX] nas aplicações web [sites]. Ataques XSS baseados no DOM ainda são muito comuns encontrar nas aplicações web, muito por causa da complexidade de analisar códigos JavaScript [situação agravada quando o código está comprimido ou ofuscado].

Mas afinal o que é o DOM XSS?
DOM XSS é um ataque XSS[5] onde a ação nociva é executada como resultado de uma modificação no DOM [Document Object Model] do browser da vítima, presente num script do lado do cliente. Isto significa que, a resposta HTTP não é modificada mas o código do lado do cliente é executado de uma forma “diferente” [ou maliciosa] do habitual.
Ao contrário de outros ataques XSS, o DOM XSS opera do lado do cliente [client-side] e não no lado do servidor [server-side].
Por outras palavras, geralmente, uma aplicação web contém códigos em JavaScript que gerem o input do utilizador no HTML. Estes códigos controlam a aplicação web através do DOM. Uma injeção de código arbitrário no DOM é intitulado de DOM XSS.

Dependendo do tipo de vulnerabilidade, um utilizador malicioso pode utilizar ataques DOM XSS para roubo de dados de autenticação, phishing e até mesmo para propagar malware. Como os ataques DOM XSS são executados no browser da vítima, monitorizar este tipo de atividade pode ser uma tarefa difícil. Digo isto porque em determinados casos, o vector de ataque DOM XSS não passa sequer pelo servidor. Se a ação nociva estiver inserida num identificador hash (após o caracter #), os browsers não enviam essa parte do URL para os servidores.
Esta situação não ocorre apenas nos identificadores hash mas também em algumas novas funcionalidades HTML5, como o LocalStorage e o IndexedDB.
Tome como exemplo o seguinte código JavaScript numa página index.html:

var foobar = location.hash;
document.write(foobar);

domxss_1

Se aceder ao endereço com o browser Mozilla Firefox [Google Chrome bloqueia algumas tentativas de XSS – mas não todas :-)]:

http://site-que-nao-existe.pt/index.html

Não vai surgir nada no ecrã. No entanto se colocar:

http://site-que-nao-existe.pt/index.html#1234

Irá surgir no ecrã #1234 [valor da propriedade hash do objeto location].
Dado que não existe qualquer tipo de validação do input do utilizador, é possível injetar código HTML.
Testamos então injetar no location.hash o seguinte:

#1234<img src=x onerror=prompt(1);>

domxss_2

Acabou de explorar uma falha DOM XSS.
Convém referir que nem todas as falhas DOM XSS são fáceis de detetar. Na maioria dos casos, é necessário ter um conhecimento mais avançado da linguagem Javascript.

Mas existem formas mais automáticas para analisar este tipo de falha.
Poderá programar a sua própria ferramenta, utilizando as expressões regulares disponibilizadas pelo DOM XSS Wiki[4]:

Detetar fontes [é a origem do conteúdo, ou seja, donde vem a informação – por exemplo: document.URL]:

/(location\s*[\[.])|([.\[]\s*["']?\s*(arguments|dialogArguments|innerHTML|write(ln)?|open(Dialog)?|showModalDialog|cookie|URL|documentURI|baseURI|referrer|name|opener|parent|top|
content|self|frames)\W)|(localStorage|sessionStorage|Database)/

Detetar sinks [funções de JavaScript que poderão permitir executar strings como JavaScript]:

/((src|href|data|location|code|value|action)\s*["'\]]*\s*\+?\s*=)|((replace|assign|navigate|getResponseHeader|open(Dialog)?|showModalDialog|eval|evaluate|execCommand|execScript|setTimeout|setInterval)\s*["'\]]*\s*\()/

Caso contrário, já existem muitas ferramentas que auxiliam na pesquisa por DOM XSS:

No artigo DOM XSS – Parte 3 irei focar-me numa destas ferramentas, com exemplos práticos e dicas de utilização.

Como um vídeo vale mais do 1,8 milhões palavras, penso que é importante salientar estas duas apresentações em vídeo porque demonstram muito bem, pela voz de dois grandes especialistas, o que é o DOM XSS.

In the DOM – No one will hear you scream By Mario Heiderich

Sapo CodeBits V – Stefano di Paola

Como corrigir?
São imensos os casos que podem ocorrer para corrigir falhas DOM XSS. Passa sempre por filtrar [um bom lema para os programadores web – encode and sanitize] todos os parâmetros possíveis de modificação por parte de um utilizador.
A OWASP[6] tem uma página[7] dedicada exclusivamente à prevenção de falhas DOM XSS. Essa página explora vários tipos de cenários e contribui bastante para uma boa regra de etiqueta na programação de aplicações web.

Na segunda parte deste artigo, irei fornecer 3 exemplos de casos reais que irão ajudar o leitor a entender melhor esta matéria.

Até lá!

Referências:
[1] https://www.owasp.org/index.php/DOM_Based_XSS
[2] http://www.amazon.com/XSS-Attacks-Scripting-Exploits-Defense/dp/1597491543
[3] http://www.websegura.net/entrevista-com-robert-hansen/
[4] https://code.google.com/p/domxsswiki/
[5] https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29
[6] http://www.owasp.org
[7] https://www.owasp.org/index.php/DOM_based_XSS_Prevention_Cheat_Sheet

Hootsuite vulnerável a XSS

hootsuite_xss

Foi divulgado no site xssposed.org, que o Hootsuite está vulnerável a uma falha XSS. Este site é um arquivo de falhas XSS [apenas conhecia o xssed.com] que publica diariamente listas de sites vulneráveis a este tipo de vulnerabilidade.

Para quem não sabe o que é XSS [Cross-Site Scripting], consiste numa vulnerabilidade causada pela falta de validação em parâmetros de entrada do utilizador e a resposta do servidor numa aplicação web. Esta tipo de vulnerabilidade permite que seja inserido duma forma arbitrária, código HTML no browser de um utilizador.

O Hootsuite tem um historial de ser uma empresa que responde rápido a este tipo de problemas de segurança. Pessoalmente, posso confirmar esta situação porque já encontrei no passado [2012] uma falha do mesmo género nesta empresa. Embora não fosse uma falha crítica [Persistent Self-XSS], forneceu-me a ideia da postura da empresa perante uma pequena falha de segurança. Obtive um bom feedback por parte da equipa de segurança do Hootsuite, que resolveu rapidamente o problema. Esta atitude do Hootsuite, contraria o que é habitual, onde o XSS é na grande parte das vezes desvalorizado pelas empresas afetadas com este problema de segurança.

Malware em anúncios do Facebook

Malware em anúncios do Facebook

Alguns anúncios pagos no Facebook estão a propagar malware perante os utilizadores que clicam no mesmo.

Os temas são bastante variados mas salientam-se os anúncios de:

  • Produtos para aumentar desempenho desportivo
  • Redes sociais para adultos
  • Jogos sociais

Pelo que tenho conhecimento, o Facebook na altura da moderação do anúncio verifica automaticamente (ou manualmente) pela veracidade e reputação do site. Claro que após validação do anúncio, muito provavelmente, o malware não é detetado pelo Facebook. Utilizando técnicas mais avançadas de ofuscar código, também é possível esconder e passar por alguns filtros desta rede social e dos antivirus.
Um dos ataques que obtive acesso aproveitava-se de uma falha XSS de um site bastante popular para dar maior credibilidade. O vector XSS inseria um formulário HTML com a informação a ser enviada para um site russo ao invés do site original.

Fica aqui o alerta para não clicarem em anúncios duvidosos e manter sempre o vosso software atualizado.