Como os habíamos adelantado, explicaremos en esta noticia desde un punto de vista lo menos técnico posible, el ataque que ha sufrido la web de Inprosec y el impacto que ha tenido. Mostraremos así como se debe gestionar un incidente de seguridad de este tipo, y lo que hemos aprendido del mismo.
La antigua web de Inprosec había sido objeto de auditoría hace un año aproximadamente. Teníamos otra planeada para este año pero con la inminente entrada de la nueva web habíamos retrasado la auditoría para cuando entrase la nueva. En la pasada auditoría no se había detectado ninguna vulnerabilidad, ya que el error de seguridad que provocó el incidente, se produjo después de la misma.
El lunes un usuario de Inprosec notificó que la web no se mostraba como es debido. El departamento de Seguridad evaluó la notificación, y confirmó que la web había sido modificada, siendo objeto de un ataque.
Siguiendo el plan de respuesta a incidentes, lo primero que se hizo fue poner la página en modo mantenimiento, y hacer una evaluación preliminar del daño causado. Se detectaron entradas aleatorias en las tablas de la base de datos. Procedimos a quitar todos los posibles usuarios atacados que pudiesen autenticarse en la web, e hicimos un “snapshot” de página comprometida, tanto la base de datos como los ficheros.
Revisando los logs de nuestra plataforma así como las modificaciones de las entradas de la base de datos, acotamos la hora del ataque. Una vez definido el rango a revisar pedimos los logs del apache (tanto de conexiones como de errores) a nuestro proveedor de hosting.
Cotejando información de ambos logs, conseguimos encontrar los vectores que habían permitido el ataque, y el porqué de los mismos.
El atacante se presenta como una herramienta muy famosa para el escáner de vulnerabilidades, y se lanzaba desde una IP de un bot. Había lanzado cientos de ataques por segundo a nuestra web a través de todos los directorios; y aproximadamente un 5% de estos resultaron efectivos. Averiguamos que esta IP está relacionada con el SPAM y el fraude online
Un error de programación provocó que algunos ficheros php que existían en estos directorios pudiesen ser ejecutados sin autenticación. El atacante consiguió así escribir en nuestra base de datos, y borrar o duplicar ciertos contenidos.
Nosotros no habíamos detectado esta vulnerabilidad en nuestra auditoría de caja negra, ya que cuando la realizamos esos ficheros no eran accesibles desde internet, pero algo había cambiado en la configuración general del servidor, y unos meses después sí que lo eran.
Evaluando nuestras opciones, optamos por cortar el problema de raíz y en lugar de invertir más recursos arreglando la web antigua, adelantamos ligeramente la fecha de lanzamiento de la web nueva; corrigiendo así los errores de configuración que habían permitido este ataque.
Con esto se pone de manifiesto que la seguridad perfecta no existe. Lo que debemos hacer es mantener un nivel de seguridad adecuado a la importancia del activo y las exigencias del negocio, y tener un plan de respuesta para reaccionar con seguridad y rapidez.
Es fundamental realizar auditorías periódicas que aseguren que mantenemos el nivel adecuado de seguridad.
Esperamos que esta noticia os haya servido de ayuda e inspiración a muchos de vosotros.