En un post anterior Ximo nos habló de los análisis forenses de memoria RAM en Linux y dentro de esta entrada hizo mención a dos herramientas para el análisis de memoria RAM en entornos Windows, que son Mandiant Memoryze y Mandiant AuditViewer.

En esta entrada vamos a ver funcionalidades de la herramienta para conocerla un poco y que sirva como presentación para los que no la conocen. Las pruebas para esta entrada las hemos hecho sobre los ficheros de memoria del reto DFRWS 2005 Forensics Challenge. Por si alguien quiere probar la herramienta los ficheros de memoria son memory1 y memory2. Para profundizar os aconsejamos la guía de usuario que ofrecen los autores y donde están todas las opciones detalladas.

Con todo listo pasamos a cargar el fichero “memory1” en la herramienta AuditViewer, con el wizard de la herramienta. Resumiendo la configuración para la carga del fichero y su análisis, marcaríamos todo menos la adquisición de procesos y drivers; además, para este caso concreto recopilamos la información de todos los procesos. Hay que tener en cuenta que en este caso el fichero de memoria RAM es de 128 MB, por lo que da más pie a marcar todas las opciones y en un corto periodo de tiempo obtener los resultados. En el caso de tener un fichero de memoria más grande, el tiempo de análisis por parte de la herramienta será más largo, ¿obvio no? :), viéndonos obligados a ser más finos en la configuración, sobretodo si no contamos con mucho tiempo. Añadir que esta entrada no intenta resolver el reto, sino que únicamente usa esas imágenes para mostrar funcionalidades de la herramienta.

Una vez cargado el fichero tendremos la siguiente imagen, donde se destaca en color ROJO uno de los procesos que hay en memoria que UMGR32.EXE:

Si miramos la documentación veremos que esto significa que se ha detectado algo sospechoso en ese proceso. Lo primero que nos debemos preguntar nosotros es: ¿Qué es UMGR32.exe? ¿Es un proceso malicioso o es un proceso legítimo y habitual en el sistema operativo? Si realizamos una búsqueda rápida en Google, vemos que todo apunta a que se trata de “Back Orifice 2000”, partiendo del nombre del proceso, dato no determinante.

Con lo que hemos encontrado en Google, decidimos empezar nuestro análisis por este proceso. Es por esto que vamos a ver la información recopilada sobre ese proceso en las diferentes pestañas que nos ofrece la herramienta:

Iremos viendo la información y analizando, intentando encontrar respuestas a las preguntas que pretendemos responder con nuestro análisis. Una de las opciones más interesantes, como suele ser habitual, es Strings, que nos mostrará las cadenas del proceso. En nuestro ejemplo veremos cosas cómo:

En las imágenes anteriores se ven cadenas bastante sospechosas, como metasploit.exe, como cadena de apertura de sockets en el puerto 44444, etcétera.

Además, si vamos a la pestaña de puertos vemos como tiene a la escucha el proceso el puerto 44444. Hecho que suele ser sospechoso, ¿no? :). Con lo que se requiere analizar en profundidad.

El proceso que ha detectado como sospechoso y por eso lo ha marcado en rojo, es porque tiene código inyectado en memoria y esto requiere un análisis especial. La herramienta de una manera muy visual y sencilla nos ofrece muchas posibilidades para analizar la memoria RAM y generar un informe de manera automática en diferentes formatos. Añadir que la herramienta tiene ciertos mecanismos que ayudan a detectar anomalías, como es el caso de Mandiant Malware Rating Index (MRI), así como la posibilidad de cargar reglas de Snort que transforma en plugins para buscar en la memoria (no he probado esta funcionalidad).

Mi impresión al utilizar la herramienta ha sido buena y os animo a los que no la conozcan a probarla y como siempre a darnos su opinión. Como siempre esperamos que os sea de utilidad.

El pasado Agosto de 2011 fue publicado un artículo por Sanjay Goel, cuyo título se corresponde con el título de esta entrada. El artículo tiene como principal objetivo cubrir el estado del arte de la ciberguerra y sus retos, además de aproximarse hacia la recolección de datos inteligentes y el análisis forense de incidentes producidos en una ciberguerra.

