Estimados amigos !!!
Me hace mucha ilusión participar en este artículo, ya que aúna dos de mis pasiones, una quizás más pasada y otra presente, pero sin dudas dos disciplinas que me han marcado en mi carrera. Me refiero a las bases de datos y la ciberseguridad.
El primer curso que impartí en mi vida fue sobre Sql Server 7 creo que recordar en 3000 informática allá por el 2000, y siempre me fascinó el funcionamiento interno del motor, la memoria, la optimización. Si es cierto que me gustaba más la parte de "sistemas" que desarrollo, y eso derivó en mi pasión por los servidores. Pero bueno, batallitas aparte, que este post va de Seguridad en Sql Server sobre Windows.
Comenzamos "asentando" nuestro Sql Server sobre una UO que nos permita luego filtrar el conjunto de GPO´s diseñadas para la labor y a continuación creamos la Directiva de grupo vinculada a dicha UO. Metemos el servidor a la UO y comenzamos el viaje...
Siguiente paso, quitar roles del servidor. Si no vas a imprimir, quita el rol de servidor de impresión. Hay ataques que explotan este servicio y cuando menos superficie de exposición, mejor.
Establecer el servicio de copias VSS manual y no iniciado. Podemos sufrir un incidente por este mecanismo y no es necesario ( a no ser que sí lo sea).
Cambia el nombre al usuario SA y comprueba que está deshabilitado.
En las propiedades del servidor, en seguridad, habilitar la auditoría de inicio de sesión, correcto y erróneo.
Habilita la auditoría general del sistema creando una nueva política y establece la rama "Seguridad" o el fichero donde quieres ques se guarde. Esto dependerá del uso que le vayas a dar, y si tienes un SIEM o un SYSLOG y la manera que tenga de recolectar la información.
Firewall
Uno de los aspectos claves para securizar una instancia de Sql Server es el firewall del sistema operativo que corre bajo el. Por defecto, el puerto TCP de Sql Server escucha en la "emisora" 1433. Sin embargo, en servicios "menos" pro como Sql Express la conexión con el motor se hace por puertos aleatorios. Como se puede saber el puerto, viendo el log, pero Sql Server gestiona esto con el Sql Browser, que escucha en el puerto UDP 1434. Según tu entorno, sabiendo esto, la recomendación es abrir solo el puerto 1433 y si es posible, deshabilitar el servicio Sql Browser para cumplir con el compromiso de minimizar la superficie de exposición... Si necesitas este "dinamismo" en los puertos de entrada, te recomiendo leer este documento, y filtrar el servicio por el ejecutable, no por el puerto.
Protección extendida
Imagina el concepto de un Rogue AP. Montar un acces point wifi similar a uno en producción, y esperar que los clientes se intenten conectar... enviando sus credenciales...
El mismo concepto se puede dar en un entorno de Man in the Middle contra un sql server mediante una autenticación basada en NTLM, en la que el cliente envía el desafío, pero un atacante "en medio", por ejemplo habiendo falseado una entrada DNS, puede hacer de relay contra el Sql Server real y así hacerse con el acceso.
Microsoft implementa el Extended Protection, lo que hace es añadir un token único para cliente, y establecer una whitelist de SPN, o cuentas en las que sí se podrá acceder. De esta manera podemos evadir dicho ataque de manera sencilla.
Esta vulnerabilidad no es intrínseca de Sql Server, sino de la autenticación basada en NTLM, por lo que es aplicable a otros servicios, como el conocido uso de Responder o Inveight para el mismo concepto, pero implementando el ataque para la aplicación SMB ( compartición de carpetas) o HTTP ( las páginas wweeeeeee).
La recomendación genérica para entornos Microsoft, es deshabilitar la autenticación NTLMv1 pero ni siempre es posible, sobre todo, con sistemas Legacy o no Compliance 100% etc...y también se puede creackear.
Vamos a hacer una pequeña prueba de concepto para que veais lo "sencillo" que es aprovechar este fallo.
Voy a usar la herramienta Inveigh, el clon de Responder para Powershell. La tool ejecuta un servidor SMB falso y esnifa, escucha, peticiones NTLM en la red. El escenario teórico del ataque sería una red en la que conseguimos acceso a un sql server, por ejemplo mediante una SqlInyection y podemos ejecutar "cosas". Si podemos ejecutar una dirtree en una equipo remoto, es decir un DIR, estaremos pasando las claves NTLM* al equipo destino. Si ese equipo destino es la herramienta, esnifará la petición y obtendremos el codiciado hash. Luego lo usaremos de varias maneras, pero se extralimita de este propósito. Vamos a verlo. Ejecuto una consulta desde el SqlServer hacía Inveigh
Y ahora vemos en la herramienta como hemos capturado el hash.
Actualizaciones
El tema de las actualizaciones siempre ha sido complejo, pero como todo en la vida, al final es un reto más, pero no podemos dejarlo de lado. En numerosas auditorías y pentest que hago informo de versiones de Sql Server Viejas y sin parches importantes. Como que a TIC, y si es una rama dev. más aún, les da la risa floja en plan: "ahora viene este a decirme que no parcheo la bbdd" pero es necesario.
Es importante conocer un poco más sobre esta tarea que no todo el mundo sabe. Por lo general, los parches se liberan el segundo martes de cada mes, como los Windows... por lo que por la noche, o el miércoles por la mañana, tendrás parches...
Las actualizaciones suelen dividirse en 3 grandes grupos: HotFix, suelen ser soluciones a errores puntuales. CU o actualizaciones acumuladas, que son un conjunto de HotFix. Services Pack, son un conjunto de CU´s y HotFix y suelen tener funcionalidades nuevas. El ciclo de publicación es mayor por lo que suelen estar mucho más testeadas y son mas seguras y estables.
Dentro de este modelo, también debemos separar dos "branches" de las actualizaciones, una basada en hotfix puntuales que tienes o no, y otra denominada GDR ( General Development Release).
Imagina un hotfix que soluciona un problema X para los Sql Server sobre 2019 en versión castellano en servidores Hp de la gama ZYX... puede que tengamos ese parche, ese hotfix, si tenemos esa casuística concreta... pero si sale el service pack 1, esta "rama" de actualizaciones es general para todos los sql servers. El service pack 2 incluiría todas las actualizaciones del 1, por ser acumulativo.
Me gusta este video de mi líder mundial Enrique Catala.
Usuario Servicio
Otra de toda la vida... Si instalas un SqlServer con permisos de administrador del dominio, el SqlServer se ejecuta con este contexto de seguridad. Si un atacante accede a la bbdd, accede con esos permisos... Es sencillo. Hay que crear usuarios específicos para el servicio, y fortificarlos para que tengan solo los permisos necesarios para la labor de ejecutar el servidor. No tiene sentido que ese usuario tenga acceso de escritura a la carpeta "nóminas" de ese fileserver... si no es necesario.
NMAP
Un básico de los sistemas y más estos, es realizar auditorías periódicas para conocer el estado real de la seguridad de los mismos. Es común creer que nuestros entornos son más seguros de lo que lo son, y en el peor de los casos, podemos aprender de cambios no controlados. Nos ocurre muchas veces que encontramos planteamientos distintos de los que creían en la organización, por un cambio en un partner, una reparación rápida y "provisional", etc...
Aunque no estés muy puesto en este mundo, lanzar desde un linux algo así : nmap --script ms-sql-info,ms-sql-empty-password,ms-sql-xp-cmdshell,ms-sql-config,ms-sql-ntlm-info,ms-sql-tables,ms-sql-hasdbaccess,ms-sql-dac,ms-sql-dump-hashes --script-args mssql.instance-port=1433,mssql.username=sa,mssql.password=,mssql.instance-name=MSSQLSERVER -sV -p 1433 192.168.1.1 siempre es bueno.
PORT STATE SERVICE VERSION
1433/tcp open ms-sql-s Microsoft SQL Server 15.00.2000.00
| ms-sql-ntlm-info:
Host script results:
| ms-sql-info:
| 192.168.1.101:1433:
| Version:
| name: Microsoft SQL Server
| number: 15.00.2000.00
| Product: Microsoft SQL Server
|_ TCP port: 1433
Transact Sql
El propio lenguaje de gestión del Sql Server te proporciona algunos procedimientos y funciones relacionadas con la seguridad, que si bien te pueden sonar a chino si no las necesitas, es bueno conocerlas y darles un repaso, lo mismo identificas implementaciones inseguras o valores no deseados. Las principales son: sys.database_permissions, sys.database_principals, sys.database_role_members, sys.database_scoped_credentials, sys.master_key_passwords, sys.user_token, sys.credentials, sys.login_token, sys.securable_classes, sys.server_permissions, sys.server_principals, sys.server_role_members, sys.sql_logins, sys.system_components_surface_area_configuration, sys.asymmetric_keys, sys.certificates, sys.column_encryption_key_values, sys.column_encryption_keys, sys.column_master_keys, sys.crypt_properties, sys.cryptographic_providers, sys.key_encryptions, sys.openkeys, sys.security_policies, sys.security_predicates, sys.symmetric_keys, sys.server_audits, sys.server_audit_specifications, sys.database_audit_specifications, PWDCOMPARE (Transact-SQL), CERTPRIVATEKEY (Transact-SQL), PWDENCRYPT (Transact-SQL), CURRENT_USER (Transact-SQL), SCHEMA_ID (Transact-SQL), DATABASE_PRINCIPAL_ID (Transact-SQL), SCHEMA_NAME (Transact-SQL), sys.fn_builtin_permissions (Transact-SQL), SESSION_USER (Transact-SQL), sys.fn_get_audit_file (Transact-SQL), SUSER_ID (Transact-SQL), sys.fn_my_permissions (Transact-SQL), SUSER_SID (Transact-SQL), HAS_PERMS_BY_NAME (Transact-SQL), SUSER_SNAME (Transact-SQL), IS_MEMBER (Transact-SQL), SYSTEM_USER (Transact-SQL), IS_ROLEMEMBER (Transact-SQL), SUSER_NAME (Transact-SQL), IS_SRVROLEMEMBER (Transact-SQL), USER_ID (Transact-SQL), ORIGINAL_LOGIN (Transact-SQL), USER_NAME (Transact-SQL), PERMISSIONS (Transact-SQL)
Azure
Como pudimos ver hace unos días, el propio Azure nos permite fortificar o supervisar la seguridad de nuestros sistemas, integrando en el Security Center nuestras instancias, tanto en la nube como On Premise.
Como puedes ver, hay muchas formas de abordar el proceso de robustecimiento de nuestros motores de base de datos SQL Server, no es un proceso cerrado, y seguro que entre todos se nos ocurren más procesos, verdad?
Espero que te guste, gracias por leerme !!!