Troyanos bancarios de moda: mekotios y grandoreiros

A lo largo de este verano hemos recibido infinidad de correos, entre los cuales existe, por desgracia, un buen número de troyanos bancarios. Estos correos se suelen caracterizar por tener varias cosas en común, que es lo que vamos a explicar en este artículo.

Como elemento común (y básico para que el usuario caiga en la trampa), los correos suelen tener un gancho para que el usuario se vea en la necesidad de abrirlo: una multa de la DGT, una factura impagada de la luz, temas relacionados con la agencia tributaria, etc.

Por norma general, entre todos los correos analizados se pueden identificar dos clases principales: los correos con adjunto (habitualmente un documento doc, con macros maliciosas) y los correos con un enlace. Estos últimos son más peligrosos en cierto sentido ya que, los adjuntos que vienen por correo se suelen tener controlados y analizados, pero es más difícil controlar los ficheros que se descargan vía http por un link en el cuerpo del mensaje. Cuando son correos con enlaces, pueden descargar también un doc con macros, o a veces un fichero comprimido con un archivo .msi en su interior.

Además de esto, se identifican una serie de patrones, que no en todos los enlaces de correo se producen, pero sí en muchos, y que pueden ayudar a prevenir la descarga de estos archivos maliciosos, que se detallarán al final del artículo.

[Read more…]

Mi5terio resuelto

Día típico de otoño, por la ventana solo se aprecia un cielo gris. Es el típico día en el que crees que no va a suceder nada extraño. De repente nuestro sistema de vigilancia alerta de unas conexiones anómalas: un equipo ha intentado conectarse contra unas direcciones IP de origen desconocido. Estas direcciones IP son públicas y, según la configuración establecida en la organización, toda conexión HTTP hacia el exterior debe pasar a través de un proxy.

Las conexiones se buscan en los registros del proxy y no se encuentran, por lo tanto este equipo ha intentado conectarse directamente, haciendo caso omiso a la configuración del sistema. [Read more…]

Plantillas con malas intenciones

Hace unos días analizando varios correos di con uno que contenía un adjunto sospechoso. Era un documento .docx que a simple vista no tenia nada dentro pero ocupaba 10 kb.

El correo había pasado todas las barreras, tanto SPF, como los dos antivirus que tienen las pasarelas, y también el filtro anti spam.

El fichero .docx se puede tratar como un comprimido. Una vez extraído su contenido, me puse a analizar todos los ficheros del directorio en busca de dominios o direcciones IP que se pudiesen ver en claro:

Y logré encontrar algo interesante dentro de la ruta word/_rels/document.xml.rels donde aparece lo siguiente:
[Read more…]

Volvamos al Collins

En la actualidad, el tráfico http cada vez es menos visible para un analista de seguridad ya que ahora, en muchos casos, los servidores web obligan a usar https y por lo tanto, dejamos de tener mucha visibilidad.

En este aspecto, algunas organizaciones optan, o bien por «romper” el tráfico ssl gracias al uso de un certificado impuesto, o bien solo permiten acceso https para algunos servicios determinados. Algunos de estos servicios, como es el caso de Google, suelen estar permitidos.

Hablemos entonces, por ejemplo, del traductor de Google. Se me ocurrió la idea de hacer bypass a las conexiones a través de un traductor, en este caso de Google. [Read more…]

¿Sueñan los analistas con Exploit Kits?

img0Muchas de las web que se visitan a diario están comprometidas, y el usuario corriente navega por ellas sin tener conocimiento alguno del peligro que supone no tener el navegador o la versión de Adobe Flash  actualizada. A continuación vamos a ver un análisis de este tipo de compromisos que por desgracia, cada día es más habitual.

En el análisis de tráfico HTTP se pueden usar herramientas como Burp o  Fiddler.

En este ejemplo he usado Fiddler y en navegador Iceweasel con un plugin para simular distintos User Agent (Switch  user agent), para en momentos determinados emular Internet Explorer.

Si se quiere instalar Fiddler bajo Linux con mono, se puede seguir este manual:

http://fiddler.wikidot.com/mono

[Read more…]

Cita a ciegas con Darkleech


al0(Los dominios y nombres de usuario que se describen en este post son ficticios, con el fin de proteger la identidad de los reales)

Una de las tareas habituales a la hora de buscar posibles infecciones es analizar el trafico de navegación web (proxy) en busca de contactos con dominios de carácter dinámico (dyndns, no-ip.org, etc…).

En una de estas búsquedas se ve el contacto con un dominio dinámico sospechoso desde la página www.hospitales.com:

