martes, 31 de marzo de 2015

TRUCO RAPIDO. Mod negotiation habilitado, fuzzer de ficheros-directorios ejecutado. W3af. NSE script. Metasploit.

Estimados amigos de Inseguros.

En el mini post de hoy vamos a hablar de un pequeño truco interesante que te puede servir si estás auditando tu web, o la del vecino.

En Apache existe un módulo denominado mod_negotiation con la opción de Multiviews que se supone ayuda en la experiencia de navegación. Como? Muy sencillo. Si un usuario accede a http://dominio/fichero.tx y no introduce la última t (txt). Tanto para directorios como para ficheros, el servidor Apache le muestra una sugerencia. Bieeeeen !!! como podemos usarlo, pues por ejemplo, imagina un fichero licencias.lic, o usuarios.doc, o claves.psw o cualquier nombre de fichero jugoso. Con esta función, podemos pedir solo el nombre del fichero, y si existe, Apache nos propone la extensión. Esto reduce mucho el proceso de fuzzing para averiguar los directorios y ficheros sensibles. Conoces este recurso para hacer fuzzing de directorios en online (OSINT) ?

Un ejemplo:


Puedes averiguar si un servidor Apache emplea este módulo con la opción Multiview habilitada manualmente, o puedes usar:


2.- W3AF en modo consola o GUI.
w3af>>> plugins
w3af/plugins>>> discovery content_negotiation, webSpider
w3af/plugins>>> back
w3af>>> target
w3af/config:target>>> set target
http://dominio/
w3af/config:target>>> back
w3af>>> start


Para hacer una prueba con Metasploit, introduzco en el fichero de palabras dos ficheros que se de ante-mano que existen, para que no tarde mucho el proceso de todo el fichero.

/opt/metasploit/apps/pro/msf3/data/wmap/wmap_files.txt


Como verás, es muy sencillo utilizar este "leak" de información, muy viejo, pero muy presente aún en muchas configuraciones de Apache.

Gracias por leerme, espero que os guste !!!




CSI Seguridad. Investiga tus sistemas sin lanzar un solo comando. OSINT style.

Estimados amigos de Inseguros.

En la aventura de hoy os invito a leer mi último artículo en el blog de Eset España sobre OSINT.


En el artículo vamos a realizar algunas labores de investigación previas en la fase de Intelligence Gathering o recopilación de pruebas, de manera anónima, sin "atacar" directamente a la víctima, sino empleando la información pública en la redes.

Espero que os guste. El link: http://blogs.protegerse.com/laboratorio/2015/03/30/csi-seguridad-investiga-tus-sistemas-sin-lanzar-un-solo-comando-osint-style/

sábado, 28 de marzo de 2015

PassiveDns. Extraer registros DNS desde pcap hacia log/syslog/mysql... y si quieres, integración con OSSIM

Estimados amigos de Inseguros.

En el capítulo de hoy vamos a seguir dando una vuelta sobre el mundo de la recolección de inteligencia para nuestra defensa. Este proceso se puede emplear con el tráfico generado por el honeypot que instalamos en este capítulo.

El propósito de usar PassiveDns del señor Edward Bjarte, es analizar el contenido de un fichero pcap para extraer los registros dns. Se puede pasar como parámetro un fichero, o simplemente ejecutar la herramienta. Por defecto se pone el adaptador eth0 en modo promiscuo y comienza a analizar el tráfico de registros DNS.

Otra de las gestiones que podemos realizar con PassiveDns es integrarlo con OSSIM mediante el plugin que nos traen, en fase beta, disponible desde aquí. Si observas la definición de la regular expressión que hace el parser del log, lo mismo puedes reusarlo para tus propios propósitos :-)

El proceso de instalación comienza solventando las dependencias. Un poquito de Git y compilando.

$ sudo apt-get install git-core binutils-dev libldns1 libldns-dev libpcap-devlibdate-simple-perl
$ git clone git://github.com/gamelinux/passivedns.git
$ cd passivedns/
$ autoreconf --install
$ ./configure
$ make

Ahora podemos realizar algunas operaciones, vamos a empezar con lo más básico, esnifar alguna petición dns y ver el formato.


Vemos que pone el adaptador en modo sniffing y comienza a procesar los paquetes dns.

La idea original es utilizarlo para listar el contenido de los pcap que vamos a analizar del honeypot o cualquier otro sistema. La "salida" o el listado lo puedes emplear como te plazca. Podemos insertarlo en una base de datos mysql con un sencillo procedimiento, podemos exportarlo al fichero de log, tirarlo al syslog, configurar el delimitador de campos...

En mi caso he tenido que instalar el módulo Datetime para Perl desde Cpan, y no como indica el procedimiento oficial.

perl -MCPAN -e shell
install DateTime

El comando para ejecutar el volcado en mysql es:

sudo perl pdns2db.pl --file /var/log/passivedns.log

Una de las cosas que me gusta de almacenar la lista en Mysql es que en la tabla de resultados me almacena registros únicos con un hitcount, así me ahorro el proceso de depurar los registros duplicados. En un registro pcap de muchos Mb/Gb en un sistema en producción, es MUY útil.


Hay que tener una cosa en cuenta en la utilización del script. Cada vez que se ejecute, volcará los registros que encuentre en el log, por lo que un cat /dev/null > /var/log/passivedns.log al finalizar el script no estaría mal...

Las opciones son muy interesantes, por ejemplo, poder gestionar una whitelist mediante un fichero, para disminuir los registros a investigar...

 --file <file>          : set the file to monitor for passivedns entries (/var/log/passivedns.log)
 --batch                : process a file and exit when done
 --skiplist <file>      : file with a list of domains to skip DB insertion
 --onlylist <file>      : file with a list of domains to only insert into DB
 --whitelist <file>     : file with a list of domains to not check for in blacklist
 --blacklist <file>     : file with a list of domains to alert on
 --skiplist-pcre <file> : file with regexp list of domains to skip DB insertion
 --onlylist-pcre <file> : file with regexp list of domains to only insert into DB
 --whitelist-pcre <file>: file with regexp list of domains to not check for in blacklist
 --blacklist-pcre <file>: file with regexp list of domains to alert on
 --alertlog <file>      : file to log alerts to (/var/log/passivedns-alert.log)
 --nodb                 : dont talk to the DB at all
 --daemon               : enables daemon mode
 --verbose              : enables some verboseness
 --debug <int>          : enable debug messages (default: 0 (disabled))
 --help                 : this help message
 --version              : show pdns2db.pl version