Según comenta el artículo los actores principales de las ciberguerras son los estados, terroristas y grupos sociopolíticos, y junto a éstos existen actores secundarios que son parásitos o establecen una simbiosis con los actores principales de la ciberguerra. Se plantean varios objetivos para iniciar este tipo de conflictos, como son espionaje y reconocimiento, propaganda y guerra social, deshabilitar la infraestructura Web del gobierno objetivo y atacar infraestructura críticas entre otros. Todas estas amenazas son conocidas y hemos hablado de ellas en varios artículos de blog, de manera directa o indirecta, siendo conscientes del riesgo al que estamos expuestos, por lo menos los que estamos en este sector y vamos viendo día a día cómo van actuando los “malos”.

En una segunda parte del artículo se centra en la recolección de información y el análisis de la misma. Como todos sabemos la información existe y está ahí expuesta, y es el momento de recolectarla y sobretodo de extraerla, analizarla y de relacionar las diferentes fuentes de información. Se que dicho así, suena sencillo, pero es tal el volumen de información en la red, que este uno de los retos de este tiempo.

Sanjay Goel en el artículo diferencia entre “unstructured data”, que son datos de foros de hackers, blogs, sitios web, cuentas de twitter, etcétera, que te ayudan a prevenir un ataque y “network data”, donde se refiere a información de IDSs, darknets, honeypots, firewalls, routers, equipos infectados, etcétera. Añade además que estos dos tipos de fuente deben activarse una a la otra. Es decir, si se observa algo extraño en nuestros “network data”, debemos observar la información que llega de las “unstructured data” y viceversa, lo que resulta evidente.

Como conclusión, me permitirán que me quede con la necesidad de contar con el análisis humano combinado con herramientas semiautomáticas y técnicas avanzadas, imprescindibles para procesar este volumen de información de una diversidad tan elevada. Bajo mi punto de vista llegar a una automatización total es una tarea a día de hoy de lo más compleja, pero automatizar y correlar esta información en la medida de la posible se ha convertido en una necesidad imperiosa.

En definitiva, la información está ahí; “solo” nos queda recopilarla, correlarla, analizarla, predecir acontecimientos futuros, actuar ante acontecimientos actuales, y analizar acontecimientos pasados. Ahí es nada.

Me gustaría compartir con vosotros unas reflexiones sobre el uso de ataques a cliente hoy en día en las pruebas de “Ethical Hacking”. Lo primero de todo es aclarar que cuando hablo de ataque a cliente me refiero a pruebas diseñas explícitamente para atacar al usuario final de una organización, donde estas pruebas o ataques pueden buscar cualquier usuario de la organización o buscar determinados perfiles (ataques dirigidos), como administradores de sistemas, directivos, responsables del departamento de compras, etcétera. Además, estas pruebas o ataques combinan ingeniería social y técnicas de explotación de software cliente para conseguir objetivo.

Una vez introducido el concepto de “ataque a cliente”, desde mi punto de vista no incluir este tipo de pruebas dentro de la batería de pruebas de un “Ethical Hacking” significa que no estamos poniendo a prueba nuestra organización frente a la vía principal de infección y ataque en la actualidad. Normalmente se contemplan pruebas sobre nuestras aplicaciones Web, sobre nuestro sistemas situados en el perímetro y sobre nuestra red interna; estas pruebas son totalmente necesarias, pero me pregunto ¿son suficientes? ¿nos hemos puesto a prueba realmente? Podemos estar aplicando muchas medidas de seguridad a diferentes niveles pero, ¿son efectivas ante un ataque a cliente?

Un escenario sencillo de ataque a cliente sería el siguiente: un atacante envía un correo muy sugerente a un alto cargo de la organización para que acceda a una página Web con código javascript malicioso (el atacante podría utilizar la herramienta beEF para crear el ataque). El alto cargo accede, con lo que el equipo queda controlado por el atacante al ejecutarse el código javascript, pudiendo llegar a comprometer el equipo de manera persistente en el caso de poseer alguna vulnerabilidad (un ejemplo de este escenario sería este vídeo). Con este simple ejemplo hemos saltado las barreras perimetrales habituales y ese equipo está controlado por el atacante, poniendo a prueba la seguridad en nuestra red interna, la del propio sistema cliente y nuestros sistemas de monitorización internos.

