miércoles, 2 de octubre de 2019

Integración de Sophos Central en Splunk




¡Buenas lectores!

Después de 1 mes y medio alejado de las redes por vacaciones, trabajo y demás, volvemos con un artículo que a alguno le puede servir de ayuda sobre todo en la parte de BlueTeam e Integración. Vamos a ver como integrar Sophos Central con un SIEM, en este caso el SIEM que voy a utilizar y el cual tengo montado para uso personal es SPLUNK.

En este artículo, veremos como se integra a través de un script que podemos descargar desde Github. Como alguno sabrá, también es posible integrar Sophos Central en Splunk a través de un TA, el problema que tenemos a la hora de hacerlo de esta manera es que solo permite 1 API por TA y si tenemos varios clientes, no nos sirve ya que son varias API para un único TA.

He de comentar que en principio no importa que tipo de SIEM estemos utilizando, siempre y cuando este pueda recoger inputs locales o recibirlos a través de SYSLOG. Para este caso se va a realizar recogiendo un archivo local y añadiéndolo al SIEM para su monitorización.

Para la integración de Sophos Central con nuestra solución SIEM, necesitaremos descargar desde Github el script que nos permite realizar la llamada a la “API + Headers”, para así extraer las alertas y eventos que se produzcan en la consola de Sophos Central.

Descargamos el script, en mi caso lo he ubicado dentro del directorio "etc" en el directorio home de Splunk: /opt/splunk/etc/Sophos-Central-SIEM/:



Output de help del binario "siem.py" :



El archivo que tendremos que modificar para añadir la API es "config.ini", lo veremos en pasos siguientes.


Generación de API en Sophos Central


Pasamos a Sophos Central para generar la API. Os dejo las imágenes para que sea más visual:

Nos dirigimos a "Configuración global" > "Administración de token de API":



Presionamos en la esquina superior derecha en "Añadir Token", establecemos un nombre para nuestra API Token y guardamos:



Nos apareceran directamente las API's generadas, para este caso nos interesa "URL acceso API + Encabezados", la copiamos directamente del botón en el lateral de esta:


Modificación de Script y añadir API


Una vez generada y copiada la API que necesitaremos, tendremos que dirigirnos al directorio que hemos descargado desde Github y editar el archivo de configuración "config.ini", pegaremos la API en la 4ª línea que comienza con "token_info":



Podemos elegir el formato de salida que tendrán los eventos generados (json, cef o keyvalue), el nombre del archivo output txt que los contendrá, nos permite elegir si queremos eventos, alertas o todo (event, alert o all) y por último nos permite configurar las propiedades para un reenvío a través de Syslog, el cual no utilizaremos en este caso.

Una vez añadida la API, procedemos a ejecutar el archivo "siem.py" y obtendremos el archivo con el nombre indicado anteriormente en la ubicación "./log/ARCHIVO.txt"

Podemos visualizar el archivo output generado:



He de comentar que cuando ejecutamos "siem.py", extraerá únicamente los eventos/alertas nuevos que no han sido generados anteriormente como máximo en 24 horas, en su ejecución inicial únicamente recupera las últimas 12 horas ya que no tenemos generado el archivo de estado. A través de los comandos en la ejecución del binario, podemos indicarle que en su ejecución inicial, recoja las últimas 24 horas (-s SINCE o --since=SINCE). 

En la carpeta "state", se almacena el estado en el cual quedó en la última ejecución para que así no se duplique la extracción de eventos/alertas en el archivo output.



Bien, ya tenemos el archivo de configuración "config.ini" con la API añadida y se ha realizado la primera ejecución de "siem.py", solo nos faltaría automatizar el proceso para ejecutar el binario "siem.py" cada X tiempo para que las alertas y eventos se vayan agregando automáticamente al archivo de salida txt.

Tengo que comentar que tuve problemas a la hora de automatizar la ejecución del binario, si lo añadía directamente con "crontab -e", no se ejecutaba correctamente. Al final decidí crear un script en bash (por llamarlo de alguna forma) que contuviese el cambio de directorio a la ubicación del binario y la ejecución y en el archivo crontab alojado en /etc añadir el comando para que se ejecute cada X tiempo.

