SoftwareLibre.Net

Según afirman los descubridores, con Windows XP SP2, cuando el usuario intenta guardar una página maliciosa con un título muy largo, se desborda el buffer de la pila y se ejecuta un programa sin avisar al usuario. En las demos se arranca la calculadora, pero según los autores se podría ejecutar cualquier código incluido en la propia página, por lo que el fallo puede considerarse crítico. Como mi Windows tiene el SP3 eso no funciona, pero otra versión del exploit sí produce el cuelgue total e inmediato de Chrome, confirmando de nuevo que todas las pestañas abiertas pueden caer a la vez. Según los descubridores, el fallo ha sido reconocido por Google y está siendo estudiado. Referencias y demos: http://security.bkis.vn/?p=119 http://www.milw0rm.com/exploits/6367 http://www.derkeiler.com/Mailing-Lists/Full-Disclosure/2008-... Leer Más...

Al arrrancar hoy Chrome para comprobar la nueva remesa de vulnerabilidades publicadas, me encuentro con un aviso de que existe una actualización disponible:     Lo he intentado varias veces -lo juro- pero el resultado siempre ha sido el mismo:     Supongo que será un fallo temporal, pero a ver si alguien tiene más suerte que yo y nos puede contar qué aporta (sobre todo si actualiza WebKit a la versión no vulnerable, que es lo menos que puede esperarse). Leer Más...

Y los hay para todos los gustos: desde los que impiden acceder a cuentas de Google, al curioso hecho de que Google Analytics detecte Chrome como "Safari for Windows". Quien quiera entretenerse un rato puede probar por sí mismo los más llamativos. Claro, sí, se trata de una beta, pero se admiten apuestas sobre cuántos serán dentro de un par de semanas. Chromium-bugs. Leer Más...

Un error de diseño en Google Chrome permite la descarga de ficheros a la máquina víctima sin pedir consentimiento al usuario. Google Chrome Arbitrary File Download Vulnerability [Security Focus]. Prueba de concepto [Milw0rm]. Leer Más...

Si la primera vulnerabilidad no os pareció suficientemente grave, vamos por la segunda: http://blogs.zdnet.com/security/?p=1843 En resumen; Chrome utiliza una versión antigua y vulnerable de WebKit, que permite engañar a los usuarios de Windows y hacerles ejecutar software malicioso. Al parecer, los usuarios de Vista ya han podido contemplar uno de los primeros indicios sospechosos: Chrome almacena por defecto los ficheros descargados en el escritorio. Eso, junto a una vulnerabilidad aún no parcheada de Explorer, les convierte en vulnerables al peor "estilo Safari". Aviv Raff ha publicado una prueba de concepto:     En mi caso al pulsar el botón arranca Winrar. Leer Más...

A las pocas horas de su publicación, el flamante navegador de Google ya empieza a mostrar sus primeras debilidades. Comencemos por esta: http://evilfingers.com/advisory/google_chrome_poc.php Cuyo lamentable efecto es el siguiente: Lo más preocupante es comprobar cómo el fallo se lleva por delante todas las pestañas abiertas, contradiciendo así uno de los objetivos básicos de Chrome. Leer Más...

El US-CERT acaba de publicar un aviso sobre la detección de un aumento de ataques contra infraestructuras basadas en Linux mediante el uso de claves SSH comprometidas, probablemente relacionadas con el famoso fallo de Debian. Especialmente vulnerables son los sitios en que la identificación se realiza mediante claves no protegidas por contraseña. Tras lograr el acceso al sistema, se utilizan "exploits" contra vulnerabilidades del kernel para obtener privilegios de "root". Acto seguido, se procede a instalar un rootkit (Phalanx2) en el sistema así comprometido, el cual roba nuevas claves que se utilizan para comprometer otros sitios u otros sistemas de la propia infraestructura comprometida.

Pocos documentos tan claros e interesantes como éste de Steve Friedl para quienes tengan interés en conocer los aspectos técnicos del funcionamiento del sistema DNS, la esencia de la vulnerabilidad y los posibles métodos empleados para explotarla: An Illustrated Guide to the Kaminsky DNS Vulnerability. Se trata de la información más clara, concreta y mejor presentada que he visto en todos estos días. En lengua de Shakespeare, of course ;) Leer Más...

