Some vulnerability in ASUS routers

A few months ago, I changed my old TP-LINK router to an ASUS. Since it is the de facto manufacturer recommended by my ISP, in order to avoid any complications that could lead to delays in getting my Internet up and running I decided to go with it.

Then comes a lonely afternoon of boredom, or perhaps out of habit (I wanted to start writing a report:D), so I start by trying a little apostrophe here, a marquee as the Wi-Fi name, , command execution in one of the network diagnostic pages and a long list of etc. In the end, one thing leads to another (you know how that goes…), you get involved and when you’re conscious you have Burp or ZAP open, you’ve gone over halfway through OWASP and you’ve been looking for hours for something to play with, something interesting to see how safe your brand-new router is.

Going into more technical details, the router I bought is an ASUS DSL-N14U B1 whose firmware, at the time of the tests, was in the version “1.1.2.3_345” published on 04/09/2017.

As for the vulnerabilities discovered, the first and most boring of these, is a Cross Site Scripting (XSS) that appears when accessing a nonexistent resource without using credentials.

For example, when accessing the resource:

https://<IP>/%22%3E%3Cscript%3Ealert(window.location.path)%3C/script%3E

This is how the final HTML code looks like after executing the web request:

Nothing new nor fancy, our HTML code is executed on the browser and we get our magic pop-up.

XSS in error page

About the following vulnerability, during the testing period, it is always a good practice is to check that all the resources that require authorization are properly authenticated prior to accessing any of them, due to a misconfiguration or an oversight in the role matrix, lol.

In the case of this particular device, one of the few resources I have identified, and perhaps one of the most relevant is the password reset form. That is, if you know how the request is formed, it is possible to change the access credentials of any user, such as the administrator. These privileges also apply (1 form, double the fun!!) to other router features such as the AiCloud service discussed below.

The password change request is as follows:

Simply by modifying the http_passwd field is enough to change the password of the administrator user (admin). This means that any user who has access to the application’s web interface can change the password of any user of the application and access the router’s administration panel.

To simplify the “complicated” process, the following Python (3) script allows us to change the administrator password if we have “forgotten it”:

To execute the script, simply pass the IP, user and new password as arguments. For example:

python3 asus-passReset.py https://192.168.1.1 admin raccoon

Although the previous vulnerability is the most critical, reviewing one of the services that ASUS offers in its devices, I found a couple of interesting vulnerabilities. The service in question is AiCloud which, in the words of ASUS itself, allows:

“ASUS AiCloud keeps you connected to your data wherever and whenever you have an internet connection. It links your home network and online web storage services, giving you access to your files using the AiCloud mobile app on your iOS, Android smartphones or via a personalized browser URL…”

AiCloud access form

This service, disabled by default, is accessible via port 449 once enabled (default):

The vulnerabilities, both of which are of the XML External Entity (XXE) type, make it possible to take advantage of incorrect validation in the analysis of the XML received to, for example, access system files.

To do this, we access the resource:

https://<IP>:<PORT>/smb/css/setting.html

It manages the various accounts that have access to the AiCloud service:

Account creation interface

By creating an account:

Account creation form

Interesting information appears in the request sent to the server:

The interesting part appears in the body of the POST request, being an XML with the account information. At this point let us suppose that, as in the previous case, we have forgotten the credentials of some user of the system. To recover them, we can simply modify the XML to, for exampledisplay the /etc/passwd file:

The server response is’ 200 OK’ since the user we are creating does not exist on the platform. Then, when you return to the account management resource (https://:/smb/css/setting.html) you will see the contents of the requested file:

Result of exploiting XXE vulnerability

The second vulnerability of this category is similar and is found in the resource:

Having said that, the router model I have used for testing is not the only one affected. From updated models with similar patches, the following routers are also affected (there may be more):

• 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

1. 18/09/2017 – Vulnerabilities reported to ASUS.
2. 18/10/2017 – ASUS confirmed.
3. 18/10/2017 – Password change vulnerability patched and beta firmware released.
4. 24/10/2017 – The remaining vulnerabilities fixed and beta firmware released.
5. 28/11/2017 – The final version of the firmware published with the vulnerabilities fixed.

It is also important to mention positively the ASUS management of the incident, as its security team demonstrated at all times a correct predisposition and fluid interaction to resolve vulnerabilities.

Conclusión

I have waited a month to publish this entry, which I think is enough time for the devices to be updated (not automatically). If you haven’t updated them, my advice is to do so as soon as possible (unless you want to keep an alternative method of changing your password).

@aetsu