Privilege Escalation Vulnerability (11-13-17)
Overview
On October 18, 2017, Cisco Meraki corrected a technical error in the Meraki dashboard that made sensitive administrator authentication information available to other trusted dashboard users within the same organization. The issue allowed trusted users, with varying levels of permission, to view and access the API key and encrypted (BCrypt hashed and salted) passwords for their organization’s primary administrator. The primary administrator account is the first and/or oldest user account with full (read-write) permissions for an organization in the Meraki dashboard. This information disclosure presents the risk that less privileged users could perform API actions as though they were their organization’s primary administrator. Upon learning of the issue on October 18, 2017, Cisco Meraki immediately updated the dashboard so that the involved sensitive authentication information was no longer accessible.
If trusted users viewed the source of dashboard pages, they could have viewed the primary organization administrator’s API key and encrypted password. Cisco Meraki has no evidence to indicate that dashboard users have misused information exposed by this issue. The information, while sensitive, was only exposed to an organization’s own set of trusted users, and recovery of a usable password from its BCrypt hashed, salted version is unlikely.
Affected customers are those with more than one trusted user for the Meraki dashboard, and whose trusted users logged into dashboard between November 2016 and October 18, 2017. While risk associated with this incident is low, as a precaution, Cisco Meraki will be prompting affected administrators to update their passwords beginning on November 13, 2017. Additionally, Cisco Meraki will be directly contacting impacted primary organization administrators who have generated API keys, advising that they rotate their keys and update software using these keys at their earliest opportunity.
Viewing an Organization's API Key Status
The Meraki dashboard allows organization administrators to view the API key status across all the organizations for which they have full (read-write) organization admin permissions. To view this information, perform the following actions:
- Navigate to Announcements > Privilege Escalation Vulnerability
- Verify the API key status across any organizations that are displayed
This page is only visible to organization administrators with full (read-write) permissions. Only organizations where you are a full (read-write) organization administrator will be displayed. If nothing is listed on this page, none of the organizations where you are a full (read-write) org admin are impacted. Similarly, if you are a full (read-write) organization administrator and do not see this link, none of the organizations where you are a full (read-write) org admin are impacted.
From this page, the following actions can be performed:
- Review the Key regeneration advised column. If this column has entries that say Yes, regeneration advised, Cisco Meraki advises regenerating, revoking, or rotating these API keys.
- If the Key regeneration advised column is comprised entirely of No entries, your organizations are not impacted.
- To view API commands that were made by a particular user, click on the timeframe entry under API usage timeframe column. This will redirect to the organization changelog, filtered for this user's API changes during this timeframe.
If API used is Yes, but there are no changelog entries for this user, this means that the user only used the API to read or GET information.
Regenerating and Revoking API Keys
Cisco Meraki recommends that users immediately regenerate or revoke any existing API keys that were generated before October 18, 2017. Regenerating an API key will cause a new key to be created and the old key to be deleted. Revoking an API key will remove the API key from your dashboard user profile. To regenerate or revoke an API key, perform the following actions:
- Navigate to your username in the upper-right of the dashboard, select the username, then select My profile
- Scroll down to where it says API access
- Select either Revoke API key or Regenerate API key
If your API key is listed as Generate API key, this means you do not have an API key to regenerate or revoke.
Rotating an Existing API Key with a New Key
For admins that are currently using the Dashboard API as part of an automation, integration, or application, it may be desirable to generate a new API key for use, and to then revoke the old API key. To generate a new API key, and then later revoke any existing API keys, perform the following actions:
- Navigate to your username in the upper-right of the dashboard, select the username, then select My profile
- Scroll down to where it says API access
- Review the existing API key, then select Generate API key
- Once ready to deprecate the old API key, select Revoke on the applicable key
Frequently Asked Questions
What is a “primary organization administrator”?
Each organization has a primary administrator. Initially, it is the account holder that created the organization dashboard. If that administrator is removed from the organization, the role of primary administrator passes to the longest-tenured remaining administrator account in the organization.
How can I tell who is a primary organization administrator?
While there is no way to identify the primary organization administrator in the customer dashboard, Cisco Meraki has identified all potentially affected administrators and required that they update their passwords. The risk of a salted, hashed password being captured and reversed to its original form is fully remediated.
What is a “trusted user”?
Trusted users are those individuals that were granted access and assigned a dashboard user ID by an administrator in order to access an organization’s Meraki dashboard.
What is a hashed password?
A hashed password cannot be used to log into the Meraki dashboard. It is, instead, a string of characters that is the result of running a password through a complex hashing algorithm. This hashing algorithm takes the original password and generates a new string from it. This string is completely different from the original password. Recovery of a usable password from its salted and hashed version is extremely unlikely.
What is the scope of the impact?
This is limited in scope to those organizations who have a primary administrator and one or more trusted users who have logged into the Meraki dashboard.
What action is Cisco Meraki advising customers to take?
As a precautionary measure, Cisco Meraki is advising potentially affected organization admins to rotate their API keys. Primary admins are also being required to change their password upon the next login to the dashboard.
What is the potential risk to an organization, resulting from an exploit of this vulnerability?
The unintended exposure was limited to your organization’s own set of trusted administrators, and Cisco Meraki has no evidence to indicate misuse related to this issue. Reversing a hashed, salted password is highly unlikely. While the risk associated with this incident is considered low, any potential exposure of credential information is taken very seriously. As such, primary admins are being required to reset their passwords at the next dashboard login.
For admins whose API keys were exposed, the API functions are limited to their dashboard permissions, and the functions are otherwise outlined in this API documentation.
When did this exposure begin and when was it closed down?
This issue became present in November 2016. On October 18, 2017, Cisco Meraki updated its code so that API keys and hashed, salted passwords are no longer accessible in this way.
Are there additional steps that admins can take to ensure their dashboard is protected?
A list of administrators and permissions levels and logs of changes made via the API are always available for audit within the Meraki dashboard. Refer to the following documentation to learn more about Managing Dashboard Administrators and Permissions.