Identificando usuarios de LogmeIn en tu red

Si eres un administrador de seguridad o de sistemas y estás interesado en identificar que usuarios de tu red están utilizando el servicio de LogMeIn para conectarse a equipos de tu trabajo, no busques más: este es tu post. La única premisa es que necesitaras Snort para ello.

Vamos pues al tema. El esquema básico de comunicación de LogMeIn está formado por 3 elementos: un servidor propiedad de esta compañía, el equipo al que queremos conectarnos (un PC por ejemplo) y el equipo desde el que queremos conectar (PC, servidor, Smartphone, etc). Inicialmente y tras instalar el agente en la máquina Host, esta iniciará una conexión a los servidores de LogMeIn para enviar un Heartbeat TCP cada 30 segundos, manteniendo así una conexión abierta SSL capaz de remitir comandos al Host. En este punto podríamos crear una firma de Snort para identificar qué equipo tiene el agente instalado, pero perderíamos en este caso la dirección del cliente desde donde se intentan conectar, dado que la IP destino sería la de los servidores de LogMeIn (212.118.234.0/24, 64.74.103.0/24). Al margen de esto el NAT puede también jugarnos alguna mala pasada enmascarándonos la dirección origen.

A continuación cuando un cliente quiere conectarse a la máquina Host debe previamente autenticarse en el servicio de LogMeIn a través de sus correspondientes servidores. De esta manera esta compañía ya tiene por una parte una conexión SSL TCP establecida con la máquina Host y por otro lado una conexión SSL TCP con el Cliente, todo ello por el puerto 443 para así evadir posibles problemas de filtrado (no es https).

Por último y una vez autenticado en el servidor, éste informa a ambas partes de la dirección IP y puertos UDP que se utilizarán para la conexión directa entre HOST< -> CLIENTE. Para ello utilizan el sistema ya comentado en posts anteriores (TCP2UDP Firewall Bypassing). Desde este momento el server ya no participa en la comunicación y todo el tráfico se realiza entre los interesados de forma cifrada mediante un certificado autofirmado generado por openssl (binario en la propia carpeta de la aplicación) remitido desde el Host al Cliente. En este certificado tenemos lo que nos interesa entre otras cosas:

  • Dirección IP interna del Host
  • Dirección IP remota del Cliente
  • Nombre Netbios del equipo Host
  • Nombre de la empresa
  • Idioma

Con esto solo nos queda generarnos una firma de Snort, que aquí os dejo, para detectar ese intercambio.

alert udp any any -> any any (msg:"S2 Inicio de conexion a equipo con Logmein"; 
content:"Certificate issued by LogMeIn";nocase; classtype:policy-violation; 
sid:9900000; rev:1;)

Para finalizar me gustaría que la gente reflexionase sobre el uso de estas aplicaciones como LogMeIn y TeamViewer, a través de las que se le está dando acceso al core de tu red a un tercero cuya integridad desconocemos y que además en este caso al ser estadounidense no está sujeto a las restricciones de la legislación europea en protección de datos. Sin querer ser paranoico o conspirativo a organizaciones como la CIA o la NSA estos aplicativos les vienen como anillo al dedo. Eso al margen de que cualquier usuario con privilegios de administrador sobre su propio equipo pueda saltarse todas las políticas de seguridad de la organización. Ahí es nada.

Plan Estratégico de S2 Grupo

Antes de que mi jefe me pegue una patada en el culo a lo “Tio Phil”, me corte en pedazos y se haga una hamburguesa por revelar el Plan Estratégico Corporativo os voy a enseñar, para los que no la conocéis, la Web prezi.com. Este site permite realizar presentaciones muy atractivas visualmente mediante el uso desmesurado y frenético del zoom. Hasta ahí todo perfecto y bonito. El problema reside cuando un directivo de una super corporación quiere impresionar al consejo y realiza una presentación con información confidencial, de por ejemplo… el Plan Estratégico de la empresa 2012-2015. Tras terminar el diseño, el descuidado “encorbatado” no sabe que todas las presentaciones realizadas en la plataforma quedan expuestas al público si no se indica lo contrario, es decir se paga por el servicio Premium. A esto hay que sumarle la posibilidad de saber mediante el nombre y apellidos la persona que ha realizado el trabajo. Nuevamente el problema de seguridad no reside en una vulnerabilidad de la plataforma sino en el uso que los usuarios hacen de ella.

