iAWACS, T2 y Hack.lu

El mundo de la seguridad avanza rápidamente, tanto en ataque como en defensa, así S21Sec está presente en la mayoría de las conferencias y workshops del mundo para estar al día y ofrecer mejor servicio a nuestros clientes, además incluso presenta diversos temas en las mismas aportando nuevos conocimientos a diversos grupos de investigadores.

Este pasado mes de octubre hemos asistido a tres magníficas reuniones internacionales, la iAWACS en Francia, la T2 en Finlandia y por último a la Hack.lu en Luxemburgo.

iAWACS

El primer 'International Alternative Workshop on Aggressive Computing and Security' que se ha celebrado en Francia se hizo en Laval, un pueblecito de estudiantes con todo el encanto francés, donde se sitúa una universidad y en la misma el ESIEA (Ecole Seupérieure d'Informatique, Electronique, Automatique) una escuela al puro estilo MIT. Los asistentes se centraban especialmente en estudiantes y profesores, profesionales de la industria francesa, policías y militares, vamos, de todo. Conferenciantes internacionales solo estábamos dos Mahmoud Maqableh y un servidor (Leonardo Nve).

Había programados dos talleres y diversas conferencias, el primero de los talleres fue dado por un Sebastien Tricaud, CTO de honeynet project, 'PicViz Tutorial or How to detect a single attack log in a 4Gb log file', en este workshop aprendimos a usar PicViz, una herramienta para mostrar gráficamente mediante coordenadas paralelas parámetros de todo tipo y esto se puede usar para representar grandes cantidades de logs y así fácilmente se pueden descubrir 'extraños' en nuestros logs, solo mirando el dibujo saliente.

Mi opinión personal es que con un poco más de trabajo y perfeccionamiento PicViz será una herramienta muy muy útil en el futuro para detectar ataques o simplemente anomalías, mucho mejor que graphviz.

El segundo taller, 'WiShMaster reloaded tutorial', de Benjamin Caillat trataba de la creación automática de shellcodes para Windows, el programa y la investigación son profundamente buenos, además se demostró un profundo conocimiento de los entresijos de Windows y ficheros ejecutables PE, no obstante, ya tenemos suficientes Shellcodes para Windows en mi opinión, debería seguir la misma metodología para desarrollar lo mismo para otras plataformas.

Llegando a las conferencias he de decir, que debido a que esto era básicamente una escuela muchas de las presentaciones tenían una presentación académica modelizando matemáticamente un problema de seguridad y analizándolo, un acercamiento este que me pareció extremadamente bueno. Algunas de las que más me gustaron:

• Erwan Abgrall habló de ciertas funcionalidades de Oracle, 'Oracle: a New Hop', donde presentó que más se puede hacer aparte de lo conocido cuando descubres un SQL injectioncontra una BBDD Oracle, hizo una demo de un 'proxy' a través de SQL, así podía navegar por una red interna usando inserciones y diferentes capacidades del Oracle. Muy bueno.

• Eric Filiol (organizador de la iAWACS y profesor del EISEIA) y Robert Erra (Profesor también) hablaron de malware 'Processor-dependent malware' donde demostraron matemáticamente que se puede hacer malware ofuscado y que no se detectable por ningún antivirus, todo basado en las incorrecciones matemáticas de los procesadores.

Mahmoud Maqableh, jordano residente en Inglaterra, explicó en 'Cryptanalysis of Chaos-based Hash Function (CBHF)' como ha roto este tipo de funciones hash. Esta conferencia me llamó

ciertamente la atención y me gustó mucho, yo no soy dado a la criptografía y creía que poco iba a entender, mi sorpresa fue cuando lo entendí todo y no solo eso...

La historia comienza en una reputada revista sobre criptografía unos expertos publican las CBHF como nueva alternativa al SHA y MD5 considerándolas totalmente seguras, Mahmoud al leer el artículo supo inmediatamente (esa intuición de que algo es vulnerable solo con oírlo que tiene cierta gente) que podía romperlas, ante el desánimo de sus colegas (también expertos) el insistió en buscar un ataque. El resultado es que no solo rompió el sistema sino que además es un juego de niños, a posteriori me da incluso la impresión de que pudiera haberlo hecho yo mismo viendo lo fácil que es (a posteriori todo es más fácil).

Como he dicho esta persona me gustó especialmente tanto por su intuición como por su trabajo para demostrar que eso 'imposible' no solo era posible sino que era fácil. Mis felicidades Mahmoud.

Aparte de estas, hubo muchas más buenas conferencias sobre PLC, side-channels, RSA keys, etc... Ha nacido un nuevo punto de reunión entre académicos y profesionales de la seguridad.

T2 (www.t2.fi)

Casi inmediatamente terminar la iAWACS, partí para Finlandia donde se organizaba en Helsinki la sexta edición de la T2. Arrancó con alta presencia española arrancó, este congreso es de esos en los que se paga una barbaridad por asistir, por lo que las conferencias deben de ser del más alto nivel y lo consiguieron.

La organización fue bastante buena, buen hotel, catering entre charla y charla, nos llevaron a comer y a cenar a buenos sitios (asistentes y conferenciantes), aparte de un USB con las presentaciones, camisetas, etc etc... Como fallo solo puedo pensar en dos y realmente no lo son tanto: La hora de la comida, las conferencias empezaban a las 9 de la mañana en nuestro mismo hotel, es decir, se bajaba a las 8.30 a desayunar (y me gusta desayunar fuerte), no obstante, la hora de la comida era a las 11.30!!!!! Para los españoles acostumbrados de que la comida sea entre las 14-15.30, se nos hacía duro, en realidad es horario finés no es un fallo.

Nuestros principales anfitriones fueron la gente de F-Secure, y los inauguradores de las charlas. He de decir que una hora de historia de los virus no me pareció técnicamente provechosa pero si interesante.

Posteriormente elegí ver las dos charlas de Andrea Barisani, la primera, no programada, 'Injecting RDS-TMC Traffic Information Signals' es una impresionante investigación sobre inyectar tráfico RDS y utilizarlo para hackear los GPS de coche con resultados muy graciosos. La segunda 'Sniff Keystrokes with Lasers/Voltmeters', tenía muchas ganas de verla, y explica cómo usar la tecnología laser para detectar lo tecleado en un portátil, interesante, y más bien útil para agencias de inteligencia o policías.

Dado que coincidía con mi charla, no pude ver la del español Rafael Domínguez 'USB Attacks: Fun with Plug & 0wn', donde exponía un buffer overflow en un kernel de Linux que puede ser explotado solo conectando una llave USB.

Bastante interesante aunque afortunadamente el fallo no está en el kernel actual de Linux.

El segundo día asistí a la impresionante charla del también español David Batanero 'Forensics on GSM phones' básicamente que información esconden nuestros móviles y tarjetas SIM así como extraerla, hizo varias demostraciones de cómo hacerlos,

¡cuidadin con quién coge vuestros móviles!

Jarno Niemelä de F-Secure nos enseño como utilizar el bluetooth para espiar, las funciones que tiene y usarlo, solo tenemos que hacernos con el móvil del objetivo para realizar estos ataques, igualmente con diversas demostraciones y de nuevo

¡cuidadin con quien coge vuestros móviles!

Muhaimin Dzulfakar de NGSS con 'Advanced MySQL Exploitation' nos enseño un poco más de SQL injection, pero no mucho realmente, también presentó una herramienta integrable con Metasploit llamada MySqploit, esta herramienta sí que es interesante a la hora de atacar SQL injections en nuestras auditorias.

La última charla a la que asistí fue a la de Alexander Polyakov 'Technical Aspects of SAP Security' tanto atacando el servidor como los clientes SAP, hizo algunas demostraciones reales.

Posteriormente a las charlas y para terminar, se realizó una visita guiada a los laboratorios de F-Security, realmente impresionantes, lo que más me impresionó fue el laboratorio de virus para móviles y la protección el resto del complejo frente a virus bluetooth con un sistema de detección inalámbrico.

Hack.lu (www.hack.lu)

Al mismo tiempo que Leonardo presenciaba T2, Christian Martorella participaba de Hack.lu en Luxemburgo. Es el quinto año que se celebran estas conferencias, reuniendo mayoritariamente profesionales europeos, con fuerte presencia Francesa, Belga, Suiza y Alemana,

el entorno de las mismas muy agradable y muy bien organizadas.

En esta conferencia había una serie de Workshops los dias previos a las charlas, los cuales estaban incluidos en el precio de la entrada estandar, algunos muy interesantes impartidos por grandes profesionales como Billy k. Rios y Nitesh Dhanjani.

En las charlas hubo una fuerte presencia Francesa, específicamente de ESIEA (Escuela Superior Informatica Electronica y automatismo, que organizo IAWACs) y Sogeti, los cuales presentaron temas tan diversos como vulnerabilidades en PDF, Cifrados en Word y Excel, Virus k-ary en Python, Fuzzgrind framework para automatizar la detección de vulnerabilidades y una charla interesante sobre Troyanos en Windows Mobile 6. También teníamos algunos conferenciantes que están de gira mundial como Moxie Marlinspike y Philip Langloise, los cuales hablaron de SSLtrip y como crear un dispositivo para auditar redes wireless basado en OpenWRT, respectivamente.

No tuve la misma suerte que Leo en visitar un laboratorio, pero al menos nos llevaron al Museo de Arte contemporaneo, donde nos hicieron una visita guiada y luego un catering al ritmo del músico "Playboy's Bend", la cual se basaba en Circuit bending, muy curiosa la sesión.

Un hecho interesante es ver que el Ministro de Economía y comercio internacional, Jeannot Krecké, ha realizado la Keynote del evento.

Esto es todo sobre estas magnificas conferencias,

Saludos

Leonardo Nve & Christian Martorella

S21sec Auditoría

Pasando desapercibido...

Hace ya unos meses Asier nos trajo al blog el hecho de que una botnet utilizaba Twitter para enviar comandos a los clientes infectados.

Esta técnica puede servir principalmente para introducir una capa pública que separe lógicamente clientes y servidor, o poder prescindir de ella si no se tienen recursos. Si, por ejemplo, los clientes obtienen los comandos a ejecutar mediante una red social, y el envio de credenciales se realiza por correo electrónico, dispondremos de una separación lógica entre los bots y el panel de control, a costa de confiar en dos servicios gratuitos en vez de en un servidor a prueba de balas.

En el caso que comentamos, me resultó realmente curioso que se utilizara una cuenta upd4t3, y los comandos estuvieran codificados en base64.

Una cuenta de este estilo, sea la que sea, será detectada cuando se analice una pieza de malware que la utilice, pero me resultaría mucho más coherente ver que la cuenta twitter se llama paranoias y los mensajes no saltan con un mínimo análisis sintáctico/semántico de la web. Por ejemplo, cuatro entradas de paranoias podrían ser:

• dos ideas teoricas ilustran www.tupagina.com
• mi gato grita lallallaal
• solo versos imaginativamente narrados merecen escucha
• un optimista redomado subasta monstruosos relojes

¿Qué comandos se han enviado? ;)

