Recientemente, hemos observado que hackers han comenzado a atacar servidores Microsoft SQL (MSSQL) utilizando su puerto TCP abierto. La base de datos está configurada con una contraseña débil, a pesar de que los administradores reconocen su importancia. Una vez que el atacante accede al usuario "SA", obtiene acceso completo a la base de datos. Asegurarse de que las acciones mencionadas estén implementadas es la principal prevención para evitar este tipo de ataques. También recomendamos personalizar el "Quick Heal Firewall", que permite a los usuarios configurar las reglas del firewall según sus necesidades. Si se configura correctamente, el Quick Heal Firewall puede proteger contra estos ataques de intrusión al bloquear el tráfico de red para proteger su infraestructura. Ya hemos analizado una configuración de firewall similar en nuestro artículo anterior.
En SQL Server 2000 vimos que la protección para la modificación de objetos de sistema es básica y se habilita mediante sp_configure para poder modificarlos. En SQL Server 2005 Microsoft modificó sustancialmente el almacenamiento de dichos objetos, pasándolos a una base de datos oculta llamada mssqlsystemresource. Sin embargo, no es posible detectar directamente la presencia de dichas bases con una consulta a sys.databases, ya que la propia vista filtra dicha base como protección por ofuscamiento. Para ver qué posibilidades de modificación tenemos en 2005, vamos a montar una copia de la base de datos resources. Como ejemplo de tampering, modificamos la vista sys.server_principals para ocultar un login sysadmin que nos crearemos como puerta trasera. Si intentamos ejecutar el ALTER, obtendremos un error por la presencia de funciones internas como sysconv y has_access, que no forman parte de la gramática TSQL estándar.
Por ello, el plan práctico propone cambiar sysconv por convert y eliminar la función has_access de la consulta. Luego detachamos la copia de la base de datos de recursos, detenemos el servicio SQL Server, machacamos los ficheros de la base de datos mssqlsystemresource con las modificaciones y volvemos a arrancar el servicio. ¿Cómo detectar su presencia? Aunque SQL Server 2005 va más allá en la seguridad de SQL 2000, sigue siendo relativamente sencillo realizar modificaciones potencialmente peligrosas. La evaluación de vulnerabilidades de SQL es una herramienta fácil de usar que puede ayudar a detectar posibles vulnerabilidades de la base de datos, realizar su seguimiento y corregirlas.
La evaluación de vulnerabilidad de SQL en SSMS proporcionó una manera de examinar e informar sobre posibles configuraciones erróneas de seguridad en las bases de datos de SQL Server de forma desconectada, en SQL Server 2012 (11.x) y versiones posteriores. Esta capacidad se consolida en un paquete de seguridad de base de datos completo, denominado Microsoft Defender para SQL, que permite realizar exámenes de evaluación de vulnerabilidad e identificar ataques en tiempo real en la base de datos a gran escala entre recursos en el entorno local y en la nube. Por el contrario, la evaluación de vulnerabilidad de SQL en SSMS no consume resultados de Defender for Cloud ni pueden cargarse los resultados de los exámenes locales, y no recibe actualizaciones en tiempo real, lo que puede provocar incoherencias con Defender for Cloud. Por ello se quitó la evaluación de vulnerabilidad de SQL de SSMS a partir de la versión 19.1.
La evaluación de vulnerabilidades de SQL es un servicio que proporciona visibilidad sobre el estado de seguridad e incluye acciones recomendadas para resolver problemas de seguridad y mejorar la seguridad de la base de datos. El servicio VA ejecuta un examen directamente en la base de datos y emplea una base de reglas de conocimientos que marcan vulnerabilidades y resaltan desviaciones con respecto a procedimientos recomendados, como errores de configuración, permisos excesivos y datos confidenciales sin protección. Las reglas se basan en procedimientos recomendados de Microsoft y se centran en los riesgos más grandes para la base de datos y sus datos valiosos. Los resultados del examen incluyen pasos para corregir cada problema y proporcionan scripts de solución cuando aplica.
Puede ejecutar un examen para comprobar problemas a nivel de servidor mediante el examen de una de las bases de datos del sistema. El cuadro de diálogo Detectar vulnerabilidades permite especificar la ubicación de los exámenes. El examen es ligero, seguro y de lectura; tarda unos segundos en ejecutarse. Una vez finalizado, el informe muestra el estado de seguridad, cuántos problemas se encontraron y sus niveles de gravedad. Los resultados incluyen advertencias sobre desviaciones con respecto a procedimientos recomendados y una instantánea de la configuración de seguridad, incluyendo entidades de seguridad y roles de base de datos con permisos asociados.
Cuando se revisan los resultados, es fundamental determinar qué hallazgos son verdaderos problemas de seguridad en el entorno. Se pueden marcar resultados como una línea de base aceptable para personalizar cómo se notifican. Después de establecer líneas de base, se puede ejecutar un examen nuevo para ver el informe personalizado. Es posible ver resultados de evaluaciones anteriores abriendo exámenes existentes desde el menú correspondiente. La evaluación de vulnerabilidad puede usarse para monitorizar que las bases de datos mantengan un alto nivel de seguridad y que se cumplan las directivas de la organización. Se pueden usar cmdlets de PowerShell para gestionar programáticamente las evaluaciones de vulnerabilidad de las instancias de SQL Server.
Microsoft ha publicado avisos de seguridad sobre vulnerabilidades en Microsoft SQL Server que pueden permitir la ejecución de código. Se proporcionan secuencias de comandos VB para denegar permisos a la función pública en sp_replwritetovarbin en todas las versiones afectadas, recordando que estas secuencias de comandos deben utilizarse con precaución y sólo cuando sea necesario. Se advierte que estas son soluciones temporales y que no deben usarse si ya existe una actualización de seguridad disponible. Se recomienda conservar prácticas de seguridad y entender que estas herramientas ilustrativas pueden requerir permisos elevados y cuentas de administrador para aplicar cambios en múltiples instancias.
Buenas prácticas defensivas para mitigar ataques al MSSQL
Para evitar que atacantes exploten MSSQL, es conveniente adoptar un enfoque por capas de seguridad. Asegurar que las rutas de red a los servidores SQL estén limitadas a un conjunto autorizado de sistemas o subredes y bloquear TCP 1433 en la medida de lo posible. Verificar que las herramientas de registro y monitorización capturen las consultas SQL que cruzan los límites de la red. Confirmar que las soluciones de detección y respuesta en el host estén habilitadas y actualizadas.
Es crucial asegurar que el marco .NET esté actualizado y que AMSI sea compatible con las soluciones de seguridad basadas en host. Seguir las directrices de endurecimiento de Windows Server y aplicar el principio de privilegios mínimos al configurar roles y cuentas. Registrar, ingerir y auditar centralizadamente los eventos de inicio de sesión de SQL Server. Cifrar contenido sensible para evitar exposiciones en caso de compromiso. Evaluar los enlaces entre servidores SQL para entender el tipo de autenticación que vincula el enlace.
- Bloquear el tráfico innecesario hacia SQL Server y limitar la exposición del puerto 1433.
- Mantener actualizaciones de seguridad y aplicar parches de forma regular.
- Configurar contraseñas robustas para cuentas privilegiadas como SA y limitar su uso.
- Desplegar herramientas de evaluación de vulnerabilidades y Defender para SQL para monitorizar en tiempo real.
- Implemetar controles de endurecimiento a nivel de sistema operativo y de base de datos.
Descripción y relevancia del puerto 1433 en SQL Server
Microsoft SQL Server utiliza el puerto 1433 como puerto predeterminado para aceptar conexiones de clientes mediante el protocolo TDS sobre TCP. Este puerto es una pieza crítica de la superficie de ataque si no se gestionan adecuadamente las credenciales y las políticas de acceso. La seguridad no se limita al puerto abierto: requiere autenticación adecuada, cifrado de tráfico y control de permisos a nivel de base de datos y servidor.