ZKConfigurationStore which is optionally used by CapacityScheduler of Apache Hadoop YARN deserializes data obtained from ZooKeeper without validation. An attacker having access to ZooKeeper can run arbitrary commands as YARN user by exploiting this. Users should upgrade to Apache Hadoop 2.10.2, 3.2.4, 3.3.4 or later (containing YARN-11126) if ZKConfigurationStore is used.

**Package**

maven org.apache.hadoop:hadoop-yarn-server (Maven)

**Affected versions**

< 2.10.2

\>= 3.0.0, < 3.2.4

\>= 3.3.0, < 3.3.4

**Patched versions**

2.10.2

3.2.4

3.3.4

GHSA-rr2m-gffv-mgrj: Deserialization of Untrusted Data in Apache Hadoop YARN

Payara through 5.2022.2 allows directory traversal without authentication. This affects Payara Server, Payara Micro, and Payara Server Embedded.

**Package**

maven fish.payara.api:payara-bom (Maven)

**Affected versions**

< 5.2022.3

**Patched versions**

5.2022.3

GHSA-h28c-453m-h9xm: Path Traversal in Payara

GitHub, the owner of the Node Package Manager (npm), proposes cryptographically linking source code and JavaScript packages in an effort to shore up supply chain security.

Organizations hosting significant parts of the open source software supply chain continue to adopt security measures that give developers and maintainers more tools to harden their projects against attacks and malicious code commits.

On Monday, GitHub announced that the company — which owns and maintains the Node Package Manager (npm) service — had called for developers to comment on a plan to adopt sigstore, which simplifies the signing of code components produced by projects as well as linking them back to the source code. The sigstore project has made digitally signing source code easier because individual maintainers no longer have to manage their own cryptographic infrastructure.

The technology service allows software developers to confirm what code has been used to generate a particular software application or component, says Brian Behlendorf, general manager of Open Source Security Foundation (OpenSSF), which maintains sigstore with the Linux Foundation.

"The assembly of components into software platforms and applications — all of that has been done with the same kind of security we had on the Internet before TLS \[Transport Layer Security\], frankly," he says. "We depended on a not necessarily misplaced but  high degree of trust that the infrastructure just did things for us or that there were not bad actors out there."

The proposal is the latest effort to make tools available to developers to secure the software supply chain. GitHub's npm, the Python Package Index (PyPI), and others have already urged developers to adopt two-factor authentication (2FA) to secure their accounts to prevent a compromise through a simple credential-based attack. GitHub, for example, has already moved the top 500 most-popular npm projects to 2FA and plans to require the security technology for any project with more than a million downloads per week.

Adopting digital signing of software packages is another critical step. In March, software security firm Sonatype announced it had "every intent to adopt sigstore as part of the Maven Central platform." Maven is the most popular source of Java software components and is maintained by Sonatype. PyPI has a specification called The Update Framework (TUF) that calls for digital signing of software packages, and the repository has a sigstore module under development.

The ability to attest that a program or executable came from a certain source code repository is an important step in securing the software supply chain, Justin Hutchings, director of project management for GitHub's security features, wrote in the blog post.

"When package maintainers opt-in to this system, consumers of their packages can have more confidence that the contents of the package match the contents of the linked repository," Hutchings said. "Historically, linking packages back to the source code has been difficult because it required individual projects to register and manage their own cryptographic keys."

GitHub acquired the Node Package Manager (npm) in 2020.

**SBOMs and "Salsa"**

The ability to sign code is fundamental to supply chain security. For example, a software bill of materials (SBOM) is a way to communicate to developers and security tools the components that make up a software project. Determining what software components and libraries are used in modern software projects is not always straightforward. Already, the US government has created requirements that any software sold to a federal agency needs to have an SBOM, but only a third of companies currently use SBOMs.

Another initiative, the Supply Chain Levels for Software Artifacts (SLSA), pronounced "salsa," provides developers and application security managers with a road map for securing software projects and communicating the software provenance.

"You need to have integrity, and you need to understand the quality — SLSA is really around that integrity part," says Kim Lewandowski, one of the original creators of SLSA and a co-founder at Chainguard, a software security firm. "A developer knows they're getting this piece of software that is built around these dependencies and these are the \[software\] artifacts that went into it."

