blog

En el caso donde un archivo de imagen dd o raw (por lo tanto un flujo de bit o imagen bit a bit desde un disco) está dividido en varios archivos, es necesario preparar un archivo el cual se montará utilizando el comando “mount”.

Si se tiene un imagen constituida por SCHARDT.001, SCHARDT.002, SCHARDT.003, SCHARDT.004, SCHARDT.005, SCHARDT.006, SCHARDT.007 y SCHARDT.008. No se puede aplicar directamente los comandos forenses pertinentes, porque en este caso no se tienen un único archivo sobre el cual ejecutar el comando “mount”.

Para montar archivos de imagen raw divididos se tienen tres posibilidades.

El primer método consiste en la concatenación de archivos individuales en un único archivo de imagen, lo cual permite ejecutar los comandos forenses conocidos sobre un único archivo. La obvia desventaja en este caso, es el espacio requerido para la operación, el cual debeá ser igual a la ocupada por la suma de los archivos individuales, desde los cuales se requiere hacer una copia, concatenándolos en un único archivo.

El comando a ejecutar es:

$ cat SCHARDT.* >> SCHARDT.dd

El resultado es una imagen de nombre SCHARDT.dd conteniendo el disco completo obtenido mediante la concatenación de segmentos de imagen individuales.

Con este archivo se puede proceder con las operaciones forenses requeridas.

El segundo método es utilizar el comando “affuse” de la suite Afflib. Este puede ser utilizado para montar una imagen en formato AFF. Este comando creará un tipo de imagen “virtual” (y por lo tanto visible para el sistema, pero no existe en la realidad), el cual puede ser montado.

El comando a ejecutar es:

$ affuse SCHARDT.001 /tmp/evidencia/

Este comando producirá dentro del directorio “/tmp/evidencia” un archivo conteniendo una imagen dd o raw hecha de la concatenación de lo diversos archivos constituyentes de la imagen real. Este archivo será visible como “SCHART.001.raw”, y podría ser utilizado como parámetro para el comando “mount”.

El tercer método para montar una imagen raw divida es utilizar la herramienta en línea de comando “xmount”. Similar al comando “affuse”, xmount crea un archivo virtual conteniendo la imagen hecha por la concatenación de los segmentos individuales constituyentes de la imagen real.

El comando es:

$ sudo xmount --in dd --out dd SCHARDT.* /tmp/evidencia/

Un archivo “virtual” de nombre “SCHART.dd” será creado dentro en el directorio /tmp/evidencia/. Este archivo puede ser montado utilizando los comandos pertinentes en modo de solo lectura.

Fuentes:

http://www.cfreds.nist.gov/
https://sourceforge.net/projects/afflib/
https://github.com/simsong/AFFLIBv3
https://pinguin.lu/xmount
http://linux.die.net/man/8/mount
http://www.deftlinux.net/
http://www.deftlinux.net/doc/EN-deft7.pdf

Para montar un archivo de imagen como solo lectura (conteniendo el volcado de un disco completo, no de una sola partición) se puede utilizar el siguiente comando.

$ sudo mount -t tipo -o ro,loop,offset=$((512*inicio_particion)) opciones archivo_imagen.dd punto_montaje

Las “opciones” y la sintaxis del comando “mount” son conocidas.

En este caso sin embargo, un método de montar basado en un dispositivo “loop” “convierte” (virtualmente, sin alterar la fuente) una archivo de imagen (estático) en un dispositivo Linux (dinámico), permitiendo al Kernel montarlo como si fuese un dispositivo real.

La opción “loop” permite este tipo de abstracción y se deriva desde una aplicación implícita y automática hacia la capa siguiente del comando “losetup”, a través del cual se puede asociar un dispositivo “loop” hacia la imagen de nombre “imagen.dd”.

De esta manera se pueden ejecutar aplicaciones trabajando sobre dispositivos, también sobre imágenes de almacenamiento masivo.

Si se desea evitar el uso de “-o loop”, se debe antes de montar, crear un dispositivo “loop” utilizando el siguiente comando.

$ sudo losetup -r /dev/loop DiscoWindows7.001

El dispositivo loop podría ser utilizado como si fuese un disco fuente, para ser montado de la manera descrita previamente.

