Hace unos meses cambié mi antiguo router TP-LINK por uno de la marca ASUS. Es el primer dispositivo que tengo de ese fabricante, pero ya que lo recomendaba la operadora que tengo contratada decidí comprármelo para evitarme complicaciones.
Entonces llega una tarde de aburrimiento, o quizás por costumbre, y empiezas probando una comita aquí, un marquee como nombre de la red wifi, intentas concatenar un comando en el formulario de los tests de la red y así un largo etcétera. Al final, una cosa lleva a otra, te vas liando, y cuando eres consciente tienes Burp o ZAP abierto, te has repasado medio OWASP y llevas horas buscando algo con lo que jugar, algo interesante para ver cómo de seguro es tu nuevo y flamante router.
Entrando en detalles algo más técnicos, el router que adquirí es un ASUS DSL-N14U B1 cuyo firmware, en el momento en que se realizaron las pruebas, se encontraba en la versión “1.1.2.3_345” publicado el 04/09/2017.
En cuanto a las vulnerabilidades encontradas, la primera aunque la más aburrida, es un Cross Site Scripting (XSS) que aparece cuando se accede a un recurso inexistente sin haber iniciado sesión en el router. Concretamente ocurre al cargar la página de error resultante, y es en ésta donde se inyectara el código JavaScript.
Por ejemplo, al acceder al recurso:
https://<IP>/%22%3E%3Cscript%3Ealert(window.location.path)%3C/script%3E
El código HTML de la página de error resultante es la siguiente:
Siendo ejecutado el código que conforma el recurso accedido:
Sobre la siguiente vulnerabilidad, durante las pruebas relacionadas con el análisis de seguridad web, una buena práctica es revisar todos los recursos que requieren de autenticación para ver si alguno de ellos, debido a una mala configuración o un descuido, realmente no requiere de esta.
En el caso de dicho dispositivo, uno de los pocos recursos que he identificado, y quizás uno de los más relevantes, es el de cambio de contraseña. Es decir, si se conoce como está formada la petición, es posible cambiar las credenciales de acceso de cualquier usuario como puede ser el usuario Administrador. Además, dichos privilegios se aplican a otras funcionalidades del router como es el servicio AiCloud del que hablaremos más adelante.
Siendo la petición de cambio de contraseña la siguiente:
Basta con modificar el campo http_passwd para modificar la contraseña del usuario administrador (admin). Esto implica que cualquier usuario que tenga acceso a la interfaz web de la aplicación puede cambiar la contraseña de cualquier usuario de ésta, y acceder al panel de administración del router.
Para simplificar el “complicado” proceso, el siguiente script en Python (3) nos permite cambiar la contraseña de administrador si ésta se nos ha “olvidado”:
Para ejecutar el script basta con pasarle como argumentos la ip, el usuario y nuevo password a establecer. Por ejemplo:
python3 asus-passReset.py https://192.168.1.1 admin raccoon
Pese a que la vulnerabilidad anterior es la más crítica, revisando uno de los servicios que ofrece ASUS en sus dispositivos, encontré un par de vulnerabilidades curiosas. El servicio en cuestión es AiCloud que en palabras de la propia ASUS permite:
“ASUS AiCloud te mantiene conectado a tus datos siempre que tengas una conexión a Internet. Conecta tu red doméstica y tu servicio de almacenamiento web en línea, y te permite acceder a los datos desde la aplicación para dispositivos móviles AiCloud de tu smartphone iOS o Android, o a través de una URL personalizada que introduces en tu navegador web…”
Dicho servicio, deshabilitado por defecto, es accesible mediante el puerto 449 (por defecto):
Las vulnerabilidades, ambas son del tipo XML External Entity (XXE), permiten aprovechar una incorrecta validación en el análisis del XML recibido para, por ejemplo, acceder a ficheros del sistema.
Para ello, accedemos al recurso:
https://<IP>:<PUERTO>/smb/css/setting.html
Éste gestiona las distintas cuentas que tienen acceso al servicio AiCloud:
Al crear una:
La información interesante aparece reflejada en la petición enviada al servidor:
La parte interesante aparece en el cuerpo de la petición POST, tratándose de un XML con la información de la cuenta. En este punto supongamos que, como en el caso anterior, hemos olvidado las credenciales de algún usuario del sistema. Para recuperarlas, podemos modificar dicho XML para, por ejemplo, mostrar el fichero /etc/passwd:
Siendo la respuesta del servidor un ‘200 OK’ puesto que el usuario que estamos creando no existe en la plataforma. A continuación, al volver a acceder al recurso de gestión de las cuentas (https://<IP>:<PUERTO>/smb/css/setting.html) aparecerá el contenido del fichero solicitado:
La segunda vulnerabilidad de esta categoría es similar y se encuentra en el recurso:
Dicho esto, cabe decir que el modelo que he utilizado para las pruebas no es el único afectado. A partir de los modelos actualizados con parches similares, los siguientes routers también están afectados (puede que haya más):
- DSL-AC51
- DSL-AC52U
- DSL-AC55U
- DSL-N55U C1
- DSL-N55U D1
- DSL-AC56U
- DSL-N10_C1
- DSL-N12U C1
- DSL-N12E C1
- DSL-N14U
- DSL-N14U-B1
- DSL-N16
- DSL-N16U
- DSL-N17U
- DSL-N66U
- DSL-AC750
Timeline
- 18/09/2017 – Informo a ASUS de las vulnerabilidades.
- 18/10/2017 – Confirmación por parte del ASUS.
- 18/10/2017 – Parcheo de la vulnerabilidad del cambio de contraseña y publicado firmware beta.
- 24/10/2017 – Solucionadas las vulnerabilidades restantes y publicado firmware beta.
- 28/11/2017 – Publicada la versión final del firmware con las vulnerabilidades solucionadas.
Es importante también mencionar de forma positiva la gestión por parte de ASUS del incidente, pues su equipo de seguridad en todo momento demostró una correcta predisposición y una fluida interacción para resolver las vulnerabilidades.
Conclusión
He esperado un mes para publicar esta entrada, tiempo que a mi parecer, es suficiente para que se actualicen los dispositivos (no se hace automático). En caso de no haber actualizado, mi consejo es hacerlo con la mayor brevedad posible (a no ser que quieras conservar un método de cambio de contraseña alternativo).
¡Nos leemos en “breve”!
@aetsu