PFSense: Cómo configurar tu propio IDS & IPS con Suricata

Hemos hablado anteriormente en el blog sobre PFSense y algunas posibilidades interesantes que ofrece este tipo de software. Vimos cómo montar una VPN con PFSense y las posibilidades que PFSense ofrecía y lo fácil que es disponer de un servidor de VPN para fortificar las comunicaciones. Como se comentó en esos artículos PFSense ofrece muchas más posibilidades. En el artículo hoy, hablaremos sobre cómo montar un IDS e IPS para poder generar alertas y bloquear conexiones que puedan ser maliciosas.

Figura 1: PFSense: Cómo configurar tu propio IDS & IPS con Suricata

Suricata es un motor de detección de amenazas haciendo las funciones de IDS y de IPS. También podemos encontrar Snort dentro de PFSense para su instalación, aunque el ejemplo de hoy nos centraremos en Suricata.

 

Figura 2: Libro de Ethical Hacking 2ª Edición
de Pablo González en 0xWord

Primero comenzaremos con ver cómo instalamos Suricata en PFSense. Para ello, dentro del panel de PFSense podemos ir al apartado System y encontraremos la opción ‘Package Manager’. El gestor de paquetes nos permite ver qué tenemos instalados en PFSense y que podemos instalar a través de un panel de búsqueda.

Figura 3: Package Manager en System

Como se puede ver en la siguiente imagen, si buscamos la palabra ‘suri’ o ‘suricata’ nos aparece un paquete con la versión correspondiente para su instalación. Solamente debemos pulsar en ‘Install’ para añadir la funcionalidad a nuestro PFSense. La gestión y configuración de Suricata se hará desde el propio panel de PFSense.

Figura 4: Paquete de Suricata

Como se puede ver en las imágenes de la Figura 4 y Figura 5, una vez pulsamos en instalar vamos a ver cómo el proceso nos muestra una salida de terminal y vamos viendo cómo se lleva a cabo la instalación de Suricata sobre nuestro PFSense.

Figura 5: Instalación de Suricata

    

Una vez instalado, en el apartado de Servicios de PFSense vamos a encontrar Suricata instalado. Hay una serie de apartados que iremos tratando durante el artículo. A continuación, enumeramos algunos:

Figura 6: La lista de módulos de Suricata

• Interfaces: En este apartado vamos a poder configurar sobre qué interfaz o interfaces queremos habilitar el IDS & IPS.

• Global Settings: En este apartado configuraremos los parámetros necesarios para indicar qué conjunto de reglas y de donde se actualizarán éstas utilizará Suricata. Es necesario entender que Suricata utiliza reglas que en el caso de que las comunicaciones hagan ‘match’ se activará una alerta para notificar (vía email si tiene el suficiente grado de relevancia u otros métodos configurables) o, incluso, bloquear la dirección IP que originó la alerta (es decir, la comunicación). La detección y el bloqueo son partes fundamentales de Suricata, las que le hacen tener funciones de IDS y de IPS.

• Updates: Esta pestaña es importante, debido a que la actualización de la base de datos de reglas y otros elementos se llevarán a cabo desde esta funcionalidad,

• Alerts: Esta función permite visualizar y filtrar la información sobre las alertas. El volumen de alertas puede ser alto, por lo que será interesante manejar el filtro de éstas a través de diferentes parámetros de búsqueda. En las alertas, podemos ver qué tipo de regla ha provocado el match y la notificación.

• Blocks: Esta pestaña muestra las direcciones IP y comunicaciones que han sido bloqueadas. En esta pestaña se puede gestionar la eliminación de direcciones IP bloqueadas por error (falso positivo).

• Pass lists: Se define en este apartado las direcciones IP que se quieren ‘bypassear’. Si tenemos algunas direcciones IP que bajo ningún concepto queremos que queden bloqueadas por Suricata podemos configurarlo aquí. Es un paso fundamental para las empresas, ya que se tienen direcciones IP que deben estar dadas de alta en este apartado.

• Logs View: Esta vista nos permite visualizar los logs y realizar búsqueda sobre ellos.

Cuando entramos en Global Settings, deberemos configurar gran parte de la configuración de Suricata. Si nos fijamos en las posibles configuraciones, vamos a encontrar muchas opciones. Debemos indicar de dónde vendrán las reglas, de dónde las descargaremos y cómo llevaremos a cabo las actualizaciones.

Figura 7: Configuración de Global Settings

Es normal, que nos pidan una cuenta de Snort para configurar el catálogo de reglas. Hay diferentes fuentes de datos para las reglas, pero una opción son las reglas ‘free’ de Snort, tal como se puede ver en la imagen (hay un vínculo). Para actualizar y descargar reglas podemos necesitar un Oinkcode, el cual se puede encontrar dentro de la cuenta de snort (que se puede hacer de forma gratuita). Este Oinkcode no es más que una API Key para poder acceder al catálogo de reglas y utilizarlo en las actualizaciones de éstas.