A partir de ese momento uno se debe preguntar: ¿está mi organización preparada para prevenir, detectar y reaccionar en el caso de que esto pase? Si partimos del hecho de que alguien en la organización por alguna circunstancia ha sido infectado, ¿seríamos capaces de detectarlo? ¿Podríamos enterarnos si el espécimen que ha infectado el equipo está sacando información confidencial hacia fuera? ¿Sería capaz de parar todos los ataques destinados a usuarios de mi organización, mis medidas lo paran?.

Vamos a mostrar dos ejemplos de posibles pruebas que un equipo de “Ethical Hacking” podría diseñar de una manera sencilla y que aportaría a la organización una serie de indicadores:

1. En primer lugar el equipo de “Ethical Hacking” desarrolla un correo electrónico muy sugerente donde se regala un dispositivo electrónico de moda, aprovechando las fechas de la navidad. Este correo es enviado a la gente de la organización desde una cuenta amigable (direccion@miempresa.es). En el correo se coloca un enlace a una página Web donde cada visita será registrada. El equipo de “Ethical Hacking” dispondrá al final de un periodo establecido de una serie de datos, de los cuales se extraerán dos indicadores útiles para la organización:

• Cuantos usuarios avisan al equipo de seguridad de un correo fraudulento.
• Cuantos usuarios siguen el enlace.

El objetivo de esta “práctica” sería por tanto crear un phising controlado.

2. Otro escenario sería dejar uno o varios dispositivos USB de almacenamiento cerca de la organización en puntos estratégicos, como si se hubieran perdido. Dentro habrán documentos bastante sugerentes. Al ejecutarse lo único que se haría es mandar un paquete hacia al equipo de “Ethical Hacking” indicando que se ha visto el documento.

De este escenario tan simple se extraerán indicadores útiles para la organización como:

• Cantidad de usuarios que usan el pendrive.
• Cantidad de usuarios que ejecutan el fichero.
• Cantidad de usuarios que ejecutan el fichero como administrador, etcétera.

Este escenario pondrá a prueba el nivel de concienciación del usuario final, las políticas del sistema del cliente, etcétera.

Los escenarios posibles son muchos, como muchas son las vías que los atacantes están utilizando para infectar los equipos cliente y con ello vulnerando la seguridad de nuestra organización. Los escenarios propuestos son muy simples y podrían ampliarse, obteniendo más indicadores de interés para comprobar que todo está funcionando como esperamos. Con esta entrada lo que me gustaría es que se reflexione sobre la utilidad de este tipo de pruebas y se piense si estamos testando nuestra organización ante este tipo de ataques. Estas pruebas van dirigidas al personal de la organización, por lo que deben estar muy bien diseñadas y acordadas con el cliente para no afectar a los usuarios y a la vez obtener resultados concluyentes.

¿Qué piensan nuestros lectores sobre este tipo de pruebas? ¿se están utilizando ampliamente en las pruebas de ethical hacking? ¿son demasiado arriesgadas?.

Para terminar me gustaría dejar una presentación de Carnal0wnage, donde se tratan los ataques a la capa 8, es decir los ataques al cliente en un PENTEST, una presentación muy recomendable.

En esta pequeña entrada me gustaría comentaros un detalle interesante, que dentro de la fase de information gathering (N. del E. véase el informe sobre este tema que Josemi y Borja Merino publicaron hace unos días) a alguno le puede llegar a ser de utilidad. El otro día estaba haciendo una revisión de una aplicación Web y dentro de la fase de “Testing for web Application Fingerprint” (OWASP-IG-004) me encontré que el servidor Web en cuestión me devolvía en la cabecera HTTP Server el texto “Apache”.

HTTP/1.1 200 OK
Date: Wed, 23 Nov 2011 15:50:43 GMT
Server: Apache
Content-Language: es-ES
Content-Type: text/html;charset=UTF-8
Content-Length: 57942

En primera instancia, asumí como un campeón que era un servidor Web Apache. No obstante, utilizando la herramienta HTTPrint que deduce el resultado a partir de otras técnicas más avanzadas, obtuve que NO era un Apache, por lo que empecé a dudar y me dije: ¿habrán cambiado el banner para confundir? mmm…