Mikel Gastesi

S21sec e-crime

Nuevo binario de Zeus

La evolución continúa. Hace unos días apareció en escena un nuevo binario de ZeuS, concretamente la versión 1.3.0.26. Se trata de un espécimen que intenta mejorar el grado de ocultamiento en el sistema, como se comentaba en uno de los archivos TODO encontrado hace un tiempo. A modo de análisis superficial se pueden observar las siguientes características:

• Cuando se ejecuta, en el caso de no estar infectado ya, se copia como siempre en el directorio %SystemRoot%/system32, pero con un nombre diferente en cada ejecución, tomando como información básica del fichero la de %SystemRoot%/system32/ntdll.dll (fechas de creación, último acceso y modificación).

• Si al ejecutarse encuentra una versión anterior del troyano ésta es borrada del disco, dejando sus archivos de configuración visibles en el próximo reinicio. Para hacerse una idea, una de las últimas versiones con nombre de ejecutable sdra64.exe es la 1.2.12.

• Aparentemente ya no guarda en disco los archivos de configuración y datos robados, sino que esta información sólo se almacena en memoria.

Aparte de estos cambios importantes, también es remarcable el hecho de que no se use nombre de dominio en la URL del punto de envío de datos, sino que únicamente aparece una IP. Además, en el directorio correspondiente no parece estar el grueso del panel de control, como es normal, sino que únicamente se ve un archivo PHP de poco tamaño, tratándose probablemente de una redirección. Esto es algo que ya habíamos visto anteriormente, pero que podría ser un punto característico en esta nueva versión, siguiendo la línea de ocultar y dificultar al análisis.

