A reverse engineering of the firmware running on Ivanti Pulse Secure appliances has revealed numerous weaknesses, once again underscoring the challenge of securing software supply chains.

Eclypsiusm, which acquired firmware version 9.1.18.2-24467.1 as part of the process, said the base operating system used by the Utah-based software company for the device is CentOS 6.4.

“Pulse Secure runs an 11-year-old version of Linux which hasn’t been supported since November 2020,” the firmware security company said in a report shared with The Hacker News.

The development comes as threat actors are capitalizing on a number of security flaws discovered in Ivanti Connect Secure, Policy Secure, and ZTA gateways to deliver a wide range of malware, including web shells, stealers, and backdoors.

The vulnerabilities that have come under active exploitation in recent months comprise CVE-2023-46805, CVE-2024-21887, and CVE-2024-21893. Last week, Ivanti also disclosed another bug in the software (CVE-2024-22024) that could permit threat actors to access otherwise restricted resources without any authentication.

In an alert published yesterday, web infrastructure company Akamai said it has observed “significant scanning activity” targeting CVE-2024-22024 starting February 9, 2024, following the publication of a proof-of-concept (PoC) by watchTowr.

Eclypsium said it leveraged a PoC exploit for CVE-2024-21893 that was released by Rapid7 earlier this month to obtain a reverse shell to the PSA3000 appliance, subsequently exporting the device image for follow-on analysis using the EMBA firmware security analyzer.

This not only uncovered a number of outdated packages – corroborating previous findings from security researcher Will Dormann – but also a number of vulnerable libraries that are cumulatively susceptible to 973 flaws, out of which 111 have publicly known exploits.

Number of scanning requests per day targeting CVE-2024-22024

Perl, for instance, hasn’t been updated since version 5.6.1, which was released 23 years ago on April 9, 2001. The Linux kernel version is 2.6.32, which reached end-of-life (EoL) as of March 2016.

“These old software packages are components in the Ivanti Connect Secure product,” Eclypsium said. “This is a perfect example as to why visibility into digital supply chains is important and why enterprise customers are increasingly demanding SBOMs from their vendors.”

Furthermore, a deeper examination of the firmware unearthed 1,216 issues in 76 shell scripts, 5,218 vulnerabilities in 5,392 Python files, in addition to 133 outdated certificates.

The issues don’t end there, for Eclypsium found a “security hole” in the logic of the Integrity Checker Tool (ICT) that Ivanti has recommended its customers to use in order to look for indicators of compromise (IoCs).

Specifically, the script has been found to exclude over a dozen directories such as /data, /etc, /tmp, and /var from being scanned, thereby hypothetically allowing an attacker to deploy their persistent implants in one of these paths and still pass the integrity check. The tool, however, scans the /home partition that stores all product-specific daemons and configuration files.

As a result, deploying the Sliver post-exploitation framework to the /data directory and executing ICT reports no issues, Eclypsium discovered, suggesting that the tool provides a “false sense of security.”

It’s worth noting that threat actors have also been observed tampering with the built-in ICT on compromised Ivanti Connect Secure devices in an attempt to sidestep detection.

In a theoretical attack demonstrated by Eclypsium, a threat actor could drop their next-stage tooling and store the harvested information in the /data partition and then abuse another zero-day flaw to gain access to the device and exfiltrate the data staged previously, all the while the integrity tool detects no signs of anomalous activity.

“There must be a system of checks and balances that allows customers and third-parties to validate product integrity and security,” the company said. “The more open this process is, the better job we can do to validate the digital supply chain, namely the hardware, firmware, and software components used in their products.”

“When vendors do not share information and/or operate a closed system, validation becomes difficult, as does visibility. Attackers will most certainly, as evidenced recently, take advantage of this situation and exploit the lack of controls and visibility into the system.”

Several public and popular libraries abandoned but still used in Java and Android applications have been found susceptible to a new software supply chain attack method called MavenGate.

“Access to projects can be hijacked through domain name purchases and since most default build configurations are vulnerable, it would be difficult or even impossible to know whether an attack was being performed,” Oversecured said in an analysis published last week.

Successful exploitation of these shortcomings could allow nefarious actors to hijack artifacts in dependencies and inject malicious code into the application, and worse, even compromise the build process through a malicious plugin.

The mobile security firm added that all Maven-based technologies, including Gradle, are vulnerable to the attack, and that it sent reports to more than 200 companies, including Google, Facebook, Signal, Amazon, and others.

Apache Maven is chiefly used for building and managing Java-based projects, allowing users to download and manage dependencies (which are uniquely identified by their groupIds), create documentation, and release management.

While repositories hosting such dependencies can be private or public, an attacker could target the latter to conduct supply chain poisoning attacks by leveraging abandoned libraries added to known repositories.

Specifically, it involves purchasing the expired reversed domain controlled by the owner of the dependency and obtaining access to the groupId.

“An attacker can gain access to a vulnerable groupId by asserting their rights to it via a DNS TXT record in a repository where no account managing the vulnerable groupId exists,” the company said.

“If a groupId is already registered with the repository, an attacker can attempt to gain access to that groupId by contacting the repository’s support team.”

To test out the attack scenario, Oversecured uploaded its own test Android library (groupId: “com.oversecured”), which displays the toast message “Hello World!,” to Maven Central (version 1.0), while also uploading two versions to JitPack, where version 1.0 is a replica of the same library published on Maven Central.

But version 1.1 is an edited “untrusted” copy that also has the same groupId, but which points to a GitHub repository under their control and is claimed by adding a DNS TXT record to reference the GitHub username in order to establish proof of ownership.

The attack then works by adding both Maven Central and JitPack to the dependency repository list in the Gradle build script. It’s worth noting at this stage that the order of declaration determines how Gradle will check for dependencies at runtime.

“When we moved the JitPack repository above mavenCentral, version 1.0 was downloaded from JitPack,” the researchers said. “Changing the library version to 1.1 resulted in using the JitPack version regardless of the position of JitPack in the repository list.”

As a result, an adversary looking to corrupt the software supply chain can either target existing versions of a library by publishing a higher version or against new versions by pushing a version that’s lower than that of its legitimate counterpart.

This is another form of a dependency confusion attack where an attacker publishes a rogue package to a public package repository with the same name as a package within the intended private repository.

“Most applications do not check the digital signature of dependencies, and many libraries do not even publish it,” the researchers added. “If the attacker wants to remain undetected for as long as possible, it makes sense to release a new version of the library with the malicious code embedded, and wait for the developer to upgrade to it.”

Of the 33,938 total domains analyzed, 6,170 (18.18%) of them were found to be vulnerable to MavenGate, enabling threat actors to hijack the dependencies and inject their own code.

Sonatype, which owns Maven Central, said the outlined attack strategy “is not feasible due to the automation in place,” but noted that it has “disabled all accounts associated with expired domains and GitHub projects” as a security measure.

It further said it addressed a “regression in the public key validation” process that made it possible to upload artifacts to the repository with a non-publicly shared key. It has also announced plans to collaborate with SigStore to digitally sign the components.

“The end developer is responsible for security not only for direct dependencies, but also for transitive dependencies,” Oversecured said.

“Library developers should be responsible for the dependencies they declare and also write public key hashes for their dependencies, while the end developer should be responsible only for their direct dependencies.”