Acto seguido me puse a mirar lo que decía Netcraft, pero también me decía que era una Apache… ¿y si lo dice porque ve el banner y no hace ningún tipo de comprobación más? Entonces pensé: voy a aprovecharme de que Shodan guarda un histórico de la respuesta del servidor a ver si hubieran cambiado el banner hace poco y al principio lo tenían con versión o era otro servidor Web. Efectivamente, Shodan tenía diferentes respuestas del servidor y por lo que pude ver era un Apache y además la versión para plataformas Windows, respuesta que relacioné con el resultado del Netcraft que también decía que era un Windows.

Vale. Pero… la aplicación es nueva y el histórico de Shodan es bastante antiguo; ¿habrán cambiado de servidor web, máquina, sistema operativo y ya no se corresponde? Como véis no me quedaba tranquilo. La aplicación trataba bien los errores y aparte del banner no daba pistas evidentes que me sirviesen para aclarar si se trataba realmente de un servidor Web Apache. Lanzo la herramienta nmap con la opción “-sV” y ésta también me dice que se trata de un Apache, habiendo también hecho match la respuesta con alguno de los patrones de nmap-service-probes. Sí, parece un Apache, pero… ¿y si no es un Apache?

Después de todo esto, en una de las peticiones devueltas por el servidor en Burp, caí en la cabecera Etag, que como en otra entrada del blog ya vimos cada servidor Web la crea de una manera diferente y podemos considerarlo una característica muy útil para determinar con qué servidor Web estamos trabajando. Observé el formato y coincidía con un servidor Web Apache. Es decir, lo que me habían dicho todos menos HTTPrint :-)

Con esto último mi estado paranoico de que los administradores del servidor Web estuvieran manipulando las respuestas se calmó, ya que ví poco probable la modificación de la cabecera Etag. Las dudas me las sembraron HTTPrint y el hecho de no ver ningún tipo de mensaje que pudiera confirmarme que lo que realmente me decía el banner era correcto.

Espero que esta entrada sirva para ahorraros todas las indagaciones que tuve que hacer yo y podáis comprobar de manera rápida (si la cabecera está activa) qué servidor Web hay detrás. Desconozco si alguna herramienta utiliza esta cabecera como un elemento más para deducir que se trata de un servidor web concreto, pero al menos HTTPprint por lo que he podido ver no lo hace. Si alguien sabe alguna herramienta que lo haga, le agradecería que la comentara. De todos modos no me extrañaría que ya se esté utilizando, ya que en Wikipedia se indica la cabecera como fingerprint del servidor Web:

“An ETag is an opaque identifier assigned by a web server to a specific version of a resource found at a URL. If the resource content at that URL ever changes, a new and different ETag is assigned. Used in this manner ETags are similar to fingerprints, and they can be quickly compared to determine if two versions of a resource are the same or are different. Comparing ETags only makes sense with respect to one URL—ETags for resources obtained from different URLs may or may not be equal and no meaning can be inferred from their comparison.”

A mi me resultó curioso y pensé en escribir este post, que espero que a más de uno le ahorre unos minutos ;)

En entradas previas hemos visto qué era UMO y una pequeña guía de cómo instalarlo, por lo que ha llegado el momento de ver algunos ejemplos de cómo usarlo y donde puede ayudarnos.

Antes de empezar me gustaría comentaros que se han eliminado los ficheros de la sección de descargas donde estaba la versión empaquetada en tar.gz y es necesario por el momento descargarlo vía un cliente de subversión, tal que así, “svn checkout http://umo.googlecode.com/svn/ umo-read-only”. Añadir también que si os encontráis problemas en el uso de la librería MySQLDb con la librería para Safebrowsing en python, deciros que he propuesto un pequeño cambio en el issue 11 del proyecto para que no dé problemas.

Antes de empezar, es aconsejable actualizar la base de datos con el siguiente comando:

También, aprovecho para recordaros que como muchos ya sabéis los logs son nuestros amigos, es por ello que he intentado que exista la mayor cantidad de información en ellos, de modo que permita detectar problemas en la aplicación, registrar las acciones de qué va realizando, los enlaces que procesa, etcétera. Cuando ejecutemos UMO tendremos varios logs (es posible cambiar el nivel de log, en el fichero de configuración):

• umolog.log: donde se registran mensajes relacionados con el funcionamiento de la aplicación, por donde va pasando, etcétera
• umourls.log: donde registro las URLs que UMO va procesando.
• umomalware.log: fichero donde se almacenan las urls con malware.

