¿Hasta donde llega Google con nuestra información? Una experiencia personal

Hace unos días atrás, durante un fin de semana largo, tomé unas vacaciones en la ciudad de Mar del Plata (Argentina) junto a unos amigos. Días antes, hubo un cruce de correos con diferentes hoteles de la zona preguntando por la disponibilidad y tarifas para los días comprendidos. 

Ya es sabido por el propio Google que nuestra información, de alguna forma, es indexada por la afamada compañía. Incluso es declarado, que también se analiza la información enviada a través de correo para luego poder publicitar "a medida" y de esa manera tener una mayor tasa de éxito.

El viaje

Tal como indiqué anteriormente, hubo un correo particular con el hotel seleccionado para confirmar la reserva. A continuación se adjunta parte del correo.

Crónicas de Heartbleed: ¿Una vulnerabilidad del pasado?

Ya todos conocen la afamada vulnerabilidad que dieron a conocer como Heartbleed. Afortunadamente, tuve la suerte de poder brindar una pequeña charla en el OWASP Latam Tour 2014, en su capítulo de Argentina (Buenos Aires), sobre esta interesante vulnerabilidad.

Preparando esta charla, pude indagar un poco más profundo sobre la naturaleza de Heartbleed y dónde radicaba la falla. Esta vulnerabilidad fue descrita en detalle en muchos otros medios, por lo que intentaré darle un enfoque técnico pero distinto, además de contar algunas curiosidades durante el camino de la pequeña investigación.

Paso a paso del exploit

El exploit que surgió al poco tiempo de publicada la vulnerabilidad tuvo gran repercusión. Es por eso que creo que vale la pena explicarlo un poco más en detalle con el fin de poder comprender mejor su funcionamiento.

En primera instancia, el protocolo de HeartBeat es utilizado principalmente para prolongar la vida de una sesión HTTPS. Esta funcionalidad permite comprobar que el servidor está vivo y como parte de su funcionalidad, devuelve el payload que envió el cliente durante la petición.

La estructura de Heartbeat según el RFC 6520 puede observarse en la siguiente imagen:

El primer campo corresponde al tipo del mensaje. Existen dos tipos válidos, request (1) y response (2).  El segundo campo corresponde al tamaño del payload, y el tipo es un entero no signado de 16 bits. De allí se deduce que el máximo valor en memoria que se puede obtener es de 64 kb o 2^64.

El tercer registro corresponde al propio payload. Este mismo payload es el que vuelve como parte de la respuesta. Finalmente, el cuarto registro corresponde al padding, que son bytes que se utilizan a modo de relleno y son ignorados por el servidor.

El exploit no hace más que aprovechar el diseño de esta funcionalidad. Básicamente, envía una petición con un payload muy corto pero indicando un tamaño muy largo en el campo length. Y es aquí donde radica la falla. El servidor no calcula el tamaño del payload enviado por el cliente, y de alguna manera "confía" en el tamaño que se le indica. De esta forma, retorna el propio payload más el contenido correspondiente al tamaño indicado por el cliente.

En ese espacio de memoria puede encontrase información en texto plano, cómo por ejemplo, cookies de sesión o credenciales, entre otras alternativas.

Existen varias versiones vulnerables de a Heartbleed que se encuentran muy bien detalladas en el propio sitio de Heartbleed Bug.

SNMP: Impacto de una mala configuración sobre un protocolo simple

En estos días me surgió la necesidad de comenzar a profundizar sobre el protocolo SNMP (Simple Network Management Protocol). Este es un protocolo antiguo pero ampliamente utilizado para realizar tareas de monitoreo y administración sobre diferentes tipos de dispositivos. Cómo todo protocolo que ofrece este tipo de funcionalidades, siempre existe el riesgo de poder facilitarle la vida a un atacante si el mismo no se encuentra debidamente configurado.

No es mi intención profundizar sobre la naturaleza del protocolo ya que existe muchísima documentación que describe de forma muy detallada al mismo. Sin ir más lejos, recomiendo la lectura del RFC 1157, donde se declaran todas las bases del protocolo SNMP.

Básicamente, el riesgo reside en como se configura tanto la comunidad "public" como aquella denominada "private". La primera de ellas suele utilizarse para realizar la lectura de la configuración actual del dispositivo. La segunda para realizar escrituras, y por transición, una modificación de la misma. De esta forma, estas validaciones se realizan a través de strings o cadenas. 