Sigstore works because the technology makes signing code much easier for developers. OpenSSF's Behlendorf likens the platform to the Let's Encrypt service, which makes the keys for securing websites freely available and easy to deploy. Making any security technology easy to use is critical, he says.

"Greater security in open source software is going to come, not just by helping people write better code," he says. "It is not just going to come from a lot of people finding zero-days, and getting those fixed and fixes pushed out. It is going to come from having tooling that will make having better security throughout the supply chain a 'zero lift' for developers. If they even have to have a feature flag turned on, that is too much."

Software Supply Chain Chalks Up a Security Win With New Crypto Effort

The discovery adds to the growing list of recent incidents where threat actors have used public code repositories to distribute malware in software supply chain attacks.

Administrators of the Python Package Index (PyPI) have removed 10 malicious software code packages from the registry after a security vendor informed them about the issue.

The incident is the latest in a rapidly growing list of recent instances where threat actors have placed rogue software on widely used software repositories such as PyPI, Node Package Manager (npm), and Maven Central, with the goal of compromising multiple organizations. Security analysts have described the trend as significantly heightening the need for development teams to exercise due diligence when downloading third-party and open source code from public registries.

Researchers at Check Point's Spectralops.io uncovered this latest set of malicious packages on PyPI, and found them to be droppers for information-stealing malware. The packages were designed to look like legitimate code — and in some cases mimicked other popular packages on PyPI.

**Malicious Code in Installation Scripts**

Check Point researchers discovered that the threat actors who had placed the malware on the registry had embedded malicious code into the package installation script. So, when a developer used the "pip" install command to install any of the rogue packages, the malicious code would run unnoticed on the user's machine and install the malware dropper.

For example, one of the fake packages, called "Ascii2text," contained malicious code in a file (­\_init\_.py) imported by the installation script (setup.py). When a developer attempted to install the package, the code would download and execute a script that searched for local passwords, which it then uploaded to a Discord server. The malicious package was designed to look exactly like a popular art package of the same name and description, according to Check Point.

Three of the 10 rogue packages (Pyg-utils, Pymocks, and PyProto2) appear to have been developed by the same threat actor that recently deployed malware for stealing AWS credentials on PyPI. During the setup.py installation process, Py-Utils for instance connected to the same malicious domain as the one used in the AWS credential-stealing campaign. Though Pymocks and PyProto2 connected to a different malicious domain during the installation process, their code was near identical to Pyg-utils, leading Check Point to believe the same author had created all three packages.

The other packages include a likely malware-downloader called Test-async that purported to be a package for testing code; one called WINRPCexploit for stealing user credentials during the setup.py installation process; and two packages (Free-net-vpn and Free-net-vpn2) for stealing environment variables. 

"It is essential that developers are keeping their actions safe, double-checking every software ingredient in use and especially such that are being downloaded from different repositories," Check Point warns.

The security vendor did not immediately respond when asked how long the malicious packages might have been available on the PyPI registry or how many people might have downloaded them.

**Growing Supply Chain Exposure**

The incident is the latest to highlight the growing dangers of downloading third-party code from public repositories without proper vetting.

Just last week, Sonatype reported discovering three packages containing ransomware that a school-age hacker in Italy had uploaded to PyPI as part of an experiment. More than 250 users downloaded one of the packages, 11 of whom ended up having files on their computer encrypted. In that instance, the victims were able to get the decryption key without having to pay a ransom because the hacker had apparently uploaded the malware without malicious intent. 

However, there have been numerous other instances where attackers have used public code repositories as launching pads for malware distribution.

Earlier this year, Sonatype also discovered a malicious package for downloading the Cobalt Strike attack kit on PyPI. About 300 developers downloaded the malware before it was removed. In July, researchers from Kaspersky discovered four highly obfuscated information stealers lurking on the widely used npm repository for Java programmers.

Attackers have begun increasingly targeting these registries because of their wide reach. PyPI, for instance, has over 613,000 users and code from the site is currently embedded in more than 391,000 projects worldwide. Organizations of all sizes and types — including Fortune 500 firms, software publishers and government agencies — use code from public repositories to build their own software.

10 Malicious Code Packages Slither into PyPI Registry

