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.
De película el caso, ni tan siquiera tenían backups independientes, podían haber restaurado todo y seguir funcionando. Es increible.
Muy buena la cronologia.
Esto es un ejemplo de las desventajas del software privativo.
Abrazo,
Damian.
Muy buen árticulo. Pense que se te iba a piantar la chapita :D. Pero no, simpre con profesionalidad.
Puedo decir 3 cosas:
– Lamento el suicidio del presidente de la empresa
– Espero que paguen hasta con sus organos la empresa de estafadores.
– El ataque es totalmente reprochable, digno de un castigo muy severo.
de http://www.theregister.co.uk/2009/06/09/lxlabs_funder_death/ :
«Ligesh [from LxLabs] was also still coming to terms with the suicides by hanging of his sister and mother five years ago.»
Supongo que esto puede aminorar el cargo de conciencia del atacante y hasta cierto punto el milw0rm este, la cual en mi opinion deberia estar limpia.
Una Pregunta: Como esto de hecharle la culpa al cartero esta de moda. ¿No fuiste vos?. Porque si es asi, arreglalo!.
:D:D:D
Javier,
Felicitaciones por el artículo, la trama, el relato, el suspenso, y como si fuera poco… la claridad.
… excelente amigo, excelente.
Sumamente interesante el artículo, así como el tema.
Creo que no es intuitivo, determinar la causa primera del daño, y a pesar de estar de acuerdo, en términos generales… si me surgen muchas dudas de cuál es la mejor y óptima forma de actuar en estos casos… .
Creo que se puede pensar en alguna forma en la cual se minimizen los daños.
No creo que cuando Einstein colaboró en la construcción de la Bomba Atómica midiese las consecuencias de su colaboración, ni que estuviese mun contento con los resultados.
De la misma forma, y salvando distancias, no creo que Milw0rm, supiera que alguien se iba a suicidar, y 100.000 sites se perderian, con su ayuda.
Me resulta difícil entender la posición ética correcta.
Igualmente, esto no es un cuestionamiento a tu artículo que es PERFECTO,
Saludos,
gab
Gabriel:
Gracias por las felicitaciones.
Einsten dijo «si hubiera previsto las consecuencias, me hubiera hecho relojero». Efectivamente, no estaba para nada contento con los resultados.
En el caso de milw0rm, claro está que no podía anticipar que habría un suicidio o que 100.000 sitios se verían afectados, pero (aún sabiendo que podría haber consecuencias) hizo lo único que podía hacer. Guardar silencio (además de hacerte cómplice de la estafa) sólo aumenta la probabilidad de un daño mayor.
Reitero: en estos casos (cuando alguien tiene conocimiento de un problema grave y el responsable no lo soluciona) es mejor, pasado un tiempo prudencial, divulgarlo. La cuestión es que ya en ese momento puede estar siendo explotado por alguien.
javier,
Muy buen post, el punto que resalto es el de la estafa, esos puntos que mencionan/publicitaban como supuestos diferenciales o como los items en los que la empresa se destaca, quedo demostrado que eran todas mentiras; considero que el hecho de ser software privativo no es mas que un argumento muyyyy de borde, las anormalidades no pasan por un tema de licenciamiento, queda flotando la posibilidad en que si era codigo abierto alguien mas lo revisaría y lo corregia, pero de ahi a que la empresa lo usase es otro cantar.
un fraterno abrazo desde Montevideo
Gabriel Icasuriaga,
Interesante… lo de privativo… quedo a expectante….
gab
Exelente post,que lastima lo que sucedió pero a veces tienen que suceder cosas como estas para servir de ejemplo de lo que se tiene que hacer y lo que no en estos casos.
Gabriel Icasuriaga:
Gracias por las felicitaciones. :)
Para mí, el hecho de que el software en cuestión sea privativo es justamente lo que posibilita la estafa (y ni hablar de ignorar por completo reportes de errores graves por 14 días).
Sólo tratándose de software privativo y cerrado puede el fabricante mentir descaradamente sobre sus características. Si el código fuente estuviera a la vista, la mentira sería demasiado evidente como para siquiera poder existir.
y a los propietarios de las 100.000 webs ¿ quien los indemnizara ?
Buen artículo.
Que bien hablais (y escribis) los argentinos. Pareces Borges hablando de informática¡¡¡¡¡¡¡¡¡¡¡
Una delicia…