Microprocesadores vulnerables

Hace dos días Theo de Raadt, fundador del sistema operativo OpenBSD hacía eco de numerosas vulnerabilidades graves encontradas en los últimos microprocesadores de Intel Core 2 Duo. En función de la naturaleza de cada una, es posible implementar una actualización del microcódigo de la CPU cargada en el arranque con la ayuda de la BIOS, o bien parcheando las vulnerabilidades a nivel de sistema operativo. También expone que Intel sólo ofrece la información sobre estos fallos a los fabricantes de BIOS y de sistemas operativos de código cerrado (como Microsoft Windows o MacOS X) quedando los sistemas operativos de código libre expuestos a dichos errores.

La pregunta que se hace uno al leer este tipo de noticias es: ¿qué tiempo dedican hoy en día los fabricantes de microprocesadores a comprobar que sus diseños son fiables? ¿el mismo tiempo que en la época del 80386? Antaño los fallos graves se contaban con los dedos de una mano, se hablaba en términos de unos pocos millones de transistores integrados en el núcleo. Hoy en día, son varios cientos de millones (es cierto que una buena parte lo forma la enorme memoria caché con que cuentan estos), y la complejidad de su estructura.

Creo que va siendo hora de que los fabricantes de microprocesadores de la talla de Intel y AMD se den cuenta que más importante que la lucha en velocidades, en consumo/potencia o en número de "cores" por CPU, es el hecho de que su funcionamiento ha de ser fiable, y debe presentar el menor número de fallos de diseño posibles, que a la postre se arrastrarán generación tras generación hasta ser subsanados. También es preciso que tengan en cuenta la importante presencia de los sistemas operativos de código abierto, como por ejemplo GNU/Linux. Este respetable grupo de usuarios se encuentra a merced de que los fabricantes de BIOS decidan actualizar los microcódigos de las CPUs, al ser difícil que dichas correcciones se implementen a nivel de sistema operativo por la poca transparencia que hay al respecto.

El declive de los sistemas antivirus, ¿o no?

Hace tiempo que se viene diciendo que los sistemas antivirus tradicionales tienen los días contados. La base de esta afirmación es la dificultad que las casas antivirus están encontrando para mantener al día sus bases de datos de firmas, y además el hecho de que los creadores de virus comprueban que sus "criaturas" no son detectada por éstas antes de soltarlas.

Las nuevas tendencias incorporan técnicas que se basan en el análisis del comportamiento de los programas en ejecución. Este sistema trata de identificar aquellas aplicaciones cuya ejecución puede suponer una amenaza para el sistema y las bloquea.

No obstante, hay gente que va más allá al considerar que esta forma de combatir el malware no es sostenible. Argumentan un error de concepto, ya que intentar identificar todas aquellas potenciales amenazas, ya sea mediante técnicas de firmas, por análisis de comportamiento o por otras viejas conocidas como el análisis heurístico o los sandboxes, son ejemplos del popular refrán de la "pescadilla que se muerde la cola". Los "buenos" tratan de identificar al "malo" y éste busca nuevas técnicas de camuflaje para no ser descubierto.

Así, se propone una nueva aproximación basada en las conocidas "listas blancas". Esta técnica permitiría únicamente la ejecución de aplicaciones que previamente hayan sido identificadas como confiables por parte del administrador. Esto evitaría tener que mantener al día las firmas de virus y otra información propia de las técnicas tradicionales.

El problema de este punto de vista es que depende de la habilidad del administrador para determinar si una aplicación es confiable o no. Bien es cierto, que esto podría automatizarse y perfeccionarse creándose bases de datos centralizadas y mantenidas por las actuales casas antivirus. De hecho, este servicio ya está siendo ofrecido por algunas compañías del sector.

Actualmente existe una tendencia clara que confirma la adopción por parte del sector de esta técnica como base para combatir el problema de los virus. Sin embargo, mi opinión es que ésta no será la solución definitiva, ya que cabe esperar que los creadores de virus focalicen sus esfuerzos en que éstos sean capaces de hacerse pasar por aplicaciones válidas o en ocultar de cara al sistema su propia ejecución, y así evitar el bloqueo del sistema de whitelists.

El ensamblador puede ser divertido

En 1961, varios investigadores de Bell Labs crearon un juego de programación que llamaron Darwin. En ese juego, 2 o más programas (o especies) podían sondear la memoria, eliminar una especie enemiga que se haya localizado o reservar parte de la memoria para después copiarse a sí mismo. Las especies evolucionaron hasta que Robert Morris escribió una capaz de adaptarse al enemigo y reproducirse, que no fue superada.

A mediados de los 80, surge Core War. Parcialmente inspirado en Darwin, es un juego en el que tienes que programar tu especie en un lenguaje llamado RedCode. Este lenguaje está estandarizado y recuerda a un lenguaje ensamblador simplificado, con unas cuantas particularidades. Tan solo hay 19 instrucciones diferentes y 8 modos de direccionamiento. Las instrucciones realizan operaciones sencillas, como operaciones aritméticas, copiar el contenido de una dirección a otra, saltos condicionales o incondicionales o lanzar un proceso nuevo. También hay una operación NOP (no hace nada) y una operación DAT, que indica que la dirección contiene datos. Esta operación no es ejecutable, y si un proceso por error, o inducido por el contrario intenta ejecutarla, morirá.