Era sabido que el parcheo de los servidores DNS frente a la vulnerabilidad presentada por Kaminsky representaba sólo un alivio temporal, pero nadie sospechó que durará tan poco. Hoy mismo, Evgeniy Polyakov se ha encargado de demostrar (exploit incluido) cómo un servidor DNS corriendo BIND con la última versión perfectamente parcheada continúa siendo vulnerable al envenenamiento de la caché. El propio Polyakov se encarga de desmentir que se trate de una vulnerabilidad exclusiva de BIND, sino que todo el sistema DNS, aún parcheado, continúa siendo vulnerable, sólo que ahora se requiere un poco más de tiempo... que quizás incluso pudiera acortarse mediante un ataque distribuido.

Tal y como estaba previsto, Dan Kaminsky subió ayer al estrado de Black Hat y habló durante 80 minutos acerca de los detalles de la vulnerabilidad en DNS que ha puesto en jaque a toda Internet. Prácticamente no hay nada nuevo en los detalles técnicos con respecto a lo que se había venido filtrando en los últimos días. Básicamente, las consultas DNS incluyen un identificador aleatorio de la transacción, pero sólo se dispone de poco más de 65.000 identificadores posibles. A base de "inundar" un servidor DNS con miles de peticiones para dominios con un nombre similar, el atacante puede acertar con el número que permite considerar válida una respuesta, y de ese modo redirigir el tráfico a su antojo.

Si hasta ahora la explotación de la grave vulnerabilidad en los servidores DNS era más teórica que real, HD Moore, uno de los primeros en publicar exploits, detectó un servidor comprometido de AT&T en Austin (Texas, EE.UU.), que redirigía las peticiones realizadas a google.com hacia una página falsa que incluía marcos publicitarios. Según Kaminsky (descubridor del fallo) hay otros ataques confirmados, pero ciertos acuerdos de confidencialidad impiden revelarlos... Leer Más...

El tiempo apremia. No es ya sólo que varios exploits para el fallo de DNS estén corriendo por toda Internet, sino que además surgen nuevas ideas de explotación. Es el caso de Evilgrade, una herramienta ideada por Francisco Amato, de Infobyte Security Research, que aprovecha el fallo DNS junto a otras vulnerabilidades conocidas para subvertir la actualización en línea de múltiples programas y aplicaciones muy populares, entre los que se encuentran Java, Winzip, Winamp, MacOSX, iTunes... Leer Más...

España no es diferente. Un estudio del CERT austríaco ha confirmado que dos de cada tres servidores DNS recursivos de los principales proveedores de acceso de ese país continúan a día de hoy siendo vulnerables al grave fallo hecho público por Kaminsky: Patching Nameservers: Austria reacts to VU#800113. Como publicamos hace unos días, algo similar ocurre también en el resto del mundo. Leer Más...

Al menos eso dice hoy un artículo en The Register, que refleja una situación bastante similar a la de los proveedores de nuestro propio país. En concreto The Register califica como vulnerables (mediante el test de Kaminsky) a AT&T, BT, Time Warner y Bell Canada, así como a más de una decena de otros proveedores. La burocracia interna podría ser una de las causas de la lentitud con que se está realizando la aplicación de parches en las grandes empresas. Según algunos expertos, la mera aprobación administrativa de la aplicación de un parche tan importante podría requerir un mes, y la actualización en organizaciones muy grandes requeriría probar sucesivamente diferentes configuraciones e irlas deshaciendo hasta dar con la más apropiada. Sin embargo, para la mayoría de empresas la actualización se limita a la aplicación de un parche en su servidor, a excepción de las que aún utilizan BIND 8, que han de actualizarse previamente a BIND 9...

Este test de DNS-OARC resulta más detallado que otros y muestra sus resultados de forma gráfica, aunque también requiere esperar los resultados algunos segundos más. Informa por separado de la aleatoriedad de los dos factores implicados en la vulnerabilidad: Aleatoriedad del puerto de origen. Aleatoriedad del identificador de la transacción. Los interesados en estos factores y en cómo intervienen en el fallo, disponen de una explicación técnica bastante sencilla (aunque en inglés) en la web de McAfee. Leer Más...