Archivo de la categoría: Podcast

Podcast – 40 – Whaling

En el capítulo de hoy recupero un artículo de 2016 para convertirlo en audio para los seguidores del podcast. Como los oyentes de podcast no suelen acceder al blog, pues aquí les traigo el blog en audio.

Whaling
Fuente imagen: condiesit.co.uk

La definición de whaling sería aquel conjunto de técnicas de phishing que buscan atacar objetivos concretos de gran valor, pero para no repetirme os dejo el audio.

Podcast – 39 – Deep Packet Inspection

El capítulo de hoy ha surgido tras atender una charla comercial vía videoconferencia donde el presentador repetía una y otra vez la gran capacidad de Deep Packet Inspection de su solución. Pero, ¿seguro qué sabía lo que es, en realidad, Deep Packet Inspection?

Fuente imagen: AltenCalSoftLabs

Técnicamente hablando la denominación Deep Packet Inspection, que ha ganado bastante fuerza en el mundillo comercial y del marketing, debe utilizarse para una familia de técnicas de análisis de tráfico en el que lo que se examina no es la cabecera sino la información enviada en el paquete de datos.

Un firewall tradicional, de lo que sólo miran la tupla clásica (es decir, IP origen/destino, los puertos origen y destino; y el protocolo utilizado) tiene suficiente con mirar las cabeceras para tener toda la información necesaria para realizar su trabajo, así que estos equipos no revisan el campo de datos de los paquetes IP que gestionan. En cambio, los actuales firewalls con capacidad de seguimiento de protocolos, o lo que comercialmente se llama Next Generation Firewall, al analizar el comportamiento del protocolo necesitan analizar el campo de datos de los paquetes para tener la información necesaria. Por ejemplo, un Next Generation Firewall al gestionar el protocolo FTP permite la primera conexión al puerto 21 y luego analizará esa conexión para saber qué puerto aleatorio se ha elegido para empezar la transmisión. Así el firewall permitirá una conexión en un puerto aleatorio que, en situación normal no hubiera permitido.

Otros ejemplos clásicos son los sistemas de seguridad WAF o IDS/IPS, ya que su función es precisamente analizar las peticiones que llegan a los sistemas y revisa si las solicitudes son correctas o malintencionadas. Así que estos sistemas deben revisar el campo de datos de los paquetes y datagramas que circulan por la red.

Los proxies de navegación pueden parecer un ejemplo claro de inspección de profunda de paquetes, ya que su función es revisar las direcciones web consultadas para poder aplicar las políticas definidas por los administradores (control de acceso, categorización, etc.), su inclusión o no dentro de esta categoría en función de la arquitectura de uso. Es decir, si en nuestra empresa tenemos un proxy de navegación conocido por todos y nuestros sistemas operativos están configurados para utilizarlo, no podemos considerar que ese proxy entre dentro de la categoría ya que no se está analizando el tráfico de la red, sino que se lo enviamos conscientemente. Aquí tenemos una comunicación cliente-servidor tradicional. Si configuramos un proxy de navegación transparente que capture el tráfico sin que el cliente lo sepa, sí que entraríamos en nuestra categoría: tenemos un equipo no detectado por cliente o servidor que analiza los campos de datos y no sólo la cabecera.

Obviamente las capacidades de obtención de información de análisis los sistemas de Análisis Profundo de Paquetes son muy útiles en funciones de seguridad y, por ello, se utilizan mucho, pero la próxima vez que un comercial os cante las bondades de la Deep Packet Inspection.. preguntadle qué hace exactamente su sistema y porqué es novedoso… porque muchas veces las técnicas de recolección de datos son las mismas y lo que cambia de una solución a otra es cómo trata la información y qué hace con ella.

Podcast – 38 – Ataques a contraseñas hasheadas

Fuente imagen: Sifi Feefer

Recientemente recibí un correo electrónico de un proveedor avisándome de que debido a un acceso no autorizado a sus servidores un atacante se había hecho con la información de mi usuario y su correspondiente contraseña hasheada. En ese mismo correo aseguraban que la contraseña estaba protegida por la función de hash por lo que el atacante no podía descubrirla, pero aún así me obligaban a cambiarla… ¿No es esto una incongruencia? ¿Si está a salvo por qué me obligan a cambiarla?

Dejando de lado el dicho de que ‘más vale prevenir que curar’, la verdad es que una contraseña bien hasheada está bien protegida, pero no perfectamente protegida… y los crackers tienen técnicas para realizar ataques a contraseñas hasheadas y averiguarlas. Veamos las tres principales.