Así, siendo capaz de directamente utilizar “-o loop”, se evita la creación de un dispositivo “loop”, el cual se debe recordar cerrar con el comando “losetup -d /dev/loop0”.

Otra opción esencial cuando se monta un archivo de imagen conteniendo la adquisición de un disco completo (y por lo tanto, no de una única partición) es el “offset” o desplazamiento.

A través de la utilidad “mmls” se puede encontrar el desplazamiento de inicio de una partición del disco.

$ sudo mmls DiscoWindows7.001

Para montar la partición identificada como 03 por la salida del comando “mmls”, se debe especificar el “offset” multiplicado por 512.

En lugar de realizar el cálculo del “offset” o desplazamiento multiplicando por 512 el punto inicial de la partición obtenida con “mml”, se puede utilizar un operador matemático del shell, incluyendo como un “offset” el valor de $((512 * Inicio_Partición)), donde “Inicio_Partición” indica el byte del “offset” de la partición requerida a montar.

$ sudo mount -t ntfs -o ro,loop,noatime,noauto,noexec,offset=$((512*206848)) DiscoWindows7.001 /tmp/windows01/

Cuando se hayan completado las operaciones sobre los dispositivos, antes de desconectarlo del sistema, es necesario utilizar el comando “umount”.

$ sudo umount /tmp/windows01

Como ya se ha mencionado, estos comandos pueden ser utilizados para montar un archivo conteniendo el volcado de un disco completo. Si sólo se ha realizado el volcado de una única partición, no es necesario utilizar el parámetro “offset”, pues el inicio de la partición coincide con el del archivo.

Fuentes:

http://linux.die.net/man/8/mount
http://www.deftlinux.net/
http://www.deftlinux.net/doc/EN-deft7.pdf

Para montar un sistema de archivos en modo de solo lectura simplemente se debe tipear el siguiente comando:

$ sudo mount -t [tipo] -o [opciones] Fuente Punto_Montaje

Donde:

• “Tipo” es el tipo del sistema de archivos, usualmente vfat, ntfs-3g, ext3, etc. o “auto” cuando no se está seguro del tipo del sistema de archivos (si se omite esta opción, el montado intentará independientemente de reconocer el tipo de sistema de archivos, y esto usualmente es exitoso).
• “Fuente” puede ser una partición como /dev/hda1 o /dev/sda1.
• “Punto_Montaje” es usualmente un directorio en /media, este debe ser creado antes de ejecutar el comando mount.

Los parámetros frecuentemente utilizados (los cuales deben seguir a continuación de la opción “-o” del comando mount) son:

• ro - solo lectura: montar como solo lectura
• rw - lectura escritura: montar como modo escritura.
• loop - para montar un archivo de imagen
• noatime - no cambia la fecha de última acceso
• noexec - no permite la ejecución de archivos
• offset=N - cuando se monta un archivo de imagen de disco se proporciona el número en bytes a saltar hasta el punto en el cual inicia la partición lógica a montar

Ejemplo 1: Montar con acceso de escritura una partición FAT32 sobre el cual se almacenará un volcado de un dispositivo (el resultado de una adquisición forense).

$ sudo mkdir /media/USB1
$ sudo mount -t auto /dev/sdb1 /media/USB1/

Ejemplo 2: Montar una partición FAT32 de un dispositivo de almacenamiento en modo solo lectura el cual se desea adquirir, por ejemplo para previsualizar archivos durante actividades del campo de trabajo (es esencial utilizar la opción “-o ro” para prevenir cualquier escritura accidental hacia el disco)

$ sudo mkdir /media/evidencia
$sudo mount -t auto -o ro /dev/sdb1 /media/evidencia

Para probar la incapacidad de poder escribir en el directorio “/media/evidencia” se ejecuta el comando touch para crear un archivo de nombre “archivo.txt”.

Fuentes:

http://linux.die.net/man/8/mount
http://www.deftlinux.net/
http://www.deftlinux.net/doc/EN-deft7.pdf

El comando mount permite conectarse hacia un sistema de archivos presente sobre un dispositivo o sobre un archivo almacenado sobre el disco hacia un directorio del sistema.

En el área Forense cuando se requiere montar un dispositivo como un disco duro, USB stick, CD / DVD / CD-ROM, disco flexible, etc., se utilizará, como fuente, el dispositivo por si mismo identificándolo. En este caso:

• Para disco flexibles (usualmente con un único disco flexible se tiene /dev/d0): /dev/fdX
• Para discos duros IDE: /dev/hdX
• Para Disco duros SATA o dispositivos USB: /dev/sdX
• Para CDROM: /dev/cdrom

La letra “X” identifica el número de dispositivos sobre el sistema de archivo, de tal manera se tendrá /dev/sda par el primer disco y /dev/sdb para el segundo, mientras los número observados después del dispositivo con el comando “fdisk -l “ (/dev/sda1, /dev/sda2, etc) identifican el número de la partición dentro del dispositivo.

En forense, el montado directo de una evidencia (por ejemplo, un disco, una unidad flash USB, etc.) debe ser realizada como solo lectura, y solo cuando sea necesario. Esto asegura la integridad de la evidencia pueda ser garantizada. Las buenas prácticas indican claramente nunca se debe trabajar con los originales, siempre y únicamente sobre una copia.

El sistema de archivos seleccionado, así como fue almacenado sobre el dispositivo, puede estar contenido dentro de un archivo sobre el disco, conteniendo el volcado o imagen de flujo de bits del dispositivo adquirido. Se tienen, en este caso, imágenes:

• Formato dd o raw. Imagen de flujo de bits
• Formato ewf: EnCase
• Formato aff: Advanced Forensic Format

Algunas veces el formato de flujos de bits es dividido en archivos de tamaño pequeño (De 2 a 4 Gigas cada uno) para ser guardados sobre sistemas de archivos con un límite en el tamaño del archivo (por ejemplo FAT32), en este caso se define como raw separado.

Fuentes:

http://www.forensicswiki.org/wiki/Raw_Image_Format
http://www.forensicswiki.org/wiki/Encase_image_file_format
http://forensicswiki.org/wiki/AFF
http://www.deftlinux.net/
http://www.deftlinux.net/doc/EN-deft7.pdf

A continuación se detalla un listado de comandos útiles para realizar tareas forenses relacionadas a la gestión de dispositivos de almacenamiento.

fdisk

Los discos duros pueden ser divididos en uno o más discos lógicos denominados particiones. Esta división es descrita en la tabla de partición encontrada en el sector 0 del disco. Fdisk es un programa conducido por un menu para la creación y manipulación de tablas de partición. Entiende tablas de partición tipo DOS, BSD o SUN.

La opción “-l” de fdisk lista las tablas de partición para el dispositivos especificado y luego sale. Si no se especifica un dispositivo, se utilizan aquellos mencionados en “/proc/partitions” (si existe).

$sudo fdisk -l

mmls

mmls muestra la disposición de las particiones en un sistema de volumen, lo cual incluye tablas de partición y etiquetas de disco. Expone información sobre el “offset” o desplazamiento inicial de cada partición y espacios sin asignar.

$sudo mmls /dev/sdc

hdparm

hdparm proporciona una interfaz en linea de comandos para diversas interfaces del kernel soportados por el subsistema “libdata” SATA/PATA/SAS y el antiguo subsistema controlador IDE.

La opción “-g” muestra la geometría de la unidad (cilindros, cabezas, sectores), el tamaño (en sectores) del dispositivo, y el “offset” inicial (en sectores) del dispositivo desde el inicio de la unidad.

$sudo hdparm -l /dev/sdc

mount

Todos los archivos accedibles en un sistema GNU/Linux están ordenados en un gran árbol, la jerarquía de archivo, con raíz en “/”. Estos archivos pueden estar esparcidos sobre diversos dispositivos. El comando mount se utiliza para adjuntar un sistema de archivos encontrado sobre algún dispositivo hacia el gran árbol de archivo.

El comando lista el tipo del sistema de archivo de los dispositivos de almacenamiento conectados, y la manera en la cual fueron montados (sólo lectura / escritura-lectura).

$ sudo mount

df

df muestra la cantidad de espacio disponible sobre un sistema de archivos conteniendo cada argumento del nombre de archivo. Si no se define un nombre, se mostrará el espacio disponible de todos los sistemas de archivos montados. El espacio en disco se muestra en bloques de 1K por defecto.

$sudo df -l

Fuentes:

http://linux.die.net/man/8/fdisk
http://www.sleuthkit.org/sleuthkit/man/mmls.html
http://linux.die.net/man/8/hdparm
http://linux.die.net/man/8/mount
http://linux.die.net/man/1/df
http://www.deftlinux.net/
http://www.deftlinux.net/doc/EN-deft7.pdf

