screaminggoat , to random
@screaminggoat@infosec.exchange avatar

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.

EDIT: Sygnia links attempted zero-day exploitation to Chinese state-sponsored threat actor it tracks as Velvet Ant (no article yet). See related Bleeping Computer reporting; Cisco warns of NX-OS zero-day exploited to deploy custom malware

cc: @campuscodi @briankrebs @cR0w @mttaggart

screaminggoat OP ,
@screaminggoat@infosec.exchange avatar

@jerry @campuscodi @briankrebs @cR0w @mttaggart https://www.sygnia.co/threat-reports-and-advisories/china-nexus-threat-group-velvet-ant-exploits-cisco-0-day/

CVE-2024-20399 that was identified by Sygnia allows an attacker with valid administrator credentials to the Switch management console to escape the NX-OS CLI and execute arbitrary commands on the Linux underlaying operating system.

https://www.bleepingcomputer.com/news/security/cisco-warns-of-nx-os-zero-day-exploited-to-deploy-custom-malware/

"The threat actors gathered administrator-level credentials to gain access to Cisco Nexus switches and deploy a previously unknown custom malware that allowed them to remotely connect to compromised devices, upload additional files and execute malicious code."

Post-compromise activity includes persistence for sure, but extended beyond that.

screaminggoat OP ,
@screaminggoat@infosec.exchange avatar
tinker , to random
@tinker@infosec.exchange avatar

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....)

Nabla ,
@Nabla@chaos.social avatar

@Di4na @dymaxion @raito @whitequark Sorry I really just see this as a threat to people that do a thing because they either like it or they want to build something. If I build software that gets adopted, cool. If not also fine. If it’s insecure in a way I need to care about I’ll care about it. If it’s insecure in a way someone else needs to care about it, also fine but not my problem. If the EU makes

tinker OP ,
@tinker@infosec.exchange avatar

@dymaxion

I think the premise your introducing here is backwards.

It's not a FOSS developers concern if some or all corporations take their software, exploit and extract value from it, use it without understanding its limitations, and then incur risk on top of it.

That's the corporations fault and responsibility.

FOSS developers create software for our own use and the use of others. The inherent social contract is constrained WITHIN THE BOUNDS of understanding the mutual aid and limitations of liability.

So... yay for corporations doing what corporations do, but its not FOSS's problem.

The corporations are fully welcome to develop their own software solutions extracting and exploiting their own human "resources".

@whitequark @raito @rst @AndresFreundTec

adulau , to random
@adulau@infosec.exchange avatar

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.

🔗 https://vulnerability.circl.lu/recent
:github: https://github.com/cve-search/vulnerability-lookup

Thanks to @rafi0t for the crazy work of fighting with the different formats.

@circl

maegul , to Fediverse
@maegul@hachyderm.io avatar

Mastodon CVE Report

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)

https://arcanican.is/excerpts/cve-2024-23832/discovery.htm

@fediverse

maegul OP ,
@maegul@hachyderm.io avatar

@skullgiver

The point though is that not all platforms had the problem, which means platform diversity would have lessened the significance.

jschauma , to random
@jschauma@mstdn.social avatar

Are you using / / ? Congratulations, you won a full container breakout vulnerability via leaked file descriptors that can "lead to full control of the host system".

https://github.com/opencontainers/runc/security/advisories/GHSA-xr7r-f8xq-vfvv

-2024-21626

  • All
  • Subscribed
  • Moderated
  • Favorites
  • random
  • test
  • worldmews
  • mews
  • All magazines