viernes, 30 de noviembre de 2012

El sentido común contra el malware (I)


Todo el mundo tiene claro que es necesario evitar el malware. Pero los consejos que se brindan al respecto vienen siendo los mismos desde hace muchos años. ¿Realmente tenemos claro cómo debemos prevenir infecciones y contra qué nos estamos intentando defender? ¿Basta con el sentido común?

La infección en Windows se ve como algo con lo que se debe convivir, y que debe ocurrir cada cierto tiempo. Los mismos consejos se perpetúan en el tiempo desde hace muchos años. Básicamente: "sentido común, antivirus y cortafuegos", como un mantra al que aferrarse pero que, por alguna razón, también se intuye que no sirve para nada: "al final cada cierto tiempo, hay que formatear". La experiencia demuestra que estos consejos no pueden ser los más adecuados por antiguos, por los niveles de infección actuales y porque no atacan el problema de raíz.

Parece existir un fallo de enfoque. Se entiende el proceso de detección y desinfección pero quizás no se tenga tan claro el proceso de infección y por tanto, luchamos contra el problema cuando ya ha llegado a reproducirse en el sistema. La detección del malware en el equipo por un antivirus, aunque sea temprana, no es una prevención real... es detección preventiva.

Imaginemos que queremos hacer un viaje a un país donde no se han erradicado ciertas enfermedades y en el que el riesgo de contraerlas es muy alto. Imaginemos que en vez de informarnos de cuáles son las enfermedades concretas, sus vías de contagio y vacunarnos, lo que hacemos es preparar una maleta llena de antibióticos de amplio espectro y analgésicos de todo tipo para cuando nos pongamos enfermos o lo intuyamos. Otro ejemplo: es como si una persona muy promiscua guardase en el armario un arsenal de medicamentos contra los efectos de decenas de enfermedades de transmisión sexual, pero no contemplara el preservativo como algo esencial en su estilo de vida, confiando en su sentido común y sus medicamentos.

Y aunque no lo creamos, todos somos muy "promiscuos" en la red, por todo lo que exponemos. Por tanto, igual que es necesario abordar en capas el bastionado de los sistemas o redes protegiendo cada estadio, la prevención del malware pasa por varias fases. La primera es ese (sobrevalorado) "sentido común" con muchos matices; en medio existe una amplia gama de herramientas además del cortafuegos (irrelevante en la mayoría de los casos de malware actual); y... la última es la del antivirus.

Las veremos en más detalle en la siguiente entrega.


Sergio de los Santos
Twitter: @ssantosv

jueves, 29 de noviembre de 2012

Descubierta puerta trasera en impresoras Samsung y DELL