The malware packages had names that were common typosquats of a legitimate widely used Python library. One was downloaded hundreds of times.

An apparently school-age hacker based in Verona, Italy, has become the latest to demonstrate why developers need to pay close attention to what they download from public code repositories these days.

The young hacker recently uploaded multiple malicious Python packages containing ransomware scripts to the Python Package Index (PyPI), supposedly as an experiment.

The packages were named "requesys," "requesrs," and "requesr," which are all common typosquats of "requests" — a legitimate and widely used HTTP library for Python.

According to the researchers at Sonatype who spotted the malicious code on PyPI, one of the packages (requesys) was downloaded about 258 times — presumably by developers who made typographical errors when attempting to download the real "requests" package. The package had scripts for traversing folders such as Documents, Downloads, and Pictures on Windows systems and encrypting them. 

One version of the requesys package contained the encryption and decryption code in plaintext Python. But a subsequent version contained a Base64-obfuscated executable that made analysis a little harder, according to Sonatype.

**An Absence of Malice?**

Developers who ended up with their system encrypted received a pop-up message instructing them to contact the author of the package — "b8ff" (aka "OHR" or Only Hope Remains) — on his Discord channel, for the decryption key. Victims were able to obtain the decryption key without having to make a payment for it, Sonatype says.

"And that makes this case more of a gray area rather than outright malicious activity," Sonatype concludes. Information on the hacker's Discord channel shows that at least 15 victims had installed and run the package.

Sonatype discovered the malware on July 28 and immediately reported it to PyPI's administrators, the company says. Two of the packages have since been removed and the hacker has renamed the requesys package, so developers no longer mistake it for a legitimate package.

"There are two takeaways here," says Ankita Lamba, senior security researcher, at Sonatype. "First, be cautious when typing out the names of popular libraries, as typosquatting is one of the most common attack methods for malware," she says.

Second and more broadly, developers should always be cautious about what they’re downloading and what packages they’re incorporating into their software builds. "Open source is both critical fuel for digital innovation and a ripe target for software supply chain attacks," Lamba says.

**Growing Number of Malicious Code in Repositories**

The incident is among a growing number of instances recently in which threat actors have planted malicious code in widely used software repositories, with the goal of getting developers to download and install it in their environments. 

Some of them — like the latest incident — have involved typosquatted packages, or malware with similar sounding names as legitimate software on public software repositories. In May, for instance, Sonatype found that some 300 developers had downloaded a malicious package for distributing Cobalt Strike called "Pymafka" from the PyPI registry, thinking it was "PyKafka," a legitimate and widely downloaded Kafka client. 

Also in May, Sonatype discovered another malicious package on PyPI called "karaspace," used for stealing system information, that had the same name as a legitimate Kafka project on GitHub.

In July, researchers at Kaspersky discovered four information-stealing packages in the Node Package Manager (npm) repository. The same month, ReversingLabs reported finding some two-dozen, heavily obfuscated npm modules for stealing data that had been downloaded more than 27,000 times. The vendor estimated the malicious packages were likely installed in hundreds — and likely even thousands — of mobile applications and websites.

Security researchers have pointed to the trend as heightening the need for organizations to pay closer attention to their software supply chains — especially when it comes to using open source software from public repositories such as PyPI, npm, and Maven Central.

**A "Fun" Research Project**

Following the latest discovery, researchers at Sonatype contacted the author of the malicious code and found him to be a self-described school-going hacker apparently intrigued by exploits and the ease of developing them.

Lamba says b8ff told Sonatype that the ransomware script was completely open source and part of a project that he had developed for fun.

"As they are a school-going 'learning developer,' this was meant to be a fun research project on ransomware exploits that could have easily gone much further astray," Lamba says. "The author went on to say that they were surprised to see how easy it was to create this exploit and how interesting it was."

School Kid Uploads Ransomware Scripts to PyPI Repository as 'Fun' Project

‘We believe that announcing vulnerabilities without a fix is the best solution for a difficult problem’

‘We believe that announcing vulnerabilities without a fix is the best solution for a difficult problem’

Open source DevOps platform Jenkins is warning users of unpatched security vulnerabilities impacting more than a dozen plugins.

A leading open source automation server, Jenkins provides thousands of plugins to support building, deploying, and automating projects.

