Security Vulnerabilities
- CVEs Published In October 2021
An issue was discovered in Special:MediaSearch in the MediaSearch extension in MediaWiki through 1.36.2. The suggestion text (a parameter to mediasearch-did-you-mean) was not being properly sanitized and allowed for the injection and execution of HTML and JavaScript via the intitle: search operator within the query.
An issue was discovered in the Mentor dashboard in the GrowthExperiments extension in MediaWiki through 1.36.2. The Growthexperiments-mentor-dashboard-mentee-overview-add-filter-total-edits-headline, growthexperiments-mentor-dashboard-mentee-overview-add-filter-starred-headline, growthexperiments-mentor-dashboard-mentee-overview-info-text, growthexperiments-mentor-dashboard-mentee-overview-info-legend-headline, and growthexperiments-mentor-dashboard-mentee-overview-active-ago MediaWiki messages were not being properly sanitized and allowed for the injection and execution of HTML and JavaScript.
A vulnerability in the shared library loading mechanism of Cisco AnyConnect Secure Mobility Client for Linux and Mac OS could allow an authenticated, local attacker to perform a shared library hijacking attack on an affected device if the VPN Posture (HostScan) Module is installed on the AnyConnect client. This vulnerability is due to a race condition in the signature verification process for shared library files that are loaded on an affected device. An attacker could exploit this vulnerability by sending a series of crafted interprocess communication (IPC) messages to the AnyConnect process. A successful exploit could allow the attacker to execute arbitrary code on the affected device with root privileges. To exploit this vulnerability, the attacker must have a valid account on the system.
Pterodactyl is an open-source game server management panel built with PHP 7, React, and Go. A malicious user can modify the contents of a `confirmation_token` input during the two-factor authentication process to reference a cache value not associated with the login attempt. In rare cases this can allow a malicious actor to authenticate as a random user in the Panel. The malicious user must target an account with two-factor authentication enabled, and then must provide a correct two-factor authentication token before being authenticated as that user. Due to a validation flaw in the logic handling user authentication during the two-factor authentication process a malicious user can trick the system into loading credentials for an arbitrary user by modifying the token sent to the server. This authentication flaw is present in the `LoginCheckpointController@__invoke` method which handles two-factor authentication for a user. This controller looks for a request input parameter called `confirmation_token` which is expected to be a 64 character random alpha-numeric string that references a value within the Panel's cache containing a `user_id` value. This value is then used to fetch the user that attempted to login, and lookup their two-factor authentication token. Due to the design of this system, any element in the cache that contains only digits could be referenced by a malicious user, and whatever value is stored at that position would be used as the `user_id`. There are a few different areas of the Panel that store values into the cache that are integers, and a user who determines what those cache keys are could pass one of those keys which would cause this code pathway to reference an arbitrary user. At its heart this is a high-risk login bypass vulnerability. However, there are a few additional conditions that must be met in order for this to be successfully executed, notably: 1.) The account referenced by the malicious cache key must have two-factor authentication enabled. An account without two-factor authentication would cause an exception to be triggered by the authentication logic, thusly exiting this authentication flow. 2.) Even if the malicious user is able to reference a valid cache key that references a valid user account with two-factor authentication, they must provide a valid two-factor authentication token. However, due to the design of this endpoint once a valid user account is found with two-factor authentication enabled there is no rate-limiting present, thusly allowing an attacker to brute force combinations until successful. This leads to a third condition that must be met: 3.) For the duration of this attack sequence the cache key being referenced must continue to exist with a valid `user_id` value. Depending on the specific key being used for this attack, this value may disappear quickly, or be changed by other random user interactions on the Panel, outside the control of the attacker. In order to mitigate this vulnerability the underlying authentication logic was changed to use an encrypted session store that the user is therefore unable to control the value of. This completely removed the use of a user-controlled value being used. In addition, the code was audited to ensure this type of vulnerability is not present elsewhere.
A vulnerability in the API endpoints for Cisco DNA Center could allow an authenticated, remote attacker to gain access to sensitive information that should be restricted. The attacker must have valid device credentials. This vulnerability is due to improper access controls on API endpoints. An attacker could exploit the vulnerability by sending a specific API request to an affected application. A successful exploit could allow the attacker to obtain sensitive information about other users who are configured with higher privileges on the application.
Multiple vulnerabilities exist in the Link Layer Discovery Protocol (LLDP) implementation for Cisco Small Business 220 Series Smart Switches. An unauthenticated, adjacent attacker could perform the following: Execute code on the affected device or cause it to reload unexpectedly Cause LLDP database corruption on the affected device For more information about these vulnerabilities, see the Details section of this advisory. Note: LLDP is a Layer 2 protocol. To exploit these vulnerabilities, an attacker must be in the same broadcast domain as the affected device (Layer 2 adjacent). Cisco has released firmware updates that address these vulnerabilities.
Multiple vulnerabilities exist in the Link Layer Discovery Protocol (LLDP) implementation for Cisco Small Business 220 Series Smart Switches. An unauthenticated, adjacent attacker could perform the following: Execute code on the affected device or cause it to reload unexpectedly Cause LLDP database corruption on the affected device For more information about these vulnerabilities, see the Details section of this advisory. Note: LLDP is a Layer 2 protocol. To exploit these vulnerabilities, an attacker must be in the same broadcast domain as the affected device (Layer 2 adjacent). Cisco has released firmware updates that address these vulnerabilities.
Multiple vulnerabilities exist in the Link Layer Discovery Protocol (LLDP) implementation for Cisco Small Business 220 Series Smart Switches. An unauthenticated, adjacent attacker could perform the following: Execute code on the affected device or cause it to reload unexpectedly Cause LLDP database corruption on the affected device For more information about these vulnerabilities, see the Details section of this advisory. Note: LLDP is a Layer 2 protocol. To exploit these vulnerabilities, an attacker must be in the same broadcast domain as the affected device (Layer 2 adjacent). Cisco has released firmware updates that address these vulnerabilities.
Multiple vulnerabilities exist in the Link Layer Discovery Protocol (LLDP) implementation for Cisco Small Business 220 Series Smart Switches. An unauthenticated, adjacent attacker could perform the following: Execute code on the affected device or cause it to reload unexpectedly Cause LLDP database corruption on the affected device For more information about these vulnerabilities, see the Details section of this advisory. Note: LLDP is a Layer 2 protocol. To exploit these vulnerabilities, an attacker must be in the same broadcast domain as the affected device (Layer 2 adjacent). Cisco has released firmware updates that address these vulnerabilities.
Multiple vulnerabilities exist in the Link Layer Discovery Protocol (LLDP) implementation for Cisco Small Business 220 Series Smart Switches. An unauthenticated, adjacent attacker could perform the following: Execute code on the affected device or cause it to reload unexpectedly Cause LLDP database corruption on the affected device For more information about these vulnerabilities, see the Details section of this advisory. Note: LLDP is a Layer 2 protocol. To exploit these vulnerabilities, an attacker must be in the same broadcast domain as the affected device (Layer 2 adjacent). Cisco has released firmware updates that address these vulnerabilities.