CVE-2023-51119: fallo en el control de autorización en routers D-Link DIR-605L
Hola a tod@s, amantes y freaks de la seguridad informática. Hoy os traigo un artículo sencillo pero curioso. Estaba haciendo researching con routers y puntos de acceso WiFi antiguos cuando me topé con una vulnerabilidad a tener en cuenta.
Resulta que un amigo (gracias Sergio) me regaló un punto de acceso wifi de la marca D-Link para que jugara con él. En concreto el modelo DIR-605L (Hardware Version B2, firmware 2.13). Que tiene este aspecto:
Así que me puse a hacer pruebas con él y a probar diferentes vectores de ataque allá por finales de Diciembre de 2023.
Encontré una vulnerabilidad bastante grave en mi opinión. Trataré de explicarlo para que se entienda bien…
Tras analizar las diferentes peticiones http con la herramienta BurpSuite, observé que cualquiera de ellas, no llevaba una cookie de sesión como tal, algo extraño pues normalmente ya sabéis cómo funciona: haces login se setea una cookie y con esta, puedes hacer acciones que requieran estar autenticado. Bien, pues observé que tras hacer login, las peticiones no llevaban ninguna cookie. ¿Es un poco raro verdad? Así que decidí investigar en esta línea.
Tras hacer un reset al router/AP a su configuración de fábrica, al entrar en su panel de configuración web (IP por defecto 192.168.100.1), este pide crear una contraseña. Es decir que no tiene una contraseña por defecto como otros routers o puntos de acceso wifi, te obliga a poner una nueva siempre al principio, lo cual en mi opinión es una buena práctica.
Una vez hemos puesto una contraseña y entrado en él, curioseando las peticiones, extraje algunas importantes. Nos centraremos en la que precisamente desde la configuración sirve para cambiar la contraseña del usuario admin. Este sería el panel web donde se hace dicho cambio:
Poniendo cualquier cosa como contraseña, por ejemplo “testing12345”, la petición en BurpSuite se ve de esta manera (la contraseña se envía codificada en base64, en este caso sería dGVzdGluZzEyMzQ1):
Esta petición como comentábamos, no parece llevar ninguna cookie. Lleva unas cabeceras que son totalmente superfluas. Se pueden quitar todas y la petición sigue funcionando igual de bien. Además, en la misma ventana además de la password hay otros campos que se envían. Estos también se pueden quitar y podemos reducir la petición de cambio de contraseña en su mínima expresión.
Extrayendo la petición a un comando curl y reduciendo hasta dejar solo lo necesario para un cambio de contraseña, la petición quedaría así de sencilla:
curl -X POST -i –data-binary ‘settingsChanged=1&config.login_name=admin&config.password=dGVzdGluZzEyMzQ1’ http://192.168.100.1/goform/formSetPassword
Si lanzamos esta petición curl así por las buenas, observamos que no funciona. El servidor web responde con un código 302 redirigiendo a index.html que es una página que a su vez redirige a index.asp e indica que hay que hacer login.
Entonces… ¿por qué estas mismas peticiones sí funcionan desde la propia web de configuración?
Al principio pensaba que podía ser la cabecera Referer, pero comentaba antes, tras hacer unas pruebas con BurpSuite interceptando la petición y borrándola observé que sin ella funcionaba igual. Y lo mismo con el resto de cabeceras.
Al final la conclusión es muy sencilla y muy triste a la vez, ya que resulta existir un pésimo control de la autorización en el panel web de este punto de acceso. Lo descubrí un poco casi por casualidad ya que mientras estaba haciendo pruebas en el panel web con BurpSuite, lancé el curl y esta vez funcionó:
Fijaos en que esta vez me ha redirigido a otro sitio (apply_setting.asp). Y luego pude comprobar que efectivamente el cambio de contraseña se había hecho efectivo.
¿Por qué esta vez ha funcionado? es tan simple como que la he lanzado mientras el admin tenía una sesión activa en la página. Si cierro la sesión en la web de configuración, el curl deja de funcionar, y en cuanto hago login, el curl comienza a funcionar de nuevo. Eso significa que su control de autorización (por llamarlo de alguna manera) es tan simple como que cuando se hace login en el panel web de configuración, es como que se activa en el back-end una especie de flag interno para que cualquier petición funcione, y cuando se hace logout o se pierde la sesión, ese flag interno se deshabilita. La verdad es que sin ver el código fuente asp de la página es difícil saberlo, pero en cualquier caso, sabemos que esto es una muy mala práctica.
Explotar esto en un escenario real no sería muy difícil. Solo habría que crear un script que monitorizase el punto de acceso hasta que un admin abriese una sesión legítima y en ese momento podríamos cambiar la contraseña y hacer un takeover de su cuenta. Por lo tanto me parece una vulnerabilidad digna de ser reportada.
Como parte del responsable disclosure, hablé con el Mitre para la obtención de un CVE y con D-Link que gentilmente contestó reconociendo el fallo de seguridad publicando este boletín y dándome los créditos del descubrimiento:
https://supportannouncement.us.dlink.com/announcement/publication.aspx?name=SAP10368
Hay que remarcar que esto se descubrió en Diciembre de 2023 y al parecer apenas un mes antes, el producto había alcanzado lo que ellos llaman EOL/EOS (End Of Life/End Of Support). Es decir, resumiéndolo mucho quiere decir que no van a sacar un parche ni van a arreglarlo y que su única recomendación sobre el producto es no usarlo.
Llegados a este punto, el CVE asignado fue el CVE-2023-51119, y crear un exploit en Python3 fue sencillo. Aquí lo tenéis publicado:
https://github.com/OscarAkaElvis/CVE-2023-51119
Aquí tenéis un vídeo con la PoC (Proof of Concept) o prueba de concepto para que veáis que el exploit funciona perfectamente:
Por si alguien es curioso sobre el disclosure timeline, decir que estas cosas nunca son sencillas y siempre suele haber problemas con alguna de las partes… o bien el vendor no hace caso, o bien el Mitre no hace caso, o como esta vez que ExploitDB no me hizo caso para publicar el exploit a pesar de tener ya otro publicado con ellos (aunque esto tampoco es determinante)… en fin, siempre falla algún eslabón de la cadena. Además, las cosas suelen ir lentas. Podríamos decir que en este proceso todo fluyó esta vez más o menos bien.
Disclosure timeline:
- 11/12/2023: Vulnerability was discovered
- 12/12/2023: Reported to Mitre
- 20/12/2023: No answer yet from Mitre, reported to D-Link as part of responsible disclosure
- 22/12/2023: Vulnerability confirmed by D-Link, won’t fix announcement published (https://supportannouncement.us.dlink.com/announcement/publication.aspx?name=SAP10368)
- 23/12/2023: Vendor’s announcement link shared to Mitre
- 04/01/2024: Mitre assigned CVE number (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-51119)
- 07/01/2024: Public disclosure (https://twitter.com/OscarAkaElvis/status/1744042753707712916)
- 08/01/2024: Exploit creation and PoC video created (https://twitter.com/OscarAkaElvis/status/1744452649011892566)
- 08/01/2024: Exploit sent to Exploit-db, no answer
- 21/04/2024: Exploit released on GitHub (https://github.com/OscarAkaElvis/CVE-2023-51119)
Y colorín colorado, este cuento se ha acabado…
Contribución gracias a Óscar Alfonso Díaz aka OscarAkaElvis
Spam bonus tracks!
Última reléase de Airgeddon v11.30 que soporta multi-instancia y por tanto lanzar varios a la vez para por ejemplo atacar con dos ataques evil-twin las bandas de 2.4ghz y 5ghz simultáneamente u otros ataques en paralelo por el estilo.
https://github.com/v1s1t0r1sh3r3/airgeddon
Estad atentos, porque en breve se publicará una versión nueva de Evil-WinRM. Una herramienta de Hackplayers en la que colaboro, y que aunque es cierto que no tiene mucha actividad, al menos si está mantenida y pronto saldrá con algún feature nuevo una versión nueva (la 3.6).
Powered by WPeMatico
