Las llaves de memoria USB propagan un virus por millones de ordenadores

‘Conficker’ infecta discos duros externos y carpetas compartidas.

Hacía cuatro años que ningún virus informático lograba infectar tal cantidad de ordenadores como Conficker, también conocido como Downadup, un gusano que ha hecho saltar las alertas de los observatorios de seguridad digital de medio mundo. Este virus ha conseguido colarse en cerca de 10 millones de ordenadores, según los últimos datos de la compañía F-Secure, una virulencia que no se recordaba desde los tiempos del virus Sasser o Bluster en 2005.

El Instituto Nacional de Tecnologías de la Comunicación (Inteco) calcula que en España hay alrededor de 7.500 equipos que pueden estar expuestos a la infección, sólo a través de Internet. “Por lo general en Inteco enviamos una alerta de este tipo una vez al año, pero en 2009 ha llegado muy pronto”, comenta Marcos Gómez, subdirector de e-Confianza de Inteco, que no duda en clasificar a Conficker entre la lista de virus más dañinos.

El problema de Conficker es que utiliza tres vías para propagarse. La primera es un fallo de seguridad de Windows, que los técnicos denominan vulnerabilidad. El virus es capaz de colarse en los ordenadores usando esa “puerta abierta” del sistema operativo de Microsoft para inutilizar ciertas funcionalidades de la máquina. En un primer momento, el usuario no suele notar nada (quizás detecte cierta lentitud en su PC) pero su ordenador se convierte en un foco de infección.

La buena noticia es que Microsoft publicó el parche que corrige este fallo de seguridad en octubre de 2008. “Pensamos que el nivel de ataque no debe ser muy alto pues Windows tiene un sistema de actualizaciones a través de Internet que instala automáticamente todas las correcciones de seguridad. La vulnerabilidad es de octubre lo que nos hace pensar que son muy pocos los usuarios que no han tenido la opción de poner al día su equipo”, explica Luis Miguel Oliva de Microsoft Ibérica, quien asegura que su compañía no tiene los mecanismos para cuantificar cuántos ordenadores en España no se han instalado este parche.

Pero hasta con un Windows totalmente actualizado, los ordenadores están expuestos a Conficker pues este virus se ha inspirado en la técnica de los primeros ataques informáticos y utiliza para propagarse ya no los disquetes, pero sí las memorias externas tipo USB, las que se utilizan en los móviles, los iPods o en cualquier reproductor MP3. En cuanto el ordenador infectado detecta que se ha instalado un sistema de almacenamiento externo, el virus salta directamente al dispositivo de modo que infectará el siguiente equipo al que vaya a ser conectado.

“Ésta puede ser la vía más problemática pues las empresas no pueden controlar todos los lápices USB que se conectan en su organización de una manera centralizada”, observa Luis Corrons, director técnico de PandaLabs, quien dio la alerta naranja ayer para advertir sobre el también llamado Downadup.

La tercera vía de infección son los archivos compartidos que las compañías suelen tener en sus redes. El virus detecta estos archivos comunes a distintos departamentos, se instala en ellos e infecta a cualquier equipo que entre en estos documentos…[]

Fuente elpais.com

Conficker o Downadup, cabeza de turco

Conficker, también conocido como Downadup, ha saltado a los medios generalistas activando alarmas. La combinación de ciertas técnicas le ha permitido conseguir un buen número de infecciones. Pero no más que los cientos de miles de ejemplares de malware 2.0 que infectan hoy en día a la mayoría de los sistemas Windows. Conficker ha jugado bien sus cartas, pero no es una epidemia mayor que cualquier otra familia de malware existente. Quizás ese parecido con los troyanos antiguos, esa identificación con la imagen de virus de toda la vida que todavía muchos usuarios conservan como si fuese el panorama actual, ha permitido a este gusano aparecer como estrella mediática fácilmente señalable. Conficker es una cabeza de turco que no aporta realmente novedades al mundo del malware, ni por técnica ni por volumen, pero que por ciertos intereses, se ha convertido en una “estrella mediática”.
Conficker ha jugado bien sus cartas en su segunda versión, explotando varias vías de infección:

* Adivina contraseñas de las redes compartidas. Esto le ha permitido eludir cortafuegos en redes internas. Además revela la debilidad de muchas contraseñas usadas por los administradores.

* Se copia y ejecuta a través de memorias USB y dispositivos extraíbles. Para los administradores de redes supone un verdadero problema evitar de forma eficaz la proliferación de memorias USB que viajan de un sistema a otro. Para colmo, una mala política de seguridad que permite la ejecución automática de cualquier archivo almacenado en la memoria, y probablemente unos permisos inadecuados en el sistema, hacen el resto.

* Aprovecha vulnerabilidades. Conficker comenzó aprovechando una vulnerabilidad muy peligrosa que permitía ejecución de código sin intervención del usuario. Sin embargo la proliferación de cortafuegos ha evitado que Conficker llegue a ser ni de lejos como Blaster, por lo que su adaptación ha sido clave.

* Ingeniería social: El gusano aprovecha la autoejecución pero de una forma muy astuta. Disfrazándose como una de las opciones que aparecen en el menú de Windows cuando se inserta un dispositivo extraíble. Un usuario despistado creerá que está intentando explorar el dispositivo cuando en realidad ha ejecutado el ejemplar.

* Malware 2.0: Aunque sus técnicas de infección en general no sean las más usadas últimamente, sí se sirve de características claras del malware 2.0, como la descarga de componentes (tanto archivos de configuración como otros ejecutables) desde servidores web, convirtiéndose así en toda una infraestructura y no en un gusano autocontenido tradicional.