El uso que le des es cosa tuya, pero con esta sencilla herramienta podemos obtener rápidamente el listado de registros dns consultados sobre un pcap, algo muy útil para forense o para el ámbito del proyecto de inteligencia que llevamos en marcha.

Como siempre, gracias por leerme, espero que os guste.

jueves, 26 de marzo de 2015

OSSIM 23. Conectar un OSSIM sensor externo a nuestro servidor por VPN

Estimados amigos de Inseguros.

Después de iniciarnos en el mundo del SIEM con OSSIM (1234567 , 89 101112 1314.,15, 16 ,17 18, 19,20,21 22 )

Vamos a configurar una sencilla operación. Instalar un sensor OSSIM en un VPS externo a nuestra red, y conectarlo con nuestro actual despliegue de OSSIM de manera segura por VPN.

De esta manera podemos usar los plugins de los sistemas que tengamos en esa ubicación, y enviar los eventos al servidor central.

Tenemos que descargar una imagen ISO, que nos sirve tanto para instalar el servidor como el sensor. Si tu VPS no trabaja con virtualización, tu me contarás como vas a instalar la ISO :-). Una vez solventado este concepto, procedemos con las pantallas de instalación.


Una vez configurados los datos de red, hemos terminado !!

Ahora viene el proceso. El resumen es que en el servidor Ossim tenemos que acceder por ssh puerto 22 al sensor. En mi caso estaba en un vps, detrás de un firewall, por lo que he tenido que natear en el sensor el puerto 22. El servidor se conecta al sensor, configura el cliente vpn copiando la configuración en /etc/openvpn/ip.conf. El problema es que cuando Ossim copia los datos al cliente, en ese fichero .conf indica la dirección ip de OSSIM server, la interna, por lo que el cliente vpn del sensor intenta conectar a una ip privada... Yo he tenido que cambiar el fichero citado y poner la dirección ip publica de mi server OSSIM, y hacer un nat en el firewall hacia el puerto TCP 33800.

Vamos a ello !!!
En el servidor principal Ossim, en la consola de administración ejecutamos:

Esta es la red virtual del servidor vpn. el equpo será .1
Ahora seguimos desde el servidor OSSIM y configuramos el VPN client.

Esta ip es la local del sensor OSSIM
Ahora nos conectamos con el sensor Ossim que acabamos de instalar, y seleccionamos:


Esta IP es la del extremo virtual de la vpn del servidor OSSIM. Coincide con la red vpn que hemos configurado unos pasos atrás. Hacemos lo mismo con framework IP. Ahora aplicamos los cambios.


Por último, desde el gui de Ossim añadimos un sensor nuevo, bajo la rama despliegue, e indicamos los datos de ip, que será la interface de túnel del equipo sensor.


El resumen es:

SEDE PRINCIPAL:
ip publica--->fw/nat 33800-->ossim server.
SEDE REMOTA:
ip publica-->fw/nat 22 ->> ossim sensor.

EN OSSIM SERVER: configurar la opcion vpn server y cliente. ( por defecto 10.67.68)
EN OSSIM SENSOR: configurar las direcciones de server y framework con la ip del tunel. (por defecto 10.67.68.1)
Editar el fichero /etc/openvpn/ip.conf con la dirección ip pública del servidor OSSIM.
/etc/init.d/openvpn restart.
EN OSSIM SERVER GUI: añadir el sensor con la ip del túnel, del extremo del sensor. ( por defecto 10.67.68.12)

Como siempre espero que os sirva de ayuda, y gracias por leerme !!!

Recuerda que puedes buscar entre mis libros de hacking en español en en recopilatorio de libros sobre hacking 




miércoles, 25 de marzo de 2015

Haz tu plan de seguridad casero a coste cero.

Estimados amigos de Inseguros.

Los amigos de Eset España me han permitido escribir un post sobre como empezar a realizar un plan de seguridad en nuestra empresa a coste cero. Será una serie de artículos destinados a los que se inician en el mundo de la seguridad. Espero que os guste !!!



http://blogs.protegerse.com/laboratorio/2015/03/25/guia-para-realizar-un-plan-de-seguridad-basico-a-precio-cero/


viernes, 20 de marzo de 2015

OpenDLP. Data Loss Prevention open source. Monitoriza las fugas de información.

Estimados amigos de Inseguros.

En el capítulo de hoy vamos a hablar de un concepto habitual en el mundo de la seguridad DLP Data Loss Prevention o prevención de fugas de información.

Si la información es el activo que queremos proteger en nuestras organizaciones, detectar fugas de información por procesos "normales" o "habituales" debería ser lo más básico.

Si nos protegemos de una Sql Inyection que nos pueda dumpear una base de datos.
Si nos protegemos de un XSS que nos puede dumpear la cookie de administrador de nuestro portal.
Si nos protegemos de RFI que nos puedan comprometer la consola de un servidor web.

Nos deberíamos proteger de estas mismas fugas de información por parte de los empleados? Por supuesto que si. Imagina los frentes. Dropbox, correo, pendrives, artículos en páginas fake, etc etc.


Por lo general ser suelen emplear herramientas comerciales. Por ejemplo, tengo bastante experiencia en DLP en sistemas Fortinet en los que mediante expresiones regulares inspeccionamos todo el tráfico de salida en busca de patrones de fuga de información. PERO imagina una alerta por cada XLS, DOC o similar que sale por nuestro smtp...



