jueves, 31 de mayo de 2012

El sitio es el oficial, pero ¿y el archivo que estoy descargando?


Michal Zalewski, conocido como 'lcamtuf', ha publicado una interesante prueba de concepto que demuestra cómo sería posible engañar a un usuario haciéndole creer que está descargando un archivo de un sitio legítimo.

En la prueba, al hacer click, el usuario ve cómo su navegador abre una nueva pestaña, se dirige al sitio oficial (y auténtico) de Adobe y descarga un archivo que parece ser una actualización de flash.

En realidad este archivo no se descarga desde la página oficial, sino desde la pestaña anterior. Aun así el usuario no detectará ningún cambio en la barra de direcciones ni ninguna señal aparente que le advierta que el archivo no pertenece a la pestaña activa. En ningún navegador.

Veamos el código de la página atacante, situada aquí (http://lcamtuf.coredump.cx/fldl/):




Es un simple botón que llama a la función 'doit' cuando se pulsa.



La función javascript 'doit' abrirá una nueva ventana (o pestaña) que apuntará al sitio de descarga de flash. Adicionalmente ejecutará la función 'donext' cuando pasen 4,5 segundos.





 


La función 'donext' abrirá una segunda ventana que no será visible ya que únicamente se dirige a http://199.58.85.40/download2.cgi e inicia la descarga de un ejecutable.

Lo interesante es que el inicio de la descarga no será evitado, ni el navegador cambiará a la pestaña o ventana donde se origina. Sin embargo la sensación del usuario es que la descarga se ha efectuado desde la página original de Adobe.

Un efecto que hemos observado es que posteriormente sí se descarga el archivo original que pertenece a Adobe. Se verá en disco como una copia del anterior. Chrome es el único que avisa de que el sitio está intentando la descarga de varios archivos. En Opera, por ejemplo, se observaría una dirección diferente en el diálogo de descarga, al igual que Internet Explorer. Pero ninguna de estas advertencias parecen muy llamativas.

También merece ser señalado que durante unos instantes se observa en la barra de direcciones de la ventana objetivo la carga del manejador:

data:text/html,<meta http-equiv="refresh" content="0;URL=http://get....

Es precisamente el uso del pseudo protocolo 'data' el que permite crear una nueva página al abrir la nueva ventana. 'data' es comúnmente usado para incrustar pequeñas imágenes (favicons) en base64. La página creada tan solo contiene un elemento 'meta' que cargará la página de Adobe.

Las implicaciones de seguridad que podrían ser potencialmente explotadas son bastante obvias. Un atacante podría engañar a un usuario para que descargue un archivo malicioso haciéndole ver la página oficial de un producto cualquiera.

Zalewski ha reportado la vulnerabilidad a los principales navegadores, si bien la respuesta que ha obtenido a sido tibia, incluso Microsoft, según Zalewski, le ha comunicado que no considera esté fallo una vulnerabilidad. Firefox no ha confirmado su parcheo y Chrome ha indicado que lo parcheará pero no ofrece una fecha concreta.

Más información:

Yes, you can have fun with downloads


David García

miércoles, 30 de mayo de 2012

Solucionadas dos vulnerabilidades en Asterisk


Se han corregido dos vulnerabilidades en Asterisk, en sus versiones 1.8.x y 10.x, que podrían permitir a atacantes remotos provocar denegaciones de servicio.

Asterisk es una implementación de una central telefónica (PBX) de código abierto. Como cualquier PBX, se pueden conectar un número determinado de teléfonos para hacer llamadas entre sí e incluso conectarlos a un proveedor de VoIP para realizar comunicaciones con el exterior. Asterisk es ampliamente usado e incluye un gran número de interesantes características: buzón de voz, conferencias, IVR, distribución automática de llamadas, etc. Además el software creado por Digium está disponible para plataformas Linux, BSD, MacOS X, Solaris y Microsoft Windows.

La primera de las vulnerabilidades, con identificador AST-2012-007 (CVE-2012-2947), se basa en el controlador de canal "IAX2". Un atacante remoto podría forzar a la aplicación a intentar usar un puntero no válido pudiendo hacer que dejase de funcionar. Esta vulnerabilidad fue reportada en marzo de 2012.

La segunda, con identificador AST-2012-008 (CVE-2012-2948), trata de un error de referencia a puntero nulo en el controlador de canal "SCCP" que, usado por un atacante remoto, podría causar que el servicio dejase de estar disponible para los usuarios legítimos. Esta fue reportada el 22 de mayo.

Sendas vulnerabilidades se corrigen en las versiones 1.8.12.1 y 10.4.1 publicadas en los boletines AST-2012-007 y AST-2012-008.

Mas información:

Asterisk Project Security Advisory - AST-2012-007

Asterisk Project Security Advisory - AST-2012-008


Daniel Vaca


martes, 29 de mayo de 2012

TheFlame: reflexiones sobre otra "ciberarma" descubierta demasiado tarde


TheFlame es la nueva pieza de software descubierta y propuesta como modelo de ciberarma. Tal como ocurrió con Stuxnet y Duqu, TheFlame resulta muy interesante por su sofisticación técnica, a la vez que alimenta la imaginación de muchos sobre las posibilidades de una guerra cibernética. Veamos en qué consiste este malware y qué conclusiones se pueden sacar de su descubrimiento.

TheFlame vuelve a tener características similares a Stuxnet y Duqu. Vayamos por partes:

Fuente: Securelinst.com
  • No se trata de un malware que se disperse a discreción. Es el controlador del troyano el que decide a dónde se dirige. Si bien Duqu fue todavía más restrictivo y se encontró en menos de 100 equipos en todo el mundo, TheFlame ha sido encontrado en muchos más, pero no llega a ser masivo. Kaspersky habla de miles.
  • Parece estar diseñado para el espionaje, por sus características. En este punto, es necesario recordar que no es esta característica la que, de por sí, lo convierte en un malware sofisticado. Hoy en día, SpyEye o Zeus utilizan técnicas de robo de información extremadamente sofisticadas, que nada tienen que envidiar a TheFlame. Por ejemplo, TheFlame es capaz de capturar la pantalla solo cuando aparecen ciertas aplicaciones (como ventanas de mensajería instantánea), exactamente igual que los troyanos bancarios que almacenan en imágenes las pulsaciones del teclado virtual de un banco. También permite obtener información del sistema, registro de las teclas... todo eso está ya al alcance de cualquier creador de malware de poca monta. Sin embargo, lo que lo diferencia es básicamente es nivel de especialización y diversificación: puede comunicarse con bluetooth con otros dispositivos, o grabar conversaciones con el micrófono del sistema. Si bien estas técnicas son perfectamente posibles (incluso existe un plugin para SpyEye que permite grabar con la cámara), es poco común en el malware masivo actual. No interesan por no suponer un medio de lucro directo
            
  • Está relacionado de nuevo, con países de Medio Oriente, como ocurriera con Duqu y Stuxnet.
       
  • TheFlame es tremendamente modular. Si Stuxnet o Duqu pesaban menos de 500k, todos los plugins de TheFlame pesan unos 20 megas. Esto le confiere una gran ambivalencia que le permite, si bien no estar diseñado para objetivos concretos, sí poder ser "configurado" para las necesidades de cualquier objetivo. Se podría definir como un "toolkit" de ataque, puesto que no se han encontrado evidencias de víctimas específicas en su código, como ocurrió con Stuxnet.
      
  • Usa intensivamente el cifrado y el código ofuscado, además de tener partes lógicas escritas en LUA, lenguaje utilizado para videojuegos. LUA es un lenguaje de scripting. Las partes "lógicas" están escritas en LUA, por ejemplo, las órdenes concretas. Luego las ejecuciones las hacen librerías en C. Todo esto hace que Kaspersky estime que estudiarlo por completo les llevará un año. Duqu y Stuxnet también usaban técnicas de programación "inusuales" y pesaban demasiado (alrededor de 500k, cuando un SpyEye "típico" es raro que pase de los 200k) . Con respecto al peso, hay que destacar que otro tipo de malware mucho menos sofisticado, habitualmente creado en Brasil, suele pesar varios megas también.

Fuente: Securelinst.com

¿Conclusiones?

Este tipo de incidentes dan pie a todo tipo de elucubraciones y fantasías. ¿Estamos ante una ciberguerra? ¿Debemos prepararnos para un apocalipsis cibernético? No lo sabemos. Por ahora, solo podemos concluir las características esenciales que han compartido las tres piezas de malware calificadas como "ciberarmas" desde 2010 e intentar definir qué las categoriza como tales. Por ejemplo, TheFlame es capaz de infectar un Windows 7 completamente parcheando. De lo que se deduce un una alta probabilidad de que contenga el exploit funcional de una vulnerabilidad desconocida hasta el momento. Al igual que Stuxnet, que contenía hasta cuatro 0-days para Windows, esto le hace muy potente. Le permite gran difusión sin estorbos: pocos sistemas se le resistirán. Esta es sin duda su mayor ventaja.

Como hemos indicado, se habla de que TheFlame ha pasado desapercibido varios años. Se está especulando mucho con respecto a cuándo apareció. La idea de que fue en diciembre de 2007 es simplemente por el nombre de un archivo (wavesup3.drv), pero esto no es definitivo. En VirusTotal la primera muestra que aparece catalogada como tal es del 15 de mayo de 2011, pero, a ciencia cierta, se están detectando (precisamente de Irán y Líbano) muestras de hasta 2010. Y aquí parece estar la otra gran clave. El hecho de que puedan espiar o campar a sus anchas no convierte a estos programas en ciberarmas, sino su capacidad de pasar desapercibidos. Ha sido detectado demasiado tarde. Esta, a nuestro entender, es una de las características que define de forma más acertada las llamadas "ciberarmas": son descubiertas mucho después de que hayan sido distribuidas. Stuxnet salió a la luz en junio de 2010, pero llevaba un año circulando. El núcleo de Duqu tenía fecha de compilación de 2010, aunque fue descubierto en septiembre de 2011. En el caso de TheFlame, se sospecha que podía haber sido creado igualmente en 2010 o incluso antes, en fechas similares a las de Stuxnet y Duqu (otro indicio por el que se cree que están relacionados). Por tanto, podíamos estar hablando de al menos dos años pasando totalmente desapercibido para las víctimas, investigadores y casas antivirus.

Ante esto, lo asombroso no es que existan este tipo de programas que permiten espiar, sino más bien, la posibilidad de que se puedan eludir durante tanto tiempo todas las medidas de seguridad conocidas. Y para conseguirlo, simplemente sea necesario huir de los lugares comunes del malware masivo.

Esto dice muy poco en favor de las medidas de seguridad que se están aplicando contra las amenazas actuales. Y podemos incluir en este saco desde el software antivirus, hasta las políticas de seguridad, pasando por los IDS o los cortafuegos, los administradores y los auditores (en el caso de que existan en los sistemas infectados…... que no han sido pocos). Todos han fallado, aun estado perfectamente capacitados para detenerlo o al menos detectarlo. Y cuando esto ocurre, es que algo se está enfocando de manera equivocada. Si bien ya tenemos problemas para mantener a raya el malware masivo, el que se sale un poco del cuadro preestablecido tiene todas las posibilidades de eludirlos con éxito y, por tanto, convertirse en "ciberarma". En general, quizás el problema es que seguimos todavía bajo el yugo de la "lista negra/lista blanca": bloqueamos lo que creemos que puede ser dañino o dejamos pasar lo que tenemos anotado que es benigno, y aplicamos indiscriminadamente este concepto para protegernos de todo a cualquier nivel... y este modelo, por sí solo, se está demostrando ineficaz.

Más información:

Researchers identify Stuxnet-like malware called 'Flame'

The Flame: Questions and Answers


Sergio de los Santos
Twitter: @ssantosv

lunes, 28 de mayo de 2012

Quinta lección del "algoritmo RSA" en el MOOC Crypt4you de Criptored: Mensajes no cifrables


Se encuentra disponible en el Massive Open Online Course MOOC de Crypt4you la quinta lección del curso El Algoritmo RSA, dedicada a los mensajes o números no cifrables.

Podrás encontrarla desde el acceso directo de la lección en el curso:
 
O bien como lección destacada en la sección En portada dentro en el home de este proyecto:

Lección 5: Mensajes no cifrables

Esta quinta lección está dedicada al estudio de los mensajes o números no cifrables, es decir aquellos números que aunque se cifren con RSA usando una clave pública o una clave privada, se transmiten en claro. Determinaremos en esta lección si esta característica de RSA es o no un motivo de preocupación.

Apartados de la Lección 5:
Apartado 5.1. ¿Qué son los mensajes no cifrables?
Apartado 5.2. Calculando los números no cifrables
Apartado 5.3. Minimizando los números no cifrables
Apartado 5.4. ¿Hay que preocuparse por estos números no cifrables?
Apartado 5.5. Test de evaluación de la Lección 5

La próxima entrega de este curso, la Lección 6 sobre "El Teorema del Resto Chino" en RSA, se publicará la primera semana del mes de junio de 2012.


Jorge Ramió, Alfonso Muñoz
Equipo Crypt4you

domingo, 27 de mayo de 2012

Nueva versión de Google Chrome corrige varias vulnerabilidades


Google ha publicado la versión 19.0.1084.52 de la rama estable de su navegador web Chrome para todas las plataformas (Windows, Mac, Linux y Chrome Frame). Esta nueva versión corrige trece vulnerabilidades en total: Dos de importancia media, nueve de alta y otras dos de importancia crítica.

Importancia media

  • CVE-2011-3104: Localizada en el motor gráfico Skia, podría provocar una denegación de servicio por lectura fuera de límites. Tiene un CVSS base de 5. Se da crédito a Inferno del Google Chrome Security Team.
      
  • CVE-2011-3111: Un fallo en la lectura en el motor Javascript Google V8 podría ser aprovechado para provocar una denegación de servicio. Tiene un CVSS base de 5. Esta vulnerabilidad se le reconoce a Christian Holler, que consigue 500 dólares por el Chrome Vulnerability Rewards Program.

Importancia alta

  • CVE-2011-3103: Causada por la recolección incorrecta de basura en el motor Javascript Google V8, podría ser aprovechada para provocar el bloqueo de la aplicación o potencialmente otros impactos no especificados. CVSS base de 7,5. Acreditada a Brett Wilson de la comunidad de desarroladores de Chromium.
      
  • CVE-2011-3105: Un error en el manejo del pseudo-elemento :first-letter en las hojas de estilo en cascada (CSS) podría provocar un error use-after-free. Podría ser aprovechado para provocar una denegación de servicio. Tiene una punuación CVSS base de 7,5. Se atribuye a miaubiz, a quien además se premia con 1.000 dólares por el Chrome Vulnerability Rewards Program.
      
  • CVE-2011-3107: Un error en la forma en la que se implementan las referencias de JavaScript para los plugins podría hacer que la aplicación terminase. Tiene una puntuación CVSS de 7,5. Acreditada a Dharani Govindan de la comunidad de desarrolladores de Chromium.
     
  • CVE-2011-3109: Vulnerabilidad que sólo afecta a Linux. Un fallo de invocación incorrecta de una variable sin especificar podría se usada para provocar que el prorama termine o potencialmente otros impactos al disparar un error en la interfaz de usuario. Su puntuación CVSS base es de 7,5. Se acredita a Micha Bartholomé, a quien se asignan 1.000 dólares por el Chrome Vulnerability Rewards Program.
       
  • CVE-2011-3110,CVE-2011-3112 y CVE-2011-3113: Descubiertas por nuestros antiguos compañeros MateuszJurczyk con contribuciones de Gynvael Coldwind, ambos del Google Security Team. Con una puntuación CVSS base de 7,5, 5 y 7,5 respectivamente, todas tratan fallos en la funcionalidad PDF de Google Chrome que pueden provocar una denegación de servicio parcial o potencialmente otros impactos.
      
  • CVE-2011-3114: Se podrían dar múltiples fallos de desbordamiento de memoria intermedia al usar las funcionalidades PDF que podrían usarse para provocar una denegación de servicio o potencialmente en otros impactos. Tiene una puntuación base CVSS de 7,5. Se acredita a ascarybeasts del Google Chrome Security Team.
       
  • CVE-2011-3115: Encontrada en el motor Javascript Google V8, podría ser usada por un atacante para provocar una denegación de servicio o potencialmente en otros impactos a través de vectores que activen el disparador 'type corruption'. CVSS base de 7.5 . Acreditada a Christian Holler.

Importacia crítica

  • CVE-2011-3106: Un error en la forma en la que se usa SSL en la implementación de los WebSockets podría provocar una corrupción en la memoria del sistema. Podría ser aprovechada para ejecutar código arbitrario. Puntuación CVSS base de 10. Acreditada a Dharani Govindan de la comunidad de desarrolladores de Chromium.
      
  • CVE-2011-3108: Un error use-after-free en la caché del navegador podría ser aprovechado para ejecutar código arbitrario. Tiene una puntuación CVSS de 10 y se acredita efbiaiinzinz, que además es recompensado con 1.337 dólares por el Chrome Vulnerability Rewards Program.

En total, se han repartido 4.837 dólares a través del Chrome Vulnerability Rewards Program.

Más información:

Stable Channel Update



Francisco López


sábado, 26 de mayo de 2012

Múltiples vulnerabilidades en Wireshark 1.x


Wireshark ha publicado tres boletines de seguridad informando de múltiples vulnerabilidades que afectan a las ramas 1.4.x y 1.6.x.

Wireshark es una aplicación de auditoría orientada al análisis de tráfico en redes. Su popularidad es muy elevada, puesto que soporta una gran cantidad de protocolos y es de fácil manejo. Además Wireshark es software libre (sujeto a licencia GPL) y se ejecuta sobre la mayoría de sistemas operativos Unix y compatibles, así como en Microsoft Windows.

Las tres vulnerabilidades publicadas tienen como impacto la denegación de servicio y como vector el uso de un paquete de trazas especialmente manipulado. A continuación una breve descripción por cada una de ellas:

  • wnpa-sec-2012-08: Varios disectores ('ANSI MAP', 'ASF', 'BACapp', 'Bluetooth' 'HCI', 'IEEE 802.11', 'IEEE 802.3', 'LTP' y 'R3') podrían provocar que la aplicación entre en un bucle infinito o lo suficientemente largo como para afectar a la disponibilidad de la aplicación.
     
  • wnpa-sec-2012-09: La aplicación podría cerrarse de forma inesperada debido a un error en la asignación de memoria en el disector "DIAMETER".
      
  •  wnpa-sec-2012-10: Debido a un error en el manejo de memoria en los procesos "SPARC" y "Itanium" la aplicación podría dejar de funcionar.

Estas vulnerabilidades se han solucionado en las versiones 1.4.13 y 1.6.8. Ambas actualizaciones pueden ser descargadas desde:

Más información:

Infinite and large loops in many dissectors

Wireshark DIAMETER memory allocation flaw

Wireshark memory alignment flaw

viernes, 25 de mayo de 2012

Posible método para clonar los tokens software RSA SecureID

Tras la filtración del algoritmo de SecurID el año pasado, aún no se conocía cómo se generaba la semilla inicial. Sin embargo el investigador Behrang Fouladi, de SensePost, ha publicado un estudio en el que se concreta cómo se calcula y dónde se almacena esta semilla en las versiones software de RSA SecurID. A partir de esta información, el número podría ser fácilmente clonado en un equipo ajeno al sistema de autenticación.

SecurID es uno de los productos estrella de RSA, compañía subsidiaria de EMC. Ofrece autenticación de doble factor, que consiste en complementar un PIN conocido por el usuario ("algo que se sabe") con un número generado por un dispositivo llamado token ("algo que se tiene"). Este número cambiaría tras un intervalo de tiempo determinado. La contraseña, por tanto, sería la concatenación del PIN y el número generado pseudo-aleatoriamente.

Una implementación diferente a este sistema es la versión software, que permite utilizar un sistema de escritorio, (smartphones o incluso tablets) como dispositivo generador de tokens. Para ello, utiliza un valor llamado semilla o seed, que junto al valor del tiempo convenientemente transformado, conforma la entrada del algoritmo que genera dicho número pseudo-aleatorio.

Fouladi ha aplicado ingeniería inversa sobre el almacenamiento de los valores semilla y su protección en la versión Windows de "SecurID software token". SecurID utiliza tokenstoreplugin.dll para relacionar un sistema operativo en una máquina concreta con el token mediante el valor DeviceSerialNumber. Este se construye a partir de dos valores relativamente fáciles de obtener en sistemas Windows: el nombre de host del sistema y el SID (SecurityIdentifier) del usuario que haya instalado la aplicación. En resumen, la expresión que lo calcula sería:

device_serial_number=Left(SHA1(host_name+user_SID+"RSA Copyright 2008"),10)

¿Y con esto bastaría?

En realidad, no para todos los escenarios. El DeviceSerialNumber sólo representa un sistema de protección ante la importación de tokens provenientes de otros sistemas.

RSA normalmente realiza la provisión del servicio a través de correo electrónico. Consiste en la descarga de un programa que, una vez instalado, lee el SID y el nombre de host de la máquina y muestra un DeviceSerialNumber, que el usuario enviará a RSA. En un segundo correo, se le proporcionará el fichero de configuración relacionado con ese DeviceSerialNumber. Un tercer correo contendría una contraseña para activar el token.

Por tanto, el único escenario posible para que este método por si sólo tenga éxito es aquel en el que un atacante remoto tuviera acceso a esta cadena de correos, ya sea física o remotamente. Una vez activado el token, este es protegido por otros sistemas anti-copia y necesitaría acciones adicionales.

La información de los tokens una vez activados se almacena en una base de datos SQLite llamada RSASecurIDStorage, totalmente accesible, pero cuyos datos sensibles (por ejemplo, la semilla) están cifrados. Se protege de la copia a través de dos valores también cifrados contenidos en la tabla PROPERTIES: DatabaseKey y CryptoChecksum.

Utilizando ingeniería inversa sobre estos, Fouladi también descubrió que relacionan la base de datos con el sistema donde se instala y su usuario, ya que para descifrar dichos valores se usa la clave maestra de ambos. Adicionalmente, la base de datos también se protege con Windows Data Protection API (DPAPI).

Pero estos dos "problemas" son eludibles por un atacante: el descifrado de datos protegidos por DPAPI es posible, usando http://dpapick.com, o simplemente usando la API CryptUnprotectData, y las claves maestras se pueden volcar desde el servicio de gestión de autenticación Windows LSASS. Así, se podría extraer el fichero de base de datos de un sistema e importarlo totalmente, con la semilla incluida, a otro dispositivo.


Pero, ¿no era esto ya posible?

. Dado un número pseudo-aleatorio visto por el atacante y la hora en que se obtuvo, era posible calcular el valor devuelto por el token en un momento dado usando el algoritmo que se filtró el año pasado.

La diferencia es que, si este nuevo proceso es funcional, cualquier persona con acceso físico a la máquina que corra SecurID Software token, o que haya comprometido esta a través de un troyano o rootkit, podría extraer las claves maestras del sistema y el fichero RSASecurIDStorage y crear desde cero el token, siendo sólo necesario conocer el PIN y rompiendo la autenticación de doble factor.

Más información:

A closer look into the RSA SecureID software token

RSA SecureID software token update

una-al-dia (18/03/2011) Comprometen la seguridad de RSA y roban información sobre el producto SecurID


Francisco López

jueves, 24 de mayo de 2012

Nuevas versiones del malware de la policía y cómo eludirlas


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 Mail.


Y, en ese nuevo navegador, ir hacia c:\windows\system32 y ejecutar un explorador.


Más información:

una-al-dia (21/06/2011) Vídeo: Troyano secuestra el ordenador en nombre de la policía nacional acusando al usuario de terrorista zoofílico

una-al-dia (28/02/2012) Vuelve el troyano que se hace pasar por la policía: Cómo protegerse (de verdad)

una-al-dia (02/03/2012) El virus de la policía "evoluciona" e impide el acceso en modo seguro

una-al-dia (06/03/2012) Más información sobre el virus de la policía

una-al-dia (09/03/2012) El malware de la policía aprovecha un exploit de Java "in-the-wild" y el secreto su "éxito"

una-al-dia (18/03/2012) WhitePaper: Estudio técnico del troyano de la policía




Sergio de los Santos
Twitter: @ssantosv

miércoles, 23 de mayo de 2012

Utilidad para vigilar el uso del Modo Protegido en Internet Explorer


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:

SOFTWARE\Microsoft\Internet Explorer\Low Rights\ElevationPolicy

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:

Por cierto, durante su elaboración descubrimos algo muy curioso:


Sergio de los Santos
Twitter: @ssantosv

martes, 22 de mayo de 2012

Nuevas versiones de SpyEye graban imágenes de sus víctimas


Dmitry Tarakanov de Kaspersky ha descubierto un nuevo plugin para SpyEye (una de las familias de troyanos bancarios más utilizados) que permite grabar a través de la cámara del ordenador imágenes del usuario mientras está siendo robado por el troyano.

Existen alrededor de 40 plugins diferentes para la rama 1.3 de SpyEye, que es la más usada en los últimos tiempos. Uno de los últimos detectados se denomina "flashcamcontrol.dll". Esta librería modifica los permisos de FlashPlayer para permitir a los documentos flash descargados desde cualquier página web, la grabación con la cámara y el micrófono sin pedir permiso al usuario.

Una vez infectado, cuando la víctima visita la página de su banco, descarga un fichero swf (flash) desde un punto controlado por el atacante y se inyecta en la web legítima del banco. Este fichero comenzará la grabación, enviándola a un servidor remoto a través del protocolo Real Time Messaging Protocol (rmpt). En realidad el atacante se asegura de que puede grabar con la cámara con otro fichero adicional llamado "camara_test.sfw", que pregunta al usuario por otra cámara cuando no puede grabar a través de la definida por defecto.

¿Por qué grabar al usuario?

Tarakanov se plantea la utilidad de grabar al cliente mientras está siendo robado. Hoy en día, la mayoría de los bancos piden al usuario un dato adicional de autenticación cuando realizan una transacción, ya sea un código de una tarjeta de coordenadas o el código devuelto en forma de SMS por el banco. Los troyanos han solucionado este "problema" bien modificando la página web que la víctima "ve" en su navegador para que requiera todas las coordenadas de la tarjeta, bien infectando también el teléfono móvil. La última modalidad, la "transferencia ficticia" implica que al usuario se le indica que debe hacer una transferencia de prueba usando el código que el banco le enviará al móvil. En este esquema, es en realidad la víctima la que está realizando una transferencia al atacante sin que lo sepa, a través de una interfaz simulada. Por tanto, ¿qué aporta grabar al usuario durante este proceso? Tarakanov afirma que se desea estudiar cómo reacciona el usuario ante este esquema de ingeniería social.

Pero en realidad todo son suposiciones. Puede ser desde simplemente una prueba que no sirva para nada en el futuro, o puede tratarse del primer paso hacia una estafa mucho más elaborada, donde el atacante desee obtener información adicional sobre su víctima: sexo, edad… quizás el atacante quiera saber el modelo del móvil de la víctima, o entorno en el que se realiza la estafa. También es posible que, como teoriza Tarakanov, quieran estudiar las reacciones. Con esto podrían mejorar su ingeniería social. Por ejemplo, si muchos usuarios infectados llaman al banco tras observar la modificación "no esperada" de la página web en su ordenador, están perdiendo una potencial "víctima". Así pueden conocer el punto débil de su esquema de ataque. Quizás no le interese tanto al atacante la imagen como el audio…

Lo interesante es que SpyEye y sus plugins siguen activos, desarrollándose y buscando nuevas vías con las que eludir los avances técnicos de autenticación de la banca electrónica. Ante la mejora de los dos factores de autenticación, a los atacantes les queda sobre todo trabajar en la ingeniería social, y este módulo puede que vaya encaminado hacia ese objetivo.

Más información:

Big Brother


Sergio de los Santos
Twitter: @ssantosv

lunes, 21 de mayo de 2012

Actualización de PostgreSQL para Red Hat Enterprise Linux server 5 y 6

Red Hat ha publicado dos actualizaciones, con importancia moderada, de los paquetes de "postgresql" y "postgresql84" para las versiones 5 y 6 de su producto Enterprise Linux Server.

La primera actualización, con código RHSA-2012:0677-1, afecta al paquete "postgresql" de la versión 5 de Red Hat Enterprise Linux Server y contiene la corrección de las siguiente vulnerabilidades:

* CVE-2012-0868: Un error de filtrado al generar un fichero con 'pg_dump' que podría ser aprovechado por un atacante remoto para ejecutar código SQL arbitrario y conseguir escalar privilegios.

* CVE-2012-0866: Debido a una falta de comprobación de permisos en los disparadores (triggers) en 'PostgreSQL' un atacante remoto podría ejecutar funciones para las que no tiene permisos usando un disparador especialmente manipulado para ello.

La segunda actualización, con código RHSA-2012:0678-1, afecta a los paquetes "postgresql84", para la versión 5, y "postgresql", para la versión 6 de Red Hat Enterprise Linux Server.  En esta se corrigen también las vulnerabilidades anteriores (CVE-2012-0868 y CVE-2012-0866) además de la siguiente:

* CVE-2012-0867: A causa de un error de validación del campo "Common Name" un atacante remoto podría llegar a suplantar la identidad de una entidad legítima usando un certificado especialmente manipulado. Red Hat recomienda actualizar los sistemas afectados vía Red Hat Network:

Más información:

Moderate: postgresql security update

Moderate: postgresql and postgresql84 security update


Daniel Vaca

domingo, 20 de mayo de 2012

Revelación de información en los routers Belkin N150 Wireless y Netgear WNDRMAC


Se han publicado dos vulnerabilidades para los routers Belkin N150 Wireless Router y Netgear Wireless Extreme (WNDRMAC) N600 que podrían ser utilizadas para revelar información sensible.

La primera vulnerabilidad en el router inalámbrico Belkin N150, podría permitir revelar información sensible. El fallo se debe a que el script 'login.stm' puede mostar el hash MD5 de la contraseña del administrador en la interfaz web del router.

Esta vulnerabilidad ha sido descubierta por Avinash Tangirala, y afecta a la versión F7D1301 v1 (01A), aunque también podrían verse afectados otras versiones y modelos. Existe un exploit para aprovecharla.

Por otra parte, Nathaniel Carew ha descubierto otra vulnerabilidad en el router Netgear Wireless Extreme (WNDRMAC) N600 que también podría ser utilizada para revelar información sensible.

En este caso, la vulnerabilidad está causada por la divulgación de las preguntas y respuestas utilizadas por la funcionalidad de restablecimiento de contraseñas, en el código fuente HTML devuelto por 'unauth.cgi' cuando esta funcionalidad se encuentra activada.


Como contramedida se recomienda desactivar la funcionalidad de restablecimiento de contraseñas.

Ninguna de estas vulnerabilidades tiene asignado identificador CVE, ni existe solución oficial por parte de los fabricantes.

Más información:

Belkin N150 Wireless MD5 Password Disclosure

Netgear WNDRMAC Exposure of Sensitive Information Vulnerability



Juan José Ruiz

sábado, 19 de mayo de 2012

Disponible la última lección de intypedia Funciones unidireccionales y hash

En el servidor Web de intypedia se encuentra disponible la Lección 14 de la Enciclopedia de la Seguridad de la Información con el título Funciones unidireccionales y hash, cuyo autor es el Dr. Hugo Krawczyk, investigador de IBM Estados Unidos, y que verá como último vídeo destacado en esa página Web:

En esta lección Alicia explica a Bernardo las características y usos de las funciones unidireccionales y los hash en criptografía, resaltando su importancia como primitivas de autenticación así como sus debilidades ante ataques y colisiones.

La lección tiene una duración de 14:56 minutos y está formada por 4 escenas o capítulos:
Escena 1. Funciones unidireccionales.
Escena 2. Funciones hash.
Escena 3. Resistencia a colisiones.
Escena 4. Consideraciones prácticas: procedimientos, criptoanálisis y consecuencias.

Como siempre, la lección viene acompañada por 3 documentos en pdf que pueden descargarse desde el sitio Web de intypedia: el guión, las diapositivas y ejercicios para autoevaluación.

En los próximos días estará disponible en el servidor Web de intypedia la versión en inglés de esta lección:



Jorge Ramió
Director de Intypedia
Alfonso Muñoz
Director Técnico de Intypedia