A Vulnerability in Cisco Emergency Responder Could Allow for Arbitrary Code Execution

A vulnerability has been discovered in Cisco Emergency Responder that could allow for arbitrary code execution on a targeted host. Successful exploitation could allow an unauthenticated remote attacker to log in to the affected system using the root account and execute arbitrary commands. Cisco Emergency Responder is used to enhance the existing emergency 9-1-1 functionality offered by Cisco Unified Communications Manager. Depending on the privileges associated with the user, an attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than those who operate with administrative user rights.

There are currently no reports of this vulnerability being exploited in the wild.

A vulnerability has been discovered in Cisco Emergency Responder that could allow for arbitrary code execution.
Tactic: Credential Access (TA0006):
Technique: Unsecured Credentials (T1552):

• A vulnerability in Cisco Emergency Responder could allow an unauthenticated, remote attacker to gain unauthorized root level access to the affected system. An attacker could exploit this vulnerability by utilizing the stored static root credentials to log into the system. A successful exploit could then allow the attacker to run commands in the context of the root user. (CVE-2023-20101)

We recommend the following actions be taken:

• Apply appropriate patches provided by Cisco to vulnerable systems immediately after appropriate testing. (M1051: Update Software)
  o Safeguard 7.1: Establish and Maintain a Vulnerability Management Process: Establish and maintain a documented vulnerability management process for enterprise assets. Review and update documentation annually, or when significant enterprise changes occur that could impact this Safeguard.
  o Safeguard 7.4: Perform Automated Application Patch Management: Perform application updates on enterprise assets through automated patch management on a monthly, or more frequent, basis.
  o Safeguard 7.5: Perform Automated Vulnerability Scans of Internal Enterprise Assets: Perform automated vulnerability scans of internal enterprise assets on a quarterly, or more frequent, basis. Conduct both authenticated and unauthenticated scans, using a SCAP-compliant vulnerability scanning tool.

• Apply the Principle of Least Privilege to all systems and services. Run all software as a non-privileged user (one without administrative privileges) to diminish the effects of a successful attack. (M1026: Privileged Account Management)
  o Safeguard 4.7: Manage Default Accounts on Enterprise Assets and Software: Manage default accounts on enterprise assets and software, such as root, administrator, and other pre-configured vendor accounts. Example implementations can include: disabling default accounts or making them unusable.
  o Safeguard 5.4: Restrict Administrator Privileges to Dedicated Administrator Accounts: Restrict administrator privileges to dedicated administrator accounts on enterprise assets. Conduct general computing activities, such as internet browsing, email, and productivity suite use, from the user’s primary, non-privileged account.

• Block execution of code on a system through application control, and/or script blocking. (M1038: Execution Prevention)
  o Safeguard 2.5 : Allowlist Authorized Software: Use technical controls, such as application allowlisting, to ensure that only authorized software can execute or be accessed. Reassess bi-annually, or more frequently.
  o Safeguard 2.6 : Allowlist Authorized Libraries: Use technical controls to ensure that only authorized software libraries, such as specific .dll, .ocx, .so, etc., files, are allowed to load into a system process. Block unauthorized libraries from loading into a system process. Reassess bi-annually, or more frequently.
  o Safeguard 2.7 : Allowlist Authorized Scripts: Use technical controls, such as digital signatures and version control, to ensure that only authorized scripts, such as specific .ps1, .py, etc., files, are allowed to execute. Block unauthorized scripts from executing. Reassess bi-annually, or more frequently.

• Remove or deny access to unnecessary and potentially vulnerable software to prevent abuse by adversaries. (M1042: Disable or Remove Feature or Program)

• Safeguard 2.3: Address Unauthorized Software: Ensure that unauthorized software is either removed from use on enterprise assets or receives a documented exception. Review monthly, or more frequently.

• Safeguard 2.5: Allowlist Authorized Software: Use technical controls, such as application allowlisting, to ensure that only authorized software can execute or be accessed. Reassess bi-annually, or more frequently.

• Safeguard 2.7: Allowlist Authorized Scripts: Use technical controls, such as digital signatures and version control, to ensure that only authorized scripts, such as specific .ps1, .py, etc., files, are allowed to execute. Block unauthorized scripts from executing. Reassess bi-annually, or more frequently.

• Safeguard 4.1: Establish and Maintain a Secure Configuration Process: Establish and maintain a secure configuration process for enterprise assets (end-user devices, including portable and mobile, non-computing/IoT devices, and servers) and software (operating systems and applications). Review and update documentation annually, or when significant enterprise changes occur that could impact this Safeguard.

• Safeguard 4.8: Uninstall or Disable Unnecessary Services on Enterprise Assets and Software: Uninstall or disable unnecessary services on enterprise assets and software, such as an unused file sharing service, web application module, or service function.

• Safeguard 18.3: Remediate Penetration Test Findings: Remediate penetration test findings based on the enterprise’s policy for remediation scope and prioritization.

• Safeguard 18.5: Perform Periodic Internal Penetration Tests: Perform periodic internal penetration tests based on program requirements, no less than annually. The testing may be clear box or opaque box.