Sin embargo, también hemos encontrado muestras cuyo número de versión era 1.3.1.1 pero mantenía el comportamiento de las anteriores (aunque sí eliminaba versiones anteriores): el nombre del ejecutable era sdra64.exe y guardaba los archivos de configuración y datos en disco. Esto puede ser debido a las distintas opciones a la hora de construir los binarios (builder) o a la existencia de diferentes autores.

Como veis, alguna de las recomendaciones dadas en el post sobre detección de ZeuS varían, pero básicamente todas las técnicas siguen siendo válidas a excepción de la localización de los archivos de configuración y datos ocultos, que parecen no existir.

Se trata de un análisis preliminar de este nuevo binario, pero conforme avancemos en nuestros análisis iremos dando más detalles, ¡estad atentos!


Jose Miguel Esparza
S21sec e-crime



English version

Reputación Online: Podrías estar muerto y no lo sabías

En este blog ya hemos hablado sobre la reputación online. Volviendo a recordar un poco el concepto, la reputación online es el reflejo del prestigio o estima de una persona o marca en Internet. Como ya dijimos anteriormente, un aspecto esencial de la gestión de la reputación online es la  monitorización en tiempo real de Internet para estar al tanto de ataques potenciales contra la  reputación del individuo o de la organización en cuestión.