Cuando se planea una prueba de penetración, si no se formulan adecuadamente las reglas del contrato, se puede finalizar en el mejor de los casos con una prueba de penetración de poco costo. Y en el peor de los casos, se puede ir a prisión. Con el objetivo de mantener a los profesionales en pruebas de penetración fuera de los confortables recintos de un una penitenciaría, esta hoja de trabajo permite al profesional recorrer a través de una serie de preguntas el establecimiento un conjunto firme de acuerdos para asegurar una efectiva prueba de penetración.

Información de contacto del equipo de pruebas de penetración:

Contacto principal
Teléfono móvil
Pager
Contacto secundario
Teléfono móvil
Pager

Información de contacto de la organización objetivo

Contacto principal
Teléfono móvil
Pager
Contacto secundario
Teléfono móvil
Pager
Fuentes:

Frecuencia de información diaria.
Hora y ubicación de la información diaria.

Fecha de inicio para la prueba de penetración.
Fecha de finalización para la prueba de penetración.
Las pruebas ocurrirán en las siguientes horas.
Podrían las pruebas ser anunciadas al personal del objetivo.
Podría la organización objetivo descartar direcciones IP de los sistemas atacados.

La red de la organización objetivo tiene capacidades automáticas de rechazo, lo cual podría interrumpir el acceso de maneras imprevistas (además de crear una condición de negación de servicio), de ser así, cuales pasos se tomarán para mitigar el riesgo.

Podría el rechazo de los sistemas atacados concluir la prueba. Si no, cuales pasos deberían ser tomados para continuar si los sistemas se rechazan y cual aprobación será requerida.

Direcciones IP de los sistemas atacantes del equipo de pruebas de penetración

Si es una prueba de tipo caja negra. Cual es la política relacionada con la visualización de datos (incluyendo datos potencialmente sensibles o confidenciales) sobre los hosts comprometidos.

Podrá el personal del objetivo observar al equipo de pruebas.

Firma del contacto principal representando a la organización objetivo
Fecha

Firma del lider del equipo de pruebas de penetración.
Fecha

Si es necesario, firmas de los evaluadores individuales.

Firma
Fecha

Fuentes:

https://pen-testing.sans.org/resources/downloads
https://pen-testing.sans.org/retrieve/rules-of-engagement-worksheet.rtf

Las pruebas de penetración modernas incluyen una diversidad de actividades contra multitud de potenciales objetivos. Intentar “Hackear” todo o dejar algo ultra importante fuera, es una manera segura de ejecutar una prueba de penetración no óptima. Un profesional en pruebas de penetración puede utilizar esta hoja de trabajo, para recorrer a través de una serie de preguntas con el personal del sistema objetivo, para ayudarlo a adaptar efectivamente el alcance de la prueba para una organización objetivo.

Este documento define los siguientes puntos:

Cuales son las preocupaciones de seguridad más grandes de la organización objetivo. Entre los ejemplos se incluyen exposición de información sensible, interrupción del proceso de producción, vergüenza debido a una desfiguración del sitio web, etc.

Cuales hosts específicos, rangos de direcciones de red, o aplicaciones serán evaluadas.

Cuales hosts específicos, rangos de direcciones de red, o aplicaciones no serán explícitamente evaluadas.

Lista de cualquier tercero propietario de sistemas o redes dentro del alcance, como también cuales sistemas son de su propiedad. Se debe tener un permiso escrito por adelantado de la organización objetivo.

Será la evaluación realizada contra entornos de producción en vivo o un entorno de prueba.

La prueba de penetración incluirá las siguientes técnicas de prueba.

• Barridos ping de rangos de red
• Escaneo de puertos de los hosts objetivos
• Ecaneo de vulnerabilidades de los objetivos
• Penetración dentro de los objetivos
• Manipulación de nivel de la aplicación
• Ingeniería inversa Java/ActiveX del lado del cliente
• Intentos de penetración física
• Ingeniería social a las personas
• Otros

La prueba de penetración incluirá pruebas internas de red. Si es así, como se obtendrá este acceso.

Están los sistemas del cliente/usuario final incluidos dentro del alcance. Si es así, como podrían los clientes ser aprovechados.

