miércoles, 23 de diciembre de 2020

Firma de scripts Powershell para cumplimiento elevado

 Estimados amigos de Inseguros !!!

El tema de hoy es la risa, porque no conozco empresa que lo tenga bien, y mira que doy vueltas por compañías de todo tipo...

Ejecución de scripts en Powershell. Recuerdo cuando se introdujo su uso, o mejor dicho, popularizó, con Server 2012 ejecutabas un script y no tiraba. En internet calculo que hay un millón y medio de post diciendo cómo desactivar la política de ejecución de scripts en Windows. ( 500.000 en castellano).

Hablo del famoso set-execution policy unrestricted

No voy a entrar en todos los modos que hay, ni los ámbitos de aplicación, ni como "hackear" esto. Voy a comenzar por el principio.

Por qué no dejas la configuración de ficheros firmados, e implementas la buena práctica de usar scripts firmados, o auto-firmados... pero desactivarlo la primera vez que usas PS y dejarlo así? así no my friend !!!

Los pasos son sencillos. Debemos instalar una Entidad emisora de Certificados como un role en nuestro server favorito. Siguiendo cualquier documental en video, o en Twich ( algún día opinaré sobre esto xD) o siguiente siguiente, podrás instalar por defecto una CA, que te vendrá bien para firmar tus apps internas, tu EFS, tu IPSEC o cualquier otro servicio que requiera de certificados dentro del dominio. En este caso, solo firmar tus scripts...

Con la CA instalada, el proceso es sencillo. Configuramos en la plantilla de certificados qué usuario o grupo podrá firmar scripts PowerShell.


Con esta modificación, o dejándolo por defecto para los administradores del dominio, habilitamos la plantilla para que esté disponible.


Ahora es el turno de cargar el complemento Certificados, en el almacén personal, solicitar un nuevo certificado de firma de código a la CA.


Una vez solicitado, exportamos el certificado que usaremos para cifrar.

Creamos una GPO e indicamos que este certificado es válido, de confianza. De esta manera podremos confiar en este script firmado en todo el dominio.


Después de una actualización Gpupdate, compruebo que tengo la política habilitada de solo firmados, ejecuto cualquier script chorra ( echo "hola mundo" ) y no lo ejecutará.

Firmas el script, y lo ejecutas y lo tienes...

$cert=(dir cert:currentuser\my\ -CodeSigningCert)
Set-AuthenticodeSignature ‘.\hello.ps1' $cert


Mira el contenido del script. Crees que si lo modificas la firma funcionará o tendrás que volver a firmarlo?

Sabes cómo ver las políticas de ejecución en tu dominio? Cómo cambiarlas? Cómo detectar si alguien quiere hacer un bypass? Sabes cómo hacer un bypass?



Estamos preparando el mejor curso de ciberseguridad Microsoft en castellano y tienes la posibilidad de recibir la información y descuento cuando salga. Si te interesa, apunta tu correo en el formulario y te informaré de las novedades.

Mientras tanto, y como siempre, me tienes aquí gratis para lo que necesites !!!

Gracias por leerme !!!


jueves, 17 de diciembre de 2020

Envía mail desde Powershell sin escribir a fuego la password en el fichero...

 Estimados amigos de Inseguros !!!

Creo que el título es suficientemente descriptivo como para todos los telespectadores xD pero por si acaso...

Un caso sencillo de scripts de envío de correo podría ir vinculado a un evento determinado, o por ejemplo una tarea programada que falla... los casos son muchos.


Escribir un script en Powershell para enviar correos es sencillo, pero tener una $password="12345678" es una mala práctica, porque los malos saben que lo haces/hacemos... y buscan en todo tipo de referencias buscando este tipo de comportamientos.

El procedimiento es más bien sencillo:

Volcamos en un fichero de texto la contraseña cifrada y hacemos el envío del correo ( o cualquier uso de credenciales)recuperando la clave cifrada y haciendo la magia descifrado.

El churro sería algo así:

"CacadeVaca123" | ConvertTo-SecureString -AsPlainText -Force | ConvertFrom-SecureString | Out-File "C:\EmailPassword.txt"

$Mensaje = "mimamamemima"
$User = "notificacionempresalab@gmail.com"
$File = "C:\EmailPassword.txt"

$cred=New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $User, (Get-Content $File | ConvertTo-SecureString)