Uno de los principales enemigos de este gusano es que es fácilmente identificable por las casas antivirus. Los niveles de detección son aceptables incluso por firmas. Además, la “herramienta de eliminación de solftware malintencionado” de Microsoft incluye ya una firma para eliminar sistemas infectados. Nada que ver con el malware que es reconocido por una pequeña cantidad de motores durante meses, y que componen el grueso del verdadero panorama vírico actual…[]

Fuente hispasec.com

El año de las “grandes catástrofes” en Internet

Si por algo se ha caracterizado (y se recordará) 2008 es por convertirse en el año de las grandes catástrofes en Internet, con el descubrimiento de hasta cinco graves vulnerabilidades que hacían tambalearse los cimientos de la Red. En contraste, durante el año, la mayoría de los atacantes han seguido valiéndose sobre todo de fallos “tradicionales”.
El “despiste” de Debian

En mayo se descubre que el generador de números aleatorios del paquete OpenSSL de Debian es predecible. Esto hace que las claves generadas con él ya no sean realmente fiables o verdaderamente seguras. Alguien (por error) del equipo de Debian eliminó en 2006 una línea de código en el paquete OpenSSL de Debian que ayudaba a generar la entropía al calcular el par de claves pública y privada.

Kaminsky y los DNS

El 8 de julio de 2008 se publica una actualización coordinada para la mayoría de los dispositivos en Internet que utilizan DNS. Ha sido descubierta una vulnerabilidad inherente al protocolo que permite falsificar las respuestas DNS y, por tanto, redireccionar el tráfico. Cisco, Microsoft, BIND… todos publican una nueva versión o actualizan sus sistemas para solucionar un misterioso fallo. Dan Kaminsky es el responsable de orquestar la macroactualización. Thomas Dullien se aventura semanas después a publicar en su blog su particular visión de lo que podía ser el problema descubierto por Kaminsky, sin tener conocimiento previo de los detalles. Y no se equivoca en su teoría: es posible falsificar (a través del envío continuo de cierto tráfico) los servidores autorizados de un dominio.

Espionaje a “gran escala” con BGP

En agosto se habla de nuevo de la mayor vulnerabilidad conocida al demostrar Tony Kapela y Alex Pilosov una nueva técnica (que se creía teórica) que permite interceptar el tráfico de Internet a una escala global. Se trata de nuevo de un fallo de diseño en el protocolo BGP (Border Gateway Protocol) que permitiría interceptar e incluso modificar todo el tráfico de Internet no cifrado. BGP es un protocolo que se utiliza para intercambiar tablas de enrutamiento entre sistemas autónomos (AS). El problema es que nunca se ha llegado a idear un sistema que realmente autentique a ambas partes, y los routers estén así seguros de que la información recibida desde un AS es legítima y viene del sitio adecuado.

La denegación de servicio “perfecta”

Por cuarta vez en el año, se habla de la mayor vulnerabilidad encontrada en la Red. La compañía sueca Outpost24 dice que descubrió en el 2005 (aunque lo saca a la luz 3 años después, posiblemente animada por los otros acontecimiento) varias vulnerabilidades de base en el mismísimo protocolo TCP/IP que podrían permitir la caída de cualquier aparato con comunicación TC en la Red. Es la llamada “denegación de servicio de bajo ancho de banda”. Aunque todavía no se conocen los detalles, todo son conjeturas. Dicen no conocer una implementación de la pila que no sea vulnerable. La información sobre lo que se da en llamar Sockstress se estanca. Finalmente no ofrecen los detalles prometidos aunque pueden demostrar su eficacia.

¿El fin del WiFi?

A principios de octubre se publica que la compañía rusa ElcomSoft había conseguido reducir sustancialmente el tiempo necesario para recuperar una clave de WPA, ayudándose de tarjetas gráficas NVIDIA y fuerza bruta. Se trata más de una maniobra de publicidad que una vulnerabilidad real. Sin embargo poco después Tews y Beck encuentran un problema inherente a una parte de WPA con el cifrado TKIP. Aunque la noticia es exagerada en medios, realmente se trata de una prueba de concepto que no permite recuperar la contraseña ni influye al método de autenticación. La técnica está limitada a descifrar paquetes concretos o inyectar nuevos (y sólo una pequeña cantidad) de tamaño reducido. Aun así parece el principio del fin para WPA y un acicate para pasar a WPA2.

Problemas en IPv6

En julio también se descubrió un problema en todas las implementaciones del protocolo Neighbor Discovery Protocol (NDP) para detectar nodos IPv6. Un atacante podría interceptar tráfico privado. Todos los grandes fabricantes deben actualizar.

Los ataques más usados

Aunque se han detectado ataques a servidores SSH que se sospecha estaban relacionados con el problema de Debian y desde China se han observado ataques contra la vulnerabilidad DNS descubierta por Kaminsky, del resto de graves vulnerabilidades no se tiene constancia de que estén siendo aprovechadas al menos de forma masiva.

En realidad, los ataques masivos del “día a día” que se han sufrido este año han tenido su origen una vez más en vulnerabilidades “tradicionales” que permiten ejecución de código en software popular. Las vulnerabilidades que más han sido aprovechadas de forma masiva en 2008 (aunque no las únicas, sí las de mayor impacto) han sido:

En enero, los atacantes aprovechan de forma masiva una vulnerabilidad en RealPlayer.

En febrero se descubre que un fallo en Adobe Acrobat/Reader 8 está siendo aprovechado para infectar sistemas. También aprovecharían otra vulnerabilidad para infectar a través de archivos PDF en noviembre .

En abril, una vulnerabilidad de ejecución de código en el motor GDI de Windows.

En mayo, un problema en el reproductor Flash de Adobe…sigue

Fuente hispasec.com