En este episodio vamos a hablar del proyecto OPENDLP creado por el señor Andrew Garvin.


La instalación podemos realizarla desde las fuentes o usar un fichero OVA para virtualbox. Yo me decido por usar este, y en otro momento lo pasaré a un VMWare o Hyper-v de producción. Para hacer las pruebas me vale.

La lista de dispositivos que escanea el agente OpenDLP son: floppy, thumb drive, flash card reader, HDD, flash drive, CD-ROM and RAM disk.

Una de las gestiones que tenemos que hacer al importar la máquina es deshabilitar el usb 2.0 y activar la tarjeta de red.

Una vez instalada la máquina lo primero que debemos hacer es borrar el fichero /etc/udev/rules.d/70-persistent-net.rules para que Ubuntu no compruebe la mac de la máquina clonada, que como ha cambiado, no detecta la interface por defecto. Seguro que el user/pass opendlp/opendlp ya se te había ocurrido cierto? :-)

Ahora accedemos por scp a la carpeta /var/www/OpenDLP/bin/ y copiamos en ella el fichero sc.exe de cualquier Windows XP que tengamos por casa.

El siguiente paso es importar el fichero de certificado que se extrae en la carpeta de instalación de la máquina virtual en Firefox, en mi caso. Simple.


Podemos acceder desde el navegador de tal manera: https://ip/OpenDLP/index.html
user:dlpuser.pass:OpenDLP

Este es el aspecto inicial.


Vamos a trastear un poco con las opciones del gui. Vamos a crear un perfil para nuestros equipos Windows en este caso. Hay que tener en cuenta la antigüedad del proyecto. En el profile cambia la ruta de instalación del agente, para que no use "program files" sino una directorio concreto. De esta manera nos ahorramos el problema de las versiones x86/64


Tras el nombre e indicar el tipo Windows based agent debemos configurar las expresiones regulares que queremos monitorizar. Vamos a activar las que trae por defecto, al menos, para detectar una fuga de información de una tarjeta VISA o MASTERCARD.

Mastercard:(\\D|^)5[1-5][0-9]{2}(\\ |\\-|)[0-9]{4}(\\ |\\-|)[0-9]{4}(\\ |\\-|)[0-9]{4}(\\D|$)
Visa:(\\D|^)4[0-9]{3}(\\ |\\-|)[0-9]{4}(\\ |\\-|)[0-9]{4}(\\ |\\-|)[0-9]{4}(\\D|$)

El usuario que debemos proporcionar al agente para subir los resultados al servidor es: ddt/OpenDLPagent

Ahora realizamos un scan para instalar el agente en las ip´s que le indiquemos.


Podemos usar la recolección de datos mediante tráfico SMB sin instalar agente. Es más si intentas instalar el agente en sistemas > xp tendrás problemas con el ntlmv2 ya que winexe no lo soporta, y los sistemas operativos "modernos" suelen tener por GPO que no hagan RESPONSE a ntlm <2.


Como es normal, una regular expression tan genérica como la de las tarjetas de crédito arroja muchos falsos positivos.

En otro capítulo seguiremos trabajando con OpenDLP contra sistemas linux y con otras expresiones regulares que nos proporcionen más información.

Espero que os guste, gracias por leerme !!!

Recuerda que puedes buscar entre mis libros de hacking en español en en recopilatorio de libros sobre hacking 



lunes, 16 de marzo de 2015

Honeypots XIII nuevo cada noche + sistema de control aislado de la red para analizar la información. HoneyDrive+Vmware+Powercli

Estimados amigos de inseguros.

Después de tantos artículos sobre el asunto de Honeypots, creo que podemos darle forma con un proyecto concreto basado en un despliegue sobre VMware, muy asequible como vps en cualquier operador, y un conjunto de máquinas y configuraciones dedicadas específicamente a mantener un Honeypot.

Uno de los retos con el Honeypot es mantener su integridad. Si creamos una estrategia para generar automaticamente una máquina virtual con el honeypot cada noche, nos aseguramos que en caso de compromiso, al menos, el atacante deberá realizar las mismas acciones cada día de explotación para tener acceso. No vamos a tener un Honeypot comprometido realizando el mal a sus anchas, y nosotros recolectando logs... Legalmente creo que seríamos los responsables de las acciones del criminal.


La idea general es tener en un host VMware, una máquina virtual firewall gratuita como pueda ser pfsense, o un cfs sobre iptables, un mikrotik virtual o similar. Esto nos permite dar visibilidad hacia la parte "interna" de nuestro sistema, las máquinas virtuales con los Honeypots y sobre todo, un sistema aislado y seguro para conectarnos hacia nuestro "Command & Control" y no tener que abrir una puerta conectando nuestros sistemas hacia un Honeypot, un sistema que a priori se despliega para que te "ciber-zurran" :-).

Basando nuestro Honeypot en la distro. Honeydrive versión actual .
El proceso de instalación sobre ESXi lo puedes leer aquí.

Aparte de cambiar el teclado a tu gusto, debes realizar el cambio de clave honeydrive por una que NO TENGA NADA QUE VER CON SISTEMAS que tengamos en producción. No uses ni la misma combinación, totalmente distinta. sudo passwd es más que suficiente.

Aparte de la máquina virtual instalada como Honeydrive, vamos a crear un disco duro secundario con VMware de 20 gb, que usaremos para montar/desmontar la información de los sistemas en el Honeypot y luego pasárselo a una máquina de confianza para recolectar la información.

Importante este punto. Para crear el disco duro que pueda ser accesible por distintas máquinas tenemos que hacer una configuración un tanto distinta de como estamos acostumbrados.

Para empezar, debemos acceder al ESXi por ssh y desde el directorio del volumen donde reside nuestra máquina, crear un disco eagerzerothick con este comando:

vmkfstools -d eagerzeroedthick -c 20G -a lsilogic intercambio.vmdk
desde la ruta: /vmfs/volumes/