Figura 8: Intervalo de actualizaciones

Como se puede ver en la imagen, se debe indicar el rango o intervalo de actualización. Por defecto viene el parámetro NEVER, no recomendable, y mejor que haya una comprobación de actualización cada ‘x’ días o ‘x’ horas. Además, también debemos indicar si los equipos bloqueados se desbloquean a las ‘x’ horas o nunca. La elección de gestión de las defensas contra los ataques de redes es fundamental, pues una mala elección puede resultar en una D.o.S. del sistema.

Figura 9: Ataques en redes de datos IPv4&IPv6 (4ª Edición) de

JL. Rambla, ampliado y revisado por Pablo González y Chema Alonso

Por defecto viene NEVER, pero ya es cuestión de cada administrador decidir si se configura un rango o no. Quizá una buena estrategia sea no desbloquear automáticamente o dar un rango amplio de tiempo de bloqueo y tener la lista blanca de direcciones IP de la empresa que bajo ningún concepto deben ser bloqueadas (opción de Pass List).

Figura 10: Módulo de Alertas

En la vista de Alertas vemos cómo tenemos un filtro para poder realizar búsquedas avanzadas sobre las alertas, que pueden alcanzar un volumen alto, ya que la base de datos de reglas es muy extensa o puede serla.

¿Cómo ponemos en funcionamiento Suricata?

En la pestaña interfaces debemos darle al botón ‘Añadir’ e indicar la interfaz por la cual queremos ejecutarlo. Cuando hagamos esto, nos saldrá una pantalla como la que se puede ver a continuación. Se puede ver fácilmente que habilitamos Suricata en la interfaz WAN de Suricata.

Figura 11: Activando Suricata y Logs

Disponemos de una serie de opciones de logging, lo cual es importante pensar bien cómo configurarlo y el qué, ya que cuanta más información tengamos sobre el funcionamiento de los servicios y lo que está ocurriendo será mejor para identificar ciertos incidentes.

Figura 12: Configuración de Bloqueo

Para la parte de bloqueo también veremos un apartado, el cual debemos activar a través de la línea “Checking this option will automatically…”. Bien, debemos indicar el IPS Mode, por ejemplo, con Legacy Mode. En el caso del bloqueo debemos seleccionar el tipo de conexión, si solo queremos bloquear dirección IP origen o cómo queremos hacerlo.

Figura 13: Arrancando Suricata

Una vez configurada esta parte, debemos arrancar Suricata quedando como se puede ver en la siguiente imagen (en el apartado Interfaces). La interfaz WAN queda protegida con Suricata en modo IDS e IPS. Se recomienda estudiar y profundizar más sobre el tema de reglas, el funcionamiento interno del IDS y el modo de bloqueo ‘Legacy Mode’. Hay mucha documentación que se puede ojear.

Un ejemplo de regla y bloqueo sencillo     

A continuación, vamos a ver un ejemplo de alerta y veremos cuál es la regla que ha provocado la notificación. Las reglas son Snort puro, por lo que recomendamos echar un ojo a esta documentación.

Figura 14: Información de la regla

Respecto al bloqueo, aquí tenemos una imagen donde se puede ver un ejemplo de cómo actúa. Desde la pestaña ‘Blocks’ se puede hacer uso de la gestión de direcciones IP bloqueadas y tomar decisiones, pero sobre todo entender por qué fue bloqueada dicha dirección IP. Esto es algo fundamental para la toma de decisiones y sobre lo que puede estar sucediendo.

Figura 15: Alertas producidas por la regla

Con esto llegamos al final del artículo, en un futuro podemos jugar con situaciones que Suricata puede detectar y alertar, y ver algunos ejemplos más profundos. Si eres nuevo en ese mundo, recomendamos montar máquinas virtuales, montarte un laboratorio y practicar y jugar con este software Open Source y con las posibilidades que aporta.

Saludos,

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell” y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.  Para consultas puedes usar el Buzón Público para contactar con Pablo González

Contactar con Pablo González

PFSense: Un all-in-one con Fiewall, IPS, IDS, VPN y Proxy para fortificar tu red

La seguridad para evitar los Ataques en redes de datos IPv4 e IPv6, es uno de los campos más importantes  dentro de la fortificación de sistemas, ya que necesita de diferentes elementos para mejorar la protección. Elementos como un Firewall, un Sistema de Detección de Intrusiones (IDS), un Sistema de Prevención de Intrusiones (IPS), un Servidor de Redes Privadas Virtuales (VPN), un Proxy, etcétera. Estos elementos copan las redes de las organizaciones y son fundamentales para mantener la seguridad de la red.

Figura 1: PFSense - Un all-in-one con Fiewall, IPS, IDS,

VPN y Proxy para fortificar tu red

