Security Art Work

En esta ocasión voy a mostrar un ejemplo que sirva de idea sobre cómo utilizar reglas un poco más complejas en Snort para detectar actividades sospechosas en nuestra red basadas en geolocalización. Para ello, haremos uso de la opción flowbits en unas determinadas reglas para que salten cuando aparezcan algunos países que consideraremos como hostiles o peligrosos.

Entrando un poco en detalle, deciros que me basaré en el preprocesador de geolocalización que desarrolló nuestro compañero Joaquín Moreno (un saludo, Ximo ;)). De esta forma vamos a marcar las conversaciones con países que queramos destacar y activaremos un flowbit, que luego será comprobado por algunas reglas puntuales.

Para comenzar por la geolocalización podemos empezar por analizar las peticiones DNS realizadas por nuestros equipos hacia dominios de países hostiles:

alert udp $HOME_NET any -> $EXTERNAL_NET 53 (msg:”DNS Petición dominio en Islas Caiman”; 
flow:to_server; byte_test:1,!&,0xF8,2; content:"|03|ky|00|"; fast_pattern:only; 
sid: 3200001; rev:1;)

Esto podría alertar sobre una situación anómala pero no significa que la comunicación se establezca, ni siquiera si el servidor se encuentra en esa ubicación, aunque podemos utilizarla como un indicio más si contamos con un correlador de alertas. A continuación haremos uso del preprocesador de geolocalización para detectar comunicaciones hacia determinados países:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:”S2 GEO Conexión TCP a país 
sospechoso”; flow:established,to_server; country: [] -> [KY]; 
flowbits:set,s2.geo.taxhaven; flowbits:noalert; sid: 3200002; rev:1;)

Otra forma de geolocalizar, aunque mucho más costosa de mantener, es definir una variable indicando rangos de direcciones IP.

ipvar $TAX_HAVEN [63.136.112.0/21, 74.117.112.0/21, 74.117.216.0/21, 74.222.64.0/19, 
162.211.136.0/22, 73.225.208.0/20, 192.0.4.0/22, 198.147.208.0/22, 199.201.84.0/22, 
208.82.216.0/22, 208.157.144.0/21, 208.168.224.0/19, 209.27.52.0/22, 209.27.60.0/22, 
216.144.80.0/20]

alert tcp $HOME_NET any -> $TAX_HAVEN $HTTP_PORTS (msg:” S2 GEO Conexión TCP a país
 sospechoso”; flow:established,to_server; flowbits:set,s2.geo.taxhaven; 
flowbits:noalert; sid:3200003; rev:1;)

En ambos casos activamos el flowbit ‘s2.geo.taxhaven‘ y con el parámetro noalert le indicamos que no genere alerta. Esto no es necesario pero la alerta que nos interesa es la siguiente por lo que no queremos que nos alerte en este caso.

Ahora viene la regla compleja. Utilizaremos una regla que nos avise en caso de que un servidor nos presente un certificado SSL que contenga las palabras “Bank” o “Cayman Island”. Previamente, comprueba que el flowbit ‘s2.geo.taxhaven‘ está activo para esa conversación, es decir, no sólo el servidor dice ser de Islas Caimán sino que la IP está ubicada allí.

alert tcp $TAX_HAVEN 443 -> $HOME_NET any (msg:”S2 GEO Certificado SSL de Islas Caimán”;
 flow:established,to_client; flowbits:isset,s2.geo.taxhaven; content:“Bank”; 
content:“Cayman Island”; sid:3200004; rev:1;)

Todo esto tan sólo ha sido un ejemplo. Estoy seguro de que podréis adaptar estas reglas a aquellas situaciones en las que queráis añadir geolocalización. Particularmente, yo creo una regla por cada país hostil y utilizo un flowbits “badcountry”. Por otro lado, creo reglas para que me alerten de descarga de ficheros o conexiones desde IPs críticas a una serie de países hostiles desde el punto de vista de ser fuente de frecuentes ataques de red (flowbits:isset,s2.geo.badcountry).

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:”S2 GEO Conexión TCP a país 
sospechoso (Israel)”; flow:established,to_server; country: [] -> [IL]; 
flowbits:set,s2.geo.badcountry; flowbits:noalert; sid: 3200021; rev:1;) 

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:”S2 GEO Conexión TCP a país 
sospechoso (Rusia)”; flow:established,to_server; country: [] -> [RU]; 
flowbits:set,s2.geo.badcountry; flowbits:noalert; sid: 3200022; rev:1;) 

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:”S2 GEO Conexión TCP a país 
sospechoso (Ucrania)”; flow:established,to_server; country: [] -> [UA]; 
flowbits:set,s2.geo.badcountry; flowbits:noalert; sid: 3200023; rev:1;) 

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:”S2 GEO Conexión TCP a país 
sospechoso (Lituania)”; flow:established,to_server; country: [] -> [LT]; 
flowbits:set,s2.geo.badcountry; flowbits:noalert; sid: 3200024; rev:1;)
[...]

NOTA: Por cuestión de rendimiento, el orden en el que se comprueba el flowbit es importante, por lo que en comunicaciones TCP se recomienda colocarlo inmediatamente después del parámetro flow.

El libro que me gustaría comentar ha caído hace pocos días en mis manos y se titula “Traffic Analysis with Tshark How-to” cuyo autor es nada menos que nuestro compañero del blog Borja Merino (@BorjaMerino).

