martes, 23 de agosto de 2016

Vete al Infierno !!! DNS SINKHOLE 127.0.0.1 para Windows

Estimados amigos de Inseguros !!!

Como sabéis ando un poco enredado con el mundo del Threat Intelligence y su uso defensivo en las organizaciones.


Básicamente recopilo información de sensores propios y externos, y uso esta información en mis sistemas.

Para el caso de direcciones IP que están dando "guerra" en Internet, el proceso de uso es muy sencillo, incorporas esta inteligencia en tus sistemas perimetrales, firewalls, y cortas el tráfico.

También podemos hacer uso de la inteligencia cargando reglas en nuestros IDS/IPS sean de perímetro o internos.

Podemos usar la inteligencia de los hashes para sistemas de FIM (File Integrity Monitor) o mejor dicho HIDS (Host Ids).

Cualquier IOC (Indicators of Compromise) que nos caiga en las manos podremos usarlo de manera proactiva en nuestros sistemas.


En el episodio de hoy vamos a ver que podemos hacer con recursos IOC del tipo Dominio.

Vamos a usar un maravilloso Script del SANS en concreto editado por el señor Jason Fossen para manejar un servidor DNS Windows.

Lo primero que vamos a hacer es repasar una configuración básica de seguridad de un DNS en una infraestructura Active Directory típica.

Lo normal es tener uno o varios servidores DNS integrados en Active Directory para nuestra red local. Los nombres de los equipos, servidores, webs,etc. Como es normal, nuestro servidor DNS no conoce TODA la infraestructura de Internet, por ejemplo, www.elcorteingles.com por lo que por defecto el servidor se configura para realizar búsquedas autoritativas contra otro servidor DNS. Si no hemos cambiado nada, iremos a los reenviadores por defecto, los servidores ROOT de Internet. Si hemos prestado un poco de cuidado con esto, tendremos puestos nuestros favoritos, los del ISP, Google, o quien sabe !!!

La práctica del SinkHole (traducido es SUMIDERO) es simplemente cargar un fichero en una zona del DNS con registros DNS maliciosos, y hacer que apunten a una dirección IP inválida, por ejemplo 0.0.0.0 o 127.0.0.1 o un servidor con una advertencia.



Mis seguidores de Twitter de vez en cuando leen que publico una lista de dominios maliciosos en formato SNORT para implementar en los IDS.

Voy a crear una lista de dominios maliciosos que están dando la guerra en Internet en las últimas 24 horas, recopilados de mi sistema de Threat Intelligence.

Con este fichero, vamos a cargar los registros en un servidor DNS y de esta manera protegeremos a nuestros usuarios del acceso o mejor dicho la comunicación contra esos dominios.

Para tener una política segura de DNS deberíamos filtrar todo el tráfico DNS saliente de todos los equipos salvo los servidores DNS autorizados. De esta manera evitamos que una pieza de malware implemente su propio servidor DNS o una simple consulta hardcoreada contra un servidor dns concreto externo.

También sería interesante crear el servidor DNS que hará de SinkHole en una DMZ, sin transferencia de zona ni nada, y configurar los servidores DNS internos de Active Directory para que reenvíen al servidor SinkHole. Este resolvería "negativamente" las peticiones maliciosas, y reenviaría a su vez las peticiones DNS normales de navegación a los servidores públicos empleados. Es decir, estaríamos metiendo un salto más en nuestras consultas DNS.
Si no quieres realizar esta tarea, no pasa nada, pero recuerda que tus clientes suelen apuntar a dos servidores DNS internos, y que esta zona SinkHole no se va a replicar entre servidores, por lo que en escenarios en los que el DNS primario no está operativo y los clientes acceden al servidor secundario el sistema no ejecutaría el SinkHole, a no ser que realices el proceso de carga en los dos... Todo esto sin ideas o pistas que lanzo para que comprendas en profundidad como funciona el asunto.

Ahora vamos a las teclas. Hemos descargado el script desde la web del Sans. Ejecutamos una sentencia de prueba:

.\Sinkhole-DNS.ps1 -Domain "cacadevaca.com" -SinkHoleIP "127.0.0.1"

Ahora vamos a realizar lo mismo, pero ejecutamos un fichero concreto:


El resultado es el siguiente:


Como puedes acceder si vas a las propiedades del registro, el TTL del mismo es de 1 hora.

El proceso de creación y actualización del SinkHole debe ser constante, ya que la longevidad o duración de los dominios comprometidos suele ser baja, y mediante el TTL bajo obligamos a los clientes a no usar la posible Cache local del recurso.

Imagina un servidor importante público comprometido, y que durante 3 horas se ha dedicado a distribuir malware. Imagina que se ha detectado y se ha incorporado a una blacklist. Si el incidente ha durado 3 horas, no tiene sentido bloquear el acceso al recurso durante 24 horas, ya que estaríamos interfiriendo en el servicio.

Si por cualquier cosa quieres volver atrás a como tenías tu servidor DNS tranquilo, puedes ejecutar:
.\Sinkhole-DNS.ps1 -DeleteSinkHoleDomains y como todos los registros están en el mismo fichero de zona, se borrarán sin problemas ni interferencias con tus dominios ya configurados.

Podemos realizar un script que vaya a mi repositorio de dominios maliciosos, descargue el fichero, ejecute la actualización del SinkHole y actualice el servidor:

Invoke-WebRequest -Uri https://github.com/kinomakino/snort_rules/blob/master/agosto.csv -OutFile maleantes.txt  

.\Sinkhole-DNS.ps1 -DeleteSinkHoleDomains

.\Sinkhole-DNS.ps1 -InputFile .\maleantes.txt -IncludeWildCard -SinkHoleIP "10.1.1.1"

Si queremos darle más juego al SinkHole, podemos hacer que los dominios apunten a una ip válida en la red, un servidor linuxero que tengamos por ahí. Podemos presentar una web informando al usuario que se ha detectado un tráfico anómalo y se ha procedido a bloquear su conexión a red. Podemos enganchar un Fail2ban que acceda a log de ese server, y ejecutar un BAN en remoto en los sistemas firewalls internos para esa IP y un correo al sysadmin.


Como has podido comprobar, la potencia de usar un SinkHole es inmensa, y es muy sencillo de implementar en entorno Windows y más fácil aún en entornos BIND.

Solo tienes que decidir tu lista de fuentes de reputación favorita y empezar con el proceso.

Si tienes alguna duda, ya sabes !!!

Espero que te haya gustado, gracias por leerme !!!

PD: El fichero agosto.csv publicado está actualizado a fecha hoy.



lunes, 22 de agosto de 2016

Creación de nombres automática para fakes account.

Estimados amigos de Inseguros !!!

El otro día leyendo este artículo del señor Dark Operator se me ocurrieron varias ideas y sobre todo me gustó mucho el artículo. Para darle el sentido en castellano y mi visión os voy a recrear el concepto con mis ejemplos propios.


El concepto es sencillo. Imagina un entorno de post-explotación de un sistema en el que quieres introducir un usuario con persistencia en el sistema. La típica intrusión en un dominio Windows o un Wordpress, y la creación de uno o varios usuarios para poder acceder a posteriori, o para demostrar la intrusión.

En pequeños sistemas la creación de un usuario puede ser detectada ya que seguramente el administrador de un vistazo detecte el usuario "intruso" en cuestión.

En sistemas grandes con miles de usuarios, el proceso manual es casi imposible.

Podemos usar la página Fake Name Generator  para mediante un setting básico de campos, crear un listado de 100,1000, 10000 usuarios que podamos usar para importar en nuestro sistema comprometido.

El sistema nos ofrece la posibilidad de usar un csv,txt, etc o directamente generar las instrucciones en formato SQL.


El resultado podría ser algo parecido a esto:


Ahora podríamos emplear este csv en la importación por ejemplo en un sistema Windows. El artículo original muestras unas powershell que no creo necesarias. Con esta simple sentencia y respetando el formato del CSV podemos realizar la importación:

Import-Module ActiveDirectory
$Users = Import-Csv -Delimiter ";" -Path ".\userslist.csv"
foreach ($User in $Users)
{
    $OU = "OU=Employees,DC=lab-os,DC=com"
    $Password = $User.password
    $Detailedname = $User.firstname + " " + $User.name
    $UserFirstname = $User.Firstname
    $FirstLetterFirstname = $UserFirstname.substring(0,1)
    $SAM =  $FirstLetterFirstname + $User.name
    New-ADUser -Name $Detailedname -SamAccountName $SAM -UserPrincipalName $SAM -DisplayName $Detailedname -GivenName $user.firstname -Surname $user.name -AccountPassword (ConvertTo-SecureString $Password -AsPlainText -Force) -Enabled $true -Path $OU
Podemos ver los usuarios creados en el directorio activo:


Como medida de seguridad, si sospechamos que hemos tenido una intrusión de este tipo podemos usar PowerShell para comprobar la fecha de creación del usuario para detectar este tipo de historias.

Podrías ser así:

Get-ADUser -filter * -properties passwordlastset | sort-object passwordlastset | select-object Name, passwordlastset | Export-csv -path c:\kinotest\listos.csv

Aunque realmente miramos por la fecha de la última contraseña, pero nos sirve.

Espero que os haya gustado el recurso.

Gracias por leerme !!!


lunes, 1 de agosto de 2016

Inteligencia colectiva Ofensiva y defensiva. El video de la charla en PaellaCon

Estimados amigos de Inseguros !!!

Si os interesa el mundo del Threat Intelligence, los IOC´s, los frameworks y herramientas relacionados, y sobre todo, echar un buen ratico, os animo a ver el video de la charla que di al respecto en PaellaCon.

Espero que os guste !!!


miércoles, 20 de julio de 2016

Threat Intelligence. Yara Rules webshell hashes export OTX and other

Estimados amigos de Inseguros !!!

Hoy por ser miércoles el día que es voy a escribir un pequeño artículo para apuntar una chuleta y agradecer el trabajo de la gente de Yara RUles.


En el github oficial del proyecto han publicado un fichero yara con la identificación de las webshells más conocidas y usadas por los ciber-malosos, auditores y demás perlas del panorama :-)

El archivo es lo podéis descargar aquí.

Para los que no sepáis que es Yara Rules, mejor leer este artículo de Root Against The Machine o mal informaros con mi descripción: Un motor de detección de malware, o ficheros... basados en expresiones regulares. Es decir lo que podría ser un "motor de antivirus" en el que nosotros creamos las firmas, por ejemplo, detectar ficheros ejecutables que contengan el string "banco". El ejemplo de la documentación:

rule ExampleRule
{
    strings:
        $my_text_string = "text here"
        $my_hex_string = { E2 34 A1 C8 23 FB }

    condition:
        $my_text_string or $my_hex_string
}

El ejemplo de una webshell del fichero que han publicado sería este:

rule lamashell_php {
meta:
description = "Semi-Auto-generated - file lamashell.php.txt"
author = "Neo23x0 Yara BRG + customization by Stefan -dfate- Molls"
hash = "de9abc2e38420cad729648e93dfc6687"
strings:
$s0 = "lama's'hell" fullword
$s1 = "if($_POST['king'] == \"\") {"
$s2 = "if (move_uploaded_file($_FILES['fila']['tmp_name'], $curdir.\"/\".$_FILES['f"
condition:
1 of them
}