Esta Web puede ser un buen recurso a la hora de realizar la fase de “Information Gathering” dentro de un test de intrusión, ya que nos permite obtener nombres de usuarios e información de todo tipo, simplemente poniendo en su buscador el nombre de la entidad bajo análisis.

Os invito a realizar algunas búsquedas y cotillear un poco con cadenas como: “plan estratégico”, “resultados auditoría interna”, “consejo asesor”, “ministerio” y lo que la vuestra imaginación quiera.

(N.d.E. Aprovechando que mañana es el sorteo de Navidad y que el Pisuerga pasa por Valladolid, mañana publicaremos el Informe de Seguridad en Juegos Online 2011. Permanezcan en línea)

Lectura recomendada: Windows Sysinternals Administrator’s Reference

Pegando un vistazo a las presentaciones de la última Black Hat me sorprendió bastante la última de Mark Russinovich sobre “Zero Day Malware Cleaning with the Sysinternals Tools”. Mark ha incorporado mejoras notables en esta suite de herramientas gratuitas, para contribuir a la causa y profundizar un poco más en ellas, me animé a comprar el libro. En tan solo 23 páginas ya había amortizado los 31$ con cositas tan interesantes sobre estas tools y el sistema operativo de Microsoft, como las que paso a comentar.

En primer lugar Mark pasa a comentar aspectos generales del funcionamiento interno de Windows Vista, 7 y 2008 en cuanto al control de la autorización de seguridad. Cuando por ejemplo un usuario administrador se loguea en estos sistemas mencionados, se crean 2 tokens de sesión (creados por el LSA, Local Security Authority), uno con todos los privilegios y otro con los privilegios acotados. Este último se utiliza para crear los procesos iniciales userinit.exe y explorer.exe, así como los hijos de los mismos. Para ejecutar un proceso con el full token se requiere de una elevación UAC (User Account control), realizada por el servicio Aplication Information (Appinfo). Por lo tanto si queremos ejecutar por ejemplo un runas.exe con las credenciales de un administrador, deberemos tener en cuenta que se ejecutará con los privilegios de usuario estándar de esa cuenta. Solo hay una excepción y es el usuario administrador por defecto (que viene deshabilitado inicialmente). Por lo tanto se ha de especificar que se quiere ejecutar con permisos elevados, si queremos hacer algo que requiera privilegios más allá de un usuario normal. El modo de trabajo en UAC se puede deshabilitar y por lo tanto se vuelve al modelo de Windows XP (peligroso ya que incluso el Internet Explorer corre con máximos privilegios).

Otra curiosidad que comenta en cuanto a los procesos en Windows es que un proceso siempre registra el PID del padre, si este último muere el hijo no actualiza este registro, por lo tanto puede darse que otro proceso nuevo adquiera el PID de ese padre, pudiendo generar confusión. Este registro del proceso padre solo se hace por propósitos informativos.

Otra cosa interesante es que los hilos de un proceso pueden pasar de modo de ejecución user-mode a kernel-mode cuando necesitan realizar una operación en este nivel. Por ejemplo al leer un archivo del disco, la llamada al API de lectura de un archivo produce una transición a kernel-mode ejecutada por una instrucción de tratamiento especial que sitúa el modo de ejecución del entorno de procesamiento en kernel-mode. Entonces se produce, tras validar el acceso, la ejecución de la rutina de lectura de archivo, en este caso NtReadFile. Por último tan solo falta volver al modo de ejecución usuario. Es normal que un proceso de usuario se pase tiempo en kernel-mode y otro tiempo en user-mode. De hecho la mayoría de las aplicaciones gráficas pasan más tiempo en kernel-mode que en user-mode. Esto se puede ver con el process explorer en la gráfica de consumo de CPU (en color rojo kernel mode):

Otra cosa que me sorprendió de esta suite es la facilidad para ver los Strings de un proceso en memoria o en disco, muy útil si se quiere identificar malware. Un posible indicio de malware no solo es que presente cadenas sospechosas sino que esté comprimido el ejecutable con por ejemplo UPX. Para ello el processExplorer es capaz de marcar en color morado todos aquellos procesos que están comprimidos, lo que nos permite con tan solo abrir la aplicación obtener posibles candidatos a “bicho”.