Este libro trata, como es evidente, sobre el uso de la herramienta Tshark, la versión de línea de comandos de Wireshark, y de la que ya hemos hablado en alguna ocasión (Registro forense de red con tshark). Aunque Borja cubre un gran abanico de temas, incluye algunos ejemplos que muestran formas de capturar tráfico, la localización problemas de saturación de red, uso de filtros para buscar evidencias concretas, detectar ataques de red o la utilización de la herramienta como apoyo al hacer fuzzing a una aplicación.

Se explica de forma atractiva puesto que se presenta en forma de receta y después la explicación de qué estamos haciendo, o como lo titulan en la forma del libro “How to do it” y “How it works”. También se etiquetan las secciones por su utilidad e importancia, de la forma “recomendable”, “imprescindible” y “conviértete en experto”, de modo que permite identificar aquellos aspectos por su importancia de cara al grado de utilización de la herramienta que vaya a hacer el usuario.

Eso sí, es necesario leerlo con un equipo y una shell delante para asimilar toda la información que recoge en tan poco espacio, ya que el material es de alto nivel técnico, con explicaciones prácticas y ejemplos útiles sobre situaciones comunes para cualquier administrador de sistemas, incident handler o para cualquiera que quiera aprender o mejorar su kung-fu en tshark.

En definitiva, una lectura totalmente recomendada, a la altura del nivel técnico del autor.

¿Sabemos qué tráfico circula por nuestra red? Al hilo de los distintos posts (Analizando nuestra red, Analizando nuestra red II) de análisis de red que se han ido publicando en este blog hoy vamos a continuar en este tema centrándonos en el análisis del tráfico desde un punto de vista de rendimiento y clasificación del mismo.

Cuando monitorizamos una red, nos solemos centrar en dos puntos, la cantidad de tráfico que atraviesa la red, habitualmente mediante la activación del servicio SNMP y la consulta mediante polling del tráfico de las interfaces de red, mediante alguna herramienta que gráficamente muestre los resultados, como puede ser mrtg o Cacti, y la tipología de dicho tráfico.

Para poder monitorizar que tipo de tráfico circula por nuestra red existen distintas soluciones, aunque nos centraremos en el uso del protocolo netflow; A grandes rasgos, netflow es un protocolo de red desarrollado por Cisco para la monitorización y análisis de tráfico de red, el cual está presente en distintos fabricantes de dispositivos en la actualidad.

La arquitectura netflow esta constituida por tres elementos:

• Netflow Exporter: el dispositivo de red, habitualmente un router o un switch de gama alta (hay que confirmar previamente que el servicio netflow está soportado), que captura los flujos de datos que circulan por él, enviando información sobre direcciones IP, puertos o protocolos usados.

• Netflow collector: el elemento que recoge la información enviada por el dispositivo de red y la almacena.

• Consola de análisis: el sistema a través del cual el gestor de red analiza la información almacenada por el colector.

Para este post hemos usado un Router Cisco 1800 como Netflow Exporter y un sistema GNU/Linux para la implementación del Netflow collector y la consola de análisis.

Una vez tenemos los equipos configurados a nivel de red y por lo tanto, existe conectividad entre ellos, configuramos el colector; para ello, instalamos las herramientas flow-tools en nuestro sistema y configuramos el servicio indicando en el fichero de configuración /etc/flow-tools/flow-capture.conf la información del dispositivo de red que nos enviará la información; por cada dispositivo añadiremos al fichero de configuración una entrada como la siguiente:

-w /var/netflow/flows/completed/router 0/172.18.0.200/9995 -S1

Indicando el directorio donde almacenaremos la información enviada ordenada por fecha (/var/netflow/flows/completed/router), los datos de red del dispositivo de la forma Dirección Local/Dirección Remota/Puerto, por lo que con el parámetro 0/172.18.0.200/9995, indicamos que recibimos información del dispositivo con dirección IP 172.18.0.200 a través del puerto 9995 de cualquiera de las direcciones IP del servidor y en intervalos de un minuto. Una vez arrancado el servicio, ya podemos recibir la información de dispositivo de red.

A continuación procedemos a configurar el servicio Netflow en el router (algunos de éstos comandos son opcionales):

# Indicamos el tiempo durante el cual flujo activo antes de expirar de la caché
Router(config)#ip flow-cache timeout active 1 

# Indicamos el número de entradas en la caché
Router(config)#ip flow-cache entries 20
# Interfaz que usaremos para conectar con el colector
Router(config)#ip flow-export source FastEthernet0/0
# Versión del protocolo
Router(config)#ip flow-export version 5
# Dirección IP y puerto de colector
Router(config)#ip flow-export destination 172.17.2.23 9995 

# Captura de flujos del aplicaciones más usadas
Router(config)#ip flow-top-talkers
# Maximo número de aplicaciones
Router(config-flow-top-talkers)# top 20
# Criterio de ordenación
Router(config-flow-top-talkers)# sort-by bytes
# Filtro de flujos
Router(config-flow-top-talkers)# match destination port min 0 max 65535 

# Interfaz que captura flujos
Router(config)#interface FastEthernet0/0
# Activamos netflow para el tráfico inbound
Router(config-if)# ip flow ingress
# Activamos netflow para el tráfico outbound
Router(config-if)# ip flow egress
# Activamos la cache netflow para el enrutamiento
Router(config-if)# ip route-cache flow

Llegados a este punto, el dispositivo está en disposición de capturar los flujos de tráfico:

Router#show ip flow export
Flow export v5 is enabled for main cache
Exporting flows to 172.17.2.23 (9995)
Exporting using source interface FastEthernet0/0
Version 5 flow records
168 flows exported in 74 udp datagrams
0 flows failed due to lack of export packet
0 export packets were sent up to process level
0 export packets were dropped due to no fib
0 export packets were dropped due to adjacency issues
0 export packets were dropped due to fragmentation failures
0 export packets were dropped due to encapsulation fixup failures
Router#show ip flow top-talkers
SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Bytes
Fa0/0 172.17.2.23 Local 172.18.0.200 06 0016 A4B2 60K
Fa0/0 172.17.2.23 Local 172.18.0.200 06 A332 0017 2567
2 of 20 top talkers shown. 2 of 2 flows matched.

Router#show ip cache flow
IP packet size distribution (19470 total packets):
1-32 64 96 128 160 192 224 256 288 320 352 384 416 448 480
.000 .056 .606 .007 .005 .005 .004 .004 .004 .004 .298 .000 .000 .000 .000

512 544 576 1024 1536 2048 2560 3072 3584 4096 4608
.000 .000 .000 .000 .000 .000 .000 .000 .000 .000 .000

IP Flow Switching Cache, 278544 bytes
2 active, 4094 inactive, 170 added
4303 ager polls, 0 flow alloc failures
Active flows timeout in 1 minutes
Inactive flows timeout in 15 seconds
IP Sub Flow Cache, 21640 bytes
2 active, 1022 inactive, 170 added, 170 added to flow
0 alloc failures, 0 force free
1 chunk, 1 chunk added
last clearing of statistics never
Protocol Total Flows Packets Bytes Packets Active(Sec) Idle(Sec)
-------- Flows /Sec /Flow /Pkt /Sec /Flow /Flow
TCP-Telnet 7 0.0 99 41 0.2 29.0 6.0
TCP-other 44 0.0 155 314 2.0 40.5 5.9
UDP-other 76 0.0 154 74 3.4 0.5 15.5
ICMP 41 0.0 1 139 0.0 0.7 15.4
Total: 168 0.0 114 158 5.6 12.2 12.6

SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts
Fa0/0 172.17.2.23 Local 172.18.0.200 06 0016 A4B2 172
Fa0/0 172.17.2.23 Local 172.18.0.200 06 A332 0017 35

A continuación, como gestores de red y a través de la consola de análisis que proporciona flow-tools, ya somos capaces de mostrar la información enviada de una fecha concreta y almacenada en el colector.

Linux:/# flow-cat /var/netflow/flows/completed/test/2013/2013-05/2013-05-15/*
    | flow-print

srcIP          dstIP        prot   srcPort dstPort octets   packets
172.18.0.150   172.18.0.200  1     0       0       518880   360
172.17.0.87    172.18.0.200  6     22      15042   83196    282
172.18.0.150   172.18.0.200  6     55215   23      9560     239
172.17.2.23    172.18.0.200  17    44186   161     71       1
172.17.2.23    172.18.0.200  17    50078   161     71       1
172.17.2.23    172.18.0.200  17    40590   161     73       1
172.17.2.23    172.18.0.200  17    44599   161     73       1
172.17.2.23    172.18.0.200  17    59577   161     73       1

Lógicamente, con estos datos almacenados, es posible configurar una interfaz gráfica, como por ejemplo el plugin Flowview de Cacti, para recoger esta información almacenada y presentarla de forma más amigable para el gestor, pudiendo filtrar los flujos recibidos y crear gráficas por puertos o direcciones IP (pinchar en la imagen para ampliarla).

Para acabar, flow-tools nos permite crear filtros de captura para analizar los flujos recibidos en base a patrones. Si por ejemplo queremos obtener los flujos de tráfico SSH, podríamos crear en un fichero (/tmp/filter) un filtro como el siguiente:

filter-primitive SSH
type ip-port
permit 22

filter-definition FlujoSSH
match ip-destination-port SSH

Y aplicar el filtro a la información almacenada un día concreto:

Linux:/# flow-cat /var/netflow/flows/completed/test/2013/2013-05/2013-05-15/*
    | flow-nfilter -F FlujoSSH -f /tmp/filter | flow-print

srcIP         dstIP         prot    srcPort dstPort octets packets
172.18.0.150  172.18.0.200  6       34498   22      44     1
172.18.0.150  172.18.0.200  6       33169   22      44     1
172.18.0.150  172.18.0.200  6       63712   22      44     1
172.18.0.150  172.18.0.200  6       61025   22      44     1
172.18.0.150  172.18.0.200  6       43271   22      44     1
172.18.0.150  172.18.0.200  6       44450   22      44     1
172.18.0.150  172.18.0.200  6       33121   22      44     1
172.18.0.150  172.18.0.200  6       63119   22      44     1
172.18.0.150  172.18.0.200  6       37077   22      44     1
172.18.0.150  172.18.0.200  6       35145   22      44     1
172.18.0.150  172.18.0.200  6       59776   22      44     1
172.18.0.150  172.18.0.200  6       52694   22      44     1
172.18.0.150  172.18.0.200  6       44754   22      44     1

Con ésta funcionalidad y aunque hay aplicaciones dedicadas a ello, no sería complejo crear un agente que analizara periódicamente los flujos recibidos por el colector en busca de patrones sospechosos o cambios en el uso de la red, como por ejemplo un aumento del uso del protocolo telnet en la red con respecto a información anterior, generando una alerta en nuestro sistema de monitorización.