El objetivo del juego está claro. Hay que eliminar a los contrarios que conviven en el área de memoria en la que se juega. Se pueden utilizar muchas estrategias diferentes. Programas que se copian continuamente, que bombardean la memoria, que buscan a los rivales antes de bombardearlos, que lanzan varios procesos y hacen varias cosas en paralelo o que utilizan diferentes estrategias a lo largo de la partida. Un programa puede tener desde unas pocas lineas (incluso solo 1), hasta unas cuantas decenas.

Imagen 1.: pMars en modo debug

Para jugar sólo hace falta un editor de texto y un simulador de Core War como pMARS. Hay varias páginas dedicadas a Core War / RedCode. Puedes empezar visitando king of the hill, crear tu especie y participar en campeonatos.

¿RSA en el punto de mira?

El pasado día 21 de junio se ha publicado un artículo en http://www.physorg.com/news98962171.html que hace referencia a la descomposición de grandes números en sus números primos.

En principio este artículo podría pasar desapercibido y no ser tenido en cuenta salvo que las técnicas actuales de descifrado utilizan la factorización de las claves en sus números primos. Como medida se suelen utilizar claves de grandes longitudes que sean productos de números primos muy altos, lo que complica enormemente la posibilidad de descifrarlas con los medios actuales.

El artículo está basado en la descomposición de un número muy grande (307 dígitos) que aunque no es primo es un número de los denominados “difíciles de factorizar”. Para poder factorizarlo se han utilizado tres clústeres de máquinas de tres universidades diferentes y únicamente 11 meses de intensos cálculos.

Actualmente las claves de cifrado suelen ser claves de gran longitud (1024 bits) que a su vez son productos de dos números primos muy grandes (generalmente mayores de 150 dígitos). Debido a la dificultad de poder factorizar números grandes estas técnicas siguen siendo hoy en día seguras, pero se está abriendo una pequeña ventana para poder descifrarlas.

FIRST Conference 2007

Las conferencias FIRST son una oportunidad única para conocer de cerca las últimas actividades del los CERT mundiales, actividades orientadas principalmente a la gestión de incidentes de Seguridad.

En esta ocasión, la conferencia va a tener lugar en Sevilla, durante la semana del 18 al 22 de Junio, contando con ponencias impartidas por miembros de CERT internacionales muy conocidos por la aportación que han ido haciendo a la comunidad de la Seguridad, como puede ser Wietse Z. Venema o Jose Nazario, entre otros.

S21sec participa doblemente, como patrocinador del evento y como ponente en una presentación con el título The Evolution of Online Fraud.




Esperamos tener la oportunidad de estar con vosotros en Sevilla.

Decompilando malware

Recientemente, el autor del programa IDA Pro (que por cierto venimos usando desde hace muchos años en S21sec), ha desarrollado un plugin llamado Hex-Rays que permite decompilar código para facilitar su análisis.

En las primeras pruebas que hemos estado haciendo sobre todo a la hora de analizar manualmente algún nuevo troyano que no saque nada interesante en el Analizador Automático de Malware, hemos podido comprobar que en situaciones no muy difíciles, el plugin funciona bastante bien.

Veamos un ejemplo: una pequeña función que simplemente crea un fichero en disco (realmente es una función real de un troyano que se llama al crear un fichero de configuración del robo de credenciales)



Al utilizar el nuevo plugin de Ilfak Guilfanov, obtenemos el siguiente código ya en un lenguaje de alto nivel:



Es decir, tenemos una función que recibe una cadena como parámetro de entrada (que en el programa es c:\\windows\\temp), le concatenamos '$q.tmp' y creamos el fichero. Después comprobamos si ha habido algún error en la creación o no.

Realmente, verlo en un lenguaje tipo C puede ayudar significativamente al analista a la hora de examinar cualquier código desconocido, ¡aunque si estás acostumbrado a leer miles y miles de líneas en ensamblador puede que no te haga falta!

Sugerencias para mejorar la seguridad en SCADA

En el siguiente artículo se explica brevemente la evolución de los sistemas Scada y se presentan una lista de vulnerabilidades más comunes que existen hoy en día. Luego, se hacen varias recomendaciones para corregirlas, agrupadas en tres categorías: redes, sistemas y procedimientos.

Autor: Daniel Liberal S21sec

Descargar artículo completo (pdf)

Nuevo objetivo del fraude online: el control de dominios

La situación actual respecto al fraude online, nos permite desde S21sec detectar y prevenir, en numerosos casos, los ataques de fraude que se van produciendo, muchas veces incluso en las fases de preparación.

Se ha comentado en varias ocasiones la capacidad actual de los troyanos existentes en Internet del robo de credenciales de acceso a las páginas web de las entidades financieras, actividad que realizan mediante diversas técnicas cada día más sofisticadas (BHO, inyección en procesos o man-in-the-middle) y en este artículo vamos a exponer un nuevo uso observado de los mismos.

El artículo en cuestión se centra en el cambio de mentalidad del uso de las credenciales robadas, ya no sólo buscando credenciales de acceso a entidades financieras, sino también ahora a una actividad generalmente subestimada, el control de los dominos de Internet

Ejemplo de panel de control:


English version available at 'Online Fraud new targets: domain control'

Mulas y fraude en Internet

La aparición de la palabra ‘mula’ en el entorno del fraude en Internet data ya de varios años atrás. Como viene siendo frecuente, es una traducción del término anglosajón ‘money mule’, y se puede definir como ‘una persona que transfiere dinero o mercancías que han sido obtenidas de forma ilegal en un país (generalmente a través de Internet), a otro país, donde suele residir el autor del fraude.

En el último boletín de S21sec hemos escrito un artículo de carácter divulgativo sobre la aparición de este nuevo rol en la cadena del fraude, con el título 'Mulas y fraude en Internet'