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].
Vulnerabilidades
ATENCIÓN: Este sitio ha dejado de actualizarse el 15 de Abril de 2012 y se mantiene como archivo histórico de los contenidos publicados entre 2004 y 2012. Por favor, visita nuestro nuevo sitio para acceder a información actualizada. Muchas gracias."Chrome parece ser un navegador muy agradable y ligero, pero está lejos de ser tan seguro como anuncia Google. Toma prestadas varias características inseguras de otros navegadores y tiene sus propios fallos de diseño".
Si la primera vulnerabilidad no os pareció suficientemente grave, vamos por la segunda:
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.
A las pocas horas de su publicación, el flamante navegador de Google ya empieza a mostrar sus primeras debilidades.
Comencemos por esta:
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.
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.
Para detectar si nuestro sistema ha sido comprometido, además de revisar los controles habituales (Tripwire, buscar procesos ocultos, etc) hay que comprobar si existe un directorio /etc/khubd.p2/. No vale utilizar el comando ls (se oculta de él), sino tratar de entrar con un cd /etc/khubd.p2/
Si el sistema aparece comprometido, US-CERT recomienda deshabilitar la autenticación mediante claves SSH, auditar las claves en uso y avisar a los usuarios en riesgo...
Microsoft acaba de publicar una versión mejorada de URLScan, un extra para su servidor Web que actúa como filtro frente a intentos de inyección SQL y códigos maliciosos.
Pero, ¿cuál es la principal novedad que aporta URLScan 3.0 frente a su versión anterior 2.5? Pues nada más y nada menos que la nueva versión filtra también las "query string" (es decir, las cadenas que van en la URL tras el dominio, que es precisamente dónde suele está el "quid" de la cuestión). Hasta hoy, y por increíble que parezca, URLScan no filtraba las cadenas que incluyen la consulta SQL, sino sólo las URLs y en función de características tan superficiales como su longitud.
URLScan 3.0 también aporta un control más estricto que permite a los administradores definir reglas mucho más específicas, así como implementar listas blancas de cadenas de consulta permitidas.
Una vez más, Microsoft desmiente así a sus propios "fanboys", que al menos hasta hoy defendían con su característico empecinamiento que toda la responsabilidad de los últimos ataques masivos recaía exclusivamente en los desarrolladores de aplicaciones
Y es que es cierto: los ataques por inyección SQL no son "culpa" del servidor SQL de Microsoft (ni mucho menos exclusivos de sus servidores), pero la propia multinacional norteamericana reconoce que URLScan 3.0 está mejor construido que la versión anterior, y que puede ayudar al menos a que no se reproduzcan los ataques con la lamentable facilidad con que vienen haciéndolo últimamente sobre el servidor web de esta empresa...
Iván Sánchez (de Null Code Services) ha informado de la existencia de una vulnerabilidad en la utilidad Nslookup de Microsoft Windows, una herramienta de línea de comandos que se utiliza para comprobar los servidores DNS.
La vulnerabilidad (sobre la que aún no se han dado detalles) permitiría la ejecución de código arbitrario en la máquina víctima, incluso si ésta ejecuta Windows XP SP2 totalmente parcheado.
De momento no existe parche. Microsoft asegura estar estudiando la situación, mientras algunos medios afirman que la vulnerabilidad ya está siendo activamente explotada...
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:
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 ;)
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.
Para Polyakov tampoco DNSSEC supone ninguna solución definitiva, aunque sí otro alivio temporal más duradero. Sin embargo otros expertos (como Bernstein) opinan que su seguridad es sorprendentemente baja y su funcionamiento mucho más lento y pesado. Polyakov contraataca diciendo que el sistema DJBDNS, ideado por Berstein, también es vulnerable...
¿La puntilla para Vista?
Aug 09
NOTA DEL EDITOR: Como ya dije en su momento, este artículo de Fernando Acero me ha pillado con el paso "cambiao". Inicialmente no presté la menor atención a otra noticia que hablaba de la enésima vulnerabilidad de Windows Vista, pero con el tiempo esa actitud se ha mostrado equivocada. El artículo de Fernando es ya el más leído en Kriptópolis en el último mes, y está siendo enlazado, reproducido y plagiado (es decir, saltándose a la torera su licencia libre y haciéndolo pasar por propio) por infinidad de sitios.
Por Fernando Acero
De todos son conocidos los problemas de Windows Vista para entrar en el mercado, con controvertidas cifras de venta (recordemos que se lo hacen comer con patatas a cada comprador de un sistema informático) y con otros serios problemas con el hardware, los recursos y la compatibilidad, como ya predijo Gartner en su momento. Pero puede que la puntilla destinada a acabar definitivamente con este sistema operativo tan polémico se la acaben de haber dado en Las Vegas...
Habló Kaminsky
Aug 07
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.
Como dijo Kaminsky, lo que existe ahora es una ventana de riesgo que puede ser aprovechada por los delincuentes antes de que el parcheo sea total. En ese sentido, Kaminsky estimó que el 42% de los usuarios de banda ancha ya están protegidos por los parches aplicados...