22 ene 2009

Conficker/downadup: ¿aprendimos algo?

Aunque no lo he sufrido de cerca, creo interesante sacar conclusiones y plantearse algunas preguntas con respecto a estos casos que tanto ruido y daño causan: el invitado de hoy, "Conficker" o si prefieren "Downadup", en dos sabores: A suave o sabor B picante.

Bromas aparte, este gusano sin duda se ganó un lugar en la historia del malware, en la lista de los "grandes": Slammer, Blaster, Sasser, CodeRed, Conficker.

En el blog de TrendLAbs, Robert McArdle escribe:
"¿Entonces porque es tan exitoso este gusano? Simple - políticas de seguridad pobres."
Coincido con él, pero leyendo todo lo que se sabe él mismo comenta que no hay nada nuevo o sorprendente en como logró ser exitoso.

Y repasando una de las exitosas vías de propagación tenemos a la falta de actualización, la demora en aplicar parches al SO.

Veamos entonces la lista de algunos "grandes" y repasemos estos datos:

En 2001 CodeRed, aprovecha la vulnerabilidad del boletín MS01-033, un mes después del parche.
En 2002 Slammer, aprovecha la vulnerabilidad del boletín MS02-039, seis meses después del parche.
En 2003 Blaster, aprovecha la vulnerabilidad del boletin MS03-026, un mes después del parche.
En 2004 Sasser, aprovecha la vulnerabilidad del boletín MS04-011, 18 días después que salio el parche.
En 2005 Zotob, su primera versión comenzó a reproducirse apenas 4 días después de que Microsoft liberara la actualización MS05-039 necesario para corregir la vulnerabilidad explotada por el gusano, no dando tiempo a usuarios y administradores para actualizar sus sistemas.

Y ahora otra vez:

Conficker, aprovecha la vulnerabilidad del boletín MS08-067, un mes (variante A) y dos meses (variante B) después que salió el parche.

Entonces ¿qué hemos aprendido desde el 2001? A juzgar por los casi 9 millones de máquinas infectadas por Conficker (según F-Secure) parece que nada o muy poco.

Pero ¿cuál es la justificación para no aplicar un parche cuando sale? ¿Porque "rompe" algo?

Bien, es cierto. Cada vez que introducimos un cambio en un sistema, es probable que, aún habiendo planificado y hecho todo conscientemente, haya un problema. Esto es conocido, lo asumimos y nos preparamos. Gestión de cambios.

Nadie deja de actualizar las versiones de sus programas de ventas, de stock, de sistemas de producción, su procesador de palabras, o su ERP por temor a que algo falle. Sencillamente paga el precio de hacer el proceso de forma controlada y segura. Seguro no significa sin fallas, significas estar preparado por si algo falla. Con resguardos.

Entonces con los parches del SO (y otras piezas de software), ¿porqué nos demoramos si sabemos a ciencia cierta que muy probablemente algo malo nos va a pasar.?

¿No es preferible programar el día, prepararse para "romper" algo, antes que sufrir la interrupción del funcionamiento de la organización, sin aviso previo, a causa de un gusano de los "grandes" en medio de un día de trabajo, o peor, un viernes por la tarde?

Estoy seguro que muchas organizaciones han aprendido la lección hace tiempo. Pero me sorprende escuchar nombres de bancos (supuestamente sometidos a fuertes regulaciones), y corporaciones (con gruesos presupuestos de TI) sufriendo este tipo de problemas.

No hago ningún pronóstico, sólo espero que estas líneas contribuyan a mantenernos más despiertos. La seguridad es un proceso continuo, no un producto que se instala y queda funcionando.

Raúl

Redacción de Segu-info

Suscríbete a nuestro Boletín

1 comentario:

  1. Porque la gente no aplica los parches es más que claro. Usan software ilegal y entonces desabilitan la opción de actualización automática para que no los llene de carteles de advertencia.
    El resto viene solo.
    (una muy, pero muy mala lengua diría que no lo esté distribuyendo Microsoft como castigo a quienes usan software ilegal)

    ResponderBorrar

Gracias por dejar un comentario en Segu-Info.

Gracias por comentar!