Existe la posibilidad de realizar la automatización desde el propio Splunk añadiendo Scripts y tiempo de ejecución, pero creo que es mejor que estos procesos se lleven a cabo fuera de la solución Siem, ya que le estaríamos añadiendo un consumo extra. 

De todas formas si alguien conoce otra alternativa para realizar este proceso, que lo deje en los comentarios y estaré agradecido de poder leerlo y añadirlo a la lista =P

Vamos al lío, creamos el script en bash:



Le asignamos permisos de ejecución y nos dirijimos a /etc para editar el archivo crontab directamente con el editor, añadimos la última línea que nos permitirá automatizar el proceso de ejecución.

Como se puede ver en la imagen, está puesto para que se ejecute cada 1 min ya que estuve realizando comprobaciones por el tema del script y demás, pero podéis indicarle el tiempo que consideréis necesario:


Una vez modificado y los cambios guardados en el archivo crontab, comprobamos en "/var/log/syslog" que se está ejecutando correctamente:

 
Como podemos ver en la imagen anterior, el proceso se ejecuta cada minuto, bien hemos terminado la primera parte, pasemos a la segunda parte que tiene que ver con Splunk y como añadir Inputs Locales.


Agregando Local Input en Splunk


Nos dirigimos a Splunk y hacemos clic en "Settings" > "Data Inputs":




Tenemos que añadir un nuevo Local Input de tipo Files & Directories. Hacemos clic en "+ Add new":


Nos abrirá la ventana para configurar y seleccionar el archivo local.

Seleccionamos Continuously Monitor para que constantemente esté comprobando el contenido del archivo e indexarlo, hacemos clic en Browse y seleccionamos el archivo que vamos a monitorizar, en este caso el archivo output txt que genera el binario siem.py.

 


Una vez realizado, continuamos pulsando en Next en la parte superior.

Como vemos, se muestran los eventos/alertas generados en formato JSON. Podemos elegir un "Source Type" para identificar estos eventos según origen:





Configuramos el Source Type para identificar al cliente y pulsamos nuevamente en Next:


Ahora toca el turno de seleccionar el tipo de App Context - Search & Reporting (Search)  y  crear el Index (Índice) para agrupar todos los eventos, esto nos permitirá tener en un mismo saco todos los eventos y alertas de Sophos, hacemos clic en Create a new index y lo creamos.

Cuando se nos abra la ventana para crear el Index, únicamente introducimos un nombre para este, el resto se deja por defecto. Pulsamos en Next:


En la siguiente ventana, nos mostrará un pequeño resúmen del Local Input a crear:


Para finalizar pulsamos en Submit y en la siguiente ventana presionamos en Start Searching para empezar a realizar búsquedas en Splunk:


Recordemos que el tipo de lenguaje que utiliza Splunk para la búsqueda y creación de queries, se denomina SPL (Search Processing Language), para todos aquellos que no lo sepan, es un tipo de lenguaje que combina las mejores capacidades de SQL con la sintaxis de tuberías de Unix.


Resultado de búsqueda y tabla


Para comprobar que el archivo monitorizado está siendo indexado correctamente, podemos realizar una consulta simple utilizando el nombre del Index que hemos definido y podremos comprobar como se nos muestran correctamente los eventos:


Ya para terminar, si nos queremos cercioar que efectivamente se está realizando la llamada a la API y recogiendo los eventos/alertas correctamente y de esta forma Splunk los va indexando, podemos generar una alerta en un Endpoint para que se genere una alerta en Sophos Central.

Yo he generado un par de alertas y he sacado una tabla para que se muestre de una forma más visual:



Resumen de campos JSON

 

  • customer_id: Identificador único del cliente.
  • datastream: Tipo log (alerta o evento).
  • dhost: Nombre de la estación 
  • endpoint_id: Identificador único del endpoint de la estación de trabajo.
  • endpoint_type: Tipo de estación Endpoint.
  • group: Tipo de política en Sophos Central.
  • id: Identificador del evento/alerta generado.
  • name: Pequeño resumen de evento/alerta.
  • rt: Fecha/Hora de cuando se ha generado el evento/alerta.
  • severity: Nivel de criticidad/severidad.
  • source_info: Si hacemos clic en el desplegable, nos mostrará la dirección IP de la estación de trabajo donde está instalado el Endpoint de Sophos.
  • suser: Nombre de usuario que ha generado el evento/alerta.

