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