Las PYMEs también requieren de seguridad en red y es por esto que las soluciones all-in-one que se pueden encontrar pueden ayudarlas, y mucho, en fortificar su red y evitar que las amenazas del mundo digital se aprovechen de ellas. Ya sabemos que las PYMES son eslabones un poco más débiles, sobre todo cuando no hay conocimiento o concienciación sobre las amenazas del entorno. Para ellas la inversión en seguridad puede suponer un quebradero de cabeza y por esta razón soluciones como las denominadas all-in-one y similares pueden ser importantes.

Figura 2: Ataques en redes de datos IPv4&IPv6 (4ª Edición) de

JL. Rambla, ampliado y revisado por Pablo González y Chema Alonso

En el artículo de hoy, hablaremos de PFSense y de un uso básico en la que a su firewall permite. Una forma sencilla, a través de una GUI de gestionar un firewall. No hace falta aprender el listado de opciones de iptables, que siempre es recomendable de aprender y conocer cómo funciona este mundo por debajo. Además, puedes aprender sobre iptables en el libro de Hardening de servidores GNU/Linux de 0xWord.

¿Qué es PFSense?

Lo primero que hay que indicar es que es una distribución que permite configurar una máquina como router y firewall, en primer lugar. Hay que indicar que aporta un gran número de servicios, la mayoría relacionados con la securización de la red. Desde disponer de servicios básicos de red para la organización como la implementación de un DHCP o un DNS hasta la posibilidad de montar un servidor VPN o una IPSec en el propio endpoint de PFSense.

Figura 3: Libro de Hardening de Servidores GNU/Linux 4ª Edición

(Revisada y Ampliada) de Carlos Álvarez y Pablo González en 0xWord

Funcionalidades como el despliegue de un Proxy, de un IDS o incluso de utilizar un AV para evaluar cierto tráfico es posible también con este all-in-one. En el artículo de hoy vamos a tratar la configuración básica de un entorno con PFSense y vamos a utilizar la parte básica del firewall.

Entorno de prueba de PFSense

Para conocer más sobre las posibilidades de este entorno vamos a proponer un escenario. A continuación, los elementos con los que vamos a jugar en esta pequeña prueba:

• PFSense: Máquina con la distro de PFSense. Tendrá tantas interfaces de red como redes queramos segmentar y definir. En este caso tendremos una red interna y una red externa (la externa simula Internet). Si quisiéramos simular un entorno: Internet, DMZ y red interna meteríamos tres interfaces de red sobre PFSense.

• Una máquina en la red Internet (con dirección IP 11.0.0.7).
• Una máquina en la red interna (con dirección IP 10.0.0.2).
• Las interfaces de red de PFSense serán 10.0.0.1 y 11.0.0.1.

Figura 4: Configuración de los interfaces de PFSense

En la imagen anterior se pueden ver las configuraciones de las dos interfaces de PFSense. Hay que tener en cuenta que, tras la instalación de PFSense, hay que definir las interfaces de red e indicar cuál es LAN y cual es WAN. WAN será la interfaz conectada con Internet directamente. LAN será la interfaz que refleja la parte conectada con la red interna. También podemos jugar con DMZ. Una vez instalado el entorno, observamos una pantalla dónde disponemos de diferentes opciones, entre otras:

• Asignación de interfaces.
• Configuración de una nueva interfaz.
• Diferentes formas de resetear el sistema.
• Visualización y filtrado de logs.
• Reinicio y apagado del sistema.

Figura 5: Opciones de configuración de PFSense

Si conectamos a través de un navegador web por la interfaz de red de la red interna podemos acceder al panel control web de PFSense. Desde ahí vamos a poder gestionar de manera más sencilla todo lo que se puede hacer desde la herramienta. Si vemos el menú superior podemos encontrar diferentes posibilidades:

• Ver información del sistema, versión, actualizaciones, etcétera.
• Configuración de interfaces.
• Configuración del firewall. Como se puede ver en la imagen todas las opciones que proporciona PFSense: VLANes, NAT, reglas, programación, etcétera.
• Servicios de red: DNS, DHCP, Wake-on-LAN, portal cautivo, etcétera.
• Configuración de la VPN: IPSec, L2TP y OpenVPN.
• Monitorización de los servicios.

Figura 6: Opciones de configuración del Firewall

Las posibilidades sobre PFSense son muchas. Además, existe un market dónde se pueden ampliar funcionalidades, como se comentó anteriormente.

 
Ejemplo 1: Haciendo PING desde red interna a Internet

Como primer ejemplo y entendiendo que en principio PFSense va a bloquear cualquier tráfico que circula entre la máquina situada en una red y en otra, vamos a ver cómo crear reglas en la máquina.

El punto de partida es que la máquina 10.0.0.2 (la que se encuentra en red interna) no puede hacer PING (ICMP) con la máquina de Internet. La política por defecto del Firewall es DROP, ya sea en NAT, ya sea en Filtering. Es decir, se deniega el paso de los paquetes a través del Firewall, salvo que haya alguna regla que indique lo contrario. Ahora nos tocará crear esas reglas.