$EmailFrom = "test_empresalab@gmail.com"

$EmailTo = "kinomakino_mecome_el_pepino@hotmail.com"

$Subject ="Alerta de registro."

$Body = "Se ha modificado el registro con ID $Mensaje"

$SMTPServer = "smtp.gmail.com"

$SMTPClient = New-Object Net.Mail.SmtpClient($SmtpServer, 587)

$SMTPClient.EnableSsl = $true

$SMTPClient.Credentials = New-Object System.Net.NetworkCredential($cred.UserName, $cred.Password); 

$SMTPClient.Send($EmailFrom, $EmailTo, $Subject, $Body) 

El comando ConverTo-SecureString hace uso de DPAPI ( Data Protection API) para usando un algoritmo de cifrado ( AES 256 en versiones modernas, 3DES en antiguas) para montar un hash en base al propio hash de la clave del usuario.

Si quieres conocer en profundidad cómo funciona el proceso de cifrado a bajo nivel, este es el mejor artículo que conozco.

Si te gustan estos artículos, hemos habilitado un formulario en la web para registrar tu correo y enviarte información para posibles formaciones de Ciberseguridad. Te apuntas?

Gracias por leerme !!!


lunes, 14 de diciembre de 2020

Microsoft, una compañía de ciberseguridad…

Estimados amigos de Inseguros !!!

Microsoft con el paso de los años se ha convertido en una empresa que constantemente estaba en el foco de las críticas por su modelo de ciberseguridad a ser una de las compañías que más apuesta por esta disciplina. No solo en cuanto a robustez de sus productos y servicios, sino como a su verticalidad con soluciones enfocadas a dicho segmento.
Si hace 20 años hiciéramos esta afirmación sin duda nos encontraríamos detractores, pero bueno, si lo hiciéramos hace 30 quizás ni se entendería el concepto. El mundo de la tecnología es así.
Cuántas discusiones sobre la seguridad de los sistemas Microsoft, sobre todo en bares de poca alcurnia con amigos linuxeros.

Recuerdo épocas en mi vida que haciendo "barra barra" a una IP pública (conectando equipos Windows 98 con modem) te daba acceso a la carpeta del usuario... o como barrer internet buscando Sql Servers con el usuario SA sin contraseña. Parece que esto fué hace siglos, y en ocasiones nos los encontramos, pero tenemos que reconocer que todo esto ha cambiado muchos en los últimos años.

Una fecha importante para la historia en la ciberseguridad de la empresa de Redmond fue el 15 de junio de 2002, donde Bill Gates envió una carta al persona con una iniciativa denominada Trustworthy Computing animando a los empleados a concienciarse en la ciberseguridad, con "todo eso del .net" y el futuro auge de Internet. Esto fue solo una carta... pero fue al pistoletazo de salida.

Organizaciones internacionales como Common Criteria realizan exhaustivos test de seguridad contra productos de distinta índole para certificar el grado de cumplimiento. No pienses en Catalina para Mac, Red Hat o Microsoft Server, hay todo tipo de productos que se ponen bajo el radar. Los sistemas operativos de la familia Microsoft siempre aparecen con altas certificaciones. 

Pero como todo en esta vida, habrá quien confíe más o menos en estos organismos, pero sin duda, el trabajo de Microsoft por establecerse como una compañía ciberseguridad, y más allá, de ciberseguridad, son patentes en pequeños gestos con un gran impacto. Pongamos como ejemplo la política de actualizaciones de Microsoft. Hace unos años era habitual encontrar con equipos MUY desactualizados. Tanto por un proceso formal, como por la calidad de los parches, los administradores encontraban en este requisito de actualización un gran problema. Un gran adelanto fue la programación mensual del ciclo de actualizaciones vigente en los productos. A día de hoy, lo veo una gran funcionalidad, el tener un calendario estable, en el que los departamentos puedan estar pendientes y planificar procesos de parcheo. No conozco muchos fabricantes que lo hagan así. Por ejemplo, un rival directo en los sistemas de bases de datos que todos conocemos por su Plsql es NEFASTO en esto. No en su "ciberseguridad". Todos los productos tienen fallos, sino en la gestión de los mismos. Paquetes de seguridad con 800 parches son el terror de cualquier SYSDBA y pone en valor la sencillez con la que Microsoft resolvió este proceso.