Introducción
Hoy en día se pueden encontrar muchas técnicas para proteger las aplicaciones Web frente a ataques de Inyección SQL. Principalmente, saneando la entrada de texto que proviene del usuario (siempre se debe pensar que es malintencionado).

Pero, ¿qué podemos hacer si queremos tener un control sobre estos ataques? Ya sea para bloquearlos o simplemente avisarnos, podríamos pensar en implementar un WAF (Web Application Firewall) pero existen aplicaciones y dispositivos más específicos: los Database Firewalls.

Funcionamiento
Se podría decir que es similar a cualquier WAF/IPS. Emplea una serie de reglas que permiten identificar las consultas SQL malformadas/malintencionadas y evitar que se lleve a cabo el ataque. Por otro lado, existen en el mercado productos que controlan ataques como desbordamientos de buffer o denegaciones de servicio, entre otros.

Tal como se ha indicado, se hace uso de reglas basadas en expresiones regulares. En caso de coincidir los patrones, saltarán los avisos correspondientes y la consulta será bloqueada/descartada. De esta forma se consigue evitar que el ataque sea efectivo.

Además de las reglas mencionadas, existen distintos modos de filtrado/bloqueo de consultas:

• Restrictivo, mediante una lista blanca donde se especifican las consultas legítimas.

• Permisivo, mediante una lista negra, huelga decir que son las consultas a bloquear.

• Análisis gramatical de las consultas SQL, con lo que se consigue identificar consultas (aunque fuesen legítimas) que pudieran ser aprovechadas, por supuesto, para inyectar código SQL.

Por último, mencionar que una de las características que se ofrece en estos productos es la de funcionar como proxy. Se almacenan en caché los resultados de las consultas y, de este modo, se reduce la carga a los SGBD y a las BBDD correspondientes.

Mercado y compatibilidades
En este punto, mucha gente se pregunta acerca de la compatibilidad de estos productos para ser usados con sus SGBD.

En el mercado existen multitud de fabricantes que ofrecen soluciones de seguridad para sus SGBD como pueden ser Oracle o Microsoft, entre otros. A continuación se va a nombrar, muy por encima, una solución alternativa.

Hace ya años que salió a la luz GreenSQL y continúa ofreciéndose de forma gratuita (GreenSQL Express). También existe la posibilidad de adquirir el producto de pago, GreenSQL Pro, donde además de un soporte nos ofrece más funcionalidades.

La versión gratuita está restringida a proteger sólo una BBDD y sólo protege frente a ataques de inyección SQL. Esto significa que no protege contra desbordamientos de buffer, escalada de privilegios, denegaciones de servicio…

Pero, ¿qué SGDB son compatibles con GreenSQL? A continuación os nombraré los distintos gestores con los que lo podemos usar:

• Microsoft SQL Server

• PostgreSQL

• MySQL

• Microsoft Azure SQL Database

• Amazon RDS

Conclusiones
Personalmente pienso que es una solución a tener en cuenta. No sólo por el hecho de ir un paso más allá en la protección de la información almacenada, sino también por aligerar el uso del resto de dispositivos (WAF, IPS…), sobre todo si están sometidos a una alta carga de transacciones (recordad que los Database Firewall pueden funcionar como proxy).

Como comentamos en la entrada Fundamentos sobre certificados digitales el protocolo SSL es un estándar de transmisión de datos seguros sobre Internet empleado en diversos protocolos de la capa de aplicación y protocolos de la capa de transporte (TCP) como medio para establecer conexiones seguras. El protocolo SSL funciona empleando certificados de clave asimétrica del mismo tipo que los expuestos con anterioridad.

Pasemos a describir cual es el funcionamiento básico de SSL, empleando un ejemplo que detalle los pasos para establecer una conexión segura HTTPS entre un cliente y un servidor web dotado de dicha capacidad.

En primer lugar, el cliente establece conexión con el servidor mediante su puerto HTTPS (de forma estándar el 443), para lo cual realiza una solicitud de inicio de sesión segura. A continuación, el servidor devuelve un certificado en formato X.509, que constituye su clave pública. Tras verificar que los datos del certificado son correctos, el cliente procede a generar una clave simétrica aleatoria, que es la que se empleará en la transmisión de datos, cifra esta clave con la clave pública del servidor y la envía al mismo. Tras la recepción, tanto el cliente como el servidor han establecido una conexión segura empleando una clave simétrica para su sesión; en caso de que se finalizara la sesión, bien por cierre de la misma o bien por timeout se desechará dicha clave y se renegociará una nueva en la siguiente conexión. A continuación se muestra un pequeño diagrama de su funcionamiento.

Una vez explicado a grandes rasgos cual es el funcionamiento del protocolo, y entendiendo que el mismo no sólo facilita confidencialidad sino que también ayuda a asegurar la identidad del sitio remoto, la verdadera duda que nos debería asaltar es la siguiente: ¿cómo sé que el certificado descargado es real y no se ha generado de forma fraudulenta?

Actualmente cualquiera puede generar un par de claves pública/privada asociadas al dominio que considere oportuno y asociarlos a SSL, de modo que podría establecer un servicio web con un certificado fraudulento imitando un servidor legítimo y así poder realizar cualquier acción maliciosa contra los clientes que, engañados, accedieran a su servicio.