Existen diversos scripts en la red que pueden utilizarse sobre estos dispositivos con este tipo de configuración. En este caso, utilizaremos algunas herramientas ya incluidas en Kali Linux; particularmente en esta ocasión, serán ciertos módulos auxiliares que provee Metasploit. 

Mediante el módulo de snmp_login se puede realizar fuerza bruta, tanto sobre los strings de lectura como sobre los de escritura. Para ello utiliza un pequeño diccionario con aquellas strings más comunes, incluidas también en Kali Linux.

En este caso, se obtuvieron los strings correspondientes de sólo lectura ("public") y lectura-escritura (¨pr1v4t3"). Ahora es posible enviar una petición del tipo GET y GET NEXT para obtener todo el árbol de configuración del dispositivo. Para esta tarea, se ejecutó otro módulo de auxiliar de Metasploit llamado snmp_enum obteniendo una gran cantidad de información del sistema.

El servicio SNMP escucha sobre el puerto 161 por defecto y responde a través de paquetes UDP. De esta forma, luego de la ejecución del módulo auxiliar de Metasploit, se puede obtener información detallada del dispositivo.

Ingeniería reversa de firmware: Análisis de vulnerabilidad del router D-link DIR-300

Anteriormente se dio a conocer una vulnerabilidad sobre los routers D-link DIR-300 y DIR-600. En su momento, realicé un análisis sobre esta vulnerabilidad descubierta por Michael Messner en We Live Security, mostrando con ejemplos prácticos cuál podía ser el alcance de la misma. Sin embargo, en esta ocasión vamos a avanzar un poco más profundo aplicando ingeniería reversa sobre el firmware del router D-link DIR-300 para demostrar como analizar el mismo y ver en mayor detalle la vulnerabilidad a nivel de código.

Extracción del firmware

Una vez que se descargó el firmware del sitio web de D-link (versión vulnerable -  2.12 build 18.01.2012), se requiere un análisis previo ya que el mismo no puede legible por el formato que posee.

Cómo primer paso, se utiliza binwalk, una herramienta ampliamente utilizada a la hora de analizar diferentes tipos de firmware. Ejecutando binwalk sobre el archivo del firmware, se obtiene la siguiente respuesta:

La herramienta identificó diferentes tipos de cabeceras. En este caso, la que realmente nos importa es la última de ellas, la cual es un filesystem Squashfs (muy común en sistemas embebidos en routers). El paso siguiente es extraer la misma para luego analizarla. Para ello utilizaremos la herramienta dd, la cual es capaz de llevar adelante esta tarea.

A dd se le debe brindar cierta información para que realice la extracción correcta y no obtengamos un archivo corrupto (esto suele ser un dolor de cabeza en más de una ocasión). 

Expliquemos cada uno de los parámetros:

• if: Archivo de origen.
• bs: Cantidad de bytes que se leerán de forma simultánea.
• skip: Establece el offset en cantidad de bytes. Este valor es el obtenido con binwalk.
• of: Archivo de salida.

Client side controls: El problema de confiar la seguridad sobre el cliente

La seguridad sobre los formularios web siempre han sido considerados como un vector válido para llevar a cabo ataques por parte de los ciberdelincuentes. La seguridad de los mismos no debe tomarse a la ligera y es por ello que hoy presentaré uno de los errores típicos de validación de datos de entrada desde el lado del cliente.

En la actualidad es común encontrar sitios web que permiten validar los datos ingresados desde el lado del cliente. Esta actividad es más que válida y además permite reducir considerablemente el tráfico sobre aquellos servidores que realizan las operaciones. Sin embargo, es importante que la seguridad de los datos que serán ingresados en el formulario en cuestión no sean confiados únicamente a la validación de los mismos desde el lado del cliente.

¿Por qué no es suficiente la validación desde el lado del cliente a nivel de seguridad?

Suponiendo que el escenario es el planteado, un atacante podría evadir la validación desde el lado del cliente, pudiendo de esa forma realizar el ataque contra el servidor. Muchos sitios web controlan que no se ingresen caracteres especiales a fin de evitar inyecciones SQL, ataques XSS o similares. Sin embargo, si el atacante evade ese control, podría llevar a cabo el ataque contra el servidor de forma exitosa.

En la siguiente captura, puede observarse el código correspondiente a un formulario con diferentes controles de seguridad desde el lado del cliente.

Si se ingresan datos inválidos, veremos como se ejecuta un alerta e impide el envío de dichos datos al servidor.