Un fugtivo británico ridiculiza a la policía desde Facebook

Según la notícia online publicada Craig Lynch se encuentra a la fuga de la policía británica y usa los mensajes de la red social Facebook para burlarse de los mismos...

BlackHat Europe BCN

Black Hat Europe 2010. Éste año se celebra en Barcelona del 12 al 15 de Abril y para los interesados, el periodo de suscripción, y el de call for papers, está abierto desde el 15 de Diciembre de 2009...

Aprobado el Esquema Nacional de Seguridad

El Consejo de Ministros ha aprobado dos Reales Decretos que regulan los Esquemas Nacionales de Interoperabilidad y de Seguridad, dos herramientas esenciales para afianzar una administración electrónica más segura y eficaz....

La crisis y los despidos disparan el robo de
información

El robo de información confidencial en las empresas españolas ha aumentado un 60%. Este incremento se asocia a la situación de crisis económica, puesto que al aumentar el número de despidos, los empleados optan a menudo por recabar información...

Un ratón logra abrir una cámara acorazada !

Un ratón ha logrado abrir la cámara acorazada donde se guardaban los depósitos en un banco de la ciudad china de Cantón (sur), al pasar accidentalmente por el botón que controlaba su apertura, según informa hoy la prensa china...

Nuevo Dominio securecorner.net

Para tu comodidad, desde ahora podrás acceder al blog desde www.securecorner.net

Cheat Sheet de Meterpreter

Nuevo Cheat Sheet de Meterpreter realizado por blueliv.

Sin lugar a dudas un "Chuletario" muy útil para tener a mano !


Saludos,

Métodos alternativos de análisis forense

En ocasiones, duarante el desarrollo de un análisis forense postmortem, podemos requerir de la realización de una extracción masiva de documentos e información. Incluso, se podría requerir escanear el sistema en búsqueda de malware, como troyanos, spyware, backdoors, etc.  

Por ello, podemos recurrir a la utilización de herramientas que nos permitan acceder al contenido de la imagen DD bajo análisis, pudiendo montar el contenido de sus particiones como carpetas o unidades de disco en nuestro sistema de análisis.

Cabe indicar, que es importante asegurarse siempre trabajar desde una copia de análisis, asegurándonos que disponemos de un backup de la imagen original. Además de trabajar desde una copia de la imagen, es conveniente asegurarse que las herramientas que vamos a utilizar permiten montar la imagen en modo de "solo lectura".

Con el objetivo arriba indicado, disponemos de herramientas para:


  • Montar las particiones contenidas en nuestra imagen DD para acceder al contenido de las mismas y así poder ser analizadas con más facilidad
  • Realizar conversiones de formato DD a formato VMware/VirtualBox,... para poder disponer así de una máquina virtual a ser analizada. Ésta técnica es útil para análisis de ingeniería inversa si se ha confirmado que la máquina pudiera estar infectada.

Herramientas para montar particiones

Las siguientes herramienas nos permiten montar a partir de una imagen DD una o todas las particiones que ésta misma contenga:
  • Mount Image Pro
  • SmartMount
  • ImDisk
  • Filedisk
  • mount (linux)
Mientras que las 4 primeras herramientas son herramientas del entorno windows, también disponemos de la utilidad "mount" en sistemas UNIX, pudiendo montar la imagen DD como loopback, mediante el siguiente comando:

  • mount -o ro,noexec,loop,offset= imagen.dd /mnt/destino

Herramientas para crear un disco virtual

  • Liveview: Permite a raíz de una imagen DD y una sencilla interfaz gráfica, la creación de una máquina virtual que usa como dico base la imagen en cuestión a analizar.
  • Qemu: Es un emulador y virtualizador genérico de CPU que permite la ejecución de sistemas operativos y aplicaciones de una máquina a otra. Sin embargo, podemos aprovechar la utilidad de conversión de formatos para convertir una imagen DD a una imagen vmdk, usando por ejemplo el siguiente comando:
    • qemu-img convert imagendiscoendd.dd -O vmdk nombrediscovmdk.vmdk
  • VBoxManage: Pemite la creación de un disco virtual box a partir de una imagen DD. El siguiente comando, representa un ejemplo de cómo realizarlo:
    • VBoxManage convertdd imagendiscoendd.dd nombrediscovdi.vdi
Una vez creados nuestros discos virtuales, como es el caso de qemu y VBoxManage, tan solo deberemos crear una nueva máquina virtual que use el disco obtenido a partir de la imagen DD. Para ello, accederemos a las opciones avanzadas de creación de nuevas máquinas virtuales.

Como alternativa, y si vamos con cuidado, podemos editar cualquier fichero VMX de una máquina virtual existente para realizar un cambio de disco. Veamos a continuación los ficheros que tiene una máquina virtual VMware:


y a continuación, veamos el fichero .vmx que es el ficher de configuración de la máquina virtual:



Como podemos observar, esta máquina virtual dispone de un disco duro scsi, que podremos encontrar en la misma carpeta bajo el archivo binario "Other Linux 2.6.x kernel0000001.vmdk".

Como hemos podido ver, las máquinas virtuales no son más que ficheros de texto con sus correpondientes ficheros binarios de disco o de memoria, entre otros. Por ello, cabe destacar que LiveView en el fondo lo que realiza es la automatización y creación de dichos ficheros mediante una interfaz amigable sin realizar conversión de la imagen DD a vmdk.

Saludos,


Cross Site Scripting III

En los posts anteriores vimos cómo detectar XSS y evadir posibles filtros basados en listas negras de carácteres. Hoy, a modo de ejemplo, quiero presentar el framework BeEF que dada una vulnerabilidad de cross site scripting, nos permitirá disponer de un conjunto de "bots" que se conectarán a su "botmaster" para ejecutar las órdenes indicadas por el mismo.

Las funcionalidades que dispone BeEF por defecto son:


  • Módulo de autorun: Ejecución automática de determinados módulos javascript (Alert o Deface) cada vez que un bot se conecta contra el botmaster.
  • Clipboard: Módulo que permite obtener el contenido del portapapeles aprovechandose de características de Internet Explorer anterior a la versión 7.
  • Historial de navegación: Módulo que permite obtener el historial de navegación del bot usando técnicas de bruteforcing. 
  • Iniciación de peticiones: Desde el botmaster, podríamos iniciar peticiones HTTP en nombre del bot o bajo la identificación (IP, CNAME,... ) del zombie, permitiendo descargar cualquier tipo de software/malware.
  • Port Scaner: Escaneo de puertos de la red dónde está conectado el zombie, permitiendo así, realizar un escaneo de puertos de la red interna a través de una vulnerabilidad de cross site scripting.
  • Ejecución de exploits del navegador
  • Inyección de código javascript: Permite la ejecución de culquier tipo de código desarrollado por uno mismo, permitiendo lanzar ataques no contemplados por BeEF.
  • Comunicación Inter-Protocol: Permite usar el navegador "infectado" como vía de comunicación con la red interna del zombie. Por ello, el "Content Body" HTTP será el protocolo con el que se desea dialogar, estableciendo un tunnel HTTP, ya que en la mayoría de casos, el protocolo destino obviará las cabeceras HTTP y se centrará en interpretar las cabeceras que viajan en el contenido del mensaje del mismo.
Como prueba de concepto, he "infectado" una máquina cliente a través del formulario que vimos en los posts anteriores, realizando en éste caso una redirección/recarga de la URL mediante el siguiente código:



Como se observa en la siguiente imagen, cuando el usuario navega hacia la URL vulnerable, es redirigido hacia el servidor web malicioso que dispone de los scripts BeEF que infectarán a la víctima.


A continuación activamos el autorun, cerramos el navegador y volvemos a visitar el formulario vulnerable....






Obtención del historial de navegación.....

Ejecución de exploits del navegador ...

Lo más fascinante es que todo esto lo podemos ejecutar mediante código javascript sin ser detectados por los dispositivos perimetrales, ya que éstos, no lo detectarán como malware!!

En conclusión. En éstos últimos posts, hemos visto que a pesar que los cross site scripting no se consideran tan críticos como una inyección SQL, tienen mucha más importancia de la que a simple vista puede parecer, ya que como hemos visto, podríamos:

  • Realizar un daño en la imagen corporativa de una empresa/organización y ocasionarle graves pérdidas económicas
  • Obtener información de los zombies infectados
  • Realizar escaneos de puertos de la red interna a través de los zombies
  • Establecer comunicaciones con recursos internos en nombre de las máquinas zombie
  • Infectar nuevas máquinas, abriendo nuevos canales de explotación
Saludos,



La problemática de los Cross Site Scripting II

La semana pasada, estuve hablando sobre la problemática de los cross site scripting, repasando los principales ataques que se pueden realizar explotando una vulnerabilidad de éste tipo. Esta semana, voy a poner algunos ejemplos al respecto. 

Por ello, he creado una aplicación muy sencilla que nos servirá como prueba de concepto. Consta de un campo de formulario que se envía por método GET hacia el servidor, el cual contiene una pequeña aplicación PHP vulnerable a inyección de javascript cuyo código fuente es el siguiente:




         $var=$_GET['var1'];


Como se puede observar, no se efectúa validación de los parámetros de entrada que provienen del usuario, fallando en la regla básica de seguridad de todo aplicativo. 

Si realizamos una prueba inicial para comprobar qué filtrados realiza la aplicación, observamos lo siguiente:

Campo de fomulario que visualiza el usuario,