Documentación sobre Event Types Sophos API: https://community.sophos.com/kb/en-us/132727

Finalizando


Es posible que os estéis preguntando...¿Y como se añaden más clientes? Bueno, para añadir más clientes lo único que hay que realizar es copiar el directorio del script y duplicarlo, acordándose de añadir la API correspondiente en el archivo de configuración, añadirlo a crontab y al script creado en bash, a parte de añadir el Local Input en Splunk con un nuevo Source Type para identificar a este cliente. El Index puede ser el mismo para todos y así tenerlos todos los clientes indexados en uno.

También cabe la posibilidad de con un mismo Script, manejar diferentes API's, pero sinceramente no lo he probado, si alguno quiere dejarme en los comentarios una forma alternativa con la que se pueda realizar, estaré encantado de leerte y aprender =D

Nos vemos en el próximo artículo!

Saludos!

rekkatz



lunes, 12 de agosto de 2019

Fortigate y Wireshark - Convertir Sniffer Packet en archivo PCAP




¡Buenas lectores!

En esta entrada quiero compartir una de las herramientas de conversión de tráfico para Fortigate que he utilizado en varias ocaciones durante mi día a día para obtener un archivo PCAP durante un análisis de tráfico, en el caso de no tener la opción de "Packet Capture" en el dispositivo Fortigate.

Para ello utilizaremos los siguientes Scripts/Herramientas:

En algunos casos, es posible que esta opción no aparezca en el dispositvo,  ya sea por que tiene una versión inferior a la 6.0, por que no tiene disco físico el appliance o porque el modelo de este no trae la opción de fábrica.

Para la utilización de esta herramienta, necesitaremos conocer por encima la herramienta de diagnóstico "sniffer packet" que trae por CLI los dispositivos de la marca Fortinet en sus sistemas FortiOS.

En resumidas cuentas, lo que haremos será obtener mediante CLI las tramas de conexiones generadas y utilizar la herramienta "fgt2eth" para la conversión de un archivo TXT a un archivo PCAP para posteriormente ejecutarlo con Wireshark.

Requisitos que tendremos que tener en nuestra máquina:


Vamos al lío:

Para empezar utilizaremos Putty donde tendremos que configurar la opción "All session output" para que almacene en un archivo LOG todo el output de la sesión SSH que vamos a utilizar:

Configuracion_Putty


Una vez tengamos la opción indicada marcada y la ubicación donde se almacenará el archivo, establecemos conexión SSH con el dispositivo Fortigate.

Ahora que estamos dentro, vamos a ver que es la herramienta de "Sniffer Packet".

Esta herramienta nos permite realizar un rastreo o Sniffer del tráfico de una interfaz específica o varias interfaces a la vez, muy muy parecido a la ejecución de tcpdump pero integrado en FortiOS.

Su sintaxis es la siguiente:

diagnose sniffer packet <interface> <'filter'> <verbose> <count> a


Y las opciones que nos permite utilizar esta herramienta son:

  • Interface: Es la interfaz por la cual se capturará el tráfico, podemos especificar "any" y capturará por cualquier interfaz que esté configurada.
  • Filter: Será el filtro que le indiquemos para que realice match del tráfico deseado. Puede contener la siguiente sintaxis:  '[[src|dst] host] [[src|dst] host] [[arp|ip|gre|esp|udp|tcp] [port_no]] [[arp|ip|gre|esp|udp|tcp] [port_no]]'
  • Verbose: Es el tipo de información que mostrará según las tramas capturadas, se establecen en 6 niveles de verbosidad, de menor a mayor en cuanto a detalle:
    • Nivel 1: Muestra la cabecera de los paquetes
    • Nivel 2: Muestra la cabecera y los datos IP de los paquetes
    • Nivel 3: Muestra la cabecera y los datos ethernet de los paquetes
    • Nivel 4: Muestra la cabecera de los paquetes con el nombre de interfaz
    • Nivel 5: Muestra la cabecera y los datos IP de los paquetes con el nombre de interfaz
    • Nivel 6: Muestra la cabecera y los datos ethernet de los paquetes con el nombre de interfaz
  • Count: Con esta opción, podemos indicar los paquetes a recoger antes de que se detenga la herramienta. Si no indicamos nada o establecemos "0", seguirá recogiendo paquetes hasta que presionemos Ctrl + C.
  • Opción "A": Nos permite visualizar las marcas de timestamps durante la captura de las tramas.