En futuras entradas seguiremos comentando este fantástico libro 100% recomendable para los amantes de la seguridad.

Extra ball: ¿Sabían Vds que es posible montar una unidad de red con el conjunto de la suite con tan solo llamar a:

\\live.sysinternals.com\tools\ ?

Nuevo preprocesador de Snort Passive Port Discovery

(You can find the English version of this post clicking here, or scrolling down some paragraphs)

Desde hace algún tiempo hemos estado trabajando en el desarrollo de un preprocesador para la sonda de detección de intrusos de Snort capaz de aprender de una red el conjunto de activos que la conforman, así como los servicios que estos ofrecen, de una forma totalmente pasiva. Esta aproximación nos otorga la ventaja de poder obtener un mapeo de puertos sin interactuar con las máquinas del entorno. A su vez y dependiendo de la topología de red, esto nos permite obtener información de hosts sobre los que posiblemente no tengamos visión directa sobre ellos, bien porque estén desconectados o bien porque existen reglas de filtrado que no nos permitan llegar a ellos. Este puede ser el caso de una gran red donde gestionamos un Sistema de Detección de Intrusos basado en Snort, capaz de observar todo el tráfico de red, pero donde el segmento del equipo del administrador de seguridad carece de visibilidad sobre ciertas subredes de la organización. Otra de las capacidades es la de observar de forma rápida el conjunto de activos y servicios de nuestra red con tan solo consultar su base de conocimiento. Un ejemplo de la misma se muestra a continuación:

192.168.20.45:1310714459:2869
192.168.20.43:1310649818:22,23,80,81,111,113,139,389,445,901,8010
192.168.20.40:1310645266:22,80,81
192.168.20.38:1310656339:443,3389,139,445
192.168.20.30:1310714459:23,2869
192.168.20.21:1310649818:22,23,80,81,8010
192.168.20.15:1310645266:22,80,81
192.168.20.1:1310656339:443,3389

Si además de su funcionamiento de forma individual se procede a integrarlo con sistemas de correlación, podemos identificar casos donde:

1. Se detecta una alerta de intento de explotar una vulnerabilidad.
2. Se identifica un nuevo puerto abierto.

Este caso podría detectar la ejecución de forma exitosa de un exploit que abre un nuevo puerto bindeado a una Shell, como por ejemplo el típico payload de Metasploit bind_tcp al puerto 4444 o cualquier otro “custom exploit“.

Para llevar a cabo esta tarea de detección, el preprocesador utiliza una base de conocimiento que es alimentada durante los períodos de aprendizaje y alerta. Este primer período se define como el tiempo en el que el preprocesador recolecta la información de un host concreto antes de iniciar el proceso de notificación, de modo que para cada activo descubierto pasado su tiempo de aprendizaje, éste alertará de los nuevos servicios (TCP/UDP) descubiertos. Toda esta información es almacenada en memoria en una estructura de Arbol n-ario donde los nodos hoja son los encargados de almacenar los datos de cada dirección IP.

Por lo tanto el caso general presenta tantos hosts como nodos terminales existen en el árbol, para este ejemplo concreto tenemos 21 direcciones IP descubiertas, tales como 10.2.5.14 o 192.2.8.16, entre otras. Para desplegar el preprocesador se debe configurar el archivo snort.conf con los siguientes parámetros:

  • alert_host [Bool]: parámetro que activa la notificación de nuevos hosts descubiertos, toma valor 1 para activar o valor 0 para desactivar.
  • knowledgebase [archivo]: archivo donde se guardara cada “timing_knowledgebase” el conjunto de la base de conocimiento, es decir las IPs descubiertas y sus puertos.
  • timing_knowledgebase [tiempo]: período de tiempo en segundos por el cual el preprocesador guardará a disco la base de conocimiento.
  • training [tiempo]: valor en segundos del proceso de aprendizaje. Cuando una nueva IP es detectada en la red y pertenece al entorno de protección (típicamente $HOME_NET), se establece una marca de tiempo a partir de la cual comenzara a contar el timer de aprendizaje. Todo nuevo puerto descubierto en ese host no sera notificado (pero si aprendido) hasta que finalice el valor establecido en el parámetro training.
  • proto [TCP,UDP,TCP/UDP]: protocolo sobre el que trabajará el preprocesador, si tan solo se especifica TCP como protocolo entonces solo este tipo de paquetes serán procesados y notificados. Puede tomar los valores especificados entre [].
  • direccionamiento [IP,SUBNET]: listado de direcciones IP o subredes a proteger. Típicamente se utilizará la variable HOME_NET. Es posible especificar direcciones host (ej. 192.168.2.1) o subredes (192.168.2.0/24). El listado a de ser presentado entre [] y separado por comas en caso de no utilizar la variable $HOME_NET.