The organization’s latest security advisory lists a total of 27 plugin vulnerabilities, five of which were deemed to be ‘high’ impact and the majority of which remain unpatched.

**High five**

First on the list of high impact bugs – all of which were unfixed at the time of writing – is a cross-site request forgery (CSRF) vulnerability in the Coverity plugin (CVE-2022-36920).

It was found that the plugin fails to perform a permission check in an HTTP endpoint. In addition, this HTTP endpoint does not require POST requests, opening the door to CSRF attacks.

**YOU MIGHT ALSO LIKE** CompleteFTP path traversal flaw allowed attackers to delete server files

Meanwhile, an arbitrary file write vulnerability in the CLIF Performance Testing Plugin (CVE-2022-36894) allows attackers with ‘Overall/Read’ permission to create or replace arbitrary files on the Jenkins controller file system with attacker-specified content.

Stored cross-site scripting (XSS) flaws were also discovered in the Dynamic Extended Choice Parameter plugin (CVE-2022-36902) and Maven Metadata plugin (CVE-2022-36905), along with a reflected XSS vulnerability in the Lucene-Search plugin (CVE-2022-36922).

**Getting the word out**

Of the 27 plugin vulnerabilities listed in the latest Jenkins security advisory, 18 remained unpatched and are effectively zero-days.

Discussing the team’s decision to disclose these issues to the community in lieu of any fixes, Jenkins security officer Wadeck Follonier told _The Daily Swig_: “The main objective of the Jenkins security team is to ensure the Jenkins plugin ecosystem is as secure as possible.

“With a plugin ecosystem as big as ours, it isn’t a surprise that not every plugin is maintained all the time, and maintainers sometimes cannot be contacted, do not respond, or tell us they’re no longer able to maintain the plugin.

“In those cases, we analyze the vulnerability in depth, write up a detailed description, and announce it in a security advisory with other, fixed vulnerabilities.”

Read more about the latest security vulnerabilities

Follonier added: “We believe that announcing vulnerabilities without a fix is the best solution for a difficult problem, as it allows administrators to carefully consider their continued use of the affected plugin.

“Besides the Jenkins Advisories mailing list and our social channels, we inform administrators about vulnerabilities affecting their Jenkins instance directly on the UI immediately after publishing an advisory, so every Jenkins administrator gets informed about this.

“Our recommendation to Jenkins administrators is to read our security advisories to understand whether they’re impacted,” Follonier said. “A lot of vulnerabilities are irrelevant to instances with only a single administrator user that are inaccessible to others, for example.

“Of course, if they are unsure whether they are affected, the safest thing to do is to uninstall the plugin.”

**RECOMMENDED** Trio of XSS bugs in open source web apps could lead to complete system compromise

Jenkins security: Unpatched XSS, CSRF bugs included in latest plugin advisory

In Eclipse Californium version 2.0.0 to 2.7.2 and 3.0.0-3.5.0 a DTLS resumption handshake falls back to a DTLS full handshake on a parameter mismatch without using a HelloVerifyRequest. Especially, if used with certificate based cipher suites, that results in message amplification (DDoS other peers) and high CPU load (DoS own peer). The misbehavior occurs only with DTLS_VERIFY_PEERS_ON_RESUMPTION_THRESHOLD values larger than 0.

CVE-2022-2576: 580018 – Denial-of-Service vulnerability in the DTLS stack

Incorrect signature trust exists within Google Play services SDK play-services-basement. A debug version of Google Play services is trusted by the SDK for devices that are non-GMS. We recommend upgrading the SDK past the 2022-05-03 release.

CVE-2022-1799: Release Notes  |  Google Play services  |  Google Developers

Jenkins rhnpush-plugin Plugin 0.5.1 and earlier does not perform a permission check in a method implementing form validation, allowing attackers with Item/Read permission but without Item/Workspace or Item/Configure permission to check whether attacker-specified file patterns match workspace contents.

CVE-2022-36892: Jenkins Security Advisory 2022-07-27

A missing permission check in Jenkins HashiCorp Vault Plugin 354.vdb_858fd6b_f48 and earlier allows attackers with Overall/Read permission to obtain credentials stored in Vault with attacker-specified path and keys.

Tag

#maven