2015-08-09 10:53:40 191.226.176.112 Pgarcia - "none" http://www.hospitaless.com/en/index.php  0 - GET http yyuewv.hopto.org 80 /wordpress/ 633 409

El dominio está inactivo, pero queremos analizar las peticiones que se hacen al visitar esta web. Para ello, uso un analizador como Burp:

al1

[Read more…]

BRO IDS: “el ojo que todo lo ve…”

broidsBRO es una herramienta open-source para el análisis de tráfico de red cuyo objetivo es reconocer actividades sospechosas.

El análisis de red reporta varios tipos de registros divididos según el protocolo y características como puede ser HTTP, DNS, SSL, FTP, sesiones IRC, SMTP, etc.

Para la captura de paquetes utiliza libpcap. Es capaz de analizar y detectar túneles (incluyendo Ayiya, Teredo, GTPv1) además de desencapsularlos para luego analizar su contenido.

Arquitectura

Se basa en dos componentes:

  1. Motor de eventos (event engine): Reduce el flujo de paquetes, organizándolos para ser llevados a un nivel superior.
  2. Interprete de Scripts (policy script interpreter): acciones a tomar cuando se detecta una actividad determinada.

[Read more…]

PFsense: firewall perimetral (VI)

En este último capítulo sobre Pfsense (ver I, II, III, IV y V) se explica la configuración de un servidor proxy como Squid en modo transparente para no tener que configurar todos los equipos de la red.

La tarea de este proxy será registrar todas las conexiones HTTP, hacer estadísticas de navegación y denegar ciertos dominios.

El primer paso es instalar estos 3 paquetes: Squid, SquidGuard y Ligthsquid.

[Read more…]

PFsense: firewall perimetral (V)

En este quinto capítulo sobre Pfsense (ver I, II, III y IV) se explicará la instalación y configuración de Snort, con el fin de incluir un NIDS en nuestro firewall.

Para instalar Snort en system > packages


Una vez instalado, en services > snort, se procede a su configuración:

-= Pestaña iface settings =-

Es donde se elige el lugar en el que Snort va a esnifar. wlan0 en caso de querer que actúe entre internet y la entrada del firewall, o ya si se quiere algo mas interno seria en opt1 para la DMZ o LAN para la red interna. En este caso para ver todo el tráfico hacia Internet lo mejor es elegir wlan0.

Respecto a la variable home_net y external_net se pueden dejar por defecto ya que home_net englobará a todas las direcciones IP internas y external_net a todas las que sean diferentes de home_net.

-= Pestaña WAN barnyard2 =-

Barnyard2 permite procesar los log de Snort e insertarlos en una base de datos externa:

En el apartado “MYSQL Database Output settings” es donde se configura el servidor MySQL externo, donde barnyard2 insertará los Log de Snort. Previamente en este servidor externo se debe crear la base de datos snort y dar permisos al usuario snort y a la dirección IP de Pfsense (192.168.1.2) para que pueda acceder a la bbdd:

mysql -u root -p

CREATE DATABASE  snort;

grant INSERT,SELECT,UPDATE,CREATE,DELETE,EXECUTE on snort.* to snort@192.168.1.2
Set password for snort@192.168.1.2=PASSWORD('snortpass');
flush privileges;

y posteriormente crear el esquema de esta base de datos (se puede descargar desde aquí):

mysql -D snort -u root -p < ./schemas/create_mysql

-= Pestaña Global Settings =-

Las reglas de detección del IDS tienen un papel importante y en este apartado es donde se configuran. Para incluir las reglas VRT se debe incluir un código, que se consigue al registrarse en la web de Snort.

Al registrarse envían un correo con el enlace para entrar logeado en la web de snort.org, luego en nuestro perfil conseguimos el oinkcode.

-= Pestaña updates =-

Por último en la pestaña updates se procede a la descarga de las reglas:


-= Pestaña Suppress =-

Al igual que en el fichero threshold.conf de Snort, es aquí donde se puede limitar las alertas, por origen, destino,o por el numero de coincidencias en un determinado tiempo. Veamos un ejemplo:

Se tiene primero que buscar el sig_id (identificador único de cada regla), para poder limitar las alertas (para el ejemplo “1852”):

  • No alertar cuando el origen sea 192.168.3.0/24.
  • No alertar cuando el destino sea 192.168.1.10 y 192.168.1.11:
    suppress gen_id 1, sig_id 1852, track by_src, ip [192.168.3.0/24] 
    suppress gen_id 1, sig_id 1852, track by_dst, ip [192.168.1.10,192.168.1.11]
  • Suprimir directamente toda la regla:
    suppress gen_id 1, sig_id 1852
  • Solo alertar de una de las alertas de la firma cada 3600 segundos:
    event_filter gen_id 1, sig_id 1852, type limit, track by_src,  count 1, seconds 3600
  • Suprimir cualquier regla para un origen concreto:
    suppress gen_id 1, sig_id 0, track by_src, ip [192.168.1.1]

