Un Honeypot es un sistema el cual se expone de forma intencionalmente a un riesgo para observar cual sería el comportamiento “on the wild” en el caso de un sistema real desprotegido.
Creamos un Honeypot de un SQL Server al que se expone su puerto 1433 a Internet y además se utiliza una cuenta SA/sysadmin con un password sencillo.
Comenzaremos creando una máquina virtual con SQL Server 2019 a la que configuraremos conectividad pública, en el puerto 1433 y con autenticación de SQL Server:
Una vez tenemos la máquina creada, vamos a configurar que la información de nuestros logs se almacene en una cuenta de almacenamiento. Para ello comenzaremos creando un Log Analytics workspace (si no tenemos uno ya creado) y asociaremos nuestra VM:
A continuación habilitaremos el guest-level monitoring:
Durante todo este proceso, y en general con Azure, hay que tener algo de paciencia, ya que pueden pasar algunos minutos desde que realizamos la creación de un recurso y podemos utilizarlo. Seleccionaremos todos los logs de momento, para tener el máximo de información accesible desde fuera de la máquina, por si perdemos el control de ésta tras el ataque:
Es importante también asegurarnos que las extensiones finalizan su instalación correctamente. Especialmente si estamos usando una VM pequeña el tiempo puede ser elevado:
A continuación, conectaremos a la máquina y para “ablandar” algo más la seguridad y haremos algo que desgraciadamente muchas veces observamos en clientes: ejecutar el servicio con una cuenta con más permisos de los necesarios. En este caso usaremos una cuenta con permisos de administración local de la máquina:
También crearemos una auditoría a nivel de instancia que guardaremos en el application log para aumentar la información que dejemos registrada:
En poco tiempo, a los pocos minutos de tener la máquina levantada y con el puerto 1433 expuesto en Internet, podremos ver que en el log de SQL Server ya tenemos intentos de conexión a la cuenta de SA:
La gran mayoría de estos ataques vienen de China o Rusia:
Una vez hecho todo esto, comprobaremos que tenemos acceso a los logs externamente a la máquina desde el portal, con el Storage Explorer sobre nuestra cuenta.
También podemos integrar los logs con Azure Monitor tras asignarle una identidad de sistema en nuestro Azure AD:
También crearemos una base de datos con una tabla de nombre sugerente en la instancia, por si hay algún intento interactivo de conexión:
Y ya por último solo nos faltará “abrir la veda” activando la cuenta SA y poniendo un password sencillo, utilizando alguno de los valores habituales y que no deberíamos utilizar como sa, admin, P@ssw0rd, etc. A los pocos minutos de aplicar el cambio, recibimos nuestro ataque, cuya parte inicial podemos ver en una traza de profiler, hasta que ésta se cierra (por efecto del propio atacante que cierra todas las trazas que estén ejecutando):
Podemos ver cómo se eliminan varios procedimientos almacenados de sistema, se registran contra otras DLLs y se lanza este script para configurar y habilitar ole automation, xp_cmdshell así como cerrar todas las trazas que estuvieran abiertas:
EXEC sp_configure ‘show advanced options’,1;RECONFIGURE WITH OVERRIDE;EXEC sp_configure ‘xp_cmdshell’,1;RECONFIGURE WITH OVERRIDE;eXEC SP_CONFIGURE ‘SHOW ADVANCED OPTIONS’,1;RECONFIGURE WITH OVERRIDE;EXEC SP_CONFIGURE ‘SHOW ADVANCED OPTIONS’,1;RECONFIGURE WITH OVERRIDE;EXEC SP_CONFIGURE ‘DEFAULT TRACE ENABLED’,0;RECONFIGURE WITH OVERRIDE;EXEC sp_configure ‘Ole Automation Procedures’,1;RECONFIGURE WITH OVERRIDE;exec sp_configure ‘Agent XPs’, 1;RECONFIGURE WITH OVERRIDE;DECLARE @i INT,@Size INT;SET @i=1;SELECT @Size = MAX(traceid) FROM ::fn_trace_getinfo(default);WHILE @i <= @Size BEGIN EXEC SP_TRACE_SETSTATUS @i,0; SET @i=@i+1; END;
También, se nos modifica el password de SA y dejamos de tener acceso a la instancia:
El ataque también crea una cuenta llamada Mssqla para mantener acceso sysadmin aunque volvamos a modificar la cuenta sa y reseteemos su password:
También vemos en las trazas que se están intentando lanzar comandos de sistema operativo desde jobs de SQL Agent:
La mayoría de los jobs han funcionado, ejecutando sus malignos contenidos:
Algunos de los jobs son de tipo “ofuscado” como este que os mostramos, donde se intenta ocultar un varchar dentro de un string en hexadecimal, una técnica bastante habitual:
Si convertimos byte a byte nos aparece el siguiente código que es el que realmente se ejecuta:
No es el objetivo entrar en detalle en este script pero podríamos decir que el resumen de ese script es que “no hace nada bueno”, se conecta a servidores externos, descarga scripts, registra librerías sospechosas, etc.
Como la cuenta de SQL tiene permisos de administrador, el ataque ha instalado varios troyanos en la máquina sin dificultad:
En este tipo de situaciones realizar una “limpieza” del servidor suele ser la peor de las alternativas a largo plazo. Nunca tendremos la certeza al 100% que todo queda limpio y no queda afectada alguna librería, servicio, etc. que pueda volvernos a comprometer en un futuro.
Por tanto llegados a este punto el siguiente paso lógico sería salvar la información que podamos necesitar del servidor comprometido, preferiblemente de una forma offline y no conectando con el servidor para copiar ficheros vía SMB, etc. La razón es que si hacemos esto estamos dando más posibilidades al malware para intentar extenderse a otros equipos mediante esa vía. También en este caso alguno de los malware incluidos añaden un keylogger, por lo que cualquier usuario o password que escribamos una vez conetados a la máquina infectada acaba en manos del atacante y podríamos estar dándole acceso a otros sistemas. Por tanto, lo mejor es extraer de forma offline la información (ojo con los ficheros de naturaleza “infectable”, como ejecutables, ficheros Office, etc.) y destruir el servidor totalmente al finalizar:
La conclusión de esta prueba es que realmente “ahi fuera” hay muchos scanners y herramientas automatizadas lanzando ataques de forma contínua. El que nuestra máquina esté en un proveedor cloud no nos protege de este tipo de ataques, podría protegernos de algún ataque de tipo DoS, pero un intento de conexión puntual no va a estar “cortado” por defecto si nos hemos expuesto innecesariamente con una IP pública. Incluso aunque no usemos acceso externo, hay ciertos riesgos si permitimos el acceso a los servicios de Azure. La propia Microsoft recomienda que desactivemos esta opción para reducir la superficie de ataque:
Sin embargo, vemos que hay muchos clientes que para poder utilizar servicios como Azure Data Sync u otros como PowerBI (de forma sencilla, sin crear un on-premise gateway pero desplegado en Azure en una VNET para desde ahi asegurar el acceso) acaban teniendo esta opción habilitada. Esto abre la posibilidad a muchos atacantes que tengan una subscripción de Azure accesible a intentar atacar a nuestros servidores a través de servicios de Azure comprometidos. Idealmente deberiamos poder limitar que los servicios solamente pudieran acceder si forman parte de nuestra subscripción y tener incluso una lista de ellos para tener más granularidad de a cual/cuales dejamos acceso, pero es ciertamente complejo debido a la naturaleza SaaS (y con recursos compartida entre clientes) de muchos de estos servicios cloud. Algo parecido nos puede pasar si tenemos que dar acceso externo a terceras partes, a un proveedor, a un cliente, etc. donde una falla de seguridad en sus sistemas puede acabar afectándonos indirectamente a los nuestros.
Muchos habréis visto en noticias recientes ataques de Ransomware que han afectado a empresas grandes como Garmin, Canon, ADIF, Mapfre etc. Debemos concienciarnos que el grado de profesionalización y complejidad de los ataques se va incrementando con el tiempo y con ello el riesgo de que acabemos siendo un objetivo de los hackers. En nuestro mundo donde los datos son la fuente de muchas decisiones del día a día de negocio que dejen de estar accesibles para nuestra organización puede causar un gran perjucio. Además puede generar un gran problema de imagen corporativa o implicar sanciones por el no cumplimiento de la legislación de protección de datos si acaban siendo estos datos expuestos públicamente. Por tanto, es vital que mantengamos un control férreo sobre nuestros datos, tanto desde el punto de vista de la seguridad en el acceso, de su encriptación como de sus respaldos offsite para los casos más graves que requieran poner en marcha nuestro plan de recuperación ante desastres.
X Edición Executive Máster en BI & Advanced Analytics con Tecnologías Microsoft. Conviértete en un año en un experto en BI con un seguimiento personalizado de los mentores y MVPs de SolidQ y con el nuevo temario del máster en BI & Advanced Analytics , introduciendo Modern Data Warehouse, analítica y visualización avanzada.
¡Empezamos en octubre! Inscríbete ahora y aprovecha el descuento que hay disponible hasta finales de julio o completar inscripciones. Toda la información aquí.