Figura 7: Ping capturado por una regla DROP

Necesitamos crear una regla para permitir que la petición de PING (ICMP) salga de la red interna a la externa. Si nos fijamos en la siguiente imagen se va a ver que es sencillo indicar la acción (dejar pasar), la interfaz por la que llega el paquete (LAN), la interfaz por la que saldrá el paquete (WAN), el protocolo (ICMP) y el subtipo de mensaje (en este caso un ICMP echo request).

Figura 8:  Configuración de la regla para dejar pasar el Echo Request

En otras palabras, solo permitiremos que salgan los echo request de ICMP. La idea es que desde fuera (Internet) no puedan pasar el Firewall y hacer un PING (ICMP) a una máquina de la red interna, por lo que un echo reply no debe pasar de la LAN a la WAN. Ahora hay que configurar la regla contraria: desde la WAN debemos dejar pasar los ICMP con el tipo de mensaje echo reply.

Figura 9: Y ahora lo mismo desde el interfaz WAN

Todo lo trabajamos en la interfaz WAN, ya que LAN tiene una regla por defecto que es dejar pasar cualquier protocolo de arquitectura TCP/IP, por lo que las reglas se aplicarán en la interfaz WAN.

Este es un ejemplo con PFSense de lo que uno se puede montar en casa o en entornos laborales pequeños o medianos. Poco a poco iremos viendo algunos ejemplos más, donde se añadirá, por ejemplo, una red DMZ con servicios e iremos acercándonos a un entorno más real. Si quieres aprender sobre seguridad en redes, monta tu laboratorio con máquinas virtual.

Saludos,

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell” y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.  Para consultas puedes usar el Buzón Público para contactar con Pablo González

Contactar con Pablo González

OSSEC: El mundo del IDS (Intrusion Detection System) y del HIDS (Host IDS)

OSSEC es una plataforma de monitorización y detección de intrusos de código abierto. Está basado en host, es lo que llamaríamos un HIDS o sistema de detección de intrusos en host. ¿Por qué escribir de OSSEC? Hay muchas soluciones antiguas o de las llamadas con experiencia o estables que para mucha gente son desconocidas. Es esa seguridad que nos protege, que detecta las intrusiones y que, aunque los años pasen siguen ahí. 

Figura 1: OSSEC: El mundo del IDS (Intrusion Detection System) y del  HIDS (Host IDS)

La última versión estable de OSSEC data de abril de 2019 y es una solución programada en Lenguaje C, un lenguaje de programación muy especial y muy relacionado con los sistemas operativos. Podemos decir que OSSEC opera como un SIM (Security Incident Management). Su función es la de analizar registros de eventos del sistema operativo, hacer comprobaciones de la integridad de los archivos del sistema de ficheros, auditar los registros de los equipos, detectar rootkits o dar respuesta activa y alertar en tiempo real.

Figura 2: GitHub de OSSEC

OSSEC es un software bastante adaptable y proporciona muchos quehaceres en la seguridad defensiva. El proyecto surgió en 2008 y en 2009 TrendMicro lo adquiere, eso sí, con la promesa de mantenerlo en Open Source. El GitHub del proyecto sigue estando abierto para que cualquiera pueda aportar a este proyecto. Detrás hay un gran número de colaboradores y programadores.

Instalación de OSSEC

La instalación se puede realizar a través de la web de https://www.ossec.net. En el apartado “Documentation” tenemos la información referente a la instalación. La instalación puede hacerse en una gran diversidad de sistemas operativos. OSSEC dispone de varias partes en su arquitectura que hay que entender para hacer el proceso correctamente.

Figura 3: Comienzo de proceso de instalación

Principalmente, tenemos un servidor que centralizará la operativa. A este servidor le podemos poner una interfaz gráfica que permite gestionar las diferentes acciones de forma más cómoda.  Además, tenemos los agentes que son herramientas que permiten recopilar la información de las máquinas remotas y enviarlas al servidor para su gestión. Toda esta información se puede encontrar en la web de OSSEC. 

Figura 4: Configuración de ficheros de log a analizar

La instalación nos devolverá todo lo necesario instalado, por defecto, en la ruta /var/ossec. A partir de aquí dispondremos de un gran número de posibilidades. Hay que pensar que OSSEC dispone de binarios encargados de la recopilación de información, del análisis, de la monitorización, del chequeo de integridad en el sistema de archivos, etcétera.

Figura 5: Finalización de la instalación

Cuando finaliza la instalación debemos ver que en la ruta /var/ossec/bin encontraremos un gran número de binarios que proporcionan todo el potencial de la herramienta. Así como en /var/ossec/etc podremos encontrar el fichero de configuración de OSSEC.

Figura 6: Arranque y comprobación del estado del servicio de OSSEC

