La historia se repite. Tal y como ocurriera con «Code Red», de nuevo un gusano que aprovecha una vulnerabilidad en un producto de Microsoft provoca el colapso en Internet. Con respecto a los antivirus, en esta ocasión tampoco han podido detenerlo, ni siquiera a posteriori, ya que la tecnología que utilizan en sus productos les impide desarrollar firmas de detección contra este tipo de gusanos que no se escriben en disco. ¿Cuando será la próxima?
Como ya adelantamos el sábado en Hispasec, «SQLSlammer», «Sapphire», «SQLExp», o cualquiera de los otros nombres con que ha sido bautizado este nuevo gusano para MS-SQL/MSDE 2000, aprovecha una vulnerabilidad de julio de 2002, y su prevención pasa por haber aplicado el parche específico, alguno de los acumulativos posteriores, o el Service Pack 3 de MS-SQL. Otras medidas proactivas pasan por establecer reglas correctas a nivel de tráfico, impidiendo el acceso indiscriminado a los servicios de MS-SQL, en esta ocasión especialmente al puerto UDP/1434.
En caso de que el sistema ya se encontrara infectado y colapsado por el bombardeo de paquetes del gusano, las buenas prácticas recomiendan la desconexión de la red (para evitar que se reinfecte mientras aplicamos el parche), reiniciar el sistema (para que desaparezca de memoria el código del gusano), aplicar la actualización (que impide que vuelva a infectarse), y volver a iniciar el sistema conectándolo a la red para restaurar sus servicios.
Una vez pasada la crisis que provocó la rutina de propagación del gusano, cuyos efectos más notables duraron unas horas el sábado (ni se trataba de un ciberataque a EE.UU., ni Internet se va a venir abajo en las próximas horas), podemos sacar algunas conclusiones a bote pronto:
-
Internet: el gusano ha puesto de manifiesto la debilidad de la Red, si bien esta misma infraestructura ha permitido una rápida reacción coordinada de forma espontánea por parte de todos y corregir en horas un problema de tal envergadura (no había más que ver el sábado la avalancha de mensajes en los foros de seguridad donde prácticamente en tiempo real se analizaba el gusano y se proponían soluciones y medidas preventivas).
-
Antivirus: en este caso no han podido proteger a sus clientes, ni antes ni después, ya que la inmensa mayoría basan su tecnología en la identificación de firmas en objetos del disco (archivos, sectores…). El gusano, al infectar directamente a través de un desbordamiento de buffer y situarse en memoria, sin necesidad de hospedarse en el sistema de archivos, queda fuera del alcance de estos productos. Eso explica que, pese a que sí han lanzado avisos sobre el gusano, las empresas antivirus no han podido actualizar sus motores de detección para parar a este gusano. No tienen responsabilidad directa en este incidente, en cualquier caso han intentado ayudar con avisos públicos, si bien debemos ser conscientes de sus limitaciones como solución de seguridad.
-
Microsoft: Si con «Code Red» fue Internet Information Server, en este caso ha sido MS-SQL, de nuevo una vulnerabilidad en un producto de Microsoft pone en peligro no ya sólo a sus clientes, sino al resto de Internet. Vulnerabilidades tienen todos los sistemas, no es un problema en exclusiva de Microsoft, pero este caso viene a poner el dedo en la llaga cuando ya hace más de un año del lanzamiento de su iniciativa de seguridad STPP. «Strategic Technology Protection Program (STPP)» tiene como principal misión acelerar la actualización de los sistemas de Microsoft, intentando disminuir el tiempo que transcurre desde que es descubierta la vulnerabilidad hasta que el sistema del cliente es actualizado. La vulnerabilidad aprovechada por el gusano de MS-SQL data de julio del 2002.
-
Productos de terceros: La vulnerabilidad no se ha limitado a MS-SQL/MSDE 2000, sino que se extiende a muchos más productos de otros fabricantes que utilizan estos componentes de Microsoft como parte de sus soluciones. El resultado es que el servicio vulnerable se ha encontrado en sistemas en los que a priori los administradores de sistemas desconocían que debía aplicarse las actualizaciones. En una de las alertas sobre el gusano MS-SQL, que Hispasec emitió a los suscriptores del servicio SANA, se listaban más de 50 soluciones que podían instalar el componente afectado y como comprobar su existencia para evaluar si era necesario parchearlos. Para prevenir estas situaciones, una buena medida en lo sucesivo sería que esas casas de software avisaran a sus clientes cuando se publica una actualización que afecta a uno de los componentes que integra sus soluciones.
-
Parches: La disponibilidad de un parche no asegura la protección de los sistemas, es necesario que los administradores o usuarios lo apliquen. Si bien es cierto que en algunos casos puede ser un problema por dejadez, falta de tiempo o simple desconocimiento, existe también ciertas reticencias a su instalación inmediata en ambientes en producción. No es que los administradores tengan manías, sino todo lo contrario, es por experiencia propia: parches que se superponen, regresiones de vulnerabilidades, problemas de estabilidad o incompatibilidad con otros componentes.Para ejemplos, vamos a ver algo referente a esta vulnerabilidad:Existe un parche para MS-SQL 2000 de cara a corregir un problema que bajo ciertas circunstancias puede derivar en consumos de memoria no recuperables por el sistema, hasta poder llegar a la denegación de servicios (Q317748):Este parche no había sido incluido en el parche específico para la vulnerabilidad que aprovecha el gusano, ni en los siguientes acumulativos de seguridad aplicables a MS-SQL con Service Pack 2. De forma que si un administrador quería aplicar el parche para evitar las posibles pérdidas de memoria, debía aplicar la actualización disponible en Q317748.El problema es que si se aplica después de algunos de los parches de seguridad, el sistema se vuelve vulnerable, ya que esta actualización intenta instalar una versión anterior de la biblioteca ssnetlib.dll, sobreescribiendo la ya parcheada que evita la acción del gusano.Dado que el primer parche de seguridad de la vulnerabilidad que aprovecha el gusano data de julio de 2002, y este parche para evitar pérdidas de memoria es de octubre de ese mismo año, es bastante probable que más de un sistema hubiera sido parcheado correctamente en julio y que en octubre volviera a ser vulnerable por la instalación de este segundo parche.
Esto no es un caso aislado en las actualizaciones de Microsoft.Para evitar este contratiempo, ya el domingo 26, Microsoft lanzó un nuevo parche acumulativo para Service Pack 2 que incluye las correcciones de seguridad anteriores y el parche Q317748. De forma que sus recomendaciones son, bien utilizar este nuevo parche (MS02-061) sobre SP2:Bien instalar directamente el Service Pack3, que es lo que recomendábamos desde Hispasec el sábado:
- Administradores: Queda claro que parte de la responsabilidad de las incidencias causadas por este gusano la tienen los administradores de sistemas que no han actualizado puntualmente sus servidores. En cualquier caso, como acabamos de ver, no todo se limita a instalar parches de forma indiscriminada (se ve muy fácil desde la barrera), y en ocasiones los problemas han podido venir por otras causas ajenas a su responsabilidad más directa (regresión de vulnerabilidades por problemas de los parches de Microsoft, o instalación de esos componentes por parte de aplicaciones de terceros). De todas formas, bien es cierto que a nivel de administración/configuración deben de tomar medidas más proactivas, y evitar el acceso indiscriminado a los servicios que no requieran ser públicos, lo que también habría evitado la mayoría de infecciones.
- Comunidad GNU: sale reforzada de este incidente. Además del hecho de que haya sido una vulnerabilidad de un producto de Microsoft la que ha causado el incidente, lo que podrá ser para algunos simple casualidad y para otros una evidencia más, si es cierto que las primeras reacciones vinieron del mundo GNU, tanto a nivel de detecciones como medidas preventivas. Por ejemplo, cuando aun no había comunicado de Microsoft, ni avisos de las casas antivirus, ya estaban disponibles en Internet las primeras reglas para identificar al gusano a través de Snort, el popular IDS que se distribuye gratuito y con acceso público a su código fuente. La propia coordinación de los administradores en los primeros momentos, a través de los foros de Internet, fue más propia de este tipo de movimientos, más que de iniciativas privadas.
- Sistemas de Alertas: En este caso la utilidad de un sistema de alerta en tiempo real sobre nuevas amenazas e incidentes se presenta vital. Así como sistemas de monitorización, que avisen e informen a los administradores, a cualquier hora y en cualquier momento, sobre los problemas y actuaciones que atañen a sus sistemas.
- Seguridad Proactiva: Queda patente que la seguridad reactiva, como la instalación de parches o la actualización de firmas una vez se detecta un incidente, no es efectiva contra las nuevas amenazas que aprovechan el potencial de Internet. Tenemos que hacer hincapié en el concepto de seguridad de partida, tanto a la hora de configurar correctamente un sistema como al desarrollar una aplicación, y solicitar soluciones de seguridad más genéricas, que vayan más allá de la mera identificación de un incidente conocido.
Más información:
18/02/2002 Microsoft lanza en España su iniciativa STPP
http://www.hispasec.com/unaaldia.asp?id=1212
19/02/2002 Microsoft STPP, ¿estrategia tecnológica o lavado de cara?
http://www.hispasec.com/unaaldia.asp?id=1213
30/12/2002 Actualizaciones de Microsoft, un arma de doble filo
http://www.hispasec.com/unaaldia.asp?id=1527
SANA. Servicio de Análisis, Notificación y Alertas
http://www.hispasec.com/sana/
Alerta: Gusano para MS-SQL
http://www.hispasec.com/unaaldia.asp?id=1554
Bernardo Quintero
bernardo@hispasec.com
bernardo@hispasec.com
Deja una respuesta