Este lunes se hacía público un escueto boletín de seguridad del US-CERT (VU#281284) advirtiendo de la existencia, no documentada anteriormente, de una cuenta administrativa en el firmware de las impresoras Samsung (se sobrentiende de aquellas con conectividad LAN) y algunos modelos de DELL, relacionada con el protocolo SNMP.

Posteriormente, el investigador que reportó la vulnerabilidad (con CVE-2012-4964) ha proporcionado más datos al respecto. Según Neil Smith (@neilwillgettoit) y su particular investigación llevada a cabo sobre su propia impresora y posteriormente sobre los firmwares de otros modelos de Samsung, existiría una cuenta de administración ligada al protocolo SNMP (una community string de lectura y escritura), que proporcionaría de controlo total sobre el dispositivo.

La gama Samsung ML 2xxx se ve afectada por este problema
(Foto del modelo ML 2160)
SNMP es un protocolo de red dedicado a la administración de dispositivos que permite identificarlos y gestionarlos remotamente, alterar características internas e incluso actualizarlos vía firmware remoto.

Las "community strings" son credenciales de acceso, passwords en texto claro utilizados en las versiones del protocolo SNMP v1 y v2 que permiten administrar el nivel de acceso de usuario: una community como "public", por convenio sólo permitiría ver o gestionar determinada información no vital del dispositivo, dando sólo información. Por ello es conveniente cambiar los credenciales de los dispositivos o utilizar una versión de SNMP superior como la v3 que es mucho más segura.

En esta vulnerabilidad, el investigador ha descubierto que existe una "community string" de nivel administrativo, no documentada que permitiría el acceso y control de la impresora. El firmware de su impresora contenía la siguiente línea:

private static final String SECRET_PUBLIC = "s!a@m#n$p%c";

Esta community sirve tanto para lectura como para escritura, así que cualquier atacante tendría control total. Podría obtener información vital de la empresa, como los documentos internos impresos, realizar un reconocimiento de los dispositivos conectados a la red, montar un servidor SMB, enviar SPAM a través de SMTP... e incluso actualizar la impresora con un firmware especialmente manipulado a través de SNMP (con el MIB adecuado) y obtener algún tipo de shell.

Aunque no se ha comunicado un listado completo de las impresoras afectadas tanto de Samsung como DELL, desde nuestro laboratorio hemos podido comprobar algunos modelos afectados:


Series Samsung SCX-4xxx, 5xxx, 8xxx
Series Samsung ML-2xxx y ML-3xxx
Series Samsung CLX-3xxx
DELL 2335DN

Según el fabricante, con desactivar SNMP o utilizar la versión v3 es suficiente para impedir el acceso, aunque según la investigación el protocolo SNMP seguiría activado aun cuando se deshabilitara desde la utilidad de configuración. Se proporcionarán actualizaciones mediante firmwares para los diferentes modelos próximamente.

Desde nuestro laboratorio aconsejamos proteger el acceso remoto a cualquier impresora en red y activar los controles y filtros necesarios para el protocolo SNMP en entornos de producción. También actualizar todos los firmwares a los posteriores al 31 de octubre, si es posible.

Más información:

Details of the Samsung Printer SNMP Backdoor

Vulnerability Note VU#281284



José Mesa Orihuela

miércoles, 28 de noviembre de 2012

Google Chrome corrige siete vulnerabilidades

Google ha actualizado la nueva rama 23 de su navegador Chrome con la versión 23.0.1271.91, para todas las plataformas (Windows, Mac, Linux y Chrome Frame) que corrige siete nuevas vulnerabilidades con un nivel de gravedad medio-alto.

Las vulnerabilidades específicas de Chrome son las siguientes según el nivel de impacto:

  • Dos vulnerabilidades marcadas con un impacto alto: CVE-2012-5133 descubierta por @miaubiz y relacionada con los filtros gráficos SVG, y la otra CVE-2012-5134, relacionada con la librería libxml y reportada por Jüri Aedla (Google Chrome Security Team).
        
  • Tres de carácter medio: CVE-2012-5130 a través del motor grágico 2D "Skia", descubierta por Atte Kettunen del equipo universitario OUSPG. CVE-2012-5135 que afectaba al módulo de impresión, reportada por Fermín J. Serna (Google Security Team). Y el CVE-2012-5136, relacionada con la gestión de elementos de entrada HTML (Google Chrome Security Team).
        
  • Finalmente, una vulnerabilidad de gravedad baja (CVE-2012-5132) relacionada con el método de transmisión "Chunked transfer encoding" y descubierta por Attila Szász.


Google recuerda como viene siendo habitual, que parte de las vulnerabilidades solucionadas fueron detectadas a través de su proyecto público de detección de errores en memoria para aplicaciones escritas en C/C++: AddressSanitizer

Esta actualización está disponible a través del propio navegador vía Chrome Update automáticamente o desde el sitio oficial de descarga:

Más información:

Stable Channel Release and Beta Channel Update



José Mesa Orihuela

martes, 27 de noviembre de 2012

La nueva versión de Tor corrige un problema de denegación de servicio

La red de anonimato Tor ha sido recientemente actualizada añadiendo diversas mejoras y corrigiendo algunos problemas, entre ellos la prevención de una vulnerabilidad que podría generar una denegación de servicio.

Tor conforma una red descentralizada de nodos virtuales donde el tráfico viaja cifrado a través de túneles, permitiendo el anonimato de los usuarios que utilizan la red y sus servicios.

El fallo presente en la librería "relay.c" permitiría que un atacante enviara células "SENDME" especialmente manipuladas para alterar la prioridad del tráfico de células en los circuitos de Tor, superando el límite establecido por el propio control de flujo de la red y posibilitando el agotamiento de memoria en los nodos de acceso. Esto provocaría una denegación de servicio al caer esos nodos por falta de recursos.

La vulnerabilidad, que fue reportada en junio (bug 6252) y asignada a un CVE durante esta semana (CVE-2012-5573) ha sido solucionada oficialmente tras la publicación de la versión estable 0.2.3.25.

Los usuarios pueden descargarse las diferentes versiones actualizadas para cada sistema operativo desde:

Más información:

Tor DoS via SENDME cells

Bump to 0.2.3.25 – Release Notes



José Mesa Orihuela

lunes, 26 de noviembre de 2012

Denegación de servicio en Call Of Duty: Modern Warfare 3 y ejecución de código en CryEngine 3

Se ha descubierto una vulnerabilidad en el juego Call Of Duty: Modern Warfare 3 que podría provocar una denegación de servicio en los servidores públicos y privados utilizados para el modo multijugador. También un problema de ejecución de código en el motor gráfico CryEngine 3.

Call Of Duty: Modern Warfare 3 (CoDMW3) es un shooter o videojuego de disparos en primera persona ambientado en un futuro próximo. Es distribuido por Activision y se encuentra disponible tanto para PC como para las consolas. Cuenta con un modo historia para un solo jugador y un modo multijugador online.

CryEngine 3 es un motor gráfico desarrollado por Crytek y utilizado igualmente en multitud de plataformas. Se usa en en juegos como HomeFront 2 y Crysis 2.

Para el modo online, CoDMW3 se comunica principalmente a través del protocolo UDP y el puerto 27015 con mensajes cifrados y utiliza DemonWare para comprobar y autenticar a los usuarios. Cuando el servidor recibe un paquete querysessioninfo o queryserverinfo, lo descifra y envía al servidor DemonWare.

Existe un error de desreferencia a puntero nulo en el lado del servidor que podría causar que dicho servidor se bloqueara, causando de este modo una denegación de servicio.

Esta vulnerabilidad afecta tanto a los servidores públicos como privados del juego. Además los servidores públicos de CoDMW3 enumeran los servidores maestros que están en línea, por lo que un atacante podría utilizar esta información para producir un ataque de denegación de servicio en todos los servidores públicos de manera simultánea.

La vulnerabilidad ha sido descubierta por Luigi Auriemma y Donato Ferrante, quienes la presentaron en la conferencia Power of Community 2012 (POC2012) celebrada en Seúl a principios de noviembre.

En esa misma conferencia, Auriemma y Ferrante demostraron un problema de ejecución de código en CryEngine 3. A través de los servidores del juego Nexuiz, podían llegar a tomar el control de las máquinas de los jugadores. De esta vulnerabilidad no se han dado los detalles.

Más información:

Call Of Duty: Modern Warfare 3 null pointer dereference



Juan José Ruiz

domingo, 25 de noviembre de 2012

Vulnerabilidades en Novell File Reporter

Se han publicado varias vulnerabilidades que afectan a Novell File Reporter y que podrían permitir a un atacante remoto obtener información sensible y ejecutar código de forma remota con privilegios de SYSTEM.

Novell File Reporter es una herramienta que permite analizar los archivos almacenados en una red para determinar el tamaño, fecha de último acceso, ficheros duplicados, frecuencia de uso, etc. Este software está diseñado para analizar grandes cantidades de datos por lo que reparte la carga de trabajo entre el motor y los agentes NFR.

Se han publicado cuatro vulnerabilidades. Todas ellas se deben a errores encontrados en el componente "NFRAgent.exe" que se comunica mediante TPC por el puerto 3037. Son las siguientes:

  • Cuando maneja peticiones SRS, "NFRAgent.exe" no genera una respuesta de forma segura, copiando los datos del usuario en una memoria de longitud fija sin realizar una comprobación de límites. Esto podría causar un desbordamiento de memoria que un atacante remoto aprovecharía para comprometer el sistema e incluso ejecutar código con permisos de SYSTEM. Se le ha asignado el identificador CVE-2012-4956.
        
  • Al procesar peticiones /FSF/CMD para registros con NAME "SRS", OPERATION "4" y CMD "103", NFRAgent.exe podría permitir la recuperación de ficheros arbitrarios especificados en la etiqueta "PATH". Se ha identificado como CVE-2012-4957.
        
  • Al procesar peticiones /FSF/CMD para registros con NAME "FSFUI" y UICMD "126", NFRAgent.exe podría permitir la recuperación de ficheros arbitrarios especificados en la etiqueta "FILE". Esta vulnerabilidad, similar a la anterior, se ha identificado como CVE-2012-4958.
        
  • Al procesar peticiones /FSF/CMD para registros con NAME "FSFUI" y UICMD "130", NFRAgent.exe podría permitir cargar un fichero arbitrario en el host, especificándolo en la etiqueta "FILE". Esto podría permitir la ejecución de código arbitrario de forma remota y con privilegios de SYSTEM. Esta vulnerabilidad tiene asignado el identificador CVE-2012-4959.

Todas estas vulnerabilidades han sido descubiertas por Juan Vázquez y se han desarrollado varios módulos para Metasploit que las aprovechan.

Afectan a la versión 1.0.2 de Novell File Reporter y por el momento no existe parche oficial para solucionarlas.

Más información:

New 0day Exploits: Novell File Reporter Vulnerabilities






Juan José Ruiz

sábado, 24 de noviembre de 2012

Múltiples vulnerabilidades en Moodle


Se han publicado siete boletines de seguridad para Moodle que solucionan vulnerabilidades que podrían permitir la revelación de información sensible, secuestro de sesión, eludir restricciones de seguridad, y realizar ataques XSS.

Moodle es una aplicación web del tipo LMS (Learning Management System), escrita en PHP que se utiliza para la gestión de cursos en línea. Está publicada bajo licencia GNU GPL y ha sido traducida a más de 91 idiomas. Además de la comunicación entre profesorado y alumnos, dispone de distintas herramientas, como la subida de ficheros, calendario y foros.

Los siete boletines de seguridad de Moodle que se han dado a conocer son los siguientes:

  • MSA-12-0057 (CVE-2012-5471): cuando un usuario inicia sesión en Dropbox a través del repositorio de Moodle, dicha sesión permanece abierta hasta que se cierra el navegador a pesar de que el usuario se haya desconectado. Esto podría permitir que otros usuarios pudiesen acceder y utilizar los datos del primero. Ha sido descubierta por Alexander Bias.
       
  • MSA-12-0058 (CVE-2012-5472): existe un fallo en 'formslib.php' que podría permitir a un usuario remoto autenticado eludir restricciones de acceso modificando datos de un campo de un formulario ya enviado. El fallo ha sido reportado por Rossiani Wijaya.
      
  • MSA-12-0059 (CVE-2012-5473): un error de falta de filtrado en el módulo 'Database activity' podría permitir a un usuario ver la información de entradas creadas por miembros de otros grupos a los que él no pertenece a través de una búsqueda avanzada. Richard Meyer ha descubierto esta vulnerabilidad.
        
  • MSA-12-0060 Petr Škoda Jenny Donnelly han descubierto un error de falta de comprobación en la librería YUI 2 que podría permitir llevar a cabo ataques Cross-Site Scripting y ejecutar código HTML y javascript arbitrario en el navegador de un usuario en el contexto de un sitio afectado.
         
  • MSA-12-0061 (CVE-2012-5479): el plugin 'Portfolio' podría permitir la carga local de ficheros (Local File Inclusion, LFI) y ejecución de comandos de forma remota (RCE) a través de la respuesta de una llamada a la API especialmente manipulada. Cristóbal Leiva es el descubridor de este error.
        
  • MSA-12-0062 (CVE-2012-5480): Tabitha Roder ha descubierto un fallo en el módulo 'Database activity' de Moodle que podría permitir a cualquier usuario, incluso a los invitados, leer las entradas de otros usuarios.
        
  • MSA-12-0063 (CVE-2012-5481): Existe un fallo que permite revelar información en la página 'Check Permissions', al permitir que usuarios no administradores pudiesen ver los roles de todos los usuarios de la plataforma. ha sido descubierto por Jody Steele.


La mayoría de estas vulnerabilidades afectan a las versiones 2.1.x, 2.2.x y 2.3.x de Moodle. El boletín MSA-12-0058 no afecta a la rama 2.1, mientras que el MSA-12-0063 únicamente atañe a la 2.3. La rama 1.9 también se ve involucrada en el error reportado en el boletín MSA-12-0060.

Se encuentra disponible, en la página oficial, la última versión de Moodle que corrige las vulnerabilidades anteriores.

Más información:

MSA-12-0057: Access issue through repository

MSA-12-0058: Possible form data manipulation issue

MSA-12-0059: Information leak in Database activity module

MSA-12-0060: Cross-site scripting vulnerability in YUI2

MSA-12-0061: Remote code execution through Portfolio API

MSA-12-0062: Information leak in Database activity module

MSA-12-0063: Information leak in Check Permissions page

  

Juan José Ruiz

viernes, 23 de noviembre de 2012

Ejecución de código arbitrario en Opera 12

Opera Software ha publicado dos boletines de seguridad referentes a sendas vulnerabilidades que afectan a su navegador Opera. Éstas podrían ser explotadas de forma remota para revelar información sensible y ejecutar código arbitrario.

La primera vulnerabilidad, considerada crítica, se debe a un error de falta de comprobación de tamaño cuando Opera almacena la respuesta en un buffer, tras una petición HTTP. Esto podría causar un desbordamiento de memoria que podría ser aprovechado por un atacante remoto para provocar una denegación de servicio, e incluso ejecutar código arbitrario.

La otra vulnerabilidad es considerada de severidad baja. Se debe a un fallo al manejar las páginas de error que podría permitir determinar la existencia de archivos locales, revelando información que no debería ser accesible por estas páginas.

Por el momento no se ha asignado ningún identificador CVE a estas vulnerabilidades.

Ambas afectan a las versiones de Opera inferiores a la 12.11, que ha sido lanzada para corregir estas vulnerabilidades. Se puede descargar desde la página oficial.

Más información:

Advisory: HTTP response heap buffer overflow can allow execution of arbitrary code

Advisory: Error pages can be used to guess local file paths



Juan José Ruiz

jueves, 22 de noviembre de 2012

Vulnerabilidad en Instagram para iOS


Se ha descubierto una vulnerabilidad en Instagram que podría permitir a un atacante el acceso no autorizado al contenido y descargar o eliminar las fotos sin el consentimiento de la víctima.

Instagram es una aplicación gratuita, disponible para iOS y Android, que permite aplicar una serie de filtros, efectos y marcos a las fotografías tomadas y enviarlas a diferentes redes sociales para compartirlas.

Instagram realiza las comunicaciones a través de conexiones HTTP y HTTPS, siendo el método de autenticación una cookie estándar que se envía sin cifrar al servidor cuando el usuario inicia la aplicación Instagram. Es posible interceptar esta cookie (mediante un ataque Man-in-the-Middle, por ejemplo, por parte de un usuario en la misma red local) para acceder al servidor suplantando al usuario legitimo y poder realizar acciones sobre el contenido, tales como descargarlo o eliminarlo.

Este fallo de seguridad ha sido descubierto por Carlos Reventlov quien, tras ponerse en contacto con el desarrollador el 10 de noviembre  y obtener una respuesta automática, ha publicado la información acerca de la vulnerabilidad junto a una prueba de concepto como demostración, capaz de obtener la cookie y eliminar las fotografías del usuario.

Se ha comprobado que la última versión de Instagram 3.1.2 para iOS es vulnerable, aunque también podrían estar afectadas otras versiones y plataformas. Por el momento no existe solución oficial.

Más información:

Instagram 3.1.2 For iOS, Plaintext Media Information Disclosure Security Issue



Juan José Ruiz


miércoles, 21 de noviembre de 2012

Descubierto un nuevo rootkit para servidores Linux


Se ha descubierto un rootkit interesante para servidores Linux, que inyecta código en todas las páginas servidas por el servidor Proxy nginx, muy usado como "puerta" hacia Apache en servidores *nix en sitios de tráfico intenso.

Un usuario envió un correo a la lista de seguridad Full Disclosure afirmando que había descubierto sus sistemas Debian infectados por lo que parecía un "rootkit trabajando junto con nginx". Se trataba de un administrador que se había percatado de que los visitantes de su web estaban siendo redireccionados a sitios infectados. Varios tipos de petición hacia ese servidor web, devolvía un iframe inyectado en la página, que llevaba a un punto donde se intentaba infectar a los usuarios de Windows. El administrador descubrió también procesos ocultos (típico comportamiento de un rootkit) y los módulos del kernel responsables del problema, que adjuntó al correo de alerta para que pudiera ser estudiado.

Parece que el sistema de este administrador ha sido efectivamente comprometido (a nivel de root, al tratarse de un módulo para el kernel) para incluir un rootkit en él, y modificar el comportamiento de su servidor web. Así, todos los visitantes podían ser redirigidos a páginas de malware.

Nos encontramos pues ante una pieza más del puzle. Un nuevo método de distribución que implica una pieza de software interesante que previamente se desconocía. Se ha dado en llamar Rootkit.Linux.Snakso, y por ahora su detección es mínima (6 de 43 motores).

El principal problema para este rootkit es que si bien puede pasar desapercibido en el sistema, es muy fácilmente detectable por su propio funcionamiento: cualquier visitante de la web puede comprobar que se añaden iframes hacia ciertas webs sospechosas.

Cómo funciona

Está diseñado para atacar sistemas Linux de 64 bits y se ha compilado para la versión 2.6.32-5 que utiliza Debian Squeeze. Intercepta las llamadas a ciertas funciones del kernel para poder cumplir su función y, además, acepta instrucciones de un sistema central. Puede que esté en desarrollo aún. El atacante ha sido muy descuidado, porque el binario todavía contiene toda la información de "debug", y no ha sido "strippeado" (eliminada esa información). También se intuye que no es muy profesional. Algo interesante es que llega a muy bajo nivel para inyectar los iframes, sustituyendo la función de sistema tcp_sendmsg, así que el troyano modifica directamente los paquetes TCP que salen del servidor. Para saber qué inyectar, se conecta a su controlador con protocolo propio, protegido por contraseña cifrada.

Las IPs públicas que aparecen en el módulo son:
91.123.100.207
149.20.20.133
149.20.4.69
64.189.125.254

Como curiosidad, en vez de comprobar que la página servida ofrece un 200 para "inyectarse" (un OK en código HTTP) está programado para no mostrarse solo cuando se da un 403, 304 o la cadena "not found on this server" (o sea, un 404). Esta lógica es un poco extraña y seguro ha acelerado el proceso de descubrimiento.

Conclusiones

Los rootkits o el malware en Linux no son nuevos. La novedad consiste en que se ha creado un rootkit nuevo para entornos Linux, cuando lo habitual es nutrirse de código ya hecho. Otro asunto extraño es el aroma a "novato" de este rootkit. No parece un ataque dirigido, sino algo que apuntaba a infectar más sistemas. Sin embargo no cuenta con ningún mecanismo de reproducción. El atacante ha debido o bien tener acceso como root a la máquina infectada o el administrador ha quedado infectado a través de algún método que desconocemos. Hasta aquí, todo misterios.

Eliminando estos aspectos, el encuadre del ataque no es nada nuevo: los atacantes se nutren de servidores en cualquier plataforma (páginas comprometidas habitualmente) para infectar Windows. El "objetivo" de la infección es habitualmente Windows, pero no es extraño que el "medio" sea cualquier otra plataforma para maximizar su difusión.

Es, en realidad, un paso más allá en el sistema de distribución de malware. Si bien hasta ahora habíamos sido testigos de páginas comprometidas donde se añadían enlaces maliciosos, no eran comunes ataques en los que todo el sistema del servidor web se viese comprometido hasta sus entrañas... y mucho menos a través de un rootkit para Linux.

Más información:

linux rootkit in combination with nginx

HTTP iframe Injecting Linux Rootkit





Sergio de los Santos
Twitter: @ssantosv

martes, 20 de noviembre de 2012

Clave WPA2-PSK débil en routers Belkin


Se ha conocido el algoritmo de cifrado débil de las contraseñas WPA-PSK por defecto que implementan algunos routers Belkin. Un atacante podría conocer la contraseña WPA2-PSK si el dueño no ha modificado la que viene por defecto.

Muchos modelos de routers Belkin incorporan una red inalámbrica configurada por defecto, cuyo nombre (ESSID) y clave de acceso vienen impresos en una etiqueta en la parte inferior del dispositivo como se puede observar en la imagen siguiente:


Jakob Lell y Jörg Schneider han descubierto cómo se calcula clave WPA2-PSK preconfigurada en algunos modelos de routers. En realidad no es realmente aleatoria sino que calcula a partir de la dirección MAC del dispositivo. Cada uno de los ocho caracteres que componen la clave WPA2-PSK son establecidos (a partir del correspondiente carácter hexadecimal de la dirección MAC) mediante una tabla de sustitución estática.

Un atacante remoto podría obtener la clave WPA2-PSK por defecto en tan solo unas horas, mediante un ataque de fuerza bruta. Solo tendría que obtener un poco de tráfico cifrado.

Se ha comprobado que los modelos Belkin Surf N150 (F7D1301v1), N900 (F9K1104v1) y N450 (F9K1105V2) son vulnerables, aunque otros modelos también podrían verse afectados.

Esta vulnerabilidad fue reportada en el mes de enero a Belkin, y tras varios intentos de comunicación fallidos con el fabricante, los descubridores han decidido hacerla pública. Ante el silencio del fabricante, la solución es modificar los datos de acceso por defecto.

Más información:

CVE-2012-4366: Insecure default WPA2 passphrase in multiple Belkin wireless routers


Juan José Ruiz

lunes, 19 de noviembre de 2012

Cómo se veía el futuro del malware en 2002 (y III)


Han pasado más de 10 años desde un artículo titulado "The attack of the superworms" en el que, en 2002, se pronosticaba hacia dónde podía ir el malware y cuáles serían las características del código malicioso de hoy. ¿Acertaron?

Stephen Trilling, de Symantec, también decía entonces:

"Llevarán consigo un número de exploits dentro una "cabeza nuclear" [...] encontrarán algo que no esté parcheado y te pillarán. No creo que ninguna compañía esté totalmente parcheada [...] piensa en todas las vulnerabilidades que salen hoy cada día y en número de servidores de una gran organización. Los administradores no tienen tiempo."

Stephen Trilling
Seguía centrándose en los gusanos, como ente independiente que gestionaba todo el ataque y la infección. El malware está dividido hoy en servidor y cliente (o agente infector e infraestructura), donde es el servidor el que maneja la inteligencia y gestiona la explotación o recopila los datos robados. Existe poco malware que funcione por sí mismo en un entorno sin red. Lamentablemente, las circunstancias sobre las vulnerabilidades que retrata, siguen totalmente vigentes hoy en día.

Trilling  añadía:

"Con la mensajería instantánea, 
estás conectado todo el tiempo así 
que eres vulnerable todo el tiempo"

Acierta en su propuesta de a mayor conectividad, mayor exposición. Pero quizás no supieron prever la "nube" (y la exposición absoluta del navegador), y la conectividad de multitud de servicios a través de HTTP.

Lo que no predijeron

Por supuesto que es muy complicado acertar en estos aspectos, y no se puede reprochar absolutamente nada a quien se aventura a pronosticar por dónde irán las tendencias del futuro. Es complejo y solo sirve como ejercicio curioso.

Quizás se centraron en la autopropagación (gusanos) como estrategia ganadora del malware común en el futuro de 2002. El hecho es que hoy, los gusanos están "en extinción", incluso el malware que se autorreplica es escaso. Hoy la propagación es a través del navegador y la ingeniería social en el correo.

No supieron ver el malware para los dispositivos móviles como un futuro provechoso mientras que hoy el malware para Android sigue creciendo, a la espera de que se popularice Windows 8 en tabletas  y teléfonos. Esto puede traer un panorama interesante porque probablemente, se podrá infectar el teléfono desde el ordenador y viceversa. Tampoco se intuyó la explosión del malware "hágalo usted mismo" donde se proporcionan frameworks completos para crear tu propio troyano y distribuirlo o del tráfico de vulnerabilidades y del malware como servicio que todo esto acarrearía...

En resumen, sí parece que se intuía la capacidad técnica que podía llegar a desarrollar el malware, su relación con las vulnerabilidades y su persistencia en el sistema. Olvidaron quizás el aspecto práctico y el cariz de industria que ha tomado el mundo vírico. No es necesario ser vistoso ni grandes fuegos artificiales para funcionar y perdurar: como cualquier empresa, la industria del malware necesita inversión, investigación, gestión de recursos y eficacia, y para ello gestiona y explota los recursos actuales a su conveniencia. Pero... ¿fue un error centrarse demasiado en los puntos más "sensacionalistas"?

Lo que predijeron

Curiosamente, esa capacidad "fantasiosa" con la que describen las capacidades de los "gusanos", puede (con todas las salvedades posibles) incluso ajustarse a la predicción si jugamos en otra liga fuera del malware "común". Con Stuxnet como referente y el espionaje industrial, encontramos que "contenía" vulnerabilidades previamente desconocidas, actuaba como gusano, usaba certificados válidos para pasar desapercibido (algo al alcance de pocos) y robaba información confidencial... cualidades nombradas en cierta manera en ese artículo de 2002 y que reunía Stuxnet, descubierto en 2010. Incluso, el malware usado en la operación Aurora contra Google, se propagó por mensajería instantánea en 2009. Si bien algunos de los aspectos que nombraron podían sonar "futuristas" para 2002, este tipo de código (Duqu, Flame...) funcionaba así en algunos aspectos y sorprendieron a todos, incluso hace pocos años.

Curiosamente, esa figura de los "supergusanos" que dibujan está más cerca del cómo se desarrollarían los ataques exclusivos a objetivos concretos, que del malware común del día a día de los usuarios.

Más información:

Coming Soon: Attack Of The Super Worms



Sergio de los Santos
Twitter: @ssantosv



domingo, 18 de noviembre de 2012

Cómo se veía el futuro del malware en 2002 (II)


Han pasado más de 10 años desde un artículo titulado "The attack of the superworms" en el que, en 2002, se pronosticaba hacia dónde podía ir el malware y cuáles serían las características del código malicioso de hoy. ¿Acertaron?


George Bakos, del Institute for Security Technology Studies en la Universidad de Dartmouth en Hanover, decía:

"Los gusanos híbridos serán cada vez más comunes. Atacarán múltiples vulnerabilidades quizás en múltiples sistemas operativos. Establecerán un canal de comunicación con el controlador. También serán polimórficos para ocultar su presencia".

George Bakos
Bakos no iba desencaminado. Si bien hoy no son los propios gusanos los que atacan múltiples vulnerabilidades, sí que los kits de exploits son la norma. Estos alojan varias vulnerabilidades e intentan explotarlas según el perfil que les visita. Igualmente, si en vez de "sistema operativo" hablamos de "navegador", estos exploits están preparados para atacar a los más populares y sus plugins. A lo que no se ha llegado aún es la "equidad" en cantidad de malware para diferentes plataformas o al multiplataforma. Sigue ganando Windows por goleada, aunque existe un repunte importante en el malware para Android. Sobre el poliformismo, en esto quizás jamás podían imaginar hasta dónde se ha llegado. Ya no es solo que el malware "mute" sino que se crean prácticamente ficheros únicos para cada víctima, haciendo imposible además que funcione en otro sistema que no sea en el que se ha creado en primera instancia. Por supuesto, acertó de lleno con el canal de comunicación con el controlador (aunque esto ya se hacía entonces).

Dan Woolley, de SilentRunner, hablaba en 2002 de los "gusanos durmientes":

"Infectarán un sistema pero no atacará automáticamente sino que esperará una señal, que podría ser una fecha y hora predeterminada o la llegada de un cierto correo o por ejemplo la decimoséptima vez que el usuario se presenta en el sistema".

Esta afirmación es extraña. Esporádicamente han aparecido ejemplares que esperaban una fecha para su activación, pero no han pasado de la anécdota. No es práctico para ellos esperar a un momento determinado puesto que corren el riesgo de que se les descubra. Lo que sí ocurre actualmente es que el malware bancario no se activa hasta que lo necesita, o sea, cuando el usuario se presenta en su página de banca electrónica. Aunque existen troyanos bancarios que, nada más ser lanzados, muestran una pantalla al usuario pidiendo las contraseñas, los más sofisticados esperan pacientemente a que la víctima ingrese en su banco y es ahí cuando se activan. Esto es mucho más realista y reporta mejores beneficios. Sí es cierto que también se ha convertido en habitual que el malware no funcione cuando se cree "estudiado". Por ejemplo evitan las máquinas virtuales, lanzarse más de una vez desde una máquina con la misma IP, o esperan al siguiente reinicio para eludir los análisis automáticos. Woolley continúa:

"El gusano espera y resucita hasta que pienses que has limpiado tu sistema, sin que tengas ni idea de que están ahí. Los gusanos pueden ser muy silenciosos y pueden ocultarse en un fichero que ni siquiera sabes que existe. No es algo que cualquier script kiddie vaya a hacer. Es muy sofisticado"

El malware actual, desde hace años, no va asociado a archivos sino que son ficheros en sí mismos (DLL, drivers, ejecutables...). Y tampoco se ocultan más de lo necesario, puesto que no han encontrado un enemigo a la altura al que tener miedo (esto es, no temen demasiado a los antivirus). Si el "pueden ser muy silenciosos" significa que burlarían fácilmente la detección en el sistema... acertó de pleno. Lo cierto es que también estamos viviendo un resurgimiento del malware que infecta al MBR y efectivamente, eso los hace muy silenciosos y es una zona que muchos usuarios "ni siquiera saben que existe".

Veremos otras afirmaciones y las conclusiones en la siguiente entrega.

Más información:

Coming Soon: Attack Of The Super Worms




Sergio de los Santos
Twitter: @ssantosv

sábado, 17 de noviembre de 2012

Cómo se veía el futuro del malware hace 10 años (I)

Han pasado más de 10 años desde un artículo titulado "The attack of the superworms" en el que, en 2002, varios representantes de compañías de seguridad pronosticaban hacia dónde podía ir el malware y cuáles serían las características del código malicioso de hoy. ¿Acertaron?

2002 es la prehistoria del malware actual. Nada tenían que ver con el malware actual aquellos gusanos que principalmente aprovechaban los agujeros en Outlook Express o la ingeniería social para propagarse. La banca por internet no estaba tan popularizada, y lo más parecido a redes sociales se podía resumir en el Messenger y los chats. Veamos algunas predicciones de entonces:

Stephen Trilling, director de investigación de Symantec, afirmó en aquel momento:

"Veremos gusanos con una mayor sofisticación... con nuevas formas de difusión... que se podrán replicar a través de la mensajería instantánea... robarán documentos e información privada de cada ordenador. Crearán nuevos agujeros de seguridad en el sistema, y una vez que mantengan el control total de la máquina, usarla como base para lanzar nuevos ataques".

Por supuesto que el malware es más sofisticado, y por supuesto que existen nuevas maneras de difusión. Quizás, en aquel momento se centraron demasiado en la mensajería instantánea, por ser lo más parecido a las redes sociales del momento. Sin embargo, hoy la difusión hoy está clara: la web. Atrás quedaron los clientes de correo vulnerables y hoy la difusión por web (bien en páginas comprometidas o directamente de los atacantes) es el vector más peligroso, junto con el correo y la ingeniería social.

Stephen Trilling
La afirmación "robarán documentos e información privada" es curiosa. Lo que hoy consigue el malware común principalmente es robar dinero de la cuenta del banco, realizando transacciones no deseadas. Aunque ha existido malware que ha robado documentos, o bien se han tratado de ataques dirigidos o no han tenido demasiado éxito. Como mucho, el resurgir del ramsonware actual secuestra el sistema o los documentos alegando que necesita un rescate para desbloquearlo, pero la mayoría de las veces realmente no roba nada ni le interesan los documentos o fotos más allá de que se realice el pago del rescate.

"Crearán nuevos agujeros de seguridad" puede ser ambiguo. Algunas muestras desactivan el cortafuegos o eliminan algunas características de seguridad del navegador, pero solo si lo necesitan para funcionar "cómodamente" en el sistema. Pocos son los troyanos que dejan la puerta abierta al paso de otros ni mucho menos se han visto gusanos que "creen" vulnerabilidades en sí... otra cosa es que solo las conozcan ellos (0-day).

"Una vez con el control del sistema, la usarán para lanzar nuevos ataques". Esto ya se hacía entonces: una gran cantidad de gusanos usaban el sistema afectado para instalar un pequeño MTA y enviar spam. Hoy se sigue usando, pero menos.

Veremos otras afirmaciones en la siguiente entrega.

Más información:

Coming Soon: Attack Of The Super Worms



Sergio de los Santos
Twitter: @ssantosv

viernes, 16 de noviembre de 2012

Disponible la novena Lección del Algoritmo RSA en el MOOC Crypt4you de Criptored


Se encuentra disponible en el Massive Open Online Course MOOC Crypt4you de la UPM la novena lección del curso "El Algoritmo RSA", dedicada a los ataques por cifrado cíclico.

Puedes acceder a ella desde el acceso directo de la lección:

O bien la puedes ver como lección destacada en la sección "En portada" en la página principal del MOOC:

Esta lección tiene como objetivo demostrar que lo que nos han dicho sobre criptografía asimétrica y el uso de dos claves distintas en ambos extremos de una comunicación cifrada (de ahí su nombre de asimétrica) no es del todo cierto. También es posible recuperar el secreto a partir del criptograma y conociendo solamente los datos públicos de la clave de la víctima, que como sabemos están expuestos en un certificado X.509. Este ataque, basado en el cifrado cíclico, nos permitirá descifrar un criptograma y recuperar el secreto sin necesidad de conocer la clave privada de su destinatario.

Lección 9: Ataque por cifrado cíclico
Apartado 9.1. Ataque al secreto mediante cifrado cíclico
Apartado 9.2. Incidencia del valor capturado en el ataque
Apartado 9.3. Incidencia de la clave pública e en el ataque
Apartado 9.4. Ataque por cifrado cíclico a claves con primos seguros
Apartado 9.5. Test de evaluación de la Lección 9
Apartado 9.6. Datos estadísticos de esta lección
Apartado 9.7. Encuesta

La próxima y última entrega de este curso sobre RSA, Lección 10 de título "Ataque por paradoja del cumpleaños", se publicará en diciembre de 2012.

Se recuerda la existencia de esta encuesta online:


Jorge Ramió, Alfonso Muñoz
Equipo Crypt4you

jueves, 15 de noviembre de 2012

Cifrado débil de contraseñas en productos Huawei


Huawei es un fabricante chino de equipos destinados a la gestión de redes y telecomunicaciones, aunque últimamente están adentrándose en el mundo de los smartphones y las tablets. Se ha descubierto que cifra las contraseñas de los productos de manera muy débil.

Hay diferentes maneras de almacenar contraseñas por parte de los dispositivos y sistemas. Una muy común es utilizar un hash de la contraseña. En el momento de verificar si un usuario es quien dice ser, a la contraseña introducida se le aplica la misma función hash que se usó a la hora de su almacenamiento. Si la cadena resultante es igual a la almacenada, se valida. Con este sistema no se guarda la contraseña en claro en ningún momento.

También es muy común usar "sal" para generar estos hashes. Así, una de las entradas de la función hash sería la clave y otra la "sal", (que sólo se trata de ciertos bit aleatorios). Con esto se consiguen mitigar la eficacia de los ataques por diccionario.

Huawei no usa ninguno de estos métodos. El problema, descubierto por Roberto Paleari e Ivan Speziale reside en que los dispositivos usan un cifrado simétrico (algoritmo DES) con una misma clave de cifrado compartida entre todos los dispositivos ('\x01\x02\x03\x04\x05\x06\x07\x08'). No se trata de una vulnerabilidad como tal, sino de un fallo de diseño por parte del fabricante por usar contraseñas comunes y no aleatorias para cada dispositivo.

Los investigadores han publicado este código en Python para extraer las contraseñas en claro, llamando a la función 'decrypt_password'

from Crypto.Cipher import DES

def decode_char(c):
    if c == 'a':
        r = '?'
    else:
        r = c
    return ord(r) - ord('!')

def ascii_to_binary(s):
    assert len(s) == 24

    out = [0]*18
    i = 0
    j = 0

    for i in range(0, len(s), 4):
        y = decode_char(s[i + 0])
        y = (y << 6) & 0xffffff

        k = decode_char(s[i + 1])
        y = (y | k) & 0xffffff
        y = (y << 6) & 0xffffff

        k = decode_char(s[i + 2])
        y = (y | k) & 0xffffff
        y = (y << 6) & 0xffffff

        k = decode_char(s[i + 3])
        y = (y | k) & 0xffffff

        out[j+2] = chr(y       & 0xff)
        out[j+1] = chr((y>>8)  & 0xff)
        out[j+0] = chr((y>>16) & 0xff)

        j += 3

    return "".join(out)

def decrypt_password(p):
    r = ascii_to_binary(p)

    r = r[:16]

    d = DES.new("\x01\x02\x03\x04\x05\x06\x07\x08", DES.MODE_ECB)
    r = d.decrypt(r)

    return r.rstrip("\x00")


El algoritmo de cifrado usado es DES con ECB (Electronic codebook), que es el método más simple al usar el algoritmo DES.

En primer lugar el algoritmo transforma los caracteres ascii de la contraseña cifrada a binario (función ascii_to_binary), y posteriormente se queda con los 16 primeros bytes, eliminando el resto.

A continuación aplica el descifrado del algoritmo DES en modo ECB con la clave \x01\x02\x03\x04\x05\x06\x07\x08 y elimina los caracteres NUL del final de la contraseña.

El error ha sido confirmado en los productos de la familia Quidway y en los CX600 (routers y switches), aunque puede existir en más productos afectados.

En el comunicado oficial delfabricante se recomienda, como remedio temporal, limitar el acceso a los routers a los usuarios dentro de la red interna, gestionar estrictamente los privilegios de las cuentas y cambiar las contraseñas con regularidad.

El fabricante ha asignado la referencia Huawei-SA-20120827-01-CX600 al fallo.

Más información:

Seclists.org - Weak password encryption on Huawei products

Huawei - Updated Security Advisory on the Risk of Password Being Cracked Due to DES Encryption Algorithm


Antonio Sánchez