Una vez entendido esto, vamos a lanzar la herramienta de "Sniffer Packet" en la conexión SSH que tenemos abierta al dipositivo Fortigate por CLI. Para nuestro caso, utilizaremos la opción de Verbose 6, para que nos muestre lo más detallado posible los paquetes capturados:

tramas_capturadas


Como se puede ver en la imagen anterior, se ha capturado el tráfico con destino la IP de los DNS primarios de Google (8.8.8.8) a través de ICMP (Ping).

Ahora ya tendremos en el archivo LOG la salida de la sesión con Putty. Pero antes necesitamos eliminar la primera línea que se genera en el archivo LOG:


=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2019.08.12 16:01:29 =~=~=~=~=~=~=~=~=~=~=~=


y guardamos los cambios.

En este punto llega el turno de la herramienta "fgt2eth.exe", la cual nos permitirá convertir el archivo LOG en un PCAP.

Las opciones que nos muestra la herramienta:

Version : Dec 19 2014
Usage : fgt2eth.pl -in <input_file_name>

Mandatory argument are :
    -in <input_file>      Specify the file to convert (FGT verbose 3 text file)

Optional arguments are :
    -help                 Display help only
    -version              Display script version and date
    -out <output_file>    Specify the output file (Ethereal readable)
    

By default <input_file>.pcap is used
    - will start wireshark for realtime follow-up


    -lines <lines>        Only convert the first <lines> lines
    -demux                Create one pcap file per interface (verbose 6only)
    -debug                Turns on debug mode



En nuestro caso, vamos a utilizar el comando con la sintaxis:

fgt2eth.exe -in putty.log -out google_icmp.pcap

Una vez ejecutado, obtendremos nuestro archivo PCAP:

ejecucion_herramienta



Ya solo nos faltaría ejecutarlo con Wireshark y comprobar que los paquetes y el tráfico recogido es el correcto:



Y bueno hasta aquí sería todo. Espero que os sea útil.


Comentar un par de puntos por si a alguien le salta la duda:
  • En Sistemas GNU/Linux es exactamente igual, solo que hay que descargar la herramienta con extensión Perl.
  • Es posible realizar Copy&Paste de la salida en pantalla que nos muestra la consola CLI directamente desde la Webgui y pegarla en un archivo TXT y pasarle el conversor.
  • En las versiones 6.0 y superiores de FortiOS, han implementado la opción de "Packet capture" independientemente de si tiene disco físico o no, pero por si acaso, siempre viene bien tener esta herramienta.
  • En esta entrada se ha utilizado el Visor de tráfico Wireshark, pero se puede utilizar cualquier otro como NetworkMiner.
Cualquier duda o sugerencia, podéis dejarla en la caja de comentarios.

Nos vemos en el próximo artículo.

Saludos!

rekkatz

miércoles, 31 de julio de 2019

Buscando la dirección lP real detrás de Cloudflare





¡Buenas lectores!


En esta entrada os quiero hablar sobre cómo encontrar la IP real del servidor detrás de Cloudflare.

Cuando se realiza una auditoria denominada Black Box o Caja Negra, la información que se nos proporciona para poder llevar a cabo esta, es mínima, es por eso que tenemos que desplegar nuestro arsenal de herramientas para poder encontrar información útil que nos pueda servir para realizar el Pentest.

En este caso, la dirección IP real utilizando la primera etapa de la auditoría o pentest “Footprinting”.

Para ponernos en contexto, vamos a comentar de forma resumida que es Cloudflare.


¿Qué es y cómo actúa Cloudflare?


Cloudflare es un servicio que realiza la labor de intermediario entre los sitios web en línea y los usuarios finales o visitantes que intenten acceder a estos sitios web. Esto permite la protección ante ataques web, protección ante ataques DDoS, protección frente a inyección de código, protección perimetral, etc. 

Para entendernos, cuando un usuario intenta acceder a un sitio web, la solicitud no llega directamente al servidor web donde está alojado el sitio web, si no que intervienen los CDN de Cloudflare, que no son más que servidores DNS y Proxy Inverso los que reenvían el tráfico al servidor donde esté alojado el sitio web. 