Ante esta problemática aparecen las Autoridades de Certificación (CA), organismos directamente encargados de generar certificados digitales de cualquier tipo, desde firma digital hasta certificados de servidor SSL. Se trata de entidades autorizadas y reconocidas que generan certificados. En todos y cada uno de los certificados SSL (en base al protocolo X.509) se establece un emisor (issuer) que es la entidad que ha generado el certificado. Verificando el emisor, así como los certificados involucrados en la cadena de confianza se puede asegurar si el certificado lo ha emitido dicha entidad y de este modo se puede clasificar en base a la confianza que se deposita en dicha entidad. En base a este principio, si un certificado se ha emitido por una Autoridad de Certificación reconocida, se establece una cadena de confianza que asegura que dicho certificado es legítimo; es esta información la que emplean los navegadores comerciales.

Esta validación queda reflejada en el diagrama de funcionamiento de SSL en la línea discontinua (y que antes intencionadamente no se ha comentado). Profundizaremos en mayor detalle sobre el funcionamiento de las Autoridades de Certificación, formatos de certificado X.509 y cadena de confianza en próximas entradas.

Por último y para dotar a todos los curiosos que hayan leído esta entrada de un método fácil para identificar certificados no seguros en nuestras conexiones HTTPS con cualquier navegador, plantearemos dos ejemplos para distinguirlos. Utilizaremos Firefox, aunque en todos los navegadores funciona prácticamente igual.

Ejemplo de certificado reconocido: www.bankia.es

Como se puede observar en el área remarcada, aparece un candado verde con la identidad del propietario del certificado. Si pinchamos en dicha área e inspeccionamos el certificado obtendremos un resultado semejante al mostrado en la imagen siguiente, en el que se identifica el propietario del certificado, la Autoridad de Certificación emisora y su periodo de validez.

Ejemplo de Certificado no reconocido (en este caso mantendremos en secreto la identidad del sitio web):

Como se puede observar nuestro navegador, al detectar una irregularidad en el certificado nos solicita nuestro permiso explícito para aceptar dicho certificado a pesar de que sea no confiable.

Y con esto es todo. En próximas entradas del blog trataremos también verificaciones adicionales, como verificar la cadena de confianza de un certificado, saber qué protocolos de cifrado (o de generación de clave asimétrica) se emplean, el funcionamiento de una CA, etc. Es muy importante siempre que se vaya a enviar información confidencial o realizar una compra por Internet verificar en primer lugar si se establece un cifrado, y si el certificado emitido es confiable.

Espero que os haya gustado y quedo a la espera de vuestros comentarios.

(Publicamos hoy un informe sobre detección de APTs elaborado por el CSIRT-CV e INTECO-CERT cuyos autores son dos de nuestros compañeros: Jose Miguel Holguín y Maite Moreno (S2 Grupo) por parte de CSIRT-CV y Borja Merino por parte de INTECO-CERT. Todos ellos son coautores habituales de este blog).

Cuando se habla de ataques de APT se habla de organización, premeditación, persistencia, sofisticación y novedad. No hay que olvidar que este tipo de amenazas están lo suficientemente bien financiadas cómo para mantener su campaña de ataques durante un periodo largo de tiempo, y disponer de los recursos necesarios para conseguir su fin. Es posible incluso que, en caso de ser detectados, los cibercriminales tengan un plan de contingencia que les permita reorganizarse y atacar de nuevo.

Su detección por tanto es de una extrema dificultad (Véase este enlace sobre amenazas persistentes avanzadas). Algunas fuentes (Véase este enlace sobre Foros DINTEL de AA.PP. Seguridad vs Ciberdelincuencia) hablan de un nivel de detección no superior al 25%:

• Usan firmas de ataque único, novedosas y de gran creatividad, difíciles de correlacionar con las de los ataques conocidos. Este tipo de ataques están diseñados para evadir las soluciones antimalware e IPS existentes en el mercado (Véase The Undetectables: How ‘Flame’ highlights the failure of antivirus), ya que no suelen comportarse como el malware tradicional y además son creados específicamente para la organización objetivo, previo estudio de sus posibles debilidades.

• El hecho de que el malware pueda mantenerse oculto, ya esté activo o latente, y que la campaña de ataques APT sea habitualmente distribuida en largos periodos de tiempo y no sea periódica, hace que sea complicado correlacionar alertas basándonos en los datos de fechas/horas.

• El tráfico de datos que se establece suele ser encubierto a través de cifrado, esteganografía, compresión, técnicas de CovertChannels o cualquier otro tipo de métodos que permitan ocultar la ilegitimidad de ese tráfico (incluso es posible que utilicen servicios públicos y dominios comunes como Twitter, Facebook, Google Translator, etc.); las conexiones no lícitas de los servidores son muy difíciles de detectar y es muy complicada la identificación de la red atacante.

En definitiva, las APT, a día de hoy, constituyen uno de los peligros mas importantes y de mayor expansión a los que se enfrentan los profesionales de la seguridad, y son prácticamente inevitables para la mayoría de las organizaciones, y es por ello que la cuestión principal que se ha de plantear en el panorama actual frente a este tipo de amenazas es cómo detectarlas.

Es fundamental proporcionar a los profesionales de la seguridad y administradores de sistemas y redes el conocimiento necesario sobre cómo detectar una APT en sus infraestructuras tecnológicas. Es por ello que, con objeto de concienciar sobre la importancia de una detección precoz ante una amenaza de este tipo, CSIRT-CV e INTECO-CERT han colaborado para la elaboración de un informe titulado “Detección de APTs”.

Los objetivos que pretende alcanzar este informe son los siguientes:

• Constatar la importancia e implicación que tienen las APT en la seguridad nacional, tanto a nivel gubernamental, militar como en los sectores de defensa, empresarial o financiero, y el alto riesgo que conlleva que puedan verse afectadas infraestructuras críticas como centrales nucleares o de telecomunicaciones, redes eléctricas, suministros de agua, puertos, comunicaciones ferroviarias o aéreas, etc.

• Evidenciar el funcionamiento detallado de algunos casos conocidos de este tipo de ataques. Mostrar a nivel técnico y en profundidad como es el ‘modus operandi’ de algunos ejemplos de campañas de APT.

• Detallar cuales son las vías de infección más utilizadas para llevar a cabo un ataque de estas características; se mostrarán los distintos tipos de infecciones existentes a través de malware, las técnicas de ingeniería social más usadas, los medios físicos como una importante vía de infección, el creciente mercado de exploits o los Web basedAttacks.

• Establecer una serie de pasos básicos a seguir y consideraciones que se deben tener en cuenta a la hora de detectar en nuestra organización una intrusión de estas características. Se destacará la importancia de un elemento de red tan crítico como es el Firewall corporativo y como proceder para llevar a cabo un adecuado análisis de tráfico con el objetivo de detectar patrones de comportamiento que puedan hacer saltar nuestras señales de alarma frente a una intrusión (detección de anomalías en la red y en capturas de tráfico, métodos de correlación/estadísticos, técnicas de CovertChannels, etc).

El informe “Detección de APTs” puede ser descargado bien del portal Web de CSIRT-cv o desde el portal de INTECO-CERT.

Las posibilidades que ofrece Meterpreter a la hora de desarrollar módulos de post-explotación son prácticamente ilimitadas. Véanse a modo de ejemplo los módulos NBDServer.rb y Imager.rb desarrollados por R. Wesley McGrew y presentados en la Defcon 19 bajo el título “Covert Post-Exploitation Forensics With Metasploit“.

Dicho módulos permiten hacer una copia byte a byte de volúmenes físicos y unidades lógicas del equipo comprometido a través de la red; o bien montar el sistema de ficheros de dichas unidades en el equipo del atacante como si fuera un simple dispositivo más. No hace falta mencionar las posibilidades desde el punto de vista forense que ofrecen este tipo de módulos.

Gran parte de esta flexibilidad para llevar todo tipo de tareas desde una shell con Meterpreter la ofrece la extensión railgun al permitirnos cargar en runtime librerías de Windows y hacer uso de sus funciones. Al tener acceso íntegro a toda la API de Windows, las opciones de post-explotación son prácticamente inagotables.

Como aportación a la lista de módulos de post explotación forense, he desarrollado un módulo para poder recuperar ficheros eliminados desde sistemas de ficheros NTFS. De esta forma no solo podremos conseguir ficheros “existentes” en el equipo comprometido si no obtener también ficheros “eliminados” de forma insegura (en ocasiones, los más interesantes).

La idea del módulo es recorrer cada una de las entradas de la $MFT (Master File Table) e ir listando los ficheros eliminados. A medida que muestra los ficheros, añadirá un ID asociado a cada uno de ellos, el cual representará el offset de la entrada MFT de dicho fichero en disco (no es más que el número de bytes lógico a partir del cual se encuentra dicha entrada). Si posteriormente deseamos recuperar un determinado fichero especificaremos la variable FILES con dicho ID. De esta forma el módulo podrá leer la entrada correspondiente para extraer los dataruns asociados y poder así recuperar su contenido. En el caso de que el fichero sea residente extraerá directamente su contenido de la propia $MFT. A continuación un ejemplo de su uso:

Como vemos, si no especificamos la variable FILES, el módulo únicamente listará ficheros eliminados. Posteriormente, para recuperar los ficheros deseados especificamos sus IDs separados por comas. Tras ejecutar el módulo conseguiremos bajar los ficheros a nuestro loot.

Otra opción para conseguir ficheros sin necesidad de especificar su ID es mediante su extensión. Si estamos interesados únicamente en cierto tipo de ficheros podemos asignar a FILES las extensiones deseadas. Véase el siguiente ejemplo:

Téngase en cuenta que el módulo extraerá el contenido de cada uno de los clusters asociados a dicho fichero. Ya que el fichero está eliminado puede que su contenido haya sido sobreescrito o parcialmente sobreescrito por lo que es probable que consigamos un fichero corrupto (el cual puede ser interesante igualmente desde un punto de vista forense).

Es importante destacar también que el proceso de listar ficheros eliminados en un disco duro de gran tamaño (mejor dicho, con muchas entradas en su MFT) puede ser extremadamente lento; en mis pruebas alrededor de 8-10 entradas por segundo. Debido a esto, con la variable TIMEOUT podremos especificar el número de segundos que invertirá el módulo en buscar ficheros eliminados (por defecto una hora).

En el siguiente vídeo puede verse un ejemplo de su uso:

Mucho se está hablando últimamente de VPN anónimas, y en este post no pretendo descubrir las américas a nadie, pero aún así espero que le pueda ser de utilidad a alguien.

Para ponernos en situación, tengo un servidor contratado en un proveedor extranjero que me ofrece varios servicios, entre ellos una VPN (openVPN) que me permite navegar con una IP extranjera. Hasta aquí ningún misterio, para redirigir todo el tráfico basta con añadir las siguientes opciones a la configuración del servicio:

ifconfig-push IPCliente 255.255.255.0
push "dhcp-option DOMAIN ejemplo"
push "dhcp-option DNS DNS1"
push "route IPRedInterna 255.255.255.0"
push "redirect-gateway def1”

Y ejecutar los siguientes comandos:

echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s IPVPNInterna/24 -o enp1s0 -j MASQUERADE

Sin embargo, como hago uso de cierto tipo de servicios que no están permitidos por mi proveedor, me he visto obligado a recurrir a servicios de VPN anónima (“Internet Private Access” en este caso). Lo cual también permite que mis saltos realicen un segundo salto y que viajen cifrados a dos países distintos antes de salir into the wild, además de burlar el límite de número de distintos dispositivos conectados a la vez (3 en este caso) permitidos por Internet Provider Access.

Entrando en harina, si alguien conecta con la VPN de InternetPrivateAccess con la configuración que ofrecen por defecto de manera remota, lo primero que le va a pasar es que perderá el acceso total a su servidor, ya que se modifican las rutas y los paquetes viajan de vuelta por una salida diferente. Para evitar este comportamiento, antes de conectar nada, vamos a crear la tabla de rutas. En el fichero /etc/iproute2/rt_tables , pondremos:

1 services

Y crearemos un script que se ejecute al arranque del sistema:

#!/bin/bash

ip route add RedServidor/24 dev enp1s0 src IPPublicaServidor table services
ip route add default via GatewayServidor dev enp1s0 table services
ip rule add from IPPublicaServidor/32 table services
ip rule add to IPPublicaServidor/32 table services
ip rule add fwmark 1 table services

ip route flush cache

De este modo, todas las conexiones que lleguen a la IP pública del servidor no pasarán por la VPN de Internet Provider Access, lo que nos permitirá seguir ofreciendo servicios (siempre y cuando funcionen a través de TCP).

Para redirigir el tráfico desde una VPN hasta la otra, bastará con ejecutar:

iptables -t nat -A POSTROUTING -s  IPVPNInterna/24 -o tun1 -j MASQUERADE
# Sólo si antes hemos añadido la ruta anterior: 
iptables -t nat -D POSTROUTING -s IPVPNInterna/24 -o enp1s0 -j MASQUERADE 

Como bonus, decir que es posible abrir puertos en la VPN de Internet Private Access con un software que han desarrollado ellos, pero que por desgracia no tiene soporte para sistemas GNU/Linux. No obstante, se puede realizar un pequeño apaño:

$ cat /home/USUARIO/.pia_client

ID= #Resultado de ejecutar head -n 100 /dev/urandom | md5sum | tr -d " -" 
PORT= #Puerto que nos abre la API de Internet Private Access 
IP="IP” # IP asignada por Internet Private Access

El siguiente script se debe añadir en el crontab (con ejecutarse cada 30 minutos, bastaría):

#!/bin/bash

CONFIG=/home/USUARIO/.pia_client

. $CONFIG

function getIP {

        NEWIP=""

        while true; do
                NEWIP=$(ip addr show dev tun1 | grep inet | awk '{print $2}')
                if [ "$NEWIP" != "" ]; then
                        break;
                fi
                sleep 10
        done

        echo $NEWIP

}

function closePort {
        iptables -D INPUT -i tun1 -p tcp -m tcp --dport $PORT -j ACCEPT
        iptables -D INPUT -i tun1 -p udp -m udp --dport $PORT -j ACCEPT
}

function openPort {
        iptables -A INPUT -i tun1 -p tcp -m tcp --dport $NEWPORT -j ACCEPT
        iptables -A INPUT -i tun1 -p udp -m udp --dport $NEWPORT -j ACCEPT
}