Vale, ahora sí, ha llegado el momento de algún ejemplo de uso. Para ello plantearemos dos casos donde podemos utilizar la herramienta:

1. Organización que dispone de una aplicación Web y quiere de manera periódica monitorizarla. En este caso decidimos recopilar mediante crawling los enlaces y comprobar si esos enlaces están registrados en el base de datos de Google SafeBrowsing que disponemos en local.

# Vamos a recopilar los enlaces de la web www.ejemplo-umo.es con nivel de profundidad 1:

Si queremos ver qué enlaces ha procesado, lo tendremos en umourls.log:

En este caso concreto el fichero umomalware.log se encuentra vacío, lo que es una buena noticia. Deberemos tener monitorizado este fichero y en el caso de que se inserte un enlace que salte una alerta en nuestros sistemas.

2. El otro escenario que vamos a ver sería un ejemplo de un equipo de seguridad que quiere investigar determinada amenaza. Este escenario ha sido elegido para poder obtener resultados de páginas que se encuentran en la base de datos y por tanto están infectadas o lo han estado. En este caso no vamos a hacer crawling, sino que vamos a aprovechar que otros ya lo han hecho. La búsqueda que vamos a utilizar recoge los resultados de la infección masiva donde se inyectó el dominio “http://lizamoon.com”:

Enlaces recogidos por UMO y después los vulnerables:

En este caso vemos como parece que ha habido 20 URL’s de las indexadas que se ha encontrado en la base de datos.

Tomando como ejemplo uno de los enlaces y viéndolo con la herramienta Malzilla, vemos como contiene código inyectado (pinchar sobre la imagen para ampliar):

Comparando los dos casos, hemos visto que el modo que utilizan los principales buscadores tiene como ventaja que no actúa de manera directo sobre el objetivo, pero tiene como principal desventaja que la información nos la ofrece un tercero y debemos ver que no esté “sesgada” o limitada, por cantidad de peticiones u otros factores. En cambio, el modo que realiza crawling directo sobre el objetivo, ofrece como principal ventaja que no dependemos de un tercero y como desventaja, en el caso de Webs de terceros, que es más intrusivo y ruidoso.

Como veis la herramienta es sencilla de utilizar (o eso espero) y al tratarse de un script podemos automatizar su uso. Para acabar, deciros que espero que esta entrada sirva para conocer un poquito más a UMO y recordaros por un lado que está en estado Beta y que cualquier comentario será bienvenido.

Supongo que a muchos de ustedes les sonarán las reglas de Emerging Threats y sobretodo les sonarán el conjunto de reglas de la archiconocida “Russian Business Network” (RBN), sobretodo si disponen de sus sondas NIDS en un entorno mediano/grande, con gran cantidad de tráfico, donde por regla general suelen hacer acto de presencia. Estas reglas para el que no las conozcan alertan de conexiones realizadas o recibidas de direcciones de red que han sido clasificadas como maliciosas, sospechosas, peligrosas o similar. Este listado se actualizada de manera diaria, por lo menos en Emerging Threats, por lo que es bastante recomendable que nosotros también actualicemos este conjunto de reglas a la par que la fuente, ya que es un grupo bastante dinámico.

Estas reglas son muy útiles y no lo vamos a negar, ya que son un indicador que nos alerta de que existen conexiones sospechosas, desde orígenes o hacia destinos sospechosos; y lo que aportan merece la pena. Pero por otro lado, hemos podido comprobar que generan falsos positivos ciertos segmentos de red que están incluidos y que se han producido tras una simple navegación de un usuario.

Además, de los falsos positivos, las reglas de la RBN ofrecen poca información para ir poniendo filtros o realizar una investigación inicial, ya que alertan cuando el flag tcp SYN está activo, como muestra la siguiente regla:

El paquete que nos encontraremos cuando esta regla salta carecerá de contenido que pueda ayudarnos a ver de una manera rápida (siempre podemos hacer una investigación más en profundidad, pero entornos con un volumen de tráfico considerable puede suponer mucho esfuerzo) si se trata de un falso positivo o por el contrario se trata de una alerta significativa que requiera una investigación. Por otro lado, debido a la limitación de cantidad de elementos que tienen las reglas de Snort, el fichero de reglas de la RBN contiene muchas reglas, por lo que su personalización y sobretodo su reducción, resulta a priori costoso, aunque sería posible con oinkmaster o pulledpork poder realizar una personalización, pero también es costoso por lo menos la primera puesta a punto.

