Security
Headlines
HeadlinesLatestCVEs

Headline

CVE-2022-20821: Cisco Security Advisory: Cisco IOS XR Software Health Check Open Port Vulnerability

A vulnerability in the health check RPM of Cisco IOS XR Software could allow an unauthenticated, remote attacker to access the Redis instance that is running within the NOSi container. This vulnerability exists because the health check RPM opens TCP port 6379 by default upon activation. An attacker could exploit this vulnerability by connecting to the Redis instance on the open port. A successful exploit could allow the attacker to write to the Redis in-memory database, write arbitrary files to the container filesystem, and retrieve information about the Redis database. Given the configuration of the sandboxed container that the Redis instance runs in, a remote attacker would be unable to execute remote code or abuse the integrity of the Cisco IOS XR Software host system.

CVE
#vulnerability#ios#cisco#redis#auth#rpm
  • There are workarounds that address this vulnerability:

    Option 1: This is the preferred method. Disable health check and explicitly disable the use cases.

    To effectively disable health check, enter the following commands exactly as shown:

    RP/0/RP0/CPU0:8000(config)#no healthcheck enable
    RP/0/RP0/CPU0:8000(config)#healthcheck use-case asic-reset disable
    RP/0/RP0/CPU0:8000(config)#healthcheck use-case packet-drop disable
    RP/0/RP0/CPU0:8000(config)#commit
    RP/0/RP0/CPU0:8000#

    Then remove the health check RPM from the device:

    RP/0/RP0/CPU0:8000#install package remove xr-healthcheck
    Wed May 18 05:00:08.060 UTCInstall remove operation 5.2.2 has started
    Install operation will continue in the background
    RP/0/RP0/CPU0:8000#
    RP/0/RP0/CPU0:8000#install apply restart
    Wed May 18 05:01:08.842 UTC
    Install apply operation 5.2 has started
    Install operation will continue in the background
    RP/0/RP0/CPU0:8000#

    Option 2: Use an Infrastructure Access Control List (iACLs) to block port 6379.

    To protect infrastructure devices and minimize the risk, impact, and effectiveness of direct infrastructure attacks, administrators are advised to deploy infrastructure access control lists (iACLs) to perform policy enforcement of traffic sent to infrastructure equipment. Administrators can construct an iACL by explicitly permitting only authorized traffic sent to infrastructure devices in accordance with existing security policies and configurations. For the maximum protection of infrastructure devices, deployed iACLs should be applied in the ingress direction on all interfaces to which an IP address has been configured. An iACL workaround cannot provide complete protection against this vulnerability when the attack originates from a trusted source address.

    The iACL policy denies unauthorized Redis communications packets on TCP port 6379 that are sent to affected devices. In the following example, 192.168.60.0/24 is the IP address space that is used by the affected devices. Care should be taken to allow required traffic for routing and administrative access before denying all unauthorized traffic. Whenever possible, infrastructure address space should be distinct from the address space used for user and services segments. Using this addressing methodology will assist with the construction and deployment of iACLs.

    ipv4 access-list Infrastructure-ACL-Policy ! !-- The following vulnerability-specific access control entries !-- (ACEs) can drop Redis Database communication packets ! deny tcp any 192.168.60.0 0.0.0.255 eq 6379 ! !-- Explicit deny ACE for traffic sent to addresses configured !-- within the infrastructure address space ! deny ip any 192.168.60.0 0.0.0.255 ! !-- Permit or deny all other Layer 3 and Layer 4 traffic in !-- accordance with existing security policies and configurations ! !-- Apply iACL to interfaces in the ingress direction
    ! interface GigabitEthernet0/0 ipv4 access-group Infrastructure-ACL-Policy in

    For additional information about iACLs, see Protecting Your Core: Infrastructure Protection Access Control Lists.

    While these workarounds have been deployed and were proven successful in a test environment, customers should determine the applicability and effectiveness in their own environment and under their own use conditions. Customers should be aware that any workaround or mitigation that is implemented may negatively impact the functionality or performance of their network based on intrinsic customer deployment scenarios and limitations. Customers should not deploy any workarounds or mitigations before first evaluating the applicability to their own environment and any impact to such environment.

Related news

Attackers Are Probing for Zero-Day Vulns in Edge Infrastructure Products

Nearly 20% of the zero-day flaws that attackers exploited in 2022 were in network, security, and IT management products, Mandiant says.

Cisco Issues Patch for New IOS XR Zero-Day Vulnerability Exploited in the Wild

Cisco on Friday rolled out fixes for a medium-severity vulnerability affecting IOS XR Software that it said has been exploited in real-world attacks. Tracked as CVE-2022-20821 (CVSS score: 6.5), the issue relates to an open port vulnerability that could be abused by an unauthenticated, remote attacker to connect to a Redis instance and achieve code execution. "A successful exploit could allow

CVE: Latest News

CVE-2023-50976: Transactions API Authorization by oleiman · Pull Request #14969 · redpanda-data/redpanda
CVE-2023-6905
CVE-2023-6903
CVE-2023-6904
CVE-2023-3907