Aunque hablé más a fondo sobre cómo almacenar contraseñas de forma segura en el capítulo 11, podemos resumir la operativa de almacenamiento sería aplicar una función hash sobre la contraseña recibida y almacenar únicamente el resultado de la función hash. NUNCA deberíamos guardar la contraseña sino únicamente el resultado de la función hash. Sabemos que una función hash es un sistema de un solo sentido de tal forma que una misma cadena de entrada siempre devuelva el mismo resultado, pero que sea “computacionalmente imposible” obtener la cadena de entrada (es decir, la contraseña) teniendo únicamente la salida.

Ataques a contraseñas hasheadas

  1. La primera opción sería un ataque de fuerza bruta para conseguir encontrar qué contraseña genera un hash como el obtenido. Así el atacante tan sólo debe probar todas y cada una de las posibles combinaciones de caracteres para ver si el resultado de aplicarle una función hash es igual al de nuestra contraseña. Como entenderás se trata de un proceso que requiere de una capacidad de computación importante, sobre todo si usamos contraseñas largas e incluimos caracteres no alfanuméricos. Aunque es un proceso que con el tiempo será efectivo (en algún momento probará nuestra contraseña) no es muy eficiente en tiempo (pueden pasar años o siglos para localizar una password compleja), por lo que no es muy común su uso (salvo que sepamos a ciencia cierta que la contraseña es corta).
  2. Otra opción es aplicar la función de hash a un grupo concreto de contraseñas que tengamos almacenadas y ver si alguna coincide con el hash que queremos descubrir. Se suele denominar diccionario al listado de claves que queremos comprobar. Existen multitud de diccionarios con las contraseñas más utilizadas; combinaciones de palabras y números comunes; expresiones de uso común en casi cualquier idioma; etc… con lo que se puede sacar una lista de contraseñas probables. Entonces se cogen todas estas claves posibles (los listados puedes ser miles o millones de combinaciones) y se aplica la función de hash a cada una de ellas comparándola con la de la contraseña que queremos romper. Los ataques de diccionario son muy útiles cuando el atacante ha conseguido un gran listado de hashes sobre los que comparar. Pensad en las noticias de filtraciones de grandes empresas con miles o millones de usuarios: es muy probable que dentro de esos millones de usuarios haya centenares o miles de ellos que utilicen como contraseña una de las incluidas dentro del diccionario inicial. Así pues, los ataques de diccionarios son un sistema eficiente de encontrar alguna contraseña en un listado grande de víctimas, aunque no tanto cuando se busca una contraseña en concreto (aunque cómo son rápidos de ejecutar, es probablemente el primero que un atacante intente).
  3. La tercera estrategia que se encuentra en un punto intermedio, computacionalmente hablando, entre las dos anteriores los las denominadas rainbow table (aunque en español se llamarían «tablas arcoíris«, la verdad es que nunca las he oído llamar así). Se trata de tablas de hash precompiladas, específicas para cada protocolo, que relacionan distintas contraseñas con sus correspondientes hashes, aunque la relación no es uno-uno como sería el caso de los ataques por diccionario, sino que incluyen una serie de pasos intermedios que no son almacenados pero que son accesibles con los datos de la tabla. Así tenemos un sistema que implica una mayor necesidad de computación que los ataques de diccionario, pero muchísimo menos espacio de almacenamiento. A grandes rasgos podemos decir que una rainbow table aplica dos funciones (la de hash y otra denominada de reducción) varias veces de tal forma que el resultado de una función sirve como entrada de la siguiente ronda. Finalmente, tras las rondas correspondientes se almacena únicamente la entrada inicial y el resultado final, pero no los resultados intermedios. En el momento de querer sacar una contraseña se aplican las funciones de hash y reducción según el algoritmo de la tabla de reducción, permitiendo la detección de la contraseña correcta no sólo por las dos columnas almacenadas, sino también por los resultados intermedios que son calculados al vuelo. El procedimiento y las funciones utilizadas dependen de cada ‘tabla arcoíris’.

Como ves, los atacantes tienen estrategias para conseguir sacar la contraseña real del hash obtenido, y es por ello que las empresas afectadas por este tipo de filtraciones solicitan, u obligan, a sus usuarios a cambiar su contraseña de acceso: porque el atacante no tiene ahora mismo la contraseña pero puede llegar a tenerla (sobre todo si usamos claves cortas o que usen palabras/combinaciones comunes).