Valor de prueba que le insertamos ('"

Resultado obtenido y procesado por el código PHP anteriormente citado,

Visualización del código fuente que ha devuelto el servidor,


Como se ha podido observar, el mismo PHP (depende de la versión), proporciona escape de carácteres potencialmente peligrosos (mediante contrabarras), como por ejemplo ' y ", evitando ataques de inyección de código XSS, SQL, ... 

Como comenté en el post anterior, existen medidas de escape de los filtros basados en listras negras o blacklist, que, dependiendo de los controles y la programación de la aplicación serán más o menos compleja su evasión. 

Si volvemos a observar el código fuente devuelto por el servidor, el parámetro HTML "value" no se encuentra entre comillas, permitiendo a un atacante la inserción directa de código HTML. 

NOTA: Muchas veces, es importante insertar los caracteres para romper lo mínimo el código fuente. En este caso, no insertamos el últumo ">" porque es insertado siempre por la aplicación. Análogamente para el primer ">". Otras veces, es posible que se deban usar la inserción de comentarios cómo medida de escape.

Como podreis observar si realizais la prueba, el servidor no escapará ningún carácter de los anteriormente insertados, produciendo el siguiente código HTML:


Que daría como resultado lo siguiente:


Pues como veis, hemos podido comprobar que el navegador del usuario (en éste caso el mío) ha ejecutado el código que le hemos insertado sacando por pantalla el valor de la cookie (que obviamente es nulo).

Una vez hemos comprobado que podemos ejecutar código javascript, se podrían realizar cualquiera de los ataques que hablamos en el post anterior, pero antes, debemos descubrir cómo escapar al filtro de PHP, y lograr introducir comillas.


Por ello, vamos a recurrir a un Cheat Sheet elaborado por Rsnake, el cual contiene varios métodos de evasión para diferentes situaciones. Si nos paramos a pensar un poco, en nuestro caso lo que necesitamos es escapar al filtro de comilla simple y comilla doble, por lo tanto, ¿por qué no transformar dichos caracteres en su equivalente CharCode (Valor decimal de la representación ASCII del carácter)?



La problemática de los Cross Site Scripting

Los ataques de Cross Site Scripting (XSS) son uno de los ataques más peligrosos y más subestimados que existen en la actualidad. Con éste tipo de ataques, una organización puede sufrir daño a la imagen corporativa y pérdida de información. Podemos recordar el reciente ataque a través de twitter a la web de la presidencia Española en el que a través de la distribución de un enlace malintencionado se "modificó" el contenido de la página.

¿Qué puede hacer un atacante a través de una vulnerabilidad de éstas características? Pues la verdad que dependerá un poco del tipo de cross site según sea:

  • Persistente: El código inyectado quedará almacenado y cada vez que se cargue la página, los usuarios legítimos ejecutarán el código.
  • Reflejado: Sólo los usuarios que carguen la URL malintencionada ejecutarán el código

Como podeis observar, la primera vía, será más fácil y cómoda para un atacante, sin embargo, no cabe olvidar a nuestras amigas las "redes sociales" que serán un mecanismo de distribución importante para casos donde el XSS sea reflejado. En general, mediante un XSS se podrán realizar ataques del tipo:

  • Obtención de cookies de usuario (redirección de la URL legítima hacia otra)
  • Redirección del usuario (Si tuvieramos un login vía formulario Web sobre HTTPS, ¿por qué no redireccionarlo hacia otro servidor al hacer el submit del formulario?)
  • Modificación de contenido Web
El problema de éste tipo de vulnerabilidades, es que se podrá hacer casi cualquier cosa que se nos pueda imaginar gracias a las tecnologías de client que disponemos en la actualidad (Flash, Javascript, applets,ruby, perl, ....) pudiendo realizar otro tipo de ataques más avanzados (usando IFRAMES ocultos) como:

  • Escaneo de puertos de servicios internos
  • Fingerprinting de servidores internos
  • Obtención información del cliente como el historial de navegación (...¿¿¿contraseñas guardadas en el navegador???....)  que podrá permitir a un atacante obtener información de nuevos activos o recursos de una red interna.
  • Ejecución de exploits en el navegador que nos permitan aprovechar vulnerabilidades de las que rondan por ahí en la actualidad...
  • etc etc
¿Cómo vamos a proteger las aplicaciones? Pues existe tan solo 1 solución y que recibe el nombre de  FILTRADO. Es una solución muy obvia pero no todo el mundo utiliza los mecanismos de filtrado más efectivos:

  • Filtrado por Whitelist: Se define una lista de carácteres/palabras legítimas que pueden utilizarse. 
  • Filtrado por Blacklist: Se defines una lista de carácteres que no se podrán utilizar, como por ejemplo, "/", "
Inicialmente, uno puede pensar que el método de filtrado por blacklist podría ser el más eficiente y rápido de implantar, pero si consideramos que existen técnicas de evasión de filtrados, se puede llegar a la conclusión que el método más seguro será el uso de whitelists.

Saludos,