Ayer S2 Grupo entregó los premios al primer concurso de criptografía organizado por la ETSINF de la Universidad Politécnica de Valencia y patrocinado por esta casa, en el marco de las actividades propuestas para el Año Turing.

La amplia participación y el interés del alumnado fue muy alto, llegando a presentar resultados más de 50 estudiantes. Los criptogramas de Vigenère divididos en cuatro bloques de dificultad con cuatro retos cada uno propuestos por el profesorado de la ETSINF, fueron resueltos en menos de un día, demostrando el alto nivel de los participantes.

S2 Grupo, de la mano de nuestro director de seguridad Antonio Villalón y un servidor entregaron a los ganadores su bien merecido premio, un iPad para el primer clasificado, Salvador Arnal Julián y sendos iPods para el segundo clasificado, Rafael Boix Carpi y terceros, Vicent Selfa Oliver y Eduardo Pablo Novella Lorente.

Agradecer por último el interés mostrado por los participantes y el esfuerzo de la ETSINF en todas las actividades que están realizando para conmemorar el centenario de este Año Turing 2012. Para el año siguiente ya se está barajando la posibilidad de organizar un reto hacking que ponga a prueba las habilidades de los alumnos de esta escuela, por el momento enhorabuena a los premiados por su esfuerzo.

Recopilando nuevas tendencias e investigaciones sobre detección de intrusos, existe lo que se denomina ABAIS o Sistemas Inmunes Basados en Agentes Artificiales. Este tipo de sistemas tratan de emular las defensas del cuerpo humano para ofrecer una solución técnica que permita no solo identificar posibles intrusos en un sistema sino incluso acabar con ellos. Existe numerosa bibliografía detrás de este concepto, que comenzó a principios de la pasada década con Harmer P.K.

Como concepto derivado de un BIS o Sistema Inmune Biológico, los trabajos han sido orientados al seguimiento básicamente de tres paradigmas:

• La Selección Negativa
• Clonación Selectiva
• La teoría de la señal de riesgo

[Read more…]

Hoy comienza el reto de criptografía organizado por la Escuela Técnica Superior de Ingeniería Informática de la Universidad Politécnica de Valencia y patrocinado por S2 Grupo.

La prueba en la que participan alumnos de Ingeniería Informática de esta Universidad, está enmarcada dentro de las actividades propuestas para del Año Turing. Las bases de la competición las podéis encontrar en el siguiente enlace; los alumnos deberán resolver doce criptogramas dentro de cuatro niveles de dificultad diferentes, donde todos ellos han sido cifrados mediante el algoritmo Vigenèrè. El cifrado de Vigenère es un cifrado de sustitución simple polialfabético, basado en el clásico Cesar y muy amigo de Friedrich Kasiski ;)

Para dar como válida cada solución, se deberá entregar tanto el texto en claro como la cadena de cifrado. Para aquellos crackeadores de códigos que aporten la solución en el menor tiempo posible, S2 Grupo como patrocinador, aportará los siguientes premios:

1º: iPad 2, WIFI 16GB
2º: iPod nano 8GB
3º: iPod shuffle

Los sufridos regalos serán entregados a finales de este mismo mes en las instalaciones de la ETSINF.

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.

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)

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\ ?

(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:

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:

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.

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

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:

[Read more…]

(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.