OSM MANO:

From zero to admin

Vulnerability Discovery Report

1. INTRODUCTION

OSM MANO (Open Source MANO) is an open-source implementation of the ETSI NFV MANO (Management and Orchestration) stack hosted by ETSI (European Telecommunications Standards Institute). The purpose of OSM MANO is to centralize the management of the lifecycle of Virtualized Network Function (VNF).

Network Function Virtualization (NFV) is becoming more and more relevant not only on terrestrial infrastructures, but also in the aerospace sector. Thanks to NFV, in fact, it is possible to use software-based applications instead of physical boxes, making it possible for communication service providers to manage, orchestrate and expand network capabilities on-demand.

During some internal evaluation and testing activities on OSM Mano, Osmium’s security team identified two weaknesses in the publicly available version with relevant security implications if exploited. These vulnerabilities have been shared with the OSM MANO team following the responsible disclosure model and will be described in the following chapters.

The laboratory environment used for the tests was as follows: two VMs directly connected, one hosting OSM MANO and one hosting Kali Linux from which the attacks were performed.

The specifications of the two VMS are reported in the following pictures:

Hardware/Software configuration of the virtual machine used to perform the attacks: Kali linux live, 4CPU and 8GB of ram
Hardware configuration of the OSM Mano virtual machine. Operating system Ubuntu 22.04, 8 CPU, 12GB of RAM and 100GB of storage

The tests were performed on OSM MANO v14.0.2, v15.0.1, v16.0.0 and 17.0.0

2. CVE-2024-48729: BROKEN OBJECT LEVEL AUTHORIZATION

The first flaw identified in ETSI Open-Source MANO (OSM) allows any authenticated user, even the ones with low-privileged roles (such as project user), to perform privilege escalation and Denial of Service attacks.

The /osm/admin/v1/users API endpoint allows management activities on user accounts. While privileged accounts are authorized to perform actions on any account in the system (e.g. password resets, role assignments), unprivileged accounts (such as project users) should be restricted to managing only some aspects of their own account, like changing their password.

However, due to an improper implementation and the lack of restrictions, any authenticated user, regardless of their role, can perform any activity on any account, including the administrative ones.

By exploiting this vulnerability, an attacker may:

  • Change his own role to any role available in the system

  • Change other users’ details, including their username and passwords

By changing their own role, the attacker can perform a de-facto privilege escalation since they are able to autonomously set their own role to a privileged one.

By modifying the passwords of other users, an attacker can also achieve the following outcomes:

  • Complete account takeover of any user in the system (including administrative accounts) by setting a password of their choice

  • Denial of service by altering passwords, usernames, or roles, thereby preventing legitimate users from accessing the platform or performing their expected functions

The OSM mano reply to the attacker's login request showing the authentication token used in the future requests and the user role (project_user).

All these attack paths are explored In the following step-by-step exploitation of the vulnerability by a user we named evil.

2.1. Account take-over through credential replacement

Let’s first try changing the admin’s username and password. The update of user information is performed with a PATCH request to the endpoint /osm/admin/v1/users/$USER, where $USER can be the user UUID or the username.

The attacker’s request to rename the default admin in renamed_admin and changing the password to 'MyNewPassword1.' with the successful response received from OSM Mano.

As can be seen in the screenshot, a PATCH request performed against the admin account, changing its username and password, was successful (204 HTTP code in the response) and the successful change can be seen in the OSM MANO UI as well.

2.2. Privilege escalation by role self-assignment

A second attack path allows the attacker themself to perform a privilege escalation by self-assigning an administrative role.

As per the username/password replacement, the assignment of roles is performed through a PATCH request to the /osm/admin/v1/users/$USER with a JSON content that lists the role for each project associated with the user. It must be noted that the request contains the project named admin, which is the default project of OSM MANO and has nothing to do with the actual user role.

The attacker’s request to change his own role from project_user to system_admin with the successful response received from OSM Mano. The success of the attack is confirmed by a new login request returning the roles of the user.

As can be seen in the previous screenshot, we performed a PATCH request against the evil user UUID (but the attack works by targeting the username as well) and passing the system_admin role. The patch request returned a 204 status code stating the success of the operation. To further prove the success of the attack, a new login attempt returns the list of roles for the evil users, confirming the assignment of the system_admin role.

2.3. Denial of service by role-reassignment

Once it was confirmed that a regular user is capable of assigning his or her own role, a new attempt was made to verify if they can change other users’ role as well.

Once we reverted the evil user role to the project_user one, we performed a new PATCH request, this time targeting the renamed_admin account and attempting to assign the project_user role.

The attacker’s request to change the default admin role to project_user with the successful response received from OSM Mano.

The response received (204), confirms the success of the attack. This evidence states that a regular user can not only change the username and password of the default admin account, but change their own role as well, like any other user in the system, with potentially devastating effects on the availability of the platform.

This vulnerability has been fixed with OSM MANO releases 14.0.3, 15.0.2, 17.0.1. For version 16.0.0, a fix is available from commit 1188c195899581d8079173aba24b44a398a5481a.

Considering the severity and the simplicity of such an attack, it is strongly suggested to update the OSM instance to the latest release as soon as possible and to properly restrict the access to only trusted users.

3. CVE-2024-48730: IMPROPER RESTRICTION OF EXCESSIVE AUTHENTICATION ATTEMPTS

At the moment of testing, Open-Source MANO v14.x, v15.x, v16.x, v17.x resulted as having a default configuration that does not impose any restrictions on the authentication attempts performed by the default admin user. This means that the administrative account that is present by default on an OSM MANO instance is not protected against brute force attacks through a temporary account lockout or request throttling measures.

When the OSMNBI_USER_MANAGEMENT configuration is set to True, regular accounts will be subjected to the following rule:

  • Password expires after 30 days, and it will have to be renewed

  • Account expires after 90 days after the user is created, and it will have to be renewed by a system admin

  • The number of consecutive failed login attempts in OSM is 5. After that, if a user fails to login, the account will be locked

However, these rules do not apply to the default admin account which is set as always-active. This means that, with the current implementation, not only will the admin account never expire, but it will not be locked either. While this may prevent a user from being locked out and unable to access the platform with a privileged account, this leaves the most important user defenceless and an easy target.

At the moment of this writing, this is not clearly stated in the documentation and if it is overlooked and no appropriate countermeasures are put in place to protect the UI/API interface, an OSM MANO remains susceptible to brute-force attacks, with the concrete risk of full system compromise.

To establish the speed of the attack, we performed various brute-force tests against our target instance. The following screenshot shows the results of one of the attempts. Many tools exist to perform brute-force attacks, however, Wfuzz proved to be the fastest in handling the responses from OSM Mano.

WFuzz bruteforce attack against default admin statistics showing an average requests/sec of 241 and the successful retrieval of the default admin password after 48 seconds and 3101 attempts with a total of 11708 requests.

As can be seen, it was possible to perform 11708 requests (the size of our sample password list) in around 48.5 seconds, with an average speed of 246 requests/sec. By our analysis, the number of requests/second is only limited by the speed of the OSM instance and it could be possible to achieve even greater speed with an instance with more performant characteristics.

This vulnerability is tracked as CVE-2024-48729, and at the time of this writing, no fixes will be provided since it is considered work-as-intended, and guidelines have not been added to the official documentation.

Our suggestion, until further official information and guidelines are provided, is to secure your OSM instance, restricting IP access to the interface as much as possible. In addition, protective mechanisms capable of proper request throttling should be deployed and as well as automated blacklisting in response to excessive or anomalous request patterns.