Múltiples vulnerabilidades en "torremolinos.es"

Para quienes no lo conozcáis, Torremolinos es un pueblo de la provincia de Málaga.
Es el pueblo donde me he criado, estudiado, crecido,... y la verdad, ha cambiado mucho en estos años, en algunas cosas para bien y en otras para mal.

En lo que no ha cambiado demasiado (desde que soy usuario) es la web. Siempre me ha dado la sensación, de estar poco cuidada, insuficientemente accesible y poco actualizada. Parecen que en el ayuntamiento, no han entendido la importancia cada vez más creciente de la "web 2.0", y que cada vez más, tiene peso la presencia web para el turismo.

Tras mi critica personal sobre el estado "tecnológico" de mi pueblo, vamos a caso:

El primero de los fallos que he encontrado y reportado al ayuntamiento de Torremolinos es un Inyección SQL:

De Rollanwar

En este ejemplo se puede ver como la base de datos retorna el resultado inyectado, en este caso el voluntario anterior.
No he probado cosas más complicadas, pero cambiando "%20or%20ID_voluntario=%20453" por otro código más complejo se podría, potencialmente, obtener toda la base de datos de "www.torremolinos.es".

Recordar a los lectores que este tipo de practicas podrían constituir un delito.
Entiendo que esta explotación no cumple ninguno de los puntos que podrían ser tenidos en cuenta para constituir un delito, dado que esta explotación es inocua para el sistema y los datos obtenidos son publicos, se podría acceder a esos datos de forma normal.

Por otro lado he encontrado un XSS.
Los más observasores se abran dado cuenta que en la imagen anterior ambos voluntarios tenían la misma cantidad de puntos, y es que no es casualidad, es por el parámetro '&puntos=750&', cambiando el valor por '&puntos=750<script >alert("XSS");</script>&' magia:

De Rollanwar

En este ejemplo se puede ver se ejecuta el código inyectado.

Este fallo no es demasiado grave, pero permite modificar el contenido de la web, a través de una url, es decir, solo ven el contenido modificado quienes sigan ese enlace.
Al tratarse de una vulnerabilidad leve, he decidido publicarla directamente, sin espera respuesta, en "http://secureless.org".

Un ejemplo de esta explotación más llamativa puede ser la siguiente:

De Rollanwar

Por último podemos ver como también se produce un error en el tercer marámetro si insertamos una comilla.

De Rollanwar

No he intentado explotar este SQLi.

En la primera solución que se implementó por parte del ayuntamiento se filtra inadecualamente los caracteres de la URL, para redirigir a la web principal, pero se puede seguir explotando el fallo sustituyendo los espacios por '+'.

Como esta primera solución no se me comunicó decidí pasarme en persona a ver si solucionan el fallo.

Durante mi paso por el ayuntamiento, me informaron de nuevas mejoras e ideas para el futuro "web" del ayuntamiento. He de decir que los cambios para el futuro que me comentaron solucionará varias de las criticas que he vertido al inicio del post.

Estos fallos ya han sido solucionados.

TIMELINE:
08-05-2011: Descubierta
09-05-2011: Notificación del SQLi y XSS
09-05-2011: Publicación del XSS en 'secureless.org'
11-05-2011: No responde, pero parece que solucionan el problema
16-05-2011: Me pongo en contacto de nuevo, esperando contestación.
19-05-2011: No contestan y publico.
24-05-2011: Confirmo que el filtro aplicado no es valido.
24-05-2011: Retiro el post.
24-05-2011: Reenvio fallo con el nuevo ejemplo.
25-05-2011: Paso en persona a ver que ocurre con este asunto.
02-06-2011: Me informan que está solucionado.

XSS en la web de trafico de RICA (Red informatica cientifica de andalucia)

Buscando un formación sobre las redes públicas españolas he podido descubrir un fallo leve de seguridad que ya ha sido notificado a los administradores del sitio.