Un ejemplo de configuración podría ser el siguiente:

preprocessor pasive_port_discover: alert_host 1 \
                                    knowledgebase  /snort/etc/knowledgebase.txt \
                                    timing_knowledgebase 25200 \
                                    training 172800 \
                                    proto TCP \
                                    subnets $HOME_NET

Cualquier duda, comentario o sugerencia es bienvenida.


(English version follows)

We are working on a snort preprocessor with passive port discovery capabilities, able to learn the hosts and services from a network. This approach gives us a good way to construct a host-port map without interaction with the assets. Depending on the network topology this preprocessor will allow us to obtain host information that may not be directly visible, either because they are disconnected or because there are filtering rules that don’t allow us to reach them.

This may be the case in a large network where we manage an Intrusion Detection System based on Snort, which can observe all network traffic, but where the segment of the security administrator’s computer lacks visibility of certain subnets in the organization. Another capability is to look quickly at the set of assets and services of our network just checking their knowledge base. An example of the knowledge base is shown below:

192.168.20.45:1310714459:2869
192.168.20.43:1310649818:22,23,80,81,111,113,139,389,445,901,8010
192.168.20.40:1310645266:22,80,81
192.168.20.38:1310656339:443,3389,139,445
192.168.20.30:1310714459:23,2869
192.168.20.21:1310649818:22,23,80,81,8010
192.168.20.15:1310645266:22,80,81
192.168.20.1:1310656339:443,3389

In addition to their individual performance, we can to proceed to integrate it with correlation systems, identifying two facts:

1. An alert produced by an attempt to exploit a generic vulnerability.
2. The system Identifies a new open port.

The successfully execution of an exploit which opens a new port binded to a Shell, such as the typical Metasploit payload to port 4444 bind_tcp or any other custom exploit could be detected.
In order to perform this detection task, the preprocessor uses a knowledge base that is fed during periods of learning and notification. This first period is defined as the time during which the preprocessor collects information from a particular host before starting the notification process. Thus, when the learning period is finished for a given host, the preprocessor will report new services (TCP / UDP) discovered. All this information is stored in memory in a structure of n-ary tree where leaf nodes are responsible for storing data for each IP address.

Therefore the general case has as many hosts as there are terminal nodes in the tree, in this particular example we have 21 IP addresses discovered, such as 10.2.5.14 or 192.2.8.16, among others.
In order to deploy the preprocessor we must to configure the snort.conf file with the following parameters :

  • alert_host [Bool]: parameter that triggers notification of newly discovered hosts. Value 1 to enable or to 0 to disable.
  • knowledgebase [file]: The file where we will save each “timing_knowledgebase” the entire knowledge base.
  • timing_knowledgebase [time]: time interval in seconds between writes of the knowledge base to disk.
  • training [time]: seconds value for the learning process. When a new IP is detected on the network and it belongs to the protective environment (typically $ HOME_NET) the ip is stamped with the time stamp when the host was discovered. New ports discovered on that host will not be reported until the end of the value set in parameter training.
  • proto [TCP, UDP, TCP / UDP]: protocol on which the preprocessor will work, if only TCP is specified then only such packets will be processed and reported. Takes one of the values in [].
  • address [IP, SUBNET]: list of IP addresses or subnets to protect. Typically use the HOME_NET variable. You can specify host addresses (eg 192.168.2.1) or subnet (192.168.2.0/24). The list must be presented between [] and separated by commas if you do not use the variable $HOME_NET.

An example configuration file is as follows:

preprocessor passive_port_discover: alert_host 1 \
                                    knowledgebase  /snort/etc/knowledgebase.txt \
                                    timing_knowledgebase 25200 \
                                    training 172800 \
                                    proto TCP \
                                    subnets $HOME_NET

Opinions, doubts and comments are wellcomed.

TCP2UDP Firewall Bypassing