Otro de los procesos de mejora de la ciberseguridad que acometió Microsoft fue la creación de un programa de Bug Bounty o recompensa. Es un sistema en el que se "anima" a los investigadores a que realicen pruebas de seguridad contra determinados objetivos o áreas, y en función de los hallazgos se recompensa al investigador. Es decir, como hace el mundo del cibercrimen, ¡¡¡¡pero la recompensa es legal :-) Microsoft paga por reportar fallos !!!  no está mal, hay otras empresas que denuncia a los investigadores... 

¡¡¡Pero lo que todos lectores de esta humilde publicación quieren tecnología !!! quieren siglas, productos, protocolos!!! Microsoft más lejos de su programa interno, cuenta con un centro de respuesta e investigación muy potente a nivel mundial, que lucha contra el cibercrimen para los usuarios de internet, no solo para sus clientes. 

Tenemos más "siglas" para ti, Atp, el antivirus de nueva generación de Microsoft con capacidades de EDR. Si esto lo hubieran previsto los vendors de la industria hace 15 años diría que tienen capacidades de "futurología". Microsoft haciendo antivirus, además, de los más potente del mercado. No se basa en la detección por firmas, sino que implementan un potente motor heurístico con todo tipo de servicios añadidos, no sólo la detección del malware, sino el comportamiento, aprendizaje, etc. Sin duda una revolución en la ciberseguridad Microsoft !!!

Si hablamos de la nube de Microsoft, Microsoft 365 y Azure la ciberseguridad es una pata más de los servicios, como puedan ser los Gigas de Ram o las instancias de CPU. Los servicios de ciberseguridad de Microsoft contemplan toda la fase de un incidente, Impedir, detectar, mitigar, investigar, responder... Podemos conectar nuestros SIEM´s, pero también tenemos el SIEM de Microsoft, Sentinel !!!. Algo joven pero prometedor, que está abarcando las miradas de toda la industria relacionada por su potencia. podemos usar servicios de Data Lost Prevention, gestión de identidades, podemos analizar cumplimientos normativos como PCI-DSS... 

MSRC 1

El centro de respuesta de seguridad de Microsoft se alza como uno de los organismos protector de la ciberseguridad mundial en ámbitos de nuestra vida de todo tipo. 

A finales del mes de octubre, el MSRC reportaba un fuerte ataque del grupo denominado APT35 con origen en Irán, basado en una campaña de phishing dirigida a los miembros de importantes conferencias de seguridad nacional, con el objetivo de obtener de realizar contra-inteligencia a los gobiernos. Las primeras actividades del denominado APT35 se vienen desarrollando desde 2013 y se continúa con la lucha para dar caza a dicho colectivo.

En un ámbito un poco más tecnológico, el MSRC desmanteló recientemente la famosa red de ransomware Trickbot. Esta red llevaba desde 2016 casi 1 millón de infecciones controladas. La compañía analizó más de 60.000 variantes de código de dicha pieza de malware.

Estas redes emplean mecanismos de evasión de seguridad y persistencia para hacer muy difícil el análisis y comportamiento, y así rentabilizar la inversión tecnológica del grupo criminal, haciendo que durante más tiempo la muestra sea indetectable por las soluciones de seguridad, y así poder infectar al más número posible de víctimas, o simplemente permanecer más tiempo vigente.

En el último reporte de actividad publicado por Microsoft podemos conocer de primera mano las tendencias en ciberataques detectados por el MSRC de la última parte del año y el impacto del Covid19 en el panorama del cibercrimen.

Conclusión

Adoptar las tecnologías de Microsoft siempre ha tenido la ventaja de la interoperabilidad entre sus distintos componentes, y sin duda, poder contar con el gigante de Redmond como aliado en nuestro proceso de mejora de la ciberseguridad es algo positivo. Bien empleando de manera segura sus servicios/productos, o usando los destinados a proteger la organización, contamos con una apuesta firme y continuidad de la casa y lo considero una apuesta ganadora.


Gracias por leerme

viernes, 4 de diciembre de 2020

Usar Windows Event Forwarding para aglutinar logs centralizadamente sin herramientas de terceros

 Estimados amigos de Inseguros !!!

Cuando hablamos de ciberseguridad, siempre nos gusta hablar de complejas técnicas de ataque, de exploits de nueva generación con evasión de AMSI y todo tipo de perrerias técnicas.