Esta permitida la ingeniería social. Si es así, como será utilizada.

Están permitas los ataques de Negación de Servicio.

Están permitidas las verificaciones/exploits peligrosos.

Firma del contacto principal representando la organización objetivos

Fecha.

Firma del lider del equipo de pruebas de penetración.

Fecha.

Fuentes:

https://pen-testing.sans.org/resources/downloads
https://pen-testing.sans.org/retrieve/scope-worksheet.rtf

Una técnica para capturar información desde un servidor SQL Server es utilizando la herramienta SQLPing 3. Como SQL Server soporta varias instancias, es necesario para el servidor comunicar hacia el cliente los detalles de cada instancia SQL Server existentes en el servidor. SQLPing 3 utiliza el mecanismo de descubrimiento inherente en SQL Server para consultar al servidor por información detallada sobre la capacidad de conectividad del servidor y mostrarlas al usuario.

El servicio de resolución SQL o el servicio de navegación SQL operan sobre el puerto 1434 UDP. Las consultas pueden ser enviadas como paquetes de difusión hacia subredes específicas de tal manera en muchos casos, donde existe una firewall con floja seguridad, es posible consultar una subred completa con un simple paquete.

Se ejecuta la herramienta SQLPing 3, la cual es una herramienta visual.

Existen tres tipos de escaneos disponibles factibles de realizar utilizando la herramienta. Activa (Un Rango de direcciones IP), Activa (Una lista de dirección IP), y oculta.

Se selecciona el primer tipo de escaneo, definiendo adicionalmente la dirección IP de inicio en el campo “Start” o Inicio, y la dirección IP final en el campo “End” o final. Luego se procede a hacer clic en el botón de nombre “Scan” o Escan.

En la respuesta obtenida por la herramienta SQLPing 3, se puede encontrar información sobre el nombre del servidor SQL, nombre de la instancia (MSSQLServer es el nombre por defecto de la instancia). Estado del cluster (¿El servidor es parte de un cluster?), versión (devuelve sólo la versión base, pero es fácil identificar diferentes versiones). Netlib soporta detalles (Incluyendo puertos TCP, nombres de tubería, etc).

SQLPing 3 también permite realizar un ataque por fuerza bruta contra usuarios y contraseñas. Para la siguiente demostración se define en el campo “User List” o Lista de Usuarios, un archivo conteniendo los nombres de usuarios a evaluar. En el campo “Password List” o “Lista de Contraseñas”, se define un archivo conteniendo las probables contraseñas. En este escenario de evaluación ha sido factible identificar la contraseña correcta para el usuario “sa”.

De hecho se pueden encontrar administradores quienes han cambiado el puerto TCP por defecto de un servidor SQL atendiendo en un socket TCP/IP, pero un atacante utilizando SQLPing 3 puede fácilmente preguntar al servidor hacia donde se movió el puerto.

La información recogida por SQLPing 3 puede también identificar objetivo suculentos, los cuales son usualmente de misión crítica. Toda esta información expuesta ayuda al atacante a comprometer de alguna manera la instalación del SQL Server. Eso sin mencionar la capacidad de identificar usuarios y contraseñas válidos.

Fuentes:

http://www.sqlsecurity.com/downloads

Un ataque de Negación de Servicio (DoS) se enfoca en hacer un recurso (sitio, aplicación, servidor) no disponible para los propósito de su diseño. Existen diversas maneras de hacer un servicio no disponible para usuarios legítimos mediante la manipulación de paquetes de red, programación, lógica, o vulnerabilidades en el manejo de recursos, entre otros. Si un servicio recibe una número muy grande de peticiones, puede cesar su disponibilidad para usuarios legítimos. De la misma manera, un servicio puede detenerse si se explota una vulnerabilidad de programación, o la manera en la cual el servicio maneja los recursos utilizados.

Para la siguiente demostración se utiliza la herramienta de nombre OWASP Switchblade. Esta herramienta se utiliza para realizar pruebas de capacidad y carga; mejor conocidas como Negación de Servicio; sobre una aplicación web funcionando sobre Apache o IIS.

Se visualiza la carga y el tráfico en el servidor objetivo, o quien recibirá el ataque DoS.

En un sistema Windows se ejecuta la herramienta OWASP Switchblade. Defiendo la URL pertinente, y valores como el número de conexiones, velocidad de conexión, tiempo de espera, y agente de usuario. Además de definir el uso del método POST.