Revealed: The Internet’s Biggest Security Hole
http://blog.wired.com/27bstroke6/2008/08/revealed-the-in.html

IPv6 implementations insecurely update Forward Information Base
http://www.kb.cert.org/vuls/id/472363

La familia de malware DNSChanger instala “simuladores de DHCP” en la víctima

Hace unos días, tanto el SANS como distintas casas antivirus advertían de un comportamiento más que curioso en la vieja conocida familia de malware DNSChanger. Esta ha evolucionado sustancialmente: Comenzó con el cambio local de la configuración de servidores DNS en el sistema (para conducir a la víctima a los servidores que el atacante quiera). Ha llegado hasta el punto de instalar una especie de servidor DHCP e infectar así a toda una red interna. Los servidores DNS que instala el malware suelen estar en la red conocida como UkrTeleGroup.

La familia DNSChanger

Una característica interesante de DNSChanger es que es una de las familias que más han atacado a sistemas Mac, además de a Windows. Entre otras muchas formas de toparse con ellos, se suelen encontrar en servidores eMule, camuflados bajo la apariencia de otros programas.

Es una familia conocida desde hace unos tres años. Se caracterizan por modificar los servidores DNS de la víctima a la que infectan. De esta forma, la asociación IP-Dominio queda bajo el control del atacante, de manera que la víctima irá a la IP que el atacante haya configurado en su servidor DNS particular. Normalmente, se confía en los DNS de los ISP, pero si se configura cualquier otro, realmente la resolución queda a merced de su administrador, cualesquiera que sean sus intenciones.

DNSChanger comenzó modificando la configuración del sistema en local, de forma que cambiaba los servidores DNS del ISP de la víctima por otros controlados por el atacante. Después, el malware evolucionó hacia la modificación del router ADSL de la víctima. Buscaba la “puerta de enlace” del sistema, que suele corresponderse con el router, y realizaba peticiones o aprovechaba vulnerabilidades de routers conocidos para modificar estos valores. Así el usuario se veía afectado por el cambio pero de una forma mucho más compleja de detectar. Además, también se verían afectadas el resto de las máquinas que tomaran estos valores del propio router.

Dando un paso más allá

La última evolución observada implica la instalación en la víctima de un pequeño servidor DHCP. Este es el protocolo usado en las redes locales para que cuando un sistema se conecta a la red, el servidor lo reconozca y le proporcione de forma automática los valores necesarios para poder comunicarse (dirección, ip, puerta de enlace…). Habitualmente también proporciona los valores de los servidores DNS que haya establecido el administrador o el router.

El malware instala un driver que le permite manipular tráfico Ethernet a bajo nivel, o sea, fabricar paquetes de cualquier tipo. Con esta técnica simula ser un servidor DHCP. Cuando detecta preguntas de protocolo DHCP legítimas de algún sistema en la red, el malware responde con su propia configuración de DNS, de forma que el ordenador que acaba de enchufarse a la red local, quedaría configurado como el atacante quiere, y no como el administrador ha programado. El atacante confía en la suerte, pues el servidor DHCP legítimo de la red, si lo hubiese, también respondería. Quien llegue antes “gana”. Consiguen así infecciones “limpias”, pues es complicado saber quién originó el tráfico si éste no es almacenado y analizado. Además, con este método se pueden permitir realizar muchos otros ataques en red local con diferentes impactos.

¿Qué valores DNS introduce el malware?

DNSChanger es una familia que necesita de una importante infraestructura para que sea útil. Los servidores DNS (bajo el control de los atacantes) de los que se vale, los que modifica en el usuario, suelen estar alojados en la compañía ucraniana UkrTeleGroup, bajo el rango de red 85.255.x.y. Casi un 10% de todas las máquinas en ese rango de direcciones se corresponden con servidores DNS públicos que no contienen las asociaciones legítimas de domino y dirección IP. En ocasiones utilizan el servidor DNS para asociar dominios a la IP reservada 127.0.0.1, como es el caso del servidor de descargas de Microsoft download.microsoft.com. Con esto se consigue que la víctima no pueda actualizar el sistema operativo con parches de seguridad. Curiosamente, al parecer, las direcciones de actualización de Apple no están bloqueadas (a pesar de que suele afectar a este sistema operativo). También se bloquean un buen número de páginas de actualizaciones de casas antivirus.

Algunos de estos servidores DNS (ATENCIÓN: no configurarlos en el sistema bajo ningún concepto) son:

85.255.122.103, 85.255.113.114, 85.255.122.103, 85.255.112.112…[]

Fuente hispasec.com

Rogue DHCP servers
http://isc.sans.org/diary.php?storyid=5434

DNSChanger: One Infection, Lots Of Problems
http://www.avertlabs.com/research/blog/index.php/2008/12/16/dnschanger-one-infection-lots-of-problems/

Acceso remoto a los dispositivos Linksys WVC54GC

Se han encontrado dos vulnerabilidades en los dispositivos Linksys WVC54GC que podrían ser aprovechadas por un atacante remoto para acceder a información sensible, causar una denegación de servicio o ejecutar código arbitrario, pudiendo comprometer por completo el dispositivo.
El dispositivo “WVC54GC Compact Wireless-G Internet Video” se trata de una videocámara inalámbrica con servidor web incorporado que se puede conectar a la red local o directamente a Internet. El producto pertenece a la compañía Linksys, que se trata de una filial de la estadounidense Cisco Systems dedicada a las PyMEs.

Los problemas de seguridad encontrados serían los siguientes:

* La primera vulnerabilidad está causada porque el dispositivo enviaría la información de su configuración inicial en texto claro a través de la red. Esto podría ser aprovechado por un atacante remoto para al interceptar el flujo de vídeo enviado, acceder a la configuración de la red (ssid, usuarios y claves WPA o WEP, servidores DNS, etc.) o causar una denegación de servicio accediendo al firmware del dispositivo. El atacante podría aprovecharse de la vulnerabilidad por medio de un paquete especialmente manipulado enviado al puerto UDP 916, utilizado para la administración del dispositivo.

* El segundo fallo está causado por un error de límites que provocaría un desbordamiento de búfer basado en pila en el método “SetSource” del control ActiveX de NetCamPlayerWeb11gv2 (NetCamPlayerWeb11gv2.ocx). Esto podría ser aprovechado por un atacante remoto para ejecutar código arbitrario y hacerse con el control del dispositivo, por ejemplo si un usuario visita una página web especialmente manipulada…[]

Fuente hispasec.com

 

http://www.linksys.com/servlet/Satellite?c=L_Download_C2&childpagename=US%2FLayout&cid=1115417109974&packedargs=sku%3D1134691947479&pagename=Linksys%2FCommon%2FVisitorWrapper

USCERT Vulnerability Note VU#528993: Linksys WVC54GC wireless video camera vulnerable to information disclosure.
http://www.kb.cert.org/vuls/id/528993

Vulnerability Note VU#639345: Linksys WVC54GC NetCamPlayerWeb11gv2 ActiveX control stack buffer overflow.
http://www.kb.cert.org/vuls/id/639345

0-day en Internet Explorer 7

Un día antes del segundo martes del mes de diciembre un mensaje en un foro chino hacía pública una vulnerabilidad en Internet Explorer 7 -se acredita descubierta al grupo chino ‘KnownSec’-. No existe parche oficial disponible, no necesita interacción por parte del usuario y permite, si consigue explotar el fallo, ejecutar código arbitrario con los permisos del usuario.
Estamos por lo tanto ante un 0-day que solo ha tardado unas pocas horas en ver como se multiplicaban los exploits públicos capaces de infectar a un usuario con solo visitar un sitio web malicioso. Eso sin tener en cuenta la probable explotación semanas atrás de una pieza, que con tales características, cotiza muy alto en el mercado del malware.

La vulnerabilidad reside en el manejo de etiquetas XML que efectúa Internet Explorer. En los análisis de algunos exploits se ha hallado un vector común de ataque. Sin entrar en detalles, usa XML para incluir código HTML a la vez que provoca una corrupción de memoria que es aprovechada con javascript para volcar una cadena que contiene el shellcode, el cual descargará un binario que a su vez descarga componentes que ensamblan un troyano.

Microsoft ha informado que se encuentra trabajando en una solución y que en breve se podrá disponer de una actualización, probablemente será, sin no cambian las cosas, el boletín MS08-078. Como factor que ayude a mitigar el riesgo recomienda activar DEP (Data Execution Prevention), ya que por defecto se encuentra desactivado en Internet Explorer, para prevenir la ejecución de código en zonas de memoria no marcadas como ejecutables…sigue

Fuente Hispasec.com

Microsoft
“Vulnerability in Internet Explorer Could Allow Remote Code Execution”
http://www.microsoft.com/technet/security/advisory/961051.mspx

Dancho Danchev
“IE7 XML parsing zero day exploited in the wild”
http://blogs.zdnet.com/security/?p=2283

BreakingPoint Labs
“Patch Tuesdays And Drive By Sundays”
http://www.breakingpointsystems.com/community/blog/patch-tuesdays-and-drive-by-sundays

Es cierto que Microsoft ha corregido ahora una vulnerabilidad de hace siete años?

Mucho está dando que hablar el boletín MS08-68 de Microsoft. Se dice que por fin, ha corregido una vulnerabilidad conocida desde hace siete años. Pero esto, como cualquier simplificación, no es del todo cierto. No es una vulnerabilidad como tal, ni ha sido corregida por completo, porque no se puede. Vamos a intentar aclarar algunos asuntos en dos entregas.
El protocolo NTLM

Es un protocolo de autenticación basado en un intercambio desafío-respuesta, usado por Microsoft desde hace muchos años. Sirve para autenticar a un ordenador que quiere, por ejemplo, acceder a una unidad compartida de una red en otro sistema, sin que la contraseña viaje en texto claro. Durante el protocolo de autenticación, se intercambian tres (tipos de) mensajes desafío-respuesta.

* Mensaje 1: El cliente le cuenta al servidor los distintos tipos de características de cifrado y otros parámetros, para que los dos sepan qué es lo que pueden soportar y esperar uno del otro.

* Mensaje 2: Este es el que devuelve el servidor al cliente que se quiere autenticar. En él viaja el desafío, que no es más que un trozo de datos aleatorios con el que el servidor desafía al cliente: “Si sabes manipular este trozo de datos correctamente con tu contraseña, entonces sé que eres quien dices ser”.

* Mensaje 3: En él se encuentran las respuestas que ha calculado el cliente, esto es, el cálculo de la combinación contraseña-desafío con el que el cliente pretende autenticarse.

Hay que destacar que el protocolo NTLM se usa para SMB (compartición de archivos) principalmente, pero también puede usarse para autenticación HTTP, POP3, SMTP… es importante porque el uso combinado de dos protocolos sirve para otros tipos de ataque que veremos en la próxima entrega.

El problema

El protocolo NTLM fue bien acogido y muy implantado en sistemas de todo tipo. Pero en 2001 se publicó un ataque que se aprovechaba de este diseño, y que resultaba inherente al protocolo. No se trata de una vulnerabilidad sino de un fallo de diseño, y esto, virtualmente, lo hace insalvable. Un protocolo no puede cambiar de la noche a la mañana, y menos cuando lleva tantos años implantado.

