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.

Apache HTTP Verb Tampering: el karma de una mala configuración

A la hora de implementar servidores web, Apache sigue siendo la elección para la mayoría de los administradores. La razón es más que obvia; Apache se destaca por su estabilidad y facilidad a la hora de configurar el mismo. Sin embargo, siempre debe tenerse en mente que quizás una mala configuración podría derivar en un ataque exitoso por parte de un atacante. En esta ocasión profundizaremos sobre un caso común de mala configuración sobre Apache que puede derivar en un tipo de ataque conocido como HTTP Verb Tampering.

En muchos servidores web se suele definir ciertas secciones que contienen información privada o que no es accesible para el público. Los administradores suelen elegir cómo método de validación diferentes características. Una de las más utilizadas es a través de htaccess, donde la validación se realiza a través de este mecanismo. En la siguiente imagen puede apreciarse un archivo htaccess con las características mencionadas, limitando el acceso a usuarios autorizados.

Sin embargo, si se presta mayor atención, puede observarse que existe un error común en este tipo de configuraciones. El concepto de proteger información es correcto, pero en este escenario se está protegiendo un tipo de petición, formalmente las peticiones de tipo GET. De esta manera, cualquier persona que ingrese mediante un navegador a dicha sección, se le requerirá que inicie sesión para poder ver el contenido privado.