just in time to celebrate infosec.exchange returning, Cisco zero day: Cisco NX-OS Software CLI Command Injection Vulnerability
CVE-2024-20399 (6.0 medium) A vulnerability in the CLI of Cisco NX-OS Software could allow an authenticated, local attacker to execute arbitrary commands as root on the underlying operating system of an affected device. This vulnerability is due to insufficient validation of arguments that are passed to specific configuration CLI commands. An attacker could exploit this vulnerability by including crafted input as the argument of an affected configuration CLI command. A successful exploit could allow the attacker to execute arbitrary commands on the underlying operating system with the privileges of root. Note: To successfully exploit this vulnerability on a Cisco NX-OS device, an attacker must have Administrator credentials.
In April 2024, the Cisco Product Security Incident Response Team (PSIRT) became aware of attempted exploitation of this vulnerability in the wild.
Sygnia identified that CVE-2024-20399 was exploited in the wild by a China-nexus threat group as a ‘zero-day’ and shared the details of the vulnerability with Cisco. By exploiting this vulnerability, a threat group – dubbed ‘Velvet Ant’ – successfully executed commands on the underlying operating system of Cisco Nexus devices. This exploitation led to the execution of a previously unknown custom malware that allowed the threat group to remotely connect to compromised Cisco Nexus devices, upload additional files, and execute code on the devices.
For the past few months, we have been working at CIRCL (Computer Incident Response Center Luxembourg) to develop an aggregated view of vulnerabilities. This is particularly in response to the recent fragmentation of sources due to regulations, vendors providing their own feeds, and the addition of sources such as the CISA known vulnerability list.
The project, known as 'vulnerability-lookup,' is also an open-source initiative. We offer an online version for user convenience. It already includes more than 15 sources, such as the NIST NVD CVE, CVEProject's cvelist, Cloud Security Alliance, GitHub Advisory Database, PySec Advisory Database, OpenSSF Malicious Packages, and the CSAF (OASIS) sources like Siemens, CERT-Bund, or Cisco.
I think a LOT of people are missing the fact that we got LUCKY with this malicious backdoor.
The backdoor was created by an Insider Threat - by a developer / maintainer of various linux packages. The backdoor was apparently pushed back on March 8th (I believe) and MADE IT PAST all QA checks.
Let me state that again. Any quality assurance, security checks, etc., failed to catch this.
This was so far upstream, it had already gotten into the major Linux distributions. It made it into Debian pre-release, Fedora rolling, OpenSUSE rolling, Kali rolling, etc.
This is an example of Supply Chain Security that CISOs love to talk and freak out about. This is an example of an Insider Threat that is the boogey man of corporate infosec.
A couple more weeks, and it would have been in many major distributions without any of us knowing about it.
The ONLY reason we know about it is because @AndresFreundTec got curious about login issues and some benchmarking checks that had nothing to do with security and ran the issue down and stumbled upon a nasty mess that was trying to remain hidden.
It was luck.
That's it. We got lucky this time.
So this begs the question. Did the malicious insider backdoor anything else? Are they working with anyone else who might have access to other upstream packages? If the QA checks failed to find this specific backdoor by this specific malicious actor, what other intentional backdoors have they missed?
And before anyone goes and blames Linux (as a platform or as a concept), if this had happened (if it HAS happened!!!) in Windows, Apple, iOS, etc.... we would not (or will not) know about it. It was only because all these systems are open source that Andres was able to go back and look through the code himself.
Massive props and kudos and all the thank yours to Andres, those who helped him, to all the Linux teams jumping on this to fix it, and to all the folks on high alert just before this Easter weekend.
I imagine (hope) that once this gets cleaned up, there will be many fruitful discussions around why this passed all checks and what can be changed to prevent it from happening again.
(I also hope they run down any and all packages this person had the signing key for....)
Didn't expect the mastodon CVE report/account would kinda end up being about platform diversity on the fediverse (TLDR: only mastodon really had the problem, which was huge)
Are you using #Docker / #containerd / #runc? Congratulations, you won a full container breakout vulnerability via leaked file descriptors that can "lead to full control of the host system".