Una vez creado el disco, lo agregamos a la máquina virtual como siempre.

Ahora cambiamos la configuración del adaptador SCSI para que sea Virtual, y así poder acceder desde varias máquinas virtuales en el mismo host.



Podemos montar el disco, según si has particionado ya algo, con los pasos en este enlace. Recuerda que crear la partición solo lo realizarás la primera vez, en las operaciones diarias solo realizaremos la parte de montaje/desmontaje entre las distintas máquinas virtuales.

No olvides modificar tu /etc/fstab en ambas máquinas para que se monte el disco al inicio.

Un dato importante, no podrás tener las dos máquinas instaladas corriendo debido al disco, la VM activa bloquea el disco.

Esto implicaría coordinar con el proceso de restauración del Honeypot mediante Powercli, el encendido de la máquina control y posterior envio de información. Esta tarea la realizaremos con el script modificado al final del artículo en Powershell, asociado a una tarea programada.

Ya tenemos el Honeypot y un disco duro para logs, vamos a montar algún servicio honey y a cambiar la configuración para que escriba en el disco.

Antes de nada, me gusta iniciar tcpdump al arrancar la máquina virtual, filtrando solo los puertos que ofrecemos como Honeypot. De esta manera, podemos tener un pcap diario de la actividad contra al servicio Honey. Si enfocamos la captura a solo unos puertos puede que perdamos el sentido del Honeypot si lo que queremos es encontrar patrones de actividad basados en el acceso a distintos puertos, por ejemplo, si estamos detectando un bot que explota algún port knocking por defecto. Para el caso de obtener estadísticas, ip reputation, y algunos comando o la descarga de malware, me basta con hacer el tcpdump normal.

Podría valer este: =tcpdump -i eth0  -n dst port 22 or 24 -w /media/disk1/pcap.pcap

Empezamos con el famoso Kippo, que ya vimos alguna configuración por aquí.

Lo que voy a hacer es copiar todos los logs que genera, incluido la bbdd Kippo para verlo luego en Kippo-Graph, con un cron programado 10 minutos antes de apagar la máquina.

Qué cosas voy a copiar en ese disco duro? que datos voy a necesitar para visualizar en mis sistemas?
Para el ejemplo de Kippo y Kippo-graph podemos copiar:

#! /bin/bash
clave=cacadevaca
vacio=`ls -l /honeydrive/kippo/dl | grep -v total | wc -l`
now=$(date +"%m_%d_%y")
if [ ! -d /media/disk1/log-kippo/$now ]
then
mkdir /media/disk1/log-kippo/$now
fi
cp /honeydrive/kippo/log/kippo.log* /media/disk1/log-kippo/$now
if [ $vacio != 0 ]
then
cp /honeydrive/kippo/dl/* /media/disk1/log-kippo/$now
fi
if [ -f /media/disk1/pcap.pcap ]
then
cp /media/disk1/pcap.pcap /media/disk1/log-kippo/$now/pcap.pcap
fi
rm -f /media/disk1/pcap.pcap
rm -f /honeydrive/kippo/dl/*
cat /dev/null > /honeydrive/kippo/log/kippo.log
mysql -u root --password=$clave kippo -e "select * from auth" -B > /media/disk1/log-kippo/$now/auth.csv
mysql -u root --password=$clave kippo -e "select * from clients" -B > /media/disk1/log-kippo/$now/clients.csv
mysql -u root --password=$clave kippo -e "select * from downloads" -B > /media/disk1/log-kippo/$now/downloads.csv
mysql -u root --password=$clave kippo -e "select * from input" -B > /media/disk1/log-kippo/$now/input.csv
mysql -u root --password=$clave kippo -e "select * from sensors" -B > /media/disk1/log-kippo/$now/sensors.csv
mysql -u root --password=$clave kippo -e "select * from sessions" -B > /media/disk1/log-kippo/$now/sessions.csv
mysql -u root --password=$clave kippo -e "select * from ttylog" -B > /media/disk1/log-kippo/$now/tty.csv


Ten en cuenta en cambiar el path donde has montado tu disco duro de intercambio.

Preparamos un cron para que a las 23:45 realice la copia, ya que vamos a programar que a las 24:00 la máquina Honeypot se apague, se borre, se regenere desde una plantilla y se inicie.

Ahora es el turno de montar un sistema de control. Una máquina aislada del Honeypot, en la que solo se permita el acceso por ssh desde lo que denominaría la sede. En esta máquina vamos a montar el disco duro en el que se guarda toda la información del Honeypot, para poder extraer la información. De esta manera, el honeypot NUNCA tendrá una conexión hacia ningún sistema de producción, el intercambio lo haremos montando el disco duro de datos en otra máquina que si tiene acceso al sistema de producción. Esta máquina debe estar muy capada.

Cualquier máquina linux que montes es buena. El asunto ahora es agregarle en Vmware un segundo disco, que será el mismo segundo disco que hemos montado en la máquina Honeypot, osea, el de intercambio...

Comprobamos que accedemos al disco duro de intercambio.

Ahora es el turno de coordinar el tiempo entre que el Honeypot está apagado, arrancamos la máquina de control, realizamos el volcado de información hacia nuestra sede, apagamos la máquina de control e iniciamos el Honeypot de nuevo. Aquí deberías tener un script al inicio para volcar la información. Omito de momento esta parte ya que mi destino, de momento, será la propia máquina Honeypot control.

Recuerda este artículo para automatizar la tarea.

El final del script es este:

Connect-VIServer -Server ip-server-esxi -User usuario -Password contraseña
Stop-VM -VM "nombre de la clonada" -Kill -Confirm:$false
Remove-VM "nombre de la clonada" -DeletePermanently -Confirm:$false
Clone-MasterVM -MasterName "nombre de la original"  -CloneName "nombre de la clonada" -DatastoreName "nombre del datastore" -Register -PowerON

Vamos a realizar una modificación. Trás apagar la máquina virtual Honeypot, vamos a añadir:

Connect-VIServer -Server ip-server-esxi -User usuario -Password contraseña
*conexión al vmware
Stop-VM -VM "nombre de la clonada" -Kill -Confirm:$false
*parar el honeypot
Start-Sleep -s 60
*espera 1 minuto a que se apague.
Remove-VM "nombre de la clonada" -DeletePermanently -Confirm:$false
*borra la máquina honeypot
Start-VM -VM control-honeypot
*arranco la máquina de control
Start-Sleep -s 300
*espero 5 minutos para que arranque y ejecute un script de inicio volcando información.
Stop-VM -VM "control-honeypot" -Kill -Confirm:$false
*apago la máquina de control.
Clone-MasterVM -MasterName "nombre de la original"  -CloneName "nombre de la clonada" -DatastoreName "nombre del datastore" -Register -PowerON
*clono el honeypot plantilla a una máquina nueva y la inicio.

De momento el esquema es:

EQUIPO VMWARE ESXi.
-Máquina firewall para natear la IP pública con las máquinas virtuales y el propio Vsphere client.
 - Ip pública al firewall.
 - Nateos al puerto ssh y vsphere client al host Vmware. Ip privada el host.
 - Nateos al puerto del Honyepot configurado.
 - Nateo a vlan distinta para la máquina de control. Todos puertos cerrados salvo ssh filtrado a sede.
-Máquina Honeypot Honeydrive.
-Máquina Debian para recibir la información.
*Disco duro compartido entre la máquina Honeypot y Control.
*script modificado del artículo anterior con este.

Tenemos un Honeypot con kippo que se regenera todas las noches y guarda la información en un disco duro compartido con otra máquina virtual, que será la que usemos para trabajar la información. Digamos que es la parte de infraestructura.

En el próximo capítulo de la serie completaremos el script Powershell con las típicas mejoras que habrás podido observar, y realizaremos algún trabajo con la clasificación de los logs que nos ha generado Kippo. Tambien pasaremos por snort y similares el fichero pcap de captura.

Espero que os guste el artículo, gracias por leerme !!!

















IP REPUTATION Collective Intelligence Framework. Parte 2.

Estimados amigos de Inseguros !!!

Vamos a seguir madurando el concepto de IP REPUTATION que comenzamos en el pasado artículo.


En esta ocasión, vamos a preparar el framework de trabajo para obtener la información de seguridad de eventos no solo para nuestro sistema OSSIM como vimos, sino para otras fuentes públicas.

Vamos a usar el proyecto CIF Collective Intelligence Framework elaborado por REN-ISAC que me recomendó el profesor Jose Luis Chica. Gracias !!!

El proyecto implementa el formato IODEF  Incident Object Description Exchange Format . Volvemos a las épocas de los RFC´s :-)


Se puede observar que en la descripción del proyecto no aparece esta información, ya que la definición del formato IODEF se contempla como formato de transporte, y no de almacenamiento de larga duración, por lo que CIF implementa una definición de IODEF adaptada a un almacenamiento en formato JSON no en XML con en origen indica el RFC. El resultado es una tabla con una sola columna de texto. Se crean índices con la extracción de los metadatos, y al parecer, la velocidad es superior que en un planteamiento clásico de estructura SQL normalizada, con mil millones de tablas y campos.

Una imagen vale más que mil palabras. 


A diferencia de un SIEM, con CIF podemos no solo recolectar información, sino que podemos generar el output que necesitamos para incorporar en nuestros sistemas de prevención. Podemos generar la alerta para que nuestro Snort o Bro PAREN el ataque. Podemos cargar la información en IPTABLES, etc. Con OSSIM por ejemplo tendrías que hacer lo que comentamos en el anterior post, crearte un script que ejecute una inserción de la ip del evento en tu sistema. 
La lista de Outputs que genera CIF es: Bind Zone config, BRO, CSV, HTML,  IPTABLES, JSON, PCAPFILTER , SNORT, TABLE

La comodidad de usar una API nos permite usar la parte del proyecto que nos interese, consultando o exportando información de una manera controlada.

Podemos crear una estructura federada para compartir información entre varios CIF. El objetivo primordial de un proyecto como este, desarrollado para dar cobertura a los CERT´s, es el de compartir la información de amenazas.



  
El otro punto es que se integra con numerosas fuentes de información públicas o FEEDS. Como puedan ser:*algunas no funcionan bien, o bien ya no existen publicamente*

http://honeytarg.cert.br/honeypots/
http://exposure.iseclab.org/
http://arakis.pl/en/index.html
http://www.spamcop.net/
http://honeytarg.cert.br/spampots/
http://zeltser.com/combating-malicious-software/malicious-ip-blocklists.html
http://contagiodump.blogspot.com/2010/11/links-and-resources-for-malware-samples.html
http://urlquery.net/index.php
http://www3.malekal.com/malwares/
http://jsunpack.jeek.org/dec/go?list=1
http://vxvault.siri-urz.net/ViriList.php
http://minotauranalysis.com/malwarelist.aspx -- overlaps malc0de and cleanmx
http://rss.uribl.com/nic/NAUNET_REG_RIPN.xml
http://www.malwareblacklist.com/showMDL.php
http://abusix.org/service/spamfeeds
http://atlas.arbor.net/summary/fastflux?out=xml
http://dshield.org/diary.html?storyid=12373
https://reputation.alienvault.com/reputation.data
http://security-research.dyndns.org/pub/malware-feeds/ponmocup-botnet-domains.txt
http://security-research.dyndns.org/pub/malware-feeds/ponmocup-botnet-ips.txt
http://security-research.dyndns.org/pub/malware-feeds/ponmocup-malware-domains.txt
http://security-research.dyndns.org/pub/malware-feeds/ponmocup-malware-ips.txt
http://malwareint.com
http://www.senderbase.org/home/detail_virus_source
http://callbackdomains.wordpress.com
http://labs.snort.org/iplists/
http://www.enisa.europa.eu/activities/cert/support/proactive-detection/proactive-detection-report
http://rules.emergingthreats.net/open/suricata/rules/compromised-ips.txt
http://rules.emergingthreats.net/open/suricata/rules/botcc.rules
http://rules.emergingthreats.net/open/suricata/rules/rbn-ips.txt
https://www.projecthoneypot.org/list_of_ips.php
http://rules.emergingthreats.net/open/suricata/rules/tor.rules
http://rules.emergingthreats.net/open/suricata/rules/compromised.rules
http://www.malwaredomainlist.com/hostslist/ip.txt
http://rules.emergingthreats.net/open/suricata/rules/rbn.rules
http://www.mtc.sri.com/live_data/attackers/
http://intel.martincyber.com/ip/
https://reputation.alienvault.com/reputation.generic
https://www.openbl.org/lists/base.txt
http://www.blocklist.de/lists/ssh.txt
https://palevotracker.abuse.ch/
http://www.malwaregroup.com/ipaddresses
http://www.ciarmy.com/list/ci-badguys.txt
http://www.malware.com.br/cgi/submit?action=list
http://www.autoshun.org/files/shunlist.html
abusechweb http://dnsbl.abuse.ch/webabusetracker.php
arbor http://atlas-public.ec2.arbor.net/public/ssh_attackers
autoshun http://www.autoshun.org/files/shunlist.csv
badguys http://www.t-arend.de/linux/badguys.txt
blacklisted http://www.infiltrated.net/blacklisted
brawg http://www.brawg.com/hosts.deny
cleanmxv http://support.clean-mx.de/clean-mx/xmlviruses?response=alive&format=csv&fields=url,ip,domain&domain=
cleanmxp http://support.clean-mx.de/clean-mx/xmlphishing?response=alive&format=csv&fields=url,ip,domain&domain=
danger http://danger.rulez.sk/projects/bruteforceblocker/blist.php
denyhost http://stats.denyhosts.net/stats.html
dshield http://www.dshield.org/ipsascii.html?limit=5000
dynastop http://dynastop.tanaya.net/DynaStop.BleedingThreats.conf
emergingthreats http://www.emergingthreats.net/rules/bleeding-compromised.rules
evilssh http://vmx.yourcmc.ru/BAD_HOSTS.IP4
geopsy http://www.geopsy.org/blacklist.html
haleys http://charles.the-haleys.org/ssh_dico_attack_hdeny_format.php/hostsdeny.txt
kidsclinic http://www.kids-clinic.jp/uni/ipaddress/new_log
kolatzek http://robert.kolatzek.org/possible_botnet_ips.txt
malekal http://www3.malekal.com/exploit.txt
maldom http://mirror1.malwaredomains.com/files/domains.txt
mdl http://www.malwaredomainlist.com/mdl.php?colsearch=All&quantity=All&search=
prometheus http://downloads.prometheus-group.com/delayed/rules/modsec/domain-blacklist.txt
skygeo http://sky.geocities.jp/ro_hp_add/ro_hp_add_hosts.txt
sshbl http://www.sshbl.org/list.txt
stopforumspam http://www.stopforumspam.com/downloads/bannedips.csv
surriel rsync://psbl-mirror.surriel.com/psbl/psbl.txt

Imagina parsear todas estas fuentes a mano :-)

Existe otro proyecto parecido. AbuseHelper pero no he podido investigar mucho, y por lo que veo, está poco actualizado
La instalación realizada sobre Debian Wheezy requiere de las siguientes dependencias y paquetes:

sudo aptitude -y install rng-tools postgresql apache2 apache2-threaded-dev gcc g++ make libexpat1-dev libapache2-mod-perl2 libclass-dbi-perl libdigest-sha-perl libnet-cidr-perl libossp-uuid-perl libxml-libxml-perl libxml2-dev libmodule-install-perl libapache2-request-perl libdbd-pg-perl bind9 libregexp-common-perl libxml-rss-perl libapache2-mod-gnutls libapreq2-dev rsync libunicode-string-perl libconfig-simple-perl libmime-lite-perl libfile-type-perl libtext-csv-perl libio-socket-inet6-perl libapr1-dbg libhtml-table-perl libdate-manip-perl libtry-tiny-perl libclass-accessor-perl pkg-config libnet-ssleay-perl vim libjson-xs-perl libextutils-parsexs-perl libdatetime-format-dateparse-perl libnet-patricia-perl libdatetime-perl libtext-table-perl libcpan-meta-perl libmodule-build-perl

Si usas otra distribución puedes consultar la dependencias:
El siguiente paso es instalar zeromq, paquete necesario para la gestión de colas de mensajes entre componentes y algunos componentes más que requieren instalación por fuente.

$ wget http://download.zeromq.org/zeromq-2.2.0.tar.gz
$ tar -zxvf zeromq-2.2.0.tar.gz
$ cd zeromq-2.2.0
$ ./configure && make && sudo make install
$ sudo ldconfig

sudo PERL_MM_USE_DEFAULT=1 perl -MCPAN -e 'install Test::SharedFork,Test::TCP,Net::Abuse::Utils,Regexp::Common::net::CIDR,LWP::Protocol::https,Google::ProtocolBuffers,Iodef::Pb::Simple,Compress::Snappy,Snort::Rule,Time::HiRes,Net::Abuse::Utils::Spamhaus,Net::SSLeay,Net::DNS::Match,Log::Dispatch,Sys::MemInfo,LWPx::ParanoidAgent,ZeroMQ,Net::Whois::IP,Net::DNS,Email::Address'
 
$ wget http://search.cpan.org/CPAN/authors/id/J/JS/JSTOWE/Linux-Cpuinfo-1.7.tar.gz
$ tar -zxvf Linux-Cpuinfo-1.7.tar.gz
$ cd Linux-Cpuinfo-1.7
$ perl Makefile.PL && make && sudo make install
 
Ahora nos auto-baneamos de Internet durante un tiempo :-)

iface eth0 inet
        dns-nameservers 127.0.0.1
sudo vim /etc/resolv.confnameserver 127.0.0.1

Añadimos el usuario CIF:

sudo adduser --disabled-password --gecos '' cif

Configuramos algunos parámetros en Apache.

sudo a2ensite default-sslsudo a2enmod ssl perl apreq

sudo vi /etc/apache2/sites-available/default-ssl
<IfModule mod_ssl.c>

<VirtualHost _default_:443>
+      PerlRequire /opt/cif/bin/http_api.pl
+      Include /etc/apache2/cif.conf
....
 
sudo vi /etc/apache2/cif.conf
 
<Location /api>
    SetHandler perl-script
    PerlResponseHandler CIF::Router::HTTP
    PerlSetVar CIFRouterConfig "/home/cif/.cif"
</Location>
 
Por último configuramos rng-tools para generar numeros random.

echo 'HRNGDEVICE=/dev/urandom' | sudo tee -a /etc/default/rng-tools

Configuramos BIND y Postgres con las instrucciones que nos proporciona la documentación oficial.Si tienes problemas al reiniciar Bind puedes comprobar el fallo ejecutando: named-checkconf

Ahora instalamos el framework CIF.

Paramos Apache
$ tar -xzvf cif-v1-1.X.X.tar.gz
$ cd cif-v1-1.X.X
$ ./configure && make testdeps
$ sudo make install
$ sudo make initdb 

El proceso de configuración es muy sencillo y está bien documentado aquí.

Este proceso tarda bastante, quizás horas.


Una vez terminado el proceso de instalación, configurada la rotación de logs y creados los cron para ejecutar las actualizaciones, es turno de probar la herramienta.

Para poder consultar la información tenemos varios métodos, un cliente instalado, un plugin para los navegadores Firefox y Chrome y la API.

Vamos a instalar el complemento en Chrome tal como lo índica el manual. Descargamos el plugin. Y configuramos:



Configuramos la dirección del servidor, la API key de cliente y probamos conexión.



Con esto ya podemos consultar nuestro servidor CIF desde Chrome. Vamos a hacer una prueba. Podemos hacer click sobre el icono de CIF en la parte superior derecha, o directamente sobre un dominio, correo, IP o similar, seleccionarlo y botón derecho.




Ya tenemos instalado CIF server para recolectar inteligencia de distintas fuentes de información mas  o menos públicas. Podemos consultar manualmente esta información con el Plugin para Chrome. 

En los próximos episodios seguiremos trabajando con la idea de integrar en un única base de datos, nuestras IP´s, cotejando la información con estas fuentes, y creando una base de datos sólida.

Espero que os guste, gracias por leerme.

jueves, 12 de marzo de 2015

IP REPUTATION- Crea tu bbdd de información de los distintos sistemas de seguridad. PARTE 1

Estimados amigos de Inseguros.

En el post de hoy vamos a empezar una serie de artículo relacionados con la creación de una base de datos de Reputación IP. La idea es tener una bbdd de direcciones ip´s que han atacado de alguna manera a alguno de nuestros sistemas o honeypots.

De esta manera si tenemos actividad maliciosa en un vps externo o una sede remota, podremos obtener esa información y banear no solo en el VPS, sino en todos nuestros sistemas.

Para realizar esta práctica voy a trabajar con la base de datos instalada en OSSIM ya que la mayoría de mis eventos los centralizo en el SIEM, si los tengo disponibles para analizar, los tengo disponibles para almacenar.


Uno de los primeros pasos que debes hacer es el de la servilleta. Documentar las ideas que te vayan surgiendo en el proyecto y medio documentarlas. Yo suelo hacer esto, llegando a ser autentico fan de los folios A3 llenos de cajitas y flechas con los datos y procesos. Eso si, solo los entiendo yo xD.


El primer paso que vamos a hacer es conectarnos con nuestra bbdd de OSSIM para crear la estructura de la bbdd de IP REPUTATION. Los datos de configuración los tenemos en /etc/ossim/ossim_setup.conf.

Puedes usar cualquier base de datos que tengas o quieras crear, pero dado el gran número de registros que se van a insertar, tantos como Events Per Second tengas en tu SIEM, prefiero hacerlo en local en esa máquina para evitarme conectarme a otro Mysql externo. Para gusto los colores.

Para obtener información de actividad maliciosa en la red vamos a usar distintas fuentes de información.

Una de las fuentes que vamos a usar para nuestra IP REPUTATION es la base de datos OTX de AlienVault. Si tenemos ya ese conocimiento de confianza de parte de una gran empresa, por qué no usarlo? Indicaremos en todo momento en nuestra bbdd que esas ip´s provienen de OTX y no de nuestros sistemas internos.

En este capítulo de Inseguros vimos como registrarnos en el servicio para usarlo desde la web o desde OSSIM.

La bbdd es un fichero ubicado en /etc/ossim/server/reputation.data  con el siguiente formato:

112.125.32.145#4#2#Scanning Host#CN#Beijing#39.9289016724,116.388298035#11
112.64.214.174#4#2#Scanning Host#CN#Shanghai#31.0456008911,121.39969635#11
113.108.197.251#4#2#Scanning Host#CN#Guangzhou#23.1166992188,113.25#11
113.193.6.214#4#2#Scanning Host#IN#Mumbai#18.9750003815,72.8257980347#11

Podemos investigar el log para saber cuando se está descargando la información y si existe alguna incidencia.

alienvault:/etc/ossim/server# tail -F /var/log/ossim/reputation.log
2015-03-11 09:15:03 Message-update: Reputation updated
2015-03-11 09:30:01 Message-feedback: Running reputation feedback
2015-03-11 09:30:01 Message-feedback: Getting data from database
2015-03-11 09:30:02 Message-feedback: Sending information (reputation step)
2015-03-11 09:30:03 Message-feedback: Information sent (reputation step)
2015-03-11 09:30:03 Message-feedback: Sending information (all feedback step)
2015-03-11 09:30:03 Message-feedback: Information sent (all feedback step)
2015-03-11 10:15:01 Message-update: Running reputation updater
2015-03-11 10:15:02 Message-update: Updating database from server
2015-03-11 10:15:02 Message-update: Reputation updated

Otra fuente que vamos a usar es spamhaus. Mediante el sencillo comando host ip.zen.spamjaus.org podemos consultar si está incluido o no. Lo implementaremos en un script por cada ip que introduzcamos en la bbdd, añadiendo este dato a una "columna" de la ip del tipo "INCLUIDO SPAMHAUS". Lo veremos en otro capítulo.

Tenemos que tener en cuenta que vamos a crear una base de datos de conocimiento. Las acciones posteriores que configuramos en nuestros sistemas de seguridad las tenemos que definir según nuestro criterio. Por ejemplo, puede que no bloqueemos una dirección IP que ha intentado hacer un Connect a un puerto de un Honeypot... sería como un port scan o similar y no daríamos a basto en bloquear las ip´s. Pero sin embargo, si esa misma IP está reportada en OTX o SPAMHAUS quizás si podríamos configurarlo como una amenaza real y realizar acciones defensivas.

Podemos usar este conocimiento para otros sistemas como la detección/prevención de intrusos. Podemos consultar esta lista con Mod_Security o Snort para añadir mas profundidad a los bloqueos, no solo la IP sino el patrón de ataque.



EL TIPICO DATO-INFORMACION-CONOCIMIENTO-INTELIGENCIA.

El dato serían los logs de firewalls, ids, waf, av, siem, etc. Por  ejemplo: ssh connect a un honeypot.

La información sería la clasificación y métrica de los eventos que han producido el dato. Por ejemplo: clasificación como riesgo bajo.

El conocimiento sería peligrosidad de esa información. Por ejemplo, si tengo varios eventos de ese tipo, pero desde una ip en un país que no es "a priori" atacante, o que es España y lo considero un posible escanneo dirigido.

La inteligencia sería ACTUAR con ese conocimiento. Por ejemplo, baneando esa ip y registran un log que a su vez me genere datos con información, para llegar al conocimiento que esa ip lleva 6 meses intentando conectarse.

La cuestión sobre todo esto es definir donde se va a realizar la gestión del conocimiento. Para eso está el SIEM y por eso se toma como fuente base de recolección. Aunque obtendremos información de otros servicios de seguridad, como pueda ser Fail2Ban, que por cualquier motivo no hemos integrado en el SIEM. Suele ser por pereza para escribir las regular expressions para los logs  :-)

Vamos a empezar con lo más fácil. Cargar nuestros eventos del SIEM Ossim en una tabla de nuestra base de datos IP REPUTATION. Para ello utilizaremos una acción para cada evento, que ejecutará un script de inserción.


Si tienes dudas en como crear políticas puedes consultar este artículo.


No te voy a dar la tabla de destino xD ni el script que hace el insert into, solo difundo mis ideas xD.

En algún momento del proyecto vamos a necesitar de un lenguaje de programación algo más "versátil" que bash script. Por ejemplo, para ejecutar procedimientos almacenados en Mysql que requieren de un "output". Usaremos PHP ejecutado desde scripts bash para ir realizando nuestras "lógicas de negocio".

Un ejemplo de tablas que puedes crear son:

LOCATION: cargar la ip, pais, codigo pais, ciudad, latitud y longitud y timestamp. Con esta tabla desnormalizada podemos cargar todo lo relativo a geolocalización.

DATA: los datos que extraemos del script de inserción que ejecutamos con OSSIM. De momento solo vamos a introducir estos datos, en otros capítulos podemos agregar otras fuentes.

SENSOR: identificar que sensor ha generado el evento, como pueda Snort, Modsec, Ossec, etc.

CATEGORIAS: una manera de clasificar los eventos: portscan, exploit, malware, spam, bad traffic, tor traffic.

WHITELIST: una tabla para cargar aquellas ip´s que no queremos incluir NUNCA, como puedan ser algunas ip´s que usemos para test de intrusión internos. 

OTX: Cargar la información de la base de datos de OTX en nuestro sistema nos ayudará en varios sentidos. El primero, que todos los datos de LOCATION nos los brinda, es decir, que cualquier evento que venga a nuestros sistemas, cuya ip exista en OTX, nos ahorramos pasarle el script para geolocalizarlo.


Una de las cosas que debes valorar es que si tienes muchas inserciones por segundo, mucha actividad maliciosa a registrar, puede que necesites un almacenamiento para Mysql del tipo MyIsam y no Innodb que suele ser más lento para la escritura. El problema de este almacenamiento es que MyIsam no trabaja con FK, por lo que toda la lógica de integridad referencial la tendrás que mantener con tu código php. 

Por poner un ejemplo, gestionar que una ip está incluida ya o no en la IP REPUTATION. O si por lo contrario vas a usar como pk el binomio IP-Tipo de ataque. Si una IP se elimina de la base de datos al pasar una semana, su registro asociado en LOCATION debería desaparecer solo no? para qué guardar información de IP´s que no están en tu registro...

Vas a tener un hitcount para saber si una ip maliciosa es "novata" o lleva ya algunos intentos? Puede que para sistemas en producción que paramos los ataques y baneamos, no va a aumentar el hitcount, pero si en un Honeypot...

Creo que con estos datos ya puedes empezar a pensar en montarte tu sistema de reputación ip propio.

Estoy preparando otra serie de artículos sobre el despliegue automático de honeypots de manera seria, con sus medidas de seguridad. En algún punto conectaré las dos series de artículos.

La idea del proyecto global que estoy montando es:

Tener un OVF con todas las máquinas y configuraciones necesarias para instalar un sistema completo Honeypot seguro en un VPS, y con esa información alimentar la base de datos de reputación IP.

Espero que os guste la serie. Gracias por leerme.