El mecanismo de autenticación de NTLM garantiza la confidencialidad de la contraseña gracias al uso de un desafío, pero no es posible para el cliente verificar el origen de este desafío ni la integridad del paquete. Un servidor SMB creado por el atacante podría proporcionar al cliente un desafío obtenido en otra conexión, y utilizar el resultado de la autenticación para autenticarse en esa otra conexión. Ni siquiera tiene la necesidad de conocer la contraseña en texto claro. Simplificando, se trata de “engañar” a un cliente para que cifre un desafío y usar su respuesta para autenticarte en otro sistema como si fueras el cliente engañado. Para engañarlo sólo es necesario montar un servidor SMB por ejemplo y que la víctima se conecte. Se retiene la conexión y se realiza el ataque cuando se obtenga la respuesta.

Esta vulnerabilidad es conocida como “replay attack”. Sin saber la contraseña de la víctima, se puede deambular por una red accediendo a los recursos como si se fuese el sistema atacado, replicando la respuesta al desafío. En 2001, Sir Dystic (miembro de The Cult of the Dead Cow) publicó la primera herramienta capaz de realizar ataques de “replay attack” contra el protocolo NTLM, llamada SmbRelay. Era muy inestable y sólo válida para NT. Más adelante existió una herramienta más sofisticada llamada SmbRelay2. Basándose en el mismo fallo, se puede hablar del “reflection attack”, que implica usar el desafío de la víctima para devolvérselo firmado por ella misma y entrar en su sistema con las credenciales del usuario (pero sin saberlas). En vez de utilizarlas para acceder a otro recurso de red, se usan para entrar en el sistema que ha “picado” con el ataque.

Via Hispasec.com

Las soluciones

Microsoft ha luchado durante los últimos años contra este fallo del protocolo sin poder atajarlo por completo. En realidad es imposible si no es con un cambio de protocolo. Y Microsoft introdujo ya con Windows NT 4.0 SP4, el NTLMv2, que corregía el problema. Sin embargo nunca lo activaba por defecto, por lo de siempre: compatibilidad hacia atrás. Así que su uso es poco generalizado incluso hoy en día.

La implementación de Kerberos de Microsoft también mitigaba el problema en entornos de Directorio Activo. El problema es que no siempre puede usarse este protocolo, y cuando se da el caso, se utiliza NTLM en su versión 1 ó 2.

También se puso a disposición de los usuarios de Microsoft una directiva muy poco usada, la firma digital del protocolo SMB, que mitigaría el problema. Realmente, quien quisiese estar a salvo del “replay attack” tenía muchas posibilidades de conseguirlo. El problema es que quizás no siempre todo sería compatible con el resto de sistemas antiguos o diferentes a Microsoft. Sin embargo, en entornos completamente Microsoft a partir de XP y 2003, es perfectamente posible utilizar estas medidas y estar a salvo desde hace tiempo.

Por último, en Windows 2008 por fin se cumplen todas las buenas medidas de seguridad que Microsoft viene implementando desde hace años: mínimos privilegios y configuración muy segura por defecto. De hecho es el primer sistema operativo que no soporta en sus configuraciones por defecto el uso del protocolo NTLM.

Por qué no han sido suficientes

Existen muchos factores que han alimentado que este problema todavía sea usado con éxito por atacantes. La desaparición de NTLMv1 no está cerca, se encuentra muy arraigado. La compatibilidad con sistemas que no son de Microsoft es otro factor a tener en cuenta. Pero el más importante quizás sea el desconocimiento de los administradores, tanto del riesgo como de las políticas que pueden mitigarlo.

Por qué ahora el parche

Una de los últimos intentos de solución ha sido precisamente este parche que mitiga el problema. Según Microsoft ha acumulado la experiencia suficiente para poder introducir esta actualización sin romper literalmente toda la comunicación entre sus sistemas. De haber realizado cambios drásticos en el pasado, las consecuencias hubiesen sido desastrosas… así que ha tenido que lastrar un protocolo débil durante estos años.

La política de Microsoft siempre ha sido priorizar parches para las vulnerabilidades que están siendo activamente explotadas o para las que existen pruebas de concepto. Las herramientas Smbrelay1 y 2 ya no eran funcionales bajo Windows 2000, XP y 2003. Pero hace poco, Metasploit publicó un módulo de relay que hacía que el ataque fuese trivial. También se anunció la publicación de SmbRelay3 (pensada en principio para enero, pero lanzada ya al público), una excelente herramienta de Andrés Tarascó que hacía de nuevo que el ataque fuese muy sencillo y efectivo. Probablemente esto ha obligado a Microsoft a tomar medidas.

¿Es efectivo el nuevo parche?

Este parche MS08-068, evita que el protocolo SMB permita la autenticación a través de NTLM con un desafío de red que acaba de ser generado para otra conexión saliente. El parche se queda exclusivamente ahí, por lo que si complementamos diferentes protocolos como HTTP y SMB el ataque sigue siendo efectivo. Del mismo modo, si se reenvían las credenciales contra otro sistema de la red, por ejemplo un servidor de ficheros o un controlador de dominio, el ataque también es factible, puesto que el tercer sistema no puede tener conocimiento de que este paquete está siendo reutilizado. Al tratarse de un fallo de diseño de NTLM, los parches de Microsoft solo podrán limitar el impacto…[]

Via Hispasec.com

Microsoft Security Bulletin MS08-068 — Important
http://www.microsoft.com/technet/security/bulletin/ms08-068.mspx

La versión 3.2 de Safari corrige hasta 11 fallos de seguridad

Después de que Mozilla publicara recientemente una actualización de seguridad para su navegador Firefox, ahora le ha llegado el turno a Safari. Apple acaba de lanzar la versión 3.2 de su navegador en la que se corrigen hasta 12 vulnerabilidades, algunas de ellas catalogadas como críticas ya que podrían permitir la ejecución de código de forma remota. Recordamos que la última revisión de seguridad de Safari fue publicada a finales del mes de Junio.