Desde Inseguros siempre apostamos por construir un sistema desde lo básico, con el Fix The Basics y las ideas claras, y pasito a pasito.

Al igual que digo que la seguridad empieza por el inventario, la gestión de eventos, de logs, es la siguiente pieza para una correcta visibilidad, monitorización.

Mi experiencia en el mundo Microsoft es que los logs se emplean para realizar resolución de problemas, cuando tienes algo que no va... esto en el mejor de los casos. Otros administradores buscan ayuda fuera o en Google sin ni siquiera mirar sus eventos...

Los que nos dedicamos a la ciberseguridad tenemos claro que el SIEM es una pieza importante, ese sistema que concentra los logs de todo tipo de sistemas, y que aportan un sinfín de ventajas a la hora de detectar ataques.

En los entornos menos maduros es inviable la adquisición del mismo, ya que si bien el coste al final son euros o dólares o pesos... el factor humano de la gestión es fundamental, y mucho más costoso que el licenciamiento. No os imagináis la cantidad de organizaciones que compran el SIEM fantástico de turno e incluso está apagado.

En el artículo de hoy vamos a repasar una función de los sistemas Microsoft Server 2012 en adelante que es la capacidad de enviar-adquirir eventos.

Vamos con las imágenes que se explican mejor que yo.


Una vez habilitado el colector, activamos una GPO sobre los equipos que queremos habilitar con enviadores. Para esto, lo mejor es una UO de servidores?


Server=http://Myservername(fqdn):5985/wsman/SubscriptionManager/WEC

El siguiente paso es usar el grupo restringido Lector de registro de evento y añadir el usuario Servicio de Red al grupo para darle permisos de lectura.



Si usas un sistema 2016 o 2019 como collector, deberás cambiar los permisos del webservices que escucha WINRM mediante estos comando. Puedes leer el por qué aquí

netsh http delete urlacl url=http://+:5985/wsman/

netsh http add urlacl url=http://+:5985/wsman/ sddl=D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)

netsh http delete urlacl url=https://+:5986/wsman/

netsh http add urlacl url=https://+:5986/wsman/ sddl=D:(A;;GX;;;S-1-5-80-569256582-2953403351-2909559716-1301513147-412116970)(A;;GX;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)

Por último, tienes que configurar el formato de los eventos que se envían para que lo haga en el formato del visor de eventos nativos

Wecutil.exe ss ata /cf:Events

Si eres como yo, algo nervioso, puedes forzar un evento en el "sender" para comprobar que recibes.


Si tienes seguridad en el WINRM, tendrás que cambiar la directiva de grupo que restringe las direcciones IP de origen de la comunicación, pero solo si estás en un entorno altamente securizado.


Una vez configurado el sistema, nos vamos a la rama del visor de eventos de suscripciones, como empezó todo esto, y gráficamente podemos indicar sobre qué equipos queremos recibir los eventos y qué tipo de eventos.


Es aquí donde puedes configurar un pre-indexer para ahorrar envio, y solo recibir los id de eventos que te interesan.

Sin duda, muy útil, tanto si estás en un entorno con SIEM o sin él. Si tienes uno, te ahorras estar desplegando en todos los servidores el agente de turno. Puedes centralizarlo todo en en servidor y posteriormente instalar el agente solo en el "hub" que aglutina los eventos.

Y después de unos Gpupdate /force tendrás tus logs centralizados bajo la rama que hayas configurado.


Espero que te haya servido de ayuda.

En unos días lanzaremos un curso en profundidad de seguridad en sistemas Windows, para conocer mejor las bases técnicas de los Windows y Active Directory, como atacarlos, y cómo defenderlos.

Si crees que puedes estar interesado, puedes enviar un mail a formacion@seguridadsi.com y te mantendremos informado.

Gracias por leerme !!!



martes, 24 de noviembre de 2020

Como protegernos antes el ataque de moda Kerberoasting

Estimados amigos de Inseguros !!!

En todos los aspectos de la vida sufrimos la incidencia de las modas. En la ciberseguridad no iba a ser menos.

Si bien hace 5 años la seguridad de los sistemas Microsoft no se trabajaba, ahora todo el mundo la práctica. Conocer los 4 ataques más sencillos de manual no te hace galan del título de maestro del universo. 