Fruto de los últimos tests de penetración que hemos realizado me gustaría compartir con nuestros lectores una herramienta que he desarrollado “Quick-and-dirty” en Python para entornos donde un cortafuegos está bloqueando el tráfico de inicio de conexión TCP de salida a Internet, pero no el UDP. El escenario propuesto se trata de un clásico caso de post explotación donde hemos conseguido ejecutar código como root en una máquina Linux del segmento de usuarios o de DMZ. El problema es que no podemos iniciar conexión de un terminal (telnet, ssh, vnc…) hacia nuestra máquina remota, ni tampoco dado que no hay NAT, desde el atacante al servidor comprometido. Pero gracias al “hábil” administrador del Firewall el tráfico UDP está permitido de salida.

En este momento es donde entra en acción nuestra herramienta, la cual ejecutada en el entorno conquistado, mapeará todos sus puertos TCP al interfaz localhost de la máquina del atacante. Es decir, para conectar a un servicio TCP de la víctima protegido por el Cortafuegos, el atacante tan solo tendrá que conectar a un determinado puerto de su propia interfaz localhost. Toda la comunicación entre el equipo comprometido y el de la víctima, se realizará mediante paquetes UDP, obteniendo un resultado de transformación TCP2UDP. Al comenzar a remitir paquetes de este tipo desde la red interna de la víctima hacia el atacante, el Firewall actualizará su registro interno de “conexiones” UDP abiertas, dejando pasar el paquete de inicio de comunicación hacia el entorno comprometido, debido a la capacidad “conectionless” del protocolo UDP.

La herramienta hace uso de las aplicaciones “packit”, para mantener la comunicación cliente-servidor abierta y la gran “socat”, para la redirección de puertos sin utilizar “fifos”. La gran desventaja de esta herramienta tcp2udp es que todavía no trabaja en entornos Windows (próxima versión en curso). Ésta nos puede ser útil si por ejemplo la ejecución de código remota se ha realizado a través de una vulnerabilidad en una web, o necesitamos mapear servicios internos de la máquina al exterior. Espero os sea útil como lo fue para mí, happy hacking!

Pueden descargar la herramienta desde este enlace: tcp2udp.tar.gz

Recopilación Local File Inclusion LFI

Este post no pretende ser una introducción o revisión exhaustiva de las vulnerabilidades de inclusión de código local o remoto. Por el contrario sí opino que la información concretamente de la explotación de un LFI se encuentra repetida hasta la saciedad, así como cada investigador ha aportado de forma dispersa pequeños trucos que amplían el espectro de explotación. Por lo tanto, creo que es interesante realizar una recopilación de estas mencionadas artimañas para conseguir el control de una máquina, permitiendo ésta la inclusión de código de forma local. Algunas de ellas son bastante conocidas, pero por el contrario, durante el trabajo de recopilación he dado con varias que desconocía y que me han sorprendido.

Muy brevemente comentaremos el punto de partida: un servidor Web que por ejemplo presenta una inclusión de código no sanitizada o filtrada correctamente. Aislando el código podría ser lo siguiente:

<?php
$param = $_GET[‘PARAM’];
include( $param . ‘.php’ );
?>

[Read more…]

Saltando el bloqueo de iPhone (y van 2)

(N.d.E. Para que no se aburran durante este largo fin de semana, aquí va una entrada de Roberto calentita calentita.)

Hace escasos días surgía la noticia de la posibilidad de saltar el código de bloqueo de los dispositivos iPhone con IOS 4.1 a través de las llamadas de emergencia, permitiendo realizar llamadas a cualquier número. El escándalo saltaba nuevamente, y los “antimaqueros” tenían una nueva excusa para demonizar al gigante de Jobs y los usuarios amantes de “la Manzana”, entre los que se encuentra un servidor, sonreíamos resignadamente ante las burlas de estos.

Pues bien, para quitar hierro al asunto y aunque como profesional de la seguridad me parece una gran pifia por parte de los desarrolladores de Apple, os voy a presentar una segunda manera de poder realizar llamadas a cualquier número con el bloqueo de código activado. Este método hace uso del control por voz de nuestros terminales, de esta manera y con el dispositivo bloqueado tan solo tenemos que dejar presionado el botón de Home durante un par de segundos y activar el reconocimiento de audio. Acto seguido tan solo tenemos que pronunciar el comando “llamar” y el número de teléfono que queramos, por ejemplo “llamar 555 34 43 34”.