Los problemas solventados en la versión 3.2 de Safari se pueden dividir en dos bloques, los que están causados por fallos en WebKit, el motor de navegación de código abierto contenido en Safari, y los propios de Safari, que son los expuestos en primer lugar:

 

1- Múltiples vulnerabilidades en la librería zlib 1.2.2 que podrían causar una denegación de servicio.

2- Denegación de servicio o ejecución remota de código arbitrario al procesar documentos XML especialmente manipulados. El fallo está causado por un desbordamiento de búfer basado en heap en la librería libxslt.

3- Se ha encontrado un fallo de desbordamiento de búfer basado en heap en el manejador de espacios de color de CoreGraphics. La vulnerabilidad podría ser aprovechada para hacer que la aplicación se cierre de forma inesperada o para ejecutar código arbitrario si un usuario visualiza una imagen especialmente manipulada.

4- Se han encontrado múltiples intentos de acceso a memoria no inicializada al hacer uso de la librería libtiff para intentar procesar imágenes TIFF codificadas con LZW. Esto podría ser aprovechado para hacer que Safari se cerrase de forma inesperada o para ejecutar código arbitrario, si un usuario visualiza una imagen especialmente manipulada.

5- Existe un fallo de corrupción de memoria durante el procesado que hace ImageIO de imágenes TIFF especialmente manipuladas. Esto podría ser aprovechado por un atacante remoto para ejecutar código arbitrario o causar una denegación de servicio en la aplicación.

6- Denegación de servicio o ejecución remota de código arbitrario causada por una corrupción de memoria en ImageIO al procesar imágenes JPEG especialmente manipuladas que contengan perfiles ICC.

7- Desbordamiento de búfer causado por el procesamiento de forma errónea de imágenes que contengan un perfil ICC. Esto podría ser aprovechado por un atacante remoto para ejecutar código arbitrario o hacer que Safari se cierre de forma inesperada.

8- Revelación de información sensible a usuarios locales a través de la caché del navegador.

A continuación se detallan los fallos del motor de navegación WebKit:

9- Acceso a memoria fuera de límites causado por un manejo erróneo de los índices de arrays JavaScript en Safari. Esto podría ser aprovechado por un atacante remoto para ejecutar código arbitrario o causar una denegación de servicio si se visita un página web especialmente modificada.

10- Denegación de servicio o ejecución remota de código causada por un fallo de corrupción de memoria en Webcore al manejar hojas de estilos.

11- Revelación de información sensible aprovechándose de que el interfaz de plugins de WebKit no bloquea el acceso a URLs locales desde los propios plugins…[]

Via Hispasec.com

Safari 3.2 for Windows:
http://www.apple.com/support/downloads/safari32forwindows.html

Safari 3.2 for Tiger:
http://www.apple.com/support/downloads/safari32fortiger.html  

Safari 3.2 for Leopard:
http://www.apple.com/support/downloads/safari32forleopard.html

About the security content of Safari 3.2
http://support.apple.com/kb/HT3298

TKIP usado en WPA parece estar herido de muerte

Los investigadores alemanes Erik Tews y Martin Beck dicen haber conseguido saltarse parcialmente la seguridad que proporciona WPA (Wi-Fi Protected Access) en las redes inalámbricas. WPA vino a salvarnos del inseguro WEP (Wired Equivalent Privacy), que fue vencido pocos años después de su estandarización y que hoy en día es un cifrado obsoleto. Este descubrimiento hace pensar que WPA parece ir por el mismo camino.
Segundo ataque al algoritmo de cifrado y autenticación WPA para redes inalámbricas, y esta vez va en serio. A principios de octubre se publicó la noticia de que la compañía rusa ElcomSoft había conseguido reducir sustancialmente el tiempo necesario para recuperar una clave de WPA, ayudándose de tarjetas gráficas NVIDIA. Al parecer el método conseguía, a través de fuerza bruta, deducir claves extraordinariamente rápido. La fuerza bruta no supone un ataque o una debilidad del WPA en sí, por tanto el cifrado se mantenía relativamente a salvo siempre que se usase una contraseña suficientemente larga y entrópica. El descubrimiento de ElcomSoft no era tan relevante en este sentido. Todo es susceptible de ser atacado por fuerza bruta. Sin embargo lo que Tews y Beck han encontrado sí es un problema inherente a una parte de WPA, un fallo en la criptografía usada en muchas configuraciones.

Es importante recalcar que el método descubierto no permite recuperar la contraseña. Y que tampoco influye el método de autenticación. El problema está en el cifrado. Está limitado a descifrar paquetes concretos o inyectar nuevos (y sólo una pequeña cantidad). También es necesario destacar que el ataque sólo funciona si se utiliza el cifrado TKIP, no el AES. El ataque inminente y posible es provocar una denegación de servicio o inyectar paquetes ARP, lo que puede hacer que se redirija el tráfico. Insistimos en que no es posible por ahora recuperar la clave o descifrar todo el tráfico.

WPA puede usar diferentes algoritmos de cifrado: AES (estándar y seguro por ahora) y el Temporal Key Integrity Protocol (TKIP). Aquí es donde se ha encontrado la vulnerabilidad. Un ataque basado en la misma técnica que volvió obsoleto al WEP (ataque conocido como chopchop) ha permitido que se pueda descifrar un paquete de tipo ARP en menos de 15 minutos, independientemente de la contraseña usada para proteger el WPA. TKIP se creó precisamente para solucionar los problemas de WEP. Por ejemplo añade entre otras, comprobación de integridad del mensaje (MIC) en vez del débil CRC32 que usaba WEP. El problema es que TKIP también conserva varios peligros heredados de WEP. TKIP se creó para que fuese compatible con los dispositivos que ofrecían WEP sólo con actualizaciones del firmware, sin necesidad de cambiar el hardware: un parche.

