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):
http://support.microsoft.com/default.aspx?scid=KB;EN-US;q317748Este 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.aspBien 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.
Bernardo Quintero
bernardo@hispasec.com
Más información:18/02/2002 Microsoft lanza en España su iniciativa STPP
http://www.hispasec.com/unaaldia.asp?id=121219/02/2002 Microsoft STPP, ¿estrategia tecnológica o lavado de cara?
http://www.hispasec.com/unaaldia.asp?id=121330/12/2002 Actualizaciones de Microsoft, un arma de doble filo
http://www.hispasec.com/unaaldia.asp?id=1527SANA. 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
