miércoles, 24 de agosto de 2016

Crea tus reglas automáticas de Firewall mediante capturas PCAP con Wireshark.

Estimados amigos de Inseguros !!!

En el capítulo de hoy vamos a ver una funcionalidad muy interesante de la mano del producto Wireshark.

Como todos sabéis, Wireshark es un sistema para la captura y análisis de redes. Yo particularmente lo uso mucho en mi día a día, bien sea para detectar tráfico anómalo, ver posibles cuellos de botellas, malos usos de la red, respuesta a incidentes, etc.


Hablando con un cliente sobre la segmentación de la red, el cliente no se animaba a crear vlans restrictivas en los distintos departamentos. El problema era que los miembros de "diseño" accedían a MIL aplicaciones, puertos, servicios de la DMZ, y esto multiplicado por muchos departamentos. Crear las vlans con permiso de tráfico entre ellas total no es muy efectivo de cara a la seguridad. Es más lo más efectivo es que no sean Vlans sino redes distintas, pero bueno...

Cuando le presenté la idea al cliente casi me besa, bueno realmente me beso, pero queda feo que yo diga eso :-)

La idea es muy sencilla. Capturamos un poco de tráfico en horario de producción, seleccionamos una máquina tipo. Indicamos al usuario que intente acceder a todo tipo de herramientas. Que si al ERP, que si a la aplicación de la cámara, al correo, no se que, no se cuantos. Lo invitamos a un cafe y le damos una patadita xD.

Ahora es el turno de usar Wireshark. Podemos ir identificando el tráfico y crear las reglas de Firewall apropiadas para el servicio que se ha usado. Pongamos este ejemplo gráfico que seguro es más descriptivo.


Como se aprecia en la captura de imagen, he seleccionado un paquete TCP que es parte de un flujo de conexión a una web por el puerto 80.

Ahora nos situamos en la parte superior, en Tools y pulsamos sobre Firewall ACL Rules.


Tenemos la posibilidad de elegir el formato de salida de la regla que vamos a crear, pudiendo elegir entre:


Voy a usar la regla del estilo Windows que son muy claritas.

El sistema me presenta 4 reglas, dos genéricas para abrir los puertos que intervienen en la comunicación del paquete que le he marcado, y otras dos más restrictivas vinculando la dirección IP concreta.


Como estamos hablando de un cliente TIPO, vamos a usar solo las dos primeras reglas. Tenemos la opción de que la regla sea deny o allow, dependiendo de la configuración por defecto que hayamos marcado en el firewall. Si nuestra última línea del firewall será DENY ALL, configuramos ALLOW, como es lógico.

Si hacemos esto con varios clientes, en distintos tiempos, podemos hacer una conjunto de reglas en base al uso que detectamos, y si no lo teníamos, documentar los servicios a los que acceden los usuarios/departamentos.

El día D, habilitamos el Firewall para la Vlan, y esperamos que los usuarios no se quejen mucho. Siempre saldrá algún servicio de esos que se hacen una vez al mes, y ademas, será viernes, pero bueno es una aproximación para organizar el tráfico entre vlans en un entorno medio complejo, y que vive aún en el /16 de hace 15 años.

Espero que os haya servidor de ayuda, gracias por leerme.

PD: Si has leido el post, has intentado usar la Tool, y no te aparece, tranquilo !!! yo hago el blog para ayudar XD. Tienes que bajar la versión DEV. de Wireshark.

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.


Related Posts Plugin for WordPress, Blogger...