Back in the day, Ivanti disclosed CVE-2021-44529, a critical "code injection" vulnerability in its EPM Cloud Services Appliance (CSA) product.
Ivanti has been in the news recently as threat actors continue to actively exploit vulnerabilities in its products. The software vendor, at the time, proposed some interesting workarounds for the CVE.
Ivanti users had the choice of either applying a "patch 512" issued by the vendor, or manually editing a "csrf-magic.php" file in the product, and removing the last few lines of code present in it, starting with "// Obscure Tokens."
"Code injection" is a backdoor in OSS component
This led bug bounty hunter and security researcher Tuan Anh Nguyen to conclude that the so-called "code injection" vulnerability was in fact a "backdoor" in an open source component, "csrf-magic."
Csrf-magic, according to its website, is an open source library to help secure your application against Cross-Site Request Forgery (CSRF) attacks, by simply including the provided "csrf-magic.php" file above every PHP page.
The project, authored by Dr. Edward Z. Yang, PhD, maintains its official Git source code repo on repo.or.cz, although a GitHub repository also exists at ezyang/csrf-magic, purportedly also maintained by the author.
Note, the official Git repos for the project are different than the one shared by Nguyen at the time - hxxps://github(.)com/csrf-magic/csrf-magic… which no longer exists on GitHub. Archived copies of the latter, however, retain some pages and help us better understand what could have happened.
Archived pages showing the "csrf-magic/csrf-magic" repository:
Security researcher and blogger Ron Bowes of Greynoise Labs dug into the case again this month, and made some noteworthy observations.
Ivanti's workaround that suggested removing the code beyond the "// Obscure Tokens" line concerns this version of csrf-magic.php file:
Notice the malicious backdoor present from lines 399 to 407, packed between the legitimate blocks of code: the "csrf_hash()" function and another which loads the user configuration. The legitimate blocks are part of the real csrf-magic package, but the "obscure tokens" code pops out of nowhere.
The mysterious Git commit
This change was apparently introduced by a mysterious commit titled, "1.0.5 update" (ID: f7f84f887a5f2e19926a2ad3c48614905629d60b). Unfortunately, the particular commit itself exists nowhere anymore – not on the official csrf-magic Git repo, or any of its mirrors. No one knows what happened to it.
Bowes, who was able to successfully deobfuscate the PHP code explains in his blog post that the code reads values from 4 cookies, before running an "eval()" function to run suspicious code. He further shares a Metasploit exploit by another researcher ('h00die-gr3y') targeting the particular backdoor in Ivanti products:
Project likely cloned, backdoored by TA and… mistakenly used by Ivanti
As for why the problematic piece of obfuscated code can only be found in vulnerable Ivanti products and nowhere else (other than in an archived, now-removed GitHub repository) there’s one theory.
As opposed to hijacking the legitimate "csrf-magic" project and injecting a backdoor there, a threat actor (TA) seems to have cloned the original "csrf-magic" project. They then published it under a "csrf-magic/csrf-magic" GitHub repository that they maintain(ed), and added a malicious commit (f7f84f8 on Feb 1, 2014) to it under the guise of a "1.0.5 update."
Rather than updating anything, however, all that the commit did was introduce malicious code in an otherwise legitimate copy of the csrf-magic project.
This is a possible reason as to why the commit ID exists nowhere on csrf-magic's official and forked Git repos mentioned above, but only in the removed GitHub repository.
It further draws attention to the fact that a counterfeit "csrf-magic/csrf-magic" GitHub repository would have appeared more legitimate and trustworthy to product developers at the time than the project's official Git repository that lives primarily on repo.or.cz.
It is worth noting when searching for an OSS project, the first search result on Google, even if hosted by a known domain like GitHub, is not necessarily trustworthy.
Even today, benign clones and forks of "csrf-magic" exist on GitHub and distribution registries like Packagist, the leading repository of PHP packages. At this time, these appear to be safe to use, but we'd still advise consuming the project from its official source.
The Sonatype Security Research team as well as our automated malware detection systems will continue to monitor for malicious components, including illicit "csrf-magic" clones, and flag these to keep the dev community safe against threats.
The incident sheds light on the wide and untethered scale of the open source ecosystem that allows many possibilities, including making it possible to clone and fork projects for developers and threat actors alike. The OSS world provides various choices to consumers and developers to pick from, but not all such choices may be wise.
While cases of legitimate OSS projects getting hijacked and then infiltrated with malware have been widely reported on, this case apparently entailed a threat actor copying a legitimate project, altering it, and then casually passing it off as the real deal – thereby silently poisoning the open source software supply chain.
When consuming open source components, it is wise to thoroughly inspect them for signs of tampering, malicious code, suspicious commits, vulnerability exploits, and malware. Having reliable automation solutions in place like Sonatype Repository Firewall and Sonatype Lifecycle are the only way to tackle this growing issue.
