9.8 CVE-2024-20439
A vulnerability in Cisco Smart Licensing Utility could allow an unauthenticated, remote attacker to log in to an affected system by using a static administrative credential.
This vulnerability is due to an undocumented static user credential for an administrative account. An attacker could exploit this vulnerability by using the static credentials to log in to the affected system. A successful exploit could allow the attacker to log in to the affected system with administrative privileges over the API of the Cisco Smart Licensing Utility application.
https://nvd.nist.gov/vuln/detail/CVE-2024-20439
Categories
CWE-912 : Hidden Functionality
Hidden functionality can take many forms, such as intentionally malicious code, "Easter Eggs" that contain extraneous functionality such as games, developer-friendly shortcuts that reduce maintenance or support costs such as hard-coded accounts, etc. From a security perspective, even when the functionality is not intentionally malicious or damaging, it can increase the product's attack surface and expose additional weaknesses beyond what is already exposed by the intended functionality. Even if it is not easily accessible, the hidden functionality could be useful for attacks that modify the control flow of the application.
CWE-798 : Use of Hard-coded Credentials
The product contains hard-coded credentials, such as a password or cryptographic key. Credential storage in configuration files is findable using black box methods, but the use of hard-coded credentials for an incoming authentication routine typically involves an account that is not visible outside of the code. Automated white box techniques have been published for detecting hard-coded credentials for incoming authentication, but there is some expert disagreement regarding their effectiveness and applicability to a broad range of methods. This weakness may be detectable using manual code analysis. Unless authentication is decentralized and applied throughout the product, there can be sufficient time for the analyst to find incoming authentication routines and examine the program logic looking for usage of hard-coded credentials. Configuration files could also be analyzed. For inbound authentication: Rather than hard-code a default username and password, key, or other authentication credentials for first time logins, utilize a "first login" mode that requires the user to enter a unique strong password or key. If the product must contain hard-coded credentials or they cannot be removed, perform access control checks and limit which entities can access the feature that requires the hard-coded credentials. For example, a feature might only be enabled through the system console instead of through a network connection. Condition Monitor firmware has a maintenance interface with hard-coded credentials Engineering Workstation uses hard-coded cryptographic keys that could allow for unathorized filesystem access and privilege escalation Distributed Control System (DCS) has hard-coded passwords for local shell access Programmable Logic Controller (PLC) has a maintenance service that uses undocumented, hard-coded credentials Firmware for a Safety Instrumented System (SIS) has hard-coded credentials for access to boot configuration Remote Terminal Unit (RTU) uses a hard-coded SSH private key that is likely to be used in typical deployments Telnet service for IoT feeder for dogs and cats has hard-coded password [REF-1288] Firmware for a WiFi router uses a hard-coded password for a BusyBox shell, allowing bypass of authentication through the UART port Installation script has a hard-coded secret token value, allowing attackers to bypass authentication SCADA system uses a hard-coded password to protect back-end database containing authorization information, exploited by Stuxnet worm FTP server library uses hard-coded usernames and passwords for three default accounts Chain: Router firmware uses hard-coded username and password for access to debug functionality, which can be used to execute arbitrary code Server uses hard-coded authentication key Backup product uses hard-coded username and password, allowing attackers to bypass authentication via the RPC interface Security appliance uses hard-coded password allowing attackers to gain root access Drive encryption product stores hard-coded cryptographic keys for encrypted configuration files in executable programs VoIP product uses hard-coded public credentials that cannot be changed, which allows attackers to obtain sensitive information VoIP product uses hard coded public and private SNMP community strings that cannot be changed, which allows remote attackers to obtain sensitive information Backup product contains hard-coded credentials that effectively serve as a back door, which allows remote attackers to access the file system
References
CPE
| cpe |
start |
end |
| Configuration 1 |
| cpe:2.3:a:cisco:smart_license_utility:*:*:*:*:*:*:*:* |
>= 2.0.0 |
< 2.3.0 |
REMEDIATION
EXPLOITS
Exploit-db.com
| id |
description |
date |
|
| No known exploits |
POC Github
Other Nist (github, ...)
CAPEC
Common Attack Pattern Enumerations and Classifications
| id |
description |
severity |
| 133 |
Try All Common Switches
An attacker attempts to invoke all common switches and options in the target application for the purpose of discovering weaknesses in the target. For example, in some applications, adding a --debug switch causes debugging information to be displayed, which can sometimes reveal sensitive processing or configuration information to an attacker. This attack differs from other forms of API abuse in that the attacker is indiscriminately attempting to invoke options in the hope that one of them will work rather than specifically targeting a known option. Nonetheless, even if the attacker is familiar with the published options of a targeted application this attack method may still be fruitful as it might discover unpublicized functionality. [Identify application] Discover an application of interest by exploring service registry listings or by connecting on a known port or some similar means. [Authenticate to application] Authenticate to the application, if required, in order to explore it. [Try all common switches] Using manual or automated means, attempt to run the application with many different known common switches. Observe the output to see if any switches seemed to put the application in a non production mode that might give more information. [Use sensitive processing or configuration information] Once extra information is observed from an application through the use of a common switch, this information is used to aid other attacks on the application |
Medium |
| 190 |
Reverse Engineer an Executable to Expose Assumed Hidden Functionality
An attacker analyzes a binary file or executable for the purpose of discovering the structure, function, and possibly source-code of the file by using a variety of analysis techniques to effectively determine how the software functions and operates. This type of analysis is also referred to as Reverse Code Engineering, as techniques exist for extracting source code from an executable. Several techniques are often employed for this purpose, both black box and white box. The use of computer bus analyzers and packet sniffers allows the binary to be studied at a level of interactions with its computing environment, such as a host OS, inter-process communication, and/or network communication. This type of analysis falls into the 'black box' category because it involves behavioral analysis of the software without reference to source code, object code, or protocol specifications. |
Low |
| 191 |
Read Sensitive Constants Within an Executable
|
Low |
| 70 |
Try Common or Default Usernames and Passwords
An adversary may try certain common or default usernames and passwords to gain access into the system and perform unauthorized actions. An adversary may try an intelligent brute force using empty passwords, known vendor default credentials, as well as a dictionary of common usernames and passwords. Many vendor products come preconfigured with default (and thus well-known) usernames and passwords that should be deleted prior to usage in a production environment. It is a common mistake to forget to remove these default login credentials. Another problem is that users would pick very simple (common) passwords (e.g. "secret" or "password") that make it easier for the attacker to gain access to the system compared to using a brute force attack or even a dictionary attack using a full dictionary. |
High |
MITRE
Techniques
| id |
description |
| T1078.001 |
Valid Accounts:Default Accounts |
| T1552.001 |
Unsecured Credentials:Credentials in files |
| © 2022 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. |
Mitigations
| id |
description |
| T1078.001 |
Applications and appliances that utilize default username and password should be changed immediately after the installation, and before deployment to a production environment. |
| T1552.001 |
Ensure that developers and system administrators are aware of the risk associated with having plaintext passwords in software configuration files that may be left on endpoint systems or servers. |
| © 2022 The MITRE Corporation. Esta obra se reproduce y distribuye con el permiso de The MITRE Corporation. |
Cybersecurity needs ?
Strengthen software security from the outset with our DevSecOps expertise
Integrate security right from the start of the software development cycle for more robust applications and greater customer confidence.
Our team of DevSecOps experts can help you secure your APIs, data pipelines, CI/CD chains, Docker containers and Kubernetes deployments.
Discover this offer
