Lecciones del gusano MS-SQL

• 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):
  http://support.microsoft.com/default.aspx?scid=KB;EN-US;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:
        
  http://www.microsoft.com/technet/security/virus/alerts/slammer.asp
       
  Bien instalar directamente el Service Pack3, que es lo que recomendábamos desde Hispasec el sábado:
      
  http://www.microsoft.com/sql/downloads/2000/sp3.asp    

• 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