Search Results for: análisis forense

El segundo día de este congreso comenzó de la mano de Jose Luis Verdeguer (@pepeluxx) y Victor Seva (@linuxmaniac), que en su charla “Secure Communications System” concienciaron a los presentes de que en un sistema de comunicación, aunque las transmisiones se cifren de extremo a extremo siempre pueden haber mecanismos que permitan realizar técnicas de tipo “man-in-the-middle”, por lo que no es recomendable confiar en infraestructuras de terceros si la privacidad es crucial. Como colofón, presentaron un sistema de comunicaciones libre, basado en VOIP, en el que prima la seguridad, y que estará disponible para su descarga en breve.

A continuación, Joaquín Moreno (@MoxilO), ex-compañero de Security Art Work, realizó una densa charla sobre forense en Mac OS X titulada “Forense a bajo nivel en Mac OS X”. El trabajo realizado por Joaquín es parte de su tesis de máster, y además, prometió publicarlo en cuanto lo presentase, por lo que los interesados podremos asimilar de manera más tranquila todos los conceptos presentados en el breve tiempo del que dispuso. Además, Joaquín está implementando su trabajo a modo de complementos para Plaso, una herramienta para generar líneas temporales cuando se realizan análisis forenses.

Tras un breve descanso en el que pudimos disfrutar de las ya tradicionales conchas Codan, Jorge Ramió (con el que tuvimos una entrevista en Security Art Work), reconocido criptógrafo y profesor de la UPM, realizó una charla denominada “RSA cumple 36 años y se le ha caducado el carné joven” donde tras una breve introducción al algoritmo de cifrado RSA, explicó cómo éste ha sido capaz de afrontar sus 36 años de existencia mediante el aumento de la cantidad de bits necesarios para generar las claves criptográficas. No obstante, Ramió también mostró técnicas de “crackeo” independientes de la longitud de clave y del algoritmo. Estas técnicas, conocidas como ataques de canal lateral consisten, por ejemplo, en escuchar el sonido que emiten los sistemas al realizar los cálculos, o medir la potencia eléctrica que consumen para así poder recuperar la clave criptográfica y poder descifrar los datos.

En la siguiente charla, José Luís Quintero y Félix Estrada, Centro de Operaciones de Seguridad de la Información del Ministerio de Defensa (COSDEF), dieron una charla sobre ciberguerra titulada “Ciberguerra. De Juegos de Guerra a La Jungla 4”, que como su título indica, fue amenizada con referencias a clásicos del cine como Juegos de Guerra.

A continuación, Jeremy Brown y David Seidman, de Microsoft, iban a presentar su charla “Microsoft Vulnerability Research: How to be a finder as a vendor”. No obstante, al no poder asistir David Seidman, fue Jeremy Brown quien finalmente dio un repaso a los programas de compensación para los investigadores de seguridad que deciden colaborar con Microsoft.

Antes del descanso, Chema Alonso (@chemaalonso) habló sobre su ojito derecho, Latch, en una charla titulada “Playing and Hacking with Digital Latches”. Como muchos ya sabréis, esta herramienta permite definir a los usuarios si pueden acceder, o no, a sus redes sociales. De este modo, se garantiza que si un usuario no requiere acceder a un recurso, nadie más puede hacerlo empleando su cuenta.

Tras un breve descanso, Miguel Tarasco presentó AcrylicWifi en su charla “Análisis WiFi de forma nativa en Windows”. AcrylicWifi es una herramienta de análisis de seguridad y monitorización de redes inalámbricas para sistemas Windows desarrollada por Tarlogic. A su vez, Andrés Tarasco presentó en “Ataques dirigidos con APTs Wi-Fi” el protocolo WXP (Wireless exfiltration Protocol), cuyo fin es el de comunicar los sistemas afectados por un APT con su Command & Control a través de los probe request y probe response de la tecnología WiFi.

Roberto Baratta (@RoberBaratta), dio consejos sobre cómo mejorar la seguridad informática con un presupuesto casi nulo en su charla “Monetización de la seguridad”. La última charla del día vino de la mano de César Lorenzana y Javier Rodríguez (@javiover) del Grupo de Delitos Telemáticos de la Guardia Civil (@GDTGuardiaCivil), exponiendo un caso de éxito en su ponencia “Por qué los llaman APT cuando lo que quieren decir es dinero” detallaron un caso que resolvieron sobre APTs.

En múltiples ocasiones hemos hablado en este blog de tshark como herramienta de análisis forense de red. Esta herramienta proporciona una versatilidad que se va ampliando con cada nueva versión, donde se le añaden nuevos filtros y mejoras.

Supongamos que nos encontramos analizando un incidente de seguridad en el que tenemos tráfico hacia varios servidores ubicados detrás de una misma dirección IP. Debido a esto, no se puede filtrar por dirección IP así que hay que buscar otra solución. En este artículo voy a mostrar una manera de extraer únicamente aquellos paquetes que están relacionados con un servidor (host) y no con una dirección IP.