Para mas información sobre las configuraciones, se puede visitar el siguiente link.

-= Pestaña Pass list y Blocked =-

En el caso de que Snort también funcione como IPS, es decir no solo alerte, sino que pueda bloquear, en estas dos pestañas se elige qué direcciones están exentas de bloqueo o cuáles bloquear. Por defecto las direcciones WAN, los gateway, servidores DNS, VPN, etc. están en la lista de no bloqueo.

Dentro de Services > snort > snort interfaces se edita (botón a la derecha con la letra “e”) en la pestaña WAN Categories:

Se pueden escoger qué reglas usar como se muestra en la imagen.

En la siguiente y última entrada de la serie sobre Pfsense veremos el tema de Squid como proxy HTTP. Espero que os haya parecido interesante.

pfSense: firewall perimetral (IV)

Volvemos a la carga con la cuarta parte de nuestra serie sobre pfSense. En el anterior capítulo explicamos cómo configurar las opciones avanzadas del sistema (ver también la primera entrada y la segunda, para los despistados). En esta cuarta parte vamos a explicar cómo configurar “el corazón del firewall”, es decir las reglas de pfSense.

Lo primero, para facilitar la creación de reglas, es importante saber lo que son los “alias” y qué posibilidades brindan. Vamos a la pestaña superior, Firewall → Aliases.

Dentro podemos crear diversos alias como Hosts, subredes, puertos y URLs. Este es un ejemplo de creación de alias para los servidores que pertenecen a la red DMZ:

Así es como se vería un resumen de todos los Alias creados:

Ahora se trata de usar estos alias para configurar las reglas en el apartado Firewall → Rules. Lo más importante que debemos tener en cuenta al crear una regla es que prevalece la prioridad de la regla que se sitúa por encima de otra regla.

En nuestro ejemplo (y en general, en cualquier entorno en producción) la red DMZ no debe tener acceso a la red interna, ya que la DMZ es la que albergará los servidores que están expuestos a Internet y esta red no debe tener ningún tipo de comunicación hacia la red interna. Por otro lado, sí que nos interesa que se puedan gestionar los servidores desde la red interna hacia la DMZ, por lo que podemos crear una regla que permita el trafico por el puerto 22 (SSH) desde la red interna hacia la DMZ.

En el apartado Rules, la interfaz que pertenece a DMZ es “OPT1”, desde allí, existe un botón con el símbolo “+” para añadir reglas. Por tanto, creamos una regla que deniegue el acceso desde la DMZ a red interna, donde en “Destination” usamos el alias “Subnet_lan” creado anteriormente.

Exactamente de la misma forma pero desde la interfaz LAN (red interna) crearemos una regla que deniegue todo el tráfico desde red interna (LAN) a la subred DMZ (más adelante se superpondrán reglas que prevalezcan sobre esta). A continuación, creamos una regla por encima de la anterior que permita la comunicación SSH desde red interna (LAN) hasta los servidores en DMZ:

Ahora en las reglas del firewall de la interfaz LAN (nótese que el deny de DMZ hacia LAN está en el interfaz OPT1, por eso no se muestra) se vera así:

En la regla de más arriba (la más prioritaria) están permitidos dos puertos 10443 y 10022, que son los que se usan para administrar PFsense por HTTPS y SSH. Esta regla se crea por defecto y es importante que exista ya que en caso contrario, se estaría denegando el acceso al propio firewall.

El siguiente paso es configurar NAT (Network Address Traslation). Para ello en la sección NAT en Port Forwarding, configuraremos que nos permitan acceder al servidor web y al servidor FTP desde internet a estos dos equipos situados en la DMZ. En el caso del HTTP sería como se muestra en la imagen.

Tras aplicar ambas reglas, tendríamos una situación como la siguiente:

Es importante saber que al crear esta regla en NAT automáticamente se crean las reglas del firewall asociadas, de forma que se pueda hacer efectivo el acceso desde fuera hacia dentro. Por tanto, así quedarían las reglas del firewall en la interfaz WAN ahora:

Con estos ejemplos básicos ya podemos comenzar a «trastear» con pfSense y un mayor número de reglas. En el siguiente artículo veremos la implementación de herramientas como un IDS (Snort) o un proxy (Squid), dentro de pfSense.