Al hacer clic en el botón de nombre “Run Attack”, se apertura una nueva ventana y se inicia el ataque.

Esta herramienta incluye técnicas letales como “SSL Half Connect”, “HTTP Post” y “Slowloris”. Con esta herramienta es factible determinar si las defensas contra una Negación de Servicio son las adecuadas.

De retorno al servidor objetivo de evaluación, se visualiza un incremento en el uso del ancho de banda.

Si un usuario legítimo intentase acceder hacia la aplicación web objetivo, esto no será factible.

Algunas veces un atacante puede inyectar y ejecutar código arbitrario mientras realiza un ataque de Negación de Servicio (DoS) para acceder hacia información crítica o ejecutar remotamente comandos en el servidor. Ataques de negación de servicio degradan significativamente la calidad del servicio experimentado por usuarios legítimos. Estos ataques introducen grandes retrasos en las respuestas, perdidas excesivas, e interrupciones del servicios, lo cual genera un serio impacto en la disponibilidad.

Fuentes:

https://www.owasp.org/index.php/Denial_of_Service
https://www.owasp.org/index.php/OWASP_HTTP_Post_Tool
http://www.binarytides.com/linux-commands-monitor-network/
https://github.com/proactiveRISK/ddos-toolbox
http://www.itsecgames.com/

El archivo “sapi/cgi/cgi_main.c” en versiones anteriores a PHP 5.3.12 y 5.4.x anteriores a 5.4.2, cuando es configurado como un script CGI (mejor conocido como php-cgi), no maneja adecuadamente las cadenas de consulta careciendo del caracter correspondiente al signo igual “=”.

Cuando PHP es utilizado en una configuración basada en CGI; como el mod_cgi de Apache; php-cgi recibe y procesa parámetros de cadena para consulta como argumentos en línea de comando, lo cual permite pasar opciones en línea de comando, como “-s”, “-d” o “-c”, hacia el binario php-cgi, lo cual puede ser explotado para exponer el código fuente y obtener ejecución de código remoto.

Para la siguiente demostración se utiliza la máquina virtual de nombre “bee-box”conteniendo la versión más actual de bWAPP.

Ingresar a bWAPP, y seleccionar el “bug” de nombre "PHP CGI Remote Code Execution", para luego hacer clic en el botón de nombre “Hack”..

Se verifica la versión API del servidor y versión de PHP.

La manera más simple de explotar esta vulnerabilidad permite exponer el código fuente PHP, utilizando la URL adecuada.

http: //IP_Objetivo / bWAPP/ admin/?-s

El atacante también puede optar por ejecutar comandos en el servidor. Esencialmente; con esta vulnerabilidad; se podría inyectar argumentos dentro del binario PHP-CGI y hacer cambios en las directivas “php.ini” permitiendo la ejecución remota de código.

Para ganar la capacidad de ejecutar código remoto, se debe indicar a “php.ini” permita la inclusión de URL (allow_url_include = 1), y automáticamente anteponer el “archivo” php//:input. Esto significa lo enviado en una petición POST es interpretado como PHP, y ejecutado

Se utiliza la funcionalidad de “Resend” o Reenvío de Zed Attack Proxy, para enviar una nueva petición utilizando el método POST solicitando la siguiente URL:

http://IP_Objetivo /?-d+allow_url_include %3d1+-d+auto_prepend_file %3dphp://input

En el cuerpo del mensaje se incluye el comando a ejecutar.

<?php echo(md5("Hola Mundo")) ?>

La respuesta devuelta por el servidor incluirá para este caso el resultado de aplicar un hash MD5 sobre la cadena de texto “Hola Mundo”.

Un atacante remoto no autenticado podría obtener información sensible, causar una condición de negación de servicio, o puede ser capaz de ejecutar código arbitrario con los privilegios del servidor web.

Fuentes:

https://www.owasp.org/index.php/Server-Side_Includes_(SSI)_Injection
http://www.itsecgames.com/
https://bugs.php.net/bug.php?id=61910
https://cve.mitre.org/cgi-bin/cvename.cgi?name=cve-2012-1823
https://www.rapid7.com/db/vulnerabilities/php-cve-2012-1823
http://insecurety.net/?p=705