De esta manera, la dirección IP que se muestra no es la auténtica del servidor web, si no la de los servidores intermediarios. 

Cloudflare permite proteger el sitio web mediante transferencia de los DNS originales del sitio, al DNS asignado por el servicio de Cloudflare.


Esquema de funcionamiento Cloudflare


¿Cómo saber si está detrás de Cloudflare?


Bueno, pero ¿cómo sabemos si realmente este servidor se encuentra detrás de la red de Cloudflare? 

Una forma rápida sería con la ejecución de Ping al sitio web a auditar y acceder a la dirección IP que nos resuelve: 


Ejecución de ping al sitio web a auditar

Como se puede observar al intentar acceder, nos devuelve código de Error 1003 de Cloudflare:

Error 1003 de Cloudflare al intentar acceder


Otra de las formas sería a través de herramientas web Checkforcloudflare, esta nos indica visualmente si pertenece el sitio web está utilizando Cloudflare o no:


Buscando la dirección IP real


Para buscar la dirección IP que se esconde detrás de Cloudflare, tenemos varias posibilidades que mostraré a continuación, en este caso mostraré la forma manual y en proximas entradas me centraré en herramientas automatizadas.


Certificados SSL


Si queremos obtener datos relacionados con los certificados que se encuentran en sitios web en línea, no podemos hablar de otra herramienta mejor que Censys, esta nos permite comprobar todos los certificados que se encuentran en Internet gracias a su base de datos, a parte también nos proporciona otros datos de interés relacionados.

Censys nos permite realizar búsquedas con operadores lógicos Booleanos, de esta forma podemos relacionar campos de una manera sencilla. (Uso de Queries Censys)

Una vez estemos en la web de Censys, seleccionaremos en la barra de búsqueda “Certificates”.


Para realizar una búsqueda correcta, añadiremos la siguiente query:

  • Certificados para el sitio a auditar: 
    • parsed.names: “Dominio”
  • Solo mostrar certificados válidos: 
    • tags.raw: trusted
Si esto lo juntamos con lógica booleana, nos devolverá los resultados que tengan el dominio indicado y un certificado válido: 

  • parsed.names: “dominio” and tags.raw: trusted

Resultado de búsqueda en Censys

Una vez que nos ha devuelto resultado, tendremos que entrar en cada uno de estos y seleccionar "Explore" en la esquina superior derecha y a su vez en "IPv4 Hosts".

De esta forma, se realizará la búsqueda de direcciones IPv4 a través del hash-256 del certificado.

Información de Sitio Web en Censys

Obtención de IP real a través de Censys
Podría ser la IP real del servidor, podemos probar a navegar directamente con la dirección IP y comprobar que nos muestra ¿redirige al sitio web? ¿muestra el sitio web correctamente con la dirección IP? 


Sitio Web y Cabeceras de correo


Aunque no lo creas, desde el propio sitio web del que queremos obtener la dirección IP, podemos obtener mucha información.

Si tenemos la oportunidad de inicializar el envío de un correo electrónico desde la página web (confirmación de registro, pedidos, suscripciones, tickets de soporte, contraseña olvidada, etc) hasta nuestro correo, existe la posibilidad de poder extraer la dirección IP real del servidor.

Para que la dirección IP sea correcta, hay que tener en cuenta que el servidor de correo de origen debe ser interno, es decir, que salga con la misma dirección IP que el sitio web, en el caso que sea un servidor de terceros o esté montado sobre otro servidor con otra dirección IP, no va a ser exactamente la dirección que buscamos... aunque nunca viene mal tenerlas para más investigación.

En el caso de la imagen siguiente, las direcciones IP son del mismo rango pero no exactamente la que quería, con lo cual tuve que subir/bajar el último octeto para conseguir la dirección IP real del sitio web.


Cabecera de correo con direcciones IP

Es posible que a la hora de intentar acceder a dichas direcciones IP con la barra de direcciones del navegador no podamos acceder.

Este método es posible que no funcione porque el servidor web estará configurado para ignorar las solicitudes que no contienen el nombre del host correspondiente o porque varios sitios están alojados en el mismo sitio web.