function getPort {
        NEWPORT=$(sudo -u USUARIO -- curl -d 
              "user=USUARIOIPV&pass=PASSWORDIPV&client_id=$ID&local_ip=$NEWIP" 
              https://www.privateinternetaccess.com/vpninfo/port_forward_assignment 2>/dev/null);
        NEWPORT=$(echo $NEWPORT | awk -F'[{:}]' '{print $3}')
        echo $NEWPORT 
}

function replaceConfig {
        sed -i.bak "s/^PORT=.*$/PORT=$NEWPORT/" $CONFIG || exit
        sed -i.bak "s/^IP=.*$/IP=\"$NEWIP\"/" $CONFIG || exit
       #Acciones que queremos hacer tras abrir un puerto
}


NEWIP=$(getIP)
NEWPORT=$(getPort)
if [ "$NEWIP" != "$IP" -o "$NEWPORT" != "$PORT" ]; then
        closePort
        openPort
        replaceConfig
fi

De este modo, cada 30 minutos se verificará que la IP de la VPN y el puerto que nos natea la API son el mismo, y en caso de que cambien se cerrará el puerto viejo y se abrirá el nuevo. No hay que olvidarse de reiniciar aquellas aplicaciones que dependan de los puertos nateados.

Son muchos casos en los que la videovigilancia puede vulnerar la privacidad de las personas. Estos casos pueden generar una cierta controversia. Uno es el caso que me sucedió hace unos pocos días.

Al entrar en un taxi en Madrid me llamó la atención encontrarme con una cámara delante de mis narices. Fue algo que nunca me había ocurrido y no me esperaba. Era una cámara que me enfocaba directamente y la verdad bastante intimidatoria. No me había fijado al entrar pero en las ventanillas del taxi se indicaba mediante unas pegatinas que el taxi estaba videovigilado. A raíz de este hecho me estuve preguntando sobre la regulación de este tipo de cámaras y los requisitos legales que deben cumplir. ¿Qué medidas debe tomar el taxista en este caso? ¿Qué derechos tiene el cliente?
Otra situación similar puede ocurrir con los gimnasios donde las cámaras controlan la seguridad del mismo en las salas generales donde la gente se encuentra realizando ejercicios físicos. ¿Está permitido realizar grabaciones en los gimnasios? ¿Quién lo regula?

En alguna ocasión en este blog Antonio Villalón ha comentado este tipo de vigilancia a través de cámaras [1] [2] [3] [4] pero no desde el ámbito de la protección de datos, por lo que en este artículo queremos acercarnos a esa visión.

Esta es la introducción que realiza la Agencia Española de Protección de Datos (en adelante AEPD) en su Guía de Videovigilancia.

Son varias las leyes o instrucciones las que regulan este tipo de actuación. En primer lugar debemos tener en cuenta la Ley de Seguridad Privada 23/1992, de 30 de julio. Esta ley regula la prestación de servicios de vigilancia y seguridad. Las únicas que podían prestar los servicios de videovigilancia eran las empresas de seguridad que se regulan por esta ley. La llamada ley Ómnibus, Ley 25/2009, de 22 de diciembre, en su artículo 14 modificaba la LSP añadiendo la disposición adicional sexta:

Esta disposición permite a cualquier persona o empresa instalar, vender o mantener un sistema de videovigilancia siempre que la prestadora del servicio no se dedique a otros fines definidos en el artículo 5 de la LSP y no vayan conectadas las cámaras con centrales de alarma. Por tanto en este sentido podemos considerar que hay bastante libertad para el uso de estos elementos de seguridad.
¿Entonces quien protege al ciudadano grabado? ¿Nadie regula la captación de imágenes?

Ahí es donde entra la LOPD. Como he comentado antes, las imágenes que pueden identificar a una persona se consideran un dato de carácter personal por lo que debe ser tratado como tal. A este respecto entra en juego tanto la Ley 15/1999, de 13 de diciembre, de protección de datos de carácter personal, como el Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarrollo de la citada ley. Adicionalmente la AEPD aprobó la Instrucción 1/2006, de 8 de noviembre, sobre el tratamiento de datos personales con fines de vigilancia a través de sistemas de cámaras o videocámaras.

Esta instrucción viene a detallar los casos en los que está permitido utilizar cámaras para la vigilancia. A este respecto se especifica a lo largo de toda la instrucción el deber de respetar el principio de proporcionalidad, “lo que supone siempre que resulte posible, adoptar otros medios menos intrusivos a la intimidad de las personas.” Este deber de proporcionalidad no dejar de ser un tanto indeterminado por lo que a continuación la propia instrucción intenta clarificar mencionando una Sentencia del Tribunal Constitucional 207/1996: “una exigencia común y constante para la constitucionalidad de cualquier medida restrictiva de derechos fundamentales, entre ellas las que supongan una injerencia en los derechos a la integridad física y a la intimidad”.

Personalmente considero que el principio de proporcionalidad sigue quedando bastante indeterminado y ambiguo.

Dejando los casos a un lado, y asumiendo que cualquier persona u organización puede instalar videovigilancia veamos qué medidas debe cumplir. En primer lugar, y como ya he mencionado, debería registrar el fichero ante la AEPD como cualquier otro fichero con datos de carácter personal.

En segundo lugar el responsable de los sistemas de videovigilancia deberá tomar las medidas de seguridad exigidas por la LOPD, al menos las de nivel básico. En ninguna de las citadas leyes o normativas especifica el nivel de los datos que son las imágenes por lo que también queda bastante en el aire las medidas que debe contener. La guía de videovigilancia de la AEPD deja en manos del responsable del fichero la evaluación del nivel de seguridad teniendo en cuenta el artículo 81 del RDLOPD en función del contenido y finalidad del fichero. Una secuencia de imágenes o un vídeo puede ofrecer una definición de las características o de la personalidad de un ciudadano. ¿Deberían ser declarados todos los ficheros como nivel medio? ¿Y si los grabados son menores? ¿Demasiada ambigüedad para un tema tan sensible?

En tercer lugar tienen el deber de información que tienen todos aquellos que utilizan videocámaras para la vigilancia. Esta identificación se regula en el Anexo de la instrucción 1/2006.

Por tanto a pesar de la controversia que puedan crear, las cámaras en los taxis es una práctica utilizada cada vez más, pudiendo realizarse siempre y cuando se cumpla con la “proporcionalidad” en la recogida de los datos y cumpliendo con las medidas exigidas por la LOPD. En cuanto a los gimnasios, la ley también deja lugar a interpretaciones, aunque la guía de videovigilancia de la AEPD da un poco de luz, y cito: “En espacios como gimnasios, balnearios o “Spa” etc., pueden captarse imágenes susceptibles de afectar a los derechos a la intimidad, a la propia imagen y a la protección de datos. Deberán tenerse en cuenta estas circunstancias respetando tales derechos no captándose imágenes de personas identificadas o identificables en los lugares en los que se realiza materialmente la práctica deportiva o se reciban este tipo de servicios.”

Más allá de todo esto considero que la normativa en materia de videovigilancia a día de hoy no está regulada como debería y da lugar a muchas interpretaciones.

¿Qué piensan los lectores de SecurityArtWork? Podéis compartir en los comentarios cualquier anécdota u opinión respecto a la seguridad.