Los analistas han observado que aprovechándose de estas similitudes, y eludiendo las mejoras introducidas con TKIP, se puede realizar un ataque muy al estilo del que se creó contra WEP y con resultados limitados. Para ello atacan a paquetes ARP (se usan estos paquetes porque son pequeños y sólo quedan por conocer 14 bytes, una vez que se sabe en qué subred nos movemos) y el resultado es que se puede descifrar en menos de 15 minutos. Para otros paquetes se debería emplear más tiempo. El truco es usar un canal o cola QoS diferente de donde fue recibido el paquete. El ataque funciona incluso si la red no tiene funcionalidad QoS…[]

Via Hispasec.com

Microsoft publicará dos boletines de seguridad el próximo martes

Si en octubre fueron once boletines de seguridad los que salieron a la luz, este mes Microsoft prevé publicar dos actualizaciones el martes 11 de noviembre. La dedicada a Office alcanza la categoría de crítica, y la dedicada a Windows de importante.

Adicionalmente, y como viene siendo habitual, Microsoft publicará una actualización para Microsoft Windows Malicious Software Removal Tool. Además, se publicarán actualizaciones de alta prioridad no relacionadas con la seguridad. Como es habitual, cada boletín podrá contener un número indeterminado de correcciones de seguridad.

Ambos problemas afectan a toda la gama de sistemas operativos mantenidos por ahora (desde Windows 2000 a Windows 2008) y toda la gama de Office igualmente, puesto que el fallo crítico se da en Microsoft XML Core Services. Según la versión instalada de este intérprete de XML, la gravedad puede reducirse de crítica a importante.

Al menos en el momento de la publicación de este boletín, Microsoft no ha añadido el “exploitability index” o índice de explotabilidad. Este concepto fue introducido el mes pasado por Microsoft para indicar las posibilidades de que se cree un exploit para cada vulnerabilidad…[]

Via Hispasec.com

Microsoft Security Bulletin Advance Notification for October 2008
http://www.microsoft.com/technet/security/bulletin/ms08-nov.mspx

Nueva versión de Adobe Acrobat/Reader 8 corrige graves vulnerabilidades conocidas desde hace meses

Adobe ha publicado una nueva versión de los productos Acrobat y Reader en su rama 8 que soluciona ocho graves problemas de seguridad. La mayoría son críticos, casi todos conocidos desde hace meses, uno compartido con otro software de lectura de PDF que ya solucionó hace tiempo un fallo parecido… y para una vulnerabilidad existen públicamente detalles técnicos que ya han permitido la creación de un exploit.

Adobe Acrobat y Adobe Acrobat Reader son programas para visualizar o crear archivos PDF, desde hace tiempo estándar de facto en la visualización de documentos y desde hace poco estándar oficial ISO 19005-1:2005.

Adobe Reader y Acrobat 8.1.2 y anteriores sufren ocho problemas de seguridad. Adobe publicó ayer la versión 8.1.3 que los soluciona. La rama 9 no se ve afectada.

De los ocho problemas, varios son fallos no especificados que podrían permitir la ejecución de código. Uno de los más graves se da en la función JavaScript “util.printf”, provocado por un error al procesar cadenas de formato. Adobe fue advertida del problema en abril de este mismo año. Foxit Reader, otro popular lector de PDF, también sufría una vulnerabilidad muy parecida. Foxit lo solucionó un mes después, en abril, mientras que Adobe publicó ayer la solución.

Otro problema se da en el control ActiveX NOS Microsystems getPlus Downloader, un componente que sufre un desbordamiento de memoria intermedia conocido desde mayo. También el problema en la función getCosObj se le notificó entonces y ha sido corregido ahora.

Diferentes fallos en la funciones AcroJS y getCosObj fueron notificados en enero y mayo respectivamente. Por último un error de límites que permite ejecución de código, fue notificado a Adobe en diciembre de 2007. Todos solucionados desde el día 4 de noviembre con la versión 8.1.3…[]

Se recomienda actualizar cuanto antes a la nueva versión disponible, según versión, desde:

http://www.adobe.com/support/downloads/product.jsp?product=1&platform=Windows
http://www.adobe.com/support/downloads/product.jsp?product=1&platform=Macintosh
http://www.adobe.com/support/downloads/product.jsp?product=112&platform=Windows
http://www.adobe.com/products/acrobat/readstep2.html

Via Hispasec.com

Security Update available for Adobe Reader 8 and Acrobat 8:
http://www.adobe.com/support/security/bulletins/apsb08-19.html

Adobe Reader Javascript Printf Buffer Overflow:
http://www.coresecurity.com/content/adobe-reader-buffer-overflow

Phishing a entidades registrantes: ¿Necesitan los atacantes nuevos dominios?

Desde ayer se está produciendo una verdadera avalancha de correo basura que simula ser de registrantes reputados como Enom y Networksolutions. Bajo la excusa de que el domino está a punto de caducar, su objetivo es robar las contraseñas de clientes de registrantes y por tanto adueñarse de sus dominios. Ayer además se dio a conocer que ICANN ha retirado la licencia a Estdomains, uno de los registrantes supuestamente aliados con el mundo del malware… ¿Será que los atacantes andan escasos de dominios?