Si queremos arrancar OSSEC podemos hacer uso del binario ossec-control con la opción “start”. Con la opción “status” podemos ver todo lo que tenemos al alcance y estamos ejecutando. Podemos instalar la solución OSSEC-WUI para poder hacer uso de Apache y PHP y poder ejecutar una interfaz gráfica que proporcione lo necesario para poder gestionar desde un entorno más amigable.

¿Dónde están las cosas?

- /bin y /etc: Son carpetas que lo dicen todo con su nombre. En la primera encontraremos los binarios de OSSEC. En la segunda veremos los ficheros de configuración. 

 

- /logs: Aquí encontraremos los logs: ossec.log y alerts/alerts.log. 

 

- /rules: En este directorio se almacenan las reglas que son utilizadas para generar alertas. 

 

- /stats: Directorio donde se generan estadísticas.

¿Cómo es el fichero de configuración?

En /var/ossec/etc/ossec.conf encontraremos el fichero de configuración. Es un fichero que se divide en diferentes partes o directivas.

- Global: Es un apartado global donde se puede configurar el servicio del SMTP para notificar las alertas. 

 

- Rules. Es una directiva donde se “incluyen” los ficheros con las reglas de detección. Estas reglas están escritas en ficheros XML. 

 

- Active-response: Esta directiva muestra las diferentes respuestas activas que tiene OSSEC configuradas por defecto. Se puede configurar cómo se quiere responder ante un tipo de evento generado. 

Figura 7: Configuración de active-response

- Localfiles: Esta directiva indica los ficheros a monitorizar y analizar. Son los ficheros de log del sistema. Esta es la sección del “collector”.

Figura 8: Configuración de localfile

- Syscheck: Este apartado configura cómo trabajará el monitoreo sobre el sistema, así como los directorios y ficheros que serán chequeados para ver los posibles cambios o alteraciones. Esto es importante, ya que ante una intrusión puede haber carpetas que cambien en lo que a permisos se refiere, puede haber ficheros que son alterados en su contenido, etcétera. Otra herramienta interesante en este campo es tripwire, pero esa la dejamos para otro momento. 

Instalando un agente en GNU/Linux

La instalación de un agente de OSSEC en GNU/Linux como una herramienta de fortificación es sencilla. Hay que hacer uso del binario /var/ossec/bin/manage_agents. Desde esta herramienta se llevará a cabo una doble operativa:

- El servidor, dónde hemos instalado OSSEC, tiene una key que debemos extraer para proporcionársela al cliente (o agente). 

 

- El agente debe añadir esa key desde la herramienta manage_agents. 

Lo primero es que desde manage_agents en el servidor añadir un agent y le asignamos un ID, por ejemplo, 001. Con 001 nos devolverán una key bastante larga. Esa key hay que hacerla llegar a la máquina GNU/Linux en la que queremos instalar el agente.  Ejecutamos manage_agents en la máquina GNU/Linux cliente.

Figura 9: Configuración del agente

En esta máquina solo obtendremos dos opciones: importar una clave de servidor o salir. Al darle a importar obtendremos información sobre el propio agente, esa info viene en la propia clave. Una vez hecho esto, tendremos al agente recopilando información y enviándola a OSSEC. Si disponemos de OSSEC-WUI instalado en la máquina del servidor, podremos empezar a ver los logs remotos que están llegando.

Figura 10: Libros de Linux Exploiting y de Hardening de Servidores GNU/Linux

OSSEC una herramienta con mucho potencial para la Fortificación de sistemas GNU/Linux que se puede descubrir a través del uso de máquinas virtuales en un laboratorio y que, si te dedicas a la ciberseguridad, debes conocer. El mundo de los IDS es apasionante, y no todo son los IDS de red o NIDS, también hay que ocuparse de los HIDS. 

Saludos,

Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell”, "Pentesting con Kali Silver Edition" y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.  Para consultas puedes usar el Buzón Público para contactar con Pablo González - Conseguir 100 Tempos Gratis en MyPublicInbox

 Contactar con Pablo González

Evadiendo el AV/IDS con Powershell: Fun with Flags! (wrong!) Fun with Meterpreter!

He podido disfrutar de unas pequeñas vacaciones y mientras uno tiene horas de avión puede aprovechar para pensar en cosas. En ocasiones las cosas en las que se piensan son la parte de hobby de la que para muchos de nosotros es también nuestro trabajo. En esas horas de avión pensé en varias cosas, quizá algunas las veáis en un tiempo, pero también hay oportunidad de leer. A mí me gusta leer cosas sobre mis pasiones tecnológicas como son el Ethical Hacking, Powershell, Metasploit, Payloads avanzados, evasión, y un largo etcétera de conceptos y técnicas que son de mi interés.

Figura 1: Evadiendo el AV/IDS con Powershell: Fun with Flags! (wrong!) Fun with Meterpreter!