Generalmente estos ataques pueden venir de blogs, o de alguna de las diferentes redes sociales existentes.
En este rango de ataques, recientemente nos hemos topado con un caso llamativo, al "enterarnos" esta semana de que "str0ke", moderador del popular “site” sobre vulnerabilidades Milw0rm, había muerto.

Parece ser que todo empezó aquí, y se empezó a extender por internet, apareciendo mensajes transmitiendo condolencias a la familia, esquelas e incluso fiestas. Afortunadamente, "str0ke" ha dado señales de vida
a través de su cuenta de twitter.

 

Aquí tenéis otro divertido ejemplo de cómo una persona murió en facebook, para finalmente ser resucitada y convertida en un “zombie” de facebook.

Así que ya sabéis, tened cuidado de lo que se dice de vosotros en internet, ¡podríais haber muerto y no saberlo!

 

Asier Marruedo

S21sec e-crime

Un par de opiniones (parte 2)

Continuando el post de la semana anterior...

2. Un ciber-ataque puede causar daños en las instalaciones e incluso a las personas.

SÍ, PERO NO. Es el sistema físico el que puede causar el daño. Lo que es peligroso son las materias (gases, sustancias químicas, elementos pesados...), las condiciones de proceso (altas o bajas presiones, temperaturas, atmósferas explosivas…), los equipos (riesgo de atrapamiento, aplastamiento, corte..)…

La interconexión de "sistemas de gestión" con sistemas productivos, aumenta los riesgos porque se introduce una nueva fuente de errores o problemas, pero no tiene la capacidad directa de interacción con el medio físico.

En cada nivel o capa de nuestro sistema deben existir mecanismos de seguridad que no dependan de niveles superiores y que garanticen la no interferencia en el funcionamiento de las aplicaciones de niveles inferiores.

Cada nivel debe ser diseñado para ser correcto, que en condiciones normales funcione como debe, y efectivo, que sea capaz de responder adecuadamente ante a los imprevistos (variables del proceso, fallo accionamientos, órdenes de incompatibles con el contexto...). La implementación de mecanismos de seguridad en cada nivel permite mitigar el daño o las pérdidas.

