Cómo encontramos cinco vulnerabilidades en los Router D-Link 859

En el Centro de Investigación de Seguridad de Telefónica Chile decidimos realizar una búsqueda de vulnerabilidades en dispositivos que pudiesen presentar algún tipo de riesgo, de fácil acceso y consumo masivo a través de artefactos no necesariamente costosos ni robustos y que estuviesen al alcance de cualquier usuario común. Teniendo presente esta idea, miramos nuestro espacio de trabajo y centramos nuestro foco en el Router D-Link modelo DIR859 del que disponíamos.

Las características de este router son bastante básicas. Se trata de un dispositivo común para tener WiFi en un hogar o en una pequeña oficina. Esta simplicidad reduce considerablemente los vectores de ataque pero a su vez dificulta la búsqueda de vulnerabilidades para dicho equipo.

Quisimos llevar este dispositivo a otros escenarios para comenzar a investigarlo. El primer paso fue leer su manual por si encontrábamos algo interesante y después hicimos un pentesting a toda la aplicación web para intentar encontrar algún bypass o lo que siempre se espera encontrar: una “ejecución de código” en uno de sus módulos.

Buscando la ejecución con fuzzing

Para esta primera instancia del análisis utilizamos técnicas de fuzzing a un nivel más de usuario, como por ejemplo sus servicios, protocolos y aplicaciones web. Las automatizamos con un pequeño desarrollo llamado BurpFuzz, un plugin para BurpSuit que permite crear plantillas a elección para el fuzzer “Boofuzz” de cada solicitud capturada.

Después de un par de semanas jugando con los fuzzer no encontramos vulnerabilidades críticas, sólo de baja severidad. Así que el siguiente camino fue realizar un análisis más dinámico y a bajo nivel (Reversing/Assembly).

***Reversing* del *firmware***

Empezamos buscando la última versión de firmware “1.06b01 Beta01” que utilizaba el dispositivo. Tras descargarlo, procedimos a descomprimir el archivo para obtener su estructura de archivos e iniciar un nuevo análisis, búsqueda de credenciales por defecto, servicios ocultos, claves privadas…

Después de todo este tiempo sólo obtuvimos un par de corrupciones en binarios que se ejecutaban desde Busybox y que no eran herramientas del Router propiamente dichas.

Pero seguimos mirando un poco más hasta que dimos con el binario “/htdocs/cgibin”. Este binario maneja los valores, en gran parte, como variables de entorno y es el intermediario entre la aplicación web, el servidor y los códigos fuentes.

Después de entender la función que cumple este binario, pudimos interceptar de forma precisa solicitudes de distintos tipos como HTTP/UPnP y métodos únicos que son utilizados por estos protocolos. Analizando un par de solicitudes nos dimos cuenta de que ciertos valores eran procesados por el este archivo “/htdocs/cgibin”. Desde este punto aplicamos técnicas de ingeniería inversa para poder entender dónde y cómo eran manejados estos valores por el binario.

Con las horas, días y semanas que dedicamos al análisis, sentíamos que estábamos cerca de algo importante y seguimos comprendiendo más y más sobre cómo operaba el router con cada depuración. De esta manera pudimos identificar finalmente las funciones (genacgi_main(), ssdpcgi_main() y phpcgi_main()) que validaban los valores mencionados anteriormente y que controlábamos. Por fin lo habíamos encontrado.

Nos centramos en las funciones sospechosas (y vulnerables)

Ahora explicaremos de forma breve las funciones que encontramos y que además nos permitieron obtener una “ejecución de código remoto (RCE) no autenticado y filtración de información no autenticado” en el dispositivo:

La función genacgi_main() permite recibir solicitudes de suscripción con el método SUBSCRIBE y notificar eventos generales entre dispositivos. Utilizando el mismo método más una variable “service” que es enviada en la URI, nosotros podemos reemplazar su valor para obtener una ejecución de código remoto.
La función ssdpcgi_main() realiza un descubrimiento de servicios utilizando el método M-SEARCH. Cuando se realiza una solicitud de descubrimiento, ésta contiene en su cabecera el valor de ST, que se utiliza para buscar un target. Esta búsqueda de target permite la ejecución de código al concatenar un comando al valor de búsqueda.
La función phpcgi_main() procesa todas las solicitudes HTTP de tipo HEAD, GET o POST. Dentro de estas solicitudes existe una validacion de sesión de usuario, la cual se puede evitar agregando un nuevo valor a la variable AUTHORIZED_GROUP, de manera que podemos obtener lecturas de archivos como configuraciones de acceso o VPN.

Puedes saber más sobre el protocolo UPnP y su arquitectura aquí. Pero estas funciones afectadas se encontraban, por supuesto, en más productos, como se detalla en esta imagen:

Tras avisar al fabricante, los CVE-ID asociados a las vulnerabilidades (que ya disponen de parche) son:

CVE-2019-20217 – (afecta variable SERVER_ID método M-SEARCH).
CVE-2019-20216 – (afecta variable REMOTE_PORT método M-SEARCH)
CVE-2019-20215 – (afecta variable HTTP_ST método M-SEARCH)
CVE-2019-17621 – (afecta variable REQUEST_URI método SUBSCRIBE)
CVE-2019-20213 – (afecta variable AUTHORIZED_GROUP)

A continuación te dejamos una lista de enlaces con un análisis en profundidad y detallado de las vulnerabilidades de ejecución de código e Information Disclosure no autenticado.

Let’s Encrypt revoca tres millones de certificados por culpa de (bueno, casi) un «&» en su códigoScratch, programación al alcance de todos (parte 3)