El caso Code Spaces (o como un ciberataque puede destruir – literalmente – una compañía en la nube)

El pasado mes de Junio, Code Spaces , empresa que ofrecía servicios de hosting para facilitar la colaboración en la nube de equipos de desarrollo de software, fue (literalmente) destruida como consecuencia de un ciberataque. Vamos a realizar un análisis de este caso, pues sirve para ejemplificar el tipo de amenazas que afrontan las empresas en el ciberespacio y mostrar cómo una inadecuada estrategia de seguridad en la nube puede acabar con un negocio en pocas horas.  Esperemos que el estudio de las causas raíz que han llevado a Code Spaces a la desaparición, permita extraer lecciones para que otros emprendedores de negocios en la nube no cometan los mismos errores o para aquellos que estén valorando llevar servicios críticos a la nube.

CodeSpaces_01

 

Ofrecemos a continuación una adaptación resumida y traducida del mensaje en el que la compañía explica el incidente:

¡!Code Spaces ha caído!!

Estimados clientes,

 El martes 17 de junio de 2014 recibimos una serie de ataques de denegación de servicio distribuido (DDOS) bien orquestados contra nuestros servidores; esto ha sucedido muy a menudo con anterioridad y normalmente lo hemos superado de modo que ha resultado transparente para la comunidad de usuarios de Code Spaces. En esta ocasión, sin embargo, el DDOS fue sólo el comienzo.

 Una persona no autorizada,  que a fecha de hoy no ha sido identificada  (Todo lo que podemos decir es que no tenemos ninguna razón para pensar que sea o haya sido empleado de Code Spaces) obtuvo acceso a nuestro panel de control de Amazon EC2 y dejó una serie de mensajes para que nos pusiéramos en contacto con los responsables del ataque mediante una dirección de Hotmail.

Se inició a partir de esta cuenta de correo una cadena de contactos en los que la persona nos extorsionaba y solicitaba una fuerte suma de dinero a cambio de que cesara el ataque DDOS.

 Al darnos cuenta de que alguien había accedido a nuestro panel de control, comenzamos a investigar cómo se había logrado acceder y el nivel de acceso que este intruso tenía a los datos en nuestros sistemas, haciéndosenos evidente que hasta el momento ningún acceso a nivel de la máquina se había logrado debido a que el intruso no tenía nuestras claves privadas.

 En este punto, procedimos al cambio de contraseñas para retomar el control del panel de administración de nuestra infraestructura en Amazon; sin embargo, el intruso había previsto  esto y al detectar nuestro intento de recuperación de la cuenta, procedió a eliminar al azar información crítica. Finalmente logramos conseguir acceder, pero para entonces el atacante ya había borrado información crítica. En resumen, la mayoría de nuestros datos, copias de seguridad, configuraciones de la máquina y las copias de seguridad estaban total o parcialmente eliminadas de manera irreversible. Esto tuvo lugar durante un período de 12 horas que he condensado en esta breve explicación

 (…)

 Code Spaces no podrá seguir operando más allá de este punto. el coste de la solución de este problema hasta la fecha y el coste esperado de la indemnización a los clientes que se han quedado sin el servicio que pagaron,  pone a Code Spaces en una posición irreversible tanto financieramente como en términos de credibilidad.

 Por ello no tenemos otra alternativa que cesar nuestra actividad y concentrarnos en apoyar a nuestros clientes afectados en la exportación de los datos restantes que les quedan con nosotros.

 Todo lo que podemos decir en este momento es cuánto lo sentimos, tanto a nuestros clientes como a las personas que se ganaban la vida en Code Spaces. (…) En nombre de todo el personal de Code Spaces, por favor, acepta nuestras más sinceras disculpas por las molestias que le haya causado. Esperamos que un día volvamos a ser capaces de restablecer y el servicio y la credibilidad que alguna vez tuvo Code Spaces!”

CodeSpaces_02

¿Cómo es posible que el incidente haya sucedido?

 Sobre la protección de las copias de respaldo (backups)

En primer lugar, parece que la información que Code Spaces ofrecía en su web (ahora inaccesible) sobre la seguridad de las copias de respaldo de los datos de los clientes, era cuando menos incompleta o engañosa:

“En Code Spaces, cada vez que tú realizas un cambio en los datos, nosotros realizamos copias de seguridad que almacenamos en múltiples localizaciones off-site. Esto te dá la tranquilidad con cada commit…”

Lo que parece claro es que, aun dando por cierto que se realizaban copias de seguridad en múltiples ubicaciones, el control de todos estos backups se debía realizar desde un único panel de control centralizado en Amazon. Al haber sido comprometido el acceso a este punto centralizado de control, se pudieron destruir los backups.  La realización de copias múltiples del backup en ubicaciones distintas podría ser una medida efectiva en caso de fallo en alguno de los servidores; pero, obviamente, dado el aparente control centralizado de estos backups, esto no era suficiente para un caso de sabotaje.

Sobre el acceso ilícito a la consola centralizada de administración