Otra moda actual es la de los CTF´s, en la que muchos jóvenes, no todos, emplean su tiempo en encontrar la gloria de un ranking o puesto laboral en base a pasar pruebas al estilo de las olimpiadas. Pregunta a los jugadores de CTF´s de hace 15 años si pensaban que algún día esto iba a ser de "chicos guays".

Si juntamos las dos opciones me encuentro con gente que sabe eso, lanzar el ataque, en este caso el Kerberoasting, pero que no tienen ni pajolera idea de que es lo que está ocurriendo por detrás... o lo que es más curioso, como solucionarlo !!!

Cuando te inicias en el mundo del CTF tu misión no es arreglar, es romper, pero en la vida real luchamos contra el cibercrimen, y si bien este ataque nos produce inmenso placer cuando conseguimos hacerlo y obtener buenos resultados, el objetivo es proteger a las organizaciones. Al menos es mi visión, atacar para defender y viceversa...

Una aproximación del ataque podría ser esta y una explicación un poco de más bajo nivel podría ser esta de la gente de Tarlogic con una explicación sencilla.

Disponible a partir de Windows Server 2012, podemos implementar Fast ( Flexible Authentication Secure Tunneling

La idea es sencilla, crear, o mejor dicho, requerir una autenticación previa a la hora de pedir al KDC el TGS que luego crackeamos.

Cuando se hace la petición del TGT se establece una session key con el timestamp y la contraseña del equipo, que como sabes es random y de 120 caracteres, lo que aporta la suficiente aleatoriedad a la mezcla que hace imposible el ataque criptográfico.

Como siempre, es necesario tener el dominio en nivel funcional 2012, todos los DC´s 2012 o superiores :-) y todos los clientes Windows 8 o superior.

Si tenemos otro ambiente debemos de ser muy cuidadosos con esto o perderemos integración con Kerberos en esos dispositivos.

La teclas del piano son muy sencillas, y como suele ser habitual en este tipo de settings, podemos configurar si el comportamiento es obligado o recomendado.


Primero lo definimos y luego en la rama de Kerberos, bajo KDC le decimos que lo ponga en marcha.


El resultado con un antes y un después es muy gráfico

Como siempre, espero que entiendas el propósito del post y no te quedes con los dos comandos ofensivos o defensivos, sino reflexiona y amplía tu información sobre esta temática y aporta valor, no te quedes con lo superficial.

Gracias por leerme !!


viernes, 6 de noviembre de 2020

Openvas i hate you and i love you... actualizad feeds


Estimados amigos de Inseguros!!!

Sin duda alguna Openvas es un producto interesante en la gestión de vulnerabilidades, en concreto en el análisis, pero si has trabajado con el coincidiras conmigo que se rompe más que la escopeta de una feria.

Recuerdo una frase de un gran amigo manchego diciendo eso, que es más complicado que configurar openvas xD.

Tengo colegas que a pesar de aceptar que es una pedazo de herramienta, le tienen "reticencias" por lo complejo que es el troubleshooting.

Bajo mi punto de vista, y además el uno formaba parte del otro, le ha pasado lo mismo que a OSSIM, grandes proyectos que no han sabido/querido mantener la evolución de las dos líneas de producto, comunitaria y comercial, por supuesto en detrimento la primera de la segunda. 

Bueno, a pesar de esta reflexión, me gusta Openvas y lo uso, y recientemente hay problemas para actualizar los feeds, la inteligencia...las detecciones... De poco nos sirve usar este programa si no detectamos las vulnerabilidades que aparecen mes a mes. Hay que actualizar !!!

Y desde hace poco, han cambiado el servidor de feeds y si eres como yo que andas con una versión vieja del software base, y no has actualizado los componentes, no podrás actualizar.

Podrías actualizar el sistema, pero la vas a liar, la vas a liar mucho xDDDD

Para actualizar los feeds vamos a empezar por los NVT con el comando:  

/usr/sbin/greenbone-nvt-sync

Si todo va bien no sigas, pero sospecho que no podrás.

Yo para empezar he editado este fichero /usr/sbin/greenbone-nvt-sync y he cambiado donde ponía feed.openvas.org y lo he cambiado por feed.community.greenbone.net.

Una vez descargados, lo suyo es hacer un rebuild en vez de hacer un update. Como sabes por defecto Openvas usa Sqlite ( podemos poner postgresql) .

/usr/sbin/openvasmd --rebuild --verbose –progress

Le pegamos un reinicio a la máquina y seguimos con