Como aspectos negativos de esta funcionalidad nativa del terminal cabe destacar que gran parte de los usuarios no la utilizan o ni siquiera saben que existe, a ello hay que añadir su principal problema y es que viene activada por defecto cuando se adquiere el dispositivo. ¿Debería Apple desactivar esta funcionalidad, al menos por defecto, dejando la posibilidad de activarla al usuario? La respuesta a esto se la dejamos a los lectores.

Por último y como buena noticia comentar que es posible deshabilitar su uso cuando el terminal está bloqueado en Ajustes-> General -> Bloqueo con código -> Marcación por voz.

Black Hat Europa, 2 day briefings

En su segundo día, la Black Hat Europa comenzó con la presentación de Thai Duong y Juliano Rizzo sobre Crypto ataques a aplicaciones web. Su investigación se ha dirigido a cryptoanalizar el modo de cifrado por bloque Cipher-Block Chaining. CBC fue inventado por IBM en 1976. En este cifrado, a cada bloque de texto plano se le aplica una operación XOR con el resultado del bloque anterior. De esta manera el resultado de un módulo es dependiente de los anteriores, excepto para el primero que se utiliza un vector de inicialización IV. La siguiente imagen es muy ilustrativa:

El tamaño de bloque suele ser de 8 bytes con un cifrado DES/triple DES o 16 bytes para AES. Por lo que respecta a la clave de cifrado se utiliza 56 bits para DES, 168 bits para triple DES y 128, 192 o 256 para AES. Pero, ¿qué ocurre si el último bloque de texto plano no es del tamaño requerido? Pues que es completado con información arbitraria, normalmente 0’s por seguridad. Esta última afirmación es justamente una de las debilidades del sistema.

Thai Duong y Juliano Rizzo presentaron el ataque Padding Oracle, el cual requiere que el atacante pueda interceptar mensajes con padding y a su vez tenga acceso al sistema que lo comprueba a modo de oráculo. El proceso que un atacante podría realizar para comprobar si el rellenado de bits es correcto es el siguiente:

  • Se remite la cadena cifrada al oráculo.
  • El oráculo mediante la clave de cifrado comprueba si es correcto el padding
  • El oráculo contestará al atacante con un 0 si es incorrecto o un 1 si es correcto.

Si el lector quiere ampliar conocimientos en cuanto al proceso completo recuperación de la trama de bytes original puede consultar su paper, disponible online.

Como caso práctico de implementación del ataque, Thai y Juliano presentaron la rotura de un captcha que utiliza este modo de cifrado. El sistema utiliza CBC para albergar el texto detrás de la imagen difuminada, lo que han denominado ERC.

<img src=”/captha?token=ERC”/>

El ERC se guarda en un campo oculto del formulario o en una cookie. Cuando el usuario remite el código introducido por teclado, el servidor compara la cadena con el resultado de descifrar el ERC. Si son iguales el resultado del captcha es correcto. De esta forma el servidor que recibe el ERC es susceptible a ataques de Padding Oracle siempre y cuando respondan ante rellenados de bits incorrectos. En la mayoría de sistemas, cuando se modifica el ERC y el rellenado es correcto el servidor devuelve una imagen con un código difuso, pero el problema viene cuando el servidor ha inicializado el IV con información aleatoria dificultando la obtención de P0. Para solventarlo, Thai y Juliano proponen obtener P0 y el IV de una imagen introducida por un usuario normal.

Otros sistemas que utilizan CBC e identificados por los autores del ataque, son las View States de JavaServer Faces. Nuevamente, un 10 para estos chicos.

Black Hat Europa 1 day briefings (IV)

La BH Europa, en general nos ha dejado muy buen sabor de boca, aunque no todo fueron peritas en dulce. La única nota negativa la trajo James Arlen, que a través de un seductor titulo SCADA and ICS for Security Experts tuvo a la audiencia expectante, esperando las últimas novedades sobre seguridad SCADA. Nada mas allá de la realidad, detrás de un gran orador —todo hay que reconocerlo— la conferencia no aportó novedad alguna, vertiente técnica, o aplicación interesante.

