Se ha publicado una actualización de Cisco IOS XR que soluciona una vulnerabilidad que afectaría a la disponibilidad del sistema donde se ejecute este software. Cisco IOS XR es el sistema operativo que corre en varios routers Cisco tales como el CRS-1, el 12000 y el ASR9000 series. Esta vulnerabilidad afecta a los RSP440 de Cisco ASR9000 y a los PRP de Cisco Carrier Routing System (CRS).
El problema se debe a un error no especificado al procesar paquetes de red. Si un atacante remoto envía un paquete especialmente manipulado puede llegar a causar una denegación de servicio dejando inaccesible el sistema. Esta vulnerabilidad tiene como identificador CVE-2012-2488 y afecta a la versión 4.2.0 de los routers ASR9000 y a las versiones 4.0.3, 4.0.4, 4.1.0, 4.1.1, 4.1.2, y 4.2.0 de los routers CRS Performance Route Processor. Cisco ha publicado la versión 4.2.1 que soluciona el problema de seguridad para ambos tipos de enrutadores.
Hemos podido leer algún artículo en que se califica a TheFlame como una "super-ciber-arma" del futuro. Este llamativo titular no puede más que asustar al lector y prepararlo para un apocalipsis cibernético. Las razones para esta espectacular clasificación son cuando menos desenfocadas. Parece que lo que sorprende del malware, es en realidad lo menos interesante. "TheFlame es "el espía definitivo", copia datos del disco duro, registra mensajes instantáneos y otras comunicaciones online, registra pulsaciones de teclas, toma capturas de pantalla e incluso enciende el micrófono y graba conversaciones cercanas". Este párrafo real leído en medios de comunicación, solo recopila características comunes de cualquier malware actual (y de hace años) al alcance de cualquiera. ¿Por qué nos sorprende entonces? ¿Por qué lo destacan los periodistas como hecho diferenciador?
Anclados en el pasado
No hemos asimilado que el malware actual es capaz de esto, aunque lo lleva haciendo varios años. Por ejemplo, Bagle, marcó un punto de inflexión en el mundo del malware: era absolutamente modular (como TheFlame), permitía el robo de información, se difundía a través de varios medios... y nació en 2004. Desde entonces, este modelo no ha parado de evolucionar, hasta el punto de que todas estas funcionalidades se pueden considerar "estándar" para cualquier creador de malware, en forma de kits "Do it yourself", y de módulos programables. El usuario medio sigue pensando que el malware, en general, solo es capaz de ralentizar el ordenador o, como mucho, mostrar publicidad no deseada. Y sobre todo, que el antivirus (y solo el antivirus) les protegerá. La concienciación en este sentido es muy escasa.
Nos gustan los fuegos artificiales
Sub7 o Back Orifice, eran piezas de software muy sofisticadas en los 90, que permitían un absoluto control del sistema afectado. Sentaron las bases de las RAT (remote administration tool) actuales. Contaban con funcionalidades parecidas a las de TheFlame pero de una forma mucho menos discreta. Sin embargo, todavía hoy, la gente recuerda que su mayor logro era que permitía abrir la bandeja del CDROM remotamente...
El usuario sigue dejándose llevar por las funcionalidades más llamativas, independientemente de su utilidad práctica. Esta es la razón por la que en las series y películas los ordenadores se muestran con gráficos espectaculares, sonidos y efectos especiales en cada movimiento de pantalla, teclado o ratón. Si bien son muy vistosos, en la vida real resultarían insoportables a los cinco minutos de uso. Grabar la conversación, por muy espectacular que pueda parecer (que no lo es), no es útil por ahora para un troyano bancario. Para robar una cuenta no es necesario lucir espectaculares gráficos o emitir soniditos galácticos.
Sin embargo, controlar el DOM del navegador, modificarlo, inyectarse en procesos... todo esto es técnicamente más interesante y peligroso, pero poco llamativo para el usuario de a pie.
¿Nos debe sorprender algo, entonces?
El malware va por delante de las medidas de seguridad, por tanto, deberíamos sorprendernos de las características que convierten al malware en algo tan escurridizo que las elude. Principalmente, lo llamativo del malware actual no es qué puede llegar a hacer, sino el cómo llega a poder hacerlo y mantenerlo. En definitiva, tres puntos clave:
Cómo consigue infectar los sistemas. Uno de los mayores méritos del malware, verdaderamente sorprendente, son las habilidades técnicas de los exploiters para aprovechar vulnerabilidades, la capacidad de difundir estos exploits, eludir las medidas de protección de los sistemas operativos, y hacerse con el control de la máquina. Esto es un arte complejo, y (no sin razón) es lo más valorado en el mercado negro: conocer una vulnerabilidad es lo que mejor se paga hoy en día, pues permite ejecutar código arbitrario en los sistemas. A partir de ahí todo lo que se consiga, aunque interesante, ya no es "tan complejo". El trabajo duro ha sido conseguido. Una vez con el volante en la mano, conducir el coche no es tan difícil.
Cómo consiguen pasar desapercibidos. Los creadores de malware centran sus esfuerzos actuales en la ofuscación de código, empaquetamiento, "técnicas anti debugger"... la inversión se centra en cómo hacer que su código sea más complejo, y su estudio lleve más tiempo. Esto les permite pasar desapercibidos. A veces las técnicas son muy ingeniosas, pero no suelen trascender del laboratorio que las estudia.
El uso de la ingeniería social. Debería seguir sorprendiéndonos cómo los atacantes destripan la naturaleza humana y consiguen engañar a los usuarios para que pulsen sobre los enlaces, entreguen sus datos personales o incluso realicen transferencias ficticias en favor del propio atacante... Usando un ejemplo cercano, sería como sorprenderse más de que el "virus de la policía" pueda crear técnicamente una ventana que ocupa toda la pantalla, que del hecho de que haya conseguido una credibilidad en su estafa que consigue un ratio de efectividad tan elevado.
En definitiva, no es que TheFlame sea un malware más sin mérito (en absoluto), sino que llama la atención que, por un lado, no se mencionen las características que realmente lo hacen único (programación LUA, exploits internos y conexión por bluetooth, recolección de metadatos...). Por otro, que sea necesario un despliegue mediático de este calibre para que al usuario común le llegue el mensaje de unas características que suenan a ciencia ficción... cuando las posee el malware común, el que en estos momentos infecta a millones de máquinas.
En esta entrega de la saga, vamos a analizar una amenaza de tipo 'Dropper', es decir, un fichero cuya misión es descargar e instalar otra pieza de malware con más funcionalidad.
La muestra me ha llegado como 'video_michel_telo.exe'. En este punto puede que algunos opinen que alguien que haya podido encontrar interesante ese supuesto vídeo bien merece lo que le pase, pero eso cae fuera del objetivo de este post.
Lo primero que vamos a hacer es abrir el fichero con OllyDbg, y nos encontramos con un warning:
Tiene pinta que el fichero está comprimido usando algún packer, le decimos que no y pasamos a ver que hay en la memoria (pulsando en el ícono M de Olly)
Como podemos observar, encontramos trazas de que el fichero ha sido comprimido con UPX por lo que, en este punto, no tenemos acceso a la forma del programa 'real' lo que impide, entre otras cosas, curiosear por las strings.
Afortunadamente, UPX es bastante sencillo de 'reversear', se puede encontrar información, por ejemplo, en este magnífico post que me ha servido como referencia.
Lo primero que vamos a hacer es abrir el programa con Olly y ver donde se detiene:
La primera instrucción ese ese PUSHAD y lo que tenemos que encontrar es la instrucción POPAD que se encuentra unas cuantas líneas mas abajo, hay que hacer scroll hasta localizar dicha línea.
Una vez localizada la línea, nos situamos ahí y pulsamos F2 para poner un breakpoint.
Acto seguido pulsamos F9 para que el programa se lance y llegue hasta nuestro breakpoint.
Una vez el programa se detiene en el breakpoint, si vamos pulsando F7 para que el programa avance instrucción por instrucción, llegamos a este punto
El objetivo es llegar a ese JMP que conduce realmente al 'entry point' del programa original, es decir, al pastel sin el envoltorio de UPX.
En ese punto, el programa real ya es visible y por lo tanto podemos pedir a Olly que realice el análisis completo
Después de eso, ya tenemos acceso, entre otras cosas, a todas las strings que contiene el programa (y que antes, al estar bajo UPX no teníamos acceso)
Así que hacemos un search de las strings del programa
Y ¡Sorpresa! encontramos material interesante
Como se puede observar, entre las strings del programa encontramos la URL de donde va a descargar la otra pieza de malware, el directorio que va a crear y el nombre del ejecutable.
Ahora vamos a buscar esa información usando otra aproximación al problema. Vamos a obviar que tenemos acceso a la información de las strings y vamos a intentar descubrir la misma información empleando otra técnica.
Primero le pedimos a Olly que nos enseñe las llamadas a las APIs que realiza el programa
De entre todas las llamadas hay dos bastante sospechosas, URLDownloadToFile() y ShellExecute() Si acudimos a MSDN, nos encontramos que la primera: 'Downloads bits from the Internet and saves them to a file' Muy interesante.
Y la segunda: 'Performs an operation on a specified file' no es muy descriptiva pero sirve para ejecutar un programa.
Tiene toda la pinta que va a descargar ese otro fichero y ejecutarlo. Vamos a poner dos breakpoints en esas funciones para verlo justo cuando suceda.
Ahora simplemente tenemos que ejecutar el programa pulsando F9 para que llegue a los breakpoints. Evidentemente este tipo de ejecuciones hay que hacerlas de forma controlada. La idea es tener el entorno seguro bajo control. En el próximo post explicaré como crear un entorno de análisis adecuado.
Al pulsar F9, el programa, como es lógico, se para en el breakpoint de URLDownloadToFile y si miramos en el stack, nos encontramos:
La URL que va a descargar y el lugar donde lo va a depositar.
Ahora, volvemos a pulsar F9 y por lógica, deberíamos llegar a la parte en la que trata de ejecutar dicho fichero.
Como podemos ver en el stack, ahí está la ejecución del fichero que se ha descargado.
Y esto es todo por hoy, no puedo olvidarme de dar las gracias al GDT por su colaboración
Sí, el virus de la policía sigue activo e infectado a usuarios. Lo interesante es que continúa evolucionando. Veremos en esta entrada qué novedades traen las últimas versiones, y cómo recuperar el control del sistema de manera muy sencilla si ha quedado infectado.
El malware de este tipo que secuestra el sistema, parece dar pasos en falso. A veces avanzan las técnicas de manera muy efectiva, y otras simplemente empeoran la efectividad de su producto. Veremos ahora algunos ejemplos.
La nueva moda es distribuir este tipo de troyanos en forma de DLL. Una librería de Windows no es más que un ejecutable, en realidad. De hecho, su "magic number" es el mismo, MZ. ¿Cómo se ejecuta una DLL? Existen dos formas, con regsvr32.exe (pasándole como parámetro la DLL) o con rundll32.exe, pasándole como parámetro la DLL y además, una función que se encuentre dentro.
¿Y si no conocemos la función dentro de la DLL? No importa. Se invocará al main (la rutina de iniciación principal) de la DLL y ejecutará su código igualmente. Por tanto, realmente el segundo parámetro de rundll32, en este caso, da igual. Para una víctima, esto es irrelevante puesto que todo el código (sea en forma de ejecutable o DLL) se ejecutará a través de vulnerabilidades.
Una vez lanzado el malware, se copia a la carpeta de inicio del usuario. En ella introduce un enlace (.lnk) que apunta al lanzamiento de la DLL.
No os dejéis engañar por la extensión (modificada por el troyano). Police.exe sigue siendo una DLL, no un ejecutable. Posicionándose en la carpeta de inicio, es fácilmente eludible, puesto que simplemente se puede arrancar con otro usuario o bien en modo a prueba de fallos. Pero veremos otra manera de eludir el troyano más adelante.
¿Por qué distribuirse en forma de DLL?
Puede tratarse de un intento de despiste para los antivirus. Al ser lanzado como parámetro de un programa legítimo (rundll32.exe, que seguro se encuentra en las listas blancas de todos los motores), cabe la posibilidad de que algún antivirus se "relaje". Una vez en memoria, el troyano estará a salvo del antivirus.
Otra razón que se nos ocurre es por intentar evitar las sandboxes que ejecutan automáticamente malware. Casas antivirus, investigadores, sandoboxes públicas, etc, suelen contar con máquinas que lanzan automáticamente los ejecutables con la idea de estudiarlos y tener una primera aproximación del comportamiento de la muestra. Si es sospechoso pasa a un análisis manual. En principio, una DLL con extensión de ejecutable daría error de ejecución, y por tanto se tomaría de forma automática como ejecutable corrupto, a no ser que el sistema esté específicamente diseñado para comprobar que se trata de una DLL y lanzarla como tal, cosa que no ocurre normalmente...…
Internet Explorer en modo kiosko, cómo eludirlo
Una vez lanzado el malware, encontramos otra novedad. Ahora, en vez de mostrar una aplicación sin bordes que ocupe toda la pantalla, o un BMP que impide acceder al escritorio, se cierran todas las aplicaciones abiertas y se lanza un Internet Explorer en modo kiosko. Esta es una opción legítima del navegador, diferente a pantalla completa, que permite navegar sin acceso al sistema y con muchas otras restricciones. Cualquiera puede probarlo lanzando en el sistema el comando:
C:\Program Files\Internet Explorer>iexplore.exe k
Desde este punto, escapar del troyano se reduce a intentar escapar del modo kiosko. El troyano, aunque intenta restringir de varias formas el acceso a la máquina, no lo consigue. De hecho, es perfectamente posible escapar con sencillos pasos. Algo que que se puede hacer es desconectar la máquina de Internet, para que la visita a la web que aloja la imagen que bloquea el sistema no pueda ser accedida. De esta manera Internet Explorer dará un error de conexión. En XP, por ejemplo, se puede aprovechar el diagnóstico de conexión, en el apartado de más información.
Aunque, a causa de las restricciones impuestas por el troyano, no se podrá acceder al disco libremente.
Aun así, poco después de aparecer este error, Internet Explorer dejará de funcionar, se podrá recuperar el escritorio.
En Windows 7 todavía es más sencillo. Se puede usar por ejemplo el menú contextual del envío de correo por Mai
Y, en ese nuevo navegador, ir hacia c:\windows\system32 y ejecutar un explorador.
El modo protegido de Internet Explorer es, en realidad, el uso de control de integridad aplicado al navegador de Microsoft. Una especie de sandbox. Esta funcionalidad aporta una medida extra de seguridad a Internet Explorer, además de ser, junto a Chrome de los pocos navegadores que la utilizan. Pero en Internet Explorer existe una forma "por diseño" de eludirla. Hemos creado una pequeña herramienta que permite vigilar qué aplicaciones se pueden "saltar" la sandbox.
Desde su versión Vista, Windows implementa MACL ("Mandatory Access Control List"). Todos sus objetos tienen un "nivel de integridad" asociado. Normalmente "medio". Los objetos (procesos, ficheros, carpetas…) que tengan asociado un nivel de integridad "bajo", no podrán acceder a niveles superiores ("medio" o "alto"), mientras que los de nivel "medio" o "alto" sí podrán acceder a los objetos definidos con nivel de integridad "bajo". Esto deja a los procesos o archivos definidos con nivel de integridad "bajo", en una especie de sandbox, puesto que no pueden acceder a nada con nivel "medio"… o sea, al disco duro.
¿Cómo se definen estos niveles de integridad?
Aunque es una herramienta muy útil, no existe forma gráfica de hacerlo en Windows. Sólo es posible con la utilidad icacls.exe o a través de APIs específicas en los procesos. Tampoco existen demasiados programas que las utilicen de forma predeterminada. Uno de ellos es Internet Explorer, y al hecho de usarlo en sus procesos, Windows lo llama "Modo protegido".
Pero claro, ¿cómo es posible grabar a disco algo descargado desde el navegador, o realizar cambios en el sistema, si en teoría con el modo protegido el navegador no puede acceder a esa parte? Tanto Chrome como Internet Explorer manejan el concepto de "broker" que es un proceso en modo de integridad "medio", que siempre se ejecuta y hace de intermediario para que el navegador no se encuentre totalmente aislado. Esto puede suponer un punto de exposición. ¿Quién es "broker" en Windows? ¿A qué otros programas se les permite actuar de esta manera? Los que están definidos en esta rama de registro:
Tanto en su versión de LocalMachine como de CurrentUser. La mayoría de las extensiones y plugins de Internet Explorer necesitan de estas políticas de elevación para poder funcionar cómodamente. Si no fuese así, muchas de estos programas integrados en el navegador, esperarían confirmación cada vez que son ejecutados, y aparecería un diálogo como este:
Así que si la rama "Policy" del programa "broker" tiene el valor 3, una instancia del programa que se ejecute con integridad "baja" podrá invocarlo de forma silenciosa (sin que apareciese el diálogo) y manejará la petición en modo de integridad "medio"... lo que supone un peligro. Otras opciones de ejecución de estos programas "brokers" son: el valor 0, que impide que sea lanzado; el valor 1 que haría que se lanzase el proceso desde Internet Explorer siempre con nivel "bajo" sin preguntar; y el nivel 2 que lanzaría el programa con nivel "medio" preguntando.
Una buena parte del adware que se instala en forma de barra en Internet Explorer, también se introduce en esa rama del registro para ejecutarse de forma transparente.
MICBypassCheck
Hemos creado una pequeña herramienta (no demasiado elaborada estéticamente) que, simplemente, recorre esa lista de programas y muestra de forma cómoda sus políticas. Un código de colores ayuda a diferenciar qué política tiene cada programa. Además, marcará en rojo las rutas a programas que no existen. Por ejemplo, ciertos programas desinstalados pueden "olvidar" el eliminar esa rama. Estos pueden ser eliminados sin problemas. El programa también permite grabar un fichero con la información.
Ha sido programado en C# por Sergio de los Santos y necesita .NET 4 para funcionar. Está disponible desde:
Principal