A partir de la explicación dada por la compañía no se puede descartar (de hecho, sería la explicación más plausible) que los atacantes conociesen previamente las claves de los administradores en el panel de administración. Tampoco es descartable que los atacantes sean o hayan contado con el apoyo de empelados (o ex-empleados) de la compañía.

No se menciona nada sobre el mecanismo de acceso a la consola de administración en Amazon; sin embargo, no parece que estuviese habilitada la autenticación multifactor (basada en algo que se conoce, como una contraseña y algo que se tiene; como por ejemplo un generador hardware de claves desechables o un móvil que recibe códigos adicionales de acceso). De haber estado habilitado este control adicional, esto querría indicar con alta probabilidad que los atacantes contaban con apoyo de dentro de la organización y/o acceso físico a algunos recursos de la compañía.

Cómo podría haberse evitado el desenlace desastroso

Para finalizar este post, vamos a enumerar brevemente algunas medidas que habrían ayudado a evitar o al menos mitigar las consecuencias de un ataque de este tipo:

 Política de copias de respaldo redundantes a prueba de sabotajes

En el caso que hemos revisado, parece que había copias de seguridad redundantes en varios servidores diferentes; sin embargo, todo la gestión del proceso se realizaba desde una única consola de administración y en la infraestructura de un único proveedor (Amazon); por ello, al quedar comprometida la clave de la única consola de administración, quedó expuesta toda la información. Este modelo, como hemos mencionado, serviría para prevenir fallos técnicos de la plataforma, pero no un caso de acceso ilícito y sabotaje.

Lo deseable es que las copias de respaldo de la infraestructura sean almacenadas en servidores de plataformas distintas cuyo acceso de administración sea distinto al del administrador de backup. De este modo, aunque se comprometiese la clave de la consola de administración de la infraestructura desde donde se realizase el backup, esto no implicaría por sí mismo que se pudiesen sabotear las copias de respaldo almacenadas en otras infraestructuras.

Si es factible además, por el volumen de datos, es recomendable almacenar copias de respaldo en soportes físicos que puedan ser almacenados localmente de manera segura (por ejemplo, en una caja fuerte ignífuga) en las oficinas de la compañía dueña de la información o en las dependencias de  empresas terceras especializadas.

Análisis de Riesgos

Conviene que las compañías de servicios lleven a cabo un análisis de riesgos que contemple los escenarios que pongan en riesgo su capacidad técnica para continuar dando servicio a sus clientes. A partir de este análisis deben diseñarse controles y planes para poder restablecer y garantizar la continuidad del servicio ante contingencias diversas de la infraestructura técnica. En el caso que hemos revisado, el plan de contingencia cubría escenarios de errores técnicos puntuales de la infraestructura; pero no escenarios de sabotaje de elementos técnicos críticos. El diseño de la política de copias de respaldo que hemos mencionado anteriormente obedecería a un análisis de este tipo de escenarios.

Para ayudar a centrar el análisis de riesgos remitimos al lector a nuestro anterior post, sobre peores escenarios de riesgo en el e-commerce.

Seguridad de las conexiones remotas de administración

El acceso remoto de administración debe realizarse desde equipos informáticos fuertemente securizados, de modo que se reduzca al máximo la probabilidad de infección de los mismos con software malicioso (ej: keyloggers, etc…). Por otro lado,  debe asegurarse que la conexión con el servidor esté cifrada de acuerdo a los estándares de la industria. Además, si es factible, debe explorarse la posibilidad de que la conexión a la página/consola de administración se restringa a determinadas direcciones IP y que se disparen alertas de monitorización cuando haya intentos de conexión, desde otras direcciones.

Monitorización de Seguridad

Establecer un proceso de monitorización proactiva de los accesos a las infraestructuras críticas puede ayudar a la detección temprana de actividades ilícitas. Si bien esto, por sí mismo no evita el incidente, sí que puede dar la oportunidad de gestionarlo.

Autenticación Multi-Factor

El acceso a las consolas de administración de infraestructuras críticas no puede basarse en mecanismos inseguros como el simple uso de pares [usuario + contraseña]. En estos casos, deben habilitarse mecanismos de autenticación fuerte (basada en algo que se conoce, como una contraseña y algo que se tiene; como por ejemplo un generador hardware de claves desechables). En caso de que un proveedor de servicios Cloud no facilite la posibilidad de establecer autenticación fuerte, esto debe tenerse en consideración y no es recomendable cuando se trata de gestionar infraestructuras críticas para nuestro negocio.

 Gestión de derechos de acceso

Las claves de administración deben ser cambiadas frecuentemente. De manera especial, además, cuando un empelado con privilegios de administración cambia de responsabilidad o se va de la compañía, debe procederse al cambio sistemático de todas las claves que conociese y a la inhabilitación de los elementos necesarios para la administración (ej: portátil, teléfono móvil, llaves hardware de generación de claves de acceso desechables…).

banner_me

Ir al nuevo blog

 Otros artículos relacionados

Ataques DDoS

Peores Escenarios de Riesgo tecnológico

Externalización de aplicaciones críticas en la nube

Soluciones Cloud sobre Amazon Web Services: distribución de responsabilidades en el control y la seguridad

 

 

 

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s