greenbone-certdata-sync  greenbone-scapdata-sync

Me gusta hacerlo por partes para ir delimitando problemas, y por supuesto, snapshot en mi caso a la máquina para no pasarlo luego mal…

Espero que os guste y os sirva de ayuda si usais el producto. Gracias por leerme !!! 

martes, 3 de noviembre de 2020

Tienes un antivirus... los malos tienen un anti-antivirus ... Process Herpaderping para evasión de medidas...

 Estimados amigos de Inseguros !!!

Dentro la carrera, lucha, guerra entre el bien y el mal... en el mundo ciber tenemos ataques, medidas defensivas, evasión de las medidas defensivas, detección de evasión de medidas defensivas, y así hasta encontrar la verdad sobre qué fue antes, el huevo o la gallina...

En esta ocasión vamos a probar una técnica recién publicada por el señor Johnny Shaw.  El fundamento técnico en detalle podemos conocerlo de la mano del mismo autor, pero sin duda es un gran paso en la evasión de antivirus por lo novedoso de la técnica.

En el momento de revelar la prueba de concepto se podía evadir al antivirus de Microsoft, pero en el momento de mis pruebas el proceso de evasión no era capaz de evitar la ejecución de la herramienta, sin embargo probé con otro antivirus, en este caso Avast y funcionaba perfectamente.


Los pasos son muy sencillos y están plenamente descritos en el repositorio de la POC.

Algunos ejemplos de detección los tenemos como siempre de la mano del maestro...


Qué te parece? has probado en otras plataformas?

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 !!!

martes, 27 de octubre de 2020

Fortificación sencilla de SQL en Azure..y en On Premise...

 Estimados amigos de Inseguros !!!

Nube segura, seguro? por defecto si o por defecto no? pues depende !!! la nube, en este caso Azure, nos proporciona principalmente "seguridad del hardware" y disponibilidad, bueno y la seguridad de no tener que gestionar el sistema operativo que hay por debajo... pero podemos subir un poquito más las cotas de ciberseguridad de nuestros Sql Server en la nube mediante unos pequeños procesos. Pero espera... quizás nos sirva para On premise...


Los ataques que podemos experimentar en nuestros motores de bases de datos son los típicos ataques de fuerza bruta, inyecciones de código y algunos comportamientos denominados atípicos. El sistema es capaz de detectar elementos inseguros ( XP_cmd...) y configuraciones débiles, por ejemplo, demasiados permisos en usuarios... Esto se realiza mediante el análisis de vulnerabilidades y la monitorización constante.

El conjunto de funcionalidades de seguridad de nuestras bases de datos no se queda en esta capa, existen numerosas funcionalidades como el etiquetado de datos sensibles, transporte cifrado... quizás esto sea objetivo de otro post...

Como siempre, las teclas del piano son muy sencillas y la configuración inicial es más bien un paseo... para eso nos hemos quedao :-)



Podemos apreciar como desde el inicio el análisis me aporta valor.


El sistema nos indica, en un Sql Server recien instalado, que solo tenemos un usuario, el DBO y que esto es peligroso... bieeeen.

Pero bueno, todos sabemos que las nubes están muy ricas y son muy buenas, pero seguimos teniendo elementos On-Premise, y más, los que consumen recursos altos. El proceso es muy sencillo, solo tenemos que instalar el servicio Azure Arc, descargar el script y ejecutarlo en nuestro servidor On-Premise. En unos minutos veremos nuestro Sql Server, o mejor, los resultados, en el centro de seguridad.


Aunque recuerda que puedes ejecutar el análisis de vulnerabilidades sin nada de todo esto en los nuevos SqlServe 2019.



Como ves, es muy sencillo usar estas funcionalidades para mejorar la seguridad y sobre todo monitorización de nuestros servidores Sql Server.

Espero que te sirva, gracias por leerme !!!


lunes, 26 de octubre de 2020

No disimules y simula: Simulación de ataque con Microsoft 365

 Estimados amigos del Inseguros !!!

Una de las patas más importantes en el juego de la ciberseguridad es el usuario. Nos quejamos constantemente de usuarios poco preparados, que lo aceptan todo, bien, si, pero seamos realistas, no todos deben ser unos auténticos cracks con la informática... y por qué no decirlo, todos hemos caido total o parcialmente en algún "problema", ya sea un virus, un spam o un casi phishing...