De lo que hoy voy a hablar no es una técnica nueva, ni mucho menos, ya que la podemos encontrar hace dos años, pero este tipo de técnicas o "tricks" que van saliendo son la forma de evasión de los elementos de seguridad. En algunas ocasiones, la gente piensa que la evasión es perpetua y se debe entender que es la caza del gato y el ratón, tal y como ocurre con el malware y los antivirus o los exploits y las soluciones de protección ante ejecución de código. En este artículo se habla de esta técnica, la cual es bastante interesante para entender el juego del gato y del ratón en este ámbito.

Figura 2: AV/IDS Evasion with Powershell

Lo normal, es encontrar una gran cantidad de información sobre evasión de antivirus para la parte del stager, por ejemplo, técnicas de codificación, cifrado o, incluso, realizando la compilación de una versión propia del ejecutable que contiene la shellcode. Esto es relativamente sencillo hoy en día con Python, Ruby, generar macros VBA o, incluso, crear un pequeño código en Powershell.

De lo que uno encuentra menos son artículos o posts centrados en la evasión de soluciones de seguridad como un IDS o un IPS. Si analizamos dónde ocurre la acción hay que entender que el proceso del stager ocurre en memoria y el stager es inyectado en ella. Es decir, todo ocurre en la memoria, por lo que los antivirus ‘sufren’ más para poder hacer algo. La DLL que se inyecta no tocará el disco. Sobre técnicas de evasión escribimos Borja Merino y yo en el libro de Hacking con Metasploit de 0xWord.

¿Qué ocurre en un entorno corporativo?

Aquí tenemos más soluciones de seguridad. Podemos encontrar un IDS, un IPS, un Proxy Web que analice el tráfico, etcétera. Aquí la evasión puede ser más costosa. Esta es una lista de elementos de seguridad que hay que tener en cuenta en un entorno corporativo:

• Proxy web con interceptación SSL (Bridging HTTP-s)

• IPS (Intrusion Prevention System)

• IDS (Intrusion Detection System)

• Antivirus en hosts (Servers & endpoints)

Al menos, esto sería algo normal, básico en un entorno. Los canales TLS/SSL no valdrían según el esquema anterior, porque se tiene la capacidad de ver el contenido de la comunicación. El antivirus en los hosts e, incluso, en el Proxy permitiría analizar parte o totalidad del tráfico. Los IDS/IPS con firmas conocidas o asociadas al Meterpreter.

Figura 3: Esquema de seguridad en entorno corporativo

Entonces tenemos un objetivo claro, evadir esto. Lo cual puede no ser sencillo y debemos entender que es un problema temporal, puede haber técnicas de evasión que funcionen bien en un momento determinado o contra unas soluciones determinadas. Pero es temporal, ya que es el juego del gato y el ratón. En un momento determinado hay una técnica que permite evadir diferentes mecanismos, pero cuando se conoce, los proveedores pondrán mitigación para solventar este hecho. Así de forma iterativa.

El objetivo y el desafío

El objetivo está claro, como he dicho, es evadir estos mecanismos para lograr la comunicación y ejecución del stager. El desafío podemos verlo en diferentes puntos. El stager utilizará el Proxy en caso de que haya un Proxy en la organización. Para ello, debe poder detectarlo y utilizar el que esté configurado en la máquina. El stager debe ser ofuscado de tal forma que evite al AV, al IDS y la detección del Proxy.

Metasploit proporciona una serie de payloads que son compatibles con lo que se necesita. Ofrece varias. Una que se puede utilizar en estos escenarios es meterpreter/reverse_winhttp. Este Meterpreter permite utilizar el Proxy del sistema, utilizar las credenciales del Proxy y poder ofuscar el código con stage_encoder.

Figura 4: Libro de Metasploit para Pentesters 4ª Edición & Hacking con Metasploit en 0xWord

Antes de continuar, una aclaración con Meterpreter. Hay que recordar que Meterpreter es un payload de Metasploit, el cual es ejecutado en una máquina a través de un stager de tamaño pequeño. Éste se ejecuta en el equipo y se establece una comunicación con la máquina del atacante para descargar un stage payload, el cual será una DLL que es cargada en memoria y ejecutada a través de la técnica Reflective DLL.

Una de las vías que abre el mundo de la evasión es el siguiente: se trata de identificar payloads de Metepreter que disponen de la posibilidad de detectar servidores Proxy, utilizar credenciales de estos y disponer de la posibilidad de ‘encoder’. Anteriormente comenté reverse_winhttp, por lo que se puede hacer uno propio tomando como base éste u otros tipos que permitan las características anteriores. Quizá sea lo más inteligente, pero también lo más complejo.

Una idea "tonta"

El investigador Arno, propuso una técnica sencilla en el artículo de la Figura 2 y que vale para algunas configuraciones corporativas. Es una técnica que él mismo calificó de ‘tonta’, pero lo importante es ver que hay que probar diferentes ideas y ver cuáles pueden funcionar y cuáles no. Como se puede ver en ese artículo, lo importante es que los pequeños tricks que van saliendo día a día pueden ayudarte en tu Ethical Hacking.

Figura 5: Script con SecureRandom