Para ilustrar el ejemplo voy a utilizar un archivo de captura de tráfico en formato PCAP descargado desde NETRESEC de una máquina infectada con W32/Sdbot, proporcionado por Russ McRee.

Cuando estamos analizando tráfico hacia un servidor web podemos ver los paquetes enviados por el cliente utilizando el filtro “http.host==” (p.e, http.host==www.age.ne.jp):

El problema es que únicamente se muestran los enviados hacia el servidor, ya que se basa en el parámetro Host de la cabecera HTTP. En el caso en el que queramos capturar también la respuesta podremos utilizar el filtro tcp.stream pero debemos hacer un paso previo; para ello recordaremos este filtro.

El filtro “tcp.stream” es un valor que tshark asigna a los paquetes en función del flujo TCP al que pertenecen, así aquellos paquetes que formen parte de una misma conversación o flujo TCP tendrán el mismo valor.

La idea que pretendemos llevar a cabo es identificar los flujos TCP que vayan dirigidos al host que queremos para, posteriormente, extraer todos los paquetes que sean de esos flujos TCP, no sólo las peticiones HTTP.

Primero listamos el flujo TCP de los paquetes dirigidos al host:

Ahora un poquito de Kung-Fu, y listo:

Lo que se ha hecho en la captura anterior es obtener el mismo listado y realizar otra búsqueda utilizando el filtro tcp.stream con esos valores, por tanto recorremos el archivo un número de veces igual al número de flujos anterior y creamos un archivo (stream{n}.pcap) por cada uno de ellos. Finalmente, se fusionan en un único archivo PCAP con mergecap, llamado www_age_ne_jp.pcap.

Para ver que no sólo tenemos las peticiones al servidor sino también las respuestas de éste, mostramos el contenido del archivo:

Para comprobar que las peticiones son hacia el servidor que queremos mostramos únicamente los campos de dirección IP origen y destino, el host al que va dirigida la petición HTTP y el flujo TCP al que corresponden (el valor tcp.stream varia porque es relativo al propio archivo PCAP, no obstante se puede comprobar que el número de flujos es el mismo):

Por último, como nota añadida a esta manera de extraer aquellos paquetes que nos interesan, recalcar que el archivo se procesa un número de veces igual al de flujos que devuelva la operación anterior. Esto, si el archivo con el que estamos trabajando es muy pesado, puede sobrecargar el sistema.

Para evitar esto, en lugar de utilizar el filtro para un único flujo, se encadenan todos los filtros con un OR y así sólo procesamos el archivo una única vez, aunque se hagan más comprobaciones.

Mientras que el tiempo para ejecutar el comando de la primera manera es:

Quizá éste archivo no sea el mejor ejemplo ya que su tamaño es pequeño, aunque se puede apreciar que se reduce en más de una quinta parte el tiempo real de proceso.

Por experiencia propia, en una búsqueda similar en un archivo de 4 GB la diferencia está entre tres minutos para su ejecución con la primera opción, y no terminar tras más de una hora con la segunda.

Espero que os sirva para futuras búsquedas.

En ocasiones, en el transcurso del análisis forense de un sistema Windows, puede resultarnos de utilidad conocer el nivel de parcheado del equipo que estamos analizando. En la presente entrada veremos cómo llevar a cabo esta tarea con ayuda de la herramienta Microsoft Baseline Security Analyzer (MBSA).

Cabe aclarar que esta herramienta se aplica sobre sistemas en ejecución (“en vivo”), y no sobre imágenes offline del sistema de ficheros, por lo que en primer lugar será necesario levantar una copia de la máquina objeto del análisis forense. A tal efecto podemos utilizar herramientas como Live View (que nos permitiría desplegar una imagen del disco duro de la máquina obtenida, por ejemplo, con el comando dd, en forma de máquina virtual) o Clonezilla (con la que podríamos obtener una imagen del disco duro del equipo analizado, que luego podríamos desplegar en una máquina virtual u otra máquina física), entre muchas otras opciones.

En lo que sigue, asumiremos que ya tenemos lista y en ejecución esta copia del equipo a analizar. Puesto que el supuesto de partida es que estamos llevando a cabo un análisis forense, asumiremos que tampoco podemos conectar esta copia del equipo a Internet, de modo que utilizaremos el programa MBSA de una forma completamente offline.

Podemos descargar MBSA, en su versión 2.3, a través del siguiente enlace:

http://www.microsoft.com/en-us/download/details.aspx?id=7558

El programa no requiere ningún componente extra (como .NET) y se instala a través del típico asistente, sin mayores complicaciones:

Tras iniciar el programa, llevaremos a cabo un primer escaneo de prueba sobre el equipo, a través de la opción “Scan a computer”:

El objetivo de este primer análisis, que no podrá completarse correctamente, es que MBSA genere los directorios donde almacena la caché con el catálogo de actualizaciones de Windows. Para la versión 2.3, este directorio es "Configuración local \ Datos de programa \ Microsoft \ MBSA \ Cache" (a partir del perfil del usuario administrador con el que estemos ejecutando la herramienta) y, puesto que vamos a llevar a cabo todo el proceso con la máquina que estamos analizando desconectada de Internet, será necesario descargar el catálogo de Windows Update (Microsoft lo denomina “archivo de examen sin conexión”) desde otra máquina y copiarlo a la anterior ruta.

Podemos descargar este archivo (su nombre es wsusscn2.cab) a través del siguiente enlace:

http://go.microsoft.com/fwlink/?LinkId=76054

A continuación, lo copiamos en el directorio caché de MBSA:

En sistemas realmente desactualizados, podría suceder que la versión del agente de Windows Update sea tan vieja que MBSA no pueda llevar a cabo el análisis. En este caso, el programa presenta el siguiente mensaje de error: “Computer has an older version of the client and security database demands a newer versión. Current version is and minimum required version is…”, tal como puede observarse en la siguiente captura:

Si la máquina estuviera conectada a Internet, el propio MBSA actualizaría el agente de Windows Update, pero en nuestro caso deberemos descargar el instalador desde otra máquina e instalarlo en el equipo sobre el que estamos llevando a cabo el análisis forense. Microsoft documenta este procedimiento en el siguiente artículo:

http://technet.microsoft.com/en-us/library/bb932139.aspx

Para sistemas x86, podemos descargar el instalador desde la siguiente URL:

http://go.microsoft.com/fwlink/?LinkID=100334

De nuevo, la instalación se lleva a cabo vía asistente y no presenta mayores complicaciones:

Una vez contamos con una versión reciente del agente de Windows Update, ya podremos lanzar la herramienta contra el catálogo de actualizaciones que hemos descargado. Podemos marcar las opciones de escaneo de interés (en nuestro caso “Check for security updates”) y llevar a cabo el análisis:

Este sería el resumen de resultados para un equipo Windows XP SP3 “dejado caer”, sin ningún parche aplicado:

Mediante la opción “Result details” podemos obtener el detalle de los parches concretos que no han sido aplicados:

También podemos copiar los resultados del análisis en el portapapeles (opción “Copy to clipboard”) y guardarlo en un fichero de texto, que luego podremos utilizar para la confección del informe forense:

Por último, cabe señalar que el programa también cuenta con interfaz de línea de comandos, con la que podemos lanzar los análisis de forma automática con las opciones requeridas:

Esperamos que la entrada haya resultado de vuestro interés.

De un tiempo a esta parte muchos de los ataques que sufren los portales web se materializan en peticiones POST. Inyecciones SQL, inclusión de ficheros remotos o envenenamiento de parámetros son sólo algunos de los ataques en los que intervienen peticiones POST.

El problema es que por regla general la información de las peticiones POST no se guarda en los logs, por lo que al hacer un análisis forense a un equipo atacado, generalmente nos falta información para poder esclarecer el origen del compromiso o la información que se ha podido ver comprometida.

Por ello vamos a ver, centrados en el servidor web Apache, las posibilidades que existen para guardar el contenido de las peticiones POST que se hacen a nuestro servidor web.

[Read more…]

Los Indicadores de Compromiso (IOCs) (de los que ya hablamos en el informe Detección de APTs) son una tecnología que está teniendo un gran auge en los últimos años y que consiste en utilizar XML Schemas para describir las características técnicas de una amenaza por medio de las evidencias de compromiso que la misma deja en el equipo comprometido tras la infección: procesos, entradas de registro, ficheros descargados, etc.

La empresa Mandiant ha desarrollado un framework open-source, llamado OpenIOC que nos permite a través de dos tools (IOC Editor e IOC Finder), desde describir de forma semántica el comportamiento del malware/APTs por medio de ficheros XML (IOC Editor) hasta utilizar los mismos para buscar signos de infección en una máquina sin necesidad de llegar a realizar un análisis exhaustivo de la misma para identificar el tipo de amenaza (IOC Finder).

Con IOC Editor podemos definir una gran cantidad de características y además posee una interfaz de edición muy intuitiva para crear nuestros ficheros IOC:

De lo que se trata al definir un fichero IOC es de buscar por ejemplo localizaciones específicas en el sistema de ficheros, registro u otras partes del SO que habitualmente sean usadas por malware, buscar rastros que pudieran haber dejado herramientas usadas por los atacantes, señales de actividad de los intrusos sobre los sistemas que indiquen movimientos laterales que muestren un comportamiento anormal del usuario…etc. Lo ideal es buscar datos muy concretos para evitar falsos positivos. En definitiva, la definición de IOCs permite a las organizaciones definir piezas de inteligencia de amenazas de una manera estandarizada. Los ficheros IOC al estar definidos bajo un mismo estándar son más fáciles de intercambiar para compartir información entre la comunidad. Así, sitios como http://iocbucket.com/, http://ioc.forensicartifacts.com/ o los propios foros de Mandiant pueden sernos de gran ayuda para encontrar determinados IOCs o compartir los que nosotros hayamos creado.

Un extracto de una fichero IOC (elaborado por AlientVault) sería por ejemplo el que muestra la siguiente figura correspondiente a la APT Red-October. Con esta plantilla y con la ayuda de IOC Finder se podría localizar indicios del Red-October en nuestras máquinas.

Con IOC Finder, a través del parámetro “collect” se recopilará un conjunto de datos (procesos, entradas de registro,etc.) en el equipo sospechoso y los irá almacenando en forma de ficheros XML (crea hasta 50) en un directorio que crea “audits” para tal fin. Así si ejecutamos en el equipo por ejemplo:

>mandiant_ioc_finder.exe collect -o /INDICADORES

Nos generará los ficheros XML correspondientes (proceso que puede tardar horas) y los copiará en la ruta /INDICADORES que le indicamos con el parámetro -o (para más información sobre los parámetros ver guía del usuario de IOC Finder). Una vez este proceso ha finalizado a través del parámetro “report” procederemos al procesamiento de esos ficheros XML por el que se buscarán los patrones de infección que queremos localizar con ayuda de los ficheros IOC de los que dispongamos o hayamos definido. Así por ejemplo si ejecutamos:

>mandiant_ioc_finder.exe report -s ./INDICADORES/audits -i FICHEROXML.ioc -t html

nos indica que la fuente de nuestros datos (-s) está en la ruta /INDICADORES/audits, que buscamos los patrones de infección definidos en FICHEROXML.ioc y que el informe de resultados nos lo muestre en formato html (-t). Un ejemplo de uno de esos informes de salida extraído de este artículo de Mandiant se muestra a continuación:

Los IOCs representan una manera eficiente y rápida para identificar y definir amenazas avanzadas que de otra forma resultarían muy complejas de evidenciar y que, en algunos casos, pasarían inadvertidas por sistemas AV o HIDS. Hay que considerar por tanto su uso para analizar equipos que muestren comportamientos extraños como por ejemplo aquellos que presentan patrones de tráfico poco comunes.

Si adquirimos soltura definiendo IOCs pueden ser de gran efectividad en el ciclo de vida de una investigación ante un incidente de seguridad.

El proceso sería el siguiente: tras una evidencia inicial de un equipo/s comprometidos se investiga vía análisis forense cual es el IOC de la intrusión y se crea. Una vez creados se despliega en nuestros sistemas o redes objetivo para buscar la existencia de este IOC en otros sitios. Si se identifican nuevos sistemas sospechosos se recolectarán estas nuevas evidencias que tras analizarlas nos ayudarán a identificar más en profundidad la intrusión, descartar falsos positivos,etc, que nos ayudarán a refinar y crear nuevos IOCs de forma que volvemos a iniciar el círculo hasta que creamos haber recopilado toda la información necesaria.

Este proceso puede ser muy lento si tenemos que ir equipo por equipo ejecutando el IOC Finder así que dependiendo de la infraestructura que haya o diseño de la red podemos pensar en automatizar este proceso ayudándonos de ciertas infraestructuras.

Por ejemplo, imaginemos que nuestras máquinas forman parte de un Active Directory (AD) por el cual podemos administrar los inicios de sesión en los equipos conectados a la red, establecer políticas por ejemplo a determinadas Unidades Organizativas (OU), grupos de usuarios, desplegar programas en muchos equipos, etc. Podríamos valernos de diversos métodos que podemos implementar con dicho AD para automatizar el proceso de recolección de IOCs en varios equipos.

Así pues, supongamos un escenario ficticio en el que tenemos un Controlador de Dominio “midominio”, del que forman parte varias OU (Departamento 1, Departamento 2, etc). Dentro de esas OU tenemos varios equipos y usuarios sobre los que podemos realizar de manera centralizada ciertas acciones (lo recomendable es tener equipos y usuarios en OU diferentes pero para comodidad de las pruebas lo he establecido así):

Supongamos por ejemplo que dentro de mi Departamento 1 se ha encontrado una máquina comprometida, la he analizado y he creado mi IOC y quiero comprobar en todas las máquinas de ese mismo departamento si hay alguna otra que presenta ese mismo IOC valiéndome del IOC Finder.

Con el AD podemos hacer, entre otras acciones, lo siguiente:

• Asignar vía GPO scripts de inicio y apagado del equipo: Cada vez que el equipo se encienda/apague se ejecutarán los scripts que le hayamos asignado. Lo hará con privilegios de la cuenta System.
• Asignar vía GPO scripts de inicio y cierre de sesión del usuario: Cada vez que el usuario inicie/cierre sesión se ejecutarán los scripts que le hayamos asignado. Se ejecutará con los permisos del usuario en cuestión, por lo que habitualmente habría que darle permisos de Administrador.
• Asignar directamente al perfil del usuario/s el script que queramos que se ejecute al inicio. Lo hará con los privilegios que cuente el usuario, por tanto habría que darle permisos de Administrador normalmente.

Así pues supongamos que —por poner un ejemplo— podemos crearnos un vbscript, recolector.vbs que nos llame a nuestro mandiant_ioc_finder.exe y al cual le indicamos que nos copie todos los ficheros XML resultados en una ubicación compartida a la que los usuarios/equipos lleguen y tengan permiso de escritura. Habitualmente en muchas organizaciones se puede utilizar por ejemplo el servidor del AV —al que los equipos tienen acceso para actualizaciones y similares— creando una carpeta para tal fin, yo he llamado “indicadores” a esta carpeta. Grosso modo, de manera muy simple, nuestro vbscript podría ser contener líneas similares a las siguientes:

Set WshShell = WScript.CreateObject(“WScript.Shell”)
WshShell.run(“mandiant_ioc_finder.exe collect -o //10.0.0.3/indicadores”)

En este caso incluiremos el mandiant_ioc_finder.exe en la misma ubicación que recolector.vbs.

Si optamos por la opción de crear una GPO vinculada a mi OU=Departamento 1 para que recolector.vbs sea ejecutado al inicio de sesión del usuario los pasos a seguir serían los siguientes (para asignar el script al inicio/apagado del equipo los pasos son similares, he escogido por comodidad que se ejecutara al inicio de sesión del usuario):

1. Dejo mandiant_ioc_finder.exe y recolector.vbs en el recurso compartido NETLOGON de mi controlador de dominio u otra carpeta compartida de dominio.

2. Me sitúo sobre la OU sobre la que quiero aplicar la directiva en cuestión, en este caso Departamento 1, y presiono boton derecho del ratón para desplegar el cuadro de diálogo de Propiedades, en el que me dirigiré a la pestaña Directiva de grupo y pulsando en Nuevo crearé un vínculo de objeto de directiva de grupo al que le he llamado “Recolección de IOCs”:

Una vez nombrada, presionamos en Editar para su configuración:

Como vemos en la imagen anterior podemos aplicar la configuración específica sobre el equipo “Configuración del equipo”, o sobre el usuario “Configuración de usuario”. Para asignar un script al inicio de sesión del usuario, nos dirigimos a Configuración de usuario>Configuración de Windows>Secuencia de comandos(inicio de sesión/cierre de sesión) —de igual forma para asignar un script al inicio/apagado del equipo iriamos a Configuración del equipo>Configuración de Windows>Secuencia de comandos—. Una vez en este punto, elegimos en este caso la ejecución del script al inicio de sesión del usuario, y pulsamos en Agregar para cargar el/los script/s que queramos asignar al inicio:

Si pulsamos en Examinar nos lleva a la ubicación en la que tenemos que dejar nuestros ejecutables:

Y seleccionamos nuestro .vbs:

Una vez hecho esto la directiva ya estaría creada y cada vez que los usuarios iniciaran sesión en los equipos de Departamento 1 ejecutarían el recolector.vbs, con lo que en la carpeta indicadores comenzarían a llegar nuestros primeros resultados (podemos probar en un equipo de prueba que funciona forzando una actualización de las directivas con el comando gpupdate /force e iniciando sesión). Una vez en destino los ficheros podrían procesarse. Podría incluso pensarse en automatizar también este proceso.

Si no queremos aplicar una directiva de grupo podemos recurrir a asignar el script directamente como secuencia de inicio de sesión, seleccionado en nuestro AD el usuario/s que queramos, botón derecho > Propiedades y en Perfil podemos introducir directamente el script que deseamos que se ejecute al inicio de sesion de esos usuarios escogidos:

Comentar que el comportamiento de los scripts puede perfilarse mediante algunas políticas que se sitúan en el apartado Plantillas Administrativas (grupo que contiene todas las configuraciones de políticas basadas en el registro de Windows Server), por ejemplo ejecutar la secuencia de comandos de inicio de sesión de forma síncrona/asíncrona, tiempo de espera máximo para secuencias de comandos de directivas de grupo, etc.

Probablemente hayan soluciones mucho más elaboradas, lo que dependerá también de cada infraestructura, de la carga de la red (igual al inicio de sesión o arrancado del equipo la ejecución de este script ralentice mucho la máquina y haya que programar esta tarea para otra hora, o conviene hacerlo al final del día…etc, importante probarlo todo primero en PREPRODUCCIÓN y junto a los administradores y expertos en AD de la organización), del objetivo de los investigadores, del administrador del dominio, etc. En cualquier caso mi objetivo es dar unas pinceladas genéricas de como podría pensar hacerse este despliegue en un AD para automatizar este proceso. Agradecería cualquier aportación o sugerencia al respecto.

Nota: documentación sobre implementación y gestión de AD hay mucha y muy variada, con grandes libros y foros de ayuda ya que es una tecnología muy extendida, como por ejemplo este PDF sobre Administración avanzada de Windows Server 2008 R2. Yo realicé las pruebas implantando un controlador de dominio sobre un Windows Server 2003 y con Windows 7 como equipos de usuarios.

Continuamos con el resumen de la 3ª edición de Navaja Negra, al que asistimos José Vila (@jovimon) y un servidor los pasados días 3-5 de octubre.

En este segundo día, la primera charla fue a cargo de Marc Rivero (@Seifreed), en la que habló sobre la evolución del fraude en Internet. En ella, Marc comenzó haciendo un breve resumen sobre las amenazas más sonadas: phishing, troyanos, el virus de la Policía… así como de los kits disponibles en el mercado negro para facilitar la creación de los mismos.

Respecto a este tipo de amenazas, Marc también hizo hincapié acerca de las herramientas disponibles en ambos bandos ya sea para verificar que el malware es indetectable o bien para poder neutralizarlo. También se habló sobre las técnicas Man-in-the-Browser, en las que el atacante actúa de árbitro entre el cliente y el servidor, obteniendo en este caso las credenciales de acceso a la cuenta corriente de la víctima, para luego realizar pequeñas transferencias que puedan pasar desapercibidas.

Otros temas que se trataron en la charla fueron los de los muleros y el uso de servidores a prueba de balas, o servidores comprometidos, para alojar el malware y dificultar la identificación de los responsables.

[Read more…]

(Volvemos a la carga con la undécima entrega de la serie GOTO, que teníamos algo olvidada. Como ya saben, basada en las polémicas instrucciones GOTO de programación. En anteriores ocasiones hablamos de I: Consultores de Seguridad, II: Consultores LOPD, III: Análisis de Riesgos, el IV: Open Source, V: ¿Quién se ha llevado mi queso?, VI: Auditores vs. Consultores, VII: Privacidad vs. todo lo demás , VIII: LOPD a “coste cero” (¿y?), IX: El negocio de la seguridad y X: Periodistas)

Para cualquiera que haya estudiado una carrera universitaria de informática o algún programa educativo similar es evidente que en sus contenidos no se tratan, en la mayor parte de los casos, las tecnologías específicas de fabricantes como Microsoft, CISCO, HP, EMC2 etc. Asimismo, por lo general la formación en materia de seguridad suele brillar por su ausencia, tanto en el ámbito de la gestión (SGSIs, Análisis de riesgos, etc.) como en la parte más técnica (pentesting, análisis forense, etc.). En definitiva, que una vez acabada la fase eminentemente académica y ya de pleno en el mundo laboral, puede ser interesante ampliar los conocimientos, algo que puede hacerse a través de la experiencia a lo largo de los años, autoformación y buenos profesionales en los que apoyarse, a través de formación reglada (esto ya lo vimos el otro día con Joel y hace bastante tiempo publicamos una entrada con certificaciones interesantes) o ambos.

Afortunadamente, para solventar este problema la informática cuenta con un abanico bastante amplio de certificaciones, dirigidas a aquellos profesionales con necesidades específicas en ésta o aquélla tecnología, en éste o aquél ámbito. He de confesar no obstante que yo nunca he sido un gran fan de la formación reglada y menos si es necesario hacer acto de presencia, algo que considero en general una absoluta pérdida de tiempo (evidentemente, no siempre). Lo cual incluye, todo sea dicho, la formación universitaria. Esa es, supongo, una de las razones entre otras de que únicamente disponga de una certificación CISA y una CRISC. La primera la saqué yendo al examen sin haber acabado de leer el temario y la segunda la tengo gracias al programa de grandfathering y evidentemente a mi experiencia en la realización de análisis de riesgos. Voy a serles sincero: no creo que ninguna de ellas me haya aportado absolutamente nada, pero bueno, ahí están; al fin y al cabo, cumplí con los requisitos necesarios para su obtención y tengo totalmente justificadas mis horas de formación.

[Read more…]

Después de un tiempo sin proponer ningún reto, volvemos con nuestro equipo de investigación, el cual cree estar a un paso de conocer el siguiente punto de encuentro de la banda que llevan investigando desde hace unos meses.

Gracias a las últimas intervenciones realizadas, se hicieron con el siguiente archivo: captured_file, el cual pese a estar codificado, parece que proporciona información sobre el lugar en el que se realizará el siguiente intercambio. Además, en la detención realizada de unos de los miembros que participarían en el intercambio, se obtuvo un teléfono móvil el cual únicamente contenía dos mensajes de texto (SMS) en su memoria.

[Read more…]

Una Darknet es una porción de mi red, un determinado espacio enrutado de direcciones IP, en la cual no hay servidores ni servicios activos. Es decir, de manera externa ningún paquete debería estar dirigido contra ese espacio de direcciones.

Por tanto, cualquier paquete que entre en una Darknet no debería ser legítimo. Podría llegar a ella por errores como políticas pobres de seguridad o una deficiente configuración (como por ejemplo mensajes de broadcast enviados a un segmento al cual no pertenece el emisor) pero la mayoría de estos paquetes llegarían enviados por algún tipo de acción sospechosa como algún malware (ver Responding to Zero Day Threats) o atacante que esté dentro de nuestra red y estuviera buscando de manera activa dispositivos vulnerables.

Si dentro de nuestra Darknet, montamos un servidor recolector que recoja ese tráfico que entra en la misma, lo analice y lo procese, nos ayudaría a recopilar más información sobre ese tráfico anómalo/malicioso que pudiera estar circulando por la infraestructura de red de nuestra organización, ayudándonos además a reducir el número de falsos positivos, a detectar ataques en tiempo real o nuevas tendencias de ataques a través de un análisis forense de ese tráfico de la Darknet.

Podemos monitorizar, entre otros, una serie de comportamientos anómalos en la misma, como (ver Aprendiendo del enemigo):

• Tráfico sospechoso agrupado por puertos (TCP,UDP,ICMP,etc) o relacionado con determinados servicios (SSH, FTP, WEB, etc), ataques de fuerza bruta contra servicios, escaneos, ataques de DoS, etc.
• Ataques específicos que utilicen técnicas de spoofing.
• Direcciones IP y dominios en listas negras.
• Determinados patrones generados por malware (escaneos, aumento de tráfico, baja de servicios, propagación de gusanos, bots, etc.)
• Identificación de patrones de Botnets dentro y fuera de la red o redes P2P.
• Posible tráfico malicioso hacia redes externas.
• Nuevas tendencias de ataques.

Desde el proyecto “The Darknet Project” de Team Cymru, nos cuentan un par de ejemplos prácticos de detección de anomalías monitorizando el tráfico de una Darknet. Por ejemplo, sabemos que existen bots que explotan los recursos compartidos abiertos de Microsoft Windows 2000. Un rasgo común de este tipo de bots es el escaneo de sistemas escuchando en el puerto 445/TCP, así que, consultando las herramientas de monitorización de tráfico de red integradas en el servidor recolector de nuestra Darknet podemos detectar si se ha producido un escaneo hacia el 445/TCP. De confirmarse, sería una señal de alerta puesto que los paquetes que se detectan dentro de la Darknet, como se ha comentado, no son legítimos.

Otro ejemplo práctico es sobre el gusano Slammer, el cual realiza un ataque de tipo DoS a servidores SQL mediante el envío múltiple de archivos con el código del gusano al puerto 1434. Uno de los síntomas de la presencia de Slammer es el considerable aumento del tráfico de red a través del puerto UDP 1434 (SQL Server Resolution Service Port). Detectando en nuestra Darknet un indicador de este tipo, nos alertaría sobre la posible presencia del gusano en nuestra red.

En definitiva, recopilando datos sobre todo el tráfico podemos ir analizándolo buscando todos los patrones de interés y automatizar a posteriori todo el proceso a través de un IDS que hayamos instalado en nuestro servidor recolector por ejemplo.

Antes de poner en marcha la creación de una Darknet en nuestra organización es importante tener en cuenta, entre otros, estos dos aspectos:

• Definir las características de la red (topología, alcance, visibilidad).
• Concretar equipamiento hardware y software a instalar, teniendo en cuenta qué tipo de datos queremos recolectar y cómo queremos tratarlos (herramientas de captura de tráfico, herramientas análisis de tráfico, posibilidad de implantar honeypots, etcétera) y el presupuesto económico del que disponemos.

Creación de una Darknet

• El primer paso en el despliegue de una Darknet es ubicarla en un sitio adecuado, así que se deberá escoger un segmento/s de direcciones IP de la red que serán enrutadas hacia la misma. Es recomendable utilizar un espacio de direcciones de al menos /24 (a mayor espacio reservado mayor visibilidad se conseguirá).
• El siguiente paso es reservar el espacio físico y lógico para la Darknet. Como bien nos indican desde Team Cymru, se recomienda no poner una Darknet en el mismo dominio de colisión o VLAN que otras subredes; el objetivo de la Darknet es proveernos de datos fiables, así que es importante evitar “envenenar” la Darknet con tráfico legítimo así como tampoco se recomienda poner las IP de la Darknet visibles públicamente en nuestro DNS.

El CLCERT nos trae una propuesta de DarkNet que sería similar a la siguiente arquitectura (ver Diseño e implementación de una Darknet para monitoreo de la red en Chile – CLCERT):

• Router de Darknet: configurado de forma que transmita todo el contenido que entre a la Darknet. Reenviará el tráfico entrante a la Darknet al servidor recolector. El router deberá estar configurado de forma que acepte únicamente el tráfico entrante (input traffic) dirigido a la Darknet, pero no a la inversa (output traffic). Debería alertarnos en caso de que se detectara tráfico saliente de la Darknet (estaríamos hablando de una Darknet configurada tipo ‘agujero negro’) puesto que todo el tráfico de la Darknet, como se ha comentado, es no legítimo. El router, además deberá estar configurado para SNMP con el fin de disponer de estadísticas de tráfico —utilizando por ejemplo la herramienta MRTG— ya que por ejemplo, nuevas amenazas de malware pueden detectarse fácilmente basándose únicamente en las estadísticas de tráfico de la interfaz de la Darknet.
• Servidor Recolector: interconectado a la Darknet analizará el tráfico. Sería interesante instalar un IDS, un analizador de protocolos, herramientas de análisis de logs, e incluso se puede pensar en la implantación de algún tipo de honeypot, dependiendo la instalación de todas estas herramientas del tipo de análisis y procesamiento que se le quiera dar al tráfico.
• Red administrativa: red especialmente bastionada ya que recibirá de manera continua tráfico malicioso y en la que se procesaran los datos procedentes del servidor recolector, se obtendrán estadísticas e informes sobre el tráfico detectado.

En definitiva, y puesto que todo el tráfico en la Darknet es potencialmente sospechoso, puede sernos muy útil para detectar tráfico malicioso o anomalías de configuración de dispositivos en nuestra organización.

Por si os interesa profundizar en el tema, existen varios proyectos de creación de Darknets (también conocidos como telescopios de red; ver Darknet y telescopios de red) a gran escala cuyos principales objetivos son la monitorización de la actividad de tráfico de red y detección de nuevas tendencias en Internet:

Hoy me gustaría hacer una review de un libro que comencé hace unas semanas y que me ha parecido de lo más interesante: Violent Python. Su autor, TJ O’Connor, es un paracaidista del ejército estadounidense con una larga ristra de certificaciones de seguridad a sus espaldas, entre las que destacan el GIAC Security Expert (GSE) y el Offensive Security Certified Expert (OSCE). En la escritura del libro ha contribuido también Robert Frost, militar y graduado en ciencias de la computación, y ha sido editado por Mark Bagget, instructor certificado de SANS y consultor y fundador de In Depth Defense, INC., entre otros.

Con estos currículos, cuando alguien coge el libro por primera vez piensa que no puede decepcionar, y tras haberlo leído, puedo confirmar que no lo hace. El libro cubre multitud de temas: test de penetración, análisis forense, análisis de tráfico, seguridad en wireless, seguridad en páginas web y evasión de antivirus… todos desde un punto de vista más práctico que teórico, lo cual es de agradecer.

Todos los capítulos tienen su parte de “historia del abuelo cebolleta”, donde expone un caso real que marcó un antes y después en la seguridad informática, como cuando Kevin Mitnick entró en los sistemas de Shimomura, o cuando HD Moore ayudó al Pentágono en la identificación de qué IP estaba buscando vulnerabilidades en sus sistemas. Mediante estos relatos, el autor consigue motivar al lector para, a continuación, mostrarle la implementación de dichos ataques (o soluciones a problemas) en Python, con una sintaxis clara y comprensible.

Aunque no todo podría ser bueno: el libro hace un uso intensivo de librerías externas, que en algunos casos, no están lo suficientemente mantenidas ni probadas. Personalmente, también esperaba más contenido en la sección de Bluetooth, ya que es una tecnología sobre la que el autor ha realizado varias publicaciones, y a la que se le podría sacar mucho partido con los smartphones. Hablando de los mismos, puede que una sección en la que se hablase de Python en Android, mediante por ejemplo la librería python-for-android (Py4A), fuese de gran utilidad: es más versátil llevar encima un móvil o tablet que un portátil, y se podrían utilizar como plataforma de ejecución de varios de los programas implementados en el libro.

En definitiva, el libro atrapa de principio a fin y es altamente recomendable para todos aquellos que estamos interesados en el mundo de la seguridad informática. El texto, aunque en inglés, está muy bien explicado, y no hace falta tener grandes conocimientos de Python para poder sacarle jugo, puesto que el código, además de efectivo, es extremadamente simple, mostrando todo el potencial que se puede sacar a Python.