En los últimos días hemos recibido una noticia que desde China se estaban produciendo ataques de fuerza bruta a servidores SQL Server. La puedes leer completa en el siguiente enlace:
https://www.guardicore.com/2020/04/vollgar-ms-sql-servers-under-attack/
Se registraron alrededor de tres mil ataques llamados “vulgar” sobre instancias de bases de datos que estaban expuestas a internet con contraseñas consideradas débiles.
La brecha de seguridad la encontraron en usuarios SQL Server con el rol ‘sysadmin’ que les permitía habilitar las siguientes opciones:
EXEC sp_configure 'show advanced options', 1;RECONFIGURE;
EXEC sp_configure 'xp_cmdshell', 1;RECONFIGURE;
exec sp_configure 'show advanced options', 1;RECONFIGURE;
exec sp_configure 'Ad Hoc Distributed Queries',1;RECONFIGURE;
exec sp_configure 'show advanced options', 1;RECONFIGURE;
exec sp_configure 'Ole Automation Procedures',1;RECONFIGURE;
exec sp_addextendedproc xp_cmdshell,'xp_cmdshell.dll'A partir de todas estas modificaciones generan usuarios locales en el sistema operativo, crean ejecutables que consumen CPU y memoria, y alteran claves de registro. Podéis ver todo el proceso y más información en la noticia anterior de la empresa de seguridad cibernética GuardiCore.
¿Cómo evitarlos?
El objetivo de esta entrada es cómo podríamos haber evitado estos ataques en nuestras instancias SQL Server. Como DBA’s, es nuestra responsabilidad que un ataque de fuerza bruta no pueda romper nuestra seguridad. Por ello es importante tener activada la opción de “Enforce Password Policy” :
De esta forma, si la política de bloqueo de contraseña es por ejemplo cinco intentos, se bloquearía y no podrían seguir intentando hasta que algún usuario con permisos necesarios la desbloquee.
Otro de los factores que esta opción nos permite, es que comprueba la complejidad de la contraseña: que está deba disponer de mayúsculas, minúsculas, números, caracteres, repetición, etc. Todo esto se define en las políticas a nivel del sistema operativo donde está corriendo el SQL Server (normalmente se configura con políticas de dominio). La podéis ver en la consola Local Security Policy (secpol.msc):
Para saber que usuario SQL tiene la opción habilitada puedes usar esta query:
select name,is_policy_checked from sys.sql_loginsEn el siguiente enlace de Microsoft podéis comprobar todas las columnas e información de la tabla de sistema sys.sql_logins:
Y para comprobar si un usuario está bloqueado, podéis usar esta query sobre la misma tabla:
select name,LOGINPROPERTY(name,'isLocked') as UsuarioBloqueado from sys.sql_loginsMás información sobre la función de sistema LOGINPROPERTY en la página de Microsft:
https://docs.microsoft.com/es-es/sql/t-sql/functions/loginproperty-transact-sql
Nuestro laboratorio:
Estos fueron los resultados tras realizar pruebas en nuestro laboratorio:
Para ello hemos realizado una prueba muy básica con ayuda de un Powershell e iteraciones un ataque de fuera bruta sobre un usuario “sa”.
El script de Powershell es el siguiente:
$passwords = Get-Content "C:\Users\Toño\Desktop\SICUEL.es\AtaqueFuerzaBruta\Contraseñas.txt"
foreach ($password in $passwords){
Write-Host "Intento conexión con contraseña: " $password
try {
Invoke-Sqlcmd -ServerInstance "192.168.1.134\SICUEL1" -Username sa -Password $password -Query "Select @@version"
} catch {
"No se ha podido conectar al gestor SQL Server"
}
}Usamos un fichero llamado Contraseñas.txt que tiene diez contraseñas:
Al intentar conectar con cada una fallan por contraseña fallida (la buena es la número 10), pero ya la cuenta está bloqueada como podéis ver en el log:
De esta forma evitaríamos que entren a nuestra instancia con un usuario administrador.
Si no tuviésemos habilitada esta opción, podríamos entrar y por ejemplo ejecutar un comando de Shell para saber que usuario levanta el servicio SQL Server:
Desde SICUEL.ES os recomendamos que reviséis todos vuestros usuarios SQL y comprobéis si tenéis o no la opción CHECK_POLICY habilitada en todas vuestras instancias SQL Server.