El error era causado al no validar correctamente la variable "titulo", que se usa para escribir el título de las gráficas mostradas.

Os dejo una imagen sobre el fallo.

De Rollanwar

En el ejemplo se ha usado un iframe y un javascript para mostrar los impactos más importantes.

Una vez encontrado este fallo me puse en contacto con el quipo de seguridad de CICA quienes solucionaron el problema en dos "partes".

La primera solución, temporal, filtraba las comillas (', ") del título. Esto complica la escritura del XSS, pero no soluciona correctamente el problema.

Como no se filtra el código HTML y los navegadores son relajados para la interpretación de código HTML, se podría explotar linkando un JS externo y ejecutandolo el código escrito en la web.

Como observé que este primer filtro no solucionaba el problema, y como no había recibido contestación, me puse en contacto con ellos para conocer el estado de la incidencia y sugerirles usar el filtro 'htmlentities'.

Este post ha sido publicado tras recibir y confirmar que el fallo se encontraba solucionado.

TIMELINE:
18-04-2010: Descubierta
19-04-2010: Notificado y recibido la respuesta
20-04-2010: Solución temporal (No soluciona el problema del todo. Aún no he recibido notificación oficial)
23-04-2010: Me pongo en contacto de nuevo con ellos para confirmar que siguen con ello.
28-04-2010: Me confirman que están trabajando en ello.
30-04-2010: Me confirman la solución y publicación.

Salto de resticciones en Statpress

Recientemente he descubierto un fallo en el plugins de wordpress 'statpress'.

El error es causado por el modo en le que este plugin realiza la acción de exportar. El manejador no comprueba correctamente los permisos del usuario que llama ha esta acción. Esto permitiría a un atacante no autenticado obtener los datos de las estadisticas.

Dado el comportamiento del manejador, la acción de exportar se realiza durante la importación del plugin; dado que statpress realiza el las estadisticas durante la etapa de 'wp-head' esta acción no queda reflejada en las estadisticas.

El fallo se soluciona creando una acción en la etapa de 'init' de Wordpress (antes de enviar las cabeceras) haciendo que se llame a un evento apropiad.

Este error no se puede explotar si el plugins no esta activo.

Prueba de concepto

site.com?statpress_action=exportnow&from=FECHA&to=FECHA&del=SEPARADOR

Parche sugerido:

add_action('init', 'iri_checkExport');
function iri_checkExport(){
 if ($_GET['statpress_action'] == 'exportnow') {
  $mincap=get_option('statpress_mincap');
  if ($mincap == '')
   $mincap = "level_8";
  if ( current_user_can( $mincap ) )
   iriStatPressExportNow();
 }
}

TIMELINE:
04-12-2009: Descubierta
06-12-2009: Creda posible solución
11-12-2009: Notificado
12-12-2009: Recibido comunicado de que lo solucionarán
13-12-2009: Se inserta el fix pero no se borra el error, Notificado
18-12-2009: Solución final publica

Saca la versión de Wordpress gracias a Gears

Bueno, cuando estuve mirando el error del FPD observé que existía un fichero que mostraba con un contenido demasiado explicito, en un principio pesé que podía ser un fallo por el que se descubriría la versión del wordpress instalada, movido por un dato muy claro:

"version" : "ae52efa2f066ffc235840dc615f051d7"

En ese momento me mosqueo un poco y me puse a buscar. Que diablos era ese fichero con referencias a javascripts.

Resulta que es un fichero usado por Gears, antes Google Gears.

¿Que es Gears? os preguntareis algunos. Pues bien Gears es un programa diseñado en principio por Google y que posteriormente ha liberado para la comunidad. Este es el software que en el que se basa Gmail offline o GoogleDocs offline entre otros. Con estos datos el software se descarga de tu sitio la información para que puedas usarla sin conexión y luego se sincroniza con el servidor.

Pero vamos a lo interesante.

¿Como calcula la versión?

En la versión 2.8.x el calculo se realiza a partir de:

//El generador que da soporte a Gears usa estos datos
md5( $tinymce_version . $manifest_version ) //Como aparece en manifest.php
//Donde:
$tinymce_version = "3241-1141" //Para 2.8.x
//Y
$manifest_version = "20090610" //Para 2.8
$manifest_version = "20090616" //Para v2.8.1 - 2.8.4
//Por tanto:
//En v2.8 podriamos poner
echo '"version" : "068d0a4281fb2a342ba6fd73b6b93982"';
//En v2.8.1-2.8.4
echo '"version" : "ae52efa2f066ffc235840dc615f051d7"';

En las versiones 2.6.x y 2.7.x el valor de $man_version se calcula mediante unas funciones que crean un dato que parece aleatorio; pero bueno eso no es un muy importante ya que se le añade un "_DIGITOS" que nos indica la versión. Haciendo por tanto que el valor de $man_version sea poco relevante.

//En v2.7.x
$man_version = bucles_1($man_version)//Por resumir
$man_version = md5($man_version);
//Podríamos poner algo asi en v2.7.x
echo '"version" : "'."$man_version"."_20081201".'"';
//En v2.6
$man_version = bucles_2($man_version)//Por resumir
$man_version = md5($man_version);
echo '"version" : "'."$man_version"."_20080710a".'"';
//En v2.6.1 - 2.6.5
echo '"version" : "'."$man_version"."_20080810".'"';

Lo curioso del caso es que según las especificaciones de Geads el valor de "version" es un String, que solo indica si ha cambiado o no el contenido del fichero. Por tanto sería igual de valido hacer un md5 de la fecha de la ultima actualización si es que esta actualización cambiase el valor de este fichero. O incluso lo que seria más óptimo, cuando se instalase el blog se creara un fichero estático y se modificara en caso de ser necesario en vez de estar generandose continuamente con cada petición.

Pero aun hay algo más, dado que en los datos mostrados existe más información sobre versiones de los distintos ficheros js, podríamos obtener más diferencias.

En la versión 2.7 thickbox.js?ver=3.1-20080430

En la versión 2.7.1 thickbox.js?ver=3.1-20090123

Si en el caso de 2.7.x hay que mirar en "thickbox", en las versiones 2.6.x lo tenemos aún más fácil, ya que podemos encontrar varios sitios donde viene directamente la versión, por ejemplo, wp-admin.css?ver=2.6.x entre otros.

//Parte del código de gears-manifest.php en la versión 2.6.1
foreach ( $wp_scripts->registered as $script ) {
	if ( empty($script->src) || strpos($script->src, 'tiny_mce_config.php') ) continue;
	$ver = empty($script->ver) ? $wp_version : $script->ver; //Aquí en ocasiones se incluye la versión
	$src = str_replace( array( '/wp-admin/', '/wp-includes/' ), array( '', '../wp-includes/' ), $script->src );
	$defaults .= '{ "url" : "' . $src . '?ver=' . $ver . '" },' . "\n";
	$man_version .= $ver;
}

Conclusiones

Aunque en principio podría haber parecido un vector claro para conocer la versión del Wordpress, parece que en las versión 2.8.x estos datos claros se han eliminando.

Aún así en la versión actual sigue dejando un claro punto para saber si la versión en cuanto cambien los valores de $tinymce_version o $manifest_version.

Bajo mi punto de vista, como ya he dicho antes, modificaría el modo de crear el valor de "version" y lo convertiría en un dato aleatorio, que solo cambien cuando sea necesario.
De este modo un posible atacante solo sería capaz de conocer si un wordpress se ha actualizado conociendo el valor anterior de "version" si esa actualización cambiara este dato, hecho que no siempre ocurre.

Referencia:
Tutorial de gears
Arquitectura de gears
Aplicaciones disposibles