El nivel más importante es el nivel físico y los equipos deben tener cuantas modificaciones y elementos auxiliares sean necesarios. Dentro de lo posible, un sistema sobre el que perdamos la capacidad de control debiera evolucionar por si mismo hacia un estado seguro y estable, priorizando (en este orden) el bienestar del entorno y las personas, la integridad del sistema en sí y las materias y/o productos en proceso.

En el siguiente plano, están las aplicaciones de usuario que interaccionan con el sistema físico (sea en un PLC, DCS, RTU, IED...). Aquí tenemos dos problemas:

• se intenta ahorrar en la parte de seguridad de los equipos y poner los mecanismos de seguridad dependiendo de la parte software.
• no se suelen auditar los programas. Se verifica su funcionamiento (corrección) pero las pruebas sobre su efectividad suelen ser muy limitadas (y cuando los servicios de programación son subcontratados la situación final puede ser muy diversa).

Si el sistema está bien diseñado, implementado y mantenido, el daño principal que se podría sufrir sería la pérdida de disponibilidad del sistema. La parte de visualización del proceso, no debiera suponer una amenaza, porque las operaciones inseguras o incorrectas no deben ser ejecutadas por un programa del nivel inferior (SI ESTA BIEN HECHO).

El resto de capas superiores son gestión, procesado y análisis de información y debiera ser posible trabajar sin ellas, al menos temporalmente y desde el punto de vista de poder producir un bien o prestar un servicio y sin considerar implicaciones normativas (cómo sucede en farmacia y química fina).

Diego López
S21sec Labs

Fiabilidad en los IDS

Hoy, leyendo la noticia sobre el sistema del DNI facial y, más concretamente, leyendo los comentarios que acompañan a la noticia, se podía leer que el sistema no era del todo fiable. El sistema tiene una fiabilidad del 95% dentro de un escenario controlado, o lo que es lo mismo, un error en la identificación de personas del 5%.

Y es la fiabilidad de los sistemas automáticos lo que más me ha llamado la atención. Extrapolando el término de fiabilidad a la seguridad informática, y más concretamente, al concepto de sistemas de detección de intrusiones, me ha llevado a formularme la pregunta ¿cuán fiables son los sistemas automáticos frente a los configurados manualmente? Para responder a esta pregunta, en primer lugar, debemos diferenciar entre los sistemas automáticos, conocidos como detectores de anomalías, de los configurados manualmente, también denominados detectores basados en firmas o del mal uso.

Los sistemas basados en detección de anomalías, son sistemas basados en comportamientos inusuales del sistema. Estos sistemas se basan en el aprendizaje de patrones dentro de un escenario exento de ataques o intrusiones. Para llevar a cabo este aprendizaje, estos sistemas hacen uso de técnicas de inteligencia artificial tales como modelos de clasificación y modelos de predicción.

Los sistemas basados en firmas o en detección del mal uso, son sistemas capaces de monitorizar las actividades de un sistema y compararlas con las firmas de ataques ya conocidos, almacenadas a su vez en Bases de datos. Estos sistemas son incapaces de predecir un ataque debido a su propia naturaleza ya que, solo detecta aquellos ataques ya identificados por el sistema.

En la realidad, cabe mencionar que son los sistemas basados en firmas son los que máyor número de ataques identifican correctamente, alcanzando cotas del 90-100% de ataques bien identificados, gracias a su bajo nivel de falsos positivos. Por otro lado, los sistemas basados en la detección de anomalías ofrecen ratios bastante altos, alcanzando cotas de 85-95% de los ataques bien identificados, dependiendo del escenario de uso.

En consecuencia, mencionar que a pesar de que los sistemas de detección basados en firmas son bastante más fiables que los basados en anomalías, estos últimos no ofrecen malos resultados, acercándose rápidamente al rango de fiabilidad deseado.

Aitor Corchero Rodríguez
S21sec labs

Retos para la Administración Pública de la Ley 11/2007