Podemos evadirlo con la herramienta CURL, esta nos permite enviar solicitudes con un encabezado personalizado con la opción –H:

  • curl -H "Host: HOST NAME" http://IP

Si queremos conectar a través HTTPS, tendremos que agregar la opción –K antes de la dirección IP, esta opción nos permite saltarnos el certificado.

  • curl -H "Host: HOST NAME" -k https://IP

Comprobaremos el código fuente HTML que nos devuelve y quien sabe, igual obtenemos algo más interesante…

Un truquillo para este método es enviar un correo a un destinatario falso pero que contenga el dominio correcto. Si el destinatario no existe, recibiremos un correo indicándonos que ha fallado la entrega, con lo cual tendremos un correo para investigar =P


Registros DNS y DIG


Los registros DNS también nos pueden aportar información muy valiosa, para eso tenemos la herramienta de SecurityTrails, la cual nos permite comprobar los históricos de los registros DNS antes de añadirse a la red Cloudflare. 


Tenemos 2 opciones:

Búsqueda por registros de tipo A


Buscamos el sitio web a auditar y nos dirigimos en el panel de la izquierda a “Historical Data”, de esta manera nos mostrará los registros de Tipo A y nos dirá directamente cual es la dirección IP real en caso de que esté almacenada.

Registros Tipo A con SecurityTrails


Búsqueda por registros NS


Como anteriormente, pero una vez estemos en “Historical Data”, hacemos click en “NS”.

Registros Tipo NS con SecurityTrails

Con los registros NS a mano, utilizaremos la herramienta DIG para que nos devuelva la dirección IP real del servidor:

  • dig @ns1.targetnameservers.com targetdomain.com

Netcraft


Netcraft es una herramienta web muy útil, la cual nos brinda información del sitio web que queremos auditar. Podemos visualizar el histórico de los servidores donde se ha ido alojando el Sitio Web, así como los Nameserver, Site Rank, etc. Como he comentado, información muy útil. 

De esta manera, podemos comprobar también el histórico de las direcciones IP antes de ser añadido al servicio de Cloudflare.

Para ello accedemos a Netcraft e introducimos el sitio web a auditar, directamente nos mostrará información relacionada con el sitio como se puede ver en la siguiente imagen.


Información útil del Sitio Web a auditar


Probando y confirmando


Cuando hemos obtenido la dirección IP pública real del servidor donde está alojado el sitio web, tenemos que probar que verdaderamente funciona, para ello tenemos 2 opciones de saltarnos los servidores de la red de Cloudflare:

Opción 1

Añadir directamente el domino/subdominio y la dirección IP al archivo hosts:

Añadir dirección IP y dominio al archivo Hosts


Opción 2

Si vamos a utilizar Burpsuite para la auditoria o pentest, es recomendable asignar una resolución de nombre manual, de esta forma anularemos el reenvío hacia los servidores de Cloudflare y resolverá con la dirección IP añadida. Para ello:

Resolución de nombre en Burpsuite


Conclusiones


Hay que tener en cuenta que ninguno de los métodos mostrados aquí es 100% fiable, es posible que a mi me sirva, pero a alguno de vosotros no. Lo mejor que se puede hacer es probar todos los métodos e investigar hasta conseguir la dirección IP correcta.

Cabe mencionar que la exposición de la direccion IP real del servidor, no se trata de ninguna vulnerabilidad de Cloudflare, más bien son fallos de configuración de los administradores del Sitio Web, exponiendo dominios o subdominios que no han sido añadidos correctamente al servicio de Cloudflare.

Como hemos podido observar, lo más importante en la primera fase de auditoría o Pentest, es la recolección de información, obtener direcciones IP de todo tipo para más tarde ir comprobando y descartando. 

Los servidores DNS siempre deben estar en el punto de mira ya que nos pueden mostrar información histórica y que siempre estará disponible en Internet.

Aquí abajo os dejo unas cuantas herramientas para la recopilación de información de Sitios Web, así como enumeración de subdominios, servicios, etc:


Existen muchos otros métodos de detección, si alguno de vosotros quiere dejar un comentario con el que mejor le sirve en su día a día se lo agradecería =D

Nos vemos en el próximo artículo.

Saludos!

rekkatz


Referencias: