Examining the Open-source Python Application CVEs That Led to the Cisco Server Breach

Hackers recently exploited two critical vulnerabilities (CVEs) in SaltStack’s “Salt” management framework in order to compromise a handful of servers at Cisco. As defined by the National Vulnerability Database (NVD), the specific CVEs in question are:

• CVE-2020-11651: An authentication bypass vulnerability that can provide functionality to unauthenticated network clients
• CVE-2020-11652: A directory traversal vulnerability where untrusted input is not sanitized correctly, thereby providing open access to the master server’s entire file system

Exploitation of these vulnerabilities can allow an attacker to circumvent all authentication and authorization controls and publish arbitrary control messages, read and write files anywhere on Salt’s master server file system, and steal the secret key used to authenticate to the master as root. This provides an attacker with full remote command execution as root on both the master and all minions that connect to it.

Cisco discovered and remediated the problem on the same day that the compromises happened (May 7, 2020). However, any unpatched versions of Cisco’s Virtual Internet Routing Lab Personal Edition (VIRL-PE) or Cisco Modeling Labs Corporate Edition (CML-CE) products remain vulnerable to similar methods of exploitation.

Sponsorships Available

Sponsorships Available

Sponsorships Available

Securing Python-based Open-source Applications Like Salt

The Salt framework is an open-source library that is used to monitor and update the state of servers. And because it is written in the dynamic Python language (instead of a static language like Java or C), effective application security needs to be performed during the runtime. Traditional application security (AppSec) tools—like static application security testing (SAST) and dynamic application security testing (DAST)—cannot provide runtime protection and therefore may miss critical vulnerabilities in Python-based applications.

The solution to this issue is runtime application self-protection (RASP). An instrumentation-based RASP solution runs inside the application itself in production to validate request inputs and prevent vulnerabilities from being exploited.

And as with any application using open-source components, Salt’s adopted frameworks and libraries may include undiscovered or unpatched vulnerabilities. This is another situation where security that is embedded within the application runtime can help. Software composition analysis (SCA) observes open-source libraries during operation to accurately identify vulnerable components.

How Contrast Security Addresses These Vulnerabilities

Contrast’s instrumentation-based AppSec platform automates vulnerability identification and remediation verification by testing running applications via data flows. It provides visibility into every application route instead of attempting to analyze code or probe from the outside (i.e., SAST and DAST).

The Contrast DevOps-Native AppSec Platform includes Contrast Protect (RASP) for applications in production and Contrast OSS (SCA) and Contrast Assess interactive application security testing (IAST) for detecting and remediating vulnerabilities during development. (It is worth noting that Contrast Assess is currently the only IAST solution on the market that supports Python-based applications.)

Both of the CVEs present in the Salt framework were included in Contrast’s known vulnerability database since the day they were announced by the National Vulnerability Database (NVD)—April 30, 2020 (one week before the Cisco attack!).

Neither Contrast Assess nor Contrast Protect would have detected the CVE-2020-11651 authentication vulnerability because it was just exposing a resource by accident. In the case of the CVE-2020-11651 authentication vulnerability, Contrast OSS would have detected it and sent  an alert that the version of Salt in Cisco’s environment was critically vulnerable based on this known CVE.

The more critical CVE-2020-11652 directory traversal vulnerability would have been caught by all three Contrast platform solutions. Contrast OSS would have made the same Salt version alert as with the previous CVE. Because this is a path traversal attack, Contrast Protect would have blocked it in any mode of operation. Similarly, Contrast Assess would have also reported this vulnerability during the development/preproduction stages when data flowed from custom code into the library.

Contrast would have detected the vulnerabilities in the Salt library that was used and associated a severity level with each vulnerability.

Contrast Protect would observe the malicious exploit and block it from executing the vulnerability.