miércoles, 28 de octubre de 2020

For, For, Fortificación de Sql Server for for for fun...

 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.



Si te ves con fuerza actívala :-)

Otra buena práctica es dejar el servidor al antojo de los administradores Sql Server, por lo que yo pondría una GPO específica para ese o esos servers y habilitaría el inicio de sesión sólo a los miembros del grupo administradores de Sql Server... 

Usa el cifrado transparente TDE en las bases de datos para cifrar con un certificado los ficheros. Es útil para entornos en los que se puede realizar un ataque físico, por ejemplo, con acceso a un disco duro, a un backup etc. Por defecto en 2019 todas las bases de datos creadas se cifran, pero si vienes del pasado... sigue este procedimiento.

Otra buena idea es cifrar el contenido de una columna, por ejemplo datos sensibles, para que el administrador de la base de datos no tenga que ver el contenido de la misma.


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.


Ahora vamos a configurar la seguridad extendida en el SqlServer, y vamos a comprobar el resultado.


*NTLM: Cuando hablamos de Ntlm me refiero a net-ntlm. No es lo mismo que NTLM, pero para centrar al lector en la seguridad del Sql Server los conceptos son los mismos, y a fin de cuentas, ambos hashes se pueden crackear. Esto es una aclaración para puristas. Si quieres saber la diferencia entre Net-NTLM y NTLM pincha aquí y estudia :-) *

Otro tip para tu conocimiento. Si has hecho esta POC, prueba a pedir desde el Sql Server el DirTree con nombre de equipo en vez de dirección IP, sabes qué ocurre? Cuando hacemos barra barra a un equipo pasa lo mismo !!! si lo hacemos por nombre, la autenticación es basada en Kerberos, y no entra en juego Ntlm... tip de seguridad genérico :-)

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_passwordssys.user_tokensys.credentials, sys.login_token, sys.securable_classes, sys.server_permissionssys.server_principals, sys.server_role_members, sys.sql_logins, sys.system_components_surface_area_configuration, sys.asymmetric_keys, sys.certificatessys.column_encryption_key_values, sys.column_encryption_keys, sys.column_master_keys, sys.crypt_properties, sys.cryptographic_providerssys.key_encryptions, sys.openkeys, sys.security_policies, sys.security_predicatessys.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 !!!

No hay comentarios:

Publicar un comentario

Gracias por comentar !!