Ante esto, buscando si existían comentarios en la red sobre las reglas de RBN, me encontré en la lista del proyecto Emerging Threats en una entrada que sí se había hablado sobre las reglas de RBN y donde “Eoin Millar” del blog TrojanedBinaries ofrecía una manera de tratar las reglas de RBN muy interesante. El proceso sería el siguiente:

• 1. Descargarse el fichero de IPs de la RBN alojado en la url http://doc.emergingthreats.net/pub/Main/RussianBusinessNetwork/RussianBusinessNetworkIPs.txt
• 2. Crear un fichero donde se creen bloques de variables del tipo ipvar (requisito para usar ipvar que Snort esté compilado con soporte para ipv6) para almacenar las direcciones ip. Os pongo el ejemplo que comenta Eoin donde se ve muy claro la estructura del fichero (fichero rbn.conf):
  ipvar RBN_1 [127.0.0.1,127.0.0.1,127.0.0.1,127.0.0.1,127.0.0.1]
ipvar RBN_2 [127.0.0.1,127.0.0.1,127.0.0.1,127.0.0.1,127.0.0.1]
ipvar RBN_NET [$RBN_1,$RBN_2]

  En el proceso de creación de este fichero nosotros hemos añadido ciertos controles para prevenir errores en el listado de la RBN, como ha sido fijar un tamaño mínimo de máscara de red y no aceptar direcciones IPs reservadas para redes privadas. Pero esto cada uno a su gusto :).

• 3. Una vez creado este fichero lo incluiremos dentro de nuestro snort.conf, mediante un include rbn.conf.
• 4. Ahora ya nos será más flexible la información de la RBN. Por ejemplo, podemos crear reglas como esta:
  alert tcp $HOME_NET any -> $RBN_NET 80 (msg:"ET accesos de la RBN a servidores WEB"; flow:to_server,established; dsize:>1; detection_filter:track by_src, count 1, seconds 60; reference:url,doc.emergingthreats.net/bin/view/Main/RussianBusinessNetwork; classtype:misc-attack; sid:3000001; rev:1;)

Con esta regla podemos monitorizar los accesos desde direcciones IP de nuestra red a servidores Web dentro de la RBN y podremos visualizar parte del contenido enviado.

Con esto lo que hemos conseguido es reducir el número de reglas, ya que con 2,3 reglas podríamos disponer de todas las del fichero de Emerging Threats y por lo tanto podemos hacer cambios de una manera más sencilla. Por otro lado, disponemos de una variable nueva que puede ser utilizada en otras reglas creadas por nosotros o por terceros.

Por último agradecer a Joaquín Moreno la colaboración en el script para automatizar este proceso :) y sobretodo espero como siempre que os sea de utilidad.

Actualización: Pueden descargarse el script para autogenerar el fichero rbn.conf de este enlace: rbnupdate.py.

Me gustaría en esta breve entrada presentaros a Url Malware Owned (UMO), una mini herramienta hecha en Python. Como podéis ver en el título se trata de la versión Beta 0.1; espero sobretodo en las siguientes versiones ir puliendola y darle estabilidad, como principal objetivo. UMO nace para poder detectar enlaces maliciosos. Las funcionalidades por el momento implementadas son:

• Permite recopilar enlaces a través de una consulta a Google y Bing.
• Permite hacer “crawling” de una página Web concreta.
• Permite analizar un enlace que creamos puede estar comprometido.
• Estos enlaces recopilados de diversas maneras, se buscan en la base de datos en local del safebrowsing de Google. Si se encuentran el enlace ha sido registrado por Google y lo tiene indexado.
• Permite actualizar la base de datos de Google Safebrowsing.
• La salida de la aplicación es un fichero con los enlaces maliciosos.

La aplicación ha sido sobre todo basada en el código de la aplicación fimap (descubierta a través de la librería xgoogle en su README, ¡gracias!), a cuyo desarrollador quiero agradecer la gran labor realizada en la aplicación, ya que me ha permitido en poco tiempo iniciar esta aplicación que va orientada a descubrir enlaces con malware en vez de vulnerabilidades de Remote File Inclusion :)