Lo que hizo el investigador fue añadir un número aleatorio de bytes al comienzo del stage que es enviada de vuelta. Metiendo 64 KB al principio del stage conseguía engañar al antivirus, aunque esto siempre es un proceso prueba y error. Para hacer esto modificó el fichero meterpreter_loader.rb. Hay que tener en cuenta que hay que añadir una librería nativa de Ruby, la cual puede instalarse con ‘gem install rubysl-securerandom’.

Figura 6: Script con el código en PowerShell

Además, se modifica el código añadiendo, justo antes de meter la DLL, la variable randomData. Ahí se generan los 64KB aleatorios y luego se concatena el código de la DLL. Se publicó un ejemplo de script en Powershell para simplificar el proceso. Este script genera dos hilos. A continuación, se explica qué es lo que hace:

1. El hilo 1 inicia un Proxy HTTP que escucha en la interfaz de loopback en el puerto 8080. 

2. El hilo 2 carga y ejecuta en memoria un Meterpreter reverse_winhttp configurado para conectarse al Local Proxy. Es decir, la configuración es LHOST apuntando a 127.0.0.1 y LPORT apuntando al 8080. 

3. El Local Proxy del hilo 1, está configurado para conectarse al C&C, utilizando la configuración determinada del servicio Proxy y, si fuera necesario, utilizar autenticación NTLM. 

4. Cuando se ejecuta el stager de Meterpreter en el hilo 2, lo primero que se solicita es la DLL. 

5. Dicha solicitud pasará por el Local Proxy, el del hilo 1, el cual se encarga de transmitir la solicitud al C2, a través del proxy corporativo. Además, se encarga de eliminar los 64 KB de datos aleatorios. 

6. Desde este punto, toda comunicación entre el Meterpreter y el C2 pasa por el proxy local sin modificar.

A continuación, se puede ver el código dónde se invocan los dos hilos comentados anteriormente en el código.

Figura 7: Lanzamiento de ambos hilos en el código de Powershell

De nuevo comento que la técnica no es nueva y que es un trick válido para algunos escenarios corporativos. Lo importante es entender que este tipo de técnicas van saliendo y se van descubriendo, en muchos casos, con prueba y error el hecho de evadir un IDS o un IPS o algunas de las complejas soluciones de seguridad que existen en ciertas entidades. Puedes encontrar más cosas de evasión en el libro de Hacking con Metasploit.

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advance Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDO de Telefónica.

SAPPO: Spear APPs to steal OAuth-tokens (4 de 4)

Para la última parte de esta serie podemos hacer exactamente el mismo ataque que hemos visto en el caso anterior pero ahora contra una cuenta de Windows Live. Para ello podríamos utilizar la misma App que creamos inicialmente o crear otra distinta, y podríamos usar el mismo correo electrónico con ingeniería social o distinto, pero deberemos cambiar la SCOPE_LIST del correo de petición de permisos para adecuarlos a los disponibles en Windows Live, que son distintos a los que existen en Office 365.

Figura 30: Atacando cuentas de Windows Live

Una vez que la víctima decidiera aceptar dar permisos a la app "besar al sappo" con un clic en YES, nuestra plataforma recibiría un AccessToken que le permitiría invocar la API de Windows Live para acceder a todos los recursos concedidos. Como se puede ver, en la implementación existente a día de hoy en Windows Live no se permite - aún - acceder al correo electrónico, aunque sí que existen los SCOPES definidos para ello. Actualmente, están en un proceso de migración que todavía no han concluido y en el que pronto dejarán disponible el acceso para todos los buzones.

Figura 31: Un AccessToken válido para una cuenta de Windows Live en Sappo

Desde nuestra plataforma es posible, sin embargo, hacer uso de otras APIs, como acceder a los contactos o al servicio de almacenamiento de ficheros OneDrive. Como parte de la PoC hemos implementado el acceso a OneDrive de forma gráfica, así que basta con hacer clic en el botón de OneDrive y acceder a la estructura de documentos contenida.

Figura 32: Accediendo a los documentos de las carpetas de OneDrive

Allí se pueden descargar todos los ficheros, navegar por las carpetas para ir buscando documentación e, incluso, lanzar consultas de búsquedas de palabras dentro de documentos, lo que ayudaría a encontrar la información de forma mucho más dirigida.

Figura 33: Con la API de OneDrive en Windows Live se pueden buscar docs

Al igual que en el caso de Microsoft Office365, en Windows Live es posible ver los permisos concedidos a las apps. En este caso, además es posible ver en detalle todos los permisos que se han concedido. Hay que ir a la zona de Aplicaciones y Servicios y allí estará la app.

Figura 34: Lista de Apps con permisos concedidos

Y si hacemos clic en detalles podremos ver la lista detallada de todos los permisos que se han concedido a esta app.

Figura 35: Lista de permisos concedidos a esta app