Si pasas un proceso en un servidor que ejecute Yara con esta regla, nos mostraría el fichero en el caso de que tuviéramos esa shell instalada en el servidor. Imagino que se usará mas en Respuesta a Incidentes para detectar servidores comprometidos que para la parte defensiva que es la que me interesa a mi.
Recorrer el servidor, un webserver grande buscando este fichero cada 5 minutos puede consumirnos el sistema entero, y yo ya cuento con otro sistema de FIM (FIle Integrity Monitor) que me monitoriza "cosas". Pero me gustaría meter una regla en un sistema defensivo que me detecte la subida de estos ficheros, pongamos por ejemplo un mod_security.
Lo que pretendo es extraer simplemente el hash de la shell y volcarlo en un fichero para poder cargarlo en mis firmas. También lo voy a subir a la base de datos OTX de AlienVault por si le sirve a alguien, y por supuesto, lo voy a incorporar a mi sistema de Threat Intelligence que tenemos en Eset España.
Muy sencillo el comando, le pasamos el fichero de yara rules y le pasamos una salida, sencillo:
grep -n "hash = " /sitio/yara_shells.txt | awk -F  "=" '{print $2}' | tr -d '"' > /sitio/hashes.txt
Como he dicho, es solo un pequeño truco que quiero documentar y agradecer el trabajo desinteresado de la comunidad que escribe yara rules públicas y la gente de OTX.
Gracias por leerme.


martes, 12 de julio de 2016

OSSIM 27. Mamá, he roto OSSIM... Backups

Estimados amigos de Inseguros !!!

Vamos a escribir el vigésimo séptimo artículo de la serie dedicada a OSSIM (todos los artículos).


En esta ocasión vamos a trabajar un poco con las opciones de configuración y backups.

El producto OSSIM en la versión de software libre, no se en la de pago, suele ser algo "inestable" por no decir otra cosa con algunas situaciones. Bien sea porque nos quedamos sin disco, o por un corte de corriente, mala actualización, y demás situaciones no-friendly para el sysdamin, la base de datos se suele corromper, o se puede corromper, tampoco voy a criticar este producto GRATUITO.

Lo que si sabéis todos los que lo estáis usando, es que antes de hacer algún cambio importante o update, mejor hacer un snapshot o copia de seguridad potente.

El sistema hasta la versión 5.2.4 realizaba una copia de seguridad automática de la configuración del sistema, desde las políticas, assets, configuración de openvas, usuarios, TODO. La ubicación de las copias de seguridad se solía hacer en /var/alienvault/backup/ 

Si actualizaste a la versión 5.2.5, sin leer, como suele ser el caso :-) habrás notado que ya no se están realizando backups automáticos y el sistema nos invita amablemente a introducir una clave de seguridad para los backups, un punto más de seguridad en nuestros despliegues.

El procedimiento es tan sencillo como este.

Si alguna vez se nos va la base de datos, tenemos que tener en cuenta una cuestión. Si actualizamos el servidor OSSIM no podemos restaurar la configuración de una versión previa.

El otro día me paso eso, que me petó la BBDD, pensé que actualizando se arreglaría, y me vi en la situación de no poder restaurar la configuración por ser de una versión anterior. Todo el OSSIM de años perdido...

Me puse a pensar como loco, porque ya no fumo :-) y pensé: si en en /etc/ossim/ossim_setup.conf tengo la clave de la BBDD mysql de OSSIM y tengo los ficheros .sql, por qué no los lanzó a ver si la actualización no ha tocado mucha definición de tablas, y salgo del paso? Correcto, ejecute el dump de mysql de todos los ficheros .sql y volví a respirar.

Si vas a hacerlo uno a uno (son muchos) me parece bien, yo pensé en hacer un cat *.sql   | mysql -u adasd..... y funcionó.

Aprovecha también para introducir estos ficheros en tu sistema de backups de disco general. Si exportas la configuración a otro servidor salvarás los "muebles" en caso de que se rompa el disco y no puedas acceder localmente a la copia de seguridad...

Espero que sea estable la solución, aunque imagino que en la próxima actualización me tocará lidiar con las tablas del mysql... De momento tengo SIEM. Realmente tengo copias de seguridad de la máquina, pero quería probar estas pequeñas historias para cuando todo falla.

Espero que os sirva de ayuda, tanto lo de los backups, como la ubicación del fichero de configuración de mysql, como simplemente echar un rato simpático leyendo Inseguros :-)

Un saludo !! gracias por leerme !!!


Related Posts Plugin for WordPress, Blogger...