CVE-2023-41570: CVE-2023-41570: Access Control vulnerability in MikroTik REST API

Recently, Mikrotik added a REST server as a new API for managing the router. It is a nice alternative to their proprietary API when automating RouterOS.

However, young software usually contains bugs. Sometimes, these bugs are security-related, and, together with not-so-safe defaults, they may create a vulnerability.

This vulnerability has been assigned the ID CVE-2023-41570.

Background

RouterOS (from Mikrotik) is a closed-source Linux-based operating system for network appliances, specifically switches, routers and firewalls. It is used in Mikrotik appliances (such as RouterBOARD), but it can be downloaded and installed on other devices and virtual machines.

The management interfaces of RouterOS include SSH, MAC-Telnet, Winbox (a proprietary Windows-only tool), Webfig (a web user interface), and a proprietary API (additionally, ISPs have also TR-069). Since version v7.1beta4, RouterOS also includes a REST server. The REST server is started as a sub-resource of Webfig at /rest. More information on the RouterOS REST API web page.

Authentication

RouterOS supports local and remote user authentication and authorization databases (via RADIUS). Users belong to groups, each with its own permissions set. The resulting permission set is additive – it is the sum of all permissions granted by groups.

By default, only the local database is used, and three groups are present: full, with unlimited access to the router; write, with almost complete access except for file transfer (to/from the router itself) and user policies, and read, with read-only access (plus reboot privileges). Also, by default, rest-api is a specific permission granted to all groups.

Users may be restricted to logging in only from specific IP addresses or networks.

The vulnerability

REST APIs are protected by HTTP Basic authentication. You should provide a valid username and password pair. The username must have the rest-api (which, by default, is granted to all groups).

The vulnerability lies in the fact that, while other interfaces (SSH, Webfig, etc.) check whether the user is authorized to log in from that specific IP address, this is not the case for the REST server. Users can access the REST server from any IP address, even if they are not authorized in the users’ database.

To exploit this vulnerability:

• the attacker must have a username and password pair that has rest-api permission (but no permission to log in from the attacker IP address);
• the firewall should allow access to the web user interface from the IP address of the attacker;
• Webfig (the web UI) must be enabled: the REST server is part of Webfig.

Note that, by default, all groups have the rest-api permission (any user is allowed to use REST APIs), and Webfig is enabled. There is no way to disable the REST server, as it is integrated into Webfig. This is unexpected; usually, services like SSH or proprietary APIs are under the “IP” -> “Services” menu with their independent entry. At the very least, there should be a flag in the Webfig service www to enable the REST server selectively (defaulting off).

So, I think the majority of those who left Webfig active don’t realize that they are exposing the REST endpoint too, and that every user can access it, regardless of the IP filter configured in the user database.

To exacerbate the problem, the read group has some dangerous permissions: sniff (to intercept traffic), reboot, and sensitive (read sensitive information, such as Wi-Fi passwords or IPSec pre-shared keys). I certainly do not expect a “read” user to reboot the router.

Mikrotik advisory and solution

Mikrotik released RouterOS version 7.12 with the fix (the changelog contains only a generic reference to “www - fixed allowed address setting for REST API users”).

Timeline

I followed the responsible disclosure process described in the “Responsible disclosure of discovered vulnerabilities” page. I reported the vulnerability at 2023-08-19 09:46:00 UTC and received the ACK at 2023-08-24 07:43:00 UTC. The fix was released in version 7.12 at 2023-11-09 09:45:00 UTC (time point from RouterOS changelog).