Con la publicación de la Ley 11/2007, nuestro país ha dado un paso de gigante hacia la Administración electrónica (lo que se ha venido denominando e-Administración) al reconocernos a los ciudadanos nuestro derecho a relacionarnos con las Administraciones Públicas a través de los medios electrónicos. Evidentemente, esto que, para los ciudadanos es una ventaja, para la propia Administración es un gran reto desde una perspecitva operativa pero también en lo relativo a la seguridad.

De todas formas, esta situación no es nueva, el sector financiero español se enfrentó al mismo tipo de problema al principio de la década. Las entidades financieras tuvieron que exportar su modelo de negocio hacia Internet para lograr que los usuarios pudiesen realizar el mismo tipo de operaciones en la vida digital que ya hacían cotidianamente en el mundo físico. En mayor o menor medida, esos retos, dentro del sector financiero, están ya resueltos. Para lograrlo, fue necesario tomar medidas correctivas, puesto que no se planificó el despliegue de esos servicios desde un punto de seguridad, sino desde el punto de vista de negocio, cosa completamente legítima, pero que demostró que planteaba problemas.

La experiencia durante estos años nos ha enseñado que uno de los problemas principales es poder demostrar que el usuario ha realizado una determinada operación a nivel informático. Lo que comúnmente conocemos por trazabilidad. Un usuario realizará los trámites que la e-Administración le brinde y tendremos que, además de prestarle el servicio adecuadamente, verificar que ese trámite se hizo en forma y tiempo. No solo para una correcta tramitación, sino para poder demostrar, en caso de que sea necesario, de una manera conforme al principio de legalidad establecido en el artículo 4 de la Ley, en cuanto al mantenimiento de la integridad de las garantías jurídicas de los ciudadanos ante las AA.PP. establecidas en la Ley 30/1992.

El reto es poder demostrar que el usuario ha entrado en nuestas aplicaciones, que ha hecho el trámite necesario, que fue él quién realmente lo hizo, y que él mismo ha firmado documentos, en fin, asegurar el timeline (trazarlo).

Una mala planificación de la entrada en vigor de los servicios prestados nos lleva a tener que realizar inversiones adicionales, a demoras en el tiempo de despliegue y a una enorme dificultad en el tratamiento de los datos. Pero si somos capaces de encontrar una vía de desarrollo adecuado, podremos incurrir en menor gasto y ahorrarnos gran parte de los dolores de cabeza que aquí planteamos.

Nuestra sugerencia, sobre la base de las lecciones aprendidas, pasaría por un ciclo de vida completo de los logs necesarios para dicha trazabilidad, desde la definición inicial, pasando por una herramienta capaz de gestionar la información de los logs hasta una auditoría que verifique que se cumplen las condiciones necesarias para evitar el no repudio.

La definición inicial debe permitirnos marcar cuáles son los requisitos que establecemos para dicho sistema de gestión de logs, qué tipo de información deben generar las aplicaciones que se creen para posibilitar los trámites electrónicos y poder así planificar adecuadamente todas las acciones necesarias para llevar a cabo la implantación de dicho sistema. Por otra parte, los criterios definidos en esta primera fase deberían ser la base para la realización de las auditorías de verificación una vez implementado el sistema.

Para el último punto, es necesaria una aplicación que controle los logs de las aplicaciones, que los centralice, con propósito de restaurar de alguna manera la actividad y que nos permita, no solo reconstruir la sesión, sino asegurar que se produjo. Tenemos que tener en cuenta que algunos de los datos que encontraremos están sujetos a LOPD u otros controles. Así mismo, es necesario la firma y sellado de tiempo, si procede, de esos logs. En algunos casos será incluso necesario cifrarlos. Y por supuesto, tendremos que ser capaces de buscar entre todos los datos almacenados, para poder demostrar al ciudadano, u a otra instancia superior, que esa relación entre el ciudadano y la Administración Pública se ha producido.

Sabemos que es un proceso largo y que las aplicaciones no serán todas iguales pero mejor abordar las cuestiones de seguridad incluidas en la Ley antes del despliegue de los servicios online a los ciudadanos.

Antonio Ramos, Director S21sec Galicia
Fernando Carrazón, Consultor tecnológico preventa