En el episodio de hoy mostraros unas pequeñas ayudas que tenemos con el servicio ATP de Microsoft. 

Nos quejamos muchas veces del coste del servicio M365 ( Office 365) pero al final si vas sumando funcionalidades, el ahorro es considerable. Compara una solución de correo+antivirus potente + software de simulación de phishing...al final para decir que algo es caro o barato hay que compararlo.

Si eres un afortunado de contar en tu plan de licenciamiento el ATP, es importante conocer el simulador de ataques

Por el momento podemos simular dos escenarios de ataques al usuario final, fuerza bruta ( horizontal y vertical) y phishing ( robo de credenciales y adjuntos).


Como casi todo lo del gigante de Seattle, el proceso es muy sencillo.


Elegimos la lista de destinatarios desde una lista de direcciones o uno o más ficheros csv.
Continuamos...


Sin muchos más clicks, tenemos el correo enviado en el buzón del destinatario con cierto aspecto raro ( se puede cambiar lo que quieras).


Si continuamos con la farsa nos aparecen el caso de phishing con unas credenciales...


El proceso acaba con una "landing" que te muestra lo ocurrido. Puedes verla en esta url: http://portal.prizesforall.com/Login/Phished

Por supuesto que podemos linkar esta landing con formación dedicada nuestra o whatever you want...

En esta ocasión podemos ver un reporte desde la consola de administración donde nos mostraría el % de usuarios que han abierto, han clickeado o han introducido las credenciales.


Ahora vamos a probar un ataque sencillo de fuerza bruta desde el portal ATP. Los clicks son muy intuitivos y descriptivos...


Este tipo de acciones suelen tener un gran impacto en la ciberseguridad, de nuestros compañeros y empleados, y si bien no es tecnológicamente apasionante ... es muy efectivo...

Sueles emplear campañas de este tipo para entrenar a tus usuarios?

Espero que te sirva, gracias por leerme !!!



viernes, 23 de octubre de 2020

Usas inicio de sesión único en Azure Active Directory... resetea la contraseña Kerberos...Mimikatz la quiere xD

 Estimados amigos de Inseguros !!!

Seguro que muchos de vosotros tenéis un Directorio Activo sincronizado con Azure para una o varias funciones. Principalmente lo usamos para conectar las cuentas del dominio local con cuentas de Office 365.

Una de las funcionalidades que tenemos disponibles es la Inicio de sesión único de conexión directa, un SSO para no tener que estar autenticando nuestros Office online en cada uso.

Esta sincronización se hace mediante un ticket kerberos que se le pasa al navegador para autenticar con el portal de Office por ejemplo. 

El funcionamiento interno del ticket Kerberos se hace mediante una cuenta de equipo denominada AZUREADSSOACC. Cuando el usuario hace login en el portal de office, el controlador de dominio On-Premise genera un ticket kerberos usando esta cuenta, que representa el "azure ad".


Cómo imaginas, esta cuenta es muy importante y es necesario resetear el ticket kerberos que se genera de vez en cuando, por lo menos una vez al mes, para evitar que si se ve comprometida la cuenta o el ticket, un atacante no siga teniendo el control del usuario.

El ataque sería muy sencillo usando Mimikatz por ejemplo:

mimikatz.exe "lsadump::dcsync /user:AZUREADSSOACC$" exit


Con esta información estamos a disposición de crear un Silver Ticket mediante este ataque e impersonar a cualquier usuario.


Bueno, pero el propósito de este post no es otro que ayudar con la defensa, como casi siempre, y es importante que de vez en cuando, una o dos veces al trimestre... al semestre... hagais un reset del ticket kerberos para evitar persistencia en el sistema. No se os ocurra cambiar la clave de la cuenta.


El proceso es muy sencillo. Os recomiendo comprobar el estado de vuestra conexión, resetear el ticket, y volver a comprobarlo.


Import-Module “C:\Program Files\Microsoft Azure Active Directory Connect\AzureADSSO.psd1”

New-AzureADSSOAuthenticationContext 

Get-AzureADSSOStatus | ConvertFrom-Json

$Clave = Get-Credential

Update-AzureADSSOForest -OnPremCredentials $Clave

Espero que os sirva un poco para conocer cómo funciona esta particularidad, y sobre todo, para os asegureis !!!

Gracias por leerme !!!