Por el contrario, Manish Saindane de Attack and Defense Labs acudió con una propuesta sobre como atacar aplicaciones que utilizan objetos serializados en Java. Manish ha desarrollado un plugin para Burp que permite al Pentester editar objetos Java on the fly. La serialización de objetos Java es un protocolo implementado por Sun para convertir objetos en tramas de bytes, con el objetivo de guardarlos en disco o transmitirlos por la red. Este flujo de datos contiene la suficiente información para reconstruir el objeto original. A título informativo, la clase que puede instanciar objetos de este tipo son ObjectOutputStream y ObjectInputStream, cuyos métodos serializables son: readObject(), writeObject().

Cuando un objeto serializado es transmitido por la red se puede identificar por su cabecera con los bytes 0xac 0xed, aunque es posible que viaje comprimido en formato zip. Si el objeto es de tipo String, por ejemplo, éste vendrá codificado en UTF-8 modificado. El ataque funciona de la siguiente manera:

[Read more…]

Black Hat Europa 1 day briefings (III)

Continuando con la crónica de la BH Europa que estamos realizando estos días, en la cuarta exposición Paul Stone de Context (empresa de seguridad del Reino Unido) vino con una propuesta muy interesante sobre nuevas técnicas de ClickHacking, presentándonos una nueva herramienta que permite implementar este tipo de ataques. Destacar que ésta se puede descargar y juguetear con ella.

El ClickHacking es un término relativamente nuevo (sobre 2 años), que básicamente consiste en hacer que el usuario pinche (clickee) en cierto contenido oculto a través del uso de iframes, permitiendo a un atacante realizar acciones como un usuario lícito. Un ataque típico contra versiones de Flash antiguas permitía a un usuario mal intencionado tomar el control de la cámara y el micrófono de la víctima habilitando la configuración de seguridad.

Este tipo de nuevas técnicas presentan las siguientes características:

  • Se evita la protección Anti-CSRF
  • Se inyectan Clicks no datos
  • No funciona el ataque si la distribución de la página cambia
  • Requiere de la interacción con el usuario
  • Se puede evitar con Anti-Framing

Pues bien, vamos a ver un ejemplo de cómo utilizar esta fantástica herramienta, aunque para aquellos interesados, nada mejor que probar la aplicación directamente. En primer lugar cargamos el Framework abriendo con el navegador el recurso cjtool.html. En el frame izquierdo tenemos el menú de acciones y en el derecho el entorno de acción.

En el cuadro de texto URL introducimos la dirección de la página que queremos que interactúe con el usuario de forma oculta. En el marco derecho por tanto y tras pinchar en “Go”, identificamos los campos donde queremos inyectar el Click. En este caso vamos a hacer la prueba con un entorno phpLDAPadmin. Nuestro objetivo será que cuando el usuario realice un primer Click se rellene el campo contraseña con un valor arbitrario, y en una segunda pulsación del ratón se producirá un evento sobre el botón enviar. Este ejemplo es meramente ilustrativo de cómo utilizar la herramienta, ya que no se pretende autenticarse con las credenciales del usuario legítimo. Un escenario real donde se pudiera aprovechar esta vulnerabilidad sería por ejemplo, un site bancario donde el atacante mediante una serie de acciones sobre la página pudiera completar una transacción bancaria a favor del atacante.

Volviendo al ejemplo, en el menú izquierdo encontramos las acciones que se pueden “programar” sobre la página: Cargar URL, hacer un Click, introducir texto, arrastrar contenido, o extraer contenido. Introducimos en primera instancia una cadena de texto arbitraria en el campo contraseña. Hacemos click en Enter Text, arrastramos la cruz verde desde el menú izquierdo al campo contraseña del frame derecho, y por último introducimos la cadena deseada.

Lo siguiente es establecer la acción de presionar sobre el botón “Entrar”. Pulsamos sobre el botón “Click” y nuevamente arrastramos la cruz sobre “Entrar”.

Una vez establecidas las acciones que queremos que realice el usuario, podemos simularlo con Replay Steps. Inmediatamente en el marco derecho vemos como el puntero se sitúa sobre el campo contraseña movamos donde movamos el ratón. Tras hacer click, la cadena programada es copiada en el formulario, pasando el puntero nuevamente al botón “Entrar”. Una última pulsación permite entrar en la aplicación sin que el usuario lícito se entere.

Sin ninguna duda, un gran trabajo de Paul Stone y el equipo de Context, ¡un 10!