En una próxima entrada mostraré cómo instalar UMO, sus dependencias y cómo ejecutarla, de modo que sea más fácil su puesta en marcha. Por otro lado, si alguien se anima a probarla, cualquier fallo que detectéis os agradeceré mucho que me lo comuniquéis, bien en un comentario, bien a través de la dirección de correo indicada en los ficheros de umo. Además, si alguien echa de menos determinada funcionalidad, pero no la ve en el TODO (ahora mismo algo escaso), también será bien recibida.

Como espera cualquiera que inicia un proyecto de este tipo, espero que os sea de utilidad aunque sea “cachito”.

En estos días que corren está sonando mucho para lo bueno y para lo malo el servicio “pastebin.com”. Este servicio se utiliza para pegar texto, un servicio sencillo como la vida misma :).

Como no podía ser de otra manera el servicio está siendo utilizado para subir todo tipo de contenido: dumps de base datos de terceros tomadas sin pedir permiso, usuarios, contraseñas, código fuente de aplicaciones, listados de proxys, configuraciones de botnets, etcétera. Otra de las cosas destacables, es el hecho de que el servicio lo usan determinados keyloggers para almacenar lo que van capturando, como os mostramos a continuación:

Esto no es algo novedoso como se puede leer en en thetechherald y hackhispano. Pero nos gustaría volver a resaltarlo dado que se sigue registrando contenido actualmente por keyloggers.

Aconsejamos por tanto en la medida de lo posible monitorizar este tipo de servicios, dado que la información pública en ellos es de lo más variopinta. Para esta monitorización os aconsejamos herramientas como Pastenum.

Recientemente en el blog de Lenny Zeltser, se ha publicado una entrada donde hace referencia a un documento realizado por “CompuCom”, donde se explicaba una prueba de concepto de una técnica para identificar la distribución de un malware mediante la cabecera HTTP ETags.

En estos momentos dos de las principales fuentes para poder filtrar y prevenir la distribución a los usuarios finales es mediante listas de IPs o listados de dominios maliciosos (ver MDL por ejemplo). Pero todos sabemos que tanto las IPs como los dominios van variando de una manera muy rápida, lo que hace muy difícil la tarea de filtrar y prevenir la distribución en base a estos listados.

Los investigadores de “CompuCom” proponen utilizar la cabecera http ETags a modo de “fingerprint”. La cabecera HTTP ETag es opcional y enviada por el servidor Web, que sirve para que el cliente pueda realizar una validación condicional de la caché, de manera que en el caso de que se haya servido ese objeto no volverlo a solicitar con lo que se produce un ahorro de ancho de banda entre cliente y servidor.

A continuación os mostramos nuestras impresiones del documento. Lo primero que debemos tener claro es que:

1. La cabecera ETag es opcional.
2. Por lo que hemos podido ver cada uno de los servidores Web, posee un formato diferente para la cabecera ETag. A continuación podemos ver un listado de ETags de servidores Web diferentes (en el artículo ponen como ejemplo un ETag como el cuarto del listado)

3. El cálculo depende de determinadas variables temporales, variables asociadas al sistema, etcétera. Por poner un ejemplo, en el caso de Apache tras visitar la URL “hxxp://192.168.1.40/file.exe”, que se trata de un fichero infectado, el servidor Web nos devuelve (véase http://httpd.apache.org/docs/current/mod/core.html):

El Etag que nos envía el servidor se divide en:

• 33b309: Inode, inodo en el sistema que tiene asociado.
• 5400: Size, tamaño de fichero
• 4a49c1fd8d4c0: Mtime, tiempo de la última modificación.

Este mismo binario en otro sistema sería servido con un ETag diferente (inodo y mtime cambiarán con una alta probabilidad). Podemos plantearlo como si tuviéramos tres variables:

• V1=IP
• V2=dominio
• V3=sistema (englobamos sistema operativo, servidor web y binario)

En el caso de que V3 sea constante, podemos detectar el malware, dando igual el valor que tenga V1 y V2, dado que no se contemplan en su cálculo.

Estaremos atentos a la evolución de la investigación de “CompuCom”, pero por el momento pensamos que tienen un largo camino por recorrer, para ver su efectividad.