Estas aquiContenido / Más de 500.000 sitios web afectados por ataque masivo de inyección SQL
Más de 500.000 sitios web afectados por ataque masivo de inyección SQL
Entre la enorme lista de víctimas se encuentran esta vez los sitios de organismos oficiales (Naciones Unidas, UNICEF, Department of Homeland Security, Servicio Civil del Reino Unido...), revistas (Redmond Magazine, Pocket PC Magazine...), empresas (Aeroflot...), etc, etc.
El mecanismo es el habitual. Se explota de forma masiva una vulnerabilidad peculiaridad de Microsoft IIS y Microsoft SQL Server para insertar javascript en los servidores afectados, que se sirve a los navegadores de sus visitantes de modo que éstos resultan redirigidos a otros sitios maliciosos, donde se ensayan diferentes exploits para varias vulnerabilidades conocidas, buscando instalar malware en sus máquinas.
Y también, como es habitual, están a salvo los usuarios de Firefox con NoScript...
Referencias:
Versión para imprimir
Sinceramente, había oido comentarios en otras webs sobre que la seguridad de IIS había mejorado, pero mejorado de verdad. Y ahora veo que no es así, y para variar "Currently, Microsoft is not aware of any attacks attempting to exploit the potential vulnerability."
http://www.microsoft.com/technet/security/advisory/951306.mspx
El termino de SQL Injection se debe a la explotacion de un mal diseño realizado en la capa de negocio y no se debe especificamente al software utilizado. Es responsabilidad del desarrollador tener en cuenta esta vulnerabilidad y aplicar best practices en su desarrollo.
Este termino lo estas confundiendo con otro tipo de ataque llamado Cross-site scripting(CSS) o XSS, y tampoco tiene que ver con algun software o plataforma especifica. Todo apunta a un mal desarrollo
A pesar que la navegación con Noscript a veces es muy conflictiva, sin duda es nuestro mejor amigo.
Seguridad + comodidad de uso = INCOMPATIBLES.
No es incompatible seguridad+comodidad de uso. Lo que es incompatible es dispositivo programable con usuario que no sabe programar.
Mi reproductor de DVD es muy fácil de usar, pero no creo que nadie pueda meterle un virus.
Para ser justos, hay que decir que la protección que ofrece Firefox con NoScript (limitar la funcionalidad del navegador en sitios no marcados expresamente como confiables), es equivalente a la que se puede conseguir con Internet Explorer y las zonas de seguridad.
En IE hay que establecer en "Alto" el nivel de seguridad en la zona "Internet", y en "Medio" en los "Sitios de Confianza". Luego, a medida que se navega, hay que añadir a los sitios de confianza a aquellas páginas que queramos permitir mayor funcionalidad.
En ambos casos, Firefox/IE, este tipo de defensa funcionará en ataques como el descrito en este post, ya que el sitio comprometido (una página "popular" y en principio de confianza) no contiene el código malicioso, sino que nos redirige a otra que sí que intenta atacarnos. Como en esta segunda no permitiremos el uso de javascript y similares, el ataque es evitado.
El problema vendrá cuando el atacante altere el contenido de un sitio "confiable", en el que tendremos permitido javascript. Entonces nuestra seguridad dependerá del resto de medidas que tengamos implementadas: actualización del sistema, antivirus, etc.
Parece ciencia ficción, pero ya ha pasado, y me temo que dado el gran beneficio que puede llegar a obtener el atacante, volverá a pasar.
En cualquier caso, limitar la funcionalidad del navegador (sea cual sea, lo importante en este caso es evitar infecciones que repercuten negativamente en toda la comunidad de internautas) siempre es bueno, ya que hoy en día se ha convertido en el principal vector de ataque al que estamos expuestos.
Creo que me he perdido algo, o a lo mejor hablas de MSIE8, pero no veo la opción de permisos temporales, o la lista de servidores extraídos del código de la página, ola facilidad de uso, o la opción para impedir IFRAME, o ... Bueno, prueba otra vez NoScript, que acaban de sacar la versión 1.6.4 :-)
... Explorer con zonas es tan seguro (o más) que Firefox con Noscript ...
... SQL Server es invulnerable ...
... IIS invencible, mil veces mejor que Apache ...
... Cerrudo es un fantasma ...
... Vista, un super hit ...
... Microsoft inventó el PC y Bill Gates la Internet ...
Aceptamos barco como animal acuático?
y no echar culpas a alguien cuando no se tienen, ya que si no se pierde credibilidad.
Es un ataque de Sql inyectado, es decir, la culpa es de las aplicaciones web que no comprueban, o no lo hacen correctamente, los datos de entrada. Además por lo que parece, una mejor gestión de permisos del usuario usado en la aplicación web, limitando lo que puede hacer, mejoraría las cosas. Además se podrían usar procedimientos almacenados,...
Si se tracta de una inyección sql el problema no es fallo de IIS ni de SqlServer, sino mas bien es fallo del programador por no validar las entradas del programa.
Ya que hace más fáciles los ataques por inyección SQL al permitir obtener información sobre campos de tablas de manera automatizada. Con otros sistemas de BBDD es posible también hacer ataques de inyección SQL, pero debes tener datos (o intentar adivinarlos) sobre los nombres de los campos para que funcione.
Este ataque, además, es en dos fases. En una primera se contamina al servidor para que ofrezca la redirección mediante javascript a los visitantes de la web. En la segunda se intenta infectar a los visitantes redirigidos al sitio malicioso. MS y los usuarios tienen responsabilidad compartida en ambas:
- En la primera: MS por facilitar los ataques SQL, El usuario/desarrollador por no usar buenas prácticas de programación para prevenirlos.
- En la segunda: MS por no disponer de un sistema cómodo (lo de las zonas de seguridad es tremendamente más incomodo de establecer que noscript, con lo que tiene todos los números de acabar desactivado por defecto). El usuario por no desactivar la ejecución de scripts.
Por lo que respecta al tema de los javascripts. Hay innumerables páginas no maliciosas que exigen su uso para mostrar contenidos. No hablamos de monerías gráficas sinó de funcionalidades básicas. Esto nos obliga a autorizar su uso si queremos acceder a información o archivos, planteando la disyuntiva entre seguridad y acceso. Una ruleta rusa.