Voy a relatar este suceso en orden cronológico, porque me parece que es el más razonable para entender las causas e identificar a quienes corresponden las responsabilidades de un incidente lamentable (e increible).

La empresa de alojamiento web Vaserv utiliza un sistema de virtualización de servidores llamado HyperVM, que se complementa con un panel de gestión llamado Kloxo (anteriormente LxAdmin). Ambos productos (privativos) son desarrollados por la empresa india Lxlabs.

El 21 de mayo de 2009, un experto en seguridad apodado milw0rm descubre 24 problemas serios de seguridad en Kloxo. Inmediatamente (según informa luego), envía un email a Lxlabs (conteniendo un enlace al informe detallado), alertando sobre la existencia de vulnerabilidades graves. Dos días después, recibe una respuesta (sin firma) diciendo que a la brevedad lo verificarían.

Una semana después, reitera el aviso, recibiendo (al día siguiente) una respuesta en la que afirman que están trabajando en eso y que en un par de horas le informarían. Finalmente, el 4 de junio (14 días después del informe inicial), ante la falta de respuesta de Lxlabs (y notando que ni siquiera habían accedido al enlace con el informe detallado), se decide a hacer públicos los errores (y la historia).

4 días después (el 8 de junio) ocurre el desastre: un grupo de atacantes borra absolutamente todos los archivos de aproximadamente 100.000 sitios alojados en Vaserv (¡incluyendo las copias de respaldo!).

Al día siguiente, el jefe de Lxlabs (K T Ligesh, de 32 años), se suicida ahorcándose.

Algunas conclusiones

En varios sitios se han armado profusas discusiones sobre el tema (Slashdot, Barrapunto, ComunidadHosting, entre otros). Las opiniones se reparten entre las condolencias por la muerte de Ligesh, las condenas a la negligencia de Lxlabs y las imputaciones a los atacantes e incluso a milw0rm.

A la hora de repartir responsabilidades por lo ocurrido, según mi opinión (¡que por algo este es mi blog!), hay que separar varias cuestiones:

La estafa de Lxlabs

Basta contrastar la publicidad de Lxlabs respecto de las bondades de su producto en materia de seguridad, con el informe de los errores para darse cuenta de que se trata de una gran mentira: de los cinco puntos resaltados como grandes virtudes, los cuatro primeros son totalmente falsos y el quinto resulta totalmente irrelevante (y hasta cómico, en el contexto de lo sucedido).

Las reproduzco a continuación (resumidas y en castellano), ya que seguramente en breve serán quitadas del sitio web:

• Kloxo se ejecuta con el usuario ‘lxlabs’, que es un usuario normal del sistema, sin ningún permiso especial.
• El administrador de archivos nunca acepta un path completo proveniente del usuario.
• Un usuario no puede realizar ninguna operación sobre un archivo que no le pertenezca.
• Todas las ejecuciones de programas se realizan luego de cambiar al contexto del usuario que lo requirió.
• Kloxo registra cada cambio que se haya hecho en el sistema de archivos, así como también cada ejecucion de un programa externo.

Esto es, lisa y llanamente, una estafa. Pero una estafa bastante común en el mundo del software privativo, en donde el cliente no tiene más remedio (si acepta el trato) que confiar ciegamente en las propiedades que el proveedor asegura que su software tiene.

La estupidez de Lxlabs

Los errores en Kloxo son realmente patéticos. Lamentablemente nadie fuera de Lxlabs puede ver el código, pero basta analizar cada bug para darse cuenta de que el programa está escrito por gente que no tiene la más somera idea sobre seguridad.

La estupidez de Vaserv

Esto es menos evidente (y bastante más común), pero… ¿no hay bastante de estupidez en una empresa que utiliza un programa crítico para mover todo su negocio y confía ciegamente en el proveedor que se lo ofrece? Yo digo que sí.

La negligencia de Lxlabs

Recibir un email informando sobre 24 problemas graves, luego un segundo aviso, responderlos a ambos, y en 14 días ni siquiera dignarse a mirar de qué se trata merece, cuando menos, este calificativo.

La negligencia de Vaserv

La estupidez y negligencia de Lxlabs no excusan de ninguna manera a Vaserv de su responsabilidad, adquirida ante sus clientes al venderles un servicio como “seguro” y “estable”, y luego no tomar los recaudos para evitar semejante desastre.

Ante sus clientes, es claro que son ellos los únicos responsables (a estos, poco les importa si Vaserv eligió contratar el servicio de Lxlabs o de quien sea…).

La malicia de los atacantes

Casi por descontado, el o los atacantes, que causaron un daño terrible (e incalculable a priori) no tienen ningún justificativo para lo que hicieron.

Cabe destacar que, si bien hicieron un desastre, no lucraron con la vulnerabilidad (pudieron haberla usado para realizar estafas, robar información, y un largo etcétera.).

Otra aclaración: como puede verse en el informe de los problemas, la ejecución de las técnicas de ataque no requieren demasiados conocimientos. Bien podría haberlas realizado un niño con un poco de tiempo, ganas de experimentar y, claro está, una gran desaprensión por la información de terceros.

El rol de milw0rm

Amén del tiempo que dedicó para descubrir todas estas vulnerabilidades (seguramente, sin que nadie le pagara a cambio), tuvo la mejor disposición posible: Notificó detalladamente al responsable del software, esperó un tiempo prudencial, volvió a notificarlo. Fué sólo ante la inactividad de éste que se decidió a divulgar públicamente el problema.

Muchos critican esta actitud (hasta llegar al extremo de culparlo por el ataque). Hay que tener en cuenta, antes que nada, que habiendo encontrado semejantes errores bien podría haberlos vendido (en una buena suma) a alguna organización delictiva. ¿Qué más podría haber hecho, al no tener respuesta? Guardar silencio no es una opción, en el caso de querer hacer algo positivo: estaría siendo cómplice de la desidia (y la estafa) del proveedor, y seguramente el problema sería detectado por alquien más, quién sabe con qué actitud.

Aunque suene contradictorio (y esto es conocido y aceptado en los ámbitos relacionados con la seguridad), cuando el responsable de un programa es informado de un problema y pasado un tiempo razonable no hay respuesta, lo mejor que puede hacerse es divulgarlo, con el fin de evitar un mal mayor (y de paso, para que la negligencia de dicho proveedor quede puesta de manifiesto).

Conclusiones

Como puede verse, la salida simplista de cargar las tintas sobre el atacante que “volteó” 100.000 sitios de un plumazo (y que bien puede haber sido un adolescente desaprensivo) oculta a los mayores responsables del problema y las pérdidas de las víctimas.

Una buena forma de comenzar a reducir la frecuencia de ocurrencia de estos incidentes (y su impacto) es tomar conciencia de por qué ocurren.