Dependiendo de cuál sea el IDP las funciones que se podrían realizar con este tipo de Apps maliciosas cambiará, pero al final el concepto es siempre el mismo. Conseguir un AccessToken para una serie de SCOPES e implementar el acceso.

Ask the Experts

Como hemos venido contando a lo largo de la serie, al final el gran problema es que hemos estado entrenando a los usuarios a detectar un tipo de ataque de phishing muy concreto en el que se solicitan las credenciales a través de una página web alojada en un servidor hackeado o falso en el que no se identifica de forma correcta el dominio del sitio, pero todas estas recomendaciones fallan cuando hablamos de un ataque de Spear App.

Figura 36: Pregunta a los expertos }:)

Cuando el usuario tiene que dar clic en YES - besar al sappo - lo hace en el sitio web original de Microsoft. Está en el dominio Microsoft.com, está bajo una conexión HTTPs, con un Certificado Digital de Validación Extendida - verde - que es correcto y pertenece a Microsoft, y además nunca se está solicitando ningún usuario ni contraseña.

Figura 37: La URL está dentro de Microsoft.com siempre

Además de todo eso, el filtro AntiPhishing implementado en el navegador tampoco puede detectar nada ya que la URL en la que se está es la correcta de Microsoft, y no va a bloquearla.  Hay que entrenar a los usuarios para detectar este tipo de ataques con Spear Apps, además de entrenarlos para detectar el Spear Phishing.

Soluciones: Awarenes & Cloud Analytics

Como posibles contramedidas a estas soluciones se presentan varias alternativas. Por supuesto, reforzar las tecnologías AntiSpam en los sistemas de correo electrónico debería ser parte de la estrategia, pero al basarnos en servicios de Cloud Pública como Office365 no hay demasiado que hacer en ese aspecto. Lo que sí que se puede hacer es una monitorización activa de las situaciones anómalas por medio de un análisis de los logs de los proveedores de Cloud, tal y como hacemos en nuestros servicios de Security Monitoring.

Figura 38: Security Monitoring de Eleven Paths basado integrado con LogTrust

En Microsoft Office 365 es posible acceder a los logs de actividad de todas las cuentas de un dominio corporativo para proceder a su análisis. Un Sistema de Detección de Intrusiones en Cloud que analice estos logs para detectar patrones anómalos o comportamientos no habituales podría detectar la aparición de una nueva app asociada a un buzón de correo.

Figura 39: Esquema de funcionamiento de Elastica de Blue Coat

Tecnologías como LogTrust que permite analizar todos los logs y crear reglas de uso o soluciones como Elastica de BlueCoat pueden dar soporte a este tipo de trabajos a realizar por los equipos de seguridad de una empresa.

Soluciones: Cifrado de Nube Pública

Por último, otra opción posible para evitar el robo de datos por medio de apps maliciosas podría ser el uso de soluciones de cifrado de datos de nube pública. En este caso, una solución como Vaultive que cifra Office 365 haría que, si una app consigue permisos para acceder a los correos mediante un AccessToken, esta app no pueda acceder a los datos descifrados de la cuenta si no lo hace vía el Gateway corporativo que realiza el cifrado y descifrado de los datos.

Figura 40: Cifrado de Office 365 con Gateway de Vaultive

En esta conferencia tienes un ejemplo de cómo funciona Vaultive en Office 365, que estuvieron en nuestro Security Innovation Day mostrando la integración que han hecho con Latch.


Figura 41: Cifrado de Office 365 con Vaultive
Si la app consiguiera el AccessToken, pero intentara acceder desde fuera de la red de la empresa - sin pasar por el gateway que cifra y descifra la nube pública - entonces obtendrías todos los datos de los mensajes de correo electrónico cifrados, tal y como se ve en la siguiente imagen.

Figura 42: El correo al que se accede está cifrado.

Una aplicación maliciosa podría seguir destrozando los correos o accediendo a la lista de remitentes, pero nunca podría leer los correos electrónicos del buzón, ya que están todos cifrados.

Conclusiones

Estas técnicas no son nuevas, y en el mundo del cibercrimen se han utilizado puntualmente en muchos escenarios de ataque. En el pasado ya se habló por aquí de ataques de SPAM Phishing para conseguir Tokens OAuth y es una de las recomendaciones de seguridad de Hotmail y Gmail que debes revisar para saber si te están espiando ahora, pero es importante que los responsables de identidades en las organizaciones sean totalmente conscientes de los peligros de estos ataques que son mucho mayores que los típicos ataques de Spear Phishing - ya de por sí muy peligrosos en las organizaciones -.

Autores: Chema Alonso & Pablo González

*****************************************************************************************

- SAPPO: Spear APPs to steal OAuth-tokens (1 de 4)

- SAPPO: Spear APPs to steal OAuth-tokens (2 de 4)

- SAPPO: Spear APPs to steal OAuth-tokens (3 de 4)

- SAPPO: Spear APPs to steal OAuth-tokens (4 de 4)

*****************************************************************************************