Se ha observado una avalancha de correos de tipo phishing. Esta vez no intentan simular portales de entidades bancarias, sino que están destinados a simular registrantes reputados de dominios como Enom y Networksolutions. El asunto del correo suele ser: “Attention: domain will be expired soon.” En su interior en un cuidado inglés y en texto plano se avisa al usuario de que su domino está a punto de caducar y que debe visitar la web del registrante e introducir su usuario y contraseña para renovar el dominio. En otras ocasiones en el correo se habla de que a causa de un corte temporal en el servicio, es necesario que el usuario se autentique.

En cualquiera de los casos el enlace lleva a una página que simula fielmente el portal de Enom o Networksolutions. Los dominios (adquiridos para la ocasión y camuflados en dominios de tercer nivel) bajo los que se alojan estos phishing suelen tener la estructura:
www.enom.com.comXY.biz, o www.networksolutions.com.sysXY.mobi/ siendo XY números cualesquiera. Aunque esto puede cambiar en cualquier momento…

Hacía tiempo que no se observaba una campaña tan virulenta contra dueños de domino. Por otro lado (o quizás está relacionado), el pasado martes ICANN eliminó a Estdomains de su lista de registrantes acreditados: ya no pueden ejercer más su función. Estdomains siempre ha estado bajo la sospecha de ser un registrante que se lleva bien con el crimen organizado en Internet. Una buena parte de los dominios contratados en esta empresa han servido y sirven para la difusión del malware 2.0 y todo tipo de actividades ilegales. Siempre se les ha acusado de ser excesivamente “tolerantes” con estas prácticas. ICANN en un movimiento sin precedentes (que ha sido muy aplaudido), ha anunciado en un comunicado público que debido a la eterna sospecha sobre Estdomains (ellos siempre han negado que toleren el abuso de sus dominios), les retira la licencia. Aunque Estdomains ha presentado alegaciones (en estonio) y el proceso está temporalmente parado en espera de que ICANN las estudie. El dueño de Esdomains ha estado en prisión anteriormente por fraudes con tarjetas de crédito…sigue

Source hispasec.com

ICANN
http://www.icann.org/correspondence/burnette-to-tsastsin-28oct08-en.pdf

Último parche de Microsoft: ¿Sufriremos otro Blaster?… No.

El día 23 Microsoft publicó un parche fuera de su ciclo habitual, de carácter crítico, en el que se solucionaba un problema de seguridad en el servicio Server de las distintas versiones del sistema operativo Windows. Avisó con un día de antelación. Hoy, el exploit ya es público. Las características de la vulnerabilidad hacen que sea “ideal” para ser aprovechado por un gusano tipo Blaster, que se convirtió en epidemia en 2003. ¿Podría pasar lo mismo con este fallo?

En julio de 2003 se descubre el desbordamiento de memoria intermedia en la interfaz RPC de sistemas Windows que, a la postre, permitiría la aparición del fatídico gusano Blaster. Otro fallo parecido un año después propició el nacimiento de Sasser, otro popular gusano. El último parche publicado por Microsoft de forma urgente, el MS08-067, tiene las mismas características: un desbordamiento de memoria intermedia en el procesamiento de peticiones RPC (Remote Procedure Call) que efectúa el servicio Server. ¿Se creará otro gusano parecido?

Lo que hace que esta vulnerabilidad sea especialmente peligrosa, es que es explotable de forma remota sin interacción del usuario: un atacante envía una petición especialmente manipulada a un puerto, y ya puede ejecutar código en el sistema con los máximos privilegios. Candidato ideal para un gusano “como los de antes”. De ahí que Microsoft, con buen criterio, se haya lanzado a romper su ciclo habitual. Quizás motivado porque el fallo ha sido descubierto cuando ya se estaban produciendo ataques muy concretos. No a gran escala, pero sí que se han detectado incidentes que demostraban que los atacantes conocían el problema y lo estaban aprovechando en secreto. La última vez que Microsoft publicó una actualización de seguridad fuera de su ciclo habitual de actualizaciones fue el 3 de abril de 2007.

El último problema de este tipo (explotable enviado peticiones a un servicio) se vio hace más de dos años. Lo trataba el boletín MS06-040 y también afectaba al servicio Server (de hecho este nuevo boletín lo reemplaza). Se hizo público el exploit y hubo malware que lo aprovechaba, pero no fue epidemia. En este caso pensamos que tampoco se convertirá en el problema que antaño suponían estas vulnerabilidades. Por varias razones.

¿Por qué creemos que el potencial gusano no se convertirá en epidemia?

Microsoft cometió enormes y numerosos fallos de seguridad de este tipo en el pasado. Los gusanos de infección masiva campaban a sus anchas. Pero intentó solucionarlo a través de varios métodos. Primero con su nueva estrategia de seguridad anunciada hacia 2002. Desde entonces (tarde quizás) la seguridad sería prioridad. El problema es que, sobre una base tan débil, los resultados han tardado en observarse… pero están ahí. Por ejemplo, sobre Vista y Windows 2008 esta última vulnerabilidad no es crítica sino sólo “importante”, que no es poco. En las últimas versiones de Windows el atacante debe estar autenticado para poder hacer que el exploit ejecute código. Si no, sólo se provocará una denegación de servicio.

Con el Service Pack 2 de Windows XP se activa el cortafuegos entrante por defecto. Esto mitiga enormemente las posibilidades de explotación de este tipo de fallos. De hecho, desde que el Sevice Pack fue lanzado en agosto de 2004, el malware se trasladó al navegador. Al no poder aprovechar fallos en los servicios por culpa del cortafuegos, necesitaban colarse en los sistemas de otra forma, e Internet Explorer sufrió la consecuencias. Todavía hoy es la forma favorita del malware de ejecutar código. Por si fuera poco, hoy en día, los usuarios están más que nunca detrás de un router casero que protege, en principio, los puertos del ordenador…sigue

Hispasec.com